为什么最小传输单元是固定的
六层标准规定链路必须支持至少一千二百八十字节的报文尺寸，这个数字是可用性的下限而非推荐值。之所以要求这样，是为了让所有链路都有一个无需协商即可通行的大小，避免分片带来的性能与可靠性问题；同时也避免把最小尺寸定得过小，导致协议头占比过高。
为什么会出现大包黑洞
六层把分片责任交给发送方：中间设备遇到超过下一跳承载能力的大包时不再自行分片，而是回送一个报文过大的差错通知，由发送方调整大小重发。如果这条差错通知被防火墙拦掉，发送方就会一直用过大尺寸重发，表现为连通性测试正常、稍大的数据全部丢失。
基本信息
| 链路最小尺寸 | 一千二百八十字节，必须支持 |
|---|---|
| 分片责任 | 由发送方执行，中间设备不再分片 |
| 反馈机制 | 报文过大的差错通知回送给发送方 |
| 典型症状 | 小包通、大包不通，页面打不开 |
| 隧道场景 | 封装越厚，可用的载荷越小 |
典型使用场景
- 排查网页打不开：连通性测试正常但应用不可用时，优先怀疑这条反馈被拦截
- 隧道加固：封装层数越多，越需要调低接口尺寸或做报文段钳制
- 防火墙策略复核：确认差错通知被放行，是策略评审的固定检查项
- 验证手段：用逐步加大的探测报文确定可通行的最大尺寸
- 跨运营商排障：路径中某一段承载能力较小且不回送通知时，需要逐段确认
- 方案设计：在设计阶段就把封装开销算进可用载荷，避免上线后才发现问题
症状与验证
症状与验证
ping -6 -s 1400 目标地址
# 大包不通、小包通，基本可以判定为路径尺寸探测问题
# 提示报文过大，或大包完全超时
ping -6 -s 1200 目标地址
# 小尺寸通常正常，用于对照
# 处置：放行报文过大类型的差错通知，或在隧道场景对报文段长度做钳制尺寸与处置对照
| 场景 | 可用载荷 | 常见问题 | 处置方向 |
|---|---|---|---|
| 普通以太网 | 标准尺寸 | 少见 | 保持默认 |
| 单层封装 | 减去封装开销 | 大包丢失 | 调低接口值 |
| 多层封装 | 减去多层开销 | 小包通大包不通 | 报文段长度钳制 |
| 差错被拦截 | 名义可用 | 发送方一直重试 | 放行差错通知 |
六层的路径探测依赖差错通知，因此它不是可选的优化项而是必需机制；拦截它会在应用层表现为难以定位的间歇故障，尤其是页面加载与大文件传输。
隧道场景下不要沿用默认尺寸假设：每多一层封装就少一部分可用载荷，尽早调低接口值或做报文段长度钳制，比上线后再排查省事得多。