《Wireshark网络分析的艺术》—来点有深度的-阿里云开发者社区

开发者社区> 云计算> 正文

《Wireshark网络分析的艺术》—来点有深度的

简介:

本节书摘来自异步社区《Wireshark网络分析的艺术》一书中的来点有深度的,作者林沛满,更多章节内容可以访问云栖社区“异步社区”公众号查看。

来点有深度的
Wireshark网络分析的艺术
前一篇文章发布后,被一些公众号转发了。于是就有资深技术人员找到我,说读完觉得不过瘾,希望来点有深度的。好吧,那篇的确只从表面上介绍了延迟确认在网络发生拥塞时的影响,要往深处分析的话还是有不少料的。

先发散一下思维:除了VMware所建议的关闭延迟确认,还有其他的方法可以解决这个问题吗?

答案是肯定的。既然VMware的文章说“某些提供iSCSI访问的存储阵列在出现网络拥塞时处理不当”,就说明还有些存储阵列是处理得当的,即使打开延迟确认也不怕。那它们又是如何处理的呢?我做了很多研究之后,发现它们其实就是启用了TCP SACK(Selective Acknowledgement)功能,因此在大量丢包的时候不需要每个重传包都确认一次,也就不怕延迟确认的影响了。图1从客户端的角度演示了同样丢包的情况下,启用SACK的TCP协议栈是怎样处理重传的。


6b6e120e3faa4f3adc676f752dd81d4aaf00b420

这个传输过程发生了以下事件。

1.客户端在同一时刻(或者说同一窗口)发送了9个TCP包,其中3、4、5号因为拥塞丢失了。

2.到达服务器的6、7、8、9号包触发了4个“Ack 3”。

3.由于启用了SACK,所以服务器可以在4个“Ack 3”中告知客户端哪些包已经收到了。

4.因为客户端已经知道哪些包丢了,哪些包已经收到,所以它可以一口气完成重传。

SACK信息在Wireshark中很容易看到。如图2所示,只要把“Ack=656925”和“SACK: 661857-663035”这两个因素结合起来,客户端就知道排在后面的数据段661857-663035已经送达,但排在前面的656925-661856(共4932字节)反而丢失了,因此它需要重传这段数据。从图3可以看到每个重传包的Len值,四个包加起来恰好就等于4932字节。


9ccef5aabbd16e4df96fb98ce53c36df353c861c

由此可见启用SACK其实比关闭延迟确认更高效,因为它可以一次性重传多个丢包,而不用每重传一个就等待一次Ack,白费多个往返时间。这在局域网环境中的优势还不太明显,如果是在远程镜像中,一个正常的往返时间都要花上百毫秒,那就更应该启用SACK了。我真的很好奇VMware为什么不提供这个建议。

说完SACK,再讲一个更加有深度的知识点:除了大量重传之外,延迟确认还会在什么场景下严重影响性能?

从本质上看,延迟确认之所以会在大量重传时影响性能,是因为它在该场景下会多次出现(甚至因为延迟太久而导致超时重传)。那么还有什么场景会导致延迟确认多次出现呢?凭空想象是很难得到答案的,不过当你看过的网络包足够多时,肯定会遇到一些。我个人遇到最多的是TCP窗口极小的情况,此时启用延迟确认简直就是雪上加霜。图4演示了服务器接收窗口只有2920字节(相当于两个MSS),且关闭了延迟确认时的场景。因为客户端每发两个包就会耗光窗口,所以不得不停下来等待服务器的确认。假如这时候在服务器上启用了延迟确认,那29号和30号之间、32号与33号之间……以及38号和39号之间都需要多等待200毫秒,意味着传输效率会下降数百倍。这个场景下的延迟确认杀伤力巨大,又非常隐蔽,所以第一次遇上的工程师根本不知所措。


39e0ad6aa0bec1032ffe58184eba36a7362b9105

其他的场景我也遇到过一些,不过次数很少,就不一一列举了。更值得关注的,是如何在Wireshark中发现延迟确认,并计算它所带来的影响。

由于延迟确认是一个正常的TCP机制,有其积极的一面,所以Wireshark是不会把它当作问题标志出来的,而且点击AnalyzeExpert Info菜单也是不会统计延迟确认的。难道我们只能靠人工去计算每个确认包的等待时间吗?我几年前就因此吃过一次亏——有位同事找我分析一个性能相关的网络包,我用Wireshark看了半天都没有发现问题,所以就斩钉截铁地说跟网络无关。后来客户自己尝试关闭了延迟确认,性能居然就飙升了,导致我和同事都非常尴尬。最后写分析报告的时候才想到办法:只要用“tcp.analysis.ack_rtt > 0.2 and tcp.len==0”过滤一下,就可以把所有超过200毫秒的确认都筛出来了(当然筛出来的不一定全都是延迟确认,追求精确的话就逐个检查)。图5正是我当年遇到的那个网络包,只要把过滤出来的包数乘以0.2秒,就知道大概浪费了多少时间。


cde849e99d76e2660342bdc9bc982a906eb40074

这两篇文章所列举的案例,其实在现实环境中广泛存在。不过由于症状只是性能差,所以很多用户以为是带宽不足导致的,就一直忍着。用Wireshark抓个包看看吧,很可能无需升级硬件,也可以帮你的系统大幅度提升性能的。

本文仅用于学习和交流目的,不代表异步社区观点。非商业转载请注明作译者、出处,并保留本文的原始链接。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
云计算
使用钉钉扫一扫加入圈子
+ 订阅

时时分享云计算技术内容,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。

其他文章