关于nagle与延迟ack的问题

Question

我在线阅读延迟ack与Nagle算法相结合，可能会出现性能问题。但据我所知，Nagle算法是延迟的。如果他们不一样，有什么区别？

Answer 1

它们不是一回事，但在某种程度上是相互关联的，当它们一起使用时，可能会产生一些陷阱和问题。

延迟ACK

延迟ACK可以看作是在接收端实现的东西。由于ACK延迟，ACK不会立即发送，而是延迟一段时间(通常为200 ms)。希望它需要发送的ACK可以与本地应用程序希望向另一个方向发送的一些数据进行组合或“打包”。

延迟的ACK使应用程序有机会更新窗口，也许还可以立即发送响应。特别是，在字符模式远程登录的情况下，延迟的ACK可以将服务器发送的段数减少3倍(ACK、窗口更新和回显字符都合并在一个段中)。此外，在一些大的多用户主机上，延迟ACK可以通过减少要处理的数据包总数来大大减少协议处理开销。然而，ACK的过度延迟会干扰往返定时和分组“时钟”算法。rfc1122

延迟ACK是用来避免这种情况的：

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

由于ACK延迟，TCP将在单个段中发送请求、ACK和响应。

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

John在这个论坛中提到，延迟的ACK是一个打赌，另一端将回复您刚才发送的内容几乎立即。除了一些RPC协议，这是不可能的。所以ACK延迟机制一次又一次地输掉赌注，延迟ACK，等待ACK可以被备份的数据包，没有得到它，然后发送ACK，延迟。

Nagle算法

Nagle算法可以看作是在发送端实现的，以提高效率，试图始终发送完整的TCP数据包。

从(TCP/IP图解(第1卷)：W. Richard Stevens的协议的Nagle中可以看出，当TCP连接有尚未被确认的未确认的数据时，只有在所有未确认的数据被确认后，才能发送小段(小于SMSS的数据)。相反，少量数据由TCP收集，并在确认到达时以单个段发送。此过程有效地迫使TCP进入停止等待行为，它停止发送，直到收到任何未完成的数据的ACK。实际上，正如John在这个论坛中提到的那样。如果您关闭Nagle算法，然后迅速将单个字节发送到套接字，则每个字节将作为一个单独的数据包输出。这可以增加一个或两个数量级的流量，吞吐量相应下降。

延迟蚁群算法与Nagle算法交互

延迟ACK和Nagle交互在(TCP/IP图解(第1卷)：W. Richard Stevens的协议中描述--考虑使用延迟ACK向服务器发送请求的客户端，服务器以不完全适合单个数据包的数据量进行响应。

在这里，我们看到客户端在从服务器接收到两个数据包之后，保留了一个ACK，希望能够支持发送到服务器的其他数据。通常，TCP需要为两个接收到的数据包提供ACK，如果它们是完全大小的，并且它们不在这里。在服务器端，由于Nagle算法正在运行，因此在返回ACK之前，不允许向客户端发送额外的数据包，因为最多允许一个“小”数据包未完成。延迟ACK和Nagle算法的结合导致了一种死锁形式(双方都在等待对方)。您还可以阅读斯图尔特·切希尔在本论文中由Nagle的算法与延迟ACK之间的交互所引起的问题。

Answer 2

纳格尔:在收到密码之前，不要发送小数据包。

延迟发送:延迟发送到接收到足够小的数据包为止。

所以他们是死锁