跳转到内容

TCP延迟确认

维基百科,自由的百科全书

这是本页的一个历史版本,由Ehime留言 | 贡献2019年1月31日 (四) 09:57 (// Edit via Wikiplus)编辑。这可能和当前版本存在着巨大的差异。

TCP延迟确认(英語:TCP delayed acknowledgment)是传输控制协议的一些实现所使用的技术,用于改善网络性能。该技术可以在本质上将若干ACK报文组合在一起成为单个报文,从而减少协议开销。 但是,在某些情况下,该技术可能会降低应用程序性能。

方法和优点

RFC1122所说,一个主机可以延迟发送ACK报文高达500毫秒。 此外,以每完整的数据包为一段,ACK报文必须每两段发送一次。

延迟的ACK可以使应用程序有机会更新TCP接收窗口 ,也可以立即发送ACK报文。 对于某些协议(如Telnet) ,通过将ACK、窗口更新和响应数据组合到一个段中,可以将服务器发送的响应数量减少3倍。 [1]

问题

延迟ACK引入的额外等待时间在与某些应用程序和配置交互时可能导致进一步的延迟。 如果发送方正在使用Nagle的算法 ,则数据将由发送方排队,直到收到ACK。 如果发送方未发送足够的数据来填充最大段大小 (例如,如果它执行两次小的写操作,然后执行阻塞读取),则传输将暂停到ACK延迟超时。 Linux内核从版本2.4.4开始支持禁用延迟ACK的TCP_QUICKACK套接字选项。 [2]

让我们想象一下,Bob正在向Carol发送数据的情况。 Bob的套接字层具有少于一个完整数据包的数据。 根据Nagle的算法,在他收到已发送数据的ACK之前,不会发送这段数据。 与此同时,Carol的应用层在获取所有数据之前不会发送响应。 如果Carol使用延迟的ACK,她的套接字层将不会发送ACK,直到达到超时。

如果应用程序以较小的块发送数据并期望定期ACK,则可能发生这种负面交互。 为防止此延迟,应用程序层需要连续发送数据而无需等待ACK。 或者,Nagle的算法可能被发送方的应用程序禁用。

参考

  1. ^ http://tools.ietf.org/html/rfc1122#page-96
  2. ^ tcp(7) in Linux. manpages.info. [9 May 2018] (英语).