TCP 还是 UDP：中控系统里两种网络协议的取舍

判断标准不是谁更快，而是这个动作允不允许丢

中控系统真正关心的是"命令到了没有"

选 TCP 还是 UDP，表面是协议问题，实质是可靠性问题。中控系统里的一次控制往往对应一个明确的物理动作：幕布降下来、灯光切到会议模式、摄像头转到预置位。这些动作要么必须完成，要么必须知道它没完成。所以判断标准不是"哪个协议更快"，而是"这个动作允不允许丢"。

TCP：有确认，但要处理粘包与超时

TCP 自带重传和顺序保证，适合"必须送达"的控制命令和配置下发。代价是两件事必须自己处理。

• 粘包与拆包：TCP 是字节流，没有消息边界概念。设备连续发两条状态，你可能一次收到两条连在一起，也可能一条被拆成两段。解决办法是按协议约定处理——有长度头的按长度读，有结束符的按结束符切，两者都没有的只能靠超时切分，很不稳。

• 超时与重试：连接建立成功不代表命令被设备接受，很多设备收下命令后回一个错误码。控制逻辑要同时判断"连接层成功"和"业务层成功"，缺一不可。

UDP：广播发现与实时状态回传

UDP 无连接、不保证送达，但有两类场合特别合适。一是设备发现：向广播地址发一个查询包，在线的设备各自回应，一次就能摸清一个网段里有什么设备，用 TCP 做这件事要逐个地址尝试，效率低得多。二是高频状态回传：设备每秒上报一次温度、亮度、通道状态，丢一两包无关紧要，下一包很快就到，用 TCP 反而要维持大量连接。

混合用法往往最实用

实际项目里常见组合是：UDP 做发现和状态订阅，TCP 做命令下发，串口兜住那些没有网络口的设备。这种混合不是折中，而是各取所长。需要注意的是，一旦混合，状态来源就有多个，界面显示的设备在线状态要以"最后一次有效心跳的时间"来判断，不能只依赖连接是否建立。

超时与重试要讲策略

重试不能无脑循环。合理的做法是：单条命令给一个较短的超时（几百毫秒到一两秒，取决于设备响应速度），失败后重试一到两次，仍失败则标记该设备为异常并上报告警，而不是继续堆积重试请求。对同一条命令反复重发，可能造成设备收到多次执行——切模式这类操作重复执行后果不大，但"上升/下降"这类相对动作重复执行就会失控。

小结

把每个控制动作按"丢了会怎样"分类，再决定走 TCP 还是 UDP，比统一用一种协议更贴合现场。协议只是通道，真正决定系统稳定的是超时、重试和状态判断这三件事写没写清楚。