iddler是什么?

在正式學習Fiddler之前， 我們還是要對Fiddler有一個初步的認識!

Fiddler是以web proxy代理服務器的形式工作的 , 它也是一個http協議數據抓包與調試代理工具，它能夠記錄和檢查當前你的電腦和互聯網之間的http消息, 也就是說可以將網絡傳輸發送與接受的數據包進行截獲、重發、編輯、轉存等操作 還可以用來檢測網絡安全。 是不是感覺很強大!

Fiddler主要能干什么?

Fiddler是一個客戶端和服務端的一個http代理工具 , 客戶端和服務端彼此之間的交流都可以被Fiddler所監聽到!

Fiddler不僅僅是一款非常強大的抓包工具，還是一款web調試的利器

它能夠實現以下功能:

0. 監控我們瀏覽器所有的http/https的信息和流量，也就是所有的請求，所有的流量都可以監聽
1. 當監聽截取到http請求之后，就可以做一些查看 分析瀏覽器請求的內容細節,就可以偽造一些請求 偽造一個服務器的響應都是可以的!
2. 還可以測試網站的性能
3. 解密https的web會話
4. 全局、局部斷點功能!

Fiddler的應用場景也很廣泛

0. 接口測試
1. 接口調試
2. 線上環境調試
3. web項目性能分析
4. 前后端bug監測
5. 弱網斷網監測
6. hosts配置監測
7. mock模擬測試

要知道Fiddler作為系統代理，所有的來自微軟互聯網服務的http請求在到達目標Web服務器之前都會經過Fiddler，同樣的，所有的Http響應都會在返回客戶端之前也會經過Fiddler。

為什么要學習Fiddler?

因為我們做開發必然要和http打交道對吧， 并且還有一些新手朋友也要學習http的相關知識，但是http的知識點比較多和雜亂,如果你沒有一個看得見摸得著的數據參照，是很難去把控http信息, 那么要理解http協議，我個人建議可以先從抓包工具開始從淺入深的形式慢慢了解http以及Fiddler這款抓包工具的使用

所以不管你是分析http還是剛剛學習http的朋友 ,都可以先學習一下Fiddler抓包工具!

并且在windows系統下只要一提到抓包肯定首選的就是Fiddler

總之學習了Fiddler之后，會讓你對http的理解更上一層樓!

下載Fiddler

官方下載地址

https://www.telerik.com/download/fiddler

填寫好電子郵箱和國家地區 點擊Download for windows就可以下載了

如圖

注意 這個Fiddler工具是基于.NET Framework的 ,因為Fiddler是c#開發的

如果是比較老的windows系統要保證運行環境!??

Fiddler的安裝方法也很簡單 獲取到安裝包之后,直接選擇安裝路徑 或 無腦下一步就可以了!??

安裝成功會顯示如下界面!

認識一下軟件體系結構—B/S 與 C/S架構

B/S架構

在了解Fiddler原理之前，還先清楚我們web最基本的架構是什么，就是B/S架構, 它也是目前最常用的一種軟件架構

B就是瀏覽器(Browsers) 也就是客戶端 這邊

S就是服務器端(Server)也就是web服務器這邊

我們平常的web服務、web項目、web應用都是運行在服務端的, 那么通過綁定ip地址+端口監聽的形式來接收和處理一些前端也就是客戶端發起的http請求, 從而客戶端通過http協議和請求就可以獲取到指定服務器上的頁面 文件 資源、等等..

如圖

舉個例子

當你在瀏覽器地址欄上輸入百度的地址之后，服務器端就會給你返回一個百度的html頁面資源

總結

B/S架構就是瀏覽器/服務器的一種交互模式，是Browser/Server的簡稱。

并且這種架構的軟件不需要在用戶的電腦上安裝任何客戶端程序，只需要在用戶的電腦上安裝瀏覽器即可。

用戶僅僅使用瀏覽器通過web服務器和數據庫做交互，交互的結果將會以html網頁的形式顯示在瀏覽器上。

C/S架構 [了解]

出了我們的B/S架構，其實還有一種就是C/S架構是客戶端/服務端的一種交互模式，是Client/Server的簡稱。它是早期常用的一種軟件架構，這種架構的軟件需要在用戶的電腦上安裝客戶端程序, 有興趣的朋友可以自行了解，這里就不過多贅述了!

我們平常在進行軟件開發時，通常會根據需求在兩種基本架構中進行選擇!

HTTP 基礎知識

學習Fiddler的時候,HTTP的知識點也是必不可少的, 所以這里必須要給大家簡單的介紹一下HTTP的相關知識!

http中文意思為超文本傳輸協議 英文全稱為Hyper Text Transfer Protocol

它是用于萬維網服務器傳輸超文本到本地瀏覽器的一種傳輸協議

目的是保證客戶端與服務端之間的通信

什么是http請求和響應?

http的工作方式為一個簡單的客戶端請求 與 服務端響應的應答過程

它指定了客戶端發送給服務器什么樣的消息形式以及得到什么樣的消息響應

所有的www文件都必須遵循這個標準協議, 目的是提供一種發布和接收html頁面的方法

舉個例子

比如說 客戶端（瀏覽器）向服務器提交一個http請求, 那么服務器又會向客戶端這邊返回響應信息。而這些響應信息包含關于客戶端請求的狀態信息以及客戶端所需要的內容信息。

如圖

http協議和web之間的本質

其實就是瀏覽器和服務器打交道的

客戶端向服務器端發送Http請求,然后服務器端向客戶端返回http響應!

http協議就是瀏覽器和服務器之間進行溝通的一種規范, 也就是以這個規范來向服務器發起請求, 服務器才會給客戶端進行正確的響應, 所以http有的時候也可以理解為是一種 規范、規則、標準

http協議是屬于應用層的協議,而且是基于TCP/IP協議的, 也就是說http通信發生在TCP/IP鏈接之上

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

最早http是用來向客戶端傳輸html文件內容,默認的端口80

擴展

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

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

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

http請求和響應的基本原理

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

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

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

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

http請求(request)也叫請求報文一個基本的http請求報文結構分為如下幾點:

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

抓包了解一下

那么我們在學習http知識的時候 就可以先直接使用Fiddler來抓取一個http請求和http響應來先看看到底是什么東西!

這樣也有助于一些新手來理解http!

我們可以通過Fiddler抓取網絡數據包的手段，就可以看到一個基本的http請求結構都包含哪些信息!

例如一個GET方式的請求(Request)信息 如下:

GET https://www.baidu.com/?name=zhangsan HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="100", "Google Chrome";v="100"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9

例如一個POST方式的請求(Request)信息 如下:

POST https://api.codelife.cc/stat/userHm HTTP/1.1
Host: api.codelife.cc
Connection: keep-alive
Content-Length: 48
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="100", "Google Chrome";v="100"
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36
Content-Type: application/json
Accept: application/json, text/plain, */*
sec-ch-ua-platform: "Windows"
version: 1.2.27
Origin: chrome-extension://mhloojimgilafopcmlcikiidgbbnelip
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9

{"fp":"4c49c2fd79e1658546e4b8ad","tn":6}

怎么樣 是不是看這一大堆腦殼都大了呢 ？ 哈哈哈不要著急，我們慢慢來學!

我們先來看一張請求(Request)圖解

如圖

然后我們來逐一拆解上圖中的各個部分!

1.請求方式 (Request method)

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

2.URL (Uniform Resource Locator)

URL中文名為統一資源定位符 英文全稱Uniform Resource Locator ,

我們網絡中的每一信息資源都有統一的且在網上唯一的地址!

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

URL的一般語法格式為：

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

1.協議 (protocol)

協議有http、ftp、https、等...

2.主機名 (hostname) + 域名

主機名+域名 例如: www.xsphp.com

3.端口 (port)

端口是一個數字, 端口是可選的 省略時使用方案是服務器默認配置的端口

例如 80、8080、..

各種傳輸協議都有默認的端口號，如http協議的默認端口為80

如果URL地址省略端口，則使用默認端口號

注意

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

4.路徑文件 (path)

由零或多個/符號隔開的字符串，一般用來表示主機上的一個目錄或文件地址

例如: /tpl/index.php

5.查詢參數 附加資源 (query-parameters)

這一項在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

3.請消息求頭 (Request Header)

請求消息頭也叫消息頭告訴服務器發送的是什么數據類型，編碼類型、請求的是哪臺主機、以及客戶端瀏覽器的一些系統環境 等等前面已經說過了, 并且請求頭是可以由開發人員根據需求去進行自定義的

這些消息頭中有很多頭部字段名 和 對應的值它的格式為 name:value

我們常見的一些請求頭如下表:

我們可以用Fiddler截取一個請求頭看看

如圖

4.空行

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

5.請求體

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

http響應報文 (Response)基本結構

http響應(response)也叫響應報文

其實響應報文比請求報文更加簡單, 你只要能夠搞懂請求報文 那么響應報文就很容易搞懂!

http響應(response)的一個基本結構分為如下幾點:

0. 響應行
1. 響應頭
2. 空白行
3. 響應體

我們可以通過Fiddler抓取網絡數據包的手段，就可以看到一個基本的http響應結構都包含哪些信息!

舉個例子

如果你還看不明白 那么我們先來看一張http響應(response)圖解 你就會明白了!

然后我們來逐一拆解上圖中的各個部分!

1.響應行

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

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

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

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

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

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

1xx: 提示消息類型

2xx: 成功消息類型

3xx: 重定向類型

4xx: 客戶端錯誤信息

5xx: 服務器錯誤信息

2.響應頭 (Response Header)

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

而且這里的響應頭跟請消頭 很類似, 格式也基本一樣, 它的格式為 name:value

具體我這里也列舉了一些常見的響應頭 如下表:

還有更多的響應頭這里就不一一列舉了!

3.空白行

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

4.響應體

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

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

小結

對于http相關的的知識點 就說這么多了,對于學習fiddler足夠了

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

Fiddler運行原理

Fiddler的原理簡單點說就是通過改寫HTTP代理然后讓網絡數據從Fiddler這邊通過 這樣子來監控并且截取到網絡信息數據。當你打開Fiddler的時候, 就已經設置好了瀏覽器的代理了。當你關閉的時候，它會自動的幫你把代理還原

之前也說過了 B/S架構就是客戶端和服務器之間的 請求和響應, 剛剛我們也知道了Fiddler通過代理的形式來進行監聽，它在請求和響應中起到一個什么樣的角色呢?

這里還要清楚一點的就是 瀏覽器默認走的是我們的系統代理

其實這里的代理監聽 就是在 請求和響應之間插了一腳, 讓fiddler成為系統代理

在你安裝好Fiddler之后啟動，并可以打開菜單欄中的Tools--->options--->Connections

如下圖

看到了吧,這里有一句Act as system proxy on startup意思就是(在啟動時充當系統代理),并且默認監聽端口設置為了8888

如圖

這里以chrome瀏覽器為例:

只要fiddler一旦啟動并開始監聽的時候，就會默認成為系統代理, 所以你的網絡請求 也就會被fiddler所抓取到!

如圖

或者如下圖一樣Fiddler就是一個中間的proxy(代理服務器)

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-ItS8dJ6N-1651910920350)(img/fiddler_3-3.png)]

當關閉fiddler的時候，手動設置代理選項就會被清空

所以我們才會說Fiddler是介于客戶端和服務器中間的一個角色, 監控客戶端和服務器所有通信的過程!

小結

Fiddler是以代理WEB服務器的形式工作的,瀏覽器與服務器之間通過建立TCP連接以HTTP協議進行通信，

瀏覽器默認通過自己發送HTTP請求到服務器，本地使用代理地址:127.0.0.1, 端口:8888.

而當Fiddler開啟會自動設置系統代理， 退出的時候它會自動注銷代理，這樣就不會影響別的程序。

但是如果Fiddler非正常退出，這時可能會因為Fiddler沒有自動注銷，而會造成網頁無法訪問。

解決的辦法是重新啟動下Fiddler就可以了, 這也是有很多新手安裝了Fiddler之后導致一些網絡無法訪問的原因之一!

"點贊" "評論" "收藏"

大家的支持就是我堅持創作下去的動力!?

?如果以上內容有任何錯誤或者不準確的地方，歡迎在下面 留個言指出、或者你有更好的想法，歡迎一起交流學習?

.簡介

有的小伙伴或者童鞋們可能會好奇地問：不是講解和分享抓包工具了怎么這里開始講解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,當然還有其他的一些請求方式, 如下表所示：

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。我們常見的一些請求頭如下表所示：

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位數字的代碼, 而這些常見的狀態碼又可以分為幾種提示類型: 如下表所示：

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

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

1xx: 提示消息類型

2xx: 成功消息類型

3xx: 重定向類型

4xx: 客戶端錯誤信息

5xx: 服務器錯誤信息

8.2響應頭 (Response Header)

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

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

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

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了

明：本公眾號大部分文章來自作者日常學習筆記，部分文章經作者授權及其他公眾號白名單轉載。 未經授權嚴禁轉載。 如需轉載，請聯系開百。

請不要利用文章中的相關技術從事非法測試。 由此產生的任何不良后果與文章作者及本公眾號無關。

目前大圖推送僅針對常讀、加星的公眾號顯示。 建議大家“把瀟湘新安定為明星”，不然可能看不到！

本文已經作者@蘇雅圖師師許可轉發至公眾號。 如果喜歡的話可以閱讀他的原創文章以及其他文章。

文章來源：博客園（蘇雅圖）原文地址：https://www.cnblogs.com/arrdres/p/17335376.html

0x01 開門見山

首先我們來回顧一下“微信綁定手機號數據庫被下庫”的事件。 我也第一時間得知了這個消息，然后跟蹤了整個事件的經過。 以下是該事件的相關截圖以及近期泄露的10000個數據樣本：

我個人認為這件事沒什么。 最好關注一下此前的45億快遞數據查詢通道近日疑似復活的消息。

消息就是這樣傳開的。 真實性尚未確定，因為作者不會冒風險，查詢個人信息就意味著賬號和個人信息必然會測試是否真實，但我們可以知道的是，之前的查詢渠道名為“星鏈”，現在稱為星盾。

我為什么要提到這兩件事呢？ 因為我要寫的微信小程序抓包教程和第一個事件有關。 也可以說是受到“坐一旁”的啟發。 事件發生后，“如何獲取某個微信賬號的wxid”的問題迅速在某個圈子里火爆，也有人很快給出了思路。 方法也很簡單。 我在這里簡單地重現一下：

特別說明：此思路僅適用于iOS系統（蘋果系統）

1. 從 Apple App Store 安裝“Stream”軟件：

2. 配置代理并安裝證書。 內置教程，此處省略。

3. 開始抓包。 （為了方便我在iPad上測試）

4.在群里找到目標，點頭頭像，右上角進行投訴。

選擇任何投訴原因。 注意，這并不是真正的投訴，只是獲取加載的數據包。 最后一步不需要提交。 返回工具頁面，點擊上傳流量即可查看數據包。

選擇“按域名”查看數據。 一般情況下，上報功能會請求weixin110子域名。

選擇紅框中的POST請求，exposeh5cgi是標識符。

選擇請求模塊以查看請求的數據包。

然后向下滾動并單擊以查看請求正文。

箭頭處的realChatUser是“投訴用戶”的wxid。 獲得wxid意味著即使不知道對方的微信名也能找到用戶的手機號碼。

這就是我今天要分享的抓包思路。 同理，微信小程序也是可以的。 我應該不是第一個知道的，但是實戰中有一些細節需要注意。 我會在文章最后講到。 因為可能有人要反駁我，微信小程序抓包不是有很多思路嗎？ 確實，你是對的。 毫不夸張地說，你所知道的想法我都明白，但問題是很多想法很容易失敗。 這里我列出一些基本的想法。

第一種：使用Burpsuite配合模擬器進行抓包

眾所周知，Burpsuite是滲透測試必備的抓包工具。 從微信小程序中抓包也應該很方便。 您可以通過在模擬器中配置證書來抓包。

起初這個想法大家都知道，但后來微信改變了規則，這個方法就失效了。 前幾個月有消息稱微信似乎禁止登錄模擬器，檢測到會警告賬號被封禁。 該消息是否屬實尚未得到證實。 當然，更專業的同學可以安裝“Xpose框架”之類的東西，讓模擬器更加強大，或者說可以繞過微信檢測機制嗎？

第二種：使用Fiddler在微信PC端抓包

Fiddler 也是一個功能強大的數據包捕獲工具，或數據包分析工具，可以調試計算機上的 HTTP 流量。

有些事情Burpsuite做不到，它可以，而且我個人用得比較少。 Fiddler既適用于微信PC端，也適用于模擬器，但這個想法似乎從去年11月左右就已經過期了，具體細節尚未確認。

第三種方法：微信PC端使用Charles抓包

根據官網介紹，Charles是一個HTTP代理和HTTP監控工具，主要適用于網頁瀏覽器。

查爾斯俗稱“花瓶”。 應該說，它是安全圈中的“后來者”抓包工具。 我平時經常使用它，因為這個工具可以捕獲某些“特殊”數據包，例如JavaScript觸發的數據。 包？ 我也不知道怎么形容。

需要補充的是，上述三種思路還可以結合在蘋果手機上設置“網絡代理”，使用“電腦工具”來捕獲手機的數據包。 具體來說，還可以用來捕獲“微信小程序”或“手機QQ”的一些數據包。這個想法筆者親自測試過，但目前還不清楚是否仍然有效。