MTU、MSS 与封装开销

很容易把 MTU 和 MSS 当成同一个数字的两种叫法。它们不是，而这种混淆造成了相当大一部分隧道性能问题。MTU 是链路的属性：这条链路能承载的最大帧。标准以太网是 1500 字节，这也是超大 ping 过不了一台配置不当的网络设备的原因。

MSS 是 TCP 连接的属性：任一端愿意放进单个报文段的最大载荷。它不是链路设置，也不是由 MTU 协商出来的 —— 每一端通告自己能够接收的 MSS，并根据自己知道的 MTU 减去相应首部来得出这个值。

MSS = MTU − IP 首部 − TCP 首部

IPv4：1500 − 20 − 20 = 1460 字节
IPv6：1500 − 40 − 20 = 1440 字节

1460 这个数字太常见了，值得直接记住。如果你在一条正常工作的连接上看到远低于它的值，说明有东西在加首部 —— 而这正是本页要讲的全部内容。

MTU 是在最外层测量的，因此链路帧与应用数据之间的每一个首部字节，都会减少能装下的数据量。普通路径上是 1500 字节里的 40 字节开销，约 2.7%。一旦加上隧道，这个数字会迅速攀升。

最后两行正是 IPsec 与 MPLS 站点经常需要下调 MTU 的原因。一个使用 AES-CBC 加 SHA-256 完整性校验的 ESP 隧道，光它自己就要加约 73 字节，还没算外层 IP 首部。

以一条承载私有站点流量、跑在公网上的 GRE 隧道为例。线上跑的数据包是公网的以太网帧，私有网络的数据包是它里面的载荷。从外往里算：

用同样的算术看 VXLAN，就明白为什么 overlay 网络常把内层 MTU 设为 1450：以太网、IPv4、UDP、VXLAN，再加内层的以太网、IPv4 与 TCP 首部，合计 14 + 20 + 8 + 8 + 14 + 20 + 20 = 104 字节，在外层 MTU 1500 下留给内层 TCP 载荷的就是 1396 字节。

PMTUD 本应让上述事情全部自动完成。发送方把 Don't Fragment 位置 1，并按自己认为路径能支持的尺寸发包。当某台路由器发现下一跳的 MTU 更小时，它应当丢弃该包并回送一条 ICMP 消息 —— “需要分片”，并携带更小的 MTU。发送方据此减小尺寸后重试。

失效模式在于：ICMP 经常被防火墙拦截，可能是出于安全考虑有意为之，也可能是限速带来的附带损伤。当这条消息永远到不了，发送方会继续用超大包， 而每一个都被丢弃，连接看起来就是卡死。这就是 PMTUD 黑洞，它的表现有非常明确的特征：

最快的诊断方法是发一个带 Don't Fragment 的超大 ping，然后对载荷大小做二分查找，直到能通为止。在隧道上这样测出的应当就是真实的路径 MTU，可以拿它和两端所认为的值对比。

在不能指望 PMTUD 的地方，通常的做法是 MSS 钳制。路径上的某台路由器改写 SYN 与 SYN-ACK 报文中的 MSS 字段，这样两端会立刻使用一个装得下的值，完全不需要去发现什么。这在 PPPoE 链路上很常见：8 字节的 PPPoE 首部把有效 MTU 降到 1492，MSS 降到 1452。

MSS 钳制有几个值得了解的限制。它只影响握手经过钳制设备的那些连接，所以对于处在不在路径上的路由器后面的主机毫无作用。它也不会去改动一条已经建立的连接。而且由于它改写了两端协商一致的字段，它可能掩盖真正的配置错误，而不是修复它。

替代方案包括：在两端显式设置 MSS；把隧道的接口 MTU 调低，让算术自然成立；或者 —— 对 IPv6 而言 —— 尊重"PMTUD 是强制要求"这一点，确保 ICMPv6 类型 2 消息永远不会被过滤。

• 按最外层 MTU 来定 MSS，而不是按 1500。把你实际使用的首部逐个加起来。MTU / MSS 计算器会逐层完成这个算术。
• 绝不要整体屏蔽 ICMP。如果必须过滤，至少要放行入方向的 fragmentation-needed（类型 3、代码 4）—— 屏蔽它会让所有终结在你身后的路径的 PMTUD 全部失效。对 IPv6 则要放行 Packet Too Big（类型 2）。
• 记住 1460 只对普通 IPv4 以太网路径成立。IPv6 是 1440，PPPoE 是 1452，任何带隧道的路径都还要更小。
• 隧道的实际代价往往高于首部算术的估算。GRE over IPsec 叠起来可以吃掉一百多字节，把 1500 字节的路径压到 MSS 接近 1330。
• 两个方向都要检查。不对称路由意味着回程路径的 MTU 可能不同，而 MSS 是按方向分别通告的。