带15秒超时的Always listening UDP Server偶发丢包该如何解决？

解决方案 #

首先纠正一个认知偏差：只要你的UDP socket处于绑定、未关闭的状态，报文到达后会先进入操作系统内核的socket接收缓冲区排队，不需要程序刚好执行到recvfrom才会接收，你调用recvfrom只是从内核缓冲区取已经收到的报文而已。

你遇到的丢包问题，核心根源是你用recvfrom15秒超时响应服务控制的逻辑不合理，以及可能的缓冲区不足、处理链路阻塞，可以按以下优先级优化： #

方案1：优先优化现有UDP服务逻辑（保留低延迟优势） #

• 替换超时轮询逻辑：不要靠recvfrom超时来检测服务控制请求，Windows平台可以用WSAEventSelect模型，同时监听UDP socket的接收事件和服务控制的事件对象，全程不需要断开socket，也不存在监听间隙，能100%规避你推测的第一种丢包场景。
• 调大内核接收缓冲区：调用setsockopt设置SO_RCVBUF参数，将默认的几KB接收缓冲区调大到1~4MB（根据你的报文大小和并发量调整），内核会自动为你排队最多对应大小的报文，就算你的业务逻辑短时间没调用recvfrom，报文也不会丢失。
• 接收/处理逻辑解耦：接收线程只负责调用recvfrom收报文，收到后立刻丢到独立的工作线程池处理回传等逻辑，接收线程马上回到recvfrom调用，完全消除你推测的第二种丢包场景。
• 可选增加轻量应用层可靠性：如果对丢包零容忍，可以加极简的ACK机制：客户端发送指标后等待50~100ms，没收到服务端的ACK应答就重发一次，开销远低于TCP，完全不会影响实时性。

方案2：切换TCP的适用场景 #

如果存在以下情况，可以考虑切换TCP，局域网环境下TCP的延迟和UDP差值通常在1ms以内，对指标采集的时间敏感度影响可以忽略：

• 单个指标报文大小超过MTU（通常1500字节），UDP分片后丢包概率会大幅上升
• 每秒上报的指标数超过1000条，且报文平均大小超过500字节，UDP内核缓冲区溢出的概率会明显升高
• 后续需要增加批量上报、加密传输等能力，TCP的成熟特性可以减少大量开发量

内容的提问来源于stack exchange，提问作者chris-p-tech