要約

  • RFC 9218のHTTP優先度はスケジューリングへの一つの入力であり提案にすぎず、処理・送信・完了の順序を保証しない。
  • 実効性を示す記録は、各ホップのシグナルを、統合方針、スケジューラ状態、バイト配分、時刻、利用者側の結果まで結ばなければならない。

共有エッジがページ、重要なスタイルシート、複数の画像を同時に配信する場面を考える。ブラウザはスタイルシートに u=0 を付ける。ダッシュボードはそのフィールドを見て、重要資源が保護されたと判定する。しかしエッジはオリジンからの応答側シグナルを統合し、ローカルな公平性と容量の規則も適用する。小さな画像が先に完了し、スタイルシートはオリジン処理を待つ。フィールドは残っていても、想定した順序の証明にはならない。

これは分析用の仮想事例であり、特定事業者の障害報告ではない。クライアントの希望、中継者の処理、オリジンの判断、最終スケジューラの動作を分けるための例だ。四者は関係していても、同じ事実ではない。

RFC 9218 はHTTP応答向けの拡張可能な優先度方式を定める。Priority フィールドはエンドツーエンドのシグナルである。一方、HTTP/2とHTTP/3の PRIORITY_UPDATE は初期または更新後の値を一ホップだけ運ぶ。ブラウザの記録だけでは、最後のスケジューラに何が届いたかを示せない。

基本パラメータは意図的に簡潔だ。緊急度 u は0から7で、小さいほど優先度が高く、既定値は3である。増分性 i は、応答の一部が届くだけでも有用な出力を作れるかを示し、既定値は偽である。これは端点の見方を表す語彙であって、普遍的な待ち行列や帯域配分、完了順のアルゴリズムではない。

規格は境界を明記する。シグナルは提案にすぎず、応答間の特定の処理順や送信順を保証しない。サーバの判断には実装、配置環境、物体の大きさ、キャッシュ、オリジンの準備状況、輻輳、多重化が影響する。緊急度を尊重していても、小さな低優先応答が大きな高優先応答より先に完了することはある。

したがって完了順だけを見るのは危険だ。高優先の大きな応答が多くの帯域を受けても、小さな応答より後に終わり得る。増分応答は、途中の断片に価値があるため同じ緊急度の応答と容量を共有する場合がある。最初のバイト、有用な最初のバイト、転送完了、画面描画は別々の成果である。

要求後に優先度が変わることもある。背景プリフェッチだったスクリプトが、画面遷移により急に重要になる場合、クライアントは PRIORITY_UPDATE を送る。このフレームは現在のパラメータ一式を運び、対象ストリームの開始と競合し得る。証拠には要求・応答フィールド、更新フレーム、受信順、実際に利用したスケジューラの時点を残す必要がある。

中継者はさらに境界を増やす。クライアントの要求優先度とオリジンの応答優先度を統合でき、その方針は実装に委ねられる。複数クライアントを一つのバックエンド接続に集約する場合、全ての自己申告 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のスケジューリングに関する希望が、それに帰属された配信動作を本当に生んだかである。

出典