iperf3 网络测速：从带宽测量到 TCP/UDP 吞吐基准

为什么需要 iperf3

日常排查网络时，大家习惯用 ping 看连通性和延迟、用 curl/wget 看下载速度。但"下载速度"受限于目标服务器带宽、CDN 节点、磁盘读写、并发数等一堆变量，并不能代表链路本身能跑多快。当需要评估两台机器之间的真实可用带宽——比如云主机刚买回来想知道能跑多少、专线是否达标、负载均衡后端容量够不够——就需要一个专门测量吞吐的工具。

iperf3 就是为此而生的。它是 iperf2 的继任者，用 C 语言编写，性能开销极小，是目前 Linux 运维里最常用的带宽基准测试工具：一端跑服务端（server）负责接收，一端跑客户端（client）负责发送，几秒钟就能得到这条链路的吞吐数据，还能用 UDP 模式测抖动和丢包率。

iperf3 的组成与工作原理

iperf3 采用经典的 客户端-服务端 架构：

• 服务端：iperf3 -s，在某个端口（默认 5201）上监听，等待客户端连入并接收数据
• 客户端：iperf3 -c <主机地址>，主动连接服务端并发起测试，负责控制测试参数与汇总输出

工作流程大致是：客户端先通过控制连接与服务端协商测试参数，然后建立数据连接持续发送数据，默认每 1 秒上报一次瞬时速率，测试结束（默认 10 秒）输出汇总。TCP 模式下 iperf3 会主动打满带宽（不限速），所以测出的就是当前链路在当前网络条件下的最大可用吞吐；UDP 模式则需要用 -b 指定目标速率，用来观察抖动和丢包。

安装

Ubuntu/Debian 系一条命令即可：

apt update
apt install -y iperf3

其他平台也有现成安装方式：macOS 用 brew install iperf3，Windows 可从 iperf.fr 官网 下载官方二进制，官方也提供 Docker 镜像 方便容器环境使用。

安装后先确认版本（本文实测环境是 Ubuntu 24.04，iperf3 版本 3.16）：

iperf3 --version

服务端：启动与端口确认

在作为接收端的主机上启动服务端。前台运行即可，测试结束用 Ctrl+C 退出；也可以加 -D 让它以后台守护进程方式运行：

iperf3 -s
# 或后台运行
iperf3 -s -D

启动后用 ss 确认端口 5201 处于监听状态：

ss -tlnp | grep 5201

服务端常用参数

客户端：一条命令跑默认 TCP 测速

客户端连接服务端主机，默认跑 10 秒 TCP 测速：

iperf3 -c <服务端IP>

以下演示环境里服务端和客户端是同一台机器（127.0.0.1 回环），用于展示命令形态与输出格式；真实使用把地址换成对端主机 IP 即可。图中从上到下依次是：服务端以守护进程启动、ss 确认 5201 端口监听、客户端默认 TCP 测速：

看输出结构：

• Connecting to host 127.0.0.1, port 5201：确认连接目标
• 中间的逐行报告：每 1 秒一次的瞬时吞吐，Transfer 是传输数据量，Bitrate 是速率，Retr 是 TCP 重传次数，Cwnd 是拥塞窗口
• 结尾的汇总行：整个测试期间的总量，以 sender（发送端）/ receiver（接收端） 分开显示

本次回环测试 5 秒共传 14.7 GB，速率 25.3 Gbps，重传 2 次。回环接口走的是内核内部虚拟链路，数值远高于真实网络，不能当作对外带宽，只说明 iperf3 本身能打满一条连接。

客户端常用参数

反向测速：测上行带宽

默认模式是客户端 → 服务端方向，测的是链路下行（从客户端视角）。如果想测反方向——服务端 → 客户端——加 -R（reverse）参数即可：

iperf3 -c <服务端IP> -R

这个方向在"服务端外发数据给客户端"的场景（比如客户端从服务端拉取备份、流媒体下行）很重要。许多带宽不对称的线路（如家庭宽带上行远小于下行）两向测速差异明显，正规验收建议 -R 双向都测。

并行多流：贴近真实并发

单条 TCP 连接受拥塞窗口、丢包重传等因素影响，往往测不满带宽。真实业务（Nginx 多连接并发、CDN 多路回源）是"多连接同时跑"的，用 -P N 模拟 N 条并行连接更贴近实际：

iperf3 -c <服务端IP> -t 10 -P 4

并行 4 条流在本机回环上的输出：

可以看到 4 条流各自约 10 Gbps，结尾的 [SUM] 行汇总为 40.6 Gbps。并行数越多，单条连接的调度开销与争用也越大，实测时从 -P 2、-P 4 逐步往上加，找到能代表真实业务的并发度即可。

UDP 测速：抖动与丢包

TCP 有拥塞控制、会自动重传，测出来的都是"成功送达的量"。而实时音视频、游戏、监控推流这类业务走 UDP，更关心的是抖动（jitter）和丢包率——即使带宽够，抖动大、丢包多也会卡顿。iperf3 用 -u 切到 UDP 模式，并用 -b 指定目标速率：

iperf3 -c <服务端IP> -u -b 100M

本次回环上以 100 Mbps 发送 UDP 流的结果：

输出末尾的关键列：

• Jitter：抖动，单位 ms，反映包到达间隔的稳定性
• Lost/Total Datagrams：丢包数 / 总数据报数，括号内是丢包百分比

回环上 100 Mbps 无压力，抖动 0.000–0.012 ms、丢包 0%，非常干净。真实链路测 UDP 时，-b 从低往高慢慢加（如 10M → 50M → 100M → 500M），观察丢包率何时开始抬升——开始明显丢包的速率附近，就是这条链路 UDP 业务的可行上限。不过注意：UDP 没有重传，测试中极少量丢包是正常现象，丢包率持续走高才说明链路已达瓶颈。

JSON 输出：脚本化解析与告警

iperf3 支持 -J 输出结构化 JSON，方便用 jq 提取关键指标接入监控或告警脚本：

iperf3 -c <服务端IP> -t 10 -J > result.json

用 jq 提取汇总带宽（Gbps）与 CPU 占用：

cat result.json | jq '.end.sum_sent.bits_per_second / 1e9'
cat result.json | jq '.end.sum_received.bits_per_second / 1e9'
cat result.json | jq '.end.cpu_utilization_percent'

sum_sent 是发送端速率，sum_received 是接收端速率，两者一致说明数据全部送达；cpu_utilization_percent 包含本机与服务端两侧的 CPU 占用，用于判断测速结果是否受 CPU 瓶颈影响（单核打满时结果会偏低）。

常见问题与排错

• Connection refused：先确认服务端 iperf3 -s 在运行、ss -tlnp | grep 5201 能看到监听；再确认防火墙放行 TCP 5201（用自定义端口记得同步改两端 -p）
• 防火墙放行：云主机安全组 + 系统防火墙都要开。iptables/nftables 放行示例：nft add rule inet filter input tcp dport 5201 accept
• 结果低于预期：先 -P 4 并行再测一次排除单连接瓶颈；检查服务端 CPU 是否被打满（iperf3 单线程只能用一个核心）；公网链路还要考虑运营商限速与丢包
• UDP 测试要看丢包：TCP 模式测不出丢包，UDP 模式配合 -b 才能量化抖动与丢包，音视频类业务务必补一轮 UDP 测试
• 回环 vs 真实网络：127.0.0.1 回环测的是本机协议栈，数值虚高；验收带宽必须在两台真实主机之间、并 -R 双向都测

小结

iperf3 用十几行命令就能把"链路到底能跑多快"量化出来：服务端 iperf3 -s 监听，客户端 iperf3 -c <IP> 默认 TCP 打满带宽，-R 补测反方向，-P N 模拟多连接并发，-u -b 测 UDP 的抖动与丢包，-J 输出 JSON 方便脚本化。测速的关键是明确场景：验收带宽就在两台真实主机间双向测，调优并发就加 -P，排查音视频质量就补 UDP。配合 -J 接入监控后，链路劣化也能第一时间告警，而不是等用户反馈"卡了"才发现。