【入門編】HTTP/1.1パイプライニングの仕様とHOLブロッキング問題 – HTTPプロトコル・通信規格実践ガイド

なぜWebサイトの表示は「渋滞」するのか？HTTP/1.1 パイプライニングとHOLブロッキングの正体

こんにちは！インフラエンジニアとして日々ネットワークの深淵を覗いている筆者です。

皆さんは、Webサイトを閲覧していて「画像やデータがなかなか読み込まれないな……」とイライラした経験はありませんか？実はその裏側では、HTTPという通信ルールの「限界」と、それを乗り越えようとした先人たちの知恵がせめぎ合っているんです。

今回は、Web通信の歴史の中でも少し影の薄い、しかし非常に重要な「パイプライニング」という仕組みと、それが引き起こした「HOLブロッキング」という深刻な渋滞について、身近な例えを交えて紐解いていきましょう。

—

1. そもそもHTTPって何をしているの？

まずは基本の「おさらい」です。Webブラウザ（皆さんが使っているChromeやSafariなど）が、Webサイトのデータを置いているサーバーに対して「この画像ちょうだい！」「このスタイルシートも！」とお願いをすることをリクエスト、それに対してサーバーがデータを届けることをレスポンスと呼びます。

このやり取り、昔々（HTTP/1.0の頃）は「一問一答」形式でした。

1. ブラウザ「画像Aをください」
2. サーバー「はい、どうぞ（パケット送信）」
3. （到着を待つ）
4. ブラウザ「画像Bをください」
5. サーバー「はい、どうぞ」

これだと、1つのリクエストが終わるまで次のリクエストを出せません。まるで、郵便屋さんが1通の手紙を届けるたびに、一度郵便局に戻ってから次の手紙を拾いに行くようなものです。これでは効率が悪すぎますよね。

—

2. 「パイプライニング」で渋滞解消を目指す！

そこで登場したのが、HTTP/1.1で導入された「パイプライニング」という技術です。

イメージしてください。郵便屋さんが、わざわざ局に戻らなくても、手元に持っている大量の手紙（リクエスト）を、玄関ポストに次々と投函できるようになったとしたらどうでしょう？

ブラウザ「画像A！画像B！画像C！全部ちょうだい！」と一気に送る。
サーバーはそれを受け取り、順番に処理してレスポンスを返す。

これなら、待ち時間を大幅に短縮できそうです。これが「パイプライニング」の夢見た世界でした。

—

3. 致命的な落とし穴「Head-of-Line（HOL）ブロッキング」

しかし、現実はそう甘くありませんでした。ここで「Head-of-Line（先頭行）ブロッキング」という厄介な問題が立ちはだかります。

先ほどの郵便屋さんの例えで考えてみましょう。あなたは「大きな荷物（重い画像）」を一番最初に注文し、その後に「軽いハガキ（小さなアイコン）」を注文しました。

1. 郵便屋さん、大きな荷物をポストに入れようとするが、入り口が狭くて詰まってしまった！
2. 後ろに続くはずの「ハガキ」は、大きな荷物が邪魔で、いつまで経ってもポストに入れられない。

そう、これがHOLブロッキングです。「先頭のリクエストが処理されるまで、後ろのデータはどれだけ小さくても待たなければならない」というルールが、パイプライニングの足を引っ張ってしまったのです。

なぜこれが問題なのか？

Webサイトの表示において、ブラウザは「小さなCSSファイル」を先に読み込んでデザインを整えたいのに、その前に指定した「巨大な動画」や「高画質な写真」の転送が終わるまで、後ろの小さなデータがすべて足止めを食らってしまうからです。

—

4. 現場での確認とパラメーター

実は、このパイプライニングは現代のWebブラウザ（ChromeやFirefoxなど）では、デフォルトで無効化されています。理由はまさにこのHOLブロッキングが原因で、トラブルの元になるからです。

もし、皆さんがサーバーの設定やネットワーク機器のログでこの挙動を確認しようとするなら、以下のようなイメージになります。

クライアントからサーバーへのリクエスト（概念図）
実際にはTCPストリーム上で以下のように連続して送られます
GET /big-image.jpg HTTP/1.1 # これが詰まると後続が全滅
GET /small-style.css HTTP/1.1 # これが届かない！
GET /icon.png HTTP/1.1 # これも待機中…

インフラエンジニアとしては、もし古いシステムなどでパイプライニングが有効になっている環境に出会ったら、「なぜ通信が詰まるのか」の第一容疑者としてこの仕組みを疑うのが定石です。

—

まとめ：そして現代へ

HTTP/1.1のパイプライニングは、「一気に送れば速くなるはず！」という素晴らしい理想から生まれましたが、HTTPというプロトコル自体が「順番通りに返さなければならない（FIFO）」という厳格なルールを持っていたため、HOLブロッキングという壁に阻まれました。

しかし、この失敗があったからこそ、後のHTTP/2では「ストリーム」という概念が導入され、複数のデータを並列で、かつ順番を気にせずにやり取りできるようになったのです。

技術の進化は、こうした「現場の詰まり」を一つひとつ解消していく積み重ねなんですね。皆さんもネットワークのトラブルに遭遇したときは、「今、何が先頭で詰まっているのか？」を想像してみてください。パケットの行進が見えてくると、トラブルシューティングがぐっと楽しくなりますよ！

それでは、また次回の深掘りでお会いしましょう！