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里面，但后续的客户端版本会直接集成进来。

说点什么

若是什么问题或建议能够给我提issue或加QQ群462558941
也欢迎你们直接PR
若是以为whistle好用且对你们有帮助，帮忙分享给你所在的团队及别忘了给whistle加个Star