workerman udp 高并发需协同优化协议设计、事件循环与系统资源：onmessage 仅轻量解析并入队，禁用同步io；调大内核udp缓冲区并监控recv-q；发送端实现双向心跳、预解析ip、复用socket，并在应用层实现ack重传机制。
Workerman UDP 处理大量数据包，不能靠“加大缓冲区”或“暴力收发”硬扛，必须从协议设计、事件循环承载力和系统层资源三方面协同控制。否则很快出现丢包、CPU 单核打满、连接假死或 EMFILE 错误。
UDP 收包太快导致事件循环被阻塞怎么办
Workerman 的 UDP 服务默认用 stream_socket（多进程时）或 socket（单进程时）监听，但无论哪种，如果每秒收到成千上万个包，而每个 onMessage 回调里做了同步 IO（比如写文件、查数据库、sleep），就会卡住整个事件循环，后续包堆积、延迟飙升甚至被内核丢弃。
- 务必在
onMessage中只做轻量解析（如提取包头、校验长度）、快速入队，把耗时逻辑交给异步任务或 Channel 消费 - 避免在回调中使用
file_put_contents、mysqli_query、curl_exec等同步操作 - 若需限流，可在接收端加滑动窗口计数器，例如每秒最多处理 500 个包，超限直接
$connection->close()或丢弃（注意：UDP 无连接，close()实际是清空该 socket 关联的内部状态） - 检查
Worker::$maxConnection是否设得过高——UDP 不需要连接管理，这个值对 UDP 无效，别被误导
怎么避免 UDP 包被内核 silently 丢弃
Linux 内核 UDP 接收缓冲区（net.core.rmem_max）默认通常只有 212992 字节（约 208KB），一旦应用没及时读走，新包就会被直接丢弃，且不报错。你看到“客户端发了但服务端没收到”，八成是这个原因。
- 临时调大：运行
sudo sysctl -w net.core.rmem_max=4194304（4MB），并写入/etc/sysctl.conf持久化 - 在 Workerman 启动前，用
ini_set('socket.receive_buffer_size', 4194304)尝试设置（部分环境生效，但不如系统级可靠） - 用
ss -uln观察Recv-Q列，持续 >0 表示已开始丢包 - 不要依赖“增大
buffer就万事大吉”——根本解法是让onMessage执行足够快，或者用多进程 +reusePort分摊压力
UDP 大量并发发送时为什么连不上客户端
UDP 是无连接的，但 Linux 内核对“未显式绑定源地址的 UDP socket”会维护一个临时五元组映射（类似 NAT 表项）。当服务端高频向不同客户端 IP:PORT 发包，又缺乏心跳保活，这个映射可能在几十秒内被内核回收，导致后续发包失败（表现为客户端收不到，strace 可见 sendto 返回 0 或 EAGAIN）。
- 务必实现双向心跳：客户端和服务端每 30–60 秒互相发一个最小包（如 4 字节
0x01），维持内核映射 - 发送前确保目标地址已“首次通信过”——即服务端必须先收到过该客户端的包，才能反向发过去（这是 UDP 通信的前提）
- 避免用
gethostbyname做 DNS 查询：它会阻塞事件循环；改用异步 DNS 库（如workerman/async-dns）或预解析缓存 IP - 高并发发送建议复用
socket资源，不要每次socket_create+socket_sendto，而是用stream_socket_client创建后长期持有
真正难的不是“怎么发”，而是“怎么确认对方收到了”——UDP 本身不提供 ACK。如果你的业务要求可靠交付（比如 GB28181 注册、SIP 消息），就必须在应用层实现重传+序列号+超时机制，这部分逻辑很容易掩盖在看似简单的 onMessage 里，结果压测时才发现丢信率飙升。别跳过这一步。
