以太网无处不在，几乎所有硬件厂商都有涉及，所有以太网链路都有一个共同的参数：MTU。
$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWNlink/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
MTU（最大传输单元）规定单个网络数据包最大长度。一般来说，在局域网中的设备通讯时，MTU 大约为 1500 字节；实际上互联网也普遍以 1500 字节运行。但是这并不意味着链路层技术无法传输更大的数据包。
例如，802.11 网络（也就是大众所了解的 WiFi）MTU 为 2304 字节；如果你使用光纤，则 MTU 约为 4352 字节。以太网本身具有“巨型帧”的概念，其中 MTU 可以设置为 9000 字节（如果网卡，交换机和路由器支持）。
但是这些在互联网上都意义不大，因为 Internet 主干网目前主要由以太网链接组成，因此数据包实际最大长度现在都是非正式地设置为 1500 字节，以避免数据包在传输链路上被分片。
从表面上看，1500 是一个奇怪的数字，计算机领域碰到的很多数字都基于数学常数，例如使用 2 的幂。但 1500 显然不属于前者。
那么 1500 是从哪里来的，为什么我们仍在使用它呢？
魔术数字
以太网问世第一个重大突破是以 10BASE-2（细缆网）和 10BASE-5（粗缆网）的形式出现，最后的数字是说单个网段可以跨越几个百米。
由于当时有许多竞争协议，并且存在硬件限制，早期设计者在一封电子邮件 (1) 中指出数据包缓冲存储器的需求一定程度决定了 1500 这个数字。（感谢推友 @yeled 提供资料）
回顾一下，大一点 MTU 可能会更好，但是在早期会增加网卡成本，并进而影响以太网的广泛采用。
1980年发表的论文“以太网：本地计算机网络的分布式数据包交换 (2) ”，是对网络大数据包效率成本分析的早期记录。这对当时的以太网设计尤其重要，因为当时以太网在所有系统之间共享同一同轴电缆，或者使用以太网集线器，后者一次只能允许一个数据包在以太网网段的所有成员之间传输。
因此必须选择一个合适的数值，这样在共享网络段（有时很忙）上的传输等待时间不会太久，而且数据包头的开销也不会太大。（请参阅前面提到的论文第15-16页）
因此工程师最终选择了 1500 字节（约 12000 bit）作为最佳“安全”值。
这些年来，各种传输系统出现与消亡，但是它们的 MTU 值仍然使用以太网的 1500 字节。大于 MTU 可能会导致 IP 碎片，或者需要进行路径 MTU 检测。两者都有各自的问题。（为了保险）有时大型操作系统甚至会将默认 MTU 设到更低的水平。
效率的因素
现在我们知道互联网 MTU 设为 1500 主要是由于旧的时延问题和硬件限制，接下来我们分析这个数值对互联网的效率影响到底有多大。
如果我们查看来自骨干 Internet 流量交换点（AMS-IX）的数据，发现至少有 20％ 的数据包通过该交换设备时是最大长度。
我们还可以分析局域网的总流量：
如果将这两个图结合，你将得到如下所示的内容。这是不同大小数据包有多少流量的估计：
如果我们仅看以太网包头所占用的流量，则会得到相同的图表，但比例不同：
这表明在最大的数据包上，仅是数据包头就消耗了大量带宽。由于峰值流量显示开销大约 246G Bit/s 的开销，因此我们可以假设，如果有机会全部采用了巨型帧，此开销仅约为 41G Bit/s。
但是我认为，我们已经航行在更广阔的互联网上。尽管某些互联网运营商使用 9000 MTU 进行运营，但绝大多数运营商不这样做，历史一次又一次地表明，想要改变互联网的集体想法极其困难。
如果你对 1500 字节的 MTU 以太坊历史有更多了解，请通过电子邮件联系作者 ethernet1500@benjojo.co.uk。难过的是，网络上与此相关的手册，邮件列表帖子等内容正在迅速消失。
文中链接：
https://blog.benjojo.co.uk/asset/1hhfq2UR8
https://blog.benjojo.co.uk/asset/4Up5QvCjA
原文链接：
https://blog.benjojo.co.uk/post/why-is-ethernet-mtu-1500
参考阅读：
解决并发编程之痛的良药--结构化并发编程
Hulu如何扩展InfluxDB使其支持每秒百万TPS
深入浅出Rust异步编程之Tokio
聊聊用 UUID/GUID 作为主键那些坑
为了戒网，我给每个网站自动添加3-25秒的访问延迟
如何成为一名在家办公的高效工程师（一个国外团队的远程经验）
本文作者 Dmitry Nosachev，由高可用架构翻译。技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。
高可用架构
改变互联网的构建方式
长按二维码 关注「高可用架构」公众号
