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过程的不同是:

经过了SSL加密,客户端与服务器直接处理了SSL的加解密而不是经过Stunnel转手

SSL除了用来加密其NPN(Next Protocol Negotiation)扩展还用来沟通协议,所以同样一个443端口可以同时用来支持传统的HTTPS和新的SPDY协议

同一个SSL加密连接可以同时用来做多个HTTP GET,因为SYN FRAME与SYN REPLY FRAME的对应关系是通过Stream Id来完成的。而一个SSL连接中可以同时有多个Stream。

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


相关内容

    暂无相关文章