udp传输中mtu分片会显著拖慢网络性能，核心在于ip层分片后各片段独立路由、校验与丢包，任一片失败即导致整包报废且udp不重传；1472字节是udp数据部分在以太网mtu=1500下的安全上限（1500−20ip头−8udp头），超此值将触发分片，引发丢包率非线性上升、接收端重组压力及中间设备兼容性风险。
UDP传输中MTU分片会显著拖慢网络性能，核心问题不是“能不能传”，而是“传得稳不稳、快不快”。根本原因在于IP层分片后，每个片段独立路由、独立校验、独立丢包——只要其中任意一片出错，整包就报废，而UDP本身不重传，应用层必须全量重发。
为什么1472是UDP安全发送的临界值
以太网标准MTU为1500字节，但这是指IP层有效载荷上限。实际计算需逐层扣除头部：
- 以太网帧头（14B）+ FCS（4B）不计入MTU
- IP头部固定20B（无选项时）
- UDP头部固定8B
- 因此：1500 − 20 − 8 = 1472 字节 —— 这才是UDP数据部分最大安全长度
一旦超过1472，比如发1473字节，内核就会拆成至少两个IP分片：第一个含完整UDP头+1464字节数据，第二个仅含IP头+剩余9字节。后者极易被中间设备（如防火墙、NAT、低配路由器）丢弃，且无法单独重传。
分片带来的三类真实损耗
这些损耗在高并发、低延迟场景（如游戏、音视频、IoT心跳）中会被急剧放大：
- 丢包率非线性上升：单个UDP包分2片时，整体丢包概率 ≈ 1 − (1−p)²（p为单片丢包率）。当p=1%时，整包丢包率升至约1.99%；分4片时跃升至约3.94%
- 接收端重组压力：Linux用ipfrag_queue缓存分片，超时（默认30秒）未收齐则全部丢弃；大量分片还会触发ipfrag_high_thresh内存水位告警
- 中间设备兼容性风险：部分企业级防火墙、运营商CGNAT设备会直接丢弃带MF（More Fragments）标志的IP包，或拒绝转发偏移非零的分片
规避分片的实用策略
与其调大ipfrag_max_dist硬扛分片，不如从源头控制包长：
- 应用层主动切片：将大数据按≤1472字节分块，加序号/校验，由应用自己做可靠交付（如QUIC风格）
- 启用Path MTU Discovery（PMTUD）：设置socket选项
IP_PMTUDISC_DO，让内核探测路径最小MTU，避免盲目分片 - 统一链路MTU：若可控（如IDC内网），将所有节点MTU设为一致（如9000用于jumbo frame），并确保交换机透传
- 禁用分片兜底：对关键UDP服务，可设
IP_PMTUDISC_PROBE强制探测，或干脆用IP_PMTUDISC_DONT+ 应用层分段
验证是否发生分片
不用猜，用工具直接看：
- 抓包确认：
tcpdump -i eth0 'ip[6] & 0x01 != 0' -w frag.pcap（匹配IP头第7字节的MF位） - 查内核统计：
netstat -su | grep -A 5 "fragment"，关注ReasmFails和FragCreates - 检查路径MTU：
ping -M do -s 1472 target_ip（-M do禁止分片，失败说明路径MTU＜1500）
不复杂但容易忽略：很多UDP服务上线前只测通不通，没测稳不稳——而分片问题往往在流量高峰或跨网段时才暴露。
