多个连接的聚合吞吐量 (Linux)
为什么来自同一主机的多个连接比来自不同主机的多个连接获得更好的吞吐量？
我怀疑是与内核相关的（Linux），但确认会有很大帮助。
更多详细信息 我有 1 个接收器进程，我们称之为 R。它接受传入连接并使用 select() 接收数据。
我有 3 个发送进程 S1、S2、S3。它们连接到 R 并以固定速率（即每秒 200Mbit）发送数据。
如果 S1、S2 和 S3 在同一台机器上，我会得到比将它们分别放在不同机器上更好的结果。 （这两种情况下，R 都在其他机器上）
600Mbit/s 的速度
示例：R 在主机 0 上，S1、S2、S3 在主机 2 上，R 以 600Mbit/s 的速度接收R 在主机 0 上，S1 在主机 1 上，S2 在主机 2 上，S3 在主机 3 上，R 以 接收480Mbit/s
这对我来说看起来违反直觉，我期望相反，因为在第二种情况下，发送者不必共享网卡和处理器（并不是期望处理器或网卡成为瓶颈......）
[上面的主机是 Linux 集群中的节点，带有专用的全双工千兆交换机。他们正在运行 2.6.24-24-generic （我猜是最新的 Ubuntu）]
Why do multiple connections from the same host achieve better throughput than multiple connections from different hosts?
I suspect is something kernel-related (Linux) but a confirmation would help a lot.
More details I have 1 receiver process, let's call it R. It accepts incoming connections and receives data using select().
I have 3 sender processes S1, S2, S3. They connect to R and send data at a fixed rate, i.e. 200Mbit per second each.
If S1, S2 and S3 are on the same machine, I get better results than having each one of them on a different machine. (R is in both cases on some other machine)
Example: R on host0, S1, S2, S3 on host2, R receives at 600Mbit/s
R on host0, S1 on host1, S2 on host2, S3 on host3, R receives at 480Mbit/s
This looks counter-intuitive for me, I expected the opposite since in the second case senders don't have to share the network card and the processor (Not that expect processor or network card to be bottlenecks...)
[The hosts above are nodes in a linux cluster with a dedicated full-duplex Gigabit switch. They are running 2.6.24-24-generic (latest Ubuntu i guess)]
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这可能是因为当发送者都在一台机器上时，传出的数据包都会很好地排队并一次发送一个（仅仅因为它们都通过一个网卡这一事实）。
而在多发送者的情况下，两台机器通常会同时发送数据包，然后由网络交换机对它们进行排队。这对于发送 TCP 来说会表现为抖动延迟 - 有时数据包会直接交换到接收方，有时则必须等待来自交换队列内其他发送方的一两个数据包。
我预计延迟抖动本身就足以减少您的带宽 - 请记住，要在标准 TCP 窗口下维持 200mbps，您需要 2.6 毫秒的最小往返时间，这非常紧张。
This is probably because when the senders are all on one machine, the outgoing packets are all nicely queued and sent one-at-a-time (just by virtue of the fact that they're all going through one NIC).
Whereas in the multiple-senders case, two machines will often send packets at the same time, and it is then up to the network switch to queue them. This will manifest itself to the sending TCP as a jittery latency - sometimes a packet will be switched straight through to the receiver, other times it will have to wait for one or two packets from the other senders inside the switch queues.
I expect that the latency jitter on its own would be enough to knock that much off your bandwidth - remember that to sustain 200mbps with standard TCP windows, you need a minimum round-trip-time of 2.6ms, which is pretty tight.