iperf网络性能测试实战：从基础命令到带宽瓶颈定位

做网络运维这么多年，我见过太多类似的争论：传输大文件慢，业务部门说是带宽不够，带宽运营方说 ping 明明很通。两边吵到最后，往往都要把 iperf（网络性能测试工具）拉出来把链路压一遍才收场。iperf 听起来简单，一个安装包、一条命令，可真正要用得明白、能拿数据说服别人，其实有不少门道。这篇文章我按实际工作顺序来写：先讲它到底解决什么问题，再讲怎么装、怎么跑、怎么读结果，然后拆几个真正卡人的进阶参数，最后放一段我自己排障的案例和一份防坑清单。默认读者是网络工程师或系统管理员，刚入行的同学也可以对着操作，里面的坑基本都填着怎么绕开。

1. 为什么 ping 通了，带宽还是可能出问题

很多刚接触网络排障的同事，习惯一上来就 ping。ping 基于 ICMP，发的是很小的探测报文，几毫秒往返一次，主要验证的是“链路通不通”“延迟高不高”。它看不到的问题多得是：TCP 数据流被限速器卡住、防火墙把大包丢了一部分、交换机端口误码率升高导致大量重传、运营商 QoS 只对某些流量生效——这类问题在小报文为主的 ping 里面几乎不会暴露。

反过来说，iperf 做的事是“真正搬数据”。它会在一台机器上启动服务端，在另一台机器上用客户端建立一条尽量占满链路的 TCP 或 UDP 会话，让数据在两端高速流动，然后告诉你每秒钟搬了多少 bit，有没有重传，如果走 UDP 的话还会告诉你丢包了多少、抖动多大。换句话说，ping 是量血压，iperf 是上跑步机做心肺测试——平时正常的血压，不代表你跑一百米后就一定不喘。

我经常在项目里把它当“裁判”用。两个部门争论带宽是不是够，先把 iperf 架好，两端各放一台干净机器，跑 30 秒，数据摆出来，谁都不用吵。它还能当压力源使用，做交换机 QoS 规则调整前后的对比、判断新买的网卡是否发挥了一千兆的全部能力、验证某条加密隧道封装后吞吐衰减到什么程度。哪怕是家用场景，想确认运营商宣称的 500M 宽带是不是实测 500M，iperf 也比网页测速更可控，至少它不会被浏览器缓存和 CDN 节点位置干扰。

从一个从业者的角度看，iperf 的价值不在于“测出多少多少 Mbps 这个数字”，而在于“这个数字在什么样的协议、并发、窗口和网络条件下得出来的”。同样一台机器，跑出来的结果可能从 300Mbps 到 940Mbps 不等，区别往往就是参数没选对。这也是为什么我不太赞成只知道抄一条命令就去生产环境测试的用法——结果不好看时，你分不清是链路烂，还是参数不合适。

要真正用好 iperf，脑子里先把两条主线理清：一条是 TCP 测试，面向吞吐量和重传率，适合日常带宽评估；另一条是 UDP 测试，面向丢包、抖动和限速验证，适合语音视频、无线这类对实时性敏感的场景。下面所有内容都围绕这两条主线展开。

2. 安装前的四个决策点：版本、平台、端口与角色

2.1 iperf2 还是 iperf3？

先回答最容易被忽略的问题：版本。iperf 存在两个大版本，iperf2 和 iperf3，它们默认端口不同，参数名也有差异，最关键的是两边不兼容。你拿着一台机器跑 iperf2，另一台跑 iperf3，服务端和客户端根本握不上手。我自己就见过因为版本不统一，排障排了半天最后发现两边工具不是同一个人的情况。

简单给一张对照表加深印象：

新项目我基本只用 iperf3。因为它对 TCP 状态信息的输出更完整，跑一次就能直接看到有没有重传，省得再抓包。只有一种例外：当你要对接的老设备或者旧脚本用的是 iperf2 时，才需要装 iperf2。两种都装也不冲突，分不同端口跑就行，只要确保两端不要出现版本不一致的情况。

2.2 各平台安装方式一览

多数 Linux 发行版自带 iperf3 的软件包。Ubuntu/Debian 系：

sudo apt update sudo apt install iperf3

CentOS/RHEL 系新版用 dnf：

sudo dnf install iperf3

macOS 上最简单的是 Homebrew：

brew install iperf3

Windows 环境稍微麻烦一点。官方不提供完整的安装包，一般是下载免安装的可执行文件，解压后直接放在一个目录里，通过 cmd 或 PowerShell 运行 iperf3.exe，用法和 Linux 端完全相同。注意 Windows 默认防火墙会挡入站，服务端跑起来之前先给 5201 端口加放行规则，否则客户端那边会一直卡在连接握手阶段。

如果公司内网环境不方便用包管理器，或者你想给某个特定设备交叉编译，源码编译也很直接。依赖主要是 gcc、make 和 OpenSSL 开发库。在 Ubuntu 上大致是：

sudo apt install build-essential libssl-dev # 下载对应版本的源码包后解压并进入目录 tar zxvf iperf-3.x.x.tar.gz cd iperf-3.x.x ./configure make -j$(nproc) sudo make install

建议优先用发行版仓库或官方发布的二进制包。源码编译能让你拿到最新版本，但要注意新版参数和旧版本的兼容性，比如 3.1 之后新增的某些选项，老版本不认识，写脚本时容易踩坑。

2.3 端口与角色如何分配

iperf 是典型的客户端/服务端模型。被测试的那一端（比如远端机房）启动服务端，本地这一端用客户端主动连过去。默认端口是 5201 的 TCP；如果你测试的是 UDP，握手报文还是 TCP，只有真正的数据流变成 UDP。所以防火墙放行时，通常要同时放行 TCP 5201 和 UDP 5201。

实际项目里我习惯给 iperf 分配一个独立的高位端口，比如 5203。因为 5201 是常用默认端口，生产环境里可能已经被杂七杂八的服务占掉了，也容易被防火墙的默认规则盯上。指定端口就一行：

iperf3 -s -p 5203

客户端对应地加：

iperf3 -c 192.168.10.5 -p 5203

服务端需要长期驻留时，别直接用裸终端挂着。SSH 一断，iperf 就跟着没了。用 tmux 或 nohup 都行，我更习惯 tmux，因为重连还能回来看输出：

tmux new -s iperf iperf3 -s -p 5203

至此，两台机器已经“有话可讲”了。但先别急着套复杂参数，用默认方式跑一轮，先把流程走通，拿到一个基准数据，接下来再谈优化。

3. 基础用法全流程：让两台机器跑起来

3.1 服务端：先把它稳稳跑起来

服务端很简单，一条命令：

iperf3 -s -p 5203

这条命令会创建一个 TCP 监听端口，接受客户端请求。我一般再加一个-D变成守护进程，或者配合 tmux。不管哪种方式，确认监听起来了，可以用：

ss -lntp | grep 5203

看到 LISTEN 状态，就可以进入客户端环节。如果你是第一次做这个测试，建议先找两台机器直连，不经过任何中间设备，跑一次。这样能先验证工具安装、端口放行和参数使用都没有问题。后面再放到真实链路里，才不会一遇到异常数字就怀疑是 iperf 本身有 bug。

3.2 客户端：从默认参数开始

客户端第一次测试，就一条命令，不要加太多花活：

iperf3 -c 192.168.10.5 -p 5203 -t 10

这里-c指定对端 IP，-p指定端口，-t指定持续秒数。默认情况下它会做 TCP 测试，10 秒结束后输出总结果，中途每秒输出一行临时数据。如果你想每秒一行看得更直观，加-i 1。如果希望输出单位固定成 Mbps 而不是自动缩放，加-f m。我常用的一个稳定版本是：

iperf3 -c 192.168.10.5 -p 5203 -t 30 -i 1 -f m

测试期间要保持两台机器没有其他大流量应用在跑。尤其别开着下载工具、视频会议或者备份任务，否则测出来的数字会明显偏低，而你根本不知道是谁在抢带宽。

3.3 输出报告怎么读

跑完后，终端最后几行是汇总信息。常见的一个良性结果长这样：

[ ID] Interval Transfer Bitrate Retr [ 5] 0.00-30.00 sec 3.28 GBytes 939 Mbits/sec 12 sender [ 5] 0.00-30.00 sec 3.28 GBytes 938 Mbits/sec receiver

看三个关键位置：

1. sender 行和 receiver 行的 Bitrate。两行数值接近，说明数据基本都到达对端，链路没有明显丢包。如果 sender 远大于 receiver，说明链路或中间设备在丢包。
2. Retr 列。表示 TCP 重传次数，数值为 0 到几十之间都算正常。如果到几百上千，说明链路不稳定、缓冲不足或存在拥塞。
3. Bitrate 绝对值。以 1Gbps 网卡为例，实测 930Mbps 左右是正常的。因为以太网帧头、TCP/IP 协议头要占用开销，理论最大值大约就是 940Mbps。低于 800Mbps 就值得往下查了。

一个小原则：第一次用默认参数跑完，如果 Bitrate 已经很高，说明链路整体健康，后面再去压更大压力；如果默认参数就不达标，先别急着换参数，优先检查物理链路、网卡协商、防火墙这类基础项。顺序错了，很容易被复杂参数带偏方向。

4. 进阶参数拆解：从单流到并发，从 TCP 到 UDP

4.1 并发流 -P：为什么单线程跑不满万兆

iperf3 默认只建一条 TCP 连接。单条连接受限于 CPU 单核处理能力、TCP 拥塞控制算法以及网络设备对单流的策略，在千兆环境通常能跑到 900Mbps 左右，在万兆环境一般只能跑到 3-6Gbps。这不是工具的问题，而是现实世界的传输层机制。

想要压出链路真实上限，用-P参数增加并发流数量。每条流都是一个独立 TCP 连接，可以分散到多核和多个网卡队列：

iperf3 -c 192.168.10.5 -p 5203 -t 30 -P 4

并发流数怎么定？我一般从物理核数的一半开始试，比如 4 核机器先跑-P 2，再试-P 4。观察每条流的 Bitrate，如果各条流差不多，说明链路资源被均匀利用；如果某条流特别低，中间设备做负载均衡时哈希粒度不够，这条路径上可能有等价链路没散开。

使用并发流时还有个细节：服务端默认每个连接会起一个线程处理，-P 8以上时，服务端 CPU 占用会明显上去。如果你看到 CPU 快满了但带宽还没上去，瓶颈就在主机处理能力，而不是链路。这时可以加-A把流绑定到指定 CPU 核心上，例如：

iperf3 -c 192.168.10.5 -p 5203 -t 30 -P 4 -A 0,2,4,6

不过这个参数要求客户端和服务端 CPU 架构一致且支持亲和性绑定，虚拟化环境里经常不生效，当作调试手段用就好，不必每次都用。

4.2 窗口大小与 BDP：跨机房延迟更关注的参数

TCP 吞吐的一个重要上限是窗口大小。窗口决定了一个包发出后，没收到确认前最多可以再发多少数据。如果窗口太小，高延迟链路上就会一直“等确认”，带宽利用率上不去。

估算窗口需求有一个公式：带宽（bps）乘以往返时延 RTT（秒），再除以 8，得到字节数。这个值叫带宽延迟积（BDP）。举例来说，1000Mbps 链路、RTT 1ms，理论上只需要 125KB 窗口，操作系统默认值轻松覆盖。但如果是一条跨省专线，RTT 30ms，同样 1000Mbps，BDP 就成了 3.75MB，默认窗口可能不够。

这时候给 iperf3 显式设置窗口：

iperf3 -c 192.168.10.5 -p 5203 -t 30 -w 4M

-w 4M表示收发两端都尝试使用 4MB 的 socket 缓冲区。注意这只是“尝试”，最终生效值受系统内核参数net.core.rmem_max和net.core.wmem_max限制，设置得比内核上限还大时会被悄悄截断。想知道实际生效值，可以在测试输出里找到 Cwnd 列，它显示当前拥塞窗口大小，能间接反映 socket 缓冲区的真实限制。

如果一个 30ms RTT 的专线用默认参数只跑出 200-400Mbps，但你发现多并发流能明显提升，那多半就是窗口不够。这种情况调大-w往往立竿见影。先算 BDP，再设置窗口，别凭感觉给一个巨大的数值，内核不认时反而会让人困惑。

4.3 UDP 测试：丢包率和抖动才是重点

TCP 自带重传机制，链路不稳时它会把吞吐降下来，但从结果上不太容易看出网络到底丢了多少包。UDP 不一样，发送端按设定的速率往外扔，接收端没接到的就是丢了，测试结果直接反映链路质量。

启动 UDP 测试时，服务端不需要加-u，客户端指定即可：

iperf3 -c 192.168.10.5 -p 5203 -u -b 800M -t 30

-b 800M表示发送端以 800Mbps 的目标速率向网络发送 UDP 报文。如果链路实际能承载 1000Mbps，接收端能看到接近 800Mbps 的接收速率，丢包率很低。如果链路只能承载 600Mbps，接收速率会到 600Mbps 左右，而丢包率会飙升。

UDP 测试报告里我最关心三个数字：接收速率、丢包率（Lost/Total Datagrams）、抖动（Jitter）。抖动是语音视频场景的关键指标，一般要求越低越好，超过几十毫秒就很容易感知到卡顿。不过要注意，iperf3 的抖动计算依赖两端时间同步，测试前尽量先让两边服务器用 NTP 对一下时间，否则数字失真。

还要提醒一句：UDP 测试的-b值要谨慎。对着一条 1Gbps 专线如果设成-b 2G，发送端会疯狂往网络塞流量，结果通常是大量丢包、设备 CPU 高负载，甚至影响同链路其他业务。我一般从链路标称带宽的 80% 开始试，再按业务需求逐步提高。

4.4 反向与双向：别忽略上行

默认测试方向是客户端发送、服务端接收，也就是测的“下行”。但很多链路上下行质量并不对称，尤其是经过无线、卫星或运营商限速链路时。最直接的办法是用-R把方向反过来，让服务端发、客户端收：

iperf3 -c 192.168.10.5 -p 5203 -t 30 -R

如果想要同时压上行和下行，用--bidir：

iperf3 -c 192.168.10.5 -p 5203 -t 30 --bidir

双向测试比两次反向测试更接近真实业务场景，因为此时链路同时在两个方向上跑满，能看到队列、缓存、双工协商在双向压力下的表现。不过它也是所有测试中最容易影响生产流量的，强烈建议放在维护窗口执行。

测双向时，如果看到上行和下行速率悬殊，先别急着下结论。某些防火墙、QoS 设备会对双向流量做额外的策略，有些链路聚合组在双向流量下哈希不均也会出现吞吐波动。正确的做法是同一条链路，在同样的时段，分别用单向、反向、双向各跑一轮，对比数字的变化趋势，才能定位问题在主机还是中间设备。

5. 一次真实链路定位过程：从 305Mbps 到 940Mbps

前面讲了不少参数，可能觉得抽象。这里把我最近一次排障过程完整写出来，信息都做了脱敏处理，但思路可以复用。

背景：某公司两处机房之间有一条 1000Mbps 专线，业务反馈从总部往分公司同步数据很慢。我在两端各放了一台服务器，系统都是干净的 Linux，iperf3 版本一致，位于同一网段的直连路由，没有经过防火墙。

第一步，先确认基本连通性和延迟：

ping -c 10 192.168.10.5

结果延迟保持在 0.8ms 左右，丢包 0%。看表面，链路完全正常。

第二步，用默认参数做基准测试：

iperf3 -c 192.168.10.5 -t 30 -f m

结果只有 305Mbps。对一个千兆链路来说，这个数字低得明显不正常。但我没有立刻怀疑专线本身，因为专线标称千兆，且延迟正常。我先把服务端和客户端的网卡协商信息拉出来看，两端都显示 1000Mbps，全双工，链路层没有掉速。

第三步，加并发流：

iperf3 -c 192.168.10.5 -t 30 -P 4 -f m

结果立刻跳到 810Mbps 左右。这说明链路容量本身没问题，瓶颈在单条 TCP 流上。那单流为什么只能用三分之一带宽？

第四步，看 TCP 细节。回到单流测试，把 Retr 和 Cwnd 输出打印出来：

iperf3 -c 192.168.10.5 -t 30 -f m -i 1

Retr 计数不高，Cwnd 也一直在正常范围，说明不是丢包导致的拥塞窗口收敛。那问题大概率出在主机侧的中断处理上。我登录服务端，检查了网卡中断分布，发现所有中断都集中在一个 CPU 核心上，多队列没有把流量分散到其他核。

第五步，调整网卡多队列和相关驱动参数。这里不展开具体设备信息，原理是把队列数从默认的 1 扩到 4，重新分配中断亲和性，让四个队列分别落到四个核上。改完后重新跑单流测试，速率从 305Mbps 升到了 710Mbps；再跑-P 4，直接到 940Mbps，和链路理论上限基本吻合。

这个案例最大的收获是：iperf 能帮你把“链路问题”和“主机问题”分开。如果多流测试能跑满而单流跑不满，链路基本是健康的，问题在主机协议栈或网卡调优；如果多流还是跑不满，才更可能是链路或中间设备受限。这个判断顺序，比记住任何一条具体命令都重要。

6. 实用防坑清单：带宽单位、防火墙、网卡协商与测试纪律

6.1 先分清 bit 和 Byte

iperf3 默认输出的 Bitrate 单位是 Mbits/sec，也就是“兆比特每秒”。很多初学的人把这个数值直接当成 MB/s 使用，于是 940Mbits/sec 被说成 940MB/s，再和实际文件传输速度一对比就觉得有问题。实际上 940Mbits/sec 换算成字节大约是 117.5MB/s，这个速度已经非常接近千兆网卡的理论极限。想要输出直接显示字节单位，用-f B参数。

理解这一点还有个实际意义：如果你买的带宽是 1000Mbps 专线，那它的理论极限大约是 119MB/s。做需求评估时，不要拿 1000 这个数字去乘以任何时间算传输时长，要先除以 8，否则项目工期预判会差出将近一个数量级。

6.2 防火墙与端口冲突

服务端启动后客户端连不上，最常见的三个原因：防火墙挡住了端口、服务端没跑起来、端口被其他进程占用。Linux 下查看端口占用：

ss -lntp | grep 5203

确认服务端监听没问题后，再查客户端到服务端端口连通性：

telnet 192.168.10.5 5203

如果 telnet 能通但 iperf3 连不上，再用一层：

nc -vz 192.168.10.5 5203

Windows 防火墙的放行规则比较隐蔽，有时服务端明明在跑，客户端却一直连接超时。在服务端机器上手动加一条针对 TCP 5201 的入站允许规则，UDP 5201 也顺手放行，测试就不会卡在第一步。

6.3 网卡协商、线缆和中间设备

设备明明宣称千兆，实测只有 90Mbps 左右，第一步检查协商结果。用 ethtool 看网卡当前速率：

ethtool eth0

如果显示 Speed: 100Mb/s 而不是 1000Mb/s，说明自协商出了问题。换线、换端口、检查水晶头压线顺序，都能解决一部分问题。还有一种情况：中间串了一个百兆交换机或老旧的光电转换器，也会让整条链路降级到百兆，这时候 iperf 的数值反而帮你“探测”出了物理链路里的隐性短板。

想测全链路最大吞吐时，如果网络启用了 VLAN，记得把 VLAN tag 开销算进去。1500 字节 MTU 下，VLAN tag 要占 4 字节，实际有效载荷略有下降。启用巨帧（Jumbo Frame）到 9000 字节后，帧头比例下降，吞吐上限会略高一些，但前提是整条链路所有设备都支持并且配置一致，中途某一段 MTU 小了，就会在测试流量压满时放大分片问题。

6.4 测试纪律：时长、时段、日志与无线环境

我见过太多人为了赶时间只跑 3 秒 5 秒，然后拿着不代表任何意义的数字去开会。iperf3 客户端在启动后的前几秒要做好 TCP 握手、拥塞窗口爬升，测试时间太短，测出来的往往是爬坡过程的中间值，不是稳定值。我一般至少用 30 秒，测持续表现时用 60-120 秒，让链路充分进入稳态。

测试时段也很重要。生产带宽基本都被业务占用时，iperf 结果很难看，这时候你吵不过业务。选择维护窗口，尽量在没有其他大流量竞争的时间段跑，数据才有横向对比价值。同时每次测试都加上：

iperf3 -c 192.168.10.5 -t 30 --logfile /tmp/iperf_$(date +%F).log

日志文件里会带上版本信息、时间戳和完整输出，方便后续回溯。

无线环境则是另一套玩法。Wi-Fi 受干扰、信号强度、AP 负载影响极大，单次测试结果毫无意义。把测试时间分成多段，至少跑 5 次，记录每次的速率取中位数，再对比有线接入的结果——差多少，就是无线本身丢掉的性能。如果在无线路由器旁边测都很低，先检查是否连接到 5GHz 频段、信道是否拥挤、周围是否有同频干扰源，再用 iperf 验证，思路比单纯反复跑命令有效得多。

我自己这些年用下来，最大的体会是 iperf 它不复杂，难的是把它放进一套可重复、可对比的测试流程里。我每接一个网络项目，都会在项目起始阶段把两端机器的系统版本、iperf 版本、测试参数、拓扑图存成一个固定模板，后面每次排障都按同一套命令跑。这样出来的数字才能互相比较，不然今天加了这个参数、明天换了那个版本，最后得到的结论连自己都没办法复现。

最后再分享一个小习惯：测试完别急着关服务端。把两边的 iperf 进程都留一段时间，等到重试或对照实验做完再回收。很多奇怪的网络问题，往往是你关掉工具之后才暴露出来的——比如某台机器 CPU 软中断飙升，或者设备在流量停止后需要几秒钟才能恢复队列。iperf 只是一个刻度尺，尺子本身不值钱，值钱的是你会不会用它把问题量出来。