SPDY
SPDY是Google家提出来的协议。其核心内容是用一个TCP连接,跑多个HTTP的STREAM。对于用SPDY协议跑HTTP代理来说,其 意义就在于之前是每个HTTP请求都要开连接关连接,用了SPDY之后,客户端与代理之间是保持长连接的,然后在这个连接里,代理访问不同的HTTP服务 器,就是不同的HTTP STREAM。而且,用SPDY协议虽然没有强制但是一般客户端与代理之间是SSL连接的,所以GFW也无法对连接的内容做关键字过滤。相比 Stunnel的方案,省去了每个连接额外的SSL过程,而且也省去了每个HTTP请求额外的TCP握手过程。所以从执行效率的角度来看,SPDY是非常 理想的。
以一个最简单的HTTP GET为例SPDY的交互过程是这样的: [客户端] -SSL CLIENT HELLLO-> [服务器] [客户端] <-SSL SERVER HELLO/CERTIFICATE/NPN (HTTP/1.1, SPDY/3, SPDY/2)等 [服务器] # 服务器通过SSL的NPN扩展告诉客户端我这支持HTTP 1.1也支持SPDY 2和3 [客户端] -SSL CLIENT CERTIFICATE/NPN(SPDY/3)等-> [服务器] # 客户端告诉服务器我选择SPDY3 [客户端] <-SSL SERVER FINISHED- [服务器] # SSL握手完成 [客户端] -SSL加密的SYN FRAME(HTTP GET)-> [服务器] # SYN FRAME是SPDY版的HTTP GET,意思是一样的 [客户端] <-SSL加密的SYN REPLY FRAME(200 OK)- [服务器] # SYN REPLAY FRAME是SPDY版的200 OK,意思是一样的
这里与最传统的HTTP GET过程的不同是:
但是直接支持SPDY协议的服务器并不多,大部分都是Google自家的服务器。所以寄期望于所有的服务器都运行SPDY协议,从而 GFW无法进行关键字检测是不现实,比寄期望与所有服务器都部署HTTPS还要不现实。单就反GFW关键字过滤来说,服务器支持HTTPS与SPDY并无区别。 HTTP流量,SPDY的代理连接
有了SPDY协议,客户端与代理之间就又多了一种选择,除了明文的不加密的传统的HTTP,和效率低下的Stunnel模式,还可以用Shrpx+Squid跑SPDY协议。其过程是这样的 [客户端] -SSL CLIENT HELLLO-> [代理] [客户端] <-SSL SERVER HELLO/CERTIFICATE/NPN (HTTP/1.1, SPDY/3, SPDY/2)等 [代理] [客户端] -SSL CLIENT CERTIFICATE/NPN(SPDY/3)等-> [代理] [客户端] <-SSL SERVER FINISHED- [代理] # 与代理建立好SSL连接,通过NPN选择了选择SPDY3协议 [客户端] -SSL加密的SYN FRAME(Stream1 HTTP GET)-> [代理] -HTTP GET-> [服务器1] [客户端] -SSL加密的SYN FRAME(Stream2 HTTP GET)-> [代理] -HTTP GET-> [服务器2] [客户端] <-SSL加密的SYN REPLY FRAME(Stream2 200 OK)- [代理] <-200 OK- [服务器2] [客户端] <-SSL加密的SYN REPLY FRAME(Stream1 200 OK)- [代理] <-200 OK- [服务器1]
可见利用SPDY协议,客户端与代理之间的数据传输就是SSL加密的,而且避免了每个HTTP请求都建立新的TCP连接,重新进行SSL握手。而代理与服务器因为都在墙外,所以HTTP明文交流并没有任何问题。 HTTPS流量,SPDY的代理连接
SPDY协议的SYN FRAME除了支持HTTP GET/POST这些之外,HTTP CONNECT也是可以的。除了需要包装成SPDY的各种FRAME之外,HTTP协议自身的语义其实都是一样的。其交互过程是这样的:
[客户端] -SSL CLIENT HELLLO-> [代理] [客户端] <-SSL SERVER HELLO/CERTIFICATE/NPN (HTTP/1.1, SPDY/3, SPDY/2)等 [代理] [客户端] -SSL CLIENT CERTIFICATE/NPN(SPDY/3)等-> [代理] [客户端] <-SSL SERVER FINISHED- [代理] # 与代理建立好SSL连接,通过NPN选择了选择SPDY3协议 [客户端] -SSL加密的SYN FRAME(HTTP CONNECT)-> [代理] -TCP SYN-> [服务器] [客户端] <-SSL加密的SYN REPLY FRAME(200 OK)- [代理] <-TCP SYN ACK- [服务器] [客户端] -SSL加密的DATA FRAME(HTTP GET)-> [代理] -HTTP GET-> [服务器] [客户端] <-SSL加密的DATA FRAME(200 OK)- [代理] -200 OK-> [服务器]
完成了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 |