截至 2009 年,HTTP/1.1 面世已经超过 10 年了,并且无可争议的是,它依然是互联网上最受欢迎的应用层协议。这是因为它不仅用来浏览网页,还是很多其他东西的参考协议。它上手简单、实现容易,并被广大的开发者和运维工程师所理解,因此积累了很多优势,成为了无可替代的协议。一些人甚至开始说,HTTP 形成了互联网架构经典沙漏模型的“第二腰”。

尽管如此,HTTP 还是与时代脱节了。Web 如今已经发生了翻天覆地的变化,它的需求给 HTTP 协议造成了巨大的压力。现在,加载一个网页通常包含好几百个请求,总体开销在拖慢 Web。这就催生了一个新的行业,专治 Web 性能问题——Web 性能优化。

HTTP 社区很清楚这些问题,但是并没有授权大家修复它们。过往的努力,如 HTTP-NG,已经失败了。没有来自 Web 浏览器和服务器的强力支持的提案就动手的做法,看起来并不妙。这反映在 HTTP 工作组当时的纲领中,它说:

工作组不得制定 HTTP 的新版本,也不得给 HTTP 添加新功能。

相反,我们的使命是阐述清楚 HTTP 的规范,并且(至少对我而言)重建一个 HTTP 实现者的强大社区。

也就是说,还有人想实现 HTTP 语义的更高效表达,像 Roy Fielding 的 WAKA 提案 1(很不幸,从未完成)和基于 SCTP2 的 HTTP(主要在特拉华大学)。

1https://tools.ietf.org/agenda/83/slides/slides-83-httpbis-5.pdf

2https://tools.ietf.org/html/draft-natarajan-http-over-sctp-00

去 Google 做了一次有关上面这些话题的分享后,我收到了 Mike Belshe 留给我的一张便条,问我们是否可以碰个面。我们在 Mountain View 的 Castro 大街上吃了晚饭,他说 Google 正要发布 SPDY,替代 HTTP 协议。

SPDY 之所以不同,是因为 Mike 为 Chrome 浏览器工作,他和为 GFE(Google 的前端 Web 服务器)工作的 Roberto Peon 是搭档。他们控制着连接的两端,因而可以快速迭代,并且他们可以在 Google 的超大流量上测试新的协议,因此能够在大规模场景下验证协议的设计。

整个晚饭时间我都感到发自内心的高兴。他们在解决实际问题,并且已经测试过代码和数据。这些正是互联网工程任务组(IETF)所推崇的。

然而,直到 2012 年,SPDY 才开始流行开来。Firefox 实现了该协议,然后是 Nginx 服务器,接着是 Akamai。Netcraft 报告说,支持 SPDY 协议的网站数据激增。

显然,新版本的 HTTP 协议引起了广泛的关注。

2012 年 10 月,HTTP 工作组被授权发布 HTTP/2,使用 SPDY 作为起点。之后的两年间,来自各个公司和开源项目的代表在各地碰面讨论这个新的协议,解决其中的问题,并确保彼此的实现能互相兼容。

在这个过程中,我们有过意见不一致的时候,甚至也有过激烈的争辩。但是,每个人所表现出的专业能力、合作意愿和强烈信念仍然让我印象深刻。这真是一支了不起的、让人愿意共事的团队。

举个例子,有时候大家一致认为,取得进展比为某人的观点争论一整天更重要,所以我们掷硬币来做决定。有些人可能觉得这很疯狂,但我觉得这反映出了成熟的态度和深邃的洞察力。

2014 年 12 月,在规定的截止日期 16 天后(这对标准制定的工作来讲,已经很早了),我们向国际互联网工程指导委员会(IESG)提交了 HTTP/2,申请批准。

大家都说,实践才能出真知;对互联网工程任务组来说,可运行的代码才能说明一切。我们很快就有了拿得出手的东西,并得到了所有主流浏览器、多数 Web 服务器、CDN 和其他工具的支持。

HTTP/2 并不是完美的,但完美向来也不是我们的目标。我们的现实目标是化乱为治,并逐渐提升 Web 性能;远景目标则是为确保可以发布新版本的 HTTP 做好准备,这样 Web 才不会受制于一份过时的协议。

从这个角度来看,我们已经成功了。当然,我们要做的还有很多。

——Mark Nottingham

Mark Nottingham 在 HTTP 工作组已经 10 多年了。对本书来说尤其有意义的是,当 HTTP/2 完成的时候,他担任工作组主席。他现在是工作组负责 QUIC 的主席,也曾是 Akamai Foundry 团队的一员。

目录