iPerf网络性能测试实战：从基础命令到带宽、丢包、抖动分析

我做了几年网络设备测试，每天跟带宽、丢包、抖动打交道，经常遇到有人拿着两个千兆口的设备，非说“这网速不对”，结果一查，只是拿SMB复制文件在那愣测——磁盘缓存、小文件开销、协议栈限制全混在一起，根本说不清是网络问题还是存储问题。后来我就跟身边人反复讲：真要验证网络本身的性能，别猜，用iPerf。

iPerf是一个开源的网络性能测试工具，专门用来测两台设备之间的TCP/UDP最大带宽、抖动和丢包率，通吃Windows、Linux、macOS，命令行一敲，结果一出来，链路成色一目了然。这篇博文就是给零基础的人准备的，一步步带你把iPerf环境搭起来、把测试跑通、把结果看懂，最后再讲几个我在实测里踩过、也帮别人排查过的坑。不管你是刚入行的运维、做车载电子测试的工程师，还是就想验一下家里新换的交换机是否满速，这套流程都适用。

1. iPerf到底能做什么，为什么测网络一定要用它

1.1 挂羊头卖狗肉的错误测速法

很多人验证网络好坏的第一反应是：在两台电脑之间拷个大文件，看速度。这个办法不是完全不能用，但结果几乎没法信。原因有三个：第一，文件拷贝的速度上限不一定由网络决定，硬盘的读写速度、文件系统的缓存策略、SMB/NFS协议的处理开销都会成为瓶颈，你看到的速度可能只是磁盘cache命中了；第二，拷贝过程受小文件数量的影响极大，几万个几KB的小文件拷贝速度能掉到几MB/s，但这跟链路质量毫无关系；第三，你没有统一的标准，今天拷这个文件明天拷那个文件，得到两个数字没法对比。

iPerf解决的就是这个痛点。它专门用来打流，不碰磁盘，所有数据都在内存里生成、发送、接收、丢弃，测出来的就是网络这条“管道”本身能透多少水。你拿它测出来的数字，跟设备、跟交换机、跟网线的关系是干净的，不会被存储干扰。

1.2 iPerf核心功能一览

iPerf的命令行选项很多，但核心就两件事：

• 测TCP带宽：默认模式，计算有效吞吐量，也就是一条TCP连接最多能跑多少Gbps。
• 测UDP带宽/质量：指定带宽发包，统计接收端的吞吐量、丢包率、抖动（jitter）。

前者对应文件传输、数据库同步这类靠TCP传输的场景，后者对应音视频实时流、语音通话这类使用UDP的场景。TCP测出来的是“我能跑多快”，UDP测出来的是“这条链路稳不稳、丢不丢包、抖不抖动”。很多视频卡顿、语音断断续续的问题，TCP带宽明明看着很高，单查UDP指标才发现丢包率吓人。

1.3 谁最需要这套工具

• 运维和IT人员：机房新上服务器，验证交换机端口链路是否协商对、网线是否达标。
• 车载电子测试工程师：车载以太网（比如100BASE-T1、1000BASE-T1）的带宽、稳定性测试，iPerf是实验室里的常客。
• 无线网络调试者：家里换了Wi-Fi 6路由器，验证5GHz频段的实际吞吐量。
• 硬件开发者：量产网口、嵌入式板卡，需要批量确认网口驱动和PHY芯片工作正常。

我自己的习惯是：只要是涉及“两个网络节点之间到底能跑多少量”的问题，第一反应永远是iPerf，不是ping，不是拷贝文件。ping只能证明“通不通”，iPerf能告诉你“快不快、稳不稳、极限在哪”。

2. 环境搭建：三分钟把iPerf装到三台平台上

2.1 Windows上安装iPerf

Windows最直接的方式是去iPerf官网下载编译好的二进制压缩包，解压到任意目录即可，不需要安装。解压后文件夹里一般能看到iperf3.exe（新版）或iperf.exe（旧版）。为了后续使用方便，建议把这个目录加入系统PATH环境变量。右键“此电脑 → 属性 → 高级系统设置 → 环境变量”，在Path里新增你解压的路径，保存后新开一个命令行窗口，敲下：

iperf3 -v

如果打印出版本信息，说明安装成功。顺便说一句，Windows系统自带的杀毒软件有时候会弹窗提示，这是因为iPerf本身要监听端口当服务器，属于正常现象，选择允许即可。

2.2 Linux上安装iPerf

Linux的安装命令各个发行版不太一样，但都很简单。Ubuntu/Debian系列用apt：

sudo apt update sudo apt install iperf3

RHEL/CentOS系列用yum或dnf：

sudo yum install iperf3 # 或者 sudo dnf install iperf3

装完还是一样，用iperf3 -v确认。有些老系统的源里可能只有iperf2，不是不能用于基础测试，但后续讲的参数以iperf3为准，建议优先装3.x版本。

2.3 macOS上安装iPerf

macOS用户如果装了Homebrew，一行命令搞定：

brew install iperf3

没装Homebrew也可以用编译源码的方式，但没必要，先装Homebrew，日常用的工具基本都能覆盖。

2.4 iperf2还是iperf3？

这里专门提醒一个新手容易踩的坑：你搜iPerf教程，搜出来的命令一半是iperf的，一半是iperf3的，参数用法略有区别。iperf2是经典版本，很多老设备、嵌入式Linux自带的还是它；iperf3是重写后的版本，修了很多老问题，支持多线程流，输出也更易读。

建议统一用iperf3。唯一的例外是，如果你的被测设备只有iperf2（比如某些老安卓开发板的系统镜像里编译好的只有iperf2），那两边协议必须一致，服务器端和客户端用同一个主版本，别混着跑。

3. 第一次把测试跑通：架构理解与命令行上手

3.1 最简单的C/S模型

iPerf采用经典的客户端-服务器模型。测试前，你手里必须有两台能通过网络连通的设备，一台充当服务器端，一台充当客户端。不能用一台设备自己测自己，因为这样流量没有真正跨过物理链路，结果没有任何意义。

服务器端执行：

iperf3 -s

客户端执行：

iperf3 -c 服务器IP地址

默认情况下，客户端会向服务器的5201端口发起TCP连接，持续传输10秒，然后把测量结果分别打印在两端屏幕上。

3.2 一条命令跑通，快速看懂输出

假设我在一台IP为192.168.1.10的电脑上启动了服务器端，然后在另一台电脑上执行：

iperf3 -c 192.168.1.10

典型的输出如下：

Connecting to host 192.168.1.10, port 5201 [ 4] local 192.168.1.20 port 50000 connected to 192.168.1.10 port 5201 [ ID] Interval Transfer Bitrate Retr [ 4] 0.00-1.00 sec 113 MBytes 948 Mbits/sec 0 [ 4] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 0 ... [ 4] 0.00-10.00 sec 1.09 GBytes 940 Mbits/sec 0

每一行是一个1秒间隔的数据，Transfer是这段时间传了多少数据，Bitrate是速率，Retr是TCP重传次数。最后一行是整个测试10秒的汇总。如果你用的是千兆网卡、千兆交换机、超五类及以上网线，这个数字跑到940Mbps左右就算正常，跑不到就说明链路或配置有瓶颈。

这里有个小细节：为什么千兆口理论上限是1000Mbps，实测最高却只有940Mbps左右？因为TCP/IP协议要消耗额外的开销，帧头、ACK包、控制帧等都要占带宽，实测940-950Mbps才是健康状态。如果有人跟你说千兆测出999Mbps，别信，要么是统计区间太短，要么是用了奇怪的加速手段。

3.3 反向测试与服务端模式

默认是客户端往服务器方向打流，也就是从client端发送、server端接收。但实际网络设备很多时候是收发不对称的，尤其无线和PON接入场景。想看反向带宽，也就是服务器往客户端方向发送，加一个-R参数即可：

iperf3 -c 192.168.1.10 -R

这是一个非常实用的参数，我测路由器NAT转发性能、测无线AP上下行吞吐时，正反向差距往往能暴露很多问题。有的设备下行能跑900Mbps，上行只有400Mbps，这时候只看一个方向就会被误导。

4. 高频参数解析：-l、-t、-P、-u、-b别再用错

4.1 -l 参数：调整缓冲区长度到底影响什么

热词里提到“iperf的-l参数”，这也是很多新手最容易困惑的一个参数。-l是--len的缩写，意义是设置读写缓冲区的长度，单位默认是字节。在iperf3里，TCP模式下默认的缓冲区长度是128KB，UDP模式下默认是8KB。

很多人以为调大-l就能让带宽跑得更高，其实在TCP模式下，-l的作用远没有想象中那么大。因为TCP有拥塞控制和窗口协商机制，真正决定吞吐量的是TCP窗口大小、往返时延和网卡/CPU的处理能力，缓冲区只要设置合理，瓶颈通常不在这一层。在实际测试里，我会按如下场景调整-l：

• UDP模式测小包转发性能：把-l调成64、128、256字节，用于模拟VoIP语音包、游戏同步包等小包场景，看单位时间内能转发多少个包、丢包率是多少。
• UDP模式测大包带宽：把-l调成1400字节左右，模拟接近MTU的视频流数据包。
• TCP模式下很少动：除非默认缓冲区在你特定的高带宽长距链路上有异常表现，否则保持默认就好。

举个例子，用UDP模式测试一个设备处理128字节小包的能力：

iperf3 -c 192.168.1.10 -u -b 100M -l 128 -t 30

这条命令表示以100Mbps的码率发送长度为128字节的UDP包，持续30秒。服务器端统计出来的丢包率一旦偏高，说明设备的小包转发能力存在瓶颈。在这里要强调一个容易误操作的点：-l的单位是字节，千万不要把它跟-b的单位（bit）搞混，写错一个数量级测试结果完全没法看。

4.2 -t 和 -i：控制测多久、打印多密集

-t指定测试持续时间，默认10秒。测长期稳定性时我会用它跑30秒、1分钟，甚至几个小时。-i指定每隔几秒打印一次结果，默认是1秒一次。如果跑1小时测试还1秒记一行，输出会非常长，这时我通常把-i设成10，既能看到变化趋势，又不至于刷屏：

iperf3 -c 192.168.1.10 -t 3600 -i 10

4.3 -P 多流并发：更接近真实的业务模型

-P指定并发连接数，默认是1条TCP流。单条流的带宽上限有时候受限于单核CPU的吞吐能力，尤其是2.5G/10G网卡出现之后，单流很难打满，这时候要用多流：

iperf3 -c 192.168.1.10 -P 4

我测服务器网卡和交换机上联口时，一般至少开4条流，多的时候开16条。多流还能模拟实际业务的并发特征，比如几十台设备同时访问NAS、几百路视频流同时通过核心交换机。但要注意，-P出来的总带宽是各条流之和，iperf3最后输出会按每个stream分别列速度，最后再给一个SUM汇总，别只看第一个流觉得带宽不对。

4.4 -u 和 -b：UDP模式才是测试链路质量的杀手锏

默认的TCP测试只输出“速率”，它只能告诉你极限能跑多快，却很难暴露抖动和实时性。要测视频会议、语音通话这种对延迟敏感的UDP业务，必须切换到UDP模式，并用-b指定发送码率：

iperf3 -c 192.168.1.10 -u -b 20M

这条命令表示以20Mbps的速度发送UDP流，持续10秒。UDP模式测完，服务器端会输出三组关键数字：接收速率、丢包率（Lost/Total Datagrams）、抖动（Jitter）。比如你设定20Mbps的码率，结果接收端只收到15Mbps、丢了25%的包，抖动高达5ms，那么中间链路肯定是有问题的。这里建议码率不要设置过高，超过链路极限会导致系统性的丢包，反而掩盖了真实的抖动水平。正确的做法是先跑TCP测出极限带宽，再取极限带宽的50%~80%作为UDP测试码率。

4.5 其他值得收藏的参数

• -p：指定服务端端口，默认5201，如果端口被占用或者要同时起多组测试，必须修改。
• -O：忽略前N秒的“热身”数据，排除慢启动阶段的影响，测长稳时很实用。
• --bidir：双向同时测试，省去手动反向测试，适合验证全双工链路。
• -R：反向模式，服务器发送、客户端接收。
• -4/-6：强制IPv4或IPv6。

5. 看懂测试结果：带宽、丢包、抖动、重传的判读标准

5.1 带宽数字怎么看才不算误判

很多人测完只盯着“Bitrate”那一列，看到数字小于网卡标称速率就慌了。其实不应该直接拿它跟网卡的“标称速率”比，而要跟“协商速率”比。所谓协商速率，就是网卡和交换机端口实际握手出来的速率等级。如果你用的是千兆网卡，但网线是四芯的老线，协商速率可能只有100Mbps，那么TCP跑到94Mbps左右反而是满速。先确认协商速率再下结论。Linux下可以用ethtool 网卡名查看，比如ethtool eth0，Windows下在“网络连接 → 状态”里就能看到链接速度。还有一点，测出来的带宽值如果波动极大，比如一会儿900Mbps一会儿200Mbps，除了链路拥塞，还要考虑对方设备的CPU是否被打满。低速嵌入式设备的性能瓶颈往往在CPU的协议栈处理上，而不是真正的物理链路带宽。

5.2 丢包率：判断链路质量的硬指标

UDP测试的丢包率是最敏感的指标之一。局域网有线场景下，健康的链路丢包率应当为0；无线网络可以放宽到0.1%~0.5%；如果超过1%，语音和视频通话就会明显感知到卡顿。丢包的原因可能是带宽超过了链路容量、交换机端口拥塞、光模块光功率异常、网线质量差、Wi-Fi信号干扰等。排查时先看是不是码率设太高，把-b降低一半再测一次，如果丢包率立刻归零，说明不是链路坏，而是流量超过了容量。

5.3 抖动（Jitter）：实时音视频最关注的数据

iPerf的UDP输出里Jitter表示接收端数据包到达时间的离散程度，单位毫秒。抖动越小越好，有线局域网一般小于0.5ms，无线网络通常在1~5ms区间。抖动大于10ms时，VoIP通话会出现明显的断续或回声，视频会议的体验也会很差。如果抖动跟丢包率同时升高，多半是拥塞导致的排队延迟波动。值得注意的是，jitter是在服务端统计的，所以测试时两边的时钟不需要同步，不影响正确性。

5.4 Retr：TCP重传数

TCP模式的输出里有个Retr字段，表示这段时间内发生了多少次TCP重传。重传多的可能原因包括：链路丢包、收发缓冲区太小、拥塞窗口被误伤。短时间轻微重传不一定是坏事，TCP本身就是靠重传和拥塞控制来保证可靠性的，但如果在千兆局域网里测出大量重传，基本可以判定链路物理质量存在问题。我做网线验收时，会连续跑10次TCP测试，任何一次Retr超过个位数，这根线我都会重新压。

6. 进阶实战：长时间稳定性测试与车载网络场景

6.1 用iPerf做12小时压力测试

很多网络故障不是一开始就出现的，而是运行一段时间后，设备发热、内存泄漏、性能下降才会暴露。只测10秒根本看不出问题。我最常跑的稳定性测试套路是：服务器端开启iperf3 -s，客户端用4条并发流连续跑12小时，每10秒记录一次结果：

iperf3 -c 192.168.1.10 -P 4 -t 43200 -i 10

跑完后把输出的数据拷下来导入Excel，画一条“时间-带宽”曲线。健康的曲线应该平稳，顶多围绕平均值小幅波动，如果出现周期性掉坑或瀑布式下降，基本就是设备热降频或固件bug。做这种长稳测试时，建议用-O 30先跳过前30秒的慢启动阶段，避免把启动过程算进平均数据。

6.2 车载以太网测试中的iPerf实践

热词里“车载网络测试”是一个重要场景。现代汽车里的摄像头、雷达、IVI主机之间跑的都是以太网，最常见的是100BASE-T1和1000BASE-T1。这类链路的特点是对电磁干扰敏感、线束环境复杂，所以验证单个ECU（电子控制单元）的收发能力和整车网络在恶劣环境下的稳定性，就成了开发测试的重要一环。

在车载实验室里，工程师会把两个ECU板卡通过车载以太网线束对接，一边运行iPerf服务器端，一边运行客户端。由于很多ECU是嵌入式Linux系统，资源有限，跑iPerf时参数要保守一些，比如把并发流控制在2条以内，UDP码率按链路带宽的50%设置。另外，车载场景下我更关注的是长期丢包率曲线和抖动是否随温度变化，所以通常结合温箱做联合测试：温度从-40℃升到85℃，全程每5分钟记录一次jitter和丢包。如果丢包率曲线在某个温度点突然抬高，那基本能锁定是PHY芯片或者晶体振荡器的温漂问题。这不是说iPerf能替代专业车载测试工具，但它作为快速验证手段，成本低、部署快，非常适合前期摸底。

6.3 无线网络的iPerf测试要点

测试Wi-Fi网络时，环境因素影响极大，跟有线测试完全是两回事。无线测试第一原则是：固定位置再测，不要边走动边测。室内环境下，手机或者笔记本离路由器1米远、隔一堵墙、走到阳台上，三个位置的吞吐量可能分别是900Mbps、300Mbps、50Mbps。如果要做对比，比如对比两个路由器谁信号好，必须保证被测设备、客户端位置、天线角度、测试时段完全一致。建议在每个点位至少测3次取平均值，无线链路的波动特性决定了单次测试没有代表性。另外，无线测试时注意周围其他Wi-Fi的干扰，选择深夜或者工作日上午这种干扰少的时段，测试数据会稳定很多。

7. 常见问题排查实录与避坑指南

7.1 就是连不上：常见连接报错

新手最常遇到的报错是unable to connect to server。按以下顺序排查：

我这几年见过最多的问题，不是命令写错，是防火墙没放行。Windows自带防火墙默认拦截入站连接，在公网/局域网里跑iPerf前一定要把对应端口放行，或者干脆临时关闭防火墙测试确认根因后再加规则。

7.2 带宽怎么都跑不满

有一个特别隐蔽的问题：网卡的“节能以太网（EEE）”和“中断合并（Interrupt Coalescing）”功能，在某些主板网卡上会导致小包吞吐剧烈抖动。此时可以尝试在网卡高级设置里关闭节能相关的选项，或者把接收/发送缓冲区调大，重新测试。

7.3 小技巧：写一个一键测试脚本

最后分享一个我常用的批处理小脚本，把服务器端、客户端参数固化好，团队成员不需要记参数就能跑：

#!/bin/bash # iperf3_quick_test.sh 用法: 脚本名 服务器IP SERVER=$1 if [ -z "$SERVER" ]; then echo "Usage: $0 <server_ip>" exit 1 fi iperf3 -c "$SERVER" -t 10 -i 1 iperf3 -c "$SERVER" -t 10 -i 1 -R iperf3 -c "$SERVER" -u -b 20M -t 10 -i 1

这段脚本一次执行TCP上行、TCP下行、UDP稳定性三组测试，正好覆盖大多数网络验收场景。实测下来，一个完全没接触过iPerf的同事，拿到这个脚本和一份结果判读表，也能独立完成基础测试。我个人在实际操作中还有一个习惯：每次测试前用date命令给输出加个时间戳，保存到独立日志文件里。网络问题的排查经常需要回看历史数据，没有时间戳的日志，价值至少打一半折扣。