對比使用Charles和Fiddler兩個工具及利用Charles抓取https數據（App）
實驗目的：對比使用Charles和Fiddler兩個工具
實驗對象：車易通App，易銷通App
實驗結果：
1. 接口數據呈現方式對比：
（1） Charles樹狀結構呈現於屏幕，清晰易區分
（2）Fiddler默認按時間倒敘呈現所有接口數據，不易區分
個人覺得圖形界面上Charles更易使用，當然可以通過過濾抓取的接口數據，這樣Fiddler下也就很容易區分你要找的接口了。
2. 針對車易通和易銷通App抓取的接口數據全面性對比：
（1） Charles對於https無法直接獲取到，可獲取的呈現出來也都是亂碼，需要安裝ssl證書，后面會寫具體設置方法。
（2） Fiddler可以直接抓取所有接口數據，無需設置。
------------華麗麗的分割線-------------
本來就是想對比一下，給自己選一個順手的工具用啦，過程中有意外發現，也是寫這個小總結的主要原因~
在同時使用Fiddler和Charles抓取 車易通和易銷通app的數據時發現，Charles是獲取到的數據沒有Fiddler全面，我想要的數據幾乎都沒抓到，問了鳳姐，問了開發和接口相關人員，考慮到了加密處理，虛擬目錄等等等等，無解…… 重新一條一條比對后發現Charles沒有抓取到的數據剛好在Fiddler下全部都是https協議的，對於這部分https協議Charles幾乎都獲取不到，能夠獲取到的也都是亂碼狀態，問題找到啦，百度解決……. 以下是解決方案，so easy…….
------------------------------------------
charles抓取https請求設置
1. 問題所在： 用charles抓取https請求，會出現SSLProxying disabled in Proxy Settings這樣的提示，如下圖。
2. 解決方案：
（1） 安裝charles ca證書，如下圖。
（2） 然后會彈出證書信息，選擇安裝證書，下一步，將證書存儲改為：受信任的根證書頒發機構，下一步，完成。
（3）修改charles的proxysettings：選擇Proxy | Proxy Settings，彈出proxy設置選項卡，勾選Enabling transparent HTTPproxying。
（4）選擇ssl,勾選Enable SSL Proxying，在Location部份選擇add，按如下圖添加，抓取任意站點、443端口的數據。
（5）設置完畢，此時再連接代理去抓取https協議，已經完全可以了~
另外，我看網上有說這樣設置完成還是抓取App的時候失敗了的，但是我試了安卓和ios都沒有遇到這種情況，如果大家有遇到可以通過http://www.charlesproxy.com/ssl.zip去下載證書，給移動設備安裝（網上有反應ios設備安裝不了這個的，我沒有嘗試過……） 。
題外話：整個設置步驟很簡單啦，網上遍地都是，但我當時很好奇為什么要設置成443,為什么要安裝ca證書， 所以又查了一下https跟http的區別，補充一下我這匱乏的知識體系。
HTPPS和HTTP的概念 :
我的理解：很簡單， https是在http的基礎上加了SSL層，是http的安全版，端口是443。
http就不用說啦，超文本傳輸協議，規定瀏覽器跟服務器之間傳輸規則的，端口是80。
----------以下是百度的版本：-----------
HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。 它是一個URI scheme（抽象標識符體系），句法類同http:體系。用於安全的HTTP數據傳輸。https:URL表明它使用了HTTP，但HTTPS存在不同於HTTP的默認端口及一個加密/身份驗證層（在HTTP與TCP之間）。這個系統的最初研發由網景公司進行，提供了身份驗證與加密通訊方法，現在它被廣泛用於萬維網上安全敏感的通訊，例如交易支付方面。
超文本傳輸協議 (HTTP-Hypertext transfer protocol) 是一種詳細規定了瀏覽器和萬維網服務器之間互相通信的規則，通過因特網傳送萬維網文檔的數據傳送協議。
HTTPS和HTTP的區別：
https協議需要到ca申請證書，一般免費證書很少，需要交費。http是超文本傳輸協議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協議http和https使用的是完全不同的連接方式用的端口也不一樣,前者是80,后者是443。http的連接很簡單,是無狀態的HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議 要比http協議安全HTTPS解決的問題：1 . 信任主機的問題. 采用https 的server 必須從CA 申請一個用於證明服務器用途類型的證書. 改證書只有用於對應的server 的時候,客戶度才信任次主機.所以目前所有的銀行系統網站,關鍵部分應用都是https 的. 客戶通過信任該證書,從而信任了該主機.其實這樣做效率很低,但是銀行更側重安全. 這一點對我們沒有任何意義,我們的server ,采用的證書不管自己issue 還是從公眾的地方issue, 客戶端都是自己人,所以我們也就肯定信任該server.2 . 通訊過程中的數據的泄密和被竄改1. 一般意義上的https, 就是server 有一個證書.a) 主要目的是保證server 就是他聲稱的server. 這個跟第一點一樣.b) 服務端和客戶端之間的所有通訊,都是加密的.i. 具體講,是客戶端產生一個對稱的密鑰,通過server 的證書來交換密鑰. 一般意義上的握手過程.ii. 加下來所有的信息往來就都是加密的. 第三方即使截獲,也沒有任何意義.因為他沒有密鑰. 當然竄改也就沒有什么意義了.2. 少許對客戶端有要求的情況下,會要求客戶端也必須有一個證書.a) 這里客戶端證書,其實就類似表示個人信息的時候,除了用戶名/密碼, 還有一個CA 認證過的身份. 應為個人證書一般來說上別人無法模擬的,所有這樣能夠更深的確認自己的身份.b) 目前少數個人銀行的專業版是這種做法,具體證書可能是拿U盤作為一個備份的載體.HTTPS一定是繁瑣的.a) 本來簡單的http協議,一個get一個response. 由於https 要還密鑰和確認加密算法的需要.單握手就需要6/7 個往返.i. 任何應用中,過多的round trip 肯定影響性能.b) 接下來才是具體的http協議,每一次響應或者請求, 都要求客戶端和服務端對會話的內容做加密/解密.i. 盡管對稱加密/解密效率比較高,可是仍然要消耗過多的CPU,為此有專門的SSL 芯片. 如果CPU 信能比較低的話,肯定會降低性能,從而不能serve 更多的請求.ii. 加密后數據量的影響. 所以，才會出現那么多的安全認證提示。