網(wǎng)站制作NEWS
Wireshark TS | 二談訪問網(wǎng)頁失敗
訪問網(wǎng)頁失敗案例分析
案例背景描述了一個從Wireshark sharkfest 2018 - Point And ShootPacket中提取的案例，涉及用戶在訪問某些網(wǎng)站頁面時無法顯示，而其他頁面如Google可以正常訪問，但Apple網(wǎng)站訪問失敗。初步結(jié)論指向了廣域網(wǎng)環(huán)境中的MTU問題。撰寫此文章的原因是該案例采用對比分析方法，通過收集多個數(shù)據(jù)包以清晰地揭示問題本質(zhì)。
問題信息收集
為了進(jìn)行故障排查，用戶分別在OSAKA和TOKYO局域網(wǎng)下捕獲了兩個pcap文件，分別標(biāo)記為2_OSAKA_FAIL_LAN.pcap和2_TOKYO_SUCCESS_LAN.pcap。
數(shù)據(jù)包跟蹤文件詳細(xì)信息如下：
2_OSAKA_FAIL_LAN.pcap：通過Tcpdump捕獲，無截斷，捕獲數(shù)據(jù)包數(shù)量僅為5個，捕獲持續(xù)時間為0.1秒，平均速率為46kbps。數(shù)據(jù)包數(shù)量少且捕獲時間短，推斷用戶根據(jù)問題所在，精確過濾了關(guān)鍵問題數(shù)據(jù)包。
2_TOKYO_SUCCESS_LAN.pcap：同樣通過Tcpdump捕獲，無截斷，捕獲數(shù)據(jù)包數(shù)量233個，捕獲持續(xù)時間為1.3秒，平均速率為1263kbps。
專家分析
數(shù)據(jù)包跟蹤文件總體沒有明顯問題，需要深入數(shù)據(jù)包分析。
問題分析
對比OSAKA和TOKYO兩個局域網(wǎng)的數(shù)據(jù)包信息，關(guān)鍵差異在于MTU問題。OSAKA局域網(wǎng)捕獲的數(shù)據(jù)包在TCP三次握手后，客戶端發(fā)送GET請求，服務(wù)器僅回復(fù)了ACK，沒有后續(xù)數(shù)據(jù)響應(yīng)。而TOKYO局域網(wǎng)捕獲的數(shù)據(jù)包，在TCP三次握手后，客戶端發(fā)送GET請求，服務(wù)器回復(fù)了ACK以及數(shù)據(jù)分段，HTTP交互結(jié)果為200 OK。
對比分析顯示，OSAKA和TOKYO局域網(wǎng)在TCP三次握手過程中，客戶端通告的MSS均為1460，但收到服務(wù)器端發(fā)來的SYN/ACK時，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ù)分段在中間被丟棄，客戶端僅收到服務(wù)器的ACK后陷入沉默。而在TOKYO局域網(wǎng)中，服務(wù)器發(fā)送的數(shù)據(jù)分段滿足廣域網(wǎng)中間路徑的最小MTU限制，因此數(shù)據(jù)分段成功傳輸，客戶端正常完成交互。
結(jié)論
通過對比OSAKA和TOKYO局域網(wǎng)的數(shù)據(jù)包跟蹤文件，明確揭示了訪問網(wǎng)頁失敗的原因是MTU問題。問題的根本原因可能在于中間的網(wǎng)絡(luò)環(huán)境，如路由器對MSS大小的調(diào)整。對于需要添加報頭的網(wǎng)絡(luò)環(huán)境，如PPPOE、IPSEC VPN等，根據(jù)實際情況調(diào)整MSS或MTU值以保證正常傳輸。
多重隨機(jī)標(biāo)簽