一个拥塞的低速链路出了问题，然而诊断网络速度并不是那么容易的事儿。

有一位客户联系我们，他在进行网络速度检查之后发现了网络性能问题。客户需要从中央存储系统传输大的计算辅助设计文件（0.5~1GB）到远程工作者那儿，其中有一些在15英里远的地方。在花大价钱购买1Gbps WAN链路之前，它决定使用WAN模拟器先验证预期的传输操作。文件存储系统通过一条10Gbps以太网链路连接数据中心交换机。客户连接采用的是一条从交换机到WAN模拟器的1Gbps以太网连接，然后再用另一条1Gbps链路连接客户端。具体参见图1。

图1

客户希望实现800~900Mbps的数据传输速度，而且没有任何其他的大流量应用程序争夺链路带宽。WAN模拟器一开始设置了0毫秒（ms）的延迟时间。文件传输也按预期方式进行，达到了预期的吞吐量。然而，当延迟时间增加到15ms时，吞吐量出现严重下降的现象。客户端的最大吞吐量只有420Mbps，而且经常会下降到100Mbps左右。为什么网络速度检查会出现如此大的差别呢？

分析数据

我们获取了文件存储系统和客户端的数据包快照，然后将它们导入到Wireshark中。由于731MB传输速度下的数据包数量较大，因此逐个数据包进行分析用处并不大。相反，我们使用了Wireshark的TCP序列空间图形化选项——选择流中的数据包，然后选择菜单Wireshark Statistics >TCP Stream Graphs > tcptrace。这样整个序列空间图就很好看。

但是，再仔细地分析，我们发现传输中有几秒钟时间丢掉了大量数据包。

传输一开始很好，但是随后遇到一些丢包。系统大约花了3/4秒钟时间恢复传输。数据丢包之后传输速度下降，正如序列数字图形的倾斜处所示。我们的分析并没有发现其他的丢包问题。传输713.5MB数据花费了17.28秒，相当于42.33Mbps~338Mbps的用户数据传输速度。我们预计传输会在7秒钟内结束，而不是17秒。这是其中一个较好的吞吐量测量结果。有时间测试显示吞吐量低至70~100Mbps。

关于网络速度检测的分析

存储系统开始发送数据，它有一条10Gbps的链路，但是它有15ms的延迟。这样就有18MB左右的带宽延迟。当网络设备缓冲区填满时，有大量数据包被丢弃。存储系统花了700ms的时间重新传输所丢掉的数据。然后，它应该以较慢开始速度恢复数据传输，然后逐步增加速度。这里需要进一步的分析。

我们的存储供应商在另一个同时运行的测试中对系统进行了分析。测试结果发现，由于数据包丢失，存储系统的TCP代码的拥塞窗口参数减少为1。此外，IT还指出，存储系统的TCP堆是基于TCP Reno代码的，而这种实现方式非常旧。当出现严重丢包现象时，内部拥塞窗口都会被设置为1。拥塞窗口期间不会传输任何的数据包，所以需要在传输中监控存储系统的内部组件，才能检测到这个问题。TCP Reno使用了一个额外的慢启动算法来逐步增大拥塞窗口大小，所以每一次过后传输窗口都会增加一个数据包的大小。

对于731MB文件，存储系统不会再遇到拥塞，这是因为恢复文件传输的时间很长，足够传输窗口恢复到可能导致更多丢包现象的临界点。如图3所示，在丢包和累加丢包之前的爬升形状不一样。

存储系统在提升速度时认为它运行在一条10Gbps路径上。然后，交换机因为其内部缓冲区资源耗光了而丢掉了一些数据包。存储系统的TCP堆会将拥塞窗口减少为1个数据包。存储服务器需要经过700ms的时间才发现问题和重新传输所丢掉的数据包。这种增加传输窗口大小的慢启动机制还使用了累加机制，数据包会在每一次成功传输（如窗口增加）之后叠加到传输窗口上。对于700Mbps文件而言，它永远到不了拥塞丢包的点。对Reno TCP堆进行研究发现，高延迟网络上有无数关于这个问题的报告。

问题并不在网络上

在这种情况下，网络速度检测所暴露的问题并不是网络问题；相反，问题出现在存储系统控制器所使用的老TCP代码上。这个问题是一个由高速发送端引起的低速链路（远程客户的1Gbps链路）拥塞过载问题，即存储系统和交换机之间的10Gbps接口出了问题。

增加路径中路由器的缓冲区可能只能延缓丢包发生的时间。如果有多个来源造成1个链路拥塞，一样可能出现相同的问题。最好的做法是使用服务质量（QoS）对流量进行优先级划分，抛弃不重要的数据包。如果这个方法行不通，那么可以使用权重式随机实行早期检测的方法，在拥塞开始形成之时就开始丢弃数据包，给来源提供负反馈信息。

这个问题还有一个有趣的方面，如果将10Gbps链路替换为1Gbps链路，那么传输速度就会达到800Mbps。存储系统不会遇到严重的丢包问题，因此也不会缩减拥塞窗口。在系统达到链路容量时会出现少量的丢包问题，但是它不足以导致存储系统的Reno代码关闭拥塞窗口和切换到累加慢启动状态。

解决方法是什么呢？我们提出了针对不同速度差异的不同解决方法：

• 使用QoS监控1Gbps，模拟出一条1Gbps路径；
• 使用10Gbps以太网暂停帧通知存储系统延迟发送；
• 配置一个1Gbps接口，使用策略路由、域名系统和NAT，迫使远程客户端流量在1Gbps路径上传输。有一个供应商自己进行了测试，验证了我们所观察到的问题，而且它反馈说暂停帧和QoS的方法没有作用。（这个结果很让人意外 ，因为我们确定监控1Gbps是有效的。我们希望获得QoS监控测试的数据包捕捉文件，以理解为什么它不起作用。）我们建议在存储系统和交换机之间使用1Gbps接口，似乎这是唯一可选的方法。

下一步是什么？

这是一个有趣的问题。客户将自己决定该采用哪一种方法。我们会继续思考这个问题，在得到数据包捕捉文件之后也会去分析QoS数据包流。

有意思的是，在提交了分析报告不久之后，我们知道有另一家工程公司遇到了类似的问题。它的解决方案是将数据从内部存储系统迁移到一个基于云的存储供应商上，它在每一个远程站点上使用Panzura缓存系统。它能够使更高带宽的VPN切换到较低价格的互联网连接上，从而帮助提升吞吐量。我们认为，这是一个创新的解决方法，但是它需要改变业务流程和基础架构，需要几个月时间才能实现。