国标设备接入时，“传输协议”那一栏往往是最被轻视的选项。它不像设备编码填错那样立刻报错，也不像密码错了那样马上登不上。它的麻烦在于：上线当天一切正常，三个月后才开始陆续出问题。

1、上线那天一切正常，三个月后开始出事

先还原一条在交付现场反复出现的时间线。

第1天，设备接入，画面出来，通道列表齐全，验收通过。工程师收工，剩下的一句交代通常是“先跑着看”。

第2周，偶尔有那么一两台设备显示离线，重启一下又好了。没人在意——设备嘛，偶尔抽风很正常。

第1个月，晚上并发高的时候开始花屏、卡帧，白天又恢复正常。甲方反馈，工程师回复“网络问题”，双方都觉得合理。

第2个月，某个片区换了宽带运营商，那批设备集体注册不上，或者注册上了点播黑屏。这时候才发现，之前那批“偶尔抽风”的设备，全都在同一个网段。

第3个月，甲方要调两个月前某天某段时间的录像做取证，回放进度条卡住，或者干脆拉不出流。

把这几件事串起来看，共同特征很清楚：没有一件是平台“坏了”，全都是接入时的协议选型与现场网络条件不匹配，问题被网络波动放大之后才暴露出来。

而它的代价之所以高，是因为排查要横跨三段——设备端、网络链路、平台侧。每一段都有各自的负责人，每一段都能给出“我这边看起来没问题”的证据。最后承担出差、协调和解释成本的，往往是当初做选型的那个人。所以这不是一个可以“先跑着看”的选项。

2、先分清：GB28181里有两条链路，不是一条

讨论UDP还是TCP之前，必须先把一件事情讲清楚：国标接入里跑的是两条不同的链路，它们的作用、流量特征、故障表现都不一样。

第一条是SIP信令链路。负责设备注册、心跳保活、点播与回放请求、云台PTZ控制、录像检索，以及上下级平台之间的级联。国标GB28181公网平台EasyGBS的国标信令引擎原生封装了GB28181的2016与2022等版本，负责处理的正是这条链路上的全部交互。信令数据量很小，但它是“设备在不在线、指令能不能下得去”的决定性因素。

第二条是RTP媒体流链路。真正的音视频数据走这条路。它的数据量是信令的几百上千倍，直接决定“画面清不清楚、流不流畅”。

这里有一个容易被忽略的性质：GB28181的信令是有状态的。一旦SIP连接成功，就形成了Session绑定关系，后端服务节点需要长期保持这条SIP连接（无论是UDP还是TCP）的状态，中途无法变换服务节点。

国标GB28181设备管理软件EasyGBS的SIP网关模式就是在这个特性上做的设计：前端用统一的SIP网关作为唯一信令入口，按负载均衡策略把设备会话分配到后端节点并保持绑定；而RTP媒体流由国标设备与分配到的节点直接建立连接，点对点交互，不经过网关。网关盯得住信令，媒体流不占网关带宽。

理解这一点之后，选型问题的表述就更准确了：

• 信令链路的选型，决定“设备在不在”；
• 媒体链路的选型，决定“画面好不好”。

两者需要一起决策，但排查时可以分开看——这也是后面故障对照表的依据。

3、四个环节上的真实差别

下面按注册、保活、点播、回放与云台四个环节，把两种协议的差别讲具体。需要说明的是，UDP无连接、无重传、开销小，TCP面向连接、可靠重传、有队头阻塞——这部分属于通用网络原理，任何一种传输层选型都绕不开这两组特性。

注册环节。

UDP模式下，设备发一个REGISTER，平台回一个响应，一次交互即完成，速度快、开销小。但设备侧并不存在“连接”这个概念，国标GB28181视频平台EasyGBS平台只能靠后续心跳来判断设备是否还活着。TCP模式下，设备先与平台建立长连接再注册，平台能通过连接状态感知到设备断开，离线判定更快也更准，代价是每台设备都会占用平台侧一条长连接。

保活环节。

这是最容易埋雷的地方。UDP完全依赖周期性心跳，而心跳间隔与NAT映射老化时间的配合是关键——心跳发得太稀疏，运营商或防火墙已经把NAT映射回收了，但平台因为没到判定超时的时间，界面上还显示“在线”。等到有人去点播，才发现根本打不通。TCP则不同，连接本身就是保活线索，配合应用层心跳，掉线感知要实时得多。

点播环节。

UDP没有重传机制，丢包会直接体现在画面上——花屏、马赛克、卡帧，网络质量好的时候它的时延是最低的。TCP可靠传输，丢包会重传，代价是重传期间时延会累积。弱网环境下两种模式的观感完全不同：UDP是“画面碎但不延迟”，TCP是“画面完整但滞后几秒”。

安防场景里绝大多数人更能接受前者，但如果你要的是事后取证的完整性，结论会反过来。

回放与云台控制环节。

回放是持续大流量场景，UDP下的丢包会被明显放大，表现为进度条卡顿、拖动后长时间缓冲。云台与控制指令走的是SIP信令，在UDP模式下，极端网络状况中指令存在丢失可能，典型表现是“点了没反应，再点一次又动了”——很多人把这当成平台卡顿，其实是信令丢了。

4、决策表：什么网络条件选什么

国标GB28181软件EasyGBS在协议接入层兼容TCP/UDP双向传输，同时适配海康、大华、宇视、天地伟业等全品牌设备。既然两种都支持，选型就可以完全按网络条件来定，而不是按习惯来定。

有一点要单独说明。表里倒数第二行——设备没有公网IP的情况，在实际项目里占比很高，而且它不是一个“换个协议”就能解决的问题。这类点位在运营商内网、路由器端口不可动、防火墙不放行，人还跑不到现场。正确的顺序是：先让链路可达，再在可达的基础上做协议选型。

另外补充一个常被忽略的约束：信令在TCP模式下是长连接。

点位规模上去之后，长连接数量、内存占用、单节点的信令处理能力都会成为新的上限。这也是国标GB28181公网平台EasyGBS引入SIP网关模式的原因之一——把注册、保活、信令交互的压力分散到多个后端节点，媒体流仍然由设备与节点直连，不形成新的瓶颈。

5、切换前后：怎么验证，怎么对照故障

选型定了，不代表事情结束。切换这个动作本身是有风险的，需要有明确的验证步骤。

切换前，先把四件事做实。

• 第一，确认平台侧与设备侧的协议配置是一致修改的，而不是只改了一边。
• 第二，按实际部署的端口信息表，逐一确认防火墙与端口映射放通的是对应协议，UDP与TCP的端口策略不能混用。
• 第三，选择业务低峰时段操作，并预留回退窗口——如果切过去问题更大，能在最短时间内切回来。
• 第四，切换前记录一组基线数据：在线设备数、点播首帧耗时、24小时内的离线次数。

切换后，按这个顺序验证。

• 先看设备是否全部重新注册成功，在线数与基线是否一致；
• 再随机抽查点播，重点挑跨网段、跨运营商的那几路；
• 然后测云台控制，连续操作看有没有丢指令；
• 接着做一次历史录像回放，验证回放链路；
• 最后观察满24小时，重点看夜间并发高峰的离线与花屏情况是否有改善。

常见问题对照表。

国标视频分析平台EasyGBS提供日志全量留存、SIP报文诊断与设备故障自动告警能力，上面这些排查动作里凡是涉及“看信令到底发生了什么”的，都应该以平台侧SIP诊断记录为准，而不是靠现场猜。