網(wǎng)絡慢分析實例

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

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

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