Workerman的UDP服务适合物联网心跳、SIP/GB28181注册等低延迟高并发场景，需记录客户端地址主动回包、60秒保活，不适用于视频流中继，多播需手动setsockopt且跨平台兼容性差。
UDP服务适合低延迟、高并发但容忍丢包的场景
Workerman 的 UDP 支持不是为通用 Web 交互设计的，它天然适合那些「发了就不管是否到达」但要求极快响应或海量终端同时上报的业务。比如物联网设备心跳、SIP/GB28181 视频注册、QUIC 协议前置代理、轻量级日志采集 —— 这些场景共同点是：单包小、频率高、不能卡主线程、不依赖 TCP 建连开销。
GB28181 和 SIP 注册必须用 UDP 主动回包
国标 GB28181 设备上线时，会向平台发送 REGISTER 消息（UDP），平台必须在 5 秒内用 200 OK 回复，否则设备认为注册失败。Workerman 的 $udpWorker->onMessage 能立刻捕获并构造响应，但要注意：
- 必须记录客户端的
$connection->getRemoteAddress()，后续主动发包全靠它 - Linux 内核对 UDP “连接态”默认只维持约 5 分钟（使用
stream_socket时），所以得每 60 秒发一次MESSAGE或空包保活 - 不要在
onMessage里做耗时操作（如查 DB），否则阻塞事件循环，导致其他设备注册超时
视频流转发不适合直接用 Workerman UDP 做中继
虽然文档里有“UDP 视频流传输”示例，但实际部署中容易出问题：
- Workerman 的 UDP 连接对象不支持
sendto的flags参数（如MSG_DONTWAIT），大包分片后易被内核丢弃 - 广播式转发（
foreach ($udpWorker->connections as $c) $c->send($data)）在千级设备时会迅速打满 CPU，因为每个send都触发一次系统调用 - 真正稳定的视频流分发建议用 ZLMediaKit 或 SRS 接入，Workerman 只负责信令（如 SDP 交换、设备状态同步）
多播（Multicast）需手动 setsockopt，且跨平台行为不一致
如果要用 Workerman 接收 239.0.0.1 这类多播地址，不能只靠 new Worker("udp://239.0.0.1:1234")，必须在 onWorkerStart 里手动调用 socket_set_option：
$socket = stream_socket_server("udp://0.0.0.0:1234", $errno, $errstr, STREAM_SERVER_BIND);
socket_set_option($socket, IPPROTO_IP, MCAST_JOIN_GROUP, [
'group' => inet_pton('239.0.0.1'),
'interface' => 0 // Linux 下设为 0 表示任意网卡；FreeBSD 可能报错，得换具体网卡索引
]);
这个操作在 Docker 容器里大概率失败，因为默认网络模式不支持多播组加入 —— 容易被忽略的是：不是代码写错了，而是运行环境没开权限。
