同學們在學網絡課程的時候都知道，除巨幀外，常見的以太網幀的長度范圍是64字節到1518字節，并且因為最初總線型半雙工的組網原因，人們制定了CSMA/CD協議，規定了以太網中最短幀為64字節。然而，互聯網的發展日新月異，今天的網絡早已不是當初的半雙工模式，CSMA/CD協議也早已不再使用，那么現在網絡是否允許小于64字節的以太網幀或者報文傳輸呢？本文搭建硬件環境進行了驗證。

回顧

電磁波在雙絞線上傳輸的速度為0.7倍光速，在1km電纜的傳播時延約為5us。傳統的網絡信道比較差，需要有重傳機制保障可靠性。于是，在節點A向節點B發送數據進行通信的時候，要保證以太網的重傳，必須保證A收到碰撞信號的時候，數據包沒有傳完，要實現這一要求，A和B之間的距離很關鍵，也就是說信號在A和B之間傳輸的來回時間必須控制在一定范圍之內。IEEE定義了這個標準，一個碰撞域內，最遠的兩臺機器之間的round-trip time 要小于512bit 時間。(來回時間小于512位時，所謂位時就是傳輸一個比特需要的時間）。因此，傳統以太網有如下特點： 1、最大覆蓋距離（兩個站點最遠的距離）：2500m； 2、爭用期（即一個信號最遠來回的傳播時間）：51.2us；過來這個時間還未監聽到沖突，則說明無沖突； 3、最小幀長：64字節；因為傳統以太網速率是10Mbps，爭用期是51.2us；即在這個時間內，幀的數據不能發完，否則將不能監聽到沖突了（CSMA/CD協議是邊發邊聽、不發不聽；因為如果幀發完，則不在監聽，這個時候即使來了有沖突的信號，不在監聽，也不知道已經沖突了），這樣的話CSMA/CD協議可靠性也就大大折扣了；即：B/10M >= 51.2us;即512bit，64個字節； 4、幀間最小間隔：9.6us；相當于發送96bit；即在CSDM/CD協議下，一個站點在監測到信道空閑后，需要等待9.6us才能發送數據；（主要目的是留給剛剛接收數據的站點清理接收緩存，做好接下一陣的準備----------流量控制其實也是） 上述所說的以太網幀是針對以太網Ⅱ型幀進行的描述。幀格式如下：

那么，現在互聯網中發送長度小于64字節的報文時如何傳送呢？比如ARP報文。有效長度如下： ARP報文：4字節+4字節+6字節+4字節+6字節+4字節=28字節，遠不夠64字節。 事實上，在傳送ARP報文時，需要進行填充。

arp程序代碼里，會增加一個填充程序，填充字段 18字節， 這樣以太網數據部分=ARP28字節+填充18字節=46字節。這樣，Dmac 6字節+S mac 6字節+ type 2字節+ARP 46字節+FCS4字節=64字節。 從而保證了互聯網上可以有效的傳輸小于64字節的報文。上述內容來源于網絡，如有侵權，請聯系我刪除。網上有很多很多討論為什么以太網幀最短幀為64字節的文章，大家可以自行百度。我們關注的問題是，如果不填充，而是強行傳送小于64字節的報文呢？我們搭建了一個上板實驗進行了驗證。

實驗環境

開發板：Zedboard。 網絡：雙絞線接Zedboard四端口擴展板1口和3口并形成回環。 EDA工具：Vivado2018.2、ModelSim10.5。 真實硬件驗證環境如下圖（請忽略圖中紙箱子等雜物）：

回環結構

實驗目的：為了驗證，在實際鏈路中短于64字節的mac數據幀能否通過雙絞線在phy層之間傳輸，以及mac核對于長度不符合要求的數據幀的處理情況。

事實上，在上圖中，最短幀能否通過MAC1對應的RJ45網口發出來的前提是能否順利的通過PHY芯片，FPGA芯片、PHY芯片以及RJ45接口的關系圖如下：

PHY與FPGA之間的接口為RGMII接口。在FPGA內部構建的長度小于64字節的以太網幀，通過FPGA芯片與PHY芯片之間的RGMII接口首先發給PHY芯片，如果能夠順利的通過PHY芯片，才能從RJ45接口（MAC1）通過雙絞線發送給MAC2的RJ45接口，進而再經過MAC2對應的RJ45接口、PHY芯片，最后送回到FPGA芯片內部。如下圖所示，左側MAC1采用自己寫的超短幀產生和接收模塊，右側MAC2采用Opencores上的開源MAC核。

數據流

Step1：通過data_gen模塊循環發送定長數據32’h12_34_56_78，通過8位數據端口傳給ephy_source模塊。

Step2：ephy_source模塊根據接收的數據，以及長度進行mac幀封裝，并填寫固定目的mac地址：48’h01_01_01_01_01_01以及源mac地址:48’h08_08_08_08_08_08之后依次按單字節發送數據域內數據，并進行crc計算。

Step3：通過rgmii接口模塊進行8位gmii接口數據到4位rgmii接口數據的轉換后接到phy層。

Step4：經雙絞線傳輸后來到另一端的phy層，并依次經過phy層、rgmii轉換送入mac處理。

Step5：mac接收的數據，在去掉前導碼、crc校驗后，以32位寬的形式將數據部分發送給用戶側，這里直接將數據通過回環發送到mac2的用戶發送數據端口，再次通過mac2的組幀、crc計算、8位gmii到4位rgmii的轉換之后通過phy2的tx發送回phy1的接收端口。

超短幀長度設置為40字節。從MAC1發出，經過PHY1芯片，經過雙絞線和MAC2的PHY2芯片，可以在MAC2的RGMII接口處收到。

仿真及上板結果如下：

可以看到在數據幀長度不符合標準的時候，是沒有辦法通過MAC2的mac核的，但是能夠到達接收端的rgmii_rx部分。

經檢查，發現開源IP核接收數據文件mac_rx_ctrl.v中對接收到的數據幀進行了長度判斷，把不滿足64字節的數據幀給過濾掉了。

通過寄存器可以配置LTU MTU大小，默認的LTU=64bytes MTU=1530bytes。

為了能接收到長度為40直接的數據幀，我們進行了如下修改：

LTU限制改為34， payload=34-4=30，由于接收控制的最小幀長信號是在寄存器組里配置，所以對需要在reg_init中更改。

修改完之后，在MAC2處即能接收到40字節的以太網幀了。

數據流可以在MAC2處回環了。但從MAC2的發送口收到的數據幀長度被自動填充到64字節了。如下圖中的打紅叉處。

經檢查，發現開源代碼的發送模塊部分會自動的填充補零。相關模塊代碼如下：

修改成支持傳輸40字節的超短幀，如下圖：

修改過之后，超短幀數據即可形成回環。

上板抓取超短幀

MAC1超短幀發送端

ephy_send側的發送數據，對應抓取數據幀位置如下圖。

注意：這里沒有抓發送側的rgmii_txd是因為他是oddr型的驅動，沒有辦法驅動寄存器，所以沒法打拍抓信號，更不能直接抓，所以抓了轉換前的8位數據。

MAC2超短幀接收端

值得注意的是，這里的rgmii_rx是buf型的驅動，所以是可以抓的信號，并且還未進行4到8的轉換，所以這里只有上升沿采到的高半字節偶數，而低半字節需要下降沿采樣。抓取位置對應于下圖中的箭頭處。

結論

通過以上實驗可知，超短幀是可以經過雙絞線傳輸的，PHY芯片不會對其進行過濾。但筆者沒有對商用的交換機進行測試，也許會出現文中提到的MAC那樣，硬件芯片會自動補零到64字節了。