在出现网络连接挂起、冻结、缓慢、无响应的情况时，其原因通常会被不合理地认定为“MTU/MRU 问题”，并仓促提出几种“灵丹妙药”（通常对情况无效或不适用），例如涉及iptables或的命令ifconfig，以及其他“将 MTU 夹紧到 TSS”的咒语。
我想知道 MTU/MRU 问题到底是什么，为什么它会影响连接速度和延迟，以及如何解决它（已知和现代方法），因为我想以知识的方式解决这个问题，而不是用魔法。
答案1
这个问题有点复杂，所以我先从基础开始。如果你已经知道这些，请原谅我。
MTU 是最大传输单元，即计算机接口将发送的最大数据包。对于以太网，默认值为 1500 字节。以太网帧通常允许的最大大小为 1522-1542（取决于您计算的大小），而额外的空间则“保留”用于标头信息。
不同的连接可能具有不同的功能。在 Internet 上遇到 MTU 略小于 1500 的链接是很常见的。这通常是由于该链接使用了额外的标头信息或使用了除“标准”以太网之外的介质（大多数 Internet 实际上运行在 ATM/SoNet 连接上）。通常，遇到此类链接的流量会被简单地分成多个部分并发送。
因为这种情况很常见，而且在发明 IP 时也是如此，ICMP 协议的部分职责是通报 MTU 的任何问题。如果由于某种原因无法分解和转发数据包，则使用 ICMP 将问题反馈给发送计算机。发送计算机采取适当的措施，将信息分解成较小的块，每个人都会很高兴。整个过程都在后台处理。在正常运行的网络 永远不需要处理 MTU 设置。
最后一句的限定词是关键。自动化流程失败的常见原因有三个：
- 实施不力 - 软件在某些时候根本无法正常工作。没有法律规定人们必须遵守互联网的相关标准，而且有些公司会违反标准，通常是为了省钱。
- 管理禁用实施 - 一些好心人会破坏软件，因为他们实际上不知道自己在做什么。我亲眼见过有人阻止 ICMP，因为他们认为它只用于 ICMP.0.0 数据包（回显，大多数人通过实用程序知道这一点
ping）。 - 其他原因完全超出了这一“正常”过程。最常见的情况是，连接损耗太大，只有较短的数据包才能可靠地通过连接（或无需大量重试）。一些早期的 DSL 和 CableModems 存在此类问题。在此之前，拨号上网在使用质量极差的电话线和激进的线路编码时通常会遇到此类问题。
那么，为什么这种情况很常见：懒惰的技术人员/公司。用一个很小的 MTU 来限制连接几乎普遍比修复上述问题之一“更容易”。如上所述，现在没有人应该处理 MTU（我能想到的唯一例外是启用巨型帧，但这实际上不是我们在这里讨论的）。无论如何，正确的治疗方法是找出根本问题并解决它；典型的治病不治标的例子。
MTU 如何影响连接？将数据切成小块意味着每块数据都有更好的机会到达目的地，尤其是在高度不可靠的连接中。然而，由于数据块较小，传输的每个数据的开销更大。这意味着有效连接速度会降低；如果 MTU 真的很小，则显著降低。延迟可能会受到影响，尽管我预计影响很小，因为标头和碎片/重组过程需要额外的处理和开销。
更新：- 关于--clamp-mss-to-pmtu
我个人，我从未对 MTU 进行过任何改动；我承认我有点完美主义，当遇到这种丑陋的 hack 时，我总能找到问题的根源并能够纠正它。为此，我对这个iptables选项--clamp-mss-to-pmtu并不熟悉。显然，使用这种 hack 非常常见，而且在大多数情况下可能非常没有必要。它仍然是一种弥补上述问题之一的 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 系统，但几乎可以适用于任何操作系统。
- 选择一个 ICMP Ping 目标（例如 Google.com、Yahoo.com、Facebook.com 等）。尝试使用以下命令 ping 它们：
ping -c 2 -s 1472 -D google.com。- 这应该成功。如果不成功，它应该返回“数据包需要分段”。如果其中任何一个为真，则停止，您的连接工作正常。
- 如果没有返回任何内容，或者给出“超时”消息，则说明存在问题。
- 仅适用于断开的连接：运行
traceroute -F google.com 1472。这将告诉您哪个跳转已断开。注意：CPE 不响应跟踪路由请求的情况很常见，因此如果第一跳转没有响应，请不要惊慌。- 无论哪个最后响应的跳转都是对您来说正常工作的最后一个跳转。
- 如果它们均未响应，则可能是您的 CPE 或 DSL 线路（确定哪个线路可能有点棘手，但如果是现代线路，则几乎肯定不是 CPE）。注意：如果您的连接正常，则 traceroute 将成功完成。
附言：现在哪个 ISP 使用 PPTP？！这是过时且无用的过去的产物。他们至少应该使用 PPPoE；但只需通过 MAC 和 Segment 授权调制解调器就会容易得多（对 ISP 和客户来说都更容易）。