如何解釋 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 屬性。