iperf3网络性能测试实战：带宽、丢包率与故障排查全解

1. 为什么你的测速结果总是不靠谱：iperf3能解决什么问题

大部分人第一次接触iperf3，都是被逼的。公司网络升级了带宽，运营商说给了千兆，结果实际下载大文件时速度死活上不去；或者说好的内网万兆，日常拷贝数据却只有两三百兆；再或者视频会议频繁卡顿，交换机厂商和服务器厂商互相甩锅，谁都说是对方的问题。这时候你需要一个能把网络性能量化出来的工具，iperf3就是圈子里的通用语言。

iperf3是一个开源的网络性能测试工具，它的核心能力就两件事：制造流量和测量流量。在一台机器上跑服务端，另一台跑客户端，客户端主动往服务端灌数据，测试完成后给出带宽、丢包率、延迟抖动等关键指标。它不依赖任何图形界面，纯命令行操作，跨平台支持Windows、Linux、macOS，甚至路由器固件里都有集成版本。正因为轻量、标准、结果可复现，它成了网络工程师、运维人员、云厂商验收链路时事实上的行业标准。

我见过很多刚接触iperf3的人，第一反应是“这不就是个测速软件吗，跟Speedtest有什么区别”。区别非常大。Speedtest测的是你到运营商节点的速度，中间跨越了公网上无数未知设备，结果只能代表“你家的网络到某个节点大概怎么样”。但iperf3是两台指定机器之间的点对点测试，你可以完全控制链路两端，中间经过了哪些交换机、哪些光纤、哪些防火墙，全都心里有数。这意味着它能帮你定位问题到底出在哪一段：是服务器网卡不行，是交换机端口协商失败，还是光纤衰减太大，或者是防火墙的会话限制把流量掐了。

还有一类人拿它当压力工具用。iperf3可以指定并发流数、测试时长、缓冲区大小，甚至故意用UDP协议以固定速率灌流量，观察链路什么时候开始丢包。这本质上就是在做链路极限压力测试，很多机房在割接、扩容之后，都会用iperf3先把链路打一遍，再让业务上线。从这个角度说，iperf3是网络验收、故障排查、性能调优三板斧里最趁手的那一把。

这篇文章我不打算写成man page的中文翻译，那样你翻文档就行，不必看我废话。我会按照实际使用中从易到难、从带宽到丢包的路径，把核心参数、使用场景、典型坑点一次性讲透。内容覆盖Linux下的部署安装、TCP和UDP两种测试模式的差异、如何解读测试结果、以及一套完整的排障思路。新手照着敲命令就能跑通，老手也能在细节里找到一些值得留意的点。

2. 环境准备与iperf3安装部署：比你想的更简单，但也别踩版本坑

2.1 服务端与客户端的角色划分

iperf3采用典型的C/S架构。所谓服务端，就是等待连接、接收流量的一端，运行命令是iperf3 -s，默认监听5201端口。所谓客户端，就是主动发起流量的一端，运行命令是iperf3 -c 服务端IP。这个角色划分一定要先搞清楚，因为很多人第一次测试失败，就是两台机器上全都启动成了服务端，谁也连不上谁。

有个容易混淆的点：服务端和客户端只是测试发起方不同，不代表服务端就是“服务器”。如果你想测试两台普通PC之间的网线直连速度，任意一台当服务端都可以。另外，iperf3的流量方向是“客户端主动发送”，所以如果你想测双向速率，需要加-R参数让客户端反过来下载。后面会详细讲。

2.2 Linux环境下的三种安装方式

在Linux上部署iperf3基本有三种途径：包管理器安装、源码编译安装、容器化部署。我个人建议优先用包管理器，除非你的系统版本太老、仓库里的iperf3版本过旧，或者需要特定构建选项。

Debian/Ubuntu系列：

apt update && apt install -y iperf3

CentOS/RHEL/Fedora系列：

yum install -y iperf3 # 或者新版本的dnf dnf install -y iperf3

需要注意的一个坑：CentOS 7自带的源里默认没有iperf3，需要先装EPEL源：

yum install -y epel-release yum install -y iperf3

如果你需要源码编译安装，我建议去官网下载稳定版，不要用GitHub上的master分支，有些中间版本存在已知的统计口径问题。编译安装的步骤很简单：

wget https://downloads.es.net/pub/iperf/iperf-3.14.tar.gz tar xf iperf-3.14.tar.gz cd iperf-3.14 ./configure && make && make install ldconfig

源码编译的主要好处是可以自己加编译参数，比如静态编译、启用调试模式。但对于绝大多数测试场景，包管理器安装已经完全够了。

2.3 防火墙与端口放行：90%的连接失败都出在这里

装好之后，第一件事不是立刻开测，而是确认防火墙。很多人在内网两台机器之间跑iperf3，客户端一直报unable to connect to server，排查半天发现服务端程序没问题、IP能ping通，最后才反应过来是防火墙把5201端口拦了。

服务端需要放行TCP和UDP的5201端口，因为iperf3的默认测试模式是TCP，但UDP测试模式同样走5201端口。

# 对于firewalld firewall-cmd --permanent --add-port=5201/tcp firewall-cmd --permanent --add-port=5201/udp firewall-cmd --reload # 对于iptables iptables -A INPUT -p tcp --dport 5201 -j ACCEPT iptables -A INPUT -p udp --dport 5201 -j ACCEPT

还有一个大家容易忽略的地方：如果服务端机器有多个网卡，iperf3默认绑定在0.0.0.0所有接口上，但有的版本在某些系统上会有差异。稳妥起见，可以在服务端显式指定绑定地址：

iperf3 -s --bind 0.0.0.0

在实际测试多网卡机器的时候，也可以用--bind指定只监听某个特定IP，这样能排除其他网卡的干扰。

注意：iperf3的默认端口是5201，但如果这个端口被占用，可以通过-p参数指定其他端口。两端都必须带上相同的-p值，否则根本连不上。

2.4 版本兼容性：为什么客户端和服务端版本不一样会出诡异问题

iperf3的版本兼容性是个老生常谈但必须强调的问题。它的设计思路是：客户端和服务端的主版本号必须一致。也就是说，3.x的客户端可以连3.x的服务端，但2.x和3.x之间不兼容。原因很简单，iperf2和iperf3的作者不是同一拨人，协议格式完全不同。

即便都是3.x版本，如果双方版本差距过大，也可能会出现一些不太容易察觉的问题，比如新版本增加了一些参数，老版本服务端不支持；或者新版本修复了某些统计口径的bug，导致同一链路的测试结果在两个版本下有差异。我遇到过的真实案例：一台机器的iperf3是3.1.3，另一台是3.14，跑UDP测试时，老版本那端的丢包率统计明显偏高，换了相同版本之后再测就恢复正常了。

所以我的建议是：测试之前在两台机器上分别执行iperf3 --version确认版本，尽量保持一致。特别是长期维护的服务器集群，建议把iperf3的安装包固化到自动化部署脚本里，避免每次装出来的版本都不一样。

3. TCP带宽测试实战：从默认参数跑到多线程参数调优

3.1 第一次跑通TCP测试：默认参数解读

安装完成、防火墙放行之后，就可以开始第一次测试了。假设服务端IP是192.168.1.10，在服务端执行：

iperf3 -s

在客户端执行：

iperf3 -c 192.168.1.10

默认情况下，iperf3会跑10秒钟的TCP测试，然后输出一份汇总报告。先看一个典型的输出：

Connecting to host 192.168.1.10, port 5201 [ 5] local 192.168.1.20 port 45234 connected to 192.168.1.10 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 113 MBytes 948 Mbits/sec [ 5] 1.00-2.00 sec 112 MBytes 940 Mbits/sec [ 5] 2.00-3.00 sec 113 MBytes 948 Mbits/sec ... [ 5] 0.00-10.00 sec 1.10 GBytes 946 Mbits/sec

这里最关键的一行就是最后一行汇总：946 Mbits/sec表示这10秒钟的平均带宽。每次测试结束后，服务端也会输出一份同样的报告，方便你从两端确认数据一致。

你可能会问：为什么我的是千兆内网，测出来只有946M而不是1000M？这是正常的，因为千兆以太网的理论速率是1000Mbps，但TCP/IP协议头、以太网帧头都会占用一部分开销，实际有效载荷速率通常在940M-960M之间。同理，万兆网卡测出来通常在9.4G-9.6G左右。如果测出来只有八九百兆甚至更低，才说明有问题。

3.2 加大测试时长和并发流数：不要只看10秒的成绩

默认的10秒测试其实偏短，特别是对于长肥网络（高带宽高延迟链路），TCP的拥塞窗口需要时间爬升，10秒可能还没完全跑到峰值。我通常在业务上线验收时用-t 30甚至-t 60，让测试时间更充分。

iperf3 -c 192.168.1.10 -t 60

还有一个更重要的参数是-P，它代表并发连接数。默认情况下iperf3只建立一条TCP连接，但实际业务往往是多线程并发访问的。单条TCP连接的性能受限于TCP窗口大小、系统缓冲区配置、甚至CPU单核处理能力，并不总能跑满链路。用-P 4或者-P 8可以让iperf3建立多条并行连接同时灌流量，更接近真实业务场景。

iperf3 -c 192.168.1.10 -t 30 -P 4

注意：-P参数增加的是独立的TCP连接数，每条连接都有独立的端口和缓冲区。当并发数增加后带宽提升，说明单条连接有瓶颈；如果并发数增加了带宽仍然上不去，那瓶颈很可能在更底层的链路或者网卡本身。

我习惯的做法是分别测试-P 1、-P 4、-P 8三组数据，记录对比曲线。如果-P 1是900M，-P 4是940M，差异不大说明单连接就能跑满；如果-P 1只有300M，-P 4能到900M，那就说明单TCP连接确实存在窗口或CPU瓶颈，需要去查系统参数或者网卡多队列配置。

3.3 反向测试与双向测试：链路的不对称性比你想象的常见

默认的测试方向是客户端发数据给服务端。但很多网络环境的上行和下行链路质量并不一样，尤其是跨运营商、跨地域的专线，或者接入了负载均衡设备的场景。所以完整的验收流程一定包含反向测试。

# 反向模式：服务端向客户端发送数据 iperf3 -c 192.168.1.10 -R

-R是Reverse的缩写，翻转数据方向。还有一种情况是同时测双向：

iperf3 -c 192.168.1.10 --bidir

--bidir会让两端同时向对方发送数据，模拟的是真实业务中上下行同时有流量的场景。跑双向测试时总带宽一般会低于单向测试的带宽，因为链路是共享的。如果双向测试时总带宽严重下降，或者一端几乎被饿死，那很可能链路上存在半双工设备或者明显的队列竞争。

3.4 指定传输时长与报告间隔：输出更适合分析的日志

默认的输出是每秒一行，测试结束再给一个汇总。这在实际使用中其实不太够用，因为你需要观察带宽的波动趋势，而不是只看一个平均值。推荐两个参数组合使用：

iperf3 -c 192.168.1.10 -t 30 -i 1

-i是间隔，-i 1表示每秒输出一行，-i 0表示只在结束输出汇总。如果你想看每一秒的带宽值是否稳定，把输出重定向到文件里，之后用Excel或Python画个趋势图，比盯着屏幕刷数字有说服力得多。

iperf3 -c 192.168.1.10 -t 30 -i 1 > tcp_test_result.txt

在分析日志时，我特别关注的是中间是否有掉坑：如果这30秒的逐秒数据里，有某几秒带宽骤降到一两百兆，随后又恢复，哪怕平均带宽看着还行，链路质量也值得警惕。这种瞬时波动在业务上的表现就是“偶尔卡顿一下”，非常影响体验。

3.5 调整发送缓冲区：TCP window相关的疑难杂症

深入一些的TCP调优，会用-w参数指定TCP窗口大小。这个参数等于告诉系统“我要这么大”的接收缓冲区或发送缓冲区，系统会结合net.core.rmem_max等内核参数做最终决策。在长肥网络下，窗口太小会严重限制吞吐量。

iperf3 -c 192.168.1.10 -w 1M

窗口大小的设置有一个经典的计算公式：带宽延迟积。TCP的理论最大吞吐量 = 窗口大小 / RTT。如果RTT是10ms（跨城市的专线常见值），窗口只有64KB，那理论最大吞吐量就是64KB/10ms约等于52Mbps，根本没有余量跑满千兆。这时候把-w调大到1M甚至4M，效果立竿见影。

不过要提醒一句：-w只影响iperf3这条连接的系统缓冲区申请，如果你要在业务上复现这个性能，需要在应用层或者系统层做同样的配置，只把iperf3调好没有意义。

还有个常见问题是CPU瓶颈。iperf3是单线程模型，跑在单核上，万兆速率对CPU的占用率不低。如果服务端CPU主频不高，或者单核性能弱，实测速率会先顶到CPU上限而不是链路上限。判断方法很简单：测试时用top看iperf3进程的CPU占用，如果已经接近100%，那链路的真实能力可能比测出来的更高。这时候要么换更好的CPU，要么用-P多连接模式把负载分散到多核上。

4. UDP测试与丢包率分析：被大多数人忽视的重度场景

4.1 为什么要用UDP来测：带宽和丢包率同时抓在手里

TCP测试虽然最能反映真实业务的表现，但它有一个天然的缺陷：TCP有拥塞控制，发现丢包会自动降速重传，所以你看到的最终速率是“被TCP协议修正过之后的结果”，而不是链路的真实承载能力。这就像一辆车在堵车的路上行驶，你测出来的是平均时速，而不是它最高能开多快。

UDP测试则完全不同。iperf3在UDP模式下按固定的速率发包，不管链路吃不吃得下，我照发不误。这样一来，如果链路带宽不够，或者设备丢包严重，立刻就能从“发送速率”和“接收速率”的差值、以及接收端的丢包率数字上看出来。

UDP测试的典型场景包括：

• 视频会议、VoIP语音、直播推流这类对延迟和丢包敏感的应用
• 链路验收时需要确认设备的线速转发能力
• 定位TCP测试结果不佳时，区分是“链路丢包导致TCP降速”还是“TCP参数配置不合理”

4.2 UDP测试的命令和关键参数

UDP测试需要显式指定协议和带宽上限：

iperf3 -c 192.168.1.10 -u -b 1000M -t 30

其中-u表示使用UDP协议，-b 1000M表示以1000Mbps的速率发送数据，-t 30表示持续30秒。UDP模式必须指定-b，因为UDP没有拥塞控制，你不限制速率，它会直接打爆链路，思科交换机都扛不住这种广播风暴式的流量。

-b的值怎么定？我建议先做一个预估：如果你要验证千兆链路，-b 1000M；验证万兆，就是-b 10000M。如果你不确定链路到底能跑多少，可以先从低往高扫：分别测-b 500M、-b 800M、-b 1000M，看丢包率随速率上升的变化曲线。丢包率开始大幅上升的那个速率点，大致就是链路可靠承载的极限。

4.3 读懂UDP结果里的关键数字

UDP测试的输出格式跟TCP不太一样，典型的报告长这样：

[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 1.17 GBytes 1002 Mbits/sec 0.021 ms 0/154282 (0%)

这里每一列的含义依次是：测试区间、传输数据量、实际接收速率、抖动、丢包数/总包数及丢包百分比。

重点关注三件事：接收速率、抖动、丢包率。

接收速率如果远低于发送速率（-b指定的值），说明链路出现了拥塞丢包。抖动值代表的是数据包到达时间间隔的方差，单位是毫秒，这个数值对视频会议和VoIP影响很大，一般网络条件下抖动在0.1ms以内算优秀，超过1ms就需要关注了。丢包率是核心指标，0%丢包是最理想状态，低于0.1%基本可接受，超过1%就必须定位问题。

4.4 丢包率持续存在时的排查思路

丢包是不可接受的，但丢包的根因可能不止一个。根据我的经验，按照以下顺序排查能省不少事：

第一，先看物理层。光模块和光纤衰减是内网环境里最常见的问题。损耗过大的光路会导致光模块接收功率低于灵敏度阈值，产生间歇性丢包。在交换机上检查光模块的收发光功率：

# 以华为设备为例 display interface transceiver # 思科设备 show interface transceiver

第二，看端口协商状态。如果对端一个千兆一个百兆，或者自协商失败导致端口速率异常，握手时就会丢包。用ethtool eth0检查两端速率和双工模式是否一致。

第三，看链路聚合。如果链路是多个物理口聚合在一起的（比如2个千兆口做LACP），流量哈希算法可能导致流量不均，某个成员口打满而另一个空闲，这时候丢包率会随着测试速率上升而恶化。检查聚合口各成员口的流量分布能很快确认这个原因。

第四，看CPU软中断。某些低端交换机的转发能力达不到标称的线速，或者开启了ACL、QoS等特性后转发性能进一步下降，遇到大流量时CPU过载，只能丢包。这类问题很难通过配置解决，只能更换硬件或者简化策略。

4.5 UDP测试的参数细节：包长、时长与流量模型

UDP测试还有一个经常被忽略的参数是包长。-l参数可以指定数据包大小，默认是1460字节（对应TCP的MSS），这是最接近TCP业务的包大小。但如果你的真实业务是VoIP这类小包场景，默认参数就不太能反映真实情况，可以把包长调成更小的值来测试：

# 模拟小包场景，每个包64字节 iperf3 -c 192.168.1.10 -u -b 100M -l 64 -t 30

包长越小，单位时间需要转发的包数就越多，对设备转发能力的考验就越大。有些设备的丢包率在做大包测试时完全正常，一旦换成小包测就原形毕露，因为小包PPS已经超过了设备的转发上限。这个知识点在做防火墙、路由器这类应用层设备验证时尤其管用。

5. iperf3参数详解与进阶技巧：带宽测试的正确打开方式

5.1 完整参数地图：高频参数与冷门参数分类

网上关于iperf3参数的资料很多，但绝大多数是man page的中文翻译，没有重点和场景分类。我按照实际使用频率整理一份自用的参数表：

有个容易被忽略但非常好用的参数是-O，全称是omit。它的作用是跳过测试开始前N秒的数据不统计。TCP建立连接后带宽爬升需要时间，尤其是高延迟链路，前几秒钟的速率往往偏低。如果不排除这段时间，平均值会被拉低，掩盖链路的真实能力。

iperf3 -c 192.168.1.10 -t 30 -O 5

上面这个命令的意思是：总测试时长30秒，但前5秒的数据不计入最终统计。相当于实际有效统计时间是25秒。

5.2 如何控制iperf3的CPU占用：避免测试工具本身成为瓶颈

这里补充一个非常实用的经验：iperf3默认是单线程的，但加上-P之后，每条流会占用一个线程，多核CPU可以并行处理。不过有时候你只是想让iperf3跑满带宽，而不是跑满CPU，这时候建议用taskset或者nice控制进程的CPU亲和性和优先级。

# 将iperf3客户端绑定到CPU核心0运行 taskset -c 0 iperf3 -c 192.168.1.10 -t 30

在万兆测试场景下，这个技巧很实用：如果iperf3进程被调度到了某个繁忙的核心上，速率容易波动，绑定一个空闲核心可以让结果更稳定。这个经验在虚拟机环境里尤其重要，因为虚拟机的虚拟CPU可能被宿主机的其他负载抢占。

5.3 测试结果的可信度判断：一份结果应该包含哪些信息

跑完测试，我一般会在测试记录里写清楚以下信息，否则几天后回看数据，根本看不懂当时测的是什么条件：

• 测试时间、测试人员
• 两端机器的IP、网卡型号、驱动版本
• iperf3版本号
• 协议（TCP/UDP）、测试时长、并发数、缓冲区大小
• 测试方向（正向/反向/双向）
• 交换机型号、端口速率、光模块收发光功率
• 最终结果：带宽值、丢包率、抖动

这样一份记录，不只是给自己看，也是在跟运营商或设备厂商扯皮时拿得出手的证据。网络问题的定责，大多数时候看的就是谁拿得出规范的测试报告。

5.4 结果波动大时怎么判断：重复性与一致性比单次值更重要

单次测试的数值没有太大意义，因为网络环境是动态的。我自己的习惯是：同一组参数至少测三次，取中间值或平均值，再记录最大最小值作为波动范围。如果三次结果差距在5%以内，说明链路稳定；如果差距超过20%，说明链路上有明显的干扰因素，需要进一步排查。

bash的for循环写出来的批量测试脚本很实用：

for i in 1 2 3; do iperf3 -c 192.168.1.10 -t 30 -i 1 >> result_${i}.log done

另外，如果你的测试场景是隔段时间跑一次、观察长期稳定性，可以直接在crontab里挂一个定时任务，让iperf3定期执行并把结果写到带时间戳的文件里，这样积累几天的数据之后，链路质量的变化趋势一目了然。我发现不少机房在割接后“感觉网络不太稳”但说不出具体证据，用这个方法积累数据，很快就能定位到是某个时段、某个方向上的问题。

6. 常见错误与踩坑实录：我用iperf3踩过的那些坑

6.1 端口被防火墙拦截：connection refused与timeout的区别

客户端连接服务端失败，通常有两种报错。Connection refused说明网络能通、端口被拒绝，一般是服务端没启动、或者服务端监听的端口跟客户端请求的不一致。Operation timed out说明数据包发出去后石沉大海，大概率是中间设备的防火墙把包丢了，TCP握手都没完成。这两个报错的排查路径完全不同：前者查服务端进程和端口，后者查链路防火墙和ACL。

有一种很容易误判的情况：服务端启动时默认只监听IPv4的0.0.0.0，但有些新版本还会同时监听IPv6的::，客户端如果解析域名拿到了IPv6地址，连接的是IPv6端口，而防火墙只放行了IPv4规则，也会出现超时。解决办法很简单：客户端连接时直接用IPv4地址，或者在服务端用--bind 0.0.0.0显式指定只监听IPv4。

6.2 通过交换机直连与网线直连的结果差异：物理链路的威力

实操中我经常遇到一种情况：两台服务器通过交换机互联，测出来带宽只有600M，但两台服务器用网线直连能跑满950M。这种差异基本说明问题出在交换机这一层。可能是交换机端口配置了限速策略、开了QoS队列、或者级联口带宽不够被流量打满。

排查思路是分层剥离：先用直连网线确认两端网卡本身没问题，再把交换机接入链路逐步增加，从“A直连B”到“A接交换机接B”，每次就增加一个变量。这个方法虽然笨，但最可靠，能精确定位瓶颈在哪一跳上。

6.3 网卡协商错误：千兆网卡只跑出百兆速率

这类问题在物理服务器上很常见。服务器网卡和交换机端口之间如果自协商失败，可能会降到百兆甚至十兆模式。用ethtool eth0一看，Speed: 100Mb/s，一切解释都通了。这种问题通常跟网线质量有关：劣质网线或者是网线过长（超过100米），就会导致自协商失败降级。

还有一个隐蔽的变种：服务器是千兆网卡，交换机端口是千兆，但中间的跳线或者配线架上有一段是百兆的线序，或者某根线的线对接触不良，导致物理链路只能工作在100M。这种问题用光看配置很难发现，必须物理层检查。

6.4 iperf3服务端被异常终止：端口占用与僵尸进程处理

测试过程中如果要中断，直接按Ctrl+C就行。但有的时候服务端进程会因为各种原因没有被正确回收，或者你可能开了很多个服务端实例，端口被占用。启动新服务端时就会看到bind failed: Address already in use。

处理方法：

# 查找占用5201端口的进程 lsof -i :5201 # 或者 ss -tulpn | grep 5201 # 强制结束 kill -9 <pid>

一个更稳妥的做法是给服务端加--one-off参数，这个参数会让服务端在接受一次客户端测试后自动退出，避免长时间挂在那里占着端口。适合批量自动化的场景。

6.5 测试结果忽高忽低：网卡多队列与中断绑定的调整

万兆测试时如果带宽结果忽高忽低，不像千兆那么稳定，我第一个怀疑的就是网卡中断没有做负载均衡。默认情况下，网卡的中断可能都集中在一个CPU核上处理，单核处理不过来就会出现瓶颈，速率上上下下地波动。解决方法是在支持RSS（Receive Side Scaling）的网卡上开启多队列，并用irqbalance或者手动把不同队列的中断绑定到不同CPU核心上。

# 查看网卡队列数 ls /sys/class/net/eth0/queues/ # 查看当前中断分布 cat /proc/interrupts | grep eth0

这不是iperf3本身的配置问题，但却是跑iperf3时最常暴露出来的底层性能问题。我在调优万兆链路时，往往先处理中断绑定，再看带宽结果是否正常，顺序千万别搞反。

7. iperf3在实战场景中的延伸应用：不止是打流工具

7.1 云服务器带宽验收：从EIP到实例规格逐段验证

云服务器用户在测试带宽时，经常遇到“买的100M带宽为什么iperf3只能测出80M”的问题。这通常不是因为云厂商虚标，而是因为没有把测试方法用对。云环境的带宽验证比物理机房复杂，因为流量经过虚拟交换机、宿主机、物理网关，每一层都可能有带宽策略。

我的建议是分三层验证：第一层，用本机回环地址测试实例本身的网络栈性能；第二层，用同一可用区内的两台云服务器内网IP互测，验证VPC内网链路；第三层，用绑定EIP的方式走公网测试，验证公网出口带宽。这样如果结果不达标，能直接定位到是哪一层的问题。

云环境下跑iperf3有个细节：云服务器的带宽策略通常是“突发模式”的，某个时间窗口内允许你超过稳定带宽。测试时要拉长到-t 60以上，看平均速率而不是峰值，因为峰值可能吃的是突发额度。

7.2 家里路由器/软路由的性能测试：设备NAT转发能力实测

很多人折腾软路由或者买高端路由器，想知道NAT转发到底能跑多少，iperf3也能派上用场。拓扑很简单：一台电脑连路由器的WAN口，另一台连LAN口，把WAN口配置成静态IP，然后在两台电脑之间跑iperf3。测出来的速率就是路由器NAT转发的真实性能。

这个测试有一个关键点：两端电脑的子网需要不同，流量才能真正经过NAT。如果两台电脑在同一个子网里，交换机芯片直接给转了，根本没走NAT路径，测出来的结果没有参考价值。我见过有人犯了这个错误还得出“路由器性能一般”的结论，属实冤枉。

7.3 网线质量测试：距离与速率的关系验证

有些人以为千兆网线只要是8芯就能跑千兆，这个认知在短距离内成立，但距离一长就露馅。用iperf3可以做网线质量验证：把两台笔记本用待测网线直连，分别测近距离和长距离（比如接个50米、100米的卷装网线）的带宽和丢包率。如果速率随距离明显下降，说明网线衰减超标，截一段重做水晶头往往能解决。

带宽测试之外，网线质量还可以用专门的线缆测试仪测TDR回波损耗、近端串扰等指标，但iperf3胜在方便、直观，不需要额外设备。用同样的方法也可以验证光纤跳线的质量。

7.4 与类似工具的分工对比：iperf3、qperf、netperf、psping

工具圈里跟iperf3功能类似的还有netperf、qperf等。简单说下我的使用感受：

• netperf更老牌，支持更多测试模式（TCP_STREAM、UDP_STREAM、TCP_RR等），但配置略繁琐，输出格式不如iperf3直观。
• qperf是InfiniBand/RDMA生态的工具，测试RDMA网络的带宽和延迟非常准，但在传统以太网上用起来反而不如iperf3顺手。
• iperf3胜在简单、生态好、文档多，绝大多数场景能覆盖。
• psping是微软出的，主打TCP ping和带宽测试，Windows Server环境下排障用得上，但功能比iperf3简单太多。

选择的原则很简单：多数场景直接用iperf3；RDMA相关的测试用qperf；纯Windows环境图个省事可以用psping做快速带宽判断。

7.5 自动化集成：将iperf3测试嵌入脚本与监控系统

如果网络需要常态化监测，完全可以把iperf3集成进监控脚本。比如在Zabbix或者Prometheus体系里，定时触发iperf3测试，把结果推给监控系统。这样能建立一个链路的长期质量基线，一旦某天的测试结果偏离基线，说明有潜在的物理或配置变化，可以提前处理，不必等到业务报障再去排查。

一个简单思路：用shell脚本每次测试后把Bitrate和Lost/Total解析成数值，通过curl推送到监控API。注意UDP测试结果里丢包率的字段位置可能因为版本不同有偏移，写解析脚本时要先人工确认输出格式。

8. 把带宽和丢包率问题一次讲透：从测试结果反推网络故障的根因

8.1 带宽高但丢包大：链路拥塞或缓冲不足的第一信号

如果你测出高带宽的同时丢包率也高，最典型的解释就是链路拥塞或者设备的缓冲不足。iperf3以某个速率发包，中间设备转发不过来，就会丢包。但有意思的是，在iperf3的输出里，接收端显示的带宽可能是正常的（因为发送端在持续发包，接收端能收多少是多少），但如果丢包率居高不下，说明这条链路并不是所有流量都能被转发。

这种状态对TCP业务的影响是明显的：TCP发现丢包会立即启动拥塞控制，降低发送速率，所以TCP有效吞吐量低于链路理论值。而对UDP业务来说，丢包直接表现为画面花屏、语音断续、数据缺失。

遇到这种组合，先降低-b的速率，找到开始丢包的临界点，再结合链路各节点的端口流量统计，判断是哪一段出现了瓶颈。如果降低速率后丢包消失，基本可以确定是拥塞问题；如果速率很低时丢包依然存在，优先怀疑物理链路。

8.2 带宽低但丢包不高：TCP参数或应用层限制的可能性更大

反过来，如果TCP测试速率不理想，但UDP测试丢包率很低，说明链路本身是通的、带宽余量也够，问题大概率出在TCP协议栈的配置上。经典的案例是：服务器默认的TCP窗口过小，或者启用了某些保守的拥塞控制算法，导致单连接吞吐上不去。

全网net.ipv4.tcp_rmem和net.ipv4.tcp_wmem配置偏小时，iperf3用-w调大窗口能测出好成绩，但真实业务不改内核参数就跑不上去。这类问题在跨地域的长肥网络中尤其明显。可以检查两端Linux服务器的内核参数，把TCP缓冲区上限适当调大，再试一次。如果还是上不去，再考虑并发数或者CDN、负载均衡等中间层的限制。

8.3 单向正常、另一向异常：不对称链路与设备策略的排查重点

正向测试正常、反向测试很差的场景，比你想的更常见。造成不对称的原因包括：光模块的发送和接收光功率不一致、运营商专线的上下行带宽分配不同、交换机上只在某个方向上应用了QoS策略、或者是流量的哈希不均导致聚合口的某一侧拥塞。

排查时先确认两端光纤的收发光功率是否都在正常范围内，再看交换机接口的入方向和出方向的丢包计数是否对称。很多交换机在接口上同时统计input errors和output errors，如果只有output方向持续计数，说明问题在出方向的链路上。

8.4 多跳链路下的逐段定位：iperf3分段测试方法论

当两个节点之间的链路跨越多个设备和线路时，单纯测两端无法定位问题在哪一段。我的做法是“逐段测试”：从A测到最近一跳的设备，再测到再远一跳的设备，像切洋葱一样一层层剥开。这个过程很繁琐，但也是最可靠的。

比如A要通过两个机房的路由器到达B，链路是A - R1 - R2 - B。我依次跑这几组测试：A到R1的loopback地址、A到R2的loopback地址、A到B。哪一段的结果明显差，问题就锁定在哪一段。如果你对某几条链路有权限，还可以在中间设备上用tcpdump同时抓两端的包，比对同一时刻的TCP序列号，精准定位丢包发生在哪个设备上。

提示：iperf3测试时建议在两端同时抓包（tcpdump -i eth0 -w test.pcap），即使测试结果正常，抓包数据也能作为链路质量的旁证。在跟设备厂商开Case时，这份pcap比命令行输出更有说服力。

8.5 从带宽测试到延迟测试：补充ping的结果才能还原链路全貌

iperf3主要测带宽和丢包，但延迟和抖动的数据也有参考价值。UDP测试报告里的Jitter就是抖动指标，但如果你想更全面地评估链路质量，建议配合ping工具使用。

长ping配合iperf3是标准的链路体检组合：先ping几百个包统计平均延迟、最大延迟、丢包率，再跑iperf3的TCP和UDP测试。如果ping的延迟稳定在1ms以内，但iperf3的UDP测试抖动有几十毫秒，说明链路上存在排队延迟，可能是有周期性的流量突发挤占了带宽。如果ping的不稳定值和iperf3的丢包率同时上升，基本可以断定链路质量问题而非设备配置问题。

我个人习惯是把这些测试结果整合到一份文档里，格式大致是：链路拓扑、ping统计、iperf3 TCP结果、iperf3 UDP结果、结论和建议。每次排障或验收都按这个模板走，效率和说服力都高很多。