【正文】 的最大字節(jié)數(shù)。如果出錯返回NULL；（2）pcap_t *pcap_open_live(char *device, int snaplen, int promisc, int to_ms, char *ebuf)，函數(shù)用于打開網(wǎng)絡(luò)設(shè)備，并且返回用于捕獲網(wǎng)絡(luò)數(shù)據(jù)包的數(shù)據(jù)包捕獲描述字。如果沒有設(shè)置過濾規(guī)則，所有數(shù)據(jù)包都將放入內(nèi)核緩沖區(qū)，并傳遞給用戶層緩沖區(qū)。當(dāng)一個數(shù)據(jù)包到達網(wǎng)絡(luò)接口時，libpcap首先利用已經(jīng)創(chuàng)建的Socket從鏈路層驅(qū)動程序中獲得該數(shù)據(jù)包的拷貝，再通過Tap函數(shù)將數(shù)據(jù)包發(fā)給BPF過濾器。但如果 BPF 監(jiān)聽接口，驅(qū)動首先調(diào)用BPF；BPF 首先進行過濾操作，然后把數(shù)據(jù)包存放在過濾器相關(guān)的緩沖區(qū)中，根據(jù)用戶定義的規(guī)則決定是否接收此數(shù)據(jù)包以及需要拷貝該數(shù)據(jù)包的哪些內(nèi)容；最后將過濾后的數(shù)據(jù)給與過濾器相關(guān)聯(lián)的上層應(yīng)用程序，設(shè)備驅(qū)動再次獲得控制。libpcap 支持BPF過濾機制[15]。 libcap工作原理 libpcap主要由兩部分構(gòu)成：網(wǎng)絡(luò)分接頭（Network Tap）和數(shù)據(jù)過濾器（Package Filter）[14]。 系統(tǒng)開發(fā)語言、工具及環(huán)境 系統(tǒng)開發(fā)語言根據(jù)項目整體設(shè)計要求，該項目需要運行在Linux系統(tǒng)下，程序采用C語言實現(xiàn)。(6) 關(guān)閉pcap數(shù)據(jù)包文件。(4) 打開pcap數(shù)據(jù)包文件。(2) 根據(jù)傳入的參數(shù)設(shè)置需要分析的協(xié)議類型。（2）數(shù)據(jù)包處理模塊這個模塊主要負責(zé)各種協(xié)議的分析，是整個系統(tǒng)最核心的部分，它通過調(diào)用各個協(xié)議分析函數(shù)，對預(yù)先設(shè)定的協(xié)議進行分析。關(guān)閉數(shù)據(jù)包文件 輸出分析結(jié)果圖 協(xié)議分析系統(tǒng)流程圖 協(xié)議分析系統(tǒng)主要由初始化模塊和數(shù)據(jù)包處理模塊這兩個核心模塊組成。（2）協(xié)議分析系統(tǒng)，應(yīng)用層協(xié)議解析系統(tǒng)的核心模塊，主要負責(zé)使用深度包檢測技術(shù)對各種應(yīng)用層協(xié)議（例如：HTTP協(xié)議，F(xiàn)TP協(xié)議等等）進行分析，并打印分析結(jié)果。 基于DPI的應(yīng)用層協(xié)議解析系統(tǒng)設(shè)計方案。（2）系統(tǒng)應(yīng)該穩(wěn)定、健壯，能夠獨立的。（2）輸出需求分析出的應(yīng)用層數(shù)據(jù)協(xié)議信息，包括協(xié)議類型、該協(xié)議的字節(jié)數(shù)、數(shù)據(jù)包數(shù)等信息。（4）能夠正確的解析應(yīng)用層數(shù)據(jù)協(xié)議，給出解析的結(jié)果和分析報告。（2）通過對應(yīng)用層協(xié)議的解析，識別出當(dāng)前數(shù)據(jù)包中包含的應(yīng)用層協(xié)議，以此對網(wǎng)絡(luò)進行內(nèi)容控制及管理。并且對應(yīng)用層解析系統(tǒng)中的數(shù)據(jù)包捕獲庫模塊、HTTP協(xié)議分析模塊和DHCP協(xié)議分析模塊做了詳細介紹，并對其實現(xiàn)的核心技術(shù)點及算法做了詳細分析；第4章結(jié)合實際的測試環(huán)境，根據(jù)第2章提出的系統(tǒng)需求，歸納出了針對協(xié)議解析模塊的測試目標(biāo)，包括對功能需求、輸入輸出需求等多個方面的測試，最終測試結(jié)果基本符合各項要求，說明了整個基于DPI的應(yīng)用層解析系統(tǒng)的可行性和正確性；第5章針對本文的研究內(nèi)容做了自己的總結(jié)與展望，在肯定了論文研究的意義和價值的同時，也對基于DPI的應(yīng)用層解析系統(tǒng)提出了改進建議。本文從5個方面著手對基于DPI的應(yīng)用層協(xié)議解析系統(tǒng)的研究背景以及設(shè)計與實現(xiàn)作了詳細的介紹。當(dāng)檢測多行響應(yīng)時，客戶檢測以確認此行是否以結(jié)束字符開始。在這些情況中，下面分別表述：在發(fā)送第一行響應(yīng)和一個 CRLF 之后，任何的附加信息行發(fā)送，他們也由 CRLF 對結(jié)束。現(xiàn)在有兩種狀態(tài)碼：確定(+OK)和失敗 (ERR)。POP3 響應(yīng)由一個狀態(tài)碼和一個可能跟有附加信息的命令組成。命令和參數(shù)由可打印的 ASCII 字符組成，它們之間由空格間隔。POP3 命令由一個命令和一些參數(shù)組成[28]。當(dāng)連接建立后， POP3 服務(wù)器發(fā)送確認消息。如下圖 所示。在協(xié)議中有三種狀態(tài)[27]：認可狀態(tài)，處理狀態(tài)，和更新狀態(tài)。POP3 客戶端向服務(wù)器發(fā)送命令并等待響應(yīng)， POP3 命令采用命令行形式，用ASCII 碼表示。 POP3協(xié)議POP3[26]（Post Office Protocol 3，郵局協(xié)議 3）協(xié)議適用于 C/S 架構(gòu)模型的電子郵件協(xié)議，POP3 是此協(xié)議發(fā)展的第三版，它規(guī)定怎樣將個人計算機連接到 Internet 的郵件服務(wù)器。SMTP 所示。SMTP 交互過程[12]比較簡單：（1）客戶端向SMTP服務(wù)器的25端口發(fā)起請求，通過三次握手建立鏈接；（2）服務(wù)器返回 220 的狀態(tài)碼，告訴客戶端服務(wù)準(zhǔn)備成功；（3）客戶端收到220狀態(tài)碼后向服務(wù)器發(fā)出 HELO 或者 EHLO 的命令告訴服務(wù)器該客戶端需要的服務(wù)類型，其中 HELO 是默認的 SMTP 服務(wù)，EHLO 要求除了默認的服務(wù)之外還要支持?jǐn)U展服務(wù)。 SMTP協(xié)議SMTP[11] （Simple Mail Transfer Protocol,簡單郵件傳輸協(xié)議）是一種提供可靠且有效的電子郵件傳輸協(xié)議。服務(wù)器端則通過狀態(tài)碼告訴客戶端當(dāng)前服務(wù)器的反饋狀態(tài)。被動模式的通信過程和主動模式基本一致，只是由客戶端發(fā)起數(shù)據(jù)鏈路的建立請求。主動模式下，F(xiàn)TP的通信過程如下：（1）由客戶端通過TCP三次握手向服務(wù)器發(fā)起控制鏈接的請求；（2）當(dāng)和服務(wù)器建立控制鏈接成功之后，在主動模式下客戶端將會發(fā)一個端口號給服務(wù)器，告訴當(dāng)前這次傳輸服務(wù)器所使用的數(shù)據(jù)傳輸端口；（3）服務(wù)器收到這個信息后就向客戶端發(fā)起數(shù)據(jù)鏈接請求，并開始傳遞數(shù)據(jù)；（4）數(shù)據(jù)傳輸完成后，該數(shù)據(jù)鏈路就被拆除了，如果客戶端進行一次新的傳輸，則向服務(wù)器發(fā)送一個新的端口號，重新建立鏈接。FTP 的一個完整的通信過程[10]如圖 所示。 FTP協(xié)議FTP [9]（File Transfer Protocol，文件傳輸協(xié)議）支持兩種模式：（1）Standard 模式(也就是PORT,主動模式), 由FTP 的客戶端發(fā)送 PORT 命令到 FTP 服務(wù)器（2）Passive 模式(也就是PASV,被動模式)，由 FTP 的客戶端發(fā)送 PASV 命令到FTP 服務(wù)器。 file：DHCP服務(wù)器為 DHCP客戶端指定的啟動配置文件名稱及路徑信息。 chaddr：DHCP客戶端的硬件地址。 siaddr：DHCP客戶端獲取 IP地址等信息的服務(wù)器 IP地址。 ciaddr：DHCP客戶端的 IP地址。第一個比特為廣播響應(yīng)標(biāo)識位，用來標(biāo)識 DHCP 服務(wù)器響應(yīng)報文是采用單播還是廣播方式發(fā)送，0 表示采用單播方式，1 表示采用廣播方式。目前沒有使用，固定為 0。 DHCP報文格式 xid：由客戶端軟件產(chǎn)生的隨機數(shù)，用于匹配請求和應(yīng)答報文。 hops：DHCP 報文經(jīng)過的 DHCP 中繼的數(shù)目。 hlen：硬件地址長度。具體的報文類型在 option字段中標(biāo)識。DHCP協(xié)議中傳輸?shù)膱笪挠涉溌穼宇^（承載鏈路層信息），IP頭（標(biāo)準(zhǔn)IP協(xié)議頭，20B），UDP頭（8B）和DHCP報文四部分組成?？蛻舳耸盏絛hcp_ack確認報文后，廣播arp報文，目的地址是被分配的ip地址。如果有多臺dhcp服務(wù)器向該客戶端發(fā)來dhcp_offer報文，客戶端只接受第一個收到的dhcp_offer報文，然后以廣播方式向各dhcp服務(wù)器回應(yīng)dhcp_request報文，該信息中包含dhcp服務(wù)器在dhcp_offer報文中分配的ip地址。dhcp服務(wù)器接收到客戶端的dhcp_discover報文后，從ip地址池中挑選一個尚未分配的ip地址分配給客戶端，向該客戶端發(fā)送包含出租ip地址和其它設(shè)置的dhcp_offer報文。DHCP協(xié)議的通信過程如下：（1）發(fā)現(xiàn)階段，即dhcp客戶端尋找dhcp服務(wù)器的階段。HTTP 協(xié)議有固定的狀態(tài)碼以及其表達的信息，分別是：1xx 表示信息類，2xx 表示成功類，3xx 表示重定向類，4xx 表示客戶端錯誤類， 5xx 表示服務(wù)器錯誤類。狀態(tài)碼是用來表示當(dāng)服務(wù)器收到客戶端的請求報文之后返回的一個響應(yīng)狀態(tài)，表示請求是否被理解或被滿足。版本空格狀態(tài)碼空格解釋狀態(tài)碼換行符回車符換行符回車符頭部字段名：值換行符回車符頭部字段名：值換行符回車符實體主體（通常不用）請求頭部請求數(shù)據(jù)請求行 HTTP請求報文一般格式其中請求方法是指當(dāng)前 HTTP請求報文中對所請求的資源的操作類型，常用的方法[8]包括 GET、POST、HEAD、PUT、CONNECT、DELETE、TRACE 和 OPTION；URL (Uniform Resource Locator, 統(tǒng)一資源定位符)是統(tǒng)一資源定位符，用來指出請求資源的路徑；請求頭部說明了瀏覽器、服務(wù)器或者報文主體的一些信息。 HTTP工作模式圖在HTTP通信過程中，HTTP 的請求報文分為請求行、請求頭部和請求數(shù)據(jù)三部分組成，一般格式如圖 所示。 HTTP協(xié)議HTTP協(xié)議[6,7]（hypertext transport protocol，超文本傳輸協(xié)議）是一個屬于應(yīng)用層的面對對象協(xié)議，它是工作在TCP/IP協(xié)議體系的TCP(Transfer ControlProtocol, 傳輸控制協(xié)議)之上可靠傳輸，采用的是C/S（客戶端/服務(wù)器）的工作模式。應(yīng)用層直接和應(yīng)用程序接口并提供常見的網(wǎng)絡(luò)應(yīng)用服務(wù)。行為模式識別技術(shù)通常用于無法根據(jù)協(xié)議判斷的業(yè)務(wù)的識別。（3）行為模式識別技術(shù)。應(yīng)用層網(wǎng)關(guān)需要先識別出控制流，并根據(jù)控制流的協(xié)議通過特定的應(yīng)用層網(wǎng)關(guān)對其進行解析，從協(xié)議內(nèi)容中識別出相應(yīng)的業(yè)務(wù)流。某些業(yè)務(wù)的控制流和業(yè)務(wù)流是分離的，業(yè)務(wù)流沒有任何特征。通過對“指紋”信息的升級，基于特征的識別技術(shù)可以很方便的進行功能擴展，實現(xiàn)對新協(xié)議的檢測?；凇疤卣髯帧钡淖R別技術(shù)通過對業(yè)務(wù)流中特定數(shù)據(jù)報文中的“指紋”信息的檢測以確定業(yè)務(wù)流承載的應(yīng)用。（1）基于“特征字”的識別技術(shù)[1]。成功的DPI技術(shù)必須能夠提供基本功能，如高性能計算和對分析任務(wù)的靈活的支持。DPI恰好能夠提供這些要求[3]，尋求更好的網(wǎng)絡(luò)管理以及合規(guī)的用戶企業(yè)應(yīng)該把DPI作為一項重要的技術(shù)。DPI能夠檢測出數(shù)據(jù)包的內(nèi)容及有效負載并且能夠提取出內(nèi)容級別的信息，如惡意軟件、具體數(shù)據(jù)和應(yīng)用程序類型。通常的DPI解決方案能夠為不同的應(yīng)用程序提供深度數(shù)據(jù)包檢測。隨著對應(yīng)用層協(xié)議解析的要求越來越高，對基于DPI的應(yīng)用層協(xié)議解析技術(shù)的研究也變得越來越重要。傳統(tǒng)報文檢測僅僅分析IP包的四層以下的內(nèi)容，包括源地址、目的地址、源端口、目的端口以及協(xié)議類型。 課題研究的目的和意義DPI（Deep Packet Inspection，深度包檢測）技術(shù)就是近年來出現(xiàn)的一種協(xié)議識別技術(shù)。并且當(dāng)前網(wǎng)絡(luò)上的一些非法應(yīng)用會采用隱藏或假冒端口號的方式躲避檢測和監(jiān)管，造成仿冒合法報文的數(shù)據(jù)流侵蝕著網(wǎng)絡(luò)[2]。這種識別能達到較高的速率，但是現(xiàn)在大量的應(yīng)用層協(xié)議為了避免識別，逃避防火墻的檢查，不使用固定的端口進行通信。對于網(wǎng)絡(luò)管理來說，最重要的就是識別和區(qū)分網(wǎng)絡(luò)流量，通過協(xié)議識別可以對網(wǎng)絡(luò)進行流量控制、網(wǎng)絡(luò)計費、內(nèi)容過濾、以及流量管理。 Second, the article given an overview on the system architecture of the application layer protocol analysis system and subsystem functions,and at the same time, it gaven a detailed description on the analy