fidder抓包原理及content-type類型

fidder抓包原理簡介：

1. 客戶端像WEB服務器發送HTTP(S)請求時，請求會先經過Fiddler代理服務器。
2. Fiddler代理服務器截取客戶端的請求報文，再轉發到WEB服務器，轉發之前可以做一些請求報文參數修改 的操作
3. WEB服務器處理完請求以後返回響應報文，Fiddler代理服務器會截取WEB服務器的響應報文。
4. Fiddler處理完響應報文後再返回給客戶端。
   

fidder抓包https原理：

現在基本上都使用HTTS傳輸，傳輸的數據都是經過加密的，這增加了我們分析數據包的難度，由於H TTPS傳輸需要使用到CA證書，所以抓取HTTPS數據包時需要做一些特殊配置。Fiddler截取HTTPS 報文的流程大致如下：

1. 客戶端請求建立HTTPS鏈接，發送客戶端支持的加密協議及版本列表等信息給服務器端。
2. Fiddler接受客戶端請求並僞裝成客戶端向WEB服務器發送相同的請求。
3. WEB服務器收到Fiddler的請求以後，從請求中篩選合適的加密協議。並返回服務器CA證書，證書中包括公鑰信息。
4. Fiddler收到WEB服務器的響應後保存服務器證書並自簽名一個CA證書，僞裝成服務器，把該證書下發給客戶端。
5. 客戶端驗證證書合法性。（Fiddler能否抓取到HTTPS報文關鍵看這一步）
6. 客戶端生產對稱密鑰，通過證書的公鑰加密發送給服務器。
7. Fiddler攔截客戶端的請求以後，使用私鑰解密該報文，獲取對稱加密祕鑰，並使用服務器證書中帶的公鑰加密該對稱密鑰發送給WEB服務器。此時對稱密鑰已經泄露了，以後可以使用該祕鑰界面客戶端和服務器端傳輸的數據。
8. WEB服務器接收到客戶端發送的加密的對稱密鑰後使用私鑰解密，並使用對稱密鑰加密測試數據傳給客戶端。
9. Fiddler使用前面獲取的對稱密鑰解密報文。
10. 客戶端驗證數據無誤以後HTTPS連接就建立完成，客戶端開始向服務器發送使用對稱密鑰加密的業務數據
11. Fiddler使用前面獲取的對稱密鑰解密客戶端發送的數據並重新加密轉發給服務器端。

Fidder在此時就相當於一個雙面間諜一樣，對服務器來說它是客戶端，對客戶端來說它是服務器端，能夠同時獲得客戶端和服務端加密的內容

常見的content-type：

1. application/x-www-form-urlencoded：這應該是最常見的提交數據的方式了。數據被編碼爲名稱/值對，這是標準的編碼格式。
2. multipart/form-data：一般用在發送文件的POST包，另外，還有boundary用於分割數據。當文件太長，HTTP無法在一個包之內發送完畢 ，就需要分割數據，分割成一個一個chunk發送給服務端， 那麼boundary用於區分數據塊, 而後面的數據就是標示區分包作用
   
3. text/xml：通過XML 形式將數據發送給服務器
4. application/json：通過json形式將數據發送給服務器，現在越來越多的應用使用application/json,由於 JSON 規範的流行，除了低版本 IE 之外的各大瀏覽器都原生支持 JSON. stringify，服務端語言也都有處理 JSON 的函數，使用 JSON 不會遇上什麼麻煩。