訪問(wèn)網(wǎng)頁(yè)失敗案例分析

案例背景描述了一個(gè)從Wireshark sharkfest 2018 - Point And ShootPacket中提取的案例，涉及用戶(hù)在訪問(wèn)某些網(wǎng)站頁(yè)面時(shí)無(wú)法顯示，而其他頁(yè)面如Google可以正常訪問(wèn)，但Apple網(wǎng)站訪問(wèn)失敗。初步結(jié)論指向了廣域網(wǎng)環(huán)境中的MTU問(wèn)題。撰寫(xiě)此文章的原因是該案例采用對(duì)比分析方法，通過(guò)收集多個(gè)數(shù)據(jù)包以清晰地揭示問(wèn)題本質(zhì)。

問(wèn)題信息收集

為了進(jìn)行故障排查，用戶(hù)分別在OSAKA和TOKYO局域網(wǎng)下捕獲了兩個(gè)pcap文件，分別標(biāo)記為2_OSAKA_FAIL_LAN.pcap和2_TOKYO_SUCCESS_LAN.pcap。

數(shù)據(jù)包跟蹤文件詳細(xì)信息如下：

2_OSAKA_FAIL_LAN.pcap：通過(guò)Tcpdump捕獲，無(wú)截?cái)?，捕獲數(shù)據(jù)包數(shù)量?jī)H為5個(gè)，捕獲持續(xù)時(shí)間為0.1秒，平均速率為46kbps。數(shù)據(jù)包數(shù)量少且捕獲時(shí)間短，推斷用戶(hù)根據(jù)問(wèn)題所在，精確過(guò)濾了關(guān)鍵問(wèn)題數(shù)據(jù)包。

2_TOKYO_SUCCESS_LAN.pcap：同樣通過(guò)Tcpdump捕獲，無(wú)截?cái)啵东@數(shù)據(jù)包數(shù)量233個(gè)，捕獲持續(xù)時(shí)間為1.3秒，平均速率為1263kbps。

專(zhuān)家分析

數(shù)據(jù)包跟蹤文件總體沒(méi)有明顯問(wèn)題，需要深入數(shù)據(jù)包分析。

問(wèn)題分析

對(duì)比OSAKA和TOKYO兩個(gè)局域網(wǎng)的數(shù)據(jù)包信息，關(guān)鍵差異在于MTU問(wèn)題。OSAKA局域網(wǎng)捕獲的數(shù)據(jù)包在TCP三次握手后，客戶(hù)端發(fā)送GET請(qǐng)求，服務(wù)器僅回復(fù)了ACK，沒(méi)有后續(xù)數(shù)據(jù)響應(yīng)。而TOKYO局域網(wǎng)捕獲的數(shù)據(jù)包，在TCP三次握手后，客戶(hù)端發(fā)送GET請(qǐng)求，服務(wù)器回復(fù)了ACK以及數(shù)據(jù)分段，HTTP交互結(jié)果為200 OK。

對(duì)比分析顯示，OSAKA和TOKYO局域網(wǎng)在TCP三次握手過(guò)程中，客戶(hù)端通告的MSS均為1460，但收到服務(wù)器端發(fā)來(lái)的SYN/ACK時(shí)，OSAKA的MSS為1460，而TOKYO的MSS為1414。這種差異導(dǎo)致后續(xù)部分?jǐn)?shù)據(jù)分段發(fā)送失敗。

OSAKA局域網(wǎng)中，由于廣域網(wǎng)中間路徑的最小MTU限制，導(dǎo)致服務(wù)器發(fā)送的數(shù)據(jù)分段在中間被丟棄，客戶(hù)端僅收到服務(wù)器的ACK后陷入沉默。而在TOKYO局域網(wǎng)中，服務(wù)器發(fā)送的數(shù)據(jù)分段滿(mǎn)足廣域網(wǎng)中間路徑的最小MTU限制，因此數(shù)據(jù)分段成功傳輸，客戶(hù)端正常完成交互。

結(jié)論

通過(guò)對(duì)比OSAKA和TOKYO局域網(wǎng)的數(shù)據(jù)包跟蹤文件，明確揭示了訪問(wèn)網(wǎng)頁(yè)失敗的原因是MTU問(wèn)題。問(wèn)題的根本原因可能在于中間的網(wǎng)絡(luò)環(huán)境，如路由器對(duì)MSS大小的調(diào)整。對(duì)于需要添加報(bào)頭的網(wǎng)絡(luò)環(huán)境，如PPPOE、IPSEC VPN等，根據(jù)實(shí)際情況調(diào)整MSS或MTU值以保證正常傳輸。