HTTP 可扩展优先级方案

这是一个互联网标准轨道文档。

本文档是互联网工程任务组 (IETF) 的产物。它代表了 IETF 社区的共识。该文档已接受公开评审并已获得互联网工程指导组 (IESG) 批准发布。有关互联网标准的更多信息，请参阅 RFC 7841 第 2 节。

有关本文件当前状态、任何勘误以及如何提供反馈的信息，可在 https://www.rfc-editor.org/info/rfc9218 获得。

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

HTTP [HTTP] 资源的表示通常与一个或多个其他资源存在关系。客户端经常在处理已检索的表示时发现这些关系，这可能导致进一步的检索请求。同时，这些关系的性质决定了客户端是否会被阻塞而无法继续处理本地可用资源。一个示例是 HTML 文档的可视化呈现，文档引用的级联样式表（CSS）文件的检索可能会阻塞渲染。相比之下，内联图像不会阻塞渲染，会在图像数据块到达时增量绘制。

HTTP/2 [HTTP/2] 和 HTTP/3 [HTTP/3] 支持在单个连接上复用请求和响应。任何提供复用的协议实现的一个重要功能是能够对发送的信息进行优先级排序。例如，为了尽早为客户端提供有意义的 HTML 文档呈现，HTTP 服务器应当优先发送那些对呈现最重要的 HTTP 响应，或这些响应的分块。

HTTP/2 和 HTTP/3 服务器可以通过任意方式对并发响应数据的传输进行调度。服务器可以忽略客户端的优先级信号仍然成功提供 HTTP 响应。然而，不了解客户端如何发出请求和消费响应的服务器可能会导致客户端应用性能不佳。优先级信号允许客户端传达它们对请求优先级的看法。服务器有其自身的需求，这些需求独立于客户端，因此服务器通常将优先级信号与其他可用信息结合起来，以指导响应数据的调度。

RFC 7540 [RFC7540] 的流优先级允许客户端发送一系列优先级信号来向服务器传达一个“优先级树”；该树的结构表示客户端偏好的相对排序和带权带宽分配。服务器可以将这些优先级信号用作优先级决策的输入。

RFC 7540 流优先级的设计与实现被观察到存在不足，具体说明见 第 2 节。因此，HTTP/2 [HTTP/2] 在其修订中弃用使用这些流优先级信号。为了保持线上的兼容性，HTTP/2 保留了这些协议元素（参见 HTTP/2 第 5.3.2 节），这意味着即使存在替代信号（例如本文档描述的方案），这些元素仍可能被使用。

本文档描述了一种使用绝对值的可扩展 HTTP 响应优先级方案。第 4 节 定义了优先级参数，这是一种标准化且可扩展的优先级信息格式。第 5 节 定义了 Priority HTTP 头字段，用于以与 HTTP 版本无关的方式传达初始优先级。客户端可以发送该头字段以指示它们对响应优先级的看法。同样，位于中介之后的服务器可以使用该字段向中介提示优先级。在发送请求之后，客户端可以通过发送对应于 HTTP 版本的帧来改变它们对响应优先级的看法（参见 第 6 节），这些帧如 第 7.1 节 和 第 7.2 节 所定义。

头字段和帧的优先级信号是服务器响应优先级处理的输入。它们仅为建议，并不保证某一响应相对于其他响应在处理或传输顺序上的具体行为。第 10 节 和 第 12 节 提供了关于服务器可能如何基于这些信号采取行动的考虑和指导。

RFC 7540 流优先级（参见 RFC7540 第 5.3 节）是一个复杂的系统，客户端通过信号流的依赖关系和权重来描述一个不平衡树。它在部署和互操作性方面存在限制，并已在 HTTP/2 的修订中被弃用。为了保持线上的兼容性，HTTP/2 保留了这些元素（见 HTTP/2 第 5.3.2 节），这意味着即使存在替代信号（例如本文档描述的方案），这些元素仍可能被使用。

许多 RFC 7540 的服务器实现并不根据 HTTP/2 优先级信号采取行动。

优先级决策可以使用服务器关于资源的信息或请求生成顺序的信息。例如，了解 HTML 文档结构的服务器可能希望优先传送对用户体验至关重要的图像而不是其他图像。在 RFC 7540 中，服务器难以解释客户端发送的优先级信号，因为相同的条件可能导致不同客户端发出非常不同的信号。本文档描述的信号更简单且更受限，需要更少的解释并减少差异。

RFC 7540 未定义服务器可用于向中介提供优先级信号的方法。

RFC 7540 流优先级是相对于在同一连接上同时存在的其他请求表达的。在不清楚其他请求如何共享连接的应用中，或在像 HTTP/3 这样跨流没有强顺序保证的协议中，难以将此设计融入应用。

独立研究的实验 [MARX] 表明，对于 Web 使用场景，较简单的方案在性能特性上至少可以达到与实践中复杂的 RFC 7540 方案相当的表现。

本文档定义的优先级方案主要关注 HTTP 响应消息的优先级（参见 HTTP Semantics 第 3.4 节）。它定义了新的优先级参数（第 4 节）以及传达这些参数的方法（第 5 节 与 第 7 节），用于将响应的优先级传达给负责对它们进行优先级排序的服务器。第 10 节 为服务器在结合其他输入和因素时如何依据这些信号采取行动提供了考虑。

CONNECT 方法（参见 HTTP Semantics 第 9.3.6 节）可用于建立隧道。对隧道的信号传递也类似适用；关于服务器端优先级的额外考虑见 第 11 节。

第 9 节 描述了客户端如何可选地将本方案的元素应用于它们生成的请求消息的本地处理。

某些形式的 HTTP 扩展可能会改变 HTTP/2 或 HTTP/3 的流行为或定义新的数据承载机制。这类扩展可以自行定义如何应用本优先级方案。

优先级信息是一系列键值对，为将来的扩展留出空间。每个键值对表示一个优先级参数。

Priority HTTP 头字段（第 5 节）是在发出请求或响应时以端到端方式传输这组优先级参数的方法。发送请求后，客户端可以通过发送对应 HTTP 版本的 PRIORITY_UPDATE 帧来改变其对响应优先级的看法（第 6 节），这些帧如 第 7.1 节 与 第 7.2 节 所定义。帧仅在单跳上传输优先级参数。

中介可以在 PRIORITY_UPDATE 帧或 Priority 头字段中消费并产生优先级信号。仅将 Priority 请求头字段传递到下一跳的中介会保留来自客户端的原始端到端信号；见 第 14 节。中介可以既转发 Priority 头字段，又额外发送 PRIORITY_UPDATE 帧。这将既保留客户端的端到端信号，又按 第 7 节 的指导指示下一跳使用不同的优先级。替换或添加 Priority 请求头字段的中介会覆盖客户端的原始端到端信号，这可能影响请求随后所有接收者的优先级处理。

对于 Priority 头字段和 PRIORITY_UPDATE 帧，优先级参数集合被编码为 Dictionary（参见 [STRUCTURED-FIELDS] 第 3.2 节）。

本文档定义了紧急度（u）和是否可增量处理（i）优先级参数。当接收到不携带这些优先级参数的 HTTP 请求时，服务器 SHOULD 视为指定了它们的默认值。

中介可以组合其转发的请求和响应中的信号。注意，响应中省略优先级参数的处理方式与请求中省略时不同；见 第 8 节。

接收者按 [STRUCTURED-FIELDS] 第 4.2 节 中描述的方式解析 Dictionary。当 Dictionary 成功解析时，本文档额外要求：未知的优先级参数、取值超出范围的优先级参数，或类型不符的值 MUST 被忽略。

Priority HTTP 头字段是一个承载优先级参数的 Dictionary（参见 第 4 节）。它可以出现在请求和响应中。它是一个端到端的信号，用来表示端点关于 HTTP 响应应如何被优先处理的观点。第 8 节 描述了中介如何合并来自客户端和服务器的优先级信息。客户端不能将 Priority 响应头字段的出现或省略解释为任何优先级处理已发生的确认。关于端点如何基于 Priority 头字段值采取动作的指导见 第 9 节 和 10 节。

带有 Priority 头字段的 HTTP 请求可能会被缓存并在后续请求中重用；参见 [CACHING]。当源服务器基于收到的 HTTP 请求的属性生成 Priority 响应头字段时，服务器应通过使用控制缓存行为的头字段（例如 Cache-Control、Vary）来控制缓存响应的可缓存性或适用性。

在客户端发送请求之后，改变响应的优先级可能是有益的。例如，浏览器可能会为一个 JavaScript 文件发出预取请求，并在 Priority 请求头字段中将紧急度参数设置为 u=7（后台）。然后，当用户导航到引用该 JavaScript 文件的页面时，在预取进行中，浏览器可以发送一个 reprioritization 信号，将 Priority 字段值设置为 u=0。PRIORITY_UPDATE 帧（第 7 节）可以用于此类重新优先级设置。

本文档为 HTTP/2 [HTTP/2] 和 HTTP/3 [HTTP/3] 指定了一种新的 PRIORITY_UPDATE 帧。该帧携带优先级参数并基于版本特定的标识符引用被优先化的目标。在 HTTP/2 中，此标识符为 stream ID；在 HTTP/3 中，标识符可以是 stream ID 或 push ID。与 Priority 头字段不同，PRIORITY_UPDATE 帧是按跳（hop-by-hop）的信号。

客户端在控制流上发送 PRIORITY_UPDATE 帧，使其可以独立于承载响应的流而发送。这意味着它们可用于对响应或推送流重新优先级，或在替代 Priority 头字段的情况下指示响应的初始优先级。

PRIORITY_UPDATE 帧在 Priority Field Value 字段中传达完整的一组优先级参数。省略某个优先级参数表示使用其默认值。无法解析 Priority Field Value MAY 被视为连接错误。在 HTTP/2 中，该错误类型为 PROTOCOL_ERROR；在 HTTP/3 中，该错误类型为 H3_GENERAL_PROTOCOL_ERROR。

客户端 MAY 在其引用的流打开之前发送 PRIORITY_UPDATE 帧（HTTP/2 推送流除外；参见 第 7.1 节）。此外，HTTP/3 在流之间不提供保证的 ordering，这可能导致帧被比预期更早接收。无论哪种情况都会导致竞争条件，即服务器接收到引用尚未打开的请求流的 PRIORITY_UPDATE 帧。为了解决此类情况，就调度而言，最近接收到的 PRIORITY_UPDATE 帧可以被视为最新信息并覆盖任何其他信号。服务器 SHOULD 缓冲最近接收到的 PRIORITY_UPDATE 帧，并在所引用的流打开后应用它。为每个流保存 PRIORITY_UPDATE 帧会消耗服务器资源，服务器可以通过本地实现策略对其进行限制。尽管可以发送任意数量的 PRIORITY_UPDATE 帧，但仅存储最近接收到的帧可以限制资源占用。

客户端并不总是最清楚哪些 HTTP 响应应被优先处理。服务器可能掌握额外的信息，可以与客户端表明的优先级相结合，以改进响应的优先级排序。例如，HTML 文档的使用可能非常依赖某个内联图像；此类依赖关系通常由服务器最清楚。或者，当服务器收到对字体 [RFC8081] 和图像具有相同紧急度的请求时，服务器可能会优先传送字体，以便可视客户端能尽早呈现文本信息。

源可以使用 Priority 响应头字段来指示其关于 HTTP 响应应如何被优先处理的观点。转发 HTTP 响应的中介可以将 Priority 响应头字段中发现的优先级参数与客户端的 Priority 请求头字段结合，作为其优先级处理过程的输入。对于如何合并优先级不提供具体指导；这由实现决定。

HTTP 响应中缺少优先级参数表示服务器不希望更改客户端提供的值。这与请求头字段不同：在请求头字段中省略优先级参数表示使用其默认值（参见 第 4 节）。

作为一个非规范性示例，当客户端发送一个紧急度参数为 5、是否可增量处理参数为 true 的 HTTP 请求时：

:method = GET
:scheme = https
:authority = example.net
:path = /menu.png
priority = u=5, i

并且源响应为

:status = 200
content-type = image/png
priority = u=1

中介可能会将其对紧急度的理解从 5 更改为 1，因为它更倾向于使用服务器提供的值。增量值继续为 true，即客户端指定的值，因为服务器未指定增量参数（i）。

客户端 MAY 使用优先级值对其发起的请求在本地进行处理或调度选择。

通常，HTTP 服务器尽可能提前发送所有响应是有益的。然而，当在单个连接上为多个请求提供服务时，请求之间可能会为诸如连接带宽等资源发生竞争。本节描述了在存在此类竞争时，服务器可如何调度竞争响应的发送顺序的考虑事项。

服务器调度是一个基于多种输入的优先级过程，优先级信号只是输入的一种形式。实现选择或部署环境等因素也会起作用。任何给定连接很可能具有许多动态变化。出于这些原因，不可能描述通用的调度算法。本文档为服务器可能如何基于优先级参数采取行动提供了一些基本的、非详尽的建议，但并未详细描述服务器如何将优先级信号与其他因素结合。端点不能依赖于基于优先级信号的特定处理。表达优先级仅为建议。

在可行时，建议服务器尊重紧急度参数（第 4.1 节），在可能时先发送更高紧急度的响应。

增量参数指示客户端如何在字节到达时处理响应。建议在可行时，服务器尊重增量参数（第 4.2 节）。

具有相同紧急度的非增量响应 SHOULD 通过按照流 ID 的升序优先分配带宽来提供，这对应于客户端发出请求的顺序。这样做可确保客户端可以使用请求顺序来影响响应顺序。

具有相同紧急度的增量响应 SHOULD 通过在它们之间共享带宽来提供。增量响应的消息内容会随着部分或分块的接收被使用。客户端可能更受益于接收所有这些资源的一部分，而不是单个资源的全部。对于提高性能所需的资源部分大小因资源类型而异：有些资源类型在较早位置包含关键元素；有些资源可以渐进使用。该方案未对服务器应如何使用大小、类型或任何其他输入来决定优先级进行明确要求。

1. 在相同紧急度级别下，先有一个对大型资源的非增量请求，随后是对小资源的增量请求。
2. 在相同紧急度级别下，先有一个长度不确定的增量请求，随后是对大型资源的非增量请求。

建议服务器在可能的情况下避免此类饥饿。实现避免的方法由实现者决定。例如，服务器可以基于内容大小等信息预先发送特定增量类型的响应。

服务器推送的最佳调度很难确定，尤其是在被推送的资源与活动并发请求发生竞争时。服务器在调度时可以考虑多种因素，例如被推送资源的类型或大小、触发推送的请求的优先级、活动并发响应的计数、其他活动并发响应的优先级等。对于如何最好地应用这些因素没有通用指导。过于简单的服务器很容易以过高的优先级推送并阻塞客户端请求，或以过低的优先级推送并延迟响应，从而抵消服务器推送的预期目标。

优先级信号是服务器推送调度的一个因素。参数默认值的概念在此略有不同，因为没有明确的客户端信号初始优先级。服务器可以应用源响应中提供的优先级信号；见 第 8 节 中关于合并的指导。在缺少源信号的情况下，应用默认参数值可能并非最佳。无论服务器以何种方式决定调度被推送的响应，它都可以通过在 PUSH_PROMISE 或 HEADERS 帧中包含 Priority 字段向客户端指示预期优先级。

当流承载 CONNECT 请求时，本文档中的调度指导适用于该流上的帧。发出多个 CONNECT 请求的客户端可以将增量参数设置为 true。实现了增量参数处理建议的服务器（第 10 节）很可能会公平地调度这些请求，防止一个 CONNECT 流阻塞其他流。

诸如 TCP 和 QUIC 的传输协议通过检测分组丢失并重传丢失的信息来提供可靠性。除了 第 10 节 中的考虑外，重传数据的调度可能会与新数据竞争。本节余下部分讨论在使用 QUIC 时的有关考虑。

QUIC 第 13.3 节 说明：“端点 SHOULD 优先重传数据而不是发送新数据，除非应用指定的优先级另有指示”。当 HTTP/3 应用使用本文档定义的优先级方案并且 QUIC 传输实现支持应用指示的流优先级时，一个在调度新数据和重传数据时考虑流的相对优先级的传输实现可能更符合应用的预期。然而，对于传输如何基于这些信息选择调度并没有要求，因为该决定取决于若干因素和权衡。传输可能会优先为高紧急度流发送新数据而不是为低优先级流重传数据，或者无论紧急度如何都优先重传数据。

QUIC-RECOVERY 第 6.2.4 节 还强调在探测超时（Probe Timeout）计时器到期后发送探测分组时关于应用优先级的考虑。支持应用指示优先级的 QUIC 实现可能会在选择探测数据时使用流的相对优先级。

通常，HTTP 实现依赖底层传输在竞争带宽的连接之间维持公平性。当中介在客户端连接上接收 HTTP 请求时，会将它们转发到后端连接。根据中介如何将请求合并或拆分到不同的后端连接，不同的客户端可能会体验到不同的性能。如果中介在转发请求时也使用优先级信号，这种差异可能会扩大。第 13.1 节 和 13.2 节 讨论了减缓此类不公平扩大的措施。

相反，第 13.3 节 讨论了服务器如何可能根据优先级信号有意地对某些连接分配不等的带宽。

与使用按跳（hop-by-hop）帧的 HTTP/2 优先级方案相反，Priority 头字段被定义为“端到端”。

客户端如何处理响应是与生成该请求的客户端相关的属性，而不是中介的属性。因此，这是一个端到端属性。由 Priority 头字段携带的这些端到端属性如何影响共享连接的响应之间的优先级，是一个按跳处理的问题。

将 Priority 头字段定义为端到端对缓存中介很重要。此类中介可以将 Priority 头字段的值与响应一同缓存，并在提供缓存响应时使用缓存的头字段值，之所以可以这样做，正是因为该头字段被定义为端到端而非按跳。

第 7 节 介绍了服务器对 PRIORITY_UPDATE 帧进行缓冲时的考虑事项。

第 10 节 给出了示例，说明以某种方式优先处理响应的服务器可能会陷入无法传输响应的饥饿状态。

来自 [STRUCTURED-FIELDS] 的安全性考虑适用于对 第 4 节 中定义的优先级参数的处理。

字段名:

Priority

状态:

permanent

参考:

本文件

代码:

0x9

名称:

SETTINGS_NO_RFC7540_PRIORITIES

初始值:

0

参考:

本文件

代码:

0x10

帧类型:

PRIORITY_UPDATE

参考:

本文件

值:

0xF0700-0xF0701

帧类型:

PRIORITY_UPDATE

状态:

permanent

参考:

本文件

变更控制者:

IETF

联系人:

ietf-http-wg@w3.org

IANA 已在 <https://www.iana.org/assignments/http-priority> 创建了“超文本传输协议（HTTP）优先级”注册表，并已使用 表 1 中的条目对其进行了填充；有关其相关程序，请参见 第 4.3.1 节。

Roy Fielding 在 <https://www.ietf.org/proceedings/83/slides/slides-83-httpbis-5.pdf> 提出了使用头字段表示优先级的想法。在 <https://github.com/pmeenan/http3-prioritization-proposal> 中， Patrick Meenan 主张使用紧急度和并发性的元组来表示优先级。禁用 HTTP/2 优先级的能力受 [PRIORITY-SETTING] 的启发，该草案由 Brad Lassey 和 Lucas Pardue 撰写，本文根据未并入该文档更新的反馈对其进行了修改。

定义替代 HTTP/2 优先级方案的动机来自广泛的 HTTP 社区讨论。特别感谢 Roberto Peon、Martin Thomson 和 Netflix 提供的已明确并入本文的文本。

除上述人员外，本文档还受益于 HTTP 优先级设计团队的广泛讨论，团队成员包括 Alan Frindell、Andrew Galloni、Craig Taylor、Ian Swett、Matthew Cox、Mike Bishop、Roberto Peon、Robin Marx、Roy Fielding 以及本文档的作者。

Yang Chi 为重传调度部分做出了贡献。