WAN链接性能测试的方法

在相距约200英里的位置之间，我们有一对新的路由多样的1Gbps以太网链路。“客户端”是一台功能强大的新型计算机（HP DL380 G6，双E56xx Xeons，48GB DDR3，一对300GB 10krpm SAS磁盘R1，W2K8R2-x64），“服务器”也是一台足够不错的计算机（HP BL460c G6 ，双E55xx Xeons，72GB，R1对146GB 10krpm SAS磁盘，双端口Emulex 4Gbps FC HBA（链接到双Cisco MDS9509s），然后连接到带有128 x 450GB 15krpm FC磁盘的专用HP EVA 8400（RHEL 5.3-x64）。

使用客户端的SFTP，使用大型（> 2GB）文件只能看到大约40Kbps的吞吐量。我们已经执行了服务器到“其他本地服务器”的测试，并通过本地交换机（Cat 6509s）看到了大约500Mbps的传输速度，我们将在客户端进行相同的操作，但是大约需要一天的时间。

您将使用什么其他测试方法向链接提供商证明问题出在哪里？

调整大象：
这可能需要调整，但这可能不是pQd所说的问题。这种链接称为“长胖管道”或大象（请参阅RFC 1072）。因为这是一条长距离的千兆管道（距离在这种情况下实际上是时间/延迟），所以tcp接收窗口必须很大（有关图片，请参见TCP / IP插图集1，TCP扩展部分）。

为了弄清楚接收窗口是什么，您需要计算带宽延迟乘积：

Bandwidth * Delay = Product

如果存在10MS延迟，则此计算器估计您需要约1.2 MB的接收窗口。我们可以使用上面的公式自己进行计算：

echo $(( (1000000.00/.01)/8  )) 
12500000

因此，您可能希望运行数据包转储，以查看tcp窗口缩放（允许更大窗口的TCP扩展）是否发生正确，以便在解决任何大问题后进行调整。

窗口绑定：
如果这是问题所在，那就是您没有缩放就限制了窗口大小，如果没有适当的窗口缩放并且无论管道大小如何，都有大约200ms的延迟，我会期望得到以下结果：

Throughput = Recieve Window/Round Trip Time

所以：

echo $(( 65536/.2 ))
327680 #Bytes/second

为了获得所看到的结果，您只需要解决延迟，即：

RTT = RWIN/Throughput

因此（对于40 KB / s）：

echo $(( 65536.0/40000.0 )) 
1.63 #Seconds of Latency

（请检查我的数学，当然这些不包括所有协议/标头开销）

40kbps的速度非常低[直到我怀疑媒体转换器/双工不匹配的程度[但是您有千兆位，所以半双工没有空间！]等）。必须有丢包或非常高的抖动。

iperf是我想到的第一个衡量可用吞吐量的工具。在一侧跑

iperf -s 

另一方面：

iperf -t 60 -c 10.11.12.13

然后您可以交换客户端/服务器角色，对双工使用-d等。在测试开始之前在两台计算机之间运行mtr，以查看未使用的链路上的延迟/丢包情况，以及它们在数据传输期间如何变化。

您会看到：抖动很小，没有数据包丢失，直到链路饱和到其容量的90％左右。

iperf for * nix and win，在这里和这里阅读有关它的信息。

* nix和win的 mtr 。

tracepath可以显示两个站点之间的路由问题。

iperf，ttcp和bwping可以为您提供有用的信息。

您知道如何设置1GB链接吗？您是通过此链接桥接还是路由？链接的SLA是什么？您可能会受到链接提供商的影响？

如果您仅获得40kbs，则存在一个严重的问题，您确定它不是1MB的链接，而是1GB / s的链接。您可能会发现链接的速度与您认为的不一样:-)

RFC 2544或Y.156sam

这些是网络测试，旨在由运营商证明SLA。IPERF等不是可验证的网络测试方法。