郵便局の行列をなくしたい！「HTTPパイプライン化」という挑戦の物語
こんにちは！ネットワークの深淵を愛するエンジニアの皆さん。今日は、Webサイトがパッと表示される裏側で、かつてエンジニアたちが頭を悩ませた「HTTPパイプライン化」という技術についてお話しします。
「Webサイトがなかなか表示されない…」そんなイライラを解消するために、先人たちはどんな工夫を凝らしたのか。まるで郵便局の窓口に並ぶ人々に例えて、紐解いていきましょう！
—
昔のWeb通信は「一問一答」の行列だった
HTTP/1.1が登場した頃、Webブラウザとサーバーのやり取りは、とても律儀な「一問一答」スタイルでした。
1. リクエスト（手紙を出す）: 「画像Aをください！」
2. レスポンス（返事が届く）: 「はい、これが画像Aです」
3. 次のリクエスト: 「じゃあ次は画像Bをください！」
もしWebページに100個の小さなアイコンがあったらどうなるでしょう？100回も「往復」を繰り返さなければなりません。通信のたびに、地球の裏側まで手紙を届けるようなラグ（遅延）が発生してしまうのです。
「待たずに投げる！」という革命
そこで生まれたのが「パイプライン化」です。
これは、窓口に並んでいる人が「次の人の順番を待たずに、まとめて注文をカウンターに投げ込む」ようなイメージです。
- 従来: リクエスト1を送る → レスポンス1を待つ → リクエスト2を送る…
- パイプライン化: リクエスト1, 2, 3を一気に送りつける！
これなら、サーバー側で処理をしてくれる間に通信の往復時間を節約できるはずですよね。
—
しかし現実は甘くない：「HOLブロッキング」という壁
「これで通信爆速だ！」と誰もが期待したパイプライン化ですが、実は致命的な弱点がありました。それが「HOLブロッキング（Head-of-Line Blocking：列の先頭での詰まり）」です。
郵便局の窓口で例えると…
窓口の担当者が、投げ込まれた3つの注文を「順番通り」にしか処理できないと想像してください。
1. 注文1（重い画像）: 処理に時間がかかる。
2. 注文2（小さなアイコン）: すぐ終わるのに、注文1が終わるまで待たされる。
3. 注文3（テキストデータ）: これも注文1のせいで待ちぼうけ。
一番手前の「注文1」が詰まると、後ろに控えている注文2も3も、すべてが窓口のカウンターで足止めを食らってしまうのです。これがHOLブロッキングの正体です。「前のやつが終わるまで、お前たちは一歩も動くな！」というわけです。
—
パイプライン化はなぜ使われなくなったのか？
結局、この仕組みは「前の処理が遅いと、全部が遅くなる」という副作用があまりに大きく、多くのブラウザやサーバーでは「デフォルトでオフ」にされる運命をたどりました。
現代のWebでは、この問題を解決するために、HTTP/2という新しい規格で「マルチプレキシング（多重化）」という、より賢いやり方が採用されています。
今の現場ではどうなっている？
現代のネットワーク開発では、以下のような設定や考え方が主流です。
/ HTTP/1.1での挙動イメージ /
GET /image1.jpg HTTP/1.1 // 1番目のリクエスト
GET /image2.jpg HTTP/1.1 // 2番目のリクエストを待ちきれずに送信
GET /image3.jpg HTTP/1.1 // 3番目も送信！
/
- ただし、サーバー側で処理が詰まると
- 2と3は1の終了を待つことになり、
- 結局ブラウザは「あれ、まだ来ないな…」と
- タイムアウトや再送処理で苦しむことになります。
/
現代のエンジニアとしては、「HTTP/1.1で無理やりパイプライン化するよりも、HTTP/2やHTTP/3といった新しいプロトコルへの移行を検討する」のが、最も賢いトラブルシューティングになります。
—
最後に：失敗から学ぶエンジニアの視点
「パイプライン化」は、一見すると「賢い工夫」に見えます。しかし、ネットワークの世界では「解決策が別のボトルネックを生む」ことがよくあります。
「なぜこの技術は使われなくなったのか？」という歴史を知ることは、単に仕様を覚えるよりもずっと価値があります。それは、「今の当たり前が、どんな試行錯誤の上に成り立っているのか」を知るということだからです。
これからも、パケットが駆け巡るリアルな挙動を想像しながら、一歩ずつ一緒に学んでいきましょうね。次回の記事では、このHOLブロッキングを根本から解決した「HTTP/2の魔法」について解説します。お楽しみに！
コメント