QUIC协议的演进之路

Posted 2021-09-01 LiveVideoStack_

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了QUIC协议的演进之路相关的知识，希望对你有一定的参考价值。

当通过网络传输数据时，一种新的协议QUIC（Quick UDP Internet Connection，快速UDP互联网连接）正在成为FAANG的默认选择。本篇文章描述了QUIC协议是如何克服其他版本HTTP的限制脱颖而出的。

FAANG是美国市场上五大最受欢迎和表现最佳的科技股的首字母缩写，即Facebook、Apple、Amazon、Netflix和Google。

HTTP的演进

HTTP属于应用层传输协议，运行于TCP/IP之上。现在它已成为万维网中数据交换的基础。HTTP包括4个稳定版本：HTTP/0.9、HTTP/1.0、HTTP/1.1 和HTTP/2。HTTP/3于2018年首次提出，目前已获得全球2/3 web浏览器的支持。

HTTP/0.9（1991）

HTTP/0.9是HTTP的第一个版本，用作W3C的底层通信协议。它是一个非常简单的客户端-服务器、请求-响应、使用Telnet的协议，只支持GET命令（作为请求方法）和超文本协议（作为响应类型）。该协议不包含HTTP消息头，且发送响应后，连接会立即断开。

HTTP/1.0（1996）

HTTP/0.9极其简单，且使用非常受限。新的HTTP版本HTTP/1.0引入了很多新特性，使它更加通用。这些新的特性包括：

每次HTTP 请求/响应都会重新建立TCP连接
添加了对 POST 和 HEAD 方法的支持
协议头带有版本号、协议类型、状态码字段
响应类型：超文本、脚本、媒体、样式表
支持keep-alive连接，但默认情况下它是“关闭”的

HTTP/1.1（1997）

HTTP/1.0的主要缺陷是：它在每次请求\\响应时都要建立新的TCP连接。这种做法非常耗时，且影响客户端和服务器的性能。HTTP/1.1的出现解决了这一问题：

单个TCP连接上可以传送多个HTTP请求和响应
添加了对 PUT、DELETE、TRACE、OPTIONS 方法的支持
默认持久连接

HTTP/2（2015）

随着流媒体内容的增加，网站也开始变得越来越复杂。为了满足这种需求，HTTP/1.1的功能不断扩展：首次支持多个TCP连接，并试验性地引入了管道机制（pipelining），即在同一个TCP连接里面，客户端可以同时发送多个请求。但扩展不可能无止境，最终需要采用一个新的协议，于是HTTP/2出现了，该协议包括如下重大改进：

多路复用：这是HTTP/2的一个特性，允许同时通过单个TCP连接发起多重请求-响应消息。每次HTTP请求-响应都被分割成二进制帧，客户端和服务器都以二进制帧为基本单位发送消息（请求和响应）。通过多路复用，客户端无需再等待上一个请求完成就可以发送多重请求。这样，HTTP/2便解决了HTTP队头阻塞（HoL）的问题。如图所示：

头部压缩：使用 HPACK 压缩消息头
非阻塞下载
支持服务器推送
采用二进制分帧，不再是纯文本
解决了队头阻塞问题

HTTP/3（2018）

通过多路复用，HTTP/2解决了队头阻塞问题。但如果TCP流中出现了丢包，根据TCP的拥塞控制机制，其他数据流就只能等待丢包被重新发送和接收。所以，TCP的队头阻塞问题在HTTP/2中依然存在。

HTTP/3通过使用基于UDP的传输协议QUIC解决了这一问题。

HTTP/3是自HTTP/2之后最新且最主要的HTTP版本。因为HTTP/3本身就是为QUIC协议设计的，所以也被描述为基于QUIC的HTTP/2。HTTP/3的目标是通过使用谷歌的QUIC协议提供快速、可靠安全的网络连接。HTTP/3包括以下特性：

使用基于UDP的QUIC作为传输协议
解决了TCP队头阻塞问题
使用QPACK头部压缩机制
提供更快页面加载时间

HTTP/2 VS HTTP/3

下图展示了HTTP/2和HTTP/3两者的对比：

相同点：

HTTP/2 和 HTTP/3 使用相同的语法和语义结构，并且适用于同一请求/响应方法、状态码和协议字段。此外，两者都使用设计相似的头部压缩算法（HPACK 和 QPACK）。

不同点：

特性	HTTP/2	HTTP/3
传输层协议	TCP	基于UDP的QUIC
头部压缩算法	HPACK	QPACK
队头阻塞问题	解决HTTP队头阻塞	同时解决HTTP和TCP 队头阻塞
握手协议	TCP + TLS	QUIC
加密协商	可通过TLS（默认版本为1.2，后续版本可选）与ALPN协议扩展进行协商	使用用于QUIC协议的Alt-Svc（以 TLS 1.3 作为 TLS 的最低版本）
握手时间	因为需要TCP和TLS 握手，所以更慢	QUIC协议直接处理数据流，所以更快

QUIC是一种新的多路传输层网络协议标准，建立在 UDP 之上。QUIC的主要目标是通过减少页面加载时间提升用户体验，并提高HTTPS的传输性能。它在本质上是TCP+TLS+HTTP/2。

设计HTTP/3的目的就是要充分利用 QUIC 的优势。QUIC 协议本身可以处理数据流，所以排除了 TCP 队头阻塞问题。

QUIC 的一些关键特性包括：

基于UDP
使用没有队头阻塞的连接复用
重构TCP的关键机制（连接复用、连接建立、拥塞控制、可靠性），并成为可靠的传输协议

交换数据包

对于典型的QUIC协议，客户端和服务器之间交换了三种类型的数据包，如下图所示：

QUIC连接建立和安全的净荷包

1. 安全的首包

首先，客户端在一个CRYPTO 帧中传输包含TLS 1.3 Client Hello的首包。Client Hello包含不同类型的的扩展项，如目标服务器的SNI（Server Name Indication，服务器名称指示）、QUIC 传输参数、压缩证书等，以及客户端支持的压缩方法和不同的加密套件。

如果服务器接受QUIC和TLS 1.3参数，它也会在CRYPTO帧中发送包含对客户端首包确认信息和TLS 1.3 Server Hello的首包信息。Server Hello中包含被服务器接收的加密套件和不同的扩展（如密钥共享、支持的版本等）。在客户端接收到 Server Hello后，会向服务器发送一个ACK确认包。

这三个首包都可能包含一个填充帧，以根据需要增加数据包的大小。

2. 握手包

客户端和服务器之间的首包被交换以后，服务器会发送一个握手数据包，其中包含余下的服务器端消息，如证书、与服务器身份验证相关的加密扩展。客户端会验证这些证书，然后QUIC 握手以客户端发送的握手消息结束。

3. 安全的净荷包

一旦安全的QUIC连接建立，客户端与服务器之间的信息便可以安全传输。

QUIC 0-RTT

为了缩短建立新连接的时间，QUIC采用0-RTT。在这里，如果客户端之前使用1-RTT连接到服务器，则服务器必须存储与流量控制相关的传输参数的副本，如 initial_max_data、initial_max_stream_data_bidi_local 等。

下一次，在QUIC 0-RTT模式中，客户端立即开始与服务器的数据传输，不需要等待握手完成。

然而，0-RTT也有设计上的缺陷：允许重放攻击。

我们为什么要用QUIC？

传统的TCP协议是建立在操作系统层和中间路由模块之上实现的，它的握手阶段信息很容易被这些中间模块篡改而变得不安全。

但QUIC协议是在UDP之上的用户级（如浏览器）中实现的，因此它更加灵活、对用户更友好，并且能够在短时间内支持更多设备。