HTTP 1.1 と HTTP 2.0 の違いを以下に示します:
従来の HTTP の動作では、同一接続で複数のリクエストを行う場合、クライアントは次を送信する前に各リクエストのレスポンスを待つ必要がありました。この逐次的なアプローチはウェブサイトのリソースのロード時間を大幅に増加させます。この問題に対処するため、HTTP/1.1 ではパイプラインと呼ばれる機能が導入され、クライアントはサーバーのレスポンスを待たずに複数のリクエストを送信できるようになりました。サーバーはクライアントに受信した順序でレスポンスします。
パイプライン化は解決策のように見えましたが、いくつかの課題がありました:
HTTP/1.1 をサポートするサーバーからのページロードを最適化するために、ウェブブラウザは回避策を実装しました。サーバーへの6〜8本の並列接続を開き、複数のリクエストの同時送信を可能にします。この並列性はパイプラインに関連する問題を軽減し、全体的なページロード時間を改善することを目的としています。
ウェブブラウザーが 6 から 8 の並列接続を選択する理由は最適化の考慮に基づいています。この数値を選択した具体的な理由には、リソース使用率、ネットワーク効率、および潜在的なボトルネックの回避のトレードオフが含まれる場合があります。
パイプライン処理の制約に対応するため、HTTP/2 はマルチプレキシングと呼ばれる機能を導入しました。マルチプレキシングは、単一の接続上で複数のリクエストとレスポンスを同時に送信することを可能にし、クライアントとサーバー間のより効率的な通信を実現します。
HTTP/2 はバイナリフレーミングメカニズムを使用しています。これは HTTP メッセージがフレームと呼ばれる小さな独立した単位に分解されることを意味します。これらのフレームはインターリーブでき、互いに独立して接続上で送信できます。受信側では、フレームが再組み立てされて元の HTTP メッセージが再構成されます。
このバイナリフレーミングメカニズムは HTTP/2 での多重化を実現するための基本要素です。ブラウザが同じ接続で複数のリクエストをブロッキングなしに送信できるようにします。その結果、Chrome などのブラウザは HTTP/2 リクエストに同じ接続 ID を使用し、クライアントとサーバー間の効率的で途切れのない通信を実現します。
本質的に、バイナリフレーミングメカニズムによって実現された HTTP/2 の多重化機能は、単一の接続を通じた複数のリクエストとレスポンスの同時伝送を促進することで、クライアントとサーバー間のデータ交換の効率と速度を向上させます。
HTTP/2 プロトコルのパフォーマンスを向上させるために、サーバーが新しい HTTP/2 リクエストを受信するたびに、リクエストはデフォルトでスレッドプール (デフォルトで 32) でディスパッチされます。これにより、単一の接続が多数の並行リクエストを送信し、このスレッドプールがない場合は (接続スレッドのコンテキストで) 順次処理が必要になるような状況での待機を回避します。
スレッドプールの動作は、以下のプロパティで設定できます。
リクエストを微調整して、時間のかかるリクエストをスレッドプールで処理し、その他は接続スレッドで処理するように選択するには、OnHttp2BeforeAsyncRequest イベントを使用します。このイベントはスレッドプールにリクエストをキューイングする前に発生します。Async パラメータを使用してリクエストをスレッド化するかどうかを設定します。
procedure OnHTTP2BeforeAsyncRequest(Sender: TObject; Connection: TsgcWSConnection; const ARequestInfo: TIdHTTPRequestInfo; var Async: Boolean);
begin
if ARequestInfo.Document = '/fast-request' then
ASync := False;
end;