摘要：在因特網(wǎng)日益發(fā)展壯大的今天，萬(wàn)維網(wǎng)在其上的通信量已經(jīng)超過(guò)90%，萬(wàn)維網(wǎng)信息的安全問(wèn)題已經(jīng)越來(lái)越被人們所重視，而作為萬(wàn)維網(wǎng)應(yīng)用層核心協(xié)議的http協(xié)議是基礎(chǔ)。當(dāng)網(wǎng)絡(luò)發(fā)生異常時(shí)，對(duì)網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)進(jìn)行監(jiān)視和分析，是網(wǎng)管人員解決網(wǎng)絡(luò)故障的一種常用方法。
本文介紹應(yīng)用層HTTP數(shù)據(jù)包的截獲與還原技術(shù)的實(shí)現(xiàn),并簡(jiǎn)要介紹其中所涉及的數(shù)據(jù)包截獲、數(shù)據(jù)包分析、應(yīng)用數(shù)據(jù)重組以及數(shù)據(jù)包解碼等關(guān)鍵技術(shù)。該系統(tǒng)可以監(jiān)聽(tīng)網(wǎng)管人員感興趣的數(shù)據(jù)包，通過(guò)對(duì)其進(jìn)行分析和研究，分析出其遵守的協(xié)議以及其應(yīng)用層數(shù)據(jù)，恢復(fù)到被監(jiān)視用戶所看到數(shù)據(jù)的格式。該系統(tǒng)的實(shí)現(xiàn)，為網(wǎng)管人員有效地管理網(wǎng)絡(luò)提供了一種直觀的工具。
關(guān)鍵詞：http數(shù)據(jù)包； 截獲； 還原
Abstract: With the increasing development and expansion of Internet, the traffic of World-Wide-Web has occupied more than 90 percent on Internet at present. Therefore, people have attached more and more importance to the security of the WWW information. While HTTP (Hypertext Transfer Protocol) as the central protocol of WWW’s application layer forms the foundation of it. Monitoring and analysing the data transferred on network is the daily works for network manager
The writer of this paper introduced the design and implementation for capturing a part of http data packets, recovering the captured http data packets，and analyzed some key technologies about capturing data packet brief，packet analyzing, reconstructing application data and packet decoding and so on．This system can monitor the packages which network manager is interested in，analyze the protocols which the packet uses，recover the format which the end user see．The implementation of the system provides a visual tool for network managers.
Key Words: http packets；capture；recover
目 錄
前言 1
第一章 HTTP網(wǎng)絡(luò)數(shù)據(jù)包截獲與還原的理論基礎(chǔ) 2
1.1 網(wǎng)絡(luò)體系結(jié)構(gòu) 2
1.1.1 網(wǎng)絡(luò)參考模型概述 2
1.1.2 TCP/IP協(xié)議族 3
1.2 HTTP協(xié)議概述 4
1.2.1 http協(xié)議的幾個(gè)重要概念 5
1.2.2 http協(xié)議結(jié)構(gòu) 6
1.2.3 http協(xié)議的運(yùn)作方式 12
1.3 基于HTTP協(xié)議的網(wǎng)絡(luò)行為監(jiān)視 16
1.3.1 http協(xié)議的安全因素 16
1.3.2 基于http協(xié)議監(jiān)視的實(shí)現(xiàn) 17
第二章 開(kāi)發(fā)工具與環(huán)境配置 19
2.1 JAVA語(yǔ)言介紹 19
2.1.1 平臺(tái)無(wú)關(guān)性 19
2.1.2 面向?qū)ο?20
2.1.3 安全穩(wěn)定 21
2.1.4 支持多線程 22
2.2 JDK概述 22
2.2.1 Java開(kāi)發(fā)工具JDK 介紹 22
2.2.2 開(kāi)發(fā)環(huán)境配置 23
第三章 HTTP數(shù)據(jù)包截獲 24
3.1 HTTP數(shù)據(jù)包截獲模塊設(shè)計(jì) 24
3.1.1 體系結(jié)構(gòu)設(shè)計(jì) 24
3.1.2 WinPcap工具 25
3.1.3 Packet.dll 26
3.1.4 Jpcap類(lèi)庫(kù) 28
3.2 數(shù)據(jù)包的存儲(chǔ) 29
3.3 數(shù)據(jù)包捕獲和存儲(chǔ)流程圖 32
3.4 數(shù)據(jù)包捕獲和存儲(chǔ)程序片斷 32
第四章 HTTP數(shù)據(jù)包信息的分析與還原 35
4.1 字符編碼的信息概述 35
4.1.1 ASCALL字符編碼 35
4.1.2 GB2312字符編碼 36
4.1.3 BIG5字符編碼 36
4.1.4 UNICODE(UTF-8)字符編碼 36
4.2 捕獲數(shù)據(jù)包信息的分析 38
4.2.1 捕獲數(shù)據(jù)數(shù)據(jù)包的重組分析 38
4.2.2 捕獲數(shù)據(jù)包編碼格式的分析 40
4.2.3 捕獲數(shù)據(jù)的分析的程序片段 40
4.3 對(duì)捕獲數(shù)據(jù)包信息的部分還原 41
4.3.1 捕獲數(shù)據(jù)包信息還原的流程圖 41
4.3.2 捕獲數(shù)據(jù)包的信息還原算法 42
第五章 總結(jié) 52
參 考 文 獻(xiàn) 54
謝 辭 55
前言
在短短的二十幾年時(shí)間里,萬(wàn)維網(wǎng)(Word Wide Web)從一種發(fā)布高能物理數(shù)據(jù)的方式演變?yōu)槿缃袢藗冾^腦中的因特網(wǎng),它之所以如此流行是由于它有一個(gè)豐富多彩的界面,初學(xué)者很容易使用,并且提供了大量的信息資源,幾乎涉及人們所能想象的所有主題。
HTTP是一個(gè)屬于應(yīng)用層的面向?qū)ο蟮膮f(xié)議，而http協(xié)議作為www的主要協(xié)議,由于其簡(jiǎn)捷、快速的方式，適用于分布式超媒體信息系統(tǒng)。它于1990年提出，經(jīng)過(guò)幾年的使用與發(fā)展，得到不斷地完善和擴(kuò)展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規(guī)范化工作正在進(jìn)行之中，而且HTTP-NG(NextGenerationofHTTP)的建議已經(jīng)提出。
但HTTP協(xié)議存在許多安全漏洞，比如說(shuō)允許遠(yuǎn)程用戶向遠(yuǎn)程服務(wù)器請(qǐng)求連接,并且執(zhí)行遠(yuǎn)程命令.這個(gè)安全漏洞可以以許多方式損壞Web服務(wù)器和客戶機(jī)，這些危害信息還包括對(duì)遠(yuǎn)程請(qǐng)求的武斷認(rèn)證；破壞請(qǐng)求和應(yīng)答的保密性；濫用服務(wù)器功能和資源等。而在網(wǎng)絡(luò)上傳送的不良信息，也影響人們的身心健康，包括色情、迷信和暴力等信息。對(duì)危害信息和不良信息在應(yīng)用層的還原可以很明確的知道該信息傳送的具體信息，具有很直觀的效果，可以幫助網(wǎng)絡(luò)管理人員較好的監(jiān)視網(wǎng)絡(luò)。對(duì)于網(wǎng)絡(luò)數(shù)據(jù)包的截獲和還原是網(wǎng)絡(luò)行為監(jiān)視的一部分，本文主要介紹HTTP數(shù)據(jù)包的截獲與還原技術(shù)，該技術(shù)涉及到數(shù)據(jù)包截獲、數(shù)據(jù)包分析、應(yīng)用數(shù)據(jù)重組和字符編碼解碼等關(guān)鍵技術(shù)。該技術(shù)的實(shí)現(xiàn)可以幫助網(wǎng)管人員監(jiān)聽(tīng)感興趣的HTTP數(shù)據(jù)包，分析出其遵守的協(xié)議以及其應(yīng)用層數(shù)據(jù)，同時(shí)將應(yīng)用層數(shù)據(jù)進(jìn)行重組，恢復(fù)到原始的數(shù)據(jù)格式，達(dá)到與被監(jiān)視用戶相同的顯示效果。該系統(tǒng)的實(shí)現(xiàn)，為網(wǎng)管人員有效地管理網(wǎng)絡(luò)提供了一種直觀的工具。
本文所介紹的基于HTTP協(xié)議的截獲和還原信息主要是萬(wàn)維網(wǎng)信息，而這些信息包括文本、圖象和聲音等，本文主要是針對(duì)文本信息的還原，而大多數(shù)的嗅探器并不支持的數(shù)據(jù)在應(yīng)用層的還原。本文所提出的應(yīng)用層數(shù)據(jù)的還原技術(shù)是針對(duì)大多數(shù)嗅探器的局限性提出來(lái)的。
第一章 http網(wǎng)絡(luò)數(shù)據(jù)包截獲與還原的理論基礎(chǔ)
1.1 網(wǎng)絡(luò)體系結(jié)構(gòu)
1.1.1 網(wǎng)絡(luò)參考模型概述
OSI的七層協(xié)議體系結(jié)構(gòu)既復(fù)雜又不實(shí)用，但其概念清楚，體系結(jié)構(gòu)理論較完整。TCP/IP的協(xié)議現(xiàn)在得到了廣泛的應(yīng)用，但它原先并沒(méi)有一個(gè)明確的體系結(jié)構(gòu)。TCP/IP是一個(gè)四層的體系結(jié)構(gòu)，它包含應(yīng)用層、運(yùn)輸層、網(wǎng)際層和網(wǎng)絡(luò)結(jié)構(gòu)層。不過(guò)從實(shí)質(zhì)上講，TCP/IP只有三層，即應(yīng)用層、運(yùn)輸層和網(wǎng)際層，因?yàn)樽钕旅娴木W(wǎng)絡(luò)接口層并沒(méi)有什么具體內(nèi)容。
下面的圖片反應(yīng)了兩臺(tái)計(jì)算機(jī)進(jìn)行通信時(shí)的各層數(shù)據(jù)流結(jié)構(gòu)。
圖1.1
應(yīng)用層 應(yīng)用層是體系結(jié)構(gòu)中的最高層。應(yīng)用層確定進(jìn)程之間通信的性質(zhì)以滿足用戶的需要。應(yīng)用層不僅要提供應(yīng)用進(jìn)程所需要的信息交換和遠(yuǎn)地操作，而且還要作為相互作用的應(yīng)用進(jìn)程的用戶代理，來(lái)完成一些為進(jìn)行語(yǔ)義上有意義的信息交換所必須的功能。應(yīng)用層直接為用戶的應(yīng)用進(jìn)程提供服務(wù)。在因特網(wǎng)中的應(yīng)用層協(xié)議很多，如支持萬(wàn)維網(wǎng)應(yīng)用的HTTP協(xié)議，支持電子郵件的SMTP協(xié)議，支持文件傳輸?shù)腇TP協(xié)議等等。
運(yùn)輸層 運(yùn)輸層的任務(wù)就是負(fù)責(zé)主機(jī)中兩個(gè)進(jìn)程之間的通信。
因特網(wǎng)的運(yùn)輸層可使用兩種不同協(xié)議。即面向連接的傳輸控制協(xié)議TCP，和無(wú)連接的用戶數(shù)據(jù)報(bào)協(xié)議UDP。面向連接的服務(wù)能夠提供可靠的交付，但無(wú)連接服務(wù)則不保證提供可靠的交付，它只是“盡最大努力交付”。這兩種服務(wù)方式都很有用，各有其優(yōu)缺點(diǎn)。
在分組交換網(wǎng)內(nèi)的各個(gè)交換接點(diǎn)機(jī)都沒(méi)有運(yùn)輸層。運(yùn)輸層只能存在于分組交換網(wǎng)外面的主機(jī)之中。運(yùn)輸層以上的各層就不再關(guān)心信息傳輸?shù)膯?wèn)題了。正因?yàn)槿绱?，運(yùn)輸層就成為計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)中非常重要的一層。
網(wǎng)絡(luò)層 網(wǎng)絡(luò)層負(fù)責(zé)為分組交換網(wǎng)上的不同主機(jī)提供通信。在發(fā)送數(shù)據(jù)時(shí)，網(wǎng)絡(luò)層將運(yùn)輸層產(chǎn)生的報(bào)文段或用戶數(shù)據(jù)報(bào)封裝成分組或包進(jìn)行傳送。在TCP/IP體系中，分組也叫作IP數(shù)據(jù)報(bào)，或簡(jiǎn)稱(chēng)為數(shù)據(jù)報(bào)。
因特網(wǎng)是一個(gè)很大的互聯(lián)網(wǎng)，它由大量的異構(gòu)網(wǎng)絡(luò)通過(guò)路由器相互連接起來(lái)。因特網(wǎng)主要的網(wǎng)絡(luò)協(xié)議是無(wú)連接的網(wǎng)際協(xié)議IP和許多路由選擇協(xié)議，因此因特網(wǎng)的網(wǎng)絡(luò)層也叫網(wǎng)際層或IP層。
數(shù)據(jù)鏈路層 在發(fā)送數(shù)據(jù)時(shí)，數(shù)據(jù)鏈路層的任務(wù)是將在網(wǎng)絡(luò)層交下來(lái)的IP數(shù)據(jù)報(bào)組裝成幀，在兩個(gè)相鄰接點(diǎn)間的鏈路上傳送以幀為單位的數(shù)據(jù)。每一幀包括數(shù)據(jù)和必要的控制信息?？刂菩畔⑹菇邮芏四軌蛑酪粋€(gè)幀從哪個(gè)比特開(kāi)始和到哪個(gè)比特結(jié)束?？刂菩畔⑦€使接受端能夠檢測(cè)到所收到的幀中有無(wú)差錯(cuò)。如發(fā)現(xiàn)有差錯(cuò)，數(shù)據(jù)鏈路層就丟棄這個(gè)出了差錯(cuò)的幀。
物理層 物理層的任務(wù)是透明地傳送比特流。在物理層上所傳數(shù)據(jù)的單位是比特。傳遞信息所利用的一些物理媒體，如雙絞線、同軸電纜、光纜，并不在物理層之內(nèi)而是在物理層的下面。
1.1.2 TCP/IP協(xié)議族
TCP/IP協(xié)議族（如下圖所示），它的特點(diǎn)是上下兩頭大而中間?。簯?yīng)用層和網(wǎng)絡(luò)接口層都有多種協(xié)議，而中間的IP層很小，上層的各種協(xié)議都向下匯聚到一個(gè)IP協(xié)議中。這種很象沙漏計(jì)時(shí)器形狀的TCP/IP協(xié)議族表明：TCP/IP可以為各式各樣的應(yīng)用提供服務(wù)，同時(shí)也可以連接到各式各樣的網(wǎng)絡(luò)上。正因?yàn)槿绱?，因特網(wǎng)才會(huì)發(fā)展到今天的這種全球規(guī)模。
圖1.2
整個(gè)通信網(wǎng)絡(luò)的任務(wù)，可以劃分成不同的功能塊，即抽象成所謂的 ” 層” 。用于互聯(lián)網(wǎng)的協(xié)議可以比照TCP/IP參考模型進(jìn)行分類(lèi)。TCP/IP協(xié)議棧起始于第三層協(xié)議IP(互聯(lián)網(wǎng)協(xié)議) 。所有這些協(xié)議都在相應(yīng)的RFC文檔中討論及標(biāo)準(zhǔn)化。重要的協(xié)議在相應(yīng)的RFC文檔中均標(biāo)記了狀態(tài): “必須“ (required) ，“推薦“ (recommended) ，“可選“ (elective) 。其它的協(xié)議還可能有“ 試驗(yàn)“(experimental) 或“ 歷史“(historic) 的狀態(tài)。
1.2 http協(xié)議概述
我們?cè)跒g覽器的地址欄里輸入的網(wǎng)站地址叫做URL(UniformResourceLocator，統(tǒng)一資源定位符)。就像每家每戶都有一個(gè)門(mén)牌地址一樣，每個(gè)網(wǎng)頁(yè)也都有一個(gè)Internet地址。當(dāng)你在瀏覽器的地址框中輸入一個(gè)URL或是單擊一個(gè)超級(jí)鏈接時(shí)，URL就確定了要瀏覽的地址。瀏覽器通過(guò)超文本傳輸協(xié)議(HTTP)，將Web服務(wù)器上站點(diǎn)的網(wǎng)頁(yè)代碼提取出來(lái)，并翻譯成漂亮的網(wǎng)頁(yè)。
Internet的基本協(xié)議是TCP/IP協(xié)議，然而在TCP/IP模型最上層的是應(yīng)用層(Applicationlayer)，它包含所有高層的協(xié)議。高層協(xié)議有：文件傳輸協(xié)議FTP、電子郵件傳輸協(xié)議SMTP、域名系統(tǒng)服務(wù)DNS、網(wǎng)絡(luò)新聞傳輸協(xié)議NNTP和HTTP協(xié)議等。
HTTP協(xié)議(Hypertext Transfer Protocol，超文本傳輸協(xié)議)是用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。它不僅保證計(jì)算機(jī)正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內(nèi)容首先顯示(如文本先于圖形)等。這就是你為什么在瀏覽器中看到的網(wǎng)頁(yè)地址都是以“http://”開(kāi)頭的原因。
自WWW誕生以來(lái)，一個(gè)多姿多彩的資訊和虛擬的世界便出現(xiàn)在我們眼前，可是我們?cè)趺茨軌蚋尤菀椎卣业轿覀冃枰馁Y訊呢？當(dāng)決定使用超文本作為WWW文檔的標(biāo)準(zhǔn)格式后，于是在1990年，科學(xué)家們立即制定了能夠快速查找這些超文本文檔的協(xié)議，即HTTP協(xié)議。經(jīng)過(guò)幾年的使用與發(fā)展，得到不斷的完善和擴(kuò)展，目前在WWW中使用的是HTTP/1.0的第六版。
1.2.1 http協(xié)議的幾個(gè)重要概念
1.連接(Connection)：一個(gè)傳輸層的實(shí)際環(huán)流，它是建立在兩個(gè)相互通訊的應(yīng)用程序之間。
2.消息(Message)：HTTP通訊的基本單位，包括一個(gè)結(jié)構(gòu)化的八元組序列并通過(guò)連接傳輸。
3.請(qǐng)求(Request)：一個(gè)從客戶端到服務(wù)器的請(qǐng)求信息包括應(yīng)用于資源的方法、資源的標(biāo)識(shí)符和協(xié)議的版本號(hào)
4.響應(yīng)(Response)：一個(gè)從服務(wù)器返回的信息包括HTTP協(xié)議的版本號(hào)、請(qǐng)求的狀態(tài)(例如“成功”或“沒(méi)找到”)和文檔的MIME類(lèi)型。
5.資源(Resource)：由URI標(biāo)識(shí)的網(wǎng)絡(luò)數(shù)據(jù)對(duì)象或服務(wù)。
6.實(shí)體(Entity)：數(shù)據(jù)資源或來(lái)自服務(wù)資源的回映的一種特殊表示方法，它可能被包圍在一個(gè)請(qǐng)求或響應(yīng)信息中。一個(gè)實(shí)體包括實(shí)體頭信息和實(shí)體的本身內(nèi)容。
7.客戶機(jī)(Client)：一個(gè)為發(fā)送請(qǐng)求目的而建立連接的應(yīng)用程序。
8.用戶代理(Useragent)：初始化一個(gè)請(qǐng)求的客戶機(jī)。它們是瀏覽器、編輯器或其它用戶工具。
9.服務(wù)器(Server)：一個(gè)接受連接并對(duì)請(qǐng)求返回信息的應(yīng)用程序。
10.源服務(wù)器(Originserver)：是一個(gè)給定資源可以在其上駐留或被創(chuàng)建的服務(wù)器。
11.代理(Proxy)：一個(gè)中間程序，它可以充當(dāng)一個(gè)服務(wù)器，也可以充當(dāng)一個(gè)客戶機(jī)，為其它客戶機(jī)建立請(qǐng)求。請(qǐng)求是通過(guò)可能的翻譯在內(nèi)部或經(jīng)過(guò)傳遞到其它的服務(wù)器中。一個(gè)代理在發(fā)送請(qǐng)求信息之前，必須解釋并且如果可能重寫(xiě)它。
代理經(jīng)常作為通過(guò)防火墻的客戶機(jī)端的門(mén)戶，代理還可以作為一個(gè)幫助應(yīng)用來(lái)通過(guò)協(xié)議處理沒(méi)有被用戶代理完成的請(qǐng)求。
12.網(wǎng)關(guān)(Gateway)：一個(gè)作為其它服務(wù)器中間媒介的服務(wù)器。與代理不同的是，網(wǎng)關(guān)接受請(qǐng)求就好象對(duì)被請(qǐng)求的資源來(lái)說(shuō)它就是源服務(wù)器；發(fā)出請(qǐng)求的客戶機(jī)并沒(méi)有意識(shí)到它在同網(wǎng)關(guān)打交道。
網(wǎng)關(guān)經(jīng)常作為通過(guò)防火墻的服務(wù)器端的門(mén)戶，網(wǎng)關(guān)還可以作為一個(gè)協(xié)議翻譯器以便存取那些存儲(chǔ)在非HTTP系統(tǒng)中的資源。
13.通道(Tunnel)：是作為兩個(gè)連接中繼的中介程序。一旦激活，通道便被認(rèn)為不屬于HTTP通訊，盡管通道可能是被一個(gè)HTTP請(qǐng)求初始化的。當(dāng)被中繼的連接兩端關(guān)閉時(shí)，通道便消失。當(dāng)一個(gè)門(mén)戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時(shí)通道被經(jīng)常使用。
14.緩存(Cache)：反應(yīng)信息的局域存儲(chǔ)。
1.2.2 http協(xié)議結(jié)構(gòu)
HTTP報(bào)文由從客戶機(jī)到服務(wù)器的請(qǐng)求和從服務(wù)器到客戶機(jī)的響應(yīng)構(gòu)成。
請(qǐng)求報(bào)文格式如下：
請(qǐng)求行 通用信息頭 請(qǐng)求頭 實(shí)體頭 報(bào)文主體
表3.1
請(qǐng)求行以方法字段開(kāi)始，后面分別是 URL 字段和 HTTP 協(xié)議版本字段，并以 CRLF 結(jié)尾。SP 是分隔符。除了在最后的 CRLF 序列中 CF 和 LF 是必需的之外，其他都可以不要。有關(guān)通用信息頭，請(qǐng)求頭和實(shí)體頭方面的具體內(nèi)容可以參照相關(guān)文件。
響應(yīng)報(bào)文格式如下：
狀態(tài)行 通用信息頭 請(qǐng)求頭 實(shí)體頭 報(bào)文主體
表3.2
狀態(tài)碼元由3位數(shù)字組成，表示請(qǐng)求是否被理解或被滿足。原因分析是對(duì)原文的狀態(tài)碼作簡(jiǎn)短的描述，狀態(tài)碼用來(lái)支持自動(dòng)操作，而原因分析用來(lái)供用戶使用?？蛻魴C(jī)無(wú)需用來(lái)檢查或顯示語(yǔ)法。有關(guān)通用信息頭，響應(yīng)頭和實(shí)體頭方面的具體內(nèi)容可以參照相關(guān)文件。
HTTP（HyperTextTransferProtocol）
HTTP（HyperTextTransferProtocol）是超文本傳輸協(xié)議的縮寫(xiě)，它用于傳送WWW方式的數(shù)據(jù)，關(guān)于HTTP協(xié)議的詳細(xì)內(nèi)容請(qǐng)參考RFC2616。HTTP協(xié)議采用了請(qǐng)求/響應(yīng)模型?？蛻舳讼蚍?wù)器發(fā)送一個(gè)請(qǐng)求，請(qǐng)求頭包含請(qǐng)求的方法、URI、協(xié)議版本、以及包含請(qǐng)求修飾符、客戶信息和內(nèi)容的類(lèi)似于MIME的消息結(jié)構(gòu)。服務(wù)器以一個(gè)狀態(tài)行作為響應(yīng)，相應(yīng)的內(nèi)容包括消息協(xié)議的版本，成功或者錯(cuò)誤編碼加上包含服務(wù)器信息、實(shí)體元信息以及可能的實(shí)體內(nèi)容。
通常HTTP消息包括客戶機(jī)向服務(wù)器的請(qǐng)求消息和服務(wù)器向客戶機(jī)的響應(yīng)消息。這兩種類(lèi)型的消息由一個(gè)起始行，一個(gè)或者多個(gè)頭域，一個(gè)只是頭域結(jié)束的空行和可選的消息體組成。HTTP的頭域包括通用頭，請(qǐng)求頭，響應(yīng)頭和實(shí)體頭四個(gè)部分。每個(gè)頭域由一個(gè)域名，冒號(hào)（:）和域值三部分組成。域名是大小寫(xiě)無(wú)關(guān)的，域值前可以添加任何數(shù)量的空格符，頭域可以被擴(kuò)展為多行，在每行開(kāi)始處，使用至少一個(gè)空格或制表符。
通用頭域
通用頭域包含請(qǐng)求和響應(yīng)消息都支持的頭域，通用頭域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。對(duì)通用頭域的擴(kuò)展要求通訊雙方都支持此擴(kuò)展，如果存在不支持的通用頭域，一般將會(huì)作為實(shí)體頭域處理。下面簡(jiǎn)單介紹幾個(gè)在UPnP消息中使用的通用頭域。
Cache-Control頭域
Cache-Control指定請(qǐng)求和響應(yīng)遵循的緩存機(jī)制。在請(qǐng)求消息或響應(yīng)消息中設(shè)置Cache-Control并不會(huì)修改另一個(gè)消息處理過(guò)程中的緩存處理過(guò)程。請(qǐng)求時(shí)的緩存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，響應(yīng)消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。各個(gè)消息中的指令含義如下：
Public指示響應(yīng)可被任何緩存區(qū)緩存。
Private指示對(duì)于單個(gè)用戶的整個(gè)或部分響應(yīng)消息，不能被共享緩存處理。這允許服務(wù)器僅僅描述當(dāng)用戶的部分響應(yīng)消息，此響應(yīng)消息對(duì)于其他用戶的請(qǐng)求無(wú)效。
no-cache指示請(qǐng)求或響應(yīng)消息不能緩存
no-store用于防止重要的信息被無(wú)意的發(fā)布。在請(qǐng)求消息中發(fā)送將使得請(qǐng)求和響應(yīng)消息都不使用緩存。
max-age指示客戶機(jī)可以接收生存期不大于指定時(shí)間（以秒為單位）的響應(yīng)。
min-fresh指示客戶機(jī)可以接收響應(yīng)時(shí)間小于當(dāng)前時(shí)間加上指定時(shí)間的響應(yīng)。
max-stale指示客戶機(jī)可以接收超出超時(shí)期間的響應(yīng)消息。如果指定max-stale
息的值，那么客戶機(jī)可以接收超出超時(shí)期指定值之內(nèi)的響應(yīng)消息。
Date頭域
Date頭域表示消息發(fā)送的時(shí)間，時(shí)間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時(shí)間表示世界標(biāo)準(zhǔn)時(shí)，換算成本地時(shí)間，需要知道用戶所在的時(shí)區(qū)。
Pragma頭域
Pragma頭域用來(lái)包含實(shí)現(xiàn)特定的指令，最常用的是Pragma:no-cache。在HTTP/1.1協(xié)議中，它的含義和Cache-Control:no-cache相同。
請(qǐng)求消息
請(qǐng)求消息的第一行為下面的格式：
MethodSPRequest-URISPHTTP-VersionCRLFMethod表示對(duì)于Request-URI完成的方法，這個(gè)字段是大小寫(xiě)敏感的，包括OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。方法GET和HEAD應(yīng)該被所有的通用WEB服務(wù)器支持，其他所有方法的實(shí)現(xiàn)是可選的。GET方法取回由Request-URI標(biāo)識(shí)的信息。HEAD方法也是取回由Request-URI標(biāo)識(shí)的信息，只是可以在響應(yīng)時(shí)，不返回消息體。POST方法可以請(qǐng)求服務(wù)器接收包含在請(qǐng)求中的實(shí)體信息，可以用于提交表單，向新聞組、BBS、郵件群組和數(shù)據(jù)庫(kù)發(fā)送消息。
SP表示空格。Request-URI遵循URI格式，在此字段為星號(hào)（*）時(shí)，說(shuō)明請(qǐng)求并不用于某個(gè)特定的資源地址，而是用于服務(wù)器本身。HTTP-Version表示支持的HTTP版本，例如為HTTP/1.1。CRLF表示換行回車(chē)符。請(qǐng)求頭域允許客戶端向服務(wù)器傳遞關(guān)于請(qǐng)求或者關(guān)于客戶機(jī)的附加信息。
請(qǐng)求頭域可能包含下列字段Accept、Accept-Charset、Accept-Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If-Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。對(duì)請(qǐng)求頭域的擴(kuò)展要求通訊雙方都支持，如果存在不支持的請(qǐng)求頭域，一般將會(huì)作為實(shí)體頭域處理。
典型的請(qǐng)求消息：
GEThttp://class/download.microtool.de:80/somedata.exe
Host:download.microtool.de
Accept:*/*
Pragma:no-cache
Cache-Control:no-cache
Referer:http://class/download.microtool.de/
User-Agent:Mozilla/4.04[en](Win95;I;Nav)
Range:bytes=554554-
Host頭域
Host頭域指定請(qǐng)求資源的Intenet主機(jī)和端口號(hào)，必須表示請(qǐng)求url的原始服務(wù)器或網(wǎng)關(guān)的位置。HTTP/1.1請(qǐng)求必須包含主機(jī)頭域，否則系統(tǒng)會(huì)以400狀態(tài)碼返回。
Referer頭域
Referer頭域允許客戶端指定請(qǐng)求uri的源資源地址，這可以允許服務(wù)器生成回退鏈表，可用來(lái)登陸、優(yōu)化cache等。他也允許廢除的或錯(cuò)誤的連接由于維護(hù)的目的被追蹤。如果請(qǐng)求的uri沒(méi)有自己的uri地址，Referer不能被發(fā)送。如果指定的是部分uri地址，則此地址應(yīng)該是一個(gè)相對(duì)地址。
Range頭域
Range頭域可以請(qǐng)求實(shí)體的一個(gè)或者多個(gè)子范圍。例如，
表示頭500個(gè)字節(jié)：bytes=0-499
表示第二個(gè)500字節(jié)：bytes=500-999
表示最后500個(gè)字節(jié)：bytes=-500
表示500字節(jié)以后的范圍：bytes=500-
第一個(gè)和最后一個(gè)字節(jié)：bytes=0-0,-1
同時(shí)指定幾個(gè)范圍：bytes=500-600,601-999
但是服務(wù)器可以忽略此請(qǐng)求頭，如果無(wú)條件GET包含Range請(qǐng)求頭，響應(yīng)會(huì)以狀態(tài)碼206（PartialContent）返回而不是以200（OK）。
User-Agent頭域
User-Agent頭域的內(nèi)容包含發(fā)出請(qǐng)求的用戶信息。
響應(yīng)消息
響應(yīng)消息的第一行為下面的格式：
HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF
HTTP-Version表示支持的HTTP版本，例如為HTTP/1.1。Status-Code是一個(gè)三個(gè)數(shù)字的結(jié)果代碼。Reason-Phrase給Status-Code提供一個(gè)簡(jiǎn)單的文本描述。Status-Code主要用于機(jī)器自動(dòng)識(shí)別，Reason-Phrase主要用于幫助用戶理解。Status-Code的第一個(gè)數(shù)字定義響應(yīng)的類(lèi)別，后兩個(gè)數(shù)字沒(méi)有分類(lèi)的作用。第一個(gè)數(shù)字可能取5個(gè)不同的值：
1xx:信息響應(yīng)類(lèi)，表示接收到請(qǐng)求并且繼續(xù)處理
2xx:處理成功響應(yīng)類(lèi)，表示動(dòng)作被成功接收、理解和接受
3xx:重定向響應(yīng)類(lèi)，為了完成指定的動(dòng)作，必須接受進(jìn)一步處理
4xx:客戶端錯(cuò)誤，客戶請(qǐng)求包含語(yǔ)法錯(cuò)誤或者是不能正確執(zhí)行
5xx:服務(wù)端錯(cuò)誤，服務(wù)器不能正確執(zhí)行一個(gè)正確的請(qǐng)求
響應(yīng)頭域允許服務(wù)器傳遞不能放在狀態(tài)行的附加信息，這些域主要描述服務(wù)器的信息和Request-URI進(jìn)一步的信息。響應(yīng)頭域包含Age、Location、Proxy-Authenticate、Public、Retry-After、Server、Vary、Warning、WWW-Authenticate。對(duì)響應(yīng)頭域的擴(kuò)展要求通訊雙方都支持，如果存在不支持的響應(yīng)頭域，一般將會(huì)作為實(shí)體頭域處理。
典型的響應(yīng)消息：
HTTP/1.0200OK
Date:Mon,31Dec200104:25:57GMT
Server:Apache/1.3.14(Unix)
Content-type:text/html
Last-modified:Tue,17Apr200106:46:28GMT
Etag:"a030f020ac7c01:1e9f"
Content-length:39725426
Content-range:bytes554554-40279979/40279980
Location響應(yīng)頭
Location響應(yīng)頭用于重定向接收者到一個(gè)新URI地址。
Server響應(yīng)頭
Server響應(yīng)頭包含處理請(qǐng)求的原始服務(wù)器的軟件信息。此域能包含多個(gè)產(chǎn)品標(biāo)識(shí)和注釋?zhuān)a(chǎn)品標(biāo)識(shí)一般按照重要性排序。
實(shí)體
請(qǐng)求消息和響應(yīng)消息都可以包含實(shí)體信息，實(shí)體信息一般由實(shí)體頭域和實(shí)體組成。實(shí)體頭域包含關(guān)于實(shí)體的原信息，實(shí)體頭包括Allow、Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、Etag、Expires、Last-Modified、extension-header。extension-header允許客戶端定義新的實(shí)體頭，但是這些域可能無(wú)法未接受方識(shí)別。實(shí)體可以是一個(gè)經(jīng)過(guò)編碼的字節(jié)流，它的編碼方式由Content-Encoding或Content-Type定義，它的長(zhǎng)度由Content-Length或Content-Range定義。
Content-Type實(shí)體頭
Content-Type實(shí)體頭用于向接收方指示實(shí)體的介質(zhì)類(lèi)型，指定HEAD方法送到接收方的實(shí)體介質(zhì)類(lèi)型，或GET方法發(fā)送的請(qǐng)求介質(zhì)類(lèi)型Content-Range實(shí)體頭Content-Range實(shí)體頭用于指定整個(gè)實(shí)體中的一部分的插入位置，他也指示了整個(gè)實(shí)體的長(zhǎng)度。在服務(wù)器向客戶返回一個(gè)部分響應(yīng)，它必須描述響應(yīng)覆蓋的范圍和整個(gè)實(shí)體長(zhǎng)度。一般格式：
Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth
例如，傳送頭500個(gè)字節(jié)次字段的形式：Content-Range:bytes0-499/1234如果一個(gè)http消息包含此節(jié)（例如，對(duì)范圍請(qǐng)求的響應(yīng)或?qū)σ幌盗蟹秶闹丿B請(qǐng)求），Content-Range表示傳送的范圍，Content-Length表示實(shí)際傳送的字節(jié)數(shù)。
Last-modified實(shí)體頭
Last-modified實(shí)體頭指定服務(wù)器上保存內(nèi)容的最后修訂時(shí)間。
1.2.3 http協(xié)議的運(yùn)作方式
HTTP協(xié)議是基于請(qǐng)求／響應(yīng)范式的。一個(gè)客戶機(jī)與服務(wù)器建立連接后，發(fā)送一個(gè)請(qǐng)求給服務(wù)器，請(qǐng)求方式的格式為，統(tǒng)一資源標(biāo)識(shí)符、協(xié)議版本號(hào)，后邊是MIME信息包括請(qǐng)求修飾符、客戶機(jī)信息和可能的內(nèi)容。服務(wù)器接到請(qǐng)求后，給予相應(yīng)的響應(yīng)信息，其格式為一個(gè)狀態(tài)行包括信息的協(xié)議版本號(hào)、一個(gè)成功或錯(cuò)誤的代碼，后邊是MIME信息包括服務(wù)器信息、實(shí)體信息和可能的內(nèi)容。
許多HTTP通訊是由一個(gè)用戶代理初始化的并且包括一個(gè)申請(qǐng)?jiān)谠捶?wù)器上資源的請(qǐng)求。最簡(jiǎn)單的情況可能是在用戶代理(UA)和源服務(wù)器(O)之間通過(guò)一個(gè)單獨(dú)的連接來(lái)完成(見(jiàn)圖1.1)。
圖1.1
當(dāng)一個(gè)或多個(gè)中介出現(xiàn)在請(qǐng)求／響應(yīng)鏈中時(shí)，情況就變得復(fù)雜一些。中介由三種：代理(Proxy)、網(wǎng)關(guān)(Gateway)和通道(Tunnel)。一個(gè)代理根據(jù)URI的絕對(duì)格式來(lái)接受請(qǐng)求，重寫(xiě)全部或部分消息，通過(guò)URI的標(biāo)識(shí)把已格式化過(guò)的請(qǐng)求發(fā)送到服務(wù)器。網(wǎng)關(guān)是一個(gè)接收代理，作為一些其它服務(wù)器的上層，并且如果必須的話，可以把請(qǐng)求翻譯給下層的服務(wù)器協(xié)議。一個(gè)通道作為不改變消息的兩個(gè)連接之間的中繼點(diǎn)。當(dāng)通訊需要通過(guò)一個(gè)中介(例如：防火墻等)或者是中介不能識(shí)
別消息的內(nèi)容時(shí)，通道經(jīng)常被使用。
圖1.2
上面的圖1.2表明了在用戶代理(UA)和源服務(wù)器(O)之間有三個(gè)中介(A,B和C)。一個(gè)通過(guò)整個(gè)鏈的請(qǐng)求或響應(yīng)消息必須經(jīng)過(guò)四個(gè)連接段。這個(gè)區(qū)別是重要的，因?yàn)橐恍〩TTP通訊選擇可能應(yīng)用于最近的連接、沒(méi)有通道的鄰居，應(yīng)用于鏈的終點(diǎn)或應(yīng)用于沿鏈的所有連接。盡管圖1.2是線性的，每個(gè)參與者都可能從事多重的、并發(fā)的通訊。例如，B可能從許多客戶機(jī)接收請(qǐng)求而不通過(guò)A，并且／或者不通過(guò)C把請(qǐng)求送到A，在同時(shí)它還可能處理A的請(qǐng)求。
任何針對(duì)不作為通道的匯聚可能為處理請(qǐng)求啟用一個(gè)內(nèi)部緩存。緩存的效果是請(qǐng)求／響應(yīng)鏈被縮短，條件是沿鏈的參與者之一具有一個(gè)緩存的響應(yīng)作用于那個(gè)請(qǐng)求。下圖說(shuō)明結(jié)果鏈，其條件是針對(duì)一個(gè)未被UA或A加緩存的請(qǐng)求，B有一個(gè)經(jīng)過(guò)C來(lái)自O(shè)的一個(gè)前期響應(yīng)的緩存拷貝。
圖1.3
在Internet上，HTTP通訊通常發(fā)生在TCP/IP連接之上。缺省端口是TCP80，但其它的端口也是可用的。但這并不預(yù)示著HTTP協(xié)議在Internet或其它網(wǎng)絡(luò)的其它協(xié)議之上才能完成。HTTP只預(yù)示著一個(gè)可靠的傳輸。
以上簡(jiǎn)要介紹了HTTP協(xié)議的宏觀運(yùn)作方式，下面介紹一下HTTP協(xié)議的內(nèi)部操作過(guò)程。
首先，簡(jiǎn)單介紹基于HTTP協(xié)議的客戶/服務(wù)器模式的信息交換過(guò)程，如圖1.4所示，它分四個(gè)過(guò)程，建立連接、發(fā)送請(qǐng)求信息、發(fā)送響應(yīng)信息、關(guān)閉連接。
圖1.4
圖1.4
在WWW中，“客戶”與“服務(wù)器”是一個(gè)相對(duì)的概念，只存在于一個(gè)特定的連接期間，即在某個(gè)連接中的客戶在另一個(gè)連接中可能作為服務(wù)器。WWW服務(wù)器運(yùn)行時(shí)，一直在TCP80端口(WWW的缺省端口)監(jiān)聽(tīng)，等待連接的出現(xiàn)。
下面，討論HTTP協(xié)議下客戶/服務(wù)器模式中信息交換的實(shí)現(xiàn)?！ ?br>1.建立連接 連接的建立是通過(guò)申請(qǐng)?zhí)捉幼?Socket)實(shí)現(xiàn)的。客戶打開(kāi)一個(gè)套接字并把它約束在一個(gè)端口上，如果成功，就相當(dāng)于建立了一個(gè)虛擬文件。以后就可以在該虛擬文件上寫(xiě)數(shù)據(jù)并通過(guò)網(wǎng)絡(luò)向外傳送。
2.發(fā)送請(qǐng)求
打開(kāi)一個(gè)連接后，客戶機(jī)把請(qǐng)求消息送到服務(wù)器的停留端口上，完成提出請(qǐng)求動(dòng)作。
HTTP/1.0 請(qǐng)求消息的格式為：
請(qǐng)求消息=請(qǐng)求行(通用信息|請(qǐng)求頭|實(shí)體頭)CRLF[實(shí)體內(nèi)容]
請(qǐng)求 行=方法 請(qǐng)求URL HTTP版本號(hào) CRLF
方 法=GET|HEAD|POST|擴(kuò)展方法
U R L=協(xié)議名稱(chēng)+宿主名+目錄與文件名
請(qǐng)求行中的方法描述指定資源中應(yīng)該執(zhí)行的動(dòng)作，常用的方法有GET、HEAD和POST。不同的請(qǐng)求對(duì)象對(duì)應(yīng)GET的結(jié)果是不同的，對(duì)應(yīng)關(guān)系如下：
對(duì)象 GET的結(jié)果
文件 文件的內(nèi)容
程序 該程序的執(zhí)行結(jié)果
數(shù)據(jù)庫(kù)查詢(xún) 查詢(xún)結(jié)果
HEAD——要求服務(wù)器查找某對(duì)象的元信息，而不是對(duì)象本身。
POST——從客戶機(jī)向服務(wù)器傳送數(shù)據(jù)，在要求服務(wù)器和CGI做進(jìn)一步處理時(shí)會(huì)用到POST方法。POST主要用于發(fā)送HTML文本中FORM的內(nèi)容，讓CGI程序處理。
一個(gè)請(qǐng)求的例子為：
GEThttp://networking.zju.edu.cn/zju/index.htmHTTP/1.0
頭信息又稱(chēng)為元信息，即信息的信息，利用元信息可以實(shí)現(xiàn)有條件的請(qǐng)求或應(yīng)答。
請(qǐng)求頭——告訴服務(wù)器怎樣解釋本次請(qǐng)求，主要包括用戶可以接受的數(shù)據(jù)類(lèi)型、壓縮方法和語(yǔ)言等。
實(shí)體頭——實(shí)體信息類(lèi)型、長(zhǎng)度、壓縮方法、最后一次修改時(shí)間、數(shù)據(jù)有效期等。
實(shí)體——請(qǐng)求或應(yīng)答對(duì)象本身。
3.發(fā)送響應(yīng)
服務(wù)器在處理完客戶的請(qǐng)求之后，要向客戶機(jī)發(fā)送響應(yīng)消息。
HTTP/1.0的響應(yīng)消息格式如下：
響應(yīng)消息=狀態(tài)行(通用信息頭|響應(yīng)頭|實(shí)體頭) CRLF 〔實(shí)體內(nèi)容〕
狀態(tài)行=HTTP版本號(hào) 狀態(tài)碼 原因敘述
狀態(tài)碼表示響應(yīng)類(lèi)型
1×× 保留
2×× 表示請(qǐng)求成功地接收
3×× 為完成請(qǐng)求客戶需進(jìn)一步細(xì)化請(qǐng)求
4×× 客戶錯(cuò)誤
5×× 服務(wù)器錯(cuò)誤
響應(yīng)頭的信息包括：服務(wù)程序名，通知客戶請(qǐng)求的URL需要認(rèn)證，請(qǐng)求的資源何時(shí)能使用。
4.關(guān)閉連接
客戶和服務(wù)器雙方都可以通過(guò)關(guān)閉套接字來(lái)結(jié)束TCP/IP對(duì)話
1.3 基于http協(xié)議的網(wǎng)絡(luò)行為監(jiān)視
1.3.1 http協(xié)議的安全因素
HTTP協(xié)議存在許多的安全漏洞，這些安全漏洞之一就是允許遠(yuǎn)程用戶向遠(yuǎn)程服務(wù)器請(qǐng)求連接，并且執(zhí)行遠(yuǎn)程命令。這個(gè)安全漏洞可以以許多方式損壞web服務(wù)器和客戶機(jī)，包括但不局限于如下這些：
對(duì)遠(yuǎn)程請(qǐng)求的武斷認(rèn)證。
對(duì)web服務(wù)器的武斷認(rèn)證。
破壞請(qǐng)求和應(yīng)答的保密性。
濫用服務(wù)器功能和資源。
通過(guò)搜索它的程序錯(cuò)誤和安全漏洞，濫用服務(wù)器。
濫用日志信息（提取IP地址、域名和文件名等等）。
許多這樣的安全漏洞是眾所周知的，一些應(yīng)用程序，如Netscape的SSL和NCSA的SHTTP XE“S-HTTP”試圖解決這些問(wèn)題，但僅僅是其中的一部分問(wèn)題。問(wèn)題是，在internet上，web服務(wù)器對(duì)客戶的行為顯得很脆弱。因此需要對(duì)其監(jiān)視。
1.3.2 基于http協(xié)議監(jiān)視的實(shí)現(xiàn)
在CSMA／CD(Carrier Sense Multiple Access/Collision Detection，載波偵聽(tīng)多路訪問(wèn)沖突檢測(cè))網(wǎng)絡(luò)下，監(jiān)視網(wǎng)絡(luò)上流動(dòng)的數(shù)據(jù)包，捕捉我們感興趣的數(shù)據(jù)包，對(duì)感興趣的數(shù)據(jù)包進(jìn)行分析和研究，分析出其所遵守的協(xié)議，進(jìn)一步得到其應(yīng)用層數(shù)據(jù)，并在需要的情況下將其數(shù)據(jù)進(jìn)行重組，恢復(fù)到被監(jiān)視用戶所看到的格式，為進(jìn)行更深一步的分析和研究打下基礎(chǔ)。
網(wǎng)絡(luò)監(jiān)視器實(shí)現(xiàn)的一個(gè)前提條件是必須能夠“聽(tīng)到”網(wǎng)路上所有的數(shù)據(jù)包，假如網(wǎng)卡僅能接收到屬于自己的數(shù)據(jù)包，也就無(wú)法實(shí)現(xiàn)監(jiān)視功能了。
因此，其實(shí)現(xiàn)的網(wǎng)絡(luò)應(yīng)當(dāng)是基于共享式的，而在CSMA／CD網(wǎng)絡(luò)上是可以使網(wǎng)卡接受到所有的數(shù)據(jù)包，所以我們將實(shí)現(xiàn)的網(wǎng)絡(luò)環(huán)境暫時(shí)局限于以太網(wǎng)上。在系統(tǒng)結(jié)構(gòu)設(shè)計(jì)上，網(wǎng)絡(luò)監(jiān)視器可以從下向上分為三層，分別實(shí)現(xiàn)不同的功能，位于最下層的為捕獲層，該層完成的功能是在基于CSMA／CD的網(wǎng)絡(luò)上截獲網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)包，這一部分是與平臺(tái)相關(guān)的，這是因?yàn)獒槍?duì)不同的操作系統(tǒng)平臺(tái)，其網(wǎng)絡(luò)的軟件體系結(jié)構(gòu)也大不相同，無(wú)論是DOS下的PktDrv驅(qū)動(dòng)程序模型，還Windows下NDIS(Network Driver Interface Specification)結(jié)構(gòu)模型，其處理的過(guò)程以及驅(qū)動(dòng)程序的結(jié)構(gòu)都不一樣，因此想為它們?cè)O(shè)計(jì)一個(gè)通用的捕獲包組件是不太可能的，必須針對(duì)不同操作系統(tǒng)的不同特點(diǎn)設(shè)計(jì)不同的組件，以滿足它們特有的需要。為了能夠在添加新的操作系統(tǒng)支持時(shí)不影響原有系統(tǒng)的實(shí)現(xiàn)，在該層的實(shí)現(xiàn)時(shí)，采用了Bridge的設(shè)計(jì)模式 ，它將Capturer(捕獲類(lèi))抽象和它的實(shí)現(xiàn)部分分別放在獨(dú)立的類(lèi)層次結(jié)構(gòu)中，其中一個(gè)類(lèi)層次結(jié)構(gòu)針對(duì)Capturer接口，另外一個(gè)獨(dú)立的類(lèi)層次結(jié)構(gòu)針對(duì)平臺(tái)相關(guān)的捕獲器實(shí)現(xiàn)部分，這個(gè)類(lèi)層次結(jié)構(gòu)的根類(lèi)為Capturerlmp；位于捕獲層之上的為分析層，該層主要是對(duì)數(shù)據(jù)包所包含的內(nèi)容進(jìn)行分析，獲知其所用的協(xié)議和所包括的數(shù)據(jù)，這一部分只與特定的協(xié)議組有關(guān)，而和操作系統(tǒng)平臺(tái)無(wú)關(guān)，事實(shí)上，對(duì)于TCP／IP協(xié)議，無(wú)論是在Unix或DOS，還是在Windows下，它們的分析和重組都是完全一樣的，所以，這部分可以設(shè)計(jì)為一個(gè)通用組件；最上面一層為重組層，該層對(duì)一些常用的協(xié)議進(jìn)行會(huì)話恢復(fù)，以得知會(huì)話的全過(guò)程，這一部分同第二部分一樣也是與平臺(tái)無(wú)關(guān)的。
關(guān)鍵技術(shù)將在下面的章節(jié)做詳細(xì)介紹，包括數(shù)據(jù)包的捕獲、重組、分析、解碼還原等過(guò)程。
