网络性能出问题,问题并不在网络上,怎么解?

日期:2016-12-12作者:Terry Slattery

【TechTarget中国原创】

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

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

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

作者>更多

Terry Slattery
Terry Slattery

NetCraftsmen

网络监测与分析>更多

相关推荐

技术手册>更多

  • IT职业及网络认证指导手册

    随着经济的衰退, 有抱负的IT网络人员以及经验老道的职场人士开始重新审视就业市场。那么在这种经济下滑的形势下如何进行IT职业规划呢?网络认证能保证IT职业生涯吗?网络认证有什么步骤可遵循吗?各种不同认证之间有什么区别呢?哪种认证是最适合你的呢?本文将为大家一一介绍。

  • IPv6迁移攻略

    从2003年开始IPv6过渡就一直被人们提及,如今,亚洲地区IPv4地址已经消耗殆尽,但你准备好向IPv6迁移了么?本技术手册将为你详细介绍IPv6的迁移知识。

  • WAN优化控制器使用教程

    对于广域网(WAN)管理人员来说,确保应用交付的可用性十分重要,IT机构优化应用性能的一个主要方法就是通过部署WAN优化控制器(WOC)。

  • 使用脚本管理Windows网络(更新版)

    “授人以鱼,不如授人以渔。”的确如此。而在忙碌的IT世界里,这也适用于脚本化管理:“给人一个有用的脚本,不如教他自己写脚本。”

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 虚拟化
  • 服务器
  • 数据中心
【TechTarget中国原创】

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

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

520

图1

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

分析数据

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

2

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

3

传输一开始很好,但是随后遇到一些丢包。系统大约花了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数据包流。

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