直接用iperf3 -c server_ip测得的带宽常远低于真实上限，因单线程TCP受限于CPU、内核协议栈或网卡中断；需多路并发压测，并结合服务端重传、丢包等指标综合诊断。
直接用 iperf3 -c server_ip 测出来的数字，往往远低于真实带宽上限——单线程 TCP 会卡在 CPU、内核协议栈或网卡中断上。真正压出瓶颈，得让流量“多路并发”，同时看清服务端视角的重传和丢包。
服务端必须做两件事
只跑 iperf3 -s 是不够的：
- 加
-D启为守护进程（避免终端退出中断监听） - 若服务器有多个物理网卡或支持 RSS 的网卡，用
--bind-dev eth0绑定到具体设备；否则所有连接都挤在同一个 CPU 核上，-P 再高也白搭 - 防火墙要放行对应端口（默认 5201），例如：
sudo ufw allow 5201
客户端关键参数不能省
裸跑 -P 8 容易误判。真实压测必须带这三项：
-
-t 30：至少跑满 30 秒，避开 TCP 慢启动阶段干扰 -
-i 1：每秒输出瞬时速率，能识别抖动、突发丢包或重传毛刺 -
--get-server-output：拉取服务端统计，含重传数、接收窗口、实际 RTT——客户端自己不报这些
TCP 与 UDP 测试策略不同
TCP 测的是稳定吞吐能力，UDP 测的是链路承载极限：
- TCP 命令示例：
iperf3 -c 192.168.1.100 -P 4 -t 30 -i 1 --get-server-output - UDP 需限速并观察丢包：
iperf3 -c 192.168.1.100 -u -b 900M -P 4 -t 30 -i 1（-b 设略低于理论带宽，比如千兆链路设 900M，再逐步上调直到丢包率 ≤ 3%） - UDP 结果重点看 Jitter（抖动）和 Lost/Total（丢包比），不是 Bandwidth
结果怎么看才不踩坑
别只盯着最后一行平均值：
- 看每秒输出里是否持续波动过大（说明链路不稳定或驱动异常）
- 服务端输出里的 Retr（重传数）明显上升，说明接收窗口不足或网络拥塞
- UDP 测试中 datagrams 丢包率突然跳升，往往是交换机缓冲区溢出或 QoS 限速
- 如果 -P 2 到 -P 4 带宽翻倍，但 -P 4 到 -P 8 几乎没涨，瓶颈大概率在网卡队列或 CPU 调度，不是带宽本身
