HTTP的未来以及对SPDY的争论

jopen 12年前

　　原文链接：The Future of HTTP and the Controversy over 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。

来自: InfoQ