64字节的最小以太网数据包规则在实践中受到尊重吗？

如果仔细观察，您会注意到所有比最小帧大小（没有FCS的60个字节）更短的帧是由您的机器传输的帧。 接收到的帧应该填充到60个字节而没有FCS; 它们包含Wireshark“Packet Details”窗口中“Ethernet II”下的“Padding”字段，对应于这些额外的字节。

至less在Linux中，传输之前，所有传输的帧数less于60个字节的应该被networking驱动程序（甚至NIC硬件）自动填充，但Wireshark没有显示这个，因为帧被复制到Wireshark使用的数据包套接字在填充之前添加​​。

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

由于千兆位以太网在使用实际的电缆长度时，64字节的最小帧大小已经不足以用于碰撞检测，并且仅仅增加最小帧大小会导致带宽的显着浪费，因此， 扩展机制被引入用于半双工千兆位链接（更多信息请参见这里 ）。 运营商扩展在networking硬件中实施，软件不可见。 从理论上讲，使用载波扩展可以实现对半双工链路可选的最小帧大小，而对于全双工链路，不需要载波扩展和最小帧大小。 然而，64字节的最小帧尺寸仍然保留，可能是为了与可能期望的旧软件兼容。

这恐怕就是这些“依赖”的问题之一

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

什么？ 一个交换机之间的网卡等？

不遵守规则的后果是什么？

再次在什么和如何？

一般情况下，最坏的情况是数据包被丢弃，就是这样，它不会让你的数据中心着火（尽pipe不要引用我的意思，反正也不会在任何法律文件中）。 如果它碰到一个路由器，它可能会重新构build，无论如何，它会通过或不通过交换机 – 真的很漂亮。