MTU/MRU 问题究竟是什么，它是由什么引起的以及如何解决它？

Question

在挂起、冻结、缓慢、无响应的互联网连接的情况下，原因通常被不合理地确定为“MTU/MRU 问题”，其中包含几个仓促提出的“魔法疗法”（通常无效或不适用于这种情况），例如涉及iptables或 的命令ifconfig，以及其他“将 MTU 钳制到 TSS”法术。

我想知道的是 MTU/MRU 问题究竟是什么，它为什么会影响连接速度和延迟，以及它是如何解决的（已知的和现代的方法），因为我想以知识渊博的方式解决问题，不是神奇。

Answer 1

这是一个有点复杂的问题，所以我将从基础开始。如果你已经知道这一切，请原谅我。

MTU 是最大传输单元，是计算机接口将发送的最大数据包。对于以太网，默认值为 1500 字节。以太网帧通常最多允许为 1522-1542（取决于您的计数），并且额外的空间被“保留”用于标头信息。

各种连接可能具有不同的能力。在 Internet 上运行 MTU 略小于 1500 的链接是很常见的。这通常是由于链接使用了额外的标头信息或使用了“标准”以太网以外的介质（大多数 Internet 实际上运行在ATM/SoNet 连接）。通常，遇到这种链接的流量会被简单地分成多个部分并一起发送。

因为这很常见，而且是在 IP 被发明的时候，ICMP 协议的部分职责是与 MTU 沟通任何问题。如果一个数据包由于任何原因不能被破坏和转发，ICMP 用于将问题传达回发送计算机。发送计算机采取适当的行动，将信息分解成更小的块，每个人都很高兴。这整个过程是在幕后处理的。在正常运行的网络中 ，永远不需要搞砸 MTU 设置。

最后一句话的限定词是踢球者。自动化流程出现故障的常见原因有以下三个：

1. 破碎的实现 - 软件在某些时候无法正常工作。没有法律规定人们必须遵循互联网的相关标准，也有违反标准的公司，通常是为了便宜。
2. 行政上禁用的实施 - 出于好意的人会破坏软件，因为他们实际上并不知道他们在做什么。我个人见过有人阻止 ICMP，因为他们认为它仅用于 ICMP.0.0 数据包（回声，大多数人都知道该ping实用程序）。
3. 完全超出这个“正常”过程的其他原因。通常，这意味着连接非常有损，只有较短的数据包才能可靠地通过连接（或无需大量重试）。一些早期的 DSL 和 CableModems 有这样的问题。在此之前，当使用质量很差的电话线和激进的线路编码时，拨号通常会出现这样的问题。

那么，为什么很常见：懒惰的技术人员/公司。与解决上述问题之一相比，几乎普遍“更容易”阻止与微小 MTU 的连接。如上所述，现在没有人应该每个人都必须与 MTU 搞混（我可以想到启用巨型帧的一个例外，但这实际上不是我们在这里讨论的内容）。在任何情况下，正确的解决方法是找出潜在的问题并解决它；治病不治本的经典案例。

MTU 如何影响连接？将数据切成小块意味着每块都有更好的机会到达目的地，尤其是在高度不可靠的连接中。然而，作为较小的部分，每个传输的数据有更多的开销。这意味着有效连接速度降低；如果 MTU 真的很小。延迟可能会受到影响，但我希望它是轻微的，因为头和碎片/重组过程的额外处理和开销。

更新： - 就--clamp-mss-to-pmtu
我个人而言，我从未与 MTU 混过；我承认我有点完美主义者，当遇到像这样丑陋的黑客时，我总能找到问题的根源并能够纠正它。为此，我不熟悉该iptables选项--clamp-mss-to-pmtu。显然，使用这种 hack 是非常普遍的，并且在大多数情况下可能非常没有根据。弥补上述问题之一仍然是一种黑客攻击。我引用了 iptables(8) 的 Linux 联机帮助页：

此目标用于克服那些阻止“需要 ICMP 分片”或“ICMPv6 数据包太大”数据包的犯罪脑残 ISP 或服务器。

联机帮助页的相对严厉的语言应该表明不遵循 RFC（并且不努力尝试或补偿）的 ISP 和网络获得了多少蔑视。

谈到在 VPN 中使用 UDP，这曾经是最常见的，以最小化 VPN 的开销并允许现有端点管理会话信息。VPN 无法知道应如何处理会话，因此该任务最好留给知道的应用程序。

许多现代 VPN 隧道协议建立在较低级别（甚至更少的开销）上，例如 GRE 和 L2TP；或在更高级别进行隧道传输（通常是为了与限制性防火墙兼容或其他原因），例如 SSTP 或 SSH。这些将逐渐取代 UDP 作为传输机制。

更新 2： - 诊断 MTU/ICMP 问题
因此，您认为您遇到了 MTU/ICMP 问题并希望确定。这个过程有两个基本步骤。这些说明适用于 Linux 或 BSD 机器，但几乎可以适用于任何操作系统。

1. 选择一个 ICMP Ping 目标（例如 Google.com、Yahoo.com、Facebook.com 等）。尝试使用以下命令 ping 它们：ping -c 2 -s 1472 -D google.com.
   • 这应该会成功。如果不成功，它应该返回“数据包需要分片”。如果其中任何一个是真的，请停止，您的连接工作正常。
   • 如果这没有返回任何内容，或者给出“超时”消息，那么您有问题。
2. 仅对于断开的连接：运行traceroute -F google.com 1472。这会告诉你哪个跃点坏了。注意：CPE 不响应 traceroute 请求是很常见的，所以如果第一跳没有响应，请不要惊慌。
   • 响应的最后一跳是最后一个适合您的跳。
   • 如果他们都没有响应，那就是你的 CPE 或 DSL 线路（弄清楚哪个可能有点棘手，但如果它是现代的，它几乎永远不会是 CPE）。注意：如果您的连接工作正常，traceroute 将成功完成。

附带说明：现在什么 ISP 使用 PPTP？！这是过时和无用的过去的爆炸。他们至少应该使用 PPPoE；但简单地通过 MAC 和 Segment 授权调制解调器会容易得多（对 ISP 和客户来说都更容易）。