3. iPerf 吞吐测试实战：客户端与服务端模式、TCP/UDP 测试命令、结果解读
好，咱们进入实战环节。
前两章我们把理论基础和工具准备都搞定了。现在，是时候真刀真枪地跑一轮 iPerf 了。这一章我会带着你，从最简单的客户端-服务端模式开始，一步步把 TCP 和 UDP 的吞吐测试跑通，最后再教你怎么看懂那一串串数字。
我个人习惯，学一个新工具，先别管那么多参数，先让它跑起来再说。看到输出，你才有感觉。
3.1 客户端与服务端模式：谁听谁说？
iPerf 的工作模式，说白了就是“服务端等着，客户端主动”。
- 服务端（Server）：被动监听端口，等着客户端来连。它不主动发数据。
- 客户端（Client）：主动连接服务端，然后开始“灌”流量。
你想想看，这就像打电话。服务端是那个一直守在电话旁的人（监听模式），客户端是那个拿起电话拨号的人。拨通了，客户端就开始说话（发送数据），服务端就听着（接收数据）。
-s 参数。然后在测试机器上跑客户端，用 -c 参数指定服务端 IP。顺序别搞反了，不然客户端连不上，会报错。
这里有个关键点：吞吐测试的方向。默认情况下，是客户端发送，服务端接收。但你可以用 -R 参数让服务端反向发送给客户端。这在测试链路不对称的时候特别有用。
3.2 TCP 吞吐测试命令：最常用的场景
TCP 测试是咱们最常用的。因为它模拟了真实应用（比如 HTTP、FTP）的传输行为。我建议你从 TCP 开始练手。
3.2.1 基础 TCP 测试
先来个最简单的。假设服务端 IP 是 192.168.1.100。
服务端（在 192.168.1.100 上执行）：
iperf3 -s客户端（在测试机上执行）：
iperf3 -c 192.168.1.100就这么简单。默认它会测试 10 秒钟，然后给你一个汇总报告。
输出解读（关键字段）：
- Interval：数据统计的时间间隔。默认是 0.0-10.0 秒。
- Transfer：在这个时间段内传输的总数据量。比如 1.10 GBytes。
- Bitrate：带宽，也就是吞吐量。这是你最关心的指标。比如 945 Mbits/sec。
- Retr：重传次数。TCP 的重传意味着丢包或拥塞。这个数字如果很大，说明链路有问题。
- Cwnd：TCP 拥塞窗口大小。它反映了 TCP 对网络状态的判断。
我记得有一次，帮客户排查一个“网速慢”的问题。我跑了个 iPerf，看到吞吐只有 200Mbps，但链路是千兆的。再一看 Retr 那一列，好家伙，重传率高达 5%。这就是典型的链路层问题，后来发现是网线质量太差。
3.2.2 常用 TCP 测试参数
光跑默认的还不够。实际项目中，我们经常需要调整参数来模拟不同场景。
| 参数 | 作用 | 我的用法 |
|---|---|---|
-t |
测试时长（秒） | 我一般用 -t 30，跑 30 秒，数据更稳定。 |
-P |
并行流数 | 测试多连接场景用 -P 4。注意，不是越大越好。 |
-w |
TCP 窗口大小 | 高延迟链路（比如跨国），我会调大窗口，比如 -w 1M。 |
-R |
反向测试（服务端发，客户端收） | 测试上行带宽时用。 |
-i |
报告间隔（秒） | -i 1 每秒输出一次，方便看实时波动。 |
一个典型的“压力测试”命令：
iperf3 -c 192.168.1.100 -t 60 -P 4 -w 256K -i 1这个命令的意思是：客户端连服务端，跑 60 秒，开 4 个并行流，TCP 窗口设为 256KB，每秒打印一次结果。
-P 8，结果吞吐反而下降了。因为并行流太多，加剧了无线信道的竞争和重传。所以，并行流数不是越多越好，要根据实际场景调整。
3.3 UDP 吞吐测试命令：关注丢包和抖动
UDP 测试和 TCP 完全不同。TCP 有重传和拥塞控制，UDP 没有。所以 UDP 测试更能反映网络的“原始”承载能力，以及丢包和抖动情况。
3.3.1 基础 UDP 测试
UDP 测试需要指定带宽，不然 iPerf 会以尽可能快的速度发包，很容易把网络打满。
服务端（同样用 -s，但建议加 -u 明确指定 UDP 模式）：
iperf3 -s -u客户端：
iperf3 -c 192.168.1.100 -u -b 100M这个命令的意思是：客户端以 100Mbps 的速率向服务端发送 UDP 数据包，持续 10 秒。
UDP 输出解读（关键字段）：
- Total Datagrams：发送/接收的总数据包数。
- Jitter：抖动，单位 ms。它反映了数据包到达时间的波动。VoIP 和视频会议对抖动很敏感。
- Lost/Total Datagrams：丢包率。这是 UDP 测试的核心指标。比如 10/1000 (1%)，意味着丢了 1% 的包。
你想想看，如果丢包率超过 1%，对于实时音视频来说，体验就会明显变差。我遇到过最夸张的一次，丢包率到了 15%，那视频基本就是马赛克了。
3.3.2 常用 UDP 测试参数
| 参数 | 作用 | 我的用法 |
|---|---|---|
-b |
目标带宽（必选） | 模拟 100Mbps 视频流用 -b 100M。 |
-l |
数据包大小（字节） | 默认 1470 字节。模拟小包场景（如 VoIP）用 -l 200。 |
--pacing-timer |
流量整形间隔 | 让流量更平滑，避免突发。我一般配合 -b 使用。 |
一个模拟 VoIP 场景的命令：
iperf3 -c 192.168.1.100 -u -b 1M -l 200 -t 30 -i 1这个命令模拟了 1Mbps 的 VoIP 流，每个包 200 字节，跑 30 秒，每秒看一次抖动和丢包。
3.4 测试结果解读：从数字到结论
跑完测试，拿到一堆数字，然后呢？
嗯，这里要注意。数字本身没有意义，你得结合场景去解读。
- 看带宽是否达标：比如你买了 500Mbps 的宽带，TCP 测试只有 300Mbps，那肯定有问题。
- 看重传率（TCP）：重传率 = Retr / 总包数。如果超过 0.1%，就要警惕了。超过 1%，链路大概率有硬件问题或严重拥塞。
- 看丢包率（UDP）：对于实时业务，丢包率 < 0.1% 是优秀，0.1% - 1% 是可用，> 1% 就是不可接受了。
- 看抖动（UDP）：抖动 < 10ms 是优秀，10-30ms 是良好，> 50ms 就会影响体验。
- 看带宽波动：用
-i 1看每秒的带宽值。如果忽高忽低，说明网络不稳定，可能有背景流量在干扰。
下面这张图，帮你理清 iPerf 测试的核心逻辑和决策路径。
最后，我想强调一点：不要只看一次测试结果。网络是动态的。我建议你至少跑三次，取平均值。如果三次结果差异很大，那说明网络本身就不稳定，需要进一步排查。