分片丢失为什么更致命
IP 分片把一个大报文拆成多个片段传输，接收方只要缺任意一片就无法重组，整个报文作废。TCP 有重传兜底，UDP 大报文只能等应用超时，所以依赖分片的应用对丢包格外敏感。抓包上的表现是同一 IP 标识的分片组缺片，或者出现分片重组超时的 ICMP 消息。
基本信息
| 关键字段 | ip.flags.mf、ip.frag_offset、ip.id、ip.len |
|---|---|
| 相关 ICMP | type 3 code 4（需分片但 DF 置位）、type 11 code 1（重组超时） |
| 观察对象 | 同一 ip.id 的分片是否齐全 |
| 常见场景 | UDP 大报文、隧道内层、老式应用协议 |
典型使用场景
- UDP 应用间歇失败但小报文正常，怀疑大报文被分片后丢失
- 排查 DNS 响应偏大时走分片被中间设备丢弃
- 隧道环境中内层大包丢失，与封装开销有关
- 确认问题出在 MTU 而不是应用逻辑
- 评估安全设备对分片的处理差异导致的不一致现象
检查分片完整性
检查分片完整性
tshark -r t.pcap -Y "ip.flags.mf==1 || ip.frag_offset>0" -T fields -e ip.src -e ip.id -e ip.frag_offset -e ip.len
# 按 ip.id 分组后检查片段是否齐全，缺任意一片整包即作废
tshark -r t.pcap -Y "icmp.type==11 && icmp.code==1" -T fields -e ip.src -e ip.dst
# 分片重组超时，说明接收侧等不到全部片段
tshark -r t.pcap -Y "icmp.type==3 && icmp.code==4" -T fields -e ip.src
# 需分片但 DF 置位，路径 MTU 不足的直接信号字段逐项读法
| 字段 | 含义 | 读法 |
|---|---|---|
| ip.flags.mf | 还有后续分片 | 非最后一片为 1，最后一片为 0 |
| ip.frag_offset | 分片偏移，单位 8 字节 | 偏移为 0 的是第一片 |
| ip.id | IP 标识 | 同一分片组共享同一个值 |
| ip.len | 该片长度 | 最后一片通常比前面的片小 |
| frame.len | 整帧长度 | 用于核对是否被 snaplen 截断 |
分片与乱序不是一回事。乱序到达的片段按偏移排齐后仍能重组，缺片则必然失败。分析前先按 ip.id 排序，再判断到底是真的缺片还是只是顺序颠倒。
分片在不同抓包点的可见性不同：下游没抓到某一片，不等于上游没发。要判断丢在哪一跳，必须在两端或多点同时抓包，并统一过滤条件与时间窗。
排查顺序
- 先确认报文是否真的被分片：过滤 mf 置位或偏移大于 0 的帧
- 按 ip.id 分组，逐组检查片段是否齐全、偏移是否连续
- 确认是否存在重组超时或需分片的 ICMP 差错消息
- 核对路径 MTU，检查是否因隧道封装或链路 MTU 较小导致
- 条件允许时在应用侧改用不分片的大报文方案，从根上规避分片