写过网络排障的人都知道一个尴尬：宽带标称500M，Speedtest测出来也有480M，可内网从NAS拖一个大文件，速度死活只有40MB/s。问题到底出在路由器、交换机、网线还是硬盘？这时候你要的不是测“到互联网的速度”，而是测“这条链路本身能跑多少”。而做这件事最顺手的工具，就是iperf3。

iperf3是一个开源、跨平台的主动式网络性能测试工具，跑在C/S架构上，一端当服务端、一端当客户端，客户端主动往服务端灌流量，通过统计单位时间内“灌进去多少、收到多少、丢了多少”，算出这条链路的真实吞吐、抖动和丢包率。用好它，不光是跑一条iperf3 -s和iperf3 -c这么简单。这篇攻略我会把安装部署、常用参数、UDP打流、多线程与反向测试、常见坑和排障思路一次讲透，尤其针对Windows和Linux两种最常见的使用环境，适合运维、网工、做无线覆盖的、搞NAS的，还有云服务器玩家收藏。

1. 为什么要用iperf3：主动打流和被动测速的差别

1.1 Speedtest测的只是“到运营商机房的体验”

很多人把测速等同于点开测速网页看数字。Speedtest这类工具测的是你当前所在网络到测速服务器之间的“尽力而为体验”，结果受测速节点距离、运营商互联、上行拥塞影响很大，同一时间换个节点数字能差出两倍。它衡量的是“你到公网的实际感受”，不是“你家交换机到NAS之间那根网线能跑多快”。

iperf3则完全不同。它工作在C/S模式下，你指定两台设备，一台当服务端、一台当客户端，所有流量直接在两者之间跑，不经过任何第三方节点。流量形态也由你控制：TCP还是UDP、几条并发流、持续多久、窗口多大。它回答的问题非常单纯——“这两台设备之间的网络管道，到底能塞下多少数据”。

1.2 用iperf3能解决哪些实际场景

按我这些年遇到的，iperf3最常见的用途有五个：

• 内网链路验收：两栋楼之间拉了根光纤，熔纤师傅说通了，到底能跑多少？用iperf3打满流量看实际吞吐。
• Wi-Fi覆盖效果验证：AP装完了，信号显示满格，但终端跑到角落iperf3一测，吞吐掉到几十Mbps，这才是真实覆盖质量。
• NAS与局域网瓶颈定位：从NAS复制文件慢，iperf3分别在NAS、PC、交换机和核心之间分段测，先排除网络再排查磁盘。
• 云服务器带宽核实：云厂商标称5Mbps的带宽，用iperf3从本机打流到服务器，看实际能跑多少，也能验证是否被限速。
• 网络设备性能压力测试：路由器、防火墙做完策略后，用多线程打流验证NAT转发能力、会话处理能力是否达标。

1.3 为什么选择iperf3而不是其他工具

iperf这个工具从2005年前后就存在了，iperf3是esnet公司在2014年后重写的版本，不是简单升级，而是解决了旧版很多问题。它单线程能更有效地压满高速链路，增加了JSON格式输出，还能用UDP测试抖动和丢包。相比同行里的netperf、nc、dd测试，iperf3在跨平台、安装便捷度、对UDP和TCP都支持、结果可量化这几个维度上综合得分最高。尤其是“UDP打流”测试，几乎只有iperf3能把抖动、丢包、带宽三组数据同时拿到，这是其他工具很难替代的。

2. 准备环境：Windows、Linux、macOS下的安装部署

2.1 Windows下安装iperf3的两种方式

Windows用户最头疼的就是这种命令行工具。其实iperf3在Windows下根本不需要“安装”，它是绿色软件。去官网或者GitHub的Release页面下载对应zip包（通常是iperf3-x.xx-win64.zip），解压到任意目录，里面就一个iperf3.exe。用的时候打开cmd或者PowerShell，cd到解压目录，或者干脆把iperf3.exe所在目录加入系统PATH，之后在任意路径直接敲iperf3就能用。

如果你嫌英文页面难找，也可以搜“magic iperf3”这类图形化封装版本。它有图形界面，点两下就能跑，适合临时救急。但我还是建议主力用法还是命令行版，因为脚本化和参数控制的自由度高得多，图形封装反而限制了调试能力。

首次使用建议先验证一下：

bash复制iperf3 -v

能输出版本信息就说明工具可用。另外注意Windows上防火墙默认会拦截入站连接，跑服务端那台机器需要手动放行TCP 5201端口，否则客户端连不上，这个在第5部分排障里详细讲。

2.2 Linux环境下安装与源码编译

Linux下的安装最省事：

bash复制# Debian / Ubuntu
apt install iperf3 -y

# CentOS / RHEL / Rocky
yum install iperf3 -y

仓库里没有的话，去官网下源码编译，依赖很少，只需要gcc和make：

bash复制wget https://downloads.es.net/pub/iperf/iperf-3.16.tar.gz
tar -xzf iperf-3.16.tar.gz
cd iperf-3.16
./configure
make && make install

装完同样用iperf3 -v验证。Linux服务器做服务端时有个常见坑：系统默认的TCP缓冲区上限可能不够高，尤其在高带宽长距离链路上会限制吞吐。可以通过sysctl调大：

bash复制sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216

这个在千兆内网里不明显，但在10Gbps以上或者跨地域专线时，不调窗口上限带宽就是上不去，后面调优部分会再展开。

2.3 macOS和群晖NAS等特殊环境

macOS可以用Homebrew装，一条命令搞定：

bash复制brew install iperf3

群晖NAS这类嵌入式系统比较麻烦，官方套件中心没有iperf3，得进SSH手动装。比较省心的做法是用Docker：

bash复制docker run -it --rm --network=host networkstatic/iperf3 -s

这句在NAS上直接起服务端。我自己实测在DS920+上跑iperf3服务端挺稳的，而且Docker镜像里自带的iperf3版本比套件中心的旧iperf2好用太多。

3. 核心参数解析：从一次最简单的TCP测试说起

3.1 先跑通一次：服务端和客户端的配合

假设有机器A（192.168.1.10）和机器B（192.168.1.20），B是NAS，A是PC。先在这两台机器上都装好iperf3，然后：

在目标设备（作为接收方）B上启动服务端：

bash复制iperf3 -s

默认监听5201端口。然后在PC端A上执行：

bash复制iperf3 -c 192.168.1.20

几秒钟后屏幕上就会出来一段结果。默认情况下，客户端会持续向服务端传输10秒钟，结束后显示三行关键的Summary：

code复制[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  1.09 GBytes   938 Mbits/sec                  sender
[  5]   0.00-10.00  sec  1.09 GBytes   938 Mbits/sec                  receiver

看receiver那行的Bitrate，这就是实际的TCP吞吐量。如果两条链路上同时还有别的业务，数据会偏低。生产环境建议在业务低峰期测试，并且用-i 1参数每秒打印一次数据：

bash复制iperf3 -c 192.168.1.20 -i 1

这样能看到吞吐随时间的变化曲线，排查“刚开始快、后面慢”这种拥塞问题会清晰很多。

3.2 TCP测试的核心参数速查

iperf3参数不算多，但每个都影响结果，这里把最常用的一套列出来：

参数看起来很杂，但核心逻辑就一句话：客户端发起、服务端响应，时长用-t控制，流量形态用-u和-b控制，压力规模用-P控制。

3.3 理解关键原理：为什么固定线程数和TCP窗口会影响结果

很多人第一次测iperf3，发现千兆内网只能跑到四五百Mbps，第一反应是“网线坏了”。其实很可能是两个原因：iperf3是单线程模型，默认只能用单核CPU处理数据包。如果你的设备CPU主频低、单核性能弱，比如一些ARM架构的NAS，跑到500Mbps就顶天了，这不是网络瓶颈，是CPU瓶颈。这时候可以试试-P 4，开四个并发流，让多个CPU核心合力处理，往往会看到吞吐明显上涨。这也是为什么一开始测速老是上不去，先用-P参数拉开线程数再判断是不是硬件瓶颈。

另一个关键点是TCP窗口大小。TCP的吞吐上限理论上受“带宽时延积（BDP）”约束，公式是：

code复制BDP = 带宽 × 往返时延
窗口大小 ≥ BDP 才能打满带宽

拿千兆局域网举例：带宽1000Mbps，RTT 0.5ms，BDP约62.5KB，默认窗口就能满足。但如果是跨地域专线，带宽100Mbps、RTT 50ms，BDP就有625KB，默认窗口可能不够，带宽自然上不去。这时候手动指定窗口：

bash复制iperf3 -c 192.168.1.20 -w 2M

窗口调大以后，吞吐有时能翻一倍。道理就是：TCP的发送窗口决定了数据在路上“同时能存在多少”，窗口太小，链路再宽也是空空荡荡的，就像一条很宽的高速公路上车流很少，通行量自然上不去。

4. 实操进阶：UDP打流、多流并发与全双工验证

4.1 UDP打流测试的正确姿势

UDP模式是iperf3的看家本领，尤其在做语音、视频这类实时业务的链路质量评估时，TCP测出来的吞吐值参考意义有限，因为TCP有重传机制，丢包会自动补偿；而UDP没有这些机制，能直接暴露链路的丢包和抖动。UDP测试的命令长这样：

服务端：

bash复制iperf3 -s

客户端：

bash复制iperf3 -c 192.168.1.20 -u -b 100M -t 30 -i 1

这里-u指定UDP模式，-b 100M表示“我要打100Mbps的UDP流量”。难点在于-b怎么选。实际上UDP没有拥塞控制，它就像一个任性的发送机，你说打多快它就打多快，不给链路设上限，可以把链路直接打爆，造成全网卡顿。所以务必要先明确这条链路的目标带宽，设一个安全阈值。一般建议先按链路标称带宽的80%设置，测完再一点点往上加。

看结果时有三个指标：

code复制[ ID] Interval       Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5] 0.00-30.00 sec   354 MBytes   99.0 Mbits/sec  0.045 ms  0/24874 (0%)  sender
[  5] 0.00-30.00 sec   353 MBytes   98.7 Mbits/sec  0.049 ms  0/24765 (0%)  receiver

• Bandwidth：实际达到的吞吐，如果远低于-b设定值，说明链路能力不足。
• Jitter：抖动，单位ms，一般VoIP要求低于30ms，视频会议要求更低。
• Lost/Total：丢包率和丢包数量。0%说明链路质量好，1%以上就需要定位原因。

UDP测试里最典型的问题是“发送端带宽高、接收端带宽低”，或者出现Lost/Total数值很高，说明中间设备处理不了那么多包，已经开始主动丢弃。这时候需要把-b降下来，或者检查交换机端口是否存在拥塞。

4.2 多并行流的压力测试：-P参数的使用边界

要让多核设备跑出极限，就需要-P参数：

bash复制iperf3 -c 192.168.1.20 -P 4 -t 20

这句话会同时建立4条TCP连接并行打流。很多人以为-P越大越好，其实有个边界：一般建议从2开始，逐步增加到4、8，观察每次结果是否还在明显提升。如果加到8以后结果反而下降了，说明CPU软中断、网卡多队列已经饱和，再增加流数只是增加调度开销。

要真正把多核压满，还有个隐蔽条件：网卡的RSS（Receive Side Scaling，接收端缩放）多队列功能必须开启，否则所有流量被中断到同一个CPU核心，多流也无法利用多核。Linux下可以用下面命令看网卡支持的队列数：

bash复制ethtool -l eth0

如果看到Combined最大是4或8，就说明有多个队列。但Windows下大部分网卡默认就开启了RSS，不用额外折腾。

4.3 反向测试与双向同时打流：验证全双工链路

iperf3的-R参数是让服务端向客户端发数据，也就是测反方向：

bash复制iperf3 -c 192.168.1.20 -R

更严格的做法是双向同时打流。iperf3本身不支持在一条命令里同时跑双向，但你可以开两个窗口，一个用默认方向，一个加-R：

bash复制# 终端1
iperf3 -c 192.168.1.20 -t 30

# 终端2
iperf3 -c 192.168.1.20 -R -t 30

两个方向同时测试，能验证设备是否具备真正的全双工转发能力。有些低端交换机在半双工模式下，单方向吞吐正常，双向同时跑就掉到一半，这种坑只有双向测试才能踩出来。

4.4 关于magic iperf3和图形化工具的使用建议

如果想省事，也有人推magic iperf3。它的价值在于把参数变成了表单，选服务端还是客户端、输IP、设带宽、选UDP/TCP，点开始就出结果。但有几个问题你得知道：部分打包版本内置的iperf3版本较旧，可能少了新参数；而且在Windows上被安全软件误报的情况也遇到过。最稳妥的办法还是先下载官方zip包，把iperf3.exe保存好，magic iperf3这类工具适合给不太熟悉命令行的同事应急用，长期搞网络调试的还是建议命令行走天下。

5. 常见问题与排障实录

5.1 症状一：吞吐远低于预期，怎么分层定位

无论拿到多离谱的iperf3结果，都要先按“端到端分层”的思路来。千万不要一上来就换网线、换交换机。我的习惯是：

1. 先确认协商速率：电脑网卡显示1.0Gbps还是100Mbps，如果显示100Mbps，已经说明物理链路有问题。
2. 检查MTU：两端设备MTU不一致且开了巨型帧，容易出现“能ping通但大包静默丢失”的诡异现象。iperf3测速低但ping正常时，用ping -l 1472测试大包。
3. 换iperf3参数排除软件因素：加-P 4试一下多流，如果多流能跑满而单流跑不满，说明是端点CPU或TCP窗口问题，链路本身没毛病。
4. 分段测试：电脑连交换机测电脑到交换机，再直连NAS测，最终确定瓶颈在哪一段。

有一次我帮朋友定位NAS传输慢，iperf3单流只有280Mbps，加-P 8能到930Mbps，判断是NAS的J3455 CPU单核性能不够，不是网线问题。不跑多流测试，这问题就很难定位清楚。

5.2 症状二：客户端连不上服务端

“Unable to connect to server: Connection refused”或者一直卡在Connecting，大概率不是iperf3本身的问题，而是服务端没起来、端口被防火墙挡了、或者服务端绑错了网卡。

Windows上重点是防火墙放行：

bash复制netsh advfirewall firewall add rule name="iperf3" dir=in action=allow protocol=TCP localport=5201

Linux上检查监听端口：

bash复制ss -lntp | grep 5201

如果没有监听，多半是iperf3服务端没启动成功，前台直接跑iperf3 -s看有没有报错。另外，有些Linux发行版防火墙默认开启：

bash复制firewall-cmd --permanent --add-port=5201/tcp
firewall-cmd --reload

云服务器还要记得安全组规则放行5201端口，这个很容易漏。

5.3 症状三：UDP打流时接收端带宽为负值或丢包异常高

iperf3的UDP接收端如果报告Bandwidth是负数，其实这个现象很经典，通常是因为发送端发生了时钟跳变，或者客户端既当发送方又统计丢包时计数器溢出。更常见的“丢包从接收端看非常高”则是接收缓冲区不足：

Linux下提升UDP接收缓冲区：

bash复制sysctl -w net.core.rmem_default=16777216
sysctl -w net.core.rmem_max=33554432

客户端同步使用-w参数指定较大的接收窗口：

bash复制iperf3 -c 192.168.1.20 -u -b 200M -w 8M

如果丢包集中在接收端而发送端丢包为0，基本可以断定是接收缓冲区或接收端CPU处理能力问题。如果两端都丢包，那就是链路本身或中间交换机的队列溢出。

5.4 症状四：带宽测量结果不稳定，忽高忽低

内网测试最怕结果反复横跳。先别急着怀疑iperf3，这个工具本身是稳定的，问题更可能出在：测试期间有后台业务抢带宽、Wi-Fi干扰波动、或者设备里节能模式自动降频。跑长时间测试最有效：

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

用-i 10看分钟级别的抽样，均值会比10秒测试稳定得多。如果均值一直波动大，结合网卡协商、连接速率、信号强度来判断是物理层还是网络层的问题。无线环境里尤其明显，20MHz信道和80MHz信道的吞吐上限完全不同。

5.5 常见问题速查表

5.6 公网测试要特别注意的两件事

最后提个醒，iperf3不仅能测内网，也能测公网链路，比如你买了一台云服务器，想验证带宽，完全可以用本机连服务器测。但公网环境必须有节制：一是服务端是公开IP的话，任何人扫到5201端口都能给你灌流量，会造成昂贵流量账单，测完务必立刻关掉服务端；二是公网测试结果受运营商路由、跨网段质量影响，和Speedtest一样，只能说明“到你服务器的路径质量”，不代表你的宽带本身不行。真正要验收宽带，应该找运营商提供的测速节点或专门的测速服务器，而不是拿iperf3去随便连。

6. 附：一次完整的实测记录与结果解读

文字写得再多，不如跑一遍。以下是我在一个千兆局域网环境下的完整实测，环境：Windows 11客户端，Linux服务端，网线直连千兆交换机。服务端启动iperf3 -s，客户端依次执行三组命令。

第一轮，TCP默认10秒测试：

bash复制iperf3 -c 192.168.1.20

结果：

code复制[  5]   0.00-10.00 sec  1.09 GBytes   938 Mbits/sec                  receiver

千兆链路跑到938Mbps，基本达到线速，说明物理链路干净，TCP默认参数够用。

第二轮，加-P 4测试多流能力：

bash复制iperf3 -c 192.168.1.20 -P 4 -t 10

结果：

code复制[SUM]   0.00-10.00 sec  1.10 GBytes   946 Mbits/sec                  receiver

单流已经接近940Mbps，多流只是微涨，说明单核CPU已经够用了，链路本身也没有瓶颈。

第三轮，UDP打流100Mbps测试抖动与丢包：

bash复制iperf3 -c 192.168.1.20 -u -b 100M -t 15

结果：

code复制[  5]   0.00-15.00 sec  176 MBytes   98.8 Mbits/sec  0.032 ms  0/12343 (0%)  sender
[  5]   0.00-15.00 sec  176 MBytes   98.8 Mbits/sec  0.059 ms  0/12343 (0%)  receiver

抖动0.059ms，丢包0%，链路质量很好。这个结果可以作为基线存档，之后网络一旦劣化，再跑同样的命令对比，问题就一目了然。

7. 我的实操体会

用iperf3这么多年，最让我感慨的是：网络调优里90%的问题都不是玄学，而是没拿到足够精确的测量数据。iperf3的价值就是帮我把“感觉网很慢”这种模糊问题，变成“链路938Mbps、CPU瓶颈、丢包0.059%、窗口不足”这些具体事实。一旦问题被量化，排障思路就清晰了。

几个个人建议送给你：第一，在所有设备上把iperf3装好，临时应急至少也得备个Windows版zip包；第二，测试前先确认物理层协商速率，这能排除一半的干扰因素；第三，建立自己的“基线数据”，同一链路在不同时间多测几次存下来，后面再出问题才有参照物。另外建议顺手学一下JSON格式输出，配个脚本定时跑，能做成简单的链路质量巡检工具，这个投入很值得。