64 字節最小乙太網數據包規則在實踐中是否得到遵守？
對我的網路介面進行一次快速的 WireShark 掃描會發現一堆長度小於 64 字節的乙太網數據包。我知道 WireShark 去除了尾隨的 4 字節 CRC，但我仍然看到一些 42 字節的 ARP 數據包，一些 54 字節的 IGMPv3 和一些 54 字節的 TCP。
是否遵守 64 字節的最小乙太網數據包規則？不遵守規則的後果是什麼？
如果你仔細看，你會注意到所有小於最小幀大小（60 字節，沒有 FCS）的幀都是你的機器傳輸的幀。接收到的幀應該填充到 60 字節，沒有 FCS；它們包含Wireshark“數據包詳細資訊”視窗中“乙太網II”下的“填充”欄位，對應於那些額外的字節。
至少在 Linux 中，所有傳輸的小於 60 字節的幀應該在傳輸之前由網路驅動程序（甚至 NIC 硬體）自動填充，但是 Wireshark 沒有顯示這一點，因為幀被複製到 Wireshark 使用的數據包套接字在添加填充之前。
最初指定最小幀大小是為了使用於共享乙太網介質的 CSMA/CD 協議正常工作——可靠的衝突檢測要求傳輸幀所需的時間（與幀的大小成正比，連同所有報頭和前導碼）必須大於任意兩個站之間的信號傳播時間。目前的乙太網在大多數情況下實際上並不是共享介質（具有全雙工鏈路的交換機不執行沖突檢測）。從技術上講，在全雙工鏈路上不需要強制最小幀大小，但出於兼容性原因仍然這樣做。
由於千兆乙太網在使用實際電纜長度時，64字節的最小幀大小已不足以進行沖突檢測，而簡單地增加最小幀大小會導致頻寬的嚴重浪費，因此為半雙工千兆引入了載波擴展機制連結（另請參閱此處了解更多資訊）。運營商擴展在網路硬體中實現，對軟體不可見。從理論上講，使用載波擴展可以使半雙工鏈路的最小幀大小可選，而對於全雙工鏈路，既不需要載波擴展，也不需要最小幀大小。但是，仍然保留了 64 字節的最小幀大小，可能是為了與預期的舊軟體兼容。