在实践中是否遵守 64 字节最小以太网数据包规则？

Question 1

如果您仔细观察，您会发现所有短于最小帧大小（60 字节，不含 FCS）的帧都是由您的机器传输的帧。接收的帧应填充至 60 字节，不含 FCS；它们包含 Wireshark“数据包详细信息”窗口中“以太网 II”下的“填充”字段，该字段对应于这些额外的字节。

至少在 Linux 中，所有传输的短于 60 字节的帧都应该在传输之前由网络驱动程序（甚至 NIC 硬件）自动填充，但 Wireshark 并未显示这一点，因为在添加填充之前，帧就被复制到 Wireshark 使用的数据包套接字中了。

最初，指定最小帧大小是为了使用于共享以太网介质的 CSMA/CD 协议正常工作 — 可靠的冲突检测要求传输帧所需的时间（与帧大小以及所有报头和前导码成正比）必须大于任何两个站之间的信号传播时间。当前的以太网在大多数情况下实际上并不是共享介质（具有全双工链路的交换机不执行冲突检测）。从技术上讲，在全双工链路上不需要强制执行最小帧大小，但出于兼容性原因，仍然需要这样做。

由于千兆以太网在使用实际电缆长度时，64字节的最小帧大小已不足以进行碰撞检测，而简单地增加最小帧大小将导致带宽的严重浪费，因此运营商扩展引入了半双工千兆链路机制（另见这里更多信息）。载波扩展在网络硬件中实现，对软件不可见。理论上，使用载波扩展使得强制执行半双工链路的最小帧大小成为可选操作，而对于全双工链路，载波扩展和最小帧大小都不是必需的。但是，64 字节的最小帧大小仍然保留，可能是为了与可能需要它的旧软件兼容。

Answer

如果您仔细观察，您会发现所有短于最小帧大小（60 字节，不含 FCS）的帧都是由您的机器传输的帧。接收的帧应填充至 60 字节，不含 FCS；它们包含 Wireshark“数据包详细信息”窗口中“以太网 II”下的“填充”字段，该字段对应于这些额外的字节。

至少在 Linux 中，所有传输的短于 60 字节的帧都应该在传输之前由网络驱动程序（甚至 NIC 硬件）自动填充，但 Wireshark 并未显示这一点，因为在添加填充之前，帧就被复制到 Wireshark 使用的数据包套接字中了。

最初，指定最小帧大小是为了使用于共享以太网介质的 CSMA/CD 协议正常工作 — 可靠的冲突检测要求传输帧所需的时间（与帧大小以及所有报头和前导码成正比）必须大于任何两个站之间的信号传播时间。当前的以太网在大多数情况下实际上并不是共享介质（具有全双工链路的交换机不执行冲突检测）。从技术上讲，在全双工链路上不需要强制执行最小帧大小，但出于兼容性原因，仍然需要这样做。

由于千兆以太网在使用实际电缆长度时，64字节的最小帧大小已不足以进行碰撞检测，而简单地增加最小帧大小将导致带宽的严重浪费，因此运营商扩展引入了半双工千兆链路机制（另见这里更多信息）。载波扩展在网络硬件中实现，对软件不可见。理论上，使用载波扩展使得强制执行半双工链路的最小帧大小成为可选操作，而对于全双工链路，载波扩展和最小帧大小都不是必需的。但是，64 字节的最小帧大小仍然保留，可能是为了与可能需要它的旧软件兼容。

Question 2

恐怕这是一个“视情况而定”的问题

是否遵守 64 字节最小以太网数据包规则？

在什么上？交换机、NIC 之间等等？

不遵守规则会有什么后果？

再次讨论什么以及如何？

通常，最坏的情况是数据包被丢弃，仅此而已，它不会让您的数据中心着火（尽管不要引用我的话，至少在任何法律文件中都不要引用 :) ）。如果它到达路由器，它可能会在出去的路上被重新构造，并且在交换机上它要么通过要么不通过 - 实际上非常二进制。

Answer