本文系統化梳理網路通訊中MTU、MSS核心概念、換算公式、Ping測試原理、隧道封裝適配問題及故障排查思路,是解決Giants、網路分片、VPN卡頓、網頁存取異常等問題的核心基礎。
一、MTU(最大傳輸單元)MTU 全稱 Maximum Transmission Unit指資料鏈結層單次能夠傳輸的完整最大資料包總大小,包含所有協定頭部及資料內容,為鏈結層的傳輸上限。
預設標準值:乙太網路(Ethernet)預設 MTU = 1500 位元組,為區域網路、公網常規鏈路標準值。
結構說明:整個連結幀最大承載1500字節,包含IP頭部、傳輸層頭部、業務數據,是完整資料包的總尺寸上限。
二、MSS(最大分段大小)MSS 全名為 Maximum Segment Size,是 TCP 協定的專屬參數
指TCP封包中真正的業務資料最大大小,不含 IP 頭部、TCP 頭部,且僅承載使用者業務資料。

1. 核心換算公式常規網路場景下,IP頭部、TCP頭部預設基礎長度均為20位元組,固定公式如下:
MSS = MTU – IP頭部(20) – TCP頭部(20) = MTU – 402.
預設標準值基於乙太網路預設MTU 1500計算:1500 – 40 = 1460 字节
結構說明:1500位元組總MTU中,固定預留20位元組IP頭部+20位元組TCP頭部,剩餘1460位元組純資料區域即為MSS最大值,僅承載用戶業務資料。
三、Ping測試MTU原理(1472位元組的由來)Ping 工具基於 ICMP 協議實現,並非TCP協議,因此計算規則與MSS不同,是日常快速檢測鏈路MTU上限的常用手段。
1. 資料包組成ICMP資料(1472位元組) + ICMP頭部(8位元組) + IP頭部(20位元組) = 1500位元組(標準MTU上限)
2. 標準測試指令及參數意義
ping -f -l 1472
目標位址•-l 1472:
指定資料大小為基礎1472:指定資料名稱為單位的Fragment(禁止分片),核心作用:若資料包大小超過連結MTU上限,直接丟棄資料包、測試失敗,不會自動分片傳輸,精準偵測連結最大承載能力此指令的核心用途:驗證目前連結是否支援標準1500位元組的MTU傳輸。

四、MTU變小的核心原因(隧道場景)很多人誤以為MTU變小是連結品質變差,實際上與連結頻寬、穩定性無關,僅由隧道封裝協定導致。
VPN、GRE、IPSec 等隧道技術會在原始資料包外層額外新增一層協定頭部,整體資料包體積變大。
而連結物理MTU上限(1500)固定不變,封裝頭部佔用了部分空間,導致能承載的原始業務資料空間被壓縮,即有效MTU變小,這也是隧道網路最容易出現分片、丟包的核心原因。
不同隧道協定的封裝頭部佔用位元組不同,是實戰調參的核心依據,常見隧道頭部開銷標準:
•GRE隧道:基礎頭部佔用 24 字節
•IPSec隧道(ESP):常規封裝佔用 50~60 字節
•VPN接合隧道:多層丟裝頭套MTU + 真實位元組數值做三段精化

實戰舉例:
案例1:
公網無隧道場景(正常、無分片)普通公網/區域網,無任何隧道封裝:TCP業務資料1460 + TCP頭20 + IP頭20 = 1500位元組(剛好塞滿MTU)此時封包大小等於連結最大承載值,無需分片、不會丟包,傳輸完全正常,這也是一般上網、手機流量存取網路穩定的原因。
案例2:接入GRE隧道(不調MSS,必丟包/必分片)GRE隧道會在外層額外封裝24位元組GRE頭部,物理鏈路MTU依然固定1500不變。
沿用預設TCP 1460資料發包,總包大小計算:1460(資料)+20(TCP)+20(IP)+24(GRE隧道頭) = 1524位元組1524 > 1500,超出連結MTU上限!
此時設備只能執行IP分片,將一個完整大包拆成多個小包傳輸;而現代防火牆、VPN設備、運營商骨幹網,預設開啟分片報文攔截策略(防攻擊),直接丟棄分片資料包。
最終現象:微信發文字(小包)正常,開啟網頁、傳文件(大包)打不開/卡頓超時,是最典型的隧道MTU適配故障。
案例3:IPSec加密隧道IPSec ESP加密隧道封裝開銷更大,常規佔用50~60位元組頭部。
同樣預設1460 TCP資料發包,總包可達 1550+ 字節,超限更嚴重,分片、丟包、TCP重傳機率大幅提升,VPN辦公系統、內網業務存取異常高發。
案例4:微調MSS解決問題針對GRE隧道場景,全域下調TCP MSS至1360:1360(資料)+20(TCP)+20(IP)+24(GRE) = 1424位元組1424 < 1500,完全在MTU承載範圍內!無需分片、不會被防火牆攔截,從源頭徹底解決隧道大包丟包、網頁打不開、業務卡頓、TCP反覆重傳的問題。
此時裝置只能對超大資料包進行強制分片分割傳輸。
而大部分防火牆、VPN設備預設開啟分片偵測、防碎片攻擊策略,會直接丟棄分片封包,最後引發大封包傳輸失敗、小封包正常的詭異網路故障。
資料包結構:新增隧道頭部 + 原始完整資料包(原頭+原資料)五、手動調整MSS的必要性網路隧道封裝後,有效MTU降低,預設1460位元組的TCP資料段會超出連結承載上限,導致資料包必須分片、甚至直接丟包,引發各類網路異常。
1. 精準MSS計算公式(隧道通用萬能公式)物理出口MTU預設1500場景下,隧道環境調參唯一標準公式:
最優MSS = 1500 – 隧道外層頭部開銷 – 40(TCP+IP基礎頭部固定開銷)
原理:預留所有頭部開銷,讓杜包後的最終包完備全包尺寸,≤10005 2. 各隧道對應標準MSS精準參數(實戰直接套用)•純GRE隧道(頭部24位元組)
計算:1500-24-40 = 1436
標準配置:ip tcp adjust-mss 1436•IPSec ESP加密隧道(常規60位元組最大開銷)
計算:1500-60-40 = 1400
標準配置:ip tcp adjust-mss 1400•GRE+IPSec雙層封裝(高開銷80~100位元組)
計算:1500-100-40 = 1360
標準配置:ip tcp adjust-mss 13603. 為什麼網路上大多用 1360?1360 不是所有場景的精準最適值,而是全場景通用保守安全值。
無論單層隧道、雙層疊加隧道,設定1360皆可相容,不會超限丟包,適合不確定隧道封裝格式、懶人一鍵適配場景。
4. 核心設定指令// 精準場景按需配置
ip tcp adjust-mss 1436 // 純GRE
ip tcp adjust-mss 1400 // 單層IPSec
ip tcp adjust-mss 1360 // 雙層疊加/通用保守值
5. 作用原理主動告知客戶端,當前網路存在隧道封裝開銷,限制TCP單段最大資料尺寸,從源頭杜絕大包機超限,避免攔截設備IP分片、防火牆分頁封包表ip tcp adjust-mss 13602.
作用原理主動告知客戶端,目前網路環境不支援超大TCP資料段,限制TCP單段資料最大大小,從來源避免資料包分片、丟包、TCP重傳,適配隧道封裝後的網路環境,解決VPN、專線隧道異常問題。
六、MTU/MSS異常典型故障現像
出現以下網路問題,優先檢查MTU、MSS適配問題:
•網頁打不開、網頁載入不全,但微信、QQ等即時通訊正常(小資料包正常,大封包傳輸異常)
•網頁連線卡頓、業務存取不穩定
•網路頻繁出現記憶資料含數、資料包丟七TCP純業務資料大小(不含任何頭部)
3. 常規固定換算:MSS = MTU – 404. VPN/隧道本質:給予原始資料包外層多套一層協定殼,擠佔傳輸空間,降低有效MTU




