“跑分”这个词放在网络设备上很多人第一反应是测速网站或下载工具。但你真拿迅雷下载速度当网络性能证据多半会被现实打脸——同一个千兆局域网下载能跑满文件拷贝却慢得离谱同一台服务器白天测和半夜测结果能差出一大截。这不是玄学而是因为你测的根本不是“网络性能”而是“某个应用在一堆复杂因素下碰巧跑出来的结果”。真正要判断一条链路能承载多大流量行业里通用的办法是用受控流量去打让两端只做一件事一端拼命发一端拼命收。这里最常用的工具就是iperf一个命令行下的老牌网络性能测试工具。它能测TCP吞吐、UDP丢包、抖动、重传也能模拟并发流、反向传输、双向同时传输。这篇文章我打算从实战角度把iperf3的安装、命令、结果解读、排障思路一次性讲清楚适合刚接触服务器互联的新手也适合被“网速明明可以但业务老是卡”折磨的运维。1. 开始跑分前先想清楚iperf要测的到底是谁很多人第一次跑iperf上来就是两台机器敲两行命令结果数字不好看就开始怀疑网线、怀疑交换机、怀疑人生。但在动手之前有一件事比命令本身更重要你得先明确这次跑分到底在测哪一段链路。iperf测的是“端到端可达带宽”这个“端到端”具体是哪两个点完全取决于你的测试拓扑。拿最简单的场景举例主机A直连主机B跑出来的数字是两张网卡加一根网线的能力如果A接到交换机1交换机1再接核心交换机再接交换机2最后才到B那跑出来的就是整个二三层路径的总体吞吐包括所有线缆、端口协商、VLAN标签、以及中间设备有没有做限速。两层拓扑不同同一个iperf命令的含义天差地别。1.1 大文件复制为什么当不了带宽证据先把最常被拿来当借口的东西排除掉很多人觉得“我拷贝一个10GB大文件速度有110MB/s所以带宽没问题”这个推理漏洞很多。第一磁盘是隐藏瓶颈。千兆网口的理论极限传输速率大约是125MB/s但如果你从一块慢速机械盘读数据或者往一块快满的固态盘写数据磁盘速度可能根本撑不满网卡。iperf的结果是“网络栈能跑多快”文件复制的速度是“整套存储加网络系统能跑多快”两者不是一回事。第二文件共享协议有大量交互开销。SMB、NFS这类协议在传输文件时会做权限校验、元数据查询、分块确认小文件场景下协议开销甚至远大于传输本身你会看到一个很低的“网速”但真正的链路带宽一点问题都没有。第三缓存会制造幽灵性能。现代操作系统会把写入数据先塞到内存缓存里然后异步落盘复制刚开始时速度飞快过一会儿突然掉下来你以为这是网络波动其实只是缓存刷完了。所以判断网络带宽不能看“磁盘到磁盘”的复制速度必须把文件系统从链路里摘出去。iperf就是干这个的它让数据直接从发送端内存生成通过网络传输接收端收到后直接丢弃全程不碰磁盘。1.2 iperf的模型内存数据、网络栈和受控流量可以这样理解iperf的工作方式它开一辆空载的测试车在高速路上反复往返只统计道路本身能承受多少车流而不是让你拉着一车货去感受堵车。启动客户端后它会在内存里持续生成数据把数据塞进socket交给协议栈发送服务端接收数据后直接丢弃只做统计。整个过程CPU参与、内存参与、网卡参与但磁盘不参与应用逻辑不参与。正因如此iperf的结果才被认为是衡量网络吞吐能力的标准口径。但这里有个容易误会的点iperf测出来的数字里其实也包含了主机协议栈的CPU处理能力、网卡驱动的转发能力、中断处理能力。也就是说它是“整台主机链路”的综合成绩不是纯物理链路成绩。如果接收端CPU太弱iperf数字低不代表网线不行可能只是接收端主机处理不过来。理解了这一点后面很多诡异结果就都有了解释方向。惯例是把接收方那台机器当作服务端发起方当作客户端。默认情况下iperf3通过TCP协议进行测试因为TCP是绝大多数业务的基础。需要模拟实时音视频这类对丢包敏感、又不用重传的场景时再切换到UDP模式单独看丢包率与抖动。2. 环境铺设两端机器、端口规划和测试方向环境准备没有太多玄学但有几个细节容易让新手卡住半天起不了服务我把它们集中放在这里讲。2.1 安装和版本最容易忽略的坑iperf3在主流系统上都能直接装。Debian/Ubuntu系的机器执行sudo apt update sudo apt install -y iperf3Red Hat系的机器执行sudo dnf install -y iperf3macOS用户可以直接用Homebrew装brew install iperf3Windows下稍微特殊一点没有系统包管理器内置一般去iperf官网的发布渠道拿编译好的二进制解压后就能用。需要注意某些杀毒软件会把其中的exe当作可疑程序因为它会频繁创建socket收发大批量数据这属于误报。验证是否可用很简单命令行输入iperf3 -v能打印版本信息就说明环境OK。版本问题上藏着一个老坑网上大量教程还在用iperf2的语法但iperf3是重新实现的项目虽然命令参数大体相似两端的协议却不互通。如果你服务端装的是iperf3客户端用的还是iperf2那套命令连接会直接失败。测试前建议两端都执行iperf3 -v确认主版本号一致避免浪费时间。2.2 端口、防火墙和拓扑规划iperf3默认监听5201端口测试时控制通道和数据通道都用这个端口。注意TCP测试需要TCP 5201放通UDP测试需要UDP 5201放通这是两回事。很多人在云主机上只给安全组放通了TCP 5201TCP测试没问题切到UDP参数后测试直接跑不起来或者丢包100%还以为是命令写错了。测试前先确认基本连通性可以用ping看网络通不通再用nc -vz IP 5201或者telnet IP 5201确认目标端口能连上。如果是自建机房服务端本机的防火墙也要检查Linux下经常是firewalld或iptables默认策略挡掉了外部访问。规划拓扑时我强烈建议先做一次“分段测试”。具体做法是两台机器用网线直连不经过交换机跑一次拿到物理网卡层的基线成绩。把两台机器分别接入两台交换机再跑一次看交换机转发是否引入损耗。如果还要跨VLAN那就再穿过路由设备测一次看路由策略有没有限速。这样做完哪个环节拖后腿就一目了然。最忌讳的是直接把两台机器丢到三层网络里跑一个数字数字不好看了根本分不清是网线、交换机、防火墙还是路由策略的问题。2.3 判断结果前的“方向感”iperf默认测试的是“从客户端到服务端”这个方向的数据流。如果你想模拟下载场景里的下行流量需要在客户端加-R参数让服务端反过来向客户端发送数据。这看起来只是加个参数但实际操作中有个很容易误判的点同一条链路正向和反向测出来的结果可能有明显差异。原因可能是两端网卡性能不对称、驱动版本不同、甚至服务端主机的接收队列配置不同。所以标准做法是正向测一遍、反向测一遍双向同时再测一遍三个数字都记录。只测一个方向遇到不对称链路时你会得到一张偏科的成绩单。3. 上手命令从一次完整TCP测试到并发、反向与UDP安装好了、方向想清楚了就可以开始真正敲命令了。我把一条条命令按使用频率排序建议你顺序过一遍每一条都理解它存在的意义。3.1 先起服务端再敲客户端先在作为接收方的机器上启动服务端iperf3 -s可以看到监听提示----------------------------------------------------------- Server listening on 5201 -----------------------------------------------------------服务端起来后在另一台机器上执行iperf3 -c 192.168.1.10这里把IP替换成服务端机器的实际地址。默认测试时长是10秒每秒输出一行统计结束后会有一个汇总行。典型的输出片段长这样[ ID] Interval Transfer Bitrate Retr Cwnd [ 4] 0.00-1.00 sec 112 MBytes 941 Mbits/sec 0 1.08 MBytes [ 4] 1.00-2.00 sec 112 MBytes 940 Mbits/sec 0 1.08 MBytes [ 4] 2.00-3.00 sec 113 MBytes 947 Mbits/sec 0 1.08 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr Cwnd [ 4] 0.00-10.00 sec 1.08 GBytes 930 Mbits/sec 0 1.08 MBytes一眼就能看出这是一条接近千兆的链路全程没有TCP重传拥塞窗口也稳定属于非常健康的状态。如果看到的数字只有两三百Mbits/sec后面几节的内容就是给你准备的排查清单。3.2 加时长、并发和预热时间默认10秒测试在绝大多数场景够用但要排查稳定性问题我建议拉长到30秒同时开4条并发流并跳过最开始的5秒统计iperf3 -c 192.168.1.10 -t 30 -P 4 --omit 5-t 30表示跑30秒-P 4表示同时建立4条TCP流--omit 5表示统计时跳过前5秒。为什么要开并发流现代服务器CPU可能有多核、多队列但单条iperf流在多数情况下只能占用一个核来处理收发中断这时候即使链路带宽是10Gbps单流也会被钉在单核性能上跑不上去。开4条流可以同时让多个CPU核心参与吞吐往往会有明显提升。这属于主机性能瓶颈导致的结果偏低不是链路本身的问题。“跳过前5秒”则是为了消除TCP慢启动阶段的影响。TCP刚建立连接时要先经过慢启动探测链路容量前一两秒的速率会低一些。把这段剔掉其结果更接近稳定传输状态。3.3 反向和双向搞清上传下载的真实差距反向测试直接在客户端加-R即可iperf3 -c 192.168.1.10 -R这条命令测的是服务端发数据到客户端的方向。配合默认方向两条命令就能解释“为什么上传下载速率不对称”。如果业务场景要求双向同时传输比如监控视频并发回传、数据库主备同步用双向模式更接近真实负载iperf3 -c 192.168.1.10 --bidir双向模式的输出会同时出现两个方向的统计注意看的时候不要只盯第一个结果要把两边的带宽、重传、抖动都摘出来对比。有些老教程写的是-d参数新版iperf3也兼容但我个人更习惯写--bidir语义清晰不容易记混。3.4 UDP专项延迟、抖动和丢包怎么测很多实时业务走的是UDP不会像TCP那样丢了重传因此TCP测出来的带宽安好不等于视频会议不卡顿。UDP测试通常指定一个目标发送速率让客户端以该速率向服务端灌流量iperf3 -u -c 192.168.1.10 -b 500M -t 15-u表示UDP模式-b 500M表示以500Mbps的速率发包。服务端输出会多出两列Jitter抖动和Lost/Total Datagrams丢包统计。典型片段[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 4] 0.00-15.00 sec 705 MBytes 394 Mbits/sec 0.023 ms 297/21314 (1.4%)这里客户端按500Mbps发包服务端只收到394Mbps有1.4%的丢包说明链路在500Mbps压力下已经出现拥塞。UDP模式下重点不是看那个Bandwidth数字有多高而是看你在目标速率下网络能不能兜住。如果你指定的速率超过链路上限丢包必然出现这是用来压测极限和判断承载能力的手段。4. 结果解码吞吐、重传、抖动这些数字的意义命令行跑通了下一步是读懂结果里的每个字段。很多人只看到最后一行的带宽忽略Retr和Cwnd结果吞吞吐吐匹配不上实际体验。4.1 输出字段逐项拆解以iperf3较新的输出为例逐列解释字段含义我通常怎么用Interval统计区间默认1秒一次看整个测试周期内吞吐是否平稳Transfer该区间内实际传输的数据量与后面的带宽互相验证防止单位换算出错Bitrate/Bandwidth换算成每秒比特数的带宽最直观的吞吐指标RetrTCP重传次数重传高说明链路有拥塞或传输错误CwndTCP拥塞窗口大小数值持续很小说明窗口没撑开可能有缓冲瓶颈Jitter数据包到达时间间隔的波动实时语音视频场景特别关注Lost/Total DatagramsUDP测试中丢失包数/总包数计算丢包率判断链路在指定速率下是否健康还有个小细节每次测试结束客户端会打印一行sender统计服务端会打印一行receiver统计。TCP测试中以接收方统计为准。因为发送方统计的数据已经交给了协议栈但其中一部分可能还在途或者已经丢了接收方统计的是真正到达对端协议栈的数据更接近链路实际承载能力。如果sender和receiver两个数值差得很大说明重传和丢失很多链路状态值得警惕。4.2 数字之间的关联和常见误读单个数字不好判断问题要看几组数字的组合关系。我总结过几类典型模式看到的现象我首先怀疑什么带宽很高但Retr也很多链路存在拥塞TCP反复丢包重传实际应用会感到不稳定带宽低但Retr基本为0大概率是主机CPU单核瓶颈或TCP窗口过小链路本身未必有问题多流比单流带宽高出很多单流被单核性能绑住了优先查看CPU中断分配反向比正向差两端网卡或驱动性能不对称重点看接收端主机UDP丢包高但TCP表现正常中间设备可能对UDP流量做了更严格的QoS策略网络性能问题很少是单一因素多组数据交叉着看才能定位到“链路容量”和“主机能力”的边界。4.3 多次测试与稳定值判断我只跑一次不敢下结论。网络链路存在瞬时波动一次测试可能正好撞上拥塞窗口收紧、交换机突发缓存占用单次结果并不代表性。我的习惯是同一个参数跑三次记录三次带宽值取中位数作为参考。如果三次结果的最大值和最小值相差超过15%这链路多半存在明显不稳定因素需要进一步看每一秒统计的波动趋势。把统计间隔调小到0.5秒可以更清楚地看到瞬间变化iperf3 -c 192.168.1.10 -t 10 -i 0.5如果看到前面秒数吞吐高、后面突然腰斩那就要怀疑交换机缓存不足或TCP窗口被限流机制压制了。5. 实测里最容易翻车的四个场景这部分是我觉得整篇文章里最有价值的部分。很多人在网络上各种背命令一到现场还是翻车原因就是踩了这些隐形坑。5.1 网卡协商速率和双工模式是最大的幕黑手先检查服务器网卡当前协商结果。Linux下执行ethtool eth0关注Speed和Duplex两行。正常千兆网卡应该看到1000Mb/s和Full。如果看到100Mb/s那iperf跑到后来怎么测都超不过百兆如果看到Half说明双工模式协商失败网卡可能不停出现冲突TCP重传会高得吓人。出现降速时先换网线再换交换机端口最后看网卡驱动里是否被强制设定了速率。很多自协商问题换根线就好这没太多技术含量但确实是最常见的翻车原因。Windows下可以在网卡状态里看“速度”PowerShell也有命令能查出LinkSpeed字段。5.2 CPU单核瓶颈链路没满主机先满了我遇到过最尴尬的一次是测10Gbps网卡链路和网卡都支持但iperf不管怎么跑都在4Gbps左右上不去。检查top之后发现业务机器上一个CPU核已经烧到100%其余核都在闲逛——典型的单流被单核绑定。解决方法有几个方向跑iperf时增加并发流让多核分担尝试调整网卡队列数RSS多队列把中断分散到多个CPU核或者在服务端用taskset把iperf进程绑到不同核上配合-P并发流让吞吐不再被单个核卡死。验证也很简单测试过程中另开一个窗口跑mpstat -P ALL 1看各核使用率。如果某颗核持续占满基本可以断定瓶颈在主机不在线路。5.3 防火墙、限速策略和DPI设备防火墙放行端口但不代表转发性能就一定好。很多企业防火墙默认开启了深度包检测逐包去做应用识别一开DPI吞吐直接掉两三成。测试性能时最好先关掉应用识别规则测完再恢复否则把防火墙的DPI能力算进“链路损耗”里就冤了。另外云安全组、交换机QoS队列、带宽策略这些也会对iperf流量生效。如果你发现UDP测试丢包特别严重但TCP测出来还算正常往往就是中间设备对UDP流量做了单独限速或丢弃策略。可以试着换一个端口测试排除掉端口策略的影响。5.4 虚拟化层的叠加损耗虚拟机里跑iperf测出来的不仅仅是物理链路能力还包含宿主机虚拟交换机、虚拟网卡驱动的开销。同一台物理机虚拟机间通信和物理机间通信的结果经常相差很大。这不是iperf跑错了而是你必须界定清楚自己在测哪一层。如果目标是评估虚拟机上的业务网络性能那在虚拟机里测没问题这就是真实的业务视角。如果目标是评估物理网络硬件能力那就应该到宿主机上跑不要隔着一层虚拟化看数字。容器场景同理bridge网络模式会引入NAT和端口映射开销做硬件性能基线测试时建议先用容器宿主机直跑再考虑容器内的结果。5.5 MTU与分片问题跨网段或经过某些封装设备时MTU可能被调小导致iperf默认的较大TCP包触发IP分片甚至被丢弃。表现就是带宽极低或者测试根本跑不起来。先用ping探测一下路径MTUping -M do -s 1472 -c 3 192.168.1.10能通说明路径MTU至少支持1500不通或提示需要分片就把包体减小再试。如果确认MTU有问题可以在iperf里指定TCP最大段大小绕过路径MTU限制iperf3 -c 192.168.1.10 -M 1400这个参数能解决不少“网速离奇慢”的疑难杂症。不过MTU问题在纯局域网里相对少见跨复杂网络时优先想起来查一下就行。做完上面这些排查再回头看看iperf输出里那串数字你会发现大部分怪问题都能从“链路容量”和“主机处理能力”两个方向归因。跑分只是前戏能够解释跑分结果并对症下药才是网络性能测试的真正意义。我自己的习惯是每次测试都做一个简短记录时间、两端IP、服务端和客户端版本、TCP还是UDP、单流还是多流、方向是正向还是反向、跑了多久、最终的吞吐和重传。把这些固定下来下次再遇到“网络变慢”的反馈直接拿历史结果对比很多争论都能少掉一大半。