延迟确认和Nagle算法

前篇文章介绍了三次握手和四次挥手，了解了TCP是如何建立和断开连接的，文末还提到了抓包挥手时的一个“异常”现象，当时无法解释，特地查了资料，知道了数据传输中的延迟确认策略。

何谓延迟确认策略？

WIKI:TCP delayed acknowledgment is a technique used by some implementations of the Transmission Control Protocol in an effort to improve network performance. In essence, several ACK responses may be combined together into a single response, reducing protocol overhead. However, in some circumstances, the technique can reduce application performance.即接收方收到包后，如果暂时没有内容回复给发送方，则延迟一段时间再确认，假如在这个时间范围内刚好有数据需要传输，则和确认包一起回复。这种也被称为数据捎带。延迟确认只是减轻网络负担，未必可以提升网络性能，有些情况下反而会影响性能。

正是这个策略，让图中缺少了一次断开连接的包，仔细看可以发现4405和4287之间时间也是差了200ms左右，为什么是200ms？根据TCP/IP详解卷一里面的描述是绝不大部分平台的时延是按200ms来实现的，但是不允许超过500ms。

谈到延迟确认就必须再谈谈Nagle算法，两者的作用都是减轻网络负担，Nagle算法起源于John Nagle在RFC896的提议，所以命名为Nagle算法。Nagle在描述The small-packet problem时提到TCP在传输1字节有用信息时必须传输41字节的数据，其中20字节的TCP头，20字节的IP头，4000%的开销在低负载网络是可以容忍的，但是在重负载网络，这种开销是会导致网络拥塞，进而导致重传和数据丢失。这里暂时先不用关注拥塞、重传等，后面再讨论。重点关注下Nagle算法的实现原理，即在发送的数据在未被确认前，如果有新的小数据生成，那就把小数据收集起来，等凑足一个MSS或者收到确认后再发送。

说到这，我们就清楚了提到的延迟确认和Nagle算法的作用都是降低网络负担，提高传输效率，但是未必能提升网络性能。

参考资料：

https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment

https://www.rfc-editor.org/rfc/pdfrfc/rfc896.txt.pdf

https://en.wikipedia.org/wiki/Nagle%27s_algorithm