监控画面卡顿花屏先查传输协议：RTSP 的 UDP、TCP、HTTP 怎么选
痛点场景
监控平台上总有那么几路画面不给力：预览时一顿一顿，图像出现碎片、丢帧，或者延迟大到人在镜头前走了三秒画面才动。硬盘没报警、网络表面上也通，问题到底出在哪？
官方知识库把这个场景讲得很直白：由于网络环境和设备之间的差异，Surveillance Station 可能无法提供最佳播放质量。解决思路不是换摄像机，而是根据具体需求，到摄像机的高级设备设置里调整 RTSP 传输协议，让它匹配实际网络状况。
入口在哪
打开网络摄像机的编辑摄像机窗口，进入：
设备 > 高级 > RTSP 和 RTP 设置
在这里的传输协议下拉菜单中，根据摄像机功能和所选编码方法，会看到它支持的协议项目——通常包括 UDP、TCP、HTTP 与自动四类。
四个选项各自的脾气
UDP：延迟最低，但经不起折腾
- 优点：图像延迟较低，实时性最好；
- 软肋：网络环境较差、或设备之间隔着许多路由器时，数据包可能丢失，导致图像碎片或丢帧——花屏大概率就是它；
- 对策：改善网络环境、减少设备之间的节点（路由层级）。
适合网络质量好、跳数少、追求实时预览的局域网环境。
TCP：稳定可靠，但吃带宽
- 优点：提供稳定且可靠的连接和图像质量，不丢包；
- 软肋：网络带宽不足时延迟较高——画面完整但慢半拍；
- 对策：提高网络带宽来压低延迟、增强即时性。
适合带宽有富余、图像完整性优先于实时性的场景，比如回放与取证为主的点位。
HTTP：能穿防火墙，但代价不小
- 优点：视频串流可以穿过防火墙的限制——这是它存在的理由；
- 软肋：与其他协议相比占用更多网络带宽和系统资源，可能导致较高延迟；
- 官方建议：对于不需要流量通过防火墙或防火墙规则的环境，建议选择 UDP 或 TCP，没必要付这笔额外开销。
自动：按顺序试，断线用老路恢复
选择自动时，Surveillance Station 将按 UDP > TCP > HTTP 的顺序尝试建立 RTSP 连接。如果摄像机断开连接，系统会使用最后使用的协议来恢复连接。
拿不准环境状况时选它，让系统自己挑能通的那条路。
一张表选型
| 协议 | 延迟 | 画质稳定性 | 带宽占用 | 适配场景 |
|---|---|---|---|---|
| UDP | 低 | 网差时碎片丢帧 | 低 | 局域网、跳数少、求实时 |
| TCP | 带宽不足时高 | 稳定可靠 | 中 | 带宽充裕、完整性优先 |
| HTTP | 较高 | 稳定 | 高 | 流量必须过防火墙 |
| 自动 | 视命中协议 | 视命中协议 | 视命中协议 | 环境不明、先跑起来 |
调整后的验证
改完协议回到实时预览，连续观察几分钟：碎片和丢帧是否消失、延迟是否在可接受范围。多路由层级的环境里，逐路调整比一刀切效果好——每台摄像机面对的网络路径不同，协议选择本就该因地制宜。若选 UDP 后仍丢帧，说明该优化的是网络本身：减少中间节点、排查劣质线缆和拥塞的上联口，而不是继续在协议菜单里打转。
预防与注意
- 新点位上线时，先看一眼传输协议的默认值是否与该点位网络条件匹配，别等值班员抱怨画面卡才回头查；
- 跨防火墙取流是 HTTP 的专属场景，其余环境按官方建议优先 UDP 或 TCP；
- 选「自动」的点位如果频繁断线重连，留意它最后命中的是哪一档协议——那往往暴露了网络质量的真相；
- 编码方法改变后，下拉菜单里的可选项可能变化（官方说明可选项取决于摄像机功能与所选编码方法），调整前先确认当前编码配置。
监控画面的“小毛病”背后常常是协议与网络的错配——把传输协议这颗螺丝拧对位置，很多“该换设备了”的问题其实不用花钱。