在VMware和iSCSI阵列上关闭延迟确认

文章出处：http://www.360doc.com/content/15/0115/11/21412_441002570.shtml#

有网友发给我一篇关于VMware的文章，说怎么都读不明白。我一开始还不以为然，没想到读了一半就想拍案叫绝——表面看来平淡无奇，但内在隐含的技术细节太妙了！要是早一点看到它，一定会收录到拙作《Wireshark网络分析就这么简单》的第三部分。

这篇文章大概是这么说的：

问题描述：

VMware可能会遭遇读写方面的性能问题，这是因为有些iSCSI阵列在处理网络拥塞时与众不同，它们用非常保守的方式来重传丢失的网络包，即每个来回只传一个。

解决方式：

在VMware和iSCSI阵列上关闭延迟确认（Delayed Ack）。

你可能会觉得这个解决方式与问题描述简直风马牛不相及，网络拥塞和延迟确认是怎样扯上关系的？实际上还真的很有关系，且听我慢慢说来。

首先来看看什么叫延迟确认。我用上海的笔记本（10.32.200.43）连接悉尼的服务器（10.32.23.55），同时在上海的笔记本上抓包。由下图可见，从上海发出一个SSH请求到收到悉尼的回复，总共用时149毫秒左右，这是正常的。但是笔记本收到回复之后，并没有立即确认，而是延迟了大约215毫秒（0.363628-0.148774）。

这就是传说中的延迟确认了。它的好处是，假如在这等待的215毫秒里上海的笔记本有数据要发，就可以在发数据时捎带确认信息，就像让室友出去吃饭的时候顺便给你带外卖一样。它的坏处就不用细说了，就是多出来215毫秒的延迟，一般可以忽略。

接着我们再来看看“有些iSCSI阵列在处理网络拥塞时与众不同”指的是什么。其实它指的就是NewReno在处理多个网络包丢失时的算法。以下图为例，发送方发出了8个网络包，其中2、3、4号包在路上丢失了。NewReno的处理方式是这样的：

1. 已经到达的5、6、7、8号包能利用dup ack触发2号包的快速重传。

2. 2号包到达后，接收方Ack 3，于是重传3号包。

3. 3号包到达后，接收方Ack 4，于是重传4号包。

4. 4号包到达后，接收方Ack 9，于是传输新的9号包。

这个过程本来没有任何问题，算是优雅地把2、3、4号包的窟窿给补上了。但是想象一下，假如接收方启用了延迟确认会怎么样？它将会在每一个Ack之前白等200多毫秒，数量一多就会耗时很长。假如丢失的是50个包，你可能要多等10秒钟才能补齐窟窿。在网络世界中，10秒钟已经算很长很长了，而丢失50个包是常有的事。

看完了以上分析，不知道你是否觉得VMware的文章写得很有道理？其实不然，更好的办法是启用SACK，这样重传过程还能更快：

1. 最后一个Dup Ack 2会告诉发送方：我没有收到2、3、4，但是收到了5、6、7、8.

2. 发送方可以一口气把2、3、4号包都重传了。

以上这些内容，其实在拙作的第70页《重传的讲究》，和第80页《延迟确认与Nagle算法》中都有零散提及。如果你认真阅读过那两篇，那么VMware描述的这个问题对你来说就很容易了。

注：VMware的那篇KB链接在此：http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1002598