做网络运维这么多年我见过太多类似的争论传输大文件慢业务部门说是带宽不够带宽运营方说 ping 明明很通。两边吵到最后往往都要把 iperf网络性能测试工具拉出来把链路压一遍才收场。iperf 听起来简单一个安装包、一条命令可真正要用得明白、能拿数据说服别人其实有不少门道。这篇文章我按实际工作顺序来写先讲它到底解决什么问题再讲怎么装、怎么跑、怎么读结果然后拆几个真正卡人的进阶参数最后放一段我自己排障的案例和一份防坑清单。默认读者是网络工程师或系统管理员刚入行的同学也可以对着操作里面的坑基本都填着怎么绕开。1. 为什么 ping 通了带宽还是可能出问题很多刚接触网络排障的同事习惯一上来就 ping。ping 基于 ICMP发的是很小的探测报文几毫秒往返一次主要验证的是“链路通不通”“延迟高不高”。它看不到的问题多得是TCP 数据流被限速器卡住、防火墙把大包丢了一部分、交换机端口误码率升高导致大量重传、运营商 QoS 只对某些流量生效——这类问题在小报文为主的 ping 里面几乎不会暴露。反过来说iperf 做的事是“真正搬数据”。它会在一台机器上启动服务端在另一台机器上用客户端建立一条尽量占满链路的 TCP 或 UDP 会话让数据在两端高速流动然后告诉你每秒钟搬了多少 bit有没有重传如果走 UDP 的话还会告诉你丢包了多少、抖动多大。换句话说ping 是量血压iperf 是上跑步机做心肺测试——平时正常的血压不代表你跑一百米后就一定不喘。我经常在项目里把它当“裁判”用。两个部门争论带宽是不是够先把 iperf 架好两端各放一台干净机器跑 30 秒数据摆出来谁都不用吵。它还能当压力源使用做交换机 QoS 规则调整前后的对比、判断新买的网卡是否发挥了一千兆的全部能力、验证某条加密隧道封装后吞吐衰减到什么程度。哪怕是家用场景想确认运营商宣称的 500M 宽带是不是实测 500Miperf 也比网页测速更可控至少它不会被浏览器缓存和 CDN 节点位置干扰。从一个从业者的角度看iperf 的价值不在于“测出多少多少 Mbps 这个数字”而在于“这个数字在什么样的协议、并发、窗口和网络条件下得出来的”。同样一台机器跑出来的结果可能从 300Mbps 到 940Mbps 不等区别往往就是参数没选对。这也是为什么我不太赞成只知道抄一条命令就去生产环境测试的用法——结果不好看时你分不清是链路烂还是参数不合适。要真正用好 iperf脑子里先把两条主线理清一条是 TCP 测试面向吞吐量和重传率适合日常带宽评估另一条是 UDP 测试面向丢包、抖动和限速验证适合语音视频、无线这类对实时性敏感的场景。下面所有内容都围绕这两条主线展开。2. 安装前的四个决策点版本、平台、端口与角色2.1 iperf2 还是 iperf3先回答最容易被忽略的问题版本。iperf 存在两个大版本iperf2 和 iperf3它们默认端口不同参数名也有差异最关键的是两边不兼容。你拿着一台机器跑 iperf2另一台跑 iperf3服务端和客户端根本握不上手。我自己就见过因为版本不统一排障排了半天最后发现两边工具不是同一个人的情况。简单给一张对照表加深印象维度iperf2iperf3默认端口50015201单流 TCP 测试支持支持双向同时测试原生 -d 参数方便需要 --bidir 参数TCP 细节输出较少含 Retr 重传计数、Cwnd 拥塞窗口UDP 测试支持输出较简支持报告更规范化维护状态基本处于维护状态由网络研究团队主导持续更新新项目我基本只用 iperf3。因为它对 TCP 状态信息的输出更完整跑一次就能直接看到有没有重传省得再抓包。只有一种例外当你要对接的老设备或者旧脚本用的是 iperf2 时才需要装 iperf2。两种都装也不冲突分不同端口跑就行只要确保两端不要出现版本不一致的情况。2.2 各平台安装方式一览多数 Linux 发行版自带 iperf3 的软件包。Ubuntu/Debian 系sudo apt update sudo apt install iperf3CentOS/RHEL 系新版用 dnfsudo dnf install iperf3macOS 上最简单的是 Homebrewbrew install iperf3Windows 环境稍微麻烦一点。官方不提供完整的安装包一般是下载免安装的可执行文件解压后直接放在一个目录里通过 cmd 或 PowerShell 运行 iperf3.exe用法和 Linux 端完全相同。注意 Windows 默认防火墙会挡入站服务端跑起来之前先给 5201 端口加放行规则否则客户端那边会一直卡在连接握手阶段。如果公司内网环境不方便用包管理器或者你想给某个特定设备交叉编译源码编译也很直接。依赖主要是 gcc、make 和 OpenSSL 开发库。在 Ubuntu 上大致是sudo apt install build-essential libssl-dev # 下载对应版本的源码包后解压并进入目录 tar zxvf iperf-3.x.x.tar.gz cd iperf-3.x.x ./configure make -j$(nproc) sudo make install建议优先用发行版仓库或官方发布的二进制包。源码编译能让你拿到最新版本但要注意新版参数和旧版本的兼容性比如 3.1 之后新增的某些选项老版本不认识写脚本时容易踩坑。2.3 端口与角色如何分配iperf 是典型的客户端/服务端模型。被测试的那一端比如远端机房启动服务端本地这一端用客户端主动连过去。默认端口是 5201 的 TCP如果你测试的是 UDP握手报文还是 TCP只有真正的数据流变成 UDP。所以防火墙放行时通常要同时放行 TCP 5201 和 UDP 5201。实际项目里我习惯给 iperf 分配一个独立的高位端口比如 5203。因为 5201 是常用默认端口生产环境里可能已经被杂七杂八的服务占掉了也容易被防火墙的默认规则盯上。指定端口就一行iperf3 -s -p 5203客户端对应地加iperf3 -c 192.168.10.5 -p 5203服务端需要长期驻留时别直接用裸终端挂着。SSH 一断iperf 就跟着没了。用 tmux 或 nohup 都行我更习惯 tmux因为重连还能回来看输出tmux new -s iperf iperf3 -s -p 5203至此两台机器已经“有话可讲”了。但先别急着套复杂参数用默认方式跑一轮先把流程走通拿到一个基准数据接下来再谈优化。3. 基础用法全流程让两台机器跑起来3.1 服务端先把它稳稳跑起来服务端很简单一条命令iperf3 -s -p 5203这条命令会创建一个 TCP 监听端口接受客户端请求。我一般再加一个-D变成守护进程或者配合 tmux。不管哪种方式确认监听起来了可以用ss -lntp | grep 5203看到 LISTEN 状态就可以进入客户端环节。如果你是第一次做这个测试建议先找两台机器直连不经过任何中间设备跑一次。这样能先验证工具安装、端口放行和参数使用都没有问题。后面再放到真实链路里才不会一遇到异常数字就怀疑是 iperf 本身有 bug。3.2 客户端从默认参数开始客户端第一次测试就一条命令不要加太多花活iperf3 -c 192.168.10.5 -p 5203 -t 10这里-c指定对端 IP-p指定端口-t指定持续秒数。默认情况下它会做 TCP 测试10 秒结束后输出总结果中途每秒输出一行临时数据。如果你想每秒一行看得更直观加-i 1。如果希望输出单位固定成 Mbps 而不是自动缩放加-f m。我常用的一个稳定版本是iperf3 -c 192.168.10.5 -p 5203 -t 30 -i 1 -f m测试期间要保持两台机器没有其他大流量应用在跑。尤其别开着下载工具、视频会议或者备份任务否则测出来的数字会明显偏低而你根本不知道是谁在抢带宽。3.3 输出报告怎么读跑完后终端最后几行是汇总信息。常见的一个良性结果长这样[ ID] Interval Transfer Bitrate Retr [ 5] 0.00-30.00 sec 3.28 GBytes 939 Mbits/sec 12 sender [ 5] 0.00-30.00 sec 3.28 GBytes 938 Mbits/sec receiver看三个关键位置sender 行和 receiver 行的 Bitrate。两行数值接近说明数据基本都到达对端链路没有明显丢包。如果 sender 远大于 receiver说明链路或中间设备在丢包。Retr 列。表示 TCP 重传次数数值为 0 到几十之间都算正常。如果到几百上千说明链路不稳定、缓冲不足或存在拥塞。Bitrate 绝对值。以 1Gbps 网卡为例实测 930Mbps 左右是正常的。因为以太网帧头、TCP/IP 协议头要占用开销理论最大值大约就是 940Mbps。低于 800Mbps 就值得往下查了。一个小原则第一次用默认参数跑完如果 Bitrate 已经很高说明链路整体健康后面再去压更大压力如果默认参数就不达标先别急着换参数优先检查物理链路、网卡协商、防火墙这类基础项。顺序错了很容易被复杂参数带偏方向。4. 进阶参数拆解从单流到并发从 TCP 到 UDP4.1 并发流 -P为什么单线程跑不满万兆iperf3 默认只建一条 TCP 连接。单条连接受限于 CPU 单核处理能力、TCP 拥塞控制算法以及网络设备对单流的策略在千兆环境通常能跑到 900Mbps 左右在万兆环境一般只能跑到 3-6Gbps。这不是工具的问题而是现实世界的传输层机制。想要压出链路真实上限用-P参数增加并发流数量。每条流都是一个独立 TCP 连接可以分散到多核和多个网卡队列iperf3 -c 192.168.10.5 -p 5203 -t 30 -P 4并发流数怎么定我一般从物理核数的一半开始试比如 4 核机器先跑-P 2再试-P 4。观察每条流的 Bitrate如果各条流差不多说明链路资源被均匀利用如果某条流特别低中间设备做负载均衡时哈希粒度不够这条路径上可能有等价链路没散开。使用并发流时还有个细节服务端默认每个连接会起一个线程处理-P 8以上时服务端 CPU 占用会明显上去。如果你看到 CPU 快满了但带宽还没上去瓶颈就在主机处理能力而不是链路。这时可以加-A把流绑定到指定 CPU 核心上例如iperf3 -c 192.168.10.5 -p 5203 -t 30 -P 4 -A 0,2,4,6不过这个参数要求客户端和服务端 CPU 架构一致且支持亲和性绑定虚拟化环境里经常不生效当作调试手段用就好不必每次都用。4.2 窗口大小与 BDP跨机房延迟更关注的参数TCP 吞吐的一个重要上限是窗口大小。窗口决定了一个包发出后没收到确认前最多可以再发多少数据。如果窗口太小高延迟链路上就会一直“等确认”带宽利用率上不去。估算窗口需求有一个公式带宽bps乘以往返时延 RTT秒再除以 8得到字节数。这个值叫带宽延迟积BDP。举例来说1000Mbps 链路、RTT 1ms理论上只需要 125KB 窗口操作系统默认值轻松覆盖。但如果是一条跨省专线RTT 30ms同样 1000MbpsBDP 就成了 3.75MB默认窗口可能不够。这时候给 iperf3 显式设置窗口iperf3 -c 192.168.10.5 -p 5203 -t 30 -w 4M-w 4M表示收发两端都尝试使用 4MB 的 socket 缓冲区。注意这只是“尝试”最终生效值受系统内核参数net.core.rmem_max和net.core.wmem_max限制设置得比内核上限还大时会被悄悄截断。想知道实际生效值可以在测试输出里找到 Cwnd 列它显示当前拥塞窗口大小能间接反映 socket 缓冲区的真实限制。如果一个 30ms RTT 的专线用默认参数只跑出 200-400Mbps但你发现多并发流能明显提升那多半就是窗口不够。这种情况调大-w往往立竿见影。先算 BDP再设置窗口别凭感觉给一个巨大的数值内核不认时反而会让人困惑。4.3 UDP 测试丢包率和抖动才是重点TCP 自带重传机制链路不稳时它会把吞吐降下来但从结果上不太容易看出网络到底丢了多少包。UDP 不一样发送端按设定的速率往外扔接收端没接到的就是丢了测试结果直接反映链路质量。启动 UDP 测试时服务端不需要加-u客户端指定即可iperf3 -c 192.168.10.5 -p 5203 -u -b 800M -t 30-b 800M表示发送端以 800Mbps 的目标速率向网络发送 UDP 报文。如果链路实际能承载 1000Mbps接收端能看到接近 800Mbps 的接收速率丢包率很低。如果链路只能承载 600Mbps接收速率会到 600Mbps 左右而丢包率会飙升。UDP 测试报告里我最关心三个数字接收速率、丢包率Lost/Total Datagrams、抖动Jitter。抖动是语音视频场景的关键指标一般要求越低越好超过几十毫秒就很容易感知到卡顿。不过要注意iperf3 的抖动计算依赖两端时间同步测试前尽量先让两边服务器用 NTP 对一下时间否则数字失真。还要提醒一句UDP 测试的-b值要谨慎。对着一条 1Gbps 专线如果设成-b 2G发送端会疯狂往网络塞流量结果通常是大量丢包、设备 CPU 高负载甚至影响同链路其他业务。我一般从链路标称带宽的 80% 开始试再按业务需求逐步提高。4.4 反向与双向别忽略上行默认测试方向是客户端发送、服务端接收也就是测的“下行”。但很多链路上下行质量并不对称尤其是经过无线、卫星或运营商限速链路时。最直接的办法是用-R把方向反过来让服务端发、客户端收iperf3 -c 192.168.10.5 -p 5203 -t 30 -R如果想要同时压上行和下行用--bidiriperf3 -c 192.168.10.5 -p 5203 -t 30 --bidir双向测试比两次反向测试更接近真实业务场景因为此时链路同时在两个方向上跑满能看到队列、缓存、双工协商在双向压力下的表现。不过它也是所有测试中最容易影响生产流量的强烈建议放在维护窗口执行。测双向时如果看到上行和下行速率悬殊先别急着下结论。某些防火墙、QoS 设备会对双向流量做额外的策略有些链路聚合组在双向流量下哈希不均也会出现吞吐波动。正确的做法是同一条链路在同样的时段分别用单向、反向、双向各跑一轮对比数字的变化趋势才能定位问题在主机还是中间设备。5. 一次真实链路定位过程从 305Mbps 到 940Mbps前面讲了不少参数可能觉得抽象。这里把我最近一次排障过程完整写出来信息都做了脱敏处理但思路可以复用。背景某公司两处机房之间有一条 1000Mbps 专线业务反馈从总部往分公司同步数据很慢。我在两端各放了一台服务器系统都是干净的 Linuxiperf3 版本一致位于同一网段的直连路由没有经过防火墙。第一步先确认基本连通性和延迟ping -c 10 192.168.10.5结果延迟保持在 0.8ms 左右丢包 0%。看表面链路完全正常。第二步用默认参数做基准测试iperf3 -c 192.168.10.5 -t 30 -f m结果只有 305Mbps。对一个千兆链路来说这个数字低得明显不正常。但我没有立刻怀疑专线本身因为专线标称千兆且延迟正常。我先把服务端和客户端的网卡协商信息拉出来看两端都显示 1000Mbps全双工链路层没有掉速。第三步加并发流iperf3 -c 192.168.10.5 -t 30 -P 4 -f m结果立刻跳到 810Mbps 左右。这说明链路容量本身没问题瓶颈在单条 TCP 流上。那单流为什么只能用三分之一带宽第四步看 TCP 细节。回到单流测试把 Retr 和 Cwnd 输出打印出来iperf3 -c 192.168.10.5 -t 30 -f m -i 1Retr 计数不高Cwnd 也一直在正常范围说明不是丢包导致的拥塞窗口收敛。那问题大概率出在主机侧的中断处理上。我登录服务端检查了网卡中断分布发现所有中断都集中在一个 CPU 核心上多队列没有把流量分散到其他核。第五步调整网卡多队列和相关驱动参数。这里不展开具体设备信息原理是把队列数从默认的 1 扩到 4重新分配中断亲和性让四个队列分别落到四个核上。改完后重新跑单流测试速率从 305Mbps 升到了 710Mbps再跑-P 4直接到 940Mbps和链路理论上限基本吻合。这个案例最大的收获是iperf 能帮你把“链路问题”和“主机问题”分开。如果多流测试能跑满而单流跑不满链路基本是健康的问题在主机协议栈或网卡调优如果多流还是跑不满才更可能是链路或中间设备受限。这个判断顺序比记住任何一条具体命令都重要。6. 实用防坑清单带宽单位、防火墙、网卡协商与测试纪律6.1 先分清 bit 和 Byteiperf3 默认输出的 Bitrate 单位是 Mbits/sec也就是“兆比特每秒”。很多初学的人把这个数值直接当成 MB/s 使用于是 940Mbits/sec 被说成 940MB/s再和实际文件传输速度一对比就觉得有问题。实际上 940Mbits/sec 换算成字节大约是 117.5MB/s这个速度已经非常接近千兆网卡的理论极限。想要输出直接显示字节单位用-f B参数。理解这一点还有个实际意义如果你买的带宽是 1000Mbps 专线那它的理论极限大约是 119MB/s。做需求评估时不要拿 1000 这个数字去乘以任何时间算传输时长要先除以 8否则项目工期预判会差出将近一个数量级。6.2 防火墙与端口冲突服务端启动后客户端连不上最常见的三个原因防火墙挡住了端口、服务端没跑起来、端口被其他进程占用。Linux 下查看端口占用ss -lntp | grep 5203确认服务端监听没问题后再查客户端到服务端端口连通性telnet 192.168.10.5 5203如果 telnet 能通但 iperf3 连不上再用一层nc -vz 192.168.10.5 5203Windows 防火墙的放行规则比较隐蔽有时服务端明明在跑客户端却一直连接超时。在服务端机器上手动加一条针对 TCP 5201 的入站允许规则UDP 5201 也顺手放行测试就不会卡在第一步。6.3 网卡协商、线缆和中间设备设备明明宣称千兆实测只有 90Mbps 左右第一步检查协商结果。用 ethtool 看网卡当前速率ethtool eth0如果显示 Speed: 100Mb/s 而不是 1000Mb/s说明自协商出了问题。换线、换端口、检查水晶头压线顺序都能解决一部分问题。还有一种情况中间串了一个百兆交换机或老旧的光电转换器也会让整条链路降级到百兆这时候 iperf 的数值反而帮你“探测”出了物理链路里的隐性短板。想测全链路最大吞吐时如果网络启用了 VLAN记得把 VLAN tag 开销算进去。1500 字节 MTU 下VLAN tag 要占 4 字节实际有效载荷略有下降。启用巨帧Jumbo Frame到 9000 字节后帧头比例下降吞吐上限会略高一些但前提是整条链路所有设备都支持并且配置一致中途某一段 MTU 小了就会在测试流量压满时放大分片问题。6.4 测试纪律时长、时段、日志与无线环境我见过太多人为了赶时间只跑 3 秒 5 秒然后拿着不代表任何意义的数字去开会。iperf3 客户端在启动后的前几秒要做好 TCP 握手、拥塞窗口爬升测试时间太短测出来的往往是爬坡过程的中间值不是稳定值。我一般至少用 30 秒测持续表现时用 60-120 秒让链路充分进入稳态。测试时段也很重要。生产带宽基本都被业务占用时iperf 结果很难看这时候你吵不过业务。选择维护窗口尽量在没有其他大流量竞争的时间段跑数据才有横向对比价值。同时每次测试都加上iperf3 -c 192.168.10.5 -t 30 --logfile /tmp/iperf_$(date %F).log日志文件里会带上版本信息、时间戳和完整输出方便后续回溯。无线环境则是另一套玩法。Wi-Fi 受干扰、信号强度、AP 负载影响极大单次测试结果毫无意义。把测试时间分成多段至少跑 5 次记录每次的速率取中位数再对比有线接入的结果——差多少就是无线本身丢掉的性能。如果在无线路由器旁边测都很低先检查是否连接到 5GHz 频段、信道是否拥挤、周围是否有同频干扰源再用 iperf 验证思路比单纯反复跑命令有效得多。我自己这些年用下来最大的体会是 iperf 它不复杂难的是把它放进一套可重复、可对比的测试流程里。我每接一个网络项目都会在项目起始阶段把两端机器的系统版本、iperf 版本、测试参数、拓扑图存成一个固定模板后面每次排障都按同一套命令跑。这样出来的数字才能互相比较不然今天加了这个参数、明天换了那个版本最后得到的结论连自己都没办法复现。最后再分享一个小习惯测试完别急着关服务端。把两边的 iperf 进程都留一段时间等到重试或对照实验做完再回收。很多奇怪的网络问题往往是你关掉工具之后才暴露出来的——比如某台机器 CPU 软中断飙升或者设备在流量停止后需要几秒钟才能恢复队列。iperf 只是一个刻度尺尺子本身不值钱值钱的是你会不会用它把问题量出来。
