プロンプトと適用性
あるページが HTML、クリティカル CSS、フォント、画像、バックグラウンドデータを同時にリクエストします。モバイル帯域幅は限られています。チームは HTTP Priority を使用してクリティカルなリソースをより早く完了させたいと考えていますが、プロキシによる上書き、飢餓状態、アプリケーションのスケジューリングをバイパスするキャッシュヒット、パケットロスによる再送が順序を変更することを懸念しています。HTTP/1.1、HTTP/2、HTTP/3 を網羅するサーバーおよびプロキシのスケジューリングを、検証を含めて設計してください。
RFC 9218 は、バージョンに依存しない Priority ヘッダーと、HTTP/2 および HTTP/3 向けの再優先順位付けフレームを定義しています。これは配信 SLA ではなく、優先傾向（プリファレンス）を伝達するものです。優れた回答では、シグナル、スケジューラ、キャッシュ、トランスポートを分離し、各レイヤーが何を拒否または書き換えできるかを明示します。
面接官がテストしていること
- urgency が 0 から 7 の範囲であり、値が小さいほど緊急度が高く、リクエストのデフォルト値が 3 であることを理解しているか。
- 同一 urgency を持つリソースに対して、incremental が同時実行性と完了時間にどのように影響するかを説明できるか。
- HTTP/1.1 のリクエスト順序制御と、HTTP/2 および HTTP/3 における多重化スケジューリングの違いを区別できるか。
- Priority を SLA ではなくヒントとして扱い、悪意のある、または不正確なクライアント宣言に対処できるか。
- キャッシュヒット、プロキシでの再優先順位付け、QUIC の再送、公平性、およびコネクション間の競合を考慮できるか。
- ユーザー体験と公平性のメトリクスを備えた、ロールバック可能なロールアウトを設計できるか。
最初に確認すべき明確化の質問
- 目標は LCP の短縮、特定 API のテールレイテンシ削減、それともバックグラウンドスループットの向上ですか？それぞれによってポリシーとメトリクスが変わります。
- リソースは同一コネクション、同一 CDN ノード、同一キャッシュキー上にありますか？単一コネクションの優先度は、コネクション間で直接比較することはできません。
- どのリソースがインクリメンタルに処理可能ですか？完全な CSS、フォント、チャンクごとに消費できない圧縮オブジェクトは、単に緊急度が高いという理由だけで分割すべきではありません。
- プロキシはリクエスト/レスポンスヘッダーおよび PRIORITY_UPDATE を転送しますか？すべてのホップで HTTP/2 または HTTP/3 が使用されていますか？
- 低価値なリクエストが最高優先度を要求するのを防ぐテナント、ユーザー、またはセキュリティ境界は存在しますか？
30秒での回答
私は目標をユーザーに見える完了時間として定義し、デフォルト値を用いてリソースを分類します。クライアントの Priority ヘッダーは入力の1つであり、サーバーはリソースタイプ、キャッシュ状態、コネクション、公平性に基づいてこれを再計算します。0 から 7 の urgency は相対的な順序を提供し、incremental はバイトが到着するにつれて順次消費できるレスポンスに使用します。HTTP/1.1 はコネクションのリクエスト順序に依存し、HTTP/2 と HTTP/3 はスケジューラ、およびサポートされている場合は再優先順位付けフレームを使用します。キャッシュヒット、再送、コネクション間の帯域幅は個別に処理する必要があります。カナリアリリースでは LCP、クリティカルリソースの完了、バックグラウンドのテールレイテンシ、飢餓状態、帯域幅を追跡し、ガードレールに抵触した場合は書き換えを無効化します。
ステップごとの詳細解説
1. プロダクトの目標をスケジューリングの目標に変換する
HTML、レンダリングブロック CSS、クリティカルフォントは早期に完了させる必要があります。大きな画像は緊急度を下げることができ、アナリティクスやプリフェッチがクリティカルパスと競合してはなりません。バックグラウンド API にも最大待機時間が必要です。「クリティカルなリクエストを優先する」と述べるだけでなく、各クラスに待機時間の上限と帯域幅の割り当てを設定します。
2. 2つの Priority パラメータを説明する
u は緊急度を表します。0 が最も高く 7 が最も低く、リクエストのデフォルト値は 3 です。i は、レスポンスをインクリメンタルに処理できることを示します。i を使用すると、サーバーは同一緊急度のリソース間で帯域幅を分割できるため、すべてのリソースの開始は早くなりますが、各リソースの完了時間は遅くなる可能性があります。これが指定されていない場合、分割して消費できないオブジェクトに対しては通常、順次配信（シーケンシャル）の方が適しています。
GET /style.css HTTP/1.1
Host: example.test
Priority: u=1
GET /hero.jpg HTTP/1.1
Host: example.test
Priority: u=4, iサーバーのレスポンスからも、ダウンストリームの中継ノードに対して優先度ヒントを送信できます。レスポンスヘッダーを省略することは、サーバーがクライアントの優先度を変更しなかったことを意味します。未知のパラメータは無視すべきであり、クライアントの値は認可や課金の証明情報ではありません。
3. プロトコルバージョンごとの境界を選択する
HTTP/1.1 には組み込みの多重化優先順位付けがありません。サーバーの動作は主にコネクションの順序、コネクションの同時実行数、およびキューに従います。HTTP/2 と HTTP/3 は単一の多重化コネクション上で帯域幅を共有するため、スケジューラは urgency と incremental を使用して次のデータセグメントを選択できます。どちらも PRIORITY_UPDATE メカニズムを使用して既存リクエストの優先傾向を変更できますが、実装において即時または厳密な実行が保証されているわけではありません。
4. キャッシュとプロキシを処理する
キャッシュヒットは、オリジンのアプリケーションスケジューリングに到達することなく返される場合があります。優先度の影響は送信フェーズおよびキャッシュ充填フェーズに留めてください。通常の Priority ヘッダーによってオブジェクトの認可が変更されたり、暗黙のうちにキャッシュキーになったりしてはなりません。プロキシはクライアントコネクションを集約したり、異なるバックエンドコネクションを使用したり、レスポンスの優先度を書き換えたりできます。各境界で元の値、最終的な値、およびその理由を記録します。キャッシュの動作は、引き続き Cache-Control や Vary などのフィールドによって制御されます。
5. 再送と公平性を処理する
QUIC と TCP は失われたデータを再送します。高緊急度の新規オブジェクトが、低緊急度の再送よりも常に自動的に優先されるべきではありません。再送によって既に進行中のレスポンスのブロックが解除される可能性があるためです。RFC 9218 はこのトレードオフをトランスポートおよびアプリケーションのポリシーに委ねています。コネクション間において、単一コネクション上の u=0 がグローバルで最大の帯域幅を保証することはできません。バックグラウンド処理が永久に飢餓状態にならないよう、コネクションごとのクォータ、エージング、および連続送信バジェットの上限を追加します。
6. 優先度の乱用と伝播エラーを防止する
クライアントはすべてのリクエストに u=0 を付与する可能性があるため、サーバーはリソースのアローリスト、認証済みアイデンティティ、ページフェーズ、および履歴を使用してこれを補正する必要があります。最大緊急度に上限を設け、テナントクォータを適用し、未知のリソースにはデフォルト値にフォールバックし、オーバーライドを記録します。プロキシ間では、文字列を盲目的にコピーするのではなく意味を維持します。シグナルを認識しないホップは、レスポンスの正確性を変えることなく安全にシグナルを無視すべきです。
7. カナリアリリース、フォールバック、受け入れ基準
固定されたページと低リスクの CDN ノードから開始し、一部のコネクションに対してサーバーによる書き換えを有効にします。同一のネットワーク、デバイス、キャッシュ状態、リソースセットで比較を行います。LCP、クリティカル CSS の完了時間、フォントブロック時間、バックグラウンドの p95 および p99、TTFB（First Byte までの時間）、重複ダウンロード、コネクション使用率、および低優先度の最大待機時間を測定します。改善効果は、エラー、帯域幅コスト、テナント間の公平性と比較検討する必要があります。スケジューラの動作が異常な場合は、直ちにデフォルトの優先度に戻します。
質の高い模範解答
ファーストペイントの完了とバックグラウンドリクエストの目標を定義し、HTML、レンダリングブロック CSS、フォント、インクリメンタルメディア、バックグラウンドデータを分類します。クライアントの Priority ヘッダーは単なるヒントに過ぎません。リソースのアローリスト、ページフェーズ、キャッシュ状態、テナントクォータを使用してこれを補正します。デフォルトとして urgency 3 を使用し、クリティカルリソースには値を下げ、バックグラウンド処理には値を上げ、コンシューマが部分データを処理できる場合にのみ incremental を使用します。
HTTP/1.1 は主にコネクションとキューの順序に依存します。HTTP/2 と HTTP/3 は多重化スケジューラと任意の再優先順位付けフレームを使用します。キャッシュヒットによって認可やキャッシュキーが変更されてはならず、プロキシは元の優先度と最終的な優先度を記録すべきです。再送が新規データに対して自動的に劣後してはならないため、コネクションクォータ、エージング、連続送信上限を追加します。カナリアリリースでは LCP、クリティカル完了、バックグラウンドのテール、帯域幅、低優先度の待機時間を比較し、ガードレールが悪化した場合はサーバーの書き換えを無効化します。
よくある間違い
Priority: u=0を完了 SLA として扱うこと → 輻輳、キャッシュ状態、再送が依然として影響するため、測定可能な目標を持つスケジューラ入力として使用する必要があります。incrementalを「より早く完了する」と解釈すること → 帯域幅を共有すると個々のオブジェクトの完了が遅れる可能性があるため、部分的な消費に価値がある場合にのみ使用します。- クライアントの優先度によってキャッシュキーや認可を変更させること → キャッシュの断片化や権限のエラーにつながるため、キャッシュと権限の契約は独立して保ちます。
- 1つの HTTP/2 コネクションのみを分析すること → コネクション間の競合によって結果が逆転する可能性があるため、コネクション、ノード、ネットワーク、テナントごとに検証をスライスします。
- 高優先度の再送を常に他のデータより優先させること → 新しいレスポンスやバックグラウンドストリームが飢餓状態になる可能性があるため、再送ポリシー、クォータ、エージングを含めます。
- LCP のみを確認すること → バックグラウンドのテールレイテンシや帯域幅コストが悪化する可能性があるため、ユーザー体験、信頼性、公平性、コストのガードレールを合わせて設定します。
フォローアップ質問と回答
すべてのクライアントが u=0 を送信してきたらどうしますか？
信頼できないヒントとして扱います。リソースタイプ、ページフェーズ、認証済みアイデンティティ、テナントクォータを使用して再計算し、異常または未知のリクエストをデフォルトに戻し、オーバーライドされた理由を記録します。
incremental は常に体験を向上させますか？
いいえ。同一緊急度のレスポンス間で帯域幅を共有するため、複数のリソースの開始は早くなりますが、各リソースの完了は遅くなる可能性があります。コンシューマが部分的なバイトを処理でき、その開始時間の短縮によるメリットがある場合に使用します。
キャッシュヒットに対して Priority は必要ですか？
キャッシュヒットは通常、オリジンのアプリケーションキューをバイパスしますが、プロキシがコネクション上の送信をスケジューリングすることは依然としてあり得ます。Priority が認可に入り込んだり、キャッシュキーを勝手に変更したりしてはなりません。ヒット、充填、送信の各ステージを個別に監視します。
パケットロス後、再送と高緊急度の新規データのどちらを優先すべきですか？
コンテキストに依存しない唯一の答えはありません。再送によって進行中のレスポンスのブロックが解除される場合もあれば、新しいデータの方がユーザーにとって重要な場合もあります。ストリームの依存関係、インクリメンタル処理の可否、輻輳状態、および測定可能な体験目標を組み合わせて判断します。
HTTP/1.1 で同じ優先順位付けを実装できますか？
HTTP/2 のような多重化優先度ツリーがありません。サーバーキュー、コネクションの同時実行性、リソースの順序付けによってポリシーを近似することはできますが、それは依然として実装戦略にとどまり、Head-of-Line ブロッキングやコネクション競合についてテストする必要があります。
低優先度の処理が飢餓状態になっていないことをどのように証明しますか？
すべてのリクエストについてキュー時間と最初の送信時間を記録し、リソース、コネクション、テナントごとに最大待機時間と p99 を計算します。高緊急度の負荷が持続する状況下でも、エージング、クォータ、またはデッドラインによって低優先度の処理が確実にサービスを受けられていることを検証します。