彻底了解QUIC协议：QUIC的真相揭秘

本文已参与「新人创作礼」活动，一起开启掘金创作之路。

一、写在开篇

本系列的写作旨在对QUIC协议有更深入的理解。包括QUIC是什么，解决了什么问题，QUIC相关概念的介绍，QUIC协议细节解读。也会拓展开来，介绍一些与QUIC相关性较强的其它知识。

本系列的写作会将RFC9000作为重要参考，输出一些个人解读和思考。

希望本系列的文章能给笔者和读者都带来收获，通过学习QUIC协议能够对网络协议有更深刻的认识和理解。

文章中出现的错误、疏漏、不足之处欢迎在评论区指正。

二、QUIC是什么

QUIC概念

QUIC是quick udp internet connection(快速UDP网络连接)的简称。

进一步解释，它是基于UDP的多路复用的安全的传输协议。

QUIC所在的层级如图所示:

这里就涉及到几个关键词UDP，多路复用，安全。

先提出几个问题，后面会一一探究:

1. 为什么QUIC要基于UDP协议设计。

2. QUIC的多路复用的意义。

3. QUIC的安全相关设计有什么独到之处。

QUIC历史

QUIC是非常年轻的协议，据提出至今不到十年，据正式发布至今还不到两年。

QUIC首次提出是在2012年，在Google内部开始实验性的研究。

2015年6月提交QUIC规范草案给IETF。

2018年10月IETF QUIC工作组和HTTP工作组联合声明了HTTP/3，即在QUIC之上运行的HTTP协议。

2021年5月IETF正式公布RFC9000。

从实验性的提出到正式发布历经了9年时间，虽然距离正式发布的时间并不长，但是QUIC已被大范围的试验和应用，

被众多浏览器所支持，包括Chrome、Opera、Safari、Edge、Firefox。

也有不少的移动端app的网络交互选择使用QUIC协议。

三、为什么要用QUIC

为什么HTTP/3基于QUIC

QUIC最为大家所熟知的使用场景就是承载HTTP协议(HTTP over QUIC)，那么为什么HTTP/3选择了QUIC作为底层协议呢？

先回顾下HTTP/1，HTTP/2的发展历程，看看遇到了哪些问题，做了哪些优化。

HTTP/1、HTTP/2遇到的一些问题

队头阻塞问题

什么是队头阻塞(Head-of-line bloking)问题？其实有两个不同层面的队头阻塞问题。

1. TCP队头阻塞问题

2. HTTP队头阻塞问题

TCP队头阻塞

TCP是可靠的、保障数据到达的协议，当丢包发生时，对丢失包进行重传会阻碍后续包的处理。

类似在超市结账，队头的人结账速度慢会影响队伍后面的所有人。

HTTP队头阻塞

HTTP的队头阻塞和TCP的队头阻塞是类似的，只不过TCP队头阻塞是包级别的，而HTTP队头阻塞粒度扩大到单个HTTP请求。浏览器一般只允许对相同域名发起有限的几条tcp连接，在单条tcp连接之上的HTTP请求会排队发送，如果返回结果慢会影响后续请求的发起。

慢启动问题

除了队头阻塞问题，基于TCP的HTTP协议的效率也受限于TCP的慢启动策略。

“慢启动”是TCP的一种拥塞控制策略，它旨在避免发送的数据超过网络承载能力发生网络拥塞。

在处于慢启动阶段时，每过一个RTT才会调整一次拥塞窗口(决定单次发送的数据上限)，这种策略在某些场景是适合的。但在HTTP场景下，多数的请求只传输很小的数据量，却要等待几次RTT才能使拥塞窗口的增长满足需求，如果单个请求结束后就断开连接，下个请求开始时重新建立，那么每个请求都要经历一次慢启动过程，这样很影响HTTP传输的效率。

HTTP/1、HTTP/2为解决上述问题做的努力

HTTP/1.1的管线化

HTTP/1.1增加了管线化，这是一种可以将多个HTTP请求打包送出的技术，发送多个请求时不需要等待单个请求的响应。但是服务端回复响应时仍要按照请求顺序依次回复。

管线化只解决了部分的HTTP层队头阻塞问题，并没有得到广泛的使用。

由SPDY协议发展而来的HTTP/2

SPDY协议提出也是为了解决HTTP队头阻塞的问题，SPDY的层次在TCP之上，HTTP之下，它提出了fream(桢)和stream(流)的概念。传输的数据单元是fream，在fream内有标识它所属的流id信息。

HTTP/2是对SPDY协议的标准化，多个独立的请求和响应可以在同一tcp通道上传输用不同的流区分，解决了HTTP层面的队头阻塞问题。

解决了HTTP层面的队头阻塞，就可以针对每一个域名只保持一条长连接，这样也能极大降低TCP的慢启动带来的影响。

HTTP/2所做的努力很好的解决了HTTP层面的队头阻塞，提升了HTTP访问效率，但受限于TCP协议的特性，仍无法解决TCP层面的队头阻塞问题。

QUIC的解决之道

QUIC通过基于UDP重新实现可靠传输，突破了TCP协议的种种限制。

多路复用

QUIC协议中有stream和fream的概念(在SPDY、HTTP/2中也有类似的概念)，多路流之间的数据包无需保障到达顺序(单路流的数据顺序还是要保障的)，实现了多路复用，避免了TCP的队头阻塞问题。

基于UDP实现

TCP是实现在内核空间的，这就造成了它很难被更改，想要升级TCP协议，就要对网络上海量的设备(终端、路由器等)升级操作系统，这已经非常不现实了。

UDP足够简洁，QUIC在用户空间基于UDP实现了可靠传输、拥塞控制、加解密等功能。上述功能在用户空间实现而非内核空间，极大的提升了使用时的灵活性和协议本身迭代速度。

更快的建联

快速建联也是QUIC安全设计相关的独到之处。

QUIC的安全和TCP+TLS有什么区别？

TCP + TLS的握手至少要经历2个rtt:

1. 先建立好TCP连接。

2. 再进行加密协商。

而QUIC的在设计之初就将安全性考虑了进来，在建立连接握手的同时进行加密协商，这样只需1个RTT就能完成建联，节省了交互次数。

使用QUIC的客户端基于先前的通讯和本地信息存储，可以做到0RTT建联。具体的细节将在以后介绍。

支持连接迁移

QUIC的连接并不绑定在单一的网络路径上，它使用一个唯一的连接标识(cid)来区分连接，该设计使得当网络环境发生改变时(网络拓扑变化，NAT地址变化)连接能够继续使用。

在HTTP协议之外

QUIC的应用场景不只局限于承载HTTP协议，QUIC协议属于传输层，理论上可以在任何应用TCP协议的地方使用QUIC，包括但不限于长连接、RPC调用、IM通讯、媒体数据传输。

四、本篇总结

QUIC协议(快速UDP网络连接协议)是基于UDP的、多路复用的、安全的传输协议。

它能解决HTTP/1、HTTP/2的队头阻塞问题，缩短建联时间，提升传输效率。

它的可靠传输、拥塞控制、加密等功能都实现在用户空间，在使用中有更多的灵活性，也利于协议本身的快速迭代。

QUIC有丰富的使用场景，包括各种长连接、RPC、IM、流媒体传输，不局限于HTTP。