本节书摘来自异步社区《Wireshark网络分析的艺术》一书中的一篇关于VMware的文章，作者林沛满,更多章节内容可以访问云栖社区“异步社区”公众号查看。
一篇关于VMware的文章
Wireshark网络分析的艺术
有位读者在VMware的知识库里找到一篇文章，觉得很像他正在遭遇的一个性能问题，便转发给我确认。作为好为人师的技术员，我当然不能让读者失望。
这篇文章大概讲了这样一件事。
问题描述
某些iSCSI存储阵列在出现网络拥塞时处理不当，会严重影响VMware的读写性能。这和它们的TCP实现方式有关。
解决方式
在VMware和存储阵列上关闭延迟确认（Delayed ACK）
VMware和iSCSI存储阵列是什么？我在知识库里找到一个网络拓扑，看起来很简单，大概如图1所示。我们无需理解得很深，只要把iSCSI存储阵列当作一台服务器，再把VMware当作其客户端就行了，两者通过以太网传输数据。
乍一看，这个“问题描述”与“解决方式”简直风马牛不相及。网络拥塞怎么能靠关闭延迟确认来解决？不过出于对VMware的一贯信任，我决定还是好好研究一下。
我们先要明白什么叫延迟确认，它可以用一个简单的例子来说明：在上海的笔记本上启动Wireshark抓包，然后用Putty远程登录一台位于悉尼的服务器。由图2可见，在上海发出一个SSH请求之后，经过149毫秒左右（即1号包和2号包之间的时间差）收到了悉尼的回复，这是正常的往返时间。但是笔记本收到回复之后，却没有立即确认，而是延迟了200毫秒以上（即2号包和3号包之间的时间差）才确认。
这个现象就是传说中的延迟确认，我在上一本书中也介绍过。为了让大家更好地理解它，我们再做个对比实验：我在笔记本上关闭了延迟确认，然后再次连接悉尼的服务器。从图3可见2号包和3号包之间几乎没有时间差了（只有0.000121秒，可以忽略）。
启用延迟确认是有好处的，假如在这等待的200毫秒里，上海的笔记本恰好有数据要发，就可以在发数据时捎带确认信息，省去了一个纯粹的确认包。图4就符合这种情况。笔记本收到11号包之后，等了41毫秒左右（即11号包和12号包之间的时间差）恰好又有一个SSH请求要发，就顺便把确认捎带过去了，因此省掉了一个纯粹的确认包。之所以有很多TCP协议栈默认启用延迟确认，正是基于这个原因——少一些确认包可以节省带宽嘛。
延迟确认的坏处也很明显，就是会凭空多出一段延迟。这个机制的作用很像你中午懒得去食堂吃饭，便等到下午出门上课时顺便去吃一点。结果就是少跑了一趟食堂，但是吃饭时间却被延后了。
理解了延迟确认的原理，我们再回顾VMware的那篇文章。一般来说，偶尔浪费200毫秒的等待时间并不算严重的问题，VMware为什么要这么在意呢？又不是等待很多个200毫秒。当我联想到“很多个”时，终于明白了——这世界上还真的存在一种很老的TCP的实现（RFC 2582），会导致拥塞时出现多个200毫秒的等待时间。详情且看下文分析。
图5从客户端的视角演示了启用延迟确认时，某些TCP协议栈在处理网络拥塞时的状况。
这个传输过程发生了以下事件。
1．客户端在同一时刻（或者说同一窗口）发送了9个TCP包，其中3、4、5号因为拥塞丢失了。
2．到达服务器的6、7、8、9号包触发了4个“Ack 3”，于是客户端快速重传3号包，此时它并不知道4号包也丢了。
3．由于服务器上启用了延迟确认，所以它收到3号包之后，等待了200毫秒才回复Ack 4。
4．客户端重传4号包，然后服务器又等待了200毫秒才回复Ack 5。
5．客户端重传5号包，然后服务器又等待了200毫秒才回复Ack 10。
6．客户端传输新的10号包，自此该网络拥塞就完全恢复了。
由于当时没有抓包，因此以上分析仅是我的推测。还有另一种可能是在某个200毫秒的延迟过程中，那些丢包的RTO（Retransmission Timeout）已经被触发，所以进入了超时重传阶段。无论符合哪一种可能，性能都会严重下降，因此VMware建议关闭延迟确认是很有道理的，只不过没把原理说清楚。我甚至怀疑写这篇文章的人也没真正理解，因为里面还提到了慢启动之类不太相关的东西。
假如把延迟确认关闭掉，那该TCP协议栈处理拥塞的过程就变成图6所示。包还是那些包，不过浪费在延迟确认上的600毫秒就省下来了。只要往返时间不是太长，那些丢包也不会触发超时重传，所以避免了第二种可能。
我把分析结果告诉了那位读者，确保这个修改没什么副作用。于是他壮着胆子关闭了延迟确认，果然VMware的性能就飙升了。图7是他在关闭之后抓的网络包，和上文分析的一模一样，果然连续丢了很多包，而且每个重传都需要确认一次。
我以前分享的案例都是先在Wireshark中找到症状，然后再结合协议分析找到原因的。而这次纯粹是依靠协议分析，预测能从包里看到什么，然后再用Wireshark验证的。听起来似乎是完全靠灵感，但灵感不是天生的，它来自长期的训练。只有在Wireshark中看过了延迟确认和大量重传的样子，才可能意识到它们放在一起会出大问题。
注意：
如果对那篇VMware的文章感兴趣，可以在其知识库http://kb.vmware.com中搜索1002598来找到它。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。
