当前位置: 代码迷 >> Web前端 >> 将来的web基础――SPDY <一>(转)
  详细解决方案

将来的web基础――SPDY <一>(转)

热度:331   发布时间:2012-09-08 10:48:07.0
未来的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
其实发现想细致了解里面各种名词,真不是一篇文章能介绍清楚的。天河也查了好久,稍详细的介绍跟实践待续哈。