为何iPerf3单流与多流测试的比特率存在巨大差异？

测试情况 #

10个并发连接测试 #

执行命令：

iperf3 -p 32770 -R -t 180 -P 10 -c <remote_ip>

测试输出：

Connecting to host <remote_ip>, port 32770
Reverse mode, remote host <remote_ip> is sending
[  6] local <local_ip> port 54283 connected to <remote_ip> port 32770
[  8] local <local_ip> port 54284 connected to <remote_ip> port 32770
[ 10] local <local_ip> port 54285 connected to <remote_ip> port 32770
[ 12] local <local_ip> port 54286 connected to <remote_ip> port 32770
[ 14] local <local_ip> port 54287 connected to <remote_ip> port 32770
[ 16] local <local_ip> port 54288 connected to <remote_ip> port 32770
[ 18] local <local_ip> port 54289 connected to <remote_ip> port 32770
[ 20] local <local_ip> port 54290 connected to <remote_ip> port 32770
[ 22] local <local_ip> port 54291 connected to <remote_ip> port 32770
[ 24] local <local_ip> port 54292 connected to <remote_ip> port 32770

[ ID] Interval           Transfer     Bitrate         Retr
[  6]   0.00-180.03 sec   546 MBytes  25.5 Mbits/sec  689            sender
[  6]   0.00-180.01 sec   546 MBytes  25.4 Mbits/sec                  receiver
[  8]   0.00-180.03 sec   128 KBytes  5.82 Kbits/sec  109            sender
[  8]   0.00-180.01 sec  0.00 Bytes  0.00 bits/sec                  receiver
[ 10]   0.00-180.03 sec   128 KBytes  5.82 Kbits/sec   16            sender
[ 10]   0.00-180.01 sec  0.00 Bytes  0.00 bits/sec                  receiver
[ 12]   0.00-180.03 sec   543 MBytes  25.3 Mbits/sec  730            sender
[ 12]   0.00-180.01 sec   542 MBytes  25.3 Mbits/sec                  receiver
[ 14]   0.00-180.03 sec   368 MBytes  17.2 Mbits/sec  846            sender
[ 14]   0.00-180.01 sec   367 MBytes  17.1 Mbits/sec                  receiver
[ 16]   0.00-180.03 sec   746 MBytes  34.7 Mbits/sec  634            sender
[ 16]   0.00-180.01 sec   744 MBytes  34.7 Mbits/sec                  receiver
[ 18]   0.00-180.03 sec   469 MBytes  21.8 Mbits/sec  727            sender
[ 18]   0.00-180.01 sec   468 MBytes  21.8 Mbits/sec                  receiver
[ 20]   0.00-180.03 sec   128 KBytes  5.82 Kbits/sec  112            sender
[ 20]   0.00-180.01 sec   128 KBytes  5.83 Kbits/sec                  receiver
[ 22]   0.00-180.03 sec   507 MBytes  23.6 Mbits/sec  624            sender
[ 22]   0.00-180.01 sec   506 MBytes  23.6 Mbits/sec                  receiver
[ 24]   0.00-180.03 sec  7.50 MBytes   349 Kbits/sec  671            sender
[ 24]   0.00-180.01 sec  7.38 MBytes   344 Kbits/sec                  receiver
[SUM]   0.00-180.03 sec  3.11 GBytes   148 Mbits/sec  5158             sender
[SUM]   0.00-180.01 sec  3.11 GBytes   148 Mbits/sec                  receiver

单连接测试 #

执行命令：

iperf3 -p 32770 -R -t 180 -P 1 -c <remote_ip>

测试输出：

Connecting to host 18.132.14.20, port 32770
Reverse mode, remote host 18.132.14.20 is sending
[  6] local 192.168.1.177 port 55808 connected to 18.132.14.20 port 32770
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  6]   0.00-180.00 sec  7.00 MBytes   326 Kbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  6]   0.00-180.02 sec  7.00 MBytes   326 Kbits/sec  635            sender
[  6]   0.00-180.00 sec  7.00 MBytes   326 Kbits/sec                  receiver

背景信息 #

正常情况下通过fast.net和speedtest.net测试可达150Mbps，但近期测试结果在325Kbps到150Mbps之间波动。为进一步排查，在AWS上搭建了iPerf3服务器，在台式机和笔记本上运行iPerf3客户端测试。无论使用5GHz无线、电力线1000BaseT还是直接通过1000BaseT连接路由器，测试结果均类似。原本预期单连接测试能达到满速150Mbps，至少能达到多流测试中某一条连接的比特率水平。

差异原因分析 #

• TCP拥塞控制的局限性：单连接TCP流遇到丢包时，会触发*拥塞窗口（Cwnd）*快速收缩，且恢复速度较慢。从单连接测试的Retr（重传）数635可以看出，丢包导致单流无法维持高速。而多连接时，多个TCP流的拥塞控制独立运行，部分流即使受丢包影响降速，其他流仍能抢占可用带宽，总和接近满速。
• ISP链路的流量限制策略：部分ISP可能对单连接带宽做了限制，却允许多连接聚合达到更高速率。这种情况常见于共享带宽的接入网络，ISP通过限制单流避免个别用户占用过多资源。
• 路径丢包的分散效应：如果丢包是间歇性或针对单流的（比如链路中某个节点的队列溢出），多流可以分散丢包影响。单流遇到持续丢包时会一直处于低速恢复状态，而多流中总有部分流能避开丢包峰值，维持较高速率。
• TCP窗口初始化差异：单连接需要逐步提升拥塞窗口，若测试期间频繁丢包，窗口始终无法增长到足够大；多连接同时初始化，能更快占据链路带宽，即使个别流降速，整体带宽利用率更高。

内容的提问来源于stack exchange，提问作者user29757222