QUIC协议报文解析(三)

在前面的两篇文字里我们简单介绍了QUIC的发展历史，优点以及QUIC协议的连接原理。本篇文章将会以具体的QUIC报文为例，详细介绍QUIC报文的结构以及各个字段的含义。

早期QUIC版本众多，主要有谷歌家的gQUIC，以及IETF致力于将QUIC标准化，即IETF QUIC（iQUIC），还有Facebook家的mvfst。早期各家的QUIC都有自己定制的字段，但总体是大同小异。

与包头格式固定的 TCP 不同，QUIC 有两种类型的包头。建立连接的QUIC数据包需要包含的信息多，它使用长头格式。一旦建立连接，只需要某些报头字段，后续数据包使用短报头格式以提高效率。

一：gQUIC早期Q043以及以下版本包头

gQUIC的Q043及以下的版本与Q044版本之后的公共包头是不同的与现在最新的公共包头是不同的

前8位是公共标志位，其中部分意义如下：

0x01	Packet是否包含QUIC Version
0x02	Packet是否是Public Reset Packets
0x0C的两比特	Connection ID的长度（0/8/32/64位）
0x30的两比特	Packet number的长度（8/16/32/48位）

Connection ID：客户端产生的一个64位无符号整型，标识唯一的连接，可以与服务端协商Connection ID的长度。当客户端漫游，IP 4元组无法标识一个连接时，可使用Connection ID标识一个连接。当IP 4元组可以标识连接时，该字段可省略。

Version：32位的版本号。当客户端提议的版本不支持时，服务器端可以设置版本标记，并提供一个可接受版本列表。

Packet Number：包号。每个普通包（与特别的公共复位和版本协商包相反）由发送者分配包号。由某一端发送的首包包号应该为1，后续每个包的包号应比前一个大1。

gQUIC的Q043及以下的版本没有后来的长包头短包头的说法，其包头的格式是统一的。只是后面为了兼容主流QUIC在Q044版本之后公共包头采用了长包头和短包头的形式。

二：QUIC长包头

随着2021年5月 QUIC RFC 9000发布，并由RFC 9001、RFC 9002和RFC 8999支持（其中，RFC8999定义了QUIC协议版本无关的规范，RFC9001定义了QUIC与TLS的协议映射、RFC9002定义了QUIC协议的丢失恢复与拥塞控制）。这意味着QUIC Version 1已经正式标准化，并且QUIC部署将从使用临时草案版本转向新创建的Version 1。与此同时，有最新消息指出QUIC Version 1以一种新的互联网传输技术作为标准发布，可提高Web应用程序的性能、安全性和隐私性。

随着QUIC标准化版本的宣布，目前Facebook、Akamai、Microsoft、Cloudflare、Ericsson、F5、Fastly和Google都已部署了QUIC和HTTP/3。至此QUIC进入到统一的时代。

为什么要介绍上面的背景，因为在RFC9000出来之前QUIC的长包头和短包头不说在各个大厂之间，即使是同一个厂家比如Google，不同版本的QUIC包头的格式也是有差别的。这就没发展开了，下面我们看一下RFC9000的长包头。

最明显的标志就是第一个字节的高位设置为 1。该字节中的所有其他位都是特定于版本的。另外对于Packet Type占两位，其取值如下：

Version：四个字节，包括一个 32 位版本字段。 RFC9000的Version是1，其实也可以理解这是QUIC标准化后的第一个版本

Destination Connection ID Length：目标连接 ID 字段的字节长度。此长度编码为 8 位无符号整数。

Destination Connection ID：目标连接 ID 字段，长度在 0 到 160个字节之间。

Source Connection ID Length：源连接 ID 字段的字节长度。此长度编码为 8 位无符号整数。

Source Connection ID：源连接 ID 字段，长度在 0 到 160个字节之间。

数据包的其余部分包含特定于版本的内容。

三：QUIC短包头

短包头的格式如下：

带有短包头的 QUIC 数据包的第一个字节的高位设置为 0。

带有短包头的 QUIC 数据包包括紧跟在第一个字节之后的目标连接 ID。短包头不包括目标连接 ID 长度、源连接 ID 长度、源连接 ID 或版本字段。目标连接 ID 的长度没有编码在具有短包头的数据包中，并且不受本规范的限制。

数据包的其余部分具有特定于版本的语义