1.1. 文档结构

本文档描述了 QUIC 核心协议，其结构如下：¶

• 流是 QUIC 提供的基本服务抽象。¶

  • 第 2 节描述与 流相关的核心概念，¶
  • 第 3 节提供 流状态的参考模型，并且¶
  • 第 4 节概述流量 控制的运作。¶

• 连接是 QUIC 端点进行通信的上下文。¶

  • 第 5 节描述与 连接相关的核心概念，¶
  • 第 6 节描述版本 协商，¶
  • 第 7 节详述建立 连接的过程，¶
  • 第 8 节描述地址 验证以及关键的 拒绝服务缓解措施，¶
  • 第 9 节描述端点如何将 连接迁移到新的 网络路径，¶
  • 第 10 节列出终止 打开连接的选项，并且¶
  • 第 11 节提供流 和连接错误 处理的指导。¶

• 分组和帧是 QUIC 用于通信的基本单位。¶

  • 第 12 节描述与 分组和帧相关的概念，¶
  • 第 13 节定义数据 传输、重传和 确认的模型，并且¶
  • 第 14 节规定管理 承载 QUIC 分组的数据报 大小的规则。¶

• 最后，QUIC 协议元素的编码细节在以下章节中描述：¶

  • 第 15 节（版本），¶
  • 第 16 节（整数编码），¶
  • 第 17 节（分组报头），¶
  • 第 18 节（传输 参数），¶
  • 第 19 节（帧），以及¶
  • 第 20 节（错误）。¶

配套文档描述了 QUIC 的丢包检测和拥塞控制 [QUIC-RECOVERY]，以及 TLS 和 其他加密机制的使用 [QUIC-TLS]。¶

本文档定义 QUIC 版本 1，它符合 [QUIC-INVARIANTS] 中的协议 不变式。¶

要引用 QUIC 版本 1，请引用本文档。对 QUIC 有限的 版本无关属性集合的引用可以引用 [QUIC-INVARIANTS]。¶

1.2. 术语与定义

本文档中的关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、 “SHALL NOT”、“SHOULD”、 “SHOULD NOT”、“RECOMMENDED”、“NOT RECOMMENDED”、“MAY”和“OPTIONAL” 应按 BCP 14 [RFC2119] [RFC8174] 中的描述解释，但仅在它们以全大写形式出现时才如此，如此处所示。¶

本文档中常用的术语如下所述。¶

QUIC：

本文档描述的传输协议。QUIC 是名称， 不是 首字母缩写。¶

端点：

能够通过生成、 接收 和处理 QUIC 分组来参与 QUIC 连接的实体。QUIC 中只有两类端点： 客户端和服务器。¶

客户端：

发起 QUIC 连接的端点。¶

服务器：

接受 QUIC 连接的端点。¶

QUIC 分组：

QUIC 的一个完整可处理单元，可以封装在 UDP 数据报中。一个或多个 QUIC 分组可以封装在单个 UDP 数据报中。¶

触发 ACK 的分组：

包含 ACK、PADDING 和 CONNECTION_CLOSE 以外帧的 QUIC 分组。这些分组会使接收方发送确认；见 第 13.2.1 节。¶

帧：

结构化协议信息的一个单元。存在多种 帧类型， 每种帧类型携带不同的信息。帧包含在 QUIC 分组中。¶

地址：

在不加限定地使用时，表示网络路径一端的 IP 版本、IP 地址和 UDP 端口号的元组。¶

连接 ID：

用于在端点处标识 QUIC 连接的 标识符。 每个端点都会选择一个或多个连接 ID，供其对等方包含在 发往该端点的分组中。此值对对等方是不透明的。¶

流：

QUIC 连接内的有序字节的单向或双向通道。一个 QUIC 连接可以承载多个并发流。¶

应用：

使用 QUIC 发送和接收数据的实体。¶

本文档使用术语“QUIC 分组”、“UDP 数据报”和“IP 分组” 来指代各自协议的单位。也就是说，一个或多个 QUIC 分组可以封装在 UDP 数据报中，而 UDP 数据报又封装在 IP 分组中。¶

1.3. 记号约定

本文档中的分组和帧图使用自定义格式。该格式的目的 是概括而非定义协议元素。正文定义结构的 完整语义和细节。¶

复杂字段先给出名称，然后跟随一组由一对 匹配大括号包围的字段。该列表中的每个字段以逗号分隔。¶

单个字段包含长度信息，以及关于固定 值、可选性或重复的指示。单个字段使用以下 记号约定，所有长度均以比特为单位：¶

x (A)：

表示 x 的长度为 A 比特¶

x (i)：

表示 x 使用 第 16 节中描述的可变长度 编码保存整数值¶

x (A..B)：

表示 x 可以是从 A 到 B 的任意长度；A 可以省略 以表示 最小值为零比特，B 可以省略以表示没有设定上限； 这种格式中的值总是以字节边界结束¶

x (L) = C：

表示 x 具有固定值 C；x 的长度由 L 描述，L 可以使用上面的任意长度形式¶

x (L) = C..D：

表示 x 的值位于从 C 到 D（含端点）的范围内， 长度由 L 描述，如上所述¶

[x (L)]：

表示 x 是可选的，且长度为 L¶

x (L) ...：

表示 x 重复零次或多次，且每个 实例的 长度为 L¶

本文档使用网络字节序（即大端）值。字段 从每个字节的高位比特开始放置。¶

按照约定，单个字段通过使用 复杂字段的名称来引用该复杂字段。¶

图 1提供了一个示例：¶

示例结构 {
  一比特字段 (1),
  具有固定值的 7 比特字段 (7) = 61,
  具有可变长度整数的字段 (i),
  任意长度字段 (..),
  可变长度字段 (8..24),
  具有最小长度的字段 (16..),
  具有最大长度的字段 (..128),
  [可选字段 (64)],
  重复字段 (8) ...,
}

当正文中引用单比特字段时，可以通过使用承载该字段的字节值 并将该字段的值置位，来明确该字段的位置。例如，值 0x80 可以用于指代 字节最高有效位中的单比特字段，例如 图 1 中的 一比特字段。¶

2.1. 流类型与 标识符

流可以是单向的，也可以是双向的。单向流在一个方向上携带 数据：从流的发起者到其对等方。 双向流允许在两个方向上发送数据。¶

流在一个连接内由一个数值标识，称为 流 ID。流 ID 是一个 62 比特整数（0 到 2⁶²-1），它在 一个连接上的所有流中唯一。流 ID 编码为 可变长度整数；见 第 16 节。QUIC 端点 MUST NOT 在一个连接内重用流 ID。¶

流 ID 的最低有效位（0x01）标识 该流的发起者。客户端发起的流具有偶数编号的流 ID（该 比特设为 0），服务器发起的流具有奇数编号的流 ID（该 比特设为 1）。¶

流 ID 的次低有效位（0x02）区分 双向流（该比特设为 0）和单向流（该 比特设为 1）。¶

因此，流 ID 中的两个最低有效位将流标识为 四种类型之一，如 表 1 所汇总。¶

每种类型的流空间从最小值（分别为 0x00 到 0x03） 开始；每种类型的后续流以数值 递增的流 ID 创建。乱序使用的流 ID 会导致 该类型中所有编号更低的流也被打开。¶

2.2. 发送与接收 数据

STREAM 帧（第 19.8 节） 封装应用发送的数据。端点使用 STREAM 帧中的 Stream ID 和 Offset 字段将数据按顺序放置。¶

端点 MUST 能够将流数据作为有序 字节流交付给应用。交付有序字节流要求端点缓冲 任何乱序接收的数据，直至所通告的流量控制限制。¶

QUIC 未对乱序交付流数据作出具体 规定。不过，实现 MAY 选择向接收应用提供 乱序交付数据的能力。¶

端点可能会多次在相同流偏移处接收到某个流的数据。 已经接收过的数据可以丢弃。在给定偏移处的数据 如果被多次发送，则 MUST NOT 改变；端点 MAY 将在一个流内相同偏移处接收到不同数据 视为类型为 PROTOCOL_VIOLATION 的连接 错误。¶

流是一种有序字节流抽象，QUIC 看不到其他结构。 当数据被传输、因分组丢失而重传，或在接收方交付给 应用时，不期望保留 STREAM 帧边界。¶

端点在任何流上发送数据前，MUST NOT 不确保其处于 对等方设置的流量控制限制之内。流量控制在 第 4 节中有详细描述。¶

2.3. 流优先级

如果正确确定分配给流的资源优先级，流复用会对应用性能产生 显著影响。¶

QUIC 不提供交换优先级信息的机制。 相反，它依赖从应用接收优先级信息。¶

QUIC 实现 SHOULD 提供某些方式， 使应用能够指示 流的相对优先级。实现使用应用提供的信息 来确定如何向活跃流分配资源。¶

2.4. 流上的操作

本文档不定义 QUIC 的 API；而是定义一组 应用协议可以依赖的流上的功能。应用 协议可以假定 QUIC 实现提供的接口 包含本节描述的操作。为特定应用协议 使用而设计的实现，可能只提供该协议使用的那些操作。¶

在流的发送部分，应用协议可以：¶

• 写入数据，并了解何时已成功保留流量控制 信用 （第 4.1 节），以发送所写入的 数据；¶
• 结束流（干净终止），从而产生一个 设置了 FIN 比特的 STREAM 帧 （第 19.8 节）；以及¶
• 重置流（突然终止），如果该流尚未处于 终止状态，则产生一个 RESET_STREAM 帧 （第 19.4 节）。¶

在流的接收部分，应用协议可以：¶

• 读取数据；以及¶
• 中止读取流并请求关闭， 可能产生 STOP_SENDING 帧（第 19.5 节）。¶

应用协议还可以请求获知流上的状态变化， 包括对等方何时打开或重置了流、对等方 何时中止读取流、何时有新数据可用，以及何时由于流量控制而可以或 不可以向流写入数据。¶

3.1. 发送流状态

图 2显示流中向对等方 发送数据的部分的状态。¶

       o
       | 创建流（发送）
       | 对等方创建双向流
       v
   +-------+
   | Ready | 发送 RESET_STREAM
   |       |-----------------------.
   +-------+                       |
       |                           |
       | 发送 STREAM /             |
       |      STREAM_DATA_BLOCKED  |
       v                           |
   +-------+                       |
   | Send  | 发送 RESET_STREAM     |
   |       |---------------------->|
   +-------+                       |
       |                           |
       | 发送 STREAM + FIN         |
       v                           v
   +-------+                   +-------+
   | Data  | 发送 RESET_STREAM | Reset |
   | Sent  |------------------>| Sent  |
   +-------+                   +-------+
       |                           |
       | 接收全部 ACK              | 接收 ACK
       v                           v
   +-------+                   +-------+
   | Data  |                   | Reset |
   | Recvd |                   | Recvd |
   +-------+                   +-------+

由端点发起的流的发送部分（客户端的类型 0 和 2，服务器的类型 1 和 3）由应用打开。“Ready”状态表示 一个新创建的流，它能够接受来自 应用的数据。流数据可以在此状态下被缓冲，以准备 发送。¶

发送第一个 STREAM 或 STREAM_DATA_BLOCKED 帧会使流的发送部分 进入“Send”状态。实现可以选择推迟 为流分配流 ID，直到它发送第一个 STREAM 帧并 进入此状态，这样可以实现更好的流优先级处理。¶

由对等方发起的双向流的发送部分（服务器的类型 0， 客户端的类型 1）在接收部分 被创建时从“Ready”状态开始。¶

在“Send”状态中，端点在 STREAM 帧中传输——并在必要时重传—— 流数据。端点遵守其对等方设置的流量控制限制， 并继续接受和处理 MAX_STREAM_DATA 帧。处于 “Send”状态的端点如果因流量控制限制而被阻塞 无法发送（第 4.1 节），就会生成 STREAM_DATA_BLOCKED 帧。¶

在应用指示所有流数据均已发送，并且发送了 包含 FIN 比特的 STREAM 帧之后，该流的发送部分进入 “Data Sent”状态。从此状态起，端点仅在必要时重传流数据。 端点不需要为处于此状态的流检查流量控制限制或发送 STREAM_DATA_BLOCKED 帧。在对等方收到最终流偏移之前， 仍可能收到 MAX_STREAM_DATA 帧。对于此状态下的流， 端点可以安全地忽略从其对等方收到的任何 MAX_STREAM_DATA 帧。¶

一旦所有流数据都已被成功确认，该流的发送部分 进入“Data Recvd”状态，这是一个终止状态。¶

从“Ready”、“Send”或“Data Sent”中的任意状态，应用 都可以发出信号，表示它希望放弃流数据的传输。或者， 端点可能会从其对等方接收到 STOP_SENDING 帧。在这两种情况下， 端点都会发送 RESET_STREAM 帧，这会使流进入 “Reset Sent”状态。¶

端点 MAY 将 RESET_STREAM 作为第一个 提及某个流的帧发送； 这会使该流的发送部分打开，并立即 转换到“Reset Sent”状态。¶

一旦包含 RESET_STREAM 的分组被确认，该流的发送 部分进入“Reset Recvd”状态，这是一个终止状态。¶

3.2. 接收流 状态

图 3显示流中 从对等方接收数据的部分的状态。流的接收部分的状态仅 镜像对等方处流的发送部分的一部分状态。 流的接收部分不跟踪发送部分中无法被观察到的状态， 例如“Ready”状态。相反，流的接收部分 跟踪向应用交付数据的情况，其中有些无法由 发送方观察到。¶

       o
       | 接收 STREAM / STREAM_DATA_BLOCKED / RESET_STREAM
       | 创建双向流（发送）
       | 接收 MAX_STREAM_DATA / STOP_SENDING（双向）
       | 创建编号更高的流
       v
   +-------+
   | Recv  | 接收 RESET_STREAM
   |       |-----------------------.
   +-------+                       |
       |                           |
       | 接收 STREAM + FIN         |
       v                           |
   +-------+                       |
   | Size  | 接收 RESET_STREAM     |
   | Known |---------------------->|
   +-------+                       |
       |                           |
       | 接收全部数据              |
       v                           v
   +-------+ 接收 RESET_STREAM +-------+
   | Data  |--- （可选） ------>| Reset |
   | Recvd |  接收全部数据      | Recvd |
   +-------+<-- （可选） -------+-------+
       |                           |
       | 应用读取全部数据          | 应用读取重置
       v                           v
   +-------+                   +-------+
   | Data  |                   | Reset |
   | Read  |                   | Read  |
   +-------+                   +-------+

由对等方发起的流的接收部分（客户端的类型 1 和 3， 或服务器的类型 0 和 2）在收到该流的第一个 STREAM、STREAM_DATA_BLOCKED 或 RESET_STREAM 帧时被创建。对于 由对等方发起的双向流，接收针对该流 发送部分的 MAX_STREAM_DATA 或 STOP_SENDING 帧也会创建接收部分。流的 接收部分的初始状态为“Recv”。¶

对于双向流，当由端点发起的 发送部分（客户端的类型 0，服务器的类型 1）进入“Ready”状态时，接收部分进入“Recv”状态。¶

当从对等方收到针对某个双向流的 MAX_STREAM_DATA 或 STOP_SENDING 帧时，端点会打开该双向流。对于未打开的流收到 MAX_STREAM_DATA 帧表明远端对等方已经打开该 流，并正在提供流量控制信用。对于未打开的流收到 STOP_SENDING 帧表明远端对等方不再希望在此 流上接收数据。如果分组丢失或重排序，任一帧都可能在 STREAM 或 STREAM_DATA_BLOCKED 帧之前到达。¶

在创建一个流之前，所有具有更低编号 流 ID 的同类型流 MUST 都必须被创建。这确保 两个端点上的流创建顺序保持一致。¶

在“Recv”状态中，端点接收 STREAM 和 STREAM_DATA_BLOCKED 帧。传入数据会被缓冲，并可按正确顺序重新组装 以交付给应用。随着应用消耗数据且 缓冲空间变得可用，端点会发送 MAX_STREAM_DATA 帧， 以允许对等方发送更多数据。¶

当收到带有 FIN 比特的 STREAM 帧时，流的最终大小 即为已知；见 第 4.5 节。该流的接收部分 随后进入 “Size Known”状态。在此状态下，端点不再需要发送 MAX_STREAM_DATA 帧；它只接收流数据的任何重传。¶

一旦已收到该流的全部数据，接收部分便进入 “Data Recvd”状态。这可能因收到同一个使其转换到 “Size Known”的 STREAM 帧而发生。在收到全部数据之后， 可以丢弃该流的任何 STREAM 或 STREAM_DATA_BLOCKED 帧。¶

“Data Recvd”状态会持续到流数据已交付给 应用为止。一旦流数据已被交付，流进入“Data Read”状态，这是一个终止状态。¶

在“Recv”或“Size Known”状态收到 RESET_STREAM 帧会使 流进入“Reset Recvd”状态。这可能导致 向应用交付流数据被中断。¶

收到 RESET_STREAM 时，所有流数据可能已经被接收 （即处于“Data Recvd”状态）。同样，在收到 RESET_STREAM 帧（“Reset Recvd”状态）之后，剩余的流数据也可能到达。 实现可以自由选择如何处理这种 情况。¶

发送 RESET_STREAM 意味着端点无法保证 流数据的交付；但是，并没有要求在收到 RESET_STREAM 时 不得交付流数据。实现 MAY 中断 流数据的交付，丢弃任何未被消耗的数据，并发出已收到 RESET_STREAM 的信号。如果流数据已被完整接收并缓冲起来以供 应用读取，则 RESET_STREAM 信号可能被抑制或暂不发出。 如果 RESET_STREAM 被抑制，则该流的接收部分 保持在“Data Recvd”。¶

一旦应用收到表明该流 已被重置的信号，该流的接收部分就转换到“Reset Read” 状态，这是一个终止状态。¶

3.3. 允许的帧类型

流的发送方仅发送三种会影响发送方或接收方处 流状态的帧类型：STREAM（第 19.8 节）、 STREAM_DATA_BLOCKED（第 19.13 节）和 RESET_STREAM （第 19.4 节）。¶

发送方 MUST NOT 从终止状态 （“Data Recvd”或“Reset Recvd”）发送任何这些帧。发送方 MUST NOT 为处于“Reset Sent”状态或任何终止状态的流发送 STREAM 或 STREAM_DATA_BLOCKED 帧——也就是说，在发送 RESET_STREAM 帧之后不得发送。由于承载这些帧的分组 可能延迟交付，接收方可能在任何状态下收到这三种 帧中的任意一种。¶

流的接收方发送 MAX_STREAM_DATA 帧 （第 19.10 节）和 STOP_SENDING 帧（第 19.5 节）。¶

接收方只在“Recv”状态中发送 MAX_STREAM_DATA 帧。接收方 MAY 在尚未收到 RESET_STREAM 帧的任何状态中发送 STOP_SENDING 帧——也就是说，除“Reset Recvd”或 “Reset Read”以外的状态。不过，在“Data Recvd”状态中发送 STOP_SENDING 帧几乎没有价值，因为所有流数据 都已被接收。由于分组延迟交付，发送方可能在任何状态中收到 这两种帧中的任意一种。¶

3.4. 双向流 状态

双向流由发送部分和接收部分组成。 实现可以将双向流的状态表示为 发送流状态和接收流状态的组合。最简单的模型将流 表示为：当发送部分或接收部分任一处于非终止状态时为“open”， 当发送流和接收流均处于终止状态时为“closed”。¶

表 2显示了双向流状态的更复杂 映射，它大致对应于 HTTP/2 [HTTP2] 中定义的流状态。这表明， 流的发送部分或接收部分中的多个状态会映射到 相同的组合状态。注意，这只是这种映射的一种可能； 该映射要求数据在转换到“closed”或“half-closed”状态之前 被确认。¶

3.5. 受请求的状态 转换

如果应用不再关注它在某个 流上正在接收的数据，它可以中止读取该流并指定应用错误码。¶

如果流处于“Recv”或“Size Known”状态，则传输 SHOULD 通过发送 STOP_SENDING 帧来发出此信号，以促使相反方向的流关闭。 这通常表明接收应用 不再读取它从该流接收的数据，但这并不保证 传入数据会被忽略。¶

发送 STOP_SENDING 帧之后收到的 STREAM 帧仍然计入 连接和流的流量控制，即使这些帧可以在 收到时被丢弃。¶

STOP_SENDING 帧请求接收端点发送 RESET_STREAM 帧。收到 STOP_SENDING 帧的端点在流处于“Ready”或“Send”状态时 MUST 发送 RESET_STREAM 帧。如果流处于“Data Sent”状态，则端点 MAY 推迟发送 RESET_STREAM 帧，直到包含未完成数据的 分组被确认或被声明为丢失。如果任何未完成数据被声明为丢失，则端点 SHOULD 发送 RESET_STREAM 帧，而不是重传该数据。¶

端点 SHOULD 将 STOP_SENDING 帧中的错误码复制到它发送的 RESET_STREAM 帧中，但它可以使用任何应用错误码。发送 STOP_SENDING 帧的端点 MAY 忽略随后为该流收到的任何 RESET_STREAM 帧中的错误码。¶

STOP_SENDING SHOULD 只为尚未被对等方重置的 流发送。STOP_SENDING 对处于“Recv”或“Size Known” 状态的流最有用。¶

如果包含先前 STOP_SENDING 的分组丢失，则预期端点会 发送另一个 STOP_SENDING 帧。不过，一旦该流的所有流 数据或 RESET_STREAM 帧已经被接收——也就是说， 该流处于“Recv”或“Size Known”以外的任何状态——发送 STOP_SENDING 帧就是不必要的。¶

希望终止双向流两个方向的端点 可以通过发送 RESET_STREAM 帧来终止一个方向，并可以 通过发送 STOP_SENDING 帧来促使相反方向尽快终止。¶

4.1. 数据流量控制

QUIC 采用基于限制的流量控制方案，其中接收方通告 它准备在给定流上或整个连接上接收的 总字节数限制。这导致 QUIC 中存在两个层级的数据流量控制：¶

• 流流量控制，它通过限制可在每个流上 发送的数据量，防止单个流消耗连接的整个 接收缓冲区。¶
• 连接流量控制，它通过限制所有流中 在 STREAM 帧中发送的流数据总字节数，防止发送方 超过接收方的连接缓冲容量。¶

发送方 MUST NOT 发送超过任一 限制的数据。¶

接收方在握手期间通过传输参数 为所有流设置初始限制（第 7.4 节）。 随后，接收方发送 MAX_STREAM_DATA 帧（第 19.10 节）或 MAX_DATA 帧 （第 19.9 节）给发送方，以通告更大的 限制。¶

接收方可以通过发送带有相应流 ID 的 MAX_STREAM_DATA 帧来为某个流通告更大的限制。MAX_STREAM_DATA 帧 表示流的最大绝对字节偏移。接收方可以 根据该流上当前已消耗数据的偏移 来确定要通告的流量控制偏移。¶

接收方可以通过发送 MAX_DATA 帧来为连接通告更大的限制，该帧表示 所有流的绝对字节偏移之和的最大值。接收方维护 所有流上已接收字节的累计和，用于检查是否违反 已通告的连接或流数据限制。接收方可以根据 所有流上已消耗字节之和来确定要通告的最大数据限制。¶

一旦接收方为连接或流通告了限制，通告 更小的限制并不是错误，但更小的限制没有效果。¶

如果发送方违反已通告的连接或流数据限制，接收方 MUST 以类型为 FLOW_CONTROL_ERROR 的错误 关闭连接；关于错误处理的详细信息见 第 11 节。¶

发送方 MUST 忽略任何不会增加 流量控制限制的 MAX_STREAM_DATA 或 MAX_DATA 帧。¶

如果发送方已经发送到限制为止，它将无法发送新数据 并被视为阻塞。发送方 SHOULD 发送 STREAM_DATA_BLOCKED 或 DATA_BLOCKED 帧，以向接收方表明它有数据要写入但受到 流量控制限制阻塞。如果发送方被阻塞的时间超过 空闲超时（第 10.1 节），即使发送方有可用于传输的数据， 接收方也可能关闭连接。为防止 连接关闭，受流量控制限制的发送方在没有 正在传输的触发 ACK 的分组时，SHOULD 定期发送 STREAM_DATA_BLOCKED 或 DATA_BLOCKED 帧。¶

4.2. 增加流量 控制限制

实现决定何时以及通告多少信用 于 MAX_STREAM_DATA 和 MAX_DATA 帧中，但本节提供若干考虑事项。¶

为避免阻塞发送方，接收方 MAY 在一个 往返时间内多次发送 MAX_STREAM_DATA 或 MAX_DATA 帧，或足够早地发送它，以留出时间应对 该帧丢失和随后的恢复。¶

控制帧会造成连接开销。因此，频繁 发送只带有小幅变化的 MAX_STREAM_DATA 和 MAX_DATA 帧并不可取。另一方面，如果更新不够频繁， 就需要更大幅度地增加限制，以避免阻塞发送方， 这要求接收方承担更大的资源承诺。 在确定通告多大的限制时，资源承诺和开销之间存在权衡。¶

接收方可以使用自调优机制，根据往返时间估计和 接收应用消耗数据的速率，调节所通告附加信用的频率和数量， 类似于常见 TCP 实现。作为一种优化，端点可以只在有其他帧要发送时 发送与流量控制相关的帧，从而确保流量 控制不会导致发送额外的分组。¶

被阻塞的发送方并不需要发送 STREAM_DATA_BLOCKED 或 DATA_BLOCKED 帧。因此，接收方 MUST NOT 在发送 MAX_STREAM_DATA 或 MAX_DATA 帧之前等待 STREAM_DATA_BLOCKED 或 DATA_BLOCKED 帧；这样做可能导致发送方在连接余下期间都被阻塞。 即使发送方发送这些帧，等待它们也会导致发送方 至少被阻塞整整一个往返时间。¶

当发送方在被阻塞后收到信用时，它可能能够 立即发送大量数据，从而造成短期拥塞；关于发送方如何避免这种 拥塞的讨论，见 第 7.7 节，见 [QUIC-RECOVERY]。¶

4.3. 流量控制 性能

如果端点无法确保其对等方在此连接上始终拥有 大于该对等方带宽时延积的可用流量控制 信用，则其接收吞吐量将受限于流量控制。¶

分组丢失会在接收缓冲区中造成空洞，从而阻止应用 消耗数据并释放接收缓冲空间。¶

及时发送流量控制限制更新可以提升性能。 仅为提供流量控制更新而发送分组会增加网络 负载并对性能产生不利影响。将流量控制更新与 其他帧（例如 ACK 帧）一起发送，可以降低这些更新的成本。¶

4.4. 处理流 取消

端点最终需要就每个流上已消耗的流量控制信用量 达成一致，以便能够统计连接级流量控制的 所有字节。¶

收到 RESET_STREAM 帧后，端点将拆除匹配流的状态， 并忽略随后到达该流的更多数据。¶

RESET_STREAM 会突然终止流的一个方向。对于 双向 流，RESET_STREAM 不影响相反方向的数据流。两个 端点 MUST 为该流中未终止 方向维护流量控制状态，直到该方向进入终止状态。¶

4.5. 流最终大小

最终大小是流消耗的流量控制信用量。 假设流上的每个连续字节都只发送一次，则 最终大小就是已发送的字节数。更一般地说， 这是流上发送的最大偏移字节的偏移加一；如果 没有发送任何字节，则为零。¶

发送方始终可靠地向接收方传达流的最终大小， 无论该流以何种方式终止。最终大小是带有 FIN 标志的 STREAM 帧的 Offset 和 Length 字段之和，需要注意 这些字段可能是隐式的。或者，RESET_STREAM 帧的 Final Size 字段承载此值。这保证两个端点就 发送方在该流上消耗了多少流量控制信用达成一致。¶

当流的接收部分进入“Size Known”或“Reset Recvd”状态 （第 3 节）时，端点将知道该流的最终大小。接收方 MUST 使用流的最终大小，在其连接级流量控制器中 统计该流上发送的所有字节。¶

端点 MUST NOT 在流的最终大小处或 之后发送数据。¶

一旦知道流的最终大小，它就不能改变。如果收到的 RESET_STREAM 或 STREAM 帧表明该流的最终大小发生变化，则端点 SHOULD 以类型为 FINAL_SIZE_ERROR 的错误作出响应； 关于错误处理的详细信息见 第 11 节。接收方 SHOULD 将在最终大小处或之后接收到数据 视为类型为 FINAL_SIZE_ERROR 的错误，即使流已经关闭也是如此。生成这些错误并非 强制要求，因为要求端点生成这些错误也意味着 端点需要为已关闭的流维护最终大小状态， 这可能意味着显著的状态承诺。¶

4.6. 控制 并发

端点限制对等方可以打开的传入流的累计数量。 只有流 ID 小于 (max_streams * 4 + first_stream_id_of_type) 的流才能被打开；见 表 1。初始 限制在传输参数中设置；见 第 18.2 节。后续限制使用 MAX_STREAMS 帧通告；见 第 19.11 节。单向流和双向流 适用单独的限制。¶

如果接收到的 max_streams 传输参数或 MAX_STREAMS 帧的值 大于 2⁶⁰，这将允许一个 无法表示为可变长度整数的最大流 ID；见 第 16 节。如果 收到其中任一项，则连接 MUST 立即关闭，并使用 连接 错误：如果违规值是在传输参数中收到的，则类型为 TRANSPORT_PARAMETER_ERROR；如果是在 帧中收到的，则类型为 FRAME_ENCODING_ERROR；见 第 10.2 节。¶

端点 MUST NOT 超过其 对等方设置的限制。收到带有超过其已发送限制的流 ID 的帧的端点 MUST 将 此视为类型为 STREAM_LIMIT_ERROR 的连接错误；关于错误处理的详细信息，见 第 11 节。¶

一旦接收方使用 MAX_STREAMS 帧通告了流限制， 通告更小的限制没有效果。不会 增加流限制的 MAX_STREAMS 帧 MUST 被忽略。¶

与流和连接流量控制一样，本文档将 何时以及应通过 MAX_STREAMS 向对等方通告多少流的决定 留给实现。实现可以选择在 流关闭时增加限制，以使对等方可用的流数量大致 保持一致。¶

因对等方限制而无法打开新流的端点 SHOULD 发送 STREAMS_BLOCKED 帧（第 19.14 节）。 此信号被认为有助于调试。端点 MUST NOT 等待接收 此 信号之后才通告附加信用，因为这样做将意味着 对等方至少被阻塞整整一个往返时间，并且如果对等方选择不发送 STREAMS_BLOCKED 帧，则可能无限期阻塞。¶

5.1. 连接 ID

每个连接拥有一组连接标识符，或称连接 ID， 每个连接 ID 都可以标识该连接。连接 ID 由端点独立 选择；每个端点选择其对等方使用的连接 ID。¶

连接 ID 的主要功能是确保 较低协议层（UDP、IP）中的地址变化不会导致 QUIC 连接的分组被递送到错误的端点。每个端点 使用一种特定于实现（也许还特定于部署）的方法选择 连接 ID，该方法允许带有该连接 ID 的分组 被路由回该端点，并在收到时由该端点识别。¶

使用多个连接 ID 是为了使端点能够发送 不会被观察者在没有端点协作的情况下识别为属于同一连接的 分组；见 第 9.5 节。¶

连接 ID MUST NOT 包含任何 可被外部 观察者（即不与签发方协作的观察者）用于将它们 与同一连接的其他连接 ID 相关联的信息。举一个简单例子， 这意味着同一个连接 ID 在同一 连接上 MUST NOT 被签发超过一次。¶

带长报头的分组包含 Source Connection ID 和 Destination Connection ID 字段。这些字段用于为新连接设置连接 ID； 详情见 第 7.2 节。¶

带短报头的分组（第 17.3 节）只包含 Destination Connection ID 并省略显式长度。端点预期知道 Destination Connection ID 字段的长度。使用基于连接 ID 路由的 负载均衡器的端点可以与负载均衡器约定连接 ID 的固定长度， 或约定一种编码方案。 固定部分可以编码显式长度，这使整个 连接 ID 能够在长度上变化，并且仍可被负载均衡器使用。¶

Version Negotiation（第 17.2.1 节）分组会回显客户端 选择的连接 ID，既用于确保正确路由到客户端，也用于 表明该分组是对客户端所发送分组的响应。¶

当不需要连接 ID 来路由到正确端点时，可以使用零长度连接 ID。 不过，在使用零长度连接 ID 的同时， 在同一本地 IP 地址和端口上复用连接，会在存在对等方连接迁移、 NAT 重新绑定以及客户端端口复用时导致失败。端点 MUST NOT 为多个 使用零长度连接 ID 的并发连接使用相同的 IP 地址和端口，除非它确信 那些协议特性未被使用。¶

当端点使用非零长度连接 ID 时，它需要确保 对等方拥有可供选择的连接 ID 供应，用于发往 该端点的分组。这些连接 ID 由端点使用 NEW_CONNECTION_ID 帧提供（第 19.15 节）。¶

5.2. 将分组匹配到 连接

传入分组在接收时被分类。分组可以 与现有连接相关联，或者——对于服务器——可能创建一个新 连接。¶

端点会尝试将分组与现有连接相关联。如果分组 具有对应现有连接的非零长度 Destination Connection ID， QUIC 就会相应地处理该分组。注意，一个连接 可以关联多个连接 ID；见 第 5.1 节。¶

如果 Destination Connection ID 为零长度，且分组中的寻址信息 与端点用于标识零长度连接 ID 连接的寻址信息匹配， QUIC 就会将该分组作为该 连接的一部分处理。端点可以仅使用目的 IP 和端口，也可以同时使用 源地址和目的地址进行标识，尽管这会使 连接变得脆弱，如 第 5.1 节所述。¶

端点可以针对任何无法归属于现有连接的分组发送 Stateless Reset （第 10.3 节）。 Stateless Reset 允许对等方更快识别连接何时变得不可用。¶

如果与现有连接匹配的分组 与该连接的状态不一致，则这些分组会被丢弃。例如，如果分组 指示的协议版本不同于该连接的 版本，或者在预期密钥可用后移除分组保护失败，则丢弃分组。¶

缺乏强完整性保护的无效分组，例如 Initial、Retry 或 Version Negotiation，MAY 被丢弃。端点在处理这些分组的内容后才 发现错误时，MUST 生成 连接错误，或者完全回滚该处理期间所做的任何更改。¶

5.3. 连接上的 操作

本文档不定义 QUIC 的 API；而是定义一组 应用协议可以依赖的 QUIC 连接功能。 应用协议可以假定 QUIC 实现提供的 接口包含本节描述的操作。为特定应用协议 使用而设计的实现可能只提供该协议使用的那些操作。¶

在实现客户端角色时，应用协议可以：¶

• 打开连接，这会开始 第 7 节中描述的交换；¶
• 在 Early Data 可用时启用它；以及¶
• 获知 Early Data 是否已被服务器接受或 拒绝。¶

在实现服务器角色时，应用协议可以：¶

• 监听传入连接，这会准备进行 第 7 节中描述的交换；¶
• 如果支持 Early Data，则在发送给客户端的 TLS 恢复票据中嵌入由应用控制的数据；以及¶
• 如果支持 Early Data，则从客户端的 恢复票据中取回由应用控制的数据，并基于该 信息接受或拒绝 Early Data。¶

在任一角色中，应用协议可以：¶

• 配置每种类型允许的初始流数量的 最小值，如传输参数（第 7.4 节）中传达的那样；¶
• 通过为流和连接 设置流量控制限制来控制接收缓冲区的资源分配；¶
• 识别握手是否已经成功完成 或仍在进行；¶
• 通过生成 PING 帧 （第 19.2 节）或请求传输在空闲超时到期之前 发送额外帧 （第 10.1 节），防止连接静默关闭； 以及¶
• 立即关闭（第 10.2 节）连接。¶

6.1. 发送版本 协商分组

如果客户端选择的版本不可被服务器接受，则 服务器以 Version Negotiation 分组响应；见 第 17.2.1 节。这 包含服务器将接受的版本列表。端点 MUST NOT 响应收到的 Version Negotiation 分组而发送 Version Negotiation 分组。¶

此系统允许服务器在不保留状态的情况下处理 使用不支持版本的分组。虽然 Initial 分组或作为响应发送的 Version Negotiation 分组都可能丢失，但客户端会持续发送新分组， 直到成功收到响应或放弃连接尝试。¶

服务器 MAY 限制其发送的 Version Negotiation 分组数量。例如，能够将分组识别为 0-RTT 的服务器，可以选择不响应 0-RTT 分组发送 Version Negotiation 分组，并预期它最终会收到 Initial 分组。¶

6.2. 处理版本 协商分组

Version Negotiation 分组被设计为允许未来定义 使 QUIC 能够协商连接所用 QUIC 版本的功能。 未来的标准轨道规范可能会改变支持多个 QUIC 版本的实现 对响应使用此版本建立连接的尝试而收到的 Version Negotiation 分组的反应方式。¶

只支持此版本 QUIC 的客户端在收到 Version Negotiation 分组时，MUST 放弃当前 连接尝试，但有以下两个例外。如果客户端已经收到并成功处理了 任何其他分组，包括较早的 Version Negotiation 分组，则客户端 MUST 丢弃任何 Version Negotiation 分组。 如果 Version Negotiation 分组列出了客户端所选择的 QUIC 版本， 客户端 MUST 丢弃该 Version Negotiation 分组。¶

如何执行版本协商留待未来由标准轨道规范定义。 特别是，未来的工作将确保其对版本降级攻击具有鲁棒性；见 第 21.12 节。¶

6.3. 使用保留 版本

为了使服务器将来能够使用新版本，客户端需要正确 处理不支持的版本。某些版本号（0x?a?a?a?a，如 第 15 节所定义）被保留，用于包含版本 号的字段。¶

端点 MAY 在未知或不支持的 版本会被忽略的任何字段中添加保留版本，以测试对等方是否正确 忽略该值。例如，端点可以在 Version Negotiation 分组中包含保留版本；见 第 17.2.1 节。端点 MAY 发送带有保留 版本的分组，以测试对等方是否正确丢弃该分组。¶

7.1. 示例握手 流程

TLS 如何与 QUIC 集成的细节见 [QUIC-TLS]， 但这里也提供一些示例。支持客户端地址验证的该交换扩展 显示在 第 8.1.2 节。¶

一旦任何地址验证交换完成，就使用 加密握手来就加密密钥达成一致。加密握手承载于 Initial（第 17.2.2 节）和 Handshake （第 17.2.4 节）分组中。¶

图 5概述了 1-RTT 握手。每一行 显示一个 QUIC 分组，先显示分组类型和分组编号，随后显示 这些分组通常包含的帧。例如， 第一个分组的类型为 Initial，分组编号为 0，并包含携带 ClientHello 的 CRYPTO 帧。¶

多个 QUIC 分组——即使是不同分组类型——可以被合并 到单个 UDP 数据报中；见 第 12.2 节。 因此，此握手可以只由四个 UDP 数据报组成，也可以由更多数量的数据报组成 （受协议固有限制约束，例如拥塞控制和 反放大）。例如，服务器的第一轮发送包含 Initial 分组、Handshake 分组以及 1-RTT 分组中的“0.5-RTT 数据”。¶

客户端                                                  服务器

Initial[0]: CRYPTO[CH] ->

                                 Initial[0]: CRYPTO[SH] ACK[0]
                       Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
                                 <- 1-RTT[0]: STREAM[1, "..."]

Initial[1]: ACK[0]
Handshake[0]: CRYPTO[FIN], ACK[0]
1-RTT[0]: STREAM[0, "..."], ACK[0] ->

                                          Handshake[1]: ACK[0]
         <- 1-RTT[1]: HANDSHAKE_DONE, STREAM[3, "..."], ACK[0]

图 6显示了一个 带有 0-RTT 握手和单个 0-RTT 数据分组的连接示例。 注意，如 第 12.3 节所述， 服务器在 1-RTT 分组中确认 0-RTT 数据，并且 客户端在同一分组编号空间中发送 1-RTT 分组。¶

客户端                                                  服务器

Initial[0]: CRYPTO[CH]
0-RTT[0]: STREAM[0, "..."] ->

                                 Initial[0]: CRYPTO[SH] ACK[0]
                                  Handshake[0] CRYPTO[EE, FIN]
                          <- 1-RTT[0]: STREAM[1, "..."] ACK[0]

Initial[1]: ACK[0]
Handshake[0]: CRYPTO[FIN], ACK[0]
1-RTT[1]: STREAM[0, "..."] ACK[0] ->

                                          Handshake[1]: ACK[0]
         <- 1-RTT[1]: HANDSHAKE_DONE, STREAM[3, "..."], ACK[1]

7.2. 协商连接 ID

连接 ID 用于确保分组的一致路由，如 第 5.1 节所述。长报头包含两个连接 ID：Destination Connection ID 由分组的接收方选择，并用于提供 一致路由；Source Connection ID 用于设置对等方所使用的 Destination Connection ID。¶

在握手期间，带长报头（第 17.2 节）的分组用于 建立两个端点使用的连接 ID。每个端点使用 Source Connection ID 字段指定在发往它们的分组的 Destination Connection ID 字段中使用的连接 ID。在处理 第一个 Initial 分组后，每个端点会将其随后发送的分组中的 Destination Connection ID 字段设置为它收到的 Source Connection ID 字段的值。¶

当客户端发送 Initial 分组且此前尚未从服务器收到 Initial 或 Retry 分组时，客户端会用不可预测的值填充 Destination Connection ID 字段。此 Destination Connection ID MUST 至少为 8 字节长。在从服务器收到分组之前， 客户端 MUST 在此连接的所有分组中使用相同的 Destination Connection ID 值。¶

客户端发送的第一个 Initial 分组中的 Destination Connection ID 字段 用于确定 Initial 分组的分组保护密钥。收到 Retry 分组后， 这些密钥会改变；见 第 5.2 节 ，见 [QUIC-TLS]。¶

客户端用自己选择的值填充 Source Connection ID 字段， 并设置 Source Connection ID Length 字段以指示长度。¶

第一轮发送中的 0-RTT 分组使用与客户端第一个 Initial 分组相同的 Destination Connection ID 和 Source Connection ID 值。¶

在首次从服务器收到 Initial 或 Retry 分组时，客户端会使用 服务器提供的 Source Connection ID 作为后续分组的 Destination Connection ID， 包括任何 0-RTT 分组。这意味着客户端在连接建立期间 可能必须两次更改其在 Destination Connection ID 字段中设置的连接 ID：一次是响应 Retry 分组， 另一次是响应来自服务器的 Initial 分组。一旦客户端 收到来自服务器的有效 Initial 分组，它 MUST 丢弃 随后在该连接上收到的任何带有不同 Source Connection ID 的 分组。¶

客户端 MUST 只响应首次收到的 Initial 或 Retry 分组，更改它用于发送分组的 Destination Connection ID。 服务器 MUST 根据首次收到的 Initial 分组设置它用于发送分组的 Destination Connection ID。只有当值来自 NEW_CONNECTION_ID 帧时，才允许 对 Destination Connection ID 进行任何后续更改；如果 后续 Initial 分组包含不同的 Source Connection ID，则它们 MUST 被丢弃。这避免了对多个带有不同 Source Connection ID 的 Initial 分组进行无状态处理时可能产生的 不可预测结果。¶

端点发送的 Destination Connection ID 可以在连接的生命周期中改变， 尤其是在响应连接迁移 （第 9 节）时；详情见 第 5.1.1 节。¶

7.3. 认证 连接 ID

每个端点在握手期间对连接 ID 所作的选择 通过在传输参数中包含所有值来认证；见 第 7.4 节。这确保用于 握手的所有连接 ID 也由加密握手进行认证。¶

每个端点都会在 initial_source_connection_id 传输 参数中包含它发送的第一个 Initial 分组的 Source Connection ID 字段值； 见 第 18.2 节。服务器会在 original_destination_connection_id 传输参数中包含它从 客户端收到的第一个 Initial 分组的 Destination Connection ID 字段； 如果服务器发送了 Retry 分组，则这里指的是在发送 Retry 分组之前收到的 第一个 Initial 分组。如果服务器发送 Retry 分组，还会在 retry_source_connection_id 传输参数中包含 Retry 分组的 Source Connection ID 字段。¶

对等方为这些传输参数提供的值 MUST 与 端点在其发送（以及服务器接收）的 Initial 分组的 Destination 和 Source Connection ID 字段中使用的值相匹配。 端点 MUST 验证收到的传输参数与收到的连接 ID 值匹配。 在传输参数中包含连接 ID 值并对其进行验证， 可确保攻击者无法通过在握手期间注入携带攻击者所选连接 ID 的分组来影响成功连接的连接 ID 选择。¶

端点 MUST 将任一端点缺少 initial_source_connection_id 传输 参数，或服务器缺少 original_destination_connection_id 传输参数的情况，视为 类型为 TRANSPORT_PARAMETER_ERROR 的连接错误。¶

端点 MUST 将以下情况视为 类型为 TRANSPORT_PARAMETER_ERROR 或 PROTOCOL_VIOLATION 的连接错误：¶

• 在收到 Retry 分组后，服务器缺少 retry_source_connection_id 传输 参数，¶
• 在未收到 Retry 分组时存在 retry_source_connection_id 传输 参数，或¶
• 从对等方在这些传输参数中收到的值 与 Initial 分组中相应 Destination 或 Source Connection ID 字段中发送的值不匹配。¶

如果选择了零长度连接 ID，则对应的传输 参数以零长度值包含。¶

图 7显示完整握手中使用的连接 ID （其中 DCID=Destination Connection ID， SCID=Source Connection ID）。图中显示了 Initial 分组的交换， 以及之后包含握手期间建立的连接 ID 的 1-RTT 分组交换。¶

客户端                                                  服务器

Initial: DCID=S1, SCID=C1 ->
                                  <- Initial: DCID=C1, SCID=S3
                             ...
1-RTT: DCID=S3 ->
                                             <- 1-RTT: DCID=C1

图 8显示了一个 包含 Retry 分组的类似握手。¶

客户端                                                  服务器

Initial: DCID=S1, SCID=C1 ->
                                    <- Retry: DCID=C1, SCID=S2
Initial: DCID=S2, SCID=C1 ->
                                  <- Initial: DCID=C1, SCID=S3
                             ...
1-RTT: DCID=S3 ->
                                             <- 1-RTT: DCID=C1

在两种情况下（图 7 和 8），客户端都会将 initial_source_connection_id 传输参数的值设置为 C1。¶

当握手不包含 Retry（图 7）时，服务器将 original_destination_connection_id 设置为 S1（注意该值由 客户端选择），并将 initial_source_connection_id 设置为 S3。在这种情况下，服务器 不包含 retry_source_connection_id 传输参数。¶

当握手包含 Retry（图 8）时，服务器将 original_destination_connection_id 设置为 S1，将 retry_source_connection_id 设置为 S2， 并将 initial_source_connection_id 设置为 S3。¶

7.4. 传输参数

在连接建立期间，两个端点都会对其传输参数作出 经过认证的声明。端点需要遵守 每个参数所定义的限制；每个参数的描述 都包含其处理规则。¶

传输参数是由每个端点单方面作出的声明。 每个端点可以独立于其对等方所选择的值来选择 传输参数的值。¶

传输参数的编码详见 第 18 节。¶

QUIC 在加密握手中包含编码后的传输参数。 一旦握手完成，对等方声明的传输参数就可用。 每个端点都会验证其对等方提供的值。¶

每个已定义传输参数的定义包含在 第 18.2 节中。¶

端点 MUST 将收到值无效的传输 参数视为类型为 TRANSPORT_PARAMETER_ERROR 的连接错误。¶

端点 MUST NOT 在给定传输 参数扩展中多次发送同一参数。端点 SHOULD 将收到重复 传输参数视为类型为 TRANSPORT_PARAMETER_ERROR 的连接错误。¶

端点使用传输参数来认证握手期间的 连接 ID 协商；见 第 7.3 节。¶

ALPN（见 [ALPN]）允许客户端 在连接建立期间提供多个应用 协议。客户端在握手期间包含的传输参数适用于 该客户端提供的所有应用协议。应用协议可以为传输 参数推荐值，例如初始流量控制限制。不过， 对传输参数值设置约束的应用协议，如果这些 约束发生冲突，可能会使客户端无法提供多个应用协议。¶

7.5. 加密消息 缓冲

实现需要维护一个缓冲区，用于接收乱序到达的 CRYPTO 数据。由于 CRYPTO 帧没有流量控制，端点 可能迫使其对等方缓冲无界数量的数据。¶

实现 MUST 支持至少缓冲 4096 字节的乱序 CRYPTO 帧中接收的数据。端点 MAY 选择允许在握手期间缓冲更多数据。 握手期间较大的限制可以允许交换更大的密钥或凭据。 端点的缓冲区大小无需在连接生命周期内保持不变。¶

握手期间无法缓冲 CRYPTO 帧可能导致 连接失败。如果端点的缓冲区在握手期间被超出， 它可以临时扩展缓冲区以完成握手。如果端点 不扩展其缓冲区，它 MUST 以 CRYPTO_BUFFER_EXCEEDED 错误码关闭连接。¶

一旦握手完成，如果端点无法缓冲 CRYPTO 帧中的所有数据， 它 MAY 丢弃该 CRYPTO 帧以及未来收到的所有 CRYPTO 帧， 或者它 MAY 以 CRYPTO_BUFFER_EXCEEDED 错误 码关闭连接。包含被丢弃 CRYPTO 帧的分组 MUST 被确认，因为 即使 CRYPTO 帧被丢弃，该分组也已被传输层接收和处理。¶

8.1. 连接建立期间的 地址验证

连接建立隐式地为两个端点提供地址验证。 特别是，收到一个受 Handshake 密钥保护的分组， 就确认对等方已经成功处理了 Initial 分组。一旦 端点成功处理了来自对等方的 Handshake 分组，它就可以 将对等方地址视为已经验证。¶

此外，如果对等方使用由端点选择的连接 ID， 且该连接 ID 至少包含 64 比特熵，则端点 MAY 将对等方地址视为已验证。¶

对于客户端而言，其第一个 Initial 分组中 Destination Connection ID 字段的值，允许其在成功处理任何分组时将服务器地址作为其中一部分进行验证。 来自服务器的 Initial 分组使用从该值派生的密钥保护（见 第 5.2 节 ，见 [QUIC-TLS]）。或者，该值会由服务器在 Version Negotiation 分组（第 6 节）中回显，或包含在 Retry 分组的 Integrity Tag 中（第 5.8 节，见 [QUIC-TLS]）。¶

在验证客户端地址之前，服务器 MUST NOT 发送超过其已接收字节数三倍的数据。 这限制了使用欺骗性源地址能够发起的任何放大攻击的规模。 为避免地址验证之前的放大，服务器 MUST 统计所有唯一归属于单个连接的数据报中收到的载荷字节。 这包括包含成功处理分组的数据报，以及包含的分组全部 被丢弃的数据报。¶

客户端 MUST 确保包含 Initial 分组的 UDP 数据报具有至少 1200 字节的 UDP 载荷，并按需添加 PADDING 帧。 发送填充数据报的客户端允许服务器在完成地址验证前 发送更多数据。¶

如果客户端没有发送额外的 Initial 或 Handshake 分组， 服务器的 Initial 或 Handshake 分组丢失可能导致死锁。当服务器达到 反放大限制，而客户端已经收到对其发送的所有数据的确认时， 可能出现死锁。在这种情况下，当客户端没有理由再发送额外分组时， 服务器将无法发送更多数据，因为它尚未验证客户端的地址。 为防止这种死锁，客户端 MUST 在探测超时（PTO）时发送分组； 见 第 6.2 节，见 [QUIC-RECOVERY]。 具体而言，如果客户端没有 Handshake 密钥，它 MUST 发送一个 包含至少 1200 字节的 UDP 数据报中的 Initial 分组；否则发送 Handshake 分组。¶

服务器可能希望在开始加密握手之前验证客户端地址。 QUIC 使用 Initial 分组中的令牌，以在完成握手之前提供 地址验证。该令牌会在连接建立期间通过 Retry 分组交付给 客户端（见 第 8.1.2 节），或在先前连接中使用 NEW_TOKEN 帧交付（见 第 8.1.3 节）。¶

除了地址验证之前施加的发送限制外，服务器还受到 拥塞控制器所设限制的约束。客户端仅受拥塞控制器约束。¶

客户端                                                  服务器

Initial[0]: CRYPTO[CH] ->

                                                <- Retry+Token

Initial+Token[1]: CRYPTO[CH] ->

                                 Initial[0]: CRYPTO[SH] ACK[1]
                       Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
                                 <- 1-RTT[0]: STREAM[1, "..."]

8.2. 路径验证

路径验证由两个对等方在连接迁移期间使用 （见 第 9 节），以在地址变化后验证可达性。 在路径验证中，端点测试特定本地地址与特定对等方地址之间的可达性， 其中地址是 IP 地址和端口组成的二元组。¶

路径验证测试在通向对等方的路径上发送的分组是否被该 对等方接收。路径验证用于确保从迁移的对等方收到的分组 不携带欺骗性源地址。¶

路径验证不会验证对等方能否在返回方向发送。 确认不能用于返回路径验证，因为其中包含的熵不足， 且可能被伪造。端点独立地确定路径每个方向上的可达性， 因此返回可达性只能由对等方建立。¶

路径验证可以由任一端点在任何时候使用。例如，端点 可能在一段静默期后检查对等方是否仍然拥有其地址。¶

路径验证并非设计为 NAT 穿越机制。尽管这里描述的 机制可能有效创建支持 NAT 穿越的 NAT 绑定，但其预期是 其中一个端点能够在未先在该路径上发送分组的情况下接收分组。 有效的 NAT 穿越需要这里未提供的额外同步机制。¶

端点 MAY 将其他帧与用于路径验证的 PATH_CHALLENGE 和 PATH_RESPONSE 帧一起包含。特别是，端点可以将 PADDING 帧与 PATH_CHALLENGE 帧一起包含，用于路径最大传输单元发现 （PMTUD）；见 第 14.2.1 节。端点在发送 PATH_RESPONSE 帧时也可以包含自己的 PATH_CHALLENGE 帧。¶

端点对从新的本地地址发送的探测使用新的连接 ID； 见 第 9.5 节。探测新路径时，端点可以 确保其对等方有一个未使用的连接 ID 可用于响应。 如果对等方的 active_connection_id_limit 允许，在同一分组中发送 NEW_CONNECTION_ID 和 PATH_CHALLENGE 帧，可确保对等方在发送响应时 有一个未使用的连接 ID 可用。¶

端点可以选择同时探测多条路径。用于探测的 同时路径数量受到其对等方先前提供的额外连接 ID 数量限制， 因为用于探测的每个新本地地址都需要一个先前未使用的连接 ID。¶

9.1. 探测新路径

端点 MAY 在将连接迁移到新的本地地址之前， 使用路径验证（第 8.2 节） 从新本地地址探测对等方可达性。路径验证失败只意味着新路径 不可用于此连接。无法验证路径不会导致连接结束，除非 没有可用的有效替代路径。¶

PATH_CHALLENGE、PATH_RESPONSE、NEW_CONNECTION_ID 和 PADDING 帧是 “探测帧”，所有其他帧是“非探测帧”。只包含探测帧的分组是 “探测分组”，包含任何其他帧的分组是“非探测分组”。¶

9.2. 发起连接 迁移

端点可以通过从新的本地地址发送包含非探测帧的分组， 将连接迁移到该新本地地址。¶

每个端点在连接建立期间都会验证其对等方地址。 因此，迁移端点可以在知道对等方愿意在其当前地址接收时 向对等方发送。这样，端点就可以迁移到新的本地地址， 而无需先验证对等方地址。¶

为在新路径上建立可达性，端点在新路径上发起路径 验证（第 8.2 节）。端点 MAY 将路径验证推迟到对等方向其新地址发送下一个 非探测帧之后。¶

迁移时，新路径可能不支持端点当前的发送速率。 因此，端点会重置其拥塞控制器和 RTT 估计， 如 第 9.4 节所述。¶

新路径可能不具有相同的 ECN 能力。因此，端点 按 第 13.4 节所述验证 ECN 能力。¶

9.3. 响应连接 迁移

从新的对等方地址收到包含非探测帧的分组，表明 对等方已经迁移到该地址。¶

如果接收方允许迁移，它 MUST 将后续分组发送到新的对等方地址，并且如果验证尚未开始， MUST 发起路径验证（第 8.2 节） 以验证对等方对该地址的拥有。如果接收方没有来自对等方的未使用连接 ID， 则在对等方提供连接 ID 之前，它无法在新路径上发送任何内容；见 第 9.5 节。¶

端点只会响应编号最大的非探测分组来更改其发送分组的地址。 这确保端点在收到重排序分组时不会向旧的对等方地址发送分组。¶

端点 MAY 向未验证的对等方地址发送数据， 但它 MUST 按第 9.3.1 和 9.3.2 节所述防范潜在攻击。端点 MAY 如果最近见过某个对等方地址，则跳过对该地址的验证。 特别是，如果端点在检测到某种形式的虚假迁移后返回 先前已验证的路径，跳过地址验证并恢复丢包检测和拥塞状态 可以降低攻击对性能的影响。¶

在更改其发送非探测分组的地址后，端点 可以放弃针对其他地址的任何路径验证。¶

从新的对等方地址收到分组可能是对等方发生 NAT 重新绑定的结果。¶

在验证新的客户端地址后，服务器 SHOULD 向客户端发送新的地址 验证令牌（第 8 节）。¶

9.4. 丢包检测与 拥塞控制

新路径上的可用容量可能不同于旧路径。 在旧路径上发送的分组 MUST NOT 贡献于新路径的拥塞控制或 RTT 估计。¶

在确认对等方拥有其新地址后，端点 MUST 立即将新路径的拥塞控制器和往返时间估计器重置为初始值 （见 [QUIC-RECOVERY] 的附录 A.3 和 B.3）， 除非对等方地址唯一的变化是端口号。由于仅端口变化通常是 NAT 重新绑定或其他中间盒活动的结果，端点 MAY 在这些情况下保留其拥塞控制状态和往返时间估计，而不是 恢复到初始值。在从旧路径保留的拥塞控制状态用于具有显著不同 特征的新路径时，发送方可能在拥塞控制器和 RTT 估计器适应之前 发送得过于激进。通常建议实现谨慎地在新路径上使用先前值。¶

当端点在迁移期间从/向多个地址发送数据和探测时， 接收方可能出现表面上的重排序，因为产生的两条路径可能具有不同的往返时间。 在多条路径上接收分组的接收方仍会发送覆盖所有已接收分组的 ACK 帧。¶

虽然在连接迁移期间可能使用多条路径，但单个拥塞控制上下文和 单个丢包恢复上下文（如 [QUIC-RECOVERY] 中所述） 可能已经足够。例如，端点可能延迟切换到新的拥塞控制上下文， 直到确认旧路径不再需要（例如 第 9.3.3 节中描述的情况）。¶

发送方可以对探测分组作出例外，使其丢包检测独立， 且不会不适当地导致拥塞控制器降低发送速率。 端点可能在发送 PATH_CHALLENGE 时设置单独定时器，如果收到对应的 PATH_RESPONSE，则取消该定时器。如果在收到 PATH_RESPONSE 之前定时器触发， 端点可能发送新的 PATH_CHALLENGE，并以更长时间重新启动定时器。此定时器 SHOULD 按 第 6.2.1 节，见 [QUIC-RECOVERY] 所述设置，且 MUST NOT 更激进。¶

9.5. 连接迁移的隐私 影响

在多条网络路径上使用稳定的连接 ID 会允许被动观察者 将这些路径之间的活动相关联。在网络之间移动的端点可能不希望 其活动被其对等方以外的任何实体关联，因此如 第 5.1 节所述， 从不同本地地址发送时会使用不同的连接 ID。为使这有效， 端点需要确保其提供的连接 ID 不能被任何其他实体关联。¶

在任何时候，端点 MAY 将其传输使用的 Destination Connection ID 更改为尚未在另一条路径上使用过的值。¶

端点 MUST NOT 在从多个本地地址 发送时重用连接 ID——例如，在按 第 9.2 节所述发起连接迁移时， 或在按 第 9.1 节所述探测新网络路径时。¶

类似地，端点在发送到多个目的地址时 MUST NOT 重用连接 ID。由于其对等方无法控制的网络变化，端点可能会 从新的源地址收到具有相同 Destination Connection ID 字段值的分组， 在这种情况下，只要仍从同一本地地址发送，它 MAY 继续对新的远端地址使用当前连接 ID。¶

这些关于连接 ID 重用的要求仅适用于发送分组， 因为路径无意变化时可能不会伴随连接 ID 变化。例如，在一段网络不活动之后， 当客户端恢复发送时，NAT 重新绑定可能导致分组在新路径上发送。 端点按 第 9.3 节所述响应此类事件。¶

在每条新网络路径上为两个方向发送的分组使用不同的连接 ID， 可以消除使用连接 ID 将同一连接在不同网络路径上的分组相关联。 报头保护确保分组编号不能用于关联活动。这并不阻止 使用分组的其他属性（例如时序和大小）来关联活动。¶

端点 SHOULD NOT 与请求零长度连接 ID 的 对等方发起迁移，因为新路径上的流量可能会被轻易关联到旧路径上的流量。 如果服务器能够将具有零长度连接 ID 的分组关联到正确连接， 这意味着服务器正在使用其他信息来解复用分组。例如，服务器 可能向每个客户端提供唯一地址——例如使用 HTTP 替代服务 [ALTSVC]。可能允许在多条网络路径上 正确路由分组的信息，也会允许对等方以外的实体关联这些路径上的活动。¶

客户端可能希望通过在一段不活动后发送流量时切换到新的连接 ID、 源 UDP 端口或 IP 地址（见 [RFC8981]）， 来降低可关联性。同时更改其发送分组的地址可能导致服务器检测到连接迁移。 这确保支持迁移的机制即使对未经历 NAT 重新绑定或真实迁移的客户端也会被演练。 更改地址可能导致对等方重置其拥塞控制状态（见 第 9.4 节），因此地址 SHOULD 只应不频繁地更改。¶

耗尽可用连接 ID 的端点无法探测新路径或发起迁移， 也无法响应对等方的探测或迁移尝试。为确保迁移可行， 并且不同路径上发送的分组不能被关联，端点 SHOULD 在对等方迁移之前提供新的连接 ID； 见 第 5.1.1 节。如果对等方可能已经耗尽可用 连接 ID，迁移端点可以在新网络路径上发送的所有分组中包含 NEW_CONNECTION_ID 帧。¶

9.6. 服务器首选 地址

QUIC 允许服务器在一个 IP 地址上接受连接， 并在握手后不久尝试将这些连接转移到更首选的地址。 当客户端最初连接到多个服务器共享的地址，但更希望使用单播地址以确保 连接稳定性时，这尤其有用。本节描述将连接迁移到 首选服务器地址的协议。¶

本文档指定的 QUIC 版本不支持在连接中途将连接迁移到 新服务器地址。如果客户端在尚未发起向该地址迁移的情况下 从新服务器地址收到分组，则客户端 SHOULD 丢弃这些分组。¶

9.7. IPv6 流标签与 迁移的使用

使用 IPv6 发送数据的端点 SHOULD 按照 [RFC6437] 应用 IPv6 流标签，除非本地 API 不允许设置 IPv6 流标签。¶

流标签生成 MUST 被设计为 尽量降低与先前使用的流标签发生可关联性的可能性，因为稳定的流标签 会允许在多条路径上关联活动；见 第 9.5 节。¶

[RFC6437] 建议使用伪随机函数派生 值来生成流标签。在生成流标签时，除源地址和目的地址外还包含 Destination Connection ID 字段，可以确保变化与其他可观察标识符的 变化同步。将这些输入与本地秘密组合的密码学哈希函数 是一种可能的实现方式。¶

10.1. 空闲超时

如果任一端点在其传输参数中指定了 max_idle_timeout （第 18.2 节）， 当连接保持空闲的时间超过两个端点通告的 max_idle_timeout 值中的较小者时， 连接会静默关闭并丢弃其状态。¶

每个端点都会通告 max_idle_timeout，但端点处的有效值 被计算为两个通告值中的较小者（或者如果只有一个端点通告非零值， 则为唯一通告值）。通过宣布 max_idle_timeout，端点承诺 如果它在有效值到期之前放弃连接，就会发起立即关闭 （第 10.2 节）。¶

当收到并成功处理来自对等方的分组时，端点会重新启动其空闲定时器。 如果自上次收到并处理分组以来没有发送过其他触发 ACK 的分组， 则端点在发送触发 ACK 的分组时也会重新启动其空闲定时器。 发送分组时重新启动此定时器，可确保在发起新活动后连接不会被关闭。¶

为避免空闲超时期过短，端点 MUST 将空闲超时期增加到 至少为当前探测超时（PTO）的三倍。这允许多个 PTO 到期， 因而在空闲超时之前发送并丢失多个探测。¶

10.2. 立即关闭

端点发送 CONNECTION_CLOSE 帧（第 19.19 节）以立即 终止连接。CONNECTION_CLOSE 帧会使所有流立即变为关闭； 打开的流可以被认为已经被隐式重置。¶

发送 CONNECTION_CLOSE 帧后，端点立即进入 closing 状态；见 第 10.2.1 节。收到 CONNECTION_CLOSE 帧后，端点进入 draining 状态；见 第 10.2.2 节。¶

协议违规会导致立即关闭。¶

立即关闭可以在应用协议已安排关闭连接后使用。 这可能是在应用协议协商优雅关闭之后。应用协议可以交换 两个应用端点都需要的消息，以同意连接可以关闭； 之后应用请求 QUIC 关闭连接。当 QUIC 因此关闭连接时， 会使用带有应用提供错误码的 CONNECTION_CLOSE 帧向对等方发出关闭信号。¶

closing 和 draining 连接状态的存在，是为了确保连接 干净关闭，并正确丢弃延迟或重排序的分组。 这些状态 SHOULD 至少持续当前 PTO 间隔的三倍， 如 [QUIC-RECOVERY] 中所定义。¶

在退出 closing 或 draining 状态之前处理掉连接状态， 可能导致端点在收到迟到分组时不必要地生成 Stateless Reset。 端点如果有其他方式确保迟到分组不会引发响应，例如能够关闭 UDP 套接字， MAY 提前结束这些状态以便更快回收资源。 保留打开套接字以接受新连接的服务器 SHOULD NOT 提前结束 closing 或 draining 状态。¶

一旦其 closing 或 draining 状态结束，端点 SHOULD 丢弃所有连接状态。端点 MAY 响应该连接所属的任何后续传入分组发送 Stateless Reset。¶

10.3. 无状态重置

无状态重置作为最后手段选项提供给无法访问连接状态的 端点。崩溃或故障可能导致对等方继续向无法正常继续连接的端点 发送数据。端点 MAY 响应收到无法与活跃连接关联的分组 发送 Stateless Reset。¶

无状态重置不适合用于指示活跃连接中的错误。 希望传达致命连接错误的端点如果能够使用 CONNECTION_CLOSE 帧， 就 MUST 使用它。¶

为支持此过程，端点会签发无状态重置令牌， 这是一个难以猜测的 16 字节值。如果对等方随后收到一个 Stateless Reset，即一个以该无状态重置令牌结尾的 UDP 数据报， 该对等方会立即结束连接。¶

无状态重置令牌特定于连接 ID。端点通过在 NEW_CONNECTION_ID 帧的 Stateless Reset Token 字段中包含该值来签发 无状态重置令牌。服务器还可以在握手期间签发 stateless_reset_token 传输参数，该参数适用于其在握手期间选择的连接 ID。 这些交换受加密保护，因此只有客户端和服务器知道其值。 注意，客户端不能使用 stateless_reset_token 传输参数，因为客户端的 传输参数没有机密性保护。¶

当关联的连接 ID 通过 RETIRE_CONNECTION_ID 帧 （第 19.16 节）退役时，令牌即失效。¶

收到无法处理的分组的端点会发送一个 采用以下布局的分组（见 第 1.3 节）：¶

无状态重置 {
  固定位 (2) = 1,
  不可预测位 (38..),
  无状态重置令牌 (128),
}

此设计确保 Stateless Reset 在可能范围内 与带有短报头的常规分组无法区分。¶

Stateless Reset 使用整个 UDP 数据报，从分组报头的前两个比特 开始。第一个字节的其余部分以及其后的任意数量字节被设置为 SHOULD 与随机值无法区分的值。数据报的最后 16 字节 包含无状态重置令牌。¶

对于预期接收方以外的实体，Stateless Reset 会表现为 带短报头的分组。为了使 Stateless Reset 表现为有效的 QUIC 分组，Unpredictable Bits 字段需要包含至少 38 比特数据 （或 5 字节，减去两个固定位）。¶

如果接收方要求使用连接 ID，则得到的最小大小 21 字节 并不能保证 Stateless Reset 难以与其他分组区分。为实现这一点， 端点 SHOULD 确保其发送的所有分组至少比 它请求对等方在其分组中包含的最小连接 ID 长度长 22 字节， 并按需添加 PADDING 帧。这确保对等方发送的任何 Stateless Reset 与发送给该端点的有效分组无法区分。响应 43 字节或更短分组 发送 Stateless Reset 的端点 SHOULD 发送比所响应分组短一个字节的 Stateless Reset。¶

这些值假定无状态重置令牌与分组保护 AEAD 的最小扩展长度相同。 如果端点可能已经协商出具有更大最小扩展的分组保护方案， 则需要额外的不可预测字节。¶

端点 MUST NOT 发送比其收到分组大三倍或更多的 Stateless Reset，以避免被用于放大。 第 10.3.3 节描述了对 Stateless Reset 大小的额外限制。¶

端点 MUST 丢弃过小而无法成为有效 QUIC 分组的分组。举例来说，对于 [QUIC-TLS] 中定义的 AEAD 函数集合， 小于 21 字节的短报头分组永远无效。¶

端点 MUST 发送格式为短报头分组的 Stateless Reset。不过，端点 MUST 将任何以有效无状态 重置令牌结尾的分组视为 Stateless Reset，因为其他 QUIC 版本可能允许使用长 报头。¶

端点 MAY 响应带长报头的分组发送 Stateless Reset。在无状态重置令牌可供对等方使用之前， 发送 Stateless Reset 不会有效。在此 QUIC 版本中，带长报头的分组 仅在连接建立期间使用。由于无状态重置令牌直到连接建立完成或接近完成时 才可用，因此忽略带长报头的未知分组可能与发送 Stateless Reset 一样有效。¶

端点无法从带短报头的分组确定 Source Connection ID； 因此，它无法设置 Stateless Reset 中的 Destination Connection ID。 因此，Destination Connection ID 将不同于先前分组中使用的值。 随机的 Destination Connection ID 会使该连接 ID 看起来像是迁移到 一个使用 NEW_CONNECTION_ID 帧提供的新连接 ID 的结果；见 第 19.15 节。¶

使用随机化连接 ID 会导致两个问题：¶

• 该分组可能无法到达对等方。如果 Destination Connection ID 对路由到对等方至关重要，则该分组可能被错误路由。 这也可能触发另一个 Stateless Reset 作为响应；见 第 10.3.3 节。未被正确路由的 Stateless Reset 是无效的错误检测和恢复机制。在这种情况下，端点 需要依赖其他方法——例如定时器——来检测连接已经失败。¶
• 随机生成的连接 ID 可以被对等方以外的 实体用于识别这可能是 Stateless Reset。偶尔使用不同连接 ID 的端点 可能会对此引入一些不确定性。¶

这种无状态重置设计特定于 QUIC 版本 1。 支持多个 QUIC 版本的端点需要生成一个 Stateless Reset， 该重置会被支持该端点可能支持（或在丢失状态之前可能支持）的任何版本的 对等方接受。设计 QUIC 新版本的人需要意识到这一点，并且要么 （1）重用此设计，要么（2）使用分组最后 16 字节以外的部分承载数据。¶

11.1. 连接错误

导致连接不可用的错误，例如明显违反协议语义， 或影响整个连接的状态损坏，MUST 使用 CONNECTION_CLOSE 帧 （第 19.19 节）发出信号。¶

应用特定协议错误使用帧类型为 0x1d 的 CONNECTION_CLOSE 帧发出信号。特定于传输的错误，包括本文档描述的 所有错误，承载在帧类型为 0x1c 的 CONNECTION_CLOSE 帧中。¶

CONNECTION_CLOSE 帧可能在一个丢失的分组中发送。端点 SHOULD 准备好在终止的连接上收到更多分组时， 重传包含 CONNECTION_CLOSE 帧的分组。限制重传次数以及发送该最终分组的 时间，可以限制在已终止连接上耗费的工作量。¶

选择不重传包含 CONNECTION_CLOSE 帧的分组的端点，有其对等方错过第一个此类分组的风险。 对于继续接收已终止连接数据的端点，唯一可用的机制是 尝试无状态重置过程（第 10.3 节）。¶

由于 Initial 分组的 AEAD 不提供强认证，端点 MAY 丢弃无效的 Initial 分组。即使本规范在其他地方要求 连接错误，也允许丢弃 Initial 分组。端点只有在不处理该分组中的帧， 或回滚任何处理影响时，才可以丢弃分组。丢弃无效 Initial 分组可用于减少暴露于拒绝服务的风险；见 第 21.2 节。¶

11.2. 流错误

如果应用层错误影响单个流，但在其他方面使 连接保持可恢复状态，则端点可以发送带有适当错误码的 RESET_STREAM 帧 （第 19.4 节），只终止受影响的 流。¶

在应用协议未参与的情况下重置流，可能导致 应用协议进入不可恢复状态。RESET_STREAM MUST 只能由使用 QUIC 的应用协议发起。¶

RESET_STREAM 中承载的应用错误码的语义 由应用协议定义。只有应用协议能够导致流被终止。 应用协议的本地实例使用直接 API 调用，远端实例使用 STOP_SENDING 帧， 后者触发自动 RESET_STREAM。¶

应用协议 SHOULD 定义处理由任一端点 过早取消的流的规则。¶

12.1. 受保护分组

QUIC 分组根据分组类型具有不同级别的密码学保护。 分组保护的细节见 [QUIC-TLS]；本节概述所提供的保护。¶

Version Negotiation 分组没有密码学保护；见 [QUIC-INVARIANTS]。¶

Retry 分组使用 AEAD 函数 [AEAD] 来防止 意外修改。¶

Initial 分组使用 AEAD 函数，其密钥使用线上可见的 值派生。因此，Initial 分组不具有有效的机密性保护。 Initial 保护的存在是为了确保分组发送方位于网络路径上。 任何从客户端接收 Initial 分组的实体都可以恢复密钥， 这些密钥允许它们读取该分组内容，并生成会在任一端点成功认证的 Initial 分组。AEAD 也会保护 Initial 分组免遭意外修改。¶

所有其他分组都使用从加密握手派生的密钥进行保护。 加密握手确保只有通信端点接收 Handshake、0-RTT 和 1-RTT 分组对应的密钥。使用 0-RTT 和 1-RTT 密钥保护的分组具有强 机密性和完整性保护。¶

出现在某些分组类型中的 Packet Number 字段具有作为 报头保护一部分应用的替代机密性保护；详情见 第 5.4 节，见 [QUIC-TLS]。 底层分组编号会随着在给定分组编号空间中发送的每个分组而增加； 详情见 第 12.3 节。¶

12.2. 合并分组

Initial（第 17.2.2 节）、0-RTT （第 17.2.3 节）和 Handshake （第 17.2.4 节）分组包含一个 Length 字段， 该字段决定分组的结尾。该长度包括 Packet Number 和 Payload 字段，这两个字段都受机密性保护，且初始长度未知。 一旦报头保护被移除，就会知道 Payload 字段的长度。¶

使用 Length 字段，发送方可以将多个 QUIC 分组合并到一个 UDP 数据报中。这可以减少完成加密握手并开始发送数据所需的 UDP 数据报数量。这也可用于构造路径最大传输单元（PMTU）探测； 见 第 14.4.1 节。接收方 MUST 能够处理合并分组。¶

按照加密级别递增的顺序合并分组（Initial、0-RTT、 Handshake、1-RTT；见 第 4.1.4 节，见 [QUIC-TLS]），会使接收方更可能 在一次遍历中处理所有分组。带短报头的分组不包含长度， 因此它只能是 UDP 数据报中包含的最后一个分组。端点 SHOULD 在帧要以相同加密级别发送时， 将多个帧包含在单个分组中，而不是在相同加密级别合并多个分组。¶

接收方 MAY 基于 UDP 数据报中 第一个分组的信息进行路由。发送方 MUST NOT 将具有不同连接 ID 的 QUIC 分组合并到单个 UDP 数据报中。接收方 SHOULD 忽略数据报中任何后续分组，如果其 Destination Connection ID 与第一个分组不同。¶

每个合并到单个 UDP 数据报中的 QUIC 分组都是独立且 完整的。合并 QUIC 分组的接收方 MUST 分别处理每个 QUIC 分组，并分别确认它们，就像它们是作为不同 UDP 数据报的 载荷收到一样。例如，如果解密失败（因为密钥不可用或出于其他任何原因）， 接收方 MAY 丢弃或缓冲该分组以便稍后处理，并且 MUST 尝试处理剩余分组。¶

Retry 分组（第 17.2.5 节）、 Version Negotiation 分组 （第 17.2.1 节）以及带短报头的分组（第 17.3 节）不包含 Length 字段，因此在同一 UDP 数据报中不能后接其他分组。 还要注意，不存在 Retry 或 Version Negotiation 分组与另一个分组合并的情况。¶

12.3. 分组编号

分组编号是范围从 0 到 2⁶²-1 的整数。 该编号用于确定分组保护的密码学 nonce。每个 端点为发送和接收分别维护一个分组编号。¶

分组编号限制在此范围内，因为它们需要能完整表示在 ACK 帧（第 19.3 节）的 Largest Acknowledged 字段中。 不过，当存在于长报头或短报头中时，分组编号会被缩减并编码为 1 到 4 字节；见 第 17.1 节。¶

Version Negotiation（第 17.2.1 节）和 Retry（第 17.2.5 节） 分组不包含分组编号。¶

QUIC 中的分组编号被划分为三个空间：¶

Initial 空间：

所有 Initial 分组（第 17.2.2 节）都在此空间中。¶

Handshake 空间：

所有 Handshake 分组（第 17.2.4 节）都在此空间中。¶

应用数据空间：

所有 0-RTT（第 17.2.3 节）和 1-RTT（第 17.3.1 节） 分组都在此 空间中。¶

如 [QUIC-TLS] 中所述，每种分组类型使用不同的保护密钥。¶

概念上，分组编号空间是分组可以被处理和确认的上下文。 Initial 分组只能使用 Initial 分组保护密钥发送，并且只能在同样为 Initial 分组的分组中被确认。类似地，Handshake 分组在 Handshake 加密 级别发送，并且只能在 Handshake 分组中被确认。¶

这会强制分隔不同分组编号空间中发送的数据的密码学保护。 每个空间中的分组编号都从分组编号 0 开始。 在同一分组编号空间中发送的后续分组 MUST 使分组 编号至少增加 1。¶

0-RTT 和 1-RTT 数据存在于同一分组编号空间中， 以便丢包恢复算法在这两种分组类型之间更容易实现。¶

QUIC 端点 MUST NOT 在一个连接的同一 分组编号空间内重用分组编号。如果发送的分组编号达到 2⁶²-1，发送方 MUST 在不发送 CONNECTION_CLOSE 帧或任何后续分组的情况下关闭连接；端点 MAY 响应其收到的后续分组发送 Stateless Reset（第 10.3 节）。¶

接收方 MUST 丢弃新解保护的 分组，除非它确定尚未处理来自同一分组编号空间且具有相同分组编号的 另一个分组。出于 第 9.5 节 ，见 [QUIC-TLS] 中描述的原因， 重复抑制 MUST 在移除分组保护后发生。¶

为检测重复而跟踪所有单独分组的端点， 有积累过多状态的风险。可以通过维护一个最小分组编号来限制 检测重复所需的数据，低于该编号的所有分组都会被立即丢弃。 任何最小值都需要考虑往返时间的大幅变化，包括对等方可能用 大得多的往返时间探测网络路径的可能性；见 第 9 节。¶

发送方的分组编号编码和接收方的解码在 第 17.1 节中描述。¶

12.4. 帧与帧类型

移除分组保护后，QUIC 分组的载荷由一系列完整帧组成， 如 图 11所示。 Version Negotiation、Stateless Reset 和 Retry 分组不包含帧。¶

分组载荷 {
  帧 (8..) ...,
}

包含帧的分组载荷 MUST 至少包含一个帧，并且 MAY 包含多个帧和多种帧类型。端点 MUST 将收到不包含帧的分组视为类型为 PROTOCOL_VIOLATION 的连接错误。 帧始终适配在单个 QUIC 分组内，不能跨多个分组。¶

每个帧都以 Frame Type 开始，用于指示其类型， 随后是依赖具体类型的附加字段：¶

帧 {
  帧类型 (i),
  依赖类型的字段 (..),
}

表 3列出并汇总了 本规范中定义的每种帧类型的信息。表后包含对此摘要的说明。¶

每种帧类型的格式和语义在 第 19 节中有更详细说明。本节余下部分提供 重要且通用信息的摘要。¶

ACK、STREAM、MAX_STREAMS、STREAMS_BLOCKED 和 CONNECTION_CLOSE 帧中的 Frame Type 用于承载其他帧特定标志。对于所有 其他帧，Frame Type 字段仅标识该帧。¶

表 3中的“分组”列 列出每种帧类型可能出现在哪些分组类型中，并由以下字符表示：¶

I：

Initial（第 17.2.2 节）¶

H：

Handshake（第 17.2.4 节）¶

0：

0-RTT（第 17.2.3 节）¶

1：

1-RTT（第 17.3.1 节）¶

ih：

只有类型为 0x1c 的 CONNECTION_CLOSE 帧可以出现在 Initial 或 Handshake 分组中。¶

关于这些限制的更多细节，见 第 12.5 节。注意， 所有帧都可以出现在 1-RTT 分组中。端点 MUST 将收到 不允许的分组类型中的帧视为类型为 PROTOCOL_VIOLATION 的连接错误。¶

表 3中的“特殊规则”列 汇总了管理该帧类型处理或生成的任何特殊规则， 并由以下字符表示：¶

N：

仅包含带此标记的帧的分组不会 触发 ACK；见 第 13.2 节。¶

C：

仅包含带此标记的帧的分组，在拥塞控制目的下不计入 在途字节；见 [QUIC-RECOVERY]。¶

P：

仅包含带此标记的帧的分组，可用于 在连接迁移期间探测新的网络路径；见 第 9.1 节。¶

F：

带此标记的帧的内容受流量控制； 见 第 4 节。¶

表 3中的“分组”和“特殊规则”列不构成 IANA 注册表的一部分；见 第 22.4 节。¶

端点 MUST 将收到未知类型的帧 视为类型为 FRAME_ENCODING_ERROR 的连接错误。¶

在此版本的 QUIC 中，所有帧都是幂等的。也就是说， 有效帧在被多次接收时不会导致不良副作用或错误。¶

Frame Type 字段使用可变长度整数编码（见 第 16 节），但有一个例外。为确保 帧解析实现简单且高效，帧类型 MUST 使用尽可能短的 编码。对于本文档定义的帧类型，这意味着单字节编码， 即使这些值可以编码为 2、4 或 8 字节的可变长度整数。 例如，虽然 0x4001 是值为 1 的可变长度整数的合法 两字节编码，PING 帧始终编码为值为 0x01 的单字节。 此规则适用于所有当前和未来的 QUIC 帧类型。端点 MAY 将收到使用比必要长度更长编码的帧类型 视为类型为 PROTOCOL_VIOLATION 的连接错误。¶

12.5. 帧与编号 空间

一些帧在不同分组编号空间中被禁止。这里的规则 概括了 TLS 的规则，因为与建立连接相关的帧通常可以出现在 任何分组编号空间的分组中，而与传输数据相关的帧只能出现在应用 数据分组编号空间中：¶

• PADDING、PING 和 CRYPTO 帧 MAY 出现在任何分组编号空间中。¶
• 发出 QUIC 层错误信号的 CONNECTION_CLOSE 帧（类型 0x1c）MAY 出现在任何分组编号空间中。发出应用错误信号的 CONNECTION_CLOSE 帧 （类型 0x1d）MUST 只能出现在应用数据分组 编号空间中。¶
• ACK 帧 MAY 出现在任何 分组编号空间中，但只能确认出现在该分组编号空间中的分组。 不过，如下文所述，0-RTT 分组不能包含 ACK 帧。¶
• 所有其他帧类型 MUST 只能在应用数据分组编号空间中发送。¶

注意，由于各种原因，无法在 0-RTT 分组中发送以下帧： ACK、CRYPTO、HANDSHAKE_DONE、NEW_TOKEN、PATH_RESPONSE 和 RETIRE_CONNECTION_ID。服务器 MAY 将在 0-RTT 分组中收到这些帧视为类型为 PROTOCOL_VIOLATION 的连接错误。¶

13.1. 分组处理

在成功移除分组保护并处理完该分组中包含的所有帧之前， 分组 MUST NOT 被确认。对于 STREAM 帧，这意味着数据已经入队，以准备由应用协议接收， 但不要求数据已被交付和消费。¶

一旦分组被完全处理，接收方通过发送一个或多个 包含所接收分组编号的 ACK 帧来确认接收。¶

端点如果能够检测到这种情况，SHOULD 将收到 对其未发送分组的确认视为类型为 PROTOCOL_VIOLATION 的连接错误。 关于这可能如何实现的进一步讨论，见 第 21.4 节。¶

13.2. 生成确认

端点会确认其接收并处理的所有分组。不过，只有 触发 ACK 的分组才会导致在最大 ACK 延迟内发送 ACK 帧。 不触发 ACK 的分组仅在由于其他原因发送 ACK 帧时才会被确认。¶

无论出于何种原因发送分组时，如果最近没有发送过 ACK 帧， 端点 SHOULD 尝试包含 ACK 帧。 这样做有助于对等方及时检测丢包。¶

一般来说，接收方频繁反馈可以改善丢包和拥塞响应， 但这必须与接收方响应每个触发 ACK 分组而发送 ACK 帧所产生的 过大负载相平衡。下面给出的指导旨在取得这种平衡。¶

13.3. 信息重传

被确定为丢失的 QUIC 分组不会整体重传。 其中包含的帧也是如此。相反，帧中可能承载的信息会按需 在新的帧中再次发送。¶

新的帧和分组用于承载被确定已丢失的信息。 一般来说，当包含该信息的分组被确定为丢失时，信息会再次发送； 当包含该信息的分组被确认时，发送停止。¶

• CRYPTO 帧中发送的数据按照 [QUIC-RECOVERY] 中的规则重传， 直到所有数据都被确认。Initial 和 Handshake 分组的 CRYPTO 帧中的数据会在相应分组编号空间的密钥被丢弃时被丢弃。¶
• STREAM 帧中发送的应用数据会在新的 STREAM 帧中 重传，除非端点已经为该流发送 RESET_STREAM。一旦端点 发送 RESET_STREAM 帧，就不再需要更多 STREAM 帧。¶
• ACK 帧承载最新一组确认，以及来自最大已确认分组的 确认延迟，如 第 13.2.1 节所述。延迟发送包含 ACK 帧的分组或重新发送旧 ACK 帧，可能导致对等方生成 膨胀的 RTT 样本或不必要地禁用 ECN。¶
• 流传输的取消，如 RESET_STREAM 帧中承载的， 会一直发送，直到被确认或直到对等方确认所有流数据 （也就是说，流的发送部分达到“Reset Recvd”或“Data Recvd”状态）。 RESET_STREAM 帧的内容在再次发送时 MUST NOT 改变。¶
• 类似地，请求取消流传输，如 STOP_SENDING 帧中编码的，会一直发送，直到流的接收部分进入 “Data Recvd”或“Reset Recvd”状态；见 第 3.5 节。¶
• 连接关闭信号，包括包含 CONNECTION_CLOSE 帧的分组，在检测到分组丢失时不会再次发送。重新发送这些 信号见 第 10 节。¶
• 当前连接最大数据在 MAX_DATA 帧中发送。如果包含最近发送的 MAX_DATA 帧的分组被声明为丢失， 或端点决定更新限制，则在 MAX_DATA 帧中发送更新后的值。 需要谨慎，避免过于频繁发送此帧，因为该限制可能频繁增加并导致 不必要地发送大量 MAX_DATA 帧；见 第 4.2 节。¶
• 当前最大流数据偏移在 MAX_STREAM_DATA 帧中发送。与 MAX_DATA 一样，当包含某个流最近的 MAX_STREAM_DATA 帧的分组丢失，或限制被更新时，会发送更新后的值， 同时注意防止该帧发送过于频繁。当流的接收部分进入 “Size Known”或“Reset Recvd”状态时，端点 SHOULD 停止发送 MAX_STREAM_DATA 帧。¶
• 给定类型流的限制在 MAX_STREAMS 帧中发送。与 MAX_DATA 一样，当包含某个流类型最近 MAX_STREAMS 帧的分组被声明为丢失，或限制被更新时，会发送更新后的值， 同时注意防止该帧发送过于频繁。¶
• 阻塞信号承载在 DATA_BLOCKED、 STREAM_DATA_BLOCKED 和 STREAMS_BLOCKED 帧中。DATA_BLOCKED 帧具有连接作用域， STREAM_DATA_BLOCKED 帧具有流作用域，STREAMS_BLOCKED 帧 的作用域限定为特定流类型。如果包含某个作用域最近帧的分组丢失， 且仅在端点仍受相应限制阻塞时，会发送新帧。 这些帧始终包含其传输时导致阻塞的限制。¶
• 使用 PATH_CHALLENGE 帧进行的存活性或路径验证检查 会周期性发送，直到收到匹配的 PATH_RESPONSE 帧，或不再需要 进行存活性或路径验证检查。PATH_CHALLENGE 帧每次发送时都包含不同的载荷。¶
• 使用 PATH_RESPONSE 帧进行的路径验证响应 只发送一次。预期对等方会按需发送更多 PATH_CHALLENGE 帧以引发 额外 PATH_RESPONSE 帧。¶
• 新的连接 ID 在 NEW_CONNECTION_ID 帧中发送，并在包含它们的分组丢失时重传。 此帧的重传携带相同的序列号值。同样，退役的连接 ID 在 RETIRE_CONNECTION_ID 帧中发送，并在包含它们的分组丢失时重传。¶
• 如果包含 NEW_TOKEN 帧的分组丢失， 则会重传 NEW_TOKEN 帧。除了直接比较帧内容外，不提供 用于检测重排序和重复 NEW_TOKEN 帧的特殊支持。¶
• PING 和 PADDING 帧不包含信息， 因此丢失的 PING 或 PADDING 帧不需要修复。¶
• HANDSHAKE_DONE 帧 MUST 重传，直到其被确认。¶

除非应用指定的优先级另有指示，否则端点 SHOULD 优先重传数据， 而不是发送新数据；见 第 2.3 节。¶

即使鼓励发送方在每次发送分组时都组装包含最新信息的帧， 也不禁止重传丢失分组中的帧副本。重传帧副本的发送方 需要处理由于分组编号长度、连接 ID 长度和路径 MTU 变化导致的 可用载荷大小减少。接收方 MUST 接受 包含过时帧的分组，例如承载比旧分组中发现的最大数据值更小的 MAX_DATA 帧。¶

发送方 SHOULD 避免在分组被确认后 重传其中的信息。这包括在被声明为丢失后又被确认的分组， 这可能在网络重排序存在时发生。这样做要求发送方在分组被声明为丢失后 保留关于分组的信息。发送方可以在经过足以允许重排序的一段时间后丢弃此信息， 例如一个 PTO（第 6.2 节 ，见 [QUIC-RECOVERY]）， 或基于其他事件，例如达到内存限制。¶

检测到丢包后，发送方 MUST 采取 适当的拥塞控制行动。 丢包检测和拥塞控制的细节在 [QUIC-RECOVERY] 中描述。¶

13.4. 显式拥塞 通知

QUIC 端点可以使用 ECN [RFC3168] 来检测并响应网络 拥塞。ECN 允许端点在 IP 分组的 ECN 字段中设置 ECN-Capable Transport (ECT) 码点。随后，网络节点可以通过在 ECN 字段中设置 ECN-CE 码点来指示 拥塞，而不是丢弃分组 [RFC8087]。 端点按照 [QUIC-RECOVERY] 中描述的方式，通过降低其发送速率来响应 所报告的拥塞。¶

为启用 ECN，发送 QUIC 的端点首先确定某条路径是否支持 ECN 标记，以及对等方是否报告收到的 IP 报头中的 ECN 值； 见 第 13.4.2 节。¶

14.1. Initial 数据报大小

客户端 MUST 通过向 Initial 分组 添加 PADDING 帧，或通过合并 Initial 分组，将所有承载 Initial 分组的 UDP 数据报载荷扩展到至少最小允许最大数据报大小 1200 字节；见 第 12.2 节。Initial 分组甚至可以 与无效分组合并，接收方会丢弃这些无效分组。类似地，服务器 MUST 将所有承载触发 ACK 的 Initial 分组的 UDP 数据报载荷 扩展到至少最小允许最大数据报大小 1200 字节。¶

发送这种大小的 UDP 数据报可确保网络路径在两个方向上 都支持合理的路径最大传输单元（PMTU）。此外，客户端扩展 Initial 分组有助于降低由服务器响应未验证客户端地址而造成的 放大攻击幅度；见 第 8 节。¶

如果发送方认为网络路径和对等方都支持其选择的大小， 则包含 Initial 分组的数据报 MAY 超过 1200 字节。¶

服务器 MUST 丢弃承载在 UDP 数据报中且 其载荷小于最小允许最大数据报大小 1200 字节的 Initial 分组。 服务器 MAY 也可以通过发送错误码为 PROTOCOL_VIOLATION 的 CONNECTION_CLOSE 帧立即关闭连接；见 第 10.2.3 节。¶

服务器在验证客户端地址之前，还 MUST 限制其发送的字节数；见 第 8 节。¶

14.2. 路径最大 传输单元

PMTU 是整个 IP 分组的最大大小，包括 IP 报头、 UDP 报头和 UDP 载荷。UDP 载荷包括一个或多个 QUIC 分组 报头和受保护载荷。PMTU 可能取决于路径特征，因此可能随时间变化。 端点在任意给定时间发送的最大 UDP 载荷称为该端点的 最大数据报大小。¶

端点 SHOULD 使用 DPLPMTUD（第 14.3 节）或 PMTUD（第 14.2.1 节）来确定 到目的地的路径是否会在不分片的情况下支持期望的最大数据报大小。 在缺少这些机制时，QUIC 端点 SHOULD NOT 发送 大于最小允许最大数据报大小的数据报。¶

DPLPMTUD 和 PMTUD 都会发送大于当前最大数据报大小的 数据报，称为 PMTU 探测。所有未在 PMTU 探测中发送的 QUIC 分组 SHOULD 调整为适配在最大数据报大小内，以避免 数据报被分片或丢弃 [RFC8085]。¶

如果 QUIC 端点确定任何一对本地和远端 IP 地址之间的 PMTU 不能支持最小允许最大数据报大小 1200 字节，则它 MUST 立即停止在受影响路径上发送 QUIC 分组， 但 PMTU 探测中的分组或包含 CONNECTION_CLOSE 帧的分组除外。 如果无法找到替代路径，端点 MAY 终止连接。¶

每一对本地和远端地址都可能具有不同的 PMTU。 因此，实现任何类型 PMTU 发现的 QUIC 实现 SHOULD 为每个本地和远端 IP 地址组合维护最大数据报大小。¶

QUIC 实现 MAY 在计算最大数据报 大小时更加保守，以允许未知的隧道开销或 IP 报头选项/扩展。¶

14.3. 数据报分组化 层 PMTU 发现

DPLPMTUD [DPLPMTUD] 依赖跟踪承载在 PMTU 探测中的 QUIC 分组的丢失或确认。使用 PADDING 帧的 DPLPMTUD PMTU 探测实现了 “使用填充数据进行探测”，如 第 4.1 节 ，见 [DPLPMTUD] 中所定义。¶

端点 SHOULD 将 BASE_PLPMTU（第 5.1 节，见 [DPLPMTUD]）的初始值设置为与 QUIC 最小允许最大 数据报大小一致。MIN_PLPMTU 与 BASE_PLPMTU 相同。¶

实现 DPLPMTUD 的 QUIC 端点会为每个本地和远端 IP 地址组合维护 DPLPMTUD 最大分组大小（MPS）（第 4.4 节，见 [DPLPMTUD]）。 这对应于最大数据报大小。¶

14.4. 发送 QUIC PMTU 探测

PMTU 探测是触发 ACK 的分组。¶

端点可以将 PMTU 探测的内容限制为 PING 和 PADDING 帧， 因为大于当前最大数据报大小的分组更可能被网络丢弃。 因此，承载在 PMTU 探测中的 QUIC 分组丢失并不是拥塞的可靠指示， 并且 SHOULD NOT 触发拥塞控制反应；见 第 3 节， 见 [DPLPMTUD]中的条目 7。 不过，PMTU 探测会消耗拥塞窗口，这可能延迟应用的后续传输。¶

17.1. 分组编号编码与 解码

分组编号是范围从 0 到 2⁶²-1 的整数 （第 12.3 节）。当存在于长分组报头或短分组 报头中时，它们编码为 1 到 4 字节。通过只包含分组编号的 最低有效位，表示分组编号所需的位数会被减少。¶

编码后的分组编号按 第 5.4 节，见 [QUIC-TLS]中的描述受到保护。¶

在收到某个分组编号空间的确认之前， MUST 包含完整分组编号；不能按下文所述截断。¶

在收到某个分组编号空间的确认后，发送方 MUST 使用一种分组编号大小，其可表示的范围大于最大已确认分组编号与正在发送的分组编号之间 差值的两倍。接收该分组的对等方随后会正确解码 分组编号，除非该分组在传输中被延迟，以至于在许多更高编号的分组 已经收到之后才到达。端点 SHOULD 使用足够大的 分组编号编码，以便即使该分组在随后发送的分组之后到达， 仍能恢复分组编号。¶

因此，分组编号编码的大小至少比连续未确认分组编号数量 （包括新分组）的以 2 为底的对数多一位。 分组编号编码的伪代码和示例见 附录 A.2。¶

在接收方，分组编号保护会在恢复完整分组编号之前被移除。 随后，完整分组编号会基于存在的有效位数、这些位的值，以及在成功认证分组中 收到的最大分组编号进行重建。恢复完整分组编号是成功完成 分组保护移除所必需的。¶

一旦报头保护被移除，就通过查找最接近下一个预期分组的 分组编号值来解码分组编号。下一个预期分组是最高已接收分组编号 加一。分组编号解码的伪代码和示例见 附录 A.3。¶

17.2. 长报头分组

长报头分组 {
  报头形式 (1) = 1,
  固定位 (1) = 1,
  长分组类型 (2),
  类型特定位 (4),
  版本 (32),
  Destination Connection ID 长度 (8),
  Destination Connection ID (0..160),
  Source Connection ID 长度 (8),
  Source Connection ID (0..160),
  类型特定载荷 (..),
}

长报头用于在建立 1-RTT 密钥之前发送的分组。 一旦 1-RTT 密钥可用，发送方就切换到使用短报头发送分组 （第 17.3 节）。长形式允许特殊分组 ——例如 Version Negotiation 分组——以这种统一的固定长度分组格式表示。 使用长报头的分组包含以下字段：¶

Header Form：

字节 0（第一个字节）的最高有效位（0x80）在 长报头中设置为 1。¶

Fixed Bit：

字节 0 的下一位（0x40）设置为 1，除非该分组是 Version Negotiation 分组。包含此位为零值的分组在此版本中不是 有效分组，并且 MUST 被丢弃。此位为 1 的值允许 QUIC 与其他协议共存；见 [RFC7983]。¶

Long Packet Type：

字节 0 的接下来的两位（掩码为 0x30 的位）包含 分组类型。分组类型列在 表 5中。¶

Type-Specific Bits：

字节 0 的低四位（掩码为 0x0f 的位）的语义 由分组类型决定。¶

Version：

QUIC Version 是跟随第一个字节的 32 位字段。 该字段指示正在使用的 QUIC 版本，并决定如何解释协议的其余字段。¶

Destination Connection ID Length：

版本之后的字节包含后续 Destination Connection ID 字段的长度（以字节为单位）。此长度编码为 8 位 无符号整数。在 QUIC 版本 1 中，此值 MUST NOT 超过 20 字节。收到值大于 20 的版本 1 长报头的端点 MUST 丢弃该分组。为了正确形成 Version Negotiation 分组，服务器 SHOULD 能够读取来自 其他 QUIC 版本的更长连接 ID。¶

Destination Connection ID：

Destination Connection ID 字段跟在 Destination Connection ID Length 字段之后，后者指示此字段的长度。 第 7.2 节更详细地描述了 此字段的使用。¶

Source Connection ID Length：

Destination Connection ID 之后的字节包含后续 Source Connection ID 字段的长度（以字节为单位）。此长度编码为 8 位无符号整数。在 QUIC 版本 1 中，此值 MUST NOT 超过 20 字节。收到值大于 20 的版本 1 长报头的端点 MUST 丢弃该分组。为了正确形成 Version Negotiation 分组，服务器 SHOULD 能够读取来自其他 QUIC 版本的更长连接 ID。¶

Source Connection ID：

Source Connection ID 字段跟在 Source Connection ID Length 字段之后，后者指示此字段的长度。第 7.2 节 更详细地描述了此字段的使用。¶

Type-Specific Payload：

分组的剩余部分（如果有）是类型特定的。¶

在此版本的 QUIC 中，定义了以下带长报头的分组类型：¶

长报头分组的报头形式位、Destination 和 Source Connection ID 长度、 Destination 和 Source Connection ID 字段，以及 Version 字段都与版本无关。 第一个字节中的其他字段是版本特定的。关于如何解释来自不同 QUIC 版本的分组，详见 [QUIC-INVARIANTS]。¶

字段和载荷的解释特定于版本和分组类型。 虽然此版本的类型特定语义在以下各节中描述，但此版本 QUIC 中 若干长报头分组包含这些附加字段：¶

Reserved Bits：

字节 0 的两位（掩码为 0x0c 的位）在多种 分组类型中被保留。这些位使用报头保护进行保护；见 第 5.4 节，见 [QUIC-TLS]。 保护前包含的值 MUST 设置为 0。 端点在移除分组保护和报头保护后，如果收到这些位具有非零值的分组， MUST 将其视为类型为 PROTOCOL_VIOLATION 的连接错误。 仅移除报头保护后就丢弃这样的分组可能使端点暴露于攻击；见 第 9.5 节，见 [QUIC-TLS]。¶

Packet Number Length：

在包含 Packet Number 字段的分组类型中，字节 0 的 最低有效两位（掩码为 0x03 的位）包含 Packet Number 字段的长度， 编码为无符号两位整数，其值比 Packet Number 字段以字节为单位的长度少一。 也就是说，Packet Number 字段的长度是此字段的值加一。 这些位使用报头保护进行保护；见 第 5.4 节，见 [QUIC-TLS]。¶

Length：

这是分组剩余部分（即 Packet Number 和 Payload 字段）的长度（以字节为单位），编码为可变长度整数 （第 16 节）。¶

Packet Number：

此字段长度为 1 到 4 字节。分组编号使用报头 保护进行保护；见 第 5.4 节，见 [QUIC-TLS]。Packet Number 字段的长度编码在字节 0 的 Packet Number Length 位中；见上文。¶

Packet Payload：

这是分组载荷——包含一系列帧——并使用分组保护进行保护。¶

Version Negotiation 分组 {
  报头形式 (1) = 1,
  未使用 (7),
  版本 (32) = 0,
  Destination Connection ID 长度 (8),
  Destination Connection ID (0..2040),
  Source Connection ID 长度 (8),
  Source Connection ID (0..2040),
  支持的版本 (32) ...,
}

Initial 分组 {
  报头形式 (1) = 1,
  固定位 (1) = 1,
  长分组类型 (2) = 0,
  保留位 (2),
  分组编号长度 (2),
  版本 (32),
  Destination Connection ID 长度 (8),
  Destination Connection ID (0..160),
  Source Connection ID 长度 (8),
  Source Connection ID (0..160),
  令牌长度 (i),
  令牌 (..),
  长度 (i),
  分组编号 (8..32),
  分组载荷 (8..),
}

0-RTT 分组 {
  报头形式 (1) = 1,
  固定位 (1) = 1,
  长分组类型 (2) = 1,
  保留位 (2),
  分组编号长度 (2),
  版本 (32),
  Destination Connection ID 长度 (8),
  Destination Connection ID (0..160),
  Source Connection ID 长度 (8),
  Source Connection ID (0..160),
  长度 (i),
  分组编号 (8..32),
  分组载荷 (8..),
}

Handshake 分组 {
  报头形式 (1) = 1,
  固定位 (1) = 1,
  长分组类型 (2) = 2,
  保留位 (2),
  分组编号长度 (2),
  版本 (32),
  Destination Connection ID 长度 (8),
  Destination Connection ID (0..160),
  Source Connection ID 长度 (8),
  Source Connection ID (0..160),
  长度 (i),
  分组编号 (8..32),
  分组载荷 (8..),
}

Retry 分组 {
  报头形式 (1) = 1,
  固定位 (1) = 1,
  长分组类型 (2) = 3,
  未使用 (4),
  版本 (32),
  Destination Connection ID 长度 (8),
  Destination Connection ID (0..160),
  Source Connection ID 长度 (8),
  Source Connection ID (0..160),
  Retry 令牌 (..),
  Retry 完整性标签 (128),
}

17.3. 短报头分组

此版本的 QUIC 定义了单一一种使用短分组报头的分组类型。¶

1-RTT 分组 {
  报头形式 (1) = 0,
  固定位 (1) = 1,
  Spin Bit (1),
  保留位 (2),
  密钥阶段 (1),
  分组编号长度 (2),
  Destination Connection ID (0..160),
  分组编号 (8..32),
  分组载荷 (8..),
}

17.4. 延迟自旋位

延迟自旋位定义用于 1-RTT 分组（第 17.3.1 节）， 它使网络路径上的观察点能够在连接持续期间进行被动延迟监测。 服务器反射收到的自旋值，而客户端在一个 RTT 后“自旋”该值。 路径上的观察者可以测量两次自旋位切换事件之间的时间，以估计连接的端到端 RTT。¶

自旋位只存在于 1-RTT 分组中，因为可以通过观察握手来测量 连接的初始 RTT。因此，自旋位在版本协商和连接建立完成后可用。 关于路径上测量和延迟自旋位的使用，在 [QUIC-MANAGEABILITY] 中有进一步讨论。¶

自旋位是此版本 QUIC 的一个 OPTIONAL 特性。不支持此特性的端点 MUST 按下文定义禁用它。¶

每个端点单方面决定是否为某个连接启用或禁用自旋位。 实现 MUST 允许客户端和服务器的管理员 全局或按连接禁用自旋位。即使管理员未禁用自旋位，端点 MUST 在每 16 条网络路径中随机选择至少一条路径， 或每 16 个连接 ID 中随机选择一个，禁用其自旋位的使用， 以确保禁用自旋位的 QUIC 连接在网络上常见可见。 由于每个端点独立禁用自旋位，这确保自旋位信号在大约八分之一的 网络路径上被禁用。¶

当自旋位被禁用时，端点 MAY 将自旋位设置为 任意值，并且 MUST 忽略任何传入值。RECOMMENDED 端点将自旋 位设置为随机值，该值可为每个分组独立选择，也可为每个连接 ID 独立选择。¶

如果连接启用了自旋位，端点会为每条网络路径维护一个自旋 值，并在该路径上发送 1-RTT 分组时，将分组报头中的自旋位设置为 当前存储的值。自旋值在每个端点针对每条网络路径初始化为 0。 每个端点还会记住在每条路径上从其对等方看到的最高分组编号。¶

当服务器收到使其在给定网络路径上从客户端看到的最高 分组编号增加的 1-RTT 分组时，它会将该路径的自旋值设置为等于 收到分组中的自旋位。¶

当客户端收到使其在给定网络路径上从服务器看到的最高 分组编号增加的 1-RTT 分组时，它会将该路径的自旋值设置为收到分组中 自旋位的反值。¶

端点在更改某条网络路径上使用的连接 ID 时，会将该网络路径的 自旋值重置为 0。¶

18.1. 保留传输 参数

标识符形式为 31 * N + 27 的传输参数 （其中 N 为整数值）被保留，用于演练未知传输参数必须被忽略的 要求。这些传输参数没有语义，可以承载任意值。¶

18.2. 传输参数 定义

本节详细说明本文档中定义的传输参数。¶

这里列出的许多传输参数具有整数值。那些被标识为整数的 传输参数使用可变长度整数编码；见 第 16 节。 除非另有说明，如果传输参数不存在，则其默认值为 0。¶

定义了以下传输参数：¶

original_destination_connection_id (0x00):

此参数是客户端发送的第一个 Initial 分组中的 Destination Connection ID 字段值；见 第 7.3 节。此传输 参数仅由服务器发送。¶

max_idle_timeout (0x01):

最大空闲超时是以毫秒为单位的值， 编码为整数；见（第 10.1 节）。 当两个端点都省略此传输参数或指定值为 0 时，空闲超时被禁用。¶

stateless_reset_token (0x02):

无状态重置令牌用于验证无状态重置；见 第 10.3 节。此参数是 16 字节序列。 此传输参数 MUST NOT 由客户端发送，但 MAY 由服务器发送。 未发送此传输参数的服务器，不能对握手期间协商的连接 ID 使用 无状态重置（第 10.3 节）。¶

max_udp_payload_size (0x03):

最大 UDP 载荷大小参数是一个整数值， 限制端点愿意接收的 UDP 载荷大小。载荷大于此限制的 UDP 数据报 不太可能由接收方处理。¶

此参数的默认值是最大允许 UDP 载荷 65527。 低于 1200 的值无效。¶

此限制确实会以与路径 MTU 相同的方式 作为数据报大小的额外约束，但它是端点的属性，而不是路径的属性； 见 第 14 节。预期这是端点专门用于 保存传入分组的空间。¶

initial_max_data (0x04):

初始最大数据参数是一个整数值， 包含连接上可发送数据最大数量的初始值。这等同于在完成握手后 立即为连接发送 MAX_DATA（第 19.9 节）。¶

initial_max_stream_data_bidi_local (0x05):

此参数是一个整数值，指定本地发起的 双向流的初始流量控制限制。此限制适用于发送该传输参数的端点所打开的 新创建双向流。在客户端传输参数中，这适用于标识符最低有效两位 设置为 0x00 的流；在服务器传输参数中，这适用于最低有效两位 设置为 0x01 的流。¶

initial_max_stream_data_bidi_remote (0x06):

此参数是一个整数值，指定对等方发起的 双向流的初始流量控制限制。此限制适用于接收该传输参数的端点所打开的 新创建双向流。在客户端传输参数中，这适用于标识符最低有效两位 设置为 0x01 的流；在服务器传输参数中，这适用于最低有效两位 设置为 0x00 的流。¶

initial_max_stream_data_uni (0x07):

此参数是一个整数值，指定单向流的 初始流量控制限制。此限制适用于接收该传输参数的端点所打开的 新创建单向流。在客户端传输参数中，这适用于标识符最低有效两位 设置为 0x03 的流；在服务器传输参数中，这适用于最低有效两位 设置为 0x02 的流。¶

initial_max_streams_bidi (0x08):

初始最大双向流参数是一个整数值， 包含接收此传输参数的端点被允许发起的双向流初始最大数量。 如果此参数不存在或为零，则对等方在发送 MAX_STREAMS 帧之前 不能打开双向流。设置此参数等同于发送具有相同值的相应类型 MAX_STREAMS（第 19.11 节）。¶

initial_max_streams_uni (0x09):

初始最大单向流参数是一个整数值， 包含接收此传输参数的端点被允许发起的单向流初始最大数量。 如果此参数不存在或为零，则对等方在发送 MAX_STREAMS 帧之前 不能打开单向流。设置此参数等同于发送具有相同值的相应类型 MAX_STREAMS（第 19.11 节）。¶

ack_delay_exponent (0x0a):

确认延迟指数是一个整数值，指示用于解码 ACK 帧（第 19.3 节）中 ACK Delay 字段的指数。 如果此值不存在，则假定默认值为 3（表示乘数为 8）。 大于 20 的值无效。¶

max_ack_delay (0x0b):

最大确认延迟是一个整数值，指示端点将延迟发送 确认的最大时间量，以毫秒为单位。此值 SHOULD 包含接收方预计的闹钟触发延迟。例如，如果接收方设置 5ms 的定时器， 而闹钟通常最多晚触发 1ms，那么它应该发送 6ms 的 max_ack_delay。 如果此值不存在，则假定默认值为 25 毫秒。大于或等于 2¹⁴ 的值无效。¶

disable_active_migration (0x0c):

如果端点不支持在握手期间所用地址上的 主动连接迁移（第 9 节），则包含 disable active migration 传输参数。 收到此传输参数的端点 MUST NOT 在向对等方握手期间使用的 地址发送时使用新的本地地址。此传输参数不禁止客户端对 preferred_address 传输参数采取行动后的连接迁移。此参数是零长度值。¶

preferred_address (0x0d):

服务器的首选地址用于在握手结束时实现服务器地址变更， 如 第 9.6 节所述。此传输参数仅由服务器发送。服务器 MAY 选择只发送一个地址族的首选地址，方法是为另一个地址族 发送全零地址和端口（0.0.0.0:0 或 [::]:0）。IP 地址按网络字节序编码。¶

preferred_address 传输参数包含 IPv4 和 IPv6 的地址与端口。 四字节 IPv4 Address 字段后跟关联的两字节 IPv4 Port 字段。 随后是 16 字节 IPv6 Address 字段和两字节 IPv6 Port 字段。 在地址和端口对之后，Connection ID Length 字段描述后续 Connection ID 字段的长度。最后，16 字节 Stateless Reset Token 字段包含与该连接 ID 关联的无状态重置令牌。此传输参数的格式如下方 图 22 所示。¶

Connection ID 字段和 Stateless Reset Token 字段包含一个 序列号为 1 的替代连接 ID；见 第 5.1.1 节。 将这些值与首选地址一起发送，可以确保当客户端发起向首选地址的迁移时， 至少有一个未使用的活动连接 ID。¶

首选地址的 Connection ID 和 Stateless Reset Token 字段 在语法和语义上与 NEW_CONNECTION_ID 帧（第 19.15 节）的对应字段相同。选择零长度连接 ID 的服务器 MUST NOT 提供首选地址。类似地，服务器 MUST NOT 在此传输参数中包含零长度连接 ID。 客户端 MUST 将违反这些要求视为 类型为 TRANSPORT_PARAMETER_ERROR 的连接错误。¶

Preferred Address {
  IPv4 Address (32),
  IPv4 Port (16),
  IPv6 Address (128),
  IPv6 Port (16),
  Connection ID Length (8),
  Connection ID (..),
  Stateless Reset Token (128),
}

active_connection_id_limit (0x0e):

这是一个整数值，指定端点愿意存储的来自对等方的 最大连接 ID 数量。此值包括握手期间收到的连接 ID、 在 preferred_address 传输参数中收到的连接 ID，以及在 NEW_CONNECTION_ID 帧中收到的连接 ID。 active_connection_id_limit 参数的值 MUST 至少为 2。 收到小于 2 的值的端点 MUST 以 TRANSPORT_PARAMETER_ERROR 类型的错误关闭连接。 如果此传输参数不存在，则假定默认值为 2。如果端点签发零长度连接 ID， 它永远不会发送 NEW_CONNECTION_ID 帧，因此会忽略从对等方收到的 active_connection_id_limit 值。¶

initial_source_connection_id (0x0f):

这是端点在其为连接发送的第一个 Initial 分组的 Source Connection ID 字段中包含的值；见 第 7.3 节。¶

retry_source_connection_id (0x10):

这是服务器在 Retry 分组的 Source Connection ID 字段中包含的值；见 第 7.3 节。 此传输参数仅由服务器发送。¶

如果存在，设置初始逐流流量控制限制的传输参数 （initial_max_stream_data_bidi_local、initial_max_stream_data_bidi_remote 和 initial_max_stream_data_uni）等同于在每个相应类型的流打开后立即 在该流上发送 MAX_STREAM_DATA 帧（第 19.10 节）。 如果传输参数不存在，该类型的流以 0 的流量控制限制开始。¶

客户端 MUST NOT 包含任何仅限服务器的 传输参数： original_destination_connection_id、preferred_address、 retry_source_connection_id 或 stateless_reset_token。服务器 MUST 将收到任何这些传输参数视为类型为 TRANSPORT_PARAMETER_ERROR 的连接错误。¶

19.1. PADDING 帧

PADDING 帧（type=0x00）没有语义值。PADDING 帧可用于 增加分组大小。填充可用于将 Initial 分组增加到所需的最小大小， 或为受保护分组提供抵抗流量分析的保护。¶

PADDING 帧的格式如 图 23 所示，该图表明 PADDING 帧没有内容。也就是说，PADDING 帧由标识该帧为 PADDING 帧的单个字节组成。¶

PADDING Frame {
  Type (i) = 0x00,
}

19.2. PING 帧

端点可以使用 PING 帧（type=0x01）验证其对等方是否仍然 存活，或检查到对等方的可达性。¶

PING 帧的格式如 图 24 所示，该图表明 PING 帧没有内容。¶

PING Frame {
  Type (i) = 0x01,
}

PING 帧的接收方只需确认包含此帧的分组。¶

当应用或应用协议希望防止连接超时时，可以使用 PING 帧保持连接存活；见 第 10.1.2 节。¶

19.3. ACK 帧

接收方发送 ACK 帧（类型 0x02 和 0x03），以通知发送方其已 收到并处理的分组。ACK 帧包含一个或多个 ACK Range。 ACK Range 标识被确认的分组。如果帧类型为 0x03，ACK 帧还包含 到目前为止在连接上接收到的带有关联 ECN 标记的 QUIC 分组累计计数。 QUIC 实现 MUST 正确处理这两种类型，并且如果它们已为 自己发送的分组启用 ECN，则 SHOULD 使用 ECN 部分中的信息 管理其拥塞状态。¶

QUIC 确认是不可撤销的。一旦被确认，即使某个分组不出现在 未来的 ACK 帧中，它仍保持被确认状态。这不同于 TCP 选择性确认 （SACK）的撤销 [RFC2018]。¶

来自不同分组编号空间的分组可以使用相同的数值标识。 对分组的确认需要同时指示分组编号和分组编号空间。这通过让每个 ACK 帧只确认与承载该 ACK 帧的分组处于同一空间中的分组编号来完成。¶

Version Negotiation 和 Retry 分组不能被确认，因为它们不包含 分组编号。这些分组不依赖 ACK 帧，而是由客户端发送的下一个 Initial 分组隐式确认。¶

ACK 帧的格式如 图 25 所示。¶

ACK Frame {
  Type (i) = 0x02..0x03,
  Largest Acknowledged (i),
  ACK Delay (i),
  ACK Range Count (i),
  First ACK Range (i),
  ACK Range (..) ...,
  [ECN Counts (..)],
}

ACK 帧包含以下字段：¶

Largest Acknowledged:

一个可变长度整数，表示对等方正在确认的最大分组编号； 这通常是对等方在生成 ACK 帧之前收到的最大分组编号。 不同于 QUIC 长报头或短报头中的分组编号，ACK 帧中的值不会被截断。¶

ACK Delay:

一个可变长度整数，以微秒为单位编码确认延迟； 见 第 13.2.5 节。它通过将字段中的值 乘以 ACK 帧发送方所发送的 ack_delay_exponent 传输参数的 2 次幂来解码；见 第 18.2 节。与简单地 将延迟表示为整数相比，这种编码允许在相同字节数内表示更大的 值范围，代价是分辨率较低。¶

ACK Range Count:

一个可变长度整数，指定帧中 ACK Range 字段的数量。¶

First ACK Range:

一个可变长度整数，指示 Largest Acknowledged 之前 连续被确认分组的数量。也就是说，通过从 Largest Acknowledged 字段减去 First ACK Range 值来确定该范围中被确认的最小分组。¶

ACK Ranges:

包含额外的分组范围，这些范围在未确认（Gap）和 已确认（ACK Range）之间交替；见 第 19.3.1 节。¶

ECN Counts:

三个 ECN 计数；见 第 19.3.2 节。¶

ACK Range {
  Gap (i),
  ACK Range Length (i),
}

   smallest = largest - ack_range

   largest = previous_smallest - gap - 2

ECN Counts {
  ECT0 Count (i),
  ECT1 Count (i),
  ECN-CE Count (i),
}

19.4. RESET_STREAM 帧

端点使用 RESET_STREAM 帧（type=0x04）突然终止 流的发送部分。¶

发送 RESET_STREAM 后，端点停止在所标识的流上传输和重传 STREAM 帧。RESET_STREAM 的接收方可以丢弃它已经在该流上收到的任何数据。¶

端点如果收到针对仅发送流的 RESET_STREAM 帧， MUST 以 STREAM_STATE_ERROR 错误终止连接。¶

RESET_STREAM 帧的格式如 图 28 所示。¶

RESET_STREAM Frame {
  Type (i) = 0x04,
  Stream ID (i),
  Application Protocol Error Code (i),
  Final Size (i),
}

RESET_STREAM 帧包含以下字段：¶

Stream ID:

被终止流的流 ID 的可变长度整数编码。¶

Application Protocol Error Code:

一个可变长度整数，包含指示为何关闭该流的 应用协议错误码（见 第 20.2 节）。¶

Final Size:

一个可变长度整数，指示 RESET_STREAM 发送方给出的 流最终大小，以字节为单位；见 第 4.5 节。¶

19.5. STOP_SENDING 帧

端点使用 STOP_SENDING 帧（type=0x05）传达其正在根据应用请求 在接收时丢弃传入数据。STOP_SENDING 请求对等方停止在流上传输。¶

STOP_SENDING 帧可以为处于“Recv”或“Size Known”状态的流发送； 见 第 3.2 节。收到针对尚未创建的 本地发起流的 STOP_SENDING 帧，MUST 被视为 类型为 STREAM_STATE_ERROR 的连接错误。收到针对仅接收流的 STOP_SENDING 帧的端点 MUST 以 STREAM_STATE_ERROR 错误终止连接。¶

STOP_SENDING 帧的格式如 图 29 所示。¶

STOP_SENDING Frame {
  Type (i) = 0x05,
  Stream ID (i),
  Application Protocol Error Code (i),
}

STOP_SENDING 帧包含以下字段：¶

Stream ID:

一个可变长度整数，承载被忽略流的流 ID。¶

Application Protocol Error Code:

一个可变长度整数，包含应用指定的发送方忽略该流的原因； 见 第 20.2 节。¶

19.6. CRYPTO 帧

CRYPTO 帧（type=0x06）用于传输加密握手消息。 它可以在除 0-RTT 之外的所有分组类型中发送。CRYPTO 帧为 加密协议提供有序字节流。CRYPTO 帧在功能上与 STREAM 帧相同， 但它们不携带流标识符；不受流量控制；也不携带可选偏移量、 可选长度和流结束标记。¶

CRYPTO 帧的格式如 图 30 所示。¶

CRYPTO Frame {
  Type (i) = 0x06,
  Offset (i),
  Length (i),
  Crypto Data (..),
}

CRYPTO 帧包含以下字段：¶

Offset:

一个可变长度整数，指定此 CRYPTO 帧中数据在流中的 字节偏移量。¶

Length:

一个可变长度整数，指定此 CRYPTO 帧中 Crypto Data 字段的长度。¶

Crypto Data:

加密消息数据。¶

每个加密级别中都有单独的加密握手数据流， 每个流都从偏移量 0 开始。这意味着每个加密级别都被视为 单独的 CRYPTO 数据流。¶

流上传递的最大偏移量——偏移量与数据长度之和——不能超过 2⁶²-1。收到超过此限制的帧 MUST 被视为类型为 FRAME_ENCODING_ERROR 或 CRYPTO_BUFFER_EXCEEDED 的连接错误。¶

不同于包含流 ID 来指示数据属于哪个流的 STREAM 帧， CRYPTO 帧为每个加密级别承载单个流的数据。该流没有显式结束， 因此 CRYPTO 帧没有 FIN 位。¶

19.7. NEW_TOKEN 帧

服务器发送 NEW_TOKEN 帧（type=0x07），为客户端提供一个 可在未来连接的 Initial 分组报头中发送的令牌。¶

NEW_TOKEN 帧的格式如 图 31 所示。¶

NEW_TOKEN Frame {
  Type (i) = 0x07,
  Token Length (i),
  Token (..),
}

NEW_TOKEN 帧包含以下字段：¶

Token Length:

一个可变长度整数，指定令牌的长度，以字节为单位。¶

Token:

客户端可与未来 Initial 分组一起使用的不透明 blob。 令牌 MUST NOT 为空。客户端 MUST 将收到 Token 字段为空的 NEW_TOKEN 帧视为 类型为 FRAME_ENCODING_ERROR 的连接错误。¶

如果错误地确定包含该帧的分组已经丢失，客户端可能收到 多个包含相同令牌值的 NEW_TOKEN 帧。客户端负责丢弃重复值， 这些重复值可能被用于关联连接尝试；见 第 8.1.3 节。¶

客户端 MUST NOT 发送 NEW_TOKEN 帧。 服务器 MUST 将收到 NEW_TOKEN 帧视为 类型为 PROTOCOL_VIOLATION 的连接错误。¶

19.8. STREAM 帧

STREAM 帧隐式创建流并承载流数据。STREAM 帧中的 Type 字段 采用 0b00001XXX 形式（或从 0x08 到 0x0f 的值集合）。 帧类型的三个低位决定帧中存在的字段：¶

• 帧类型中的 OFF 位（0x04）被设置时表示 存在 Offset 字段。当设置为 1 时，Offset 字段存在。当设置为 0 时， Offset 字段不存在，Stream Data 从偏移量 0 开始（也就是说， 该帧包含流的第一个字节，或包含无数据流的结束）。¶
• 帧类型中的 LEN 位（0x02）被设置时表示 存在 Length 字段。如果此位设置为 0，则 Length 字段不存在， Stream Data 字段延伸到分组末尾。如果此位设置为 1， Length 字段存在。¶
• FIN 位（0x01）表示该帧标记流的结束。 流的最终大小是此帧的偏移量与长度之和。¶

端点如果收到针对尚未创建的本地发起流或仅发送流的 STREAM 帧，MUST 以 STREAM_STATE_ERROR 错误终止连接。¶

STREAM 帧的格式如 图 32 所示。¶

STREAM Frame {
  Type (i) = 0x08..0x0f,
  Stream ID (i),
  [Offset (i)],
  [Length (i)],
  Stream Data (..),
}

STREAM 帧包含以下字段：¶

Stream ID:

一个可变长度整数，指示该流的流 ID；见 第 2.1 节。¶

Offset:

一个可变长度整数，指定此 STREAM 帧中数据在流中的 字节偏移量。当 OFF 位设置为 1 时，此字段存在。 当 Offset 字段不存在时，偏移量为 0。¶

Length:

一个可变长度整数，指定此 STREAM 帧中 Stream Data 字段的长度。当 LEN 位设置为 1 时，此字段存在。 当 LEN 位设置为 0 时，Stream Data 字段会消耗分组中所有剩余字节。¶

Stream Data:

要交付的指定流中的字节。¶

当 Stream Data 字段长度为 0 时，STREAM 帧中的偏移量是 将发送的下一个字节的偏移量。¶

流中的第一个字节偏移量为 0。流上传递的最大偏移量 ——偏移量与数据长度之和——不能超过 2⁶²-1，因为无法为该数据提供流量控制额度。 收到超过此限制的帧 MUST 被视为类型为 FRAME_ENCODING_ERROR 或 FLOW_CONTROL_ERROR 的连接错误。¶

19.9. MAX_DATA 帧

MAX_DATA 帧（type=0x10）用于流量控制，以通知对等方 在整个连接上可以发送的最大数据量。¶

MAX_DATA 帧的格式如 图 33 所示。¶

MAX_DATA Frame {
  Type (i) = 0x10,
  Maximum Data (i),
}

MAX_DATA 帧包含以下字段：¶

Maximum Data:

一个可变长度整数，指示整个连接上可以发送的 最大数据量，以字节为单位。¶

STREAM 帧中发送的所有数据都计入此限制。 所有流上的最终大小之和——包括处于终止状态的流——MUST NOT 超过 接收方通告的值。如果端点接收的数据超过其已发送的最大数据值， 则端点 MUST 以类型为 FLOW_CONTROL_ERROR 的错误终止连接。 这包括 Early Data 中违反记住限制的情况；见 第 7.4.1 节。¶

19.10. MAX_STREAM_DATA 帧

MAX_STREAM_DATA 帧（type=0x11）用于流量控制， 以通知对等方在某个流上可以发送的最大数据量。¶

MAX_STREAM_DATA 帧可以为处于“Recv”状态的流发送； 见 第 3.2 节。收到针对尚未创建的 本地发起流的 MAX_STREAM_DATA 帧，MUST 被视为 类型为 STREAM_STATE_ERROR 的连接错误。收到针对仅接收流的 MAX_STREAM_DATA 帧的端点 MUST 以 STREAM_STATE_ERROR 错误终止连接。¶

MAX_STREAM_DATA 帧的格式如 图 34 所示。¶

MAX_STREAM_DATA Frame {
  Type (i) = 0x11,
  Stream ID (i),
  Maximum Stream Data (i),
}

MAX_STREAM_DATA 帧包含以下字段：¶

Stream ID:

受影响流的流 ID，编码为可变长度整数。¶

Maximum Stream Data:

一个可变长度整数，指示在所标识流上可以发送的 最大数据量，以字节为单位。¶

在将数据计入此限制时，端点会考虑在流上发送或接收的数据的 最大已接收偏移量。丢包或重排序可能意味着，流上的最大已接收偏移量 可能大于该流上接收的数据总大小。收到 STREAM 帧 可能不会增加最大已接收偏移量。¶

在流上发送的数据 MUST NOT 超过 接收方通告的最大流数据值中的最大者。如果端点收到的数据超过 它已为受影响流发送的最大流数据值，则端点 MUST 以类型为 FLOW_CONTROL_ERROR 的错误终止连接。这包括 Early Data 中 违反记住限制的情况；见 第 7.4.1 节。¶

19.11. MAX_STREAMS 帧

MAX_STREAMS 帧（type=0x12 或 0x13）通知对等方 其被允许打开的给定类型流的累计数量。类型为 0x12 的 MAX_STREAMS 帧 适用于双向流，类型为 0x13 的 MAX_STREAMS 帧适用于单向流。¶

MAX_STREAMS 帧的格式如 图 35 所示。¶

MAX_STREAMS Frame {
  Type (i) = 0x12..0x13,
  Maximum Streams (i),
}

MAX_STREAMS 帧包含以下字段：¶

Maximum Streams:

在连接生命周期内可以打开的相应类型流的累计数量。 此值不能超过 2⁶⁰，因为无法编码大于 2⁶²-1 的流 ID。收到允许打开大于此限制的流的帧 MUST 被视为类型为 FRAME_ENCODING_ERROR 的连接错误。¶

丢包或重排序可能导致端点收到的 MAX_STREAMS 帧中流限制 低于先前收到的值。不增加流限制的 MAX_STREAMS 帧 MUST 被忽略。¶

端点 MUST NOT 打开超过其对等方设置的 当前流限制所允许的流。例如，收到单向流限制 3 的服务器 被允许打开流 3、7 和 11，但不能打开流 15。 如果对等方打开的流超过允许数量，端点 MUST 以类型为 STREAM_LIMIT_ERROR 的错误终止连接。这包括 Early Data 中 违反记住限制的情况；见 第 7.4.1 节。¶

注意，这些帧（以及相应的传输参数）并不描述可以并发打开的 流数量。该限制包括已经关闭的流以及打开的流。¶

19.12. DATA_BLOCKED 帧

发送方希望发送数据但由于连接级流量控制而无法发送时， SHOULD 发送 DATA_BLOCKED 帧 （type=0x14）；见 第 4 节。DATA_BLOCKED 帧可用作 调整流量控制算法的输入；见 第 4.2 节。¶

DATA_BLOCKED 帧的格式如 图 36 所示。¶

DATA_BLOCKED Frame {
  Type (i) = 0x14,
  Maximum Data (i),
}

DATA_BLOCKED 帧包含以下字段：¶

Maximum Data:

一个可变长度整数，指示发生阻塞时的连接级限制。¶

19.13. STREAM_DATA_BLOCKED 帧

发送方希望发送数据但由于流级流量控制而无法发送时， SHOULD 发送 STREAM_DATA_BLOCKED 帧 （type=0x15）。此帧类似于 DATA_BLOCKED（第 19.12 节）。¶

端点如果收到针对仅发送流的 STREAM_DATA_BLOCKED 帧， MUST 以 STREAM_STATE_ERROR 错误终止连接。¶

STREAM_DATA_BLOCKED 帧的格式如 图 37 所示。¶

STREAM_DATA_BLOCKED Frame {
  Type (i) = 0x15,
  Stream ID (i),
  Maximum Stream Data (i),
}

STREAM_DATA_BLOCKED 帧包含以下字段：¶

Stream ID:

一个可变长度整数，指示因流量控制而被阻塞的流。¶

Maximum Stream Data:

一个可变长度整数，指示发生阻塞时的流偏移量。¶

19.14. STREAMS_BLOCKED 帧

发送方希望打开流但由于其对等方设置的最大流限制而无法打开时， SHOULD 发送 STREAMS_BLOCKED 帧 （type=0x16 或 0x17）；见 第 19.11 节。 类型为 0x16 的 STREAMS_BLOCKED 帧用于指示达到双向流限制， 类型为 0x17 的 STREAMS_BLOCKED 帧用于指示达到单向流限制。¶

STREAMS_BLOCKED 帧不会打开流，而是通知对等方需要新流， 但流限制阻止了该流的创建。¶

STREAMS_BLOCKED 帧的格式如 图 38 所示。¶

STREAMS_BLOCKED Frame {
  Type (i) = 0x16..0x17,
  Maximum Streams (i),
}

STREAMS_BLOCKED 帧包含以下字段：¶

Maximum Streams:

一个可变长度整数，指示发送该帧时允许的最大流数量。 此值不能超过 2⁶⁰，因为无法编码大于 2⁶²-1 的流 ID。收到编码了更大流 ID 的帧 MUST 被视为类型为 STREAM_LIMIT_ERROR 或 FRAME_ENCODING_ERROR 的连接错误。¶

19.15. NEW_CONNECTION_ID 帧

端点发送 NEW_CONNECTION_ID 帧（type=0x18），以向其对等方提供 替代连接 ID，这些连接 ID 可用于在迁移连接时破坏可关联性； 见 第 9.5 节。¶

NEW_CONNECTION_ID 帧的格式如 图 39 所示。¶

NEW_CONNECTION_ID Frame {
  Type (i) = 0x18,
  Sequence Number (i),
  Retire Prior To (i),
  Length (8),
  Connection ID (8..160),
  Stateless Reset Token (128),
}

NEW_CONNECTION_ID 帧包含以下字段：¶

Sequence Number:

发送方分配给连接 ID 的序列号，编码为 可变长度整数；见 第 5.1.1 节。¶

Retire Prior To:

一个可变长度整数，指示哪些连接 ID 应该退役； 见 第 5.1.2 节。¶

Length:

一个 8 位无符号整数，包含连接 ID 的长度。 小于 1 和大于 20 的值无效，并且 MUST 被视为 类型为 FRAME_ENCODING_ERROR 的连接错误。¶

Connection ID:

指定长度的连接 ID。¶

Stateless Reset Token:

一个 128 位值，当使用关联连接 ID 时， 该值将用于无状态重置；见 第 10.3 节。¶

如果端点当前要求其对等方使用零长度 Destination Connection ID 发送分组，则它 MUST NOT 发送此帧。 将连接 ID 的长度更改为零长度或从零长度更改，会使识别连接 ID 值何时更改变得困难。 正在发送带零长度 Destination Connection ID 的分组的端点 MUST 将收到 NEW_CONNECTION_ID 帧视为 类型为 PROTOCOL_VIOLATION 的连接错误。¶

传输错误、超时和重传可能导致同一个 NEW_CONNECTION_ID 帧被多次接收。多次收到同一个帧 MUST NOT 被视为连接错误。 接收方可以使用 NEW_CONNECTION_ID 帧中提供的序列号来处理 多次收到同一个 NEW_CONNECTION_ID 帧的情况。¶

如果端点收到的 NEW_CONNECTION_ID 帧重复了先前签发的连接 ID， 但 Stateless Reset Token 字段值不同或 Sequence Number 字段值不同， 或者一个序列号被用于不同的连接 ID，则端点 MAY 将该接收视为类型为 PROTOCOL_VIOLATION 的连接错误。¶

Retire Prior To 字段适用于连接建立期间建立的连接 ID 和 preferred_address 传输参数；见 第 5.1.2 节。Retire Prior To 字段中的值 MUST 小于或等于 Sequence Number 字段中的值。 收到 Retire Prior To 字段中的值大于 Sequence Number 字段中的值时， MUST 被视为类型为 FRAME_ENCODING_ERROR 的连接错误。¶

一旦发送方指示了 Retire Prior To 值，后续 NEW_CONNECTION_ID 帧中发送的较小值就没有效果。接收方 MUST 忽略任何 不增加已接收最大 Retire Prior To 值的 Retire Prior To 字段。¶

端点如果收到 NEW_CONNECTION_ID 帧，其序列号小于先前收到的 NEW_CONNECTION_ID 帧的 Retire Prior To 字段，则 MUST 发送相应的 RETIRE_CONNECTION_ID 帧来退役新收到的连接 ID， 除非它已经为该序列号这样做过。¶

19.16. RETIRE_CONNECTION_ID 帧

端点发送 RETIRE_CONNECTION_ID 帧（type=0x19），以指示它 将不再使用其对等方签发的连接 ID。这包括握手期间提供的连接 ID。 发送 RETIRE_CONNECTION_ID 帧也作为请求对等方发送更多连接 ID 供未来使用； 见 第 5.1 节。新的连接 ID 可以使用 NEW_CONNECTION_ID 帧（第 19.15 节）交付给对等方。¶

退役连接 ID 会使与该连接 ID 关联的无状态重置令牌失效。¶

RETIRE_CONNECTION_ID 帧的格式如 图 40 所示。¶

RETIRE_CONNECTION_ID Frame {
  Type (i) = 0x19,
  Sequence Number (i),
}

RETIRE_CONNECTION_ID 帧包含以下字段：¶

Sequence Number:

正在退役的连接 ID 的序列号；见 第 5.1.2 节。¶

收到包含大于先前发送给对等方的任何序列号的 RETIRE_CONNECTION_ID 帧，MUST 被视为 类型为 PROTOCOL_VIOLATION 的连接错误。¶

RETIRE_CONNECTION_ID 帧中指定的序列号 MUST NOT 指向承载该帧的分组的 Destination Connection ID 字段。对等方 MAY 将其视为类型为 PROTOCOL_VIOLATION 的连接错误。¶

如果端点被其对等方提供了零长度连接 ID，则不能发送此帧。 提供零长度连接 ID 的端点 MUST 将收到 RETIRE_CONNECTION_ID 帧视为类型为 PROTOCOL_VIOLATION 的连接错误。¶

19.17. PATH_CHALLENGE 帧

端点可以使用 PATH_CHALLENGE 帧（type=0x1a）检查到对等方的 可达性，并在连接迁移期间进行路径验证。¶

PATH_CHALLENGE 帧的格式如 图 41 所示。¶

PATH_CHALLENGE Frame {
  Type (i) = 0x1a,
  Data (64),
}

PATH_CHALLENGE 帧包含以下字段：¶

Data:

此 8 字节字段包含任意数据。¶

在 PATH_CHALLENGE 帧中包含 64 位熵，可确保接收该分组 比正确猜测该值更容易。¶

此帧的接收方 MUST 生成包含相同 Data 值的 PATH_RESPONSE 帧 （第 19.18 节）。¶

19.18. PATH_RESPONSE 帧

PATH_RESPONSE 帧（type=0x1b）是为响应 PATH_CHALLENGE 帧而发送的。¶

PATH_RESPONSE 帧的格式如 图 42 所示。PATH_RESPONSE 帧的格式 与 PATH_CHALLENGE 帧相同；见 第 19.17 节。¶

PATH_RESPONSE Frame {
  Type (i) = 0x1b,
  Data (64),
}

如果 PATH_RESPONSE 帧的内容与端点先前发送的 PATH_CHALLENGE 帧内容不匹配，则端点 MAY 生成类型为 PROTOCOL_VIOLATION 的连接错误。¶

19.19. CONNECTION_CLOSE 帧

端点发送 CONNECTION_CLOSE 帧（type=0x1c 或 0x1d）来通知其 对等方连接正在关闭。类型为 0x1c 的 CONNECTION_CLOSE 帧用于仅在 QUIC 层发出错误信号，或表示不存在错误（使用 NO_ERROR 码）。 类型为 0x1d 的 CONNECTION_CLOSE 帧用于发出使用 QUIC 的应用发生错误的信号。¶

如果存在未被显式关闭的打开流，则在连接关闭时它们会被 隐式关闭。¶

CONNECTION_CLOSE 帧的格式如 图 43 所示。¶

CONNECTION_CLOSE Frame {
  Type (i) = 0x1c..0x1d,
  Error Code (i),
  [Frame Type (i)],
  Reason Phrase Length (i),
  Reason Phrase (..),
}

CONNECTION_CLOSE 帧包含以下字段：¶

Error Code:

一个可变长度整数，指示关闭此连接的原因。 类型为 0x1c 的 CONNECTION_CLOSE 帧使用 第 20.1 节中定义空间的错误码。 类型为 0x1d 的 CONNECTION_CLOSE 帧使用应用协议定义的错误码； 见 第 20.2 节。¶

Frame Type:

一个可变长度整数，编码触发错误的帧类型。 当帧类型未知时，使用值 0（等同于提及 PADDING 帧）。 CONNECTION_CLOSE 的应用特定变体（type 0x1d）不包含此字段。¶

Reason Phrase Length:

一个可变长度整数，指定原因短语的长度，以字节为单位。 因为 CONNECTION_CLOSE 帧不能拆分到多个分组之间，所以任何分组大小限制 也会限制原因短语可用的空间。¶

Reason Phrase:

关于关闭的额外诊断信息。如果发送方选择不提供 超出 Error Code 值之外的详细信息，则其长度可以为零。 这 SHOULD 是 UTF-8 编码字符串 [RFC3629]，不过该帧不承载语言标签等信息， 这些信息本可帮助除创建该文本的一方之外的任何实体理解。¶

CONNECTION_CLOSE 的应用特定变体（type 0x1d）只能使用 0-RTT 或 1-RTT 分组发送；见 第 12.5 节。当应用希望在握手期间放弃连接时，端点 可以在 Initial 或 Handshake 分组中发送类型为 0x1c 且错误码为 APPLICATION_ERROR 的 CONNECTION_CLOSE 帧。¶

19.20. HANDSHAKE_DONE 帧

服务器使用 HANDSHAKE_DONE 帧（type=0x1e）向客户端发出 握手确认信号。¶

HANDSHAKE_DONE 帧的格式如 图 44 所示，该图 表明 HANDSHAKE_DONE 帧没有内容。¶

HANDSHAKE_DONE Frame {
  Type (i) = 0x1e,
}

HANDSHAKE_DONE 帧只能由服务器发送。服务器 MUST NOT 在完成握手之前发送 HANDSHAKE_DONE 帧。服务器 MUST 将收到 HANDSHAKE_DONE 帧视为类型为 PROTOCOL_VIOLATION 的连接错误。¶

19.21. 扩展帧

QUIC 帧不使用自描述编码。因此，端点需要理解所有帧的语法， 才能成功处理分组。这允许高效编码帧，但也意味着端点不能向其对等方 发送未知类型的帧。¶

希望使用新帧类型的 QUIC 扩展 MUST 首先确保 对等方能够理解该帧。端点可以使用传输参数来表明其愿意接收 扩展帧类型。一个传输参数可以指示支持一个或多个扩展帧类型。¶

修改或替换核心协议功能（包括帧类型）的扩展，如果与其他 修改或替换相同功能的扩展组合，将难以结合使用，除非明确 定义该组合的行为。此类扩展 SHOULD 定义它们与 先前定义的、修改相同协议组件的扩展之间的交互。¶

扩展帧 MUST 受拥塞控制， 并且 MUST 导致发送 ACK 帧。 例外是替换或补充 ACK 帧的扩展帧。除非扩展中指定， 扩展帧不纳入流量控制。¶

IANA 注册表用于管理帧类型的分配；见 第 22.4 节。¶

20.1. 传输错误码

本节列出了已定义的 QUIC 传输错误码，这些错误码可用于 类型为 0x1c 的 CONNECTION_CLOSE 帧。这些错误适用于整个连接。¶

NO_ERROR (0x00):

端点将其与 CONNECTION_CLOSE 一起使用， 表示在没有任何错误的情况下突然关闭连接。¶

INTERNAL_ERROR (0x01):

端点遇到内部错误，无法继续该连接。¶

CONNECTION_REFUSED (0x02):

服务器拒绝接受新连接。¶

FLOW_CONTROL_ERROR (0x03):

端点收到的数据超过了其通告的数据限制； 见 第 4 节。¶

STREAM_LIMIT_ERROR (0x04):

端点收到一个帧，其流标识符超过了 对应流类型的通告流限制。¶

STREAM_STATE_ERROR (0x05):

端点收到针对某个流的帧，而该流所处状态 不允许该帧；见 第 3 节。¶

FINAL_SIZE_ERROR (0x06):

(1) 端点收到一个包含数据的 STREAM 帧， 其数据超过了先前建立的最终大小；(2) 端点收到一个 STREAM 帧或 RESET_STREAM 帧，其中包含的最终大小小于已经收到的流数据大小；或 (3) 端点收到一个 STREAM 帧或 RESET_STREAM 帧，其中包含的最终大小 与已经建立的最终大小不同。¶

FRAME_ENCODING_ERROR (0x07):

端点收到格式错误的帧——例如， 未知类型的帧，或 ACK 帧包含的确认范围数量超过了 分组剩余部分能够承载的数量。¶

TRANSPORT_PARAMETER_ERROR (0x08):

端点收到格式错误的传输参数，包含无效值， 省略了强制传输参数，包含了被禁止的传输参数，或存在其他错误。¶

CONNECTION_ID_LIMIT_ERROR (0x09):

对等方提供的连接 ID 数量超过了通告的 active_connection_id_limit。¶

PROTOCOL_VIOLATION (0x0a):

端点检测到协议合规性错误，而该错误未被 更具体的错误码覆盖。¶

INVALID_TOKEN (0x0b):

服务器收到的客户端 Initial 中包含无效的 Token 字段。¶

APPLICATION_ERROR (0x0c):

应用或应用协议导致连接被关闭。¶

CRYPTO_BUFFER_EXCEEDED (0x0d):

端点在 CRYPTO 帧中收到的数据超过了其 能够缓冲的数量。¶

KEY_UPDATE_ERROR (0x0e):

端点在执行密钥更新时检测到错误；见 第 6 节，见 [QUIC-TLS]。¶

AEAD_LIMIT_REACHED (0x0f):

端点已经达到给定连接所使用 AEAD 算法的机密性或完整性限制。¶

NO_VIABLE_PATH (0x10):

端点已经确定网络路径无法支持 QUIC。 除非路径不支持足够大的 MTU，否则端点不太可能收到携带此代码的 CONNECTION_CLOSE 帧。¶

CRYPTO_ERROR (0x0100-0x01ff):

加密握手失败。保留 256 个值的范围， 用于承载所使用加密握手特有的错误码。当使用 TLS 进行加密握手时 发生错误的错误码，见 第 4.8 节，见 [QUIC-TLS]。¶

有关注册新错误码的详细信息，见 第 22.5 节。¶

定义这些错误码时应用了若干原则。可能要求接收方采取 特定操作的错误条件会被赋予唯一代码。表示常见条件的错误 会被赋予特定代码。如果不满足这两种条件，则错误码用于标识协议栈的 一般功能，例如流量控制或传输参数处理。最后，对于实现无法或不愿意 使用更具体代码的条件，提供通用错误。¶

20.2. 应用协议 错误码

应用错误码的管理留给应用协议。应用协议错误码用于 RESET_STREAM 帧（第 19.4 节）、 STOP_SENDING 帧（第 19.5 节），以及 类型为 0x1d 的 CONNECTION_CLOSE 帧（第 19.19 节）。¶

21.1. 安全属性概述

QUIC 的完整安全分析不在本文档范围内。 本节以非正式方式描述期望的安全属性，以帮助实现者并指导协议分析。¶

QUIC 假定 [SEC-CONS] 中描述的威胁模型，并针对 该模型产生的许多攻击提供保护。¶

为此，攻击被分为被动攻击和主动攻击。被动攻击者具有 从网络读取分组的能力，而主动攻击者还具有向网络写入分组的能力。 然而，被动攻击也可能涉及具有能力导致路由变化或对构成连接的分组所走路径 进行其他修改的攻击者。¶

攻击者还被进一步分类为路径上攻击者或路径外攻击者。 路径上攻击者可以读取、修改或移除它观察到的任何分组，使该分组不再到达 其目的地；而路径外攻击者观察分组，但不能阻止原始分组到达其预期目的地。 两类攻击者也都可以发送任意分组。此定义与 第 3.5 节 ，见 [SEC-CONS] 中的定义不同，因为这里的 路径外攻击者能够观察分组。¶

握手、受保护分组和连接迁移的属性将分别考虑。¶

21.2. 握手拒绝 服务

作为加密且经过认证的传输，QUIC 提供了一系列 抵御拒绝服务的保护。一旦加密握手完成，QUIC 端点会丢弃大多数 未经认证的分组，从而极大限制攻击者干扰现有连接的能力。¶

连接建立后，QUIC 端点可能接受某些未经认证的 ICMP 分组 （见 第 14.2.1 节），但这些分组的使用 极其有限。端点可能接受的唯一其他分组类型是无状态重置 （第 10.3 节），它依赖令牌在使用前 保持秘密。¶

在创建连接期间，QUIC 只提供针对网络路径外攻击的保护。 所有 QUIC 分组都包含证明：接收方看到了来自其对等方的前一个分组。¶

握手期间地址不能改变，因此端点可以丢弃在不同网络路径上 收到的分组。¶

Source 和 Destination Connection ID 字段是握手期间 防御路径外攻击的主要手段；见 第 8.1 节。它们必须与对等方设置的值匹配。 除 Initial 和 Stateless Reset 外，端点只接受包含 Destination Connection ID 字段且 该字段匹配端点先前选择值的分组。这是 Version Negotiation 分组所提供的唯一保护。¶

Initial 分组中的 Destination Connection ID 字段由客户端 选择为不可预测的值，这还有另一个目的。承载加密握手的分组使用 从该连接 ID 和特定于 QUIC 版本的 salt 派生的密钥进行保护。 这使端点能够使用与加密握手完成后相同的流程来认证其收到的分组。 无法认证的分组会被丢弃。以这种方式保护分组，强有力地保证了 分组发送方看到了 Initial 分组并理解了它。¶

这些保护并非旨在有效抵御能够在连接建立前接收 QUIC 分组的 攻击者。这样的攻击者可能发送会被 QUIC 端点接受的分组。 此版本的 QUIC 试图检测此类攻击，但预期端点会建立连接失败， 而不是恢复。大体而言，加密握手协议 [QUIC-TLS] 负责检测握手期间的篡改。¶

允许端点使用其他方法来检测并尝试从握手干扰中恢复。 无效分组可以使用其他方法识别和丢弃，但本文档不强制规定任何具体方法。¶

21.3. 放大攻击

攻击者可能能够从服务器接收地址验证令牌 （第 8 节），然后释放其用于获取该令牌的 IP 地址。稍后，攻击者可以通过伪造同一地址来与服务器发起 0-RTT 连接，而该地址现在可能指向不同的（受害）端点。因此，攻击者可能导致 服务器向受害者发送一个初始拥塞窗口大小的数据。¶

服务器 SHOULD 通过限制地址验证令牌的 使用和生命周期来缓解此攻击；见 第 8.1.3 节。¶

21.4. 乐观 ACK 攻击

确认其未收到分组的端点，可能导致拥塞控制器允许以 超出网络支持能力的速率发送。端点 MAY 在发送分组时跳过 分组编号以检测这种行为。端点随后可以立即以 PROTOCOL_VIOLATION 类型的连接错误关闭连接；见 第 10.2 节。¶

21.5. 请求伪造 攻击

请求伪造攻击发生在端点使其对等方向受害者发出请求， 且该请求由该端点控制的情况下。请求伪造攻击旨在让攻击者获得 其对等方所具备、而攻击者原本可能无法获得的能力。对于网络协议， 请求伪造攻击通常用于利用受害者因对等方在网络中的位置而授予该对等方的 任何隐式授权。¶

要使请求伪造有效，攻击者需要能够影响对等方发送什么分组 以及这些分组发送到哪里。如果攻击者能够使用受控载荷定位易受攻击的服务， 该服务可能执行归因于攻击者对等方但由攻击者决定的操作。¶

例如，Web 上的跨站请求伪造 [CSRF] 利用会导致客户端发出包含授权 cookie [COOKIE] 的请求，从而允许一个站点访问本应仅限于另一个站点的信息和操作。¶

由于 QUIC 运行在 UDP 之上，主要关注的攻击方式是： 攻击者能够选择其对等方发送 UDP 数据报的地址，并能控制这些分组中 一些未受保护的内容。由于 QUIC 端点发送的大部分数据受到保护， 这包括对密文的控制。如果攻击者能够使对等方向某个主机发送 UDP 数据报， 而该主机会基于数据报中的内容执行某些操作，则攻击成功。¶

本节讨论 QUIC 可能被用于请求伪造攻击的方式。¶

本节还描述了 QUIC 端点可以实现的有限对策。 这些缓解措施可由 QUIC 实现或部署单方面采用，而无需请求伪造攻击的潜在目标采取行动。 然而，如果基于 UDP 的服务未正确授权请求，这些对策可能不足。¶

由于 第 21.5.4 节中描述的迁移攻击非常强大且没有 足够的对策，QUIC 服务器实现应假定攻击者能够使其生成任意 UDP 载荷 并发送到任意目的地。QUIC 服务器 SHOULD NOT 部署在 未部署入口过滤 [BCP38] 且同时存在 安全性不足的 UDP 端点的网络中。¶

虽然通常无法确保客户端不与易受攻击的端点共处同一位置， 但此版本的 QUIC 不允许服务器迁移，因此防止了针对客户端的伪造迁移攻击。 任何允许服务器迁移的未来扩展 MUST 同时定义 针对伪造攻击的对策。¶

21.6. Slowloris 攻击

通常称为 Slowloris [SLOWLORIS] 的攻击试图保持大量 到目标端点的连接处于打开状态，并尽可能长时间保持打开。 这些攻击可以通过生成避免因不活动而关闭所需的最少活动量， 针对 QUIC 端点执行。这可能涉及发送少量数据、逐渐打开流量控制窗口以 控制发送方速率，或制造模拟高丢包率的 ACK 帧。¶

QUIC 部署 SHOULD 为 Slowloris 攻击提供缓解措施， 例如增加服务器允许的最大客户端数量、限制单个 IP 地址允许建立的连接数量、 对连接允许的最小传输速度施加限制，以及限制端点允许保持连接的时长。¶

21.7. 流分片 与重组攻击

恶意发送方可能故意不发送流数据的某些部分， 使接收方为未发送的数据投入资源。这可能导致接收缓冲区内存占用不成比例， 和/或在接收方创建庞大且低效的数据结构。¶

恶意接收方可能故意不确认包含流数据的分组， 试图迫使发送方存储未确认的流数据以便重传。¶

如果流量控制窗口与可用内存相对应，则针对接收方的攻击会得到缓解。 然而，一些接收方会过度承诺内存，并通告总体上超过实际可用内存的 流量控制偏移量。当端点行为良好时，过度承诺策略可以带来更好性能， 但会使端点容易受到流分片攻击。¶

QUIC 部署 SHOULD 为流分片攻击提供缓解措施。 缓解措施可以包括避免过度承诺内存、限制跟踪数据结构的大小、 延迟 STREAM 帧重组、实现基于重组空洞年龄和持续时间的启发式方法， 或这些措施的组合。¶

21.8. 流承诺 攻击

恶意端点可以打开大量流，耗尽端点上的状态。 恶意端点可以在大量连接上重复此过程，其方式类似于 TCP 中的 SYN 洪泛攻击。¶

通常，客户端会按顺序打开流，如 第 2.1 节所述。 然而，当多个流在短时间间隔内发起时，丢包或重排序可能导致打开流的 STREAM 帧乱序接收。收到更高编号的流 ID 时，接收方需要打开同一类型中 所有中间流；见 第 3.2 节。 因此，在新连接上，打开流 4000000 会打开 1000001 个 客户端发起的双向流。¶

活动流的数量受 initial_max_streams_bidi 和 initial_max_streams_uni 传输参数限制，并由收到的任何 MAX_STREAMS 帧更新，如 第 4.6 节所述。如果选择得当， 这些限制可以缓解流承诺攻击的影响。然而，如果限制设置过低， 当应用期望打开大量流时可能影响性能。¶

21.9. 对等方拒绝服务

QUIC 和 TLS 都包含在某些上下文中有合法用途的帧或消息， 但这些帧或消息可能被滥用，使对等方消耗处理资源，而对连接状态没有任何 可观察影响。¶

消息也可以用于以很小或无关紧要的方式改变并恢复状态， 例如发送对流量控制限制的小幅增量。¶

如果处理成本相对于带宽消耗或对状态的影响来说过大， 那么这可能允许恶意对等方耗尽处理能力。¶

虽然所有消息都有合法用途，但实现 SHOULD 跟踪处理成本相对于进展的比例， 并将任何大量无生产性分组视为攻击迹象。端点 MAY 通过连接错误响应该条件，或通过丢弃分组来响应。¶

21.10. 显式拥塞 通知攻击

路径上攻击者可能操纵 IP 报头中 ECN 字段的值， 以影响发送方速率。[RFC3168] 更详细地讨论了这些操纵及其影响。¶

有限路径上攻击者可以复制并发送修改了 ECN 字段的分组， 以影响发送方速率。如果接收方丢弃重复分组，攻击者需要使重复分组 与原始分组竞速，才能在此攻击中成功。因此，除非 IP 分组中的至少一个 QUIC 分组被成功处理，否则 QUIC 端点会忽略该 IP 分组中的 ECN 字段； 见 第 13.4 节。¶

21.11. 无状态重置 预言机

无状态重置会造成一种可能的拒绝服务攻击， 类似于 TCP 重置注入。如果攻击者能够导致为具有所选连接 ID 的连接生成 无状态重置令牌，则这种攻击是可能的。能够导致生成此令牌的攻击者 可以重置具有相同连接 ID 的活动连接。¶

如果分组可以被路由到共享静态密钥的不同实例——例如， 通过更改 IP 地址或端口——则攻击者可以导致服务器发送无状态重置。 为防御这种拒绝服务，针对无状态重置共享静态密钥的端点（见 第 10.3.2 节） MUST 被安排为：具有给定连接 ID 的分组始终到达 具有连接状态的实例，除非该连接不再活动。¶

更一般地说，如果具有相应连接 ID 的连接可能在任何使用 相同静态密钥的端点上处于活动状态，则服务器 MUST NOT 生成无状态重置。¶

在使用动态负载均衡的集群中，可能在活动实例仍保留连接状态时 发生负载均衡器配置变化。即使实例保留连接状态，路由变化以及由此产生的 无状态重置仍会导致连接终止。如果分组没有机会被路由到正确实例， 则发送无状态重置比等待连接超时更好。然而，只有当路由不能被攻击者影响时， 这才是可接受的。¶

21.12. 版本降级

本文档定义了 QUIC Version Negotiation 分组 （第 6 节），可用于在两个端点之间 协商使用的 QUIC 版本。然而，本文档未指定此版本与后续未来版本之间如何 执行该协商。特别是，Version Negotiation 分组不包含任何防止版本降级攻击的 机制。使用 Version Negotiation 分组的未来 QUIC 版本 MUST 定义一种能够稳健抵御版本降级攻击的机制。¶

21.13. 通过路由进行的 定向攻击

部署应限制攻击者将新连接定向到特定服务器实例的能力。 理想情况下，路由决策独立于客户端选择的值，包括地址。一旦实例被选中， 可以选择一个连接 ID，使后续分组被路由到同一实例。¶

21.14. 流量分析

QUIC 分组的长度可能泄露这些分组内容长度的信息。 PADDING 帧使端点在一定程度上能够掩盖分组内容长度；见 第 19.1 节。¶

击败流量分析具有挑战性，并且是活跃研究的主题。 长度并非信息可能泄露的唯一方式。端点还可能通过其他侧信道泄露敏感信息， 例如分组时序。¶

22.1. QUIC 注册表的 注册策略

所有 QUIC 注册表都允许码点的临时注册和永久注册。 本节记录这些注册表共有的策略。¶

22.2. QUIC Versions 注册表

IANA 已在 "QUIC" 标题下添加了 "QUIC Versions" 注册表。¶

"QUIC Versions" 注册表管理一个 32 位空间；见 第 15 节。该注册表遵循 第 22.1 节中的注册策略。 该注册表中的永久注册使用 Specification Required 策略分配 （[RFC8126] 的 第 4.6 节）。¶

协议的码点 0x00000001 被以永久状态分配给 本文档中定义的协议。码点 0x00000000 被永久保留；该码点的说明表明 此版本保留用于版本协商。¶

所有符合模式 0x?a?a?a?a 的码点均被保留， MUST NOT 由 IANA 分配，并且 MUST NOT 出现在已分配值列表中。¶

22.3. QUIC Transport Parameters 注册表

IANA 已在 "QUIC" 标题下添加了 "QUIC Transport Parameters" 注册表。¶

"QUIC Transport Parameters" 注册表管理一个 62 位空间。 该注册表遵循 第 22.1 节中的注册策略。 该注册表中的永久注册使用 Specification Required 策略分配 （[RFC8126] 的 第 4.6 节）， 但 0x00 到 0x3f（十六进制）之间的值（含两端）除外， 这些值使用 Standards Action 或 IESG Approval 分配，如 [RFC8126] 的第 4.9 节和第 4.10 节所定义。¶

除 第 22.1.1 节中列出的字段外，此注册表中的永久注册 MUST 包含以下字段：¶

Parameter Name:

参数的简短助记名。¶

此注册表的初始内容见 表 6。¶

整数值 N 的所有形式为 31 * N + 27 的值 （即 27、58、89，...）均被保留；这些值 MUST NOT 由 IANA 分配，并且 MUST NOT 出现在已分配值列表中。¶

22.4. QUIC Frame Types 注册表

IANA 已在 "QUIC" 标题下添加了 "QUIC Frame Types" 注册表。¶

"QUIC Frame Types" 注册表管理一个 62 位空间。 该注册表遵循 第 22.1 节中的注册策略。 该注册表中的永久注册使用 Specification Required 策略分配 （[RFC8126] 的 第 4.6 节）， 但 0x00 到 0x3f（十六进制）之间的值（含两端）除外， 这些值使用 Standards Action 或 IESG Approval 分配，如 [RFC8126] 的第 4.9 节和 4.10 节所定义。¶

除 第 22.1.1 节中列出的字段外，此注册表中的永久注册 MUST 包含以下字段：¶

Frame Type Name:

帧类型的简短助记名。¶

除 第 22.1 节中的建议外，新永久注册的规范 SHOULD 描述端点可能用来确定其能够发送 所标识帧类型的方式。预计大多数注册都伴随一个传输参数注册；见 第 22.3 节。 永久注册的规范还需要描述帧中任何字段的格式和所分配语义。¶

此注册表的初始内容列于 表 3。注意，该注册表不包括 表 3中的 "Pkts" 和 "Spec" 列。¶

22.5. QUIC Transport Error Codes 注册表

IANA 已在 "QUIC" 标题下添加了 "QUIC Transport Error Codes" 注册表。¶

"QUIC Transport Error Codes" 注册表管理一个 62 位空间。 该空间被拆分为三个范围，并由不同策略管理。该注册表中的永久注册 使用 Specification Required 策略分配 （[RFC8126] 的 第 4.6 节）， 但 0x00 到 0x3f（十六进制）之间的值（含两端）除外， 这些值使用 Standards Action 或 IESG Approval 分配，如 [RFC8126] 的第 4.9 节和第 4.10 节所定义。¶

除 第 22.1.1 节中列出的字段外，此注册表中的永久注册 MUST 包含以下字段：¶

Code:

参数的简短助记名。¶

Description:

错误码语义的简要描述；如果提供了规范引用， 则该描述 MAY 是摘要。¶

此注册表的初始内容见 表 7。¶

A.1. 可变长度 整数解码示例

图 45中的伪代码展示了如何 从字节流中读取可变长度整数。ReadVarint 函数接受一个参数—— 字节序列，它可以按网络字节序读取。¶

ReadVarint(data):
  // 可变长度整数的长度编码在第一个字节的
  // 前两个比特中。
  v = data.next_byte()
  prefix = v >> 6
  length = 1 << prefix

  // 一旦知道长度，就移除这些比特并读取任何
  // 剩余字节。
  v = v & 0x3f
  repeat length-1 times:
    v = (v << 8) + data.next_byte()
  return v

例如，八字节序列 0xc2197c5eff14e88c 解码为十进制 值 151,288,809,941,952,652；四字节序列 0x9d7f3e7d 解码为 494,878,333；两字节序列 0x7bbd 解码为 15,293；单字节 0x25 解码为 37（两字节序列 0x4025 也是如此）。¶

A.2. 分组编号 编码算法示例

图 46中的伪代码展示了 实现如何为分组编号编码选择适当大小。¶

EncodePacketNumber 函数接受两个参数：¶

• full_pn 是正在发送分组的完整分组编号。¶
• largest_acked 是对等方在当前分组编号空间中 已确认的最大分组编号（如果有）。¶

EncodePacketNumber(full_pn, largest_acked):

  // 比特数必须至少比连续未确认分组编号数量的
  // 以 2 为底的对数多一，包括新分组。
  if largest_acked is None:
    num_unacked = full_pn + 1
  else:
    num_unacked = full_pn - largest_acked

  min_bits = log(num_unacked, 2) + 1
  num_bytes = ceil(min_bits / 8)

  // 编码整数值，并截断为 num_bytes 个
  // 最低有效字节。
  return encode(full_pn, num_bytes)

例如，如果端点已经收到对分组 0xabe8b3 的确认， 并且正在发送编号为 0xac5c02 的分组，则有 29,519（0x734f）个 未完成的分组编号。为了表示至少两倍于该范围的值 （59,038 个分组，即 0xe69e），需要 16 位。¶

在相同状态下，发送编号为 0xace8fe 的分组会使用 24 位 编码，因为需要至少 18 位来表示该范围的两倍 （131,222 个分组，即 0x020096）。¶

A.3. 分组编号 解码算法示例

图 47中的伪代码包含一个 在移除报头保护后解码分组编号的示例算法。¶

DecodePacketNumber 函数接受三个参数：¶

• largest_pn 是当前分组编号空间中已成功 处理的最大分组编号。¶
• truncated_pn 是 Packet Number 字段的值。¶
• pn_nbits 是 Packet Number 字段中的比特数 （8、16、24 或 32）。¶

DecodePacketNumber(largest_pn, truncated_pn, pn_nbits):
   expected_pn  = largest_pn + 1
   pn_win       = 1 << pn_nbits
   pn_hwin      = pn_win / 2
   pn_mask      = pn_win - 1
   // 传入分组编号应大于 expected_pn - pn_hwin，
   // 且小于或等于 expected_pn + pn_hwin
   //
   // 这意味着不能只是从 expected_pn 中剥离尾部比特
   // 并加上 truncated_pn，因为这样可能会得到
   // 窗口之外的值。
   //
   // 以下代码计算一个候选值，并确保它位于
   // 分组编号窗口内。
   // 注意额外检查以防止溢出和下溢。
   candidate_pn = (expected_pn & ~pn_mask) | truncated_pn
   if candidate_pn <= expected_pn - pn_hwin and
      candidate_pn < (1 << 62) - pn_win:
      return candidate_pn + pn_win
   if candidate_pn > expected_pn + pn_hwin and
      candidate_pn >= pn_win:
      return candidate_pn - pn_win
   return candidate_pn

例如，如果最高的成功认证分组的分组编号为 0xa82f30ea，则包含 16 位值 0x9b32 的分组将被解码为 0xa82f9b32。¶

A.4. ECN 验证 算法示例

每当端点开始在新的网络路径上发送时，它会确定该路径 是否支持 ECN；见 第 13.4 节。如果路径 支持 ECN，目标就是使用 ECN。端点也可以定期重新评估先前被判定为 不支持 ECN 的路径。¶

本节描述一种测试新路径的方法。此算法旨在展示 如何测试路径是否支持 ECN。端点可以实现不同方法。¶

路径被分配一个 ECN 状态，其值为 "testing"、"unknown"、 "failed" 或 "capable" 之一。在状态为 "testing" 或 "capable" 的路径上， 端点发送带 ECT 标记的分组——默认是 ECT(0)；否则，端点发送 未标记的分组。¶

要开始测试路径，ECN 状态被设置为 "testing"， 并将现有 ECN 计数记为基线。¶

测试周期运行若干分组或一段有限时间，由端点决定。 目标不是限制测试周期的持续时间，而是确保发送足够多的标记分组， 以便收到的 ECN 计数能够清楚表明路径如何处理标记分组。 第 13.4.2 节建议将其限制为十个分组 或三倍 PTO。¶

测试周期结束后，路径的 ECN 状态变为 "unknown"。 从 "unknown" 状态开始，对 ACK 帧中 ECN 计数的成功验证 （见 第 13.4.2.1 节）会使路径的 ECN 状态变为 "capable"，除非没有已标记分组被确认。¶

如果 ECN 计数验证在任何时候失败，受影响路径的 ECN 状态 变为 "failed"。如果带标记分组全部被声明为丢失，或者它们全部被标记为 ECN-CE，则端点也可以将路径的 ECN 状态标记为 "failed"。¶

遵循此算法可确保对于正确支持 ECN 的路径，ECN 很少被禁用。 任何错误修改标记的路径都会导致 ECN 被禁用。对于那些罕见的、标记分组被路径丢弃的情况， 测试周期的短持续时间限制了产生的丢包数量。¶