2. iperf3 工具详解：安装、TCP/UDP 测试与调优
说到带宽测试，我第一个想到的工具就是 iperf3。这玩意儿轻量、跨平台、结果精准，几乎成了网络工程师的瑞士军刀。我个人习惯在排查网络瓶颈时，第一件事就是掏出 iperf3 跑一轮。今天咱们就把它掰开揉碎了讲清楚。
核心知识点速览
- iperf3 安装：Linux / Windows / macOS 全平台覆盖
- TCP 带宽测试：单流 vs 多流，窗口调优
- UDP 带宽测试：抖动、丢包率、带宽上限
- 双向测试：同时上下行，模拟真实场景
- 常用参数调优：线程数、缓冲区、报告间隔
2.1 安装部署：三分钟搞定
iperf3 的安装非常简单。我平时在 Linux 服务器上用得最多，一条命令就完事。
# Ubuntu / Debian
sudo apt install iperf3
# CentOS / RHEL
sudo yum install iperf3
# macOS (Homebrew)
brew install iperf3
# Windows 去官网下载 exe，或者用 scoop
scoop install iperf3小提示：Windows 用户记得把 iperf3.exe 所在目录加到 PATH 环境变量里，不然每次都要 cd 到目录才能用，挺烦的。
安装完后，验证一下版本：
iperf3 --version看到版本号就说明搞定了。嗯，就是这么简单。
2.2 TCP 带宽测试：最常用的场景
TCP 测试是 iperf3 的默认模式。说白了，就是模拟两台机器之间的 TCP 数据传输，看看能跑多快。
服务端启动：
iperf3 -s默认监听 5201 端口。我建议加上 -p 指定端口，避免跟其他服务冲突。
客户端启动：
iperf3 -c 192.168.1.100跑完你会看到类似这样的输出：
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 1.10 GBytes 945 Mbits/sec这个 945 Mbits/sec 就是带宽。我在项目中遇到过一个问题：明明交换机是千兆口，但测出来只有 300M。后来发现是网线质量不行，换了根 Cat6 的线，直接飙到 940M。你想想看，很多时候瓶颈不在设备，而在线缆。
多流测试：模拟真实并发
单流测试只能反映一条连接的情况。实际业务中，往往是几十上百条连接同时跑。这时候就要用多流测试了。
iperf3 -c 192.168.1.100 -P 4-P 4 表示开 4 个并行流。我一般会从 4 开始，逐步增加到 8、16，看看带宽能不能线性增长。如果到某个点不再增加，说明瓶颈在 CPU 或者网卡中断处理上。
注意：并行流数不是越多越好。我曾经在 40 核的服务器上试过 -P 64，结果 CPU 软中断飙到 100%，带宽反而下降了。建议从 2 开始，逐步增加。
2.3 UDP 带宽测试：看抖动和丢包
UDP 测试跟 TCP 不太一样。TCP 有重传机制，测的是「有效吞吐」。UDP 则更接近原始的网络状态，能看到抖动和丢包率。
iperf3 -c 192.168.1.100 -u -b 100M-u 表示 UDP 模式，-b 100M 表示目标带宽 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.123 ms 0/85234 (0%)丢包率 0% 说明网络很干净。如果丢包率超过 1%，那就要注意了。我记得有一次帮客户排查视频会议卡顿的问题，UDP 测试丢包率高达 5%，最后发现是交换机端口协商成了半双工。你想想看，半双工模式下，冲突域一大，丢包能不严重吗？
经验之谈：UDP 测试的 -b 参数不要设得太高。我建议从 10M 开始，逐步增加，直到出现明显丢包。那个临界点就是网络的实际 UDP 承载能力。
2.4 双向测试：同时上下行
很多场景下，网络流量是双向的。比如视频会议、文件同步。这时候单向测试就不够用了。iperf3 提供了双向测试模式。
iperf3 -c 192.168.1.100 -d-d 表示双向测试。服务端和客户端会同时发送数据。输出结果会显示两个方向的带宽：
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 1.05 GBytes 902 Mbits/sec (发送方向)
[ 7] 0.00-10.00 sec 1.02 GBytes 876 Mbits/sec (接收方向)如果上下行带宽差距很大，比如上行 900M、下行只有 300M，那就要检查一下是不是网卡驱动或者交换机端口配置有问题了。我遇到过一台服务器，上行正常，下行死活上不去，最后发现是 RX 队列中断绑在了同一个 CPU 核心上。
2.5 常用参数调优：让测试更精准
iperf3 的参数很多，但常用的就那么几个。我列个表，方便你查阅。
| 参数 | 作用 | 示例 | 我的建议 |
|---|---|---|---|
-p |
指定端口 | -p 5202 |
避免跟现有服务冲突 |
-i |
报告间隔（秒） | -i 1 |
我习惯用 1 秒，能看到实时波动 |
-t |
测试时长（秒） | -t 30 |
至少 30 秒，太短看不出问题 |
-P |
并行流数 | -P 4 |
从 2 开始，逐步增加 |
-w |
TCP 窗口大小 | -w 256K |
高延迟链路建议加大 |
-l |
缓冲区大小 | -l 128K |
默认 8K，大文件传输可以加大 |
-R |
反向测试（服务端发数据） | -R |
配合 -d 使用，看双向 |
-J |
JSON 格式输出 | -J |
方便脚本解析，我写自动化脚本必加 |
窗口调优实战
TCP 窗口大小对高延迟链路影响很大。举个例子，跨洋链路延迟 200ms，如果窗口只有 64K，那带宽上限就是：
带宽 = 窗口大小 / RTT = 64KB / 0.2s = 2.56 Mbps是不是很低？把窗口调到 1MB：
iperf3 -c 192.168.1.100 -w 1M带宽就能到 40Mbps 左右。我在做跨国业务优化时，经常靠调这个参数来提升吞吐。
注意：窗口大小不是越大越好。Linux 内核有 tcp_rmem 和 tcp_wmem 的限制，你设的窗口不能超过系统最大值。可以用 sysctl net.ipv4.tcp_rmem 查看。
JSON 输出：自动化必备
如果你需要把测试结果集成到监控系统或者 CI/CD 流水线里，JSON 格式是首选。
iperf3 -c 192.168.1.100 -J | jq '.end.sum_received.bits_per_second'这样就能直接拿到带宽数值，方便后续处理。我写自动化脚本时，一定会加 -J 参数。
避坑指南
最后分享几个我踩过的坑：
- 防火墙拦截：记得在服务端放行 5201 端口。我曾经在云服务器上忘了配安全组规则，客户端一直连不上，排查了半天才发现。
- CPU 瓶颈：iperf3 是单线程的。如果 CPU 跑满 100%，带宽上不去，可以试试
-P多流，或者换用 iperf2（支持多线程）。 - 网卡 offload：有些网卡开启了 TSO/GRO，会导致测试结果虚高。建议在测试前关闭：
ethtool -K eth0 tx off rx off。 - 版本不一致：服务端和客户端的 iperf3 版本要一致，否则可能报错。我习惯两边都用最新版。
好了，iperf3 的核心用法就这些。你只要把上面这些参数和场景吃透，日常的带宽测试基本都能搞定。