1. 为什么内网测速要专门装工具而不是直接拷贝文件做运维的人应该都有过这种经历客户报障说“内网传文件慢”你第一反应是去共享文件夹里拖一个大文件试试感觉速度不理想但又说不出来具体差在哪。其实这就是典型的缺少量化手段——你只看到了传输一个文件用了多久但你不知道这条链路到底能跑多少、瓶颈在交换机还是网卡还是线缆。iperf就是这么个工具。它的原理很简单一端做服务端Server一端做客户端Client客户端往服务端持续发包然后统计单位时间内传了多少数据。比起拷贝一个大文件iperf有几个不可替代的优势它可以指定测试时长、并发数、TCP窗口大小、UDP包大小和带宽上限能针对不同业务场景做定向模拟它可以量化丢包率、抖动、重传率最重要的一点是它测的是链路的实际吞吐能力而不是磁盘读写能力。我之前遇到过一例很典型的情况内网从服务器拷一个 10GB 的数据库备份文件到本地显示速度能到 110MB/s看起来挺快但多台机器同时从这台服务器拉数据整体速度就被砍了一大截。用 iperf 一测发现单条 TCP 流只能跑 450Mbps 左右问题出在网卡驱动没有开启多队列导致多并发时单核 CPU 成为瓶颈。这种问题不靠 iperf 这类工具根本定位不出来。适合用这套方案的人很明确做服务器运维的、做弱电项目验收的、自己家里有 NAS 想确认网线和交换机到底有没有跑到千兆的还有刚装完 CentOS 系统想知道虚拟化平台网络性能是否正常的人。这篇文章就按我的实际操作过程完整走一遍 CentOS 9 装 iperf 到测试出报告的量流程包含每一步的坑和判断依据。2. 装iperf之前先把这四件事搞清楚2.1 确定你的CentOS 9具体是什么版本CentOS 9 现在只有 Stream 版本没有传统意义上像 CentOS 7 那种稳定版。CentOS Stream 9 的定位是 RHEL 9 的上游滚动版本所以你在系统里执行cat /etc/centos-release看到的可能是CentOS Stream release 9。这一点直接影响你后面用什么包管理器装软件。CentOS Stream 9 默认的软件源里是有 iperf3 的但版本未必是最新的。我在 2024 年下半年装的时候默认源里是 3.9 版本已经足够用了。需要确认的一点是系统默认仓库有没有启用。有时候你装完系统或者换过源/etc/yum.repos.d/下的仓库文件可能被改过导致搜索不到软件包。先执行dnf repolist看一下当前启用的仓库列表比直接去dnf install然后报错要省事得多。还有一个小细节CentOS Stream 9 里yum命令虽然还在但本质上是dnf的软链接你直接用dnf就行。别用yum install iperf因为 CentOS 9 默认源里只有iperf3老版本的iperf可能在 EPEL 源里才有两者命令和参数不完全兼容下面细说。2.2 明确你的测试模式iperf2 还是 iperf3这是个特别容易踩的坑。如果你在搜索引擎搜iperf 安装出来的教程有一大半是 iperf2 的用法命令是iperf -s和iperf -c端口默认 5001。而 iperf3 的用法是iperf3 -s和iperf3 -c端口默认 5201。两者最大的区别在于iperf3 不支持多线程模式下的双向同时测试-d参数被移除了而 iperf2 支持iperf3 的 UDP 测试模式更能反映真实网络质量且报告格式更清晰。现在的实际环境里iperf3 是绝对主流因为它在处理高带宽、多并发时对 CPU 的占用更小报告里的重传率、抖动、丢包统计项也更完整。我建议直接装 iperf3。除非你是在维护老设备某些嵌入式设备的 iperf 还是 2.x 版本那时候再考虑兼容问题。判断对端设备用的哪个版本也很简单服务端启动时看提示信息iperf2 会输出iperf: server is running on port 5001iperf3 会输出iperf3: server is listening on 5201。2.3 确认测试机之间的网络连通性这个步骤看起来多余但实际上很多人装完 iperf 发现连不上第一反应怀疑是防火墙查了半天结果是 IP 都不通。所以在装软件之前先把基础连通性确认了ping -c 4 192.168.1.100如果 IP 不通就不要往下进行了先解决二层三层的问题。如果 IP 通再确认测试端口没被占用。比如你想用 5201 端口先执行ss -tlnp | grep 5201如果已有进程占用要么换端口要么杀掉旧进程。我在实际测试中遇到过服务器上跑着其他服务占用了 5201 端口的情况直接改用来测端口 15201iperf3 -s -p 15201客户端对应加-p 15201即可。iperf3 对端口的限制很少自定义端口完全没问题只要两端保持一致防火墙放行对应端口就行。2.4 确认网卡速率协商状态很多人忽略这一步导致测出来的数据根本不具备参考价值。你以为是测链路带宽实际上测的是降级协商后的百兆速率。用 ethtool 查看ethtool eth0重点看Speed字段。千兆网卡应该显示1000Mb/s万兆显示10000Mb/s。如果显示100Mb/s说明网线质量或线序有问题或者对端设备端口是百兆的。这种基础问题不解决后面测多少遍都是白费。对于服务器上有多块网卡的情况先通过ip addr确认当前使用的网卡名称是哪个再看协商速率不要对着不用的那块网卡查半天。我在一台双网卡服务器上就犯过这个错查了 eth0 显示千兆但实际跑数据走的是 eth1eth1 协商成百兆了症结从一开始就找错了方向。3. CentOS 9 安装 iperf3 的两种方式实测都能用3.1 方式一直接利用默认仓库安装推荐CentOS Stream 9 的 BaseOS 仓库里已经包含 iperf3安装非常简单dnf install -y iperf3安装完成后验证一下iperf3 -v输出的版本信息如果显示iperf 3.9之类的字样就说明安装成功了。这种方式适合绝大多数场景因为默认仓库里的版本稳定性和兼容性都有保障而且不会有依赖问题。如果执行dnf install -y iperf3提示找不到软件包先别急着换源执行下面的命令更新一下仓库缓存dnf makecache然后再安装。这个情况在新装的系统上比较常见仓库元数据还没拉取完整。需要额外说明的是如果你之前把默认源替换成了国内的镜像源仍然能正常安装因为各镜像源都会同步 CentOS Stream 9 的 BaseOS 仓库。3.2 方式二EPEL 源安装备选方案有些精简版系统连 BaseOS 仓库都不完整或者你需要更新版本的 iperf3可以考虑从 EPEL 源装。EPEL 是 Fedora 社区维护的扩展软件仓库里面有大量默认源没有的软件包。dnf install -y epel-release dnf install -y iperf3EPEL 源的好处是软件版本更新更快坏处是在部分精简环境下安装epel-release本身就可能因为缺少依赖而失败。遇到这种情况直接下载 RPM 包手动安装wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm rpm -ivh epel-release-latest-9.noarch.rpm实际测试中这条链路在 CentOS Stream 9 上是走得通的。但因为默认仓库已经有 iperf3 了EPEL 方案通常只在默认源不可用的时候才需要。3.3 方式三源码编译安装适合需要特定版本的场景如果事情到了非编译不可的地步比如你需要打某些性能补丁或者指定版本源码编译的流程也不复杂dnf install -y gcc make wget https://downloads.es.net/pub/iperf/iperf-3.17.1.tar.gz tar -zxvf iperf-3.17.1.tar.gz cd iperf-3.17.1 ./configure make -j$(nproc) make install编译安装后可执行文件默认在/usr/local/bin/iperf3。因为/usr/local/bin的优先级通常高于/usr/bin直接执行iperf3一般就能找到新版本。如果命令找不到检查一下是否缺少ldconfig刷新或者直接把/usr/local/bin加入环境变量。源码编译这条路线我只有在测试 3.16 以上版本分支时才走过日常使用完全没必要为了新版去折腾。4. 核心实操服务端和客户端的完整测试流程4.1 服务端启动参数详解假设我有两台 CentOS 9 机器一台 IP 是 192.168.1.10一台是 192.168.1.20。我先把 192.168.1.10 作为服务端启动iperf3 -s看到Server listening on 5201就说明启动成功了。如果想把日志输出到文件方便事后分析可以加-D参数以守护进程方式运行iperf3 -s -D --logfile /var/log/iperf3.log补充一个细节服务端默认只能接受一个客户端连接测试完成后会退出。这是 iperf3 和 iperf2 的一个显著区别。如果你要连续测试多台客户端需要反复启动服务端。嫌麻烦的话可以用一个最简单的循环脚本while true; do iperf3 -s -p 5201; done或者直接每次测完重新运行一次服务端命令。真实场景里我通常直接前台跑因为测试窗口也就几分钟没必要搞得太复杂。什么情况下需要加-i参数-i控制报告的间隔时间比如iperf3 -s -i 1这样每秒输出一次统计信息方便实时观察带宽波动。默认情况下 iperf3 只出最终汇总报告不加-i也能看最终结果但如果链路不稳定中间过程的数据变化对排查问题更有参考价值。4.2 客户端基础测试测单向 TCP 吞吐服务端起来之后在客户端机器上执行最基础的测试iperf3 -c 192.168.1.10这条命令默认持续 10 秒采用单线程 TCP 测试。10 秒结束后输出的报告里最关键的两个数字是Transfer和Bitrate。比如[ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.10 GBytes 940 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 1.10 GBytes 940 Mbits/sec receiver看到940 Mbits/sec这个数值对于千兆网络来说就是正常的。因为千兆以太网的理论上限是 1000Mbps但刨去以太网帧头、TCP/IP 协议开销实际能跑到的极限就在 940Mbps 左右。如果你测出来是 940说明链路质量很好没有丢包重传如果只有 500 多那就要往下查了。Retr字段代表 TCP 重传次数0 说明没有重传。重传次数高说明链路存在丢包可能是网线质量问题、交换机端口错误或者对端负载过高导致缓存溢出。4.3 反向测试和双向同时测试判断链路是否对称很多场景下我们不光要测下行还要测上行。比如服务器向客户端发送数据的速度是正常的但客户端往服务器传数据却很慢这就需要分别测试两个方向。iperf3 的反向测试参数是-R--reverse表示让服务端往客户端发包iperf3 -c 192.168.1.10 -R正常情况下千兆链路的正反向结果应该非常接近。如果单向差距超过 20%优先考虑网卡配置、网线线对问题或交换机端口协商异常。如果要做双向同时测试iperf3 提供了--bidir参数iperf3 -c 192.168.1.10 --bidir这个参数在 3.9 版本里已经支持了。输出结果会分两段显示一段是从客户端到服务端方向一段是服务端到客户端方向。--bidir的价值在于模拟真实业务场景很多应用比如数据库同步、视频会议是典型的双向流量模型。有些交换机在做 QoS 策略或端口限速时只限制了单向这种问题只有双向测试才能暴露出来。4.4 多线程测试压出真实带宽极限单线程测试结果受限于单 TCP 流的窗口和 CPU 单核处理能力尤其在高带宽环境万兆下单线程很难跑满。多线程参数的用法是-Piperf3 -c 192.168.1.10 -P 4-P 4表示同时发起 4 条 TCP 流。输出报告里每条流单独显示最后有一个 SUM 汇总行。比如 4 条流分别是 235Mbps合计就是 940Mbps说明带宽被榨干了。这里有一个实操心得多线程测试结果如果和单线程结果一模一样比如单线程也是 940多线程也是 940说明瓶颈在物理链路如果多线程明显高于单线程说明瓶颈在 TCP 单流限制或者 CPU 单核性能不足。不同情况对应完全不同的优化方向前者查硬件后者查配置。4.5 UDP 测试很多运维容易忽略的关键测试TCP 测试本质上是可靠传输协议网速不好时 TCP 会自动降速来保证不丢包。但在承载语音、视频这类实时业务时UDP 才是真实场景。UDP 测试能暴露链路在无拥塞控制时的真实表现。iperf3 -c 192.168.1.10 -u -b 1000M-b 1000M表示以 1000Mbps 的目标带宽发送 UDP 包。输出的报告里有两个关键指标Jitter抖动和Lost/Total Datagrams丢包率。丢包率是重点[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 114 MBytes 956 Mbits/sec 0.012 ms 1029/87208 (1.2%)如果丢包率在 0% 到 0.5% 之间说明链路质量良好如果超过 1%就需要关注了。特别是你要在上面跑 VoIP、视频会议这类实时业务1% 的 UDP 丢包已经能造成可感知卡顿。UDP 测试的带宽参数-b一定要给目标值否则默认只有 1Mbps测出来的数据没有任何意义。测千兆网络建议-b 1000M测万兆给-b 10000M。如果链路的实际能力达不到目标iperf 会告诉你实际跑了多少这个差值就是链路的上限。4.6 测试时长和间隔别用默认参数就完事-t参数指定测试时长默认 10 秒。10 秒对于排查问题来说太短了尤其是间歇性丢包的问题可能需要 30 秒甚至 60 秒才能暴露。我习惯的做法是iperf3 -c 192.168.1.10 -t 30 -i 5-t 30表示跑 30 秒-i 5表示每 5 秒输出一次中间报告。30 秒足够覆盖绝大多数网络波动场景。如果要做长时间稳定性测试跑 300 秒也不嫌多比如iperf3 -c 192.168.1.10 -t 300 -i 10长测试有个好处能观察带宽是否一直稳定在同一水平线还是每隔几十秒出现一次断崖下跌。造成周期性下跌的原因通常是交换机缓存不足、CPU 温度过高降频、或者链路中有其他流量周期性抢占带宽。5. 一份iperf3测试报告的逐项解读5.1 报告中的关键字段怎么看很多新手看到 iperf3 输出的报告会发懵密密麻麻的数字不知道看哪个。我拆开讲一下最关键的报告字段。TCP 测试报告示例[ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.10 GBytes 940 Mbits/sec 0 sender第一列[ID]是测试流的编号单线程就是 5。Interval是统计时间段。Transfer是这段时间内传输的数据量。Bitrate就是实时带宽单位是 Mbits/sec注意这里用的是 bit 而不是 byte。1.10 GBytes 对应 940 Mbits/sec换算关系是1 Byte 8 bit1.10 GBytes 8.8 Gbits除以 10 秒就是 0.88 Gbps加上协议开销计算就是报告显示的 940 Mbps。Retr是重传次数TCP 发生丢包时会触发重传。重传次数高说明链路不稳定。看到上万的重传次数先查网线、查交换机端口、查光模块光功率大概率能找到问题。UDP 测试报告示例[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 114 MBytes 956 Mbits/sec 0.012 ms 0/81178 (0%)Jitter代表包的到达时间间隔变化单位是毫秒。数值越小越好超过 1ms 就要引起重视。Lost/Total Datagrams是丢包统计括号里是丢包率。0% 是最理想的结果语音业务在 1% 以内基本无感视频会议在 3% 以内可接受超过 5% 就会出现明显花屏和卡顿。5.2 SUM 行和单流行之间的换算关系多线程测试时报告会先列出每一条流的独立数据然后是一个 SUM 汇总。比如-P 4的结果[ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 282 MBytes 236 Mbits/sec 0 sender [ 7] 0.00-10.00 sec 282 MBytes 236 Mbits/sec 0 sender [ 9] 0.00-10.00 sec 282 MBytes 236 Mbits/sec 0 sender [ 11] 0.00-10.00 sec 282 MBytes 236 Mbits/sec 0 sender [SUM] 0.00-10.00 sec 1.10 GBytes 940 Mbits/sec 0 sender四条流各自的带宽加起来正好等于 SUM 的带宽。如果单流之间差距很大比如两条 400Mbps、两条 100Mbps说明负载均衡有问题。常见的原因是网卡多队列没开启导致中断都集中在一个 CPU 核上。用lspci -vvv查网卡是否支持多队列配合ethtool -l eth0查看队列数量可以验证这个判断。5.3 什么样的结果才算正常这个表格是我的个人判断标准不同环境下会有差异但作为初始参考足够了网卡规格TCP测试预期带宽备注百兆94 Mbps 左右以太网协议开销约6%千兆940 Mbps 左右万兆网卡单流可能跑不满万兆3~9.4 Gbps取决于网卡型号和PCIe通道数如果千兆网络测出来的结果只有 80~100Mbps基本可以确定有网线质量问题、协商错误或者端口限速。你跑ethtool eth0如果显示100Mb/s那 94Mbps 就是正常的——但问题本来就出在协商结果上。6. 常见问题与排查技巧实录6.1 防火墙挡掉连接遇到最多的就是这个问题。服务端启动了客户端一执行iperf3 -c直接报错iperf3: error - unable to connect to server: Connection refused这个错误提示其实是两类原因一类是服务端没启动或 IP 不对另一类是防火墙拦截了 SYN 包。如果用telnet 192.168.1.10 5201测试端口都不通先去检查防火墙firewall-cmd --list-ports如果没有放行 5201 端口执行firewall-cmd --permanent --add-port5201/tcp firewall-cmd --permanent --add-port5201/udp firewall-cmd --reload注意 TCP 和 UDP 都要放行因为 iperf3 默认先走 TCP 建立控制连接UDP 测试模式下数据流走 UDP。只放行 TCP 会导致 TCP 测试正常、UDP 测试连不上。另外如果服务器的 selinux 处于 enforcing 模式通常不影响端口监听但如果你用自定义端口最好确认一下 selinux 上下文策略避免遇到怪问题semanage port -l | grep 5201没有semanage命令就先装policycoreutils-python-utils。这一步不是必做但能排除掉一类隐蔽问题。6.2 测速结果远低于预期先别急着怪设备速度不达标时有一个固定的排查顺序确认网卡协商速率ethtool eth0看 Speed。确认网线等级五类线跑千兆是不行的至少要超五类或六类。确认交换机端口是否为自适应状态两端是否都强制千兆全双工。确认网卡驱动是否加载了正确的模块ethtool -i eth0查看驱动版本。确认是否存在其他大流量业务干扰用nload或iftop看一下实时流量。从优先级上看物理层问题排在第一位。我遇到过一台服务器iperf3 只能跑 300Mbps重启后又恢复正常。后来发现是网卡固件过热导致降速补充机柜通风后问题彻底消失。这种间歇性问题最考验耐心如果前四个排查点都正常建议直接跑长时长测试-t 60把波动抓出来。6.3 iperf3 服务端口被默认占用服务端启动时报bind() failed: Address already in use这种错误通常意味着有老进程占用了端口。处理方式lsof -i :5201 kill -9 PID或者用fuser -k 5201/tcp一条命令搞定。在 CentOS 9 里ss -tlnp | grep 5201可以看到占用进程。如果是之前跑的前台 iperf3 没退干净找到 PID 直接杀掉就行。6.4 IPv6 和主机名造成连接失败在一台同时配了 IPv4 和 IPv6 地址的机器上如果客户端直接用主机名连接可能会优先尝试 IPv6 地址而服务端只监听了 IPv4 的 5201 端口导致连接失败。解决办法有两个方案一客户端连接时用 IP 地址而不是主机名iperf3 -c 192.168.1.10方案二服务端同时监听 IPv6iperf3 -s -6还有一种隐蔽的情况两台机器之间有多条路由客户端选择的路径不是最优路径。用traceroute看路径如果经过了不必要的设备查一下路由表。6.5 测速结果高但业务实际慢别死磕iperfiperf 测的是纯网络性能磁盘 I/O、应用层处理能力完全不在 iperf 的辐射范围内。如果你 iperf 测出 940Mbps 但拷贝文件只有 80MB/s问题大概率在磁盘写入速度或 SMB 协议限制上。拿实际业务服务比如 FTP、HTTP、数据库做基准测试才能拿到贴近业务的性能数据。iperf 解决的永远是链路本身够不够快这个问题应用层再慢它也管不着。附再分享一个我常用的批量测试技巧最后分享一个实用小技巧。如果你有多台机器要测手写命令效率太低我一般是直接在客户端机器上写一个简单脚本循环测试多个目标地址#!/bin/bash for ip in 192.168.1.10 192.168.1.20 192.168.1.30; do echo Testing $ip iperf3 -c $ip -t 10 -i 1 done服务端那边用while true; do iperf3 -s; done循环顶着。这样逐台测过去一份报告文件就能对比出所有链路的质量差异。之后如果你还想做更细致的验证可以接着调-w参数指定 TCP 窗口大小或者用--congestion cubic切换拥塞控制算法。但那些都属于进阶玩法了先把基础的 TCP 和 UDP 测试跑明白内网带宽测试这件事你就已经能够应付大多数实际场景了。
CentOS 9 安装 iperf3 内网带宽测试实战指南
1. 为什么内网测速要专门装工具而不是直接拷贝文件做运维的人应该都有过这种经历客户报障说“内网传文件慢”你第一反应是去共享文件夹里拖一个大文件试试感觉速度不理想但又说不出来具体差在哪。其实这就是典型的缺少量化手段——你只看到了传输一个文件用了多久但你不知道这条链路到底能跑多少、瓶颈在交换机还是网卡还是线缆。iperf就是这么个工具。它的原理很简单一端做服务端Server一端做客户端Client客户端往服务端持续发包然后统计单位时间内传了多少数据。比起拷贝一个大文件iperf有几个不可替代的优势它可以指定测试时长、并发数、TCP窗口大小、UDP包大小和带宽上限能针对不同业务场景做定向模拟它可以量化丢包率、抖动、重传率最重要的一点是它测的是链路的实际吞吐能力而不是磁盘读写能力。我之前遇到过一例很典型的情况内网从服务器拷一个 10GB 的数据库备份文件到本地显示速度能到 110MB/s看起来挺快但多台机器同时从这台服务器拉数据整体速度就被砍了一大截。用 iperf 一测发现单条 TCP 流只能跑 450Mbps 左右问题出在网卡驱动没有开启多队列导致多并发时单核 CPU 成为瓶颈。这种问题不靠 iperf 这类工具根本定位不出来。适合用这套方案的人很明确做服务器运维的、做弱电项目验收的、自己家里有 NAS 想确认网线和交换机到底有没有跑到千兆的还有刚装完 CentOS 系统想知道虚拟化平台网络性能是否正常的人。这篇文章就按我的实际操作过程完整走一遍 CentOS 9 装 iperf 到测试出报告的量流程包含每一步的坑和判断依据。2. 装iperf之前先把这四件事搞清楚2.1 确定你的CentOS 9具体是什么版本CentOS 9 现在只有 Stream 版本没有传统意义上像 CentOS 7 那种稳定版。CentOS Stream 9 的定位是 RHEL 9 的上游滚动版本所以你在系统里执行cat /etc/centos-release看到的可能是CentOS Stream release 9。这一点直接影响你后面用什么包管理器装软件。CentOS Stream 9 默认的软件源里是有 iperf3 的但版本未必是最新的。我在 2024 年下半年装的时候默认源里是 3.9 版本已经足够用了。需要确认的一点是系统默认仓库有没有启用。有时候你装完系统或者换过源/etc/yum.repos.d/下的仓库文件可能被改过导致搜索不到软件包。先执行dnf repolist看一下当前启用的仓库列表比直接去dnf install然后报错要省事得多。还有一个小细节CentOS Stream 9 里yum命令虽然还在但本质上是dnf的软链接你直接用dnf就行。别用yum install iperf因为 CentOS 9 默认源里只有iperf3老版本的iperf可能在 EPEL 源里才有两者命令和参数不完全兼容下面细说。2.2 明确你的测试模式iperf2 还是 iperf3这是个特别容易踩的坑。如果你在搜索引擎搜iperf 安装出来的教程有一大半是 iperf2 的用法命令是iperf -s和iperf -c端口默认 5001。而 iperf3 的用法是iperf3 -s和iperf3 -c端口默认 5201。两者最大的区别在于iperf3 不支持多线程模式下的双向同时测试-d参数被移除了而 iperf2 支持iperf3 的 UDP 测试模式更能反映真实网络质量且报告格式更清晰。现在的实际环境里iperf3 是绝对主流因为它在处理高带宽、多并发时对 CPU 的占用更小报告里的重传率、抖动、丢包统计项也更完整。我建议直接装 iperf3。除非你是在维护老设备某些嵌入式设备的 iperf 还是 2.x 版本那时候再考虑兼容问题。判断对端设备用的哪个版本也很简单服务端启动时看提示信息iperf2 会输出iperf: server is running on port 5001iperf3 会输出iperf3: server is listening on 5201。2.3 确认测试机之间的网络连通性这个步骤看起来多余但实际上很多人装完 iperf 发现连不上第一反应怀疑是防火墙查了半天结果是 IP 都不通。所以在装软件之前先把基础连通性确认了ping -c 4 192.168.1.100如果 IP 不通就不要往下进行了先解决二层三层的问题。如果 IP 通再确认测试端口没被占用。比如你想用 5201 端口先执行ss -tlnp | grep 5201如果已有进程占用要么换端口要么杀掉旧进程。我在实际测试中遇到过服务器上跑着其他服务占用了 5201 端口的情况直接改用来测端口 15201iperf3 -s -p 15201客户端对应加-p 15201即可。iperf3 对端口的限制很少自定义端口完全没问题只要两端保持一致防火墙放行对应端口就行。2.4 确认网卡速率协商状态很多人忽略这一步导致测出来的数据根本不具备参考价值。你以为是测链路带宽实际上测的是降级协商后的百兆速率。用 ethtool 查看ethtool eth0重点看Speed字段。千兆网卡应该显示1000Mb/s万兆显示10000Mb/s。如果显示100Mb/s说明网线质量或线序有问题或者对端设备端口是百兆的。这种基础问题不解决后面测多少遍都是白费。对于服务器上有多块网卡的情况先通过ip addr确认当前使用的网卡名称是哪个再看协商速率不要对着不用的那块网卡查半天。我在一台双网卡服务器上就犯过这个错查了 eth0 显示千兆但实际跑数据走的是 eth1eth1 协商成百兆了症结从一开始就找错了方向。3. CentOS 9 安装 iperf3 的两种方式实测都能用3.1 方式一直接利用默认仓库安装推荐CentOS Stream 9 的 BaseOS 仓库里已经包含 iperf3安装非常简单dnf install -y iperf3安装完成后验证一下iperf3 -v输出的版本信息如果显示iperf 3.9之类的字样就说明安装成功了。这种方式适合绝大多数场景因为默认仓库里的版本稳定性和兼容性都有保障而且不会有依赖问题。如果执行dnf install -y iperf3提示找不到软件包先别急着换源执行下面的命令更新一下仓库缓存dnf makecache然后再安装。这个情况在新装的系统上比较常见仓库元数据还没拉取完整。需要额外说明的是如果你之前把默认源替换成了国内的镜像源仍然能正常安装因为各镜像源都会同步 CentOS Stream 9 的 BaseOS 仓库。3.2 方式二EPEL 源安装备选方案有些精简版系统连 BaseOS 仓库都不完整或者你需要更新版本的 iperf3可以考虑从 EPEL 源装。EPEL 是 Fedora 社区维护的扩展软件仓库里面有大量默认源没有的软件包。dnf install -y epel-release dnf install -y iperf3EPEL 源的好处是软件版本更新更快坏处是在部分精简环境下安装epel-release本身就可能因为缺少依赖而失败。遇到这种情况直接下载 RPM 包手动安装wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm rpm -ivh epel-release-latest-9.noarch.rpm实际测试中这条链路在 CentOS Stream 9 上是走得通的。但因为默认仓库已经有 iperf3 了EPEL 方案通常只在默认源不可用的时候才需要。3.3 方式三源码编译安装适合需要特定版本的场景如果事情到了非编译不可的地步比如你需要打某些性能补丁或者指定版本源码编译的流程也不复杂dnf install -y gcc make wget https://downloads.es.net/pub/iperf/iperf-3.17.1.tar.gz tar -zxvf iperf-3.17.1.tar.gz cd iperf-3.17.1 ./configure make -j$(nproc) make install编译安装后可执行文件默认在/usr/local/bin/iperf3。因为/usr/local/bin的优先级通常高于/usr/bin直接执行iperf3一般就能找到新版本。如果命令找不到检查一下是否缺少ldconfig刷新或者直接把/usr/local/bin加入环境变量。源码编译这条路线我只有在测试 3.16 以上版本分支时才走过日常使用完全没必要为了新版去折腾。4. 核心实操服务端和客户端的完整测试流程4.1 服务端启动参数详解假设我有两台 CentOS 9 机器一台 IP 是 192.168.1.10一台是 192.168.1.20。我先把 192.168.1.10 作为服务端启动iperf3 -s看到Server listening on 5201就说明启动成功了。如果想把日志输出到文件方便事后分析可以加-D参数以守护进程方式运行iperf3 -s -D --logfile /var/log/iperf3.log补充一个细节服务端默认只能接受一个客户端连接测试完成后会退出。这是 iperf3 和 iperf2 的一个显著区别。如果你要连续测试多台客户端需要反复启动服务端。嫌麻烦的话可以用一个最简单的循环脚本while true; do iperf3 -s -p 5201; done或者直接每次测完重新运行一次服务端命令。真实场景里我通常直接前台跑因为测试窗口也就几分钟没必要搞得太复杂。什么情况下需要加-i参数-i控制报告的间隔时间比如iperf3 -s -i 1这样每秒输出一次统计信息方便实时观察带宽波动。默认情况下 iperf3 只出最终汇总报告不加-i也能看最终结果但如果链路不稳定中间过程的数据变化对排查问题更有参考价值。4.2 客户端基础测试测单向 TCP 吞吐服务端起来之后在客户端机器上执行最基础的测试iperf3 -c 192.168.1.10这条命令默认持续 10 秒采用单线程 TCP 测试。10 秒结束后输出的报告里最关键的两个数字是Transfer和Bitrate。比如[ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.10 GBytes 940 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 1.10 GBytes 940 Mbits/sec receiver看到940 Mbits/sec这个数值对于千兆网络来说就是正常的。因为千兆以太网的理论上限是 1000Mbps但刨去以太网帧头、TCP/IP 协议开销实际能跑到的极限就在 940Mbps 左右。如果你测出来是 940说明链路质量很好没有丢包重传如果只有 500 多那就要往下查了。Retr字段代表 TCP 重传次数0 说明没有重传。重传次数高说明链路存在丢包可能是网线质量问题、交换机端口错误或者对端负载过高导致缓存溢出。4.3 反向测试和双向同时测试判断链路是否对称很多场景下我们不光要测下行还要测上行。比如服务器向客户端发送数据的速度是正常的但客户端往服务器传数据却很慢这就需要分别测试两个方向。iperf3 的反向测试参数是-R--reverse表示让服务端往客户端发包iperf3 -c 192.168.1.10 -R正常情况下千兆链路的正反向结果应该非常接近。如果单向差距超过 20%优先考虑网卡配置、网线线对问题或交换机端口协商异常。如果要做双向同时测试iperf3 提供了--bidir参数iperf3 -c 192.168.1.10 --bidir这个参数在 3.9 版本里已经支持了。输出结果会分两段显示一段是从客户端到服务端方向一段是服务端到客户端方向。--bidir的价值在于模拟真实业务场景很多应用比如数据库同步、视频会议是典型的双向流量模型。有些交换机在做 QoS 策略或端口限速时只限制了单向这种问题只有双向测试才能暴露出来。4.4 多线程测试压出真实带宽极限单线程测试结果受限于单 TCP 流的窗口和 CPU 单核处理能力尤其在高带宽环境万兆下单线程很难跑满。多线程参数的用法是-Piperf3 -c 192.168.1.10 -P 4-P 4表示同时发起 4 条 TCP 流。输出报告里每条流单独显示最后有一个 SUM 汇总行。比如 4 条流分别是 235Mbps合计就是 940Mbps说明带宽被榨干了。这里有一个实操心得多线程测试结果如果和单线程结果一模一样比如单线程也是 940多线程也是 940说明瓶颈在物理链路如果多线程明显高于单线程说明瓶颈在 TCP 单流限制或者 CPU 单核性能不足。不同情况对应完全不同的优化方向前者查硬件后者查配置。4.5 UDP 测试很多运维容易忽略的关键测试TCP 测试本质上是可靠传输协议网速不好时 TCP 会自动降速来保证不丢包。但在承载语音、视频这类实时业务时UDP 才是真实场景。UDP 测试能暴露链路在无拥塞控制时的真实表现。iperf3 -c 192.168.1.10 -u -b 1000M-b 1000M表示以 1000Mbps 的目标带宽发送 UDP 包。输出的报告里有两个关键指标Jitter抖动和Lost/Total Datagrams丢包率。丢包率是重点[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 114 MBytes 956 Mbits/sec 0.012 ms 1029/87208 (1.2%)如果丢包率在 0% 到 0.5% 之间说明链路质量良好如果超过 1%就需要关注了。特别是你要在上面跑 VoIP、视频会议这类实时业务1% 的 UDP 丢包已经能造成可感知卡顿。UDP 测试的带宽参数-b一定要给目标值否则默认只有 1Mbps测出来的数据没有任何意义。测千兆网络建议-b 1000M测万兆给-b 10000M。如果链路的实际能力达不到目标iperf 会告诉你实际跑了多少这个差值就是链路的上限。4.6 测试时长和间隔别用默认参数就完事-t参数指定测试时长默认 10 秒。10 秒对于排查问题来说太短了尤其是间歇性丢包的问题可能需要 30 秒甚至 60 秒才能暴露。我习惯的做法是iperf3 -c 192.168.1.10 -t 30 -i 5-t 30表示跑 30 秒-i 5表示每 5 秒输出一次中间报告。30 秒足够覆盖绝大多数网络波动场景。如果要做长时间稳定性测试跑 300 秒也不嫌多比如iperf3 -c 192.168.1.10 -t 300 -i 10长测试有个好处能观察带宽是否一直稳定在同一水平线还是每隔几十秒出现一次断崖下跌。造成周期性下跌的原因通常是交换机缓存不足、CPU 温度过高降频、或者链路中有其他流量周期性抢占带宽。5. 一份iperf3测试报告的逐项解读5.1 报告中的关键字段怎么看很多新手看到 iperf3 输出的报告会发懵密密麻麻的数字不知道看哪个。我拆开讲一下最关键的报告字段。TCP 测试报告示例[ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.10 GBytes 940 Mbits/sec 0 sender第一列[ID]是测试流的编号单线程就是 5。Interval是统计时间段。Transfer是这段时间内传输的数据量。Bitrate就是实时带宽单位是 Mbits/sec注意这里用的是 bit 而不是 byte。1.10 GBytes 对应 940 Mbits/sec换算关系是1 Byte 8 bit1.10 GBytes 8.8 Gbits除以 10 秒就是 0.88 Gbps加上协议开销计算就是报告显示的 940 Mbps。Retr是重传次数TCP 发生丢包时会触发重传。重传次数高说明链路不稳定。看到上万的重传次数先查网线、查交换机端口、查光模块光功率大概率能找到问题。UDP 测试报告示例[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 114 MBytes 956 Mbits/sec 0.012 ms 0/81178 (0%)Jitter代表包的到达时间间隔变化单位是毫秒。数值越小越好超过 1ms 就要引起重视。Lost/Total Datagrams是丢包统计括号里是丢包率。0% 是最理想的结果语音业务在 1% 以内基本无感视频会议在 3% 以内可接受超过 5% 就会出现明显花屏和卡顿。5.2 SUM 行和单流行之间的换算关系多线程测试时报告会先列出每一条流的独立数据然后是一个 SUM 汇总。比如-P 4的结果[ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 282 MBytes 236 Mbits/sec 0 sender [ 7] 0.00-10.00 sec 282 MBytes 236 Mbits/sec 0 sender [ 9] 0.00-10.00 sec 282 MBytes 236 Mbits/sec 0 sender [ 11] 0.00-10.00 sec 282 MBytes 236 Mbits/sec 0 sender [SUM] 0.00-10.00 sec 1.10 GBytes 940 Mbits/sec 0 sender四条流各自的带宽加起来正好等于 SUM 的带宽。如果单流之间差距很大比如两条 400Mbps、两条 100Mbps说明负载均衡有问题。常见的原因是网卡多队列没开启导致中断都集中在一个 CPU 核上。用lspci -vvv查网卡是否支持多队列配合ethtool -l eth0查看队列数量可以验证这个判断。5.3 什么样的结果才算正常这个表格是我的个人判断标准不同环境下会有差异但作为初始参考足够了网卡规格TCP测试预期带宽备注百兆94 Mbps 左右以太网协议开销约6%千兆940 Mbps 左右万兆网卡单流可能跑不满万兆3~9.4 Gbps取决于网卡型号和PCIe通道数如果千兆网络测出来的结果只有 80~100Mbps基本可以确定有网线质量问题、协商错误或者端口限速。你跑ethtool eth0如果显示100Mb/s那 94Mbps 就是正常的——但问题本来就出在协商结果上。6. 常见问题与排查技巧实录6.1 防火墙挡掉连接遇到最多的就是这个问题。服务端启动了客户端一执行iperf3 -c直接报错iperf3: error - unable to connect to server: Connection refused这个错误提示其实是两类原因一类是服务端没启动或 IP 不对另一类是防火墙拦截了 SYN 包。如果用telnet 192.168.1.10 5201测试端口都不通先去检查防火墙firewall-cmd --list-ports如果没有放行 5201 端口执行firewall-cmd --permanent --add-port5201/tcp firewall-cmd --permanent --add-port5201/udp firewall-cmd --reload注意 TCP 和 UDP 都要放行因为 iperf3 默认先走 TCP 建立控制连接UDP 测试模式下数据流走 UDP。只放行 TCP 会导致 TCP 测试正常、UDP 测试连不上。另外如果服务器的 selinux 处于 enforcing 模式通常不影响端口监听但如果你用自定义端口最好确认一下 selinux 上下文策略避免遇到怪问题semanage port -l | grep 5201没有semanage命令就先装policycoreutils-python-utils。这一步不是必做但能排除掉一类隐蔽问题。6.2 测速结果远低于预期先别急着怪设备速度不达标时有一个固定的排查顺序确认网卡协商速率ethtool eth0看 Speed。确认网线等级五类线跑千兆是不行的至少要超五类或六类。确认交换机端口是否为自适应状态两端是否都强制千兆全双工。确认网卡驱动是否加载了正确的模块ethtool -i eth0查看驱动版本。确认是否存在其他大流量业务干扰用nload或iftop看一下实时流量。从优先级上看物理层问题排在第一位。我遇到过一台服务器iperf3 只能跑 300Mbps重启后又恢复正常。后来发现是网卡固件过热导致降速补充机柜通风后问题彻底消失。这种间歇性问题最考验耐心如果前四个排查点都正常建议直接跑长时长测试-t 60把波动抓出来。6.3 iperf3 服务端口被默认占用服务端启动时报bind() failed: Address already in use这种错误通常意味着有老进程占用了端口。处理方式lsof -i :5201 kill -9 PID或者用fuser -k 5201/tcp一条命令搞定。在 CentOS 9 里ss -tlnp | grep 5201可以看到占用进程。如果是之前跑的前台 iperf3 没退干净找到 PID 直接杀掉就行。6.4 IPv6 和主机名造成连接失败在一台同时配了 IPv4 和 IPv6 地址的机器上如果客户端直接用主机名连接可能会优先尝试 IPv6 地址而服务端只监听了 IPv4 的 5201 端口导致连接失败。解决办法有两个方案一客户端连接时用 IP 地址而不是主机名iperf3 -c 192.168.1.10方案二服务端同时监听 IPv6iperf3 -s -6还有一种隐蔽的情况两台机器之间有多条路由客户端选择的路径不是最优路径。用traceroute看路径如果经过了不必要的设备查一下路由表。6.5 测速结果高但业务实际慢别死磕iperfiperf 测的是纯网络性能磁盘 I/O、应用层处理能力完全不在 iperf 的辐射范围内。如果你 iperf 测出 940Mbps 但拷贝文件只有 80MB/s问题大概率在磁盘写入速度或 SMB 协议限制上。拿实际业务服务比如 FTP、HTTP、数据库做基准测试才能拿到贴近业务的性能数据。iperf 解决的永远是链路本身够不够快这个问题应用层再慢它也管不着。附再分享一个我常用的批量测试技巧最后分享一个实用小技巧。如果你有多台机器要测手写命令效率太低我一般是直接在客户端机器上写一个简单脚本循环测试多个目标地址#!/bin/bash for ip in 192.168.1.10 192.168.1.20 192.168.1.30; do echo Testing $ip iperf3 -c $ip -t 10 -i 1 done服务端那边用while true; do iperf3 -s; done循环顶着。这样逐台测过去一份报告文件就能对比出所有链路的质量差异。之后如果你还想做更细致的验证可以接着调-w参数指定 TCP 窗口大小或者用--congestion cubic切换拥塞控制算法。但那些都属于进阶玩法了先把基础的 TCP 和 UDP 测试跑明白内网带宽测试这件事你就已经能够应付大多数实际场景了。