Fiddler工具使用介紹一

Fiddler基礎知識

• Fiddler是強大的抓包工具，它的原理是以web代理服務器的形式進行工作的，使用的代理地址是：127.0.0.1，端口默認爲8888，我們也可以通過設置進行修改。
• 代理就是在客戶端和服務器之間設置一道關卡，客戶端先將請求數據發送出去後，代理服務器會將數據包進行攔截，代理服務器再冒充客戶端發送數據到服務器；同理，服務器將響應數據返回，代理服務器也會將數據攔截，再返回給客戶端。
• Fiddler可以抓取支持http代理的任意程序的數據包，如果要抓取https會話，要先安裝證書。

HTTP協議

• 要分析Fiddler抓取的數據包，我們首先要熟悉HTTP協議。HTTP即超文本傳輸協議，是一個基於請求與響應模式的、無狀態的、應用層的協議，絕大多數的Web開發，都是構建在HTTP協議之上的Web應用。
• HTTP的工作過程：當我們請求一個超鏈接時，HTTP就開始工作了，客戶端先發送一個請求到服務器，請求內容包括：協議版本號、請求地址、請求方式、請求頭和請求參數；服務器收到請求後做相應的處理，並將響應數據返回到客戶端，響應內容包括：協議版本號、狀態碼和響應數據。前端根據響應數據做相應的處理，就是最終我們看到的內容。這些過程是HTTP自動完成的，我們只是輸入或點擊請求地址，然後查看前端給我們展示的內容。更多關於HTTP協議的介紹請參考：http://www.cnblogs.com/li0803/archive/2008/11/03/1324746.html
• 請求方式常用的有：GET、PUT、POST、DELETE。
• HTTP狀態碼主要分爲5類：以1開頭的代表請求已被接受，需要繼續處理；以2開頭的代表請求已成功被服務器接收、理解、並接受；以3開頭的代表需要客戶端採取進一步的操作才能完成請求；以4開頭的代表了客戶端看起來可能發生了錯誤，妨礙了服務器的處理；以5開頭的代表了服務器在處理請求的過程中有錯誤或者異常狀態發生，也有可能是服務器意識到以當前的軟硬件資源無法完成對請求的處理。
• 常見的主要有：200：服務器成功處理了請求；404：未找到資源；500：內部服務器錯誤；503：服務器目前無法爲請求提供服務；302：請求的URL已臨時轉移；304：客戶端的緩存資源是最新的，要客戶端使用緩存。
• 每個狀態碼的詳細介紹請參考：https://baike.baidu.com/item/HTTP%E7%8A%B6%E6%80%81%E7%A0%81/5053660?fr=aladdin

Fiddler的使用

• Fiddler是一個很好用的抓包工具，可以將網絡傳輸發送與接收的數據包進行截獲、重發、編輯等操作。也可以用來檢測流量。
• Fiddler安裝後，設置的端口默認爲8888，當Fiddler啓動後，默認將IE的代理設爲了127.0.0.1:8888，而其他如火狐瀏覽器需要手動設置代理後纔可以抓包。設置內容如圖：

fiddler是一個很好的抓包工具，默認是抓http請求的，對於pc上的https請求，會提示網頁不安全，這時候需要在瀏覽器上安裝證書。

一、網頁不安全

1.用fiddler抓包時候，打開百度網頁：https://www.baidu.com

2.提示：網頁不安全

 

二、fiddler設置

1.打開菜單欄：Tools>Fiddler Options>HTTPS

2.勾選Decrypt HTTPS traffic，裏面的兩個子菜單也一起勾選了

 

三、導出證書

1.點右上角Actions按鈕

2.選第二個選項，導出到桌面，此時桌面上會多一個文件：FiddlerRoot.cer,如左側圖。

 

四、導入到firefox瀏覽器

1.打開右上角瀏覽器設置》選項》高級》證書》查看證書》證書機構》導入

2.勾選文件到入

3.打開文件後，會彈出個框，勾選三個選項就完成操作啦。

Google Chrome證書配置與之類似，證書導入之後需要重新啓動瀏覽器和fiddler。

1）要使用Fiddler進行抓包，首先需要確保Capture Traffic是開啓的（安裝後是默認開啓的），勾選File->Capture Traffic，也可以直接點擊Fiddler界面左下角的圖標開啓和關閉抓包。

2）所以基本上不需要做什麼配置，安裝後就可以進行抓包了。那麼我們怎麼分析抓到的這些數據包呢？如圖所示的區域爲數據包列表，要分析這些數據包，首先要了解各字段的含義。

名稱	含義
#	抓取HTTP Request的順序，從1開始，以此遞增
Result	HTTP狀態碼
Protocol	請求使用的協議，如HTTP/HTTPS/FTP等
Host	請求地址的主機名
URL	請求資源的位置
Body	該請求的大小
Caching	請求的緩存過期時間或者緩存控制值
Content-Type	請求響應的類型
Process	發送此請求的進程：進程ID
Comments	允許用戶爲此回話添加備註
Custom	允許用戶設置自定義值
圖標	含義
	請求已經發往服務器
	已從服務器下載響應結果
	請求從斷點處暫停
	響應從斷點處暫停
	請求使用 HTTP 的 HEAD 方法，即響應沒有內容（Body）
	請求使用 HTTP 的 POST 方法
	請求使用 HTTP 的 CONNECT 方法，使用 HTTPS 協議建立連接隧道
	響應是 HTML 格式
	響應是一張圖片
	響應是腳本格式
	響應是 CSS 格式
	響應是 XML 格式
	響應是 JSON 格式
	響應是一個音頻文件
	響應是一個視頻文件
	響應是一個 SilverLight
	響應是一個 FLASH
	響應是一個字體
	普通響應成功
	響應是 HTTP/300、301、302、303 或 307 重定向
	響應是 HTTP/304（無變更）：使用緩存文件
	響應需要客戶端證書驗證
	服務端錯誤
	會話被客戶端、Fiddler 或者服務端終止

3）每個Fiddler抓取到的數據包都會在該列表中展示，點擊具體的一條數據包可以在右側菜單點擊Insepector查看詳細內容。主要分爲請求（即客戶端發出的數據）和響應（服務器返回的數據）兩部分。

 4）HTTP Request Header：以百度爲例，查看請求百度主頁這條數據包的請求數據，從上面的Headers中可以看到如下內容：

請求方式：GET

協議： HTTP/1.1

Client 頭域：

Accept: text/html, application/xhtml+xml, image/jxr, */*                             ---------瀏覽器端可以接受的媒體類型

Accept-Encoding: gzip, deflate                                                                  ---------壓縮方法

Accept-Language: zh-CN                                                                          ---------語言類型

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14.14393                             ---------客戶端使用的操作系統和瀏覽器的名稱和版本

COOKIE頭域：將cookie值發送給服務器

Transport 頭域：

Connection：當網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP連接是否關閉。keep-alive表示不會關閉，客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接；close表示關閉，客戶端再次訪問這個服務器上的網頁，需要重新建立連接。

HOST：主機名或域名，若沒有指定端口，表示使用默認端口80.

　　5）HTTP Response Header：繼續以百度爲例，如圖所示：

協議：HTTP/1.1

狀態碼：200

Cache頭域：
Cache-Control: private                                               ---------此響應消息不能被共享緩存處理，對於其他用戶的請求無效

Date: Sat, 05 Aug 2017 04:37:43 GMT                      ---------生成消息的具體時間和日期

Expires: Sat, 05 Aug 2017 04:37:42 GMT                  ---------瀏覽器會在指定過期時間內使用本地緩存

Cookie/Login 頭域：

Set-Cookie: BDSVRTM=264; path=/                           ---------把cookie發送到客戶端
Set-Cookie: BD_HOME=1; path=/
Set-Cookie: H_PS_PSSID=1425_21097_22157; path=/; domain=.baidu.com

Entity頭域

Content-Length: 202740                                              ---------正文長度
Content-Type: text/html;charset=utf-8                         ---------告知客戶端服務器本身響應的對象的類型和字符集

Miscellaneous 頭域：
Bdpagetype: 2

Bdqid: 0x99791efd00036253

Bduserid: 2577220064
Server: BWS/1.1                                                          ---------指明HTTP服務器的軟件信息

X-Ua-Compatible: IE=Edge,chrome=1
Security頭域：
Strict-Transport-Security: max-age=172800                ---------基於安全考慮而需要發送的參數，關於這個參數的解釋，請參考：http://www.freebuf.com/articles/web/66827.html

Transport頭域：

Connection: Keep-Alive

6）TextView：顯示請求或響應的數據。

7）WebForms：請求部分以表單形式顯示所有的請求參數和參數值；響應部分與TextView內容是一樣的。

8）Auth：顯示認證信息，如Authorization

9）Cookies：顯示所有cookies

10）Raw：顯示Headers和Body數據

11）JSON：若請求或響應數據是json格式，以json形式顯示請求或響應內容

12）XML：若請求或響應數據是xml格式，以xml形式顯示請求或響應內容

13）上面是以百度主頁爲例，百度主頁採用的是GET請求，在TextView中沒有請求body，我們再以無憂行網站登錄接口爲例，它是一個POST請求，除了請求頭外，在TextView中多了請求數據。這也是GET請求和POST請求的一個區別。GET請求是將請求參數放在url中，而POST請求一般是將請求參數放在請求body中。

 

 

總結：通過Fiddler可以抓取請求和響應參數，通過對參數進行分析，可以定位是前端還是後臺問題。例如我們在測試登錄接口時，輸入了正確的手機號和密碼，但前端提示“請輸入正確的用戶名和密碼”；僅僅通過界面提示我們只能描述bug表象，但不能分析出問題原因。假設通過抓包我們發現是由於前端參數名錯誤或參數值爲空，從而導致後臺報錯。這個時候我們將bug指向前端開發人員，並將參數數據和接口文檔中對應的報文數據作爲附件上傳，是不是可以提高bug的解決效率呢？Fiddler在實際的功能測試中有很大的作用，一方面幫助我們更好的瞭解某個業務中客戶端和服務器端是通過哪些接口進行請求的，從而更好的瞭解代碼邏輯；另一方面，我們還可以通過響應數據判斷哪裏出現了問題，例如可能服務器程序掛了，導致前端報“服務器故障”，這時我們通過抓包發現響應數據返回502，這時我們可以手動去重啓服務或是聯繫運維重啓服務，從而提高問題的解決效率。

轉載自原文：https://www.cnblogs.com/miantest/p/7289694.html

更詳細的可以參照博客：https://www.cnblogs.com/yyhh/p/5140852.html