TCP延迟与Nagle算法的比较

Question

当您的应用程序遭受TCP延迟ack和Nagle算法之间不幸的交互时，提供的常见解决方案是关闭Nagle的算法。

然而，在一般的网络搜索中，Nagle的算法总体上似乎更好(基于一般的算法以及这、这、这等)。但是看起来很难关闭延迟的ack，即使您关闭它，tcp堆栈也会在随后的数据交换中再次打开它。另一方面，Nagle的算法可以很容易地使用TCP_NODELAY或类似的选项关闭，并且保持不变。

纳格尔算法偏重延迟的背后原因是什么？与Nagle的算法相比，选择延迟ack的技术/非技术原因是什么？

编辑:正如@Bart van Ingen Schenau所指出的，当您无法控制客户端时，您所能做的就是关闭Nagle的algo，但是对客户端的控制是相当常见的，我想知道原因。

Answer 1

据我理解：

• Nagle的算法缓冲要发送的字节，直到可以发送一个完整的数据包，或者要发送的数据中的时间差太大。如果您发送一些小东西，这会导致延迟发送数据。
• 延迟ACK延迟发送ACK消息，以便将其与在返回路径上发送的数据包相结合。这就延迟了另一端接收数据的确认。

对Nagle算法的控制完全在你这一边。应用该算法的是您的本地TCP堆栈。另一方面，延迟ACK是由您的通信伙伴的TCP堆栈创建的，您对它没有太多的控制。尤其是不跨越不同的联系。

Answer 2

看起来很难关闭延迟的ack，即使您关闭它，tcp堆栈也会在随后的数据交换中再次打开它。

我在过去减少了(而不是删除)延迟的ack计时器，特别是为了减少对等程序Nagle算法的影响，否则我无法直接接触它。它没有被重置，但它是一个内核范围的设置，而不是每个套接字。详细的细节将取决于您的具体网络堆栈，没有一般的答案。

纳格尔算法偏重延迟的背后原因是什么？

我不认为有一个-堆栈没有拼命地试图阻止你篡改延迟的问题，只是没有完全相同的理由来揭露它。

1. 发送数据是应用程序级代码中的一种操作，Nagle的算法在显式操作和执行之间引入了延迟。在重要的情况下，允许应用程序请求网络堆栈执行应用程序认为它已经要求的(即，在我调用send()时实际发送数据)似乎是合理的。
2. 发送ack是网络堆栈的内部事务管理，应用程序层从未以任何方式公开或可见。当网络堆栈决定是否对接收到的数据包进行攻击时--没有执行应用程序代码，而且应用程序还没有意识到已经接收到了数据包。

因此，虽然我同意添加一个sockopt来控制延迟的ack计时器可能是合理的，但它并没有干扰应用程序代码直接做的事情。它根本不应该对应用程序本身产生任何影响。