專利名稱：一種發現互聯網性能測量系統中的探針故障的方法
技術領域：
本發明涉及互聯網技術領域，特別涉及一種發現互聯網性能測量系統中的探針故障的方法。
背景技術：
互聯網是目前信息網絡重要基礎設施之一，然而互聯網的端到端性能問題一直是網絡管理者的一大難題。隨著hternet技術和網絡業務的飛速發展，用戶對網絡資源的需求空前增長，網絡也變得越來越復雜。不斷增加的網絡用戶和應用，導致網絡負擔沉重，網絡設備超負荷運轉，從而引起網絡性能下降。這就需要對網絡的性能指標進行提取與分析，對網絡性能進行改善和提高。因此網絡性能測量便應運而生。發現網絡瓶頸，優化網絡配置，并進一步發現網絡中可能存在的潛在危險，更加有效地進行網絡性能管理，提供網絡服務質量的驗證和控制，對服務提供商的服務質量指標進行量化、比較和驗證，是網絡性能測量的主要目的。互聯網是一種分組化的網絡，以TCP/IP技術為基礎，在網絡層上對數據報文進行逐跳的尋址與轉發。由于每一跳的網絡節點只負責本節點的數據轉發，節點之間彼此相互獨立，而當前的網絡管理系統都是以單個節點為管理對象，因此網絡管理者很難獲得網絡性能的全貌。在這種背景下，需要網絡測量系統以互聯網用戶的身份將網絡作為黑盒來對網絡性能進行主動測量。在國際上進行網絡主動測量研究的項目很多，如IEPM、NIMI、NLANRAMP、Surveyor 等，其中 IETF 所開發的 TWAMP (Two Way Active Measurement Protocol)協議(RFC5;357) 是其中比較有影響的方法之一。TffAMP協議基于端到端的測量方式，即測量實體都是主機，網絡設備不參與測量。 TffAMP包括了兩個相互獨立的協議· TffAMP-Control 用于建立測量會話，協商會話的參數(如包長、起始時間、中止時間、發包的分布參數等)，開始、終止測量會話，以及獲取測量結果(采用TCP協議)；· TffAMP-Test 規定了測量報文的格式等，用于在測量節點間進行測量報文的交互(采用UDP協議)。為了提高其開放性，TffAMP采用了控制協議與測量協議分離的思想，也就是說實際的TWAMP系統的控制協議不一定采用TWAMP-Contro 1，但底層的測量協議要采用 TWAMP-Test，這樣可以既保證了測量過程的互通性，又使得采用不同控制協議的測量節點都可以參與到測量中來，體現了測量的開放性。TWAMP協議包括五個功能實體· Session-Sender =TffAMP-Test會話中發送測量報文的測量節點；· Session-Receiver =TffAMP-Test會話中接收測量報文的測量節點；· Server 一個服務器，管理著一個或多個TWAMPIest會話，可以在每個測量節點上為每個TWAMP-Test會話進行配置，可以返回每個TWAMP-Test會話的測量結果；
· Control-Client 一個主機，用于發起建立TWAMP-kst會話的請求，以及控制會話的開始和終止；· Fetch-Client 一個主機，用于發起獲取TWAMPIest會話測量結果的請求；五個功能實體間的關系如圖1所示TWAMP協議首先假定參加測量的節點Gessionlendei^nkssion-Receiver)在不同控制者的控制之下，Session-Sender 由 Control-Client 控制，Session-Receiver 由 Server 控制，因此 Session-Sender 與 Control-Client 之間，以及 Session-Receiver 與 Server之間可以是控制者自己定義的控制協議，但Control-Client與krver之間，以及 Fetch-Client與krver之間可以使用公開的TWAMP-Control協議，這樣就使得在不同控制者的主機之間進行網絡性能測量，并通過一個開放接口獲取數據成為可能。目前一些研究機構，如Aveiro大學，已經對TWAMP協議系統進行了實現，在他們的系統中，圖中未定協議也采用了 TWAMP-Control協議。TffAMP協議由于基于端到端的測量方式，采用普通UDP報文，因此測量過程不易被感知和監測，能夠反映用戶的真實業務情況；同時在設計時就考慮了安全問題，協議內容包括了 Client與krver間以及knder與Receiver間的認證與加密機制；另外TWAMP還支持小包測量，不加密時最小報文達到42字節，加密時為60字節。但TWAMP協議也存在一些缺點，首先測量結果反映的是只是網絡邊緣主機間的性能，不利于網絡的Troubleshooting ； 其次，協議本身具有很大的開放性，一方面使協議的適應性增強，另一方面也引入了安全問題，如中間人攻擊等。因此，綜上所述，TWAMP協議是一個比較適合由用戶進行的網絡性能測量協議。TWAMP本身只是一個探針與探針、探針與服務器之間對于測量類型、測量控制參數的通信協議，如果將TWAMP協議用于實際的測量系統，必然要考慮整個系統的可靠性和可用性，需要實時判斷探針的狀態是否正常，如果出現故障，還要判斷故障是發生在探針節點上還是發生在網絡之中，以對測試結果進行正確的處理。目前，通過網絡搜索發現，仍沒有相關機構或個人提出類似思路在支持TWAMP協議的互聯網性能測量系統中實現服務器對探針的故障發現機制。
發明內容
本發明的目的是在TWAMP協議系統之上，在控制服務器與探針Gession-knder 和Session-Receiver)建立一種發現故障的方法，使得整套系統能夠實現對探針工作狀態的判斷。為實現上述目的，本發明采用以下技術方案一種發現互聯網性能測量系統中的探針故障的方法，所述互聯網性能測量系統基于TWAMP協議的系統，包括，在探針向服務器注冊成功后，由服務器建立第一內存表和第二內存表，所述第一內存表用于保存探針發送來的實時信息和接收到所述實時信息的時間， 所述第二內存表用于保存已注冊的探針的信息記錄；還具體包括步驟10 設置未連接次數為0，清空所述第二內存表；步驟20 服務器接收探針發送來的實時信息，并在所述第一內存表保存該實時信息和接收到所述實時信息的時間，在所述第二內存表保存已注冊的探針的信息記錄，包括
5探針的名稱、IP地址和網管地址信息；步驟30 從所述第二內存表中讀取一條信息記錄；步驟40 將所述信息記錄與所述第一內存表中的實時信息匹配，如能夠匹配，則證明在超時時間內收到了探針的實時信息，轉至步驟50;若不能匹配，則證明在超時時間內未收到探針的實時信息，轉至步驟70 ；步驟50 修改探針活動狀態為“正常”；步驟60 設置探針的未連接次數為0，刪除所述第一內存表中的數據，并轉至步驟 30 ；步驟70 修改探針活動狀態為“故障”；步驟80 設置探針的未連接次數+1，刪除所述第一內存表中的數據；步驟90 判斷未連接次數是否大于3，若否，則轉至步驟30 ；若是，則判定被檢測的探針出現故障。進一步地，所述步驟2中的服務器接收探針發送來的實時信息，并在所述第一內存表保存該實時信息和接收到所述實時信息的時間，，具體包括步驟21 從內存中讀取服務器的IP地址、keepalive定時時間間隔信息；步驟22 :設定調度器每隔所述ke印al ive定時時間間隔便向服務器發送 keepalive 數據包；步驟23 接收ke印alive數據包，并在所述第一內存表保存ke印alive數據包中的信息和接收到ke印alive數據包的時間。進一步地，在所述步驟22之后還包括步驟221 創建ke印alive報告的UDP端口 ；步驟222 封裝ke印alive數據包，根據已定義的ke印alive報文，填入相應信息；步驟223 發送ke印alive數據包，通過條用發送函數將ke印alive數據包通過 UDP發送給服務器；步驟2 關閉所述UDP端口。進一步地，將所述keepalive數據包的報文各字段含義分別設定為報文長度、報文類型和探針名稱。進一步地，在判定被檢測的探針出現故障后，還包括步驟110 從所述第二內存表中讀取需檢測的探針的IP地址和網關IP地址；步驟120 對步驟110中讀取的IP地址進行ping測試，確定是否能夠ping通，若是，則轉至步驟130 ；若否，則轉至步驟150 ；步驟130 判定探針的故障類型為“軟件故障”；步驟140 設置探針的未連接次數為0，刪除所述第一內存表中的數據，轉至步驟 180 ；步驟150 對探針的網關IP地址進行ping測試，確定是否能夠ping通，若是，則轉至步驟160 ；若否，則轉至步驟170 ；步驟160 判定探針的故障類型為“主機故障”，并轉至步驟180 ；步驟170 判定探針的故障類型為“網絡故障”，并轉至步驟180 ；步驟180 將探針的故障類型寫入日志。
進一步地，所述步驟110具體包括步驟111 從所述第二內存表中讀取需檢測的探針的IP地址；步驟112 判斷所述第二內存表中是否含有與步驟111中所述的IP地址相應的網關IP地址，若有，則轉至步驟114 ；若否，則轉至步驟113 ；步驟113 從數據庫探針基本信息表中讀取與步驟111中所述的IP地址相應的探針信息，并添加至所述第二內存表，并轉至步驟111 ；步驟114 從所述第二內存表中讀取需檢測的探針的網關IP地址。本發明在實現TWAMP協議的探針與服務器上增加狀態維護與故障發現的方法，在探針向服務器注冊之后，定期向服務器報發送Ke印alive信息，當Ke印alive超時后，服務器將發起對探針狀態的探測，判斷探針是否處于故障狀態。
圖1為現有技術中TWAMP協議功能實體的關系示意圖；圖2為本發明的探針端注冊流程示意圖；圖3為本發明的探針注冊請求報文格式示意圖；圖4為本發明的探針端Ke印alive處理流程示意圖；圖5為本發明的Ke印alive報文格式示意圖；圖6為本發明的創建監聽的進程和內存表示意圖；圖7為本發明的探針狀態判斷流程示意圖；圖8為本發明的探針故障檢測過程示意圖。
具體實施例方式為了使本發明的目的、技術方案及優點更加清楚，下面結合附圖及實施例，對本發明進行進一步詳細說明。此處所描述的具體實施例僅用以解釋本發明，但并不用于限定本發明。本發明中的探針故障發現包括探針和服務器兩方面的處理流程。在探針端，首先需要由管理人員將注冊信息寫入探針端本地文件，在探針啟動后， 自動啟動注冊流程，將故障發現所需信息發送至服務器端。如圖2所示，處理流程包括以下步驟步驟10，創建注冊所使用的TCP Socket。步驟20，通過該TCP Socket向服務器端發送連接請求。步驟30，連接請求接受后，根據注冊信息文件生成注冊報文，向服務器端發送注冊請求。步驟40，接收并讀取服務器端返回的注冊回復報文。步驟50，調用公共模塊關閉連接。步驟60，根據步驟40中讀到的注冊回復報文，取出其中的Ac^pt字段，此字段代表注冊是否成功。根據Accept值返回本次注冊結果。如圖3所示，探針注冊請求報文如下 報文長度4字節。 報文類型2字節，1代表探針注冊命令，2代表定時在線命令。
探針能力4字節，32bit0 探針名稱32字節，用戶為探針所配置的名稱。 密碼32字節，用戶為探針所配置的注冊密碼。 探針IP地址256字節，探針的IP地址。 探針網關IP地址256字節，探針的網關地址。在探針成功注冊之后，將啟動Keepal ive線程，定期維護服務器上的探針狀態。如圖4所示，探針端Ke印alive線程的處理流程如下步驟10，讀ke印alive相關信息，需要從內存中讀取出控制服務器的IP地址、 keepalive定時時間間隔等信息。步驟20，設定timer時間為配置時間間隔，通過固定時間調用Ke印alive發送代碼，達到報到在線狀態的目的。當定時時間到時便會自動開啟線程處理轉至步驟21處處理。步驟21，創建 Ke印alive 報告的 UDP Socket。步驟22，封裝Ke印alive數據包，根據已定義的Ke印alive報文，填入相應信息。步驟23，發送Ke印al ive數據包，通過調用發送函數將數據報通過UDP端口發送給控制服務器。步驟24，關閉 Ke印alive UDP Socket。探針端發送ke印alive數據包使用UDP端口。如圖5所示，Keepalive報文各字段含義如下 報文長度4字節。 報文類型2字節，2代表定時在線命令，1代表探針注冊命令。 探針名稱32字節，用戶為探針所配置的名稱。如圖6所示，服務器的處理流程包括以下步驟步驟110-120 服務器接受探針注冊請求，并啟動探針信息處理線程；步驟121-123 服務器對接收到的探針注冊請求信息與數據庫內的信息進行匹配；步驟124 將探針注冊信息中的IP地址，網關地址等關鍵信息保存到數據庫相應位置；步驟125-126 向探針發送注冊回復報文，并關閉連接。服務器在啟動UDP偵聽端口時就初始化探針的掃描進程，通過控制服務器參數文件中讀出掃描探針狀態時間，每隔掃描狀態間隔時間掃描一次，并作出相應的探針狀態判斷。服務器建立一個專門的內存表1，若收到探針的ke印alive信息，則將探針名稱和控制服務器接收到keepalive信息的時間保存到控制服務器端內存表中，同時建立一個內存表2為“探針名-IP地址”的哈希數據結構。如圖7所示，進行探針狀態判斷的流程如下 步驟10 判斷開始，置探針未連接次數為0，清空內存表2 ； 步驟20 根據已注冊探針信息建立內存表2，其中保存了探針名稱和IP地址、網關地址信息； 步驟30 從內存表2中取一條探針記錄；
步驟40 將該記錄與內存表1中探針名匹配，若能夠匹配，則證明在超時時間內收到了探針的ke印alive信息，轉到步驟50，修改探針狀態為正常，并返回步驟30，取下一條探針記錄；若不能匹配，則證明在超時時間內未收到探針的keepalive信息，轉到步驟 70 ； 步驟70 修改探針狀態為“故障”； 步驟80 該探針未連接次數加1，刪除內存表1中該探針條目； 步驟90 判斷未連接次數是否大于3，若未大于3，則等待ke印alive超時時間后，返回步驟40進行判斷；若大于3，則開啟探針故障判斷線程。探針故障判斷流程是為了判斷探針故障的類型，包括探針軟件故障、探針主機故障和探針網絡故障三種情況。如圖8所示，判斷流程如下 步驟110 從內存表2中讀取需探測探針IP地址； 步驟120 判斷表2中是否含有探針、網關IP，若沒有，重新從數據庫中讀取相應 fn息； 步驟140 讀取內存表2中探針IP地址； 步驟150 對探針IP地址進行ping測試，若探針可以ping通，證明探針主機本身無故障，網絡無故障，服務器未收到keepalive消息應該是由于探針軟件故障所致，因此清除內存表1中與該探針相關信息，并在日志中寫入探針“軟件故障”；若探針無法Ping通， 進入步驟180，進行進一步故障判斷； 步驟180 :ping探針網關IP地址，若可以ping通，則證明網絡無故障，而探針主機出現故障，在日志中進行注明；若無法Ping通，證明連接探針的網絡出現故障，在日志中應注明“網絡故障”。通過以上步驟，可以將探針所有可能故障形式進行完整判斷，從而使網絡性能測量系統能夠準確反映網絡的情況。以上所述僅為本發明的較佳實施例，并非用來限定本發明的實施范圍；如果不脫離本發明的精神和范圍，對本發明進行修改或者等同替換，均應涵蓋在本發明權利要求的保護范圍當中。
權利要求
1.一種發現互聯網性能測量系統中的探針故障的方法，所述互聯網性能測量系統基于 TWAMP協議的系統，其特征在于，包括，在探針向服務器注冊成功后，由服務器建立第一內存表和第二內存表，所述第一內存表用于保存探針發送來的實時信息和接收到所述實時信息的時間，所述第二內存表用于保存已注冊的探針的信息記錄；還具體包括步驟10 設置未連接次數為0，清空所述第二內存表；步驟20 服務器接收探針發送來的實時信息，并在所述第一內存表保存該實時信息和接收到所述實時信息的時間，在所述第二內存表保存已注冊的探針的信息記錄，包括探針的名稱、IP地址和網管地址信息；步驟30 從所述第二內存表中讀取一條信息記錄；步驟40:將所述信息記錄與所述第一內存表中的實時信息匹配，如能夠匹配，則證明在超時時間內收到了探針的實時信息，轉至步驟50;若不能匹配，則證明在超時時間內未收到探針的實時信息，轉至步驟70 ；步驟50 修改探針活動狀態為“正常”；步驟60 設置探針的未連接次數為0，刪除所述第一內存表中的數據，并轉至步驟30 ； 步驟70 修改探針活動狀態為“故障”；步驟80 設置探針的未連接次數+1，刪除所述第一內存表中的數據； 步驟90 判斷未連接次數是否大于3，若否，則轉至步驟30 ；若是，則判定被檢測的探針出現故障。
2.根據權利要求1所述的方法，其特征在于，所述步驟2中的服務器接收探針發送來的實時信息，并在所述第一內存表保存該實時信息和接收到所述實時信息的時間，，具體包括步驟21 從內存中讀取服務器的IP地址、ke印alive定時時間間隔信息； 步驟22 設定調度器每隔所述ke印alive定時時間間隔便向服務器發送ke印alive數據包；步驟23 接收ke印alive數據包，并在所述第一內存表保存ke印alive數據包中的信息和接收到ke印alive數據包的時間。
3.根據權利要求2所述的方法，其特征在于，在所述步驟22之后還包括 步驟221 創建ke印alive報告的UDP端口 ；步驟222 封裝ke印alive數據包，根據已定義的ke印alive報文，填入相應信息； 步驟223 發送ke印alive數據包，通過條用發送函數將ke印alive數據包通過UDP發送給服務器；步驟224 關閉所述UDP端口。
4.根據權利要求2或3所述的方法，其特征在于，將所述keepalive數據包的報文各字段含義分別設定為報文長度、報文類型和探針名稱。
5.根據權利要求1所述的方法，其特征在于，在判定被檢測的探針出現故障后，還包括步驟110 從所述第二內存表中讀取需檢測的探針的IP地址和網關IP地址； 步驟120 對步驟110中讀取的IP地址進行Ping測試，確定是否能夠ping通，若是， 則轉至步驟130 ；若否，則轉至步驟150 ；步驟130 判定探針的故障類型為“軟件故障”；步驟140 設置探針的未連接次數為0，刪除所述第一內存表中的數據，轉至步驟180 ； 步驟150 對探針的網關IP地址進行ping測試，確定是否能夠ping通，若是，則轉至步驟160 ；若否，則轉至步驟170 ；步驟160 判定探針的故障類型為“主機故障”，并轉至步驟180 ； 步驟170 判定探針的故障類型為“網絡故障”，并轉至步驟180 ； 步驟180 將探針的故障類型寫入日志。
6.根據權利要求4所述的方法，其特征在于，所述步驟110具體包括 步驟111 從所述第二內存表中讀取需檢測的探針的IP地址； 步驟112 判斷所述第二內存表中是否含有與步驟111中所述的IP地址相應的網關IP 地址，若有，則轉至步驟114 ；若否，則轉至步驟113 ；步驟113 從數據庫探針基本信息表中讀取與步驟111中所述的IP地址相應的探針信息，并添加至所述第二內存表，并轉至步驟111 ；步驟114 從所述第二內存表中讀取需檢測的探針的網關IP地址。
全文摘要
本發明公開了一種發現互聯網性能測量系統中的探針故障的方法。本發明的目的是在TWAMP協議系統之上，在控制服務器與探針(Session-Sender和Session-Receiver)建立一種發現故障的方法，使得整套系統能夠實現對探針工作狀態的判斷。本發明在實現TWAMP協議的探針與服務器上增加狀態維護與故障發現的方法，在探針向服務器注冊之后，定期向服務器報發送Keepalive信息，當Keepalive超時后，服務器將發起對探針狀態的探測，判斷探針是否處于故障狀態。
文檔編號H04L29/08GK102307119SQ20111023844
公開日2012年1月4日 申請日期2011年8月18日 優先權日2011年8月18日
發明者何寶宏, 劉述, 唐浩, 張恒升, 徐貴寶, 馬科, 高巍 申請人:工業和信息化部電信傳輸研究所