系统与基础设施blog.benjojo.co.uk
1500 字节如何成为互联网的 MTU
How 1500 bytes became the MTU of the internet
2020 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
作者从以太网的历史出发，探讨为什么 1500 字节成为了互联网通用的 MTU（最大传输单元）。文章结合早期以太网硬件（如 Xerox Alto 网卡）的设计约束，分析了包大小与开销、缓存成本、时钟同步等因素之间的权衡。
为什么经久不衰：MTU 1500 是互联网最基础却少有人追问的默认值，这篇文章把一段被时间尘封的工程决策讲清楚，对理解网络底层设计至今仍有价值。
HN 评论精选
1500 字节的真正原因是权衡包头开销与昂贵的缓冲内存，而非时钟同步。
作者最初把 1500 归因于时钟同步问题，但评论者指出早期以太网采用自时钟编码，时钟精度从来不是问题；真正原因是包不能无限大，要在开销低于 2%-5% 的前提下尽量小，而当年 SRAM 极其昂贵，更大的包会让交换和缓冲成本过高。作者后来已更正文章。
mertenVan查看英文原文
Software developer talking confidently about electrical engineering issues he knows nothing about. How cute. /s All Ethernet adapters since the first Alto card had self-clocking data recovery [1]. Clock accuracy was never a problem, as long as it was withing the acceptable range required for PLL lock/track loop. The reason for 1500 MTU is that for packet-based systems, you don't want infinitely large packets. You want small packets. but large enough so that packet overhead is insignificant, which in engineering terms means less than 2%-5% overhead. Thus 1500 max packet size. Everything above that just makes switching and buffering needlessly expensive, SRAM was hella expensive back then. Still is today (in terms of silicon area). Look at all the memory chips on Xerox Alto's Ethernet board (below) - memory chips were already taking ~50% of the board area! [1] Schematic of the original Alto Ethernet card clock recovery circuit: https://www.righto.com/2017/11/fixing-ethernet-board-from-vintage.html EDIT: Lol! Author has completely replaced erroneous explanation with correct explanation, including link to seminal paper about packet switching. Good.
碰撞浪费时间和廉价网卡晶振精度不足也是 MTU 偏小的历史原因。
1500 的选择还与早期共享信道的碰撞有关：CSMA 下两节点同时发送会碰撞并浪费整帧时间，10Mbps 下 1500 字节意味着碰撞要浪费 1.2ms，因此 1500 是经验性选择。此外早期廉价网卡不恢复时钟，晶振偏差超过 0.12% 就会损坏长帧的末尾比特，作者确实遇到过短帧正常、长帧挂死的网卡。
gugagore查看英文原文
It would be nice to corroborate this reason with another source, because my understanding is that clock synchronization was not a factor in determining the MTU, which seems really more like a OSI layer 2/3 consideration. I am surprised the PLLs could not maintain the correct clocking signal, since the signal encodings for early ethernet were "self-clocking" [1,2,3] (so even if you transmitted all 0s or all 1s, you'd still see plenty of transitions on the wire). Note that this is different from, for example, the color burst at the beginning of each line in color analog TV transmission [4]. It is also used to "train" a PLL, which is used to demodulate the color signal transmission. After the color burst is over, the PLL has nothing to synchronize to. But the 10base2/5/etc have a carrier throughout the entire transmission. [1] https://en.wikipedia.org/wiki/Ethernet_physical_layer#Early_implementations [2] https://en.wikipedia.org/wiki/10BASE2#Signal_encoding [3] http://www.aholme.co.uk/Ethernet/EthernetRx.htm [4] https://en.wikipedia.org/wiki/Colorburst
MTU 未随链路速度增长，迫使 Wi-Fi 用 AMPDU 等复杂机制弥补小包的低效。
对 802.11 来说最大开销不是包头而是随机的介质获取时间，1500 字节太小，单包发送开销可达 90% 以上。802.11n 之后不得不用 AMPDU 聚合（每次获取介质后连发最多 64KB，配合滑动窗口块确认），引入了大量复杂机制。如果 MTU 随链路速度同步增长，生活会简单得多。
mhandley查看英文原文
For 802.11, the biggest overhead is not packet headers but the randomized medium aquisition time so as to minimize collisions. 1500 bytes is way too small here with modern 802.11, so if you only send one packet for each medium aquisition, you end up with something upwards of 90% overhead. The solution 802.11n and later uses here is to use Aggregate MPDUs (AMPDUs). For each medium aquisition, the sender can send multiple packets in a contiguous burst, up to 64 KBytes. This ends up adding a lot of mechanism, including a sliding window block ack, and it impacts queuing disciplines, rate adaptation and pretty much everything else. Life would be so much simpler if the MTU had simply grown over time in proportion to link speeds.
实践中许多大网站因 PMTUD 不可靠而主动使用小于 1500 的有效 MTU。
1500 就像刻在石碑上的数字，没人讨论其历史。但值得注意的是，很多大网站故意不发满 1500 字节的包，因为路径 MTU 发现经常失效，干脆把有效 MTU 设为 1450 或 1480 了事。在 SYN 中相应调低 MSS 可能更有效，但统计难做，操作系统也没提供便捷的测试手段。
toast0查看英文原文
No comments on history, AFAIK, Packet Length Limit: 1500 was found on a stone tablet. But note that many high profile sites purposefully do not send 1500 byte packets. Path MTU detection has many cases where it doesn't work, so it's simpler to say f*** it and set your effective MTU to 1450 or 1480 and call it a day. Reflecting the MSS in SYN minus 8 (assuming a poorly configured PPPoE link) or 20 (assuming a poorly configured IPIP tunnel) or even 28 (both) is probably more effective, but stats are hard to gather, and AFAIK no OS makes it easy to run a test, you'd need to patch things and divert packets and have a good representative section of users, etc.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选