以太网最大报文长度1500，为何要超它？

转发来源：https://www.wangan.com/p/7fy7f44d987b2de2

既然 Ethernet 的最大报文长度是 1500，我们有什么理由发送大的报文呢？大的报文会导致 ip 分段。

理想与现实的差距，网络世界亦是如此。

无论是家庭局域网，还是互联网，网络接口绝大多数使用 Ethernet 接口，Ethernet 接口标准的 MTU= 1500 Bytes。这是 Ethernet 接口对于承载的上层货物制定的硬性限制。

什么是上层货物？

Ether-Type 字段之后，FCS 之前的数据字节，就是上层货物。这个货物可以为 IP、ARP、IPv6 等等。意味着，IP 报文、ARP 报文、IPv6 报文最大尺寸为 1500 字节。通常称它们为 Packet。

1500 字节包含 Ethernet Header、Ethernet Tailer 吗？

不包括。当来自上层的货物（Packet），被 Ethernet 接口自动添加了 Ethernet Header、Ethernet Tailer，就不叫 Packet，而是叫 Frame。

最长的 Ethernet Frame 是多少？

Frame = Header + Packet + Tailer

= Destination+Source +Ether-Type+Packet+FCS

= 6 + 6 +2 + 1500 +4

= 1518

所以，Ethernet 最长帧长度为 1518 字节，而不是 1500 字节。

每台计算机都通过 MTU=1500 来限制上层货物的大小。假设有一个 IP Packet，报文长度为 1500 字节，正在离开家庭局域网某一台电脑，经过电脑 Ethernet 口时，一切正常，顺利通过。

然后 IP Packet 继续上行，到达家庭局域网的出口处，也就是光猫的 WAN 接口，出了一点小状况。之所以出状况，是因为光猫是 PPPoE 拨号客户端，IP Packet 外层需要先被 PPPoE 包裹（Encapsulation），然后才能被 Ethernet 包裹。这两层的包裹关系可以看下方示意：

Frame = Header + PPPoE + IP Packet+ Tailer

            = 14 + 8 + 1500+ 4

            = 1526

从 Ethernet 接口的眼光看来，来自上层的货物不再是 1500 字节长的 IP Packet，而是 1508 字节的 PPPoE + IP Packet。

光猫的 WAN 口 MTU = 1500，由于包裹的大小 1508 > 1500 MTU，那么光猫需要将这个大包裹进行拆分成≤1500 才能放行。

IP 包裹的拆分，会大大影响光猫或其他网络设备的数据吞吐性能，所以网络设计时会想尽一切方法予以避免。那么在真实网络里是如何避免 IP 包裹的拆分（分片）的？

手段千奇百怪，争奇斗艳，但是不外乎两种手段：

内卷
外卷
什么是内卷？

就是想尽一切办法限制 IP Packet 的源头（IP 报文诞生地）的大小，通常小于标准 MTU 1500 字节。充分考虑 IP 报文端到端可能会添加形形色色的外层包装，IP 报文被添加了层层附加报文头，在到达目的地的时候，依然≤1500 字节，是不是一个好主意呢？

是的，这是现网中最完美的解决方案。还是以上文的例子为例，如果数据的源头 IP 报文大小不是 1500，而是 1492，那么在光猫的 WAN 口，即使添加 8 个 PPPoE 字节头，报文也不过 1500 字节长，依然可以顺利通过。说的容易，如何实现呢？

TCP 层面的限制

通过将 MSS 变小，从而间接将 IP 报文变小。

大家访问知乎服务器，知乎服务器为了限制客户端发出 IP 报文为 1492，只需要在三次握手时使用 MSS Option，将 MSS 设置为 1452 即可。这种方法固然好，但是只能抵消因为添加 PPPoE 头（8 个字节）而增加的长度。

但是，如果在客户端与服务器之间，还有公司的 VPN 存在，如何处理？

可以在 VPN 网关上，使用中间人技术（TCP Adjust-MSS），偷偷修改客户端与服务器的 TCP MSS，将其变得足够小，可以充分抵消由于添加 PPPoE、VPN 而增加的报文头。通常将 MSS 修改成 1380 可以应对绝大多数的网络场景。

能不能将 MSS 修改成 1000 或更小？

当然可以，但是报文小会影响传输效率，所以 1380 是一个不错的选择。当然在复杂环境中，1380 依然还是太大，可以继续下调 100 字节到 1280 字节。

UDP 层面的限制（应用层面的限制）

UDP 是无状态的，所以无法限制。为了限制数据源头的 IP 报文大小，通常是在限制跑在 UDP 上的应用层的数据报文的大小。比如所有发出应用层报文限制在 1380，少的 120 字节可以有效抵消互联网附加的报文头。

认证服务器 Radius，是一个基于 UDP 的应用。为了避免报文被分片，有一些厂商将数据源头限制在 1180 字节，少的 320 字节可以完全应对最严峻的网络环境。

读者是否觉得 1180 太保守？

厂商吃了太多关于 MTU、IP 报文分片的苦头，经过多年的网络实践，将其定为 1180。尽管保守，但是却非常可靠。

一次网络调试，其他厂商的 Radius 都出问题，唯独这个保守的厂商没有出问题。后来经过排错，发现网络端到端有效 MTU 不是 1500，而是 1450，而且不管 DF 是 1 还是 0，只要超出 1450 统统无法通行。这家保守的厂商最后胜出！

IP 层面的限制

通常 IP 层面不做限制，保持标准 MTU = 1500。完全依赖于 TCP、应用层面的限制。

但是，如果各位电脑上远程使用 VPN，本地 VPN 接口 MTU 通常为 1380 甚至更小，这是 IP 层面的限制。谈完内卷，再谈谈外卷。

外卷

网络设备将 MTU 上调到大于 1500，充分考虑到网络可能附加的报文头。

依然以第一个例子为例，如果光猫的 WAN 接口 MTU = 1508 而不是 1500，既然添加了 8 个字节的 PPPoE 报文头，是不是也无需拆分 IP 报文？

是的。

假设 IP 报文顺利离开光猫 WAN 口，进入运营商交换机，交换机上行 Tunk 口 MTU = 1508 够用吗？

不够，因为报文又被添加了一层或者两层 802.1Q，用于承载 VLAN 信息。怎么办？

很好办，只要将 Trunk 口的 MTU 上调为 1516 甚至更大，完全 Cover 由于增添报文头而带来报文长度的增加。

一句话概述，就是网络设备将 MTU 大大调大，用于容纳由于添加报文头而增加的长度，避免由于报文头增加而引起的 IP 报文分片。

最后，IP 报文越长传输效率越高，IP 报文最长为 65536 字节。为何 Ethernet 接口不能将 MTU 设置为 65536 字节，而是限制在 1500 字节？

这是一个历史遗留问题。Ethernet 发送方与接收方时钟需要同步，发送长帧意味着更长的发送时长。接收方很难保持与发送方的时钟同步，时钟偏移变大，出错的概率就会上升。为了限制错误率，将帧的长度做了上文的限制。

90 年代数字信号处理器 DSP 技术进步，锁相环技术进步，带来 Ethernet 传输技术进步。即使发 10000 字节长帧，双方依然可以保持时钟同步，出错概率依然很小。当前的路由器、交换机支持 MTU 到 9800 字节、甚至更大。

在数据中心的网络里，为了提高数据的传输效率，通常采用外卷法，交换机 MTU 设置为 9800 甚至更大，当服务器与服务器之间使用 9100 字节进行通信时，无需任何 IP 分片，IP 报文畅通无阻，将数据传输的效率最大化！