作者：一天 首發(fā)公眾號：網(wǎng)絡之路博客（ID：NetworkBlog）

MTU與IP分片（可選內(nèi)容了解）

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

（1）了解MTU的作用

Maximum Transmission Unit（MTU）：最大傳輸單元。還是以上面的例子，為什么路由器撥號的時候要把MTU設置成1492呢？在這之前已經(jīng)知道了以太網(wǎng)頭部，一個標準的以太網(wǎng)數(shù)據(jù)幀最大為1518，其中源MAC 6字節(jié)，目的MAC 6個字節(jié)，Type 2個字節(jié)，F(xiàn)CS 4個字節(jié)（前導碼不算在內(nèi)，在物理層就已經(jīng)去掉了），6+6+2+4=18個字節(jié)，1518-18=1500，這1500正好是是留給上層協(xié)議傳輸?shù)拇笮。簿褪俏覀冋f的數(shù)據(jù)幀的大小是1500個字節(jié)，包括IP頭部以及上層協(xié)議與數(shù)據(jù)整體在內(nèi)，也就是說在二層以太網(wǎng)中，實際能傳輸?shù)臄?shù)據(jù)是1500個字節(jié)。

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

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

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

（2）IP分片帶來的問題

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

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

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

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

• 以太網(wǎng)最小字節(jié)為什么要求是64呢？

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

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

• MTU值為什么是1500

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

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

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

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

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

出現(xiàn)這個問題是因為早期以太網(wǎng)通過Hub這些設備工作，處于共享方式，效率很低，而現(xiàn)在的網(wǎng)絡早已不是10M的網(wǎng)絡了，交換機已經(jīng)支持1G，10G、100G，而且?guī)挭毾恚梢酝瑫r收發(fā)的特性，那有效傳輸效率跟質(zhì)量提升了非常多，但是如今的網(wǎng)絡你會發(fā)現(xiàn)常見的還是用的mtu 1500的標準，只有數(shù)據(jù)中心或者某些特殊環(huán)境使用了一個叫做巨型幀 Jumbo Frame，可以支持大于9000字節(jié)的大小，如果全網(wǎng)都使用這種，那傳輸大的文件這些不是更快、延遲很小嗎？

但是現(xiàn)實環(huán)境沒這么簡單，因為MTU在每個設備的每一個接口（網(wǎng)卡）上面都是存在的

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

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

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

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

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

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

有IP分片包出現(xiàn)，說明剛剛的數(shù)據(jù)包整體超過1500個字節(jié)了。

• 數(shù)據(jù)明明是1473怎么就超過1500字節(jié)了呢？

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

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

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

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

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

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

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

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

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

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

由于現(xiàn)在很多協(xié)議還沒學習，不同的應用對應的頭部不一樣，自然包含的內(nèi)容也不一樣，這個會隨著后面學習的深入，慢慢的了解，設置合適的MTU可以用Windows自帶的命令可以探測，比如某個應用有問題，通過抓包發(fā)現(xiàn)發(fā)送的數(shù)據(jù)超過了MTU的大小，就可以適當?shù)恼{(diào)整。

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

留一個小疑問

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

“承上啟下”

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

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

總結

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。