作者：一天 首發公眾號：網絡之路博客（ID：NetworkBlog）

MTU與IP分片（可選內容了解）

這里來講一個比較有趣的內容，相信大家都有設置過家用路由器的經歷，不知道有沒有發現一個事情，在設置撥號的時候，里面有一個MTU，值通常是1492或者1480，如果接入方式改為DHCP的情況下，MTU就變成了1500，為什么呢？

（1）了解MTU的作用

Maximum Transmission Unit（MTU）：最大傳輸單元。還是以上面的例子，為什么路由器撥號的時候要把MTU設置成1492呢？在這之前已經知道了以太網頭部，一個標準的以太網數據幀最大為1518，其中源MAC 6字節，目的MAC 6個字節，Type 2個字節，FCS 4個字節（前導碼不算在內，在物理層就已經去掉了），6+6+2+4=18個字節，1518-18=1500，這1500正好是是留給上層協議傳輸的大小，也就是我們說的數據幀的大小是1500個字節，包括IP頭部以及上層協議與數據整體在內，也就是說在二層以太網中，實際能傳輸的數據是1500個字節。

舉一個最常見的例子，我們平時在家里用手機或者筆記本連接家用路由器看電視劇、刷抖音，數據包都是這樣的路徑，每個節點都有對應的MTU值，正常都為1500.

假設某一天，外網的對接方式變了，變成了撥號的形式，正常設置后，發現打開網頁很慢或者打不開，咨詢路由器客服后，把MTU值改成1492或者更小點，驚奇的事情發生了，都能正常訪問了，這就回到之前的問題了，為什么現在的路由器MTU都會設置成1492呢？

那是因為寬帶撥號使用的協議是PPPoE，由于還沒涉及這一塊的知識點，我們在這知道它占用8個字節就行，并且是封裝在以太網中的。比如訪問者發送了一個1495字節的數據包給視頻服務器，但是由于家用路由器采用的是這就在原來1500的字節上多出來了8個字節，超過了標準的MTU值1500字節，所以這個時候家用路由器會將這個數據包進行分片，分為2個，一個為數據包為1500個字節，另外一個數據包為3個字節，到了服務器這邊在進行重組。（實際會更加復雜點，待會我們來做個小實驗）

（2）IP分片帶來的問題

IP分片其實在網絡中是一種比較糟糕的情況，帶來了幾個問題

• 傳輸效率降低：分片會降低傳輸效率（這個待會我們用簡單的實驗可以看到）
• 增加設備的壓力：原本一個數據包大小正好在1500字節的范圍內，直接就發送了，如果超過了1500個字節，就需要涉及到分片，如果這種數據包一多，對應的設備壓力就會增大，占用設備的資源。
• 延遲加大：分片另外一個問題就是當同一個數據包的多個分片抵達目的地后，目的終端需要將數據包重組排列后才能夠去讀取里面的內容。好比一個大的物件被拆分成多個小的物件發送出去，接收后，需要進行重新組裝，更糟糕的是萬一某一個組件晚到，那么其他到了的組件就得等待；在IP分片重組中也是這樣的，所以會導致延遲加大。
• 丟包：更嚴重的是，在復雜的網絡環境中，萬一某一個分片丟失了，那其余接收到的數據就沒任何意義了，組不成一個完整的數據包，從而被丟棄。
• 某些應用訪問失效：比如上面的網頁打開失敗或者很慢就是因為分片造成的，有的服務器有保護措施，拒絕接收分片的數據包。

（3）為什么MTU是1500呢，明明IP字段的總長度是65535？

之前學過IP頭部的內容，IP頭部里面有一個總長度，最大值是65535，表示IP協議是能夠承載這么大數據包的，但是由于以太網的數據部分最大為1500，所以你在很多書籍或者稱呼里面會看到IP的數據包最大是1500個字節，多了就會被分片，那為什么以太網要把數據部分定在1500，不能跟IP頭部一樣用65535嗎？那效率不是高很多。

• 以太網最小字節為什么要求是64呢？

最早的以太網是工作在共享網絡下的，任何一個終端節點發送數據之前，都需要偵聽線路上是否有數據在傳，如果有，需要等待，如果發現線路可用，才可以發送。假設A與B終端同時傳輸1個bit給對方的話，會產生沖突，其中一個就需要等待一端發送完成后在過一個時間間隙才能發送，這個時間間隙是57.6μs。

在10Mbps的以太網中，在57.6μs時間內，能夠傳輸576個bit，以太網中要求數據幀最小長度為576個bit，原因是這個長度正好能夠讓最極端的沖突環境都能夠被檢測到（CSMA/CD），而576個bit換算成字節是72，去掉8個字節的前導符，正好是64個字節，這也是以太網幀數據部分要求的最小長46的原因（46+18），不夠46的會自動填充。

• MTU值為什么是1500

這個是了解64字節的由來，是因為早期工作方式的原因（CSMA/CD），那1500字節又是什么原因呢？

假設以太網沒有這個限制，IP協議最大可以承載65535字節，加上以太網頭部和尾部，是65535+14+4=65553字節，如果早期在10Mbps的以太網上傳輸，會占用共享鏈路50ms,這樣嚴重影響了其他主機的通信，如果有延遲敏感的應用，那肯定是無法接收的，另外如果線路的質量差，大包引起的丟包幾率也會大很多。（50ms的計算方法：（65553*8）/（10*1024*1024）≈0.05（s）（小知識點科普：Mbps為每秒傳輸百萬位比特，而65535是字節單位，1字節=8比特，所以需要*8，10Mbps換算成bps就是10*1024*1024））

竟然大的不行，換成小的呢？，比如MTU等于100，就拿上面學過的ICMP的Ping來說，如果以太網長度為100，ICMP實際數據= 100-ICMP頭部（8個字節）-IP頭部（20個字節）-以太網頭部（18個字節）=100-8-20-18=54，你會發現有效率實在太低了，有效率=54/100=54%

最終得到一個通過層層計算，發現如果以太網長度為1518的時候，有效傳輸效率=1472/1518=96.9%，這個值既能保證有一個較大的幀長度，又保證了有效傳效率。更大的或者更小的就會出現上述的問題，這個也是一個折中的長度：1518字節，對應上層IP 就是1500字節（1518-18），這個就是最大傳輸單元MTU的由來。

• 為什么不改善這個問題呢？

出現這個問題是因為早期以太網通過Hub這些設備工作，處于共享方式，效率很低，而現在的網絡早已不是10M的網絡了，交換機已經支持1G，10G、100G，而且帶寬獨享，可以同時收發的特性，那有效傳輸效率跟質量提升了非常多，但是如今的網絡你會發現常見的還是用的mtu 1500的標準，只有數據中心或者某些特殊環境使用了一個叫做巨型幀 Jumbo Frame，可以支持大于9000字節的大小，如果全網都使用這種，那傳輸大的文件這些不是更快、延遲很小嗎？

但是現實環境沒這么簡單，因為MTU在每個設備的每一個接口（網卡）上面都是存在的

如果訪問者支持MTU 9000，發送了一個9000大小的數據包交給無線路由器，無線路由正好也支持這么大，交給互聯網設備，互聯網中設備非常多，并不是所有設備都能夠去支持巨型幀的特性，很多地方還使用的非常老的設備在運行，如果要支持勢必是大面積更換，成本會非常大，那如果一個數據包9000大小經過一個MTU是標準1500的設備，那勢必就會造成分片了，還有許多比如超長幀會造成延時、CRC錯誤變多等問題，導致至今無法大面積普及使用的主要原因。

（4）IP分片后為什么會造成延遲跟效率低呢？

拖兩臺電腦，分別設置好地址，然后抓包來看看分片的情況。

說下命令，Ping 192.168.255.2這個都能夠知道啥意思，-l表示ICMP的數據部分（不含其它任何頭部信息）為1473，-c 1只發送一次。

通過抓包，可以看到有幾個信息（wireshark升級了下，界面看起來更美觀了~）

• ARP：這個是獲取對方IP對應的MAC
• ICMP，這個是正常的ICMP協議的報文
• IP Fragmented：IP分片包

有IP分片包出現，說明剛剛的數據包整體超過1500個字節了。

• 數據明明是1473怎么就超過1500字節了呢？

這里要注意，1473表明的是ICMP數據部分的大小，不計算頭部在內，那么加上頭部后呢？ 1473+8（ICMP頭部）+20（IP頭部）=1501，這樣正好超過了1500個字節，所以導致分片了。MTU是二層概念，二層以上的頭部加數據不能超過1500，否則會進行分片。

• 從192.168.255.1到192.168.255.2為什么只有一個分片包

這里對于剛接觸抓包的朋友來說，可能有點看不懂，我們來看幾個參數

1. IP頭部里面有一個identification 這個是標識符，分片的包會打上相同的包，方便目的端區分
2. Flags里面的MF位是1，表示這個不是最后一個包，如果是最后一個包會為0
3. offset：偏移符，表示數據包的位置，這個為0，表示是第一個分片包
4. Data：你這里會發現數據是1480，并且是沒有ICMP頭部的（這個內容其實是包含了頭部信息的，1480-8，1472，注意：只有第一個分片會攜帶頭部信息，抓包沒有顯示出來）。

那還有1個字節的包在抓包里面沒有顯示，這可能是抓包中把尾包省略了，但是可以從另外一個地方看出來。

在看一個完整的包可以上面的疑惑了

1. IP頭部里面有一個identification 這個是標識符，分片的包會打上相同的包，方便目的端區分
2. 抓包軟件里面有一個IPV4 Fragments的組合解析，發現有兩個分片，Frame：3，數據負載是0~1479（1480個字節），Frame：4，數據負載是1480-1481（1個字節），總共就是1481
3. DATA部分為1473，是因為1481里面有8個字節的頭部，1481-8=1473個字節

• 為什么會影響效率跟增加延遲呢？

可能數據包小，感受不到分片帶來的問題，上圖數據大小改成了5000，會發現4個分片（最后一個是隱藏了），那就會多出4個IP頭部，這些是無故多出來的數據，并且這4個頭部不管是中間設備還是接收方都需要去解封裝來看是什么內容，并且接收方根據IP頭部的分片給的信息去組裝，假設某一個分片中途延遲，那么這個數據包就不會完整，必須等待這片來組裝后才能讀取到實際的內容，這種會影響效率（多余的頭部處理），增加延遲（某一個分片沒到，對應的數據沒法重組，導致數據請求遲遲得不到響應。）更嚴重的其實是會加重設備的負擔（可能實際中不只一個數據包分片，接收方需要把收到的進行緩存，等待所有對應的分片來才能讀取到實際的數據，隨著分片越多，緩存越大，對于設備的壓力負擔也越重），如果某一片分配丟失了，會造成這個數據包不完整，被丟棄。

（5）怎么設置合適的MTU呢

由于現在很多協議還沒學習，不同的應用對應的頭部不一樣，自然包含的內容也不一樣，這個會隨著后面學習的深入，慢慢的了解，設置合適的MTU可以用Windows自帶的命令可以探測，比如某個應用有問題，通過抓包發現發送的數據超過了MTU的大小，就可以適當的調整。

ping命令里面帶有一個參數-f 它可以把IP包的DF位置1，讓其不分片，那么超過MTU需要分片的設備發現DF位置一，則直接丟棄，返回一個ICMP的差錯報文結果，通過這樣來測試出一個合適的MTU值。

留一個小疑問

這里為什么1464就可以，1465不可以呢（該環境存在撥號）

“承上啟下”

網絡層的基礎知識到這里就學習完畢了，接下來就進入傳輸層與應用層，對于這兩層，博主會挑對初學者比較重要的部分的講，全部講起來就非常費時間，涉及的內容實在太多，也不是初學者層面能夠理解的，下一篇就進入傳輸層的兩大協議，TCP與UDP。

作者：一天，公眾號：網絡之路博客（ID：NetworkBlog）。讓你的網絡之路不在孤單，一起學習，一起成長。

總結

以上是生活随笔為你收集整理的有没有好奇过路由器宽带拨号mtu值为什么是1492呢？了解MTU与分片的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。