APP天天给抓包， HTTP代理是什么弄懂了吗？

在普通代理的流程中，代理两端都是有可能察觉不到「中间人」的存在。举个例子，我们要访问A网站，实际上我们是向代理服务器发送请求，而代理服务器又再向A网站发起请求，最终将响应体通过代理服务器，返回给我们。在我们的角度，我们正常的向一个网站服务器发起请求，并且对方也返回给我们正确的数据，在这个过程中，我作为客户端，会认为代理服务器就是A网站的服务器，而A网站的服务器，又认为代理服务器是一个真实的用户。这里说到，代理服务器作为「中间人」是可以保护安全访问自己的存在，但是如果我们作为一个“守规矩”的代理服务器，想要将客户端的IP传递给服务端，可以通过X-Forwarded-IP这个自定义的Header，来告诉服务端真正的客户端IP地址。HTTP协议作为一种松散的协议，服务器在接收到X-Forwarded-IP这个请求头时，是无法验证其真伪的。它可能是代理服务器全球住宅IP，高效采集公开数据的，也可能是真实的。所以服务端从HTTP头部获取IP时，就需要格外小心。普通代理很好理解，但是它也有缺陷，它只适用于HTTP协议。在普通代理模式下，所有请求响应的数据，对于代理这个「中间人」来说，都是透明并且可以任意操作，这就会带来各种数据安全的隐患。说到网络数据安全，首先想到的就是HTTPS，但是HTTPS这种证书认证的机制，又是中间人劫持的克星。严格上来说，HTTPS下不存在中间人攻击，除非是人为的犯错了，没有对证书严格校验，或者证书被泄露。在普通的HTTPS请求中，服务端不验证客户端的证书，中间人可以作为客户端与服务端完成TLS握手。但是由于代理中间人没有证书密钥，也就无法全球住宅IP，高效采集公开数据服务端和客户端简历的TLS连接，这会导致请求失败。这个场景，对标到抓包工具的工作流程中，你会发现，如果想用Charles（或Fiddler）抓HTTPS的网络数据包，就需要在手机上安装一个Charles的CA证书，让手机设备信任此证书，才可以完成抓包，此时走的就是普通代理的模式。那换个角度，假如在手机上没有安装Charles提供的证书，也并没有影响到请求和响应，Charles只是无法解密HTTPS数据，这是如何做到的呢？这就需要用到隧道代理。

2.4隧道代理

隧道代理，又称为Web隧道（Webtunnel），这种方式可以通过HTTP连接发送非HTTP流量，这样可以在HTTP上捎带其他协议的数据。隧道代理是利用HTTP的CONNECT方法建立起来的。CONNECT方法，最初并不是HTTP/1.1的核心规范，但却是一种得到广泛使用的扩展，它在2014年发布的HTTP/1.1修订版中，才对CONNECT及隧道代理有了清晰的描述。HTTP隧道代理的工作流程是什么样的？一次普通的HTTP请求，Header部分以连续的两组CRLF（\r\n）作为结束标记，如果后面还有内容，就是Content部分的内容，也称为请求/响应体（Body），如果存在Content内容，就需要在Header中增加Content-Length来标记Content部分的长度。接收方（服务端）会根据这个长度来读取数据。CONNECT报文的请求，是没有Content部分的，只有Request-Line和Header，他们仅供代理服务器使用，并不会传递给终端服务器。请求的Header部分一旦结束（两组连续的CRLF），后面的所有数据，都被视为应该转发给终端服务器的数据，代理需要把他们无脑的直接转发，并且不允许访问公开数据长度，直到从客户端的TCP读通道关闭。CONNECT的响应报文，在代理服务器和终端服务器建立连接后，可以向客户端返回一个200Connectestablished的状态码，以此表示和终端服务器的连接，建立成功。这个200Connectestablished的Header部分一旦结束（两组连续的CRLF），后面所有的数据均为远端服务器返回的数据，同理，代理服务器会直接转发终端服务器的数据给客户端，直到终端服务器的TCP读通道关闭。