QUIC的诞生

背景

自1999年HTTP/1.1被提出以来，它已经稳定地被使用超过了20个年头。不过经典并不意味着完美，HTTP/1.1中一个连接同一时刻只能处理一个HTTP请求，如果当前的请求没有结束之前，其他的请求只能处于阻塞状
态。这一“对头阻塞”问题便催生出了HTTP/2。

HTTP/2中加入了多路复用的特性，即一次性发送多个HTTP请求报文或者响应报文，从而解决了HTTP/1.1中的对头阻塞。不过，由于HTTP2和它的前辈们一样，底层都是用TCP作为传输层协议，所以HTTP/2虽然缓解了应用层的对头阻塞问题，但仍受困于TCP的固有缺陷——TCP对头阻塞。

终于，在2012年，一位名叫Jim Roskind的（前）谷歌软件工程师再次掀起了一场传输协议革命，一种全新的传输协议呼之欲出。

诞生

2012年4月，谷歌软件工程师Jim Roskind发布了名为QUIC: Design Document and Specification Rationale的设计文档[1]。Jim在其中提到设计QUIC的原因主要是SPDY在当时仍存在不少问题，如队头阻塞、拥塞控制不够灵活、使用TLS带来的额外时间损耗等，同时想要实现低时延、更好地支持移动端等功能。这篇文档中提出了基于UDP的QUIC连接（Connection）、连接标识符（CID，Connection IDentifier）、流（Stream）、各种类型的帧（Frames，如CONGESTION_CONTROL_FRAME、ACK_FRAME、CONNECTION_CLOSE_FRAME，不过部分帧在正式的QUIC协议中已被弃用）等概念，成为了日后标准化QUIC的雏形。

在2015年的更新中，Jim提到由于自己的工作重心需要转移到其他项目上，无法继续更新这篇文档，即使未来QUIC的具体实现可能与这篇文档会有些出入，但他坚信QUIC背后的设计理念（design philosophy）并不会改变。如今已成为RFC标准的QUIC协议更多代表了一种通用的传输协议（a general-purpose transport protocol），相比谷歌刚开始只是为了优化Chromium的目的更向前迈进了一步[2]，但这篇设计文档仍可以算是奠定了QUIC整体设计思路的开山之作。

图1 QUIC: Design Document and Specification Rationale的设计文档

发展

2013年6月，Jim Roskind在Chromium Blog上发布了一篇题为Experimenting with QUIC的博客[3]，正式向外界宣布谷歌正在对QUIC进行内部测试，并准备将其集成进一小部分的开发版本的Chrome（通过命令行形式进行开启）并在真实场景下测试。而从2014年开始，谷歌开始考虑逐步进行QUIC的大规模部署[4]，一年后，谷歌开发人员又发布了一篇A QUIC update on Google’s experimental transport的博客[5]，证实了过去这两年QUIC在实际环境中表现出了不错的实验结果。虽然在大规模部署过程中遇到了不少困难，但QUIC的应用体量仍势不可挡地从不到0.025%的Chrome用户，到2017年被几乎在所有的Chrome用户中使用，而且安卓系统的YouTube应用也使用了QUIC进行视频传输[6]。随着QUIC协议和测试数据的不断完善，更重要的是喜人的性能表现，在2017年的计算机网络与通信领域顶会SIGCOMM上，一众QUIC设计和开发人员联名发表了重磅论文：The QUIC Transport Protocol: Design and Internet-Scale Deployment，其中给出了在各类真实场景中，QUIC与TCP相比在搜索延迟、视频播放延迟和视频缓冲率等方面的对比数据，可以说是QUIC已落地并商用的官宣。

实际上，在这篇论文发表前，谷歌已于2015年开始与互联网工程任务组（IETF，Internet Engineering Task Force）合作，并于2015年6月提交了一份名为QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2的互联网草案，虽然那是QUIC的主要目标还是为HTTP/2服务，但其中提到QUIC仍有望成为一种通用的传输协议（经历了漫长的6年时光后，QUIC在2021年5月终于从草案成为了RFC标准）。在随后的7月于布拉格（Prague）举行的IETF93会议上，则进行了第一场关于gQUIC测试的非正式讨论（Bar BoF）[7]，这次讨论的目标主要有三个：
• 分享关于QUIC在实际部署中的性能和测试结果（To share the status of and results from QUIC deployment）
• 获得来自IETF社区的反馈（To get feedback from the IETF transport community）
• 评估各类独立应用对QUIC的兴趣如何（To gauge interest in independent implementations）

图2 第一篇关于QUIC的草案，从时间轴上可以看出其于2015年6月发布
谷歌工程师Jana Iyengar（后来跳槽到了美国知名云计算服务商Fastly）在这次的Bar BoF上首先做了题为“QUIC: Redefining Internet Transport”的报告[8]，从宏观上对QUIC的关键特性，QUIC的性能表现，QUIC的可靠性以及QUIC的未来发展方向四个方面对QUIC进行了阐述；而微软架构师Christian Huitema（已于2016年9月从微软退休）则展示了QUIC在Windows上一些实验性测试的结果；最后，谷歌软件工程师Ian Swett阐述了QUIC中拥塞控制和丢包恢复相关机制的说明。这次的BoF举行地非常成功，正如Jana Iyengar后来在博客[9]中提到，正是许多机构对QUIC前景的看好以及对QUIC加速落地的渴望，加速了未来几年内QUIC协议的标准化，让QUIC本身作为一种独立的传输层协议从庞大的gQUIC框架中脱离出来，不再为HTTP所专属，而是成为一种通用的传输协议。

蜕变

就在IETF93的BoF举行后的第二年，谷歌趁热打铁向IETF连续提交了4篇草案[10]，分别关于QUIC协议、TLS在QUIC中的使用、QUIC中的丢包恢复机制，以及HTTP/2与QUIC的映射关系。在此基础上，随着QUIC在谷歌内部的越发普及，以及越来越多的性能测试数据被披露，QUIC越发有望成为一种标准的传输层协议。2016年7月在柏林举行的IETF96会议上，来自谷歌和QUIC社区的开发人员们举行了一场声势浩大的且正式的BoF研讨会（此次研讨会大约有400位与会者）。这次研讨会上IETF确认将QUIC“招致麾下”，同时与会人员一致同意希望创建一个专门管理QUIC进展的工作组。众望所归，在同年11月于韩国首尔举行的IETF97会议上特许成立了QUIC工作组（QUIC working group）。这两次会议标志着QUIC通过了IETF标准化考量，开始走上标准化的正轨，成为IETF准备制定并推广的互联网标准协议之一。

图3 IETF96上的正式BoF研讨会，Adam Roach摄

图4 IETF97会议QUIC研讨现场（截取自Jari Arkko推特，https://twitter.com/jariarkko/status/798324032672133120?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E798324032672133120%7Ctwgr%5E%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwww.ietf.org%2Fblog%2Freflections-ietf-97%2F）

从2016年11月发布第一篇QUIC草案（draft-ietf-quic-transport-00），到2021年5月QUIC正式成为了征求意见（RFC，Request for Comments，许多公共网络研究社区会通过其发布正式出版物），并发布了意味着QUIC Version1正式标准化的RFC9000（同时发布的还有支撑标准RFC9001、RFC9002和RFC8999。RFC8999规定了与QUIC协议版本无关的一些规则，RFC9001规定了QUIC如何与TLS之间进行映射、RFC9002规定了QUIC协议中所使用的丢失恢复机制与拥塞控制），在这几年间，仍属于草案的QUIC协议就得到了无数研究人员和开发者的关注，这在IETF历史上实属罕见。有一个现象可以证明这一点：在QUIC草案不断翻新的过程中，RFC中的关键词“MUST”, “MUST NOT”, “SHOULD”, “SHOULD NOT”等词出现的频率都在不断变高，第十四篇中这些词的频率就足足比第一篇高了不止两倍[11]。

图5 draft-ietf-quic-transport从第一篇草案到RFC9000，属于QUIC的“心路历程”。截取自https://datatracker.ietf.org/doc/rfc9000/

图6 在QUIC草案不断翻新的过程中一些关键词的变化

功到自然成。正是凭借这许多研究人员的不懈努力，QUIC最终从青涩走向成熟，从初出茅庐到现在的后生可畏，从最初谷歌提出专注于优化HTTP/2性能的gQUIC，到如今通过IETF成为标准传输协议。

注：

[1]https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit#
[2]谷歌提出的QUIC（快速UPD网络连接“Quick UDP Internet
Connections”的缩写）主要是为了提高使用HTTP的Chromium的性能，俗称gQUIC；而IETF发布的QUIC则是一种通用传输协议，能使用它的应用层不仅限于HTTP协议，俗称iQUIC
[3]https://blog.chromium.org/2013/06/experimenting-with-quic.html
[4]参见2017年SIGCOMM上的汇报https://www.ietf.org/proceedings/99/slides/slides-99-maprg-the-quic-transport-protocol-design-and-internet-scale-deployment-01.pdf
[5]https://blog.chromium.org/2015/04/a-quic-update-on-googles-experimental.html
[6]参见论文The QUIC Transport Protocol: Design and Internet-Scale
Deployment [7]Bar BOF中文可以翻译成“非正式兴趣小组”。BOF是“Birds of a Feather
Sessions”的缩写，Birds of a
Feather通常指一群个性很相似、有类似想法的人。BOF指这帮人在没有事先安排会议日程的情况下聚在一块讨论某些问题的非正式研讨会。具体介绍参见RFC6771：https://datatracker.ietf.org/doc/html/rfc6771
[8]汇报PPT参见https://docs.google.com/presentation/d/15e1bLKYeN56GL1oTJSF9OZiUsI-rcxisLo9dEyDkWQs/edit#slide=id.g99041b54d_0_0
[9]https://www.fastly.com/blog/maturing-of-quic
[10]这四篇草案的地址分别是：https://datatracker.ietf.org/doc/html/draft-hamilton-quic-transport-protocol-00，https://datatracker.ietf.org/doc/html/draft-thomson-quic-tls-00，https://tools.ietf.org/html/draft-iyengar-quic-loss-recovery-00，https://tools.ietf.org/html/draft-shade-quic-http2-mapping-00
[11] Piraux M , Coninck Q D , Bonaventure O . Observing the
Evolution of QUIC Implementations[C]// 2018.