"交换机灯亮着、摄像机也在线"不等于网络合格。视频监控对网络的要求和网页浏览不一样：它是持续的高码流传输，丢包、抖动、带宽不足都会在画面上直接体现为卡顿、马赛克甚至录像断档。验收和排查时，与其凭感觉，不如用 iperf3 把链路测一遍。本文讲四个指标、测试方法和结果判读。
四个指标：分别说明什么问题
链路质量体检看四个数，各有各的含义：
- 吞吐：单位时间实际能传多少数据，决定带宽是否够用。监控链路常按"路数×单路码率"估算需求，实测吞吐要能覆盖这个值。
- 丢包率：传输中丢失数据包的占比。视频用的 UDP 不自动重传，丢包直接表现为画面缺损，是监控最敏感的一项。
- 延迟：数据包单程传输时间，局域网内通常毫秒级，过高说明链路绕路或设备处理慢。
- 抖动：延迟的波动程度，决定画面流畅性，抖动大表现为"一卡一卡"而不是整体慢。
这四项要一起看：吞吐够但丢包高，画面照样花；延迟低但抖动大，也会周期性卡顿。只测一项容易误判。
iperf3 基础用法：两条命令跑起来
iperf3 是链路测试的常用工具，两台设备各装一份，一台做服务端、一台做客户端。核心命令三条：
- 服务端启动监听：
iperf3 -s（默认监听 5201 端口）。 - 客户端默认 TCP 测试：
iperf3 -c <服务端IP>，默认跑 10 秒，输出吞吐。 - 客户端 UDP 打流测试：
iperf3 -c <服务端IP> -u -b 100M -t 30，按目标带宽打流 30 秒，看真实吞吐和丢包率。
正式测试时长建议拉到 30 秒以上，短期测试容易被拥塞窗口波动影响，看不出稳定性能。并发参数 -P 先默认 1 测单流基准，再用 -P 2 或 -P 4 看多路并发时链路是否吃紧——一路流跑得满不代表 16 路都跑得满。
监控网络怎么测：场景与步骤
按验收场景组织测试，建议这样跑：
- 把笔记本接到 NVR 所在的核心或汇聚交换机上做服务端；另一台笔记本接到接入交换机侧做客户端，可临时占用未来装摄像机的网口。
- 先跑一条 TCP 单向测试，看链路基准吞吐（读服务端 Bitrate 输出，注意 retr 重传计数字段，数字大说明链路已开始丢包）。
- 再跑 UDP 打流，发送带宽按该链路预期需求的 1.2–1.5 倍设置，比如 16 路 400 万 H.265 估算需求 64Mbps，就用
-b 80M打流，看 10–30 秒内的丢包率。 - 换方向再测一遍：监控流量以摄像机→NVR 的上行为主，客户端放在摄像机侧、服务端放 NVR 侧的顺序更贴近真实流向。
- 配合 ping（看 RTT 与丢包）和现场画面预览（肉眼确认）交叉验证，测试结果和实际观感对得上才算数。
结果怎么判：参考口径与常见问题
判读没有放之四海的标准，给参考口径：有线局域网的丢包率应尽可能接近零（低于 1% 属可接受范围，具体以业务要求为准），吞吐不低于该链路所有并发码流总和的约 1.2 倍（含协议开销）；延迟在局域网环境通常个位数到十几毫秒，专线或跨城链路另算；抖动越小越好，实时传输场景通常要求毫秒级稳定。
测出问题按位置分层：整段都掉吞吐，查交换机端口协商、线缆和水晶头；丢包集中某一路，换一条线或换交换机端口排除单点；延迟突然升高，看是否中间有设备在做深度包处理或环路。链路测试是排查的定位器，把问题锁定在"链路"还是"设备"，后面就不用瞎换硬件。
与业务联动：卡顿排查里的链路定位
录像回放大量花屏、实时预览周期性卡顿，先把摄像机侧到 NVR 侧这一段测一遍链路段：若链路达标，问题指向供电、设备解码或录像机本身；若链路不达标，按丢包和吞吐数据定位到具体链路点处理。把 iperf3 测试固化成监控项目验收流程的一部分，会比"装完看画面没问题就交付"可靠得多——高峰期和低峰期的链路表现往往差别很大，有条件就在业务空闲期实测一次、高峰时段再复测一次。
参考资料
iperf3 网络测试实战指南（服务端/客户端参数、UDP 打流、指标解读）、实时音视频弱网指标分析（丢包率、延迟、抖动对画面的影响）、监控链路带宽与延迟优化技术文档。
TL;DR
- 四项指标一起看：吞吐管够不够、丢包管花不花、延迟管快慢、抖动管流畅。
- iperf3 三条核心命令：
-s服务端、-c客户端、-u -bUDP 打流，时长拉到 30 秒。 - 上行方向先测（摄像机→NVR），多路并发用
-P 2/4复测，retr 重传多说明已丢包。 - 参考口径：有线丢包尽量接近零，吞吐覆盖码流总和 1.2 倍以上。
- 链路达标仍卡，问题转向供电、解码和录像机；不达标按丢包位置分层定位。
参考资料
- video-network-design
- video-lag-troubleshooting
- bandwidth-storage-calc
- onvif-debug