本實驗主要介紹了利用wireshark進行數據抓包並分析HTTP協議，通過本實驗的學習，你能夠熟悉並掌握Wireshark的基本操作，加深對常用網絡協議的理解。
1.什么是HTTP
HTTP（HyperText Transfer Protocol，超文本傳輸協議）是Web系統最核心的內容，它是Web服務器和客戶端直接進行數據傳輸的規則。Web服務器就是平時所說的網站，是信息內容的發布者。最常見的客戶端就是瀏覽器，是信息內容的接受者。
HTTP（HyperText Transfer Protocol，超文本傳輸協議）協議是用於從WWW服務器傳輸超文本到本地瀏覽器的傳送協議。它可以使瀏覽器更加高效，使網絡傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內容首先顯示(如文本先於圖形)等。HTTP是一個應用層協議，有請求和響應構成，是一個標准的客戶端服務器模型。
HTTP具有以下幾個特點：
1.支持客戶/服務器模式，支持基本認證和安全認證
2.簡單快速；客戶端向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯系的類型不同。由於HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
3.靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
4.HTTP 0.9和1.0使用非持續連接：限制每次連接只處理一個請求，服務器處理完客戶的請求，並收到客戶的應答后，即斷開連接。采用這種方式可以節省傳輸時間。HTTP 1.1使用持續連接：不必為每個web對象創建一個新的連接，一個連接可以傳送多個對象。
5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味着如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。
2.HTTP請求方法
HTTP/1.1協議中共定義了8種動作（方法）來表明Request-URI指定的資源的不同操作方式。
(1)OPTIONS：返回服務器針對特定資源所支持的HTTP請求方法，也可以利用向Web服務器發送"*"的請求來測試服務器的功能性。
(2)HEAD：向服務器索要與GET請求相一致的響應，只不過響應體將不會被返回。這一方法可以在不必傳輸整個響應內容的情況下，就可以獲取包含在響應消息頭中的元信息。
(3)GET：向特定的資源發出請求。注意：get方法不應當被用於產生“副作用”的操作中。例如在Web APP中，其中一個原因是GET可能會被網站蜘蛛等隨意訪問。
(4)POST：向指定資源提交數據進行處理請求（比如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立或已有資源的修改。
(5)PUT：向指定資源位置上傳其最新內容。
(6)DELETE：請求服務器刪除Request-URI所標識的資源。
(7)TRACE：回顯服務器收到的請求，主要用於測試或者診斷。
(8)CONNECT：HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。
在大部分情況下，只會用到GET和HEAD方法，並且這些方法是區分大小寫的，當某個請求所針對的資源不支持對應的請求方法的時候，服務器應當返回狀態碼405，當服務器不認 識或不支持對應的請求方法的時候，應當返回狀態行501。
3.HTTP工作流程
HTTP是一個無狀態的協議。無狀態是指客戶端（Web瀏覽器）和服務器之間不需要建立持久的鏈接。這意味着當一個客戶端向服務器端發出請求，然后Web服務器返回響應”*”(response)，連接就被關閉了，在服務器端不保留連接的有關信息.HTTP遵 循請求(Request)/應答(Response)模型。客戶端（Web瀏覽器）向Web服務器發送請求，Web服務器處理請求並返回適當的應答。所有HTTP連 接都被構造成一套請求和應答。在該過程中要經過4個階段，包括建立連接、發送請求信息、發送響應信息和關閉連接，如下圖所示:
下面詳細介紹上圖中描述的HTTP工作流程，如下
1.客戶端通過TCP三次握手與服務器建立連接。
2.TCP建立連接成功后，向服務器發送HTTP請求。
3.服務器接收客戶端的HTTP請求后，將返回應答，並向客戶端發送數據
4.客戶端通過TCP四次斷開，與服務器斷開TCP連接。
4.持久性連接與非持久性連接
瀏覽器與web服務器建立TCP連接后，雙方就可以通過發送請求信息和應答信息進行數據傳輸。在HTTP協議中，規定TCP鏈接既可以是持久的，也可以是非持久的。具體采用哪種鏈接方式，可以由通用頭域中的Connection指定。在HTTP/1.0版本中，默認使用的是非持久性連接，在HTTP/1.1版本中，默認使用的是持久性連接。
4.1 非持久連接
非持久性連接就是每個TCP連接只用於傳輸一個請求消息和一個響應消息。用戶每請求一次Web頁面，就產生一個TCP連接。為了更詳細的了解非持久連接，下面簡單介紹一個例子。
假設在非持久連接的情況下服務器向客戶端傳送一個web頁面。假設該貝面由1個基本HTML文件和10個JPEG圖像構成，而且所有這些對象都存放在同一台服務器主機中。 再假設該基本HTML文件的URL為http://www.example.cn/somepath/index.html，則傳輸步驟如下所示。
1.HTTP客戶段首先與主機www.example.cn中的Web服務器建立TCP連接。Web服務器使用默認端口號80監聽來自HTTP客戶的連接建立請求。
2.HTTP客戶段通過TCP連接向服務器發送—個HTTP請求消息。這個消息中包含路徑名/somepath/index.html。
3.Web服務器通過TCP連接接收這個請求消息后，從服務器主機的內存或硬盤中取出對象/somepath/index.html，經由同一個套接字發出包含該對象的響應消息。
4.Web服務器告知本機的TCP協議棧關閉這個TCP連接。但是TCP協議棧要到客戶端收到剛才這個應答消息之后，才會真正終止這個鏈接。
5.HTTP客戶經由同一個套接字接收這個響應消息。TCP連接隨后終止。
6.該消息標明所封裝的對象是一個HTML文件。客戶從中取出這個文件，加以分析后發現其中有10個JPEG對象的引用。
7.這時候客戶端在重復步驟(1)~(5)，從服務器得到所引用的每一個JPEG對象。
上述步驟之所以稱為使用非持久連接，原因是每次服務器發出一個對象后，相應的TCP連接就被關閉，也就是說每個連接都沒有持續到可用於傳送其他 對象。每個TCP連接只用於傳輸一個請求消息和一個響應消息。就上述例子而言，用戶每請求一次那個web頁面，就產生一個TCP連接。
實際上，客戶端還可以通過並行的TCP連接同時取得其中的某些JPEG對象。這樣可以大大提高數據傳輸速度，縮短響應時間。目前的瀏覽器允許用戶通過配置來控制並行連接的數目，大多瀏覽器默認可以打開5-10個並行的TCP連接，每個連接處理一個請求/應答事務。
根據以上例子的描述，可以發現非持久連接具有如下幾個缺點。
首先，客戶得為每個待請求的對象建立並維護一個新的連接。對於每個這樣的連接，TCP得在客戶端和服務器端分配 TCP緩沖區，並維持TCP變量。對於有可能同時為來自數百個不同客戶的請求提供服務的web服務器來說，這會嚴重增加其負擔。其次，每個對象 都有2個RTT（Round-Trip Time，往返時延）的響應延長。一個RTT用於建立TCP連接，另—個RTT用於請求和接收對象。最后，每個對象都要經過TCP緩啟動，因為每個TCP連接都 起始於緩啟動階段。不過並行TCP連接的使用能夠部分減輕RTT延遲和緩啟動延遲的影響。
4.2 持久連接
持久連接是指服務器在發出響應后讓TCP連接繼續打開着。同一對客戶/服務器之間的后續請求和響應可以 通過這個連接發送。整個Web頁面(上例中為包含一個基本HTMLL文件和10個圖像的頁面)自不用說可以通過單個持久TCP連接發送:甚至存放在同一個 服務器中的多個web頁面也可以通過單個持久TCP連接發送。
通常，HTTP服務器在某個連接閑置一段特定時間后關閉它，而這段時間通常是可以配置的。持 久連接分為不帶流水線(without pipelining)和帶流水線(with pipelining)兩個版本。如果是不帶流水線的版本，那么客戶只在收到前一個請求的響應后才發出新的請求。這種情況下，web頁面所引用的每個對象 (上例中的10個圖像)都經歷1個RTT的延遲，用於請求和接收該對象。與非持久連接2個RTT的延遲相比，不帶流水線的持久連接已有所改善，不過帶流水 線的持久連接還能進一步降低響應延遲。不帶流水線版本的另一個缺點是，服務器送出一個對象后開始等待下一個請求，而這個新請求卻不能馬上到達。這段時間服 務器資源便閑置了。
HTTP/1.1的默認模式使用帶流水線的持久連接。這種情況下，HTTP客戶每碰到一個引用就立即發出一個請求，因而HTTP客戶可以一個接一個 緊挨着發出各個引用對象的請求。服務器收到這些請求后，也可以一個接一個緊挨着發出各個對象。與非流水線模式相比，流水線模式的效率要高得多。
1 熟悉並掌握Wireshark的基本操作。
2 加深對常用網絡協議的理解，提高就業機會。
3 培養學生理論聯系實踐的研究興趣。
服務器：windows 系統，IP地址：10.1.1.33
測試者：windows系統，IP地址：10.1.1.42
在實驗環境中，我們通過模擬局域網的兩台機器之間的數據傳輸，來抓取和分析HTTP數據，用到HFS軟件
配置HFS軟件，獲取HTTP的GET數據和POST數據
在局域網環境中，我們使用一個小工具來實現HTTP服務器。先在服務器上配置HFS
1. 配置HFS軟件
本地解壓，進入文件夾，右鍵以管理員身份運行。如下
我們先配置HFS，這里能達到我們的實驗要求，獲取到GET和POST數據包即可。點擊左上角的端口，輸入端口，這里我們用8080，如下，點擊確定
在虛擬文件系統區域，右鍵，選擇“從磁盤添加目錄”，選擇一個真實存在的目錄（此處注意務必是真實存在的），彈出的選擇目錄類型中選擇”真實目錄”，此處我們用桌面的解壓縮目錄，可以看到目錄是紅色的
右鍵目錄，點擊設置”用戶名及密碼”，在彈出的對話框中輸入用戶名和密碼（demo/demo）,點擊確定。
在右鍵目錄，點擊”屬性”，選擇”上傳”sheet頁，選中任何人。點擊確定，如下
這樣我們就配置好了HFS工具，可以在客戶端通過瀏覽器訪問了。
2. 獲取HTTP的GET數據和POST數據
下面我們在測試者機器上，打開Wireshark抓包工具，過濾條件輸入ip.addr == 10.1.1.33，然后輸入服務器中HFS給出的網址，等待服務器響應。成功之后，可以在測試者機器的瀏覽器上看到頁面，如下：
這時候，我們已經獲取到了HTTP的GET方法。我們將Wireshark獲取的數據包保存為HTTP-Get。
點擊頁面的登錄，在對話框中輸入用戶名密碼（demo/demo），確定之后等待服務器響應。成功如下
接下來，雙擊頁面的文件夾（等待服務器響應），同時重新啟動Wireshark，等待頁面刷新成功，
如上圖，會在左側看到按鈕，點擊”上傳”按鈕，選擇文件，這里我們選擇桌面上的“http-post.txt”,點擊上傳。等待服務器響應。提示上傳成功，如下
我們保存抓包文件，名字為HTTP-Post。
分析HTTP數據包
1. HTTP報文格式
HTTP由請求和響應兩部分組成，所以對應的也有兩種報文格式。下面分別介紹HTTP請求報文格式和HTTP響應報文格式。
HTTP請求報文格式
以上表格中，第1行為“請求行”，第2、3、4行為“請求頭部”，第5行為空行，第6行為“請求正文”。下面分別介紹這4部分：
1.請求行：由3部分組成，分別為：請求方法、URL（見備注1）以及協議版本，之間由空格分隔，請求方法包括GET、POST等。協議版本的格式為：HTTP/主版本號.次版本號，常用的有HTTP/1.0和HTTP/1.1。
2.請求頭部包含很多客戶端環境以及請求正文的有用信息。請求頭部由“關鍵字：值”對組成，每行一堆，關鍵字和值之間使用英文“：”分隔。
3.空行，這一行非常重要，必不可少。表示請求頭部結束，下面就是請求正文。
4.請求正文：可選部分，比如GET請求就沒有請求正文；POST比如以提交表單數據方式為請求正文。
HTTP響應報文格式
以上表格中，第1行為“狀態行”，第2、3、4行為“響應頭部”，第5行為空行，第6行為“響應正文”。下面分別介紹這4部分：
(1)狀態行由由3部分組成，分別為：協議版本，狀態碼，狀態碼描述，之間由空格分隔。狀態代碼為3位數字，200~299的狀態碼表示成功，300~399的狀態碼指資源重定向，400~499的狀態碼指客戶端請求出錯，500~599的狀態碼指服務端出錯（HTTP/1.1向協議中引入了信息性狀態碼，范圍為100~199）。這里列舉幾個常見的:
(2)響應頭部與請求頭部類似，也包含了很多有用的信息。
(3)空行，這一行非常重要，必不可少。表示響應頭部結束
(4)響應正文，服務器返回的文檔，最常見的為HTML網頁。
2. HTTP的頭域
在HTTP的請求消息和應答消息中，都包含頭域。頭域分為4種，其中請求頭域和應答頭域分別只在請求消息和應答消息中出現，通用頭域和實體頭域在兩種消息中都可以出現，但實體頭域只有當消息中包含了實體數據時才會出現。下面分別介紹這4種頭域中的域名城和功能。
HTTP請求頭域
應答頭域只在應答消息中出現，是Web服務器向瀏覽器提供的一些狀態和要求。如下
HTTP 應答頭域
通用頭域既可以用在請求消息中，也可以用在應答消息。
HTTP通用頭域
只有在請求和應答消息中包含實體數據時，才需要實體頭域。請求消息中的實體數據是一些由瀏覽器向web服務器提交的數據，如在瀏覽器中采用POST方式提交表單時，瀏覽器就要把表單中的數據封裝在請求消息的實體數據部分。應答消息中的實體數據是web服務器發給瀏覽器的媒體數據，如網頁，圖片和文檔等。實體頭域說明了實體數據的一些屬性。如下表
HTTP實體頭域
3.分析GET方法的HTTP數據包
我們以HTTP-Get數據包為例，分析GET方法的HTTP請求和響應數據包。
3.1.分析HTTP請求包
前三個是TCP的三次握手，第四個數據包則是客戶端向服務器發送的HTTP請求包，我們來學習分析下，
HTTP之前的協議，本次我們不做講解，不懂的同學可以看之前的實驗，我們來看下HTTP協議。
Hypertext Transfer Protocol
GET / HTTP/1.1\r\n #請求行信息
Expert Info (Chat/Sequence): GET / HTTP/1.1\r\n #專家信息
GET / HTTP/1.1\r\n
Severity level: Chat
Group: Sequence
Request Method: GET #請求方法為GET
Request URI: / #請求的URI
Request Version: HTTP/1.1 #請求的版本為HTTP/1.1
Host: 10.1.1.33:8080\r\n #請求的主機
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0\r\n #瀏覽器類型
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n #請求的類型
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3\r\n #請求語言
Accept-Encoding: gzip, deflate\r\n #請求的編碼格式
Connection: keep-alive\r\n #使用持久連接
\r\n #空行
Full request URI: http://10.1.1.33:8080/ #請求的URI為10.1.1.33:8080
HTTP request 1/8
Response in frame: 2770 #應答是第2770幀
Next request in frame: 2775 #下一個請求是第2775幀
以上就是HTTP請求包的相關信息，可以看到客戶端使用HTTP/1.1版本向服務器發送了GET請求，請求訪問10.1.1.33的服務器。將以上信息填入到報文格式中，如下
GET方法的HTTP請求報文格式
3.2. 分析HTTP響應包
根據請求包的信息，我們已經知道，響應包是第2770幀，下面我們來看下
在HTTP之前，我們看到了下圖顯示的，TCP重組片段，這些片段共有2270個字節，由於超過了TCP數據包的最大數據分段（MSS），所以將數據在TCP層進行了分段。從下面的信息，可以看到分斷后的數據包及包大小，如#2767（247），其中2767表示幀號，大小為247個字節。
下面來看HTTP的具體部分
Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n #響應行信息
Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n #專家信息
HTTP/1.1 200 OK\r\n #HTTP響應信息，響應碼為200
Severity level: Chat
Group: Sequence
Request Version: HTTP/1.1 #請求版本
Status Code: 200 #狀態碼
Response Phrase: OK #響應短語
Content-Type: text/html\r\n #響應的內容類型
Content-Length: 2023\r\n #包的長度
Content length: 2023
Accept-Ranges: bytes\r\n #服務器支持的請求：字節
Server: HFS 2.3 beta\r\n #服務器類型
Set-Cookie: HFS_SID=0.248448607278988; path=/; \r\n #設置Http Cookie
Cache-Control: no-cache, no-store, must-revalidate, max-age=-1\r\n #緩存控制
Content-Encoding: gzip\r\n #實體數據的壓縮格式
\r\n #空行
HTTP response 1/8 #HTTP響應
Time since request: 0.015248000 seconds #響應使用的時間
Request in frame: 2763 #請求的幀號為2763
Next request in frame: 2775 #下一個請求的幀號2775
Next response in frame: 2778 #下一個響應的幀號是2778
Content-encoded entity body (gzip): 2023 bytes -> 4375 bytes #內容編碼（gzip）
Line-based text data: text/html #基於行的文本數據
根據以上信息，可以知道服務器使用HTTP/1.1 200 OK響應了客戶端的請求。將信息填入到報文格式中，如下
GET方法的HTTP響應報文格式
4. 分析POST方法的HTTP數據包
4.1. 分析HTTP請求包
下面我們以HTTP-Post為例，分析POST方法的HTTP請求和響應。打開數據包，輸入過濾條件ip.addr ==10.1.1.33,顯示出的HTTP中，Info列中還有POST的即可，如下
我們展開分析下
Hypertext Transfer Protocol #HTTP協議
POST /hfs2_3b287/ HTTP/1.1\r\n #請求行
Expert Info (Chat/Sequence): POST /hfs2_3b287/ HTTP/1.1\r\n #專家信息
POST /hfs2_3b287/ HTTP/1.1\r\n
Severity level: Chat
Group: Sequence
Request Method: POST #請求方法為POST
Request URI: /hfs2_3b287/ # 請求的URI
Request Version: HTTP/1.1 #請求的版本
Host: 10.1.1.33:8080\r\n #使用的主機
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0\r\n #使用的瀏覽器類型
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n #瀏覽器接受的類型
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3\r\n #希望使用的語言
Accept-Encoding: gzip, deflate\r\n #可使用的編碼格式，這里是gzip和deflate
Referer: http://10.1.1.33:8080/hfs2_3b287/\r\n #從包含的URL頁面發起請求
Cookie: HFS_SID=0.248448607278988\r\n #Cookie信息
Cookie pair: HFS_SID=0.248448607278988
Authorization: Basic ZGVtbzpkZW1v\r\n #授權證書信息
Credentials: demo:demo #登錄的用戶名密碼
Connection: keep-alive\r\n #使用持久連接
Content-Type:multipart/form-data;boundary=---------------------------54542580413055\r\n #請求的內容類型
Content-Length: 367\r\n #包的長度
Content length: 367
\r\n #空行
Full request URI: http://10.1.1.33:8080/hfs2_3b287/ #請求的URI為http://10.1.1.33:8080/hfs2_3b287/
HTTP request 1/6
Response in frame: 3800 #響應的幀號
Next request in frame: 3802 #下一個請求的幀號
以上就是使用POST方法的HTTP請求包，可以看到請求的連接及登錄的用戶名密碼等。將上面的信息填入到報文格式中，如下
POST方法的HTTP請求報文格式
另外，我們在HTTP的下面，看到了如下的內容
類型的Multipart/form-data是上傳文件的一種方式。Multipart/form-data其實就是瀏覽器用表單上傳文件的方式。最常見的情境是：在寫郵件時，向郵件后添加附件，附件通常使用表單添加，也就是用multipart/form-data格式上傳到服務器。我們實驗中向服務器上傳了一個文件，所以就是此類型。
再看Wireshark中的使用
首先看wireshark中字段與Multipart/form-data的對應關系： MIME Multipart Media Encapsulation：代表整個Multipart/form-data上傳文件中的數據。
Encapsulated multipart part：代表表單中不同部分的數據。
Boundary：用來隔開表單中不同部分的數據。
其次，
1) MIME Multipart Media Encapsulation, Type: multipart/form-data, Boundary: "---------------------------54542580413055"
這行指出這個請求是multipart/form-data格式的，且boundary是“----------54542580413055”這個字符串。
2）關於Boundary： Boundary：用來隔開表單中不同部分的數據。實際上，每部分數據的開頭都是由“--”+boundary開始的（這是MIME標准中講述的標准內容）。
3） Encapsulated multipart part：緊跟着boundary的是該部分數據的描述：
Content-Dispostion:form-data;name="Filename"\r\n
每一個part至少一個name和一個content部分。
可以從上面的multipart/form-data中，看到我們上傳的文本名字為http-post.txt，內容為“This is demo for HTTP POST”。
4.2. 分析HTTP響應包
根據Wireshark現實的響應包幀數，我們來看下第3800幀。
Hypertext Transfer Protocol #HTTP協議
HTTP/1.1 200 OK\r\n #響應行
Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n #專家信息
HTTP/1.1 200 OK\r\n #響應信息
Severity level: Chat
Group: Sequence
Request Version: HTTP/1.1 #請求版本
Status Code: 200 #狀態碼
Response Phrase: OK #響應短語
Content-Type: text/html\r\n #響應包類似
Content-Length: 570\r\n #響應包長度
Content length: 570
Accept-Ranges: bytes\r\n #服務器支持的請求：字節
Server: HFS 2.3 beta\r\n #web服務器類型
Content-Encoding: gzip\r\n #實體數據的壓縮格式
\r\n #空行
HTTP response 1/6 #響應
Time since request: 0.008774000 seconds #響應請求的時間
Request in frame: 3798 #請求的幀號
Next request in frame: 3802 #下一個請求的幀號
Next response in frame: 3804 #下一個響應的幀號
Content-encoded entity body (gzip): 570 bytes -> 866 bytes #內容編碼（gzip）
Line-based text data: text/html #文本內容
以上就是POST方法的HTTP響應包，可以看到服務器向客戶端發送了HTTP/1.1 200 OK響應了HTTP請求包。服務器類型為HFS 2.3 beta，將數據填入到報文格式中
POST方法的HTTP響應報文格式
