- Fiddler是強大的抓包工具，它的原理是以web代理服務器的形式進行工做的，使用的代理地址是：127.0.0.1，端口默認爲8888，咱們也能夠經過設置進行修改。
- 代理就是在客戶端和服務器之間設置一道關卡，客戶端先將請求數據發送出去後，代理服務器會將數據包進行攔截，代理服務器再冒充客戶端發送數據到服務器；同理，服務器將響應數據返回，代理服務器也會將數據攔截，再返回給客戶端。
- Fiddler能夠抓取支持http代理的任意程序的數據包，若是要抓取https會話，要先安裝證書。
HTTP協議html
- 要分析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，而其餘如火狐瀏覽器須要手動設置代理後才能夠抓包。設置內容如圖：
1）要使用Fiddler進行抓包，首先須要確保Capture Traffic是開啓的（安裝後是默認開啓的），勾選File->Capture Traffic，也能夠直接點擊Fiddler界面左下角的圖標開啓和關閉抓包。web
2）因此基本上不須要作什麼配置，安裝後就能夠進行抓包了。那麼咱們怎麼分析抓到的這些數據包呢？如圖所示的區域爲數據包列表，要分析這些數據包，首先要了解各字段的含義。chrome
#：順序號，按照抓包的順序從1遞增json
Result：HTTP狀態碼 瀏覽器
Protocol：請求使用的協議，如HTTP/HTTPS/FTP等緩存
HOST：請求地址的主機名或域名安全
URL：請求資源的位置服務器
Body：請求大小cookie
Caching：請求的緩存過時時間或者緩存控制值
Content-Type：請求響應的類型
Process：發送此請求的進程ID
Comments：備註
Custom：自定義值
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，這時咱們能夠手動去重啓服務或是聯繫運維重啓服務，從而提升問題的解決效率。