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 iperf3CentOS/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-port5201/tcp firewall-cmd --permanent --add-port5201/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的中文翻译没有重点和场景分类。我按照实际使用频率整理一份自用的参数表参数作用使用场景我的建议-s服务端模式接收端启动必用-c ip客户端模式连接指定服务端发起测试必用-uUDP模式链路极限测试按需-b rate指定发送速率UDP/限制速率TCPUDP必须有必用-t sec测试时长长稳测试建议30以上-i sec报告打印间隔观察趋势建议1-P n并发流数多线程压测TCP常用-R反向测试测下行必测--bidir双向同时测试测对称性按需-w size设置TCP窗口长肥网络调优按需-l size设置包长模拟小包业务按需-O sec设置测试启动时忽略前N秒排除TCP慢启动过渡期建议使用-Z设置TCP拥塞控制算法验证算法差异按需有个容易被忽略但非常好用的参数是-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服务端被异常终止端口占用与僵尸进程处理测试过程中如果要中断直接按CtrlC就行。但有的时候服务端进程会因为各种原因没有被正确回收或者你可能开了很多个服务端实例端口被占用。启动新服务端时就会看到bind failed: Address already in use。处理方法# 查找占用5201端口的进程 lsof -i :5201 # 或者 ss -tulpn | grep 5201 # 强制结束 kill -9 pid一个更稳妥的做法是给服务端加--one-off参数这个参数会让服务端在接受一次客户端测试后自动退出避免长时间挂在那里占着端口。适合批量自动化的场景。6.5 测试结果忽高忽低网卡多队列与中断绑定的调整万兆测试时如果带宽结果忽高忽低不像千兆那么稳定我第一个怀疑的就是网卡中断没有做负载均衡。默认情况下网卡的中断可能都集中在一个CPU核上处理单核处理不过来就会出现瓶颈速率上上下下地波动。解决方法是在支持RSSReceive 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简单太多。选择的原则很简单多数场景直接用iperf3RDMA相关的测试用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结果、结论和建议。每次排障或验收都按这个模板走效率和说服力都高很多。
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 iperf3CentOS/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-port5201/tcp firewall-cmd --permanent --add-port5201/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的中文翻译没有重点和场景分类。我按照实际使用频率整理一份自用的参数表参数作用使用场景我的建议-s服务端模式接收端启动必用-c ip客户端模式连接指定服务端发起测试必用-uUDP模式链路极限测试按需-b rate指定发送速率UDP/限制速率TCPUDP必须有必用-t sec测试时长长稳测试建议30以上-i sec报告打印间隔观察趋势建议1-P n并发流数多线程压测TCP常用-R反向测试测下行必测--bidir双向同时测试测对称性按需-w size设置TCP窗口长肥网络调优按需-l size设置包长模拟小包业务按需-O sec设置测试启动时忽略前N秒排除TCP慢启动过渡期建议使用-Z设置TCP拥塞控制算法验证算法差异按需有个容易被忽略但非常好用的参数是-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服务端被异常终止端口占用与僵尸进程处理测试过程中如果要中断直接按CtrlC就行。但有的时候服务端进程会因为各种原因没有被正确回收或者你可能开了很多个服务端实例端口被占用。启动新服务端时就会看到bind failed: Address already in use。处理方法# 查找占用5201端口的进程 lsof -i :5201 # 或者 ss -tulpn | grep 5201 # 强制结束 kill -9 pid一个更稳妥的做法是给服务端加--one-off参数这个参数会让服务端在接受一次客户端测试后自动退出避免长时间挂在那里占着端口。适合批量自动化的场景。6.5 测试结果忽高忽低网卡多队列与中断绑定的调整万兆测试时如果带宽结果忽高忽低不像千兆那么稳定我第一个怀疑的就是网卡中断没有做负载均衡。默认情况下网卡的中断可能都集中在一个CPU核上处理单核处理不过来就会出现瓶颈速率上上下下地波动。解决方法是在支持RSSReceive 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简单太多。选择的原则很简单多数场景直接用iperf3RDMA相关的测试用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结果、结论和建议。每次排障或验收都按这个模板走效率和说服力都高很多。
