MTU、MSS、IP 分片、PMTUD 和 PLPMTUD 有什么区别？
这几个名词都与“一个包能有多大”有关，但所在层次和作用完全不同：MTU 是链路一次能承载的最大 IP 包尺寸；Path MTU 是端到端路径上所有链路 MTU 的最小值；TCP MSS 是一个 TCP 报文段中可承载的最大应用数据量；IP 分片是把过大的 IP 包拆成多个片段；PMTUD 与 PLPMTUD 则用于发现无需分片即可通过路径的合适包尺寸。
本文目录（10 节）
核心概念对比
| 概念 | 所在层次 | 描述对象 | 是否包含协议头 | 主要作用 |
|---|---|---|---|---|
| Link MTU | 链路/IP 交界 | 单条链路可承载的最大 IP 包 | 包含 IP 头 | 限制该链路上的 IP 包尺寸 |
| Path MTU | 端到端路径 | 路径中最小的 Link MTU | 包含 IP 头 | 决定无需 IP 分片的最大包尺寸 |
| TCP MSS | TCP | 单个 TCP 段的数据部分 | 不含 TCP 与 IP 头 | 告知对端本端可接收的 TCP 数据上限 |
| IP 分片 | IP | 超过可承载尺寸的 IP 包 | 每个片段有相应 IP 信息 | 把大包拆开传输并在目的端重组 |
| PMTUD | IP、ICMP 与传输层协作 | 发现 Path MTU | 不适用 | 根据 Packet Too Big 等反馈降低发送尺寸 |
| PLPMTUD | 分包层/传输层 | 探测可工作的包尺寸 | 不适用 | 用探测与确认机制发现黑洞并调整尺寸 |
MTU 与 Path MTU：一条链路和整条路径
MTU 是 Maximum Transmission Unit。以常见以太网环境为例，接口 MTU 经常设置为 1500，但这只是本地接口或某一跳的属性。数据从客户端到服务器会经过多条链路；Path MTU 等于这些链路 MTU 中的最小值。
假设本地链路支持 1500 字节，中间隧道因额外封装只能无分片承载 1420 字节，而服务器侧仍支持 1500 字节，那么这条路径的 Path MTU 是 1420。只检查本机网卡显示的 1500，无法发现中间瓶颈。
路径也不一定永久不变。路由切换、网络漫游、负载均衡或隧道重建可能改变实际 Path MTU。一个昨天正常的固定尺寸今天可能在新路径上过大，因此协议实现需要缓存失效和重新探测机制，不能永远依赖一次测试结果。
MSS：TCP 有效载荷上限，不是 MTU 的别名
TCP Maximum Segment Size 表示一个 TCP 报文段中对端愿意接收的最大数据部分，不包含 IP 头与 TCP 头。MSS 选项在 TCP 建连的 SYN 中通告。RFC 9293 要求 TCP 实现支持发送和接收 MSS 选项，并说明实际发送 MSS 还要受到 IP 层允许的最大传输尺寸约束。
在没有 IP 选项和 TCP 扩展头的简单 IPv4 情况下，常见的 1500 MTU 减去 20 字节 IPv4 头和 20 字节 TCP 头，得到 1460 字节 MSS。IPv6 基础头更长，简单相减的结果也不同。但这只是帮助理解的例子，不能把 MTU - 40 当成所有环境的万能公式：TCP 选项、IPv6 扩展头和外层隧道都会占用空间。
所谓 MSS clamping，通常是在特定转发边界调整 TCP SYN 中通告的 MSS，促使 TCP 端点发送较小报文段。它只直接作用于 TCP，不能修复 UDP、QUIC 或任意 IP 数据报的尺寸问题，也不能代替正确的 Path MTU 发现。若一看到连接卡顿就全局压低 MSS，可能只是隐藏 ICMP 被错误阻断或隧道 MTU 配置不一致。
IP 分片：把大包拆开并不等于没有代价
IPv4 中，若包大于下一跳 MTU且允许分片，中间路由器可能将其拆分；若设置了 Don't Fragment，路由器应丢弃过大的包并返回相应 ICMP 反馈。IPv6 的中间路由器不执行这种分片：遇到过大数据包时应丢弃并发送 ICMPv6 Packet Too Big，只有源节点可以使用 Fragment Header 进行源端分片。
分片会增加头部和处理开销。任何一个片段丢失，都可能使整个原始包无法完成重组；安全设备、NAT 或负载均衡器对片段的处理也可能不一致。RFC 8900 将 IP 分片描述为脆弱机制，并建议能够调整包尺寸的应用使用路径 MTU 信息或发现机制，尽量避免依赖分片。
“能被分片”也不代表应用一定能正常工作。网络设备可能丢弃非首片，重组缓存可能超时，攻击防护策略也可能限制片段。排障目标通常应是让发送尺寸适应路径，而不是强迫网络接受更多分片。
PMTUD：依靠路径反馈发现可用尺寸
传统 Path MTU Discovery 的基本思路是发送不应在路径中分片的包，并根据路由器返回的 ICMP 反馈降低尺寸。IPv4 的经典机制由 RFC 1191 描述；IPv6 的 PMTUD 由 RFC 8201 描述，并依赖 ICMPv6 Packet Too Big 消息传递路径限制。
当相关 ICMP 消息被防火墙错误丢弃时，发送端可能不知道包太大。小包和 TCP 三次握手仍然能够通过，但开始传输较大数据后连接卡住或反复重传，这就是常说的 PMTU black hole。因而“端口能连通”和“TLS ClientHello 发出了”都不足以证明数据通道尺寸正确。
ICMP 不应被笼统视为无用流量全部封锁。应根据协议要求和安全策略允许必要的错误反馈，同时进行速率限制与合法性校验。仅在端点反复调低 MTU，可能让故障暂时消失，却留下其他协议或其他路径上的同类问题。
PLPMTUD：在分包层主动探测与确认
Packetization Layer Path MTU Discovery 不完全依赖收到 ICMP Packet Too Big。分包层通过发送不同尺寸的探测包，并依据是否得到确认来判断当前尺寸能否工作；发现疑似黑洞时缩小尺寸，也可以继续探测更大可用值。
RFC 8899 为数据报传输定义 DPLPMTUD，可用于 UDP 之上的 QUIC 等分包层。它不是简单执行一次大包 ping，而是一套由协议实现维护状态、确认探测、处理失败并重新评估路径的机制。应用是否支持、如何启用以及与拥塞控制如何配合，需要查看具体实现，不能仅凭操作系统接口 MTU 推断。
PMTUD 和 PLPMTUD 不是必然互斥。实现可以利用可信的 Packet Too Big 信息快速调整，也可通过分包层探测验证路径和处理 ICMP 不可达的情况。二者共同目标是选择尽可能高效、又不会因路径限制而丢失的发送尺寸。
为什么代理和隧道更容易遇到 MTU 问题
隧道会在原始数据外增加新的 IP、UDP、TCP、TLS 或其他协议头。若物理出口 MTU 不变，内层可用空间就会缩小。多层封装还会叠加开销，例如应用流量进入 TUN 后再次经过加密传输，实际外层包可能比直连时大得多。
不能只从协议名称猜一个固定开销。不同地址族、扩展选项、认证标签、填充和传输模式都会影响头部尺寸。正确做法是依据实现文档计算理论上限，并在真实路径上验证；同时分别观察内层接口和物理出口，避免把内层 1500 误认为外层也能无分片承载相同大小。
如果 TCP 正常而基于 UDP 的协议卡顿，可能是 TCP 的 MSS 或协议栈已自动适配，但 UDP 分包层没有得到有效反馈；反过来，QUIC 实现可能具备探测机制，而某个固定尺寸 UDP 应用仍失败。协议差异是排查线索，不是直接结论。
“小包通、大包不通”的安全排查顺序
先确定问题范围：仅一个目标、仅一个地址族、仅某类传输，还是整个隧道都受影响。记录客户端、服务端、隧道接口和出口接口的 MTU，以及是否发生路由切换。随后从两端抓取经过授权的诊断信息，观察大包是否发出、是否重传、是否收到 ICMP Packet Too Big 或 Fragmentation Needed。
再区分 TCP 与数据报。TCP 检查 SYN 中双方 MSS、实际段尺寸和重传；UDP或 QUIC 检查应用发送的数据报尺寸以及实现是否支持 PMTUD/PLPMTUD。若调整接口 MTU 或 MSS 作为对照实验，应记录修改前后值并使用最小影响范围，验证完成后恢复，不能把临时规避直接当作根因修复。
还要检查防火墙、云安全策略、NAT、容器网络和反向代理是否允许必要 ICMP/ICMPv6 信息。路径上的某一处抓包看不到反馈，不等于反馈没有在别处产生；应尽量在发送端与出口边界同时观察。最终修复需要覆盖所有受影响协议，而不是只让一个测速页面通过。
常见问题
MTU 1500 时 TCP MSS 一定是 1460 吗？
不一定。1460 是简单 IPv4、无额外 IP/TCP 选项时的常见结果。IPv6、TCP 选项、隧道封装和路径限制都会改变实际有效发送 MSS，协议栈还会结合对端通告与 Path MTU 决策。
调低 MTU 为什么能让卡住的连接恢复？
较小的包可能避开路径瓶颈，因此症状消失。但这只是证实“尺寸相关”的强线索，仍需检查隧道开销、PMTUD、ICMP 反馈和各层配置，避免把过低 MTU 永久当作唯一方案。
IPv6 路由器会像 IPv4 一样在中途分片吗？
不会。IPv6 中间路由器遇到超过下一跳 MTU 的包应丢弃并返回 Packet Too Big；需要分片时由源节点使用 Fragment Header。IPv6 最小链路 MTU为1280字节，但可用 Path MTU可能更大。
MSS clamping 能解决 QUIC 或 UDP 的问题吗？
不能直接解决。MSS 是 TCP 概念，QUIC 运行在 UDP 之上，需依靠相应实现的数据报尺寸控制及 PMTUD/PLPMTUD。TCP 恢复并不证明 UDP 路径已经正常。
Ping 小包成功能证明 MTU 没问题吗？
不能。小型 ICMP Echo 只能说明该尺寸的往返可达。需要结合地址族、不可分片语义、不同尺寸探测和传输层现象判断，而且部分网络会对 ICMP Echo 与业务流量采用不同策略。
参考资料
- RFC Editor, RFC 9293 — Transmission Control Protocol: https:
/ / www. rfc- editor. org/ info/ rfc9293/ - RFC Editor, RFC 1191 — Path MTU Discovery: https:
/ / www. rfc- editor. org/ info/ rfc1191/ - RFC Editor, RFC 8200 — Internet Protocol, Version 6 Specification: https:
/ / www. rfc- editor. org/ info/ rfc8200/ - RFC Editor, RFC 8201 — Path MTU Discovery for IPv6: https:
/ / www. rfc- editor. org/ info/ rfc8201/ - RFC Editor, RFC 8899 — Packetization Layer Path MTU Discovery for Datagram Transports: https:
/ / www. rfc- editor. org/ info/ rfc8899/ - RFC Editor, RFC 8900 — IP Fragmentation Considered Fragile: https:
/ / www. rfc- editor. org/ info/ rfc8900/