本节书摘来自异步社区《Wireshark网络分析的艺术》一书中的来点有深度的，作者林沛满,更多章节内容可以访问云栖社区“异步社区”公众号查看。
来点有深度的
Wireshark网络分析的艺术
前一篇文章发布后，被一些公众号转发了。于是就有资深技术人员找到我，说读完觉得不过瘾，希望来点有深度的。好吧，那篇的确只从表面上介绍了延迟确认在网络发生拥塞时的影响，要往深处分析的话还是有不少料的。
先发散一下思维：除了VMware所建议的关闭延迟确认，还有其他的方法可以解决这个问题吗？
答案是肯定的。既然VMware的文章说“某些提供iSCSI访问的存储阵列在出现网络拥塞时处理不当”，就说明还有些存储阵列是处理得当的，即使打开延迟确认也不怕。那它们又是如何处理的呢？我做了很多研究之后，发现它们其实就是启用了TCP SACK（Selective Acknowledgement）功能，因此在大量丢包的时候不需要每个重传包都确认一次，也就不怕延迟确认的影响了。图1从客户端的角度演示了同样丢包的情况下，启用SACK的TCP协议栈是怎样处理重传的。
这个传输过程发生了以下事件。
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字节。
由此可见启用SACK其实比关闭延迟确认更高效，因为它可以一次性重传多个丢包，而不用每重传一个就等待一次Ack，白费多个往返时间。这在局域网环境中的优势还不太明显，如果是在远程镜像中，一个正常的往返时间都要花上百毫秒，那就更应该启用SACK了。我真的很好奇VMware为什么不提供这个建议。
说完SACK，再讲一个更加有深度的知识点：除了大量重传之外，延迟确认还会在什么场景下严重影响性能？
从本质上看，延迟确认之所以会在大量重传时影响性能，是因为它在该场景下会多次出现（甚至因为延迟太久而导致超时重传）。那么还有什么场景会导致延迟确认多次出现呢？凭空想象是很难得到答案的，不过当你看过的网络包足够多时，肯定会遇到一些。我个人遇到最多的是TCP窗口极小的情况，此时启用延迟确认简直就是雪上加霜。图4演示了服务器接收窗口只有2920字节（相当于两个MSS），且关闭了延迟确认时的场景。因为客户端每发两个包就会耗光窗口，所以不得不停下来等待服务器的确认。假如这时候在服务器上启用了延迟确认，那29号和30号之间、32号与33号之间……以及38号和39号之间都需要多等待200毫秒，意味着传输效率会下降数百倍。这个场景下的延迟确认杀伤力巨大，又非常隐蔽，所以第一次遇上的工程师根本不知所措。
其他的场景我也遇到过一些，不过次数很少，就不一一列举了。更值得关注的，是如何在Wireshark中发现延迟确认，并计算它所带来的影响。
由于延迟确认是一个正常的TCP机制，有其积极的一面，所以Wireshark是不会把它当作问题标志出来的，而且点击AnalyzeExpert Info菜单也是不会统计延迟确认的。难道我们只能靠人工去计算每个确认包的等待时间吗？我几年前就因此吃过一次亏——有位同事找我分析一个性能相关的网络包，我用Wireshark看了半天都没有发现问题，所以就斩钉截铁地说跟网络无关。后来客户自己尝试关闭了延迟确认，性能居然就飙升了，导致我和同事都非常尴尬。最后写分析报告的时候才想到办法：只要用“tcp.analysis.ack_rtt > 0.2 and tcp.len==0”过滤一下，就可以把所有超过200毫秒的确认都筛出来了（当然筛出来的不一定全都是延迟确认，追求精确的话就逐个检查）。图5正是我当年遇到的那个网络包，只要把过滤出来的包数乘以0.2秒，就知道大概浪费了多少时间。
这两篇文章所列举的案例，其实在现实环境中广泛存在。不过由于症状只是性能差，所以很多用户以为是带宽不足导致的，就一直忍着。用Wireshark抓个包看看吧，很可能无需升级硬件，也可以帮你的系统大幅度提升性能的。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。
