为了方便，本文以 iOS 系统来进行演示。
使用代理
移动操作系统中都有可以设定系统代理的设置，比如在 iOS 中可以通过 Settings->WLAN 看到很多 Networks，通过点击它们后面的 Info 图标来设置代理：
这样的话，所有的请求就会先到我们设置的代理服务器，然后才有代理转发给目标服务器。于是我们就有机会在代理服务器上获取到请求的内容。
这里我使用的代理服务器是 Charles，在安装并打开了 Charles 之后，Charles 就已经在后台建立了一个代理服务了。我们可以通过 ifconfig 命令找到自己的局域网 IP，Charles 默认的代理端口是 8888。现在像上面的截图那样，在移动端中进行配置以使用我们的 Charles 代理。
现在你可以在移动端发起一些网络请求，当然最好是 HTTP 的，因为我不清楚 Charles 是否支持其他的协议类型。为了方便，我们可以使用 Safari 打开一段网址，比如 http://news.baidu.com (注意目前只是 HTTP 的，关于如何操作 HTTPS 下面会讲到)。题外话，正如你所见的，百度的最常用的功能就是检查网络服务的连通情况，比如 ping baidu.com，哈。
如果不出意外，那么你会在 Charles 左边栏中看到类似下图的情况：
那么说明我们的配置已经工作了，如果你点击它们中的一个，右边的界面中就会显示对应的请求内容：
很好，Charles 已经为我们做了很多事，现在我们可以轻松的知道发生了哪些请求以及请求的内容了。
HTTPS
现在我们试一试在 safari 中输入 www.baidu.com，我们知道百度在 www 子域中使用了 HTTPS，并且当发现用户使用的不是 HTTPS 访问此子域时，会自动的 redirect，于是我们到了 https://www.baidu.com。
现在再来看看 Charles 中的情况，我们发现 https://www.baidu.com 前面多了一把小锁：
并且右边没有给出请求的内容，但是有一条提示 - 对于 SSL 代理需要进行额外的设置。
下面我就简单解释一下为什么对于 HTTPS 而言 Charles 就暂时罢工了。更加具体的内容，可以见我的这篇文章 非对称加密和数字证书。
HTTPS 就是 HTTP over TLS，就是在原本的 HTTP 请求之前，客户端和服务器先进行 TLS 握手并建立一个 TLS 链接，然后在此链接之上进行 HTTP 协议的内容。这样就使得我们的明文请求变成加密的。但是这里还是有一个缺陷，就是 TLS 握手阶段是明文的，那么为了解决这种鸡生蛋蛋生鸡的问题，出现了证书 (Certificate) 和证书颁发机构 (Certificate Authority)。
于是在 TLS 握手阶段，多了一个校验证书的步骤，服务端会返回 CA 颁发给其的证书，而客户端对证书的真实性进行校验。由于现在的请求内容已经被加密，所以作为代理的 Charles 无法知道其中的内容，于是为了使得 Charles 可以解析 HTTPS 的内容，我们就必须协助其完成 Man-in-the-middle 攻击，攻击的对象就是我们自己。
攻击的方式很简单，在手机上安装上 Charles 的 CA 证书即可，所谓 CA 证书就是 CA 机构的证书，来证明 CA 机构的真实性，一些权威的 CA 机构的证书都是内置在我们的操作系统中的。现在我们在移动端上安装了 Charles 的 CA 证书之后，Charles 就变成了 CA 了，于是它就可以颁发一个伪造的证书来欺骗移动端中的应用。
如果你不想了解其中的原理的话，要实现这个攻击还是很简单的，Charles 也提供了很多的便利，按照下面的步骤就行了。
我们在 Charles 的菜单中找到 ：
点击一下就会看到：
在移动端的 safari 中输入地址 http://charlesproxy.com/getssl 后，跟着下面的截图来将 Charles 制作的 CA 证书安装到移动端中：
到目前为止，Charles 制作的 CA 证书已经安装到了你的移动端，如果你希望删除它的话，可以通过 Settings->General->Profile 来找到它并删除，另外如果你不信任 Charles 自制的 CA 证书的话，它也是支持你使用自己的 CA 证书的。
再回到 Charles 进行一些设置，添加一下 SSL 规则：
现在，再回到移动端，在 safari 中访问 www.baidu.com，然后再看看 Charles 中的结果，你会发现：
现在我们已经可以解析来自移动端的 HTTPS 请求了。
暂时就先写这么多吧