在上一篇文章中提到了TCP的延迟确认,延迟确认并不一定能提高性能,在某些场景下,开启延迟确认甚至会严重降低网络传输性能。
(一)下面列出几个开启延迟确认降低网络性能的场景:
场景一:
想象这样一个场景,服务端开启了延迟确认,客户端在同一时刻发送了9个TCP包,其中3、4、5号因为拥塞丢失了。
那么传输过程中发生了以下事件:
- 到达服务器的6、7、8、9号包触发了4个“Ack 3”,于是客户端快速重传3号包,此时它并不知道4号包也丢失了。
- 由于服务器上开启了延迟确认,所以它收到3号包之后,等待了200ms才回复Ack 4。
- 客户端重传4号包,然后服务器又等待了200ms才回复Ack 5。
- 客户端重传5号包,然后服务器又等待了200ms才回复Ack 10。
- 客户端传输新的10号包,自此网络拥塞就完全恢复了。
这样不断的等待回复,造成了传输效率的大幅降低。还有另一种可能是在某个200ms的延迟过程中,那些丢包的RTO已经被触发,所以进入了超时重传阶段,由于RTO阶段网络已经拥塞,发出的包几乎都没有达到目的地,所以这段时间相当于并没有传输任何数据。无论符合哪一种可能,性能都会严重下降。
解决方案:
关闭延迟确认,这样浪费在延迟确认上的600ms就省下来了。只要RTT不是太长,那么丢包也不会触发超时重传。
启用TCP SACK