基于流量監測的通信網故障分析技術研究

侯 浩，李偉娜，朱小朋，劉 丹

（西安衛星測控中心，陜西 西安 710043）

0 引 言

傳統的網絡性能評估指標[1]主要是IETF IPPM工作組定義的IP網絡性能指標，包括：連通性、吞吐量、帶寬、時延、時延抖動和丟包率等，常見的指標數據采集手段包括：基于ICMP協議的ping命令測試，可以得到連通性、時延、丟包率等指標數據；利用網絡設備支持的SNMP MIB庫可得到連通性、吞吐量、帶寬等指標數據；利用網絡測試儀可得到網絡鏈路的連通性、帶寬、丟包率、時延、抖動等指標數據。但是，上述性能測量方法缺少對特定業務場景流量特點的具體分析，性能評估的粒度粗，對實際業務傳輸質量進行評估時的指導性較弱[2]。

本文從網絡流量特點出發，提取面向業務流的網絡性能評估指標，采用關鍵節點設備的鏡像監測網絡流量，通過協議分析對業務流各指標項進行監測，進而實現通信網絡中常見的UDP分片數據丟包、TCP高速數據速率下降等故障場景的監測告警[3]。

1 通信網絡流量基線要素分析

1.1 企業通信網流量特點

目前，企業對網絡的穩定性、時延、抖動等各項指標要求都比較高，特別是對于一些十分重要的業務，網絡實時性、安全性顯得十分重要且特別突出。根據企業網絡運行的狀況和業務數據，目前，大部分企業的網絡流量多為基于UDP的業務和基于TCP的文件傳輸類型業務。基于UDP和TCP的業務，根據其工作原理和收發數據的機制來看，其網絡流量類型都會表現出較強的規律性，使我們有章可循，能夠通過發現內在規律判斷網絡的實時運行狀況。目前，由于市場上企業類型的不同，網絡要求也不同，企業通信網絡流量監測的監視點、數據流顆粒度、業務測試內容和應用要求等方面關注點差異比較大，常規的網絡性能評估指標對企業業務數據而言顆粒度過粗，如何精確、精細識別，需要我們一步研究[4]。

通過查詢文獻，邵國林等人研究提出了基于統計的流量結構的定義以及流量結構穩定性的相關描述，值得借鑒流量結構一定期間網絡流量各屬性值的大小、規模、分布及變化的綜合狀態，說明網絡流量在特定時間內的統計特性和綜合表現情況。流量和結構主要包括兩層含義：各流量屬性以及各屬性的構成關系，對特定時間窗口內的流量統計屬性進行描述，綜合各屬性值以及各屬性在系統中的構成（所占比重）。流量結構穩定性，是對于一定時期網絡流量結構的變動程度的刻畫，表現了網絡流量層面的穩定情況。該思路為我們提供了解決問題的辦法[5]。

本文通過分析企業通信網絡內業務的白名單，并利用基于時間序列的流量統計方法，對通信網內業務通信流量進行抓包監測，可發現其網絡流量具有流量結構穩定性的屬性，具體表現為數據包的包長分布、平均速率、TTL分布、端口分布、協議分布等方面，可據此構建網絡基線[6]。

1.2 網絡流量基線要素分析

網絡基線包含來自不同終端設備的流量樣本及統計屬性，梳理網絡流量白名單，構建網絡流量基線，進而獲得網絡上每個設備節點的整體流量快照，在網絡或設備工作不正常時作為比較的基準，成為監測網絡故障的重要支撐數據[7]。

（1）使用的協議

在出口路由器上捕獲網段所有設備的流量，對照流量白名單，分析是否缺少本應出現的協議，或者網絡上是否出現了新的協議，從而發現高于正常數量的特定類型的流量。

（2）身份驗證序列

各類應用程序的協議交互中，通常包括任意客戶端到所有服務的身份驗證過程的流量，比如Web應用程序、C/S消息交互軟件，身份驗證過程中通常包括豐富的通信參數協商信息，可用于協助定位該驗證過程是否是通信緩慢的原因。

（3）數據傳輸率

在網絡節點位置測量發送/接收的業務傳輸流量數據，確定傳輸速率和連接的一致性，每當在網段上建立或拆除連接速度很慢時，可以運行與基線同樣的數據并比較結果，用于協助定位通信緩慢的原因。

（4）關聯/依賴關系

通過特定場景的流量捕獲構建網絡基線，梳理各終端的業務關聯/依賴關系，以及同一業務流上不同數據包的關聯關系，利用關聯關系基線協助定位終端引起的網絡性能問題[8]。

2 面向業務層傳輸性能監測指標體系

2.1 網絡性能指標體系構建

2.1.1 基于五元組的業務流描述

TCP和UDP流的定義可用如下定義進行描述。

定義1 擁有相同的四元組（源地址、目的地址、源端口、目的端口）的一系列在一定超時時間內（Ns）連續到達的TCP數據包，或以建立連接、斷開連接為標記的區間時段內，稱為一個TCP流。

定義2 在兩個終端之間且擁有相同端口號的一系列在一定超時時間內（Ns）連續到達的UDP數據包，或以應用層開始、結束字段為標志的區間時段內，稱為一個UDP流。

根據網絡的業務傳輸特性，TCP流可以取建立連接、斷開連接為標記的區間時段內的TCP數據包，UDP流可以取應用層開始、結束字段為標志的區間時段內的UDP數據包，基于五元組（源地址、目的地址、源端口、目的端口、協議）對不同的業務流進行分析[9]。

2.1.2 基于特定業務場景的流量性能評估指標分析

根據協議交互流程，按照TCP和UDP協議，可提取出如下指標，具體見表1～表3所列。

表1 UDP業務流中采集的指標

表2 TCP三次握手采集的指標

表3 TCP業務數據交互采集的指標

2.2 基于性能監測指標的故障分析

2.2.1 基于UDP協議的業務流丟包或丟失數據包分片算法

（1）算法概述

從UDP數據包中提取標識符（Identification）、標識（Flags）和分片偏移（Fragment Offset）。

（a）對于未分片的UDP數據包

比較同一網絡路徑上不同節點位置的抓包進行比較分析，判斷同一標識符（Identification）是否均按預期路由出現，進而判斷是否丟包。

在應用層數據字段中，存在用于標識數據包序號的字段，該字段值為遞增取值，此種情況下，可通過同一節點位置的抓包數據進行該流前后數據包的對比，進而判斷是否丟包。

（b）對于分片的UDP數據包

可采集標識（Flags），若為分片字段，則判斷分片偏移（Fragment Offset）是否連續，進而判斷是否丟失數據包分片。

（2）輸入

接入設備入口、出口抓包流量；業務及鏈路已知參數：鏈路流量監管限速參數CIR、PIR、CBS（或令牌桶經驗值），業務流參數源地址、目的地址、目的端口號、協議等。

（3）輸出

通過分析，定位丟包的位置（時間，id，off），判斷丟包的原因，歸納為以下3種：

①突發流量丟包：通過流量監管的限速參數CIR、PIR、CBS判定是否發生突發流量；

②設備已知缺陷：觸發高危端口封控策略丟包；

③隨機丟包：列出丟失IP數據包，進行人工分析。

（4）模型描述

①根據業務及鏈路約束參數（源地址、目的地址、目的端口號、協議；監管限速參數CIR、PIR、CBS）輸入，提取UDP業務流Flow（time，id，off）信息。

②利用time和id修訂兩條UDP業務流Flow1和Flow2的抓包時間，time為抓包終端的時間；由于id最大值為65 535，因此同一條業務流在不同時間段存在id相同的情況，因此需要time和id兩個參數來定位特定IP數據包。

③對比兩條業務流的IP數據包id，判斷Flow1（id，time）∈Flow2（id，time），若不成立，則說明存在丟包，轉入⑤。

④對于分片數據包，判斷 Flow1（id，，time，off）∈Flow2（id，time，off），若不成立，則說明有丟失分片，通過時間time、標示符id、偏移off判斷IP數據包分片丟失發生的時間范圍以及具體的數據包，轉入⑤。

⑤判斷是否為突發流量超過流量監管引發的丟包，若短時間（如20 ms）丟失多個分片，初步分析為突發流量丟包，可通過流量監管的限速參數CIR、PIR、CBS進一步判定是否發生突發流量，結束分析。

⑥判斷是否為設備已知缺陷：觸發高危端口封控策略丟包，若丟失的為IP分片包且第37、38字節與高危端口值相同，則為設備已知缺陷引發的丟包，否則轉入⑦。

⑦判斷為隨機丟包，列出丟失IP數據包，進行人工分析。

UDP丟包問題分析算法流程如圖1所示。

圖1 UDP丟包問題分析算法流程

2.2.2 基于TCP協議的業務流降速算法

（1）算法概述

從TCP三次握手環節以及業務數據過程中可采集業務流相關性能指標，監測各指標值，與基準取值范圍進行比較，分析線路側、客戶端、服務端引發故障的可能性。

（a）線路延遲導致降速故障監測

分析關聯包時間間隔中的服務端發包間隔A（接收客戶端SYN和發送SYN/ACK的時間間隔），當服務端收到客戶端SYN數據包時，由于不涉及任何傳輸層以上的處理，因此發送一個響應只需要非常小的處理量。即使服務器正承受巨大的流量負載，通常也會迅速向SYN數據包響應一個SYN/ACK。這排除了服務器導致高延遲的可能性。因此基本可推斷，延遲是因為線路中的一些設備出了問題。

往返時間（未啟用延時確認情況下），若干秒內持續超過基準值，基本可推斷線路或客戶端存在問題；結合ICMP包采集往返時間（啟用延時確認情況下），若干秒內持續超過基準值，基本可推斷線路或客戶端存在問題。

（b）客戶端故障導致降速故障監測

分析關聯包時間間隔中的服務端發包間隔A（接收客戶端SYN和發送SYN/ACK的時間間隔），當客戶端接收到三次握手的ACK后，應該很快就發送數據包，因為所有動作都是以客戶端為中心的。延遲超過基準值，表明客戶端無法及時執行該動作，基本可推斷延遲的根源在于客戶端自身[10]。

客戶端接收到服務端發送的重復ACK后，未及時發送對應數據包，基本可推斷客戶端存在問題；網絡未擁塞且服務端接收窗口足夠大時，客戶端仍未加大發送窗口時，基本可推斷客戶端存在問題。

（c）服務端故障導致降速故障監測

分析TCP業務數據交互過程中的接收窗口大小（服務端接收窗口*窗口擴大因子），當接收窗口若干秒內遠低于基準取值范圍時，基本可推斷服務器端存在問題；若服務端可以同步抓包，通過分析服務端關聯數據包的發包間隔A，同樣可以判斷是否為服務器端的問題[11]。

（2）輸入

接入入口抓包流量；出口抓包流量；業務及鏈路已知參數：鏈路流量監管限速參數CIR、PIR、CBS（或令牌桶經驗值），業務流參數源地址、目的地址、目的端口號、協議等[12]。

（3）輸出

通過服務器端重復的ACK確認數量以及客戶端發送的數據包id，統計丟包數量，通過分析定位丟包的位置（時間，id，off），判斷丟包的原因，歸納為以下4種：

①抓包區間，定位引發丟包的單點設備；

②傳輸層或服務器端網絡質量問題：與服務器端測試傳輸層鏈路質量，協調應用方協助定位丟包位置；

③客戶端數傳軟件存在問題：服務器端接口窗口正常，但客戶端仍未加大發送窗口時，基本可推斷客戶端數傳軟件存在問題；

④服務器端數傳軟件存在問題：網絡空閑但服務器端接收窗口若干秒內遠低于基準取值范圍時，或ACK確認不及時，基本可推斷服務器端存在問題。

（4）模型描述

①根據業務及鏈路約束參數（源地址、目的地址、目的端口號、協議；監管限速參數CIR、PIR、CBS）輸入，提取TCP業務流Flow（time，id）信息。

②若Flow1中，服務端發送的重復ACK超過閾值，初步判斷鏈路中存在丟包，轉入③。

③客戶端發送重復對應ACK數據包，則判定為客戶端軟件問題，結束判斷。

④若服務器端不再發送對應ACK，則判斷為網絡偶發丟包，若丟包次數未超過閾值，則為偶發丟包，轉入⑤，反之判斷為網絡頻發丟包，轉入⑦，繼續分析。

⑤判斷是否為網內存在丟包問題，若Flow1（id，time）∈Flow2（id，time）不成立，則為網內丟包，縮小測抓包區間，定位引發丟包的單點設備，否則轉入⑥。

⑥判斷為傳輸層鏈路存在丟包問題，協調應用中心協助定位丟包位置，結束分析。

⑦網絡質量問題，與應用方測試傳輸層鏈路質量，結束分析。

⑧判斷是否已降速：“數傳速率＜經驗值”且“鏈路利用率＜經驗值”，若重復ACK超過閾值，則轉入②；反之轉入網絡質量正常，初步判定數傳軟件功能故障，轉入⑨。

⑨判斷是否為客戶端數傳軟件存在問題：若服務器端反饋的接收窗口正常，但客戶端仍未加大發送窗口時，基本可推斷客戶端存在問題，結束分析，反之轉入⑩。

⑩判斷是否為服務器端數傳軟件存在問題：網絡空閑但服務器端接收窗口若干秒內遠低于基準取值范圍時，或ACK確認不及時，基本可推斷服務器端存在問題，協調應用中心進行進一步定位[13-15]。

TCP降速問題分析算法流程如圖2所示。

圖2 TCP降速問題分析算法流程

3 結 語

本文首先對網絡性能評估指標研究現狀進行闡述，結合網絡流量特點，構建面向業務層傳輸性能監測指標體系，以UDP業務流丟包、TCP業務流降速等常見故障為案例，實現故障監測機理分析與故障監測告警[16-17]。