Boost.Asio下UDP短读是否适用？如何独立读取单个UDP多播包

参考文档中定义的短读、短写概念，是专门针对无边界的字节流套接字（典型如TCP）设计的语义，本质是指单次读操作只返回了字节流的部分内容，剩余字节仍留存于内核缓冲区等待后续读取，这一原生定义并不完全适用于UDP。
UDP属于数据报套接字，天生携带完整的消息边界，不存在类似TCP的连续字节流传输模型，但开发中确实会出现和短读体感高度相似的问题：当你为接收操作分配的缓冲区尺寸小于实际到达的UDP数据包大小时，单次接收调用只会将该UDP包的前N个字节拷贝到用户态缓冲区，数据包剩余的内容会被内核直接丢弃，不会留存到后续的接收队列中。这种截断行为虽然表现上类似短读，但和TCP短读的核心机制存在本质区别。

这个需求是完全可以实现的——UDP的原生传输模型就是基于独立数据报交付的，底层不存在跨包拼接、粘包的机制，具体实现要点如下：

• 规避常见的接口误用：绝对不要用Boost.Asio中面向流场景设计的read()、async_read()系列函数操作UDP套接字。这类接口的内置逻辑是循环累加读取到的字节，直到填满用户传入的整个缓冲区，完全不感知数据报的边界，很容易把连续到达的多个UDP包的内容拼接进同一个缓冲区，直接破坏数据报边界，这也是很多从TCP转UDP开发的人最常踩的坑。
• 选择匹配语义的接收接口：针对UDP套接字，直接使用面向数据报设计的接收接口，包括receive()、async_receive()、receive_from()、async_receive_from()。这类接口的行为逻辑是，单次调用只会从内核接收队列中取出一个完整的独立UDP数据报，不管缓冲区大小如何，都不会把多个数据报的内容拼接到同一次接收结果中。
• 适配“定长头+可变长正文”的解析逻辑：由于UDP是整包交付，不存在传输层的拆包问题，你只需要给接收缓冲区预留足够容纳最大可能数据包的冗余空间，单次调用拿到完整数据包后，直接在缓冲区中读取定长头部的长度字段，定位可变长正文的位置做解析即可，完全不需要像TCP那样编写额外的粘包、拆包状态机逻辑。

• 预留足够的缓冲区空间：如果接收缓冲区尺寸小于实际到达的UDP包长度，就会出现前述的内核截断问题，此时接口的返回值会标注实际读到的字节数，你可以通过这个返回值判断是否发生了截断，及时调整缓冲区尺寸或做丢包告警。
• 不要混淆同框架下不同套接字的接口语义：哪怕是同名的asio接收接口，绑定到UDP套接字上时遵循数据报边界语义，绑定到TCP套接字上时遵循流语义，两者的行为差异很大，不要直接照搬TCP场景下的代码逻辑编写UDP程序。

内容的提问来源于stack exchange，提问作者user22662