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

回顧

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

那么，現(xiàn)在互聯(lián)網(wǎng)中發(fā)送長度小于64字節(jié)的報文時如何傳送呢？比如ARP報文。有效長度如下： ARP報文：4字節(jié)+4字節(jié)+6字節(jié)+4字節(jié)+6字節(jié)+4字節(jié)=28字節(jié)，遠不夠64字節(jié)。 事實上，在傳送ARP報文時，需要進行填充。

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

實驗環(huán)境

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

回環(huán)結構

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

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

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

數(shù)據(jù)流

Step1：通過data_gen模塊循環(huán)發(fā)送定長數(shù)據(jù)32’h12_34_56_78，通過8位數(shù)據(jù)端口傳給ephy_source模塊。

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

Step3：通過rgmii接口模塊進行8位gmii接口數(shù)據(jù)到4位rgmii接口數(shù)據(jù)的轉(zhuǎn)換后接到phy層。

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

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

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

仿真及上板結果如下：

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

經(jīng)檢查，發(fā)現(xiàn)開源IP核接收數(shù)據(jù)文件mac_rx_ctrl.v中對接收到的數(shù)據(jù)幀進行了長度判斷，把不滿足64字節(jié)的數(shù)據(jù)幀給過濾掉了。

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

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

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

修改完之后，在MAC2處即能接收到40字節(jié)的以太網(wǎng)幀了。

數(shù)據(jù)流可以在MAC2處回環(huán)了。但從MAC2的發(fā)送口收到的數(shù)據(jù)幀長度被自動填充到64字節(jié)了。如下圖中的打紅叉處。

經(jīng)檢查，發(fā)現(xiàn)開源代碼的發(fā)送模塊部分會自動的填充補零。相關模塊代碼如下：

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

修改過之后，超短幀數(shù)據(jù)即可形成回環(huán)。

上板抓取超短幀

MAC1超短幀發(fā)送端

ephy_send側的發(fā)送數(shù)據(jù)，對應抓取數(shù)據(jù)幀位置如下圖。

注意：這里沒有抓發(fā)送側的rgmii_txd是因為他是oddr型的驅(qū)動，沒有辦法驅(qū)動寄存器，所以沒法打拍抓信號，更不能直接抓，所以抓了轉(zhuǎn)換前的8位數(shù)據(jù)。

MAC2超短幀接收端

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

結論

通過以上實驗可知，超短幀是可以經(jīng)過雙絞線傳輸?shù)模琍HY芯片不會對其進行過濾。但筆者沒有對商用的交換機進行測試，也許會出現(xiàn)文中提到的MAC那樣，硬件芯片會自動補零到64字節(jié)了。