本期分享的案例是有線網(wǎng)絡(luò)的相關(guān)問題。

背景介紹

一朋友在是某單位的IT管理，出口路由用的是某P的設(shè)備靜態(tài)公網(wǎng)IP，其一直耿耿于懷，我也不知道為什么。近期發(fā)現(xiàn)，遠(yuǎn)程PC通過互聯(lián)網(wǎng)訪問出口路由器的web管理頁面失敗，表現(xiàn)為能加載一部分信息，但是沒有彈窗登錄頁面：

于是很高興地瘋狂投訴某P售后，結(jié)果人家檢查了設(shè)備沒問題而是線路問題。很不甘心，求助于我，如果是產(chǎn)品問題直接走法律程序賠償。我不知道為何他執(zhí)念為何那么深，給他做了簡單的排查。

排查分析

第一步：對比測試

原拓?fù)洌?/p>

測試結(jié)果：PC打開瀏覽器，通過路由器公網(wǎng)IP+端口號，無法打開路由Web管理頁面和登錄。

對比拓?fù)洌?/p>

測試結(jié)果：PC打開瀏覽器，通過路由器公網(wǎng)IP+端口號，正常打開路由Web管理頁面并正常登錄

一般情況來講，正常人到這一步大概差不多了，是否經(jīng)過ISP運(yùn)營鏈路導(dǎo)致的異常其實對比很明顯。此人又較真：“路由器接入了寬帶后自己功能異常了，兼容性太垃圾，直連PC這種做不得數(shù)。需要專業(yè)的排障，抓個包看看。”我：“有道理，那就在原拓?fù)湎拢€包看看”

第二步：報文分析

抓包自然是要抓取鏈路收尾兩端的報文，第一個是遠(yuǎn)程PC接口報文，第二個是路由器GE1（WAN）口報文，同時比對丟包情況才能分析出問題，如下：

抓取訪問Web頁面異常時遠(yuǎn)程筆記本出接口的報文，如下：

可以看到加載部分資源的TCP會話一直SYN重傳沒有建立起來，并結(jié)合瀏覽器F12調(diào)試可分析應(yīng)該是嘗試去加載jpg圖片、JS文件資源時握手失敗。下面就看看路由器那邊有沒有收到握手的請求了。

抓取訪問Web頁面異常時某P路由器出口GE1接口的報文，如下：

發(fā)現(xiàn)會話都是正常的，沒有異常的會話，說明客戶端請求圖片、JS資源的TCP SYN請求沒有過來。

綜合分析：

訪問路由器Web頁面的部分會話是成功了，但是部分資源會話的請求卻沒有過來，也就是路由器的GE1接口沒有收到，基本確認(rèn)是中間運(yùn)營商鏈路丟包導(dǎo)致。

解決方案

找運(yùn)營商確認(rèn)或者更換鏈路對比試一下，但這老哥覺得我分析可能漏了些細(xì)節(jié)，欺負(fù)他看不懂報文。So，what can i say？朋友們，對于一個品牌你們會有這么大的惡意么？