HTTP代理与SPDY协议(1)(2)

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握手，额外负担相比之下挺重的。