HTTP 的未来以及对 SPDY 的争论

  • Abel Avram
  • 马立铭

2012 年 9 月 13 日

话题:DevOps

IETF 讨论了 HTTP 的未来,下一个版本将要以 SPDY 作为起点。尽管存在争议——微软声称 SPDY 与打开了所有优化的 HTTP/1.1 相差无几,而 SPDY 的发明者则表示,微软的测试在一个真实的场景中肯定了 SPDY 的优势。

8 月,IETF HTTPBIS 工作组在温哥华讨论了 HTTP/1.1 和 HTTP/2.0 的未来。此次会议围绕拟议的新纲领(charter),关于这两个版本的协议确立未来应采取的行动:

HTTP/1.1

  • RFC2616,即定义了 HTTP/1.1 协议的文档,将被更新以澄清误解,消除对互操作性有负面影响的各种歧义
  • 删除或弃用未被广泛使用的功能
  • 增加实施意见
  • 文档安全性——身份验证、Cookies 及 TLS

正如声明中所说的那样,不会有 HTTP/1.2,这些变化将成为 HTTP/1.1 的一部分。

HTTP/2.0

做出了一些最重要的决定:

  • HTTP 的新版本将保留 HTTP/1.1 的语义,以便能够将 HTTP/2.0 请求转换到 HTTP/1.1,反之亦然
  • HTTP/2.0 将有一个新的尚未定义的语法
  • HTTP/2.0 将使用SPDY 草案作为起点
  • HTTP/2.0 将能够使用 TCP 之外的其它传输协议
  • HTTP/2.0 应显著快于 HTTP/1.1
  • HTTP/2.0 应消耗更少的网络资源,如 Sockets

该工作组将在今年 9 月提出 HTTP/2.0 的一个草案,预计到 2014 年 11 月将完成标准的制定。

关于 SPDY, HTTPBIS 工作组主席 Mark Nottingham写道

重要的是要明白, SPDY 并没有被采纳为 HTTP/2.0,而是作为本次讨论的出发点,避免了浪费精力从头开始。

此外,微软HTTP Speed+Mobility的作者 Adalberto Foresti 在文章中写道:

工作组一致认为,作为 HTTP/2.0 规范进程中的一部分,七个关键领域需要深入的、以数据为驱动的讨论,所制定的标准不与任何现存的提案(SPDY, HTTP Speed+Mobility 以及 Network-Friendly HTTP Upgrade)向下兼容。

我们向 Nottingham 询问如果 HTTP/2.0 不向下兼容 SPDY,那部署了 SPDY 的系统会怎么样,我们收到的回复如下:

我想每个人都希望它们消失,所有推崇 SPDY 的人都清楚地指出它是一个实验性的协议。

对于目前 SPDY 的命运,SPDY 发明者兼SPDY 协议的编写者 Mike Belshe,在接受 InfoQ 采访时表示:

假设 HTTP/2.0 与 SPDY 一样快,甚至比 SPDY 更快,那么 Chrome 和 Firefox 将在一定的宽限期之后放弃 SPDY。但由于网站仍然实现了 HTTP/1.1,所以它们仍然会正常工作,哪怕 SPDY 当前的形式不复存在了。

然后,如果网站想提升速度,则需要升级到 HTTP/2.0。这一切将不会中断向用户的服务,但这对网站来说是一种迁移。

Foresti 也淡化了 SPDY 的重要性,他说在对 SPDY 的测试中显示,其与开启了所有优化时的 HTTP/1.1 相差无几:

为对比 SPDY 与 HTTP/1.1 的性能,我们利用受控测试研究比较了几个公共网站的下载时间。本次测试运行于大众软件之上,并使用了大部分的默认配置,同时对 HTTP/1.1 运用了目前所有可用的优化。可以在http://research.microsoft.com/apps/pubs/?id=170059找到一份测试结果的初步报告。结果反映的其它数据(http://www.guypo.com/technical/not-as-spdy-as-you-thought)表明 SPDY 的性能参差不齐。

我们的研究结果表明,当 HTTP/1.1 应用了所有已知的优化时,SPDY 和 HTTP/1.1 有着几乎相同的性能。SPDY 无法持续显著改善性能。我们将继续测试,同时也欢迎其他机构公布其结果,以便使 HTTP/2.0 可以选择最好的改进,提供比 HTTP/1.1 更好的性能和可扩展性。

我们询问了 Belshe 对 Foresti 看法的意见:

微软的研究结果证实了 SPDY 的速度优势。我也很高兴看到微软对协议的积极测试!

微软的测试是合理的,他们想知道 SPDY 是否比 pipelining 和 content-minification 更好。最后他们得出结论是:“明智地使用被广泛认知的现有优化,如 pipelining 和 content-minification,可以使 HTTP 的性能接近 SPDY”。

我基本上同意这一点,但他们忘了提及该“解决方案”在当今互联网环境中不具备可部署性。

最大的问题是 SPDY 与 pipelining 的测试比较。pipelining 在 12 年前被标准化为 HTTP/1.1 的一部分。但它从来没有被部署于主要的浏览器中。为什么呢?因为它根本用不了——不迫使用户随即挂起和延迟的话就无法进行部署。去年年底,Firefox 团队重新努力尝试使其工作,但目前已经把工作转向 SPDY 了。pipelining 有太多的问题可以列举,也可以咨询 Firefox 团队。

其次,所构建的测试方式没有利用多路复用(multiplexing)。在 pipelining 之上进行多路复用的一个显著优点是,当 pipelining 在服务器处理每个请求的过程中会“阻塞”,而复用 pipelining 则不会。但是在这个测试中,他们缓存了所有文件并以静态的形式重放,造成了零延迟的服务器处理时间。这种类型的实验室测试在许多情况下没什么问题,但是对于 SPDY 和 pipelining 比较,这是不允许的。如果没有服务器的处理时间,没有数据包丢失,也没有排队延迟,则多路复用的需求大幅减少。在微软的测试条件下,我完全有理由相信,一个良好的 pipelining 实现其速度会比 SPDY 快。 总体而言,这只是一篇学术论文并与现实世界的相关性比较小。它确认了 SPDY 比 HTTP 快,也确认了 SSL 是昂贵的。但是 pipelining 是一个无望成功的东西。如果它是可部署的,则它早就运行在 Chrome,Firefox 和 IE 上了。

Firefox 实现了 pipelining,但是它在默认情况下是关闭的,正如 Mozilla 的这个Bug错误信息所示,至少自 2004 年以来就在讨论这个问题了。根据这个 Bug,有些人已经运行开启了 pipelining 的 Firefox 许多年,而没有遇到任何问题,而其他人则遇到了严重的网站崩溃情况。这就是为什么 pipelining 没有在默认情况下被打开。MozillaZine 上的这篇文章,Network.http.pipelining,包含更多细节信息。

最近,已经有一些人在 Chrome 中尝试去测试 HTTP pipelining,根据Chromium Issue,有 10%的 Chrome 开发版在默认情况下开启了 pipelining,但这个问题现在已被关闭。HTTP pipelining 在官方版本的 Chrome 21 中,默认仍处于关闭状态。

综上所述,虽然 HTTP/2.0 可能从 SPDY 起步,但是其最终版本仍然不得而知。虽然目前 SPDY 对 non-pipelined HTTP/1.1 在速度上有所提升,但当标准变得稳定并且服务器能从中受益时,这些服务器还是会升级到 HTTP/2.0 的。

早前相关的文章:SPDY versus WebSockets? 以及HTTPbis Working Group Start To Consider HTTP/2.0。

原文链接The Future of HTTP and the Controversy over SPDY


感谢丁雪丰对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

DevOps