1.1。HTTP 的早期版本

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

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

HTTP/2 ( [ HTTP2 ] ) 引入了二进制帧和多路复用层，以在不修改传输层的情况下改善延迟。但是，由于 HTTP/2 多路复用的并行特性对 TCP 的丢失恢复机制不可见，因此丢失或重新排序的数据包会导致所有活动事务都经历停顿，无论该事务是否直接受到丢失数据包的影响。

1.2. 委托给 QUIC

QUIC 传输协议结合了流多路复用和每个流的流控制，类似于 HTTP/2 成帧层提供的。通过提供流级别的可靠性和整个连接的拥塞控制，与 TCP 映射相比，QUIC 能够提高 HTTP 的性能。QUIC 还在传输层整合了 TLS 1.3 ( [ TLS13 ] )，提供与通过 TCP 运行 TLS 相当的机密性和完整性，并改进了 TCP Fast Open ( [ TFO ] ) 的连接设置延迟。

本文档定义了 HTTP/3，它是 HTTP 语义在 QUIC 传输协议上的映射，大量借鉴了 HTTP/2 的设计。HTTP/3 依赖于 QUIC 来提供数据的机密性和完整性保护；对等认证；可靠、有序、按流交付。在将流生命周期和流控制问题委托给 QUIC 时，每个流都使用类似于 HTTP/2 框架的二进制框架。QUIC 包含一些 HTTP/2 功能，而其他功能则在 QUIC 之上实现。

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

2.1。文件组织

以下部分提供了 HTTP/3 连接生命周期的详细概述：

• 连接设置和管理（第 3 节）介绍了如何发现 HTTP/3 端点并建立 HTTP/3 连接。
• HTTP 请求生命周期（第 4 节）描述了如何使用帧来表达 HTTP 语义。
• 连接关闭（第 5 节）描述了 HTTP/3 连接如何优雅地或突然地终止。

有线协议的细节以及与传输的交互在后续章节中描述：

• 流映射和使用（第 6 节）描述了 QUIC 流的使用方式。
• HTTP 帧层（第 7 节）描述了大多数流上使用的帧。
• 错误处理（第 8 节）描述了如何处理和表达错误条件，无论是在特定流上还是对于整个连接。

最后部分提供了其他资源：

• HTTP/3 的扩展（第 9 节）描述了如何在未来的文档中添加新功能。
• HTTP/2 和 HTTP/3 之间更详细的比较可以在 附录 A中找到。

2.2. 约定和术语

关键词“必须”、“不得”、“要求”、“应”、“不得”、“应该”、“不应”、“推荐”、“不推荐”、“可以”和“可选”当且仅当它们以全部大写字母出现时，本文档中的 " 将按照 BCP 14 [ RFC2119 ] [ RFC8174 ]中的描述进行解释，如此处所示。

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

使用以下术语：

中止：

连接或流的突然终止，可能是由于错误情况。

客户：

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

联系：

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

连接错误：

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

端点：

连接的客户端或服务器。

框架：

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

本文档和[ QUIC-TRANSPORT ]中都存在称为“框架”的协议元素 。如果引用了[ QUIC-TRANSPORT ]中的帧，则帧名称将以“QUIC”开头。例如，“QUIC CONNECTION_CLOSE 帧”。没有此前言的参考文献是指 第 7.2 节中定义的框架。

HTTP/3 连接：

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

同行：

一个端点。在讨论特定端点时，“对等点”是指远离主要讨论主题的端点。

接收者：

正在接收帧的端点。

发件人：

正在传输帧的端点。

服务器：

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

溪流：

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

流错误：

单个流上的应用程序级错误。

术语“内容”在[语义]的第 6.4 节中定义。

最后，术语“资源”、“消息”、“用户代理”、“源服务器”、“网关”、“中介”、“代理”和“隧道”在[语义]的第 3 节中定义。

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

3.1。发现 HTTP/3 端点

HTTP 依赖于权威响应的概念：在给定目标资源在响应消息由源服务器发起（或在其方向）时的状态的情况下，该响应已被确定为对该请求最合适的响应在目标 URI 中标识。[语义]的4.3 节讨论了为 HTTP URI 定位权威服务器 。

“https”方案将授权与拥有证书相关联，客户端认为该证书对于由 URI 的授权组件标识的主机是可信赖的。在 TLS 握手中接收到服务器证书后，客户端必须使用[语义学]的第 4.3.4 节中描述的过程来验证证书是否与 URI 的源服务器匹配。如果证书无法针对 URI 的源服务器进行验证，则客户端不得认为服务器对该源具有权威性。

客户端可以尝试通过将主机标识符解析为 IP 地址来尝试访问具有“https”URI 的资源，在指定端口上建立到该地址的 QUIC 连接（包括如上所述的服务器证书验证），并发送通过该安全连接将 URI 定位到服务器的 HTTP/3 请求消息。除非使用某种其他机制来选择 HTTP/3，否则在 TLS 握手期间在应用层协议协商（ALPN；参见[ RFC7301 ] ）扩展中使用令牌“h3”。

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

服务器可以在任何 UDP 端口上提供 HTTP/3；替代服务广告始终包含显式端口，并且 URI 包含与方案关联的显式端口或默认端口。

Alt-Svc: h3=":50781"

3.2. 连接建立

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

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

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

虽然与核心 QUIC 协议相关的连接级别选项在初始加密握手中设置，但 HTTP/3 特定设置在 SETTINGS 帧中传达。QUIC 连接建立后，每个端点必须发送一个 SETTINGS 帧（第 7.2.4 节）作为各自 HTTP 控制流的初始帧；见第 6.2.1 节。

3.3. 连接重用

HTTP/3 连接在多个请求中是持久的。为了获得最佳性能，预计客户端不会关闭连接，直到确定不需要与服务器进行进一步通信（例如，当用户导航离开特定网页时）或直到服务器关闭连接。

一旦存在到服务器端点的连接，该连接可以重用于具有多个不同 URI 权限组件的请求。要将现有连接用于新源，客户端必须使用[语义]的第 4.3.4 节中描述的过程验证服务器为新源服务器提供的证书。这意味着客户端将需要保留服务器证书以及验证该证书所需的任何其他信息；不这样做的客户端将无法将连接重用于其他来源。

如果证书由于任何原因对于新源不可接受，则不得重用连接，并且应该为新源建立新连接。如果证书无法验证的原因可能适用于已经与连接关联的其他来源，则客户端应该重新验证这些来源的服务器证书。例如，如果由于证书已过期或被吊销而导致证书验证失败，则这可能用于使该证书用于建立权限的所有其他来源无效。

客户端不应打开多个到给定 IP 地址和 UDP 端口的 HTTP/3 连接，其中 IP 地址和端口可能来自 URI、选定的替代服务 ( [ ALTSVC ] )、配置的代理或名称解析其中任何一个。客户端可以使用不同的传输或 TLS 配置打开到相同 IP 地址和 UDP 端口的多个 HTTP/3 连接，但应避免使用相同配置创建多个连接。

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

不希望客户端为特定来源重用 HTTP/3 连接的服务器可以通过发送 421（错误定向请求）状态代码来响应请求来表明它对请求不具有权威性；参见[语义学]第 7.4 节。

4.1。HTTP 消息交换

客户端在请求流上发送 HTTP 请求，请求流是客户端发起的双向 QUIC 流；见第 6.1 节。客户端必须在给定的流上只发送一个请求。服务器在与请求相同的流上发送零个或多个临时 HTTP 响应，然后是单个最终 HTTP 响应，如下所述。有关临时和最终 HTTP 响应的描述，请参见[语义]的第 15 节。

推送的响应在服务器发起的单向 QUIC 流上发送；见 第 6.2.2 节。服务器以与标准响应相同的方式发送零个或多个临时 HTTP 响应，然后是单个最终 HTTP 响应。推送在4.4 节中有更详细的描述。

在给定的流上，收到多个请求或在最终 HTTP 响应之后收到额外的 HTTP 响应必须被视为格式错误（第 4.1.3 节）。

HTTP 消息（请求或响应）包括：

1. 标头部分，作为单个 HEADERS 帧发送（参见第 7.2.2 节），
2. 可选地，内容（如果存在）作为一系列 DATA 帧发送（参见第 7.2.1 节），并且
3. 可选地，尾部部分（如果存在）作为单个 HEADERS 帧发送。

标题和尾部部分在[语义]的第6.3和6.5节中进行了描述；内容在[语义]的第6.4节中描述。

接收到无效的帧序列必须被视为 H3_FRAME_UNEXPECTED 类型的连接错误；见第 8 节。特别是，任何 HEADERS 帧之前的 DATA 帧，或尾部 HEADERS 帧之后的 HEADERS 或 DATA 帧，都被认为是无效的。其他帧类型，尤其是未知帧类型，可能会根据它们自己的规则被允许；见第 9 节。

服务器可以在响应消息的帧之前、之后或与响应消息的帧交错发送一个或多个 PUSH_PROMISE 帧（第 7.2.5 节）。这些 PUSH_PROMISE 帧不是响应的一部分；有关详细信息，请参阅第 4.4 节。推送流上不允许使用 PUSH_PROMISE 帧；包含 PUSH_PROMISE 帧的推送响应必须被视为 H3_FRAME_UNEXPECTED 类型的连接错误；见第 8 节。

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

HEADERS 和 PUSH_PROMISE 帧可能会引用对 QPACK 动态表的更新。虽然这些更新不是消息交换的直接部分，但必须先接收和处理它们，然后才能使用消息。有关详细信息，请参阅 第 4.1.1 节。

没有为 HTTP/3 定义传输编码（参见[ HTTP11 ]的第 6.1 节）；不得使用 Transfer-Encoding 头域。

当且仅当一个或多个临时响应（1xx；参见[语义]的第 15.2 节）在对同一请求的最终响应之前，响应可能包含多个消息。临时响应不包含内容或预告片部分。

HTTP 请求/响应交换完全使用客户端发起的双向 QUIC 流。发送请求后，客户端必须关闭要发送的流。除非使用 CONNECT 方法（参见第 4.2 节），否则客户端不得依赖于接收到对其请求的响应来进行流关闭。发送最终响应后，服务器必须关闭要发送的流。此时，QUIC 流已完全关闭。

当一个流关闭时，这表示最终 HTTP 消息的结束。由于某些消息很大或无界，端点应该在收到足够多的消息以取得进展后开始处理部分 HTTP 消息。如果客户端发起的流在没有足够的 HTTP 消息来提供完整响应的情况下终止，则服务器应该中止其响应流，错误代码为 H3_REQUEST_INCOMPLETE；见第 8 节。

如果响应不依赖于尚未发送和接收的请求的任何部分，则服务器可以在客户端发送整个请求之前发送完整的响应。当服务器不需要接收请求的剩余部分时，它可以中止读取请求流，发送完整的响应，并干净地关闭流的发送部分。当请求客户端停止在请求流上发送时，应该使用错误代码 H3_NO_ERROR。客户端不能因为他们的请求突然终止而丢弃完整的响应，尽管客户端总是可以出于其他原因自行决定丢弃响应。如果服务器发送了部分或完整的响应但没有中止读取请求，客户端应该继续发送请求的主体并正常关闭流。

4.2. 连接方法

CONNECT 方法请求接收方建立一条到请求目标标识的目标源服务器的隧道；参见[语义学]第 9.3.6 节。它主要与 HTTP 代理一起使用，以与源服务器建立 TLS 会话，以便与“https”资源进行交互。

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

一个 CONNECT 请求必须按如下方式构造：

• ":method" 伪头字段设置为 "CONNECT" 
• ":scheme" 和 ":path" 伪标题字段被省略
• ":authority" 伪头字段包含要连接的主机和端口（相当于 CONNECT 请求的请求目标的权限形式；参见[语义]的第 7.1 节）

请求流在请求结束时保持打开以携带要传输的数据。不符合这些限制的 CONNECT 请求格式不正确；请参阅第 4.1.3 节。

支持 CONNECT 的代理会建立一个 TCP 连接（[ RFC0793 ]）到在 ":authority" 伪标头字段中标识的服务器。一旦成功建立此连接，代理就会向客户端发送一个包含 2xx 系列状态代码的 HEADERS 帧，如[语义]的第 15.3 节中所定义。

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

一旦 CONNECT 方法完成，就只允许在流上发送 DATA 帧。如果扩展定义特别允许，可以使用扩展帧。收到任何其他已知帧类型必须被视为 H3_FRAME_UNEXPECTED 类型的连接错误；见第 8 节。

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

通过突然终止流来表示 TCP 连接错误。代理将 TCP 连接中的任何错误（包括接收设置了 RST 位的 TCP 段）视为 H3_CONNECT_ERROR 类型的流错误；见 第 8 节。相应地，如果代理检测到流或 QUIC 连接错误，它必须关闭 TCP 连接。如果底层 TCP 实现允许，代理应该发送一个设置了 RST 位的 TCP 段。

由于 CONNECT 创建了一个到任意服务器的隧道，支持 CONNECT 的代理应该将其使用限制在一组已知端口或安全请求目标列表；有关更多详细信息，请参阅[语义]的第 9.3.6 节。

4.3. HTTP 升级

HTTP/3 不支持 HTTP 升级机制（[ SEMANTICS ]的第 7.8 节）或 101（交换协议）信息状态代码（[ SEMANTICS ]的第 15.2.2 节）。

4.4. 服务器推送

服务器推送是一种交互模式，它允许服务器将请求-响应交换推送到客户端，以等待客户端发出指示的请求。这权衡了网络使用与潜在的延迟增益。HTTP/3 服务器推送类似于 [ HTTP2 ]的第 8.2 节中描述的内容，但使用不同的机制。

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

Push ID空间从零开始，到MAX_PUSH_ID帧设置的最大值结束；请参阅第 7.2.7 节。特别是，在客户端发送 MAX_PUSH_ID 帧之前，服务器无法推送。客户端发送 MAX_PUSH_ID 帧来控制服务器可以承诺的推送次数。服务器应该按顺序使用 Push ID，从零开始。当没有发送 MAX_PUSH_ID 帧或当流引用大于最大推送 ID 的推送 ID 时，客户端必须将接收推送流视为 H3_ID_ERROR 类型的连接错误（第 8 节）。

Push ID 用于一个或多个 PUSH_PROMISE 帧（第 7.2.5 节），这些帧携带请求消息的标头部分。这些帧在生成推送的请求流上发送。这允许服务器推送与客户端请求相关联。当在多个请求流上承诺相同的 Push ID 时，解压后的请求字段部分必须包含相同顺序的相同字段，并且每个字段中的名称和值都必须相同。

然后将推送 ID 包含在最终履行这些承诺的推送流中；见第 6.2.2 节。推送流标识它履行的承诺的推送 ID，然后包含对承诺请求的响应，如第 4.1 节所述。

最后，Push ID 可以用在 CANCEL_PUSH 帧中；请参阅 第 7.2.3 节。客户使用此框架表示他们不希望收到承诺的资源。服务器使用这个框架来表明他们不会履行之前的承诺。

并非所有请求都可以推送。服务器可以推送具有以下属性的请求：

• 可缓存的；请参阅[语义]的第 9.2.3 节
• 安全的; 请参阅[语义]的第 9.2.1 节
• 不包括请求正文或预告部分

服务器必须在 ":authority" 伪头字段中包含一个服务器对其具有权威性的值。如果客户端尚未验证推送请求所指示的源的连接，它必须执行与在连接上发送该源的请求之前相同的验证过程；见第 3.3 节。如果此验证失败，则客户端不得认为服务器对该来源具有权威性。

客户端应该在收到一个 PUSH_PROMISE 帧时发送一个 CANCEL_PUSH 帧，该帧携带的请求是不可缓存的，不知道是安全的，表示存在请求主体，或者它不认为服务器具有权威性。不得使用或缓存任何相应的响应。

每个推送的响应都与一个或多个客户端请求相关联。推送与接收到 PUSH_PROMISE 帧的请求流相关联。在多个请求流上使用具有相同推送 ID 的 PUSH_PROMISE 帧可以将相同的服务器推送与其他客户端请求相关联。这些关联不影响协议的运行，但可以由用户代理在决定如何使用推送资源时考虑。

与响应的某些部分相关的 PUSH_PROMISE 帧的顺序很重要。服务器应该在发送引用承诺响应的 HEADERS 或 DATA 帧之前发送 PUSH_PROMISE 帧。这减少了客户端请求将由服务器推送的资源的机会。

由于重新排序，推流数据可以在相应的 PUSH_PROMISE 帧之前到达。当客户端接收到带有未知推送 ID 的新推送流时，关联的客户端请求和推送的请求头字段都是未知的。客户端可以缓存流数据以期待匹配的 PUSH_PROMISE。客户端可以使用流流控制（参见[ QUIC-TRANSPORT ]的第 4.1 节）来限制服务器可以提交到推送流的数据量。

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

如果客户端实现了 HTTP 缓存，则可缓存的推送响应（参见[ CACHING ]的第 3 节）可以被客户端存储。在接收到推送的响应时，推送的响应被认为在源服务器上成功验证（例如，如果存在“no-cache”缓存响应指令；请参阅[ CACHING ]的第 5.2.2.3 节）。

不可缓存的推送响应不得由任何 HTTP 缓存存储。它们可以单独提供给应用程序。

5.1。空闲连接

每个 QUIC 端点在握手期间声明一个空闲超时。如果 QUIC 连接保持空闲（没有收到数据包）超过此持续时间，则对等方将假定连接已关闭。如果现有连接的空闲时间超过 QUIC 握手期间协商的空闲超时时间，HTTP/3 实现将需要为新请求打开一个新的 HTTP/3 连接，如果接近空闲超时时间，应该这样做；请参阅[ QUIC-TRANSPORT ]的第 10.1 节。

如[ QUIC-TRANSPORT ]的第 10.1.2 节所述，当请求或服务器推送有未完成的响应时，HTTP 客户端应请求传输保持连接打开。如果客户端不期望来自服务器的响应，则允许空闲连接超时比花费精力维护可能不需要的连接更可取。网关可以根据需要维护连接，而不是产生与服务器建立连接的延迟成本。服务器不应主动保持连接打开。

5.2. 连接关闭

即使连接不是空闲的，任何一个端点都可以决定停止使用该连接并启动一个正常的连接关闭。端点通过发送 GOAWAY 帧（第 7.2.6 节）启动 HTTP/3 连接的正常关闭。GOAWAY 帧包含一个标识符，该标识符向接收者指示在此连接中已处理或可能处理的请求或推送的范围。服务器发送一个客户端发起的双向 Stream ID；客户端发送一个 Push ID（第 4.4 节）。GOAWAY 的发送者拒绝具有指定标识符或更大标识符的请求或推送（第 4.1.2 节）。如果没有处理请求或推送，则此标识符可能为零。

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

端点在收到对等方的 GOAWAY 帧后，不得发起新的请求或承诺在连接上进行新的推送。客户端可以建立一个新的连接来发送额外的请求。

一些请求或推送可能已经在传输中：

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

  来自服务器的对小于 GOAWAY 帧中流 ID 的流 ID 的请求可能已被处理；在收到响应、单独重置流、接收到另一个流 ID 低于相关请求的流 ID 的 GOAWAY 或连接终止之前，无法知道它们的状态。

  如果未处理这些请求，服务器可能会拒绝低于指定 ID 的流上的单个请求。

• 如果服务器在承诺推送后收到 GOAWAY 帧，并且推送 ID 大于或等于 GOAWAY 帧中包含的标识符，则这些推送将不被接受。

服务器应该在提前知道连接关闭时发送 GOAWAY 帧，即使提前通知很小，以便远程对等方可以知道请求是否已部分处理。例如，如果 HTTP 客户端在服务器关闭 QUIC 连接的同时发送 POST，如果服务器没有发送 GOAWAY 帧来指示它可能会发送哪些流，则客户端无法知道服务器是否开始处理该 POST 请求已采取行动。

端点可以发送多个指示不同标识符的 GOAWAY 帧，但每个帧中的标识符不得大于任何先前帧中的标识符，因为客户端可能已经在另一个 HTTP 连接上重试了未处理的请求。接收到包含比先前接收到的更大标识符的 GOAWAY 必须被视为 H3_ID_ERROR 类型的连接错误；见第 8 节。

尝试正常关闭连接的端点可以发送一个 GOAWAY 帧，其值设置为最大可能值（服务器为2 ^{62 -4，客户端为 2 62} -1）。这可确保对等方停止创建新请求或推送。在允许任何正在进行的请求或推送到达之后，端点可以发送另一个 GOAWAY 帧，指示在连接结束之前它可能接受哪些请求或推送。这确保了可以干净地关闭连接而不会丢失请求。

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

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

一旦处理了所有接受的请求和推送，端点可以允许连接变为空闲，或者可以启动连接的立即关闭。完成正常关闭的端点在关闭连接时应该使用 H3_NO_ERROR 错误代码。

如果客户端已经通过请求消耗了所有可用的双向流 ID，则服务器不需要发送 GOAWAY 帧，因为客户端无法发出进一步的请求。

5.3. 立即关闭申请

HTTP/3 实现可以随时立即关闭 QUIC 连接。这导致向对等方发送 QUIC CONNECTION_CLOSE 帧，指示应用层已终止连接。此帧中的应用程序错误代码向对等方指示关闭连接的原因。有关在 HTTP/3 中关闭连接时可以使用的错误代码，请参阅第 8 节。

在关闭连接之前，可能会发送一个 GOAWAY 帧以允许客户端重试某些请求。在与 QUIC CONNECTION_CLOSE 帧相同的数据包中包含 GOAWAY 帧可以提高客户端接收帧的机会。

如果存在未显式关闭的打开流，则在关闭连接时将其隐式关闭；请参阅 [ QUIC-TRANSPORT ]的第 10.2 节。

5.4. 运输封闭

由于各种原因，QUIC 传输可能向应用层指示连接已终止。这可能是由于对等方的显式关闭、传输级错误或中断连接的网络拓扑更改。

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

6.1。双向流

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

这意味着客户端的第一个请求发生在 QUIC 流 0 上，随后的请求发生在流 4、8 上，依此类推。为了允许这些流打开，HTTP/3 服务器应该为允许的流数量和初始流流控制窗口配置非零最小值。为了避免不必要地限制并行性，一次至少应该允许 100 个请求流。

HTTP/3 不使用服务器启动的双向流，尽管扩展可以定义这些流的用途。客户端必须将接收到服务器发起的双向流视为 H3_STREAM_CREATION_ERROR 类型的连接错误（第 8 节），除非已经协商了这样的扩展。

6.2. 单向流

在任一方向上的单向流用于多种目的。目的由流类型指示，它在流的开头作为可变长度整数发送。此整数之后的数据格式和结构由流类型决定。

单向流标头 {
  流类型 (i),
}

本文档中定义了两种流类型：控制流（第 6.2.1 节）和推送流（第 6.2.2 节）。[ QPACK ]定义了两种额外的流类型。其他流类型可以通过对 HTTP/3 的扩展来定义；有关详细信息，请参阅第 9 节。某些流类型是保留的（第 6.2.3 节）。

HTTP/3 连接在其生命周期的早期阶段的性能对单向流上数据的创建和交换很敏感。过度限制流数量或这些流的流控制窗口的端点将增加远程对等点提前达到限制并被阻塞的机会。特别是，实现应该考虑远程对等点可能希望行使保留的流行为（第 6.2.3 节) 与他们被允许使用的一些单向流。为了避免阻塞，客户端和服务器发送的传输参数必须允许对端为 HTTP 控制流创建至少一个单向流加上强制扩展所需的单向流的数量（三个是基本 HTTP 所需的最小数量/3 协议和 QPACK），并且应该为每个流提供至少 1,024 字节的流量控制信用。

请注意，如果端点在创建关键单向流之前消耗了所有初始信用，则不需要授予额外信用来创建更多单向流。端点应该首先创建 HTTP 控制流以及强制扩展所需的单向流（例如 QPACK 编码器和解码器流），然后在其对等方允许的情况下创建其他流。

如果流标头指示接收方不支持的流类型，则无法使用流的其余部分，因为语义未知。未知流类型的接收者可以使用 H3_STREAM_CREATION_ERROR 错误代码或保留错误代码（第 8.1 节）中止读取流，但不得将此类流视为任何类型的连接错误。

实现可以在知道对等方是否支持它们之前发送流类型。但是，可以修改现有协议组件（包括 QPACK 或其他扩展）的状态或语义的流类型，在已知对等方支持它们之前不得发送。

除非另有说明，否则发送者可以关闭或重置单向流。接收者必须容忍单向流在接收到单向流标头之前被关闭或重置。

推流标头 {
  流类型 (i) = 0x01,
  推送 ID (i),
}

7.1。框架布局

所有帧都具有以下格式：

HTTP/3 帧格式 {
  类型 (i),
  长度 (i),
  帧有效载荷 (..),
}

一个框架包括以下字段：

类型：

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

长度：

一个可变长度整数，用于描述帧有效负载的长度（以字节为单位）。

帧载荷：

有效负载，其语义由 Type 字段确定。

每个帧的有效负载必须准确包含在其描述中标识的字段。在已识别字段之后包含附加字节的帧有效载荷或在已识别字段结束之前终止的帧有效载荷必须被视为 H3_FRAME_ERROR 类型的连接错误；见第 8 节。特别是，冗余长度编码必须经过验证是自洽的；见第 10.8 节。

当流完全终止时，如果流上的最后一帧被截断，则必须将其视为 H3_FRAME_ERROR 类型的连接错误；见 第 8 节。突然终止的流可以在帧中的任何点重置。

7.2. 框架定义

数据帧 {
  类型 (i) = 0x0,
  长度 (i),
  数据 （..），
}

标题帧 {
  类型 (i) = 0x1,
  长度 (i),
  编码字段部分（..），
}

CANCEL_PUSH 帧 {
  类型 (i) = 0x3,
  长度 (i),
  推送 ID (i),
}

环境 {
  标识符 (i),
  值 (i),
}

设置框架 {
  类型 (i) = 0x4,
  长度 (i),
  环境 （..） ...，
}

PUSH_PROMISE 帧 {
  类型 (i) = 0x5,
  长度 (i),
  推送 ID (i),
  编码字段部分（..），
}

GOAWAY 帧 {
  类型 (i) = 0x7,
  长度 (i),
  流 ID/推送 ID (..),
}

MAX_PUSH_ID 帧 {
  类型 (i) = 0xd,
  长度 (i),
  推送 ID (i),
}

8.1。HTTP/3 错误代码

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

H3_NO_ERROR (0x100):

没有错误。当连接或流需要关闭但没有错误信号时使用。

H3_GENERAL_PROTOCOL_ERROR (0x101)：

对等方违反协议要求的方式与更具体的错误代码不匹配，或者端点拒绝使用更具体的错误代码。

H3_INTERNAL_ERROR (0x102)：

HTTP 堆栈中发生内部错误。

H3_STREAM_CREATION_ERROR (0x103)：

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

H3_CLOSED_CRITICAL_STREAM (0x104)：

HTTP/3 连接所需的流已关闭或重置。

H3_FRAME_UNEXPECTED (0x105):

接收到的帧在当前状态或当前流中是不允许的。

H3_FRAME_ERROR (0x106)：

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

H3_EXCESSIVE_LOAD (0x107):

端点检测到其对等方正在表现出可能会产生过多负载的行为。

H3_ID_ERROR (0x108):

Stream ID 或 Push ID 使用不正确，例如超出限制、降低限制或被重用。

H3_SETTINGS_ERROR (0x109):

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

H3_MISSING_SETTINGS (0x10a)：

在控制流的开头没有收到 SETTINGS 帧。

H3_REQUEST_REJECTED (0x10b)：

服务器拒绝了请求，但未执行任何应用程序处理。

H3_REQUEST_CANCELLED (0x10c)：

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

H3_REQUEST_INCOMPLETE (0x10d)：

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

H3_MESSAGE_ERROR (0x10e)：

HTTP 消息格式不正确，无法处理。

H3_CONNECT_ERROR (0x10f)：

为响应 CONNECT 请求而建立的 TCP 连接被重置或异常关闭。

H3_VERSION_FALLBACK (0x110):

请求的操作无法通过 HTTP/3 提供。对等方应通过 HTTP/1.1 重试。

保留 N 的非负整数值格式的错误代码0x1f * N + 0x21以执行将未知错误代码视为等效于 H3_NO_ERROR 的要求（第 9 节）。实现应该从这个空间中选择一个错误代码，当他们发送 H3_NO_ERROR 时有一定的概率。

10.1。服务器权限

HTTP/3 依赖于 HTTP 的权限定义。[语义]的第 17.1 节讨论了建立权限的安全考虑。

10.2. 跨协议攻击

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

这并不能保证免受所有跨协议攻击。[ QUIC-TRANSPORT ]的第 21.5 节描述了一些可以使用 QUIC 数据包的明文对不使用经过身份验证的传输的端点执行请求伪造的方法。

10.3. 中间封装攻击

HTTP/3 字段编码允许在 HTTP 使用的语法中表达不是有效字段名称的名称（[语义]的第 5.1 节）。包含无效字段名称的请求或响应必须被视为格式错误（第 4.1.3 节）。因此，中介无法将包含无效字段名称的 HTTP/3 请求或响应转换为 HTTP/1.1 消息。

同样，HTTP/3 可以传输无效的字段值。虽然大多数可以编码的值不会改变字段解析，但回车（CR，ASCII 0xd），换行（LF，ASCII 0xa）和零字符（NUL，ASCII 0x0）可能会被攻击者利用，如果它们是逐字翻译。任何包含字段值中不允许的字符的请求或响应必须被视为格式错误（第 4.1.3 节）。有效字符由[语义]第 5.5 节中的“字段内容”ABNF 规则定义。

10.4. 推送响应的可缓存性

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

根据原始服务器在 Cache-Control 标头字段中提供的指导，可以缓存推送的响应。但是，如果一台服务器托管多个租户，这可能会导致问题。例如，服务器可能会为多个用户提供其 URI 空间的一小部分。

当多个租户在同一台服务器上共享空间时，该服务器必须确保租户无法推送他们无权访问的资源的表示。未能强制执行此操作将允许租户提供将在缓存之外提供的表示，从而覆盖权威租户提供的实际表示。

要求客户端拒绝原始服务器不具有权威性的推送响应；见第 4.4 节。

10.5。拒绝服务注意事项

与 HTTP/1.1 或 HTTP/2 连接相比，HTTP/3 连接可能需要更大的资源承诺才能运行。字段压缩和流量控制的使用取决于用于存储更多状态的资源的承诺。这些功能的设置可确保这些功能的内存承诺受到严格限制。

PUSH_PROMISE 帧的数量以类似的方式受到限制。接受服务器推送的客户端应该限制它一次发布的推送 ID 的数量。

处理能力不能像状态能力那样得到有效保护。

发送要求对等方忽略的未定义协议元素的能力可能会被滥用以导致对等方花费额外的处理时间。这可以通过设置多个未定义的 SETTINGS 参数、未知帧类型或未知流类型来完成。但是请注意，某些用途是完全合法的，例如可理解的扩展和填充以增加对流量分析的抵抗力。

压缩现场部分也提供了一些浪费加工资源的机会；有关潜在滥用的更多详细信息，请参阅[ QPACK ]的第 7 节。

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

不监视此类行为的端点会将自己暴露在拒绝服务攻击的风险中。实现应该跟踪这些特性的使用并设置它们的使用限制。端点可以将可疑活动视为 H3_EXCESSIVE_LOAD 类型的连接错误（第 8 节），但误报将导致中断有效连接和请求。

10.6。使用压缩

当秘密数据在与攻击者控制的数据相同的上下文中被压缩时，压缩可以让攻击者恢复秘密数据。HTTP/3 启用字段压缩（第 4.1.1 节）；以下问题也适用于 HTTP 压缩内容编码的使用；见[语义]第 8.4.1 节。

有一些可证明的利用网络特性的压缩攻击（例如，[ BREACH ]）。攻击者引发多个包含不同明文的请求，观察每个请求中生成的密文的长度，当对秘密的猜测正确时，会显示较短的长度。

在安全通道上通信的实现不得压缩包含机密和攻击者控制的数据的内容，除非每个数据源使用单独的压缩上下文。如果不能可靠地确定数据源，则不得使用压缩。

[ QPACK ]中描述了有关字段部分压缩的进一步考虑。

10.7。填充和流量分析

填充可用于模糊帧内容的确切大小，并用于减轻 HTTP 中的特定攻击，例如，压缩内容包括攻击者控制的明文和秘密数据的攻击（例如， [ BREACH ]）。

在 HTTP/2 使用 PADDING 帧和其他帧中的填充字段以使连接更能抵抗流量分析的情况下，HTTP/3 可以依赖传输层填充或使用第 7.2.8 节和第 7.2.8节中讨论的保留帧和流类型6.2.3 . 这些填充方法在填充的粒度、如何根据受保护的信息安排填充、是否在数据包丢失的情况下应用填充以及实现如何控制填充等方面产生不同的结果。

即使连接空闲，保留流类型也可用于呈现发送流量的外观。由于 HTTP 流量经常以突发的形式出现，因此可以使用明显的流量来掩盖这种突发的时间或持续时间，甚至看起来像是在发送恒定的数据流。但是，由于此类流量仍由接收方进行流量控制，因此未能及时排出此类流量并提供额外的流量控制信用可能会限制发送方发送真实流量的能力。

为了减轻依赖于压缩的攻击，禁用或限制压缩可能比填充作为对策更可取。

使用填充可能导致比看起来立即明显的保护更少。冗余填充甚至可能适得其反。充其量，填充只会使攻击者更难通过增加攻击者必须观察的帧数来推断长度信息。错误实现的填充方案很容易被击败。特别是，具有可预测分布的随机填充提供的保护非常少。同样，将有效载荷填充到固定大小会在有效载荷大小跨越固定大小边界时暴露信息，如果攻击者可以控制明文，这可能是可能的。

10.8。帧解析

几个协议元素包含嵌套的长度元素，通常以具有显式长度的帧的形式包含可变长度整数。这可能会给粗心的实施者带来安全风险。实现必须确保帧的长度与其包含的字段长度完全匹配。

10.9。早期数据

将 0-RTT 与 HTTP/3 一起使用会导致重放攻击。当使用带有 0-RTT 的 HTTP/3 时，必须应用[ HTTP-REPLAY ]中的反重放缓解措施。在将[ HTTP-REPLAY ]应用于 HTTP/3 时，对 TLS 层的引用是指在 QUIC 中执行的握手，而对应用程序数据的所有引用都是指流的内容。

10.10。移民

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

10.11。隐私注意事项

HTTP/3 的几个特性为观察者提供了将单个客户端或服务器的操作随时间关联的机会。这些包括设置的值、对刺激的反应时间以及对设置控制的任何功能的处理。

就这些在行为上产生可观察到的差异而言，它们可以用作对特定客户进行指纹识别的基础。

HTTP/3 对使用单个 QUIC 连接的偏好允许关联用户在站点上的活动。重用不同来源的连接允许跨这些来源的活动相关联。

QUIC 的几个特性会请求立即响应，端点可以使用它来测量对等点的延迟；在某些情况下，这可能会影响隐私。

11.1。HTTP/3 标识字符串的注册

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

“h3”字符串标识 HTTP/3：

协议：

HTTP/3 

识别顺序：

0x68 0x33 ("h3") 

规格：

本文档

11.2. 新登记处

本文档中创建的新注册中心根据[ QUIC-TRANSPORT ]第 22.1 节中记录的 QUIC 注册政策运行。这些注册表都包括[ QUIC-TRANSPORT ]的第 22.1.1 节中列出的通用字段集。这些注册表[应/被]收集在“超文本传输协议版本 3 (HTTP/3) 参数”标题下。

在本文档中创建的这些注册中心的初始分配都被分配了永久状态，并列出了 IETF 的变更控制者和 HTTP 工作组的联系人 (ietf-http-wg@w3.org)。

A.1。流

HTTP/3 允许使用比 HTTP/2 更多的流 (2 ⁶² -1)。关于流标识符空间耗尽的相同考虑也适用，尽管空间要大得多，因此很可能首先达到 QUIC 中的其他限制，例如连接流控制窗口的限制。

与 HTTP/2 相比，HTTP/3 中的流并发由 QUIC 管理。当所有数据都已接收并且发送的数据已被对等方确认时，QUIC 认为流已关闭。当包含 END_STREAM 位的帧已提交到传输时，HTTP/2 认为流已关闭。结果，等价交换的流可以在更长的时间段内保持“活跃”。HTTP/3 服务器可能会选择允许更大数量的并发客户端发起的双向流来实现与 HTTP/2 等效的并发性，具体取决于预期的使用模式。

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

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

A2。HTTP 帧类型

HTTP/2 中的许多框架概念可以在 QUIC 上省略，因为传输处理它们。因为帧已经在流上，所以它们可以省略流号。因为帧不会阻塞多路复用（QUIC 的多路复用发生在这一层之下），所以可以删除对可变最大长度数据包的支持。因为流终止由 QUIC 处理，所以不需要 END_STREAM 标志。这允许从通用框架布局中删除标志字段。

帧有效载荷主要来自[ HTTP2 ]。但是，QUIC 包含许多 HTTP/2 中也存在的特性（例如，流控制）。在这些情况下，HTTP 映射不会重新实现它们。因此，HTTP/3 中不需要几种 HTTP/2 帧类型。在不再使用 HTTP/2 定义的帧的地方，已经保留了帧 ID，以最大限度地提高 HTTP/2 和 HTTP/3 实现之间的可移植性。然而，即使出现在两个映射中的帧类型也不具有相同的语义。

许多差异源于 HTTP/2 提供了跨所有流的帧之间的绝对排序这一事实，而 QUIC 仅在每个流上提供这种保证。因此，如果一种帧类型假设来自不同流的帧仍将按发送顺序接收，那么 HTTP/3 将破坏它们。

下面描述了一些特性调整的示例，以及扩展框架实现者将 HTTP/2 扩展转换为 HTTP/3 的一般指导。

A.3。HTTP/2 设置参数

与 HTTP/2 的一个重要区别是设置被发送一次，作为控制流的第一帧，此后不能更改。这消除了围绕更改同步的许多极端情况。

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

下面是如何映射每个 HTTP/2 SETTINGS 参数的列表：

SETTINGS_HEADER_TABLE_SIZE (0x1)：

见[ QPACK ]。

SETTINGS_ENABLE_PUSH (0x2)：

这被删除以支持 MAX_PUSH_ID 框架，它提供对服务器推送的更精细控制。在 HTTP/3 SETTINGS 帧中指定标识符为 0x2（对应于 SETTINGS_ENABLE_PUSH 参数）的设置是错误的。

SETTINGS_MAX_CONCURRENT_STREAMS (0x3)：

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

SETTINGS_INITIAL_WINDOW_SIZE (0x4)：

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

SETTINGS_MAX_FRAME_SIZE (0x5)：

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

SETTINGS_MAX_HEADER_LIST_SIZE (0x6)：

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

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

需要为 HTTP/2 和 HTTP/3 分别定义设置。[ HTTP2 ]中定义的设置 ID为简单起见而保留。请注意，HTTP/3 中的设置标识符空间要大得多（62 位对 16 位），因此许多 HTTP/3 设置没有等效的 HTTP/2 代码点。请参阅 第 11.2.2 节。

由于 QUIC 流可能无序到达，因此建议端点在响应其他流之前不要等待对等方的设置到达。请参阅 第 7.2.4.2 节。

A.4。HTTP/2 错误代码

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

[ HTTP2 ]的第 7 节中定义的 HTTP/2 错误代码在逻辑上映射到 HTTP/3 错误代码如下：

NO_ERROR (0x0)：

第 8.1 节中的 H3_NO_ERROR 。

PROTOCOL_ERROR (0x1)：

这被映射到 H3_GENERAL_PROTOCOL_ERROR ，除非已经定义了更具体的错误代码。此类情况包括第 8.1 节中定义的 H3_FRAME_UNEXPECTED、H3_MESSAGE_ERROR 和 H3_CLOSED_CRITICAL_STREAM 。

INTERNAL_ERROR (0x2)：

第 8.1 节中的 H3_INTERNAL_ERROR 。

FLOW_CONTROL_ERROR (0x3)：

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

SETTINGS_TIMEOUT (0x4)：

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

STREAM_CLOSED (0x5)：

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

FRAME_SIZE_ERROR (0x6)：

H3_FRAME_ERROR 错误代码在第 8.1 节中定义。

REFUSED_STREAM (0x7)：

H3_REQUEST_REJECTED（在第 8.1 节中）用于指示未处理请求。否则，不适用，因为 QUIC 处理流管理。

取消（0x8）：

第 8.1 节中的 H3_REQUEST_CANCELLED 。

COMPRESSION_ERROR (0x9)：

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

CONNECT_ERROR (0xa)：

第 8.1 节中的 H3_CONNECT_ERROR 。

ENHANCE_YOUR_CALM (0xb)：

第 8.1 节中的 H3_EXCESSIVE_LOAD 。

INADEQUATE_SECURITY (0xc)：

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

HTTP_1_1_REQUIRED (0xd)：

第 8.1 节中的 H3_VERSION_FALLBACK 。

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

B.1。由于草案-ietf-quic-http-32

• 删除了草案版本指南；添加了最终版本字符串
• 为格式错误的消息添加了 H3_MESSAGE_ERROR 

B.2。由于草案-ietf-quic-http-31

仅编辑更改。

B.3。由于草案-ietf-quic-http-30

仅编辑更改。

B.4。由于草案-ietf-quic-http-29

• 如果接收到与 HTTP/2 中的帧相对应的保留帧类型，则需要连接错误 (#3991, #3993) 
• 如果接收到与 HTTP/2 中的设置相对应的保留设置，则需要连接错误 (#3954, #3955) 

B.5。自草案-ietf-quic-http-28

• 即使流被重置，也建议使用 CANCEL_PUSH (#3698, #3700) 
• 当 GOAWAY 包含更大的标识符时使用 H3_ID_ERROR (#3631, #3634) 

B.6。由于草案-ietf-quic-http-27

• 更新文本以引用最新的 HTTP 修订
• 使用 HTTP 权限定义来建立和合并连接 (#253, #2223, #3558) 
• 定义从两个端点使用 GOAWAY (#2632, #3129) 
• 如果 URI 方案具有强制权限组件，则需要 :authority 或 Host (#3408, #3475) 

B.7. 由于草案-ietf-quic-http-26

• 没有变化

B.8. 由于草案-ietf-quic-http-25

• HTTP/3 需要 QUICv1 (#3117, #3323) 
• 移除 DUPLICATE_PUSH 并允许重复的 PUSH_PROMISE (#3275, #3309) 
• 澄清“畸形”的定义（#3352，#3345）

B.9。由于草案-ietf-quic-http-24

• 删除了 H3_EARLY_RESPONSE 错误代码；建议使用 H3_NO_ERROR (#3130,#3208) 
• 未知错误码等价于 H3_NO_ERROR (#3276,#3331) 
• 一些错误代码保留用于润滑 (#3325,#3360) 

B.10。由于草案-ietf-quic-http-23

• 删除quic了 Alt-Svc 参数 (#3061,#3118) 
• 客户端无需保留未知设置以用于 0-RTT (#3110,#3113) 
• 澄清 CANCEL_PUSH 周围的错误情况 (#2819,#3083) 

B.11。由于草案-ietf-quic-http-22

• 删除了优先级信令 (#2922,#2924) 

• 错误代码的进一步更改（#2662，#2551）：

  • 错误代码重新编号
  • HTTP_MALFORMED_FRAME 替换为 HTTP_FRAME_ERROR、HTTP_ID_ERROR 等
• 阐明未知帧类型如何与所需帧序列交互 (#2867,#2858) 
• 根据定义的接口术语描述与传输的交互（#2857，#2805）
• http-opportunistic当方案为 http(#2439,#2973)时要求使用资源 (RFC 8164) 
• 设置标识符不能重复 (#2979) 

• 0-RTT (#2972,#2790,#2945) 中 SETTINGS 帧的更改：

  • 服务器必须在其 SETTINGS 框架中发送所有具有非默认值的设置，即使在恢复时
  • 如果客户端没有与 0-RTT 票证关联的设置，它将使用默认值
  • 如果服务器无法恢复客户端将记住的设置，则服务器无法接受早期数据
• 明确禁止升级和 101 状态码 (#2898,#2889) 
• 澄清为润滑而保留的帧类型可以出现在任何流上，但禁止由于 HTTP/2 对应而保留的帧类型 (#2997,#2692,#2693) 
• 未知的错误代码不能被视为错误 (#2998,#2816) 

B.12。自草案-ietf-quic-http-21

没有变化

B.13。由于草案-ietf-quic-http-20

• 禁止关闭控制流 (#2509, #2666) 
• 更改默认优先级以使用孤立节点 (#2502, #2690) 
• 恢复独占优先级 (#2754, #2781) 
• 使用 CONNECT 时限制使用帧 (#2229, #2702) 
• 如果 CONNECT 发生连接错误，则关闭并可能重置流 (#2228, #2703) 
• 鼓励为 QPACK 提供足够的单向流 (#2100, #2529, #2762) 
• 允许扩展使用服务器发起的双向流 (#2711, #2773) 
• 阐明最大标题列表大小设置的使用 (#2516, #2774) 

• 错误代码及其发送条件的广泛更改

  • 更多错误条件需要连接错误（#2511，#2510）
  • 更新了非法 GOAWAY 帧的错误代码 (#2714, #2707) 
  • 为控制流上的 HEADERS 指定错误代码 (#2708) 
  • 为接收 PUSH_PROMISE 的服务器指定错误代码 (#2709) 
  • 指定在 HEADERS 之前接收 DATA 的错误代码 (#2715) 
  • 描述格式错误的消息及其处理 (#2410, #2764) 
  • 移除 HTTP_PUSH_ALREADY_IN_CACHE 错误 (#2812, #2813) 
  • 重构 Push ID 相关错误 (#2818, #2820) 
  • 合理化 HTTP/3 流创建错误 (#2821, #2822) 

B.14。自草案-ietf-quic-http-19

• SETTINGS_NUM_PLACEHOLDERS 为 0x9 (#2443,#2530) 
• PRIORITY 帧的 Empty 字段中的非零位可能被视为错误 (#2501) 

B.15。自草案-ietf-quic-http-18

• 建议在 GOAWAY 之后重置流，但不是必需的 (#2256,#2457) 

• 始终使用可变长度整数 (#2437,#2233,#2253,#2275) 

  • 可变长度帧类型、流类型和设置标识符
  • 重新编号的流类型分配
  • 修改后的关联保留值
• 帧布局从 Length-Type-Value 切换到 Type-Length-Value (#2395,#2235) 
• 为接收 DUPLICATE_PUSH 的服务器指定错误代码 (#2497) 
• 对无效优先级使用连接错误 (#2507, #2508) 

B.16。自草案-ietf-quic-http-17

• HTTP_REQUEST_REJECTED 用于表示请求可以重试 (#2106, #2325) 
• 在错误的流上更改了 GOAWAY 的错误代码 (#2231, #2343) 

B.17. 自草案-ietf-quic-http-16

• 将“HTTP/QUIC”重命名为“HTTP/3”（#1973）

• PRIORITY 框架的变化 (#1865, #2075) 

  • 允许作为请求流的第一帧
  • 删除排他优先级
  • 更改优先元素类型位
• 定义 DUPLICATE_PUSH 帧以引用另一个 PUSH_PROMISE (#2072) 
• 设置设置的默认值，在接收 SETTINGS 之前允许请求 (#1809, #1846, #2038) 
• 阐明未关闭的流的消息处理规则 (#1972, #2003) 
• 删除了错误代码 0 的保留并将 HTTP_NO_ERROR 移动到该值 (#1922) 
• 删除了对零长度 DATA 帧的禁止 (#2098) 

B.18. 由于草案-ietf-quic-http-15

大量的编辑重组；没有技术变化。

B.19。由于草案-ietf-quic-http-14

• 为 QUIC 传输参数推荐合理的值 (#1720,#1806) 
• 定义缺少 SETTINGS 帧的错误 (#1697,#1808) 
• 设置值是可变长度整数 (#1556,#1807) 并且没有单独的最大值 (#1820) 
• 连接关闭的扩展讨论 (#1599,#1717,#1712) 
• HTTP_VERSION_FALLBACK 回退到 HTTP/1.1 (#1677,#1685) 

B.20。由于草案-ietf-quic-http-13

• 为润滑脂保留一些框架类型 (#1333, #1446) 
• 允许未知的单向流类型，而不是错误；一些保留用于润滑脂 (#1490, #1525) 
• 要求为 0-RTT 记住设置，禁止减少 (#1541, #1641) 
• 指定截断请求的行为 (#1596, #1643) 

B.21。由于草案-ietf-quic-http-12

• 如果使用替代方法，则 TLS SNI 扩展不是强制性的 (#1459, #1462, #1466) 
• 从 HTTP/3 帧中删除了标志 (#1388, #1398) 
• 用于保留可扩展性的保留帧类型和设置 (#1333, #1446) 
• 添加了一般错误代码 (#1391, #1397) 
• 单向流带有类型字节并且是可扩展的 (#910,#1359) 
• 优先级机制现在使用显式占位符来启用树中的持久结构 (#441,#1421,#1422) 

B.22。由于草案-ietf-quic-http-11

• 将 QPACK 表更新和确认移动到专用流（#1121、#1122、#1238）

B.23。由于草案-ietf-quic-http-10

• 尝试和接受 0-RTT 时需要记住设置 (#1157, #1207) 

B.24。自草案-ietf-quic-http-09

• 选择 QCRAM 用于头部压缩 (#228, #1117) 
• server_name TLS 扩展现在是强制性的 (#296, #495) 
• 指定处理 Alt-Svc 中不支持的版本 (#1093, #1097) 

B.25。由于草案-ietf-quic-http-08

• 阐明连接合并规则 (#940, #1024) 

B.26。从草案-ietf-quic-http-07

• QUIC 中整数编码的变化 (#595,#905) 
• 酌情使用单向流 (#515, #240, #281, #886) 
• 对 GOAWAY 描述的改进 (#604, #898) 
• 改进对服务器推送使用的描述 (#947, #950, #957) 

B.27。自草案-ietf-quic-http-06

• 跟踪 QUIC 错误代码使用的变化 (#485) 

B.28. 由于草案-ietf-quic-http-05

• 使推送 ID 连续，添加 MAX_PUSH_ID，删除 SETTINGS_ENABLE_PUSH (#709) 
• 关于 keep-alive 和 QUIC PING 的指南 (#729) 
• 关于 GOAWAY 和取消的扩展文本 (#757) 

B.29。由于草案-ietf-quic-http-04

• 引用 RFC 5234 (#404) 
• 每个请求返回单个流 (#245,#557) 
• 使用来自 HTTP/2 (#81) 的单独帧类型和设置注册表
• SETTINGS_ENABLE_PUSH 而不是 SETTINGS_DISABLE_PUSH (#477) 
• 恢复 GOAWAY (#696) 
• 使用 Push ID 而不是流 ID 识别服务器推送 (#702,#281) 
• DATA 帧不能为空 (#700) 

B.30。从草案-ietf-quic-http-03

没有任何。

B.31。从草案-ietf-quic-http-02

• 跟踪运输草案的变化

B.32。由于草案-ietf-quic-http-01

• 设置更改（#181）：

  • SETTINGS 只能在连接开始时发送一次；此后没有变化
  • SETTINGS_ACK 已移除
  • 设置只能在 SETTINGS 框架中发生一次
  • 布尔格式更新
• Alt-Svc 参数从“v”更改为“quic”；格式更新 (#229) 
• 关闭连接控制流或任何消息控制流是致命错误 (#176) 
• HPACK 序列计数器可以换行 (#173) 
• 添加了 0-RTT 指导
• 添加了与 HTTP/2 和移植 HTTP/2 扩展的差异指南 (#127,#242) 

B.33。由于草案-ietf-quic-http-00

• 在整个 (#11,#29) 中将“HTTP/2-over-QUIC”更改为“HTTP/QUIC” 
• 从在 Stream 3 中使用 HTTP/2 帧更改为新的帧格式和每个请求两个流的模型 (#71,#72,#73) 
• 从 draft-bishop-httpbis-extended-settings-01 采用 SETTINGS 格式
• 重新设计 SETTINGS_ACK 以解决不确定的流间顺序 (#75) 
• 描述的 CONNECT 伪方法 (#95) 
• 更新了 ALPN 令牌和 Alt-Svc 指南 (#13,#87) 
• 应用层定义的错误代码 (#19,#74) 

B.34。由于 draft-shade-quic-http2-mapping-00

• 被采纳为 draft-ietf-quic-http 的基础
• 更新的作者/编辑列表