SPDY简介

今天在看CTF write-up时发现 有人提到 SPDY这样一个东西, 貌似跟Chrome项目有关, 于是在Geek原始冲动的驱使下了解了一下.

首先SPDY是一个应用层协议, 它被创造出来的唯一目的就是让Web更快、更快，还是更快. Google这家公司似乎很喜欢 “快” 这个东西, Chrome从诞生到现在每次几乎必定宣传自己有多么得快, 搞得大家已经产生了某种心理暗示. SPDY诞生于2009年, 其实这是对外公开发布的时间, 开始研究的时间应该更早. 众所周知, 如今的Web是通过HTTP协议和TCP协议进行传输, 但种种因素导致HTTP传输变得很慢:

• 每一个TCP连接一次只能发一个HTTP请求, 这个估计是HTTP协议的最大弊端. 想象一下如今的网站已经包含大量的图片、CSS、JS需要加载, 如果一个请求一个请求地发, 那肯定会慢死, 所以浏览器通常都是通过建立多个连接来回避这个问题, 但毕竟治标不治本.
  
• 只能由客户端主动发起HTTP请求, 即时有时服务器知道还需要回复其它资源, 它也只能等客户端先发起再回复. 服务器真可怜, 太被动了.
  
• HTTP头没有压缩, 而且HTTP头也有一些重复信息, 比如User-Agent就没有必要每次都发来发去, 太浪费带宽了.
  
• 数据压缩是可选的, Google认为必须强制要求.
  

既然HTTP有这么多缺点, 那应该不止Google自己想要解决, 其实是有的, 本着不重复造轮子的原则Google列举了现有的一些改进方案:

• HTTP pipelining: 以流水线的形式传输请求和数据, 这里吐槽一下, 以前在公司时Facebook的某牛来介绍时谈到了他们开发的BigPipe, 思想也是流水线, 同样也是为了优化Web性能, 不知道他们是不是借鉴了HTTP pipelining, :)
  
• SCTP: 用于替代TCP的传输层协议, 提供了multiplexed streams (多路复用流) 和stream-aware congestion control (流感知拥塞控制)
  
• SST: 同样用于替代TCP协议 (TCP同学真是众矢之的…), 也可以运行在UDP协议之上.
  
• MUX 和 SMUX: 运行在传输层和应用层之间的中间协议, 同样提供了复用流.
  

但是Google同学觉得以上这些都还不够, 它要追求更大程度的性能提升. 考虑到TCP现在应用还很广泛, 想替代也不是一天两天的事情, 但HTTP就不一样了, 它是应用层的! 所以说有自家的浏览器就是好办, 发明个应用层协议马上就可以上线. SPDY在刚出来的时候Google还在说这并不是用来替代HTTP协议的, 它只是一个中间协议, 但看看 最新的协议文档 里面已经将SPDY分为了两层, 其中一层被描述为HTTP-like, 大有取代HTTP的意图. 可以想到Google已经将提议提交给IETF, 也许未来的某一天我们就不再使用HTTP协议了. SPDY主要有以下一些特性:

• multiplexed streams, 一个TCP连接将支持无限的并发HTTP请求
  
• 请求优先级, 因为现在支持并发请求, 就必须得为每一个请求设置一定的优先级
  
• 压缩HTTP头, 去掉多余的头信息
  
• 全部请求都是通过SSL加密, Google认为安全网络连接必定是未来的发展方向, 即使加密会微微增加一些传输时间
  
• Web服务器将能够主动发起通信, 也就是server push
  
• 还有一个类似的叫server hint, 不同于server push的是它仅仅向客户端发送一个suggest, 提示客户端需要发送一个HTTP请求
  

这些改进到底能有多大提升? Google给出的数据是39%~55%, 在丢包严重或高延迟环境下, SPDY变现更加出色.

要支持SPDY, 除了客户端必须支持外, 还要有相应的Web服务器. 现在已经有 Python、Java、Apache moudle、Ruby 等各种实现.

最后, 如果你正在使用Chrome浏览器, 并且访问Google的网站, 那你已经开始使用SPDY了, 输入 chrome://net-internals/#spdy 还可以了解更加详细的信息.