1. 先搞清楚打流的底层逻辑1.1 为什么需要iperf3打流先说个最直接的问题你买了一条千兆宽带或者机房新拉了一条专线怎么知道实际带宽够不够很多人习惯用Speedtest这类在线测速网站但这类工具测的是到某个节点的互联网速度结果受对方服务器性能、骨干网拥堵、DNS解析策略影响很大。真要评估两台设备之间、一个局域网内部、或者一条点到点链路的真实传输能力需要的是iperf3这类专业打流工具。iperf3的核心工作方式很直白一台机器跑成服务端另一台跑成客户端客户端源源不断往服务端灌流量就像用水管往水池里放水看一分钟能放多少吨从而算出管道的真实通量。这个灌流量的过程在行话里就叫打流。打流能验证的不只是带宽上限还能顺便暴露网卡配置问题、网线质量差、交换机端口协商错误、TCP栈参数不合理等一系列隐患。我自己常干的一件事新到一台服务器或者给客户交付一套网络方案时先用iperf3做一轮双向打流。这比看设备上显示的链路已连接1Gbps靠谱得多因为协商速率只是理论值实际能跑多少是另一回事。有一次客户说内网传输特别慢我看交换机端口明明显示千兆一打流才发现实际只能跑到300Mbps左右最后排查出来是网线里有一对芯线接触不良。这种问题不主动打流测试基本发现不了。1.2 TCP和UDP两种打流模式的本质区别iperf3支持TCP和UDP两种模式很多人把这两者理解成一个可靠一个快但在打流场景里两者的用途差异很大。TCP模式用来测实际能跑多快。TCP自带拥塞控制、重传机制、流量控制它会自动适配网络条件所以在TCP模式下iperf3测到的是这条链路在当前网络条件下能达到的稳态吞吐量。这个数值接近你实际传文件时能获得的速度。比如你从NAS拷一个大文件到电脑走的也是TCPiperf3 TCP打流的结果基本能预估这个体验。UDP模式用来测链路到底能承载多少。UDP没有拥塞控制发出去就不管了。你可以指定一个目标带宽让iperf3以这个速率往对端猛灌UDP报文然后观察对端实际收到了多少、丢了多少。这就像拿一根固定口径的水管猛灌看水池那边溢出了多少水。UDP打流的价值在于它能测出一条链路在无拥塞控制约束下的极限承载能力还能顺便量化丢包率——这是TCP测不出来的。TCP模式下如果丢包TCP会重传你看到的吞吐量下降但不知道具体丢包情况UDP模式可以直接告诉你Loss%。还有一点很关键UDP打流经常会发现带宽上不去但CPU先满了的情况。因为UDP报文处理在部分网卡和系统上没法走硬件卸载大量小包会消耗大量CPU。这时候测出的瓶颈是设备处理能力而不是链路带宽。所以看UDP打流结果时要先看CPU占用。1.3 影响带宽测试结果的核心因素打流结果不理想时不要急着怪链路先按优先级排查这几个因素第一是网卡速率和双工模式。千兆网卡如果协商成百兆打流上限就是100Mbps。用ethtool看下协商结果确认Speed、Duplex、Auto-negotiation都正常。第二是TCP窗口和缓冲区。TCP的吞吐量理论上限约等于带宽时延积也就是带宽乘以RTT。如果接收窗口设置得比带宽时延积还小发送端再快也白搭。在长肥网络高带宽、高延迟里比如跨地域专线这个影响尤其明显。第三是CPU性能。iperf3本身是单线程程序如果使用的是单流测试一个核的CPU频率会直接成为瓶颈。我在低配虚拟机上测过2.4GHz的老CPU跑TCP打流单流顶多跑到五六百兆换成多流-P 4立刻跑满千兆。不是说虚拟机带宽不够纯粹是单核性能撑不住。第四是中间链路设备。交换机、路由器、防火墙都可能成为瓶颈尤其是开了QoS策略或者流过滤的防火墙转发性能会明显下降。排查这类问题时建议逐段打流先打直连的两台机器再经过交换机再经过防火墙对比哪一段掉速最明显。2. 安装部署环节的常见坑2.1 Linux端安装iperf3的几种方式iperf3在Linux上的安装不算复杂但版本问题比想象中更容易踩坑。这里说的版本不只是软件版本还包括协议版本iperf2和iperf3是两套不兼容的程序iperf2的客户端连不上iperf3的服务端反过来也一样。现在新项目基本都用iperf3但很多老设备上还留着iperf2测试前先确认两端版本要一致。Debian/Ubuntu系列用下面的命令安装sudo apt update sudo apt install iperf3 -yCentOS/RHEL/Fedora系列用sudo yum install iperf3 -y在比较新的Fedora上要换成dnfsudo dnf install iperf3 -y如果你用的发行版软件源里没有iperf3或者版本太老比如2.x时代遗留的源可以自己编译安装。编译安装的好处是能拿到最新版本还能在configure阶段指定编译参数比如启用调试模式。步骤很简单wget https://downloads.es.net/pub/iperf/iperf-3.11.tar.gz tar -xzf iperf-3.11.tar.gz cd iperf-3.11 ./configure make sudo make install编译安装后默认装到/usr/local/bin/iperf3动态库在/usr/local/lib。这时候有个坑运行iperf3可能报错error while loading shared libraries: libiperf.so.0因为系统找不到动态库路径。需要执行sudo ldconfig或者手动把/usr/local/lib加入ldconfig配置里echo /usr/local/lib | sudo tee /etc/ld.so.conf.d/iperf3.conf sudo ldconfig这类问题在新装的纯净系统上特别容易遇到先记个印象等真遇到时不用手忙脚乱。2.2 Windows端安装与配置Windows上没有包管理器那么方便但也不难。官方提供了编译好的Windows二进制包去iperf.fr官网下载对应版本解压后就能直接用。解压出来是iperf3.exe在命令行里切到对应目录就能运行。Windows使用的几个注意点管理员权限不是必需的但如果你要配合网卡多队列优化、修改TCP参数之类操作建议用管理员身份打开命令行。运行iperf3前推荐先用管理员权限关掉Windows的TCP自动调优不然某些场景下测出的吞吐量会偏低netsh interface tcp set global autotuninglevelnormal如果你觉得测出来的数据不对劲想恢复默认设置用netsh interface tcp set global autotuninglevelnormal注意Windows的防火墙可能会拦截iperf3的入站连接。第一次跑服务端时系统会弹窗询问是否允许iperf3通过防火墙记得勾选允许——如果是专用网络环境可以直接放行。如果之前不小心点了取消去控制面板的防火墙设置里手动添加入站规则开放TCP/UDP 5201端口。还有一个在Windows上经常被忽略的问题检查电源计划。笔记本默认的平衡电源计划会限制CPU频率直接影响iperf3单线程性能。做测试前先切成高性能电源计划不然测出来的带宽上限可能差出几个档次。3. 常用打流场景的实操方法与参数选择3.1 最基本的双向打流启动服务端和客户端前先规划好哪边当服务端、哪边当客户端。惯例是放在接收测速结果的那端做服务端但iperf3其实没这么讲究双向测试时两端都会收发数据。服务端启动非常简单iperf3 -s默认监听5201端口。如果需要指定端口比如多组测试同时进行加-p参数iperf3 -s -p 5202客户端发起TCP打流iperf3 -c 192.168.1.10这条命令默认进行10秒的TCP双向测试前5秒数据从客户端流向服务端后5秒反向。结束时会汇总输出两方向的带宽、重传、CPU占用等数据。这里有个小技巧很多人第一次用iperf3看到默认跑双向测试觉得没必要想只测单向加-t参数控制时长就够了。这没问题但我建议你至少在排障时做一次完整的默认双向测试因为双向测试能发现单向测试发现不了的问题——比如两条方向经过的路径不一样某些负载均衡环境或者一边的网卡有问题导致单向性能差。3.2 需要烂熟于心的核心参数用iperf3打流核心参数就这几个掌握了它们基本就能覆盖绝大多数场景-t参数控制测试时长单位秒。默认10秒。测长距链路时建议适当延长比如30到60秒因为TCP拥塞窗口需要时间爬升到稳定状态10秒可能还没跑满就结束了。-P参数控制并发流数。默认单流。想要压满带宽尤其是多核CPU的机器适当增加并发流数非常有效。比如-P 4表示同时开4条TCP流。-i参数控制结果打印间隔。默认是每秒打印一次。如果想减少输出或者录制日志时控制文件大小可以改成-i 2甚至-i 5。-u参数切换到UDP模式。UDP模式必须配合-b参数指定目标带宽。-b参数指定UDP发送带宽。比如-b 1000M表示以1000Mbps的速率发送。单位可以是bps默认也可以加后缀K、M、G表示Kbps/Mbps/Gbps还可以写K/M/G加B注意大写B表示字节但实际使用中大家习惯直接用M或G。注意UDP打流时-b不设的话iperf3默认只有1Mbps根本压不出效果。-R参数反转测试方向。默认客户端是发送端服务端是接收端加了-R后服务端往客户端发数据。在做某些网关链路排障时用这个参数对比两个方向的表现很有用。-O参数忽略前N秒的结果。这个参数在测长距高延迟链路时特别有用——TCP拥塞窗口爬升阶段的数据不具备参考价值跳过前几秒能拿到更稳定的结果。--parallel和-P是同一个参数的不同写法吗不是。记住了-P才是并发流数量--parallel不是合法参数。我见过有人把这个搞混怎么跑都报错还以为是兼容问题。3.3 用UDP打流测极限能力UDP打流是iperf3最有价值的使用场景没有之一。TCP打流相当于你问这条链路路况如何我是顺着路况开过去量的UDP打流则是不管路况直接全油门看哪些数据没送到。服务端启动方式和TCP一样iperf3 -s -u注意服务端如果忘了加-u客户端用UDP模式连过来会直接连接失败报错信息很明确。客户端侧iperf3 -c 192.168.1.10 -u -b 1000M -t 30 -i 1这条命令的意思是以1000Mbps的速率向服务端发送UDP报文持续30秒每秒打印一次结果。跑完之后看结果里的关键数据Total Datagrams总共发送了多少个数据报。Lost Datagrams丢失了多少个。Loss%丢包率。千兆网络在无拥塞状态下UDP打流丢包率应该是0%或者接近0%。如果丢包率超过0.1%说明链路质量有问题或者中间设备转发能力不足。Jitter抖动。它反映报文到达时间的波动情况单位毫秒。这个指标在语音、视频这类实时业务里特别重要抖动大会导致音质卡顿。实际操作中我习惯用UDP打流做阶梯施压先用500Mbps打一遍再用800Mbps打再用1000Mbps打逐级升高观察链路在哪个带宽点开始出现明显丢包。这个临界点就是这条链路的有效容量比TCP测出来的数值更有工程参考价值——因为它告诉你一旦业务流量超过这个值就会开始丢包用户体验会断崖式下降。3.4 如何通过多流压满带宽单流测不满带宽是非常正常的事情原因前面提到了iperf3是单线程程序单条TCP流的收发处理基本落在一个CPU核上而单核性能往往成为瓶颈。要压满带宽就得开多流。多流用法很简单iperf3 -c 192.168.1.10 -P 4 -t 30这会同时建立4条TCP流每条流独立传输汇总后的总带宽就是测试结果。但多流不是开得越多越好。流数量太多会带来两个问题一是CPU上下文切换开销变大二是TCP流之间会争抢带宽导致单条流的稳定性下降。我的经验是先从-P 2开始试不行再加到-P 4最多到-P 8就差不多了。再往上加收益非常有限反而可能让结果波动变大。多流测试还有一个隐蔽的坑如果网卡开启了RSS接收端缩放但是队列数少于-P的流数某些流的处理会挤在同一队列里反而影响性能。在服务器上做多流测试前可以用lspci确认网卡型号然后用ethtool -l eth0查看队列数量必要时用ethtool -L调整队列数。3.5 测试时长与统计间隔怎么选很多人拿到iperf3直接默认10秒就跑了这个习惯在大多数局域网测试场景里问题不大但在长距链路上会得出偏低的错误结论。TCP连接的启动阶段有一个慢启动和拥塞避免的过程拥塞窗口从初始值逐渐增大到匹配带宽时延积。对RTT只有0.2毫秒的局域网来说这个爬升过程几乎可忽略但如果是RTT达到50毫秒的跨地域链路拥塞窗口爬升到最大值可能需要好几秒甚至更长。10秒的测试时长里真正能跑满带宽的时间可能只有一半测出来的平均值自然偏低。所以我的建议是局域网测试-t 10就够用了。跨机房、跨地域的专线或公网链路-t 30起步最好-t 60。如果要用-O跳过前几秒先确认链路RTT再决定跳过多少秒。还有一个值得养成的习惯无论测多少时间-i 1都是必要的。每秒打一条日志出来你能看到带宽的实时变化趋势而不只是最终的平均值。如果中间某几秒突然掉速说明链路存在间歇性问题平均数据看不出来但实时数据一眼就能发现。4. 测试结果怎么看问题怎么排查4.1 读懂iperf3的运行结果很多人只看最后一行SUM数据其实iperf3输出的信息量比这大得多。拿一次典型的TCP测试结果举例[ ID] Interval Transfer Bitrate Retr [ 5] 0.00-1.00 sec 112 MBytes 940 Mbits/sec 0 [ 5] 1.00-2.00 sec 113 MBytes 950 Mbits/sec 0 [ 5] 2.00-3.00 sec 111 MBytes 930 Mbits/sec 1 ... - - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.09 GBytes 935 Mbits/sec 12每一行Interval代表一个统计周期Transfer是这个周期内传输的数据量Bitrate是换算出来的速率Retr是本周期内的TCP重传次数。如果Retr一直大于0说明链路存在丢包或拥塞。偶尔重传1到2次是正常的但如果每秒都有几十上百次重传链路质量一定有问题——最常见的原因是网线质量差、光模块衰减、或者中间交换机端口有CRC错误。TCP模式还有一个重要指标在汇总表里是Bitrate和Retr。如果测试结果里的Retr数量很大你要做的不是换更大带宽的方案而是先定位为什么丢包。UDP模式的输出更直白[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 1.16 GBytes 997 Mbits/sec 0.002 ms 0/149410 (0%)这里的Jitter指抖动Lost/Total表示丢失的数据报数和总数据报数括号里是丢包率。0%是理想状态。4.2 链路掉速的排查思路打流结果不理想时我建议按这个顺序排查效率最高第一步查物理层。看网卡状态ethtool ethX确认Speed是1000Mb/s还是100Mb/s。如果是100Mb/s先查网线是不是八芯全通、接口有没有松动、对端设备端口是不是百兆口。网线问题在打流测试里最臭名昭著——千兆网络只用到4根线时也能协商上千兆速率但一跑大流量就开始疯狂丢包速度跌到几百兆。第二步查两端系统参数。查看TCP缓冲区是否足够大。Linux下可以检查sysctl net.ipv4.tcp_rmem sysctl net.ipv4.tcp_wmem默认值一般是4096 87380 6291456也就是说最大窗口6MB。对短距离链路来说绰绰有余但高带宽时延积的环境下可能需要调到更大。比较稳妥的做法是临时调大到16到32MBsysctl -w net.ipv4.tcp_rmem4096 87380 33554432 sysctl -w net.ipv4.tcp_wmem4096 16384 33554432第三步查中间设备。如果直连测试一切正常经过中间交换机或防火墙后掉速问题基本就在中间设备上。优先查交换机端口是否有错误计数ethtool -S eth0 | grep error或者走管理口看交换机的CRC错误计数、FCS错误等。防火墙掉速更常见很多防火墙开了入侵检测IDS/IPS或者深度包检测DPI后转发能力只有标称值的30%到50%。这种情况要么关掉相关功能要么买更高规格的设备。第四步查CPU。这个比较容易忽略。如果iperf3测试时其中一个CPU核心已经打满而带宽还没上去那就不是链路问题而是端设备处理能力到头了。这个时候优化系统参数意义不大换更高频率的CPU、启用网卡硬件卸载、开多队列才是正确的方向。4.3 典型问题速查表现象可能原因排查方法只能跑到100Mbps网卡协商成千兆失败ethtool ethX看Speed字段网卡显示千兆但打流只有300Mbps网线接触不良或损坏换个短网线直连测试单流跑不满多流能跑满单核CPU性能瓶颈-P 4重新测试每秒都有重传中间链路丢包看交换机端口错误计数测光模块光衰U盘打流丢包率高中间设备处理能力不足逐段打流定位掉速点打流开始正常几秒后掉速过热或限流策略检查设备温度、QoS/rate-limit配置Windows测试结果偏低自动调优兼容性问题netsh interface tcp set global autotuninglevelnormal服务端报bind失败端口被占用换-p端口或者杀掉旧进程这个表里的前四行基本覆盖了日常排障中八成以上的情况。遇到问题先对着表过一遍比瞎试参数快得多。5. 打流测试经验技巧与工作习惯分享5.1 实用小技巧先说一个公认的测数据库小技巧打流之前先把服务端和客户端的系统时间同步一遍。因为iperf3日志本身不带精确时间戳打流过程如果跨越了NTP同步的调整窗口可能同步的瞬间出现时钟跳变虽然不影响速率统计但如果你用日志里的时间做分析会出现时间轴错位。用chronyc或ntpdate同步并不复杂跑一轮测试前花10秒做掉省掉后面数据对不上的麻烦。第二个技巧把打流结果保存成JSON格式。-J参数可以输出JSON结构的数据方便写脚本解析和汇总iperf3 -c 192.168.1.10 -t 30 -J result.json如果要做长期监控或批量测试JSON格式的可解析性会比纯文本好太多。我用Python写了个小脚本定时跑iperf3并把结果写入InfluxDB在Grafana上画出历史带宽曲线——哪个时段链路质量差一目了然。这个思路尤其适合IDC运维场景。第三个技巧测试前先确认防火墙规则。iperf3默认端口是5201安全策略严格的环境里对方可能只放行了TCP 80/443。测试前先确认放行策略不然你在这里怀疑链路实际是安全组没放行。第四个技巧录日志时别贪多。-i 1足够了不需要更小间隔。统计间隔太密会产生大量日志而且iperf3打印本身就是一次IO操作太密的打印可能反过来影响测试结果——这在高带宽场景下会出现一定程度的性能损耗。5.2 一个完整的测试流程建议实战中形成一套自己的标准流程很重要不仅提升效率也方便结果对比。我的做法是先做一轮Quick Test用默认参数快速确认链路是否基本正常iperf3 -c 192.168.1.10 -t 10如果基本正常再做一轮Full Testiperf3 -c 192.168.1.10 -t 30 -i 1 -P 4 iperf3 -c 192.168.1.10 -t 30 -i 1 -P 4 -R然后用UDP测极限iperf3 -c 192.168.1.10 -u -b 1000M -t 30 -i 1最后如果怀疑是光纤链路问题再加上光模块光功率检查一般用设备上的命令看接收光功率是否在正常范围内。这套流程跑下来大约2分钟但能把链路的稳态性能、双向表现、极限承载能力和异常点全部覆盖到。5.3 容易翻车的几个细节UDP打流一定要先和对方确认。默认的UDP模式是可以直接把对方带宽打满的比如你在一个共享链路上用1000Mbps的UDP猛灌影响的是整条链路上其他用户的体验。我曾经在客户现场就疏忽过默认参数上来直接千兆UDP狂灌结果把同链路其他业务的视频会议直接打挂幸好及时刹住。做这类高压测试前建议先小带宽起步确认链路再阶梯加压同时预估给正常业务留出余量。使用iperf3自带的端口要注意安全。如果不做限制你开放了iperf3服务端等于给任意能访问到该端口的人提供了一个流量放大攻击的载体。虽然iperf3本身不算是攻击工具但开放服务时最好加白名单限制比如防火墙只允许特定来源IP访问5201端口。版本兼容问题前面提过这里再强调iperf3分为通用的iperf3版本和少数变异版本但最常见的兼容问题是iperf2和iperf3混用。如果两端的iperf版本不同连接会直接失败报错信息一般类似unable to connect to server或者connect failed: Connection refused。遇到这种情况先检查版本别折腾防火墙。5.4 什么时候不该用iperf3打流很好用但不是所有测试场景都适合它。iperf3验证的是点对点的最大传输能力它模拟的是一台机器到另一台机器的持续大流量传输。但真实业务的流量模型往往不是这样网页访问是短连接、小文件视频通话是低码率、实时性要求高数据库同步是小包、高并发。这些都更适合用专门的压测工具或业务自身的监控手段来验证。另外iperf3测的是这一瞬间的链路能力它不能替代持续性的链路质量监控。链路质量会随时间、温度、负载而波动尤其是光链路。我的建议是一次性排障用iperf3足够了但如果要做链路质量评估还是要部署持续性的监控方案定期记录带宽、丢包、延迟和抖动变化曲线。5.5 个人经验总结用iperf3这几年下来我觉得它最大的价值不是测出多少带宽而是让人形成一种网络问题可量化的工作思维。别凭感觉说网速慢直接打流出一组数据再反向分析瓶颈在哪。数据不会骗人但数据也有可能误导人——前提是你得懂每个输出指标背后代表什么。我踩过最深的坑就是一开始只看Bitrate不看Retr结果明明链路在疯狂丢包重传我还以为带宽不稳定是因为网络拥塞。后来老员工提醒我注意重传计数才真正开始看懂iperf3的输出。还有一次给客户做验收测试直连测试跑满千兆但加了一台老交换机后速率掉到400Mbps。客户坚称交换机没问题我让他看交换机端口的CRC错误计数——好家伙光一个端口每秒就有几百个CRC错误最后换了台交换机解决。这个案例我一直记着因为它很好地说明了打流测试的真正价值它不是考核设备而是帮你把问题从玄学变成科学。如果你刚开始接触iperf3别急着背参数先把服务端和客户端跑起来用默认参数测一遍再试着加-P、加-u、换-i感受不同参数对结果的影响。等你想清楚每个指标背后的物理意义再用它干活就会顺手很多。
