从工作后一直都有接触charles，特别是移动端开发，用charles去抓手机包进行调试，再正常不过了。那么，charles都做了什么工作呢，可以让我们抓到浏览器或者手机向服务器发送请求及服务器响应的数据包？对于https加密请求而言，又是怎么处理的呢？
下面我们来分析一下这个过程：
以浏览器为例。我们在浏览器上输入一个请求地址，浏览器的网络进程会向目标服务器发起请求，服务器正常返回数据。那么我们如何在charles中获取到浏览器发送和接收到的数据呢？
charles可以帮助我们做到这个。有了charles，原本浏览器->服务器这样的路径成了 浏览器 -> charles -> 服务器。charles作为代理服务器 横在了浏览器和服务器中间，所以代理服务器charles就可以获取到浏览器和服务器通信的内容了。我们也就能通过charles对请求和相应的内容进行篡改来进行调试。
做一个比喻来讲：
小名(浏览器)和小红(服务器)是一个班里的同学，也是一对情侣。之前他们两个坐的特别近，上课就偷偷传纸条(发送请求)。
后来呢，班级调座位了，小红和小名相隔了很远，再也不能直接传纸条了。所以他们请坐在他们中间的小刚(charles)给他们传纸条。
刚开始的时候，他们写小纸条，内容都是正常的文字(http请求)，经过小刚时，小刚能够获得他们彼此小纸条上的内容。
后来呢，出于对通信内容安全的考虑，http协议引入了https加密机制。通过加密算法对请求和相应内容进行加密。这样一来，代理服务器尽管能够获得通信内容，但都是加密过的，一堆乱码，就没办法获取到真正的内容了。
后来，他们商量着设计一套加解密的方案。在小名把小纸条给小刚前，对原来的内容进行加密，然后小刚获得小纸条后，看到的就是一堆火星文，不能知晓其中的意思。等小纸条传给小红后，小红按照既定的规则对纸条内容进行解密，获得原来的明文。
所以，这就是当我们尝试直接在charles中访问https相关请求时，看到的都是一堆乱码，一脸懵逼……
这时，如果我们想要查看https请求和响应的真实内容，就需要安装对应的charles证书在系统上了，并且添加信任。那么这一步做了什么呢？
后来呢，小红和小名因为排座位离得更远了，需要通过小刚和小华两个人传纸条。然后他们私下商量，决定允许小刚查看纸条内容，但是对小华保密。这个时候，小名私下找到小刚，把他和小红约定的加密方式给到了小刚。
这样一来，小名继续在纸条上写加密的内容，传给小刚(charles)
对于https的验证过程，再次就不多说了。详见https为什么比http更安全
那么加入了charles后的https，又是怎样的过程呢？
- 客户端向服务器发起请求，被charles拦截
- charles拦截到之后，伪装客户端向服务器发起请求
- 服务器获取到请求信息后，将CA证书(包含了非对称加密的公钥，私钥在自己手里)发送给客户端
- charles拦截了服务器发送的消息，将CA证书保存在自己手里，然后自己将随机生成的证书发送给客户端。
- 浏览器获取到了charles的证书。通过在系统上预装charles的根证书，通过了浏览器对证书的安全验证，认为它是一个合法的证书。进而浏览器获得了charles证书的公钥。
- 浏览器通过charles的证书公钥加密对称加密的秘钥对，charles收到信息后将它用自己的私钥解密，获得之后用于信息加密的对称秘钥对。
- charles用之前获取的服务器证书的公钥对解密后的秘钥对进行加密，发送给服务器。
- 服务器收到请求信息，用自己的私钥解密，获取到对应的对称加密秘钥。然后用获取的秘钥对 对相应信息进行加密，返回给客户端
- charles获取到服务器加密后的信息，用之前获取的对称加密的秘钥进行解密，就可以获取到返回信息的明文内容了。然后再用对称秘钥进行加密后返回给客户端。客户端用对称秘钥解密，获得消息。
- 至此，charles获取到了客户端和服务器用于之后加密的秘钥对，就可以对请求消息和响应消息就行修改了。
如图所示：
