iPerf3网络性能测试完全指南：从安装到结果深度解读

很多刚接触网络调试的朋友，第一反应就是装个网络性能测试工具，然后对着命令行发呆。我接到过不少这样的活儿，一上来就问“为什么我千兆网卡测出来只有几十兆”，结果排查到最后，要么是网线不行，要么是服务端压根没跑对。今天这篇就专门讲 iPerf3，把这个工具从安装、参数到结果解读一次说透。

iPerf3 是目前用得最普遍的开源网络性能测试工具，它的核心工作就一件事：在客户端和服务端之间建立一条测试通道，持续打流量，然后把带宽、丢包、时延抖动这些关键数字给你算出来。它不是用来替代 ping 或 traceroute 的，而是解决“链路到底能跑多快、稳不稳、有没有丢包”这类问题的。适合谁看呢？运维、网络工程师、开发调试、自己搭 NAS 和软路由折腾网络的朋友，都能用得着。

1. 先搞清楚iPerf3是什么，再动手

1.1 一句话说明白它能干什么

iPerf3 的工作模式很简单，一端作为服务端监听端口，另一端作为客户端主动发起连接。连接建立之后，客户端按你指定的方向、时长、并发数往服务端灌数据，最后把统计结果打印出来。服务端和客户端的关系，就像两个人互相扔沙包，一个数扔了多少个，一个数接住了多少个，对比一下就知道中间丢了多少。

这里有个容易混淆的点：iPerf3 测出的“带宽”不是网卡的物理速率，而是当前这条链路的实际吞吐能力。物理链路是水管，iPerf3 测的是水管里实际流过的水量，中间有弯折、堵塞、阀门半开都会影响读数。所以它特别适合用来验证“换了设备以后到底有没有提升”“跨区域链路为什么业务这么卡”这类实际问题。

1.2 为什么是iPerf3，而不是老版iPerf

老牌工具 iPerf 早在 2000 年前后就存在了，iPerf3 是后来实验室重写的一个新版本。注意，这两者的协议是互不兼容的，服务端和客户端必须都跑同一系列才能通信。我见过有人在一台机器上装了 iPerf 的老版本，另一台装 iPerf3，两边折腾了半天都连不上，最后才发现版本不对。

为什么推荐 iPerf3？首先是它的输出格式清晰得多，每行间隔、速率、总量都有明确展示，还支持 JSON 格式输出，脚本里直接解析结果非常方便。其次是它默认针对现代操作系统做了不少优化，TCP 窗口、并发处理都比老版本稳。再加上日常维护活跃，各发行版软件源里基本都是 iPerf3，所以没必要再用老版本了。唯一的缺陷是 iPerf3 默认只能做单向测试，反向和双向得靠额外参数，这点后面详细说。

1.3 安装之前要避开的坑

安装本身不复杂，但有几个坑必须先排掉。最典型的一个：服务端和客户端必须同时装好，只在一端装是测不了的。很多人拿笔记本当客户端，测试机上却忘了装服务端，结果一直提示连接被拒绝。另一个坑是版本差异，比如 iPerf3.1 和 iPerf3.9 之间控制消息格式有变化，两边版本差距太大时可能直接报错或者得到异常结果。我自己的习惯是两端的 iPerf3 版本保持一致，至少大版本要一样。

安装命令各系统不一样，给你列一下常用的：

# Debian / Ubuntu apt install iperf3 # CentOS / RHEL / Rocky yum install iperf3 # 或 dnf install iperf3 # macOS brew install iperf3 # Windows # 下载编译好的 exe 放到 PATH 里即可

装完之后先别急，两条命令验证一下：

iperf3 --version

只要能看到版本号，就说明装好了。如果系统提示找不到命令，多半是源里没有或者没刷新索引。还有一点我必须强调：iPerf3 默认监听 5201 端口，测试前要确认两端防火墙都对 5201 放行，不然客户端会一直超时。这个坑非常高频，后面单独开一节细讲。

2. 我平时都在哪些场景用它

2.1 换网络设备后的点对点复测

最常见的场景就是刚换完路由器、交换机或者网线，觉得速度“应该”变快了，但说不清具体快了多少。这时候 iPerf3 就是给链路打分的最直接工具。我之前帮某公司做过一次验收，那边办公楼搬迁后内部共享文件夹打开很慢，现场网络拓扑看起来没什么异常。我先拿一台笔记本接到服务器同网段的交换机上，再用 iPerf3 做点对点测速，结果只有 200 多兆，而两端的网卡明明都是千兆。后来把两头网线拔下来一看，一根是五类线芯不齐的杂牌线，换掉之后直接跑到 940 兆。

这种场景为什么 iPerf3 比拷贝文件好用？因为它排除了磁盘、文件系统、杀毒软件这些干扰因素。拷贝大文件时吞吐再高也说不清是网络快还是缓存起了作用，iPerf3 纯粹占用 CPU 和网络通道，结果更接近链路的真实上限。

2.2 跨区域链路的吞吐量摸底

跨区域链路比局域网复杂得多，中间可能跨了运营商、多级路由，还有各种安全设备。业务方反馈“视频会议卡、传输文件慢”，但 ping 过去延迟看着还行，丢包也只是偶尔出现。这时候 iPerf3 能派上大用场。

我会这么干：先在远端服务器上启服务端，本地用 iPerf3 带-R参数反向测试，模拟从本地往远端推数据的方向。TCP 测试看两个数字，一个是带宽跑没跑满预期，另一个是重传次数。如果吞吐还行但 Retr 一直在涨，说明链路里存在间歇性丢包，TCP 因为丢包重传，速率就会被不断拉低，业务体感自然就差了。这种问题只看带宽数往往察觉不到，还得靠重传数据来抓。

2.3 多网口汇聚与并发验证

现在不少软路由和 NAS 都支持多网口链路聚合，表面看是 2G、4G 的出口带宽，但实际效果往往没宣传的那么好。验证这种场景，iPerf3 的并发参数正好派上用场。用-P 4同时开 4 条流，客户端会把流量均匀分摊到四条 TCP 连接上，测出来的总带宽就是链路汇聚后的实际水平。

这里要提醒一句：iPerf3 单条流的性能受限于 CPU 单核能力和协议栈处理效率。千兆内网还能跑满，万兆环境单流常常只能跑到 3 到 5 兆比特每秒的一半左右，必须靠并发拉满。所以如果只是拿默认参数测万兆链路发现“只有几千兆位每秒”，先别急着下结论说链路不行，把并发打开再测一轮，结果往往完全不同。

3. 实操全过程：从服务端到结果解读

3.1 服务端启动的正确姿势

服务端启动非常简单，一条命令：

iperf3 -s

默认监听在 5201 端口。前台运行的好处是能实时看到客户端的连接请求，便于确认测试确实打过来了。如果是放在生产服务器上长期跑，我习惯加-D作为守护进程后台运行：

iperf3 -s -D

日志默认写到 syslog，也可以自己指定位置，例如：

iperf3 -s -D --logfile /var/log/iperf3.log

还有一个细节：服务端如果在防火墙后面，记得把 5201 放行。用 firewalld 的话这样开放：

firewall-cmd --permanent --add-port=5201/tcp firewall-cmd --reload

如果只是临时测一下，也可以--add-port=5201/udp一并放行，因为 UDP 测试用同一个端口但协议不同。这里有个经验之谈：批量测试多台机器时，每台机器的 5201 端口都要放通，且服务端要逐一启动。有些人只在客户端测，结果第一台机器连着测试不成功，才想起来服务端根本没装好。

3.2 客户端最常用的几种测法

客户端测试命令是-c后面跟服务端 IP：

iperf3 -c 192.168.1.100

默认行为是发起 10 秒的 TCP 上行测试（从客户端视角看，是把数据发给服务端）。如果希望测久一点，比如想观察链路的稳定性，可以加-t指定时长：

iperf3 -c 192.168.1.100 -t 60

还可以用-i指定每几秒打一条中间结果：

iperf3 -c 192.168.1.100 -t 30 -i 5

这样每分钟分成多段显示，能看到速率波动情况。如果中间某段速率突降，说明那个时间段链路有拥塞或者丢包发生。

3.3 输出结果逐列拆解：别只盯着带宽

跑完一次测试，默认输出的样子大致如下：

Connecting to host 192.168.1.100, port 5201 [ 4] local 192.168.1.55 port 53212 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-10.00 sec 1.10 GBytes 940 Mbits/sec 12 714 KBytes

这几列信息各有用途：

• Interval：区间。默认整段时间，加-i后会拆成多个区间。
• Transfer：总传输量。GBytes 太大时就是数据量很大，说明链路很快。
• Bandwidth：平均速率。这是大家最关心的数字，但它只是平均值，不是峰值。
• Retr：TCP 重传次数。这个数字非常重要，比带宽更能反映链路质量。如果 Retr 是 0，链路干净；一旦持续增长，链路里多半有丢包或冲突。
• Cwnd：拥塞窗口。拥塞窗口小说明 TCP 在收敛，链路不稳或带宽被压。

我更看重的其实是两样东西：一是 Retr 重传数，二是-i分段后的速率是否平稳。峰值高、均值高但重传多，链路质量反而差，因为大量流量被浪费在重传上。反过来，如果带宽不高但 Retr 为 0，那链路干净，瓶颈可能出在网卡或设备性能上。

3.4 常用参数速查表

用 iPerf3 测试大多数场景，下面这张表足够覆盖了：

这里特别提醒一点：参数区分大小写。比如-p是端口，-P是并发数，两个字母都靠后，写错一个意义完全不同。我就见过有人把-P写成小写-p然后并发不起作用白测了半小时的。

4. 进阶玩法：UDP、反向与并发

4.1 UDP测试：时延抖动和丢包才是重点

TCP 测试看带宽和重传，但很多实时业务走的是 UDP，例如视频会议、语音通话、游戏同步。这类业务对带宽要求不算夸张，但对时延抖动和丢包率极其敏感。iPerf3 的 UDP 测试就是为此准备的。

命令格式是：

iperf3 -c 192.168.1.100 -u -b 100M -t 30

-b在 UDP 模式下的意义是发送目标速率，这个参数基本必须指定。如果不写，iPerf3 默认用 1Mbps 的发包速率，测出来的结果根本没参考价值。指定100M后，客户端会按 100Mbps 的速率持续发包，服务端统计收到了多少、抖动多大。

输出里能看到类似这样的行：

[ 5] 0.00-30.00 sec 342 MBytes 95.6 Mbits/sec 0.002 ms 0/250004 (0%)

比起带宽，我关注的是最后两项：Jitter（抖动）和 Lost/Total（丢包统计）。抖动0.002 ms说明延迟很稳定；丢包率0%说明链路没有因拥塞丢包。如果丢包率超过 1%，实时语音和视频就会出现明显卡顿。实测时我会从低到高逐步加-b，从 10M 一路加到 100M、300M，观察哪个速率点开始出现丢包，那个点就是这条链路的 UDP 承受上限。

4.2 反向与双向：测不满上行的常见解法

很多人第一次跑 iPerf3 测出来的速率很高，但业务方反映“上传特别慢”，问题就出在测试方向没搞对。默认模式下客户端向服务端发送数据，相当于测的是“本地上行”。要测“本地下行”，需要加-R参数：

iperf3 -c 192.168.1.100 -R

-R让服务端往客户端方向打流量，客户端只负责接收，这样就可以看出下载方向的链路质量。对上下行不对称的宽带接入，比如家里的百兆上行三十兆下行、专线的 100M 双向对等，这个参数能直接揭穿实际水平。

如果想同时测上下两个方向，--bidir更合适：

iperf3 -c 192.168.1.100 --bidir

这个模式会在同一时间段内跑双向流量，两边同时统计。要注意的是，双向测试比单向更接近真实业务场景，但也给链路和两端设备带来双倍负载。链路本身吞吐不够时，两边速率都会往下掉，结果看起来两边都不高，这在带宽有限的链路上是正常的。

4.3 并行流测试的适用场景和副作用

并发参数-P是最常用的调优参数之一。默认 iPerf3 只建立一条 TCP 连接，但实际业务往往不止一条流，尤其是 Web 服务、文件传输工具，都会开多个并发连接。单流测出来只有 200M，开 4 条流跑出 800M，这并不代表链路“本来就有 800M”，而是单条 TCP 流不足以占满链路带宽，多流并发能更真实地反映整体容量。

常见用法：

iperf3 -c 192.168.1.100 -P 4 -t 20

这时输出会先分四条流统计，最后给一个 SUM 汇总，SUM 行才是总带宽。

但并发不是越多越好。开太多并发可能把中间设备的会话表打满，或者把两端的 CPU 栈吃光，导致测出的数据反而下降。我的经验是从 1 条流开始，逐步加 2、4、8，观察总带宽是否还在增长。当带宽不再明显上涨甚至回落时，就说明已经到瓶颈了，再往上加没有意义。

4.4 带宽控制、窗口调优与脚本化输出

有些场景下，你想验证当前链路在不同流量限制下的表现，这就轮到服务端限速了。服务端启动时可以加-b：

iperf3 -s -b 200M

这样即使用户端不加限制，服务端也只会按 200Mbps 接收。这个功能适合模拟不同带宽等级，比如要评估办公网络在 100M、300M 下能不能撑住视频会议，就在服务端分别限制再跑。

客户端也可以用-b限制发送速率，不过只在 TCP 模式下达标，UDP 模式下它做的是发信速率控制。还有一个 TCP 窗口的参数是-w，指定发送端缓冲区大小。在长距离高带宽链路（比如跨省专线）上，默认窗口可能不够大，导致带宽上不去。设置大窗口往往能提升吞吐：

iperf3 -c 192.168.1.100 -w 4M

窗口的设置和带宽延迟积有关，一般来说链路越长、带宽越高，窗口要越大。这里我不建议盲目设很大，尤其在内存受限的旧设备上，过大窗口反而会增加延迟。先用默认值测，再用-w 1M、-w 4M逐步对比，看哪档效果最明显。

脚本化输出是另一个值得用的功能。只要在客户端加-J，所有结果都会以 JSON 对象格式输出：

iperf3 -c 192.168.1.100 -J > result.json

配合 Python 脚本可以自动解析并入库，适合批量巡检网络设备时用。我曾经拿一段十几行的脚本批量巡检了全网三十多台核心设备，把结果全部汇总到表格里，哪条链路衰减、哪台设备重传率高，一眼就扫出来了。

5. 常见问题与排查实录

5.1 连不上服务端，先按这个顺序查

这是出现频率最高的一类问题，报错往往长这样：

iperf3: error - unable to connect to server: Connection refused

我建议按下面的顺序排查：

1. 确认服务端真的在跑：服务端执行ss -lnp | grep 5201，如果没有任何输出，说明进程没起来。
2. 确认客户端能连到服务端的端口：用nc -vz IP 5201做一次端口探测。
3. 检查防火墙：云服务器上的安全组、本机防火墙都要放行 5201/tcp 和 5201/udp。
4. 检查版本兼容：两端都执行iperf3 --version对比大版本号，差距太大直接换版本。
5. 确认 IP 可达：先ping通服务端，不通的话后面全无从谈起。

需要特别注意的是：某些云平台的安全组规则默认只开放少数端口，5201 并不在其中。就算服务器防火墙全放行了，安全组拦着什么，iPerf3 一样连不上。所以第一步永远先确认安全组里加了 5201。

5.2 测出来的带宽忽高忽低

结果不稳定是很常见的现象，尤其无线场景。无线天生的信号干扰、信道占用、漫游切换都会让吞吐剧烈波动。有线场景下，如果速率忽高忽低，我优先怀疑两点：一是链路上的拥塞，二是网卡节能策略。

我常用的验证办法是加-i 1，让 iPerf3 每秒输出一行，然后用grep过滤出每分钟的速率数据，直观对比波动范围。如果是周期性下跌，再观察是不是有定时任务、备份任务在跑，把它们暂停后再测一轮。另外，把双向测试--bidir跑一遍能确认是不是某方向的问题。还有一个容易被忽略的点：Windows 笔记本的无线网卡驱动默认启用省电模式，会大幅拉低吞吐量，需要在设备管理器里把“节能模式”调到关闭。这个设置改了之后效果非常明显，我多次实测从一两百兆直接跳到八九百兆。

5.3 带宽始终上不去是哪里拖后腿

带宽上不去的排查方向一般集中在以下地方：

• 物理链路速率协商：用ethtool 网卡名看 Speed，如果显示 100Mb/s 而不是 1000Mb/s，多半是网线或协商问题。
• 网线质量：至少超五类线才能跑满千兆，劣质线或者线芯断裂会导致降级到百兆。
• 交换机端口限速：有些网管交换机的端口配置了限速策略，插上去实际速率就被限制住了。
• 两端设备性能：老旧设备的 CPU 单核能力不够，单流跑不满很正常。
• TCP 窗口不足：长距离链路记得试试-w参数。

排查时，我习惯一层层剥：先确认网卡协商速率，再用-P 2、-P 4验证是否并发提升后总带宽能拉平，最后用 UDP 模式按固定速率发包看是否丢包。这样基本能定位到是物理层、链路层还是设备性能导致的上不去。

5.4 我的标准排查动作

在实际排障中，我给自己定了一套固定动作，遇到“网速慢”的问题就按这个顺序执行：

1. ping目标地址，确认通路和基础延迟。
2. iPerf3 单流 TCP 测试 20 秒，记录带宽和 Retr。
3. iPerf3 并发 4 流 TCP 测试，确认是否多流能拉满。
4. iPerf3 UDP 测试，逐步加大-b观察丢包率拐点。
5. 记录下所有输出，对比上次巡检数据。

这套动作看起来简单，但足够覆盖大多数“慢”的问题。只要链路有异常，在某个环节就会露出马脚。比如带宽不达标但 Retr 高，基本就是丢包型问题；并发能提高但单流始终低，就是单线程性能瓶颈；UDP 小包低速率不丢、高速率狂丢，就是带宽不够用。方向对了，解决起来就快很多。

我个人在实际操作中的最大体会是：iPerf3 测出来的是链路的机械上限，不是业务感知到的日常速度。别因为测出 900M 就以为全链路没问题，还得看重传和抖动；也别因为单流只有 300M 就断定设备不行，先试试并发再下结论。

最后顺手分享一个习惯：每次测试我都会把完整参数和 JSON 输出存成文件，命名带上日期、链路两端和测试方向。比如iperf3-report-2025-shanghai-beijing-tcp.json。这样过了几个月再测，可以直接对比同一链路的带宽和重传变化，很多隐形劣化就是这样提前发现的。这个习惯成本很低，但价值极高，强烈建议你也这么做。