3、iperf3 实战：TCP 吞吐测试、UDP 吞吐测试、多线程/多流测试、反向模式测试、报告解读。
好，咱们直接进入正题。这一章我打算带你把 iperf3 这个工具彻底玩透。说实话，我见过太多人只会跑一条 iperf3 -c server 就完事了，结果出了问题根本不知道从哪下手。今天咱们就把 TCP、UDP、多流、反向模式这些场景全过一遍，顺便教你怎么看懂那些密密麻麻的报告。
核心思路：iperf3 不是测速工具，是协议栈压力验证工具。你跑出来的数字，反映的是从应用层到网卡、再到对端协议栈的整条链路质量。
3.1 环境准备与基础命令
先搭环境。我习惯在服务端和客户端都用同一版本的 iperf3，避免协议差异导致结果偏差。安装很简单：
# 服务端（监听模式）
iperf3 -s -p 5201
# 客户端（默认 TCP 测试）
iperf3 -c 192.168.1.100 -p 5201 -t 30这里 -t 30 表示测试 30 秒。我个人习惯至少跑 60 秒，因为 TCP 慢启动和拥塞控制需要时间稳定。你想想看，如果只跑 10 秒，可能还在慢启动阶段就结束了，结果根本不准。
小技巧：服务端启动时加 --one-off 参数，可以让 iperf3 在处理完一个客户端后自动退出，适合脚本化测试。
3.2 TCP 吞吐测试：别被数字骗了
TCP 吞吐测试是最常用的场景。但这里有个坑——TCP 窗口大小直接影响结果。我曾经在一条 10Gbps 链路上只跑出 2Gbps，排查了半天，发现是默认窗口太小。
正确的做法是手动调大窗口：
# 服务端
iperf3 -s -w 256K
# 客户端
iperf3 -c 192.168.1.100 -w 256K -t 60-w 参数设置 TCP 窗口大小。对于高带宽长距离链路，我建议从 256K 开始试，逐步增加到 1M 甚至 4M。为什么？因为窗口决定了未确认数据量，窗口太小，链路带宽再高也填不满。
| 链路类型 | 推荐窗口大小 | 典型场景 |
|---|---|---|
| 1Gbps 局域网 | 64K - 256K | 数据中心内部 |
| 10Gbps 局域网 | 512K - 2M | 高性能计算集群 |
| 跨地域长距离 | 4M - 16M | 跨国专线 |
注意：窗口不是越大越好。过大的窗口会导致内存占用飙升，而且如果链路有丢包，恢复时间也会变长。我建议从 256K 起步，每次翻倍，观察吞吐变化曲线。
3.3 UDP 吞吐测试：丢包才是关键
UDP 测试和 TCP 完全不同。TCP 会自动重传，UDP 不会。所以 UDP 测试的核心指标不是带宽，而是丢包率和抖动。
跑 UDP 测试时，你必须指定带宽：
# 客户端，以 100Mbps 速率发送 UDP 流
iperf3 -c 192.168.1.100 -u -b 100M -t 30这里 -u 启用 UDP 模式，-b 100M 指定目标带宽。我遇到过很多新手直接跑 -b 0（不限速），结果把网络打爆了。嗯，这里要注意——UDP 没有拥塞控制，你设多少它就发多少，链路扛不住就直接丢包。
看结果时，重点关注这几项：
- Jitter（抖动）：小于 1ms 算优秀，1-5ms 可接受，超过 10ms 说明网络不稳定。
- Lost/Total Datagrams：丢包率。对于实时音视频，丢包率超过 1% 就会明显感知。
- 实际吞吐：服务端收到的实际速率，如果远低于你设定的
-b值，说明链路有瓶颈。
实战经验：我曾在一次视频会议系统调优中，发现 UDP 丢包率高达 5%。排查后发现是交换机缓冲区太小，导致突发流量被丢弃。调大交换机 buffer 后，丢包率降到 0.1%。
3.4 多线程/多流测试：压出真实上限
单线程测试只能压满一个 CPU 核心。对于现代多核服务器，你需要用多流来模拟真实负载。
# 4 个并行流，每个流独立线程
iperf3 -c 192.168.1.100 -P 4 -t 60-P 4 表示启动 4 个并行流。我建议从 2 开始，逐步增加到 8、16，观察吞吐是否线性增长。如果增加到某个点后吞吐不再上升，说明瓶颈在 CPU 或网卡中断处理上。
这里有个经典场景：我曾经测试一台 40Gbps 网卡的服务器，单流只能跑 8Gbps，但 8 个流就能跑到 35Gbps。为什么？因为单流受限于单个 CPU 核心的中断处理能力，多流可以把负载分散到多个核心。
避坑指南：我曾经遇到过 -P 参数设太大导致测试结果反而下降的情况。原因是太多流导致 TCP 头开销和上下文切换成本超过了收益。一般来说，-P 值不要超过 CPU 核心数的 2 倍。
3.5 反向模式测试：别忽略服务端瓶颈
默认情况下，数据是从客户端发往服务端。但很多场景下，服务端才是数据发送方（比如文件服务器、视频流服务器）。这时候你需要反向模式：
# 客户端发起反向测试（数据从服务端发往客户端）
iperf3 -c 192.168.1.100 -R -t 60-R 参数让服务端变成发送方。我强烈建议你正向和反向都测一遍。为什么？因为很多网络设备（比如家用路由器）的上下行性能不对称。我曾经测过一台企业防火墙，正向能跑 900Mbps，反向只有 300Mbps，最后发现是防火墙的 NAT 表项处理在反向方向上存在性能缺陷。
| 测试方向 | 数据流向 | 典型瓶颈 |
|---|---|---|
| 正向（默认） | 客户端 → 服务端 | 客户端发送能力、上行带宽 |
| 反向（-R） | 服务端 → 客户端 | 服务端发送能力、下行带宽 |
3.6 报告解读：每一行都有意义
跑完测试后，你会看到类似这样的输出：
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.00 sec 6.87 GBytes 984 Mbits/sec 0 sender
[ 5] 0.00-60.00 sec 6.87 GBytes 984 Mbits/sec receiver我来逐行拆解：
- Interval：测试时间段。如果看到多个 Interval 行，说明 iperf3 在分段统计。
- Transfer：总传输数据量。6.87 GB 说明 60 秒内传了这么多。
- Bitrate：平均吞吐。984 Mbits/sec 接近 1Gbps 线速，很好。
- Retr：TCP 重传次数。0 表示没有重传，完美。如果这个数字很大（比如几百上千），说明链路有丢包。
重点：很多人只看 Bitrate，忽略了 Retr。我告诉你，如果 Retr 超过总包数的 0.1%，那这个 Bitrate 就是虚高的——因为重传消耗了额外带宽，实际有效吞吐要低得多。
对于 UDP 测试，报告会多出几列：
[ ID] Interval Transfer Bitrate Jitter Lost/Total
[ 5] 0.00-60.00 sec 714 MBytes 100 Mbits/sec 0.023 ms 0/500000 (0%)这里 Jitter 0.023ms 非常优秀，Lost/Total 0% 说明没有丢包。如果看到丢包率超过 0.1%，你就得检查链路了。
3.7 本章知识体系
下面这张图总结了 iperf3 实战的核心逻辑，你可以对照着回顾：
好了，这一章的内容就到这里。你把这些命令和解读方法练熟了，以后遇到网络性能问题，至少能快速定位是客户端、服务端还是中间链路的问题。记住，iperf3 是你的第一把手术刀，用好了能省下大量排查时间。