HTTP的未来以及对SPDY的争论

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中文站投稿或者参与内容翻译工作，请邮件至[email protected]。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。