tech/network · 集群 A · 网络基础原理 · 3/6

MTU 与 MSS 详解：分片、MTU 黑洞与隧道封装下的包大小问题

MTU 和 MSS 分别是什么

MTU（Maximum Transmission Unit，最大传输单元）是一条链路一次能承载的最大 IP 包大小，MSS（Maximum Segment Size，最大分段大小）是 TCP 在一个分段里能放的最大数据量。两者是“容器”和“容器里能装多少货”的关系。

以最常见的以太网为例：

├──────────────── MTU = 1500 字节 ────────────────┤
┌──────────┬──────────┬──────────────────────────┐
│ IP 头 20 │ TCP 头 20│   TCP 载荷（MSS = 1460） │
└──────────┴──────────┴──────────────────────────┘

这是不带任何选项的理想情况。实际中 TCP 头可能带时间戳等选项，IPv6 的基础头部是 40 字节，所以 MSS 会更小一些。不同网络环境的 MTU 也不同，例如某些宽带拨号方式会额外占用一部分头部，使 MTU 小于 1500。

分片与路径 MTU 发现

当一个包比下一跳链路的 MTU 大时，网络有两种处理方式：把包切成小块（分片），或者丢弃并通知发送方缩小包（路径 MTU 发现）。

分片是 IPv4 的传统做法。路由器把大包拆成多个小片分别传输，由接收方重新组装。它的问题在于：任何一片丢失整个包都要重传；重组消耗资源；不少防火墙和中间设备对分片处理并不友好。

**路径 MTU 发现（PMTUD）**是现代更常用的做法。发送方在包上设置“不分片”标志，如果某一跳放不下，就丢包并回送一条“需要分片”的 ICMP 消息，告诉发送方该链路能接受多大。发送方据此缩小后续包的大小。IPv6 中路由器不再负责分片，完全依赖这一机制。

MTU 黑洞是怎么形成的

MTU 黑洞是路径 MTU 发现失效的结果：大包被丢弃，但“需要分片”的提示没能回到发送方，于是发送方一直用过大的包重试，连接看起来卡死。

形成黑洞的常见原因：

1. 中间设备出于安全考虑过滤了 ICMP 消息；
2. 某些网络设备对 ICMP 进行限速，高负载时提示被丢掉；
3. 隧道或封装设备没有正确传递 ICMP 消息。

黑洞的特征非常鲜明——小的能过，大的不行：

• 网页首屏文字出来了，图片和脚本加载到一半停住；
• SSH 能登录，但执行输出较多的命令时卡住；
• 建立连接很快，下载速度先有数值随后归零；
• Ping 小包正常，Ping 大包（指定较大载荷且不分片）失败。

隧道与代理封装为什么让问题更明显

代理和隧道的本质，是把原始数据包装进另一层连接里传输，每多一层封装就多占一部分头部空间，留给原始数据的空间就更小。

原始包（应用视角）：
┌────────┬──────────────────────────┐
│ IP/TCP │         数据             │
└────────┴──────────────────────────┘

经过隧道封装后（链路视角）：
┌────────┬──────────┬─────────┬────────┬──────────────────┐
│外层 IP │外层 TCP/UDP│ 协议头  │ 加密开销│   原始包（可能被截断）│
└────────┴──────────┴─────────┴────────┴──────────────────┘
├────────────────── 不能超过路径 MTU ──────────────────┤

不同代理协议、不同传输方式的额外开销不一样，本文不对具体协议的字节数做定论。原理上，只要“原始包 + 封装开销”超过了路径 MTU，就需要分片或被丢弃。协议本身的差异可参考 代理协议 专题，隧道的通用模型见 网络隧道是什么。

在 TUN 模式下，客户端会创建一张虚拟网卡，并为它设定一个 MTU 值。应用发出的包先按这个 MTU 切好，再进入内核处理。这个值设得过大，封装后可能超出物理链路；设得过小，会增加包数量和处理开销。TUN 的工作原理见 TUN 虚拟网卡原理。

如何判断是不是 MTU 问题

判断 MTU 问题的关键是观察“大小相关性”：问题是否只在传输较大数据时出现。可以按以下思路检查：

1. 观察现象：是否符合“小请求正常、大流量卡住”的特征，且能稳定复现。
2. 对比直连：关闭代理访问同一境内大文件是否正常，排除本地链路问题。
3. 对比模式：系统代理模式与 TUN 模式下表现是否不同，如果只在 TUN 下出现，虚拟网卡 MTU 值得怀疑。
4. 对比传输方式：如果客户端或节点提供多种传输方式，对比是否只在某种方式下出现。
5. 大包测试：用 ping 指定载荷大小并设置不分片标志，从较大值逐步减小，观察临界点（不同系统的参数写法不同，请查阅系统文档）。

需要注意，ping 走的是 ICMP，与代理隧道内的 TCP 流量路径不一定一致，测试结果只能作为参考。

常见的缓解思路

缓解 MTU 问题的原则是“让包在进入隧道前就足够小”。常见思路有：

无论采用哪种方式，都建议一次只改一个参数，记录修改前后的表现，确认有效再保留。随意调小 MTU 可能带来额外的性能损失。路由器上的设置方式可参考 路由器方案 专题。

与其他故障的区分

MTU 问题容易与丢包、DNS 故障混淆，三者的区分要点如下：丢包通常表现为“所有大小的请求都变慢、偶发失败”，没有明显的大小相关性；DNS 故障表现为“连接根本建立不起来”或“连到了错误地址”；而 MTU 问题的连接能够建立，小数据也能传输，只有超过某个大小的数据会稳定地卡住。只要抓住“是否与数据大小相关、是否稳定复现”这两点，就能大致做出判断。

小结

MTU 问题的识别难度在于它“半通”：连接能建立，部分内容能加载，只有大包会悄悄丢失。只要记住“小的能过、大的不行”这个特征，再结合隧道封装会占用空间这一原理，就能快速把它和节点故障、DNS 问题区分开。若需完整的排查流程，请参考 分层排障法。

想了解不同服务商的协议与客户端资料，可前往 机场品牌库 或 对比工具 查看，所有字段来自品牌资料，本站未实测。