HTTPを悩ませたHead Of Line Blocking問題

前回の話にあった通り、インターネットの世界はHTTPを中心に回っていましたが、HTTPにはいくつかの問題がありました。その問題のうちの大きな一つがHead Of Line Blockingの問題でした。

今回はこの問題を掘り下げて説明させていただきます。

Head of Line Blocking（HOLブロッキング）は、HTTPプロトコルに関連する問題の1つです。HTTPは、TCPプロトコル上に構築されたプロトコルであるため、HTTPのセッションが開始されたら、HTTPリクエストはTCPコネクション上で直列化され、順番に処理されます。この時にある特定のリクエストの応答が受け取れずにいる場合、このリクエストが応答を受け取るまで、後続のリクエストは応答があるにも関わらずブロックされます。

このHOLブロッキングの問題は、HTTPのパフォーマンスに大きな影響を与えることがあります。たとえば、Webページのロード中に、大きな画像を要求するHTTPリクエストが前にある場合、それよりも簡単なタスク（たとえば、CSSやJavaScriptファイルの読み込み）が後続していても、先に処理される必要があります。これにより、ブラウザはリソースのダウンロードに時間がかかり、Webページ全体の読み込み速度が遅くなります。

この問題を解決するため、HTTP/2プロトコルでは、マルチプレックス化とストリーム優先度の機能が追加されました。マルチプレックス化により、TCP接続上で同時に複数のHTTPリクエスト/レスポンスの交換が可能になり、HOLブロッキングが軽減されます。ストリーム優先度により、リクエストの重要度に応じて、レスポンスを受け取るための優先度を設定することができます。

ただし、HOLブロッキングはTCP自体の問題です。あるTCPリクエストへの応答が欠落した状態で、以降のTCPリクエストへの応答が届いていたとしても、HTTPに限らずその通信の処理は進みません。このためHTTP/2であっても、サーバはHTTPリクエストへの応答を独立して処理できますが、TCPリクエストの応答がどこか一部でも落ちてしまうと、TCP全体の処理がとまってしまうという問題があります。

このためTCPの枠組みで対処することは難しく、根本的な解決に関しては、TCPを捨てUDPベースで開発されたQUICプロトコルが採用されたHTTP/3まで待つ必要がありました。

次のコラムを読む

目次に戻る