iperf3：这条网线到底能跑多少，别猜，测

它到底解决什么

展厅方案里有一句话经常出现：「网络采用千兆交换机，带宽满足需求。」

这句话在纸面上没问题，在现场经常不成立。原因很具体：

• 网线不达标。 施工时用的线材、水晶头压接质量、线路长度，任何一项不到位，千兆口跑出百兆速率是常事。而这个降速是静默的——网卡显示连接正常，你不测就不知道。
• 交换机是瓶颈。 标称千兆的低端交换机，在多口同时满负荷时背板转发能力可能撑不住。
• 中间有老设备。 链路里串了一个百兆的小交换机、一个老的网络转换器、或者一段老布线，整条链路就被卡在那个速率上。
• VLAN 或路由绕远了。 看起来是同一栋楼，实际数据绕到了核心交换机再回来。

这些问题的共同表现是：上了多路视频流之后画面卡顿、音频断续，而排查时你会在播控软件、素材码率、机器性能上花大量时间——因为"网络是千兆的"这个假设从一开始就没被质疑过。

iperf3 做的事很直接：在两台机器之间实际跑一遍数据，测出这条链路真实能跑多少。 它是开源工具（BSD-3-Clause，源码在 GitHub 的 esnet/iperf），三大平台都有，测一次十分钟。

十分钟换掉一个可能导致整个方案返工的假设，这个投入产出比在展厅项目里是最好的之一。

展厅哪道工序会用到它

方案阶段的可行性验证。 如果方案要上 NDI、Dante、多路 IP 视频，先到现场（或者跟甲方要网络条件）测一测。带宽不够的话，方案要改——加交换机、换线、或者改用其他传输方式。这个发现越早越好，施工完再发现就是重新布线。

施工完成后的验收。 布线做完，逐段测。这一步能发现施工质量问题——某条线跑不满，就是那条线有问题，可以要求施工方返工。这个证据比"我觉得网速慢"有力得多。

故障期的证据收集。 现场卡顿，测一下带宽。够，那问题不在网络；不够，找到是哪一段的瓶颈。

交付报告的一部分。 把各段链路的实测吞吐写进交付文档。这既是专业性的体现，也是日后出问题时的基线——半年后再测一次，跟基线一比就知道是不是网络劣化了。

怎么获取

官网 iperf.fr，三大平台都有，开源免费。

它是命令行工具，没有图形界面。这一点对不习惯命令行的人有门槛，但实际用到的命令只有两三条，记下来就行。

要准备两台机器——一台当服务端，一台当客户端。这是它的工作方式决定的：测的是两点之间的链路，所以两头都要有。

最短可用路径

最基本的用法只有两步：

1. 在一台机器上启动服务端：命令行执行 iperf3 -s，它开始监听等待。
2. 在另一台机器上启动客户端：执行 iperf3 -c 服务端IP，它开始发数据，几秒后给出测试结果。

结果里的关键数字是 Bitrate（速率）——这就是这条链路的实际吞吐。跟你预期的对比一下。

几个常用的变化：

• 测得久一点：加 -t 30 测 30 秒。默认时间较短，链路不稳定时短时间测不出问题。
• 测反方向：加 -R 反过来测。上行下行速率不一定对称，尤其是过了某些设备之后。
• 测 UDP：加 -u 并指定目标速率。展厅的组播视频流走 UDP，这个测试更接近实际场景，而且能看到丢包率——丢包率对视频流的影响比带宽更直接。

注意防火墙：服务端要放行 iperf3 用的端口，否则客户端连不上。这是最常见的"跑不起来"原因。

展厅工程里真正要改的那几个设置

测试要覆盖真实的路径。 这一点最容易做错：两台笔记本插在同一台交换机上互测，结果很好看，但这不代表从机房到三楼展项那条路也好。要按实际的业务路径测——播控机在机房，屏在三楼，就把两台测试机放在这两个位置。

分段测，找瓶颈。 端到端测出来不够，就分段：机房到楼层交换机测一次、楼层交换机到展项测一次。哪一段掉下来，问题就在那一段。

测的时候要在非营业时间。 满负荷测试会占满链路，正在跑的业务会受影响。展厅运营期间千万别测。

UDP 测试要看丢包率。 展厅的视频流很多走 UDP 组播，这类流量对丢包敏感——丢一点点包，画面就有明显的花屏或卡顿。TCP 测试因为有重传机制，掩盖了丢包问题。所以视频流场景要专门测 UDP。

结果要记进交付文档，含测试条件。 什么时候测的、从哪测到哪、用了什么参数、结果是多少。没有条件的数字是没有意义的。

踩坑与排错清单

什么时候别用它

延迟问题别用它。 它测吞吐量。如果现象是"控制指令响应慢"而不是"画面卡"，那多半是延迟问题，用 PingPlotter 看延迟和抖动更对路。

要找出谁占了带宽别用它。 它只告诉你"这条路能跑多少"，不告诉你"现在谁在跑"。流量分析要用 Wireshark 或者交换机的流量统计。

运营时段别测。 前面说过。

无线链路的结论要谨慎。 无线的速率受干扰、距离、终端数量影响，单次测试的代表性有限。展厅的关键链路本来也不该走无线。

与本站方案的衔接

网络实测这件事的价值在于把假设变成数据。展厅项目里这类假设还有很多：机器性能够不够、硬盘读得动吗、散热撑得住吗、电源余量有多少。它们的共同点是——不测就不知道，出了问题才发现代价很高。

企服君在交付规范上主张把这类基线数据做成标准动作：网络吞吐、机器温度、硬盘速度、启动时长，交付时测一遍写进文档。这些数字在一年后就是判断"是不是劣化了"的唯一依据。集成商如果想让运维有据可依而不是靠感觉，这一层是基础——见集成商年费方案。

展厅网络的整体规划见展厅网络怎么规划：网段、隔离、带宽够不够；网络风暴类问题见网络风暴怎么处理。