TCP 与 UDP 网络控制速查（展厅设备对接）
依据 TCP/UDP 公开网络标准整理，适用于带网口的展厅设备控制对接。具体设备的端口、报文格式与协议细节以设备手册为准。
从一次”命令时灵时不灵”说起
展厅新上了一台网络电源，中控发开关命令，十次里有一两次没反应，重发又好了。你可能先怀疑设备，其实病根常在传输方式选错或用错。如果这条控制命令走的是 UDP——一种”发出去不管到没到”的方式——网络稍一拥堵丢个包，命令就悄无声息地消失了，设备当然没反应。控制命令这种”必须送到、送错一次就出洋相”的场景，本该用 TCP。TCP 和 UDP 是网络控制的两条腿，选对了控制才稳。它们不难，难在很多人分不清什么场景该迈哪条腿。这篇把两者的区别、报文怎么切、心跳怎么加、展厅里怎么选讲透。
网络控制是什么
越来越多展厅设备——播放器、矩阵、网络电源、中控盒子、时序器——都带网口，支持网络控制：中控朝设备的 IP + 端口发一段控制报文，设备照做或回应。这层传输之下，无非两种送法：TCP（面向连接、可靠）和 UDP（无连接、快但不保证）。把它俩想成寄东西：TCP 像挂号信，签收回执、丢了重寄、按寄出顺序到；UDP 像往窗外扔传单，扔得快、成本低，但谁收到、收没收到、先收哪张，一概不管。选哪个，取决于你这条报文”丢一次会不会出事”。
TCP vs UDP 核心区别
| 项目 | TCP | UDP |
|---|---|---|
| 连接 | 面向连接（先三次握手建连） | 无连接（直接发） |
| 可靠性 | 可靠、有序、丢包自动重传 | 不保证送达，不保证顺序 |
| 数据形态 | 字节流（无天然消息边界） | 数据报（每个包是独立一条） |
| 开销 / 延迟 | 较高（握手、确认、重传） | 低 |
| 一对多 | 不支持（一连一） | 支持组播 / 广播 |
| 典型用途 | 控制指令、需确认的交互、状态查询 | 组播同步、状态广播、低延迟推送 |
一句经验法则：要”确保送到、按序执行”的控制指令，优先 TCP；要”一对多、抢低延迟、丢一两个无所谓”的广播或同步信号，才用 UDP。展厅里绝大多数设备控制走 TCP，UDP 主要出现在多屏同步、组播下发这种特殊场景。
粘包与拆包：TCP 用得好的关键
TCP 最容易坑新手的一点：它是字节流，没有天然的”一条消息”边界。 你连着发两条命令 AA01 和 AA02，对端可能一次性收到 AA01AA02 粘在一起（粘包），也可能先收到 AA0、再收到 1AA02（拆包）。为什么？TCP 只保证字节按序不丢，不保证你发一次对方就收一次——网络会把数据攒着或拆着传。设备命令时灵时不灵、偶尔解析出乱码，十有八九是粘包没处理。 解决靠在应用层约定消息边界，常见三招：
- 固定长度：每条命令定长（比如都是 8 字节），收满 8 字节切一刀。简单，但命令长度不一时浪费。
- 分隔符：用回车 CR、换行或特殊字节收尾（PJLink 的 CR、很多 ASCII 协议就这样），读到分隔符就切。
- 长度前缀：报文头先放一个字段写明”本条正文多少字节”（Modbus TCP 的 MBAP 头就带长度字段），先读长度再按长度收正文，最稳最通用。
写中控驱动时，务必按设备协议约定的这套边界规则切分，不能”收到一坨就整个当一条命令解析”。
心跳保活：长连接为什么会莫名断
TCP 建了长连接不代表能一直用。中间的路由器、防火墙、NAT 设备会给”看起来没数据往来”的连接设个空闲超时，几分钟没动静就悄悄把它掐了——两头都以为连着，下次发命令才发现连接早死了。 对策是心跳保活：控制端每隔一段（比如 30 秒到几分钟，看设备和网络环境）朝设备发一个无害的小报文（很多设备有专门的心跳/查询命令，没有就发个查状态命令），既让中间设备觉得”这连接还活着”别掐，也能第一时间发现链路断了好重连。展厅长期挂着的设备连接，心跳几乎是标配。
组播与 UDP：多屏同步的场景
UDP 在展厅真正的用武之地是一对多低延迟。典型是多屏 / 多投影拼接要求画面严丝合缝同步：一台主控往一个组播地址发同步信号，几十台播放器同时收到、同步刷帧。用 TCP 就得跟每台单独建连一条条发，延迟和抖动都上来了，画面会错拍；UDP 组播一次发全体同时收，延迟低且一致。代价是丢包不重传——所以它只用在”丢一帧同步信号无伤大雅、下一帧就纠回来”的容错场景，绝不用来发”必须执行”的控制命令。状态广播（一台设备把自己的状态往网段里吼一嗓子让所有监控收）也是 UDP 的常见用法。
展厅落地对接要点
- 端口要对：每种设备 / 协议有约定端口，如 Modbus TCP 用 502、PJLink 用 4352，按设备说明书配，别猜。
- 控制指令默认 TCP：需要确认执行的开关、切换、时序命令都用 TCP，宁可慢一点也要送到。
- 长连接加心跳：常驻连接务必配保活，防被中间设备静默断开。
- 按协议切报文：TCP 字节流按固定长 / 分隔符 / 长度前缀切分，杜绝粘包拆包。
- UDP 只给能容错的：多屏同步、状态广播用 UDP，控制命令别用。
- 控制网隔离：控制网与业务网 / 访客网物理或 VLAN 隔离，避免大流量把控制包挤丢、也避免安全风险。
在 SoftControl 展厅中控 里，TCP/UDP 只是最底层的搬运方式，上层把设备命令封装成”开馆""闭馆""切场景”的按钮和定时任务，配合 SoftPlayer 展厅播控 做多屏内容联动，运营不用关心底下走的是挂号信还是传单。这跟 DMX512、Modbus 里把底层协议封装成”场景”的思路一脉相承——中控吃掉传输层差异，对外只留下”点一下就生效”。
故障排查表
| 现象 | 可能原因 | 排查 / 解决 |
|---|---|---|
| 命令时灵时不灵、偶尔丢 | 控制命令误用了 UDP，丢包不重传 | 改用 TCP 发控制指令，UDP 只留给可容错的同步 |
| 长连接过一阵就失效 | 缺心跳，被路由 / 防火墙空闲超时掐断 | 加心跳保活，并做断线自动重连 |
| 命令偶尔解析出乱码 / 错位 | TCP 粘包拆包没按边界切分 | 按协议用固定长 / 分隔符 / 长度前缀切消息 |
| 设备完全连不上 | IP / 端口错、不同网段、防火墙拦 | 核对 IP 端口网段，放行防火墙，先用 telnet / ping 测通 |
| 多屏同步总差半拍 | 用 TCP 逐台发，延迟抖动大 | 改 UDP 组播一次下发，交换机开组播支持 |
| 网络一忙控制就掉线 | 控制网与业务大流量混跑被挤占 | 控制网隔离，或做 QoS 优先保障控制流量 |
| UDP 状态广播收不全 | 交换机没开组播 / 广播被 VLAN 隔断 | 检查交换机组播设置与 VLAN 划分 |
排查口诀：先分清这条报文该 TCP 还是 UDP，再看端口和心跳，最后才查设备。 大半的网络控制毛病死在”用错传输方式”和”没处理粘包 / 心跳”这两步。
边界与安全
TCP 的可靠是”尽力”不是”实时”。 丢包重传会带来延迟，网络差时一条命令可能卡几百毫秒到几秒——对时间敏感的动作要么容忍这个抖动，要么在应用层加超时重发和幂等设计（同一命令重发多次不出错）。明文别裸奔。 TCP/UDP 本身不加密，控制报文在网上是明文，务必靠控制网隔离来兜安全，别把控制端口暴露在公网。UDP 无序要自己管。 若你确实用 UDP 传一串有先后的数据，得在报文里带序号自己排序去重，别指望网络帮你保序。
动手检查清单
对接一台网络设备前后，对着过一遍：
- 查手册确认设备用 TCP 还是 UDP、监听哪个端口
- 控制命令走 TCP；UDP 只用于可容错的同步 / 广播
- 先 ping / telnet 测通 IP 与端口，确认同网段、防火墙放行
- 按协议约定的边界（定长 / 分隔符 / 长度前缀）切分报文
- 长连接配了心跳保活与断线重连
- 控制网与业务 / 访客网已隔离
- 多屏同步用 UDP 组播时，交换机已开组播支持
小结
TCP 和 UDP 的选择说白了就一句话：这条报文丢一次会不会出事——会，用 TCP；不会且要快要一对多，用 UDP。 展厅里控制命令几乎清一色 TCP，UDP 只在多屏同步、状态广播这种能容错的地方露脸。用好 TCP 的关键不在协议本身，而在两件常被忽略的活儿：按边界切报文防粘包、加心跳防静默断连。上层再由中控把这一切封装成场景按钮，运营就只管点，不用管底下走的是哪条腿。
延伸阅读：了解 Modbus 设备控制、PJLink 投影控制 与 DMX512 灯光控制，或查看全部设备协议速查。
需要把网络设备统一纳入中控调度？了解 SoftControl 展厅中控与 SoftPlayer 播放器，查看解决方案与落地案例，或直接联系我们聊聊你的定制需求。