《CSNA網(wǎng)絡(luò)分析認(rèn)證專家實戰(zhàn)案例》課件-第41章

第41章高校網(wǎng)絡(luò)訪問速度慢的探究和分析報告41.1故障描述41.2分析方案設(shè)計41.3分析情況41.4分析結(jié)論

41.1.1基本環(huán)境

用戶的基本網(wǎng)絡(luò)拓?fù)淙鐖D41-1所示，整個網(wǎng)絡(luò)環(huán)境主要是通過核心交換機連接一個流控設(shè)備，然后流控設(shè)備再連到防火墻，通過防火墻上網(wǎng)。學(xué)校招待所的網(wǎng)絡(luò)通過連接一臺TP-LINK路由器做了地址轉(zhuǎn)換，將所有從招待所出去的主機地址都映射為一個地址——192.168.30.253。41.1故障描述

圖41-141.1.2故障現(xiàn)象

整個學(xué)院的網(wǎng)絡(luò)主要分為辦公網(wǎng)和家用網(wǎng)兩大塊，故障出現(xiàn)在招待所網(wǎng)絡(luò)，而辦公網(wǎng)沒有出現(xiàn)故障。

招待所內(nèi)主機打開網(wǎng)頁的速度非常慢，不僅是像新浪這樣圖片很多的網(wǎng)站，就連訪問本學(xué)院對外的Web服務(wù)器也很慢。但是一旦把招待所網(wǎng)絡(luò)全部斷掉，用一臺機器直接接在招待所路由上訪問，打開網(wǎng)頁的速度就非常正常。而且在出現(xiàn)故障時，我們通過Ping測試發(fā)現(xiàn)延時只有幾十毫秒，也沒有嚴(yán)重的丟包現(xiàn)象。

41.2.1分析目標(biāo)

我們實地捕獲招待所計算機對互聯(lián)網(wǎng)訪問的數(shù)據(jù)流，通過分析訪問的整個過程來判斷網(wǎng)絡(luò)訪問慢是由于網(wǎng)絡(luò)延時、丟包還是其他原因引起的。41.2分析方案設(shè)計41.2.2分析設(shè)備部署

我們在招待所交換機和學(xué)院核心交換機上部署分析設(shè)備，鏡像網(wǎng)絡(luò)流量，對訪問互聯(lián)網(wǎng)的流量進(jìn)行捕獲并分析，如圖41-2所示。

圖41-2

41.3.1對招待所捕獲的Web訪問數(shù)據(jù)進(jìn)行分析

首先，我們在招待所捕獲一個學(xué)員對Web服務(wù)器訪問的數(shù)據(jù)流，然后對該數(shù)據(jù)流進(jìn)行詳細(xì)的解碼分析，如圖41-3所示。41.3分析情況

圖41-3在TCP會話分析中，我們得到該數(shù)據(jù)流的如下信息：

(1)數(shù)據(jù)流持續(xù)時間：1分17秒，也就是整個訪問持續(xù)的時間。

(2)總字節(jié)數(shù)：57KB。

從上面的數(shù)據(jù)我們可以看到，整個訪問的總字節(jié)數(shù)只有57KB，但時間用了1分多鐘，確實是非常慢的。

下面來解碼分析詳細(xì)的會話過程。

(1)三次握手時間很短，只有不到1毫秒，說明網(wǎng)絡(luò)的延時很短。

(2)服務(wù)器對GET請求的響應(yīng)為145毫秒，響應(yīng)速度正常。

(3)數(shù)據(jù)傳輸時間為1分17秒，傳輸?shù)臅r間過長。

從上面的分析我們可以非常容易地發(fā)現(xiàn)，整個會話的時間過長，基本上都是由于數(shù)據(jù)傳輸造成的。

通過對傳輸過程數(shù)據(jù)包的進(jìn)一步分析，我們發(fā)現(xiàn)在傳輸過程中沒有出現(xiàn)重傳、丟包的現(xiàn)象，但是服務(wù)器發(fā)送數(shù)據(jù)時有停頓，在整個過程中出現(xiàn)了9次停頓，每次停頓的時間從4秒到10秒不等，整個停頓的時間非常長，導(dǎo)致了傳輸?shù)倪^程很長。

如圖41-4所示，傳輸過程中還出現(xiàn)重復(fù)的確認(rèn)和亂序現(xiàn)象，說明在網(wǎng)絡(luò)中傳輸出現(xiàn)異常。

圖41-441.3.2在服務(wù)器端進(jìn)行流量分析

為確認(rèn)服務(wù)器發(fā)送數(shù)據(jù)的停頓是服務(wù)器還是由于網(wǎng)絡(luò)傳輸造成的，我們在服務(wù)器端捕獲網(wǎng)絡(luò)訪問流量，同時在核心交換機上也捕獲流量，進(jìn)行比對分析，以確認(rèn)造成數(shù)據(jù)傳輸停頓的原因。

如圖41-5所示，通過對服務(wù)器端數(shù)據(jù)的分析我們發(fā)現(xiàn)，服務(wù)器端發(fā)送數(shù)據(jù)時有大量的重傳現(xiàn)象，每次數(shù)據(jù)重傳都是由于在傳輸數(shù)據(jù)后沒有得到客戶端確認(rèn)，造成傳輸?shù)耐ｎD。

圖41-5在服務(wù)器端和客戶端的數(shù)據(jù)分析結(jié)果有明顯的不同，客戶端分析中并沒有收到數(shù)據(jù)，也沒有確認(rèn)，只有服務(wù)器停頓的現(xiàn)象，而在服務(wù)器端分析確實是發(fā)出了數(shù)據(jù)包的，所以停頓后重傳。這說明網(wǎng)絡(luò)中可能存在丟包，導(dǎo)致數(shù)據(jù)傳輸出現(xiàn)問題。41.3.3查找丟包點

利用分析設(shè)備分段捕獲以查找網(wǎng)絡(luò)丟包點，從而定位問題點。我們將流量控制設(shè)備前和流量控制設(shè)備后的訪問數(shù)據(jù)流時序圖進(jìn)行對比分析發(fā)現(xiàn)，互聯(lián)網(wǎng)服務(wù)器端發(fā)送的數(shù)據(jù)包在經(jīng)過流控設(shè)備時有丟包現(xiàn)象，發(fā)生丟包后服務(wù)器會重傳，但沒有應(yīng)答的數(shù)據(jù)包；然而，在流控設(shè)備之后我們看到，丟包發(fā)生時刻有較長一段時間沒有捕獲任何服務(wù)器數(shù)據(jù)包。所以，我們可以判斷數(shù)據(jù)包被丟失是發(fā)生在流控設(shè)備上。

流控設(shè)備的丟包造成招待所對Internet訪問緩慢，當(dāng)招待所上網(wǎng)主機少時，流控設(shè)備沒有丟包，訪問正常；當(dāng)上網(wǎng)主機多時，流控設(shè)備丟包明顯，導(dǎo)致訪問極其緩慢。而同樣經(jīng)過流控設(shè)備的辦公網(wǎng)絡(luò)則沒有這種現(xiàn)象。41.4分析結(jié)論我們推斷是由于招待所采用了一臺路由設(shè)備進(jìn)行NAT，對