網絡慢故障分析實例科來安徽辦事處目錄零窗口導致應用間歇性停滯打印慢故障防火墻應用層檢測導致FTP慢網上申報故障業務訪問慢案例1-TCP窗口問題導致應用慢故障現象：應用在交互的過程中，經常出現數秒的停滯，然后恢復正常，過段時間后，又再次出現停滯現象，如此反復數據交互過程分析C發送133B的數據C發送512B的數據S通告窗口大小為348BC發送53B的數據C發送348B的數據S通告窗口大小為0C對S的窗口探測報文S窗口仍未更新，大小為0C對S的窗口探測報文S窗口仍未更新，大小為0S窗口更新為8192B窗口問題導致應用產生了3秒的延時零窗口一般都是應用程序處理性能較差，來不及處理緩存中的數據或者應用服務器本身性能不足導致的分析結論分析結論:應用出現停滯現象主要是由于服務器端出現窗口為０導致的，肯定跟網絡無關，可以從服務器本身性能或者服務器端應用程序入手進行相應的檢查案例2-某應用打印慢故障故障現象：用戶某個業務應用在執行打印操作時，打印速度很慢，一般需要等20多秒才可以正常打印。故障分析：打印行為似乎跟網絡無關，但是我們還是先抓包看看，我們發現，每次打印的時候，客戶端均需要連接數據庫服務器，如下圖：這說明，這個打印操作是需要連接網絡中的數據庫，從數據庫中調用相關的打印數據，也就是說，這個網絡調用的過程，很可能就是產生打印時延的原因分析過程1-定位異常TCP會話在科來的“會話”視圖中，我們查看TCP會話，我們可以發現有三個會話跟數據庫有關我們可以根據TCP的會話持續時間，來定位產生延時的TCP會話分析過程2-定位延時產生的位置原理：我們通過時間差來定位延時產生的位置。我們可以發現在時間差視圖中，存在一個22.9秒的延時，這個數據包是客戶端向服務器發送的數據包，那么這個延時應該就是客戶端產生的分析過程3-查看數據包內容是客戶端向數據庫服務器進行查詢的行為；客戶端在等待了近23秒才向服務器發出這個查詢操作！分析結論與故障解決分析結論：1，客戶端在執行打印操作時，需要向網絡中的數據庫服務器調用相應的打印數據2，客戶端在與數據庫服務器交互的過程中，本身在執行一個查詢操作前，等待了22.98秒的時間，從而導致了打印的延時故障解決：卸載這個應用軟件，重新安裝，再次測試打印速度，已經恢復正常，至此，故障解決小結：其實，我們還可以通過對比分析法（對比分析正常打印的數據包與打印慢的數據包）來定位這個故障的原因。案例3-防火墻應用層檢測BUG導致FTP慢故障現象故障環境故障分析思路故障分析過程故障解決故障環境說明：1、客戶端的默認網關是主路由器2、主路由上設置了相應的策略，凡是FTP/HTTP的應用均交由備路由處理3、備路由上會將訪問國家局的網段指向國家局路由4、核心與路由間均部署防火墻，防火墻工作在透明模式下5、客戶端訪問服務器的數據流走向比較復雜，看演示思考：服務器回包的數據流走向是如何的？故障現象省局到國家局的FTP服務很慢，一般需要40多秒才可以登陸上去，有時根本登陸不上去Ping測試延時很小省局到國家局的HTTP應用正常前期簡單分析Ping延時很小，說明網絡層的延時很正常網絡環境復雜，數據流走向復雜，數據包來回路徑不一致，中間經過2臺防火墻，可能存在狀態檢測的問題HTTP的數據流走向跟FTP的數據流走向應該是一樣的，HTTP正常，FTP不正常，說明這個跟TCP的狀態檢測無關，應該是FTP應用層的問題暫時沒什么頭緒，只能先從客戶端下手，進行抓包分析，看看大體的情況登陸不上時的數據包分析TCP三次握手建立連接S響應：winsockreadyC輸入用戶名C用戶名第一次重傳2.9S的延時S的第一次重傳S的第二次重傳C用戶名第二次重傳C用戶名第三次重傳S的第三次重傳C用戶名第四次重傳S：用戶名ok，需密碼C輸入密碼S：超時關閉S“需密碼”重傳C重傳密碼5.9S的延時12S的延時23.9S的延時23.9S的延時6S的延時15.8S的延時C對”S第一次重傳“的確認C對”S第二次重傳“的確認C對”S第三次重傳“的確認登陸成功，但是很慢的數據包分析TCP三次握手建立連接S響應：winsockreadyC輸入用戶名C用戶名第一次重傳C用戶名第二次重傳C對”S第一次重傳“的確認C對”S第二次重傳“的確認S的第一次重傳S的第二次重傳S：用戶名ok，需密碼S“需密碼”第一次重傳C輸入密碼C密碼第一次重傳C密碼第二次重傳S“需密碼”第二次重傳C密碼第三次重傳S：登陸成功29.9S的延時23.9S的延時11.9S的延時5.8S的延時2.8S的延時交互過程示意圖用戶名請求用戶名請求用戶名用戶名請求用戶名請求用戶名用戶名請求用戶名請求用戶名請求用戶名請求用戶名S：winsockreadyC輸入用戶名C用戶名第一次重傳C用戶名第二次重傳S的第一次重傳S的第二次重傳S的第三次重傳結論：客戶端傳輸用戶的數據包被中間設備丟掉了！定位是什么設備丟包原理：一個目的地址不是中間設備的包進入一個中間設備，它必然會被中間設備轉發到一個出口，否則，就是被中間設備丟棄了對比分析法：通過抓取中間設備進出口的數據包，結合數據包內IPID、五元組、內容等信息來判斷是否屬于同一會話，是否有數據包被丟棄雙網卡筆記本安裝科來開啟兩個工程，分別針對中間設備進出口抓包TAPTAP其實我們也可以利用中間設備本身自帶的抓包功能進行分析和定位，具體可以參考我以前寫的PPT：《疑難故障解決實例》通過此種方法，我們定位出是防火墻丟包！防火墻丟包原因分析TIPS:防火墻中的兩個概念狀態檢測：深度檢測：原因分析：1，數據包來回路徑肯定是不一致的，那么對于基于狀態檢測的防火墻，是不會建立TCP連接的但是HTTP應用正常，抓包顯示FTP三次握手的過程也很正常，說明跟TCP狀態檢測無關2，抓包分析我們可以發現被丟棄的包都是FTP傳輸用戶名和密碼的包，這個肯定屬于FTP應用層的包，防火墻丟棄FTP應用層的數據包，那么問題應該就出在防火墻的FTP應用層檢測上故障解決故障解決：1，在防火墻上取消FTP應用綁定，讓防火墻不要對FTP的數據包進行深度的過濾和檢測2，測試，FTP登陸正常思考：除了在防火墻上取消針對FTP應用的應用層深度檢測功能外，還有其他的解決方式嗎？提示：大家注意數據包中的ICMP重定向報文案例4-網上申報故障說明:1，網上申報服務器的地址是，經過網閘后轉換為X.X.16.73；2，前置機的IP地址為X.X.16.56，征管服務器的IP地址為X.X.16.200。業務訪問流程：1，納稅人通過互聯網登陸網上申報服務器，提交相關納稅信息；2，網上申報服務器將這些納稅信息轉發給前置機的同時，將相關信息寫入征管服務器數據庫；3，網上申報服務器與前置機的數據交互出現問題，那么網上申報服務器會將征管服務器數據庫相關的信息鎖死

拓撲：故障現象故障現象：1，網上申報業務系統運行時，每天總有一部分納稅人的申報表單數據無法正常上傳，可以通過征管服務器的業務軟件看到這些用戶的申報數據處于鎖狀態；2，在沒有網閘的情況下，網上申報服務器與前置機直接通訊，則故障現象消失，網上納稅全部正常。故障分析前期分析1，結合故障現象與業務流程，我們可以清晰的發現，問題應該就是出現在網上申報服務器經過網閘的地址轉換后與前置機交互的過程。2，在網上申報服務器不通過網閘的地址轉換而是直接與前置機交互的時候，業務應用一切正常，那么，是網閘在做地址轉換的時候對某些數據報文做了修改或者是網閘直接丟棄了某些業務報文導致的故障嗎？3，網閘是最為可疑的故障關鍵點，我們決定在網閘前后部署網絡分析系統（在此環境下，可直接在申報服務器上和前置機上分別安裝網絡分析系統），對網上申報業務數據交互過程分別進行抓包，如下圖所示：數據分析-發現異常TCP會話我們通過科來網絡分析系統捕獲前置機交互的數據包，一段時間后，我們在“TCP會話”視圖中，發現有幾個TCP會話持續的時間比一般的TCP會話長很多，如下圖所示：這幾個TCP會話持續的時間均超出其他的會話很多異常會話交互過程分析網閘地址73首先發送RESET報文網閘地址向前置機發送（重傳）報文，前置機直接發送RESET報文重置連接。這個過程，導致了該TCP會話持續時間很長。第一個reset報文解碼這個數據報文的源MAC地址并非網閘的MAC，真實的網閘MAC地址是00:40:63:EF:43:DF

為什么網閘的MAC發生了變化？難道網內存在會話劫持？查看整個交互過程的MAC變化網閘源MAC為00:40:63:EF:43:DF前置機發往網閘的確認數據報文，封裝的目的MAC卻是00:21:5E:82:AF:86MAC為00:21:5E:82:AF:86的設備以網閘的IP向前置機發送RESET報文在交互的過程中，前置機將發給網閘地址的確認報文，封裝了一個非網閘的MAC地址00:21:5E:82:AF:86，為什么會突然出現了這種改變呢？前置機封裝錯誤目的MAC的原因InternetAddressPhysicalAddressTypeX.X.16.7300-21-5E-82-AF-86dynamicTIPS：ARP表的更新實際環境中，只有同時滿足以下兩個條件時，設備的ARP表項才會更新：1，設備收到來自某IP的ARP請求包或免費ARP包；2，設備的現有ARP表項中已經存在該IP對應的ARP表項。其他的非ARP報文不會對設備的ARP表項產生影響。一般而言，主機是根據其ARP表項來封裝要發送的數據報文的目的MAC地址，那么，這里前置機發往網閘數據報文的目的MAC地址出現改變是否是因為前置機的ARP表項內容變化了呢？我們在前置機的DOS窗口下，使用arp–a命令查看異常時的arp表項內容，發現網閘IP對應的MAC地址的確變成了00:21:5E:82:AF:86。前置機ARP表更新的原因我們在科來網絡分析系統的“數據包”視圖查看交互過程的所有數據報文來自MAC地址為00-21-5E-82-AF-86的ARP響應到達了前置機，前置機更新其ARP表項前置機向網絡中發送ARP請求，請求網閘IP對應的MAC前置機在收到來自網閘的數據報文之后，都向00-21-5E-82-AF-86地址發送確認報文網閘、前置機以及未知設備的數據交互情況和狀態變化案例5-業務訪問慢訪問過程的簡單流程說明：高新建投集團辦公系統服務器地址為91，通過防火墻轉換為39，提供訪問的端口為6888。高新建投集團辦公局域網中的用戶如要訪問辦公系統要通過防火墻進行地址轉換為