1.簡介
有的小伙伴或者童鞋們可能會好奇地問宏哥，不是講解和分享抓包工具了怎么這里開始講解HTTP和HTTPS協(xié)議了。這是因為你對HTTP協(xié)議越了解，你就能越掌握Fiddler的使用方法，反過來你越使用Fiddler，就越能幫助你了解HTTP協(xié)議。
Fiddler無論對開發(fā)人員或者測試人員來說，都是非常有用的工具。
2.前言
超文本傳輸協(xié)議HTTP協(xié)議被用于在Web瀏覽器和網站服務器之間傳遞信息，HTTP協(xié)議以明文方式發(fā)送內容，不提供任何方式的數(shù)據(jù)加密，如果攻擊者截取了Web瀏覽器和網站服務器之間的傳輸報文，就可以直接讀懂其中的信息，因此，HTTP協(xié)議不適合傳輸一些敏感信息，比如：信用卡號、密碼等支付信息。
為了解決HTTP協(xié)議的這一缺陷，需要使用另一種協(xié)議：安全套接字層超文本傳輸協(xié)議HTTPS，為了數(shù)據(jù)傳輸?shù)陌踩?，HTTPS在HTTP的基礎上加入了SSL協(xié)議，SSL依靠證書來驗證服務器的身份，并為瀏覽器和服務器之間的通信加密。
如果你想學習接口自動化測試，我這邊給你推薦一套視頻，這個視頻可以說是B站播放全網第一的接口自動化測試教程，同時在線人數(shù)到達1000人，并且還有筆記可以領取及各路大神技術交流：798478386????
【已更新】B站講的最詳細的Python接口自動化測試實戰(zhàn)教程全集（實戰(zhàn)最新版）_嗶哩嗶哩_bilibili【已更新】B站講的最詳細的Python接口自動化測試實戰(zhàn)教程全集（實戰(zhàn)最新版）共計200條視頻，包括：1.【接口自動化】目前軟件測試的市場行情以及測試人員能力標準。、2.【接口自動化】全面熟練Requests庫以及底層方法調用邏輯、3.【接口自動化】接口自動化實戰(zhàn)及正則和JsonPath提取器的應用等，UP主更多精彩視頻，請關注UP賬號。https://www.bilibili.com/video/BV17p4y1B77x/?spm_id_from=333.337&vd_source=488d25e59e6c5b111f7a1a1a16ecbe9a
3.HTTP和HTTPS基本概念
HTTP（HyperText Transfer Protocol：超文本傳輸協(xié)議）是一種用于分布式、協(xié)作式和超媒體信息系統(tǒng)的應用層協(xié)議。簡單來說就是一種發(fā)布和接收 HTML 頁面的方法，被用于在 Web 瀏覽器和網站服務器之間傳遞信息。是互聯(lián)網上應用最為廣泛的一種網絡協(xié)議，是一個客戶端和服務器端請求和應答的標準（TCP），用于從WWW服務器傳輸超文本到本地瀏覽器的傳輸協(xié)議，它可以使瀏覽器更加高效，使網絡傳輸減少。
HTTP 默認工作在 TCP 協(xié)議 80 端口，用戶訪問網站 http:// 打頭的都是標準 HTTP 服務。
HTTP 協(xié)議以明文方式發(fā)送內容，不提供任何方式的數(shù)據(jù)加密，如果攻擊者截取了Web瀏覽器和網站服務器之間的傳輸報文，就可以直接讀懂其中的信息，因此，HTTP協(xié)議不適合傳輸一些敏感信息，比如：信用卡號、密碼等支付信息。
HTTPS（Hypertext Transfer Protocol Secure：超文本傳輸安全協(xié)議）是一種透過計算機網絡進行安全通信的傳輸協(xié)議。HTTPS 經由 HTTP 進行通信，但利用 SSL/TLS 來加密數(shù)據(jù)包。HTTPS 開發(fā)的主要目的，是提供對網站服務器的身份認證，保護交換數(shù)據(jù)的隱私與完整性。是以安全為目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。
HTTPS協(xié)議的主要作用可以分為兩種：
一種是建立一個信息安全通道，來保證數(shù)據(jù)傳輸?shù)陌踩?/p>
另一種就是確認網站的真實性。
4.什么是http請求和響應?
http的工作方式為一個簡單的客戶端請求與服務端響應的應答過程。它指定了客戶端發(fā)送給服務器什么樣的消息形式以及得到什么樣的消息響應，所有的www文件都必須遵循這個標準協(xié)議, 目的是提供一種發(fā)布和接收html頁面的方法。舉個例子比如說 客戶端（瀏覽器）向服務器提交一個http請求, 那么服務器又會向客戶端這邊返回響應信息。而這些響應信息包含關于客戶端請求的狀態(tài)信息以及客戶端所需要的內容信息。如下圖所示：
5.http協(xié)議和web之間的本質
http協(xié)議和web之間的本質說白了就是就是瀏覽器和服務器打交道的。客戶端向服務器端發(fā)送Http請求,然后服務器端向客戶端返回http響應!
http協(xié)議：所謂協(xié)議，就是指雙方遵循的規(guī)范。http協(xié)議，就是瀏覽器和服務器之間進行“溝通”的一種規(guī)范。, 也就是以這個規(guī)范來向服務器發(fā)起請求, 服務器才會給客戶端進行正確的響應, 所以http有的時候也可以理解為是一種 規(guī)范、規(guī)則、標準。http協(xié)議是屬于“應用層的協(xié)議”,而且是基于TCP/IP協(xié)議的, 也就是說http通信發(fā)生在TCP/IP鏈接之上。
通俗一點說http協(xié)議就是基于TCP的一種應用層協(xié)議 它不會關系數(shù)據(jù)傳輸?shù)募毠?jié)問題,也就是說你不用去關心它下層TCP的運行邏輯, 它的核心只在于用來規(guī)定客戶端和服務端的數(shù)據(jù)傳輸格式。最早http是用來向客戶端傳輸html文件內容,默認的端口80
5.1擴展
有興趣的朋友可以自行了解一下iso網絡七層模型。
如果你接觸過socket網絡編程，就應該明白TCP和UDP這兩種使用廣泛的通信協(xié)議（建立連接、三次握 手等等，當然，這不是本文討論的重點）。
既然TCP/UDP是廣泛使用的網絡通信協(xié)議，那為啥有多出個http協(xié)議來呢？
筆者曾自己動手寫過一個簡單的web服務器處理軟件，根據(jù)我的推斷（不一定準確）。UDP協(xié)議具有不可靠性和不安全性，顯然這很難滿足web應用的需要。
而TCP協(xié)議是基于連接和三次握手的，雖然具有可靠性，但人具有一定的缺陷。但試想一下，普通的C/S架構軟件，頂多上千個Client同時連接，而B/S架構的網站，十萬人同時在線也是很平常的事兒。如果十萬個客戶端和服務器一直保持連接狀態(tài)，那服務器如何滿足承載呢？
這就衍生出了http協(xié)議?；赥CP的可靠性連接。通俗點說，就是在請求之后，服務器端立即關閉連接、釋放資源。這樣既保證了資源可用，也吸取了TCP的可靠性的優(yōu)點。
正因為這點，所以大家通常說http協(xié)議是“無狀態(tài)”的，也就是“服務器不知道你客戶端干了啥”，其實很大程度上是基于性能考慮的。以至于后來有了session之類的玩意。
通俗點說http，就是在請求和響應之后，服務器端立即關閉連接，并釋放資源，這樣既保證了資源可顯示與可用性，也吸取了TCP協(xié)議的可靠性優(yōu)點,但是缺點就無法跟蹤用戶的操作了,所以我們在后端開發(fā)的學習中才會接觸一個東西叫session和cookie技術
所以你也可以理解為http是基于請求與響應的模式, 并且是無狀態(tài)的應用層協(xié)議。
6.http請求和響應的基本原理
HTTP 消息是服務器和客戶端之間交換數(shù)據(jù)的方式。有兩種類型的消息︰ 請求（requests）-- 由客戶端發(fā)送用來觸發(fā)一個服務器上的動作；響應（responses）-- 來自服務器的應答。
任何一個http請求都只會分為兩個部分: 一個請求報文另外一個是響應報文。
請求報文是客戶端按照一定的格式生成一段文本,然后發(fā)給我們的服務端, 而服務器接收到了這樣一個請求報文就會解析里面的內容進行處理,然后做出反饋，也就是響應。
響應報文也就是服務器端根據(jù)請求報文反饋給客戶端的文本信息。
6.1http請求(request)報文基本結構
http請求(request)也叫請求報文，一個基本的HTTP請求報文由請求行（request line）、請求頭部（request header）、空行和請求數(shù)據(jù)4個部分構成。
?文章來源地址http://www.zghlxwxcb.cn/news/detail-603721.html
1.請求行（request line）:就是請求方式和協(xié)議,也就是說用于描述客戶端的請求方式,例如post/get方式, 以及請求的資源名稱和HTTP協(xié)議的版本號!
2.若干個請求頭（request header）: 這些也叫消息頭告訴服務器發(fā)送的是什么數(shù)據(jù)類型，編碼類型、請求的是哪臺主機、以及客戶端瀏覽器的一些系統(tǒng)環(huán)境 等等， 這些消息頭中有很多頭部字段名 和 對應的值它的格式為 name:value
3.空白行
4.請求正文內容?
說了這么多是不是有點懵有點暈，那宏哥就使用抓包工具抓取實際例子，我們具體看一下：
那么我們在學習http知識的時候 就可以先直接使用Fiddler來抓取一個http請求和http響應來先看看到底是什么東西!這樣也有助于我們來更好地理解http。我們可以通過Fiddler抓取網絡數(shù)據(jù)包的手段，就可以看到一個基本的http請求結構都包含哪些信息!例如一個GET方式的請求(Request)信息，如下圖所示：
6.2http響應(response)報文基本結構
http響應(response)也叫響應報文，一個基本的HTTP響應報文由響應行、響應頭、空行和響應體4個部分構成。
1.響應行：響應行一般由協(xié)議版本、狀態(tài)碼及其描述組成 比如 HTTP/1.1 200 OK
2.響應頭：響應頭用于描述服務器的基本信息，以及數(shù)據(jù)的描述，服務器通過這些數(shù)據(jù)的描述信息，可以通知客戶端如何處理等一會兒它回送的數(shù)據(jù)。
3.空白行：
4.響應體：響應體就是響應的消息體，如果是純數(shù)據(jù)就是返回純數(shù)據(jù)，如果請求的是HTML頁面，那么返回的就是HTML代碼，如果是JS就是JS代碼，如此之類。?
其實響應報文比請求報文更加簡單, 你只要能夠搞懂請求報文 那么響應報文就很容易搞懂，同樣的道理，我們可以通過Fiddler抓取網絡數(shù)據(jù)包的手段，就可以看到一個基本的http響應結構都包含哪些信息。
例如一個POST方式的請求(Request)信息 如下:例如一個POST方式的請求(Request)信息，如下圖所示：
怎么樣是不是看這一大堆腦殼都大了一直穩(wěn)穩(wěn)地響個不停呢 ？感覺無從下手，更不用說學習了， 哈哈哈不要著急，跟著宏哥慢慢來學!??????
7.Http請求(Request)報文結構圖解
我們先來看一張請求(Request)圖解，如下圖所示：
然后宏哥來逐一解剖上圖中的各個部分，解剖結果如下：
7.1請求方法 (Request method)
我們常見的一些請求方式也就是POST/GET,當然還有其他的一些請求方式, 如下表所示：
| 請求方法 | 描述 |
|---|---|
GET |
請求資源?比如常見的就是輸入一個URL去請求一個資源下來, 它也可以帶上一定的參數(shù)一起請求 |
POST |
提交資源?比如說我們想把用戶名和密碼 提交到服務器去,這個時候用POST比較好 |
HEAD |
獲取響應頭，檢查一個對象是否存在 |
PUT |
替換資源，向服務器發(fā)送數(shù)據(jù)，并存儲服務器內部 |
DELETE |
刪除資源 |
OPTIONS |
允許客戶端查看服務器的性能 |
TRACE |
顯示服務器收到的請求 常見于測試和調試診斷! |
CONNECT |
對通道提供支持 |
7.2URL (Uniform Resource Locator）
URL中文名為統(tǒng)一資源定位符 英文全稱Uniform Resource Locator ,可以使用一個URL地址來描述一個網絡上的資源，而HTTP的GET、POST、PUT、DELETE對應著對這個資源的查、改、增、刪四個操作。我們網絡中的每一信息資源都有統(tǒng)一的且在網上唯一的地址!
URL具體由4部分組成：協(xié)議、主機、域名、端口、路徑文件、[附加資源]
URL的一般語法格式為：
protocol :// hostname[:port] / path / [?query-parameters][#anchor]?
1.協(xié)議 (protocol)：指底層使用的協(xié)議類型，如：http、ftp、https、等...
2.主機名 (hostname) + 域名：HTTP服務器的IP或者域名。主機名+域名 例如: www.xsphp.com
3.端口 (port)：HTTP服務器端口，端口是一個數(shù)字, 端口是可選的 省略時使用方案是服務器默認配置的端口。例如 80、8080、..各種傳輸協(xié)議都有默認的端口號，如http協(xié)議的默認端口為80，如果URL地址省略端口，則使用默認端口號。
注意：有時候出于安全或其他考慮，可以在服務器配置上對端口進行重新定義，也就是采用非標準端口號，那么此時，URL地址中就不能省略端口號這一項。
4.路徑文件 (path)：訪問資源的路徑。由零或多個/符號隔開的字符串，一般用來表示主機上的一個目錄或文件地址。例如: /tpl/index.php
5.查詢參數(shù) 附加資源 (query-parameters)：發(fā)送給HTTP服務器的數(shù)據(jù)。
這一項在URL中也是可選的 用于給動態(tài)網頁如 PHP/JSP/ASP/ASP.NET等后端頁面 傳遞參數(shù)的一種方式，并且如果是GET請求方法, 那么可有多個參數(shù), 它們彼此用&符號隔開，每個參數(shù)的名和值用=符號隔開
語法格式: ?參數(shù)=值&參數(shù)2=值 以此類推。例如: ?id=33&age=25&name=zhangsan。舉個例子：一個比較常見的url地址， 如：https://www.xxxx.net/xxxx/xxxx/xxxx/100?num=1001.2014.3001.5501
6.anchor：錨點
7.3請消息求頭 (Request Header)
1.請求消息頭也叫消息頭告訴服務器發(fā)送的是什么數(shù)據(jù)類型，編碼類型、請求的是哪臺主機、以及客戶端瀏覽器的一些系統(tǒng)環(huán)境 等等前面已經說過了, 并且請求頭是可以由開發(fā)人員根據(jù)需求去進行自定義的。
這些消息頭中有很多頭部字段名 和 對應的值它的格式為 name:value。我們常見的一些請求頭如下表所示：
| 請求頭 | 描述 | |
|---|---|---|
Host |
主機IP地址或域名 | |
User-Agent |
提交一些客戶端相關信息，例如:?操作系統(tǒng)、瀏覽器等一些版本信息給服務器, 而這些信息可能會讓服務器按照一定的規(guī)則給客戶端返回兼容性比較好的信息! |
|
Accept |
指定客戶端接收的信息類型，例如: image/jpg,text/html,application/json也就是可以讓 客戶端告訴服務器?之后客戶端這一邊想接收到什么樣的數(shù)據(jù)格式 |
|
Accept-Charset |
告訴服務器等一會這邊客戶端需要接收的字符集編碼格式， |
例如: gb2312、iso-8859-1、utf-8
|
Accept-Encoding |
告訴服務器， 客戶端這邊可接受的內容壓縮編碼，例如gzip?可以在一定程度上節(jié)省流量! |
|
Accept-Language |
告訴服務器,?客戶端可接受的語言，例如Accept-Language：zh-cn
|
|
Authorization |
客戶端提供給服務端進行權限認證的信息, 也就是要告訴服務器端一些認證的信息，服務器才能返回響應的數(shù)據(jù)! | |
Cookie |
攜帶的COOKIE信息, 普通情況下，當一個用戶登錄成功，就會在本地保存一份cookie,下次請求就會直接帶上這個cookie信息，也就是這個用戶的相關信息 |
|
Referer |
當前文檔的URL?也就是記錄下從哪個鏈接地址提交到服務器的 |
|
Content-Type |
向服務器提交內容的格式例如： Content-Type：application/x-www-form-urlencoded總而言之,就是告訴 服務器,客戶端傳遞的內容屬于什么格式 或 其他編碼格式! |
|
Content-Length |
數(shù)據(jù)長度, 也就是客戶端向服務器端提交內容的數(shù)據(jù)長度有多少字節(jié)! |
|
Cache-Control |
緩存機制，例如：Cache-Control:no-cache
|
|
pragma |
防止頁面被緩存，與Cache-Control:no-cache作用一樣 |
|
| .............................................. |
2.我們可以用Fiddler截取一個請求頭看看，如下圖所示：
?
7.4空行
空白行：也就是在消息頭結束的下方，會存在一個空白行, 這是必須存在的, 是由HTTP標準規(guī)定的!
7.5請求體
請求體它的出現(xiàn)是要根據(jù)請求的方式不同而不同, 也就是如果是POST那么就會以鍵與值的形式進行發(fā)送, 如果是GET請求那么這里就不會包含請求正文內容。
從7.3宏哥抓包可以看出這里是一個json數(shù)據(jù)：
{"email":"xxxxxxx@qq.com","password":"xxxxxxx","remember":"0","code":"","mobile":"","type":"login","reqtimestamp":1647506402551}
?8.http響應(Response)報文結構圖解
?同樣我們先來看一張http響應(response)圖解，如下圖所示：
?
然后宏哥來逐一解剖上圖中的各個部分，解剖結果如下：
8.1響應行
響應行也叫狀態(tài)行， 上圖中響應行內部其實包含了3個重要的信息部分:
HTTP協(xié)議的版本、HTTP狀態(tài)碼、HTTP的狀態(tài)描述
1.HTTP協(xié)議的版本現(xiàn)目前都是HTTP/1.1 版本 這個沒什么好說的!
2.HTTP狀態(tài)碼 可以用來表示網頁服務器端給客戶端返回的HTTP響應狀態(tài), 通常都是3位數(shù)字的代碼, 而這些常見的狀態(tài)碼又可以分為幾種提示類型: ?? 如下表所示：
| 類別狀態(tài)碼 | 描述 |
|---|---|
1xx |
這種類別的狀態(tài)碼?為提示消息類型?通常表示請求被服務器端成功接收
|
2xx |
這種類別的狀態(tài)碼?為成功消息類型通常表示請求被服務器端成功處理
|
3xx |
這種類別的狀態(tài)碼?為重定向類型通常表示被服務器端重新定義了請求方向,需要進一步的操作以完成請求
|
4xx |
這種類別的狀態(tài)碼?為客戶端錯誤信息通常表示服務器告訴客戶端的一些錯誤消息
|
5xx |
這種類別的狀態(tài)碼?為服務端錯誤信息通常表示告訴客戶端 服務器這邊出現(xiàn)的一些錯誤信息
|
3.HTTP的狀態(tài)描述是緊跟在狀態(tài)碼后面的英文單詞
每一種具體類別狀態(tài)碼+狀態(tài)描述可以參考下表:
1xx: 提示消息類型
| 消息: | 狀態(tài)描述 | 含義 |
|---|---|---|
| 100 | Continue | 服務器僅接收到部分請求，但是一旦服務器并沒有拒絕該請求，客戶端應該繼續(xù)發(fā)送其余的請求。 |
| 101 | Switching Protocols | 服務器轉換協(xié)議：服務器將遵從客戶的請求轉換到另外一種協(xié)議。 |
2xx: 成功消息類型
| 消息: | 狀態(tài)描述 | 含義 |
|---|---|---|
| 200 | OK | 請求成功（其后是對GET和POST請求的應答文檔。） |
| 201 | Created | 請求被創(chuàng)建完成，同時新的資源被創(chuàng)建。 |
| 202 | Accepted | 供處理的請求已被接受，但是處理未完成。 |
| 203 | Non-authoritative Information | 文檔已經正常地返回，但一些應答頭可能不正確，因為使用的是文檔的拷貝。 |
| 204 | No Content | 沒有新文檔。瀏覽器應該繼續(xù)顯示原來的文檔。如果用戶定期地刷新頁面，而Servlet可以確定用戶文檔足夠新，這個狀態(tài)代碼是很有用的。 |
| 205 | Reset Content | 沒有新文檔。但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容。 |
| 206 | Partial Content | 客戶發(fā)送了一個帶有Range頭的GET請求，服務器完成了它。 |
3xx: 重定向類型
| 消息: | 狀態(tài)描述 | 含義 |
|---|---|---|
| 300 | Multiple Choices | 多重選擇。鏈接列表。用戶可以選擇某鏈接到達目的地。最多允許五個地址。 |
| 301 | Moved Permanently | 所請求的頁面已經轉移至新的url, 說通俗一點表示請求的資源分配了url，以后就應該使用這個url |
| 302 | Found | 所請求的頁面已經臨時轉移至新的url, 也就是說請求的資源臨時分配了url，本次請求暫且使用這個url， 這里302與301的區(qū)別是，302表示臨時性重定向，重定向的url還有可能還會改變。 |
| 303 | See Other | 表示請求的資源路徑發(fā)生改變，請使用GET方法請求url。其實與302一樣，但是明確指出讓我們使用GET方法請求url |
| 304 | Not Modified | 未按預期修改文檔?？蛻舳擞芯彌_的文檔并發(fā)出了一個條件性的請求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務器告訴客戶，原來緩沖的文檔還可以繼續(xù)使用。 |
| 305 | Use Proxy | 客戶請求的文檔應該通過Location頭所指明的代理服務器提取。 |
| 306 | Unused | 此代碼被用于前一版本。目前已不再使用，但是代碼依然被保留。 |
| 307 | Temporary Redirect | 被請求的頁面已經臨時移至新的url。 |
4xx: 客戶端錯誤信息
| 消息: | 狀態(tài)描述 | 含義 |
|---|---|---|
| 400 | Bad Request | 服務器未能理解請求，通常為表示請求的報文中存在語法錯誤?，比如: 提交json數(shù)據(jù)的時候，如果json格式有問題，接收端接收json，也會出現(xiàn)400 bad request
|
| 401 | Unauthorized | 被請求的頁面需要用戶名和密碼。 |
| 402 | Payment Required | 此代碼尚無法使用。 |
| 403 | Forbidden | 對被請求頁面的訪問被禁止。 |
| 404 | Not Found | 服務器無法找到被請求的頁面。 |
| 405 | Method Not Allowed | 請求中指定的方法不被允許, 請求的方式get、post、delete方法與后臺規(guī)定的方式不符合 例如: 比如：后臺方法規(guī)定的請求方式只接受get，如果用post請求，就會出現(xiàn)?405 method not allowed的提示 |
| 406 | Not Acceptable | 服務器生成的響應無法被客戶端所接受。 |
| 407 | Proxy Authentication Required | 用戶必須首先使用代理服務器進行驗證，這樣請求才會被處理。 |
| 408 | Request Timeout | 請求超出了服務器的等待時間。 |
| 409 | Conflict | 由于沖突，請求無法被完成。 |
| 410 | Gone | 被請求的頁面不可用。 |
| 411 | Length Required | "Content-Length" 未被定義。如果無此內容，服務器不會接受請求。 |
| 412 | Precondition Failed | 請求中的前提條件被服務器評估為失敗。 |
| 413 | Request Entity Too Large | 由于所請求的實體的太大，服務器不會接受請求。 |
| 414 | Request-url Too Long | 由于url太長，服務器不會接受請求。當post請求被轉換為帶有很長的查詢信息的get請求時，就會發(fā)生這種情況。 |
| 415 | Unsupported Media Type | 由于媒介類型不被支持，服務器不會接受請求, 例如: 后臺程序不支持提交的content-type類型，就會返回415
|
| 416 | 服務器不能滿足客戶在請求中指定的Range頭。 | |
| 417 | Expectation Failed |
5xx: 服務器錯誤信息
| 消息: | 狀態(tài)描述 | 含義 |
|---|---|---|
| 500 | Internal Server Error | 請求未完成。服務器遇到不可預知的情況。 |
| 501 | Not Implemented | 請求未完成。服務器不支持所請求的功能。 |
| 502 | Bad Gateway | 請求未完成。服務器從上游服務器收到一個無效的響應。 |
| 503 | Service Unavailable | 請求未完成。服務器臨時過載或當機。 |
| 504 | Gateway Timeout | 網關超時。 |
| 505 | HTTP Version Not Supported | 服務器不支持請求中指明的HTTP協(xié)議版本。 |
8.2響應頭 (Response Header)
1.響應頭也叫消息報頭 也就是服務器端要告訴客戶端的一些附加信息, 但是也有可能這些響應頭是由后端開發(fā)人員進行自定義的!
而且這里的響應頭跟請消頭 很類似, 格式也基本一樣, 它的格式為 name:value。具體宏哥這里也列舉了一些常見的響應頭 如下表所示：
| 響應頭 | 含義 |
|---|---|
Server |
HTTP服務器的軟件信息 |
Date |
響應報文的時間, 要注意返回時間的時區(qū) |
Expiros |
服務器指定的一個緩存過期時間 |
Set-Cookie |
設置Cookie, 也就是服務器返回的一段文本給客戶端,讓客戶端保存好,下次請求就把這個cookie文本帶上! |
Last-Modified |
資源最后修改時間 ，也就是客戶端有緩沖的文檔并發(fā)出了一個條件性的請求, 服務器告訴客戶，原來緩沖的文檔還可以繼續(xù)使用, 也就是說不用在從服務器中進行返回 |
Content-Type |
服務器返回給客戶端的響應類型和編碼字符集例如： Content-Type:text/html;charset=utf-8
|
Content-Length |
內容長度, 也就是服務器返回給客戶端返回的內容是多少字節(jié) |
Connection |
例如Keep-Alive，表示保持tcp鏈接不會關閉，當然它不會永久保持鏈接，我們在服務器端中是可以設置的 |
Location |
指明服務器給客戶端重定向的位置，也就是新的URL地址 如:304的情況 |
| ...................................... |
宏哥這里只列舉一下常見和常用的，其實還有更多的響應頭這里就不一一列舉了!有興趣的自己可以百度一下！
2.我們可以用Fiddler截取一個響應頭看看，如下圖所示：
?
8.3空白行
空白行也就是http規(guī)范制定的必須存在的一個空行, 空行的目的就是一種格式，也就是要告訴用戶接下來的內容就是正文內容了!
8.4響應體
響應體也就是實際從服務器返回給客戶端的正文內容,也可能是一些字符串， 也可以是任意的格式:
響應體大多數(shù)情況下都是html、json、文本、xml 這些格式!
從8.2宏哥抓包可以看出這里是一個json數(shù)據(jù)：
{"status":1,"code":10000,"message":"\u8bbf\u95ee\u6210\u529f","data":{"url":"","token":" xxxxxxxx","isenterprise":0,"uid":" xxxxxxxxx"}}
9.小結
1.HTTP 請求和響應具有相似的結構，由以下部分組成︰
（1）一行起始行用于描述要執(zhí)行的請求，或者是對應的狀態(tài)，成功或失敗。這個起始行總是單行的。
（2）一個可選的 HTTP 頭集合指明請求或描述消息正文。
（3）一個空行指示所有關于請求的元數(shù)據(jù)已經發(fā)送完畢。
（4）一個可選的包含請求相關數(shù)據(jù)的正文 (比如 HTML 表單內容), 或者響應相關的文檔。正文的大小有起始行的 HTTP 頭來指定。
起始行和 HTTP 消息中的 HTTP 頭統(tǒng)稱為請求頭，而其有效負載被稱為消息正文。
文章來源：http://www.zghlxwxcb.cn/news/detail-603721.html
?
到了這里，關于《吐血整理》保姆級系列教程-玩轉Fiddler抓包教程(1)-HTTP和HTTPS基礎知識的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！
