科普貼：
HTTP 是一個無狀態的協議。無狀態 是指客戶端 （Web 瀏覽器）和 服務器之間不 需要建立持久的鏈接。這 意味着當一個客戶端向服務器端發出請求，然后Web 服務器返回響應 ”*”(response) ，連接就被關閉了，在服務器端不保留連接的有關信息 .HTTP 遵 循請求 (Request)/ 應答 (Response) 模型。客戶端（Web 瀏覽器）向Web 服務器發送請求， Web 服務器處理請求並返回適當的應答。所有 HTTP 連 接都被構造成一套請求和應答。在 該過程中 要經過4 個 階段，包括建立連接、發送請求信息、發送 響應信息和關閉連接，如下圖所示:
下面 詳細介紹上圖中描述的HTTP 工作流程，如下
客戶端 通過TCP 三次握手與服務器建立連接。
TCP 建立連接成功后，向 服務器發送HTTP 請求。
服務器 接收客戶端的HTTP 請求后，將返回應答，並向客戶端發送數據
客戶端 通過TCP 四次斷開，與服務器斷開 TCP 連接。
在今天的實驗中，我們將通過模擬局域網的兩台機器之間的數據傳輸，配置好HFS軟件，來抓取和分析HTTP數據。
根據實驗環境，本實驗的步驟如下：
1． 配置HFS 軟件，獲取 HTTP 的 GET數據和POST 數據
2． 分析HTTP數據包
實戰步驟一 配置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）。這里列舉幾個常見的：
| 狀態碼 |
說明 |
| 200 |
響應成功 |
| 400 |
客戶端請求有語法錯誤，不能被服務器識別 |
| 404 |
請求資源不存在 |
| 500 |
服務器內部錯誤 |
（3） 空行，這一行非常重要，必不可少。表示響應頭部結束
（4） 響應 正文，服務器返回的文檔，最常見的為HTML網頁。
2 HTTP的頭域
在HTTP的 請求消息 和應答消息中，都包含頭域。頭域 分為4 種 ，其中請求 頭域和應答頭域分別只在請求消息和應答消息中出現，通用頭域和實體頭域在兩種消息中都可以出現，但實體頭域只有當 消息中包含了實體數據時 才會出現。下面分別 介紹這4 種 頭域中的域名城和功能。
HTTP請求頭域
| Header |
解釋 |
| Accept |
指定客戶端能夠接收的內容類型 |
| Accept-Charset |
瀏覽器可以接受的字符編碼集。 |
| Accept-Encoding |
指定瀏覽器可以支持的web服務器返回內容壓縮編碼類型。 |
| Accept-Language |
瀏覽器可接受的語言 |
| Accept-Ranges |
可以請求網頁實體的一個或者多個子范圍字段 |
| Authorization |
HTTP授權的授權證書 |
| Cache-Control |
指定請求和響應遵循的緩存機制 |
| Connection |
表示是否需要持久連接。（HTTP 1.1默認進行持久連接） |
| Cookie |
HTTP請求發送時，會把保存在該請求域名下的所有cookie值一起發送給web服務器。 |
| Content-Length |
請求的內容長度 |
| Content-Type |
請求的與實體對應的MIME信息 |
| Date |
請求發送的日期和時間 |
| Expect |
請求的特定的服務器行為 |
| From |
發出請求的用戶的Email |
| Host |
指定請求的服務器的域名和端口號 |
| If-Match |
只有請求內容與實體相匹配才有效 |
| If-Modified-Since |
如果請求的部分在指定時間之后被修改則請求成功，未被修改則返回304代碼 |
| If-None-Match |
如果內容未改變返回304代碼，參數為服務器先前發送的Etag，與服務器回應的Etag比較判斷是否改變 |
| If-Range |
如果實體未改變，服務器發送客戶端丟失的部分，否則發送整個實體。參數也為Etag |
| If-Unmodified-Since |
只在實體在指定時間之后未被修改才請求成功 |
| Max-Forwards |
限制信息通過代理和網關傳送的時間 |
| Pragma |
用來包含實現特定的指令 |
| Proxy-Authorization |
連接到代理的授權證書 |
| Range |
只請求實體的一部分，指定范圍 |
| Referer |
先前網頁的地址，當前請求網頁緊隨其后,即來路 |
| TE |
客戶端願意接受的傳輸編碼，並通知服務器接受接受尾加頭信息 |
| Upgrade |
向服務器指定某種傳輸協議以便服務器進行轉換（如果支持） |
| User-Agent |
User-Agent的內容包含發出請求的用戶信息 |
| Via |
通知中間網關或代理服務器地址，通信協議 |
| Warning |
關於消息實體的警告信息 |
| Accept |
指定客戶端能夠接收的內容類型 |
應答 頭域只在應答消息中出現，是Web 服務器向瀏覽器提供的一些狀態和要求。如下
HTTP 應答頭域
| Header |
解釋 |
| Accept-Ranges |
表明服務器是否支持指定范圍請求及哪種類型的分段請求 |
| Age |
從原始服務器到代理緩存形成的估算時間（以秒計，非負） |
| Allow |
對某網絡資源的有效的請求行為，不允許則返回405 |
| Cache-Control |
告訴所有的緩存機制是否可以緩存及哪種類型 |
| Content-Encoding |
web服務器支持的返回內容壓縮編碼類型。 |
| Content-Language |
響應體的語言 |
| Content-Length |
響應體的長度 |
| Content-Location |
請求資源可替代的備用的另一地址 |
| Content-MD5 |
返回資源的MD5校驗值 |
| Content-Range |
在整個返回體中本部分的字節位置 |
| Content-Type |
返回內容的MIME類型 |
| Date |
原始服務器消息發出的時間 |
| ETag |
請求變量的實體標簽的當前值 |
| Expires |
響應過期的日期和時間 |
| Last-Modified |
請求資源的最后修改時間 |
| Location |
用來重定向接收方到非請求URL的位置來完成請求或標識新的資源 |
| Pragma |
包括實現特定的指令，它可應用到響應鏈上的任何接收方 |
| Proxy-Authenticate |
它指出認證方案和可應用到代理的該URL上的參數 |
| Retry-After |
如果實體暫時不可取，通知客戶端在指定時間之后再次嘗試 |
| Server |
web服務器軟件名稱 |
| Set-Cookie |
設置Http Cookie |
| Trailer |
指出頭域在分塊傳輸編碼的尾部存在 |
| Transfer-Encoding |
文件傳輸編碼 |
| Vary |
告訴下游代理是使用緩存響應還是從原始服務器請求 |
| Via |
告知代理客戶端響應是通過哪里發送的 |
| Warning |
警告實體可能存在的問題 |
| WWW-Authenticate |
表明客戶端請求實體應該使用的授權方案 |
| refresh |
應用於重定向或一個新的資源被創造，在5秒之后重定向（由網景提出，被大部分瀏覽器支持） |
通用 頭域既可以用在 請求消息中，也可以用在應答消息。
HTTP通用頭域
| Header |
解釋 |
| Cache-Control |
Cache-Control指定請求和響應遵循的緩存機制，可以附帶很多的規定值。 |
| Connection |
表示是否需要持久連接 |
| Date |
表示消息發送的時間 |
| Pragma |
Pragma頭域用來包含實現特定的指令，最常用的是Pragma:no-cache，用於定義頁面緩存 |
| Trailer |
表示以Chunked編碼傳輸的實體數據的尾部存在哪些頭域 |
| Transfer-Encoding |
WEB 服務器表明自己對本響應消息體（不是消息體里面的對象）作了怎樣的編碼，比如是否分塊（chunked），例如：Transfer-Encoding: chunked |
| Upgrade |
它可以指定另一種可能完全不同的協議，如HTTP/1.1客戶端可以向服務器發送一條HTTP/1.0請求，其中包含值為“HTTP/1.1”的Update頭部，這樣客戶端就可以測試一下服務器是否也使用HTTP/1.1了。 |
| Via |
列出從客戶端到 OCS 或者相反方向的響應經過了哪些代理服務器，他們用什么協議（和版本）發送的請求。 |
| Warning |
用於警告應用到實體數據上的緩存操作或轉換可能缺少語義透明度。 |
只有在請求和應答消息中包含實體數據時， 才需要實體頭域。 請求消息中的實體數據是一些由瀏覽器向web服務器提交的數據，如在瀏覽器中采用POST方式提交表單時，瀏覽器就要把表單中的數據封裝在請求消息的實體數據部分。應答消息中的實體數據是web服務器發給瀏覽器的媒體數據，如網頁，圖片和文檔等。實體頭域說明了實體數據的一些屬性。如下表
HTTP實體頭域
| Header |
解釋 |
| Allow |
列出由請求URI標識的資源所支持的方法集 |
| Content-Encoding |
說明實體數據是如何編碼的 |
| Content-Language |
說明實體數據所采用的自然語言 |
| Content-Length |
說明實體數據的長度 |
| Content-Location |
說明實體數據的資源位置 |
| Content-MD5 |
給出實體數據的 MD5值，用於保證實體數據的完整性 |
| Content-Range |
用於指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。在服務器向客戶返回一個部分響應，它必須描述響應覆蓋的范圍和整個實體長度 |
| Content-Type |
用於向接收方指示實體的介質類型，指定 HEAD 方法送到接收方的實體介質類型，或 GET 方法發送的請求介質類型 |
| Expires |
指定實體數據的有效期 |
| Last-Modified |
指定服務器上保存內容的最后修訂時間。 |
3 分析GET方法的HTTP數據包
我們 以HTTP-Get 數據包為例 ，分析GET 方法的HTTP 請求和響應數據包。
分析HTTP請求包
我們 打開數據包，輸入過濾條件ip.addr == 10.1.1.33,如下
前三個 是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版本 向服務器發送了GEY 請求，請求訪問10.1.1.33 的 服務器。 將以上 信息填入到報文 格式中，如下
GET方法的HTTP請求報文格式
| GET |
空格 |
/ |
空格 |
HTTP/1.1 |
\r |
\n |
| Accept |
: |
text/html,application/xhtml+xml,application/xml |
\r |
\n |
||
| … |
||||||
| Connection |
: |
keep-alive |
\r |
\n |
||
| \r |
\n |
|||||
| Full request URI: http://10.1.1.33:8080/ |
||||||
esponse in frame: 2770 #應答 是第2770 幀
Next request in frame: 2775 # 下一個請求是第2775 幀
以上 就是HTTP 請求包的相關信息，可以看到客戶端使用HTTP/1.1版本 向服務器發送了GEY 請求，請求訪問10.1.1.33 的 服務器。 將以上 信息填入到報文 格式中，如下
GET方法的HTTP請求報文格式
| GET |
空格 |
/ |
空格 |
HTTP/1.1 |
\r |
\n |
| Accept |
: |
text/html,application/xhtml+xml,application/xml |
\r |
\n |
||
| … |
||||||
| Connection |
: |
keep-alive |
\r |
\n |
||
| \r |
\n |
|||||
| Full request URI: http://10.1.1.33:8080/ |
||||||
分析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響應報文格式
| HTTP/1.1 |
空格 |
200 |
空格 |
OK |
\r |
\n |
| Content-Type |
: |
text/html |
\r |
\n |
||
| … |
||||||
| Content-Encoding |
: |
gzip |
\r |
\n |
||
| \r |
\n |
|||||
| 省略 |
||||||
4 分析POST方法的HTTP數據包
分析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請求報文格式
| POST |
空格 |
/hfs2_3b287/ |
空格 |
HTTP/1.1 |
\r |
\n |
| Accept |
: |
text/html,application/xhtml+xml,application/xml |
\r |
\n |
||
| … |
||||||
| Content-Length |
: |
367 |
\r |
\n |
||
| \r |
\n |
|||||
| 忽略 |
||||||
另外 ，我們 在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”。
分析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響應報文格式
| HTTP/1.1 |
空格 |
200 |
空格 |
OK |
\r |
\n |
| Server |
: |
HFS 2.3 beta |
\r |
\n |
||
| … |
||||||
| Content-Encoding |
: |
gzip |
\r |
\n |
||
| \r |
\n |
|||||
| 省略 |
||||||
實驗中我們 講解了 主要的GET和POST 方法， 可以抓包 考慮， 學習其他的方法，動手提高能力 。
這個技術你學會了嗎？加入網安實驗室，1300+網安技能任你學！