實驗環境
操作機：Windows XP
實驗目的
0、HTTP協議的基本概念及工作流程
1、捕獲HTTP數據包的方法
2、分析HTTP的連接數據包
3、HTTP數據包的篩選技術
4、分析HTTP的數據傳輸數據包
實驗工具
wireshark
實驗步驟
了解HTTP工作流程
HTTP是一個無狀態的協議。所謂的無狀態指的是客戶端（Web瀏覽器）和服務器之間不需要建立持久的連接。這也就意味着當一個客戶端向服務器發出請求，然后服務器返回響應之后，連接也就關閉了。服務器並不會保留連接的相關信息，HTTP遵循的是請求（Request）/應答（Response）模型。客戶端（Web瀏覽器）向服務器發送請求，服務器處理請求並返回適當的應答。所有的HTTP連接都被構造成一套請求和應答。在這個過程中要經歷4個階段，包括建立連接、發送請求信息、發送響應信息和關閉連接，如下圖所示：
由上圖可知，HTTP的工作流程為：
1、客戶端通過TCP的三次握手建立與服務器的連接。
2、當TCP連接成功建立后，客戶端向服務器發送HTTP請求。
3、服務器收到客戶端的HTTP請求后，將回復響應數據包，並向客戶端發送數據。
4、客戶端通過TCP四次握手，與服務器斷開TCP連接。
HTTP連接數據包的捕獲
剛才說了，HTTP需要使用TCP的三次握手來建立連接，那么我們在使用Wireshark進行數據包的捕獲時，需要在篩選條件中加上TCP這個篩選條件。我們的目標是捕獲到使用HTTP瀏覽網頁的數據包。那么當我們開啟捕獲后，就可以打開瀏覽器，嘗試瀏覽www.baidu.com網站，就可以獲取與HTTP連接相關的一系列數據包。
由於瀏覽網頁會使用GET方法，所以我們可以在篩選器中輸入http.request.method==GET，這樣就可以篩選出所有的GET方法了。篩選后可以發現第44號數據包排在了第一位，那么這個其實就是我們要尋找的，與百度建立連接的HTTP的數據包。我們可以對其進行着色處理，這樣所有與其相關的數據包都會擁有相同的顏色。之后點擊篩選器旁邊的Clear，清除篩選條件，這樣我們就可以看到完整的HTTP連接了。
HTTP連接數據包的分析
分析上一步篩選出來的文件。可以發現，整個通信是從客戶端192.168.147.129到百度的Web服務器119.75.218.70的三次握手開始的：
當連接建立之后，第一個標記為HTTP的數據包是從客戶端發往服務器的：
可以發現，HTTP數據包通過TCP被傳輸到服務器的80端口，也就是HTTP通信的標准端口（8080端口也常被使用）。
接下來可以看到，這個數據包所請求的方法是GET，所請求的URI是“/”，請求的版本為HTTP/1.1。這些信息告訴我們這個客戶端請求使用HTTP的1.1版本，下載Web服務器的根目錄（/）。這里面還包含有客戶端向服務器發送的關於自己的信息。這些信息包含了類似於使用用戶代理（User-Agent）、瀏覽器接受的語言（Accept-Language）以及Cookie等信息。為了保證兼容性，服務器可以利用這些信息決定返回給客戶端的數據。
當服務器接收到了數據包4中的HTTP請求，它就會響應一個TCP ACK，用於數據包的確認，並在6到26號數據包中傳輸所請求的數據。HTTP只被用來發布客戶端和服務器的應用層命令。當進行數據傳輸時，除了在數據流的開始和結束部分，是看不到應用層的控制信息的。
服務器將數據在6、7、8號數據包中發送，9號數據包是來自客戶端的確認，10到24號數據包也是服務器發給客戶端的數據，25號數據包是客戶端發出的另一個確認。盡管HTTP仍然負責這些傳輸，但所有這些數據包在Wireshark中都被顯示為TCP分片而不是HTTP數據包。當數據傳輸結束后，數據的重組裝流就已經發送完了，就到了最后一個數據包：
HTTP使用了一些預定義的響應碼來表示請求方法的結果。這里我們看到了一個帶有200狀態碼的數據包，表示一次成功的請求方法。這個數據包里面包含有一個時間戳，以及一些關於Web服務器內容編碼和配置參數的額外信息。當客戶端接收到這個數據包后，這次的處理也就完成了。
HTTP傳送數據包分析
我們剛才所研究的是從Web服務器下載數據的過程，現在來研究一下上傳數據。當我們在網站上進行提交表單或者上傳文件的操作時，往往就能夠捕獲含有POST方法的數據包。最開始依舊是TCP的三次握手，之后客戶端（172.16.16.128）向Web服務器（69.163.176.56）發送了一個HTTP的數據包：
這個數據包使用了POST方法來向Web服務器上傳數據以供處理。這里使用的POST方法指明了URI為/wp-comments-post.php，以及HTTP 1.1請求版本。如果想查看上傳數據的內容，可以展開下方的HTML Form URL Encoded查看。 當這個數據包傳輸完之后，服務器會發送一個ACK數據包，並在第6個數據包中傳輸了一個響應碼302（表示“找到”）作為回應：
302響應碼是HTTP的一個常用的重定向手段。這個數據包的Location域指明了客戶端被重定向的位置。此時，這個地方就是評論所發表的原先的網頁。最后，服務器傳送一個狀態碼200，並且這個頁面的內容會在接下來的一些數據包中進行發送，從而完成傳輸。
拓展【http長連接、短連接的概念及其使用的場景】
HTTP長連接和短連接 https://www.cnblogs.com/0201zcr/p/4694945.html
- HTTP協議與TCP/IP協議的關系
HTTP的長連接和短連接本質上是TCP長連接和短連接。HTTP屬於應用層協議，在傳輸層使用TCP協議，在網絡層使用IP協議。IP協議主要解決網絡路由和尋址問題，TCP協議主要解決如何在IP層之上可靠的傳遞數據包，使在網絡上的另一端收到發端發出的所有包，並且順序與發出順序一致。TCP有可靠，面向連接的特點。
- 如何理解HTTP協議是無狀態的
HTTP協議是無狀態的，指的是協議對於事務處理沒有記憶能力，服務器不知道客戶端是什么狀態。也就是說，打開一個服務器上的網頁和你之前打開這個服務器上的網頁之間沒有任何聯系。HTTP是一個無狀態的面向連接的協議，無狀態不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協議（無連接）。
- 什么是長連接、短連接？
在HTTP/1.0中，默認使用的是短連接。也就是說，瀏覽器和服務器每進行一次HTTP操作，就建立一次連接，但任務結束就中斷連接。如果客戶端瀏覽器訪問的某個HTML或其他類型的 Web頁中包含有其他的Web資源，如JavaScript文件、圖像文件、CSS文件等；當瀏覽器每遇到這樣一個Web資源，就會建立一個HTTP會話。
但從 HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協議，會在響應頭有加入這行代碼：
Connection:keep-alive
在使用長連接的情況下，當一個網頁打開完成后，客戶端和服務器之間用於傳輸HTTP數據的 TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。實現長連接要客戶端和服務端都支持長連接。
HTTP協議的長連接和短連接，實質上是TCP協議的長連接和短連接。
參考資料
【1】https://www.ichunqiu.com/course/51449
【2】謝希仁. 計算機網絡.第5版[M]. 電子工業出版社, 2008.