有关老鹰与延迟确认的问题

它们不是一回事，而是有某种相关性，当一起使用时，可能会出现一些陷阱和问题。

延迟的ACK

延迟的ACK可以看作是在接收端实现的。 在延迟ACK的情况下，ACK不是立即发送，而是延迟一段时间（通常是200ms），希望它发送的ACK可以与本地应用希望发送到另一个方向的一些数据组合或“捎带” 。

延迟的ACK使应用程序有机会更新窗口，并且可能立即发送响应。 特别是，在字符模式远程login的情况下，延迟的ACK可以将服务器发送的段数减less3（ACK，窗口更新和回显字符全部组合在一个段中）。

另外，在一些大的多用户主机上，延迟的ACK可以通过减less要处理的分组的总数来大大降低协议处理开销。 然而，ACK的过度延迟会干扰往返时间和数据包“时钟”algorithm。 RFC1122

延迟ACK用于避免这种情况：

Client Server | | |----- Request ---->| | | |<------ ACK -------| | | |<---- Response ----| | | |------- ACK ------>| 

在延迟ACK的情况下，TCP将在单个段中发送请求ACK和响应。

 Client Server | | |----- Request ---->| | | |<-- Response/ACK---| | | |------- ACK ------>| 

约翰·纳格尔在这个论坛上提到

一个延迟的ACK是一个赌注，另一端会立即回复您刚发送的内容。 除了一些RPC协议，这是不太可能的。 所以ACK延迟机制反复失败，延迟ACK，等待可以捎带ACK的数据包，没有得到它，然后发送ACK，延迟。

Naglealgorithm

Naglealgorithm可以被看作是在发送端实现的一些东西，以提高效率，试图总是发送全尺寸的TCP数据包。

从TCP / IP说明（卷1）：由理查德·史蒂文斯的协议

Naglealgorithm说，当一个TCP连接有尚未被确认的未完成数据时，在确认所有未完成数据之前，不能发送小段（比SMSS小）。 相反，less量数据由TCP收集，并在确认到达时发送到单个段中。 此过程有效地强制TCP进入停止和等待行为，直到接收到任何未完成数据的ACK为止，停止发送。

实际上，正如John Nagle在这个论坛中提到的那样。

如果closuresNaglealgorithm，然后将单个字节快速发送到套接字，则每个字节将作为单独的数据包发送出去。 这可以增加一个或两个数量级的stream量，吞吐量相应地下降。

延迟ACK和Naglealgorithm交互

延迟的ACK和Naglealgorithm交互在TCP / IP说明的（第1卷）中描述：W.Richard Stevens的协议

考虑一个使用延迟ACK的客户端，它向服务器发送一个请求，而服务器响应的数据量并不完全适合单个数据包。

在这里，我们看到客户端在收到来自服务器的两个数据包之后，保留了一个ACK，希望额外的数据能够被送到服务器。 一般情况下，TCP只要是全尺寸的，就要为两个接收到的数据包提供一个ACK，而不是在这里。 在服务器端，因为Naglealgorithm正在运行，所以在返回ACK之前不允许向客户端发送额外的数据包，因为最多允许一个“小”数据包未完成。 延迟的ACK和Naglealgorithm的组合导致了一种死锁forms（每一方都在等待另一方）。

您也可以阅读Stuart Cheshire在本文中关于由Nagle的algorithm和Delayed ACK之间的交互引起的问题。

Nagle：不要发送小包，直到得到一个确认

延迟确认：延迟发送确认，直到收到足够的小包

所以他们是僵局