跳至內容

乙太網幀格式

維基百科,自由的百科全書

這是本頁的一個歷史版本,由Myjkccd留言 | 貢獻2013年2月3日 (日) 09:05 取消Myjkccd (对话)所作出的修订 24847636)編輯。這可能和目前版本存在著巨大的差異。

乙太網鏈路上的數據包稱作以太幀。以太幀起始部分由前導碼和幀開始符組成。後面緊跟著一個乙太網報頭,以MAC地址說明目的地址和源地址。幀的中部是該幀負載的包含其他協議報頭的數據包(例如IP協議)。以太幀由一個32位冗餘校驗碼結尾。它用於檢驗數據傳輸是否出現損壞。

結構

來自線路的二進制數據包稱作一個幀。從物理線路上看到的幀,除其他信息外,還可看到前導碼和幀開始符。任何物理硬體都會需要這些信息。[note 1]

下面的表格顯示了在以1500個八位元組MTU傳輸(有些吉比特乙太網甚至更高速乙太網支持更大的幀,稱作巨型幀)時的完整幀格式。[note 2] 一個八位元組是八個位組成的數據(也就是現代計算機的一個字節)。

802.3 乙太網幀結構
前導碼 幀開始符 MAC 目標地址 MAC 源地址 802.1Q 標籤 (可選) 以太類型或長度 負載 冗餘校驗 幀間距
10101010 7個octet 10101011 1個octet 6 octets 6 octets (4 octets) 2 octets 46–1500 octets 4 octets 12 octets
64–1522 octets
72–1530 octets
84–1542 octets

前導碼和幀開始符

一個幀以7個字節的前導碼和1個字節的幀開始符作為幀的開始。快速乙太網之前,在線路上幀的這部分的位模式是10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101011。由於在傳輸一個字節時最不重要的位最先傳輸(即低位最先傳輸),因此其相應的16進制表示為0x55 0x55 0x55 0x55 0x55 0x55 0x55 0xD5。

10/100M 網卡(MII PHY)一次傳輸4位(一個半字)。因此前導符會成為7組0x5+0x5,而幀開始符成為0x5+0xD。1000M網卡(GMII)一次傳輸8位,而10Gbit/s(XGMII) PHY晶片一次傳輸32位。 注意當以octet描述時,先傳輸7個01010101然後傳輸11010101。由於8位數據的低4位先發送,所以先發送幀開始符的0101,之後發送1101。

報頭

報頭包含源地址和目標地址的MAC地址,以太類型欄位和可選的用於說明VLAN成員關係和傳輸優先級的IEEE 802.1Q VLAN 標籤。

幀校驗碼

幀校驗碼是一個32位循環冗餘校驗碼,以便驗證幀數據是否被損壞。

幀間距

當一個幀發送出去之後,發送方在下次發送幀之前,需要再發送至少12個octet的空閒線路狀態碼。

以太幀類型

以太幀有很多種類型。不同類型的幀具有不同的格式和MTU值。但在同種物理媒體上都可同時存在。

所有四種以太幀類型都可包含一個IEEE 802.1Q選項來確定它屬於哪個VLAN以及他的IEEE 802.1p優先級(QoS)。這個封裝由IEEE 802.3ac定義並將幀大小從4位元組擴充到1522位元組(註:不包含7個前導字節和1個字節的幀開始符以及12個幀間距字節)。

IEEE 802.1Q標籤,如果出現,需要放在源地址欄位和以太類型或長度欄位的中間。這個標籤的前兩個字節是標籤協議標識符(TPID)值0x8100。這與沒有標籤幀的以太類型/長度欄位的位置相同,所以以太類型0x8100就表示包含標籤的幀,而實際的以太類型/長度欄位則放在Q-標籤的後面。TPID後面是兩個字節的標籤控制信息(TCI)。(IEEE 802.1p 優先級(QoS)和VLAN ID)。Q標籤後面就是通常的幀內容。

Ethernet II

以太 II 幀 (也稱作DIX乙太網,是以這個設計的主要成員,DEC,IntelXerox的名字命名的。[1]),把緊接在目標和源MAC地址後面的這個兩字節定義為乙太網幀數據類型欄位。

例如,一個0x0800的以太類型說明這個幀包含的是IPv4數據報。同樣的,一個0x0806的以太類型說明這個幀是一個ARP幀,0x8100說明這是一個IEEE 802.1Q幀,而0x86DD說明這是一個IPv6幀。

當這個工業界的標準通過正式的IEEE標準化過程後,在802.3標準中以太類型欄位變成了一個(數據)長度欄位。(最初的以太包通過包括他們的幀來確定它們的長度,而不是以一個明確的數值。)但是包的接收層仍需知道如何解析包,因此標準要求將IEEE802.2頭跟在長度欄位後面,定義包的類型。多年之後,802.3x-1997標準,一個802.3標準的後繼版本,正式允許兩種類型的封包同時存在。實際上,兩種封包都被廣泛使用,而最初的以太封包在以太區域網中被廣泛應用,因為他的簡便和低開銷。

為了允許一些使用以太II版本的數據報和一些使用802.3封裝的最初版本的數據包能夠在同一個乙太網段使用,以太類型值必須大於等於1536(0x0600)。這個值比802.3封包的最大長度1500byte (0x05DC)要更大。因此如果這個欄位的值大於等於1536,則這個幀是以太II幀,而那個欄位是類型欄位。否則(小於1500而大於46位元組),他是一個IEEE 802.3幀,而那個欄位是長度欄位。1500~1536(不包含)的數值未定義。[2]

802.2 LLC

一些協議,尤其是為OSI模型設計的,會直接在802.2 LLC層上操作。802.2 LLC層同時提供數據報和面向連接的網絡服務。

802.2乙太網變種沒有在常規網絡中普遍使用。只有一些大公司的沒有與IP網絡融合的Netware設備。以前,很多公司Netware網絡支持802.2乙太網,以便支持從乙太網到IEEE 802.5令牌環網或FDDI網絡的透明橋接。當今最流行的封包是乙太網版本二,由基於IP協議的網絡使用,將其以太類型設置為0x0800用於封裝IPv4或者0x86DD來支持IPv6

還有一個英特網標準來使用LLC/SNAP報頭將IPv4封裝在IEEE 802.2幀中。[3] 這幾乎從未在乙太網中實現過。(但在FDDI以及令牌環網IEEE 802.11和其他IEEE 802網絡中使用)。如果不使用SNAP,IP傳輸無法封裝在IEEE 802.2 LLC幀中。這是因為LLC協議中雖然有一種IP協議類型,卻沒有ARP。IPv6同樣可使用LLC/SNAP在IEEE 802.2乙太網上傳播,但,如同IPv4,它也絕少被這樣使用。(儘管LLC/SNAP的IPv6封包在IEEE 802網絡中被使用)。

子網接入協議

通過檢查802.2 LLC頭,可以確定他是否後繼一個SNAP頭。LLC頭包含兩個附加的8位地址欄位,在OSI模型術語中稱作服務訪問點(SAPs)。當源和目標SAP都設置為0xAA時,就會使用SNAP服務。SNAP頭允許以太類型值被任何IEEE 802協議使用,即使支持的是私有協議ID空間。在IEEE 802.3x-1997中,IEEE 以太標準被修改為明確允許緊接著MAC地址的16位欄位即可用於長度欄位,也可用於類型欄位。

Mac OS使用 802.2/SNAP 封包來實現乙太網上的AppleTalk V2協議套件("EhterTalk")。

Novell raw 802.3

Novell的"raw"802.3幀格式基於早期IEEE 802.3的工作。Novell以它作為起點來創建他自己的乙太網上IPX協議的的第一個實現。他們沒有使用LLC頭,而是直接在長度欄位後面開始IPX數據包。這不符合IEEE 802.3標準,但由於IPX的前兩個字節一直是FF(而在IEEE 802.2 LLC中這種模式雖然理論上是可能的但實際上概率極其微小),實用中這種方式與其他以太實現共同存在。但須注意在一些早期的DECnet可能無法識別之。

直到90年代中期,Novell NetWare默認使用這個幀類型,而由於Netware曾如此流行,而那時IP還不是那麼流行,在過去的一些時候,大多數的乙太網上都運載著負載IPX的"raw" 802.3封包。直到Netware 4.10,當使用IPX時,Netware才默認使用IEEE 802.2和LLC(Nerware 幀類型Ethernet_802.2)。

效率

我們可以計算乙太網的效率和比特率

當達到允許的最大負載值時可達到最高效率,對於無標籤的乙太網封包是,而使用802.1Q VLAN標籤時是

由效率中可計算比特率:

不帶802.1Q標籤的100BASE-TX乙太網的最大比特率是97.53 Mbit/s. 註:不帶標籤的最大幀尺寸=1518 + 20 (7-byte 前導符,1-byte 幀開始符, 12-byte 幀間距)= 1538。

矮幀

矮幀是一個尺寸不及IEEE 802.3定義的最小長度64位元組的乙太網幀。可能的原因是乙太網碰撞,數據不足,網卡錯誤或軟體錯誤。[4]

Notes

  1. ^ 前導碼和幀開始符無法在包嗅探程序中顯示。這些信息會在OSI第1層被網卡處理掉,而不會傳入嗅探程序採集數據的OSI第2層。也存在OSI物理層的嗅探工具以顯示這些前導碼和幀開始符,但這些設備大多昂貴,多用於檢測硬體相關的故障。
  2. ^ 前導碼和幀開始符的位模式以位串的方式給出,最左的比特最先傳輸(而非以字節為單位,乙太網傳輸最優先的位)。這個腳註與IEEE 802.3標準吻合。
  3. ^ 第一版以太幀在早期乙太網原型中使用,並使用8位MAC地址,從未在商業中使用

參考資料

  1. ^ Drew Heywood; Zubair Ahmad. Drew Heywood's Windows 2000 Network Services. Sams. 2001: 53. ISBN 0672317419. 
  2. ^ IEEE Std 802.3-2005, 3.2.6
  3. ^ RFC 1042
  4. ^ Glossary of Terms - R (Zarlink Semiconductor).  071227 products.zarlink.com[失效連結]