微信号:dellemc_tech

介绍:为戴尔易安信客户提供技术支持服务,为广大IT行业用户分享技术文章与行业信息。

【大咖讲网络】最经典的网络问题

2017-07-18 16:27 林沛满

这也许称得上最经典的网络问题,很多大师从理论上分析过的,我能在现实中遇到也算三生有幸。

 

事情是这样的。有家公司来咨询一个性能问题,说是从AIX备份数据到Windows极其缓慢,只有1 MB/s,备份所用的协议是SFTP。我的第一反应就是抓个包,然后试试Wireshark的性能三板斧。

 

1.从Statistics->Summary菜单可见,平均速度是11 Mbit/s,的确只比1 MB/s高一些,见图1。

图1

 

 

2.从Analyze->Expert Infos 菜单看,网络状况堪称完美。请看图2,连一个Warnings和Notes都没有。这样的网络性能怎么会差?

图2

 

 

      3.选定一个从AIX发往Windows的包,然后点击Statistics->TCP StreamGraph ->TCP Sequence Graph(Stevens)菜单,从图3可见,这60秒中数据传输得很均匀,没有TCP Zero Window或者死机导致的暂停。

 

 

图3

 

 

试完三板斧,我们只能得到一个结论:备份的确进行得很慢,但是仅凭Wireshark自带的分析工具找不出根本原因,这也许意味着问题不在网络上,而是在接收方或者发送方上。幸好Wireshark不但能发现网络上的问题,也能反映出接收方和发送方的一些配置,只是需要一些技巧来发现。

 

因为数据是从AIX备份到Windows的,所以如果把SFTP(SSH File Transfer Protocol)包过滤出来,理论上应该看到大多数时间花在了从AIX到Windows的传输上。可是由图4发现,从AIX到Windows的包虽然占多数,但没花多少时间。反而从Windows到AIX的两个包(533和535)之间竟然隔了0.2秒。该现象在整个传输过程中出现得很频繁,说不定性能差的原因就在此处了。只要把根本原因找出来,就有希望解决问题。

图4

 

 

那么这0.2秒之间究竟发生了什么呢?我把过滤条件去掉后得到了图5所示的包。可见Windows发出533号包之后就停下来等,直到0.2秒之后AIX的Ack(534号包)到达了才发出535号。Windows停下来的原因是什么呢?它在这两个包里总共才发了700多字节(96+656)的数据,肯定不会是因为TCP窗口受约束所致。

 


 

图5

 

 

如果你研究过TCP协议,可能已经想到了愚笨窗口综合症(Silly window syndrome)和纳格(Nagle)算法。在某些情况下,应用层传递给TCP层的数据量很小,比如在SSH客户端以一般速度打字时,几乎是逐个字节传递到TCP层的。传输这么少的数据量却要耗费20字节IP头+20字节TCP头,是非常浪费的,这种情况称为发送方的愚笨窗口综合症,也叫“小包问题”(small packet problem)。为了提高传输效率,纳格提出了一个算法,用程序员喜闻乐见的方式表达就是这样的:

 

if有新数据要发送

 

  if数据量超过MSS(即一个TCP包所能携带的最大数据量)

 

    立即发送

 

  else

 

    if之前发出去的数据尚未确认

 

      把新数据缓存起来,凑够MSS或等确认到达再发送

 

    else

 

      立即发送

 

    end if

 

  end if

 

end if

 

 

 

图5所示的状况恰好就是小包问题。Windows发了533号包之后,本应该立即发送535的,但是由于535携带的数据量小于MSS,是个小包,根据Nagle算法只好等到533被确认(即收到534)才能接着发。这一等就是0.2秒,所以性能受到了大幅度影响。那为什么AIX要等那么久才确认呢?因为它启用延迟确认了,具体可参考本书的《一篇关于VMware的文章》。

 

Nagle和延迟确认本身都没有问题,但一起用就会影响性能。解决方法很简单,要么在Windows上关闭Nagle算法,要么在AIX上关闭延迟确认。这位客户最终选择了前者,性能立即提升了20倍。

 

  • 如果你足够细心,也许已经意识到图3有问题—既然传输过程中会频繁地停顿0.2秒,为什么图3显示数据传输很均匀呢?这是因为抓包时间太长了,有60秒,所以0.2秒的停顿在图上看不出来。假如只截取其中的一秒钟来分析,再点击Statistics ->TCP StreamGraph->TCP Sequence Graph(Stevens)菜单,你就能看到图6的结果,0.2秒的停顿就很明显了。

 

 

图6

 

 

按理说,世界上到处都有启用了Nagle和延迟确认的设备在通信,为什么很少有人说起呢?我猜测大多数受害者并没有发现这个原因,以为是带宽不足所致,所以就一直忍着。我要不是用了Wireshark,也是发现不了的。根据我后来的搜索,只有斯坦福大学的博士Stuart系统地阐述过一个现实中的问题,文章在他的个人博客上http://www.stuartcheshire.org/papers/nagledelayedack/。我读完这篇文章的感觉就像遇到了知音,很想把这哥们约出来喝一杯:

 

“这么隐蔽的问题你是怎么发现的?太厉害了!”

 

“和满兄一样看包啦,分分钟的事!”

 

“论天下英雄,唯司徒君与满耳。”

 

……

 

本系列文章取自林沛满的《Wireshark网络分析的艺术》一书。




其它参考文章:

【大咖讲网络】系列文章倾情奉献!



更多精彩内容,请点击阅读原文”进行查看!

如何每天都能收到如此精彩的文章?

①点击右上角点击查看官方账号”→点击关注

②长按并识别下图中的二维码,直接访问EMC中文支持论坛


 
戴尔易安信技术支持 更多文章 谈重复数据删除技术的风险和预防之策 NAS环境中的备份 制定备份策略需要考虑哪些因素? 备份系统的设计和备份技术的选择 私有云投资回报率:提高开发人员效率
猜您喜欢 一篇文看懂Hadoop:风雨十年,未来何去何从 Go 性能优化技巧 5\/10 被误解的 Node.js ( 一 ) 周鸿祎做智能硬件免费这事靠谱吗? 微商2.0:线上安利王国|深氪