启用 TCP_NODELAY 的 Linux 环回性能

Posted 2023-03-08

【中文标题】启用 TCP_NODELAY 的 Linux 环回性能

【英文标题】：Linux Loopback performance with TCP_NODELAY enabled

【发布时间】：2011-08-15 11:52:59

【问题描述】：

我最近在运行一些比较网络性能与环回性能的性能测试时偶然发现了一个有趣的 TCP 性能问题。在我的情况下，网络性能超过了环回性能（1Gig 网络，相同子网）。在我处理延迟的情况下，延迟至关重要，因此启用了 TCP_NODELAY。我们提出的最好的理论是 TCP 拥塞控制阻止了数据包。我们做了一些数据包分析，我们可以肯定地看到数据包被持有，但原因并不明显。现在问题...

1) 在什么情况下，为什么通过环回通信会比通过网络慢？

2) 尽可能快地发送时，为什么切换 TCP_NODELAY 对环回最大吞吐量的影响比网络上的影响大？

3) 我们如何检测和分析 TCP 拥塞控制作为性能不佳的潜在解释？

4) 有人对这种现象的原因有任何其他理论吗？如果是，有什么方法可以证明这个理论？

这是一个简单的点对点 c++ 应用程序生成的一些示例数据：

传输消息大小（字节） TCP NoDelay 发送缓冲区（字节） 发送方主机 接收方主机吞吐量（字节/秒） 消息速率（毫秒/秒） TCP 128 On 16777216 HostA HostB 118085994 922546 TCP 128 关闭 16777216 主机 A 主机 B 118072006 922437 TCP 128 On 4096 HostA HostB 11097417 86698 TCP 128 关闭 4096 HostA HostB 62441935 487827 TCP 128 On 16777216 HostA HostA 20606417 160987 TCP 128 关闭 16777216 HostA HostA 239580949 1871726 TCP 128 On 4096 HostA HostA 18053364 141041 TCP 128 关闭 4096 HostA HostA 214148304 1673033 UnixStream 128 - 16777216 HostA HostA 89215454 696995 Unix数据报 128 - 16777216 HostA HostA 41275468 322464 NamedPipe 128 - - HostA HostA 73488749 574130

这里还有一些有用的信息：

我只看到这个问题很小 消息 HostA 和 HostB 都具有相同的 硬件套件（至强 X5550@2.67GHz，总共 32 个内核/128 Gig Mem/1Gig 网卡） 操作系统为 RHEL 5.4 内核 2.6.18-164.2.1.el5)

谢谢

【问题讨论】：

如果延迟很重要，我会切换到 UNIX 域套接字（非常类似于 TCP 套接字）或管道（更快，但更复杂，双向连接需要两个管道）。与 TCP 套接字相比，它们携带的行李更少，延迟更低。

这些可能不是相关的问题，但我很好奇。您在这两种情况下看到的实际结果是什么？吞吐量和时间是多少？此外，测试是主要向一个方向发送，还是更像是一种回声式测试，在响应中发送相同数量的数据？

@Mark 我将我们的测试结果添加到主帖中。我还添加了一些其他相关的细节。测试向一个方向发送。

感谢您发布信息；这当然很有趣，但它并没有真正给我任何有用的想法。差异确实非常大（启用 TCP_NODELAY 时吞吐量的 10%）。它几乎有一种“感觉”，即每个发送请求在收到 ACK 之前都是阻塞的。但这没有多大意义。

【参考方案1】：

1 或 2) 我不知道您为什么要费心使用环回，我个人不知道它与真实界面的模仿程度和有效性。我知道 Microsoft 禁用了环回接口的 NAGLE（如果您关心的话）。看看this link，有关于这个的讨论。

3) 我会仔细查看两种情况下的前几个数据包，看看前五个数据包是否有严重延迟。见here

【讨论】：

我在“此链接”中看不到任何表明 MS 为环回接口禁用 Nagle 的内容。该线程似乎是关于当 user 这样做时会发生什么。他问“为什么在环回上禁用 Nagle 的算法会变得如此糟糕”，如果它已经关闭，情况就不会如此。你能澄清一下吗？

我们使用环回的原因是我们认为我们会获得更好的性能，但我们现在偶然发现了这种现象，我们正试图找出原因。此外，在现实世界中也有使用环回的用例（因为预计会有更好的性能并且可以降低硬件成本）。

该链接与 Microsoft 无关，它与问题有关，也许您可​​以从该线程中推断出一些东西 - 虽然我认为它没有答案 - 但可能会讨论相关想法。

@user207421：仅供参考，Microsoft 的文档 does say that Nagle is disabled automatically on the loopback interface（在链接中搜索“环回”）：“出于性能原因，Nagle 算法不适用于环回 TCP 连接。”

【参考方案2】：

1) 在什么情况下，以及为什么，通过环回通信会比通过网络慢？

Loopback 将 tx+rx 的数据包设置 + tcp chksum 计算放在同一台机器上，因此它需要进行 2 倍的处理，而使用 2 台机器，您可以在它们之间拆分 tx/rx。这可能会对环回产生负面影响。

2) 在尽可能快地发送时，为什么切换 TCP_NODELAY 环回对最大吞吐量的影响比网络上的影响大得多？

不确定您是如何得出这个结论的，但是环回与网络的实现方式非常不同，如果您尝试将它们推到极限，您会遇到不同的问题。环回接口（如对 1 的回答中所述）导致同一台机器上的 tx+rx 处理开销。另一方面，网卡在其循环缓冲区中可以有多少未完成的数据包等方面有一定的限制，这将导致完全不同的瓶颈（这在芯片之间也有很大差异，甚至从两者之间的交换机也有很大差异）他们）

3) 我们如何检测和分析 TCP 拥塞控制作为性能不佳的潜在解释？

拥塞控制仅在数据包丢失时启动。你看到丢包了吗？否则，您可能会遇到 tcp 窗口大小与网络延迟因素的限制。

4) 对于这种现象的原因，有人有任何其他理论吗？如果是，有什么方法可以证明这个理论？

我不明白你在这里提到的现象。我在你的表中看到的是你有一些带有大发送缓冲区的套接字——这可能是完全合法的。在一台速度很快的机器上，您的应用程序肯定能够生成比网络可以输出更多的数据，所以我不确定您在这里将什么归类为问题。

最后一点：由于各种原因，小消息会对您的网络造成更大的性能影响，例如：

每个数据包的开销是固定的（对于 mac+ip+tcp 标头），有效负载越小，您的开销就越多。 许多 NIC 限制都与未完成数据包的数量有关，这意味着当使用较小的数据包时，您会遇到 NIC 瓶颈，而数据要少得多。 网络本身作为每个数据包的开销，因此您可以通过网络抽取的最大数据量再次取决于数据包的大小。

【参考方案3】：

这也是我面临的同样问题。在同一台 RHEL6 机器上运行的两个组件之间传输 2 MB 数据时，需要 7 秒才能完成。当数据量很大时，时间是不可接受的。传输 10 MB 数据需要 1 分钟。

然后我尝试禁用TCP_NODELAY。解决了问题

当两个组件位于两台不同的机器上时，不会发生这种情况。