整合營(yíng)銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
在正式學(xué)習(xí)Fiddler之前， 我們還是要對(duì)Fiddler有一個(gè)初步的認(rèn)識(shí)!
Fiddler是以web proxy代理服務(wù)器的形式工作的 , 它也是一個(gè)http協(xié)議數(shù)據(jù)抓包與調(diào)試代理工具，它能夠記錄和檢查當(dāng)前你的電腦和互聯(lián)網(wǎng)之間的http消息, 也就是說(shuō)可以將網(wǎng)絡(luò)傳輸發(fā)送與接受的數(shù)據(jù)包進(jìn)行截獲、重發(fā)、編輯、轉(zhuǎn)存等操作 還可以用來(lái)檢測(cè)網(wǎng)絡(luò)安全。 是不是感覺很強(qiáng)大!
Fiddler是一個(gè)客戶端和服務(wù)端的一個(gè)http代理工具 , 客戶端和服務(wù)端彼此之間的交流都可以被Fiddler所監(jiān)聽到!
Fiddler不僅僅是一款非常強(qiáng)大的抓包工具，還是一款web調(diào)試的利器
它能夠?qū)崿F(xiàn)以下功能:
Fiddler的應(yīng)用場(chǎng)景也很廣泛
要知道Fiddler作為系統(tǒng)代理，所有的來(lái)自微軟互聯(lián)網(wǎng)服務(wù)的http請(qǐng)求在到達(dá)目標(biāo)Web服務(wù)器之前都會(huì)經(jīng)過(guò)Fiddler，同樣的，所有的Http響應(yīng)都會(huì)在返回客戶端之前也會(huì)經(jīng)過(guò)Fiddler。
因?yàn)槲覀冏鲩_發(fā)必然要和http打交道對(duì)吧， 并且還有一些新手朋友也要學(xué)習(xí)http的相關(guān)知識(shí)，但是http的知識(shí)點(diǎn)比較多和雜亂,如果你沒(méi)有一個(gè)看得見摸得著的數(shù)據(jù)參照，是很難去把控http信息, 那么要理解http協(xié)議，我個(gè)人建議可以先從抓包工具開始從淺入深的形式慢慢了解http以及Fiddler這款抓包工具的使用
所以不管你是分析http還是剛剛學(xué)習(xí)http的朋友 ,都可以先學(xué)習(xí)一下Fiddler抓包工具!
并且在windows系統(tǒng)下只要一提到抓包肯定首選的就是Fiddler
總之學(xué)習(xí)了Fiddler之后，會(huì)讓你對(duì)http的理解更上一層樓!
官方下載地址
https://www.telerik.com/download/fiddler
填寫好電子郵箱和國(guó)家地區(qū) 點(diǎn)擊Download for windows就可以下載了
如圖
注意 這個(gè)Fiddler工具是基于.NET Framework的 ,因?yàn)?/span>Fiddler是c#開發(fā)的
如果是比較老的windows系統(tǒng)要保證運(yùn)行環(huán)境!??
Fiddler的安裝方法也很簡(jiǎn)單 獲取到安裝包之后,直接選擇安裝路徑 或 無(wú)腦下一步就可以了!??
安裝成功會(huì)顯示如下界面!
在了解Fiddler原理之前，還先清楚我們web最基本的架構(gòu)是什么，就是B/S架構(gòu), 它也是目前最常用的一種軟件架構(gòu)
B就是瀏覽器(Browsers) 也就是客戶端 這邊
S就是服務(wù)器端(Server)也就是web服務(wù)器這邊
我們平常的web服務(wù)、web項(xiàng)目、web應(yīng)用都是運(yùn)行在服務(wù)端的, 那么通過(guò)綁定ip地址+端口監(jiān)聽的形式來(lái)接收和處理一些前端也就是客戶端發(fā)起的http請(qǐng)求, 從而客戶端通過(guò)http協(xié)議和請(qǐng)求就可以獲取到指定服務(wù)器上的頁(yè)面 文件 資源、等等..
如圖
舉個(gè)例子
當(dāng)你在瀏覽器地址欄上輸入百度的地址之后，服務(wù)器端就會(huì)給你返回一個(gè)百度的html頁(yè)面資源
總結(jié)
B/S架構(gòu)就是瀏覽器/服務(wù)器的一種交互模式，是Browser/Server的簡(jiǎn)稱。
并且這種架構(gòu)的軟件不需要在用戶的電腦上安裝任何客戶端程序，只需要在用戶的電腦上安裝瀏覽器即可。
用戶僅僅使用瀏覽器通過(guò)web服務(wù)器和數(shù)據(jù)庫(kù)做交互，交互的結(jié)果將會(huì)以html網(wǎng)頁(yè)的形式顯示在瀏覽器上。
出了我們的B/S架構(gòu)，其實(shí)還有一種就是C/S架構(gòu)是客戶端/服務(wù)端的一種交互模式，是Client/Server的簡(jiǎn)稱。它是早期常用的一種軟件架構(gòu)，這種架構(gòu)的軟件需要在用戶的電腦上安裝客戶端程序, 有興趣的朋友可以自行了解，這里就不過(guò)多贅述了!
我們平常在進(jìn)行軟件開發(fā)時(shí)，通常會(huì)根據(jù)需求在兩種基本架構(gòu)中進(jìn)行選擇!
學(xué)習(xí)Fiddler的時(shí)候,HTTP的知識(shí)點(diǎn)也是必不可少的, 所以這里必須要給大家簡(jiǎn)單的介紹一下HTTP的相關(guān)知識(shí)!
http中文意思為超文本傳輸協(xié)議 英文全稱為Hyper Text Transfer Protocol
它是用于萬(wàn)維網(wǎng)服務(wù)器傳輸超文本到本地瀏覽器的一種傳輸協(xié)議
目的是保證客戶端與服務(wù)端之間的通信
http的工作方式為一個(gè)簡(jiǎn)單的客戶端請(qǐng)求 與 服務(wù)端響應(yīng)的應(yīng)答過(guò)程
它指定了客戶端發(fā)送給服務(wù)器什么樣的消息形式以及得到什么樣的消息響應(yīng)
所有的www文件都必須遵循這個(gè)標(biāo)準(zhǔn)協(xié)議, 目的是提供一種發(fā)布和接收html頁(yè)面的方法
舉個(gè)例子
比如說(shuō) 客戶端（瀏覽器）向服務(wù)器提交一個(gè)http請(qǐng)求, 那么服務(wù)器又會(huì)向客戶端這邊返回響應(yīng)信息。而這些響應(yīng)信息包含關(guān)于客戶端請(qǐng)求的狀態(tài)信息以及客戶端所需要的內(nèi)容信息。
如圖
其實(shí)就是瀏覽器和服務(wù)器打交道的
客戶端向服務(wù)器端發(fā)送Http請(qǐng)求,然后服務(wù)器端向客戶端返回http響應(yīng)!
http協(xié)議就是瀏覽器和服務(wù)器之間進(jìn)行溝通的一種規(guī)范, 也就是以這個(gè)規(guī)范來(lái)向服務(wù)器發(fā)起請(qǐng)求, 服務(wù)器才會(huì)給客戶端進(jìn)行正確的響應(yīng), 所以http有的時(shí)候也可以理解為是一種 規(guī)范、規(guī)則、標(biāo)準(zhǔn)
http協(xié)議是屬于應(yīng)用層的協(xié)議,而且是基于TCP/IP協(xié)議的, 也就是說(shuō)http通信發(fā)生在TCP/IP鏈接之上
通俗一點(diǎn)說(shuō)http協(xié)議就是基于TCP的一種應(yīng)用層協(xié)議 它不會(huì)關(guān)系數(shù)據(jù)傳輸?shù)募?xì)節(jié)問(wèn)題,也就是說(shuō)你不用去關(guān)心它下層TCP的運(yùn)行邏輯, 它的核心只在于用來(lái)規(guī)定客戶端和服務(wù)端的數(shù)據(jù)傳輸格式
最早http是用來(lái)向客戶端傳輸html文件內(nèi)容,默認(rèn)的端口80
擴(kuò)展
有興趣的朋友可以自行了解一下iso網(wǎng)絡(luò)七層模型
通俗點(diǎn)說(shuō)http，就是在請(qǐng)求和響應(yīng)之后，服務(wù)器端立即關(guān)閉連接，并釋放資源，這樣既保證了資源可顯示與可用性，也吸取了TCP協(xié)議的可靠性優(yōu)點(diǎn),但是缺點(diǎn)就無(wú)法跟蹤用戶的操作了,所以我們?cè)?/span>后端開發(fā)的學(xué)習(xí)中才會(huì)接觸一個(gè)東西叫session和cookie技術(shù)
所以你也可以理解為http是基于請(qǐng)求與響應(yīng)的模式, 并且是無(wú)狀態(tài)的應(yīng)用層協(xié)議
任何一個(gè)http請(qǐng)求都只會(huì)分為兩個(gè)部分: 一個(gè)請(qǐng)求報(bào)文另外一個(gè)是響應(yīng)報(bào)文
請(qǐng)求報(bào)文是客戶端按照一定的格式生成一段文本,然后發(fā)給我們的服務(wù)端, 而服務(wù)器接收到了這樣一個(gè)請(qǐng)求報(bào)文就會(huì)解析里面的內(nèi)容,然后做出回饋，也就是響應(yīng)
響應(yīng)報(bào)文也就是服務(wù)器端根據(jù)請(qǐng)求報(bào)文反饋給客戶端的文本信息
http請(qǐng)求(request)也叫請(qǐng)求報(bào)文一個(gè)基本的http請(qǐng)求報(bào)文結(jié)構(gòu)分為如下幾點(diǎn):
抓包了解一下
那么我們?cè)趯W(xué)習(xí)http知識(shí)的時(shí)候 就可以先直接使用Fiddler來(lái)抓取一個(gè)http請(qǐng)求和http響應(yīng)來(lái)先看看到底是什么東西!
這樣也有助于一些新手來(lái)理解http!
我們可以通過(guò)Fiddler抓取網(wǎng)絡(luò)數(shù)據(jù)包的手段，就可以看到一個(gè)基本的http請(qǐng)求結(jié)構(gòu)都包含哪些信息!
例如一個(gè)GET方式的請(qǐng)求(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
例如一個(gè)POST方式的請(qǐng)求(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}怎么樣 是不是看這一大堆腦殼都大了呢 ？ 哈哈哈不要著急，我們慢慢來(lái)學(xué)!
我們先來(lái)看一張請(qǐng)求(Request)圖解
如圖
然后我們來(lái)逐一拆解上圖中的各個(gè)部分!
我們常見的一些請(qǐng)求方式也就是POST/GET,當(dāng)然還有其他的一些請(qǐng)求方式, 如下表:
請(qǐng)求方法 | 描述 |
GET | 請(qǐng)求資源 比如常見的就是輸入一個(gè)URL去請(qǐng)求一個(gè)資源下來(lái), 它也可以帶上一定的參數(shù)一起請(qǐng)求 |
POST | 提交資源 比如說(shuō)我們想把用戶名和密碼 提交到服務(wù)器去,這個(gè)時(shí)候用POST比較好 |
HEAD | 獲取響應(yīng)頭 |
PUT | 替換資源 |
DELETE | 刪除資源 |
OPTIONS | 允許客戶端查看服務(wù)器的性能 |
TRACE | 顯示服務(wù)器收到的請(qǐng)求 常見于測(cè)試和調(diào)試診斷! |
URL中文名為統(tǒng)一資源定位符 英文全稱Uniform Resource Locator ,
我們網(wǎng)絡(luò)中的每一信息資源都有統(tǒng)一的且在網(wǎng)上唯一的地址!
URL具體由4部分組成：協(xié)議、主機(jī)、域名、端口、路徑文件、[附加資源]
URL的一般語(yǔ)法格式為：
protocol :// hostname[:port] / path / [?query-parameters]
1.協(xié)議 (protocol)
協(xié)議有http、ftp、https、等...
2.主機(jī)名 (hostname) + 域名
主機(jī)名+域名 例如: www.xsphp.com
3.端口 (port)
端口是一個(gè)數(shù)字, 端口是可選的 省略時(shí)使用方案是服務(wù)器默認(rèn)配置的端口
例如 80、8080、..
各種傳輸協(xié)議都有默認(rèn)的端口號(hào)，如http協(xié)議的默認(rèn)端口為80
如果URL地址省略端口，則使用默認(rèn)端口號(hào)
注意
有時(shí)候出于安全或其他考慮，可以在服務(wù)器配置上對(duì)端口進(jìn)行重新定義，也就是采用非標(biāo)準(zhǔn)端口號(hào)，那么此時(shí)，URL地址中就不能省略端口號(hào)這一項(xiàng)。
4.路徑文件 (path)
由零或多個(gè)/符號(hào)隔開的字符串，一般用來(lái)表示主機(jī)上的一個(gè)目錄或文件地址
例如: /tpl/index.php
5.查詢參數(shù) 附加資源 (query-parameters)
這一項(xiàng)在URL中也是可選的 用于給動(dòng)態(tài)網(wǎng)頁(yè)如 PHP/JSP/ASP/ASP.NET等后端頁(yè)面 傳遞參數(shù)的一種方式，并且如果是GET請(qǐng)求方法, 那么可有多個(gè)參數(shù), 它們彼此用&符號(hào)隔開，每個(gè)參數(shù)的名和值用=符號(hào)隔開
語(yǔ)法格式: ?參數(shù)=值&參數(shù)2=值 以此類推!
例如: ?id=33&age=25&name=zhangsan
舉個(gè)例子
一個(gè)比較常見的url地址， 如下:
https://www.xxxx.net/xxxx/xxxx/xxxx/100?num=1001.2014.3001.5501請(qǐng)求消息頭也叫消息頭告訴服務(wù)器發(fā)送的是什么數(shù)據(jù)類型，編碼類型、請(qǐng)求的是哪臺(tái)主機(jī)、以及客戶端瀏覽器的一些系統(tǒng)環(huán)境 等等前面已經(jīng)說(shuō)過(guò)了, 并且請(qǐng)求頭是可以由開發(fā)人員根據(jù)需求去進(jìn)行自定義的
這些消息頭中有很多頭部字段名 和 對(duì)應(yīng)的值它的格式為 name:value
我們常見的一些請(qǐng)求頭如下表:
請(qǐng)求頭 | 描述 |
Host | 主機(jī)IP地址或域名 |
User-Agent | 提交一些客戶端相關(guān)信息，例如: 操作系統(tǒng)、瀏覽器等一些版本信息給服務(wù)器, 而這些信息可能會(huì)讓服務(wù)器按照一定的規(guī)則給客戶端返回兼容性比較好的信息! |
Accept | 指定客戶端接收的信息類型， 例如:image/jpg,text/html,application/json 也就是可以讓客戶端告訴服務(wù)器 之后客戶端這一邊想接收到什么樣的數(shù)據(jù)格式 |
Accept-Charset | 告訴服務(wù)器等一會(huì)這邊客戶端需要接收的字符集編碼格式， |
Accept-Encoding | 告訴服務(wù)器， 客戶端這邊可接受的內(nèi)容壓縮編碼，例如gzip 可以在一定程度上節(jié)省流量! |
Accept-Language | 告訴服務(wù)器, 客戶端可接受的語(yǔ)言，例如Accept-Language：zh-cn |
Authorization | 客戶端提供給服務(wù)端進(jìn)行權(quán)限認(rèn)證的信息, 也就是要告訴服務(wù)器端一些認(rèn)證的信息，服務(wù)器才能返回響應(yīng)的數(shù)據(jù)! |
Cookie | 攜帶的COOKIE信息, 普通情況下，當(dāng)一個(gè)用戶登錄成功，就會(huì)在本地保存一份cookie,下次請(qǐng)求就會(huì)直接帶上這個(gè)cookie信息，也就是這個(gè)用戶的相關(guān)信息 |
Referer | 當(dāng)前文檔的URL 也就是紀(jì)錄下從哪個(gè)鏈接地址提交到服務(wù)器的 |
Content-Type | 向服務(wù)器提交內(nèi)容的格式 例如：Content-Type：application/x-www-form-urlencoded 總而言之,就是告訴服務(wù)器,客戶端傳遞的內(nèi)容屬于什么格式 或 其他編碼格式! |
Content-Length | 數(shù)據(jù)長(zhǎng)度, 也就是客戶端向服務(wù)器端提交內(nèi)容的數(shù)據(jù)長(zhǎng)度有多少字節(jié)! |
Cache-Control | 緩存機(jī)制，例如：Cache-Control:no-cache |
pragma | 防止頁(yè)面被緩存，與Cache-Control:no-cache作用一樣 |
.............................................. |
我們可以用Fiddler截取一個(gè)請(qǐng)求頭看看
如圖
空白行 也就是在消息頭結(jié)束的下方，會(huì)存在一個(gè)空白行, 這是必須存在的, 是由HTTP標(biāo)準(zhǔn)規(guī)定的!
請(qǐng)求體它的出現(xiàn)是要根據(jù)請(qǐng)求的方式不同而不同, 也就是如果是POST那么就會(huì)以鍵與值的形式進(jìn)行發(fā)送, 如果是GET請(qǐng)求那么這里就不會(huì)包含請(qǐng)求正文內(nèi)容
http響應(yīng)(response)也叫響應(yīng)報(bào)文
其實(shí)響應(yīng)報(bào)文比請(qǐng)求報(bào)文更加簡(jiǎn)單, 你只要能夠搞懂請(qǐng)求報(bào)文 那么響應(yīng)報(bào)文就很容易搞懂!
http響應(yīng)(response)的一個(gè)基本結(jié)構(gòu)分為如下幾點(diǎn):
我們可以通過(guò)Fiddler抓取網(wǎng)絡(luò)數(shù)據(jù)包的手段，就可以看到一個(gè)基本的http響應(yīng)結(jié)構(gòu)都包含哪些信息!
舉個(gè)例子
如果你還看不明白 那么我們先來(lái)看一張http響應(yīng)(response)圖解 你就會(huì)明白了!
然后我們來(lái)逐一拆解上圖中的各個(gè)部分!
響應(yīng)行也叫狀態(tài)行， 上圖中響應(yīng)行內(nèi)部其實(shí)包含了3個(gè)重要的信息部分:
HTTP協(xié)議的版本、HTTP狀態(tài)碼、HTTP的狀態(tài)描述
1.HTTP協(xié)議的版本現(xiàn)目前都是HTTP/1.1 版本 這個(gè)沒(méi)什么好說(shuō)的!
2.HTTP狀態(tài)碼 可以用來(lái)表示網(wǎng)頁(yè)服務(wù)器端給客戶端返回的HTTP響應(yīng)狀態(tài), 通常都是3位數(shù)字的代碼, 而這些常見的狀態(tài)碼又可以分為幾種提示類型: 如下表
類別狀態(tài)碼 | 描述 |
1xx | 這種類別的狀態(tài)碼 為提示消息類型 通常表示請(qǐng)求被服務(wù)器端成功接收 |
2xx | 這種類別的狀態(tài)碼 為成功消息類型通常表示請(qǐng)求被服務(wù)器端成功處理 |
3xx | 這種類別的狀態(tài)碼 為重定向類型通常表示被服務(wù)器端重新定義了請(qǐng)求方向,需要進(jìn)一步的操作以完成請(qǐng)求 |
4xx | 這種類別的狀態(tài)碼 為客戶端錯(cuò)誤信息通常表示服務(wù)器告訴客戶端的一些錯(cuò)誤消息 |
5xx | 這種類別的狀態(tài)碼 為服務(wù)端錯(cuò)誤信息通常表示告訴客戶端 服務(wù)器這邊出現(xiàn)的一些錯(cuò)誤信息 |
3.HTTP的狀態(tài)描述是緊跟在狀態(tài)碼后面的英文單詞
每一種具體類別狀態(tài)碼+狀態(tài)描述可以參考下表:
1xx: 提示消息類型
消息: | 狀態(tài)描述 | 含義 |
100 | Continue | 服務(wù)器僅接收到部分請(qǐng)求，但是一旦服務(wù)器并沒(méi)有拒絕該請(qǐng)求，客戶端應(yīng)該繼續(xù)發(fā)送其余的請(qǐng)求。 |
101 | Switching Protocols | 服務(wù)器轉(zhuǎn)換協(xié)議：服務(wù)器將遵從客戶的請(qǐng)求轉(zhuǎn)換到另外一種協(xié)議。 |
2xx: 成功消息類型
消息: | 狀態(tài)描述 | 含義 |
200 | OK | 請(qǐng)求成功（其后是對(duì)GET和POST請(qǐng)求的應(yīng)答文檔。） |
201 | Created | 請(qǐng)求被創(chuàng)建完成，同時(shí)新的資源被創(chuàng)建。 |
202 | Accepted | 供處理的請(qǐng)求已被接受，但是處理未完成。 |
203 | Non-authoritative Information | 文檔已經(jīng)正常地返回，但一些應(yīng)答頭可能不正確，因?yàn)槭褂玫氖俏臋n的拷貝。 |
204 | No Content | 沒(méi)有新文檔。瀏覽器應(yīng)該繼續(xù)顯示原來(lái)的文檔。如果用戶定期地刷新頁(yè)面，而Servlet可以確定用戶文檔足夠新，這個(gè)狀態(tài)代碼是很有用的。 |
205 | Reset Content | 沒(méi)有新文檔。但瀏覽器應(yīng)該重置它所顯示的內(nèi)容。用來(lái)強(qiáng)制瀏覽器清除表單輸入內(nèi)容。 |
206 | Partial Content | 客戶發(fā)送了一個(gè)帶有Range頭的GET請(qǐng)求，服務(wù)器完成了它。 |
3xx: 重定向類型
消息: | 狀態(tài)描述 | 含義 |
300 | Multiple Choices | 多重選擇。鏈接列表。用戶可以選擇某鏈接到達(dá)目的地。最多允許五個(gè)地址。 |
301 | Moved Permanently | 所請(qǐng)求的頁(yè)面已經(jīng)轉(zhuǎn)移至新的url, 說(shuō)通俗一點(diǎn)表示請(qǐng)求的資源分配了url，以后就應(yīng)該使用這個(gè)url |
302 | Found | 所請(qǐng)求的頁(yè)面已經(jīng)臨時(shí)轉(zhuǎn)移至新的url, 也就是說(shuō)請(qǐng)求的資源臨時(shí)分配了url，本次請(qǐng)求暫且使用這個(gè)url， 這里302與301的區(qū)別是，302表示臨時(shí)性重定向，重定向的url還有可能還會(huì)改變。 |
303 | See Other | 表示請(qǐng)求的資源路徑發(fā)生改變，請(qǐng)使用GET方法請(qǐng)求url。其實(shí)與302一樣，但是明確指出讓我們使用GET方法請(qǐng)求url |
304 | Not Modified | 未按預(yù)期修改文檔。客戶端有緩沖的文檔并發(fā)出了一個(gè)條件性的請(qǐng)求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務(wù)器告訴客戶，原來(lái)緩沖的文檔還可以繼續(xù)使用。 |
305 | Use Proxy | 客戶請(qǐng)求的文檔應(yīng)該通過(guò)Location頭所指明的代理服務(wù)器提取。 |
306 | Unused | 此代碼被用于前一版本。目前已不再使用，但是代碼依然被保留。 |
307 | Temporary Redirect | 被請(qǐng)求的頁(yè)面已經(jīng)臨時(shí)移至新的url。 |
4xx: 客戶端錯(cuò)誤信息
消息: | 狀態(tài)描述 | 含義 |
400 | Bad Request | 服務(wù)器未能理解請(qǐng)求，通常為表示請(qǐng)求的報(bào)文中存在語(yǔ)法錯(cuò)誤 ，比如: 提交json數(shù)據(jù)的時(shí)候，如果json格式有問(wèn)題，接收端接收json，也會(huì)出現(xiàn)400 bad request |
401 | Unauthorized | 被請(qǐng)求的頁(yè)面需要用戶名和密碼。 |
402 | Payment Required | 此代碼尚無(wú)法使用。 |
403 | Forbidden | 對(duì)被請(qǐng)求頁(yè)面的訪問(wèn)被禁止。 |
404 | Not Found | 服務(wù)器無(wú)法找到被請(qǐng)求的頁(yè)面。 |
405 | Method Not Allowed | 請(qǐng)求中指定的方法不被允許, 請(qǐng)求的方式get、post、delete方法與后臺(tái)規(guī)定的方式不符合 例如: 比如： 后臺(tái)方法規(guī)定的請(qǐng)求方式只接受get，如果用post請(qǐng)求，就會(huì)出現(xiàn) 405 method not allowed的提示 |
406 | Not Acceptable | 服務(wù)器生成的響應(yīng)無(wú)法被客戶端所接受。 |
407 | Proxy Authentication Required | 用戶必須首先使用代理服務(wù)器進(jìn)行驗(yàn)證，這樣請(qǐng)求才會(huì)被處理。 |
408 | Request Timeout | 請(qǐng)求超出了服務(wù)器的等待時(shí)間。 |
409 | Conflict | 由于沖突，請(qǐng)求無(wú)法被完成。 |
410 | Gone | 被請(qǐng)求的頁(yè)面不可用。 |
411 | Length Required | "Content-Length" 未被定義。如果無(wú)此內(nèi)容，服務(wù)器不會(huì)接受請(qǐng)求。 |
412 | Precondition Failed | 請(qǐng)求中的前提條件被服務(wù)器評(píng)估為失敗。 |
413 | Request Entity Too Large | 由于所請(qǐng)求的實(shí)體的太大，服務(wù)器不會(huì)接受請(qǐng)求。 |
414 | Request-url Too Long | 由于url太長(zhǎng)，服務(wù)器不會(huì)接受請(qǐng)求。當(dāng)post請(qǐng)求被轉(zhuǎn)換為帶有很長(zhǎng)的查詢信息的get請(qǐng)求時(shí)，就會(huì)發(fā)生這種情況。 |
415 | Unsupported Media Type | 由于媒介類型不被支持，服務(wù)器不會(huì)接受請(qǐng)求, 例如: 后臺(tái)程序不支持提交的content-type類型，就會(huì)返回415 |
416 | 服務(wù)器不能滿足客戶在請(qǐng)求中指定的Range頭。 | |
417 | Expectation Failed |
5xx: 服務(wù)器錯(cuò)誤信息
消息: | 狀態(tài)描述 | 含義 |
500 | Internal Server Error | 請(qǐng)求未完成。服務(wù)器遇到不可預(yù)知的情況。 |
501 | Not Implemented | 請(qǐng)求未完成。服務(wù)器不支持所請(qǐng)求的功能。 |
502 | Bad Gateway | 請(qǐng)求未完成。服務(wù)器從上游服務(wù)器收到一個(gè)無(wú)效的響應(yīng)。 |
503 | Service Unavailable | 請(qǐng)求未完成。服務(wù)器臨時(shí)過(guò)載或當(dāng)機(jī)。 |
504 | Gateway Timeout | 網(wǎng)關(guān)超時(shí)。 |
505 | HTTP Version Not Supported | 服務(wù)器不支持請(qǐng)求中指明的HTTP協(xié)議版本。 |
響應(yīng)頭也叫消息報(bào)頭 也就是服務(wù)器端要告訴客戶端的一些附加信息, 但是也有可能這些響應(yīng)頭是由后端開發(fā)人員進(jìn)行自定義的!
而且這里的響應(yīng)頭跟請(qǐng)消頭 很類似, 格式也基本一樣, 它的格式為 name:value
具體我這里也列舉了一些常見的響應(yīng)頭 如下表:
響應(yīng)頭 | 含義 |
Server | HTTP服務(wù)器的軟件信息 |
Date | 響應(yīng)報(bào)文的時(shí)間, 要注意返回時(shí)間的時(shí)區(qū) |
Expiros | 服務(wù)器指定的一個(gè)緩存過(guò)期時(shí)間 |
Set-Cookie | 設(shè)置Cookie, 也就是服務(wù)器返回的一段文本給客戶端,讓客戶端保存好,下次請(qǐng)求就把這個(gè)cookie文本帶上! |
Last-Modified | 資源最后修改時(shí)間 ，也就是客戶端有緩沖的文檔并發(fā)出了一個(gè)條件性的請(qǐng)求, 服務(wù)器告訴客戶，原來(lái)緩沖的文檔還可以繼續(xù)使用, 也就是說(shuō)不用在從服務(wù)器中進(jìn)行返回 |
Content-Type | 服務(wù)器返回給客戶端的響應(yīng)類型和編碼字符集 例如：Content-Type:text/html;charset=utf-8 |
Content-Length | 內(nèi)容長(zhǎng)度, 也就是服務(wù)器返回給客戶端返回的內(nèi)容是多少字節(jié) |
Connection | 例如Keep-Alive，表示保持tcp鏈接不會(huì)關(guān)閉，當(dāng)然它不會(huì)永久保持鏈接，我們?cè)诜?wù)器端中是可以設(shè)置的 |
Location | 指明服務(wù)器給客戶端重定向的位置，也就是新的URL地址 如:304的情況 |
...................................... |
還有更多的響應(yīng)頭這里就不一一列舉了!
空白行也就是http規(guī)范制定的必須存在的一個(gè)空行, 空行的目的就是一種格式，也就是要告訴用戶接下來(lái)的內(nèi)容就是正文內(nèi)容了!
響應(yīng)體也就是實(shí)際從服務(wù)器返回給客戶端的正文內(nèi)容,也可能是一些字符串， 也可以是任意的格式:
響應(yīng)體大多數(shù)情況下都是html、json、文本、xml 這些格式!
小結(jié)
對(duì)于http相關(guān)的的知識(shí)點(diǎn) 就說(shuō)這么多了,對(duì)于學(xué)習(xí)fiddler足夠了
接下來(lái)你就可以愉快的學(xué)習(xí)Fiddler了
Fiddler的原理簡(jiǎn)單點(diǎn)說(shuō)就是通過(guò)改寫HTTP代理然后讓網(wǎng)絡(luò)數(shù)據(jù)從Fiddler這邊通過(guò) 這樣子來(lái)監(jiān)控并且截取到網(wǎng)絡(luò)信息數(shù)據(jù)。當(dāng)你打開Fiddler的時(shí)候, 就已經(jīng)設(shè)置好了瀏覽器的代理了。當(dāng)你關(guān)閉的時(shí)候，它會(huì)自動(dòng)的幫你把代理還原
之前也說(shuō)過(guò)了 B/S架構(gòu)就是客戶端和服務(wù)器之間的 請(qǐng)求和響應(yīng), 剛剛我們也知道了Fiddler通過(guò)代理的形式來(lái)進(jìn)行監(jiān)聽，它在請(qǐng)求和響應(yīng)中起到一個(gè)什么樣的角色呢?
這里還要清楚一點(diǎn)的就是 瀏覽器默認(rèn)走的是我們的系統(tǒng)代理
其實(shí)這里的代理監(jiān)聽 就是在 請(qǐng)求和響應(yīng)之間插了一腳, 讓fiddler成為系統(tǒng)代理
在你安裝好Fiddler之后啟動(dòng)，并可以打開菜單欄中的Tools--->options--->Connections
如下圖
看到了吧,這里有一句Act as system proxy on startup意思就是(在啟動(dòng)時(shí)充當(dāng)系統(tǒng)代理),并且默認(rèn)監(jiān)聽端口設(shè)置為了8888
如圖
這里以chrome瀏覽器為例:
只要fiddler一旦啟動(dòng)并開始監(jiān)聽的時(shí)候，就會(huì)默認(rèn)成為系統(tǒng)代理, 所以你的網(wǎng)絡(luò)請(qǐng)求 也就會(huì)被fiddler所抓取到!
如圖
或者如下圖一樣Fiddler就是一個(gè)中間的proxy(代理服務(wù)器)
[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來(lái)直接上傳(img-ItS8dJ6N-1651910920350)(img/fiddler_3-3.png)]
當(dāng)關(guān)閉fiddler的時(shí)候，手動(dòng)設(shè)置代理選項(xiàng)就會(huì)被清空
所以我們才會(huì)說(shuō)Fiddler是介于客戶端和服務(wù)器中間的一個(gè)角色, 監(jiān)控客戶端和服務(wù)器所有通信的過(guò)程!
小結(jié)
Fiddler是以代理WEB服務(wù)器的形式工作的,瀏覽器與服務(wù)器之間通過(guò)建立TCP連接以HTTP協(xié)議進(jìn)行通信，
瀏覽器默認(rèn)通過(guò)自己發(fā)送HTTP請(qǐng)求到服務(wù)器，本地使用代理地址:127.0.0.1, 端口:8888.
而當(dāng)Fiddler開啟會(huì)自動(dòng)設(shè)置系統(tǒng)代理， 退出的時(shí)候它會(huì)自動(dòng)注銷代理，這樣就不會(huì)影響別的程序。
但是如果Fiddler非正常退出，這時(shí)可能會(huì)因?yàn)?/span>Fiddler沒(méi)有自動(dòng)注銷，而會(huì)造成網(wǎng)頁(yè)無(wú)法訪問(wèn)。
解決的辦法是重新啟動(dòng)下Fiddler就可以了, 這也是有很多新手安裝了Fiddler之后導(dǎo)致一些網(wǎng)絡(luò)無(wú)法訪問(wèn)的原因之一!
"點(diǎn)贊" "評(píng)論" "收藏"
大家的支持就是我堅(jiān)持創(chuàng)作下去的動(dòng)力!?
?如果以上內(nèi)容有任何錯(cuò)誤或者不準(zhǔn)確的地方，歡迎在下面 留個(gè)言指出、或者你有更好的想法，歡迎一起交流學(xué)習(xí)?
有的小伙伴或者童鞋們可能會(huì)好奇地問(wèn)：不是講解和分享抓包工具了怎么這里開始講解HTTP和HTTPS協(xié)議了。這是因?yàn)槟銓?duì)HTTP協(xié)議越了解，你就能越掌握Fiddler的使用方法，反過(guò)來(lái)你越使用Fiddler，就越能幫助你了解HTTP協(xié)議。
Fiddler無(wú)論對(duì)開發(fā)人員或者測(cè)試人員來(lái)說(shuō)，都是非常有用的工具。
超文本傳輸協(xié)議HTTP協(xié)議被用于在Web瀏覽器和網(wǎng)站服務(wù)器之間傳遞信息，HTTP協(xié)議以明文方式發(fā)送內(nèi)容，不提供任何方式的數(shù)據(jù)加密，如果攻擊者截取了Web瀏覽器和網(wǎng)站服務(wù)器之間的傳輸報(bào)文，就可以直接讀懂其中的信息，因此，HTTP協(xié)議不適合傳輸一些敏感信息，比如：信用卡號(hào)、密碼等支付信息。
為了解決HTTP協(xié)議的這一缺陷，需要使用另一種協(xié)議：安全套接字層超文本傳輸協(xié)議HTTPS，為了數(shù)據(jù)傳輸?shù)陌踩琀TTPS在HTTP的基礎(chǔ)上加入了SSL協(xié)議，SSL依靠證書來(lái)驗(yàn)證服務(wù)器的身份，并為瀏覽器和服務(wù)器之間的通信加密。
HTTP（HyperText Transfer Protocol：超文本傳輸協(xié)議）是一種用于分布式、協(xié)作式和超媒體信息系統(tǒng)的應(yīng)用層協(xié)議。 簡(jiǎn)單來(lái)說(shuō)就是一種發(fā)布和接收 HTML 頁(yè)面的方法，被用于在 Web 瀏覽器和網(wǎng)站服務(wù)器之間傳遞信息。是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，是一個(gè)客戶端和服務(wù)器端請(qǐng)求和應(yīng)答的標(biāo)準(zhǔn)（TCP），用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳輸協(xié)議，它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。
HTTP 默認(rèn)工作在 TCP 協(xié)議 80 端口，用戶訪問(wèn)網(wǎng)站 http:// 打頭的都是標(biāo)準(zhǔn) HTTP 服務(wù)。
HTTP 協(xié)議以明文方式發(fā)送內(nèi)容，不提供任何方式的數(shù)據(jù)加密，如果攻擊者截取了Web瀏覽器和網(wǎng)站服務(wù)器之間的傳輸報(bào)文，就可以直接讀懂其中的信息，因此，HTTP協(xié)議不適合傳輸一些敏感信息，比如：信用卡號(hào)、密碼等支付信息。
HTTPS（Hypertext Transfer Protocol Secure：超文本傳輸安全協(xié)議）是一種透過(guò)計(jì)算機(jī)網(wǎng)絡(luò)進(jìn)行安全通信的傳輸協(xié)議。HTTPS 經(jīng)由 HTTP 進(jìn)行通信，但利用 SSL/TLS 來(lái)加密數(shù)據(jù)包。HTTPS 開發(fā)的主要目的，是提供對(duì)網(wǎng)站服務(wù)器的身份認(rèn)證，保護(hù)交換數(shù)據(jù)的隱私與完整性。是以安全為目標(biāo)的HTTP通道，簡(jiǎn)單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。
HTTPS協(xié)議的主要作用可以分為兩種：
一種是建立一個(gè)信息安全通道，來(lái)保證數(shù)據(jù)傳輸?shù)陌踩?/span>
另一種就是確認(rèn)網(wǎng)站的真實(shí)性。
http的工作方式為一個(gè)簡(jiǎn)單的客戶端請(qǐng)求與服務(wù)端響應(yīng)的應(yīng)答過(guò)程。它指定了客戶端發(fā)送給服務(wù)器什么樣的消息形式以及得到什么樣的消息響應(yīng)，所有的www文件都必須遵循這個(gè)標(biāo)準(zhǔn)協(xié)議, 目的是提供一種發(fā)布和接收html頁(yè)面的方法。舉個(gè)例子比如說(shuō) 客戶端（瀏覽器）向服務(wù)器提交一個(gè)http請(qǐng)求, 那么服務(wù)器又會(huì)向客戶端這邊返回響應(yīng)信息。而這些響應(yīng)信息包含關(guān)于客戶端請(qǐng)求的狀態(tài)信息以及客戶端所需要的內(nèi)容信息。如下圖所示：
http協(xié)議和web之間的本質(zhì)說(shuō)白了就是就是瀏覽器和服務(wù)器打交道的。客戶端向服務(wù)器端發(fā)送Http請(qǐng)求,然后服務(wù)器端向客戶端返回http響應(yīng)!
http協(xié)議：所謂協(xié)議，就是指雙方遵循的規(guī)范。http協(xié)議，就是瀏覽器和服務(wù)器之間進(jìn)行“溝通”的一種規(guī)范。, 也就是以這個(gè)規(guī)范來(lái)向服務(wù)器發(fā)起請(qǐng)求, 服務(wù)器才會(huì)給客戶端進(jìn)行正確的響應(yīng), 所以http有的時(shí)候也可以理解為是一種 規(guī)范、規(guī)則、標(biāo)準(zhǔn)。http協(xié)議是屬于“應(yīng)用層的協(xié)議”,而且是基于TCP/IP協(xié)議的, 也就是說(shuō)http通信發(fā)生在TCP/IP鏈接之上。
通俗一點(diǎn)說(shuō)http協(xié)議就是基于TCP的一種應(yīng)用層協(xié)議 它不會(huì)關(guān)系數(shù)據(jù)傳輸?shù)募?xì)節(jié)問(wèn)題,也就是說(shuō)你不用去關(guān)心它下層TCP的運(yùn)行邏輯, 它的核心只在于用來(lái)規(guī)定客戶端和服務(wù)端的數(shù)據(jù)傳輸格式。最早http是用來(lái)向客戶端傳輸html文件內(nèi)容,默認(rèn)的端口80
有興趣的朋友可以自行了解一下iso網(wǎng)絡(luò)七層模型。
如果你接觸過(guò)socket網(wǎng)絡(luò)編程，就應(yīng)該明白TCP和UDP這兩種使用廣泛的通信協(xié)議（建立連接、三次握 手等等，當(dāng)然，這不是本文討論的重點(diǎn)）。
既然TCP/UDP是廣泛使用的網(wǎng)絡(luò)通信協(xié)議，那為啥有多出個(gè)http協(xié)議來(lái)呢？
筆者曾自己動(dòng)手寫過(guò)一個(gè)簡(jiǎn)單的web服務(wù)器處理軟件，根據(jù)我的推斷（不一定準(zhǔn)確）。UDP協(xié)議具有不可靠性和不安全性，顯然這很難滿足web應(yīng)用的需要。
而TCP協(xié)議是基于連接和三次握手的，雖然具有可靠性，但人具有一定的缺陷。但試想一下，普通的C/S架構(gòu)軟件，頂多上千個(gè)Client同時(shí)連接，而B/S架構(gòu)的網(wǎng)站，十萬(wàn)人同時(shí)在線也是很平常的事兒。如果十萬(wàn)個(gè)客戶端和服務(wù)器一直保持連接狀態(tài)，那服務(wù)器如何滿足承載呢？
這就衍生出了http協(xié)議。基于TCP的可靠性連接。通俗點(diǎn)說(shuō)，就是在請(qǐng)求之后，服務(wù)器端立即關(guān)閉連接、釋放資源。這樣既保證了資源可用，也吸取了TCP的可靠性的優(yōu)點(diǎn)。
正因?yàn)檫@點(diǎn)，所以大家通常說(shuō)http協(xié)議是“無(wú)狀態(tài)”的，也就是“服務(wù)器不知道你客戶端干了啥”，其實(shí)很大程度上是基于性能考慮的。以至于后來(lái)有了session之類的玩意。
通俗點(diǎn)說(shuō)http，就是在請(qǐng)求和響應(yīng)之后，服務(wù)器端立即關(guān)閉連接，并釋放資源，這樣既保證了資源可顯示與可用性，也吸取了TCP協(xié)議的可靠性優(yōu)點(diǎn),但是缺點(diǎn)就無(wú)法跟蹤用戶的操作了,所以我們?cè)诤蠖碎_發(fā)的學(xué)習(xí)中才會(huì)接觸一個(gè)東西叫session和cookie技術(shù)
所以你也可以理解為http是基于請(qǐng)求與響應(yīng)的模式, 并且是無(wú)狀態(tài)的應(yīng)用層協(xié)議。
HTTP 消息是服務(wù)器和客戶端之間交換數(shù)據(jù)的方式。有兩種類型的消息︰ 請(qǐng)求（requests）-- 由客戶端發(fā)送用來(lái)觸發(fā)一個(gè)服務(wù)器上的動(dòng)作；響應(yīng)（responses）-- 來(lái)自服務(wù)器的應(yīng)答。
任何一個(gè)http請(qǐng)求都只會(huì)分為兩個(gè)部分: 一個(gè)請(qǐng)求報(bào)文另外一個(gè)是響應(yīng)報(bào)文。
請(qǐng)求報(bào)文是客戶端按照一定的格式生成一段文本,然后發(fā)給我們的服務(wù)端, 而服務(wù)器接收到了這樣一個(gè)請(qǐng)求報(bào)文就會(huì)解析里面的內(nèi)容進(jìn)行處理,然后做出反饋，也就是響應(yīng)。
響應(yīng)報(bào)文也就是服務(wù)器端根據(jù)請(qǐng)求報(bào)文反饋給客戶端的文本信息。
http請(qǐng)求(request)也叫請(qǐng)求報(bào)文，一個(gè)基本的HTTP請(qǐng)求報(bào)文由請(qǐng)求行（request line）、請(qǐng)求頭部（request header）、空行和請(qǐng)求數(shù)據(jù)4個(gè)部分構(gòu)成。
1.請(qǐng)求行（request line）:就是請(qǐng)求方式和協(xié)議,也就是說(shuō)用于描述客戶端的請(qǐng)求方式,例如post/get方式, 以及請(qǐng)求的資源名稱和HTTP協(xié)議的版本號(hào)!
2.若干個(gè)請(qǐng)求頭（request header）: 這些也叫消息頭告訴服務(wù)器發(fā)送的是什么數(shù)據(jù)類型，編碼類型、請(qǐng)求的是哪臺(tái)主機(jī)、以及客戶端瀏覽器的一些系統(tǒng)環(huán)境 等等， 這些消息頭中有很多頭部字段名 和 對(duì)應(yīng)的值它的格式為 name:value
3.空白行
4.請(qǐng)求正文內(nèi)容說(shuō)了這么多是不是有點(diǎn)懵有點(diǎn)暈，那就使用抓包工具抓取實(shí)際例子，我們具體看一下：
那么我們?cè)趯W(xué)習(xí)http知識(shí)的時(shí)候 就可以先直接使用Fiddler來(lái)抓取一個(gè)http請(qǐng)求和http響應(yīng)來(lái)先看看到底是什么東西!這樣也有助于我們來(lái)更好地理解http。我們可以通過(guò)Fiddler抓取網(wǎng)絡(luò)數(shù)據(jù)包的手段，就可以看到一個(gè)基本的http請(qǐng)求結(jié)構(gòu)都包含哪些信息!例如一個(gè)GET方式的請(qǐng)求(Request)信息，如下圖所示：
http響應(yīng)(response)也叫響應(yīng)報(bào)文，一個(gè)基本的HTTP響應(yīng)報(bào)文由響應(yīng)行、響應(yīng)頭、空行和響應(yīng)體4個(gè)部分構(gòu)成。
1.響應(yīng)行：響應(yīng)行一般由協(xié)議版本、狀態(tài)碼及其描述組成 比如 HTTP/1.1 200 OK
2.響應(yīng)頭：響應(yīng)頭用于描述服務(wù)器的基本信息，以及數(shù)據(jù)的描述，服務(wù)器通過(guò)這些數(shù)據(jù)的描述信息，可以通知客戶端如何處理等一會(huì)兒它回送的數(shù)據(jù)。
3.空白行：
4.響應(yīng)體：響應(yīng)體就是響應(yīng)的消息體，如果是純數(shù)據(jù)就是返回純數(shù)據(jù)，如果請(qǐng)求的是HTML頁(yè)面，那么返回的就是HTML代碼，如果是JS就是JS代碼，如此之類。其實(shí)響應(yīng)報(bào)文比請(qǐng)求報(bào)文更加簡(jiǎn)單, 你只要能夠搞懂請(qǐng)求報(bào)文 那么響應(yīng)報(bào)文就很容易搞懂，同樣的道理，我們可以通過(guò)Fiddler抓取網(wǎng)絡(luò)數(shù)據(jù)包的手段，就可以看到一個(gè)基本的http響應(yīng)結(jié)構(gòu)都包含哪些信息。
例如一個(gè)POST方式的請(qǐng)求(Request)信息 如下:例如一個(gè)POST方式的請(qǐng)求(Request)信息，如下圖所示：
怎么樣是不是看這一大堆腦殼都大了一直穩(wěn)穩(wěn)地響個(gè)不停呢 ？感覺無(wú)從下手，更不用說(shuō)學(xué)習(xí)里， 哈哈哈不要著急，跟著慢慢來(lái)學(xué)!
我們先來(lái)看一張請(qǐng)求(Request)圖解，如下圖所示：
然后再來(lái)逐一解剖上圖中的各個(gè)部分，解剖結(jié)果如下：
我們常見的一些請(qǐng)求方式也就是POST/GET,當(dāng)然還有其他的一些請(qǐng)求方式, 如下表所示：
請(qǐng)求方法 | 描述 |
GET | 請(qǐng)求資源 比如常見的就是輸入一個(gè)URL去請(qǐng)求一個(gè)資源下來(lái), 它也可以帶上一定的參數(shù)一起請(qǐng)求 |
POST | 提交資源 比如說(shuō)我們想把用戶名和密碼 提交到服務(wù)器去,這個(gè)時(shí)候用POST比較好 |
HEAD | 獲取響應(yīng)頭，檢查一個(gè)對(duì)象是否存在 |
PUT | 替換資源，向服務(wù)器發(fā)送數(shù)據(jù)，并存儲(chǔ)服務(wù)器內(nèi)部 |
DELETE | 刪除資源 |
OPTIONS | 允許客戶端查看服務(wù)器的性能 |
TRACE | 顯示服務(wù)器收到的請(qǐng)求 常見于測(cè)試和調(diào)試診斷! |
CONNECT | 對(duì)通道提供支持 |
URL中文名為統(tǒng)一資源定位符 英文全稱Uniform Resource Locator ,可以使用一個(gè)URL地址來(lái)描述一個(gè)網(wǎng)絡(luò)上的資源，而HTTP的GET、POST、PUT、DELETE對(duì)應(yīng)著對(duì)這個(gè)資源的查、改、增、刪四個(gè)操作。我們網(wǎng)絡(luò)中的每一信息資源都有統(tǒng)一的且在網(wǎng)上唯一的地址!
URL具體由4部分組成：協(xié)議、主機(jī)、域名、端口、路徑文件、[附加資源]
URL的一般語(yǔ)法格式為：
protocol :// hostname[:port] / path / [?query-parameters][#anchor]1.協(xié)議 (protocol)：指底層使用的協(xié)議類型，如：http、ftp、https、等...
2.主機(jī)名 (hostname) + 域名：HTTP服務(wù)器的IP或者域名。主機(jī)名+域名 例如: www.xsphp.com
3.端口 (port)：HTTP服務(wù)器端口，端口是一個(gè)數(shù)字, 端口是可選的 省略時(shí)使用方案是服務(wù)器默認(rèn)配置的端口。例如 80、8080、..各種傳輸協(xié)議都有默認(rèn)的端口號(hào)，如http協(xié)議的默認(rèn)端口為80，如果URL地址省略端口，則使用默認(rèn)端口號(hào)。
注意：有時(shí)候出于安全或其他考慮，可以在服務(wù)器配置上對(duì)端口進(jìn)行重新定義，也就是采用非標(biāo)準(zhǔn)端口號(hào)，那么此時(shí)，URL地址中就不能省略端口號(hào)這一項(xiàng)。
4.路徑文件 (path)：訪問(wèn)資源的路徑。由零或多個(gè)/符號(hào)隔開的字符串，一般用來(lái)表示主機(jī)上的一個(gè)目錄或文件地址。例如: /tpl/index.php
5.查詢參數(shù) 附加資源 (query-parameters)：發(fā)送給HTTP服務(wù)器的數(shù)據(jù)。
這一項(xiàng)在URL中也是可選的 用于給動(dòng)態(tài)網(wǎng)頁(yè)如 PHP/JSP/ASP/ASP.NET等后端頁(yè)面 傳遞參數(shù)的一種方式，并且如果是GET請(qǐng)求方法, 那么可有多個(gè)參數(shù), 它們彼此用&符號(hào)隔開，每個(gè)參數(shù)的名和值用=符號(hào)隔開
語(yǔ)法格式: ?參數(shù)=值&參數(shù)2=值 以此類推。例如: ?id=33&age=25&name=zhangsan。舉個(gè)例子：一個(gè)比較常見的url地址， 如：https://www.xxxx.net/xxxx/xxxx/xxxx/100?num=1001.2014.3001.5501
6.anchor：錨點(diǎn)
1.請(qǐng)求消息頭也叫消息頭告訴服務(wù)器發(fā)送的是什么數(shù)據(jù)類型，編碼類型、請(qǐng)求的是哪臺(tái)主機(jī)、以及客戶端瀏覽器的一些系統(tǒng)環(huán)境 等等前面已經(jīng)說(shuō)過(guò)了, 并且請(qǐng)求頭是可以由開發(fā)人員根據(jù)需求去進(jìn)行自定義的。
這些消息頭中有很多頭部字段名 和 對(duì)應(yīng)的值它的格式為 name:value。我們常見的一些請(qǐng)求頭如下表所示：
請(qǐng)求頭 | 描述 | |
Host | 主機(jī)IP地址或域名 | |
User-Agent | 提交一些客戶端相關(guān)信息，例如: 操作系統(tǒng)、瀏覽器等一些版本信息給服務(wù)器, 而這些信息可能會(huì)讓服務(wù)器按照一定的規(guī)則給客戶端返回兼容性比較好的信息! | |
Accept | 指定客戶端接收的信息類型，<br />例如:image/jpg,text/html,application/json<br />也就是可以讓客戶端告訴服務(wù)器 之后客戶端這一邊想接收到什么樣的數(shù)據(jù)格式 | |
Accept-Charset | 告訴服務(wù)器等一會(huì)這邊客戶端需要接收的字符集編碼格式， | <br />例如:gb2312、iso-8859-1、utf-8 |
Accept-Encoding | 告訴服務(wù)器， 客戶端這邊可接受的內(nèi)容壓縮編碼，例如gzip 可以在一定程度上節(jié)省流量! | |
Accept-Language | 告訴服務(wù)器, 客戶端可接受的語(yǔ)言，例如Accept-Language：zh-cn | |
Authorization | 客戶端提供給服務(wù)端進(jìn)行權(quán)限認(rèn)證的信息, 也就是要告訴服務(wù)器端一些認(rèn)證的信息，服務(wù)器才能返回響應(yīng)的數(shù)據(jù)! | |
Cookie | 攜帶的COOKIE信息, 普通情況下，當(dāng)一個(gè)用戶登錄成功，就會(huì)在本地保存一份cookie,下次請(qǐng)求就會(huì)直接帶上這個(gè)cookie信息，也就是這個(gè)用戶的相關(guān)信息 | |
Referer | 當(dāng)前文檔的URL 也就是紀(jì)錄下從哪個(gè)鏈接地址提交到服務(wù)器的 | |
Content-Type | 向服務(wù)器提交內(nèi)容的格式<br />例如：Content-Type：application/x-www-form-urlencoded<br />總而言之,就是告訴服務(wù)器,客戶端傳遞的內(nèi)容屬于什么格式 或 其他編碼格式! | |
Content-Length | 數(shù)據(jù)長(zhǎng)度, 也就是客戶端向服務(wù)器端提交內(nèi)容的數(shù)據(jù)長(zhǎng)度有多少字節(jié)! | |
Cache-Control | 緩存機(jī)制，例如：Cache-Control:no-cache | |
pragma | 防止頁(yè)面被緩存，與Cache-Control:no-cache作用一樣 | |
.............................................. |
2.我們可以用Fiddler截取一個(gè)請(qǐng)求頭看看，如下圖所示：
空白行：也就是在消息頭結(jié)束的下方，會(huì)存在一個(gè)空白行, 這是必須存在的, 是由HTTP標(biāo)準(zhǔn)規(guī)定的!
請(qǐng)求體它的出現(xiàn)是要根據(jù)請(qǐng)求的方式不同而不同, 也就是如果是POST那么就會(huì)以鍵與值的形式進(jìn)行發(fā)送, 如果是GET請(qǐng)求那么這里就不會(huì)包含請(qǐng)求正文內(nèi)容。
從7.3 抓包可以看出這里是一個(gè)json數(shù)據(jù)：
{"email":"xxxxxxx@qq.com","password":"xxxxxxx","remember":"0","code":"","mobile":"","type":"login","reqtimestamp":1647506402551}同樣我們先來(lái)看一張http響應(yīng)(response)圖解，如下圖所示：
然后再來(lái)逐一解剖上圖中的各個(gè)部分，解剖結(jié)果如下：
響應(yīng)行也叫狀態(tài)行， 上圖中響應(yīng)行內(nèi)部其實(shí)包含了3個(gè)重要的信息部分:
HTTP協(xié)議的版本、HTTP狀態(tài)碼、HTTP的狀態(tài)描述
1.HTTP協(xié)議的版本現(xiàn)目前都是HTTP/1.1 版本 這個(gè)沒(méi)什么好說(shuō)的!
2.HTTP狀態(tài)碼 可以用來(lái)表示網(wǎng)頁(yè)服務(wù)器端給客戶端返回的HTTP響應(yīng)狀態(tài), 通常都是3位數(shù)字的代碼, 而這些常見的狀態(tài)碼又可以分為幾種提示類型: 如下表所示：
類別狀態(tài)碼 | 描述 |
1xx | 這種類別的狀態(tài)碼 為提示消息類型 通常表示請(qǐng)求被服務(wù)器端成功接收 |
2xx | 這種類別的狀態(tài)碼 為成功消息類型通常表示請(qǐng)求被服務(wù)器端成功處理 |
3xx | 這種類別的狀態(tài)碼 為重定向類型通常表示被服務(wù)器端重新定義了請(qǐng)求方向,需要進(jìn)一步的操作以完成請(qǐng)求 |
4xx | 這種類別的狀態(tài)碼 為客戶端錯(cuò)誤信息通常表示服務(wù)器告訴客戶端的一些錯(cuò)誤消息 |
5xx | 這種類別的狀態(tài)碼 為服務(wù)端錯(cuò)誤信息通常表示告訴客戶端 服務(wù)器這邊出現(xiàn)的一些錯(cuò)誤信息 |
3.HTTP的狀態(tài)描述是緊跟在狀態(tài)碼后面的英文單詞
每一種具體類別狀態(tài)碼+狀態(tài)描述可以參考下表:
1xx: 提示消息類型
消息: | 狀態(tài)描述 | 含義 |
100 | Continue | 服務(wù)器僅接收到部分請(qǐng)求，但是一旦服務(wù)器并沒(méi)有拒絕該請(qǐng)求，客戶端應(yīng)該繼續(xù)發(fā)送其余的請(qǐng)求。 |
101 | Switching Protocols | 服務(wù)器轉(zhuǎn)換協(xié)議：服務(wù)器將遵從客戶的請(qǐng)求轉(zhuǎn)換到另外一種協(xié)議。 |
2xx: 成功消息類型
消息: | 狀態(tài)描述 | 含義 |
200 | OK | 請(qǐng)求成功（其后是對(duì)GET和POST請(qǐng)求的應(yīng)答文檔。） |
201 | Created | 請(qǐng)求被創(chuàng)建完成，同時(shí)新的資源被創(chuàng)建。 |
202 | Accepted | 供處理的請(qǐng)求已被接受，但是處理未完成。 |
203 | Non-authoritative Information | 文檔已經(jīng)正常地返回，但一些應(yīng)答頭可能不正確，因?yàn)槭褂玫氖俏臋n的拷貝。 |
204 | No Content | 沒(méi)有新文檔。瀏覽器應(yīng)該繼續(xù)顯示原來(lái)的文檔。如果用戶定期地刷新頁(yè)面，而Servlet可以確定用戶文檔足夠新，這個(gè)狀態(tài)代碼是很有用的。 |
205 | Reset Content | 沒(méi)有新文檔。但瀏覽器應(yīng)該重置它所顯示的內(nèi)容。用來(lái)強(qiáng)制瀏覽器清除表單輸入內(nèi)容。 |
206 | Partial Content | 客戶發(fā)送了一個(gè)帶有Range頭的GET請(qǐng)求，服務(wù)器完成了它。 |
3xx: 重定向類型
消息: | 狀態(tài)描述 | 含義 |
300 | Multiple Choices | 多重選擇。鏈接列表。用戶可以選擇某鏈接到達(dá)目的地。最多允許五個(gè)地址。 |
301 | Moved Permanently | 所請(qǐng)求的頁(yè)面已經(jīng)轉(zhuǎn)移至新的url, 說(shuō)通俗一點(diǎn)表示請(qǐng)求的資源分配了url，以后就應(yīng)該使用這個(gè)url |
302 | Found | 所請(qǐng)求的頁(yè)面已經(jīng)臨時(shí)轉(zhuǎn)移至新的url, 也就是說(shuō)請(qǐng)求的資源臨時(shí)分配了url，本次請(qǐng)求暫且使用這個(gè)url， 這里302與301的區(qū)別是，302表示臨時(shí)性重定向，重定向的url還有可能還會(huì)改變。 |
303 | See Other | 表示請(qǐng)求的資源路徑發(fā)生改變，請(qǐng)使用GET方法請(qǐng)求url。其實(shí)與302一樣，但是明確指出讓我們使用GET方法請(qǐng)求url |
304 | Not Modified | 未按預(yù)期修改文檔。客戶端有緩沖的文檔并發(fā)出了一個(gè)條件性的請(qǐng)求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務(wù)器告訴客戶，原來(lái)緩沖的文檔還可以繼續(xù)使用。 |
305 | Use Proxy | 客戶請(qǐng)求的文檔應(yīng)該通過(guò)Location頭所指明的代理服務(wù)器提取。 |
306 | Unused | 此代碼被用于前一版本。目前已不再使用，但是代碼依然被保留。 |
307 | Temporary Redirect | 被請(qǐng)求的頁(yè)面已經(jīng)臨時(shí)移至新的url。 |
4xx: 客戶端錯(cuò)誤信息
消息: | 狀態(tài)描述 | 含義 |
400 | Bad Request | 服務(wù)器未能理解請(qǐng)求，通常為表示請(qǐng)求的報(bào)文中存在語(yǔ)法錯(cuò)誤 ，比如: 提交json數(shù)據(jù)的時(shí)候，如果json格式有問(wèn)題，接收端接收json，也會(huì)出現(xiàn)400 bad request |
401 | Unauthorized | 被請(qǐng)求的頁(yè)面需要用戶名和密碼。 |
402 | Payment Required | 此代碼尚無(wú)法使用。 |
403 | Forbidden | 對(duì)被請(qǐng)求頁(yè)面的訪問(wèn)被禁止。 |
404 | Not Found | 服務(wù)器無(wú)法找到被請(qǐng)求的頁(yè)面。 |
405 | Method Not Allowed | 請(qǐng)求中指定的方法不被允許, 請(qǐng)求的方式get、post、delete方法與后臺(tái)規(guī)定的方式不符合 例如: 比如： 后臺(tái)方法規(guī)定的請(qǐng)求方式只接受get，如果用post請(qǐng)求，就會(huì)出現(xiàn) 405 method not allowed的提示 |
406 | Not Acceptable | 服務(wù)器生成的響應(yīng)無(wú)法被客戶端所接受。 |
407 | Proxy Authentication Required | 用戶必須首先使用代理服務(wù)器進(jìn)行驗(yàn)證，這樣請(qǐng)求才會(huì)被處理。 |
408 | Request Timeout | 請(qǐng)求超出了服務(wù)器的等待時(shí)間。 |
409 | Conflict | 由于沖突，請(qǐng)求無(wú)法被完成。 |
410 | Gone | 被請(qǐng)求的頁(yè)面不可用。 |
411 | Length Required | "Content-Length" 未被定義。如果無(wú)此內(nèi)容，服務(wù)器不會(huì)接受請(qǐng)求。 |
412 | Precondition Failed | 請(qǐng)求中的前提條件被服務(wù)器評(píng)估為失敗。 |
413 | Request Entity Too Large | 由于所請(qǐng)求的實(shí)體的太大，服務(wù)器不會(huì)接受請(qǐng)求。 |
414 | Request-url Too Long | 由于url太長(zhǎng)，服務(wù)器不會(huì)接受請(qǐng)求。當(dāng)post請(qǐng)求被轉(zhuǎn)換為帶有很長(zhǎng)的查詢信息的get請(qǐng)求時(shí)，就會(huì)發(fā)生這種情況。 |
415 | Unsupported Media Type | 由于媒介類型不被支持，服務(wù)器不會(huì)接受請(qǐng)求, 例如: 后臺(tái)程序不支持提交的content-type類型，就會(huì)返回415 |
416 | 服務(wù)器不能滿足客戶在請(qǐng)求中指定的Range頭。 | |
417 | Expectation Failed |
5xx: 服務(wù)器錯(cuò)誤信息
消息: | 狀態(tài)描述 | 含義 |
500 | Internal Server Error | 請(qǐng)求未完成。服務(wù)器遇到不可預(yù)知的情況。 |
501 | Not Implemented | 請(qǐng)求未完成。服務(wù)器不支持所請(qǐng)求的功能。 |
502 | Bad Gateway | 請(qǐng)求未完成。服務(wù)器從上游服務(wù)器收到一個(gè)無(wú)效的響應(yīng)。 |
503 | Service Unavailable | 請(qǐng)求未完成。服務(wù)器臨時(shí)過(guò)載或當(dāng)機(jī)。 |
504 | Gateway Timeout | 網(wǎng)關(guān)超時(shí)。 |
505 | HTTP Version Not Supported | 服務(wù)器不支持請(qǐng)求中指明的HTTP協(xié)議版本。 |
1.響應(yīng)頭也叫消息報(bào)頭 也就是服務(wù)器端要告訴客戶端的一些附加信息, 但是也有可能這些響應(yīng)頭是由后端開發(fā)人員進(jìn)行自定義的!
而且這里的響應(yīng)頭跟請(qǐng)消頭 很類似, 格式也基本一樣, 它的格式為 name:value。具體這里也列舉了一些常見的響應(yīng)頭 如下表所示：
響應(yīng)頭 | 含義 |
Server | HTTP服務(wù)器的軟件信息 |
Date | 響應(yīng)報(bào)文的時(shí)間, 要注意返回時(shí)間的時(shí)區(qū) |
Expiros | 服務(wù)器指定的一個(gè)緩存過(guò)期時(shí)間 |
Set-Cookie | 設(shè)置Cookie, 也就是服務(wù)器返回的一段文本給客戶端,讓客戶端保存好,下次請(qǐng)求就把這個(gè)cookie文本帶上! |
Last-Modified | 資源最后修改時(shí)間 ，也就是客戶端有緩沖的文檔并發(fā)出了一個(gè)條件性的請(qǐng)求, 服務(wù)器告訴客戶，原來(lái)緩沖的文檔還可以繼續(xù)使用, 也就是說(shuō)不用在從服務(wù)器中進(jìn)行返回 |
Content-Type | 服務(wù)器返回給客戶端的響應(yīng)類型和編碼字符集<br />例如：Content-Type:text/html;charset=utf-8 |
Content-Length | 內(nèi)容長(zhǎng)度, 也就是服務(wù)器返回給客戶端返回的內(nèi)容是多少字節(jié) |
Connection | 例如Keep-Alive，表示保持tcp鏈接不會(huì)關(guān)閉，當(dāng)然它不會(huì)永久保持鏈接，我們?cè)诜?wù)器端中是可以設(shè)置的 |
Location | 指明服務(wù)器給客戶端重定向的位置，也就是新的URL地址 如:304的情況 |
...................................... |
這里只例舉一下常見和常用的，其實(shí)還有更多的響應(yīng)頭這里就不一一列舉了!有興趣的自己可以百度一下！
2.我們可以用Fiddler截取一個(gè)響應(yīng)頭看看，如下圖所示：
空白行也就是http規(guī)范制定的必須存在的一個(gè)空行, 空行的目的就是一種格式，也就是要告訴用戶接下來(lái)的內(nèi)容就是正文內(nèi)容了!
響應(yīng)體也就是實(shí)際從服務(wù)器返回給客戶端的正文內(nèi)容,也可能是一些字符串， 也可以是任意的格式:
響應(yīng)體大多數(shù)情況下都是html、json、文本、xml 這些格式!
從8.2 抓包可以看出這里是一個(gè)json數(shù)據(jù)：
{"status":1,"code":10000,"message":"\u8bbf\u95ee\u6210\u529f","data":{"url":"","token":" xxxxxxxx","isenterprise":0,"uid":" xxxxxxxxx"}}1.HTTP 請(qǐng)求和響應(yīng)具有相似的結(jié)構(gòu)，由以下部分組成︰
（1）一行起始行用于描述要執(zhí)行的請(qǐng)求，或者是對(duì)應(yīng)的狀態(tài)，成功或失敗。這個(gè)起始行總是單行的。
（2）一個(gè)可選的 HTTP 頭集合指明請(qǐng)求或描述消息正文。
（3）一個(gè)空行指示所有關(guān)于請(qǐng)求的元數(shù)據(jù)已經(jīng)發(fā)送完畢。
（4）一個(gè)可選的包含請(qǐng)求相關(guān)數(shù)據(jù)的正文 (比如 HTML 表單內(nèi)容), 或者響應(yīng)相關(guān)的文檔。 正文的大小有起始行的 HTTP 頭來(lái)指定。
起始行和 HTTP 消息中的 HTTP 頭統(tǒng)稱為請(qǐng)求頭，而其有效負(fù)載被稱為消息正文。
好了，對(duì)于Http和Https相關(guān)的的知識(shí)點(diǎn)就說(shuō)這么多了,對(duì)于學(xué)習(xí)fiddler足夠了！
接下來(lái)你就可以愉快的學(xué)習(xí)Fiddler了
明：本公眾號(hào)大部分文章來(lái)自作者日常學(xué)習(xí)筆記，部分文章經(jīng)作者授權(quán)及其他公眾號(hào)白名單轉(zhuǎn)載。 未經(jīng)授權(quán)嚴(yán)禁轉(zhuǎn)載。 如需轉(zhuǎn)載，請(qǐng)聯(lián)系開百。
請(qǐng)不要利用文章中的相關(guān)技術(shù)從事非法測(cè)試。 由此產(chǎn)生的任何不良后果與文章作者及本公眾號(hào)無(wú)關(guān)。
目前大圖推送僅針對(duì)常讀、加星的公眾號(hào)顯示。 建議大家“把瀟湘新安定為明星”，不然可能看不到！
本文已經(jīng)作者@蘇雅圖師師許可轉(zhuǎn)發(fā)至公眾號(hào)。 如果喜歡的話可以閱讀他的原創(chuàng)文章以及其他文章。
文章來(lái)源：博客園（蘇雅圖）原文地址：https://www.cnblogs.com/arrdres/p/17335376.html
0x01 開門見山
首先我們來(lái)回顧一下“微信綁定手機(jī)號(hào)數(shù)據(jù)庫(kù)被下庫(kù)”的事件。 我也第一時(shí)間得知了這個(gè)消息，然后跟蹤了整個(gè)事件的經(jīng)過(guò)。 以下是該事件的相關(guān)截圖以及近期泄露的10000個(gè)數(shù)據(jù)樣本：
我個(gè)人認(rèn)為這件事沒(méi)什么。 最好關(guān)注一下此前的45億快遞數(shù)據(jù)查詢通道近日疑似復(fù)活的消息。
消息就是這樣傳開的。 真實(shí)性尚未確定，因?yàn)樽髡卟粫?huì)冒風(fēng)險(xiǎn)，查詢個(gè)人信息就意味著賬號(hào)和個(gè)人信息必然會(huì)測(cè)試是否真實(shí)，但我們可以知道的是，之前的查詢渠道名為“星鏈”，現(xiàn)在稱為星盾。
我為什么要提到這兩件事呢？ 因?yàn)槲乙獙懙奈⑿判〕绦蜃グ坛毯偷谝粋€(gè)事件有關(guān)。 也可以說(shuō)是受到“坐一旁”的啟發(fā)。 事件發(fā)生后，“如何獲取某個(gè)微信賬號(hào)的wxid”的問(wèn)題迅速在某個(gè)圈子里火爆，也有人很快給出了思路。 方法也很簡(jiǎn)單。 我在這里簡(jiǎn)單地重現(xiàn)一下：
特別說(shuō)明：此思路僅適用于iOS系統(tǒng)（蘋果系統(tǒng)）
1. 從 Apple App Store 安裝“Stream”軟件：
2. 配置代理并安裝證書。 內(nèi)置教程，此處省略。
3. 開始抓包。 （為了方便我在iPad上測(cè)試）
4.在群里找到目標(biāo)，點(diǎn)頭頭像，右上角進(jìn)行投訴。
選擇任何投訴原因。 注意，這并不是真正的投訴，只是獲取加載的數(shù)據(jù)包。 最后一步不需要提交。 返回工具頁(yè)面，點(diǎn)擊上傳流量即可查看數(shù)據(jù)包。
選擇“按域名”查看數(shù)據(jù)。 一般情況下，上報(bào)功能會(huì)請(qǐng)求weixin110子域名。
選擇紅框中的POST請(qǐng)求，exposeh5cgi是標(biāo)識(shí)符。
選擇請(qǐng)求模塊以查看請(qǐng)求的數(shù)據(jù)包。
然后向下滾動(dòng)并單擊以查看請(qǐng)求正文。
箭頭處的realChatUser是“投訴用戶”的wxid。 獲得wxid意味著即使不知道對(duì)方的微信名也能找到用戶的手機(jī)號(hào)碼。
這就是我今天要分享的抓包思路。 同理，微信小程序也是可以的。 我應(yīng)該不是第一個(gè)知道的，但是實(shí)戰(zhàn)中有一些細(xì)節(jié)需要注意。 我會(huì)在文章最后講到。 因?yàn)榭赡苡腥艘瘩g我，微信小程序抓包不是有很多思路嗎？ 確實(shí)，你是對(duì)的。 毫不夸張地說(shuō)，你所知道的想法我都明白，但問(wèn)題是很多想法很容易失敗。 這里我列出一些基本的想法。
第一種：使用Burpsuite配合模擬器進(jìn)行抓包
眾所周知，Burpsuite是滲透測(cè)試必備的抓包工具。 從微信小程序中抓包也應(yīng)該很方便。 您可以通過(guò)在模擬器中配置證書來(lái)抓包。
起初這個(gè)想法大家都知道，但后來(lái)微信改變了規(guī)則，這個(gè)方法就失效了。 前幾個(gè)月有消息稱微信似乎禁止登錄模擬器，檢測(cè)到會(huì)警告賬號(hào)被封禁。 該消息是否屬實(shí)尚未得到證實(shí)。 當(dāng)然，更專業(yè)的同學(xué)可以安裝“Xpose框架”之類的東西，讓模擬器更加強(qiáng)大，或者說(shuō)可以繞過(guò)微信檢測(cè)機(jī)制嗎？
第二種：使用Fiddler在微信PC端抓包
Fiddler 也是一個(gè)功能強(qiáng)大的數(shù)據(jù)包捕獲工具，或數(shù)據(jù)包分析工具，可以調(diào)試計(jì)算機(jī)上的 HTTP 流量。
有些事情Burpsuite做不到，它可以，而且我個(gè)人用得比較少。 Fiddler既適用于微信PC端，也適用于模擬器，但這個(gè)想法似乎從去年11月左右就已經(jīng)過(guò)期了，具體細(xì)節(jié)尚未確認(rèn)。
第三種方法：微信PC端使用Charles抓包
根據(jù)官網(wǎng)介紹，Charles是一個(gè)HTTP代理和HTTP監(jiān)控工具，主要適用于網(wǎng)頁(yè)瀏覽器。
查爾斯俗稱“花瓶”。 應(yīng)該說(shuō)，它是安全圈中的“后來(lái)者”抓包工具。 我平時(shí)經(jīng)常使用它，因?yàn)檫@個(gè)工具可以捕獲某些“特殊”數(shù)據(jù)包，例如JavaScript觸發(fā)的數(shù)據(jù)。 包？ 我也不知道怎么形容。
需要補(bǔ)充的是，上述三種思路還可以結(jié)合在蘋果手機(jī)上設(shè)置“網(wǎng)絡(luò)代理”，使用“電腦工具”來(lái)捕獲手機(jī)的數(shù)據(jù)包。 具體來(lái)說(shuō)，還可以用來(lái)捕獲“微信小程序”或“手機(jī)QQ”的一些數(shù)據(jù)包。這個(gè)想法筆者親自測(cè)試過(guò)，但目前還不清楚是否仍然有效。
*請(qǐng)認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
