IP層接收到比MTU大的數據包會先分片再重組，隨後在傳遞給上層協議（比如UDP）處理嗎？

12-28

當前在調試實驗室測試線throughput速率低的問題，目前懷疑是server上跑的自動化case設置發包的length大於1480導致IP分片造成的，也通過wireshark簡單抓包證實了這一點，於是就聯繫IT開啟鏈路上設備Jumbo frame的功能，本人也修改其中一台server的網卡的MTU為2000，而測試用的client目前可能因為驅動的問題無法修改MTU，仍舊是1500的默認值，在IT解決client網卡MTU的這段時間，我重新rerun了case， case顯示速率值低到了4Mbps左右，client發包依舊分片，但server回包就不在分片了，之前的client和server同時分片的時候速率低也能達到17~18Mbps，這個MTU不匹配造成速率下降如此之多讓我意識到了一個有趣問題：
那就是在當前我的網路環境中，超過1500的數據包是可以從server端不分片的發出，鏈路也可以通過不會分片，但client端MTU限制在1500，這樣的話貌似包也可能被網卡capture，因為我能用wireshark在client上抓到該沒有分片的從server端發來大數據包（1760B），那麼client的IP層還用因為MTU的設置先對該包進行分片嗎，聯想到路由器分片好像應該會的，然後在check 目標IP地址發現發給自己的包在重組後把數據傳遞給上層協議（UDP）？請問這個邏輯對嗎。
我是無線通信出來的，網路通信只是副業，如果IT不作為的話，對這種問題不甚了解，但這個問題應該對自學網路通信的人都很困惑，所以請大家見諒如果該問題比較簡單的話並請不惜賜教。

對於這個問題，了解雙向數據是怎麼流動的，然後找出瓶頸，可能會更有意義。

沒有啟用Jumbo Frame ( 路徑MTU = 1500）

伺服器---&>客戶端方向數據流

1.1 伺服器UDP程序發2000 byte 數據，以一整塊的方式到IP層

1.2 IP MTU = 1500，2000 byte 被分成兩片

1.3 網卡發兩個幀

1.4 兩片IP包無障礙通過網路路徑

1.5 兩個幀被客戶端網卡接收並提交給IP層

1.6 IP層負責重組，得到原始2000 byte 包，並通知UDP前來取走

1.7 UDP一次性取完，並提交給應用程序，over

相反方向也類似，即客戶端IP層分片，伺服器IP層來重組。

啟用Jumbo Frame ( 路徑MTU = 2100）

伺服器---&> 客戶端方向數據流

2.1 伺服器UDP程序發2000 byte 數據，以一整塊的方式到IP層

2.2 IP MTU = 2100，2000 byte 不需要分片

2.3 網卡發一個幀

2.4 一個IP包無障礙通過網路路徑

2.5 一個幀被客戶端網卡接收，2000 byte，通知IP層有2000 byte 數據要取走

2.6 由於客戶端網卡驅動所限，MTU= 1500，意味著IP層最多一次只能取走1500 byte，所以IP層要讀取網卡數據兩次，然後把兩次的數據合併成一個原始的2000 byte ，並通知UDP前來取走

2.7 UDP一次性取完，並提交給應用程序，over

客戶---&> 伺服器方向流量依然如 1 所示，依然需要分片，伺服器端IP層需要分片，既然1、2 種情況客戶---&> 伺服器方向完全一樣，所以咱們就就不討論這個方向。

伺服器---&> 客戶端方向
場景2不需要分片，而場景1需要分片，場景2需要更少的CPU，所以場景2的吞吐量下降瓶頸不在伺服器端，也不在網路路徑上，因為路徑上沒有分片，只是正常的包轉發，與場景1需要轉發兩個包相比，場景2隻需要轉發一個大包，會更節省硬體資源，所以推測下來，瓶頸只可能在客戶端。

客戶端最大的不同，就是1.6 與 2.6，既然場景2 數據的吞吐量下降，那隻能懷疑2.6 這個處理更耗費CPU資源。

如果可能，將客戶端的MTU修改為 MTU = 2100，則數據吞吐量將大大提高，沒有任何分片重組，數據一次發送、一次讀取。

總結一下：硬體網卡設置MTU，是一個硬性限制，比如MTU= 1500，IP層必須將發給網卡API的包&< = 1500，否則調用失敗。

而IP層對UDP/TCP的數據長度則沒有什麼限制，僅是一個潛規則，潛台詞是：老夫的 MTU= 1500，各位看著辦！

TCP是謙謙君子，通過MSS = 1460 來限制自己的應用層，這樣避免IP層分片，IP層很開心，心裡竊喜：TCP果然是一個懂事的孩子！

而UDP則是魯莽之人，沒聽懂潛台詞，自說自話發給IP層&> 1500 byte 的數據，IP層內心非常不悅，心裡嘀咕：娘希匹，明知道數據要分片，自己不分，非要讓老夫分片！儘管內心不爽，但是IP層還是幫助分片，否則數據無法發給網卡啊！

UDP最憋屈，都是TMD應用層硬要發大包，和我真的沒有半毛錢關係！

這裡替UDP說句公道話，UDP的一塊應用層數據（邏輯整體），有時必須以完整的、一整塊提交到對端的應用層，否則失去了意義，應用層無法理解，而IP層分片/重組則可以保證以上的需求。

IP層如果發現鏈路層的服務提供的MTU小於IP包的大小（IP層和鏈路層會有溝通），就會查看IP包的是否允許分片比特位。如果允許分片就會分成多個ID一樣的IP包。

這個分片可以發生在路徑上任何一個發送埠。主機可以，路由器也可以。

鏈路層的MTU是收發一致的，所以不存在一邊發了大包另一邊不能收的情況。

IP包被分片以後，只有IP擁有者可以重組。IP層必須重組才能交給上層。為什麼呢？舉個例子，一個UDP包的埠號只出現在包頭上一次（IP層認為整個包是完整的，UDP層也不知道下層是不是會分片，所以只有一個UDP頭）。

分片的時候，IP層並不會在每個分片里複製一次UDP頭，他是直接把完整的UDP包切開，除了第一個分片，後面的分片都不包含UDP頭。

所以，IP層如果把分片直接交給上層，他不知道交給哪個埠。

所以IP層必須重組成一個完整的IP包再交給上層。

為什麼不考慮發送端降低UDP包的大小呢？一般1280位元組是比較靠得住的，不要想著用1440，有些鏈路上不靠譜

在中文和ENGLIS之間shift好麻煩阿，還不如total中文orEnglish呢。
你的意思是收到一個大於1500的幀，接收方IP會不會先分片再重組。應該不會。就算會你也看不出來，因為網卡收到的是完整的，上交給UDP也是完整的，至於系統內部怎麼工作是不可見的。

我記得是分片發出去，ip層並沒有重組功能，由上層根據標識重組