whistle - 跨平臺（Win/Mac/Linux）的 Fiddler

時間 2019-11-11

標籤 whistle 跨平臺 win mac linux fiddler 欄目 MacBook 简体版

原文原文鏈接

web調試代理工具是web開發人員必備的工具，它在發起web請求的客戶端與服務器之間充當中間人角色，能夠用於查看、修改或替換HTTP、HTTPS、Websocket請求(響應)數據，協助咱們作本地開發調試、構造數據、定位問題等等，業界已有一些比較優秀的web調試代理工具，特別是Windows上的Fiddler，因爲其出色的功能設計，儼然成爲了web調試代理工具的代名詞。但Fiddler只能在Windows系統上使用，當咱們換上Mac或者開發環境限制必須使用Linux時，咱們很難在這些平臺上找到相似Fiddler的工具，這個時候可能被提起最多的是Charles，Charles是用Java實現的跨平臺web調試代理工具，理論上能夠在安裝java虛擬機的桌面系統上使用，用過Fiddler的人廣泛以爲Charles難用，不論是性能、體驗、界面都沒法跟Fiddler相提並論(事實上Fiddler自己也是很耗內存)，更重要的是Charles不是免費的，價格也不菲，這也多是由於在Mac、Linux平臺上能夠選擇的web調試代理工具也很少，下面我要給你們詳細介紹的是本文的主角，開源免費且持續在維護的whistle--全新的跨平臺web調試代理工具。html

Note: 想了解調試代理工具的原理能夠看這篇文章：HTTP 代理原理及實現。java

whistle

Github: https://github.com/avwo/whistlenode

whistle是用NodeJS實現的跨平臺web調試代理工具，能夠安裝部署在裝有NodeJS的操做系統上(包括Windows、Mac、Linux等桌面或命令行系統)，並能夠經過Chrome瀏覽器訪問本地或遠程whistle的管理配置界面：git

查看、修改或替換HTTP、HTTPS、Websocket請求(響應)數據(包括url，host，方法，狀態碼，頭部及內容等)github
設置延遲請求(響應)web
限制請求(響應)速度正則表達式
在Composer裏面構造請求chrome
能夠把請求代理到其它服務器(支持socks和http代理)json
查看請求列表的Timeline瀏覽器
查看頁面JS腳本執行過程當中拋出的異常(能夠用在調試終端頁面或遠程調試)
查看JS中的console[info, log, warn, error, fatal](這些方法在IE也可使用)打印出來的數據對象(能夠用在調試終端頁面或遠程調試)
利用whistle集成的weinre查看或修改頁面的DOM結構(能夠用在調試終端頁面或遠程調試)
使用經過插件的形式擴展的功能(插件能夠用來擴展whistle的功能，特別是集成本地開發環境，方便開發人員使用)，如：處理combo請求

whistle借鑑了Fiddler的一些優秀的設計，好比請求列表及其詳細內容的展現(即Network)，但whistle不是Fiddler的複製品，除了請求列表的展現外，whistle在操做請求及功能擴展上有着本身獨特的方式，讓修改請求(響應)操做變得更簡單，並集成了終端(遠程)調試工具。

Note：爲了讓你們能對下面內容更好的理解及快速上手whistle，請先按步驟安裝好whistle：安裝node、安裝whistle、配置代理、啓動whistle

規則原理

Fiddler修改請求(響應)的數據時，須要對每一個請求設置斷點後-->手動修改-->手動放開請求，若是是同時修改多個請求或者屢次修改某個請求時，體驗不是很好；而whistle把對請求(響應)的操做分類，每一類對應一種協議(如：替換本地文件 file://)，每一個具體操做要用到的參數值放到協議後(如：file:///User/xxx/test.html中的/User/xxx/test.html)，這樣whistle把每一個操做抽象成一個uri。

問題來了，若是參數值有空格或須要多個參數(好比修改頭部的一些字段)，這個whistle是怎麼處理的？

上述問題包含兩個問題：

如何參數值有空格的問題？
在單參數情形下，若是是文件路徑或者是下面第二個問題要提到的請求參數類型(如：file://filepath、resAppend://filepath、reqHeaders://test=a%20b&referer=test等)，能夠用%20來代替，其它情形，能夠用{key}的形式把參數值存到whistle的Values系統，如：ua://{chrome-ua}，whistle會自動到Values裏面找chrome-ua對應的值。
如何處理多個參數的情形？
爲方便用戶使用，whistle儘量把一些經常使用的操做精簡到只有一個參數的情形(如請求頭部字段，能夠用協議req這種多參數的形式來新增或修改，對裏面經常使用的字段，如referer、ua等也能夠用獨立的協議(referer、ua)來設置)，但不可能把把全部操做都抽象成單個參數的情形。對於多參數情形，有以下3種方式：
- 直接用請求參數的方式轉成單參數的情形： reqHeaders://test=a%20b&referer=test，若是裏面有空格要用%20替換
- 按問題1的方式，用key代替，把value寫到whistle的Values裏面(reqHeaders://{test-reqHeaders})，而Values裏面reqHeaders的值也能夠有兩種方式具體參考：JSON格式
- 直接把值寫到本地文件(reqHeaders:///User/xxxx/test.json)，文件/User/xxxx/test.json裏面reqHeaders的值也能夠有兩種方式具體參考：JSON格式

上面解決了把每一個對web請求的操做用一個uri來表示的問題，如今咱們把對web請求的操做均可以抽象成一個operator-uri，如何用這些operator-uri來操做具體請求呢？

處理這個問題，whistle擴展了傳統hosts配置方式，採用匹配請求url到operator-uri的映射：

pattern  operator-uri

pattern能夠如下三種方式：

域名匹配：www.example.com operator-uri
路徑匹配：www.example.com/... operator-uri
正則匹配：/example/ operator-uri

爲了兼容hosts的配置方式：

# 單個匹配
127.0.0.1 www.example.com

# 多個匹配
127.0.0.1 www.example1.com www.example2.com www.exampleN.com

whistle默認匹配順序是從上到下，從左到右，多個匹配也能夠寫成

# 多個匹配
pattern operator-uri1 operator-uri2 operator-uriN

若是whistle能夠判斷operator-uri不可能爲web請求的url，即不是以下uri形式:

# operator-uri協議爲http, https, ws, wss之一
pattern http://xxxx

# operator-uri不包含協議，又不是ip
pattern xxxxx

或者pattern爲正則表達式，知足這兩種狀況下，pattern和operator-uri的順序是能夠調換的：

# 單個匹配
operator-uri pattern
# 多個匹配的狀況
operator-uri pattern1 pattern2 patternN

上面講了Rules的一些配置規則原理及Values的用途，包括：operator-uri設計原理，規則的匹配順序(從上到下，從左到右)，匹配方式，什麼狀況下能夠對調等等。

一些例子

下面舉一些例子，讓你們快速上手whistle(規則中用#做爲註釋符號，若是要查看或修改HTTPS、Websocket的請求(響應)數據，要開啓HTTPS攔截功能：啓用HTTPS)：

host
host的配置方式不只徹底兼容系統自帶的配置方式，並且支持路徑、正則匹配：

# 傳統的配置方式
# 單個匹配
127.0.0.1 www.ifeng.com
# 多個匹配
127.0.0.1 www.ifeng.com www.qq.com
    
# 路徑(順序能夠調換)
# 單個匹配
127.0.0.1 http://www.ifeng.com/xxx
# 多個匹配
127.0.0.1 http://www.ifeng.com www.qq.com/xxx
    
    
#正則(順序能夠調換)
# 單個匹配
127.0.0.1 /ifeng/
# 多個匹配
127.0.0.1 /ifeng/ /qq/
    
    
# whistle也支持以下方式，在ip前面加個協議(順序能夠調換)
# 單個匹配
host://127.0.0.1 www.ifeng.com
# 多個匹配
host://127.0.0.1 www.ifeng.com www.qq.com

端口映射(下面舉得例子都是用域名匹配的方式，其它方式同理)

# 本地調試
www.example.com 127.0.0.1:8080
    
# 映射到線上
www.example.com www.qq.com
www.example.com:8080  www.qq.com

本地替換

# 下面用`|`來分隔目錄或文件，從左到右依次找到存在的文件爲止
www.example.com file:///User/xxx/test|/User/xxx/test/index.html

上述配置，若是咱們訪問http://www.example.com/，則whistle會先找是否有/User/xxx/test這個文件，若是沒有就會匹配/User/xxx/test/index.html；若是咱們訪問http://www.example.com/test.html，則whistle會先在找文件/User/xxx/test/test.html，再找/User/xxx/test/index.html/test.html，若是沒就返回404。

這裏只是舉了幾個小例子，whistle還有很是多的功能，如：reqHeaders，resHeaders，log，disable，filter，weinre等等，並且還支持插件擴展，更多功能請參考：Wiki，功能列表

後續規劃

whistle是我業餘時間在維護且會長期維護的項目，通常來講新版本(若是有)的發佈放在週日晚上(修復影響功能的bug的版本不受時間限制，有新版本發佈界面中的About菜單現會有紅點提醒或者大版本發佈則是直接彈框提醒，你們按提示更新就能夠)，下面是一些後面的規劃內容：

插件whistle.websocket開發：用於查看websocket的請求內容
插件whistle.img開發：用於查看抓包到的圖片內容
插件whistle.settings開發：用於一鍵安裝系統代理及安裝根證書(若是根證書不能一鍵安裝，至少要作到點擊能彈出根證書的安裝對話框)，也爲後面的客戶端版本作準備
whistle的客戶端開發：有打算把一些自動化測試的功能集成進來，設想的交互功能也會比Node強不少，由於能夠直接操做本地文件
官網http://wproxy.org及文檔建設：打算用Gitbook把文檔從新整理，而後再i18n下及官網陸續創建起來

上面面規劃的功能都只是在業餘時間作，因此不能給出確切的完成時間，前面兩個插件會盡快開發出來，想關注進度能夠 Follow me：https://github.com/avwo。

PS：爲何不把websocket、img、settings這幾個插件功能集成到whistle裏面，而要以插件的形式單獨存在？主要是考慮到這幾部分功能用到的時候相對比較少，及減小安裝whistle過程當中出現錯誤及運行過程當中的內存問題，像處理websocket用到的中間件體積比較大且須要本地編譯，img功能有比較耗內存和硬盤，並且把這部分功能放在獨立的頁面可能體驗更好，綜上考慮沒有把這部分功能集成到whistle裏面，但後續的客戶端版本會直接集成進來。