iperf3网络性能测试实战：从TCP/UDP测速到瓶颈定位

先别急着上手查资料，我想先聊一个很实际的问题：你家里换了千兆宽带，可实际下载速度死活跑不满，是路由器不行，还是网线拉了垮？又或者你刚买了一台云服务器，带宽标称是200M，结果业务一上线就卡成PPT。这种时候，所有人都会告诉你“先用iperf3打一下流”，但很少有人告诉你iperf3到底怎么用才算是用对了。

iperf3就是目前最主流的网络性能测试工具，基于CS架构跑TCP和UDP流量，能测出带宽上限、丢包率、抖动等关键指标。它的定位非常纯粹——用一条命令把网络链路的质量“打回原形”。这篇内容不搞教科书式的参数背诵，我会结合我在家用环境、机房现场和云服务器之间实际折腾过的经验,把iperf3的安装、TCP测速、UDP打流、结果解读、问题排查一口气讲透，适合运维、网络工程师、做P2P或者流媒体业务的开发，以及想验证自己网络到底行不行的普通用户。

1. 先搞清楚iperf3到底是个什么家伙

1.1 一个CS架构的命令行工具

iperf3是一个开源免费的带宽测量工具，本质上就是一个客户端-服务端程序。你要测两台机器之间的网络质量，就得在一台上启动服务端模式，在另一台上启动客户端模式，然后客户端主动往服务端发包，服务端统计收到的流量情况，最后把结果打印出来。

很多第一次接触iperf3的朋友会把它误当成像ping一样的“单机命令”，其实不是。ping发的是ICMP报文，走的是网络层，它只能告诉你节点通不通、延迟大概多少。但iperf3是实实在在地占满你的带宽，用真实的TCP数据流或者UDP数据流去做传输测试，测出来的就是“这台机器到那台机器之间到底能跑多快”。这个概念很重要，因为你后面看到的带宽数字，不是运营商纸上标称的数值，而是你实际网络路径上跑出来的真实吞吐量。

另外要注意，iperf3和早期iperf2、iperf3的测试方向、报告格式、参数设计都有不少差异，网络上很多老教程还在写-i 1 -t 10之类的参数，但实际上iperf3的写法更严谨。我这个人在刚开始用iperf3的时候也踩过坑——把老版iperf的参数直接套上去，结果命令直接报错。所以下面我讲的都是iperf3自身的用法，尽量不混着来。

1.2 哪些场景最需要iperf3

我梳理了一下自己实际接触到的场景，基本可以分成三类。

第一类是局域网内的网络验证。你刚换了软路由，或者给家里拉了千兆网线，想知道实际速率是不是达标，就用一台电脑跑服务端，另一台电脑跑客户端。这时测出来的数字能够直接反映你的网卡、网线、交换机、路由器这一整条链路是否合格。

第二类是云服务器之间的带宽测试。云厂商给你标称的带宽是“理论值”，但实际跨地域通信往往要经过复杂的公网链路。你到底能不能用满这个带宽值，需要在服务器两端分别装好iperf3，然后打流验证。

第三类是UDP业务的质量评估。流媒体、语音通话、游戏同步这一类服务都用UDP传输，它们对延迟和丢包更敏感。通过iperf3的UDP打流模式，你可以人为地往链路里塞入固定码率的UDP数据包，观察丢包率和抖动，这比单纯看TCP带宽要更适合评估实时业务的承载能力。

也就是说，iperf3这工具既是网络工程师的“电子秤”，也是普通用户排查网络故障的“探针”。工具虽小，但用对了真的能省下大把时间。

2. 安装与部署：Windows、Linux、macOS一次搞定

2.1 Linux与macOS安装

Linux环境下iperf3的安装是最省事的。Debian和Ubuntu系列直接执行apt install iperf3，CentOS、Rocky、RedHat、Anolis这一类用yum install iperf3。macOS用户可以走Homebrew，brew install iperf3搞定。需要提醒的是，部分Linux发行版默认仓库里的iperf3版本可能偏旧，如果你想体验新特性或者修复已知bug，可以去iperf3官网下载源码编译安装，编译前只需要依赖gcc和make，流程不复杂，这里不展开。

装好之后可以先验证一下版本，执行iperf3 --version，只要输出了版本号就说明基础环境没问题。我再多说一句，服务器上如果开了防火墙，记得放行TCP 5201端口，因为iperf3默认监听这个端口。很多人测试半天不出结果，最后才发现是防火墙把包丢了，这种低级错误我遇见太多回了。

2.2 Windows下安装与正确使用方法

Windows用户有好几种选择。最简单的方式是直接下载官方编译好的iperf3.exe可执行文件，解压之后放进一个专门的目录，然后在cmd或者PowerShell里切到那个目录执行命令。也有人在Windows上安装了WSL，在WSL里直接apt install iperf3，这种方式同样可用，并且效率更高一些。

这里有一个特别容易踩的坑：Windows版iperf3的客户端和服务端模式是区分开的，你执行iperf3.exe -s是服务端，执行iperf3.exe -c 对端IP是客户端。但同一时间你在一台机器上只能跑一种模式，不像Linux上你可以用后台方式同时起多个进程。所以测试的时候需要准备两台设备，一台当Server，一台当Client，千万不要在一台机器上先开服务端再开客户端去连接本机IP——虽然能在逻辑上跑通，但测出来的环路结果基本没有参考价值，它不经过物理网卡，数据只是在协议栈里打了个转。

另外Windows防火墙会默认拦截iperf3的监听请求，第一次用的时候建议在防火墙弹窗里勾选允许，或者手动放行5201端口。不然的话，服务端一直在监听，客户端却一直连不上，看到的就是“connect failed: Connection refused”，别问我是怎么知道的。

3. TCP测试实战：从跑通到看懂那一串数字

3.1 最基础的跑法

先画个最简单的场景：A机器是服务端，B机器是客户端，我们要测这两台机器之间的TCP最大带宽。

A机器上执行：

bash复制iperf3 -s

看到服务端开始监听后，B机器上执行：

bash复制iperf3 -c 192.168.1.100 -t 60 -i 10

这里的-c指定对端地址，-t 60表示测试时长是60秒，-i 10表示每10秒打印一次中间结果。因为默认测试时长只有10秒，我觉得对于大部分场景来说太短了——如果链路不稳定，10秒数据很容易被瞬间波动带偏。所以我一般习惯用-t 30甚至-t 60，多跑一会儿才看得出真实水平。

测试结束之后，客户端会输出一份汇总报告，里面最重要的几行信息是区间传输量、总吞吐量、发送速率、接收速率，还有一个Retr重传数。重传数很多人不重视，我反而觉得它比带宽数字更值得关注。TCP重传意味着数据包在半路上丢了或者超时了，触发了重传机制，这直接说明链路存在丢包。如果不看这个数字，你可能还会以为自己网络带宽很大很顺畅。

3.2 参数怎么选，套路怎么用

用iperf3默认参数测TCP，本质上是“单一TCP连接能跑多快”。但很多网络环境里，单连接的吞吐量并不能代表整个网络链路的真实能力，尤其是宽带网络普遍有单连接限速策略。所以我们需要人为地创建多条并行连接，把带宽压上来。

常用的参数组合是加-P指定并发连接数：

bash复制iperf3 -c 192.168.1.100 -P 4 -t 60 -i 10

-P 4表示同时用4条TCP流去打流。我在测家庭千兆网的时候，经常发现单流的速率只有200-300Mbits/sec，但加上-P 4之后能跑到900多Mbits/sec。这就是典型的“单流限速，多流可以跑满”场景。换句话说，如果你想知道网络链路的上限，一定要用并行多流去测，而如果你想知道某个具体业务跑在单连接上能获得多大带宽，那就老老实实用单流测试。

除了并发流数，还可以用-R改变测试方向。默认是客户端发送、服务端接收，加了-R之后变成服务端发送、客户端接收。简单说，默认为下行测试，-R就是上行测试，双向链路质量不对称的情况很常见，所以建议两边都测一遍，不要只测单个方向就得出结论。

3.3 结果解读：带宽、重传和窗口

我拿到一次TCP测试结果时会依次看三样东西：带宽值、重传计数、TCP窗口大小。

首先是带宽值，它直接反映当前链路的承载能力。如果带宽数值明显低于你的预期，就要继续往下看，是重传导致的速率下降，还是窗口限制导致拥塞避退。

然后是重传，Retr那一列的数字代表每个测试区间内重传的数据包总和。重传一多，实际传输效率必然下降。比如同样的链路，重传是0的时候速度能到800Mbits/sec，重传一多可能直接掉到300Mbits/sec。TCP的拥塞控制算法会对丢包非常敏感，只要测到丢包，它会自动降低发送窗口和发送速率，这就是为什么重传对性能影响巨大。

最后是TCP窗口，工具默认用的窗口大小通常比较保守，也受到操作系统限制。如果测试结果显示吞吐量上不去，同时发送缓冲区的等待时间异常，这时候可以尝试通过-w指定窗口大小，比如iperf3 -c 192.168.1.100 -w 2M，把窗口调到2MB。这个方法在跨地域高带宽链路上特别有效，原理很简单，TCP的吞吐量上限大概等于窗口大小除以RTT，你链路延迟大，窗口不够大，带宽自然填不满。这就好比水龙头出水口够大，但蓄水池太小，一断流就发不出水量。

我个人建议对TCP测试来说，-w参数的调整要在理解了原因之后再用，不能一上来盲目加大窗口。窗口调的太大可能造成内存压力，也可能导致链路拥塞进一步加剧。合理的调参思路是：先用默认参数跑一遍，确认链路基础状况，然后看看有没有单流窗口瓶颈，再决定要不要加窗口。

4. UDP打流全解析：测延迟、抖动和丢包的正确姿势

4.1 为什么必须用UDP打流

TCP带宽很高，不代表UDP业务体验就好。原因在于TCP有重传机制，数据丢了还能补回来；UDP则没有这种保障，丢了就是丢了。对视频通话、在线游戏、实时监控这类UDP业务来说，丢包率才是真正决定体验的指标。

iperf3的UDP模式正好能帮你模拟这个场景。你可以指定以多大的码率往链路里发送UDP报文，比如-b 100M就是按100Mbits/sec的速率打流。然后工具会通过服务端接收到的报文数量和序号，统计出实际丢包率、抖动以及服务端接收速率。这个过程就像一个压力测试，你把固定码率的水流灌进管道，看有多少水能够顺利流到对面，有多少在中途漏掉了。

很多刚接触iperf3的朋友会有一个误区，觉得UDP测试就是把-b往大里写，最好直接写1G甚至10G。但你如果指定的码率已经超过了网络本身能承载的带宽，那几乎100%会丢包，测出来的数据只能说明你“打爆了链路”，不能代表真实业务水平。正确做法是：把UDP发送码率设置成你实际业务的码率，或者设置成略高于业务码率的数值，观察在这样负荷下链路是否表现稳定。

4.2 常用命令与参数

UDP测试的服务端依然用iperf3 -s启动，这一点和TCP测试没有区别。客户端命令则要加上-u参数：

bash复制iperf3 -c 192.168.1.100 -u -b 20M -t 60 -i 10

这条命令的意思很明确：以20Mbps的UDP码率，对192.168.1.100持续打流60秒。每10秒打印一次中间结果，最终还能看到总体的丢包率和抖动平均值。

我常用的几个参数说明如下：

• -u：切换成UDP模式，如果不加这个参数，即使你写了-b，工具也会按TCP模式运行。
• -b 20M：指定目标带宽，单位支持K、M、G，也可以写成500k、100M之类的格式。
• -l 1400：指定UDP包负载大小，默认是1470字节左右。如果你想模拟特定业务场景，比如语音包很小、视频包很大，可以调整这个参数。
• -t 60：测试时长，UDP模式下高码率打流对链路压力很大，一般建议至少跑30秒以上，才能看到稳定统计。

还有个很好用的组合：-i 1可以把打印间隔设为1秒。在高丢包的链路上，你希望看到丢包率是一瞬间急剧上升还是缓慢恶化，这个时候每秒打印一次输出就非常有价值。现场排障时，我经常一边开着iperf3的-i 1输出，一边抓包看是哪里开始丢包，效率极高。

4.3 iperf3的UDP测试结果怎么读

UDP模式下的汇总报告和TCP模式的差别很大。它会额外显示Jitter以及Lost/Total Datagrams。下面是一个典型的输出片段（我做了简化）：

code复制[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  4]   0.00-60.00  sec   142 MBytes   20.0 Mbits/sec  0.123 ms  123/1520 (8.1%)

看的时候我习惯按这个顺序进行：先看Bitrate是否达到了你设定的-b数值。如果接收端速率远低于设定值，说明链路出现了拥塞丢包；再看Lost/Total Datagrams的百分比，这个百分比直接反映丢包情况；最后看Jitter，也就是抖动，它反映的是数据包到达间隔的变化幅度。对于VOIP业务来说，超过30ms的抖动就会明显影响听感，对在线游戏来说，抖动比延迟还更致命。

UDP模式下，如果客户端发20M，服务端只收到15M，那丢失的5M就是被网络丢弃了，你不需要再猜。虽然iperf3无法直接测出单程延迟，但你可以在打流的同时执行ping或者使用更加专业的抓包工具来测定延迟。把带宽、丢包、抖动这三个数据放一起，链路质量大概是什么水平，心里就有数了。

5. 网络瓶颈定位与多流、调优实战

5.1 用多流和反向测试刷瓶颈

只跑一次测试其实是看不全面问题的。我调试一个网络链路的时候，通常会做一组组合测试：先用单流TCP测，再用多流TCP测，然后再用UDP打流测。单流TCP反应的是最常见的文件传输场景；多流TCP反应的是整体带宽上限；UDP打流则可以定位丢包和抖动问题。

举个例子，我在一台C3型虚拟机（2核CPU）上跑iperf3，单流始终只有400M左右，网络标称却是800M。我一开始以为是带宽被限速，后来用-P 8直接跑多流，速率瞬间飙升到接近800M。原因出在虚拟机单核CPU的性能瓶颈上——iperf3默认在单线程模式下工作，大流量统计会挤爆单核CPU。你可以观察iperf3进程启动时CPU占用率是不是快到100%，如果确实是单核瓶颈，考虑用多条并行流来分摊CPU压力，或者换用更多CPU核心的机器来跑测试。

反向测试-R也同样重要。我遇到过很多次，服务器回程链路和去程链路质量相差很大，一个方向的延迟只有20ms，另一个方向的丢包率反而很高。这种链路不对称会造成业务方抱怨“下载快，上传慢”。为了完整评估，务必两个方向都测一遍。

5.2 窗口与缓冲区的调优

TCP吞吐量受限于BDP（带宽延迟积）。公式比较简单：吞吐量上限约等于TCP接收窗口大小除以网络往返延迟RTT。举例说明：如果你的目标带宽是1Gbps，RTT是50ms，BDP就是1Gbps乘以0.05秒等于50Mbit，换算成字节就是6.25MB。这就意味着你的TCP窗口至少也要6.25MB，否则即使链路本身带宽足够，业务速度也达不到1Gbps。

iperf3允许你通过-w参数直接设置窗口大小：

bash复制iperf3 -c 192.168.1.100 -w 4M -t 30

把发送和接收窗口分别调到4MB。但你要注意，窗口大小不只是iperf3说了算，操作系统内核参数也可能成为天花板。Linux下还需要检查网卡的txqueuelen、net.core.rmem_max之类的参数，这些参数可能需要同步调整才能发挥效果。换句话说，iperf3的调优更多是“发现问题”，真正解决问题往往需要到系统内核层面做全局配置。

5.3 服务端配置与安全约束

iperf3虽然是一个测试工具，但把它长时间暴露在公网是一件相当危险的事情。它本身不提供复杂的认证和加密机制，默认情况下只要知道端口，任何人都有可能往你服务器发起流量攻击，把链路带宽占满。如果你只是临时测试，测试结束后应该立刻杀掉iperf3进程。如果确实需要长期开启，建议通过防火墙把服务端监听地址限制在内网网段，并且只对受信IP放行5201端口。

多客户端同时打流也是业务中很常见的需求。iperf3的服务端默认只支持一个客户端连接，如果你有多个测试机要同时测，要么错开时间依次执行，要么使用iperf3的--server模式提供多会话支持。但它对多客户端的并发能力确实有限，这时候可以选择使用专业的流量发生器。工具选型还是要看场景，iperf3定位的就是轻量级、快速、简单，不适合当成大规模压测平台用。

6. 常见问题与排查技巧实录

6.1 Windows那一堆坑

Windows用户遇到的坑是真的多，我把常见的错误和解决办法整理成一张速查表，方便你对照排查。

我在Windows上反复折腾后还发现一个细节：用PowerShell跑iperf3时，有些旧版本PowerShell对参数解析有特殊字符问题，尤其是-w 2M这种带单位参数，偶尔会被当成无效参数。建议Windows下用cmd来跑命令，或者在PowerShell里给参数加引号，能省掉很多莫名其妙的报错。

还有一个容易被忽略的点：Windows的TCP自动调优和iperf3设定的窗口参数可能会互相影响。如果你在Windows上通过-w设置了窗口大小，但系统本身开启了“TCP全局自动调优”，实际生效的窗口可能是系统自适应出的值，这会导致你看到的测试结果和预期不一致。想完全控制窗口，可以在命令窗口里用netsh int tcp set global autotuninglevel=disabled关掉自动调优，测完之后再恢复。

6.2 结果异常排查速查表

除了Windows特有坑之外，很多问题在不同操作系统里都会出现。我把实际的排障经验整理成下面的表格，大家遇到问题可以直接按图索骥。

在所有这些排查动作里，我最推荐的做法是“控制变量”。一次只改一个参数，改完之后重新跑测试，对比输出结果。很多新手喜欢同时调整多个参数，问题改好了也不知道是哪个参数起的作用，问题没改好也不知道该回退怎么处理，这样效率非常低。

另外有一个现场排障的小技巧：在你怀疑网络设备（交换机、路由器）存在瓶颈时，可以先把iperf3服务端和客户端分别直接插到同一台交换机下测一轮，再各自接到路由器上测一轮。如果前者正常、后者不正常，问题大概率出在路由器转发策略或者出口链路上，而不是物理介质本身。这种“层层剥离”的思路，比漫无目的地换线换网卡有效得多。

我实际操作中还有一个体会：iperf3测试的绝对数字本身意义有限，更关键的是测试条件的标准化。同一根网线，用不同缓冲区、不同并发数、不同测试时长测出来的结果差别很大。所以你在跟同事、跟客户讨论“带宽是多少”之前，一定要把命令参数统一：多少条流、多长时间、TCP还是UDP、窗口多大。只有测试口径一致，数据才有可比性，也才能最大程度避免“我这边测试很快、你那边测试很慢”的扯皮。

至于后续还能怎么扩展，其实就是围绕iperf3的结果数据继续深挖。比如对同一链路做长期周期性打流，每天固定时间跑一次，记录带宽、重传和丢包的连续曲线，就能发现网络质量是否存在固定时间段劣化，这对判断运营商高峰拥塞这类问题很有帮助。把这些数据记录下来，配合思科或者华为系交换机的流量统计，基本能定位出大部分网络性能问题。