4. iperf3 吞吐测试实战：TCP/UDP 模式、双向测试、多流并发
好，咱们进入实战环节。前面讲了理论，现在该动手了。我个人习惯，拿到一台新设备或者新链路，第一件事就是跑一轮 iperf3。为什么？因为它能最快告诉你这条链路的「底牌」——到底能跑多快，瓶颈在哪。
这一章，咱们把 iperf3 的几种核心玩法过一遍。TCP 模式、UDP 模式、双向测试、多流并发。嗯，这些基本覆盖了日常 90% 的吞吐测试场景。
4.1 TCP 模式：最常用的吞吐测试
TCP 模式是 iperf3 的默认模式。说白了，就是模拟一个「可靠」的数据传输过程。TCP 有拥塞控制、有重传、有滑动窗口，所以测出来的吞吐量，其实是「应用层能感受到的实际速率」。
先看最基本的用法：
# 服务端（先启动）
iperf3 -s -p 5201
# 客户端（发起测试）
iperf3 -c 192.168.1.100 -p 5201 -t 30这里 -t 30 表示测试 30 秒。我建议至少跑 30 秒，太短了测不准。为什么？因为 TCP 慢启动需要时间，窗口增长也需要时间。你跑 5 秒，可能还在慢启动阶段，数据根本没上去。
-i 1 参数，每秒输出一次结果。这样你能看到吞吐量随时间的变化曲线，而不是只看一个平均值。我在项目中遇到过，某条链路前 10 秒跑得很好，后面突然掉速，就是因为中间有丢包触发了拥塞控制。
TCP 模式下，有几个关键参数会影响结果：
- 窗口大小（-w）：默认值通常偏小。对于高带宽长距离链路，建议手动调大，比如
-w 1M。 - 并行流数（-P）：单流可能打不满带宽，多流并发能压榨出极限。
- 测试时长（-t）：别太短，30 秒起步。
iperf3 -v 查看版本。
4.2 UDP 模式：测极限、看丢包
UDP 模式和 TCP 完全不同。UDP 没有拥塞控制，你让它发多快它就发多快。所以 UDP 模式更适合测「链路的极限容量」和「丢包率」。
基本用法：
# 服务端
iperf3 -s -p 5201
# 客户端（指定 UDP 模式，带宽目标 100Mbps）
iperf3 -c 192.168.1.100 -u -b 100M -t 30这里 -u 开启 UDP 模式，-b 100M 指定目标带宽。注意，UDP 模式下，服务端会报告「接收到的数据量」和「丢包率」。这两个指标非常关键。
我个人的经验是：先用一个较低的带宽跑，比如 10M，看看丢包率。然后逐步增加，直到出现明显丢包。那个临界点，就是链路的实际容量。
- Jitter（抖动）：UDP 包到达时间的方差。对于实时业务（语音、视频）很重要。
- Lost/Total Datagrams：丢包数/总包数。丢包率超过 1% 就要警惕了。
举个例子，我曾经帮一个客户排查视频会议卡顿的问题。用 iperf3 UDP 模式一测，发现 50M 带宽下丢包率高达 5%。后来发现是交换机端口协商成了半双工。你想想看，半双工模式下，冲突域一大，丢包能不严重吗？
4.3 双向测试：同时测上行和下行
很多场景下，网络流量是双向的。比如视频会议、文件同步。这时候单向测试就不够用了。iperf3 提供了两种双向测试方式：
4.3.1 使用 -d 参数（传统双向）
# 服务端
iperf3 -s
# 客户端（同时发起双向测试）
iperf3 -c 192.168.1.100 -d -t 30-d 参数让客户端和服务端同时互相发送数据。但注意，这个模式下，两端的流量是独立的，互不影响。测出来的结果，其实是「各自独立跑」的吞吐量。
4.3.2 使用 --bidir 参数（推荐）
# 服务端
iperf3 -s
# 客户端（使用 --bidir）
iperf3 -c 192.168.1.100 --bidir -t 30--bidir 是较新版本 iperf3 引入的参数。它比 -d 更准确，因为两端的测试流是同步的，更能模拟真实双向流量场景。
--bidir 而不是 -d。我在一次数据中心网络测试中，用 -d 测出来上下行都能跑满 10G，但用 --bidir 一测，发现上下行同时跑时，总吞吐只有 15G。这说明交换机内部存在 Head-of-Line Blocking 问题。
4.4 多流并发：压榨极限带宽
单流 TCP 很难打满一条高带宽链路。为什么？因为单流受限于 TCP 窗口大小、RTT（往返时延）和拥塞控制算法。比如一条 10Gbps、RTT 50ms 的链路，单流 TCP 可能只能跑到 2-3Gbps。
解决办法？多流并发。用多个 TCP 连接同时发数据，把带宽「堆」起来。
# 客户端（4 条并行流）
iperf3 -c 192.168.1.100 -P 4 -t 30-P 4 表示同时开启 4 条 TCP 流。服务端会分别报告每条流的结果，最后汇总一个总和。
我一般会从 -P 2 开始试，然后逐步增加：4、8、16。直到总吞吐不再明显增长为止。那个点，就是链路的「饱和并发数」。
-P 32 时 CPU 直接 100%，吞吐反而比 -P 8 还低。所以，找到那个「甜点」很重要。
4.5 综合实战：一次完整的吞吐测试流程
好了，咱们把上面这些组合起来，看看一次完整的测试流程长什么样。
假设我要测试一条从北京到上海的 1Gbps 专线：
- 第一步：基础连通性检查
先确认能通，看 RTT 是否稳定。ping 192.168.1.100 -c 10 - 第二步：单流 TCP 测试
看看单流能跑多少。如果远低于 1Gbps，别急，继续。iperf3 -c 192.168.1.100 -t 30 -i 1 - 第三步：多流 TCP 测试
逐步增加并发数，找到饱和点。iperf3 -c 192.168.1.100 -P 4 -t 30 -i 1 - 第四步：UDP 极限测试
从 100M 开始，逐步增加，观察丢包率。iperf3 -c 192.168.1.100 -u -b 900M -t 30 - 第五步：双向测试
模拟真实双向流量场景。iperf3 -c 192.168.1.100 --bidir -P 4 -t 30
这一套下来，这条链路的「底牌」基本就摸清了。哪里有问题，一目了然。
4.6 本章知识体系
下面这张图，帮你把本章的核心逻辑串起来：
这张图把四种模式的关系和关键参数都串起来了。你测试时，可以对照着这张图，一步步来，不会漏掉任何环节。
4.7 常见问题与避坑
最后，分享几个我踩过的坑：
| 问题现象 | 可能原因 | 解决方法 |
|---|---|---|
| 单流 TCP 跑不满带宽 | TCP 窗口太小 / RTT 太大 | 调大 -w 参数，或增加并发流 -P |
| UDP 测试丢包率异常高 | 链路拥塞 / 设备性能不足 | 降低 -b 目标带宽，检查中间设备 |
| 双向测试总吞吐低于单向 | 交换机 Head-of-Line Blocking | 检查交换机缓冲区配置 |
| 多流并发时 CPU 100% | 并发数过多 / 设备性能瓶颈 | 减少 -P 值，或升级硬件 |
嗯，这一章的内容就到这。四种模式，每种都有它的适用场景。TCP 模式看应用层体验，UDP 模式看链路极限，双向测试看真实流量，多流并发压榨极限。你把这些玩熟了，吞吐测试这块基本就稳了。