上篇文章主要介绍互联网协议标准化过程中的重要意义和流程，接下来我会讲到HTTP/3的出现过程。

Cloudflare的运行代码

Cloudflare是一家美国的跨国科技企业，总部位于旧金山，在英国伦敦亦设有办事处。Cloudflare以向客户提供网站安全管理、性能优化及相关的技术支持为主要业务。通过基于反向代理的内容分发网络(CDN, Content Delivery Network)、任播(Anycast)技术 、基于nginx+lua架构的Web应用防火墙(WAF, Web Application Firewall) 及分布式域名解析服务(Distributed Domain Name Server)等技术，Cloudflare可以帮助受保护站点抵御包括分布式拒绝服务攻击(DDoS, Distributed Denial of Service)在内的大多数网络攻击，确保该网站长期在线，同时提升网站的性能、访问速度以改善访客体验，这也是Cloudflare成为新协议和不断发展的协议的早期采用者的原因，比如HTTP/2，他们还测试了一些实验性或尚未完成的特性，如TLS 1.3和SPDY。Cloudflare提供的安全服务是帮助网站阻止来自网络的黑客攻击、垃圾邮件等，并提升网页的浏览速度，这和一般的安全软件往往会影响网页的运行速度大相径庭。目前Cloudflare在全球拥有152个数据中心 ，如果用户使用了其服务，那么网络流量将通过Cloudflare的全球网络智能路由。Cloudflare会自动优化用户的网页交付，以期达到最快的页面加载时间以及最佳性能。Cloudflare提供包括CDN、优化工具、安全、分析以及应用等服务。

在IETF标准化过程中，将这些正在运行的代码部署在各种不同的真实网络上，可以帮助我们了解协议在实践中的运作情况。我们将现有的专业知识与实验信息结合起来，以帮助改进正在运行的代码。

对新的协议进行不断地测试和应用只是标准制定过程中的部分要求，另外还要知道标准什么时候该修改，什么时候该把旧的标准完全替代。有时这与面向安全的协议有关。例如，由于POODLE漏洞，Cloudflare默认禁用SSLv3。在其他情况下，落后协议会被技术更先进的协议取代，比如Cloudflare不赞成使用SPDY而赞成支持HTTP/2。

在安全Web时间轴上，相关协议的引入和废弃用橙色线条表示。垂直虚线有助于将Cloudflare事件与相关IETF文档关联起来。例如，Cloudflare在2016年9月引入了TLS 1.3支持，而最终文档RFC 8446 则是与两年后的2018年8月发布。

HTTPbis重构协议的过程

HTTP/1.1是一个非常成功的协议，时间表显示1999年后，IETF没有对此协议进行太多修改。然而，经过多年的追踪还是发现了RFC 2616的潜在问题，该问题会导致一些互操作性问题。此外，其他RFC如2817和2818对该协议进行了扩展，2007年IETF决定启动一个新的修改工作来改进HTTP协议规范。

简言之，HTTPbis决定重构RFC 2616，并修改同时发布的其他规范。决定把文件分成几部分。HTTPbis决定将勘误文档分成几部分进行修复，这也是它在2007年12月发布了6个I-D的原因:

· draft-ietf-httpbis-p1-messaging

· draft-ietf-httpbis-p2-semantics

· draft-ietf-httpbis-p4-conditional

· draft-ietf-httpbis-p5-range

· draft-ietf-httpbis-p6-cache

· draft-ietf-httpbis-p7-auth

该图显示了在最终标准协议发布之前，这项工作是如何在长达7年的起草过程中慢慢发展迭代的，可以看出期间共发布了27个草案版本。2014年6月，所谓的RFC 723x系列发布(x范围从0到5)，HTTPbis主席用“RFC2616已死”来庆祝这一成就。

HTTP/3是如何出现的?

当IETF忙着研究RFC 723x系列标准时，互联网世界的发展也经历了快速的迭代变化，就有的HTTP协议必须通过增强、扩展才能适应新的形势。俗话说，企业是市场最敏感的回应者，谷歌很早就开始用一种叫SPDY的东西。SPDY（读作“SPeeDY”）是Google开发的基于TCP的应用层协议，用以最小化网络延迟，提升网络速度，优化用户的网络使用体验。SPDY并不是一种用于替代HTTP的协议，而是对HTTP协议的增强。新协议的功能包括数据流的多路复用、请求优先级以及HTTP标头压缩。谷歌表示，引入SPDY协议后，在实验室测试中页面加载速度比原先快64%。SPDY协议的主要作用是提高web浏览的性能，而这也是HTTP的目标。2009年底SPDY v1发布，2010年SPDY v2也发布了。

互联网工程任务组（IETF）对谷歌提出的SPDY协议进行了标准化，于2015年5推出了类似于SPDY协议的 HTTP 2.0 协议标准（简称HTTP/2）。谷歌因此宣布放弃对SPDY协议的支持，转而支持HTTP/2。谷歌称，计划于 2016 年初在 Chrome 中移除 SPDY，并将为Chrome 40 添加 HTTP/2 协议支持。

此外，著名的开源HTTP服务器软件 Nginx 也于2015年9月移除了对SPDY的支持，转而支持HTTP/2。

鉴于此，未来会有越来越多的浏览器和Web服务器选择支持HTTP/2而非SPDY，以前支持SPDY的浏览器和Web服务器也会通过升级取消对SPDY的支持转为支持HTTP/2。

之所以我们建议网站不要部署SPDY，而是部署HTTP，就是因为SPDY采用了HTTP的核心范式，只是对交换格式进行了轻微的修改。现在看来，这些都可以通过HTTP明确划分的语义和语法实现。语义描述了请求和响应交换的概念，包括方法、状态代码、头字段(元数据)和主体部分(有效载荷)。语法描述如何将语义映射到连接上的字节。

HTTP/0.9、HTTP/1.0和HTTP/1.1共享许多了许多语义，这几版协议还通过TCP连接发送的字符串的形式共享语法。SPDY采用HTTP/1.1语义，并将语法从字符串更改为二进制，这是一个非常有趣的话题，但是我们今天就不深入这个话题了。

谷歌对SPDY的测试表明，改变HTTP语法是有可操作空间的，而保留现有的HTTP语义是有价值的。例如，保持URL格式以使用https://避免了许多可能会影响采用的问题。

正是看到了这些积极的测试结果，IETF决定是时候考虑HTTP/2.0了。2012年3月IETF 83会议期间HTTPbis会议对HTTP/2.0制定了据要求、目标和成功的衡量标准。其中明确指出，“HTTP/2.0仅表示有线格式与HTTP/1.x的格式不兼容”。

HTTP/2 （原名HTTP/2.0）即超文本传输协议 2.0，是下一代HTTP协议。是由互联网工程任务组（IETF）的Hypertext Transfer Protocol Bis (httpbis)工作小组进行开发。是自1999年http1.1发布后的首个更新。HTTP 2.0在2013年8月进行首次合作共事性测试。在开放互联网上HTTP 2.0将只用于https://网址，而 http://网址将继续使用HTTP/1，目的是在开放互联网上增加使用加密技术，以提供强有力的保护去遏制主动攻击。DANE RFC6698允许域名管理员不通过第三方CA自行发行证书。

在那次会议上，提交审议的I-D包括draft-mbelshe-httpbis-spdy-00 ，draft-montenegro-httpbis-speed-mobility-00 和draft-tarreau-httpbis-network-friendly-00 。最终，SPDY草案被采纳，并在2012年11月以draft-ietf-httpbis-http2-00的形式正式形成协议草案。2015年，RFC 7540 – HTTP/2 正式被发布，在两年多的时间里，总共经历了18个草案。在此规范期间，HTTP/2的语法精确性出现了一些分歧，这也是HTTP/2和SPDY不兼容的原因。

近几年IETF的主要精力都投入到了HTTP协议的跟踪和制定中了，且任务相当繁忙，HTTP/1.1重构和HTTP/2标准化要同时进行。这与21世纪初多年的平静形成了鲜明对比。所以你一定要查看完整的时间表，以真正了解近几年IETF这几年所做的工作。

由于HTTP/2正处于标准化阶段，所以暂时使用SPDY和并对其进行试验仍然有一定的价值。 Cloudflare在2012年8月引入了对SPDY的支持，直到2018年2月才弃用它，当时我们的统计数据显示，只有不到4%的Web客户端继续需要SPDY。同时，我们在RFC发布后不久的2015年12月引入了HTTP/2支持，当时我们的分析表明有相当一部分Web客户端可以直接利用HTTP/2。

SPDY和HTTP/2协议的Web客户端支持首选使用TLS的安全选项，2014年9月引入通用SSL（用户无需向证书发放机构申请和配置证书就可以使用的SSL证书）有助于确保所有注册到Cloudflare的网站都能够在我们引入这些新协议时利用这些它们。

gQUIC

谷歌在2012年到2015年间继续实验，他们分别发布了SPDY v3和v3.1。同时他们还开始研究gQUIC(当时的发音是as quick)，最初的公开规范于2012年初发布。

gQUIC的早期版本使用了SPDY v3形式的HTTP语法，这个选择是合理的，因为HTTP/2标准还没有制定完成。SPDY二进制语法被打包成可以在UDP数据报中发送的QUIC包，这与HTTP传统上依赖的TCP传输有所不同。以上的描述，简化成图就是以下的样子：

SPDY over gQUIC蛋糕模型

gQUIC使用巧妙的技巧来实现性能，技巧之一就是打破应用程序和传输之间的清晰分层。这在实践中就意味着gQUIC只支持HTTP。以至于gQUIC(当时被称为“QUIC”)一度成为HTTP的下一个替代方案。尽管在过去的几年中，QUIC不断地发生变化(我们稍后将对此进行讨论)，但直到今天，QUIC这个术语仍然被人们理解为最初的仅用于HTTP的变体。不幸的是，这是在讨论协议时经常引起混淆的原因。

后来gQUIC继续进行实验并最终使用了更接近HTTP/2的语法。二者语法如此接近，以至于大多数人简单地将其称之为"HTTP/2 over QUIC"。但是，由于技术限制，HTTP/2和QUIC之间还是有一些非常细微的差别，比如如何序列化和交换HTTP标头。虽然这只是一个很小的区别，但实际上意味着HTTP/2 over QUIC与IETF的HTTP/2是不兼容。

归根结底，互联网协议除了能提高传输性和稳定性之外，最重要的就是安全方面了。gQUIC就没有选择使用TLS来提供安全性，相反，谷歌开发了一种名为QUIC Crypto的不同方法。该方法的一个有趣的方面就是加快安全握手的新方法，先前与服务器建立了安全会话的客户端可以重用信息来进行“零往返时间”即0-RTT握手，0-RTT后来被TLS 1.3采纳。

HTTP/3目前的标准化状态

到目前为止，你应该已经熟悉了标准化的工作原理，gQUIC的标准化过程也没有什么太大的不同。人们对谷歌规范以I-D格式编写非常感兴趣。2015年6月，谷歌提交了题为“QUIC：基于UDP的HTTP/2安全可靠传输”的draft-tsvwg-quic-protocol-00，其语法几乎是HTTP/2。

谷歌宣布将在布拉格的IETF 93举办一场“Bar BoF”发布会。对于那些好奇什么是“Bar BoF”的人，请参阅RFC 6771。

简而言之，谷歌与IETF合作的结果是，QUIC似乎在传输层提供了许多优势，并且它应该与HTTP分离，重新引入层之间的清晰分离层。此外，有人倾向于返回基于TLS的握手（由于TLS 1.3在此阶段正在进行，并且正在整合0-RTT握手，因此并没有那么糟糕）。

大约一年后的2016年，谷歌提交了一套新的I-D:

· draft-hamilton-quic-transport-protocol-00 

· draft-thomson-quic-tls-00 

· draft-iyengar-quic-loss-recovery-00 

· draft-shade-quic-http2-mapping-00 

这里是关于HTTP和QUIC产生混淆的另一个来源，draft-shade-quic-http2-mapping-00名为“使用QUIC传输协议的HTTP/2语义”，它将自己描述为“在QUIC上的HTTP/2语义映射”。然而，这种说法很不恰当。HTTP/2是在维护语义的同时对原有的语法进行了修改。此外，"HTTP/2 over gQUIC"从未对语法进行过准确描述，原因我在前面已经介绍过了。

目前这个IETF版本的QUIC是一个全新的传输协议，应该说制定一个全新的传输协议是一项很艰巨的任务，不过在发布该计划之前，IETF先衡量了一下各个组织成员的实际利益。为此，2016年在柏林举行的IETF 96会议上IETF举行了正式的讨论会议。我们很幸运能够亲自参加这次会议，在会议结束时各个成员达成了共识; QUIC将被IETF标准化。

用于将HTTP映射到QUIC的第一个IETF QUIC I-D是draft-ietf-quic-http-00，该草案采用了Ronseal方法，并将其名称简化为“HTTP over QUIC”。不幸的是，该草案没有完全完成预定的修订工作，而且在整个草案中存在许多引用HTTP/2术语的地方。I-D新的负责人Mike Bishop发现了这一点，并开始修复和HTTP/2有关的错误。在01草案中，原来的描述改为“基于QUIC的HTTP语义映射”。

随着时间的推移和版本的演变， 对“HTTP/2” 术语的使用逐渐减少了，仅有的使用仅仅是对RFC 7540 部分的引用。到2018年10月，I-D已经是第16版了。虽然HTTP over QUIC 与HTTP/2相似，但它最终还会是一个独立的、不向下兼容的HTTP语法。然而，对于那些不密切跟踪IETF发展的人来说，他们并没有从文档名称的变化之处捕捉到这种差异。标准化的作用之一就是帮助大家提高通信便利和互操作性。然而，像命名这样简单的事情反而造成了标准制定的混乱，这是大家原来都没有想到的（你可能也在HTTPtre或HTTPter两个名称上犯过糊涂）。

回想一下IETF 在2012年所说的“HTTP/2.0仅表示有线格式与HTTP/1.x的格式不兼容”这句话，可以说IETF遵循了当初的承诺。在IETF 103发布之前和发布期间，经过深思熟虑，各方一致同意将“HTTP over QUIC”重命名为HTTP/3。

但是RFC 7230和RFC7231不支持IETF目前对语义和语法的定义!

有时文档标题可能会令人困惑，比如描述语法和语义的当前HTTP文档有：

RFC 7230——超文本传输协议（HTTP/1.1）：消息语法和路由；

RFC 7231——超文本传输协议（HTTP/1.1）：语义和内容；

我们可能会对这些名称进行过多的解读，并认为基本的HTTP语义是特定于HTTP版本的，即HTTP/1.1。然而，事实并非如此。鉴于这些混乱， HTTPbis工作组正在努力解决这个问题。一些成员正在进行新一轮的文件名称修订，且这项工作现在正在进行，且是HTTP核心工作。目前，工作组计划将把原来的六份草案压缩成以下三份:

HTTP语义(draft-ietf-httpbis-semantics)

HTTP缓存(draft-ietf-httpbis-caching)

HTTP/1.1消息语法和路由(draft-ietf-httpbis-messaging)

在这个新结构下，很明显的可以看出HTTP/2和HTTP/3是通用HTTP语义的语法定义，这并不意味着它们除了语法之外没有自己的特性。

总结

这篇文章对过去三十年来IETF对HTTP的标准化过程进行了简单的介绍，由于篇幅原因，我在本文没有过多介绍技术细节，而是以一个时间轴的方式理清HTTP/3的演变过程。简而言之，HTTP/3只是一种新的HTTP语法，适用于IETF QUIC，这是一种基于UDP的多路复用和安全传输。