C++ UDP服务端异常UDP分片现象相关技术问题咨询

问题1：为什么抓包仅能观测到1个数据包，而非IP分片后的两个分片报文？ #

• 该现象是网卡GRO（通用接收卸载）/GSO（通用发送卸载）特性导致的：你仅关闭了UDP分片卸载（UFO），但网卡仍会在驱动层将属于同一个UDP会话的多个IP分片合并为单个大报文后再上报给内核协议栈，tcpdump抓包点位于网卡驱动上报路径上，因此只能抓到合并后的单个报文，看不到拆分的IP分片。
• 抓包输出里的bad length 2004 > 1472就是tcpdump识别到合并后的报文长度超出单MTU对应的UDP最大载荷（1500字节MTU下UDP载荷最大1472字节）给出的提示，不代表报文在线路上没有分片。
• 要观测真实的线路分片，执行ethtool -K eth0 gro off gso off关闭对应卸载特性后再抓包，即可看到两个独立的IP分片报文。

问题2：为什么tcpdump的抓包结果中看不到末尾的'b'（0x62）字节？ #

• 原因是tcpdump默认抓包快照长度（snaplen）有限：多数发行版默认配置下tcpdump仅抓取每个报文的前1500字节左右内容用于协议解析，不会捕获合并后大报文的全部载荷，因此-X输出只能看到前1472字节内容，末尾的0x62字节因为超出默认抓取长度没有被捕获展示。
• 抓包时添加-s 0参数，将snaplen设为0（即抓取完整报文长度），即可看到包含末尾'b'字符的全部报文内容。
• 你的应用能正常收到完整2000字节数据，说明内核IP分片重组逻辑工作正常，不存在数据丢失问题，异常仅来自抓包配置和网卡卸载特性的干扰。

问题3：C++ UDP服务端设置多大的接收缓冲区最合适？目前因入站TCP包大小不固定，将缓冲区设置为65535字节是否合理？ #

• IPv4标准规定单个IP报文最大总长度为65535字节，扣除20字节IP头、8字节UDP头后，单个UDP报文的最大有效载荷为65507字节。
• 在未实现应用层UDP分片的场景下，将recvfrom调用使用的用户态接收缓冲区设为65535字节是完全合理的，该值可以覆盖所有标准UDP单报文的最大可能长度，不会出现缓冲区不足导致的报文截断。
• 需要注意区分两类缓冲区：代码中传给recvfrom的用户态缓冲区固定设为65535字节即可；内核层面的UDP socket接收缓冲区（通过SO_RCVBUF选项设置）需要根据业务流量峰值调整，避免高流量下内核缓冲区溢出丢包。

问题4：如果待传输的数据大小超过65535字节会触发什么问题？是否需要在将TCP数据封装为UDP发送前自行实现应用层分片机制？ #

• 单次调用sendto发送超过65507字节的UDP载荷时，内核会直接返回EMSGSIZE错误，不会发送超出IPv4最大报文长度限制的数据。
• 即便绕过内核长度限制发送，超过MTU产生的IP分片在网络传输中丢包风险极高：任意一个分片丢失，整个UDP报文都会被内核直接丢弃，且UDP没有重传机制，接收端完全无法收到有效数据，传输可靠性没有任何保障。
• 如果必须用UDP承载长度超过单报文上限的TCP流数据，必须自行实现应用层分片机制，同时需要配套实现分片序号标识、乱序重组、分片超时重传、重复包过滤逻辑，否则大长度数据的传输成功率完全不可控。
• 额外注意：UDP本身是无连接不可靠传输协议，跨公网做TCP转UDP转发时，除分片问题外还需要处理丢包、乱序、重复包等问题，否则业务可用性无法保障。

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