如何解释 HTTP 请求优先级与 RFC 9218？
题目与使用场景
面试官要求你解释浏览器如何表达资源优先级、服务器和中间代理如何执行，以及为什么设置了优先级仍不能保证某个请求先完成。回答应覆盖 RFC 9218 的 Priority 头、urgency 与 incremental，并说明它与旧 HTTP/2 依赖树和权重模型的关系。
面试官考察什么
- 能否区分“优先级偏好”和服务等级承诺。
- 是否理解客户端、源站、中间代理和 CDN 的责任边界。
- 能否把调度、公平性、带宽竞争和用户体验指标联系起来。
- 是否知道 RFC 7540 的优先级信号已被 RFC 9113 标记为弃用，RFC 9218 提供了可扩展方案。
作答前的澄清问题
先确认协议版本、浏览器或 SDK、是否经过 CDN、资源类型、缓存命中率和目标指标。还要问优先级是客户端提示，还是服务端要向下游重新表达调度决定；两者会影响排查路径。
30 秒回答框架
RFC 9218 定义了可扩展的 HTTP 优先级方案。请求或响应的 Priority 头可表达 urgency=0 到 7 以及是否采用增量发送；数值越小通常越紧急。它是调度输入，不是 SLA，服务器或代理可以重排、合并、延迟或忽略。HTTP/2 早期的依赖树和权重模型已被新规范弃用，因此我会用真实浏览器、源站和 CDN 的网络瀑布验证最终效果。
分步骤深入解答
1. 头部表达什么
urgency 给出相对紧急程度，incremental 表示响应是否适合分段交付。示例：
Priority: u=1, i这表示较高紧急度并允许增量发送，但不规定必须抢占所有其他流量。
2. 谁来执行
客户端可以在请求中提供偏好；服务器可在响应中更新下游看到的优先级。源站、反向代理和 CDN 都可以按连接数、队列、缓存状态、带宽和公平性重新调度。协议只定义信号和语义，不强制每一跳采用同一算法。
3. 为什么需要公平性
若始终服务最高紧急度，低优先级下载可能饥饿。调度器通常需要有限并发、配额、老化或轮转策略；增量响应还要在首字节及时性和整段完成时间之间取舍。
高质量示范回答
我会把 RFC 9218 看作跨 HTTP 实现的调度提示层。客户端根据渲染或业务目标给出紧急度和增量偏好，服务器及代理结合自身队列、缓存和带宽做最终决定。Priority 不是“先完成”保证，也不能绕过拥塞控制或连接复用。HTTP/2 的依赖和权重模型在 RFC 9113 中已弃用，因此不能只调旧树结构来推断现代结果。排障时我会固定缓存命中和网络条件，分别观察浏览器到 CDN、CDN 到源站的请求头、队列和瀑布，再用 LCP、INP、尾延迟和低带宽场景验证是否改善；若中间层不转发或覆盖头部，就应调整它的配置或接受该边界。
常见错误
- 把
urgency=0说成绝对最高优先级或硬性抢占。 - 断言所有浏览器、服务器和 CDN 都实现同一调度算法。
- 将 RFC 7540 的依赖树当作 RFC 9218 的必需配置。
- 只测本地延迟，不区分缓存命中、带宽竞争和中间层覆盖。
- 只看首字节时间，忽略增量响应对完整下载和公平性的影响。
追问及应对
如果代理不支持 Priority 头怎么办？
把它当作能力探测结果，保留安全的默认队列；同时检查是否能通过代理配置、资源拆分或连接并发限制改善关键路径，不把客户端提示当成已生效的证据。
如何证明优先级真的改善了体验？
在相同协议、缓存、带宽和请求集合下做对照，采集网络瀑布、各跳头部、LCP、INP、首字节和完整响应尾延迟，并覆盖冷缓存和低带宽场景。
fetchpriority 与 Priority 头是什么关系？
fetchpriority 是页面 API 对资源获取偏好的表达；实现可能把它映射为请求优先级，但最终仍由浏览器、服务器和中间层调度。验证时要观察实际发出的头部和网络行为，不能只看 DOM 属性。