4. iPerf3 高级技巧：多线程测试、反向测试、双向测试、带宽测试报告解读
各位好，我是老张。这一章咱们来点硬核的。iPerf3 的基本用法，说白了就是一条命令跑个单线程。但真实的生产环境，哪有这么简单？你想想看，一台服务器要同时服务几百个客户端，单线程测出来的带宽，根本就是「理想国」的数据。
我个人习惯，做性能测试从来不用默认参数。为什么？因为默认参数测出来的结果，往往只能骗骗外行。今天我就把压箱底的高级玩法掏出来，咱们一个一个说。
4.1 多线程测试：模拟真实并发
单线程测试，就像一个人搬砖。多线程测试，就是叫上一队人一起搬。道理很简单，但很多人用错了。
核心参数：-P（大写P）
这个参数指定并发线程数。注意，不是连接数，是线程数。
# 服务端（不变）
iperf3 -s
# 客户端：启动 4 个线程同时发数据
iperf3 -c 192.168.1.100 -P 4 -t 30我在项目中遇到过一个问题：某次给一家视频平台做压测，单线程能跑到 900Mbps，但一开 4 线程，总带宽反而掉到 600Mbps。排查了半天，发现是客户端的 CPU 瓶颈了。多线程虽然能压满带宽，但也会吃掉 CPU 资源。
避坑指南：
我曾经见过有人把 -P 设成 64，结果服务器直接挂了。线程数不是越多越好。一般建议：
- 千兆网络：2-4 线程足够
- 万兆网络：8-16 线程起步
- 超过 32 线程，先看看 CPU 能不能扛住
4.2 反向测试：测服务器的上行能力
默认情况下，iPerf3 是客户端发数据，服务端收数据。但很多时候，我们需要测服务端的上行带宽。比如，你的服务器要给用户推送视频流。
这时候就要用反向测试了。
# 客户端：使用 -R 参数
iperf3 -c 192.168.1.100 -R -t 30加了 -R 之后，数据流方向就反过来了。服务端变成发送方，客户端变成接收方。嗯，这里要注意：反向测试的结果，往往和正向不一样。为什么？因为服务器的网卡驱动、TCP 栈优化，通常对发送和接收的处理能力是不同的。
我记得有一次帮客户排查云服务器带宽问题。正向测试能跑到 1.2Gbps，反向测试只有 400Mbps。客户说「我的服务器上行慢」。其实不是慢，是云服务商对上行带宽做了限速。用 -R 一测，真相大白。
4.3 双向测试：同时测上下行
反向测试虽然能测上行，但它是串行的——先测完一个方向，再测另一个。如果你想要同时测上下行，就得用双向测试。
# 客户端：使用 --bidir 参数
iperf3 -c 192.168.1.100 --bidir -t 30这个参数一加，iPerf3 会在同一个连接里同时跑两个方向的流量。结果会分别显示上行和下行的带宽。
个人经验：
双向测试对设备压力很大。我曾经用一台低配的 ARM 开发板做双向测试，结果直接死机了。建议先跑一次单向，确认设备能扛住，再上双向。
4.4 带宽测试报告解读：别只看最后一行
很多人跑完 iPerf3，只看最后一行「SUM」的总带宽。这其实是个大坑。真正的信息，藏在中间那些细节里。
我们来看一份典型的测试报告：
-----------------------------------------------------------
Interval Transfer Bitrate Retr
-----------------------------------------------------------
0.00-1.00 sec 112 MBytes 940 Mbits/sec 0
1.00-2.00 sec 113 MBytes 948 Mbits/sec 0
2.00-3.00 sec 110 MBytes 923 Mbits/sec 1
3.00-4.00 sec 108 MBytes 906 Mbits/sec 3
4.00-5.00 sec 105 MBytes 881 Mbits/sec 5
5.00-6.00 sec 102 MBytes 856 Mbits/sec 8
6.00-7.00 sec 98 MBytes 822 Mbits/sec 12
7.00-8.00 sec 95 MBytes 797 Mbits/sec 15
8.00-9.00 sec 92 MBytes 772 Mbits/sec 18
9.00-10.00 sec 90 MBytes 755 Mbits/sec 20
-----------------------------------------------------------
[SUM] 0.00-10.00 sec 1.02 GBytes 860 Mbits/sec sender
[SUM] 0.00-10.00 sec 1.01 GBytes 855 Mbits/sec receiver
-----------------------------------------------------------
你看，SUM 行显示平均带宽是 860Mbps。但仔细看每一秒的数据，从第 3 秒开始，带宽就在持续下降，重传（Retr）在不断增加。这说明什么？说明网络有瓶颈，可能是缓冲区满了，或者中间设备丢包了。
报告解读要点：
- 看趋势：带宽是平稳的，还是持续下降的？下降说明有问题。
- 看重传：Retr 列的数字，0 是理想状态。超过 5 就要警惕了。
- 看抖动：相邻两秒的带宽波动超过 10%，说明网络不稳定。
- 看对称性：sender 和 receiver 的带宽差距大，说明有丢包或拥塞。
我个人的习惯是，每次测试至少跑 30 秒，然后取中间 20 秒的数据做分析。前 5 秒是 TCP 慢启动阶段，数据不稳定。后 5 秒可能有结束时的波动。中间段才是最真实的。
曾经踩过的坑：
有一次我测一个跨洋链路，SUM 显示 200Mbps，看起来不错。但仔细看每一秒的数据，发现带宽在 50Mbps 到 350Mbps 之间剧烈抖动。这种网络，做视频会议肯定卡成 PPT。只看 SUM 的话，根本发现不了这个问题。
4.5 本章知识体系
为了让你更直观地理解这些高级技巧之间的关系，我画了一张图：
这张图把四个高级技巧串起来了。多线程解决并发问题，反向和双向解决方向问题，报告解读解决结果分析问题。四者缺一不可。
好了，这一章的内容就到这里。记住，工具是死的，人是活的。同样的 iPerf3，在不同人手里，能测出完全不同的结果。关键就在于你会不会用这些高级技巧。
最后一个小建议：
每次测试前，先想清楚你要测什么。是测带宽上限？还是测稳定性？还是测双向性能？目标不同，参数组合也不同。别上来就一顿乱敲命令。