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

1. 背景介紹

某公司近期搬遷后，網(wǎng)絡(luò)設(shè)備不變（某G路由+某W交換機(jī)組網(wǎng)）。員工目前普遍反饋網(wǎng)絡(luò)慢，表現(xiàn)為網(wǎng)頁(yè)加載不完全、加載時(shí)間長(zhǎng)、網(wǎng)頁(yè)轉(zhuǎn)圈、部分網(wǎng)頁(yè)打不開需要多次刷新.....

2. 網(wǎng)絡(luò)拓?fù)?/h4>

規(guī)模在兩百人左右使用上網(wǎng)，網(wǎng)絡(luò)拓?fù)淙缦拢?/p>

三層網(wǎng)絡(luò)架構(gòu)，劃分了多個(gè)VLAN供業(yè)務(wù)部門使用。

四條入戶寬帶均為動(dòng)態(tài)公網(wǎng)IP，三條電信+一條移動(dòng)

3. 基礎(chǔ)分析

針對(duì)這種整網(wǎng)卡頓的問題，一般能想到的原因可能有：DNS服務(wù)器異?；蝽憫?yīng)慢、帶寬負(fù)載不均勻和寬帶會(huì)話數(shù)限制等，所以IT在出口路由器上做了相關(guān)的優(yōu)化策略如下：

• 嘗試一：“多線策略”使用負(fù)載均衡，無明顯改善
• 嘗試二：“多線策略”使用智能選線，無明顯改善
• 嘗試三：LAN口DHCP DNS使用本DNS（電信DNS）無明顯改善，之前是使用的公共DNS（百度,阿里，騰訊）
• 嘗試四：使用策略路由指定出口進(jìn)行分流，無明顯改善
• 確認(rèn)會(huì)話數(shù)：由于寬帶用的都是公網(wǎng)IP的企寬，和運(yùn)營(yíng)商確認(rèn)是無限制的

那下來就進(jìn)一步分析，看看問題原因到底是出現(xiàn)寬帶線路上還是其它。

4. 深入分析

(1) 遠(yuǎn)程確實(shí)發(fā)現(xiàn)網(wǎng)站存在卡頓異常，遲遲刷不出來內(nèi)容或加載失敗

(2) 直接來看PC抓取訪問該Web的異常TCP流（抓包中的對(duì)應(yīng)stream61），可以看到服務(wù)器響應(yīng)的Seq明顯出了問題：握手之后的服務(wù)器—>終端第一個(gè)包的seq為1，下來的報(bào)文應(yīng)該seq=1+length=1+0=1，但卻變成了3264449421：

我們?cè)倏聪铝硗庖粭l異常訪問Web的TCP流：

服務(wù)器返回的TCP報(bào)文的Seq錯(cuò)誤導(dǎo)致終端無法接收，可能有兩種原因：

• 其一是服務(wù)器真返回錯(cuò)了，概率非常小，接下來進(jìn)一步抓WAN口去證明即可
• 其二是TCP報(bào)文被路由器篡改導(dǎo)致返回錯(cuò)誤。

(3) 抓取WAN口訪問Web的異常TCP流，如下：

可以明確看到路由器WAN與網(wǎng)站服務(wù)器TCP交互的過程中，路由WAN響應(yīng)的ACK值明顯不對(duì)，給了一個(gè)非常大得錯(cuò)誤值，而不是ack=seq+len。

(4) 來對(duì)比看看正常的TCP流交互就清楚了：

這條正常的TCP交互流中，服務(wù)器和路由器WAN口都遵循TCP握手中seq和ack的標(biāo)準(zhǔn)計(jì)算，所以雙方都認(rèn)，沒啥問題。

5. 原因定位及解決方案

(1) 根本原因：

顯然是出口路由存在TCP流交互異常，對(duì)內(nèi)返回的網(wǎng)站TCP報(bào)文Seq值異常，PC無法接收；對(duì)外要求網(wǎng)站響應(yīng)的TCP報(bào)文ack值異常，網(wǎng)站服務(wù)器無法接收和正常交互。

(2) 解決方案：

應(yīng)該屬于產(chǎn)品BUG，但TCP流往往和硬件加速有關(guān)，可以嘗試關(guān)閉路由器的硬件加速功能觀察使用，但要注意，關(guān)閉此功能一般會(huì)導(dǎo)致吞吐量和轉(zhuǎn)發(fā)性能的下降。

(3) 后續(xù)情況：

目前來看已解決，問題閉環(huán)。