10. Server Scheduling (サーバースケジューリング)

HTTPサーバーにとって、すべてのレスポンスをできるだけ早く送信することは一般的に有益です。しかし、単一の接続で複数のリクエストを処理する場合、接続帯域幅などのリソースをめぐってリクエスト間で競合が発生する可能性があります。このセクションでは、このような競合が存在する場合に、サーバーが競合するレスポンスの送信順序をスケジュールする方法についての考慮事項について説明します。

サーバースケジューリングは、多くの入力に基づく優先順位付けプロセスです。優先度シグナルは入力の1つの形式にすぎません。実装の選択やデプロイメント環境などの要因も役割を果たします。任意の接続には多くの動的な並べ替えがある可能性があります。これらの理由により、普遍的なスケジューリングアルゴリズムを記述することはできません。このドキュメントは、サーバーが優先度パラメータに対してどのように行動するかについての基本的な、網羅的ではない推奨事項を提供します。サーバーが優先度シグナルを他の要因とどのように組み合わせるかについては詳しく説明していません。エンドポイントは、優先度シグナルに基づく特定の処理に依存できません。優先度を表現することは単なる提案です。

可能な場合、サーバーはurgencyパラメータ（第4.1節）を尊重し、低緊急度レスポンスの前に高緊急度レスポンスを送信することが推奨されます (RECOMMENDED)。

incrementalパラメータは、クライアントが到着したレスポンスバイトをどのように処理するかを示します。可能な場合、サーバーはincrementalパラメータ（第4.2節）を尊重することが推奨されます (RECOMMENDED)。

同じ緊急度の非増分レスポンスは、ストリームID昇順で帯域幅を割り当てることで提供されるべきです (SHOULD)。これは、クライアントがリクエストを行った順序に対応します。これにより、クライアントはリクエスト順序を使用してレスポンス順序に影響を与えることができます。

同じ緊急度の増分レスポンスは、それらの間で帯域幅を共有することで提供されるべきです (SHOULD)。増分レスポンスのメッセージ内容は、部分またはチャンクで受信されたときに使用されます。クライアントは、単一のリソースの全体ではなく、すべてのリソースの一部を受信することから利益を得る可能性があります。パフォーマンスを向上させるために必要なリソース部分のサイズはさまざまです。一部のリソースタイプは重要な要素を前に配置します。他のリソースは段階的に情報を使用できます。このスキームは、サーバーがサイズ、タイプ、またはその他の入力をどのように使用して優先順位付けの方法を決定すべきかを明示的に指定していません。

サーバーが同じ緊急度レベルで複数の増分および非増分レスポンスをスケジュールする必要があるシナリオが存在する可能性があります。緊急度とリクエスト生成順序に基づくスケジューリングガイダンスを厳密に遵守すると、早期の非増分レスポンスが後で発行された増分レスポンスの提供をブロックする可能性があるため、クライアントにとって次善の結果になる可能性があります。このような課題の例を以下に示します：

1. 同じ緊急度レベルで、大きなリソースに対する非増分リクエストの後に、小さなリソースに対する増分リクエストが続く。

2. 同じ緊急度レベルで、不確定な長さの増分リクエストの後に、非増分の大きなリソースが続く。

可能な場合、サーバーはこのような飢餓を回避することが推奨されます (RECOMMENDED)。これを行う手段は実装の決定です。たとえば、サーバーは、コンテンツサイズなどの他の情報に基づいて、特定の増分タイプのレスポンスを先制的に送信する可能性があります。

サーバープッシュの最適なスケジューリングは困難です。特に、プッシュされたリソースがアクティブな同時リクエストと競合する場合です。サーバーがスケジューリング時に考慮できる要因は多数あります。たとえば、プッシュされるリソースのタイプまたはサイズ、プッシュをトリガーしたリクエストの優先度、アクティブな同時レスポンスの数、他のアクティブな同時レスポンスの優先度などです。これらを適用する最善の方法についての一般的なガイダンスはありません。過度に単純なサーバーは、高すぎる優先度でプッシュしてクライアントリクエストをブロックするか、低すぎる優先度でプッシュしてレスポンスを遅延させ、サーバープッシュの意図された目標を無効にする可能性があります。

優先度シグナルは、サーバープッシュスケジューリングの1つの要因です。明示的なクライアントシグナルがないため、パラメータ値のデフォルトの概念はやや異なる形で適用されます。サーバーは、オリジンレスポンスで提供される優先度シグナルを適用できます。第8節で示された統合ガイダンスを参照してください。オリジンシグナルがない場合、デフォルトのパラメータ値を適用することは次善である可能性があります。サーバーがプッシュされたレスポンスをスケジュールする方法について何を決定しても、PUSH_PROMISEまたはHEADERSフレームにPriorityフィールドを含めることで、期待される優先度をクライアントに通知できます。

10.1. Intermediaries with Multiple Backend Connections (複数のバックエンド接続を持つ中継装置)

HTTP接続を提供する中継装置は、複数のバックエンド接続にリクエストを分散する可能性があります。優先順位付けルールを厳密に適用すると、より高い優先度のリクエストが進行中の間、低優先度のリクエストは進行できません。このブロックはバックエンド接続に伝播する可能性があり、ピアはこれを接続の停滞として解釈する可能性があります。エンドポイントは通常、一定期間後に突然接続を閉じるなど、停滞に対する保護を実装します。これが発生する可能性を減らすために、中継装置は優先順位付けを厳密に従うことを避け、代わりに転送するすべてのリクエストに少量の帯域幅を割り当てることで、それぞれが時間の経過とともにある程度の進歩を遂げることができるようにします。

同様に、サーバーは、トンネルとして機能するストリームに一定量の帯域幅を割り当てるべきです (SHOULD)。

---