今天在看 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 最近的一篇文章已经直呼 SPDY 为「a replacement for 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 服务器。现在已经有 Java、Apache module、Python、Ruby、node.js 等各种实现。
最后,如果你正在使用 Chrome 浏览器,并且访问 Google 的网站,那你已经开始使用 SPDY 了,输入 chrome://net-internals/#spdy 还可以了解更加详细的信息。