HTTP/3

HTTP/1.1 ([HTTP/1.1]) 使用以空白分隔的文本字段来传递 HTTP 消息。尽管这些交换是可读的，但使用空白进行消息格式化会导致解析复杂性并对变体行为过度容忍。

由于 HTTP/1.1 不包含复用层，通常使用多个 TCP 连接并行处理请求。然而，这对拥塞控制和网络效率有负面影响，因为 TCP 不会在多个连接之间共享拥塞控制。

HTTP/2 ([HTTP/2]) 引入了二进制分帧和复用层，以在不修改传输层的情况下改善延迟。然而，由于 HTTP/2 的复用并行性对于 TCP 的丢包恢复机制不可见，丢失或重排序的数据包会导致所有活动事务出现停顿，而不管该事务是否直接受到该丢失数据包的影响。

QUIC 传输协议整合了流复用和每流流量控制，类似于 HTTP/2 分帧层提供的功能。通过在流级别提供可靠性并在整个连接上提供拥塞控制，QUIC 有能力相比于基于 TCP 的映射提升 HTTP 的性能。QUIC 还在传输层整合了 TLS 1.3 ([TLS])，提供了与在 TCP 上运行 TLS 相当的机密性和完整性，同时具有比 TCP Fast Open ([TFO]) 更低的连接建立延迟。

本文档定义了 HTTP/3：即在 QUIC 传输协议上映射 HTTP 语义，设计上大量借鉴了 HTTP/2。HTTP/3 依赖 QUIC 来提供数据的机密性和完整性保护；对等方认证；以及可靠的、按序的、按流交付。在将流生命周期和流量控制问题委托给 QUIC 的同时，在每个流上使用类似于 HTTP/2 的二进制分帧。某些 HTTP/2 特性被 QUIC 吸收，而其他特性则在 QUIC 之上实现。

QUIC 在 [QUIC-TRANSPORT] 中描述。有关 HTTP/2 的完整描述，请参见 [HTTP/2]。

• "连接建立与管理" (第 3 节) 介绍了如何发现 HTTP/3 端点以及如何建立 HTTP/3 连接。
• "在 HTTP/3 中表达 HTTP 语义" (第 4 节) 描述了如何使用帧来表达 HTTP 语义。
• "连接关闭" (第 5 节) 描述了 HTTP/3 连接如何优雅或突然地终止。

• "流映射与使用" (第 6 节) 描述了 QUIC 流的使用方式。
• "HTTP 分帧层" (第 7 节) 描述了大多数字段上使用的帧。
• "错误处理" (第 8 节) 描述了如何处理并表达错误条件，无论是在特定流上还是针对整个连接。

• "HTTP/3 的扩展" (第 9 节) 描述了如何在将来的文档中添加新功能。
• 有关 HTTP/2 与 HTTP/3 之间更详细的比较，请参见 附录 A。

本文档中关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按 BCP 14 中的描述进行解释（仅当且仅当这些词以全大写形式出现，如此处所示）。[RFC2119] [RFC8174]

本文档使用来自 [QUIC-TRANSPORT] 的可变长度整数编码。

abort:

连接或流的突然终止，可能由于错误条件引起。

client:

发起 HTTP/3 连接的端点。客户端发送 HTTP 请求并接收 HTTP 响应。

connection:

使用 QUIC 作为传输协议的两个端点之间的传输层连接。

connection error

:

影响整个 HTTP/3 连接的错误。

endpoint:

连接的任一端：客户端或服务器。

frame:

HTTP/3 中流上通信的最小单位，由一个头和根据帧类型结构化的可变长度字节序列组成。

在本文档和 [QUIC-TRANSPORT] 中均存在称为“帧”的协议元素。当引用来自 [QUIC-TRANSPORT] 的帧时，帧名称前会加上 "QUIC" 前缀。例如，“QUIC CONNECTION_CLOSE frames”。未加此前缀的引用指的是在 第 7.2 节 中定义的帧。

HTTP/3 connection:

协商的应用层协议为 HTTP/3 的 QUIC 连接。

peer:

一个端点。当讨论特定端点时，“peer” 指相对于主要讨论主体的远端端点。

receiver:

接收帧的端点。

sender:

发送帧的端点。

server:

接受 HTTP/3 连接的端点。服务器接收 HTTP 请求并发送 HTTP 响应。

stream:

由 QUIC 传输提供的双向或单向字节流。HTTP/3 连接内的所有流都可视为“HTTP/3 流”，但在 HTTP/3 中定义了多种流类型。

stream error

:

单个流上的应用层错误。

术语 “content” 在 RFC 9110 的第 6.4 节 中定义，参见 [HTTP]。

最后，术语“resource”、“message”、“user agent”、“origin server”、“gateway”、“intermediary”、“proxy” 和 “tunnel” 在 RFC 9110 的第 3 节 中定义，参见 [HTTP]。

本文档中的数据包图使用 RFC 9000 第 1.3 节 中定义的格式来说明字段的顺序和大小，参见 [QUIC-TRANSPORT]。

HTTP 依赖权威响应的概念：也就是在响应消息生成时（由 origin server 或在其指示下）已确定为对该请求最合适的响应，基于目标资源的状态。定位 HTTP URI 的权威服务器在 RFC 9110 的第 4.3 节 中讨论，参见 [HTTP]。

“https” 方案将权威性与客户端认为对 URI 的 authority 组件中标识的主机可被信任的证书的拥有权相关联。在 TLS 握手中接收到服务器证书后，客户端 MUST 使用 RFC 9110 第 4.3.4 节 中描述的过程验证该证书是否可接受地匹配 URI 的 origin server。如果证书无法相对于 URI 的 origin server 进行验证，客户端 MUST NOT 将该服务器视为该 origin 的权威服务器。

客户端 MAY 通过将主机标识符解析为 IP 地址、在指示的端口上与该地址建立 QUIC 连接（包括按上文所述验证服务器证书），并在该受保护连接上向服务器发送针对该 URI 的 HTTP/3 请求消息，来尝试访问带有 “https” URI 的资源。除非使用其他机制选择 HTTP/3，否则在 TLS 握手期间的应用层协议协商（ALPN；见 [RFC7301]）扩展中使用令牌 "h3"。

连接性问题（例如，UDP 被阻塞）可能导致无法建立 QUIC 连接；在这种情况下，客户端 SHOULD 尝试使用基于 TCP 的 HTTP 版本。

服务器 MAY 在任何 UDP 端口上提供 HTTP/3；备用服务通告总是包含显式端口，并且 URI 包含显式端口或与该方案相关联的默认端口。

HTTP/3 依赖于 QUIC 版本 1 作为底层传输。未来规范 MAY 定义其他 QUIC 传输版本与 HTTP/3 的配合使用。

QUIC 版本 1 使用 TLS 1.3 或更高版本作为其握手协议。HTTP/3 客户端 MUST 支持在 TLS 握手期间向服务器指示目标主机的机制。如果服务器由域名标识（见 [DNS-TERMS]），客户端 MUST 发送 Server Name Indication (SNI；[RFC6066]) TLS 扩展，除非使用了指示目标主机的替代机制。

QUIC 连接按 [QUIC-TRANSPORT] 中描述的方式建立。在连接建立期间，通过在 TLS 握手中选择 ALPN 令牌 "h3" 来指示对 HTTP/3 的支持。握手中也 MAY 提供对其他应用层协议的支持。

尽管与核心 QUIC 协议相关的连接级选项在初始加密握手中设置，特定于 HTTP/3 的设置则在 SETTINGS 帧中传递。QUIC 连接建立后，每一端点 MUST 在其相应的 HTTP 控制流 的初始帧中发送一个 SETTINGS 帧。

HTTP/3 连接在多个请求间保持持久。为了获得最佳性能，期望客户端不会在确定与服务器不再需要进一步通信之前关闭连接（例如，当用户离开某个网页时），或者直到服务器关闭连接。

一旦与服务器端点的连接存在，该连接 MAY 被重用于具有多个不同 URI authority 组件的请求。要将现有连接用于新的 origin，客户端 MUST 使用 RFC 9110 第 4.3.4 节 中描述的过程验证服务器为新 origin 提供的证书。这意味着客户端需要保留服务器证书以及验证该证书所需的任何附加信息；不这样做的客户端将无法重用连接以用于其他 origin。

如果证书在任何方面对新 origin 不可接受，则该连接 MUST NOT 被重用，并且应为新 origin 建立一个新连接（SHOULD）。如果证书无法验证的原因可能也适用于已与该连接关联的其他 origin，客户端 SHOULD 重新验证这些 origin 的服务器证书。例如，如果证书验证失败是由于证书已过期或被吊销，这可能会用于使所有其他使用该证书建立权威性的 origin 失效。

客户端 SHOULD NOT 打开多个到给定 IP 地址和 UDP 端口的 HTTP/3 连接，该 IP 地址和端口可能来自 URI、选定的备用服务 ([ALTSVC])、配置的代理，或对上述任何项的名称解析。客户端 MAY 使用不同的传输或 TLS 配置向相同的 IP 地址和 UDP 端口打开多个 HTTP/3 连接，但 SHOULD 避免使用相同配置创建多个连接。

鼓励服务器尽可能长时间保持打开的 HTTP/3 连接，但在必要时允许终止空闲连接。当任一端点选择关闭 HTTP/3 连接时，终止端点 SHOULD 首先发送一个 GOAWAY 帧（见 第 5.2 节），以便双方能够可靠地确定先前发送的帧是否已被处理并优雅地完成或终止任何必要的剩余任务。

不希望客户端为特定 origin 重用 HTTP/3 连接的服务器可以通过在响应请求时发送 421（Misdirected Request，错误定向请求）状态码来表明其对该请求不具权威性；参见 RFC 9110 的第 7.4 节。

客户端在 请求流 上发送 HTTP 请求， 该流是由客户端发起的双向 QUIC 流；参见 第 6.1 节。客户端 MUST 只在给定流上发送单个请求。服务器在与请求相同的流上发送零个或多个中间 HTTP 响应，随后发送单个最终 HTTP 响应，具体如下所述。关于中间和最终 HTTP 响应的描述，请参见 第 15 节 的 [HTTP]。

被推送的响应在服务器发起的单向 QUIC 流上发送；参见 第 6.2.2 节。服务器按标准响应的相同方式发送零个或多个中间 HTTP 响应，随后发送单个最终 HTTP 响应。有关推送的更多细节，请参见 第 4.6 节。

在给定流上，接收多个请求或在最终 HTTP 响应之后再接收额外的 HTTP 响应 MUST 被视为 格式错误。

1. 头部节，包括消息控制数据，作为单个 HEADERS 帧发送，
2. 可选的内容（若存在），作为一系列 DATA 帧发送，和
3. 可选的尾部节（若存在），作为单个 HEADERS 帧发送。

头部和尾部节在 第 6.3 节 和 第 6.5 节 的 [HTTP] 中描述；内容在 第 6.4 节 中描述。

接收无效的帧序列 MUST 被视为一种 连接错误，类型为 H3_FRAME_UNEXPECTED。 特别地，在任何 HEADERS 帧之前出现 DATA 帧，或在尾部 HEADERS 帧之后出现 HEADERS 或 DATA 帧，均被视为无效。其他帧类型，尤其是未知帧类型，可能在遵守其自身规则的前提下被允许；参见 第 9 节。

服务器 MAY 在响应消息的帧之前、之后或与之交错地发送一个或多个 PUSH_PROMISE 帧。这些 PUSH_PROMISE 帧并非响应的一部分；详见 第 4.6 节。在 推送流 上不允许出现 PUSH_PROMISE 帧；如果推送的响应包含此类帧， 则 MUST 将其视为类型为 H3_FRAME_UNEXPECTED 的 连接错误。

未知类型的帧（参见 第 9 节），包括保留帧（参见 第 7.2.8 节）MAY 在请求流或 推送流 上发送，且可以在本节描述的其他帧之前、之后或与之交错发送。

HEADERS 和 PUSH_PROMISE 帧可能引用对 QPACK 动态表的更新。尽管这些更新不直接属于消息交换的一部分，但它们必须在消息可被消费之前被接收和处理。详见 第 4.2 节。

传输编码（参见 RFC 9112 第 7 节）未在 HTTP/3 中定义；不得使用 Transfer-Encoding 头字段（MUST NOT）。

当且仅当一个或多个中间响应（1xx；参见 RFC 9110 第 15.2 节）在对同一请求的最终响应之前出现时，响应 MAY 由多个消息组成。中间响应不包含内容或尾部节。

一次 HTTP 请求/响应交换完全占用一个客户端发起的双向 QUIC 流。发送请求后，客户端 MUST 关闭该流的发送方向。除非使用 CONNECT 方法（参见 第 4.4 节），客户端 MUST NOT 在收到响应之前将流关闭与接收响应相依。服务器在发送最终响应后 MUST 关闭流的发送方向。此时，QUIC 流完全关闭。

当流被关闭时，表示最终 HTTP 消息的结束。因为有些消息很大或长度不确定，端点 SHOULD 一旦接收到足够多的消息以便进行处理就开始处理部分 HTTP 消息。如果客户端发起的流在未接收到足够以提供完整响应的 HTTP 消息时终止，服务器 SHOULD 使用错误码 H3_REQUEST_INCOMPLETE 中止其响应流。

如果响应不依赖于请求中尚未发送和接收的任何部分，服务器可以在客户端发送完整请求之前发送完整响应。当服务器不需要接收请求的其余部分时，服务器 MAY 中止读取 请求流， 发送完整响应，并干净地关闭流的发送部分。在请求客户端停止在 请求流 上发送时，请求使用 H3_NO_ERROR 错误码 SHOULD。客户端 MUST NOT 因其请求被突然终止而丢弃完整响应，尽管客户端可因其他原因自行决定丢弃响应。如果服务器发送部分或完整响应但并未中止读取请求，客户端 SHOULD 继续发送请求内容并正常关闭流。

HTTP 消息将元数据作为一系列称为“HTTP 字段”的键值对来承载；参见 第 6.3 节 和 第 6.5 节 的 [HTTP]。有关已注册 HTTP 字段的列表，请参见由 IANA 维护的“Hypertext Transfer Protocol (HTTP) Field Name Registry”（<https://www.iana.org/assignments/http-fields/>）。与 HTTP/2 类似，HTTP/3 在字段名中字符的使用、Connection 头字段以及伪首部字段的使用上有额外的考虑。

字段名是包含 ASCII 子集字符的字符串。HTTP 字段名和字段值的属性在 RFC 9110 第 5.1 节 中有更详细讨论。字段名中的字符 MUST 在编码之前转换为小写。包含大写字符的请求或响应头字段名 MUST 被视为 格式错误。

HTTP/3 不使用 Connection 头字段来指示连接特定字段；在此协议中，连接特定的元数据通过其他方式传递。端点 MUST NOT 生成包含连接特定字段的 HTTP/3 字段节；任何包含连接特定字段的消息 MUST 被视为 格式错误。

唯一的例外是 TE 头字段，它 MAY 出现在 HTTP/3 请求头中；当存在时，MUST NOT 包含除 "trailers" 之外的任何值。

将 HTTP/1.x 消息转换为 HTTP/3 的中介 MUST 删除连接特定的头字段，如 RFC 9110 第 7.6.1 节 所讨论的，否则它们的消息将被其他 HTTP/3 端点视为 格式错误。

与 HTTP/2 类似，HTTP/3 使用一系列伪首部字段，其字段名以字符 :（ASCII 0x3a）开头。这些伪首部字段传递消息控制数据；参见 RFC 9110 第 6.2 节。

伪首部字段不是 HTTP 字段。端点 MUST NOT 生成本文件未定义的伪首部字段。但是，扩展可以协商修改此限制；参见 第 9 节。

伪首部字段仅在其定义的上下文中有效。为请求定义的伪首部字段 MUST NOT 出现在响应中；为响应定义的伪首部字段 MUST NOT 出现在请求中。伪首部字段 MUST NOT 出现在尾部节中。端点 MUST 将包含未定义或无效伪首部字段的请求或响应视为 格式错误。

所有伪首部字段 MUST 在头部节中出现在常规头字段之前。任何包含在常规头字段之后出现的伪首部字段的请求或响应 MUST 被视为 格式错误。

CONNECT 方法请求接收方建立到请求目标所标识的目标原点服务器的隧道；参见 RFC 9110 第 9.3.6 节。它主要与 HTTP 代理一起使用，以便为与原点服务器建立 TLS 会话从而与 "https" 资源交互。

在 HTTP/1.x 中，CONNECT 用于将整个 HTTP 连接转换为到远程主机的隧道。在 HTTP/2 和 HTTP/3 中，CONNECT 方法用于在单个流上建立隧道。

• :method 伪首部字段设置为 "CONNECT"
• :scheme 和 :path 伪首部字段被省略
• :authority 伪首部字段包含要连接的主机和端口（等同于 CONNECT 请求目标的 authority-form；参见 RFC 9110 第 7.1 节）。

请求流 在请求结束时保持打开以承载要传输的数据。与这些限制不符的 CONNECT 请求为 格式错误。

支持 CONNECT 的代理建立到 :authority 伪首部字段所标识服务器的 TCP 连接（参见 [RFC0793]）。一旦该连接成功建立，代理向客户端发送包含 2xx 系列状态码的 HEADERS 帧，如 RFC 9110 第 15.3 节 所定义。

流上的所有 DATA 帧对应于在 TCP 连接上发送或接收的数据。由客户端发送的任何 DATA 帧的载荷由代理转发到 TCP 服务器；从 TCP 服务器接收的数据由代理打包到 DATA 帧中发送给客户端。请注意，TCP 段的大小和数量不保证可预测地映射到 HTTP DATA 或 QUIC STREAM 帧的大小和数量。

一旦 CONNECT 方法完成，只允许在该流上发送 DATA 帧。如果扩展的定义明确允许，可使用扩展帧（MAY）。接收任何其他已知帧类型 MUST 被视为类型为 H3_FRAME_UNEXPECTED 的 连接错误。

TCP 连接可由任一对等方关闭。当客户端结束 请求流（即代理的接收流进入 "Data Recvd" 状态）时，代理将对其与 TCP 服务器的连接设置 FIN 位。当代理接收到带 FIN 位的数据包时，它将关闭其发送给客户端的发送流。TCP 连接在单方向保持半关闭并非无效，但服务器通常对此处理不佳，因此客户端 SHOULD NOT 在仍期望从 CONNECT 目标接收数据时关闭发送方向的流。

TCP 连接错误 由突然终止流来表示。代理将 TCP 连接中的任何错误（包括接收到带 RST 位的 TCP 段）视为类型为 H3_CONNECT_ERROR 的 流错误。

相应地，如果代理检测到流或 QUIC 连接的错误，它 MUST 关闭 TCP 连接。如果代理检测到客户端已重置流或中止读取流，它 MUST 关闭 TCP 连接。如果流被客户端重置或读取被中止，代理 SHOULD 在另一方向上执行相同操作以确保流的两个方向都被取消。在所有这些情况下，如果底层 TCP 实现允许，代理 SHOULD 发送带 RST 位的 TCP 段。

由于 CONNECT 会创建到任意服务器的隧道，支持 CONNECT 的代理 SHOULD 将其使用限制在一组已知端口或一列安全请求目标上；更多细节请参见 RFC 9110 第 9.3.6 节。

HTTP/3 不支持 HTTP Upgrade 机制（参见 RFC 9110 第 7.8 节）或 101（Switching Protocols）信息性状态码（参见 RFC 9110 第 15.2.2 节）。

服务器推送是一种交互模式，允许服务器在预期客户端将发出指定请求时将一个请求-响应交换推送给客户端。这在网络使用与潜在延迟收益之间进行权衡。HTTP/3 的服务器推送与 RFC 9113 第 8.2 节 中描述的类似，但使用了不同的机制。

每个服务器推送由服务器分配一个唯一的 push ID。push ID 在整个 HTTP/3 连接的生命周期内在各种上下文中用于引用该推送。

push ID 空间从零开始，到由 MAX_PUSH_ID 帧设置的最大值结束。特别地，服务器在客户端发送 MAX_PUSH_ID 帧之前无法进行推送。客户端通过发送 MAX_PUSH_ID 帧来控制服务器可以承诺的推送数量。服务器 SHOULD 顺序使用 push ID，从零开始。客户端 MUST 在未发送任何 MAX_PUSH_ID 帧或当流引用的 push ID 大于最大 push ID 时，将接收到的 推送流 视为类型为 H3_ID_ERROR 的 连接错误。

push ID 用于一个或多个承载请求消息控制数据和头字段的 PUSH_PROMISE 帧。这些帧在产生推送的 请求流 上发送。这样可以将服务器推送与客户端请求关联。当同一 push ID 在多个 请求流 上被承诺时，解压后的请求字段节 MUST 包含相同的字段且顺序相同，且每个字段的名称和值均 MUST 完全相同。

随后，push ID 会包含在最终实现这些承诺的 push stream 中。该 push stream 标识它所实现的承诺的 push ID，然后按照 第 4.1 节 所述包含对承诺请求的响应。

最后，push ID 可以用于 CANCEL_PUSH 帧；参见 第 7.2.3 节。客户端使用该帧表示它不希望接收承诺的资源。服务器使用该帧表示它不会实现先前的承诺。

• 可缓存；参见 RFC 9110 第 9.2.3 节
• 安全（safe）；参见 RFC 9110 第 9.2.1 节
• 不包含请求内容或尾部节

服务器 MUST 在 :authority 伪首部字段中包含一个其具有权威性的值。如果客户端尚未为被推送请求所指示的原点验证该连接，它 MUST 在在连接上为该原点发送请求之前执行相同的验证过程；参见 第 3.3 节。如果该验证失败，客户端 MUST NOT 将服务器视为该原点的权威服务器。

客户端 SHOULD 在收到承载不可缓存、未知为安全、指示存在请求内容的请求，或客户端不认为服务器对该请求具有权威性的 PUSH_PROMISE 帧时发送 CANCEL_PUSH 帧。任何相应的响应 MUST NOT 被使用或缓存。

每个被推送的响应与一个或多个客户端请求相关联。该推送与在其上收到 PUSH_PROMISE 帧的 请求流 相关联。同一服务器推送可以通过在多个 请求流 上使用相同 push ID 的 PUSH_PROMISE 帧与额外的客户端请求相关联。这些关联不影响协议的运行，但用户代理在决定如何使用被推送资源时 MAY 考虑这些关联。

PUSH_PROMISE 帧相对于响应某些部分的排序很重要。服务器 SHOULD 在发送引用承诺响应的 HEADERS 或 DATA 帧之前发送 PUSH_PROMISE 帧。这样可以降低客户端请求将被服务器推送资源所覆盖的可能性。

由于重排序，推送流 的数据可能在对应的 PUSH_PROMISE 帧之前到达。当客户端收到带尚未知 push ID 的新 推送流 时，关联的客户端请求和被推送的请求头字段均是未知的。客户端可以缓冲该流的数据以等待匹配的 PUSH_PROMISE 帧。客户端可以使用流流量控制（参见 RFC 9000 第 4.1 节）来限制服务器可对被推送流提交的数据量。如果在合理时间内未处理任何对应的 PUSH_PROMISE 帧，客户端 SHOULD 中止读取并丢弃已从 推送流 读取的数据。

推送流数据也可能在客户端已取消推送之后到达。在这种情况下，客户端可以使用错误码 H3_REQUEST_CANCELLED 中止读取该流。此操作请求服务器不要传输额外数据，并表明接收到的数据将被丢弃。

可缓存的被推送响应（参见 RFC 9111 第 3 节）可以由实现了 HTTP 缓存的客户端存储。被推送的响应在接收时被视为已在原点服务器上成功验证（例如，如果存在 "no-cache" 缓存响应指令；参见 RFC 9111 第 5.2.2.4 节）。

不可缓存的被推送响应 MUST NOT 被任何 HTTP 缓存存储。它们 MAY 单独向应用程序提供。

每个 QUIC 端点在握手期间声明一个空闲超时。如果 QUIC 连接在该时长内保持空闲（未接收数据包），对等方将假定连接已被关闭。如果现有连接的空闲时间超过在 QUIC 握手期间协商的空闲超时，HTTP/3 实现在发起新请求时需要为新的请求打开一个新的 HTTP/3 连接，并且在接近空闲超时时 SHOULD 这样做；参见 RFC 9000 第 10.1 节。

当有请求的响应或服务器推送尚未完成时（如 RFC 9000 第 10.1.2 节 所述），HTTP 客户端应请求传输层保持连接打开。如果客户端不期望来自服务器的响应，则允许空闲连接超时优于维持可能不需要的连接以节省资源。网关 MAY 为了预期需要而维持连接，以避免建立连接的延迟成本。服务器 SHOULD NOT 主动保持连接打开。

即使连接未空闲，任一端点也可以决定停止使用该连接并发起优雅的连接关闭。端点通过发送一个 GOAWAY 帧来启动 HTTP/3 连接的优雅关闭。GOAWAY 帧包含一个标识符，用以指示接收方该连接上已处理或可能已处理的请求或推送的范围。服务器发送客户端发起的双向流 ID；客户端发送一个 push ID。具有该标识符或更大的请求或推送将被发送方拒绝（参见 第 4.1.1 节）。如果未处理任何请求或推送，此标识符 MAY 为零。

GOAWAY 帧中的信息使客户端和服务器能够就哪些请求或推送在 HTTP/3 连接关闭前被接受达成一致。在发送 GOAWAY 帧后，端点 SHOULD 明确取消（见第 4.1.1 节 和 7.2.3 节）任何标识符大于等于所示值的请求或推送，以便为受影响的流清理传输状态。随着更多请求或推送到达，端点 SHOULD 继续这样做。

在收到对端发送的 GOAWAY 帧后，端点 MUST NOT 在该连接上发起新的请求或承诺新的推送。客户端 MAY 建立新的连接以发送额外的请求。

• 在收到 GOAWAY 帧后，如果客户端已经发送了流 ID 大于或等于 GOAWAY 帧中包含的标识符的请求，则这些请求将不会被处理。客户端可以安全地在另一个 HTTP 连接上重试未被处理的请求。无法重试请求的客户端在服务器关闭连接时会丢失所有在途请求。

  服务器在 GOAWAY 帧中指定的流 ID 之前的流上的请求可能已被处理；在收到响应、单独重置该流、收到另一个对该请求具有更低流 ID 的 GOAWAY，或连接终止之前，其状态无法确定。

  如果这些流上的请求未被处理，服务器 MAY 拒绝这些低于指示 ID 的单个请求。

• 如果服务器在已经承诺了 push ID 大于或等于 GOAWAY 帧中包含的标识符的推送之后收到该 GOAWAY 帧，那么这些推送将不被接受。

当已知连接将被关闭时，即便提前通知时间很短，服务器 SHOULD 发送 GOAWAY 帧，以便远端对等方能知道某个请求是否已被部分处理。例如，如果 HTTP 客户端在服务器关闭 QUIC 连接的同时发送了 POST 请求，如果服务器未发送 GOAWAY 帧来指示它可能已作用的流，客户端无法知道服务器是否开始处理该 POST 请求。

端点 MAY 发送多个表示不同标识符的 GOAWAY 帧，但每个帧中的标识符 MUST NOT 大于任何先前帧中的标识符，因为客户端可能已经在另一个 HTTP 连接上重试了未处理的请求。接收包含大于此前接收的标识符的 GOAWAY 应被视为类型为 H3_ID_ERROR 的 连接错误。

试图优雅关闭连接的端点可以发送一个值设置为最大可能值的 GOAWAY 帧（服务器为 2⁶²-4，客户端为 2⁶²-1）。这可确保对等方停止创建新的请求或推送。在允许足够时间以便在途请求或推送到达后，端点可以发送另一个 GOAWAY 帧以指明在连接结束前它可能接受哪些请求或推送。这样可以在不丢失请求的情况下干净地关闭连接。

客户端在其发送的 GOAWAY 中为 Push ID 字段选择值时具有更大的灵活性。值 2⁶²-1 表示服务器可以继续完成已经承诺的推送。较小的值表示客户端将拒绝具有大于或等于该值的推送。像服务器一样，客户端 MAY 发送后续的 GOAWAY 帧，只要所指示的 push ID 不大于先前发送的任何值。

即使 GOAWAY 指示给定请求或推送在接收时不会被处理或接受，底层传输资源仍然存在。发起这些请求的端点可以取消它们以清理传输状态。

一旦所有被接受的请求和推送都被处理完毕，端点可以允许连接变为空闲，或者它 MAY 发起立即关闭连接的操作。完成优雅关闭的端点 SHOULD 在关闭连接时使用 H3_NO_ERROR 错误码。

如果客户端已使用完可用的双向流 ID 来发起请求，则服务器无需发送 GOAWAY 帧，因为客户端无法发起更多请求。

HTTP/3 实现可以在任何时候立即关闭 QUIC 连接。这将向对等方发送一个 QUIC CONNECTION_CLOSE 帧，表明应用层已经终止连接。该帧中的应用错误码向对等方指示为何连接被关闭。有关在 HTTP/3 中关闭连接时可使用的错误码，请参见 第 8 节。

在关闭连接之前，GOAWAY 帧 MAY 被发送，以允许客户端重试某些请求。将 GOAWAY 帧包含在与 QUIC CONNECTION_CLOSE 帧相同的数据包中，会提高客户端接收到该帧的几率。

如果存在未显式关闭的打开流，则在连接关闭时这些流将被隐式关闭；参见 RFC 9000 第 10.2 节。

由于各种原因，QUIC 传输层可能会向应用层指示连接已终止。这可能是由于对等方的明确关闭、传输级别错误，或中断连通性的网络拓扑变化导致的。

如果连接在没有发送 GOAWAY 帧的情况下终止，客户端 MUST 假定任何已发送的请求（无论全部还是部分）都可能已经被处理。

所有客户端发起的双向流都用于 HTTP 请求和响应。双向流确保响应可以方便地与请求相关联。这些流称为请求流。

这意味着客户端的第一个请求发生在 QUIC 流 0 上，后续请求发生在流 4、8 等上。为了允许这些流被打开，HTTP/3 服务器 SHOULD 为允许的流数和初始流量控制窗口配置非零的最小值。为了不不必要地限制并行性，至少应允许同时存在 100 个请求流（SHOULD）。

HTTP/3 不使用服务器发起的双向流，尽管扩展可以为这些流定义用途。除非已协商此类扩展，客户端 MUST 将接收服务器发起的双向流视为类型为 H3_STREAM_CREATION_ERROR 的 连接错误。

单向流（任一方向）用于多种用途。用途由流类型指示，该类型作为可变长度整数在流开始处发送。随后数据的格式和结构由该流类型决定。

本文档中定义了两种流类型：control streams（见第 6.2.1 节）和 push streams（见第 6.2.2 节）。[QPACK] 定义了另外两种流类型。其他流类型可以通过 HTTP/3 扩展定义；有关详细信息，参见 第 9 节。某些流类型被保留（参见 第 6.2.3 节）。

HTTP/3 连接在生命周期早期阶段的性能对单向流的创建和数据交换非常敏感。过度限制流的数量或这些流的流量控制窗口的端点会增加远端对等方过早达到限制并被阻塞的概率。具体而言，实现应考虑到远端对等方可能希望对其允许使用的一些单向流行使保留流行为（参见 第 6.2.3 节）。

每个端点需要至少为 HTTP control stream 创建一个单向流。QPACK 需要另外两个单向流，其他扩展可能需要更多流。因此，客户端和服务器发送的传输参数 MUST 允许对等方创建至少三个单向流。这些传输参数 SHOULD 还为每个单向流提供至少 1,024 字节的流量控制额度。

请注意，如果其对等方在创建关键单向流之前消耗了所有初始额度，端点并不需要授予额外额度以创建更多单向流。端点 SHOULD 先创建 HTTP control stream 以及必需扩展（例如 QPACK 编码器和解码器流）所需的单向流，然后在对等方允许时创建其他流。

如果流头指示的流类型不被接收方支持，则该流的其余部分无法被消费，因为语义未知。接收到未知流类型的接收方 MUST 要么中止读取该流，要么丢弃到达的数据而不作进一步处理。如果中止读取，接收方 SHOULD 使用 H3_STREAM_CREATION_ERROR 错误码或保留错误码（见 第 8.1 节）。接收方 MUST NOT 将未知流类型视为任何形式的 连接错误。

由于某些流类型可能影响连接状态，接收方 SHOULD NOT 在读取流类型之前丢弃来自传入单向流的数据。

实现 MAY 在尚不确定对等方是否支持它们的情况下发送流类型。然而，可能修改现有协议组件状态或语义的流类型，包括 QPACK 或其他扩展，MUST NOT 在确认对等方支持之前发送。

除非另有规定，发送方可以关闭或重置单向流。接收方 MUST 容忍在接收到单向流头之前该流被关闭或重置。

Type:

标识帧类型的可变长度整数。

Length:

描述帧负载字节长度的可变长度整数。

Frame Payload:

由 Type 字段决定语义的负载。

每个帧的负载 MUST 精确包含其描述中标识的字段。包含额外字节的帧负载或在标识字段结束之前终止的帧负载 MUST 被视为类型为 H3_FRAME_ERROR 的 连接错误。特别地，冗余的长度编码 MUST 被验证为自洽；参见 第 10.8 节。

当流被干净地终止时，如果该流上的最后一个帧被截断，则此情形 MUST 被视为类型为 H3_FRAME_ERROR 的 连接错误。在任意点突然终止的流可能在帧的任何位置被重置。

下列错误代码被定义用于在突然终止流、终止读取流或立即关闭 HTTP/3 连接时使用。

H3_NO_ERROR (0x0100)

:

无错误。当需要关闭连接或流但无需报告错误时使用。

H3_GENERAL_PROTOCOL_ERROR (0x0101)

:

对等方以不符合更具体错误代码的方式违反了协议要求，或端点拒绝使用更具体的错误代码。

H3_INTERNAL_ERROR (0x0102)

:

HTTP 堆栈中发生了内部错误。

H3_STREAM_CREATION_ERROR (0x0103)

:

端点检测到其对端创建了一个其不会接受的流。

H3_CLOSED_CRITICAL_STREAM (0x0104)

:

HTTP/3 连接所需的某个流被关闭或重置。

H3_FRAME_UNEXPECTED (0x0105)

:

在当前状态或当前流上接收到了不被允许的帧。

H3_FRAME_ERROR (0x0106)

:

接收到不满足布局要求或大小无效的帧。

H3_EXCESSIVE_LOAD (0x0107)

:

端点检测到其对端表现出可能引起过度负载的行为。

H3_ID_ERROR (0x0108)

:

流 ID 或 push ID 被错误使用，例如超出限制、减少限制或被重用。

H3_SETTINGS_ERROR (0x0109)

:

端点检测到 SETTINGS 帧的负载有错误。

H3_MISSING_SETTINGS (0x010a)

:

在 control stream 的开始处未收到 SETTINGS 帧。

H3_REQUEST_REJECTED (0x010b)

:

服务器在未执行任何应用处理的情况下拒绝了请求。

H3_REQUEST_CANCELLED (0x010c)

:

请求或其响应（包括被推送的响应）被取消。

H3_REQUEST_INCOMPLETE (0x010d)

:

客户端的流在未包含完整请求的情况下终止。

H3_MESSAGE_ERROR (0x010e)

:

HTTP 消息为 格式错误，无法被处理。

H3_CONNECT_ERROR (0x010f)

:

对 CONNECT 请求建立的 TCP 连接被重置或异常关闭。

H3_VERSION_FALLBACK (0x0110)

:

请求的操作不能通过 HTTP/3 提供服务。对端应重试使用 HTTP/1.1。

格式为 0x1f * N + 0x21（N 为非负整数）的错误代码空间被保留，用以检验对未知错误代码应被视为等同于 H3_NO_ERROR 的要求（参见 第 9 节）。实现 SHOULD 在本应发送 H3_NO_ERROR 的情况下，以一定概率从该空间中选择一个错误代码。

HTTP/3 依赖于 HTTP 对权限的定义。建立权限的安全性考虑在 RFC 9110 第 17.1 节 中讨论，参见 [HTTP]。

在 TLS 和 QUIC 握手中使用 ALPN 在处理应用层字节之前确定目标应用协议。这确保了端点有强有力的保证，表明对端正在使用相同的协议。

这并不能保证免受所有跨协议攻击。RFC 9000 第 21.5 节 描述了明文 QUIC 数据包如何被用来对不使用认证传输的端点进行请求伪造的若干方式。

HTTP/3 的字段编码允许表达在 HTTP 语法中并非有效字段名的名称（参见 RFC 9110 第 5.1 节）。包含无效字段名的请求或响应 MUST 被视为 格式错误。因此，中介不能将包含无效字段名的 HTTP/3 请求或响应转换为 HTTP/1.1 消息。

同样，HTTP/3 可以传输并非总是有效的字段值。尽管大多数可编码的值不会改变字段解析，但回车（ASCII 0x0d）、换行（ASCII 0x0a）和空字符（ASCII 0x00）在被逐字翻译时可能会被攻击者利用。如果请求或响应包含字段值中不允许的字符，该请求或响应 MUST 被视为 格式错误。有效字符由 RFC 9110 第 5.5 节 中的 "field-content" ABNF 规则定义。

被推送的响应没有来自客户端的显式请求；请求由服务器在 PUSH_PROMISE 帧中提供。

是否缓存被推送的响应可以依据原点服务器在 Cache-Control 头字段中提供的指导来决定。然而，如果单个服务器托管多个租户，这可能引发问题。例如，服务器可能为多个用户各自提供其 URI 空间的一小部分。

当多个租户共享同一服务器空间时，该服务器 MUST 确保租户不能推送其无权代表的资源的表示。未能强制执行此类限制将允许某一租户提供一个表示并使其被缓存，从而覆盖权威租户提供的实际表示。

客户端必须拒绝对其原点服务器不具权威性的被推送响应；参见 第 4.6 节。

HTTP/3 连接所需的资源承诺可能比 HTTP/1.1 或 HTTP/2 更大。字段压缩和流量控制的使用依赖于为存储更多状态而作出的资源承诺。针对这些特性的设置确保了对这些特性所需内存的严格界定。

PUSH_PROMISE 帧的数量也以类似方式受限。接受服务器推送的客户端 SHOULD 限制其一次发出的 push ID 数量。

处理能力不能像状态容量那样有效地受到保护。

发送对等方被要求忽略的未定义协议元素的能力可能被滥用以使对等方消耗额外处理时间。这可能通过设置多个未定义的 SETTINGS 参数、未知帧类型或未知流类型来实现。但需注意，有些用途是完全合法的，例如可选理解的扩展和用于增加对流量分析抗性的填充。

字段节的压缩也提供了浪费处理资源的机会；有关潜在滥用的更多细节，请参见 RFC 9204 第 7 节（QPACK）。

所有这些特性——即服务器推送、未知协议元素、字段压缩——都有合法用途。只有在不必要或过度使用时，这些特性才成为负担。

不监控此类行为的端点会暴露于拒绝服务攻击的风险之中。实现 SHOULD 跟踪这些特性的使用并对其使用设置限制。端点 MAY 将可疑活动视为类型为 H3_EXCESSIVE_LOAD 的 连接错误，但误报会导致中断合法连接和请求。

当秘密数据与攻击者可控的数据在相同上下文中被压缩时，压缩可能使攻击者恢复秘密数据。HTTP/3 支持字段压缩（参见 第 4.2 节）；下列关注点也适用于 HTTP 压缩内容编码的使用；参见 RFC 9110 第 8.4.1 节。

针对压缩的可验证攻击利用了 Web 的特性（例如 [BREACH]）。攻击者诱导包含不同明文的多次请求，通过观察每次产生的密文长度，当对秘密的猜测正确时会显现出更短的长度。

在安全通道上通信的实现 MUST NOT 压缩同时包含机密数据和攻击者可控数据的内容，除非对每个数据来源使用独立的压缩上下文。如果无法可靠确定数据来源，则 MUST NOT 使用压缩。

关于字段节压缩的更多考虑见 [QPACK]。

填充可用于模糊帧内容的精确大小，并用于缓解 HTTP 内的特定攻击，例如当压缩内容同时包含攻击者控制的明文和秘密数据时的攻击（例如 [BREACH]）。

当 HTTP/2 使用 PADDING 帧和其它帧中的 Padding 字段来增强对流量分析的抗性时，HTTP/3 可以依赖传输层填充或采用第 7.2.8 节 和 6.2.3 节 中讨论的保留帧和流类型。这些填充方法在填充的粒度、填充与被保护信息的排列、在丢包情况下是否应用填充以及实现如何控制填充等方面产生不同的结果。

保留流类型可用于在连接空闲时制造看似存在的流量。由于 HTTP 流量通常呈突发性出现，表面流量可用于模糊这种突发的时序或持续时间，甚至看起来像持续发送数据的恒定流。然而，由于此类流仍受接收方的流量控制，未能及时清除这些流并提供额外的流量控制额度会限制发送方发送真实流量的能力。

为缓解依赖压缩的攻击，禁用或限制压缩可能比填充更合适作为对策。

使用填充可能并不比表面上看起来的更能提供保护。冗余填充甚至可能适得其反。充其量，填充只是通过增加攻击者必须观察的帧数量来使攻击者更难推断长度信息。错误实现的填充方案容易被攻破。特别是，可预测分布的随机填充提供的保护很少；同样，将有效载荷填充到固定尺寸会在有效载荷跨越固定边界时泄露信息，如果攻击者能控制明文，则可能利用这一点。

若干协议元素包含嵌套长度元素，通常表现为包含可变长度整数的显式长度的帧。这可能对粗心的实现者构成安全风险。实现 MUST 确保帧的长度与其所包含字段的长度精确匹配。

在 HTTP/3 中使用 0-RTT 会带来重放攻击的风险。在使用 HTTP/3 的 0-RTT 时，必须采用 [HTTP-REPLAY] 中的防重放缓解措施。将 [HTTP-REPLAY] 应用于 HTTP/3 时，对 TLS 层的引用指代在 QUIC 中执行的握手，而对应用数据的所有引用指代流的内容。

某些 HTTP 实现使用客户端地址进行日志记录或访问控制。由于 QUIC 客户端的地址可能在连接期间发生变化（未来版本可能支持同时使用多个地址），此类实现需要在相关时刻主动检索客户端的当前地址或地址列表，或明确接受原始地址可能会改变的事实。

HTTP/3 的若干特性为观察者提供了随时间关联单一客户端或服务器动作的机会。这些包括设置的值、对刺激的响应时序以及对任何由设置控制的特性的处理方式。

只要这些在行为上产生可观察的差异，它们就可能被用来对特定客户端进行指纹识别。

HTTP/3 倾向于对单一 QUIC 连接的重用允许对用户在站点上的活动进行关联。为不同原点重用连接允许跨这些原点关联活动。

QUIC 的若干特性会立即触发响应，端点可用于测量与其对端的延迟；在某些场景下，这可能具有隐私影响。

本文档在由 [RFC7301] 建立的“TLS 应用层协议协商 (ALPN) 协议 ID”注册表中创建了一个用于标识 HTTP/3 的新注册。

Protocol:

HTTP/3

Identification Sequence:

0x68 0x33 ("h3")

Specification:

本文件

本文档中创建的新注册表根据 RFC 9000 第 22.1 节 中记录的 QUIC 注册策略运行。这些注册表均包含 RFC 9000 第 22.1.1 节 所列的通用字段集合。这些注册表汇总在“Hypertext Transfer Protocol version 3 (HTTP/3)”标题下。

这些注册表中的初始分配均被赋予永久状态，并列出 IETF 作为变更控制者以及 HTTP 工作组（ietf-http-wg@w3.org）作为联系人。

HTTP/3 允许使用比 HTTP/2 更大的流数量（2⁶²-1）。与流标识符空间耗尽相关的相同考虑仍然适用，但空间要大得多，因此更可能先遇到 QUIC 的其他限制，例如连接流量控制窗口的限制。

与 HTTP/2 相比，HTTP/3 中的流并发由 QUIC 管理。QUIC 在接收了所有数据并且发送的数据被对端确认后将流视为已关闭。HTTP/2 在包含 END_STREAM 位的帧被提交到传输时将流视为已关闭。因此，对于等价的交换，HTTP/3 中的流可能保持“活动”状态更长时间。HTTP/3 服务器可能会选择允许更多的客户端发起的并发双向流以达到与 HTTP/2 相当的并发性，具体取决于预期的使用模式。

在 HTTP/2 中，只有请求和响应主体（DATA 帧的负载）受流量控制。所有 HTTP/3 帧都在 QUIC 流上发送，因此在 HTTP/3 中所有流上的所有帧都受流量控制。

由于存在其它单向流类型，HTTP/3 不再仅依赖并发单向流的数量来控制并发正在进行的推送数。相反，HTTP/3 客户端使用 MAX_PUSH_ID 帧来控制从服务器接收的推送数量。

许多来自 HTTP/2 的分帧概念在 QUIC 上可以省略，因为传输层已经处理了这些问题。因为帧已经位于某个流上，它们可以省略流编号。因为帧不会阻塞复用（QUIC 的复用在本层之下），可以移除对可变最大长度包的支持。因为流终止由 QUIC 处理，所以不需要 END_STREAM 标志。这允许从通用帧布局中移除 Flags 字段。

帧负载大多借鉴自 [HTTP/2]。然而，QUIC 包含许多特性（例如流量控制）也出现在 HTTP/2 中。在这些情况下，HTTP 映射不会重新实现它们。因此，若干 HTTP/2 帧类型在 HTTP/3 中不再需要。对于不再使用的 HTTP/2 定义的帧，其帧 ID 已被保留以最大化 HTTP/2 与 HTTP/3 实现之间的可移植性。但即使在两者映射都存在的帧类型，其语义也不完全相同。

许多差异源于这样一个事实：HTTP/2 在所有流之间提供绝对的帧顺序，而 QUIC 仅在每个流内提供此保证。因此，如果某个帧类型假定来自不同流的帧仍将以发送顺序接收，HTTP/3 将会破坏该假定。

下面描述了一些特性适配的示例，以及将 HTTP/2 扩展转换为 HTTP/3 时对扩展帧实现者的一般指导。

与 HTTP/2 的一个重要区别是设置在作为 control stream 的第一个帧中发送一次，之后不能更改。这消除了许多关于变更同步的边缘情况。

HTTP/2 通过 SETTINGS 帧指定的一些传输级选项在 HTTP/3 中被 QUIC 传输参数取代。保留在 HTTP/3 中的 HTTP 级设置与 HTTP/2 中的值相同。被取代的设置被保留，其接收被视为错误。有关保留和值的讨论，见 第 7.2.4.1 节。

SETTINGS_HEADER_TABLE_SIZE (0x01):

参见 [QPACK]。

SETTINGS_ENABLE_PUSH (0x02):

此项已被替换为 MAX_PUSH_ID 帧，后者提供了对服务器推送的更细粒度控制。在 HTTP/3 的 SETTINGS 帧中指定标识符为 0x02 的设置（对应于 SETTINGS_ENABLE_PUSH 参数）是错误的。

SETTINGS_MAX_CONCURRENT_STREAMS (0x03):

QUIC 在其流量控制逻辑中控制最大的打开流 ID。在 HTTP/3 的 SETTINGS 帧中指定标识符为 0x03（对应于 SETTINGS_MAX_CONCURRENT_STREAMS 参数）的设置是错误的。

SETTINGS_INITIAL_WINDOW_SIZE (0x04):

QUIC 要求在初始传输握手中指定流和连接的流量控制窗口大小。在 HTTP/3 的 SETTINGS 帧中指定标识符为 0x04（对应于 SETTINGS_INITIAL_WINDOW_SIZE 参数）的设置是错误的。

SETTINGS_MAX_FRAME_SIZE (0x05):

此设置在 HTTP/3 中没有等价项。在 HTTP/3 的 SETTINGS 帧中指定标识符为 0x05（对应于 SETTINGS_MAX_FRAME_SIZE 参数）的设置是错误的。

SETTINGS_MAX_HEADER_LIST_SIZE (0x06):

此设置标识符已重命名为 SETTINGS_MAX_FIELD_SECTION_SIZE。

在 HTTP/3 中，设置值为可变长度整数（6、14、30 或 62 位），而不是 HTTP/2 中的固定 32 位字段。这通常会产生更短的编码，但对于使用完整 32 位空间的设置可能产生更长的编码。从 HTTP/2 移植的设置可以选择重新定义其值以限制为 30 位以获得更高效的编码，或者如果需要超过 30 位可以利用 62 位空间。

需要为 HTTP/2 和 HTTP/3 分别定义设置。为简便起见，在 [HTTP/2] 中定义的设置标识符已被保留。注意 HTTP/3 的设置标识符空间明显更大（62 位对比 16 位），因此许多 HTTP/3 设置在 HTTP/2 中没有等价的码点。参见 第 11.2.2 节。

由于 QUIC 流可能无序到达，建议端点不要在等待对等方的设置到达后再对其它流做出响应。参见 第 7.2.4.2 节。

QUIC 拥有与 HTTP/2 相同的“流”和“连接”错误的概念。然而，HTTP/2 与 HTTP/3 之间的差异意味着错误代码不能直接在版本之间移植。

NO_ERROR (0x00):

H3_NO_ERROR，见 第 8.1 节。

PROTOCOL_ERROR (0x01):

映射为 H3_GENERAL_PROTOCOL_ERROR，除非已定义更具体的错误代码。例如包括 H3_FRAME_UNEXPECTED、H3_MESSAGE_ERROR 和 H3_CLOSED_CRITICAL_STREAM，这些都在 第 8.1 节 中定义。

INTERNAL_ERROR (0x02):

H3_INTERNAL_ERROR，见 第 8.1 节。

FLOW_CONTROL_ERROR (0x03):

不适用，因为 QUIC 处理流量控制。

SETTINGS_TIMEOUT (0x04):

不适用，因为没有定义对 SETTINGS 的确认。

STREAM_CLOSED (0x05):

不适用，因为 QUIC 处理流管理。

FRAME_SIZE_ERROR (0x06):

H3_FRAME_ERROR，见 第 8.1 节。

REFUSED_STREAM (0x07):

H3_REQUEST_REJECTED（见 第 8.1 节）用于指示请求未被处理。其他情况不适用，因为 QUIC 处理流管理。

CANCEL (0x08):

H3_REQUEST_CANCELLED，见 第 8.1 节。

COMPRESSION_ERROR (0x09):

多个错误代码在 [QPACK] 中定义。

CONNECT_ERROR (0x0a):

H3_CONNECT_ERROR，见 第 8.1 节。

ENHANCE_YOUR_CALM (0x0b):

H3_EXCESSIVE_LOAD，见 第 8.1 节。

INADEQUATE_SECURITY (0x0c):

不适用，因为假设 QUIC 在所有连接上提供足够的安全性。

HTTP_1_1_REQUIRED (0x0d):

H3_VERSION_FALLBACK，见 第 8.1 节。

需要为 HTTP/2 和 HTTP/3 分别定义错误代码。参见 第 11.2.3 节。