1.簡介

有的伙伴可能會好奇，不是講解和分享抓包工具,怎么這里開始講解HTTP和HTTPS協議了。這是因為你對HTTP協議越了解，你就能越掌握Fiddler的使用方法，反過來你越使用Fiddler，就越能幫助你了解HTTP協議。

Fiddler無論對開發人員或者測試人員來說，都是非常有用的工具。

2.前言

超文本傳輸協議HTTP協議被用于在Web瀏覽器和網站服務器之間傳遞信息，HTTP協議以明文方式發送內容，不提供任何方式的數據加密，如果攻擊者截取了Web瀏覽器和網站服務器之間的傳輸報文，就可以直接讀懂其中的信息，因此，HTTP協議不適合傳輸一些敏感信息，比如：信用卡號、密碼等支付信息。

為了解決HTTP協議的這一缺陷，需要使用另一種協議：安全套接字層超文本傳輸協議HTTPS，為了數據傳輸的安全，HTTPS在HTTP的基礎上加入了SSL協議，SSL依靠證書來驗證服務器的身份，并為瀏覽器和服務器之間的通信加密。

3.HTTP和HTTPS基本概念

HTTP（HyperText Transfer Protocol：超文本傳輸協議）是一種用于分布式、協作式和超媒體信息系統的應用層協議。 簡單來說就是一種發布和接收 HTML 頁面的方法，被用于在 Web 瀏覽器和網站服務器之間傳遞信息。是互聯網上應用最為廣泛的一種網絡協議，是一個客戶端和服務器端請求和應答的標準（TCP），用于從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議，它可以使瀏覽器更加高效，使網絡傳輸減少。

HTTP 默認工作在 TCP 協議 80 端口，用戶訪問網站?http://?打頭的都是標準 HTTP 服務。

HTTP 協議以明文方式發送內容，不提供任何方式的數據加密，如果攻擊者截取了Web瀏覽器和網站服務器之間的傳輸報文，就可以直接讀懂其中的信息，因此，HTTP協議不適合傳輸一些敏感信息，比如：信用卡號、密碼等支付信息。

HTTPS（Hypertext Transfer Protocol Secure：超文本傳輸安全協議）是一種透過計算機網絡進行安全通信的傳輸協議。HTTPS 經由 HTTP 進行通信，但利用 SSL/TLS 來加密數據包。HTTPS 開發的主要目的，是提供對網站服務器的身份認證，保護交換數據的隱私與完整性。是以安全為目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。

?

HTTPS協議的主要作用可以分為兩種：

一種是建立一個信息安全通道，來保證數據傳輸的安全；

另一種就是確認網站的真實性。

4.什么是http請求和響應?

http的工作方式為一個簡單的客戶端請求與服務端響應的應答過程。它指定了客戶端發送給服務器什么樣的消息形式以及得到什么樣的消息響應，所有的www文件都必須遵循這個標準協議, 目的是提供一種發布和接收html頁面的方法。舉個例子比如說 客戶端（瀏覽器）向服務器提交一個http請求, 那么服務器又會向客戶端這邊返回響應信息。而這些響應信息包含關于客戶端請求的狀態信息以及客戶端所需要的內容信息。如下圖所示：

?

5.http協議和web之間的本質

http協議和web之間的本質說白了就是就是瀏覽器和服務器打交道的。客戶端向服務器端發送Http請求,然后服務器端向客戶端返回http響應!

http協議：所謂協議，就是指雙方遵循的規范。http協議，就是瀏覽器和服務器之間進行“溝通”的一種規范。, 也就是以這個規范來向服務器發起請求, 服務器才會給客戶端進行正確的響應, 所以http有的時候也可以理解為是一種 規范、規則、標準。http協議是屬于“應用層的協議”,而且是基于TCP/IP協議的, 也就是說http通信發生在TCP/IP鏈接之上。

通俗一點說http協議就是基于TCP的一種應用層協議 它不會關系數據傳輸的細節問題,也就是說你不用去關心它下層TCP的運行邏輯, 它的核心只在于用來規定客戶端和服務端的數據傳輸格式。最早http是用來向客戶端傳輸html文件內容,默認的端口80

5.1擴展

感興趣的朋友可以自行了解一下iso網絡七層模型。

如果你接觸過socket網絡編程，就應該明白TCP和UDP這兩種使用廣泛的通信協議（建立連接、三次握手）。

既然TCP/UDP是廣泛使用的網絡通信協議，那為啥有多出個http協議來呢？

曾自己動手寫過一個簡單的web服務器處理軟件，根據我的推斷（不一定準確）。UDP協議具有不可靠性和不安全性，顯然這很難滿足web應用的需要。

而TCP協議是基于連接和三次握手的，雖然具有可靠性，但人具有一定的缺陷。但試想一下，普通的C/S架構軟件，頂多上千個Client同時連接，而B/S架構的網站，十萬人同時在線也是很平常的事兒。如果十萬個客戶端和服務器一直保持連接狀態，那服務器如何滿足承載呢？

這就衍生出了http協議。基于TCP的可靠性連接。通俗點說，就是在請求之后，服務器端立即關閉連接、釋放資源。這樣既保證了資源可用，也吸取了TCP的可靠性的優點。

正因為這點，所以大家通常說http協議是“無狀態”的，也就是“服務器不知道你客戶端干了啥”，其實很大程度上是基于性能考慮的。以至于后來有了session之類的玩意。

通俗點說http，就是在請求和響應之后，服務器端立即關閉連接，并釋放資源，這樣既保證了資源可顯示與可用性，也吸取了TCP協議的可靠性優點,但是缺點就無法跟蹤用戶的操作了,所以我們在后端開發的學習中才會接觸一個東西叫session和cookie技術

所以你也可以理解為http是基于請求與響應的模式, 并且是無狀態的應用層協議。

6.http請求和響應的基本原理

HTTP 消息是服務器和客戶端之間交換數據的方式。有兩種類型的消息︰ 請求（requests）-- 由客戶端發送用來觸發一個服務器上的動作；響應（responses）-- 來自服務器的應答。

任何一個http請求都只會分為兩個部分: 一個請求報文另外一個是響應報文。

請求報文是客戶端按照一定的格式生成一段文本,然后發給我們的服務端, 而服務器接收到了這樣一個請求報文就會解析里面的內容進行處理,然后做出反饋，也就是響應。

響應報文也就是服務器端根據請求報文反饋給客戶端的文本信息。

6.1http請求(request)報文基本結構

http請求(request)也叫請求報文，一個基本的HTTP請求報文由請求行（request line）、請求頭部（request header）、空行和請求數據4個部分構成。

1.請求行（request line）:就是請求方式和協議,也就是說用于描述客戶端的請求方式,例如post/get方式, 以及請求的資源名稱和HTTP協議的版本號!
2.若干個請求頭（request header）: 這些也叫消息頭告訴服務器發送的是什么數據類型，編碼類型、請求的是哪臺主機、以及客戶端瀏覽器的一些系統環境 等等， 這些消息頭中有很多頭部字段名 和 對應的值它的格式為 name:value
3.空白行
4.請求正文內容

說了這么多是不是有點懵有點暈，那就使用抓包工具抓取實際例子，我們具體看一下：

我們在學習http知識的時候 就可以先直接使用Fiddler來抓取一個http請求和http響應來先看看到底是什么東西!這樣也有助于我們來更好地理解http。我們可以通過Fiddler抓取網絡數據包的手段，就可以看到一個基本的http請求結構都包含哪些信息

例如一個GET方式的請求(Request)信息，如下圖所示：

?

6.2http響應(response)報文基本結構

http響應(response)也叫響應報文，一個基本的HTTP響應報文由響應行、響應頭、空行和響應體4個部分構成。

1.響應行：響應行一般由協議版本、狀態碼及其描述組成 比如 HTTP/1.1 200 OK
2.響應頭：響應頭用于描述服務器的基本信息，以及數據的描述，服務器通過這些數據的描述信息，可以通知客戶端如何處理等一會兒它回送的數據。
3.空白行：
4.響應體：響應體就是響應的消息體，如果是純數據就是返回純數據，如果請求的是HTML頁面，那么返回的就是HTML代碼，如果是JS就是JS代碼，如此之類。

其實響應報文比請求報文更加簡單, 你只要能夠搞懂請求報文 那么響應報文就很容易搞懂，同樣的道理，我們可以通過Fiddler抓取網絡數據包的手段，就可以看到一個基本的http響應結構都包含哪些信息。

例如一個POST方式的請求(Request)信息 如下:例如一個POST方式的請求(Request)信息，如下圖所示：

?

怎么樣是不是看這一大堆腦殼都大了一直穩穩地響個不停呢 ？感覺無從下手，更不用說學習

7.Http請求(Request)報文結構圖解

我們先來看一張請求(Request)圖解，如下圖所示：

?

然后逐一解剖上圖中的各個部分，解剖結果如下：

7.1請求方法 (Request method)

我們常見的一些請求方式也就是POST/GET,當然還有其他的一些請求方式, 如下表所示：

請求方法	描述
GET	請求資源?比如常見的就是輸入一個URL去請求一個資源下來, 它也可以帶上一定的參數一起請求
POST	提交資源?比如說我們想把用戶名和密碼 提交到服務器去,這個時候用POST比較好
HEAD	獲取響應頭，檢查一個對象是否存在
PUT	替換資源，向服務器發送數據，并存儲服務器內部
DELETE	刪除資源
OPTIONS	允許客戶端查看服務器的性能
TRACE	顯示服務器收到的請求 常見于測試和調試診斷!
CONNECT	對通道提供支持

7.2URL (Uniform Resource Locator）

URL中文名為統一資源定位符 英文全稱Uniform Resource Locator ,可以使用一個URL地址來描述一個網絡上的資源，而HTTP的GET、POST、PUT、DELETE對應著對這個資源的查、改、增、刪四個操作。我們網絡中的每一信息資源都有統一的且在網上唯一的地址!

URL具體由4部分組成：協議、主機、域名、端口、路徑文件、[附加資源]

URL的一般語法格式為：

protocol :// hostname[:port] / path / [?query-parameters][#anchor]

1.協議 (protocol)：指底層使用的協議類型，如：http、ftp、https、等...

2.主機名 (hostname) + 域名：HTTP服務器的IP或者域名。主機名+域名 例如: www.xsphp.com

3.端口 (port)：HTTP服務器端口，端口是一個數字, 端口是可選的 省略時使用方案是服務器默認配置的端口。例如 80、8080、..各種傳輸協議都有默認的端口號，如http協議的默認端口為80，如果URL地址省略端口，則使用默認端口號。

注意：有時候出于安全或其他考慮，可以在服務器配置上對端口進行重新定義，也就是采用非標準端口號，那么此時，URL地址中就不能省略端口號這一項。

4.路徑文件 (path)：訪問資源的路徑。由零或多個/符號隔開的字符串，一般用來表示主機上的一個目錄或文件地址。例如: /tpl/index.php

5.查詢參數 附加資源 (query-parameters)：發送給HTTP服務器的數據。

這一項在URL中也是可選的 用于給動態網頁如 PHP/JSP/ASP/ASP.NET等后端頁面 傳遞參數的一種方式，并且如果是GET請求方法, 那么可有多個參數, 它們彼此用&符號隔開，每個參數的名和值用=符號隔開

語法格式: ?參數=值&參數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.請求消息頭也叫消息頭告訴服務器發送的是什么數據類型，編碼類型、請求的是哪臺主機、以及客戶端瀏覽器的一些系統環境 等等前面已經說過了, 并且請求頭是可以由開發人員根據需求去進行自定義的。

這些消息頭中有很多頭部字段名 和 對應的值它的格式為 name:value。我們常見的一些請求頭如下表所示：

請求頭	描述
Host	主機IP地址或域名
User-Agent	提交一些客戶端相關信息，例如:?操作系統、瀏覽器等一些版本信息給服務器, 而這些信息可能會讓服務器按照一定的規則給客戶端返回兼容性比較好的信息!
Accept	指定客戶端接收的信息類型，<br />例如:image/jpg,text/html,application/json<br />也就是可以讓客戶端告訴服務器?之后客戶端這一邊想接收到什么樣的數據格式
Accept-Charset	告訴服務器等一會這邊客戶端需要接收的字符集編碼格式，	<br />例如:gb2312、iso-8859-1、utf-8
Accept-Encoding	告訴服務器， 客戶端這邊可接受的內容壓縮編碼，例如gzip?可以在一定程度上節省流量!
Accept-Language	告訴服務器,?客戶端可接受的語言，例如Accept-Language：zh-cn
Authorization	客戶端提供給服務端進行權限認證的信息, 也就是要告訴服務器端一些認證的信息，服務器才能返回響應的數據!
Cookie	攜帶的COOKIE信息, 普通情況下，當一個用戶登錄成功，就會在本地保存一份cookie,下次請求就會直接帶上這個cookie信息，也就是這個用戶的相關信息
Referer	當前文檔的URL?也就是紀錄下從哪個鏈接地址提交到服務器的
Content-Type	向服務器提交內容的格式<br />例如：Content-Type：application/x-www-form-urlencoded<br />總而言之,就是告訴服務器,客戶端傳遞的內容屬于什么格式 或 其他編碼格式!
Content-Length	數據長度, 也就是客戶端向服務器端提交內容的數據長度有多少字節!
Cache-Control	緩存機制，例如：Cache-Control:no-cache
pragma	防止頁面被緩存，與Cache-Control:no-cache作用一樣
..............................................	?

2.我們可以用Fiddler截取一個請求頭看看，如下圖所示：

?

7.4空行

空白行：也就是在消息頭結束的下方，會存在一個空白行, 這是必須存在的, 是由HTTP標準規定的!

7.5請求體

請求體它的出現是要根據請求的方式不同而不同, 也就是如果是POST那么就會以鍵與值的形式進行發送, 如果是GET請求那么這里就不會包含請求正文內容。

從7.3抓包可以看出這里是一個json數據：

{"email":"xxxxxxx@qq.com","password":"xxxxxxx","remember":"0","code":"","mobile":"","type":"login","reqtimestamp":1647506402551}

8.http響應(Response)報文結構圖解

同樣我們先來看一張http響應(response)圖解，如下圖所示：

?

然后來逐一解剖上圖中的各個部分，解剖結果如下：

8.1響應行

響應行也叫狀態行， 上圖中響應行內部其實包含了3個重要的信息部分:

HTTP協議的版本、HTTP狀態碼、HTTP的狀態描述

1.HTTP協議的版本現目前都是HTTP/1.1 版本 這個沒什么好說的!

2.HTTP狀態碼 可以用來表示網頁服務器端給客戶端返回的HTTP響應狀態, 通常都是3位數字的代碼, 而這些常見的狀態碼又可以分為幾種提示類型:如下表所示：

類別狀態碼	描述
1xx	這種類別的狀態碼?為提示消息類型?通常表示請求被服務器端成功接收
2xx	這種類別的狀態碼?為成功消息類型通常表示請求被服務器端成功處理
3xx	這種類別的狀態碼?為重定向類型通常表示被服務器端重新定義了請求方向,需要進一步的操作以完成請求
4xx	這種類別的狀態碼?為客戶端錯誤信息通常表示服務器告訴客戶端的一些錯誤消息
5xx	這種類別的狀態碼?為服務端錯誤信息通常表示告訴客戶端 服務器這邊出現的一些錯誤信息

3.HTTP的狀態描述是緊跟在狀態碼后面的英文單詞

每一種具體類別狀態碼+狀態描述可以參考下表:

1xx: 提示消息類型

消息:	狀態描述	含義
100	Continue	服務器僅接收到部分請求，但是一旦服務器并沒有拒絕該請求，客戶端應該繼續發送其余的請求。
101	Switching Protocols	服務器轉換協議：服務器將遵從客戶的請求轉換到另外一種協議。

2xx: 成功消息類型

消息:	狀態描述	含義
200	OK	請求成功（其后是對GET和POST請求的應答文檔。）
201	Created	請求被創建完成，同時新的資源被創建。
202	Accepted	供處理的請求已被接受，但是處理未完成。
203	Non-authoritative Information	文檔已經正常地返回，但一些應答頭可能不正確，因為使用的是文檔的拷貝。
204	No Content	沒有新文檔。瀏覽器應該繼續顯示原來的文檔。如果用戶定期地刷新頁面，而Servlet可以確定用戶文檔足夠新，這個狀態代碼是很有用的。
205	Reset Content	沒有新文檔。但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容。
206	Partial Content	客戶發送了一個帶有Range頭的GET請求，服務器完成了它。

3xx: 重定向類型

消息:	狀態描述	含義
300	Multiple Choices	多重選擇。鏈接列表。用戶可以選擇某鏈接到達目的地。最多允許五個地址。
301	Moved Permanently	所請求的頁面已經轉移至新的url, 說通俗一點表示請求的資源分配了url，以后就應該使用這個url
302	Found	所請求的頁面已經臨時轉移至新的url, 也就是說請求的資源臨時分配了url，本次請求暫且使用這個url， 這里302與301的區別是，302表示臨時性重定向，重定向的url還有可能還會改變。
303	See Other	表示請求的資源路徑發生改變，請使用GET方法請求url。其實與302一樣，但是明確指出讓我們使用GET方法請求url
304	Not Modified	未按預期修改文檔。客戶端有緩沖的文檔并發出了一個條件性的請求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務器告訴客戶，原來緩沖的文檔還可以繼續使用。
305	Use Proxy	客戶請求的文檔應該通過Location頭所指明的代理服務器提取。
306	Unused	此代碼被用于前一版本。目前已不再使用，但是代碼依然被保留。
307	Temporary Redirect	被請求的頁面已經臨時移至新的url。

4xx: 客戶端錯誤信息

消息:	狀態描述	含義
400	Bad Request	服務器未能理解請求，通常為表示請求的報文中存在語法錯誤?，比如: 提交json數據的時候，如果json格式有問題，接收端接收json，也會出現400 bad request
401	Unauthorized	被請求的頁面需要用戶名和密碼。
402	Payment Required	此代碼尚無法使用。
403	Forbidden	對被請求頁面的訪問被禁止。
404	Not Found	服務器無法找到被請求的頁面。
405	Method Not Allowed	請求中指定的方法不被允許, 請求的方式get、post、delete方法與后臺規定的方式不符合 例如: 比如： 后臺方法規定的請求方式只接受get，如果用post請求，就會出現?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請求時，就會發生這種情況。
415	Unsupported Media Type	由于媒介類型不被支持，服務器不會接受請求, 例如: 后臺程序不支持提交的content-type類型，就會返回415
416	?	服務器不能滿足客戶在請求中指定的Range頭。
417	Expectation Failed	?

5xx: 服務器錯誤信息

消息:	狀態描述	含義
500	Internal Server Error	請求未完成。服務器遇到不可預知的情況。
501	Not Implemented	請求未完成。服務器不支持所請求的功能。
502	Bad Gateway	請求未完成。服務器從上游服務器收到一個無效的響應。
503	Service Unavailable	請求未完成。服務器臨時過載或當機。
504	Gateway Timeout	網關超時。
505	HTTP Version Not Supported	服務器不支持請求中指明的HTTP協議版本。

8.2響應頭 (Response Header)

1.響應頭也叫消息報頭 也就是服務器端要告訴客戶端的一些附加信息, 但是也有可能這些響應頭是由后端開發人員進行自定義的!

而且這里的響應頭跟請消頭 很類似, 格式也基本一樣, 它的格式為 name:value。具體這里也列舉了一些常見的響應頭 如下表所示：

響應頭	含義
Server	HTTP服務器的軟件信息
Date	響應報文的時間, 要注意返回時間的時區
Expiros	服務器指定的一個緩存過期時間
Set-Cookie	設置Cookie, 也就是服務器返回的一段文本給客戶端,讓客戶端保存好,下次請求就把這個cookie文本帶上!
Last-Modified	資源最后修改時間 ，也就是客戶端有緩沖的文檔并發出了一個條件性的請求, 服務器告訴客戶，原來緩沖的文檔還可以繼續使用, 也就是說不用在從服務器中進行返回
Content-Type	服務器返回給客戶端的響應類型和編碼字符集<br />例如：Content-Type:text/html;charset=utf-8
Content-Length	內容長度, 也就是服務器返回給客戶端返回的內容是多少字節
Connection	例如Keep-Alive，表示保持tcp鏈接不會關閉，當然它不會永久保持鏈接，我們在服務器端中是可以設置的
Location	指明服務器給客戶端重定向的位置，也就是新的URL地址 如:304的情況
......................................	?

這里只例舉一下常見和常用的，其實還有更多的響應頭這里就不一一列舉了!有興趣的自己可以百度一下！

2.我們可以用Fiddler截取一個響應頭看看，如下圖所示：

?

8.3空白行

空白行也就是http規范制定的必須存在的一個空行, 空行的目的就是一種格式，也就是要告訴用戶接下來的內容就是正文內容了!

8.4響應體

響應體也就是實際從服務器返回給客戶端的正文內容,也可能是一些字符串， 也可以是任意的格式:

響應體大多數情況下都是html、json、文本、xml 這些格式!

從8.2抓包可以看出這里是一個json數據：

{"status":1,"code":10000,"message":"\u8bbf\u95ee\u6210\u529f","data":{"url":"","token":" xxxxxxxx","isenterprise":0,"uid":" xxxxxxxxx"}}

9.小結

1.HTTP 請求和響應具有相似的結構，由以下部分組成︰

（1）一行起始行用于描述要執行的請求，或者是對應的狀態，成功或失敗。這個起始行總是單行的。

（2）一個可選的 HTTP 頭集合指明請求或描述消息正文。

（3）一個空行指示所有關于請求的元數據已經發送完畢。

（4）一個可選的包含請求相關數據的正文 (比如 HTML 表單內容), 或者響應相關的文檔。 正文的大小有起始行的 HTTP 頭來指定。

起始行和 HTTP 消息中的 HTTP 頭統稱為請求頭，而其有效負載被稱為消息正文。

?

好了，對于Http和Https相關的的知識點就說這么多了,對于學習fiddler足夠了！

接下來你就可以愉快的學習Fiddler了

?