4. iperf3 进阶：多线程测试、反向模式、双向测试、带宽调优参数
好，咱们继续往下聊。上一章我们把 iperf3 的基础用法摸透了，单线程、默认方向，这些你肯定已经玩熟了。但说实话，真实的生产环境哪有这么简单？
你想想看，现在的服务器哪个不是多核的？网卡哪个不是多队列的？你要是只用单线程去压，测出来的带宽可能连实际的一半都不到。我当年第一次给一个千兆链路做验收，单线程测出来只有 300Mbps，差点把网络供应商骂了一顿。结果你猜怎么着？人家链路本身没问题，是我自己没开多线程。
这一章，咱们就把 iperf3 的进阶玩法彻底讲透。多线程、反向模式、双向测试，还有那些调优参数，一个一个来。
4.1 多线程测试：把 CPU 用满，带宽才能拉满
iperf3 默认是单线程的。单线程意味着什么？意味着它只用一个 CPU 核心去发包。现在的服务器动不动几十个核心，你只用一个，那不是浪费吗？
多线程测试的核心参数是 -P（注意是大写 P）。这个参数指定并发线程数。
# 服务端（和之前一样）
iperf3 -s
# 客户端，启动 4 个线程同时发包
iperf3 -c 192.168.1.100 -P 4跑完之后，你会看到每个线程的独立统计，最后还有一个汇总的 SUM 行。那个 SUM 才是真正的总带宽。
关键点：线程数不是越多越好。我个人习惯是，先设成 CPU 核心数的一半，然后逐步往上加。加到带宽不再增长为止。一般来说，4 到 8 个线程就够用了。你开 32 个线程，反而会因为上下文切换开销太大，导致性能下降。
小技巧：如果你不确定服务器有多少核心，可以用 nproc 或者 lscpu 看一下。我一般先设 -P 4，然后看 CPU 占用率。如果 CPU 没跑满，就继续加线程。
4.2 反向模式：测上行，别被运营商坑了
默认情况下，iperf3 是客户端向服务端发包。也就是说，测的是客户端的上行、服务端的下行。但很多时候，我们更关心客户端的下行带宽——比如你家宽带，运营商宣传的 1000M，通常指的是下行。
这时候就需要反向模式了。参数是 -R（大写 R）。
iperf3 -c 192.168.1.100 -R加了 -R 之后，数据流向就反过来了：服务端向客户端发包。测出来的就是客户端的下载速度。
我曾经帮一个朋友测他的家庭宽带。用默认模式测，上行 30Mbps，正常。但换成反向模式一测，下行只有 200Mbps。他买的可是 1000M 的套餐啊！后来发现是光猫的网口只协商到了百兆。嗯，这种坑我踩过不止一次。
注意：反向模式对服务端的 CPU 压力更大。因为服务端要负责高速发包。如果服务端性能不够，测出来的下行带宽会偏低。这时候可以结合多线程一起用：iperf3 -c 192.168.1.100 -R -P 4。
4.3 双向测试：同时测上下行，模拟真实场景
反向模式虽然能测下行，但它是一次只测一个方向。现实中呢？你在下载文件的同时，可能还在上传视频。上下行是同时进行的。
iperf3 提供了双向测试模式，参数是 --bidir。
iperf3 -c 192.168.1.100 --bidir这个模式下，客户端和服务端会同时向对方发包。结果会分别显示两个方向的带宽。
你想想看，有些链路是共享的，比如上下行共用一条物理线路。单向测的时候带宽可能很好看，但双向一开，互相抢资源，性能立马现原形。我遇到过不少交换机，单向能跑满万兆，双向一开直接掉到 6Gbps。这就是所谓的「背压」问题。
实战建议：做性能回归测试的时候，我建议你把单向、反向、双向三种模式都跑一遍。单向看极限，反向看下行，双向看链路公平性。三个数据放在一起，才能全面评估一条链路的质量。
4.4 带宽调优参数：把 iperf3 的潜力榨干
除了线程数和方向，iperf3 还有一堆调优参数。这些参数平时可能用不上，但遇到瓶颈的时候，它们就是你的救命稻草。
4.4.1 窗口大小（TCP 缓冲区）
TCP 的窗口大小决定了发送端一次能发多少数据而不等确认。窗口太小，带宽再高也跑不起来。
iperf3 -c 192.168.1.100 -w 1M-w 参数设置 TCP 窗口大小。单位可以是 K、M。对于万兆网络，我一般设成 1M 到 4M。设得太小，你会看到重传率飙升；设得太大，内存占用高，但收益有限。
我的经验：在长肥网络（高带宽、高延迟）上，窗口大小几乎是决定性因素。比如跨洋链路，延迟 200ms，窗口不调大，带宽死活上不去。公式很简单：带宽 × 延迟 = 窗口大小。1000Mbps × 0.2s = 200Mb = 25MB。所以窗口至少设 25M。
4.4.2 测试时长与间隔
默认测试时长是 10 秒。对于短链路够用了，但对于需要稳定性的场景，我建议加长。
iperf3 -c 192.168.1.100 -t 60 -i 5-t 60 表示测试 60 秒。-i 5 表示每 5 秒输出一次中间结果。这样你能看到带宽的波动情况。如果某一段突然掉下去了，说明链路不稳定。
4.4.3 UDP 模式与带宽限制
有时候 TCP 的拥塞控制会干扰测试结果。你想看看链路的原始吞吐能力？用 UDP 模式。
iperf3 -c 192.168.1.100 -u -b 1000M-u 开启 UDP 模式。-b 指定目标带宽。UDP 模式不会自动降速，它会拼命发包，直到丢包。通过丢包率，你能判断链路到底能承受多少带宽。
警告：UDP 模式很暴力。我曾经在一条共享链路上跑 UDP 测试，直接把整条链路打爆了，同事的 SSH 都断了。所以，UDP 测试请在维护窗口或者隔离环境中进行。别在生产链路上乱来。
4.4.4 零拷贝模式
对于万兆以上的网络，CPU 可能成为瓶颈。iperf3 支持零拷贝模式，减少数据在用户态和内核态之间的拷贝次数。
iperf3 -c 192.168.1.100 -Z-Z 开启零拷贝。这个功能需要系统支持（Linux 上的 sendfile 或 splice）。开启后，CPU 占用率会明显下降，带宽可能还能再涨一截。
4.5 本章核心逻辑图
下面这张图，把 iperf3 进阶测试的几种模式和数据流向画清楚了。你可以对照着理解。
4.6 实战组合拳：一条命令搞定全面测试
说了这么多，咱们来一个实战组合。假设我要对一台服务器做全面的带宽回归测试，我会这样写脚本：
#!/bin/bash
# 全面带宽回归测试脚本
SERVER="192.168.1.100"
echo "=== 1. 单向测试（4线程，60秒）==="
iperf3 -c $SERVER -P 4 -t 60 -i 10
echo "=== 2. 反向测试（4线程，60秒）==="
iperf3 -c $SERVER -R -P 4 -t 60 -i 10
echo "=== 3. 双向测试（4线程，60秒）==="
iperf3 -c $SERVER --bidir -P 4 -t 60 -i 10
echo "=== 4. UDP 极限测试（1000Mbps，10秒）==="
iperf3 -c $SERVER -u -b 1000M -t 10这个脚本跑完，你手里就有四个维度的数据了。单向看极限吞吐，反向看下行能力，双向看链路公平性，UDP 看原始承载能力。四个数据一对比，链路有没有问题，一目了然。
总结一下：iperf3 的进阶用法，说白了就是模拟真实场景。多线程模拟多任务并发，反向模式模拟下载场景，双向模式模拟全双工通信。调优参数则是帮你排除干扰，找到真正的瓶颈。做性能测试，别只跑一条命令就完事。多跑几种模式，多换几个参数，你才能对链路有真正的掌控感。
想要更多资料，联系可可