ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

iperf实战:从TCP/UDP带宽测试到网络瓶颈排查指南

2026/10/1 3:10:04 拓冰建站 浏览量
iperf实战:从TCP/UDP带宽测试到网络瓶颈排查指南 网速测试到瓶颈后为什么我先上iperf而不是换设备上周帮朋友排查一台新上架的Web服务器应用层怎么压都只有一半带宽网卡、交换机、光模块换了个遍都没解决。最后用iperf做了个端到端吞吐测试才发现问题根本不在应用层而是链路聚合的哈希策略把流量全打到了一个物理口上。这种看起来慢、但不知道哪里慢的案子我基本第一反应就是拿iperf出来测一轮。如果你也在Linux上做运维、搞网络、搭服务迟早会遇到要判断链路到底能跑多快的时刻。浏览器下载速度、speedtest结果都只能代表到某个节点的速度代表不了两台机器之间的真实带宽。iperf就是干这个用的它在你指定的两台设备之间建立一条真实的TCP或UDP数据流老老实实告诉你吞吐量、丢包率、抖动和重传情况。这篇文章我会把iperf2和iperf3的差别、安装方式、TCP/UDP测试的完整操作、以及结果怎么解读一次讲透最后附上我自己排查带宽上不去的完整思路。1. 网速测试到瓶颈后为什么先上iperf而不是换设备1.1 iperf到底能告诉我们什么很多人对带宽测试的理解还停留在speedtest这类工具上。它的逻辑很清楚找一台离你最近的测试服务器建立连接拉数据算速度。但这类测试掩盖了一个关键事实——你的网络是端到端的从本机网卡、交换机、路由器、运营商骨干、对端机房任何一环掉链子最终结果都会变慢。speedtest只能告诉你到测速节点这一段还行却没法告诉你本机和隔壁机柜里另一台服务器之间的链路质量。iperf的思路完全不同。它采用经典的C/S架构一端跑服务端iperf -s一端跑客户端iperf -c 服务端IP然后让数据流真实地穿过两台设备之间的全部链路。测出来的数字就是这两点之间真实能跑到的吞吐量。这个能力让它成了排查网络瓶颈的标准工具之一无论是千兆局域网、万兆数据中心还是跨机房专线都能用它快速测出链路底色。我自己的习惯是在任何一次网络割接、服务器上架、链路扩容之后都跑一轮iperf留个基线数据。这个基线太重要了后面业务一慢拿出当时的记录一对比能省掉大量盲人摸象式的排查时间。1.2 iperf2和iperf3到底该装哪个市面上能装到的iperf主要有两个版本线iperf2和iperf3。它们不是简单的升级关系而是两个并行维护的项目。选错版本在细节参数上会出现命令明明一样行为完全不同的坑。iperf3由ESnet主导开发是目前的主流选择。它重构了代码单线程性能更强在万兆甚至更高带宽下也能跑出接近线速的结果而且新功能基本都优先在iperf3上实现。iperf2则更老牌胜在兼容性极广老系统仓库里普遍有而且它保留了一些iperf3没有的能力比如-d双向同时测试参数。iperf3中想测双向得在两端各拉一个进程或者用-R参数反过来打这是两版之间最容易踩的坑。需要说明的是iperf3为了保证公平性UDP模式默认发送速率被限制在1Mbps左右很多人第一次跑UDP测试发现结果惨不忍睹就是因为没加-b参数指定真实带宽。而iperf2在UDP模式下默认是尽最大努力发包行为差异很大。记住这一点后面实战才不会懵。两版命令不能混用iperf3的客户端连iperf2的服务端或者反过来都连不上因为它们使用的控制协议不一样。我在服务器上一般两个版本都装iperf3做主力测试iperf2留着兼容老环境。2. 三分钟装好并在局域网跑通第一次测试2.1 主流发行版的安装方式Linux下安装iperf非常省事各发行版官方源里都有。Debian/Ubuntu系列apt update apt install -y iperf3 # 如果还想留iperf2做兼容测试 apt install -y iperfRHEL/CentOS/Rocky/Fedora系列dnf install -y iperf3 # 有的老版本源里只有iperf2名称就叫iperf dnf install -y iperf注意一点CentOS 7及更早的默认源里可能只有iperf2装iperf3需要用EPEL源。如果实在装不上直接去官网下载静态编译的二进制包解压就能用依赖很少这是我常用的备选方案。2.2 第一轮测试先摸清链路底色两台机器都装好之后测试就开始了。假设服务端IP是192.168.1.10在服务端执行iperf3 -s默认监听5201端口控制台会打印出等待连接的提示。然后客户端执行iperf3 -c 192.168.1.10默认测10秒TCP。如果只是内网千兆环境你会很快看到每秒上百MB的传输量。这个结果就是两台机器之间TCP传输能达到的吞吐量基线。第一次跑通之后我建议再做一次反向测试iperf3 -R -c 192.168.1.10-R的作用是让服务端往客户端方向打流即反向带宽。很多链路是上下行不对称的或者网卡配置有差异只测单方向会漏掉问题。有一次我排查一台文件服务器正向吞吐正常反向只有正向的三分之一最后发现是对端交换机的光模块协商到了半双工模式——这种问题只测单向根本发现不了。2.3 测试结果每列都代表什么第一次跑完你会看到一大段报告最关键的是最后几行[ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.08 GBytes 928 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 1.08 GBytes 927 Mbits/sec receiver各列含义如下Interval统计的时间区间0.00-10.00表示这10秒的累计数据。Transfer这段时间内传输的数据总量1.08 GBytes。Bitrate平均比特率927 Mbits/sec这个数字才是我们最关心的吞吐量。RetrTCP重传次数等于0说明链路干净大于0就需要警惕重传越多说明网络越拥塞这个数字要重点关注。Cwnd拥塞窗口大小如果显示的话反映TCP流量控制的情况窗口太小会限制速度。总结一下iperf的结果并非分数越高越好而是要结合场景判断。重传率、抖动、丢包这些指标往往比单纯的带宽数字更能说明问题。3. TCP测试实战把单向、双向、多流全测一遍3.1 单向测试确认链路能达到的最大吞吐TCP单向测试是最基础的场景目标很简单给定网络条件下TCP传输最多能跑多快。下面这个命令是我最常用的组合iperf3 -c 192.168.1.10 -t 30 -i 1-t 30把测试时间拉长到30秒-i 1让iperf每秒打印一次即时结果。为什么要拉长到30秒因为TCP有慢启动和拥塞控制机制前十秒可能还在提升窗口阶段测10秒往往拿不到稳定的最大值。尤其是跨运营商、高延迟链路TCP可能要10秒以上才能把窗口撑起来。如果你要压测的是持续稳定传输能力比如文件备份链路时间可以拉到60秒甚至更长。3.2 双向同时测试-d / -R与轮流测试-r实际业务中很多应用是双向通信的比如数据库同步、视频会议。iperf2的-d参数可以在一次测试中双向同时打流而iperf3改用-R参数实现反向测试。两者思路不同-d两端同时互打模拟真实双向并发场景。-R服务端打客户端本质上还是单向但方向反过来了。如果你的iperf3想模拟同时双向有两个办法一是在两端各开一个iperf3进程对打二是先正向测一轮再-R反向测一轮两者结合判断。我的习惯是至少把正向和反向都测一遍因为不少网络设备尤其无线和负载均衡设备对上下行流量的处理能力不对称。3.3 多并行流-P什么时候用单条TCP流能跑多快受限于TCP窗口、往返延迟、协议栈处理能力等多个因素。有时候单流跑不满链路带宽但业务本身是多连接并发这时候用-P参数模拟多流iperf3 -c 192.168.1.10 -P 4 -t 30-P 4表示同时开4条TCP流。多流测试最大的价值是区分链路本身慢和单流性能不足如果-P 4的总吞吐远高于-P 1说明链路余量没问题是单流受限如果多流也提不上去那瓶颈就在链路底层或者中间设备了。注意不要一上来就把-P拉满到几十先2、4、8这样渐进测试够用就行。P值越大对端CPU和内存压力也越大数字反而失真。3.4 控制测试时长和输出间隔-t和-i这两个参数平时不起眼真到排查问题时特别有用。-i 1可以观察每秒的带宽波动如果吞吐量呈锯齿状上下剧烈跳动多半是中间设备在做流量整形或拥塞控制如果是一条平滑的线说明链路状态很稳定。还有一种情况短时间测试正常时间一长就开始掉速。这通常是设备散热、限速策略或运营商QoS导致的时长拉长到300秒-t 300就能暴露出来。我排查过的一个案例就是FTP传大文件传一会儿就卡死iperf短测正常拉到120秒后吞吐开始断崖式下跌最后定位到交换机端口的带宽策略配置问题。4. UDP测试抓出TCP掩盖的丢包与抖动4.1 为什么UDP测试更接近链路真实体质TCP协议自带重传和拥塞控制丢包了会自动重发所以从TCP测试结果里你很难直观感受到链路的丢包率。但实时业务如VoIP、视频会议、直播推流基本都是UDP它们对丢包和抖动高度敏感。iperf的UDP测试正是模拟这类流量直接把丢包率和抖动暴露出来。UDP测试的核心参数是-u和-b。-u切换为UDP模式-b指定发送速率单位可以是10m10Mbps、500m500Mbps等。务必记住iperf3下不指定-b默认只有1Mbps跑出来数字会非常难看这不是链路问题是参数问题。4.2 一次标准的UDP测试怎么做假设我要验证一条带宽为100Mbps的专线能否承载80Mbps的UDP视频流在客户端执行iperf3 -u -b 80m -c 192.168.1.10 -t 30 -i 1服务端会回传一份统计重点关注这几个字段Total Datagrams发送的数据报总数。Lost Datagrams丢失的数据报数。Loss Rate丢包率。Jitter抖动单位毫秒反映数据包到达时间间隔的稳定程度。对实时音视频来说丢包率超过1%就明显影响体验超过5%基本没法用抖动应该控制在几毫秒以内。4.3 结果解读与常见问题判定如果测试结果显示丢包率很高先别急着下结论。我建议按下面的顺序排查确认-b设置是否超过了链路物理带宽。用80m测100Mbps链路应该没问题用500m测100Mbps链路丢包必然严重这属于打过了测试是为了验证是否够用不用每回都奔着极限打。确认中间没有限速策略。比如防火墙或者流量整形设备把UDP优先级调低甚至直接丢弃都会造成Jitter偏高。遇到这种情况我会用iperf逐步加大-b从10m、50m、100m往上试探找到链路能承受的无损UDP速率上限。确认不是误报。有些iperf版本在高带宽UDP测试下会出现数据包计数翻转的问题如果总发包数异常可以加--udp-counters-64bit参数试试。最后才是怀疑物理链路问题。线缆、光模块、弱信号这时候换线换口测试不冤枉。5. 带宽上不去的排查链路从网卡到中间设备的完整思路5.1 第一步先分清是谁慢拿到一份远低于预期的iperf结果别急着调参。我的排查顺序是这样的先在服务端本机测回环排除iperf自身和系统瓶颈iperf3 -s -p 5202 iperf3 -c 127.0.0.1 -p 5202回环测试里网卡和链路都不参与如果连回环都跑不快问题在CPU、内存或iperf版本上。回环正常之后再跑到客户端节点逐跳扩大范围就能一步步圈定故障域。接着看CPU占用。iperf是CPU密集型的工具尤其频繁用-P开多流时。测试时在两端各开一个top或者mpstat观察如果客户端或服务端CPU已经打满那吞吐上不去很可能是性能不够而不是网络问题。传统iperf2单线程跑万兆是很吃力的iperf3在这点上做了很多优化但也架不住小机器硬扛。再确认网卡协商速率。用ethtool查看ethtool eth0重点看Speed和Duplex两行。如果显示Duplex: Half那带宽减半是正常的先把链路协商问题解决再说其他。这类问题在老旧设备、劣质网线上非常常见也是最容易被忽略的。5.2 第二步压测资源瓶颈如果CPU、网卡协商都正常就要怀疑中间链路了。把中间设备全部绕开用一根网线直连两台机器再跑一次iperf。如果直连正常、经过交换机就慢问题定位在交换机配置或端口上。交换机端口的MTU设置不统一、STP收敛后端口阻塞、链路聚合哈希不均都是我实际遇到过的坑。链路聚合哈希不均尤其隐蔽。多块网卡bonding之后流量默认按IP、端口做哈希分布到不同物理口上。如果业务流量集中在同一对IP上哈希就可能把全部流量打到一个口聚合带宽被白白浪费。我之前遇到的情况就是这样应用层带宽只有单口水平但从交换机看到所有物理口都没跑满因为载荷分布严重不均。用iperf加-P多流加多目标IP去压才能把多口都带动起来这也是为什么多流测试在排查聚合链路时是必须做的一步。5.3 第三步窗口调优与进阶参数如果确认链路和物理设备都正常但吞吐依然上不去就到了TCP参数调优环节。最经典的是调整TCP窗口大小iperf3 -c 192.168.1.10 -w 2m-w指定TCP窗口大小2m表示2MB。窗口大小乘以往返延迟基本决定了单条TCP流的最大吞吐量。公式是最大带宽 ≈ 窗口大小 / 往返延迟。如果两台机器延迟是10ms窗口只有64KB那么理论上限就是64KB / 0.01s ≈ 6.4MB/s约51Mbps怎么跑都突破不了。另一种思路是在发送端开启TCP拥塞控制算法比如BBRsysctl -w net.ipv4.tcp_congestion_controlbbr iperf3 -c 192.168.1.10 -C bbr-C参数让iperf使用指定的拥塞控制算法。BBR在高延迟、有丢包的环境下经常能把吞吐拉高一截。不过要注意BBR需要在发送端内核支持且中间设备最好没有严格的QoS策略否则效果也不明显。再补充一个我常用的技巧测到瓶颈后用ping -M do -s 1472测一下不可分片的大包是否通得过判断路径上的MTU是否一致。MTU黑洞导致的丢包iperf的结果通常表现为速度上不去但重传率又没那么高很迷惑人。最后说一个容易被忽略的点防火墙和内核参数。服务器上的iptables/nftables如果开启了连接跟踪高连接数下会消耗大量内存和CPU。测试时可以先systemctl stop firewalld或者ufw disable排除干扰跑通之后再恢复。还有net.core.rmem_max和net.core.wmem_max这类内核缓冲区上限默认值偏小也会限制大窗口TCP吞吐。我自己的固定动作是每台新上架的服务器都做一轮标准iperf测试把命令、参数、结果存成文本放进运维文档里。后面遇到网速突然变慢的工单翻出基线一对比问题范围顿时缩小一大块。最后一个建议是iperf测试用的带宽是有成本的别在业务高峰期做极限压测尤其是跨公网的链路一不小心就会把正常业务挤掉。选业务低峰期从低带宽开始逐步加压拿到你想要的数据就停这工具才能长期为你所用。