1. 引言 (Introduction)
HTTP [HTTP] 资源的表示 (representation) 通常会与一个或多个其他资源存在关系. 客户端常常在处理已获取的表示时发现这些关系, 这可能导致进一步的获取请求. 同时, 这些关系的性质决定了客户端是否会被阻塞, 从而无法继续处理本地已有的资源. 一个例子是 HTML 文档的视觉渲染, 它可能会被该文档引用的 Cascading Style Sheets (CSS) 文件的获取过程阻塞. 相比之下, 内联图片不会阻塞渲染, 并且会随着图片分块到达而逐步绘制.
HTTP/2 [HTTP/2] 和 HTTP/3 [HTTP/3] 支持在单个连接中对请求和响应进行多路复用 (multiplexing). 对于任何提供多路复用的协议实现而言, 一项重要能力是能够为信息发送确定优先级. 例如, 为了尽早呈现有意义的 HTML 文档内容, HTTP 服务器需要优先发送它传给客户端的 HTTP 响应, 或这些 HTTP 响应的分块.
HTTP/2 和 HTTP/3 服务器可以用其选择的任何方式调度并发响应数据的传输. 服务器可以忽略客户端优先级信号, 仍然成功提供 HTTP 响应. 然而, 如果服务器不了解客户端如何发出请求以及如何消费响应, 可能会导致客户端应用性能不佳. 优先级信号允许客户端传达它们对请求优先级的看法. 服务器也有独立于客户端需求的自身需求, 因此它们通常会将优先级信号与其他可用信息结合起来, 以指导响应数据的调度.
RFC 7540 [RFC7540] 流优先级 (stream priority) 允许客户端发送一系列优先级信号, 向服务器传达一个 "priority tree"; 该树的结构表示客户端偏好的 HTTP 响应之间的相对顺序以及带宽的加权分配. 服务器可以将这些优先级信号作为优先级决策的输入.
如 Section 2 所述, RFC 7540 流优先级的设计和实现被观察到存在缺陷. 因此, HTTP/2 [HTTP/2] 已弃用这些流优先级信号. 本文档定义的优先级方案和优先级信号可以作为 RFC 7540 流优先级的替代方案.
本文档描述了一种使用绝对值为 HTTP 响应确定优先级的可扩展方案. Section 4 定义优先级参数 (priority parameters), 这是优先级信息的一种标准化且可扩展的格式. Section 5 定义 Priority HTTP header field, 它是一种独立于协议版本的端到端优先级信号. 客户端可以发送该 header field 来表示它们认为响应应如何确定优先级. 类似地, 位于中介 (intermediary) 后方的服务器也可以用它向中介传达优先级. 客户端发送请求后, 可以通过发送 Sections 7.1 和 7.2 中定义的 HTTP 版本特定帧, 改变它对响应优先级的看法 (见 Section 6).
Header field 和帧中的优先级信号是服务器响应优先级处理过程的输入. 它们只是建议, 并不保证某个响应相对于其他响应具有任何特定的处理或传输顺序. Sections 10 和 12 提供了服务器如何基于这些信号采取行动的考虑事项和指导.
1.1. 表示约定 (Notational Conventions)
本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 和 "OPTIONAL", 当且仅当它们以这里所示的全大写形式出现时, 应按 BCP 14 [RFC2119] [RFC8174] 中的描述解释.
本文档使用 [STRUCTURED-FIELDS] 的 Section 3 中的下列术语来规定语法和解析: "Boolean", "Dictionary", 和 "Integer".
HTTP 请求和响应示例使用 [HTTP/2] 中的 HTTP/2 风格格式.
本文档使用 [QUIC] 中的可变长度整数编码.
术语 "control stream" 同时用于描述标识符为 0x0 的 HTTP/2 stream 和 HTTP/3 control stream; 见 [HTTP/3] 的 Section 6.2.1.
术语 "HTTP/2 priority signal" 用于描述在 HTTP/2 frame 中从客户端发送到服务器的优先级信息; 见 [HTTP/2] 的 Section 5.3.2.