一、问题描述¶

某些iSCSI存储阵列在出现网络拥塞时处理不当，会严重影响VMware的读写性能。这和它们的TCP实现方式有关。

二、作者问题解决思路¶

2.1 分析思路¶

2.1.1 启用延迟确认¶

1、启用延迟确认时发生网络拥塞，如下

2、其传输过程解说如下: (1)客户端在同一时刻(同一窗口)发送了9个TCP包，其中3、4、5号因为拥塞丢失了。 (2)到达服务器的6、7、8、9号包触发了4个"ACK 3",此时客户端快速重传3号包，此时它并不知道4号包也丢了。 (3)由于服务器上启用了延时确认，所以它收到3号包之后，等待了200ms才回复ACK 4。 (4)客户端重传4号包，然后服务器又等待了200ms才回复了ACK 5。 (5)客户端重传5号包，然后服务器又等待了200ms才回复了ACK 10。 (6)客户端传输新的10号包，自此该网络拥塞就完全恢复了。

2.1.2 关闭延迟确认¶

1、关闭延迟确认时发生网络拥塞，如下

2、其传输过程解说如下: (1)客户端在同一时刻(同一窗口)发送了9个TCP包，其中3、4、5号因为拥塞丢失了。 (2)到达服务器的6、7、8、9号包触发了4个"ACK 3",此时客户端快速重传3号包，此时它并不知道4号包也丢了。 (3)由于服务器上关闭了延时确认，所以它收到3号包之后，同时也知道4、5号也丢了，等待了200ms回复ACK 10。 (4)客户端传输新的10号包，自此该网络拥塞就完全恢复了。

2.1.3 启用SACK¶

1、启用SACK时发生网络拥塞，如下

2、其传输过程解说如下: (1)客户端在同一时刻(同一窗口)发送了9个TCP包，其中3、4、5号因为拥塞丢失了。 (2)到达服务器的6、7、8、9号包触发了4个"ACK 3"。 (3)由于启用了SACK，所以服务器可以在4个"ACK 3"中告知客户端哪些包已经收到。 (4)因为客户端已经知道哪些包已经丢了，哪些包已经收到，所以它可以一口气完成重传。

2.2 解决方式¶

1、在VMware和存储阵列上关闭延迟确认(Delayed ACK)

2.3 总结¶

1、SACK其实比关闭延迟确认更高效，因为它可以一次性重传多个丢包，而不用每重传一个就等待一次ACK，白费多个往返时间。 2、从本质上看，延迟确认之所以会在大量重传时影响性能，是因为它在该场景下会多次出现(甚至因为延迟太久而导致超时重传)。 3、当TCP窗口极小的时候，会导致延时确认多次出现。

三、相关概念¶

3.1 VMware和iSCSI¶

可以把iSCSI存储阵列当作一台服务器，把VMware当作客户端。

3.2 延迟确认¶

3.2.1 原理¶

接收方在收到数据后，并不会立即回复ACK,而是延迟一定时间。一般ACK延迟发送的时间为200ms，但这个200ms并非收到数据后需要延迟的时间。系统有一个固定的定时器每隔200ms会来检查是否需要发送ACK包。

3.2.2 优点¶

少一些确认包，节省网络带宽。(很多TCP协议栈默认启用延迟确认)

3.2.3 缺点¶

凭空多出一段延迟