企业官网建设流程全解析

两周前帮一个朋友排查家里电视串流的卡顿问题，他一口咬定是路由器太老该换了，结果我带着笔记本到他家，用iperf3把电脑和电视之间、电脑和交换机之间、交换机和路由器之间的链路各自打了一遍流量，最后发现罪魁祸首是一根被沙发脚压扁的网线——链路速率直接掉到了百兆。换了根线之后，一切恢复正常。朋友感叹了一句“原来测网速还分这么多种”，这就是我要写这篇iperf3全攻略的原因。

网络性能测试这件事，大多数人其实只用过在线测速网站，点一下浏览器就知道“下行多少、上行多少”。但这类测试只能覆盖“你家到运营商测速服务器”这一段，而家里或者办公室里真正的网络性能瓶颈，往往出在内部设备之间：NAS到电脑、电脑到交换机、AP到核心交换机。想要把这两台设备之间的真实带宽、抖动、丢包测出来，iperf3是目前最靠谱也最常用的工具。这篇文章我会从环境搭建、TCP/UDP测试参数、结果解读、实际排障案例到注意事项全部过一遍，内容侧重实操，照着敲命令就能用。

1. 测了那么多次“网速”，我为什么还要专门用iperf3打流

很多人第一次听说iperf3，是在某个“网速慢”的讨论帖里。但真正上手之后会发现，它和在线测速完全是两个思路。搞清楚这个区别，你就理解了iperf3的定位。

1.1 Speedtest和iperf3测的是两种东西

在线测速网站（Speedtest、花瓣测速这类）的逻辑是：你的设备连接运营商机房的服务器，服务器持续向你发送数据，浏览器计算吞吐量。它测的是“你家宽带出口到测速节点”的链路质量，受运营商路由、测速节点位置影响很大。同一个宽带，晚上高峰时段测出来只有白天的一半，这种事很常见，因为瓶颈在运营商侧而不在你家。

iperf3的逻辑完全不同。它需要两个端点：一端跑服务端（iperf3 -s），一端跑客户端（iperf3 -c 对端IP），然后客户端主动向服务端发起一条数据流（TCP或UDP），在这条流上统计实际带宽、重传率、抖动和丢包。两台设备之间的交换机、网线、无线链路、路由器转发性能、网卡驱动，全部会被这条数据流“压”出原形。

所以在线测速回答的是“我家宽带够不够快”，iperf3回答的是“我这两台设备之间的链路到底行不行”。后者才是局域网组网、NAS部署、无线覆盖优化、专线验收时真正需要关心的数据。我接触过的很多家庭组网场景，宽带都是千兆，但文件从电脑拷贝到NAS只有30MB/s，这类问题在线测速永远测不出来，iperf3一打流立刻现形。

1.2 iperf3到底能测出什么

用一句话概括：iperf3能在一个可控的测试窗口内，把链路在TCP和UDP两种协议下的表现量化出来。具体包括：

• TCP场景下的最大吞吐量（单位通常显示为Mbps或Gbps）
• TCP重传率（重传高意味着链路有拥塞或丢包）
• UDP场景下的抖动（Jitter）和丢包率（Lost/Total）
• 多流并发时整体的聚合带宽（模拟真实业务的多连接情况）
• 反向模式的带宽（客户端往服务端方向）
• 指定包大小、缓存窗口、运行时间后的链路表现

基于这些数据，你能判断出链路是带宽不够、延迟太高、丢包严重，还是设备本身性能不行。我后面会在排障案例里演示具体怎么看。总之，iperf3是一个“诊断工具”而不是“测速玩具”，它输出的每一行都有意义。

2. 三分钟跑通：环境准备和第一份带宽报告

在进入参数细节之前，先把环境搭起来。这一步卡住不少人，尤其是Windows用户，因为iperf3官方发布页的下载入口并不显眼。

2.1 各平台安装方式与下载注意点

Linux（Ubuntu/Debian系）：

sudo apt update sudo apt install iperf3 iperf3 -v

CentOS/RHEL系：

sudo yum install iperf3 # 如果源里没有，可以用EPEL sudo yum install epel-release sudo yum install iperf3

macOS：

brew install iperf3

Windows：官网（iperf.fr）提供编译好的exe压缩包，下载后解压，在解压目录里打开命令提示符（或PowerShell）运行。注意Windows版本的iperf3通常是一个文件夹，里面同时有iperf3.exe和iperf2的exe，两者不能混用。下载时认准文件名里带3字样的，老版本iperf2和iperf3协议不互通，我之前就见过有人装了iperf2的客户端去连iperf3的服务端，结果一直卡在连接阶段。

提示：手机端也可以装iperf3，App Store和安卓市场里搜“iperf3”都有第三方客户端（比如“HE.NET Network Tools”内置了iperf3功能）。做无线测试时会很方便，手机直接当无线测速节点。

安装完先跑一下 iperf3 -v 确认版本号。两端版本不必完全一致，但建议都别太老，3.13以下的老版本缺少部分新参数（比如 -C 拥塞控制算法选项），出问题时排查起来容易混淆。

2.2 第一次测试：服务端加客户端，三行命令看懂结果

假设你有两台机器，机器A做服务端，IP是192.168.1.10；机器B做客户端。

服务端执行：

iperf3 -s

默认监听5201端口，会打印一句“Server listening on 5201”。如果被防火墙挡住会报错，后面第7章会说。

客户端执行：

iperf3 -c 192.168.1.10

默认测10秒，这10秒内会用单线程尽量打满链路。结束后客户端会打印一份报告，最需要关注的是最后几行：

[ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.10 GBytes 945 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 1.10 GBytes 945 Mbits/sec receiver

• Transfer：总共传了多少数据
• Bitrate：实测平均带宽，945 Mbits/sec表示约945兆比特每秒
• Retr：TCP重传次数，0代表没有重传，链路很干净

如果是千兆有线环境，跑到900Mbps以上是正常的。如果只有100Mbps上下，基本可以断定链路降到了百兆速率（网线劣质、水晶头没做好、交换机端口协商为100M都是常见原因）。小于100Mbps则要看网卡驱动、CPU占用或者是不是有设备在限速。

客户端如果想看更细的每秒数据，加 -i 1（每1秒打印一行）；想多测一会加 -t 30（30秒）。这是我日常测试的基本组合：

iperf3 -c 192.168.1.10 -i 1 -t 30

第一份报告拿到手，整个链路是否正常就有数了。后面几章讲的参数，全部是为了回答“如果结果不正常，问题出在哪”。

3. TCP单线程与多线程：千兆跑不满的常见原因和解决思路

iperf3的默认TCP测试是单条数据流。但很多人在这一步就被“坑”了：明明是千兆交换机，结果单线程测出来只有200~300Mbps，于是断定设备有问题。其实单线程跑不满千兆，往往是更复杂的链路因素导致的。

3.1 为什么单线程只有200Mbps，多线程却能跑满千兆

TCP在一条连接上的传输速率，受限于“延迟带宽积”（Bandwidth-Delay Product，BDP）。简单说，TCP的发送窗口决定了在等待确认（ACK）之前能一口气发多少数据，如果窗口太小，网速再快也没用，因为大量时间都花在“发一点、等确认、再发一点”的循环上。网络延迟越高，需要的窗口就越大。

这个领域的经验公式是：窗口大小 = 带宽 × 往返时延。比如千兆链路（1000Mbps）、RTT为20ms，理想窗口至少是1000Mbps × 0.02s = 20Mbit = 2.5MB。如果TCP窗口只有256KB，那就只有理论值的十分之一，单线程自然跑不满。

而iperf3的默认TCP窗口通常不大（不同系统不同，Linux默认可能只有几MB但受接收窗口限制），所以为了提高吞吐，最直接的方法是开多条并行流，让每个“窗口”各自跑一部分数据，把链路利用率叠上去。

客户端加 -P 参数指定并行流数量：

iperf3 -c 192.168.1.10 -P 4

服务端会收到4条连接，测得的带宽是4条流的总和。如果你发现 -P 1 只有250Mbps，-P 4 能到930Mbps，通常说明链路本身的物理带宽没问题，瓶颈在单条TCP流的窗口或终端设备的协议栈处理能力上。对于真实业务来说，很多应用本身是多连接的（浏览器、下载工具），多流测出来的聚合带宽反而更贴近实际体验。

3.2 合理调整TCP窗口，让长肥网络也跑满

-P 多线程是“捷径”，但如果你想知道单条TCP流本身的上限，或者要调的是一条真实业务的长连接（比如数据库同步、视频推流），那就要动 -w 参数手动设置窗口。

iperf3 -c 192.168.1.10 -w 2M

• 服务端不影响窗口设定，窗口由客户端发起时告诉对端
• 单位可以直接用K/M/G，这个写法在不同版本里都认
• 设置窗口需要系统和程序配合，Linux下如果提示权限问题，可以尝试加大socket缓冲区的系统上限（sysctl）

顺便说一句，iperf3报告的Bitrate是应用层负载数据率，不包含TCP头开销，所以千兆测试跑到940Mbps左右已经算跑满了（TCP开销和ACK包会占走一部分物理带宽），不要纠结为什么不是1000Mbps。

注意：很多人看到iperf3结果只有900Mbps出头，就到处查“是不是哪里没调好”。实际上在标准以太网MTU 1500字节下，千兆链路的TCP最大可用带宽就是940Mbps左右，这是协议开销决定的数学极限，不是故障。真正要警惕的是那种单线程只有400Mbps还伴随大量Retr（重传）的情况。

关于MTU：如果怀疑巨型帧（Jumbo Frame）没有统一开启，可以用 -M 参数指定TCP最大段大小：

iperf3 -c 192.168.1.10 -M 1400

-M 不带值表示探测路径MTU，带了值表示强制使用指定的MSS（TCP数据段大小）。一般不建议在没确认所有设备都支持Jumbo Frame时贸然开启，否则会导致部分设备无法通信。

4. UDP打流：抖动、丢包和真实业务的“压力测试”

标题的热搜词里单独提了“iperf3使用udp打流”，这个场景值得单独开一章。TCP测试虽然能反映吞吐量，但很多实时业务（视频会议、VoIP语音、直播推流、游戏同步）用的是UDP，它们对带宽的绝对速度不敏感，更怕抖动和丢包。iperf3的UDP模式就是专门用来量化这两个指标的工具。

4.1 UDP测试为什么不能直接照搬TCP的命令

很多人习惯性地执行 iperf3 -c 192.168.1.10 -u，然后看到结果只有1.05 Mbits/sec就以为工具坏了。其实这是iperf3的UDP默认发送速率被限制在了1Mbps，你需要用 -b 主动告诉它“按多大速率打流”。

iperf3 -c 192.168.1.10 -u -b 100M

这条命令表示：以UDP方式，按100Mbps的速率向服务端发送数据，持续10秒。服务端在端口5201上监听，不需要额外加 -u 参数（服务端会自动识别）。

这里的关键是 -b 的数值选择。它不是随便定的，应该接近你预期的链路带宽或业务峰值速率。比如你的办公出口带宽是200Mbps，那 -b 200M 就是“看看UDP能不能跑满200M”；如果你的视频会议码率只有4Mbps，-b 4M 是“看看这种低速率下链路会不会丢包”。打流速率定多高，直接决定你测的是“链路上限”还是“真实业务体验”。

还可以配合 -l 指定UDP负载大小（默认1470字节左右适配标准MTU）：

iperf3 -c 192.168.1.10 -u -b 100M -l 1400

如果怀疑MTU问题导致数据包分片，可以逐步降低 -l 数值观察丢包率变化。这个用法在排查“大包不通小包通”的经典网络故障时很有效。

4.2 一份UDP报告的读法：带宽、抖动与丢包率的配合判断

UDP测试结束后，客户端会输出类似如下内容：

[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 119 MBytes 100 Mbits/sec 0.045 ms 0/85208 (0%) sender [ 5] 0.00-10.00 sec 118 MBytes 99.3 Mbits/sec 0.052 ms 3/85208 (0.0035%) receiver

• Bitrate：发送速率与服务端实际收到的速率。如果接收端Bitrate明显低于发送端，说明链路有瓶颈或设备处理不过来
• Jitter：抖动，单位ms。它表示数据包到达时间间隔的偏离程度，数值越高，实时业务越容易卡顿
• Lost/Total Datagrams：丢包数/总包数，括号里是丢包率。语音业务通常要求丢包率低于1%，视频会议最好低于0.5%，丢包率超过2%画面就会明显花屏或声音断续

排障时有个小技巧：先按链路带宽的50%打流，再逐步调高 -b 到75%、90%、100%。每档跑10秒左右，观察Jitter和丢包率的变化拐点。如果在某一档突然开始丢包剧增，说明链路的可用容量就在这个位置附近。比如 -b 80M 时丢包率0%，-b 100M 时丢包率跳到8%，那这条链路实际可用带宽就在80~100M之间，配置限速策略时可以以此为参考。

另外，服务端的报告同样重要。如果服务端显示接收速率低于客户端发送速率，而两端设备CPU都正常，那基本可以断定中间某一跳存在瓶颈或反向流量干扰。这种“单向丢包”的特征非常明显，是我排查专线问题时最常用的判断依据。

5. 反向模式与双向测试：别被单向测速的结果蒙蔽

默认情况下，iperf3的数据流是客户端主动发送，服务端接收，测的是“客户端上行链路”。但很多网络场景的上行和下行质量并不一致，尤其是无线网络、PON接入和带有NAT的设备。如果只测一个方向，可能得出片面的结论。

5.1 反向模式-R与它的适用场景

iperf3提供了一个 -R 参数，数据流方向完全反转：服务端发送，客户端接收。此时看的是客户端下行链路。

iperf3 -c 192.168.1.10 -R

这个参数在测“设备下载能力”时非常实用。举个例子：你家AP放在客厅，卧室信号显示满格，但你用手机在线看4K视频总卡。手机跑iperf3客户端，客厅放一台跑服务端的电脑，先用默认方向测手机到AP的上行，再用 -R 测下行。两种情况结果一对比，如果上行正常但下行只有一半带宽，问题大概率出在AP的天线配置或无线协商速率上，而不是宽带本身。

对于不对称接入（比如某些宽带的上行和下行本身就不同），-R 更是必须测的。验收宽带时我会在光猫后接一台软路由跑iperf3服务端，然后用 -R 测实际下行，这个数据才代表你日常上网的体验。

5.2 双向同时打流，观察链路是否对称

-R 是分开测两个方向，但有些故障只在“同时双向传输”时才会暴露。典型场景是NAS做备份，上传的同时还要从NAS往回拉旧数据；或者是视频会议，本地要发视频流给对端，同时还要接收对端的视频流。

iPerf3 自身不支持一条命令同时双向，但你可以开两个进程实现：

客户端A（作为普通客户端）：

iperf3 -c 192.168.1.10 -t 60

客户端B（作为反向客户端，同时发起）：

iperf3 -c 192.168.1.10 -R -t 60

这里注意，第二个命令的 -R 意味着同一个iperf3进程也会占用服务端的资源，两边同时打流，就能看到全双工状态下的真实表现。如果单向测试都能跑满千兆，但双向同时跑时每一侧都掉到三四百兆，常见原因是：

• 无线AP是半双工机制的（同一时刻只能收或发，实际表现为吞吐减半，这在Wi-Fi里很正常）
• 某些低端交换机的背板带宽不够，无法线速转发双向流量
• 终端CPU处理不过来了，打流本身就占满一个核心

我自己的习惯是：日常排障先用默认方向测一遍，再用 -R 测一遍，如果链路敏感度较高再补双向测试。三步下来，上下行是否对称、全双工是否正常，基本都能覆盖到。

6. 四个真实排障案例：从iperf3数据倒推网络瓶颈

参数讲了一大堆，但真正能体现iperf3价值的，还是用它排查真实故障的过程。我挑四个印象深刻的现场案例，每个都对应一种典型的链路问题，你可以拿着同样的思路去套自己的场景。

6.1 千兆交换机下文件拷贝只有30MB/s

有人跟我描述：公司新部署了一台NAS，接入千兆交换机，电脑直连NAS拷贝大文件，速度稳定在30MB/s，也就是240Mbps左右，距离千兆理论速度差了很远。网线是六类线，交换机是千兆端口，怎么看都不该这么慢。

我用iperf3在电脑和NAS之间打流，先跑默认TCP单线程，结果只有20.4 Gbits/s的零头（实际上测出来是204Mbps），加 -P 4 后直接跳到926Mbps。这个结果说明物理链路是好的，问题出在单条TCP流的吞吐能力上。进一步看NAS端CPU，单核已经占满了。

原因：NAS的某个服务进程把TCP收发处理限制在单个CPU核心上，而单核心处理千兆TCP流的能力刚好在200Mbps左右。解决方案是让iperf3把流分散到多个核心上（或者应用层多线程），现实中的文件复制如果有多个并发连接（比如SMB多通道），就不会受这个限制。后来我们检查发现，该NAS的SMB服务没有开启多通道功能，打开之后文件拷贝速度直接翻了三倍。

这个案例说明：iperf3测出“单线程慢、多线程快”时，先别怀疑网线或交换机，很多设备本身单连接处理性能不足，多流才是它的真实水平。

6.2 Wi-Fi信号满格但视频会议卡成PPT

家里无线网络信号满格，但视频会议总是一卡一卡的。用户换了一个更高端的路由器也没解决。我去现场之后，先用网线把笔记本电脑接到路由器LAN口，电脑上跑iperf3服务端，手机装iperf3客户端，在会议室（也就是卡顿高发区）跑UDP打流测试。

结果：-b 50M 时丢包率0.3%，Jitter 约2ms；-b 100M 时丢包率突然跳到7%，Jitter飙到15ms。而信号强度其实不差，满格。这说明瓶颈根本不在信号强度，而在信道的实际容量和干扰。

后来扫了一下周边Wi-Fi信道，发现邻居的路由器把2.4G和5G信道都占得很满，尤其是在视频会议时间段。把路由器的5G频段固定到相对干净的信道（比如149），并关闭2.4G和5G的“自动信道选择”之后，同样位置用iperf3再测，-b 100M 时丢包率降到了0.1%以内。问题解决。

无线环境下iperf3的UDP模式很有价值，因为它能区分“信号很好但信道拥堵”和“信号差导致速率低”这两种情况。前者丢包率高但SNR正常，后者协商速率本身就低。

6.3 专线时好时坏，UDP测试定位到光模块

某单位一条点对点专线，白天业务高峰期丢包率从正常的小于0.1%飙到5%以上，业务方怀疑是运营商出口带宽不够。我做了两件事：

先在运营商机房和用户端同时放两台服务器跑iperf3 UDP打流，-b 500M 持续1小时，观察丢包率随时间的变化。结果发现丢包率并不是均匀分布的，而是每隔几分钟就出现一次持续约100ms的丢包峰值。这种规律性丢包在无线环境意味着干扰，在有线专线环境则很可能是物理器件问题。

再配合ping测试，用持续ping（ping 对端 -i 0.2）验证，发现高峰期ping值偶尔会出现20ms以上的波动，和丢包峰值的时间点完全吻合。最终检查光模块的接收光功率，发现已经接近灵敏度下限，并且有间歇性告警。更换光模块后，再跑iperf3 UDP打流，丢包率稳定在了0%。

这个案例的参考价值在于：iperf3的UDP模式可以做一个长时间的持续打流，模拟业务流量把潜在的间歇性问题“压”出来。如果没有工具持续打流，光靠业务方的“时好时坏”反馈，很难定位到这么具体的物理器件故障。

6.4 新增的NAS速度不达标，问题竟然在磁盘

还有一次是朋友买了新NAS，宣称能跑满千兆，结果实际使用从电脑拖文件只有50MB/s（400Mbps）。iperf3 TCP测试跑出来是930Mbps，说明网络链路完全没问题。那原因就只剩NAS侧或电脑侧了。

在NAS上用dd命令测了一下磁盘写入：

dd if=/dev/zero of=/tmp/test bs=1M count=2048

测出来只有180MB/s的读取和写入，但NAS里盘的型号并不差。后来发现是新加的机械硬盘和系统盘混在一个RAID阵列里，阵列重建和校验拖慢了整体速度。把数据盘拆分之后，iperf3到NAS的传输速度马上恢复正常。

这个案例想提醒的是：iperf3能把“网络链路问题”和“非网络问题”干净地切割开。当iperf3测试结果正常但实际应用仍然慢时，就去查应用依赖的其他资源（磁盘IO、CPU、内存、应用本身的并发能力），不要继续在网络里绕圈子。

7. 让iperf3结果更可信的进阶选项和容易踩的坑

最后这一章是我自己的经验汇总。iperf3的简单用法谁都看得懂，但要让它在不同环境下都能给出可信的结果，有几个细节值得注意。

7.1 结果不准的常见原因和排查顺序

我对“iperf3测出来不准”的求助信息做过简单统计，大部分问题集中在以下几类，按出现频率排：

防火墙这个坑是最常见的，尤其Windows上跑了服务端却没人放行入站规则。不要在防火墙上长期关闭防护，但要确认你要测试的机器上的5201端口（TCP和UDP）处于放行状态。云服务器还要记得在安全组规则里放行。

另一个容易忽略的坑：不要把 iperf3 -s 跑在无线链路上当服务端，除非你特别想测“无线服务端的能力”。无线本身波动大，会把有线链路的问题掩盖掉。我的习惯是，凡是测有线路由或交换机，服务端和客户端都尽量先接网线，再跑测试；测无线时再把其中一个节点换成无线设备。

7.2 几个值得常开的选项：零拷贝、CPU亲和性与拥塞控制

如果你的设备性能本身不够强（比如用软路由、树莓派、NAS跑iperf3服务端），在大带宽打流时CPU会成为瓶颈，导致结果虚低。此时可以开这些选项：

iperf3 -c 192.168.1.10 -Z # 零拷贝模式，减少内存复制开销 iperf3 -c 192.168.1.10 -A 2 # 绑定CPU核心2，避免多核调度带来的抖动 iperf3 -c 192.168.1.10 -C cubic # 指定拥塞控制算法

-Z 在Linux下效果明显，实测100Gbps级别的打流时能大幅降低CPU占用，日常千兆环境开了也不会出错。-A 适合在多核服务器上固定iperf3到某个核心，防止它被调度到不同核心引起结果抖动。 -C 可以临时切换拥塞控制算法（比如cubic、reno、bbr），用于对比“不同算法下链路吞吐的差异”，在长肥网络里bbr往往比cubic更能吃满带宽，但也更激进，正常业务慎用。

我个人最常用的完整命令组合是：

iperf3 -s # 服务端默认监听就行 iperf3 -c 192.168.1.10 -i 1 -t 60 -P 4 -R # 客户端下行60秒、4条流、每秒输出

如果是UDP打流：

iperf3 -c 192.168.1.10 -u -b 100M -i 1 -t 60

还有几个实用小工具配合使用：iperf3支持 -J 输出JSON格式结果，方便程序解析；--logfile 可以把结果同时写入文件。自动化巡检时，把服务端部署在核心设备旁边，定时跑脚本收集数据，比人工现场测试高效得多。

最后分享一个我自己常用的部署思路：我会在家庭网络的核心交换机旁放一台小主机（或者直接用软路由）跑iperf3服务端常驻；手机和笔记本上各装一个iperf3客户端。这样无论什么时候怀疑网络有波动，直接掏出手机点两下，就能测出当前链路的状态。遇到过几次无规律卡顿，都是靠这种机动测试在一分钟内定位到具体链路的。网络性能测试这个事，工具链不在多，关键是手边随手能用起来。