对比使用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. 加密后数据量的影响. 所以，才会出现那么多的安全认证提示。