未来的web基础——SPDY <一>（转）
前端应用的许多优化都是围绕网络开展的。Yahoo的35条网站优化实践中第一条便是Minimize HTTP Requests。前端工程师们为这些优化做了许多努力与探索，比如CSS sprits，比如CDN combo。天河就经常做CSS sprits，这个虽然有自动化工具。不过尴尬的是，主要是半自动化工具，还是要做部分工作来保证的。于是搞个CSS sprits常常花上小半天时间（苦逼的活呀）。
最近看了些关于SPDY的文章，忽然觉得，如果类似SPDY这样的中间协议（TCP之上，HTTP的补充）被大量应用了，其实我们就不需要太刻意关注最小化HTTP请求数了（YY中…）。支持一个TCP连接中无限的并发HTTP请求，是最吸引我的一个SPDY特性了。
如今，大家写的web应用都是通过HTTP与TCP协议传输的。TCP协议工作在传输层，HTTP协议则工作在应用层。不幸的是，今天在web上传播的内容与10年前有着显著的区别，HTTP传输已经渐渐无法满足人们的需要了。
每个HTTP连接只请求一个资源（HTTP pipelining做了改善，不过大大增加了复杂度，并不流行）。浏览器只好通过建立多个连接来解决此问题（你应该刻意了解过各主流浏览器支持的并发连接数吧）。
HTTP只允许由客户端发起请求。纵使服务端知道客户端需要一个资源，它也没有相关机制来通知客户端。服务端只能等待客户端发送一个请求。
未压缩的请求及响应头。现在的应用普遍使用更多的cookie、客户端自定义扩展等，一个典型的请求头还是不小的。对于猫或者ADSL这种上行带宽非常低的连接来说，还是很有影响的。
冗余的头。HTTP头在同一个会话里是反复发送的。但是，头信息中的User-Agent，Host以及Accept*等固定信息是不需要重复发送的。
非强制的数据压缩。
这么多的HTTP缺点都是Google罗列的，是SPDY协议努力的方向。SPDY希望实现降低一半的页面加载时间（据实验结果看，已经接近这个目标了），同时避免增加部署的复杂度。SPDY的具体目标有：
允许多个并发HTTP请求共用一个TCP会话。
压缩HTTP头，舍弃不必要的头信息。
协议要易于实现并且高效。
强制使用SSL传输协议，以换取更好的安全性和对现有网络系统的兼容。虽然SSL也会带来一些延迟，但Google相信长远地看，未来的web离不开安全的网络连接。
允许服务端向客户端发起一个会话，以及向客户端推送数据。
简单说下SPDY的设计及特性。
如上图，SPDY在SSL之上增加了一个session层，用来支持在一个TCP连接里实现多路复用的交叉流。原有的HTTP GET及POST消息格式保持不变；不过，SPDY制定了一个新的用于编码及传输的帧格式。流是双向的，可以由客户端或服务端发起。
SPDY特性分为基本特性（默认开启）与高级特性（可选启用）两部分。都为降低网络延迟努力。
基本特性有：
多路复用流。SPDY实现了单TCP连接中无限制的并发流。由于请求在单个信道内是交叉的，TCP的效率会更高。
请求优先级。虽然可以并发请求，但网络总有可能堵塞，所以还是要给请求分下优先级。
压缩HTTP头，舍弃不必要的头信息。
高级特性有：
Server push。就是允许服务端发起通信。
Server hint。服务端可以提示客户端可以获取某某资源了。
好了，先介绍这么多。如果你和我一样，好奇SPDY怎么应用，可以在Chrome里打开个gmail啥的，然后打开这个链接满足下好奇心。
chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active
其实发现想细致了解里面各种名词，真不是一篇文章能介绍清楚的。天河也查了好久，稍详细的介绍跟实践待续哈。
