MTU概念詳解1. 概述在IP數據在網絡上傳輸時，會涉及到MTU這個概念。MTU，即最大傳輸單元（Maximum Transport Unit），這是一個數據鏈路層的概念，指數據鏈路層對數據幀長度的限制。但是，MTU實際上限制的并非數據鏈路層數據幀的長度，而是數據鏈路層幀的載荷（Payload）部分的長度。以最常見的以太網為例，其幀格式如圖 1所示，MTU限定的是數據部分的長度，根據RFC894（附后），對于以太網而言，MTU為1500 bytes，也即“數據（載荷）”部分的最大長度為1500 bytes。圖 1 數據鏈路幀格式2. MTU詳解由于IP數據報在由IP層交由數據鏈路層傳輸時，要將包括IP報頭和IP數據的內容作為數據鏈路層的載荷封裝在數據鏈路幀中。因此，MTU實際上是限制了IP層中IP數據報的總長度，當IP數據報的總長度超過MTU時，即需要分片，若IP數據報頭中設置了“不可分片”，則該報文將被丟棄，并產生ICMP差錯報告。圖 2 IP數據報分片演示圖 2演示了一個長度為2000的IP數據報在經過以太網傳輸時的分片情況，由于MTU限制為1500 bytes，在以太網中傳輸時將被拆分為兩個分片，每個分片包含首部的長度不超過1500 bytes。3. 抓包分析在局域網中進行抓包，采用如下命令：C: ping -l 2000 10.137.135.191由于指定的數據長度超過了以太網MTU的限制，在傳輸中會發生分片。對第一個分片的抓包結果如圖 3所示。通過IP協議部分可見，該IP數據報為一個分片，且不為第一分片（More Fragments位被設置），首部長度20 bytes，總長1500 bytes。這里發現抓包得到數據鏈路幀的長度為1514 bytes，而非如圖 1所示的1526 bytes。分析其原因：數據幀在到達物理網卡時，首先要去掉前導同步碼和幀開始定界符，然后對幀進行CRC校驗。只有CRC校驗正確，才會將幀送到“設備驅動程序”進行進一步處理，此時抓包軟件才能抓到數據，因此，Wireshark抓到的數據幀是去掉了前導同步碼字段、幀開始定界符字段和幀校驗和字段后的數據，因此抓包得到的數據幀總長為1514bytes。圖 3 指定長度2000的數據報第一分片抓包結果進一步，對第二個分片進行分析，這個分片為ICMP包，其IP數據報長度為548 bytes，這其中包括原2000bytes的數據中剩余的520 bytes（上一分片傳輸了1480 bytes），加上分片的首部20bytes，以及ICMP的首部8bytes，因此該分片的IP數據層長度為20+8+520 = 548 bytes。該數據幀長度為548+14 = 562 bytes。圖 4 指定長度2000的數據報第二分片抓包結果同樣，我們還可通過抓包分析當IP數據報長度達不到最短幀長時的情況。采用如下命令：C: ping -l 0 10.137.135.191這里我們指定發送了一個長度為0的ICMP請求報文。首先分析由對端發回的reply報文，如圖 5所示。圖 5 指定長度0的數據報reply報文抓包結果可以看到，IP數據報的長度為28 bytes，包含了20 bytes IP首部和8 bytes ICMP協議首部，數據部分長度為0。由于數據部分長度達不到數據鏈路層數據幀的最小長度（46 bytes），數據層對數據進行了填充（圖中Trailer部分），最后的抓包得到的總幀長為60 bytes（46 bytes數據和14 bytes數據鏈路幀首部）。圖 6 指定長度0的數據報request報文抓包結果抓包得到的request報文如圖 6所示。從圖中可以看到，IP數據報長度和reply報文相同，同樣為28 bytes，但是得到的幀長僅為42 bytes，達不到數據鏈路幀的最小長度。分析其原因，可以看到與圖 5的差別是沒有Trailer填充字段部分。這說明了兩點：1）當IP數據報達不到數據鏈路層最小長度要求時，是由數據鏈路層進行填充的；2）Wireshark對本機發出的數據抓包的處理權優先于數據鏈路層對數據幀的處理。附：RFC894（已校對）IP 數據報通過以太網網絡傳輸標準(A Standard for the Transmission of IP Datagrams over Ethernet Networks)1984年4月本RFC文檔描述了在以太網2中封裝IP數據進行傳輸1的一種標準方法。本RFC文檔描述的是ARPA網絡社區的一種標準協議。1介紹本文適用于速率為10MB/S，采用48位地址的以太網。文獻3描述了IP數據報在一種速率3MB/S的試驗以太網中傳輸的過程。2幀格式IP數據報通過標準的以太網幀傳輸，以太網幀的幀類型字節數值必須為十六進制的0800以表示它的類型。以太幀的數據部分包含了IP數據報的首部和數據部分。以太網幀數據字段要求的最小長度為46個字節，在必要時需要在數據字段以0進行填充，填充的部分不屬于IP數據報的內容，不計入IP數據報的總長。以太網幀的數據字段的最大長度為1500個字節，因此，在以太網中傳輸的IP數據報的最大長度不能超過1500字節。在實現中，推薦盡量使用最大長度（1500字節）的數據包。網關的設計也要求必須能夠處理最大長度的數據包，并且可將超長的數據包進行分片。如果一個系統不能處理最大長度的包，應該采取措施，要求發送方減小發送數據包的長度，例如使用TCP的最大段長度4。注意：在以太網上的數據報可能不再是一般Internet上默認的576字節的最大包長。一個以太網上的主機在向另一個以太網上的主機發送數據報時，應注意到這一點。比較合適的方法是發送一個較小的數據報以避免在中間的網關處被分片。在這一點上，請參考文獻4以得到更多的信息。3地址映射32位的IP地址映射到48位的以太網地址有多種方式，可以使用靜態對照表或采用動態解析。3.1 靜態對照表 在一個局域網里可以為每一個主機制定一個以太網地址和IP地址對應的表格。3.2 動態解析32位的IP地址和48位的以太網地址之間的映射可以通過ARP5（地址解析協議）來實現。IP地址在一些Internet網絡中被隨意的分配。每一個主機必須知道自己的IP地址以及對應的以太網地址才能正常處理數據包。在必要時，需要使用ARP協議將IP地址解析為對應的以太網地址。3.3 廣播地址Internet上的廣播地址（主機地址為全1）映射為以太網廣播地址（48位全1，即16位地址FF-FF-FFFF -FF-FF）。強烈推薦使用ARP協議進行動態解析。4追蹤格式（Trailer Format）一些版本的Unix 4.2bsd為了在VAX虛擬內存結構下得到更好的性能，采用了一種不同的封裝方式。在同一以太網中的兼容系統可能使用這種格式。一般主機不要求去實現這種格式。除非發送方能夠肯定接受方可以