最近網(wǎng)絡(luò)故障臺經(jīng)常報告用戶普遍反映玩《傳奇》特別慢，用戶維護人員奔波于用戶之間，但是收效甚微。于是我們網(wǎng)管人員來分析解決這次軟故障，從而開始了為期半月的艱苦診斷歷程。
網(wǎng)絡(luò)結(jié)構(gòu)圖
在我們企業(yè)局域網(wǎng)中，A、B兩個網(wǎng)絡(luò)各自主干核心速度均為千兆，桌面速度均為百兆，內(nèi)部A、B兩個網(wǎng)絡(luò)是通過RouterA和RouterB兩個路由器的廣域網(wǎng)接口連接，主要應(yīng)用的服務(wù)器在A網(wǎng)絡(luò)，因此B網(wǎng)絡(luò)用戶通過Router的5個端口（10M）訪問位于A網(wǎng)絡(luò)的企業(yè)主頁及內(nèi)部網(wǎng)絡(luò)應(yīng)用的服務(wù)器。
故障分析
在出現(xiàn)軟故障前，最近系統(tǒng)沒有修改任何數(shù)據(jù)，而傳奇是我們新增加的網(wǎng)絡(luò)應(yīng)用服務(wù)；只是最近B網(wǎng)絡(luò)個人用戶增加比較多，而大多喜歡玩A網(wǎng)絡(luò)的傳奇，但是我們分析這絕不是游戲運行緩慢的主要原因，因為用戶反映上內(nèi)部網(wǎng)和外部Ineternet速度都不慢。
1）經(jīng)過現(xiàn)場實驗，得到如下結(jié)果：
A網(wǎng)絡(luò)用戶作為本地用戶玩?zhèn)髌鎰t速度正常，說明了A網(wǎng)絡(luò)本地網(wǎng)絡(luò)和傳奇服務(wù)器本身正常；
B網(wǎng)絡(luò)用戶訪問A網(wǎng)絡(luò)的其它應(yīng)用，如Web、E-mail、OA速度都比較快；
B網(wǎng)絡(luò)用戶訪問B網(wǎng)絡(luò)的本地服務(wù)器和通過B網(wǎng)絡(luò)上Internet速度比較快。說明B網(wǎng)絡(luò)本地網(wǎng)絡(luò)正常；
2）使用工具軟件對系統(tǒng)的測試
通過HPOpenview網(wǎng)管軟件分析各個設(shè)備之間沒有發(fā)現(xiàn)異常的流量；
通過協(xié)議分析儀沒有發(fā)現(xiàn)大量的ARP廣播查詢報文、CRC錯誤和FCS幀錯誤，證明AB網(wǎng)絡(luò)間的2M鏈路正常。
通過端口檢測發(fā)現(xiàn)A、B兩個網(wǎng)絡(luò)之間的廣域網(wǎng)接口的每個2M口數(shù)據(jù)量均達到飽和，接近80%.
問題在哪兒呢，僅僅是B網(wǎng)絡(luò)增加了傳奇用戶嗎？不是，我們判斷問題在于A、B網(wǎng)絡(luò)的連接通道，路由器的廣域網(wǎng)接口是B網(wǎng)絡(luò)用戶訪問A網(wǎng)絡(luò)傳奇服務(wù)器的傳輸瓶頸。看來A、B兩個網(wǎng)絡(luò)之間的廣域網(wǎng)接口重負荷很可能是游戲速度緩慢的主要原因，經(jīng)過我們長期監(jiān)測，該鏈路一直比較忙。由于各種原因，這個傳輸瓶頸不能從根本上解決，本次故障需從其它方面入手解決。
要根本解決這個問題，看來還得具體來分析傳奇游戲報文的發(fā)送過程：
我們聯(lián)系了一個正在玩?zhèn)髌娴挠脩簦褂肧niffer軟件進行跟蹤抓包，捕獲的數(shù)據(jù)流報文如下：
SourceAdressDestAdressSummaryLength 192.168.82.252192.168.8.190tcp:d=7200s=2353ack-1809293876wins=63266 192.168.8.190192.168.82.252tcp:Expert:FastRetransmission d=2353d=7200ack-577334120SEQ=1803135 192.168.82.252192.168.8.190tcp:d=7200s=2353ack-1809293957wins=63260 192.168.8.190192.168.82.252tcp:d=2353d=7200ack-577334120SEQ=1803107 192.168.82.252192.168.8.190tcp:d=7200s=2353ack-1809294010wins=63260 |
分析捕獲的傳奇數(shù)據(jù)報文，發(fā)現(xiàn)傳奇游戲使用的是TCP/IP協(xié)議，服務(wù)器端口為7200，數(shù)據(jù)包很小，發(fā)送為100bit左右，收為60bit左右，而且我們發(fā)現(xiàn)它發(fā)的數(shù)據(jù)包一旦丟失就會重傳，我們分析這就是導致玩?zhèn)髌嫠俣嚷闹匾颉?/p>
我們知道，大部分流媒體數(shù)據(jù)報文是基于UDP協(xié)議的數(shù)據(jù)包，它不需重傳，對網(wǎng)絡(luò)傳輸精度要求不是特別嚴格，只是保證它的帶寬等如視頻點播等即可。在A、B兩個網(wǎng)絡(luò)的廣域網(wǎng)傳輸中包含各種協(xié)議的不同大小的數(shù)據(jù)流，因此在網(wǎng)絡(luò)傳輸中，數(shù)據(jù)包一旦發(fā)生碰撞或擁塞，基于TCP的數(shù)據(jù)量小的傳奇數(shù)據(jù)包由于比較小而沒有優(yōu)勢容易被其它大包堵塞而丟失，必須重傳。所以我們的傳奇數(shù)據(jù)包在傳輸中沒有優(yōu)勢，這就是傳奇游戲速度慢的根本原因。
故障解決
通過以上網(wǎng)絡(luò)測試和分析得到了故障的主要原因，但是完全依賴拓寬路由器之間的廣域網(wǎng)是不現(xiàn)實的，因此本次故障需從其它方面入手解決。
能不能讓傳奇報文優(yōu)先發(fā)送和接受呢？于是我們咨詢了位于A、B網(wǎng)絡(luò)之間的核心路由器廠家并得到了他們的大力支持，結(jié)果是肯定的。我們通過對路由器的軟件升級，利用A、B兩個網(wǎng)絡(luò)之間的兩個路由器高品質(zhì)的QOS對通往傳奇服務(wù)器的數(shù)據(jù)流進行優(yōu)先傳輸考慮，做了一個訪問控制列表，啟動系統(tǒng)的限速功能，提高傳奇服務(wù)器數(shù)據(jù)流的優(yōu)先權(quán)，問題得到解決。
具體設(shè)置如下：
ipmultipathmodepacket priority-list10protocoliphighlist100 rate-limitenable access-list100permitip192.168.8.190/32any interfaceserial2/0:0（至serial2/0:0） priority-group10 |
總結(jié)
網(wǎng)絡(luò)問題和網(wǎng)絡(luò)故障在網(wǎng)絡(luò)應(yīng)用中隨著網(wǎng)絡(luò)結(jié)構(gòu)、網(wǎng)絡(luò)技術(shù)、網(wǎng)絡(luò)容量的變化，會不斷出現(xiàn)一些新的問題，但是不管怎么變，它都有自己的特點，只要我們認真分析各個方面，總會找到解決辦法的。
