来源《wireshark网络分析的艺术》
A.传输慢可能是小包问题加延迟确认引起的
事情是这样的。有家公司来咨询一个性能问题，说是从AIX备份数据到Windows极其缓慢，只有1 MB/s，备份所用的协议是SFTP。我的第一反应就是抓个包，然后试试Wireshark的性能三板斧。
性能判断三板斧：
1．从Statistics →Summary菜单可见，Avg.Mbit是11 Mbit/s，的确只比1 MB/s高一些，
2．从Analyze →Expert Infos菜单看，网络状况堪称完美。连一个Warnings和Notes都没有。
3．选定一个从AIX发往Windows的包，然后点击Statistics→TCP StreamGraph→TCPSequence Graph（Stevens）菜单，从图3这60秒中数据传输得很均匀，没有TCPZero Window或者死机导致的暂停。
试完三板斧，我们只能得到一个结论：备份的确进行得很慢，但是仅凭Wireshark自带的分析工具找不出根本原因，这也许意味着问题不在网络上，而是在接收方或者发送方上。幸好Wireshark不但能发现网络上的问题，也能反映出接收方和发送方的一些配置，只是需要一些技巧来发现
抓包发现Windows到AIX的两个包（533和535）之间竟然隔了0.2秒，2个包里总共才发了700多字节（96+656）的数据，肯定不会是因为TCP窗口受约束所致，如果你研究过TCP协议，可能已经想到了愚笨窗口综合症（Silly window syndrome）和纳格（Nagle）算法，传输这么少的数据量却要耗费20字节IP头+20字节TCP头，是非常浪费的，这种情况称为发送方的愚笨窗口综合症，也叫“小包问题”（smallpacket problem）。为了提高传输效率，纳格提出了一个算法，携带的数据量小于MSS，是个小包，根据Nagle算法只好等到533被确认（即收到534）才能接着发。这一等就是0.2秒，所以性能受到了大幅度影响。那为什么AIX要等那么久才确认呢？因为它启用延迟确认了
Nagle和延迟确认本身都没有问题，但一起用就会影响性能。
解决方法很简单，1.要么在Windows上关闭Nagle算法，
2.要么在AIX上关闭延迟确认。这位客户最终选择了前者，性能立即提升了20倍
既然传输过程中会频繁地停顿0.2秒，为什么图3显示数据传输很均匀呢？这是因为抓包时间太长了，有60秒，所以0.2秒的停顿在图上看不出来。假如只截取其中的一秒钟来分析，再点击Statistics →TCP StreamGraph→TCPSequence Graph（Stevens）菜单，你就能看到图6的结果，0.2秒的停顿就很明显了
网友评论