本期分享的案例是有線網絡的相關問題。

1. 背景介紹

某公司近期搬遷后，網絡設備不變（某G路由+某W交換機組網）。員工目前普遍反饋網絡慢，表現為網頁加載不完全、加載時間長、網頁轉圈、部分網頁打不開需要多次刷新.....

2. 網絡拓撲

規模在兩百人左右使用上網，網絡拓撲如下：

三層網絡架構，劃分了多個VLAN供業務部門使用。

四條入戶寬帶均為動態公網IP，三條電信+一條移動

3. 基礎分析

針對這種整網卡頓的問題，一般能想到的原因可能有：DNS服務器異常或響應慢、帶寬負載不均勻和寬帶會話數限制等，所以IT在出口路由器上做了相關的優化策略如下：

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

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

4. 深入分析

(1) 遠程確實發現網站存在卡頓異常，遲遲刷不出來內容或加載失敗

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

我們再看下另外一條異常訪問Web的TCP流：

服務器返回的TCP報文的Seq錯誤導致終端無法接收，可能有兩種原因：

• 其一是服務器真返回錯了，概率非常小，接下來進一步抓WAN口去證明即可
• 其二是TCP報文被路由器篡改導致返回錯誤。

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

可以明確看到路由器WAN與網站服務器TCP交互的過程中，路由WAN響應的ACK值明顯不對，給了一個非常大得錯誤值，而不是ack=seq+len。

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

這條正常的TCP交互流中，服務器和路由器WAN口都遵循TCP握手中seq和ack的標準計算，所以雙方都認，沒啥問題。

5. 原因定位及解決方案

(1) 根本原因：

顯然是出口路由存在TCP流交互異常，對內返回的網站TCP報文Seq值異常，PC無法接收；對外要求網站響應的TCP報文ack值異常，網站服務器無法接收和正常交互。

(2) 解決方案：

應該屬于產品BUG，但TCP流往往和硬件加速有關，可以嘗試關閉路由器的硬件加速功能觀察使用，但要注意，關閉此功能一般會導致吞吐量和轉發性能的下降。

(3) 后續情況：

目前來看已解決，問題閉環。