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

如果互联网连接挂起，死机，速度慢，无响应，则原因通常会被不合理地标识为“ MTU / MRU问题”，并草率地提出了“魔术疗法”（通常对情况无效或不适用），例如涉及iptables或的命令ifconfig，以及其他“将MTU固定为TSS”咒语。

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

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

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（我可以想到启用Jumbo帧是一个例外，但这并不是我们在此讨论的内容）。无论如何，正确的解决方法是找出潜在的问题并加以解决；治疗疾病不是症状的经典案例。

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

更新： -就--clamp-mss-to-pmtu
我个人而言，我从未对MTU感到厌烦；我承认我是一个完美主义者，当遇到这种丑陋的骇客时，我总能找到问题的根源并能够纠正它。为此，我不熟悉该iptables选项--clamp-mss-to-pmtu。显然，使用此hack非常普遍，并且在大多数情况下可能毫无必要。仍然可以弥补上述问题之一。我从Linux手册页中引用iptables（8）：

此目标用于克服阻塞“ 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和网段授权调制解调器就容易得多了（对于ISP和客户都更容易）。