摘要

  • RFC 9218 把 HTTP 优先级定义为调度输入之一和一种建议，并不保证处理、传输或完成顺序。
  • 可靠的上线记录必须把每一跳收到的信号，与合并规则、调度器状态、字节分配、时间指标和用户可见结果关联起来。

设想一个共享边缘节点同时交付页面、关键样式表和数张图片。浏览器给样式表标记 u=0，仪表盘看到字段后便宣布关键资源已获优先保护。但边缘节点还要合并源站返回的优先级信息，并执行本地公平性和容量规则。一张较小、优先级较低的图片先完成，样式表仍在等待源站处理。字段确实存在，却没有证明仪表盘声称的顺序。

这是用于分析的假设场景，并非对某家服务商事故的报道。它迫使我们区分四个事实：客户端表达的偏好、中间节点如何处理该偏好、源站表达的判断，以及调度器最终采取的动作。它们相互关联，但不能彼此替代。

RFC 9218 定义了可扩展的 HTTP 响应优先级机制。Priority 字段是端到端信号；HTTP/2 与 HTTP/3 的 PRIORITY_UPDATE 帧则在单跳内携带初始或更新后的优先级。浏览器侧抓到字段，并不能证明最终上游调度器收到了什么帧、使用了什么值。

基础参数刻意保持简洁。紧迫度 u 的范围是 0 到 7，数值越小优先程度越高，默认值为 3。增量参数 i 表示响应片段到达时能否立即产生有用输出，默认值为假。这些参数描述端点的看法，不是统一的排队、带宽分配或完成顺序算法。

标准明确给出边界：优先级信号只是建议，不保证任意两项响应之间的特定处理或传输顺序。服务器调度还要考虑实现方式、部署环境、对象大小、缓存状态、源站是否就绪、拥塞和复用情况。即使服务器确实照顾高紧迫度资源，体积较小的低紧迫度响应仍可能先完成。

因此，只看完成顺序尤其容易误判。较大的高优先级响应可能已获得更多带宽，却仍晚于小对象结束。增量响应可能与同级资源共享容量，因为先到的一部分字节就有价值。首字节、首个有用字节、传输完成和页面渲染，是四种不同结果，不能被压缩成一个绿色指标。

优先级还会在请求发出后改变。浏览器可能先以后台紧迫度预取脚本，用户导航后再提升其优先级。PRIORITY_UPDATE 帧携带当前完整参数集，并可能与相关流的建立发生竞态。因此证据必须保留顺序：请求与响应字段、每个更新帧、接收时刻，以及实际使用该信息的调度器快照。

中间节点又增加了一道边界。它可以把客户端请求中的优先级与源站响应中的优先级合并，而 RFC 9218 将具体合并策略留给实现决定。当多个客户端请求被汇聚到同一个后端连接时，绝对服从每一个自报的 u=0 会让其他用户受阻。本地公平性规则可能限制优先待遇，这仍然合理，却会打破根据原始字段作出的简单预测。

RFC 9113 记录了 RFC 7540 的旧 HTTP/2 优先级机制并未得到一致实现，现已被弃用；在确有优先级信号需求时，可采用 RFC 9218 等替代机制。因此，一份只写“HTTP/2 priority”的抓包说明并不充分，还要指出使用的机制、协商设置和实现行为。

有用的“优先级效果收据”应连接七类材料：请求与响应身份、准确的 Priority 值、每个 PRIORITY_UPDATE 的所在跳与到达顺序、中间节点的合并结果、调度策略及并发工作、随时间变化的字节分配，以及首字节、有用字节、完成和渲染时间。缓存、对象大小、源站就绪状态和连接共享情况也必须保留。这是编辑上的运行证据设计，不是 IETF 定义的协议对象。

R066 因而与相邻主题保持分离。BGP Add-Path 关注多条路由是否真正跨越独立故障域；RFC 8097 关注源验证状态的来源与解释；R065 关注同一连接上各源的证书权限。这里的问题更窄：一项 HTTP 调度建议，是否真的产生了被归因于它的交付行为？

来源