我最近偶然发现了一个有趣的TCP性能问题，同时运行了一些比较网络性能和环回性能的性能测试。就我而言，网络性能超过了环回性能（1Gig网络，同一子网）。在我处理延迟的情况下是至关重要的，因此启用了TCP_NODELAY。我们提出的最好的理论是TCP拥塞控制正在阻止数据包。我们做了一些数据包分析，我们可以肯定地看到数据包被保留，但原因并不明显。现在问题......
1）在什么情况下，以及为什么通过环回进行通信比通过网络慢？
2）当尽可能快地发送时，为什么切换TCP_NODELAY对环回的最大吞吐量的影响比对网络的影响大得多？
3）我们如何检测和分析TCP拥塞控制作为性能不佳的潜在解释？
4）有没有人对这种现象的原因有任何其他理论？如果是的话，有什么方法可以证明这个理论吗？以下是一个简单的点对点c ++应用程序生成的示例数据：
Transport Message Size (bytes) TCP NoDelay Send Buffer (bytes) Sender Host Receiver Host Throughput (bytes/sec) Message Rate (msgs/sec) TCP 128 On 16777216 HostA HostB 118085994 922546 TCP 128 Off 16777216 HostA HostB 118072006 922437 TCP 128 On 4096 HostA HostB 11097417 86698 TCP 128 Off 4096 HostA HostB 62441935 487827 TCP 128 On 16777216 HostA HostA 20606417 160987 TCP 128 Off 16777216 HostA HostA 239580949 1871726 TCP 128 On 4096 HostA HostA 18053364 141041 TCP 128 Off 4096 HostA HostA 214148304 1673033 UnixStream 128 - 16777216 HostA HostA 89215454 696995 UnixDatagram 128 - 16777216 HostA HostA 41275468 322464 NamedPipe 128 - - HostA HostA 73488749 574130
以下是一些有用的信息：
谢谢
答案 0 :(得分：8)
1）在什么情况下，以及为什么通过环回进行通信比通过网络慢？
Loopback将tx + rx的数据包设置+ tcp chksum计算放在同一台机器上，因此需要进行2倍的处理，而使用2台机器则将它们之间的tx / rx分开。这可能会对环回产生负面影响。
2）在尽可能快地发送时，为什么切换 TCP_NODELAY 对环回的最大吞吐量的影响要大于对网络的影响？
不确定你是如何得出这个结论的，但环回vs网络的实现方式却截然不同，如果你试图将它们推到极限，你就会遇到不同的问题。环回接口（如回答1所述）导致同一台机器上的tx + rx处理开销。另一方面，NIC在其循环缓冲区等中可以拥有多少个未完成的数据包，这将导致完全不同的瓶颈（并且这在芯片之间也会有很大差异，甚至来自两者之间的交换机）它们）
3）我们如何检测和分析TCP拥塞控制作为性能不佳的潜在解释？
拥塞控制仅在丢包时启动。你看到丢包了吗？否则，您可能会对tcp窗口大小与网络延迟因素进行限制。
4）有没有人对这种现象的原因有任何其他理论？如果是的话，任何证明该理论的方法都可以吗？
我不明白你在这里提到的现象。我在你的表中看到的只是你有一些带有大发送缓冲区的套接字 - 这可能是完全合法的。在快速的机器上，您的应用程序肯定能够生成比网络可以输出的数据更多的数据，所以我不确定您在这里将什么分类为问题。
最后一点：由于各种原因，小消息会在您的网络上产生更大的性能影响，例如：
答案 1 :(得分：1)
1或2）我不确定你为什么要打扰使用环回，我个人不知道它会模仿一个真实的接口有多紧密以及它将如何有效。我知道微软会为环回接口禁用NAGLE（如果你愿意的话）。看看this link，有关于此的讨论。
3）我会密切关注两种情况下的前几个数据包，看看你是否在前五个数据包中遇到严重延迟。见here
答案 2 :(得分：0)
这也是我面临的同样问题。在同一台RHEL6机器上运行的两个组件之间传输2 MB数据时，需要7秒才能完成。当数据大小很大时，时间是不可接受的。传输10 MB数据需要1分钟。
然后我尝试禁用TCP_NODELAY。它解决了这个问题
当两个组件位于两台不同的机器中时，不会发生这种情况。