
_START_ARTICLE_
TCP延迟确认
_START_SECTION_
方法和优点
_START_PARAGRAPH_
如RFC1122所说，一个主机可以延迟发送ACK报文高达500毫秒。 此外，以每完整的数据包为一段，ACK报文必须每两段发送一次。_NEWLINE_延迟的ACK可以使应用程序有机会更新TCP接收窗口 ，也可以立即发送ACK报文。  对于某些协议（如Telnet） ，通过将ACK、窗口更新和响应数据组合到一个段中，可以将服务器发送的响应数量减少3倍。
_START_SECTION_
问题
_START_PARAGRAPH_
延迟ACK引入的额外等待时间在与某些应用程序和配置交互时可能导致进一步的延迟。如果发送方正在使用Nagle的算法，则数据将由发送方排队，直到收到ACK。如果发送方未发送足够的数据来填充最大段大小（例如，如果它执行两次小的写操作，然后执行阻塞读取），则传输将暂停到ACK延迟超时。Linux内核从版本2.4.4开始支持禁用延迟ACK的TCP_QUICKACK套接字选项。 由此可以得知，如果发送方的套接字层的数据少于一个完整数据包，根据Nagle的算法，在收到已发送数据的ACK之前，是不会发送这段数据的。  与此同时，接收方方的应用层在获取所有数据之前不会发送响应。如果接收方启用了延迟的ACK，则它的套接字层将不会发送ACK，直到达到超时。_NEWLINE_如果应用程序以较小的块发送数据并期望定期ACK，则可能发生这种负面交互。  为防止此延迟，应用程序层需要连续发送数据而无需等待ACK。  或者，Nagle的算法可能被发送方的应用程序禁用。