Google正制订一项新协议，旨在替换掉HTTP

近日Google提出了SPDY——运行在SSL上的一个应用层协议，该协议旨在替换掉HTTP，而后者被认为会产生延迟。Google已经使用Web服务器与增强的Chrome浏览器开发了一个原型，结果是页面加载速度比以前快了2倍。

前一阵Google发出的倡议“让Web变得更快”旨在提高Internet的速度。该倡议涵盖了几个领域，从构建更快的Web服务器到更快的浏览器。例如，Page Speed就是个用来提高网页下载速度的工具。Google在开源大量工具的同时又发布了相关的教程以帮助全世界的开发者加快其Web站点的速度。

然而Google并没有裹足不前，他们开发了一个名为SPDY（发音为SPeeDY）的新的应用协议，一旦成功并得到广泛应用的话，SPDY就会替换掉HTTP并彻底颠覆整个Internet。SPDY白皮书说要向协议栈下面渗透并替换掉传输层协议（TCP），但Google也认识到这样的话部署起来会相当困难，因此他们打算对应用层协议HTTP进行改进。

SPDY白皮书提到了HTTP协议中的很多限制，尤其是页面传输时的延迟：

• 一个请求一个连接。由于HTTP一次只能获取一个资源（HTTP管道很有用，但也只是强制形成一个FIFO队列），因此500毫秒的服务器端延迟导致无法重用TCP通道来处理其他请求，而浏览器则通过发送多个连接来解决这一问题。自从去年以来，浏览器已经将每个域的连接由2个调整为了6个。
• 只有客户端才能发送请求。在HTTP中，只有客户端才可以发送请求。即便服务器端知道客户端需要某个资源，那它也没有办法通知客户端而只能等待其发出对该资源的请求。
• 未压缩的请求与响应头。如今的请求头的大小差别很大，从200 bytes到2KB的都有。随着应用越来越多地使用cookie和user agents扩展特性，700-800 bytes的头大小已经变得很常见了。对于modem或是ADSL连接来说，上行带宽都很低，这种延迟就变得很可观了。降低头中的数据可以改进发送请求的序列化延迟。
• 冗余的头。此外，有几个头会跨越请求在同一个通道上重复发送。像User-Agent、Host和Accept*这样的头基本都是不变的，没必要重复发送。
• 可选的数据压缩。HTTP对数据进行可选的压缩编码。内容总是应该以压缩格式发送。

SPDY的一个目标就让页面加载时间降低50%，同时将浏览速度提升一倍。对一个用户来说，几百毫秒不算什么，但每一毫秒都会对未来高度互联的Web应用产生积极的影响。当前Web上的内容并不会受到该协议的影响，只有Web服务器和客户端需要增强以充分利用该协议。

Google究竟想用SPDY做什么呢？

• 在单个TCP会话上执行多个并发的HTTP请求。
• 通过压缩头以及减少不必要的头来降低当前HTTP所占据的带宽。
• 定义一个易于实现且提升服务器效率的协议。我们希望通过砍掉一些边缘情况来降低HTTP的复杂度并定义易于解析的消息格式。
• 将SSL作为底层传输协议以达到更好的安全性且兼容于现有的网络基础设施。尽管SSL引入了延迟，但我们相信从长远来看，Web还是要依赖于安全的网络连接的。此外，要想保证跨越现有代理的通信不被破坏，SSL也是必须的。
• 让服务器可以主动与客户端通信并向客户端发送数据。

为了达成这些目标，Google在SSL之上增加了一个会话层来实现SPDY，这考虑到了“单个TCP连接之上会有多个并发、交错的流”。HTTP GET和POST消息格式保持不变，但SPDY提出了一个新的“帧格式用于在线路上编码和传输数据”。流是双向的，客户端与服务器端都能开启流。

到目前为止，Google构建了一个既能处理HTTP协议，也能处理SPDY协议的内存服务器，代码将在不久后开源。还有一个修改的Chrome版本（内部的暂定名为flip，也是开源的）运行在HTTP和SPDY之上。他们还开发了一套测试工具集来保证使用SPDY后页面仍能正确下载。这些工具也将于不久之后发布。

原型表明目前的结果还是很不错的：

我们通过模拟的家庭网络连接下载了百强网站的25个，只有1%的包丢失。每个站点都被下载了10次并计算平均的页面加载时间，然后计算所有站点的平均时间。结果表明普通TCP（没有SSL）上的页面加载时间要比HTTP提升了27% - 60%，而SSL要提升39% - 55%。

纵然提出了最好的协议，但显然Google无法凭借一己之力取得成功，还需要依靠社区的推动与努力来创建一个全新的应用层协议。其他公司对此有何反应呢，让我们拭目以待。

参考资源：SPDY协议草案规范，可以使用SPDY的Chrome

查看英文原文：Google Works on a Protocol Intended to Replace HTTP