HTTP代理与SPDY协议

HTTP代理是最经典最常见的代理协议。其用途非常广泛,普遍见于公司内网环境,一般员工都需要给浏览器配置一个HTTP代理才能访问互联网。起初,HTTP代理也用来翻越“功夫网”,但是因为“功夫网”不断发展,普通的HTTP代理早已无效了。但是,基于仍然有不少人使用明文的HTTP代理协议结合stunnel之类的软件进行加密翻墙,有时这种代理又被称为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这些。对于这种代理工作方式,客户端发给服务器的包几乎不用修改发给代理,就可以获得几乎与服务器一样的返回。其收发包过程如下

HTTPS流量,明文的代理连接

在这种工作方式中,客户端与代理之间建立的TCP连接仍然是明文的,也就是不经过SSL加密的。但是客户端发出的请求不是HTTP请求,而是HTTPS请求。因为HTTPS请求是经过SSL加密的,所以做为代理来说,虽然客户端与其建立的TCP连接本身没有经过SSL加密,但是中间传输的数据确是SSL加密的。于是代理就无法通过检查HTTPS请求的内容知道目的服务器是什么。

所以客户端必须在发HTTPS请求之前用HTTP CONNECT请求告诉代理要连接的服务器是什么,然后等代理服务器左右手的TCP连接都握稳了,客户端就可以收发HTTPS流量了。代理在其中只是一个简单的在两个TCP连接中做数据对拷,并不知道客户端与服务器在干什么。事实上,利用HTTP CONNECT,客户端与服务器之间除了可以交换HTTPS的流量,任何流量都是可以的。经过HTTP CONNECT之后,客户端与代理的TCP连接就“相当于”是与服务器之间建立的TCP连接。当然我们前面已经说过了,这种直连只是一个假象。其收发包过程如下:

因为CONNECT之后,这个左右手的TCP连接里跑什么流量,代理是完全不管的,所以这样也是可以的:

正因为CONNECT之后TCP连接可以用来跑任意的东西,当然也就可以用来再跑另外一个代理协议了,比如SOCKS代理。

只要SOCKS代理是运行在443这样HTTP CONNECT允许的端口,通过HTTP-CONNECT+SOCKS代理就可以在公司内网里访问HTTP之外的互联网内容了。

HTTP流量,SSL加密的代理连接

传统HTTP代理,客户端与代理之间是不经过加密的。因为GFW可以从明文的流量中知道你通过HTTP代理访问的目标服务器,所以可以从中切断连接。为了让HTTP代理协议继续承担翻墙的重任,人们发明一种新的方式。其拓扑结构如下

虽然拓扑结构复杂了,但是概念其实是很简单的。因为客户端与代理都不直接支持SSL的TCP连接,所以通过Stunnel做一个转换,在客户端经过Stunnel的客户端模式进行加密,然后在代理上有用Stunnel的服务器段模式进行解密。这样GFW夹在中间看到的是经过SSL加密的流量,无法进行URL关键字过滤了。收发包的过程如下:

HTTPS流量,SSL加密的代理连接

传统的HTTP代理走HTTPS流量的时候,HTTP GET的内容经过SSL加密的,GFW无法做URL关键字过滤。但是客户端与代理之间的HTTP CONNECT仍然是明文传输的。GFW仍然可以根据CONNECT的目标域名或者IP地址来判断是不是访问了GFW不允许访问的网站。所以即便客户端发的是HTTPS请求,仍然有必要在客户端与代理之间进行SSL加密。拓扑结构与上面相同。收发包的过程如下:

很明显,HTTP代理加上SSL传输的方式可以有效地对付GFW的关键字检查。但是蛋疼的地方是本来是客户端,代理与服务器之间三方的事情,现在变成了五方会谈了。转手的次数越多,效率就越差。出错了,调试问题也越麻烦。除此之外,我们还额可以看到每个SSL连接建立需要四个包,两个来回。这个SSL握手的成本不是一次性的,是附加在每个被代理的连接上的。考虑到很多HTTP请求都是短连接,内容也很少。所以每次多做一次SSL握手,额外负担相比之下挺重的。

SPDY

SPDY是Google家提出来的协议。其核心内容是用一个TCP连接,跑多个HTTP的STREAM。对于用SPDY协议跑HTTP代理来说,其意义就在于之前是每个HTTP请求都要开连接关连接,用了SPDY之后,客户端与代理之间是保持长连接的,然后在这个连接里,代理访问不同的HTTP服务器,就是不同的HTTP STREAM。而且,用SPDY协议虽然没有强制但是一般客户端与代理之间是SSL连接的,所以GFW也无法对连接的内容做关键字过滤。相比Stunnel的方案,省去了每个连接额外的SSL过程,而且也省去了每个HTTP请求额外的TCP握手过程。所以从执行效率的角度来看,SPDY是非常理想的。

以一个最简单的HTTP GET为例SPDY的交互过程是这样的:

这里与最传统的HTTP GET过程的不同是:

  1. 经过了SSL加密,客户端与服务器直接处理了SSL的加解密而不是经过Stunnel转手
  2. SSL除了用来加密其NPN(Next Protocol Negotiation)扩展还用来沟通协议,所以同样一个443端口可以同时用来支持传统的HTTPS和新的SPDY协议
  3. 同一个SSL加密连接可以同时用来做多个HTTP GET,因为SYN FRAME与SYN REPLY FRAME的对应关系是通过Stream Id来完成的。而一个SSL连接中可以同时有多个Stream。

但是直接支持SPDY协议的服务器并不多,大部分都是Google自家的服务器。所以寄期望于所有的服务器都运行SPDY协议,从而GFW无法进行关键字检测是不现实,比寄期望与所有服务器都部署HTTPS还要不现实。单就反GFW关键字过滤来说,服务器支持HTTPS与SPDY并无区别。

HTTP流量,SPDY的代理连接

有了SPDY协议,客户端与代理之间就又多了一种选择,除了明文的不加密的传统的HTTP,和效率低下的Stunnel模式,还可以用Shrpx+Squid跑SPDY协议。其过程是这样的

可见利用SPDY协议,客户端与代理之间的数据传输就是SSL加密的,而且避免了每个HTTP请求都建立新的TCP连接,重新进行SSL握手。而代理与服务器因为都在墙外,所以HTTP明文交流并没有任何问题。

HTTPS流量,SPDY的代理连接

SPDY协议的SYN FRAME除了支持HTTP GET/POST这些之外,HTTP CONNECT也是可以的。除了需要包装成SPDY的各种FRAME之外,HTTP协议自身的语义其实都是一样的。其交互过程是这样的:

完成了HTTP CONNECT之后,对应的SPDY STREAM就是自由的了。无论发送什么样的DATA FRAME(SPDY的FRAME的一种,传输二进制数据流)给代理,代理就直接转给服务器。服务器无论返回什么样的数据,代理也以DATA FRAME的形式转给客户端。这个SPDY STREAM和一个TCP连接就一样了。除了可以用来发HTTP GET之外,跑什么样的协议都行了,代理反正也不管里面是什么,它只管转发DATA FRAME。

PAC文件

HTTP代理的一个流行用法是写一个PAC文件,描述什么样的时候走什么样的代理。经典的PAC文件只有两种返回值,PROXY和DIRECT。如果返回的是PROXY则走代理,DIRECT则是直连。这里的走代理当然是最传统的HTTP代理方式,也就是浏览器与代理之间是明文的连接,不经过SSL加密的。具体浏览器是用HTTP GET/POST还是CONNECT,取决于浏览器要访问的目标服务器是HTTP还是HTTPS的,和PAC文件无关。

Chrome在PAC的PROXY与DIRECT之外添加了第三种返回值,也就是HTTPS。这种返回值的含义与PROXY是一样,都是走代理。区别在于PROXY是明文的连接,HTTPS是SSL加密的连接。所以HTTPS这个返回值的歧义在于让人以为它只用来代理HTTPS流量。因为SPDY是基于SSL的NPN扩展的,所以当浏览器与代理进行SSL握手的时候,可以选择是用HTTP/1.1协议还是SPDY/2还是SPDY/3。于是HTTPS这个PAC返回值,还可以用来支持SPDY,前提当然是代理在NPN里说它支持SPDY,而且浏览器也知道SSL的NPN扩展,而且支持SPDY协议。

另外一个PAC的扩展是苹果给iOS的PAC文件添加的SOCKS返回值。利用这个返回值可以给iPhone配置SOCKS的全局代理。但是这个与本文讨论的HTTP代理就无关了。

总结

可见HTTP代理协议自身来说,就两种:HTTP GET/POST和HTTP CONNECT。一种用来代理HTTP的流量,另外一种用来代理HTTPS的流量。HTTP CONNECT除了可以用来走HTTPS之外,因为代理并不去解析其内容,所以事实上是一个通用的代理隧道。

另外一个维度是客户端与代理之间是一个什么样的连接:不加密的连接,SSL加密的连接,SSL加密同时运行SPDY协议的连接。

所以工作模式共有2*3=6种。

引申阅读: Google官方也给了一些SPDY做代理的收发包示意例子 http://www.chromium.org/spdy/spdy-proxy-examples

给fqrouter做一个广告。fqrouter支持HTTP代理,包括用SSL连接的HTTP代理和SPDY。

1 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部