抓包神器之Charles，常用功能都在這裏了

    我們在開發網站項目的時候，我們可以通過瀏覽器的debug模式來看request以及response的數據，那麼如果我們開發移動端項目沒有網頁呢？如何抓取數據呢？

 

    前幾天有個做服務端的師弟跟我說他不用抓包工具，遇到問題直接debug代碼，那我問他，如果線上服務的話，你怎麼調？在實際項目中，沒有遇到跟客戶端相互扯皮的事情嗎？我覺得很正常啊，客戶端說他沒問題，服務端也說他沒問題，到底誰有問題？這時候沒必要相互推脫，拿數據出來說話纔是王道。抓包工具做了什麼？它把客戶端的請求數據，以及服務端返回的數據完完整整的抓取下來，供攻城獅分析問題。所以首先分析問題纔是最重要的，而不是一上來就跟蹤代碼debug。

 

 

Charles

         是一個HTTP代理服務器,HTTP監視器,反轉代理服務器，當程序連接Charles的代理訪問互聯網時，Charles可以監控這個程序發送和接收的所有數據。它允許一個開發者查看所有連接互聯網的HTTP通信，這些包括request, response和HTTP headers （包含cookies與caching信息）。

 

Charles主要功能:

• 支持SSL代理。可以截取分析SSL的請求。

• 支持流量控制。可以模擬慢速網絡以及等待時間（latency）較長的請求。

• 支持AJAX調試。可以自動將json或xml數據格式化，方便查看。

• 支持AMF調試。可以將Flash Remoting 或 Flex Remoting信息格式化，方便查看。

• 支持重發網絡請求，方便後端調試。

• 支持修改網絡請求參數。

• 支持網絡請求的截獲並動態修改。

• 檢查HTML，CSS和RSS內容是否符合W3C標準。

Charles安裝：

    去Charles的官方網站（http://www.charlesproxy.com）下載最新版的相應操作系統的Charles安裝包安裝即可。

 

    Charles是收費軟件，可以免費試用30天。試用期過後，未付費的用戶仍然可以繼續使用，但是每次使用時間不能超過30分鐘，並且啓動時將會有10秒種的延時。

 

    因此，該付費方案對廣大用戶還是相當友好的，即使你長期不付費，也能使用完整的軟件功能。只是當你需要長時間進行封包調試時，會因爲Charles強制關閉而遇到影響。（偷偷告訴你，公衆號回覆“Charles”獲取破解版下載鏈接）

 

Charles的功能很強大，我們這裏只介紹幾個常用的並且非常實用的功能：

1. 將Charles設置成系統代理

2. 截取移動設備上的網絡請求包

   1. 手動重複請求（Repeat，Advanced  Repeat）

   2. 手動模擬請求（Compose）

   3. 修改網絡請求內容（Compose）

3. 過濾網絡請求

4. 代理轉發

5. 支持https請求抓包（如果配置了還是抓不到，下面有解決方案）

 

Charles 主要提供兩種查看封包的視圖，分別名爲 “Structure” 和 “Sequence”。

1. Structure 視圖將網絡請求按訪問的域名分類。

2. Sequence 視圖將網絡請求按訪問的時間排序。

 

下面將一一介紹這些如何配置和使用：

 

一. 將Charles設置成系統代理

Charles 是通過將自己設置成代理服務器來完成抓包的，勾選系統代理後，系統本地發出去的請求都能被截取下來。如果只抓取APP的包的話，可關閉此配置，這樣不會出現太多的數據看着比較亂。

 

Mac

Windows:

    需要注意的是，Chrome 和 Firefox 瀏覽器默認並不使用系統的代理服務器設置，而 Charles 是通過將自己設置成代理服務器來完成封包截取的，所以在默認情況下無法截取 Chrome 和 Firefox 瀏覽器的網絡通訊內容。如果你需要截取的話，在 Chrome 中設置成使用系統的代理服務器設置即可，或者直接將代理服務器設置成 127.0.0.1:8888 也可達到相同效果。

 

二. 截取移動設備上的網絡請求包

我們在調試移動APP時，需要抓取APP發送的數據包，首先進行設置，Proxy -> Proxy Settings默認端口是8888，根據實際情況可修改。

 

查看本機IP地址：Help -> Local IP Addresses

 

然後配置手機代理：

IOS和Android配置差不多

 

打開要調試的APP，請求就會先發送到Charles，然後驗證是否允許訪問。

 

當點擊允許後，可以在Proxy -> Access Control Settings裏看到可以訪問此代理服務器列表

注意

如果不小心點擊了拒絕，可以手動添加手機IP/Mac地址到允許訪問列表，或者重啓Charles，手機再次訪問，會再次提示選擇。

如果不想每換一個手機都要進行驗證，可以配置允許所有手機訪問，加入

0.0.0.0/0（IPv4）或::/0（IPv6）

 

現在就可以抓包了，拿一款我們公司開發的樂視車聯APP（像是做廣告，你猜對了，用了兩天寫文章，還不允許我打個廣告嗎？ios和安卓商城均可下載）來做測試：

 

三. 過濾網絡請求

    通常情況下，網絡請求是非常大量的，從幾十個請求裏找到我們需要的觀察的某個請求比較費時，那麼我們就需要對網絡請求進行過濾，只監控向指定目錄服務器上發送的請求。有兩種方法：

 

1. 在Sequence界面的中部的Filter欄中填入需要過濾出來的關鍵字。例如我們的服務器的地址是：*.leautolink.com，那麼只需要在Filter欄中填入leautolink即可。（一般用於臨時過濾）

 

2. 在Charles的菜單欄選擇"Proxy"->"Recording Settings"，然後選擇Include欄，選擇添加一個項目，然後填入需要監控的協議，主機地址，端口號。這樣就可以只截取目標網站的封包了。如下圖所示：（固定過濾地址）

 

四. 代理轉發

    實際開發時，有這樣的場景，服務端線上版本有bug，你在本地修改程序後，需要模擬實際的線上環境，來驗證程序的正確性，最笨的方法就是讓客戶端修改一下APP的調用地址到你本機，然後重新打一個版本供你模擬測試，這樣雖然可以，但每次遇到bug都要這麼做的話，那效率極其低下，然而Charles爲我們解決了這個問題。

 

    請求轉發，把調用方調用的地址轉發到你本機地址的程序進行執行。

右鍵 -> Map Remote ...

 

並且配置Tools -> Map Romote 

 

運行APP

 

五. Https請求抓包

默認我們是看不到https的請求數據的。我們需要安裝證書。

Mac:

 

雙擊打開Charles Proxy CA

 

手機配置完代理（必須的操作）後，瀏覽器打開http://chls.pro/ssl

 

然後配置Proxy -> SSL Proxying Settings... 添加要抓取的https請求

 

然後再次請求：

 

如果不再使用Charles，想刪除手機裏的證書文件怎麼刪除呢？

設置->通用->描述文件與設備管理，刪除指定的證書即可

 

Windows:

下一步

然後繼續下一步直到導入成功。

 

剩下的配置與Max下配置相同

 

SSL的問題：

    最近iPhone系統更新到ios 10.3後,用Charles抓包竟然出現了一些問題,https的請求都會失敗,提示錯誤信息爲Failure SSLHandshake: Received fatal alert: unknown_ca 和You may need to configure your browser or application to trust the Charles Root Certificate. 然而之前任何問題都沒有,並且相關設置都正確:電腦上安裝了Charles的根證書,並且設置了始終信任,然後手機上也登錄了http://chls.pro/ssl安裝了描述文件,一切都按正常程序走的,但是錯誤始終無法解決.

 

原因：

雖然charles的根證書已經在安裝列表中顯示,但它是被關閉的。在iOS 10.3之前,當你將安裝一個自定義證書,iOS會默認信任,不需要進一步的設置。而iOS 10.3之後,安裝新的自定義證書默認是不受信任的。如果要信任已安裝的自定義證書,需要手動打開開關以信任證書。

 

解決：

設置->通用->關於本機->證書信任設置-> 找到charles proxy custom root certificate然後信任該證書即可.

 

Windows系統無法上網的問題

    在windows下，如果Charles沒有正常關閉，或者系統重啓後無法上網的問題，因爲Charles做了系統代理，當上網的時候，首先先訪問代理服務器，然後代理再去鏈接網絡，這時候Charles是非正常關閉的，只要重新打開Charles即可上網正常，正常關閉Charles後同樣沒問題。

寫給測試人員的

    另外抓包工具不只是開發人員獨享的，任何一個參與項目的人都可以使用，測試工程師，運維，產品經理等等任何對技術感興趣的人，尤其是測試工程師，在測試的過程中遇到問題，不是簡單的bug記錄員，而要做到問題的分析員，這纔是真正的“工程師”，當bug真正的到開發這的時候，他拿到的是不僅僅是bug，包含了分析過程，分析的數據，甚至是解決方案。我覺得這纔是標準工作方式。    

    舉個例子，現在是移動互聯網時代，那麼我們開發的客戶端必然包括Android和IOS版本，同樣的功能必然在不同的客戶端都有實現，比如同樣的功能Android能用，而IOS不能用，這時候對於測試人員來說，他可以簡單的提個bug說某個功能Android能用，ISO不能用，請開發人員解決。這個問題應該給誰呢？IOS開發，是IOS缺少請求參數？服務端開發，是服務端缺少對IOS的兼容嗎？爲了能讓問題解決，可能要寫兩個相同的bug發給不同的人， 那我們開發看到這樣的問題，首先重現問題，那麼肯定要跟測試人再次溝通，問問當時的測試過程，然後模擬同樣的數據進行復現。

    那麼如果我們的測試工程師換一種工作方式呢？當遇到問題的時候，用抓包工具把數據抓下來，首先比較Android和IOS發送請求參數有什麼不同，比較一下返回的數據有什麼不同，如果請求參數不同，那麼測試人員通過模擬工具，把缺少的參數加上，那麼返回的數據是不是就正確了呢？如果參數相同，返回的數據不同，或者是參數相同，返回的數據相同，這樣的話，問題就顯而易見了，測試人員可以把抓取的數據提交給相應的開發人員，而開發人員完全可以去debug了。提高測試人員的自身技能，而又提高了解決問題的效率，何樂而不爲？