就我个人而言，我从未见过它们在真实环境中使用，所以我想知道我是否只是在观看错误的网络，或者是否通常不使用巨型帧（然后：为什么？设备无法处理巨型帧今天仍然是一个问题吗？） .

巨型帧在整个互联网上几乎不存在；然而，许多公司在专用 LAN 和 WAN 中大量使用巨型帧。最常见的应用是数据库/存储流量，以提高链接/服务器的效率。

• 链接通过巨型帧获得更有效的容量
• 使用 Jumbo 帧可以显着降低服务器上的 CPU 负载；取决于在NIC 硬件中使用GRO、TSO 和 LRO 选项。我听说有些应用程序在 TSO/LRO 开启的情况下表现不佳。

1500 字节 MTU 时的最大链路效率约为 95%（假设 TCP 流量），而 9000 字节 MTU 时为 99%：

• 以太网包括 20 字节的成帧开销（Preamble + SFD + IPG）
• 以太网标头为 18 个字节
• IP 和 TCP 传输额外的 40 多个字节的标头（IP 标头为 20 个字节，TCP 标头至少为 20 个字节）
• CRC 为 4 个字节

1500 字节 MTU 时的以太网有效负载效率

1500 字节的效率（假设没有 Vlan 标签）为：94.93%

(data_size) / (ethernet_frame_size_on_wire)
(1500 - 40) / (18 + 1500 + 4 + 20) = 1460 / 1538 = 0.949284

9000 字节 MTU 时的以太网有效负载效率

9000 字节的效率（假设没有 Vlan 标签）为：99.14%

(data_size) / (ethernet_frame_size_on_wire)
(9000 - 40) / (18 + 9000 + 4 + 20) = 8960 / 9038 = 0.99136977

在 GigabitEthernet 速率下，您可以通过 Jumbo 帧获得大约 42Mbps 的速度（假设链接以最大容量运行）。

为什么巨型帧限制为 9000 字节？我想我读了一些关于这与 32 位 CRC 和的限制有关的内容

正如您在问题中所断言的，这主要是由于32 位 CRC的数学计算。更改 CRC 非常激进，因为您的交换机和所有 NIC 都需要使用相同的 CRC 计算。

很难研究，因为互联网上不存在巨型帧。（也许是 Internet2，但这不是一个全球性的公共网络。）巨型帧的主要行业用途是大批量数据传输——即 SAN 基础设施。在连接到 Internet 的网络上使用 jumbo 会带来问题——PMTUd应该允许它工作，但是有很多网络会破坏它。

帧大小不限于 9000。实际上，没有标准定义巨型帧。（出于向后兼容性的原因，它永远不会成为任何 802 标准的一部分）我有允许 16k 帧的设备。我有一些只能做 5000 次的装备——它的限制是缓冲空间。

较长的帧在统计上会增加未检测到位错误的概率。校验和的长度不能改变。它是以太网的基础部分。如果更改FCS算法，它将不再是以太网。