4. iperf3 吞吐测试实战：TCP吞吐测试、UDP吞吐测试、双向测试、多线程测试
好，咱们直接进入正题。上一章我们把 iperf3 装好了，命令行也跑通了。这一章，咱们就用它来真刀真枪地干活。
吞吐测试，说白了就是测你的网络到底能跑多快。但这里有个坑——很多人以为测出来多少就是多少，其实不是。测出来的结果，跟你用的协议、线程数、测试方向都有关系。我刚开始搞网络的时候，就吃过这个亏。
核心原则：吞吐测试不是测「网络有多快」，而是测「在当前配置下，网络能跑多快」。配置不同，结果天差地别。
4.1 TCP 吞吐测试
TCP 是最常用的测试方式。为什么？因为大部分业务都用 TCP。你想想看，Web 服务、文件传输、数据库同步，哪个不是跑在 TCP 上？
先看最基本的命令。假设服务端 IP 是 192.168.1.100：
服务端：
iperf3 -s客户端：
iperf3 -c 192.168.1.100就这么简单？对，默认就是 TCP 测试。默认端口 5201，默认测试时长 10 秒。
跑完之后，你会看到类似这样的输出：
Connecting to host 192.168.1.100, port 5201
[ 5] local 192.168.1.101 port 54321 connected to 192.168.1.100 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 1.10 GBytes 945 Mbits/sec
sender
[ 5] 0.00-10.00 sec 1.10 GBytes 945 Mbits/sec
receiver注意看最后一行——receiver 的数值才是最终结果。sender 只是发送端统计，receiver 是接收端实际收到的。这两个值如果差太多，说明网络有丢包或拥塞。
我的习惯：每次测试都盯着 receiver 那一行看。sender 可以忽略，除非你想对比发送和接收的差异。
我在项目中遇到过一种情况：sender 显示 1Gbps，receiver 只有 800Mbps。查了半天，发现是交换机端口协商成了百兆半双工。嗯，这种硬件问题，iperf3 一测就露馅。
4.2 UDP 吞吐测试
UDP 测试和 TCP 不太一样。TCP 有拥塞控制，会自动调整速度。UDP 不会——你让它发多少，它就发多少，丢了也不管。
所以 UDP 测试的核心参数是 -b（带宽限制）。
服务端：
iperf3 -s客户端：
iperf3 -c 192.168.1.100 -u -b 100M这个命令的意思是：用 UDP 发包，目标带宽 100Mbps。
输出会多一个关键指标——Jitter（抖动）和 Lost/Total Datagrams（丢包率）。
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 119 MBytes 100 Mbits/sec 0.034 ms 0/15217 (0%)丢包率 0%，抖动 0.034ms，说明网络质量很好。
但如果你把带宽设得过高：
iperf3 -c 192.168.1.100 -u -b 1000M结果可能就是：
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 287 MBytes 241 Mbits/sec 2.341 ms 56789/123456 (46%)丢包 46%！这说明你的网络根本承载不了 1Gbps 的 UDP 流量。
注意：UDP 测试时，-b 参数不要设得比链路带宽还高。否则测出来的不是吞吐，是丢包率。我曾经见过有人拿 10Gbps 的 -b 去测百兆链路，结果丢包 99%，还以为是网线坏了。
4.3 双向测试
很多时候，网络流量是双向的。比如视频会议、P2P 下载。这时候单向测试就不够用了。
iperf3 支持两种双向模式：
| 模式 | 参数 | 说明 |
|---|---|---|
| 双向同时 | -d 或 --dualtest |
客户端和服务端同时发数据 |
| 反向测试 | -R 或 --reverse |
只测服务端到客户端的方向 |
双向同时测试：
iperf3 -c 192.168.1.100 -d输出会显示两个流：
[ 5] 0.00-10.00 sec 1.10 GBytes 945 Mbits/sec sender
[ 5] 0.00-10.00 sec 1.09 GBytes 937 Mbits/sec receiver
[ 7] 0.00-10.00 sec 980 MBytes 822 Mbits/sec sender
[ 7] 0.00-10.00 sec 978 MBytes 820 Mbits/sec receiver注意看，[5] 是客户端→服务端，[7] 是服务端→客户端。双向加起来，总吞吐接近 1.8Gbps。
我遇到过一种情况：单向测试能跑满 1Gbps，双向测试两边都只有 600Mbps。后来发现是服务器的网卡不支持对称双工——说白了就是硬件瓶颈。
反向测试：
iperf3 -c 192.168.1.100 -R这个模式只测下行（服务端→客户端）。适合测下载场景。
4.4 多线程测试
单线程测试，很多时候跑不满带宽。为什么？因为 TCP 单流受限于窗口大小、CPU 单核性能、甚至网卡队列深度。
解决办法？多开几个线程。
客户端：
iperf3 -c 192.168.1.100 -P 4-P 4 表示开 4 个并行线程。
输出会变成这样：
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 282 MBytes 237 Mbits/sec
[ 7] 0.00-10.00 sec 275 MBytes 231 Mbits/sec
[ 9] 0.00-10.00 sec 290 MBytes 243 Mbits/sec
[ 11] 0.00-10.00 sec 278 MBytes 233 Mbits/sec
[SUM] 0.00-10.00 sec 1.10 GBytes 944 Mbits/sec注意最后一行 [SUM]，这是所有线程的总和。单线程可能只有 240Mbps，4 个线程加起来就能到 944Mbps。
我的建议：多线程测试时，线程数不要超过 CPU 核心数。否则线程切换开销反而会降低性能。我一般从 -P 2 开始试，逐步增加到 -P 8，看哪个值能跑满带宽。
这里有个表格，是我在项目中总结的经验值：
| 链路带宽 | 推荐线程数 | 说明 |
|---|---|---|
| 100Mbps | 1-2 | 单线程通常能跑满 |
| 1Gbps | 2-4 | 看网卡和 CPU 性能 |
| 10Gbps | 4-8 | 建议配合多队列网卡 |
| 40Gbps+ | 8-16 | 需要调优内核参数 |
4.5 综合实战：一次完整的测试流程
说了这么多，咱们来一个完整的实战案例。假设你要验收一条 1Gbps 的专线。
第一步：单向 TCP 基准测试
iperf3 -c 192.168.1.100 -t 30跑 30 秒，取稳定值。如果结果在 940Mbps 左右，说明物理层没问题。
第二步：多线程压测
iperf3 -c 192.168.1.100 -P 4 -t 30看 SUM 值能否接近 940Mbps。如果单线程只有 500Mbps，多线程能到 940Mbps，说明是 TCP 窗口问题。
第三步：双向测试
iperf3 -c 192.168.1.100 -d -t 30看两个方向是否对称。不对称的话，检查防火墙、QoS 策略。
第四步：UDP 极限测试
iperf3 -c 192.168.1.100 -u -b 1000M -t 30看丢包率和抖动。丢包超过 1% 就要排查了。
避坑指南：我曾经在验收时只做了单向 TCP 测试，结果一切正常。上线后业务方反馈双向传输卡顿。后来补了双向测试才发现，防火墙的会话表老化时间设置有问题。所以，验收测试一定要覆盖所有场景。
下面这张图，是我自己总结的 iperf3 测试决策流程，你可以照着走：
这张图的核心逻辑是：先做最简单的单向 TCP，如果不行就加线程；如果还不行就查硬件；最后用 UDP 测极限。每一步都有明确的排查方向，不会让你像无头苍蝇一样乱试。