分片带来的问题
报文超过路径的传输单元上限时会被拆分：任何一片丢失，整个报文即作废，而且没有重传机制来补救。这就是大包 UDP 服务「时通时不通」的典型根因，只有把包控制在安全尺寸内才能根治。
校验和置零是另一类风险
在 IPv4 下校验和字段允许置零，发送端省下计算开销，接收端也省下校验；代价是损坏的数据会直接进入应用层。这种做法只在有更强的下层校验时才有意义，公网服务不应采用。
基本信息
| 分片表现 | 超过路径上限即被拆分，任一片丢失整包作废 |
|---|---|
| 校验和置零 | 仅 IPv4 允许，等于放弃完整性检查 |
| 建议上限 | 公网 UDP 单包建议控制在 1200 字节以内 |
| 规范 | RFC 768 定义 UDP 校验和语义 |
典型使用场景
- 排查大包 UDP 服务的随机丢包
- 排查隧道与虚拟网络叠加封装后的尺寸问题
- 排查「小请求正常、大响应时通时不通」
- 评估服务的数据包尺寸设计是否合理
测试大包路径
测试大包路径
ping -M do -s 1472 10.0.0.9 # 加上报头正好 1500，验证路径不经分片
ping -s 4000 10.0.0.9 # 允许分片，观察是否仍通
ip link show eth0 | grep mtu # 查看接口上限
# 用业务协议发不同尺寸的请求，观察成功率随包长的变化风险与后果
| 风险 | 原因 | 后果 |
|---|---|---|
| 大包分片 | 路径传输单元较小 | 随机丢包、时通时不通 |
| 分片重组超时 | 中间设备限速或排队 | 延迟尖刺 |
| 校验和置零 | 绕过完整性检查 | 损坏数据进入应用层 |
公网 UDP 服务单包建议控制在 1200 字节以内，避免依赖路径上的分片能力：这是新协议普遍采用的经验值，留出了隧道与叠加封装的空间。
抓包看到的 UDP 长度是报文自身长度，不是外层 IP 包长：判断是否发生分片要看 IP 层的分片标志与偏移字段。
排查顺序建议从路径开始：先用不同包长测通，再回到服务端调整尺寸，能避免在应用层白改一轮。