【正文】 數(shù)據(jù)截獲和分析模塊是在Linux環(huán)境下實(shí)現(xiàn)的。數(shù)據(jù)捕獲和分析模塊在網(wǎng)絡(luò)監(jiān)控系統(tǒng)中占有非常重要的地位，該模塊從網(wǎng)絡(luò)中捕獲數(shù)據(jù)并對(duì)應(yīng)用層數(shù)據(jù)進(jìn)行分析，其處理結(jié)果存儲(chǔ)到數(shù)據(jù)庫(kù)供以后的查詢。 第四章 數(shù)據(jù)捕獲和分析模塊的實(shí)現(xiàn)監(jiān)控系統(tǒng)主要實(shí)現(xiàn)的功能是：對(duì)利用HTTP協(xié)議收發(fā)的WebMail郵件內(nèi)容的捕獲和還原，并從中提取了收發(fā)雙方的IP地址、郵件主題、郵件內(nèi)容、收發(fā)時(shí)間等信息。 本章介紹了TCP/IP的基本原理，由于本文所要論述的監(jiān)控系統(tǒng)主要是對(duì)WebMail進(jìn)行監(jiān)控，而WebMail在應(yīng)用層是基于HTTP協(xié)議的，故重點(diǎn)介紹了應(yīng)用層HTTP協(xié)議。總之，網(wǎng)絡(luò)監(jiān)控的實(shí)現(xiàn)原理就是TCP/IP協(xié)議，但是和操作系統(tǒng)中的協(xié)議棧的實(shí)現(xiàn)不同的是，網(wǎng)絡(luò)監(jiān)控主要是單向的數(shù)據(jù)拆包整合的過程，而且，從應(yīng)用的實(shí)際出發(fā)網(wǎng)絡(luò)監(jiān)控中的協(xié)議分析過遠(yuǎn)比實(shí)際的操作系統(tǒng)的協(xié)議棧簡(jiǎn)單。//假設(shè)運(yùn)輸層是tcp，獲得tcp頭， analyse（tcphdr）； //分析tcp頭，獲取信息如端口號(hào)data = （char*）tcphdr + TCP_HLEN；//獲得應(yīng)用層的數(shù)據(jù)信息 analyse（data）。//假設(shè)是以太網(wǎng)，可以從幀數(shù)據(jù)得到ip頭 analyse(iphdr)。在操作系統(tǒng)中網(wǎng)絡(luò)數(shù)據(jù)從進(jìn)入到到達(dá)應(yīng)用程序之前的內(nèi)核部分的處理都是在操作系統(tǒng)的協(xié)議棧中進(jìn)行的，網(wǎng)絡(luò)監(jiān)控系統(tǒng)完成的功能就是包括了協(xié)議棧和應(yīng)用程序。以上簡(jiǎn)單敘述的是基于內(nèi)容進(jìn)行監(jiān)控的實(shí)現(xiàn)過程，而對(duì)流量進(jìn)行監(jiān)控的網(wǎng)絡(luò)監(jiān)控應(yīng)用而言其實(shí)現(xiàn)遠(yuǎn)沒有這么復(fù)雜，只需要對(duì)于協(xié)議進(jìn)行簡(jiǎn)單的分析，獲取數(shù)據(jù)包的類型、總長(zhǎng)度，有時(shí)候還需要獲取通信相關(guān)的IP地址等信息。但是不管其應(yīng)用目的是什么，其協(xié)議分析的基礎(chǔ)都是TCP/IP協(xié)議。網(wǎng)絡(luò)監(jiān)控系統(tǒng)在獲取網(wǎng)絡(luò)數(shù)據(jù)后需要立即對(duì)網(wǎng)絡(luò)數(shù)據(jù)進(jìn)行協(xié)議分析，為實(shí)際的應(yīng)用功能提供相關(guān)的數(shù)據(jù)。當(dāng)此頭域出現(xiàn)時(shí)，它的數(shù)值表明對(duì)實(shí)體主體采用了什么樣的內(nèi)容編碼，以及因而可以使用何種解碼機(jī)制去獲得有ContentType頭域指明的媒體類型。這里以ContentEncoding為例。Age響應(yīng)報(bào)頭傳輸發(fā)送者對(duì)時(shí)間的估計(jì)，這個(gè)時(shí)間是自服務(wù)器產(chǎn)生響應(yīng)開始計(jì)算的。這些報(bào)頭給出服務(wù)器的信息和對(duì)請(qǐng)求URI標(biāo)識(shí)的資源進(jìn)行進(jìn)一步訪問所需要的信息。各個(gè)Accept報(bào)頭用來(lái)表示請(qǐng)求特別限定于一些期望的類型，例如一個(gè)內(nèi)嵌圖形的請(qǐng)求。這里以Accept請(qǐng)求報(bào)頭為例。這里以CacheControl通用報(bào)頭為例來(lái)說(shuō)明：CacheControl：這個(gè)通用頭域常用于指定必須被請(qǐng)求/響應(yīng)鏈中所有緩沖機(jī)制必須遵守的具體指令。每個(gè)頭域由一個(gè)名稱，一個(gè)冒號(hào)和一個(gè)域值組成。這類代碼表示服務(wù)器意思到發(fā)生錯(cuò)誤或者不能執(zhí)行請(qǐng)求。這類代碼用于客戶端似乎有錯(cuò)誤的情況。這類狀態(tài)碼表示為了完成請(qǐng)求，用戶代理需要采取進(jìn)一步的行動(dòng)。202 Accepted表示請(qǐng)求已被接受并正在進(jìn)行處理，但是處理還沒有完成。有多種，其中200 OK，表示請(qǐng)求成功。2xx：成功。其中100表示客戶端繼續(xù)它的請(qǐng)求。1xx：指示信息。TRACE用于激發(fā)一個(gè)遠(yuǎn)程的，應(yīng)用層的請(qǐng)求消息的回饋，它不含有消息正文。Post方法可以起到這樣的作用，對(duì)現(xiàn)有資源的注釋，向公告板，新聞組，郵件列表等添加消息，以表格的形式向數(shù)據(jù)處理進(jìn)程提交數(shù)據(jù)，通過添加操作擴(kuò)展一個(gè)數(shù)據(jù)庫(kù)。具體的格式如下：狀態(tài)行 = HTTP版本 SP 狀態(tài)編碼 SP 文本描述 CRLF下面將對(duì)請(qǐng)求報(bào)文和響應(yīng)報(bào)文的各個(gè)部分進(jìn)行概述請(qǐng)求報(bào)文的請(qǐng)求方法表示對(duì)由請(qǐng)求的URI標(biāo)識(shí)的資源所采取的方法，這個(gè)方法是大小寫敏感的。這兩種類型的報(bào)文由一個(gè)開始行，零個(gè)或多個(gè)報(bào)頭，空行（以回車換行符CRLF為前綴，什么也沒有，這個(gè)空行表示報(bào)文頭得結(jié)束），和一個(gè)可能的報(bào)文正文組成。HTTP報(bào)文由從客戶機(jī)到服務(wù)器的請(qǐng)求和從服務(wù)器到客戶機(jī)的響應(yīng)構(gòu)成。一個(gè)客戶機(jī)與服務(wù)器建立連接后，發(fā)送一個(gè)請(qǐng)求給服務(wù)器，請(qǐng)求方式的格式為，統(tǒng)一資源標(biāo)識(shí)符、協(xié)議版本號(hào)，后邊是MIME信息包括請(qǐng)求修飾符、客戶機(jī)信息和可能的內(nèi)容。HTTP協(xié)議在客戶服務(wù)器模式中具有請(qǐng)求／響應(yīng)范式功能的協(xié)議。它從開始使用到現(xiàn)在，經(jīng)過不斷發(fā)展和完善，已經(jīng)演化出多個(gè)版本。它是通用的、無(wú)狀態(tài)的、面向?qū)ο蟮膮f(xié)議。 HTTP應(yīng)用協(xié)議本文中論述的WebMail監(jiān)控系統(tǒng)在應(yīng)用層是基于HTTP[17][18]協(xié)議，因此這里將詳細(xì)介紹。UDP的長(zhǎng)度與IP協(xié)議的長(zhǎng)度有關(guān)聯(lián)性，UDP的長(zhǎng)度等于IP的長(zhǎng)度減去IP頭部的長(zhǎng)度。UDP數(shù)據(jù)長(zhǎng)度表示UDP頭部和UDP數(shù)據(jù)段的長(zhǎng)度，單位為字節(jié)。UDP協(xié)議把應(yīng)用程序需要傳遞的數(shù)據(jù)發(fā)送出去，不提供發(fā)送數(shù)據(jù)包的順序；接收方不向發(fā)送方發(fā)送接收的確認(rèn)信息，如果出現(xiàn)丟包或者重包的現(xiàn)象，也不會(huì)向發(fā)送方發(fā)送反饋，因此不能保證使用UDP協(xié)議的程序發(fā)送的數(shù)據(jù)一定到達(dá)了接收方或者到達(dá)接收方的數(shù)據(jù)順序和發(fā)送方的一致性。TCP連接通常在第一個(gè)通信的報(bào)文中指明這個(gè)選型，它指明當(dāng)前主機(jī)所能接收的最大報(bào)文長(zhǎng)度。（9） 緊急指針：只有設(shè)置了URG位才有效，它指出了緊接緊急數(shù)據(jù)的字節(jié)的順序編號(hào)。URG：表示緊急指針有效ACK：確認(rèn)序號(hào)有效PSH：表示接收方需要盡快將所收到的數(shù)據(jù)交給應(yīng)用層RST：連接有錯(cuò)，需要重建連接SYN：用于發(fā)起一個(gè)TCP的連接 FIN：用于表示將要斷開TCP連接（7） 窗口尺寸：窗口尺寸也稱接收窗口的大小，表示本機(jī)上TCP協(xié)議可以接收的以字節(jié)為單位的數(shù)目。（5） 保留位： 6位長(zhǎng)度沒有使用，必須為0。（3） 確認(rèn)號(hào)：發(fā)送方對(duì)發(fā)送的首字節(jié)進(jìn)行了編號(hào)，當(dāng)接收方成功接收后，發(fā)送回接收成功的序列號(hào)加1表示確認(rèn)，發(fā)送方再次發(fā)送的時(shí)候從確認(rèn)號(hào)開始。（2） 序列號(hào)：序列號(hào)是一個(gè)32位長(zhǎng)度的字段，表示分配給TCP包的編號(hào)。 TCP報(bào)文中的數(shù)據(jù)格式（1） 源端口號(hào)和目的端口號(hào)表示發(fā)送端和接收端的端口，用于確認(rèn)發(fā)送端和接收端的應(yīng)用程序。TCP的數(shù)據(jù)格式：TCP在IP協(xié)議的基礎(chǔ)上進(jìn)行傳輸數(shù)據(jù)，： TCP數(shù)據(jù)在IP報(bào)文中的位置TCP報(bào)文包含頭部和數(shù)據(jù)兩部分。全雙工傳輸：各主機(jī)TCP協(xié)議以全雙工的方式進(jìn)行數(shù)據(jù)流交換。面向連接的服務(wù)：在數(shù)據(jù)進(jìn)行傳輸之前，TCP協(xié)議需要先建立連接，之后的TCP報(bào)文在此基礎(chǔ)上傳輸可靠傳輸服務(wù)：基于校驗(yàn)和應(yīng)答重發(fā)機(jī)制保證傳輸?shù)目煽啃?，接收方?duì)接收到的報(bào)文進(jìn)行校驗(yàn)和計(jì)算，如果有誤，不發(fā)送確認(rèn)應(yīng)答，發(fā)送方在超時(shí)后會(huì)自動(dòng)重發(fā)此報(bào)文。 TCP首部傳輸控制協(xié)議，簡(jiǎn)稱TCP協(xié)議，它在原有IP協(xié)議的基礎(chǔ)上，增加了確認(rèn)重發(fā)、滑動(dòng)窗口和復(fù)用/解復(fù)用等機(jī)制，提供一種可靠的、面向連接的字節(jié)流服務(wù)。因此，發(fā)送IP數(shù)據(jù)報(bào)時(shí)，可以不按順序。由上層某些協(xié)議來(lái)提供可靠性。IP只提供最好的傳輸服務(wù)，對(duì)IP數(shù)據(jù)包是否能成功到達(dá)目的地并不能保證。，不包含選項(xiàng)字段，其頭部的長(zhǎng)度為20字節(jié)。路由選擇；現(xiàn)則數(shù)據(jù)在互聯(lián)網(wǎng)上的傳送路徑。IP層主要有如下作用：數(shù)據(jù)傳送：將數(shù)據(jù)從一個(gè)主機(jī)傳輸?shù)搅硪粋€(gè)主機(jī)。 IP首部TCP/IP協(xié)議中最重要的協(xié)議是IP協(xié)議，它為上層協(xié)議如TCP、UDP等協(xié)議提供傳輸?shù)耐?。例如ARP協(xié)議的數(shù)據(jù)格式為28個(gè)字節(jié)，為了符合規(guī)范，其后有18個(gè)字節(jié)的占位符用于滿足最少46字節(jié)的要求。在地址后面是兩個(gè)字節(jié)的表示類型的字段，例如0800表示此幀的數(shù)據(jù)為IP數(shù)據(jù)，0806表示此幀為ARP請(qǐng)求。 以太網(wǎng)的數(shù)據(jù)格式以太網(wǎng)用6字節(jié)來(lái)表示源地址和目的地址。以太網(wǎng)是由幾家美國(guó)商業(yè)公司聯(lián)合開發(fā)的基帶局域網(wǎng)規(guī)范，它已經(jīng)作為現(xiàn)有局域網(wǎng)采用的最通用的通信協(xié)議標(biāo)準(zhǔn)，目前TCP/IP技術(shù)主要基于此標(biāo)準(zhǔn)。在主機(jī)B上的應(yīng)用程序最后得到干凈的有效數(shù)據(jù)，然后進(jìn)行處理。IP層剝?nèi)P頭，進(jìn)行校驗(yàn)，將數(shù)據(jù)發(fā)送給其上層運(yùn)輸層。接收數(shù)據(jù)的過程是一個(gè)解封包的過程。在IP層增加IP的頭部數(shù)據(jù)，運(yùn)輸層的數(shù)據(jù)和頭部都封裝在IP層的數(shù)據(jù)部分。 TCP/IP四層模型數(shù)據(jù)傳輸過程發(fā)送的過程是一個(gè)封包的過程。但在同一層上，雙方都有對(duì)應(yīng)的一個(gè)或多個(gè)協(xié)議進(jìn)行通信。這里，通訊的兩臺(tái)主機(jī)，一個(gè)運(yùn)行HTTP客戶程序，一個(gè)運(yùn)行HTTP服務(wù)器程序，比如客戶訪問web服務(wù)器的網(wǎng)頁(yè)。這兩臺(tái)主機(jī)在應(yīng)用層運(yùn)行HTTP協(xié)議。如常用于傳送網(wǎng)頁(yè)的HTTP協(xié)議，用于文件傳輸協(xié)議FTP，用于簡(jiǎn)單郵件傳送協(xié)議SMTP等。TCP和UDP是兩個(gè)互不相同的運(yùn)輸層協(xié)議。ICMP和IGMP是IP協(xié)議的附屬協(xié)議。網(wǎng)絡(luò)層ICMP、IP和IGMP數(shù)據(jù)包的路由選擇發(fā)生在這一層。：圖 TCP/IP協(xié)議族中不同層次的協(xié)議 TCP/IP 層次功能表TCP/IP層描述主要協(xié)議主要功能鏈路層ARP，RARP和設(shè)備驅(qū)動(dòng)程序及網(wǎng)絡(luò)接口卡鏈路管理，差錯(cuò)控制，發(fā)送時(shí)將網(wǎng)絡(luò)層數(shù)據(jù)報(bào)封裝進(jìn)鏈路層的幀，接收時(shí)從接收到的比特流中準(zhǔn)確地區(qū)分出一幀的開始和結(jié)束。協(xié)議族，比如TCP/IP[15]，是一組各個(gè)層次上的不同協(xié)議的組合。167。數(shù)據(jù)幀中的各個(gè)部分的字節(jié)都有特定的含義，通過對(duì)數(shù)據(jù)包的原始數(shù)據(jù)進(jìn)行解碼，顯示數(shù)據(jù)包各個(gè)域的信息，然后根據(jù)適當(dāng)?shù)挠嘘P(guān)協(xié)議的RFC文檔和其它的規(guī)范就可以對(duì)具體的內(nèi)容進(jìn)行分析，然后根據(jù)實(shí)際的需要，進(jìn)行相關(guān)的操作，這就是網(wǎng)絡(luò)內(nèi)容監(jiān)控系統(tǒng)的協(xié)議分析部分的主要內(nèi)容。根據(jù)這些協(xié)議知識(shí)，我們可以從捕獲的數(shù)據(jù)包中獲得網(wǎng)絡(luò)上各種信息，比如網(wǎng)絡(luò)上運(yùn)行的協(xié)議和提供的服務(wù)，還可以知道一個(gè)數(shù)據(jù)包的源地址和目的地址以及它所負(fù)載的應(yīng)用信息等。而捕捉到的數(shù)據(jù)只是一串字節(jié)。考慮到監(jiān)控系統(tǒng)的監(jiān)控環(huán)境的復(fù)雜性，特別是在高速?gòu)?fù)雜的網(wǎng)絡(luò)環(huán)境中的性能要求，標(biāo)準(zhǔn)libpcap存在的一些不足，又介紹了新的數(shù)據(jù)包捕獲套接字模型PF_RING，使用PF_RING接口的libpcap的性能得到極大的增強(qiáng)。167。 PF_RING邏輯結(jié)構(gòu)圖PF_RING極大的增加了標(biāo)準(zhǔn)Linux操作系統(tǒng)的數(shù)據(jù)包捕獲性能。libpcap也有一個(gè)PF_RING加強(qiáng)的版本，因此用libpcap用戶接口編寫的監(jiān)控應(yīng)用程序也能直接受益于PF_RING。PF_RING的用戶空間庫(kù)是libpfring，利用該庫(kù)可以對(duì)數(shù)據(jù)包捕獲應(yīng)用程序進(jìn)行快熟開發(fā)。將bucket_len的長(zhǎng)度降低到最大傳輸單元（MTU）以下導(dǎo)致花費(fèi)在拷貝上的時(shí)間的減少。第一個(gè)參數(shù)表示換種緩沖區(qū)得長(zhǎng)度，而第二個(gè)參數(shù)表示捕獲包的最大長(zhǎng)度。內(nèi)核補(bǔ)丁提供了一個(gè)可卸載的內(nèi)核模塊，ring模塊，有了這個(gè)模塊才可以使用PF_RING類型套接字。因此，內(nèi)核包的旅程大量減少。該套接字使用內(nèi)存映射的緩沖區(qū)，該緩沖區(qū)被實(shí)現(xiàn)為一個(gè)環(huán)狀FIFO緩沖，由內(nèi)核和用戶應(yīng)用程序共享。PF_RING能夠利用可識(shí)別NAPI的驅(qū)動(dòng)器，并且不需要任何特別的硬件，因此它能在由標(biāo)準(zhǔn)linux內(nèi)核支持的每一個(gè)網(wǎng)絡(luò)接口卡上使用[13]。 圖 傳統(tǒng)報(bào)文處理與零拷貝的對(duì)比 PF_RING綜合上面的分析，PF_RING這種新的解決方案被提出來(lái)。創(chuàng)造零拷貝的技術(shù)包括使用基于DMA的拷貝技術(shù)和通過內(nèi)存管理模塊進(jìn)行的內(nèi)存映射技術(shù)。零拷貝被提出來(lái)解決數(shù)據(jù)多次拷貝問題。對(duì)數(shù)據(jù)包捕捉來(lái)說(shuō)，內(nèi)核設(shè)備輪詢并不足以應(yīng)付各種情況，比如使用了設(shè)備輪詢的linux系統(tǒng)，對(duì)高速網(wǎng)絡(luò)中有大量較小數(shù)據(jù)包的情況下，捕獲效果就很低。設(shè)備輪詢有利于高負(fù)荷網(wǎng)絡(luò)下改善包的捕獲性能和系統(tǒng)響應(yīng)。操作系統(tǒng)對(duì)中斷進(jìn)行如下操作，它首先屏蔽由網(wǎng)卡產(chǎn)生的中斷，這樣網(wǎng)卡就不能中斷內(nèi)核，然后調(diào)度一個(gè)任務(wù)去定期輪詢網(wǎng)卡，為需求服務(wù)，一旦驅(qū)動(dòng)器完成了網(wǎng)卡的處理，網(wǎng)卡中斷就又再次激活。這個(gè)問題也叫中斷活鎖[10]。每次數(shù)據(jù)包到達(dá)時(shí)，網(wǎng)卡就會(huì)產(chǎn)生一個(gè)中斷，由于中斷任務(wù)較其它任務(wù)優(yōu)先權(quán)高，操作系統(tǒng)會(huì)調(diào)用網(wǎng)卡驅(qū)動(dòng)進(jìn)行處理。： 基于Libpcap的包捕獲系統(tǒng)框架圖4．Libpcap缺陷和改進(jìn)方法盡管libpcap函數(shù)庫(kù)在不同的平臺(tái)上提供相同的API，但libpcap的性能在不同的平臺(tái)上則差別很大。3．Libpcap數(shù)據(jù)包捕獲應(yīng)用程序框架 Libpcap庫(kù)函數(shù)有很多，在Linux下并不是所有的libpcap庫(kù)函數(shù)都會(huì)用到。插入之后，就可以調(diào)用函數(shù)pcap_loop()或pcap_next（）開始抓包。然而，如果需要決定網(wǎng)絡(luò)掩碼，函數(shù)pcap_lookupnet(const char *device， bpf_u_int32 *netp bpf_u_int32 *maskp, char *errbuf)可以做到這一點(diǎn)。參數(shù)optimize是個(gè)標(biāo)記參數(shù)，控制過濾程序是否為了效率而進(jìn)行優(yōu)化。函數(shù)int pcap_pile（pcap_t *p， struct bpf_program *fp， char *str， int optimize， bpf_u_int32 netmask）將str所指的過濾表達(dá)式編譯成BPF代碼。這里舉寫例子：src host ；tcp[13] == 0x02 and (dst port 22 or dst port 23) 返回設(shè)定了SYN標(biāo)志位并且目的端口是22或23的數(shù)據(jù)包。但是，libpcap和tcpdump使用一個(gè)高級(jí)語(yǔ)言對(duì)過濾器進(jìn)行定義。設(shè)定一個(gè)過濾器需要三個(gè)步驟：構(gòu)造一個(gè)過濾表達(dá)式，將表達(dá)式編譯到BPF程序中，最后應(yīng)用這個(gè)過濾器。Linux操作系統(tǒng)支持BPF架構(gòu)。內(nèi)核的系統(tǒng)包過濾器提供過濾功能。這是因?yàn)樽グ^程發(fā)生在內(nèi)核，而應(yīng)用程序發(fā)生在用戶空間，而從內(nèi)核空間拷貝到用戶空間會(huì)消耗掉大量的CPU時(shí)間。通常網(wǎng)卡驅(qū)動(dòng)程序和協(xié)議棧會(huì)對(duì)這些數(shù)據(jù)處理，但是在我們應(yīng)用程序里捕捉的數(shù)據(jù)包，必須由我們自己進(jìn)行分析，而要進(jìn)行分析，我們必須了解一些相關(guān)的協(xié)議，這些知識(shí)將在第三章進(jìn)行論述。函數(shù)pcap_dispatch（pcap_t *p， int t，pcap_handler_callback, u_char *user）與函數(shù)pcap_loop（）的功能相似，但是當(dāng)在pcap_open_live()規(guī)定的to_ms時(shí)間超時(shí)時(shí)，這個(gè)函數(shù)也會(huì)返回。 /*存儲(chǔ)的字節(jié)數(shù)*/ bpf_u_int32 len。用戶定義的包處理函數(shù)必須符合具體的函數(shù)規(guī)范，否則pcap_loop()就不知道如何使用這個(gè)函數(shù)