×××技術中的MTU問題

【問題簡述】

 

在×××技術中常常遇到隧道已經創建可是某些應用程序沒法正常通信的問題，通常所來是因爲路徑MTU不匹配的緣故，下面就其中的數據傳輸流程作一些分析，以說明遇到出現此類問題該如何解決。

 

【問題分析】

先從一個實驗提及

實驗拓撲以下：

PC1-------×××網關1―――――×××網關2--------PC2

 

在上述組網中，×××網關1和2之間創建了一條GRE隧道，PC1與PC2經過該GRE隧道互訪。

這時，咱們會發現，PC1在ping 1448的報文時，在PC2上抓包發現沒有被分片，而ping 1449時，PC2上會發現PC1過來的報文已經被分片了。爲何呢？

PC1出來的IP報文長度爲1448＋8（ICMP報頭長）＋20（IP報頭長），到達×××網關1，×××網關1發到GRE隧道口，封裝GRE頭（4字節），再加上外層IP頭，到達×××網關外層以太口，這時IP報文的長度已經變爲：1448＋8＋20＋4＋20＝1500字節，恰好等於以太口的MTU，因而被順利傳送。而ping 1449時，到達外層以太口爲1501字節，超出了1500的MTU，又由於報文DF位未置1，便可以分片，×××網關因而將該報文分片發送出去。這就是咱們所看到的現象。

在上述實驗中，因爲應用程序是ping，因此報文能夠被分片，所以互通沒有問題。可是若是是WEB訪問等應用，則有些報文是不容許分片的，這樣在外層以太口就會將超過1500的報文丟掉，致使沒法通信。

從上述實驗能夠看到，因爲×××會額外加入一些報文頭，若是通信雙方的MTU不能隨之改變的話，就容易產生不通的問題。

下面以HTTP爲例，說明爲什麼產生此問題並如何解決。

先看看HTTP爲什麼沒法像ICMP那樣自動分片通信。

假設PC1/2創建了HTTP鏈接後，PC2但願從PC1下載一個大的網頁。PC2開始發送，其IP的DF位置1，不容許分片，IP報文長度爲1500字節。到達×××網關1的外網口後，×××網關1發現其長度超過了1500個字節，因而將其丟棄，並給PC1發回一個目的地址不可達的ICMP信息，出錯代碼爲」Fragmentation needed」，表示須要分片，但不容許分片，同時給出」MTU of next hop: 1500」。PC1接收到該消息後，又按照1500字節對外發送，又被丟棄，因而就造成了循環，沒法通信。

根據上述的分析，很容易獲得以下解決方式，在×××網關1的出接口設置MTU爲1500－4－20＝1476，這樣×××網關1返回ICMP不可達消息時將給出」MTU of next hop: 1476」。PC2將以1476做爲本身的最大MTU對外發送，到達×××網關1，封裝GRE和外層IP頭後就不會超過1500而順利發到對端。

這時僅解決了下載的問題，若是PC2須要將大文件上傳到PC1，一樣須要設置×××網關2的出接口MTU值小於1476。

固然，還能夠更改×××網關1的出接口的TCP MSS數值，將其更改成1500-4-20-20（TCP頭）=1456字節，也可保證HTTP等TCP應用順利經過。但該狀況僅適用於TCP應用。

上述解決方式一樣適用於其餘隧道技術，在L2TP、IPSEC等應用時能夠相應的根據其包頭數值設置MTU或MSS。