摘要：在因特網日益發展壯大的今天，萬維網在其上的通信量已經超過90%，萬維網信息的安全問題已經越來越被人們所重視，而作爲萬維網應用層核心協議的http協議是基礎。當網絡發生異常時，對網絡上傳輸的數據進行監視和分析，是網管人員解決網絡故障的一種常用方法。
本文介紹應用層HTTP數據包的截獲與還原技術的實現,並簡要介紹其中所涉及的數據包截獲、數據包分析、應用數據重組以及數據包解碼等關鍵技術。該系統可以監聽網管人員感興趣的數據包，通過對其進行分析和研究，分析出其遵守的協議以及其應用層數據，恢復到被監視用戶所看到數據的格式。該系統的實現，爲網管人員有效地管理網絡提供了一種直觀的工具。
關鍵詞：http數據包； 截獲； 還原
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網絡數據包截獲與還原的理論基礎 2
1.1 網絡體系結構 2
1.1.1 網絡參考模型概述 2
1.1.2 TCP/IP協議族 3
1.2 HTTP協議概述 4
1.2.1 http協議的幾個重要概念 5
1.2.2 http協議結構 6
1.2.3 http協議的運作方式 12
1.3 基於HTTP協議的網絡行爲監視 16
1.3.1 http協議的安全因素 16
1.3.2 基於http協議監視的實現 17
第二章 開發工具與環境配置 19
2.1 JAVA語言介紹 19
2.1.1 平臺無關性 19
2.1.2 面向對象 20
2.1.3 安全穩定 21
2.1.4 支持多線程 22
2.2 JDK概述 22
2.2.1 Java開發工具JDK 介紹 22
2.2.2 開發環境配置 23
第三章 HTTP數據包截獲 24
3.1 HTTP數據包截獲模塊設計 24
3.1.1 體系結構設計 24
3.1.2 WinPcap工具 25
3.1.3 Packet.dll 26
3.1.4 Jpcap類庫 28
3.2 數據包的存儲 29
3.3 數據包捕獲和存儲流程圖 32
3.4 數據包捕獲和存儲程序片斷 32
第四章 HTTP數據包信息的分析與還原 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 捕獲數據包信息的分析 38
4.2.1 捕獲數據數據包的重組分析 38
4.2.2 捕獲數據包編碼格式的分析 40
4.2.3 捕獲數據的分析的程序片段 40
4.3 對捕獲數據包信息的部分還原 41
4.3.1 捕獲數據包信息還原的流程圖 41
4.3.2 捕獲數據包的信息還原算法 42
第五章 總結 52
參 考 文 獻 54
謝 辭 55
前言
在短短的二十幾年時間裏,萬維網(Word Wide Web)從一種發佈高能物理數據的方式演變爲如今人們頭腦中的因特網,它之所以如此流行是由於它有一個豐富多彩的界面,初學者很容易使用,並且提供了大量的信息資源,幾乎涉及人們所能想象的所有主題。
HTTP是一個屬於應用層的面向對象的協議，而http協議作爲www的主要協議,由於其簡捷、快速的方式，適用於分佈式超媒體信息系統。它於1990年提出，經過幾年的使用與發展，得到不斷地完善和擴展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規範化工作正在進行之中，而且HTTP-NG(NextGenerationofHTTP)的建議已經提出。
但HTTP協議存在許多安全漏洞，比如說允許遠程用戶向遠程服務器請求連接,並且執行遠程命令.這個安全漏洞可以以許多方式損壞Web服務器和客戶機，這些危害信息還包括對遠程請求的武斷認證；破壞請求和應答的保密性；濫用服務器功能和資源等。而在網絡上傳送的不良信息，也影響人們的身心健康，包括色情、迷信和暴力等信息。對危害信息和不良信息在應用層的還原可以很明確的知道該信息傳送的具體信息，具有很直觀的效果，可以幫助網絡管理人員較好的監視網絡。對於網絡數據包的截獲和還原是網絡行爲監視的一部分，本文主要介紹HTTP數據包的截獲與還原技術，該技術涉及到數據包截獲、數據包分析、應用數據重組和字符編碼解碼等關鍵技術。該技術的實現可以幫助網管人員監聽感興趣的HTTP數據包，分析出其遵守的協議以及其應用層數據，同時將應用層數據進行重組，恢復到原始的數據格式，達到與被監視用戶相同的顯示效果。該系統的實現，爲網管人員有效地管理網絡提供了一種直觀的工具。
本文所介紹的基於HTTP協議的截獲和還原信息主要是萬維網信息，而這些信息包括文本、圖象和聲音等，本文主要是針對文本信息的還原，而大多數的嗅探器並不支持的數據在應用層的還原。本文所提出的應用層數據的還原技術是針對大多數嗅探器的侷限性提出來的。
第一章 http網絡數據包截獲與還原的理論基礎
1.1 網絡體系結構
1.1.1 網絡參考模型概述
OSI的七層協議體系結構既複雜又不實用，但其概念清楚，體系結構理論較完整。TCP/IP的協議現在得到了廣泛的應用，但它原先並沒有一個明確的體系結構。TCP/IP是一個四層的體系結構，它包含應用層、運輸層、網際層和網絡結構層。不過從實質上講，TCP/IP只有三層，即應用層、運輸層和網際層，因爲最下面的網絡接口層並沒有什麼具體內容。
下面的圖片反應了兩臺計算機進行通信時的各層數據流結構。
圖1.1
應用層 應用層是體系結構中的最高層。應用層確定進程之間通信的性質以滿足用戶的需要。應用層不僅要提供應用進程所需要的信息交換和遠地操作，而且還要作爲相互作用的應用進程的用戶代理，來完成一些爲進行語義上有意義的信息交換所必須的功能。應用層直接爲用戶的應用進程提供服務。在因特網中的應用層協議很多，如支持萬維網應用的HTTP協議，支持電子郵件的SMTP協議，支持文件傳輸的FTP協議等等。
運輸層 運輸層的任務就是負責主機中兩個進程之間的通信。
因特網的運輸層可使用兩種不同協議。即面向連接的傳輸控制協議TCP，和無連接的用戶數據報協議UDP。面向連接的服務能夠提供可靠的交付，但無連接服務則不保證提供可靠的交付，它只是“盡最大努力交付”。這兩種服務方式都很有用，各有其優缺點。
在分組交換網內的各個交換接點機都沒有運輸層。運輸層只能存在於分組交換網外面的主機之中。運輸層以上的各層就不再關心信息傳輸的問題了。正因爲如此，運輸層就成爲計算機網絡體系結構中非常重要的一層。
網絡層 網絡層負責爲分組交換網上的不同主機提供通信。在發送數據時，網絡層將運輸層產生的報文段或用戶數據報封裝成分組或包進行傳送。在TCP/IP體系中，分組也叫作IP數據報，或簡稱爲數據報。
因特網是一個很大的互聯網，它由大量的異構網絡通過路由器相互連接起來。因特網主要的網絡協議是無連接的網際協議IP和許多路由選擇協議，因此因特網的網絡層也叫網際層或IP層。
數據鏈路層 在發送數據時，數據鏈路層的任務是將在網絡層交下來的IP數據報組裝成幀，在兩個相鄰接點間的鏈路上傳送以幀爲單位的數據。每一幀包括數據和必要的控制信息。控制信息使接受端能夠知道一個幀從哪個比特開始和到哪個比特結束。控制信息還使接受端能夠檢測到所收到的幀中有無差錯。如發現有差錯，數據鏈路層就丟棄這個出了差錯的幀。
物理層 物理層的任務是透明地傳送比特流。在物理層上所傳數據的單位是比特。傳遞信息所利用的一些物理媒體，如雙絞線、同軸電纜、光纜，並不在物理層之內而是在物理層的下面。
1.1.2 TCP/IP協議族
TCP/IP協議族（如下圖所示），它的特點是上下兩頭大而中間小：應用層和網絡接口層都有多種協議，而中間的IP層很小，上層的各種協議都向下匯聚到一個IP協議中。這種很象沙漏計時器形狀的TCP/IP協議族表明：TCP/IP可以爲各式各樣的應用提供服務，同時也可以連接到各式各樣的網絡上。正因爲如此，因特網纔會發展到今天的這種全球規模。
圖1.2
整個通信網絡的任務，可以劃分成不同的功能塊，即抽象成所謂的 ” 層” 。用於互聯網的協議可以比照TCP/IP參考模型進行分類。TCP/IP協議棧起始於第三層協議IP(互聯網協議) 。所有這些協議都在相應的RFC文檔中討論及標準化。重要的協議在相應的RFC文檔中均標記了狀態: “必須“ (required) ，“推薦“ (recommended) ，“可選“ (elective) 。其它的協議還可能有“ 試驗“(experimental) 或“ 歷史“(historic) 的狀態。
1.2 http協議概述
我們在瀏覽器的地址欄裏輸入的網站地址叫做URL(UniformResourceLocator，統一資源定位符)。就像每家每戶都有一個門牌地址一樣，每個網頁也都有一個Internet地址。當你在瀏覽器的地址框中輸入一個URL或是單擊一個超級鏈接時，URL就確定了要瀏覽的地址。瀏覽器通過超文本傳輸協議(HTTP)，將Web服務器上站點的網頁代碼提取出來，並翻譯成漂亮的網頁。
Internet的基本協議是TCP/IP協議，然而在TCP/IP模型最上層的是應用層(Applicationlayer)，它包含所有高層的協議。高層協議有：文件傳輸協議FTP、電子郵件傳輸協議SMTP、域名系統服務DNS、網絡新聞傳輸協議NNTP和HTTP協議等。
HTTP協議(Hypertext Transfer Protocol，超文本傳輸協議)是用於從WWW服務器傳輸超文本到本地瀏覽器的傳送協議。它可以使瀏覽器更加高效，使網絡傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內容首先顯示(如文本先於圖形)等。這就是你爲什麼在瀏覽器中看到的網頁地址都是以“http://”開頭的原因。
自WWW誕生以來，一個多姿多彩的資訊和虛擬的世界便出現在我們眼前，可是我們怎麼能夠更加容易地找到我們需要的資訊呢？當決定使用超文本作爲WWW文檔的標準格式後，於是在1990年，科學家們立即制定了能夠快速查找這些超文本文檔的協議，即HTTP協議。經過幾年的使用與發展，得到不斷的完善和擴展，目前在WWW中使用的是HTTP/1.0的第六版。
1.2.1 http協議的幾個重要概念
1.連接(Connection)：一個傳輸層的實際環流，它是建立在兩個相互通訊的應用程序之間。
2.消息(Message)：HTTP通訊的基本單位，包括一個結構化的八元組序列並通過連接傳輸。
3.請求(Request)：一個從客戶端到服務器的請求信息包括應用於資源的方法、資源的標識符和協議的版本號
4.響應(Response)：一個從服務器返回的信息包括HTTP協議的版本號、請求的狀態(例如“成功”或“沒找到”)和文檔的MIME類型。
5.資源(Resource)：由URI標識的網絡數據對象或服務。
6.實體(Entity)：數據資源或來自服務資源的回映的一種特殊表示方法，它可能被包圍在一個請求或響應信息中。一個實體包括實體頭信息和實體的本身內容。
7.客戶機(Client)：一個爲發送請求目的而建立連接的應用程序。
8.用戶代理(Useragent)：初始化一個請求的客戶機。它們是瀏覽器、編輯器或其它用戶工具。
9.服務器(Server)：一個接受連接並對請求返回信息的應用程序。
10.源服務器(Originserver)：是一個給定資源可以在其上駐留或被創建的服務器。
11.代理(Proxy)：一箇中間程序，它可以充當一個服務器，也可以充當一個客戶機，爲其它客戶機建立請求。請求是通過可能的翻譯在內部或經過傳遞到其它的服務器中。一個代理在發送請求信息之前，必須解釋並且如果可能重寫它。
代理經常作爲通過防火牆的客戶機端的門戶，代理還可以作爲一個幫助應用來通過協議處理沒有被用戶代理完成的請求。
12.網關(Gateway)：一個作爲其它服務器中間媒介的服務器。與代理不同的是，網關接受請求就好象對被請求的資源來說它就是源服務器；發出請求的客戶機並沒有意識到它在同網關打交道。
網關經常作爲通過防火牆的服務器端的門戶，網關還可以作爲一個協議翻譯器以便存取那些存儲在非HTTP系統中的資源。
13.通道(Tunnel)：是作爲兩個連接中繼的中介程序。一旦激活，通道便被認爲不屬於HTTP通訊，儘管通道可能是被一個HTTP請求初始化的。當被中繼的連接兩端關閉時，通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時通道被經常使用。
14.緩存(Cache)：反應信息的局域存儲。
1.2.2 http協議結構
HTTP報文由從客戶機到服務器的請求和從服務器到客戶機的響應構成。
請求報文格式如下：
請求行 通用信息頭 請求頭 實體頭 報文主體
表3.1
請求行以方法字段開始，後面分別是 URL 字段和 HTTP 協議版本字段，並以 CRLF 結尾。SP 是分隔符。除了在最後的 CRLF 序列中 CF 和 LF 是必需的之外，其他都可以不要。有關通用信息頭，請求頭和實體頭方面的具體內容可以參照相關文件。
響應報文格式如下：
狀態行 通用信息頭 請求頭 實體頭 報文主體
表3.2
狀態碼元由3位數字組成，表示請求是否被理解或被滿足。原因分析是對原文的狀態碼作簡短的描述，狀態碼用來支持自動操作，而原因分析用來供用戶使用。客戶機無需用來檢查或顯示語法。有關通用信息頭，響應頭和實體頭方面的具體內容可以參照相關文件。
HTTP（HyperTextTransferProtocol）
HTTP（HyperTextTransferProtocol）是超文本傳輸協議的縮寫，它用於傳送WWW方式的數據，關於HTTP協議的詳細內容請參考RFC2616。HTTP協議採用了請求/響應模型。客戶端向服務器發送一個請求，請求頭包含請求的方法、URI、協議版本、以及包含請求修飾符、客戶信息和內容的類似於MIME的消息結構。服務器以一個狀態行作爲響應，相應的內容包括消息協議的版本，成功或者錯誤編碼加上包含服務器信息、實體元信息以及可能的實體內容。
通常HTTP消息包括客戶機向服務器的請求消息和服務器向客戶機的響應消息。這兩種類型的消息由一個起始行，一個或者多個頭域，一個只是頭域結束的空行和可選的消息體組成。HTTP的頭域包括通用頭，請求頭，響應頭和實體頭四個部分。每個頭域由一個域名，冒號（:）和域值三部分組成。域名是大小寫無關的，域值前可以添加任何數量的空格符，頭域可以被擴展爲多行，在每行開始處，使用至少一個空格或製表符。
通用頭域
通用頭域包含請求和響應消息都支持的頭域，通用頭域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。對通用頭域的擴展要求通訊雙方都支持此擴展，如果存在不支持的通用頭域，一般將會作爲實體頭域處理。下面簡單介紹幾個在UPnP消息中使用的通用頭域。
Cache-Control頭域
Cache-Control指定請求和響應遵循的緩存機制。在請求消息或響應消息中設置Cache-Control並不會修改另一個消息處理過程中的緩存處理過程。請求時的緩存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，響應消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。各個消息中的指令含義如下：
Public指示響應可被任何緩存區緩存。
Private指示對於單個用戶的整個或部分響應消息，不能被共享緩存處理。這允許服務器僅僅描述當用戶的部分響應消息，此響應消息對於其他用戶的請求無效。
no-cache指示請求或響應消息不能緩存
no-store用於防止重要的信息被無意的發佈。在請求消息中發送將使得請求和響應消息都不使用緩存。
max-age指示客戶機可以接收生存期不大於指定時間（以秒爲單位）的響應。
min-fresh指示客戶機可以接收響應時間小於當前時間加上指定時間的響應。
max-stale指示客戶機可以接收超出超時期間的響應消息。如果指定max-stale
息的值，那麼客戶機可以接收超出超時期指定值之內的響應消息。
Date頭域
Date頭域表示消息發送的時間，時間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界標準時，換算成本地時間，需要知道用戶所在的時區。
Pragma頭域
Pragma頭域用來包含實現特定的指令，最常用的是Pragma:no-cache。在HTTP/1.1協議中，它的含義和Cache-Control:no-cache相同。
請求消息
請求消息的第一行爲下面的格式：
MethodSPRequest-URISPHTTP-VersionCRLFMethod表示對於Request-URI完成的方法，這個字段是大小寫敏感的，包括OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。方法GET和HEAD應該被所有的通用WEB服務器支持，其他所有方法的實現是可選的。GET方法取回由Request-URI標識的信息。HEAD方法也是取回由Request-URI標識的信息，只是可以在響應時，不返回消息體。POST方法可以請求服務器接收包含在請求中的實體信息，可以用於提交表單，向新聞組、BBS、郵件羣組和數據庫發送消息。
SP表示空格。Request-URI遵循URI格式，在此字段爲星號（*）時，說明請求並不用於某個特定的資源地址，而是用於服務器本身。HTTP-Version表示支持的HTTP版本，例如爲HTTP/1.1。CRLF表示換行回車符。請求頭域允許客戶端向服務器傳遞關於請求或者關於客戶機的附加信息。
請求頭域可能包含下列字段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。對請求頭域的擴展要求通訊雙方都支持，如果存在不支持的請求頭域，一般將會作爲實體頭域處理。
典型的請求消息：
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頭域指定請求資源的Intenet主機和端口號，必須表示請求url的原始服務器或網關的位置。HTTP/1.1請求必須包含主機頭域，否則系統會以400狀態碼返回。
Referer頭域
Referer頭域允許客戶端指定請求uri的源資源地址，這可以允許服務器生成回退鏈表，可用來登陸、優化cache等。他也允許廢除的或錯誤的連接由於維護的目的被追蹤。如果請求的uri沒有自己的uri地址，Referer不能被髮送。如果指定的是部分uri地址，則此地址應該是一個相對地址。
Range頭域
Range頭域可以請求實體的一個或者多個子範圍。例如，
表示頭500個字節：bytes=0-499
表示第二個500字節：bytes=500-999
表示最後500個字節：bytes=-500
表示500字節以後的範圍：bytes=500-
第一個和最後一個字節：bytes=0-0,-1
同時指定幾個範圍：bytes=500-600,601-999
但是服務器可以忽略此請求頭，如果無條件GET包含Range請求頭，響應會以狀態碼206（PartialContent）返回而不是以200（OK）。
User-Agent頭域
User-Agent頭域的內容包含發出請求的用戶信息。
響應消息
響應消息的第一行爲下面的格式：
HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF
HTTP-Version表示支持的HTTP版本，例如爲HTTP/1.1。Status-Code是一個三個數字的結果代碼。Reason-Phrase給Status-Code提供一個簡單的文本描述。Status-Code主要用於機器自動識別，Reason-Phrase主要用於幫助用戶理解。Status-Code的第一個數字定義響應的類別，後兩個數字沒有分類的作用。第一個數字可能取5個不同的值：
1xx:信息響應類，表示接收到請求並且繼續處理
2xx:處理成功響應類，表示動作被成功接收、理解和接受
3xx:重定向響應類，爲了完成指定的動作，必須接受進一步處理
4xx:客戶端錯誤，客戶請求包含語法錯誤或者是不能正確執行
5xx:服務端錯誤，服務器不能正確執行一個正確的請求
響應頭域允許服務器傳遞不能放在狀態行的附加信息，這些域主要描述服務器的信息和Request-URI進一步的信息。響應頭域包含Age、Location、Proxy-Authenticate、Public、Retry-After、Server、Vary、Warning、WWW-Authenticate。對響應頭域的擴展要求通訊雙方都支持，如果存在不支持的響應頭域，一般將會作爲實體頭域處理。
典型的響應消息：
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響應頭
Location響應頭用於重定向接收者到一個新URI地址。
Server響應頭
Server響應頭包含處理請求的原始服務器的軟件信息。此域能包含多個產品標識和註釋，產品標識一般按照重要性排序。
實體
請求消息和響應消息都可以包含實體信息，實體信息一般由實體頭域和實體組成。實體頭域包含關於實體的原信息，實體頭包括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允許客戶端定義新的實體頭，但是這些域可能無法未接受方識別。實體可以是一個經過編碼的字節流，它的編碼方式由Content-Encoding或Content-Type定義，它的長度由Content-Length或Content-Range定義。
Content-Type實體頭
Content-Type實體頭用於向接收方指示實體的介質類型，指定HEAD方法送到接收方的實體介質類型，或GET方法發送的請求介質類型Content-Range實體頭Content-Range實體頭用於指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。在服務器向客戶返回一個部分響應，它必須描述響應覆蓋的範圍和整個實體長度。一般格式：
Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth
例如，傳送頭500個字節次字段的形式：Content-Range:bytes0-499/1234如果一個http消息包含此節（例如，對範圍請求的響應或對一系列範圍的重疊請求），Content-Range表示傳送的範圍，Content-Length表示實際傳送的字節數。
Last-modified實體頭
Last-modified實體頭指定服務器上保存內容的最後修訂時間。
1.2.3 http協議的運作方式
HTTP協議是基於請求／響應範式的。一個客戶機與服務器建立連接後，發送一個請求給服務器，請求方式的格式爲，統一資源標識符、協議版本號，後邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行包括信息的協議版本號、一個成功或錯誤的代碼，後邊是MIME信息包括服務器信息、實體信息和可能的內容。
許多HTTP通訊是由一個用戶代理初始化的並且包括一個申請在源服務器上資源的請求。最簡單的情況可能是在用戶代理(UA)和源服務器(O)之間通過一個單獨的連接來完成(見圖1.1)。
圖1.1
當一個或多箇中介出現在請求／響應鏈中時，情況就變得複雜一些。中介由三種：代理(Proxy)、網關(Gateway)和通道(Tunnel)。一個代理根據URI的絕對格式來接受請求，重寫全部或部分消息，通過URI的標識把已格式化過的請求發送到服務器。網關是一個接收代理，作爲一些其它服務器的上層，並且如果必須的話，可以把請求翻譯給下層的服務器協議。一個通道作爲不改變消息的兩個連接之間的中繼點。當通訊需要通過一箇中介(例如：防火牆等)或者是中介不能識
別消息的內容時，通道經常被使用。
圖1.2
上面的圖1.2表明了在用戶代理(UA)和源服務器(O)之間有三個中介(A,B和C)。一個通過整個鏈的請求或響應消息必須經過四個連接段。這個區別是重要的，因爲一些HTTP通訊選擇可能應用於最近的連接、沒有通道的鄰居，應用於鏈的終點或應用於沿鏈的所有連接。儘管圖1.2是線性的，每個參與者都可能從事多重的、併發的通訊。例如，B可能從許多客戶機接收請求而不通過A，並且／或者不通過C把請求送到A，在同時它還可能處理A的請求。
任何針對不作爲通道的匯聚可能爲處理請求啓用一個內部緩存。緩存的效果是請求／響應鏈被縮短，條件是沿鏈的參與者之一具有一個緩存的響應作用於那個請求。下圖說明結果鏈，其條件是針對一個未被UA或A加緩存的請求，B有一個經過C來自O的一個前期響應的緩存拷貝。
圖1.3
在Internet上，HTTP通訊通常發生在TCP/IP連接之上。缺省端口是TCP80，但其它的端口也是可用的。但這並不預示着HTTP協議在Internet或其它網絡的其它協議之上才能完成。HTTP只預示着一個可靠的傳輸。
以上簡要介紹了HTTP協議的宏觀運作方式，下面介紹一下HTTP協議的內部操作過程。
首先，簡單介紹基於HTTP協議的客戶/服務器模式的信息交換過程，如圖1.4所示，它分四個過程，建立連接、發送請求信息、發送響應信息、關閉連接。
圖1.4
圖1.4
在WWW中，“客戶”與“服務器”是一個相對的概念，只存在於一個特定的連接期間，即在某個連接中的客戶在另一個連接中可能作爲服務器。WWW服務器運行時，一直在TCP80端口(WWW的缺省端口)監聽，等待連接的出現。
下面，討論HTTP協議下客戶/服務器模式中信息交換的實現。
1.建立連接 連接的建立是通過申請套接字(Socket)實現的。客戶打開一個套接字並把它約束在一個端口上，如果成功，就相當於建立了一個虛擬文件。以後就可以在該虛擬文件上寫數據並通過網絡向外傳送。
2.發送請求
打開一個連接後，客戶機把請求消息送到服務器的停留端口上，完成提出請求動作。
HTTP/1.0 請求消息的格式爲：
請求消息=請求行(通用信息|請求頭|實體頭)CRLF[實體內容]
請求 行=方法 請求URL HTTP版本號 CRLF
方 法=GET|HEAD|POST|擴展方法
U R L=協議名稱+宿主名+目錄與文件名
請求行中的方法描述指定資源中應該執行的動作，常用的方法有GET、HEAD和POST。不同的請求對象對應GET的結果是不同的，對應關係如下：
對象 GET的結果
文件 文件的內容
程序 該程序的執行結果
數據庫查詢 查詢結果
HEAD——要求服務器查找某對象的元信息，而不是對象本身。
POST——從客戶機向服務器傳送數據，在要求服務器和CGI做進一步處理時會用到POST方法。POST主要用於發送HTML文本中FORM的內容，讓CGI程序處理。
一個請求的例子爲：
GEThttp://networking.zju.edu.cn/zju/index.htmHTTP/1.0
頭信息又稱爲元信息，即信息的信息，利用元信息可以實現有條件的請求或應答。
請求頭——告訴服務器怎樣解釋本次請求，主要包括用戶可以接受的數據類型、壓縮方法和語言等。
實體頭——實體信息類型、長度、壓縮方法、最後一次修改時間、數據有效期等。
實體——請求或應答對象本身。
3.發送響應
服務器在處理完客戶的請求之後，要向客戶機發送響應消息。
HTTP/1.0的響應消息格式如下：
響應消息=狀態行(通用信息頭|響應頭|實體頭) CRLF 〔實體內容〕
狀態行=HTTP版本號 狀態碼 原因敘述
狀態碼錶示響應類型
1×× 保留
2×× 表示請求成功地接收
3×× 爲完成請求客戶需進一步細化請求
4×× 客戶錯誤
5×× 服務器錯誤
響應頭的信息包括：服務程序名，通知客戶請求的URL需要認證，請求的資源何時能使用。
4.關閉連接
客戶和服務器雙方都可以通過關閉套接字來結束TCP/IP對話
1.3 基於http協議的網絡行爲監視
1.3.1 http協議的安全因素
HTTP協議存在許多的安全漏洞，這些安全漏洞之一就是允許遠程用戶向遠程服務器請求連接，並且執行遠程命令。這個安全漏洞可以以許多方式損壞web服務器和客戶機，包括但不侷限於如下這些：
對遠程請求的武斷認證。
對web服務器的武斷認證。
破壞請求和應答的保密性。
濫用服務器功能和資源。
通過搜索它的程序錯誤和安全漏洞，濫用服務器。
濫用日誌信息（提取IP地址、域名和文件名等等）。
許多這樣的安全漏洞是衆所周知的，一些應用程序，如Netscape的SSL和NCSA的SHTTP XE“S-HTTP”試圖解決這些問題，但僅僅是其中的一部分問題。問題是，在internet上，web服務器對客戶的行爲顯得很脆弱。因此需要對其監視。
1.3.2 基於http協議監視的實現
在CSMA／CD(Carrier Sense Multiple Access/Collision Detection，載波偵聽多路訪問衝突檢測)網絡下，監視網絡上流動的數據包，捕捉我們感興趣的數據包，對感興趣的數據包進行分析和研究，分析出其所遵守的協議，進一步得到其應用層數據，並在需要的情況下將其數據進行重組，恢復到被監視用戶所看到的格式，爲進行更深一步的分析和研究打下基礎。
網絡監視器實現的一個前提條件是必須能夠“聽到”網路上所有的數據包，假如網卡僅能接收到屬於自己的數據包，也就無法實現監視功能了。
因此，其實現的網絡應當是基於共享式的，而在CSMA／CD網絡上是可以使網卡接受到所有的數據包，所以我們將實現的網絡環境暫時侷限於以太網上。在系統結構設計上，網絡監視器可以從下向上分爲三層，分別實現不同的功能，位於最下層的爲捕獲層，該層完成的功能是在基於CSMA／CD的網絡上截獲網絡上傳輸的數據包，這一部分是與平臺相關的，這是因爲針對不同的操作系統平臺，其網絡的軟件體系結構也大不相同，無論是DOS下的PktDrv驅動程序模型，還Windows下NDIS(Network Driver Interface Specification)結構模型，其處理的過程以及驅動程序的結構都不一樣，因此想爲它們設計一個通用的捕獲包組件是不太可能的，必須針對不同操作系統的不同特點設計不同的組件，以滿足它們特有的需要。爲了能夠在添加新的操作系統支持時不影響原有系統的實現，在該層的實現時，採用了Bridge的設計模式 ，它將Capturer(捕獲類)抽象和它的實現部分分別放在獨立的類層次結構中，其中一個類層次結構針對Capturer接口，另外一個獨立的類層次結構針對平臺相關的捕獲器實現部分，這個類層次結構的根類爲Capturerlmp；位於捕獲層之上的爲分析層，該層主要是對數據包所包含的內容進行分析，獲知其所用的協議和所包括的數據，這一部分只與特定的協議組有關，而和操作系統平臺無關，事實上，對於TCP／IP協議，無論是在Unix或DOS，還是在Windows下，它們的分析和重組都是完全一樣的，所以，這部分可以設計爲一個通用組件；最上面一層爲重組層，該層對一些常用的協議進行會話恢復，以得知會話的全過程，這一部分同第二部分一樣也是與平臺無關的。
關鍵技術將在下面的章節做詳細介紹，包括數據包的捕獲、重組、分析、解碼還原等過程。