長い間、ブラウザは Web ページからアセットを取得するために、ホストごとに最大 6 つの同時 HTTP 1.1 接続を使用してきました。この黄金律を (はるかに) 超えると、DOS とみなされ、サーバーから追放されます。
現在は HTTP/2 があり、単一の接続で多数の HTTP リクエストを多重化できます。サーバーの過負荷を防ぐために、接続で多重化する同時リクエストの数に同様の制限を適用する必要がありますか? それとも、単一の接続でさらに多くのリクエストを多重化しても問題はありませんか?
ブラウザが HTTP/2 サーバーに対してホストごと、接続ごとにどのような制限を使用するか知っている人はいますか?
ベストアンサー1
クライアントとサーバーが開始できるストリームの数は無制限ではなく、各ピアが接続の開始時に送信するフレームSETTINGS_MAX_CONCURRENT_STREAMSのパラメータによって決まります。SETTINGSRFC 7540 のセクション 6.5.2デフォルトは無制限であり、RFC では次の推奨事項が示されています。
並列処理を不必要に制限しないように、この値は 100 以上にすることをお勧めします。
ただし、HTTP/2 での並列処理を検討する場合、ストリームの数は考慮すべき唯一のパラメータではありません。重みとストリームの依存関係も影響します。
各ストリームには重みが与えられ、RFC ではサーバーが重みに基づいてストリームにリソースを割り当てることを推奨しています。クライアント側では、Firefox は画像よりも CSS に高い重みを割り当てます。各ブラウザがストリームをどのように優先順位付けして整理するかの詳細については、この素晴らしいプレゼンテーションをご覧ください。Chrome は依存関係を使用するため、最も重要な要素 (CSS、HTML) は依存関係チェーン内で他の要素よりも上位になります。このツールを見るこれはChromeが生成する依存関係ツリーを示しています。サーバー側では、H2O、新しい高速HTTPサーバーは、依存関係と重みに基づいてストリームをクライアントに送信するために、接続ごとに O(1) スケジューラを実装します。つまり、デフォルトの依存関係を持つ 500 個の要素を要求した場合、各ストリームはサーバー リソースの 1/500 を取得します。
できるだけ多くの要素を要求することには、（通常のウェブ閲覧の場合）何のデメリットもないはずです。HTTPアーカイブ、ページの 40% には 100 を超える要素が含まれており、ストリーム数が 未満であれば、それらすべてを同時に要求するのが妥当であると考えられますSETTINGS_MAX_CONCURRENT_STREAMS。重要なのは、ブラウザが可能な限り高速にレンダリングできる順序でそれらを要求できることだと私は考えています。