1.4 QUIC的诞生

根据TCP、TLS和HTTP进化历史的描述，我们可以看出每个层都在尝试解决现实世界中遇到的问题。其中最想要的特性就是尽早发送数据，减少用户感知到的延迟，如TCP Fast Open、TLS False Start等；另外，应用希望更快地发送和接收数据，这方面的改进如HTTP的多路复用，但可能遇到TCP的队首阻塞导致的带宽利用率不足的问题；在解决这些问题的过程中又遇到了协议僵化，无法将新特性广泛应用。我们希望能有一个新的传输协议彻底解决这些问题，于是QUIC来了！

谷歌于2012年提出了QUIC，随后开始在浏览器和服务中使用。QUIC最初的定义是Quick UDP Internet Connections，思想是基于UDP提供并发、安全的传输方式，同时改进了TCP中存在的一些其他问题，比如拥塞控制、协议僵化、启动慢、重连慢、安全弱等 。QUIC基本功能和位置如图1-32所示。

QUIC主要从以下几个方面改进了传统的传输方式。

1）实现了没有队首阻塞的并发。HTTP2为了支持并发，增加了流和帧的概念，通过帧的封装实现了流的并发，如图1-33所示。但是HTTP2是基于TCP的，TCP并看不到流，而是将HTTP2的所有帧作为一个字节流传输，也就只能按照整个TCP连接按序交付，如果一块数据丢失，其他数据即使收到了也不能交付，这就是TCP的队首阻塞，这在一定程度上影响了HTTP2的并发。为了解决这个问题，QUIC借鉴了HTTP2中流的思想，将流的概念引入传输层，传输层通过帧的封装识别了流；通过递增的报文编号检测丢包，与应用数据交付分离，从而实现了传输层的并发。如果QUIC丢了一个报文，仅仅影响对应流的交付，不会阻塞其他流。

2）尽可能地加密。QUIC与TLS 1.3紧密协作，完成了数据加密，提供了数据的安全性和保密性，实现了比TCP+TLS更好的安全，如图1-34所示。此外还增加了QUIC报文的首部加密，除保证了报文安全性，提高了攻击门槛，还避免了协议僵化。这是因为中间件看不到QUIC报文的报文编号等信息，无法做进一步处理，后续端点想要修改QUIC的行为就不需要考虑大部分中间件的兼容性了。QUIC是与TLS深度融合的，早在HTTP2标准讨论的时候，就有提出过强制加密 ，最终虽然没有写入标准，但是HTTP2的实现基本都是仅支持与加密共同使用（TCP+TLS），HTTP2的明文方式也被证明存在安全问题 ，所以QUIC选择了必须加密的传输协议。

3）选择UDP作为底层传输。QUIC底层传输基于UDP，从而提供避免队首阻塞的条件，也兼容了主机和中间件。一方面，UDP只管将数据报（其中封装了一个或多个QUIC报文）发出去，而不管报文之间的顺序，所以UDP本身不会形成队首阻塞，可以更好地实现并发。另外一方面，多年以来互联网技术的发展使主机（包括电脑、手机、服务器、虚拟机等）和中间件（NAT、防火墙、负载均衡器等）几乎成了TCP和UDP的天下，如果采用新的协议，主机和中间件都要升级，这在互联网中不太现实，起码中间件大部分都不受自己控制，无法进行升级。所以要使用新的协议，必须考虑当前的现实，UDP作为底层传输是现实的选择。

4）用户态实现。QUIC将功能放在了用户态（而TCP位于内核态），如图1-35所示，这样可以更加灵活地修改、升级，防止了重演TCP在主机上的僵化问题。前文提到的很多问题，都可以通过改进TCP来解决，但都没有大规模应用，这是由于TCP位于内核态，难以单独升级，当然中间件的僵化也是原因之一，这应该也是QUIC对于僵化如此敏感的原因。

5）低延迟的连接建立。QUIC通过与TLS 1.3的紧密结合，实现了首次最低1-RTT发送应用数据；恢复连接时发送应用数据最低只需0-RTT。这样在时延较大或者丢包率较高的弱网环境中可以提供更好的用户体验，与其他方案的对比如图1-36和图1-37所示。需要说明的是，TFO+TLS 1.3也能实现首次1-RTT和重连0-RTT的数据发送，但是除了在最早发送应用数据与QUIC相同之外没有其他优势，比如：避免队首阻塞、更强的安全性、防止协议僵化等。

6）无缝的连接迁移。QUIC的连接基于连接标识，改变IP或者UDP端口号并不影响连接的识别，因此可以实现无缝的连接迁移，具体过程见3.6节。但是这给负载均衡带来了挑战，具体见第6章。另外也增加了放大攻击风险，具体考虑见3.6节。

7）改进的流量控制。QUIC的流量控制通过对偏移的限额实现，可以支持连接和流两个级别。除此之外，还可以限制打开中流的个数。因为完成了报文编号和数据偏移的分离，可以支持乱序确认，这比TCP+HTTP2的流量控制更加灵活。

8）改进的拥塞控制。QUIC在拥塞控制方面做出了很多优化，包括不同加密级别互相独立的报文编号空间、单向递增的报文编号、更清晰的丢包周期、确认过的报文不允许反悔、支持更多的确认范围、显式修正延迟等。对于使用多个TCP连接实现并发的应用来说，更明显的好处是可以协调所有数据间的网络占用，而不会像多个TCP连接一样竞争网络资源。

9）协议行为作为负载。TCP将协议的行为都放在首部，如ACK、序号、选项等，由于TCP首部长度限制为40字节，表达力受到了很大限制，扩展也会比较困难，而且即使使用了TLS，协议行为还是都暴露了出来。QUIC则将协议的行为大部分都作为不同的帧放在负载中携带，可以方便地扩展。

谷歌最初使用的是gQUIC，跟IETF QUIC有些不同。直到2015年6月，谷歌将QUIC提交给IETF，才开始了QUIC的标准化之路。之后，IETF正式认定QUIC为一个名称，而不再作为缩写。QUIC的发展历程如图1-38所示。

2021年5月，QUIC一系列核心草案获得标准化，包括如下内容。

《RFC8999 QUIC的版本无关属性》定义了QUIC所有版本通用的属性。

《RFC9000 QUIC：基于UDP的多路和安全传输》定义了传输协议的核心内容。

《RFC9001使用TLS保护QUIC》描述了怎么使用TLS来保护QUIC。

《RFC9002 QUIC丢包检测和拥塞控制》描述了QUIC的丢包检测和拥塞控制机制。

此后，QUIC标准被不断完善。2022年3月，QUIC的不可靠扩展实现了标准化——《RFC9221 QUIC不可靠数据报扩展》。2022年8月，《RFC9287使用QUIC位》也标准化了。

很多应用从2022年也开始了使用QUIC的标准化之路。2022年5月，DNS标准化了基于QUIC的传输方式，发布了《RFC9250基于专用QUIC连接的DNS》。

2022年6月基于QUIC的HTTP3也标准化了，包括两个QUIC定制化的标准：

《RFC9114 HTTP3》描述了基于QUIC的HTTP语义映射，还确定了QUIC包含的HTTP2功能，并描述了如何将HTTP2扩展移植到HTTP3。

《RFC9204 QPACK：HTTP3的字段压缩》基于QUIC改进了HPACK，以尽量避免队首阻塞。

2022年9月，IETF标准化了用于指导中间件管理QUIC和应用使用QUIC的两个标准，即《RFC9312 QUIC传输协议的可管理性》和《RFC9308 QUIC传输协议的适用性》。

QUIC和SCTP有很多相似之处，很多特性可以对比来看。我们可以看出，多宿主多流模式是传输协议的发展方向，安全也成为传输协议需要考虑的重要问题，总的来说传输层功能越来越多了。

SCTP和QUIC的不同出身也决定了他们的不同应用范围。

SCTP来源于电话信号传输的需求，作为核心网传输层更在意可靠性、单个消息的低时延，甚至支持了应用可以定制的消息有效期，超出有效期则不再重传，这对电话信号来说简直太友好了！在核心网中，中间件都是运营商控制的，可以不太在意兼容性，这给了SCTP生存空间。

QUIC来源于谷歌，也就更在意终端用户的感受，所以QUIC作为应用的传输层更在意首包低时延，可以更快地发送应用数据，让用户感受到更低的时延。QUIC也在意更弱网环境和移动设备，设计上对手机等要使用无线传输的设备来说比较友好；同时QUIC也考虑了中间件的支持，底层传输选用UDP，这在复杂网络环境中能更好地传输，同样也是对个人终端友好的表现。QUIC还支持了不可靠的数据报方式，对于终端上的直播和游戏类应用提供了更好的支持。

WebRTC（Web Real-Time Communications，网络实时通讯）也支持了QUIC，因为QUIC比SCTP更适合终端传输，当然两者都是谷歌推动标准化的，结合有一定的必然性。谷歌提出的新一代实时数据传递框架WebTransport直接采用了HTTP3，并使用QUIC提高传输效率。 DYHAz7luqyDAD2HIsjCWdXYcVCB8GfZPuOaswI6s9+nDQ2/R5Zt5yNE0qpQ9CuzT