| HTTP代理是最经典最常见的代理协议。其用途非常广泛，普遍见于公司内网环境，一般员工都需要给浏览器配置一个HTTP代理才能访问互联网。起初，HTTP代理也用来翻越G*W，但是因为G*W不断发展，普通的HTTP代理早已无效了。但是，基于仍然有不少人使用明文的HTTP代理协议结合 stunnel之类的软件进行加密翻Q，有时这种代理又被称为HTTPS代理。再后来，又出现了WebVpn via Spdy之类的代理协议，特点是Chrome浏览器直接支持。再加上HTTP代理协议可以代理什么？是只能代理HTTP还是也可以代理HTTPS，还是可 以用来实现SOCKS代理？总之，非常混乱。在fqsocks项目里用python实现了HTTP代理的各种主流变种，终于明白了不同称谓之后的真正含义。本文试图总结一二。
代理基础 所有的代理，其原理都是类似的。其网络拓扑结构都是这样的：
代理左手拿着与客户端的连接，右手拿着与服务器的连接，然后在两个TCP连接之间做数据的对拷。各种不同的代理协议，不同的只是TCP连接之上跑的 是什么的协议，数据是怎么经过包装，拆包的。不存在客户端与服务器之间建立TCP连接的情况。只有VPN这种在IP包这一层工作的，才能实现客户端与服务 器的之间连接。 HTTP流量，明文的代理连接
这是最简单的一种HTTP代理。其工作方式是客户端与代理之间建立的TCP连接是明文的，也就是不经过SSL加密的。在TCP连接中传输的数据就是 明文的HTTP的POST和GET这些。对于这种代理工作方式，客户端发给服务器的包几乎不用修改发给代理，就可以获得几乎与服务器一样的返回。其收发包 过程如下 [客户端] -HTTP GET-> [代理] -HTTP GET-> [服务器] [客户端] <-200 OK [代理] <-200 OK [服务器] HTTPS流量，明文的代理连接
在这种工作方式中，客户端与代理之间建立的TCP连接仍然是明文的，也就是不经过SSL加密的。但是客户端发出的请求不是HTTP请求，而是 HTTPS请求。因为HTTPS请求是经过SSL加密的，所以做为代理来说，虽然客户端与其建立的TCP连接本身没有经过SSL加密，但是中间传输的数据 确是SSL加密的。于是代理就无法通过检查HTTPS请求的内容知道目的服务器是什么。所以客户端必须在发HTTPS请求之前用HTTP CONNECT请求告诉代理要连接的服务器是什么，然后等代理服务器左右手的TCP连接都握稳了，客户端就可以收发HTTPS流量了。代理在其中只是一个 简单的在两个TCP连接中做数据对拷，并不知道客户端与服务器在干什么。事实上，利用HTTP CONNECT，客户端与服务器之间除了可以交换HTTPS的流量，任何流量都是可以的。经过HTTP CONNECT之后，客户端与代理的TCP连接就“相当于”是与服务器之间建立的TCP连接。当然我们前面已经说过了，这种直连只是一个假象。其收发包过程如下： [客户端] -HTTP CONNECT a.b.c.d:port-> [代理] -TCP SYN-> [服务器] [客户端] <-200 OK- [代理] <-TCP SYN ACK- [服务器] # 这里的200 OK与下面的200 OK的含义不同 [客户端] -SSL CLIENT HELLO-> [代理] -SSL CLIENT HELLO-> [服务器] # SSL握手包1 [客户端] <-SSL SERVER HELLO- [代理] <-SSL SERVER HELLO/CERTIFICATE等- [服务器] # SSL握手包2 [客户端] -SSL CLIENT CERTIFICATE等-> [代理] -SSL CLIENT CERTIFICATE等-> [服务器] # SSL握手包3 [客户端] <-SSL SERVER FINISHED- [代理] <-SSL SERVER FINISHED- [服务器] # SSL握手包4 [客户端] -SSL加密的HTTP GET-> [代理] -SSL加密的HTTP GET-> [服务器] [客户端] <-SSL加密的200 OK- [代理] <-SSL加密的200 OK- [服务器]
因为CONNECT之后，这个左右手的TCP连接里跑什么流量，代理是完全不管的，所以这样也是可以的： [客户端] -HTTP CONNECT a.b.c.d:port-> [代理] -TCP SYN-> [服务器] [客户端] <-200 OK- [代理] <-TCP SYN ACK- [服务器] # 这里的200 OK与下面的200 OK的含义不同 [客户端] -any request-> [代理] -any request-> [服务器] [客户端] <-any response- [代理] <-any response- [服务器]
正因为CONNECT之后TCP连接可以用来跑任意的东西，当然也就可以用来再跑另外一个代理协议了，比如SOCKS代理。
只要SOCKS代理是运行在443这样HTTP CONNECT允许的端口，通过HTTP-CONNECT+SOCKS代理就可以在公司内网里访问HTTP之外的互联网内容了。 HTTP流量，SSL加密的代理连接
传统HTTP代理，客户端与代理之间是不经过加密的。因为GFW可以从明文的流量中知道你通过HTTP代理访问的目标服务器，所以可以从中切断连接。为了让HTTP代理协议继续承担翻墙的重任，人们发明一种新的方式。其拓扑结构如下 [客户端] <-TCP连接-> [Stunnel客户端模式] <-TCP over SSL连接-> [Stunnel服务器模式] <-TCP连接-> [代理] <-TCP连接-> [服务器]
虽然拓扑结构复杂了，但是概念其实是很简单的。因为客户端与代理都不直接支持SSL的TCP连接，所以通过Stunnel做一个转换，在客户端经过 Stunnel的客户端模式进行加密，然后在代理上有用Stunnel的服务器段模式进行解密。这样GFW夹在中间看到的是经过SSL加密的流量，无法进 行URL关键字过滤了。收发包的过程如下： [客户端] -HTTP GET-> [Stunnel客户端模式] -SSL加密的HTTP GET-> [Stunnel服务器模式] -HTTP GET-> [代理] -HTTP GET-> [服务器] [客户端] <-200 OK- [Stunnel客户端模式] <-SSL加密的200 OK- [Stunnel服务器模式] <-200 OK- [代理] <-200 OK- [服务器] HTTPS流量，SSL加密的代理连接
传统的HTTP代理走HTTPS流量的时候，HTTP GET的内容经过SSL加密的，GFW无法做URL关键字过滤。但是客户端与代理之间的HTTP CONNECT仍然是明文传输的。GFW仍然可以根据CONNECT的目标域名或者IP地址来判断是不是访问了GFW不允许访问的网站。所以即便客户端发 的是HTTPS请求，仍然有必要在客户端与代理之间进行SSL加密。拓扑结构与上面相同。收发包的过程如下： [客户端] -HTTP CONNECT-> [Stunnel客户端模式] -SSL加密的HTTP CONNECT-> [Stunnel服务器模式] -HTTP CONNECT-> [代理] -TCP SYN-> [服务器] [客户端] <-200 OK- [Stunnel客户端模式] -SSL加密的200 OK-> [Stunnel服务器模式] <-200 OK- [代理] <-TCP SYN ACK- [服务器] # 这里的200 OK与下面的200 OK的含义不同 [客户端] -SSL CLIENT HELLO-> [Stunnel客户端模式] -SSL加密的SSL CLIENT HELLO-> [Stunnel服务器模式] -SSL CLIENT HELLO-> [代理] -SSL CLIENT HELLO-> [服务器] # SSL握手包1 ... 以下略去。完成SSL握手之后，数据是在双层的SSL加密之下传输的 很明显，HTTP代理加上SSL传输的方式可以有效地对付GFW的关键字检查。但是蛋疼的地方是本来是客户端，代理与服务器之间三方的事情，现在变 成了五方会谈了。转手的次数越多，效率就越差。出错了，调试问题也越麻烦。除此之外，我们还额可以看到每个SSL连接建立需要四个包，两个来回。这个 SSL握手的成本不是一次性的，是附加在每个被代理的连接上的。考虑到很多HTTP请求都是短连接，内容也很少。所以每次多做一次SSL握手，额外负担相 比之下挺重的。 |
