网络卡顿、丢包、带宽跑不满这类问题几乎每个做运维、做后端、搞弱电布线的朋友都遇到过。排查的时候最怕什么最怕“凭感觉”——用户说慢你 ping 一下延迟正常就不知道从哪下手了。我干了十多年一线见过太多人把网络问题归咎于“交换机不行”“网线太差”结果一测才发现是双工模式协商错了或者某台机器的网卡被限了速。iperf3就是解决这类问题的核心工具它是一款开源的网络性能测试工具专门用来测量两个节点之间的TCP 和 UDP 带宽、延迟抖动、丢包率。它解决的核心问题就一个把“网络慢”这种模糊描述变成“带宽 940Mbps、抖动 0.3ms、丢包 0%”这种可量化、可对比的数据。这篇文章适合谁看刚入行的网络运维、需要验证机房内网质量的开发、做监控布线的工程人员以及任何想搞清楚自己网络到底能跑多快的人。下面我把这些年用 iperf3 的完整流程、参数细节和踩过的坑一次性讲透。1. 网络性能测试的整体设计与 iperf3 选型思路1.1 为什么是 iperf3 而不是其他工具网络性能测试工具其实不少老牌的有 iperf2、netperf还有各种图形化工具。我选 iperf3 作为主力理由很实在。第一它是 iperf 的重写版本代码更精简单线程架构反而让测试结果更干净不会因为多线程调度引入额外噪声。第二它支持 TCP、UDP、SCTP 三种协议尤其是 UDP 打流能力是排查丢包和抖动的利器。第三它的输出格式统一方便脚本抓取做自动化对比。很多人会问为什么不用scp传个大文件测速因为文件传输受磁盘 IO、文件系统缓存影响太大测出来的数字根本不能代表纯网络能力。iperf3 直接在内存里造数据流绕开了磁盘瓶颈这才是“纯网络”测试。还有人用ping测带宽那更不靠谱ping 测的是延迟和连通性跟带宽完全是两码事。打个比方ping 是测“这条路通不通、走一趟多久”iperf3 是测“这条路一小时能过多少辆车”。1.2 测试模型客户端与服务端的分工iperf3 的工作模型是典型的 C/S 架构。一台机器跑服务端-s另一台跑客户端-c主动发起连接。数据流向默认是从客户端发往服务端也就是测“上行”。如果想测“下行”需要用反向模式-R。这个设计很关键因为很多网络问题是不对称的——比如上行跑满、下行拉胯或者反过来。我一般建议在正式测试前先明确测试目标你是要测两台服务器之间的最大吞吐还是要模拟真实业务流量看丢包还是要长时间压测看稳定性目标不同参数组合完全不一样。测最大吞吐就用 TCP 默认参数测丢包抖动就上 UDP 并指定带宽测稳定性就加-t拉长时间。1.3 测试前的环境准备清单在敲命令之前有几件事必须先确认否则测出来的数据全是废的。第一确认两端网卡速率和双工模式一致用ethtool eth0看如果一端是 1000M 全双工另一端是 100M 半双工那测出来必然惨不忍睹。第二确认防火墙放行了 iperf3 的默认端口 5201或者你用-p指定的端口。第三尽量让测试路径上的其他流量降到最低别一边跑备份一边测带宽。第四如果测的是跨机房链路先确认中间没有限速策略。提示测试前用ip a或ifconfig确认用的是哪块网卡多网卡机器上跑错网卡是新手最常见的错误测了半天发现走的是管理口。2. iperf3 部署与参数详解2.1 Linux 下的安装部署实操Linux 上装 iperf3 非常简单主流发行版都有官方源。Debian/Ubuntu 系直接apt install iperf3RHEL/CentOS 系用yum install iperf3或者dnf install iperf3。装完用iperf3 -v验证版本我建议两端版本尽量一致虽然 3.x 之间基本兼容但跨大版本偶尔会有参数不识别的情况。如果官方源里没有或者你需要特定版本那就源码编译。流程是下载源码包、解压、./configure、make、make install。编译前确认装了 gcc 和 make。Windows 端也有编译好的二进制包下载解压后直接在 cmd 或 PowerShell 里跑用法和 Linux 完全一样。macOS 用户用brew install iperf3最省事。2.2 核心参数逐个拆解iperf3 的参数看着多其实常用的就那十几个。我把它们分成几类来讲这样你记起来有逻辑。服务端参数比较简单-s启动服务端-D让它后台运行daemon-p指定监听端口。生产环境我强烈建议加-D不然你 SSH 一断服务就没了。客户端参数是重点。-c指定服务端地址这是必填。-t指定测试时长默认 10 秒我一般测吞吐用 30 秒测稳定性用 300 秒以上。-P指定并行连接数这个参数极其重要后面单独讲。-R反向测试让服务端发数据给客户端。-u切换 UDP 模式。-b指定目标带宽UDP 模式下必填比如-b 100M。-l指定缓冲区大小影响单次读写的数据量。-i指定报告间隔默认 1 秒设成 0 就只在结束时输出汇总。还有几个进阶参数值得记。-w指定 TCP 窗口大小窗口太小会限制吞吐尤其是在高延迟链路上。-M设置 TCP 最大段大小MSS。-N开启 TCP no-delay禁用 Nagle 算法对延迟敏感的场景有用。-4和-6强制走 IPv4 或 IPv6。2.3 参数组合的典型场景对照光记参数没用得知道什么场景用什么组合。我整理了一张表这是我这些年最常用的几套组合。测试目标推荐命令关键说明测 TCP 最大吞吐iperf3 -c 服务端 -t 30 -P 4多连接才能跑满高带宽链路测 UDP 丢包抖动iperf3 -c 服务端 -u -b 100M -t 30带宽要略高于预期实际值测下行带宽iperf3 -c 服务端 -R -t 30反向模式服务端发数据测长时间稳定性iperf3 -c 服务端 -t 600 -i 10拉长时间看有无周期性掉速双向同时测iperf3 -c 服务端 --bidir -t 30需要较新版本支持这张表建议收藏实际工作中 90% 的场景都能覆盖。3. 实操过程与核心环节实现3.1 第一步启动服务端并确认监听在作为服务端的机器上执行iperf3 -s -D -p 5201-D让它后台跑-p 5201是默认端口写出来是为了明确。启动后用ss -tlnp | grep 5201确认端口在监听。如果没监听八成是端口被占用或者权限问题低于 1024 的端口需要 root。我习惯在服务端加--logfile /var/log/iperf3.log把日志落盘方便事后查。注意如果服务端有多块网卡iperf3 默认监听所有地址。想只绑某块网卡用-B指定 IP比如-B 192.168.1.10。3.2 第二步TCP 吞吐测试的完整流程客户端执行iperf3 -c 192.168.1.10 -t 30 -P 4 -i 1这条命令的意思是连到 192.168.1.10测 30 秒开 4 条并行连接每秒报一次。跑完之后看最后几行汇总重点看SUM那一行的sender和receiver带宽。如果 sender 和 receiver 差距很大说明中间有丢包或者接收端处理不过来。为什么用-P 4因为单条 TCP 连接在长肥管道高带宽高延迟上很难跑满受限于窗口大小和拥塞控制。开多条连接能更充分地利用链路。但也不是越多越好我一般从 1 开始逐步加到 4、8看带宽什么时候不再增长那个点就是实际瓶颈。3.3 第三步UDP 打流测丢包与抖动UDP 测试是 iperf3 最有价值的功能之一。命令iperf3 -c 192.168.1.10 -u -b 100M -t 30 -i 1-u切 UDP-b 100M表示以 100Mbps 的速率发包。这里有个关键点-b的值要设成你“期望”的带宽而不是“实际”带宽。比如你测千兆链路可以先设-b 900M如果丢包严重再往下调找到不丢包的临界点。UDP 测试结果里重点看三列Jitter抖动、Lost/Total Datagrams丢包数/总数、Lost百分比。抖动反映的是延迟的稳定性实时音视频业务对抖动极其敏感一般要求小于 30ms。丢包率在理想内网里应该是 0%如果超过 0.1% 就要查了。3.4 第四步反向与双向测试默认数据是从客户端流向服务端。测下行用-Riperf3 -c 192.168.1.10 -R -t 30双向同时测用--bidiriperf3 -c 192.168.1.10 --bidir -t 30--bidir会同时建立两个方向的流输出里会分别标注。这个模式对测全双工链路很有用能看出上下行是否互相影响。我实测下来有些廉价交换机的背板带宽不足单向跑满没问题双向一跑就双双掉速这种问题只有--bidir能暴露出来。3.5 第五步结果解读与数据记录iperf3 的输出分两部分中间的每秒报告和最后的汇总。汇总里sender是发送方统计receiver是接收方统计。TCP 模式下如果两者差异大通常是接收端 CPU 或内存瓶颈。UDP 模式下接收端的丢包统计才是真实丢包。我习惯把每次测试结果存成文件命令末尾加--logfile result.txt或者用-J输出 JSON 格式方便脚本解析。做对比测试时一定要保证两次测试的参数完全一致否则没有可比性。4. 常见问题与排查技巧实录4.1 带宽跑不满的排查思路这是被问得最多的问题。千兆链路只跑出 300Mbps怎么办按这个顺序查先看ethtool确认网卡协商速率是不是 1000M 全双工再看 CPU 占用单核跑满会导致 iperf3 成为瓶颈这时候加-P多连接能缓解然后看中间设备交换机、防火墙有没有限速最后看 TCP 窗口高延迟链路需要加大-w。我踩过的一个坑某次测试怎么都跑不过 500M最后发现是测试机的网卡驱动太老更新驱动后直接跑到 940M。所以别忽略驱动和固件。4.2 UDP 丢包的典型原因UDP 打流丢包先别急着怪网络。第一-b设太高超过了链路实际能力这是最常见的“假丢包”把带宽降下来再测。第二接收端 CPU 处理不过来UDP 没有拥塞控制发多少收多少收不过来就丢。第三中间设备有 QoS 策略对 UDP 限速。第四真的是链路质量问题比如光衰、网线接触不良。排查顺序建议先降带宽确认是否假丢包再看接收端 CPU再查中间策略最后查物理链路。4.3 常见问题速查表现象可能原因排查动作连接被拒绝服务端没启动或端口不对检查-s和-p确认防火墙带宽远低于预期网卡协商、CPU 瓶颈、限速ethtool、top、加-PUDP 大量丢包带宽设太高、接收端瓶颈降-b、看接收端 CPU结果波动大背景流量干扰错峰测试、隔离环境反向测试失败版本不支持或参数错升级版本、检查-R位置4.4 几个容易被忽略的实操心得第一个心得测试时长别太短。默认 10 秒经常受 TCP 慢启动影响前几秒带宽是爬升的10 秒平均值偏低。我一般至少 30 秒重要测试 60 秒以上。第二个心得并行连接数要试。不是越多越好找到带宽不再增长的拐点就行。我见过有人开 32 条连接结果 CPU 先扛不住了。第三个心得测试机本身要够强。用一台老掉牙的机器测万兆纯属自欺欺人网卡和 CPU 都跟不上。第四个心得记录环境信息。每次测试记下时间、两端硬件、系统版本、网卡型号不然过几天回头看数据根本想不起来当时什么条件。5. 进阶用法与自动化测试思路5.1 用脚本做批量对比测试手动敲命令测一两次还行要做多节点对比就得上脚本。我的做法是写个 bash 脚本循环读取节点列表对每个节点跑固定参数的 iperf3用-J输出 JSON再用jq提取关键字段汇总成表格。这样一次能测十几个节点结果一目了然。for ip in $(cat nodes.txt); do iperf3 -c $ip -t 30 -P 4 -J result_$ip.json jq -r .end.sum_received.bits_per_second result_$ip.json done这段脚本的核心就是-J加jq把非结构化的文本变成可处理的数据。5.2 结合监控做长期趋势单次测试只能反映当下想知道网络质量有没有劣化得做长期趋势。我的做法是用 cron 定时跑 iperf3把结果写进时序数据库再用可视化工具画曲线。这样一旦某天带宽突然掉了能立刻定位到时间点结合当时的变更记录排查。5.3 测试结果的合理预期最后说个心态问题。很多人测出来 940Mbps 就慌了觉得千兆链路怎么没跑满 1000M。其实这是正常的TCP/IP 协议头、以太网帧头都有开销千兆链路 TCP 实测能到 940Mbps 左右就是优秀水平。UDP 因为开销小能更接近线速。所以别拿理论值当标准要拿同环境的基线值做对比。我个人在实际操作中的体会是iperf3 最大的价值不是给你一个绝对数字而是给你一个可对比的基准。今天测 900M明天测 600M这个变化才是真正要关注的东西。工具本身很简单难的是测试方法的设计和结果的解读这两点才是区分新手和老手的地方。