孫峰等
摘 要: 提出一種基于深度包解析技術(shù)的Web信息系統(tǒng)性能監(jiān)測(cè)分析方法。首先,闡述方法實(shí)現(xiàn)的技術(shù)基礎(chǔ);其次,給出方法的具體實(shí)現(xiàn)步驟,涉及網(wǎng)絡(luò)傳輸時(shí)延、頁(yè)面訪問(wèn)時(shí)延、系統(tǒng)健康度等指標(biāo);最后,在某電力企業(yè)門(mén)戶系統(tǒng)中對(duì)上述方法進(jìn)行驗(yàn)證。實(shí)踐表明,該性能監(jiān)測(cè)分析方法運(yùn)行穩(wěn)定、分析直觀,具有較好的實(shí)用性與市場(chǎng)價(jià)值。
關(guān)鍵詞: 深度包解析; 性能監(jiān)測(cè); 訪問(wèn)時(shí)延; 系統(tǒng)健康度
中圖分類號(hào): TN06?34 文獻(xiàn)標(biāo)識(shí)碼: A 文章編號(hào): 1004?373X(2015)21?0118?05
Analysis method of performance monitoring for information
system based on deep packet inspection
SUN Feng1, CHEN Yuhui1, LIU Jiahua1, CHEN Long1, CAI Guangchen2
(1. NARI Group Corporation/ State Grid Electric Power Research Institute, Nanjing 210000, China;
2. Pactera Technology International Ltd., Nanjing 210000, China)
Abstract: An analysis method of performance monitoring for Web information system based on deep packet inspection is proposed. The technology foundation for implementing this method is explained. The specific realization steps of this method are proposed, which involves the indicators of network transmission delay, page access delay and system health?degree. The proposed method was verified in a certain power enterprise portal system. The practice results show that this analysis method of performance monitoring can operate stably and analyze intuitively, and has good practicability and market value.
Keywords: deep packet inspection; performance monitoring; access delay; system health?degree
信息系統(tǒng)正逐漸成為支撐大型企事業(yè)單位生產(chǎn)的必要工具,而信息系統(tǒng)性能優(yōu)劣已成為生產(chǎn)力的主要體現(xiàn)?;谏疃劝馕黾夹g(shù)的Web信息系統(tǒng)性能監(jiān)測(cè)分析方法,通過(guò)對(duì)用戶訪問(wèn)信息系統(tǒng)的真實(shí)鏡像數(shù)據(jù)進(jìn)行分析,提煉出系統(tǒng)使用過(guò)程中的網(wǎng)絡(luò)時(shí)延、業(yè)務(wù)處理時(shí)延等指標(biāo),從用戶視角描述系統(tǒng)性能,計(jì)算出系統(tǒng)健康度。相比于傳統(tǒng)的通過(guò)采集主機(jī)硬件、操作系統(tǒng)、中間件、數(shù)據(jù)庫(kù)等資源指標(biāo)來(lái)判斷系統(tǒng)性能狀況的技術(shù),該方法具有分析更準(zhǔn)確、直接、可有效降低運(yùn)維人員巡檢工作量等優(yōu)勢(shì)。
1 深度Web業(yè)務(wù)包解析基礎(chǔ)
相比于普通的數(shù)據(jù)包解析,深度包解析技術(shù)(DPI)在分析IP數(shù)據(jù)包源地址、目的地址、源端口、目的端口以及協(xié)議類型等包頭信息的基礎(chǔ)上,還增加了對(duì)應(yīng)用層單個(gè)數(shù)據(jù)包內(nèi)容的分析,并且能夠把分散的數(shù)據(jù)包重新組合成一個(gè)相關(guān)聯(lián)的數(shù)據(jù)流,通過(guò)對(duì)數(shù)據(jù)流的分析,提煉出用戶訪問(wèn)信息系統(tǒng)不同頁(yè)面、不同應(yīng)用的行為。業(yè)務(wù)數(shù)據(jù)包捕獲過(guò)濾與重組還原是該技術(shù)的基礎(chǔ)。
1.1 業(yè)務(wù)數(shù)據(jù)捕獲與過(guò)濾
采用旁路偵聽(tīng)的方式實(shí)現(xiàn)業(yè)務(wù)數(shù)據(jù)捕獲與過(guò)濾,優(yōu)點(diǎn)是對(duì)Web信息系統(tǒng)的正常運(yùn)行幾乎無(wú)影響,同時(shí)管理效果也很優(yōu)異。具體步驟是,首先配置交換機(jī),將Web信息系統(tǒng)所在交換機(jī)端口的數(shù)據(jù)復(fù)制到鏡像口;其次,使用網(wǎng)線連接鏡像口與監(jiān)控主機(jī);第三,在監(jiān)控主機(jī)部署數(shù)據(jù)包采集模塊。模塊采用免費(fèi)、公共的WinPcap(Windows Packet Capture)開(kāi)發(fā)包,它為Windows應(yīng)用程序提供了訪問(wèn)網(wǎng)絡(luò)底層數(shù)據(jù)的能力。WinPcap操作的核心流程如圖1所示。
其中,pcap_lookupdev()函數(shù):遍歷本地網(wǎng)卡設(shè)備,與鏡像口相連的本地網(wǎng)卡可作為數(shù)據(jù)操作網(wǎng)卡;
pcap_open_live()函數(shù):打開(kāi)選中的設(shè)備;
pcap_setfilter()函數(shù):設(shè)置過(guò)濾器,將過(guò)濾字符串設(shè)定成“tcp and server?ip and server?port”的形式,WinPcap提供的內(nèi)核級(jí)數(shù)據(jù)包過(guò)濾機(jī)制將準(zhǔn)確地捕獲訪問(wèn)業(yè)務(wù)信息系統(tǒng)的所有TCP數(shù)據(jù)包,如“tcp and host 101.144.100.242 and port 80”規(guī)則表示捕獲IP地址為101.144.100.242的服務(wù)器80端口所有的TCP數(shù)據(jù)包;
pcap_loop()函數(shù):使用回調(diào)函數(shù)循環(huán)捕獲網(wǎng)絡(luò)數(shù)據(jù),在函數(shù)中進(jìn)行數(shù)據(jù)包分析、數(shù)據(jù)包儲(chǔ)存等操作。
圖1 WinPcap捕獲過(guò)濾網(wǎng)絡(luò)數(shù)據(jù)包核心流程
1.2 數(shù)據(jù)包重組
1.2.1 TCP數(shù)據(jù)包重組
依據(jù)TCP/IP協(xié)議原理,TCP會(huì)話的每一端都包含1個(gè)序列號(hào)與確認(rèn)號(hào),分別用來(lái)跟蹤該端發(fā)送的數(shù)據(jù)量與接收的數(shù)據(jù)量。同一TCP會(huì)話中,同方向的一對(duì)數(shù)據(jù)包,前者的相對(duì)序列號(hào)seq值與包內(nèi)容長(zhǎng)度len值之和應(yīng)該等于后者的seq值;反方向的一對(duì)數(shù)據(jù)包,前者的seq值與len值之和,應(yīng)等于后者的相對(duì)確認(rèn)號(hào)ack值。
因此,依據(jù)seq,ack,len之間的關(guān)系,為同一TCP會(huì)話建立兩個(gè)數(shù)據(jù)包隊(duì)列,依次分別存入正常包序與異常包序的TCP報(bào)文。異常包序情況包括完全重復(fù)、部分重復(fù)、數(shù)據(jù)后發(fā)先到、len=0等。
待當(dāng)前TCP會(huì)話的全部報(bào)文收取完畢后,取出正常隊(duì)列中的最后一個(gè)TCP報(bào)文,根據(jù)其seq值與len值,在異常隊(duì)列中查找其后續(xù)報(bào)文,按去重原則將異常隊(duì)列數(shù)據(jù)包丟棄或者存入正常隊(duì)列。
例如,正常隊(duì)列最后一個(gè)TCP報(bào)文數(shù)據(jù)段第一字節(jié)的序號(hào)為seq=200,len=150,異常隊(duì)列取出的同向TCP報(bào)文數(shù)據(jù)段第一字節(jié)的序號(hào)為seq=300,len=160,則報(bào)文數(shù)據(jù)序號(hào)300~350區(qū)間是重復(fù)的,因此修改異常報(bào)文seq值為350,len值為110,將其存入正常報(bào)文隊(duì)列尾。
1.2.2 HTTP數(shù)據(jù)包重組
HTTP協(xié)議是基于TCP協(xié)議,在Web信息系統(tǒng)中使用最廣泛的一種通信協(xié)議,由終端瀏覽器向服務(wù)器發(fā)起請(qǐng)求,服務(wù)器反饋請(qǐng)求結(jié)果。
HTTP請(qǐng)求方法包括GET,HEAD,POST等,其中GET表示請(qǐng)求指定的Web文檔,POST表示請(qǐng)求Web服務(wù)器接收指定文檔。HTTP響應(yīng)包括HTTP連接狀態(tài)碼、響應(yīng)頭、響應(yīng)數(shù)據(jù)等信息。
HTTP包重組是對(duì)同一TCP會(huì)話中重組過(guò)的正常包序的TCP報(bào)文進(jìn)行分析,識(shí)別出HTTP請(qǐng)求頭與響應(yīng)包頭,根據(jù)響應(yīng)包頭中的Content?Length值或chunked信息,找出所有HTTP響應(yīng)數(shù)據(jù)報(bào)文。重組流程見(jiàn)圖2。
2 信息系統(tǒng)性能監(jiān)測(cè)分析方法實(shí)施步驟
基于深度包解析技術(shù)的Web信息系統(tǒng)性能監(jiān)測(cè)分析的目的在于,從原始網(wǎng)絡(luò)數(shù)據(jù)包中提煉出信息系統(tǒng)訪問(wèn)數(shù)據(jù)并展開(kāi)分析,其包括業(yè)務(wù)數(shù)據(jù)捕獲過(guò)濾、深度包解析與時(shí)延指標(biāo)獲取、系統(tǒng)性能健康度分析三大步驟,數(shù)據(jù)流向如圖3所示。
2.1 業(yè)務(wù)數(shù)據(jù)包存儲(chǔ)
本方法采用嵌套鏈表的方式保存、捕獲、過(guò)濾并經(jīng)重組還原的,所有TCP,HTTP業(yè)務(wù)數(shù)據(jù)包。
同一個(gè)Web信息系統(tǒng)會(huì)被多臺(tái)終端訪問(wèn),因此在IP層面,信息系統(tǒng)的IP與其訪問(wèn)終端IP是一對(duì)多的關(guān)系,為每一個(gè)訪問(wèn)終端的IP維護(hù)一張IP鏈表。
在端口層面,信息系統(tǒng)提供的服務(wù)端口一般固定不變,而訪問(wèn)終端所使用的端口卻是變化不定的,因此,信息系統(tǒng)的端口與訪問(wèn)終端的端口也是一對(duì)多的關(guān)系。在IP鏈表中,為每個(gè)訪問(wèn)Web信息系統(tǒng)的端口維護(hù)一張Port子鏈表。子鏈表中的每個(gè)節(jié)點(diǎn)保存該端口下所有經(jīng)重組提煉出的HTTP協(xié)議包,分為HTTP請(qǐng)求數(shù)據(jù)與響應(yīng)數(shù)據(jù)兩部分,后者可能含有若干TCP分片包,也可能只有一個(gè)TCP包。為方便后續(xù)分析,以Port子鏈表節(jié)點(diǎn)首個(gè)數(shù)據(jù)報(bào)文開(kāi)始時(shí)間先后為排序規(guī)則,為所有的Port子鏈表節(jié)點(diǎn)建立節(jié)點(diǎn)時(shí)間索引表,如圖4所示。
所有待分析的數(shù)據(jù)都保存在嵌套鏈表中,分析完畢后,從鏈表中刪除所有已分析的數(shù)據(jù)。信息系統(tǒng)訪問(wèn)量特別大時(shí),可以選擇將嵌套鏈表的數(shù)據(jù)定期存入實(shí)時(shí)數(shù)據(jù)庫(kù)或文件,由分析線程讀取數(shù)據(jù)庫(kù)或文件數(shù)據(jù)進(jìn)行指標(biāo)提煉,并刪除過(guò)期數(shù)據(jù)。
2.2 深度業(yè)務(wù)包解析與時(shí)延指標(biāo)獲取
信息系統(tǒng)訪問(wèn)整體時(shí)延=建立連接時(shí)延+網(wǎng)絡(luò)傳輸時(shí)延+系統(tǒng)響應(yīng)時(shí)延,對(duì)用戶而言,瀏覽器渲染時(shí)間也是影響體驗(yàn)的因素之一,這里暫不考慮。
2.2.1 連接建立時(shí)延與網(wǎng)絡(luò)傳輸時(shí)延
監(jiān)控模塊為每個(gè)收到的TCP數(shù)據(jù)包加上時(shí)間戳,對(duì)于每一次終端開(kāi)始訪問(wèn)Web信息系統(tǒng)前的TCP三次握手,認(rèn)定收到的第一個(gè)握手AYN包時(shí)間為[T1,]第二次握手SYN ACK包時(shí)間為[T2,]第三次握手時(shí)間為[T3,]如圖5所示。
定義[ΔT(1?2)=T2-T1,]則[ΔT(1?2)]表示服務(wù)器本身對(duì)TCP握手包響應(yīng)的處理時(shí)間,則該時(shí)間近乎為0,同理訪問(wèn)終端對(duì)SYN ACK包的響應(yīng)時(shí)間近乎為0。定義[ΔT(2?3)=T3-T2,]則[ΔT(2?3)]表示SYN ACK包與ACK包在網(wǎng)絡(luò)上傳輸?shù)臅r(shí)間。因此:
2.2.2 系統(tǒng)響應(yīng)時(shí)延
系統(tǒng)響應(yīng)時(shí)延=頁(yè)面訪問(wèn)結(jié)束時(shí)間-頁(yè)面訪問(wèn)開(kāi)始時(shí)間。而頁(yè)面開(kāi)始時(shí)間的判斷,是基于通過(guò)深度包解析建立的頁(yè)面專屬信息庫(kù)。
(1) 頁(yè)面專屬信息庫(kù)
本方法提出頁(yè)面指紋與頁(yè)面資源兩個(gè)概念。頁(yè)面指紋是指能把某個(gè)頁(yè)面與其他頁(yè)面區(qū)分開(kāi)的頁(yè)面信息組合。多數(shù)信息系統(tǒng)不同的頁(yè)面對(duì)應(yīng)不同的URL,因此URL信息可作為頁(yè)面的指紋,結(jié)合HTTP請(qǐng)求命令,該類型指紋定義形式為“請(qǐng)求方式+URL”。少數(shù)信息系統(tǒng)采用了flex等開(kāi)發(fā)技術(shù),不同頁(yè)面采用相同的URL,如此,就需要對(duì)這部分頁(yè)面的起始交互數(shù)據(jù)進(jìn)行深度數(shù)據(jù)包分析,提煉出能夠標(biāo)識(shí)頁(yè)面的數(shù)據(jù)信息,指紋定義形式為“請(qǐng)求方式+URL+內(nèi)容關(guān)鍵詞”。
頁(yè)面資源是指信息系統(tǒng)服務(wù)器反饋給訪問(wèn)終端的各頁(yè)面組成元素,如js資源、css資源、圖片資源、xml資源等。
為待分析的Web信息系統(tǒng)建立包含頁(yè)面指紋與頁(yè)面資源專屬信息庫(kù),是系統(tǒng)響應(yīng)時(shí)延分析的前提。信息庫(kù)格式如表1所示。
(2) 頁(yè)面響應(yīng)時(shí)間的計(jì)算
讀取每一個(gè)訪問(wèn)終端的IP父鏈表的時(shí)間索引表,順序找到各Port子鏈表的節(jié)點(diǎn),對(duì)節(jié)點(diǎn)HTTP請(qǐng)求部分的數(shù)據(jù)進(jìn)行頁(yè)面指紋信息匹配。如果找到頁(yè)面指紋信息,并且節(jié)點(diǎn)HTTP響應(yīng)碼為200OK等正確碼,則認(rèn)定該節(jié)點(diǎn)第一個(gè)數(shù)據(jù)報(bào)文的開(kāi)始時(shí)間為對(duì)應(yīng)頁(yè)面的開(kāi)始時(shí)間,若響應(yīng)碼為400,500等錯(cuò)誤碼,則判定頁(yè)面訪問(wèn)失敗。時(shí)間索引表與Port子鏈表的對(duì)應(yīng)關(guān)系如圖6所示。
為當(dāng)前訪問(wèn)終端IP的每個(gè)檢測(cè)到開(kāi)始的頁(yè)面建立一個(gè)隊(duì)列,從Port子鏈表刪除已經(jīng)匹配到頁(yè)面指紋的節(jié)點(diǎn),將其加入到對(duì)應(yīng)的新建的頁(yè)面隊(duì)列中,同一個(gè)IP終端,訪問(wèn)同一個(gè)頁(yè)面的隊(duì)列應(yīng)具有惟一性。
如果在同一IP父鏈表中,短時(shí)間內(nèi)連續(xù)識(shí)別出某些Port子鏈表節(jié)點(diǎn),它們均匹配到相同的頁(yè)面,則終端可能存在頁(yè)面刷新與重復(fù)打開(kāi)行為,此時(shí)應(yīng)以最后一個(gè)Port子鏈表節(jié)點(diǎn)的第一個(gè)數(shù)據(jù)報(bào)文的開(kāi)始時(shí)間作為頁(yè)面的開(kāi)始時(shí)間。
如果當(dāng)前Port子鏈表節(jié)點(diǎn)不屬于頁(yè)面開(kāi)始節(jié)點(diǎn),則提取出該節(jié)點(diǎn)HTTP請(qǐng)求部分的資源信息,判斷該資源是否屬于當(dāng)前正在分析中頁(yè)面的頁(yè)面資源。如果不是,則丟棄該節(jié)點(diǎn);如果是,將其從Port子鏈表刪除,加入對(duì)應(yīng)的頁(yè)面隊(duì)列,同時(shí)更新該頁(yè)面隊(duì)列最遲數(shù)據(jù)包的接收時(shí)間。
若某頁(yè)面隊(duì)列從最遲數(shù)據(jù)包接收時(shí)間開(kāi)始,超過(guò)頁(yè)面訪問(wèn)時(shí)間(一般為20 s),沒(méi)有新的Port子鏈表節(jié)點(diǎn)加入,則視最遲數(shù)據(jù)包接收時(shí)間為頁(yè)面結(jié)束時(shí)間。計(jì)算頁(yè)面結(jié)束時(shí)間與開(kāi)始時(shí)間的差值作為頁(yè)面響應(yīng)時(shí)間,同時(shí)刪除該頁(yè)面隊(duì)列。
2.3 Web信息系統(tǒng)性能健康度計(jì)算
信息系統(tǒng)的組成頁(yè)面是多樣性的,不同類型頁(yè)面的時(shí)延評(píng)價(jià)標(biāo)準(zhǔn)應(yīng)具有差異性,將頁(yè)面定義為3大類、13小類(如表2所示),由用戶根據(jù)自身需求為其分別定義標(biāo)準(zhǔn)響應(yīng)時(shí)長(zhǎng)。信息系統(tǒng)的性能健康度評(píng)價(jià)基于目標(biāo)系統(tǒng)是否有響應(yīng)、目標(biāo)系統(tǒng)響應(yīng)時(shí)間是否超過(guò)基線時(shí)間。
圖9 系統(tǒng)健康度與時(shí)延截圖
4 結(jié) 語(yǔ)
本文給出一種基于深度包解析技術(shù)的Web信息系統(tǒng)性能監(jiān)測(cè)分析方法,從用戶使用的角度對(duì)信息系統(tǒng)的性能狀況做出分析與評(píng)價(jià),該方法是信息系統(tǒng)性能監(jiān)測(cè)方式的一種有益的嘗試與創(chuàng)新,已經(jīng)應(yīng)用于實(shí)際生產(chǎn)環(huán)境并得到了用戶好評(píng)。然而,本方法還存在部分待改進(jìn)的地方,如增加對(duì)HTTPS等協(xié)議的支持,增加用戶模擬訪問(wèn)環(huán)節(jié),用于在沒(méi)有真實(shí)用戶訪問(wèn)的時(shí)間段對(duì)Web信息系統(tǒng)開(kāi)展持續(xù)的實(shí)時(shí)監(jiān)控等。本文將以上述存在的問(wèn)題作為后續(xù)研究的方向與內(nèi)容,開(kāi)展更深入、細(xì)致的研究工作。
參考文獻(xiàn)
[1] 金冬成.P2P檢測(cè)控制系統(tǒng)中的協(xié)議分析[J].廣東通信技術(shù),2008(12):65?68.
[2] 謝連朋.基于WinPcap的網(wǎng)絡(luò)底層數(shù)據(jù)采集系統(tǒng)設(shè)計(jì)[J].網(wǎng)絡(luò)安全技術(shù)與應(yīng)用,2014(8):93?94.
[3] 饒瑾.深度包檢測(cè)(DPI)技術(shù)淺談與應(yīng)用[J].信息通信,2014(11):245?246.
[4] STEVENS W R.TCP/IP詳解(卷1:協(xié)議)[M].范建華,胥光輝,張濤,等譯.北京:機(jī)械工業(yè)出版社,2007.
[5] 韓東東.電子郵件監(jiān)控與審計(jì)系統(tǒng)的設(shè)計(jì)與研究[D].北京:北京化工大學(xué),2008.
[6] 董永吉,郭云飛,黃慧群,等.面向內(nèi)容安全的報(bào)文解析結(jié)構(gòu)研究[J].四川大學(xué)學(xué)報(bào):工程科學(xué)版,2012,44(5):130?135.
[7] 孫宏君.業(yè)務(wù)網(wǎng)及業(yè)務(wù)性能的虛擬化監(jiān)測(cè)平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)[D].北京:北京郵電大學(xué),2013.
[8] 吳彥倫.基于WinPcap的Web用戶業(yè)務(wù)統(tǒng)計(jì)[J].電子世界,2014(15):161?162.
[9] 曾彬.基于主動(dòng)測(cè)試的網(wǎng)絡(luò)性能監(jiān)測(cè)技術(shù)研究[D].長(zhǎng)沙:湖南大學(xué),2009.
[10] 張婧婧,陳福文.互聯(lián)網(wǎng)流量分析技術(shù)及部署方案[J].移動(dòng)通信,2013(19):71?73.