「なぜWebサイトの表示は遅くなるの？」HTTP/1.1のパイプラインと「渋滞」の正体
こんにちは！インフラの世界へようこそ。Webサイトを見ているとき、ふと「なんでこんなに表示が遅いんだろう？」と感じたことはありませんか？
実は、その裏側ではネットワークの「郵便配達員」が必死に働いています。今回は、Web通信の歴史の中でも非常に重要な「HTTP/1.1のパイプライン」という仕組みと、そこで発生する「避けられない渋滞（ヘッド・オブ・ライン・ブロッキング）」について、一緒に紐解いていきましょう。
—
そもそもHTTPの通信ってどんなイメージ？
まず、HTTP通信を「手紙のやり取り」に例えてみましょう。
- クライアント（ブラウザ）： 「この画像と、この文字のデータをちょうだい！」と手紙を書く人。
- サーバー： その手紙を受け取って、中身を梱包して送り返す郵便局。
昔のHTTP（HTTP/1.0の頃）は、「1通手紙を送ったら、返事が届くまで次の手紙は送っちゃダメ！」という、とても律儀なルールでした。これでは、たくさんの画像が必要な現代のWebサイトでは、返事を待つ時間が長すぎて、いつまで経っても画面が表示されませんよね。
—
パイプライン処理：夢の「連続投函」システム
この「待つのがもったいない！」という課題を解決するために登場したのが、HTTP/1.1の「パイプライン処理」です。
これは、郵便局（サーバー）からの返事を待たずに、「必要な手紙（リクエスト）を先に全部ポストに突っ込んでしまう」という画期的な手法です。
イメージ図
- 昔（HTTP/1.0）： リクエストAを送る → 返事を待つ → リクエストBを送る → 返事を待つ…
- パイプライン（HTTP/1.1）： リクエストAを投函！ → すぐにリクエストBを投函！ → リクエストCを投函！
これなら、郵便局員がAの荷物を探している間に、BとCの準備も始められます。一見、完璧に見えますよね？
—
しかし現実は甘くない：「ヘッド・オブ・ライン・ブロッキング」という罠
ところが、このパイプラインには致命的な弱点がありました。それが「ヘッド・オブ・ライン・ブロッキング（Head-of-Line Blocking）」です。直訳すると「列の先頭での詰まり」ですね。
先ほどの郵便局を想像してください。あなたは3通の手紙を順番にポストに入れました。
1. 手紙A： とても大きな荷物（例えば、高画質の画像）
2. 手紙B： 小さな荷物（数行のテキスト）
3. 手紙C： 小さな荷物（アイコン画像）
郵便局員は「来た順番に」荷物を処理します。するとどうなるでしょう？
「一番前の手紙A（巨大な荷物）を梱包している間、後ろの手紙BとCは、どれだけ小さくてすぐに用意できるものでも、ずっと待たされることになる」のです。
列の先頭が詰まると、後ろにどれだけ優秀なデータが並んでいても動けなくなる。これがHTTP/1.1のパイプラインが抱える「逃れられない渋滞」です。
—
実務で意識する「リクエストの姿」
少しだけ技術的なコードの側面を覗いてみましょう。ブラウザがサーバーに送るリクエストは、中身はただのテキストです。
// ブラウザが送るリクエストのイメージ
GET /image.jpg HTTP/1.1 // 1つ目のリクエスト（これが大きいと詰まる！）
Host: example.com
GET /style.css HTTP/1.1 // 2つ目のリクエスト（これも待たされる…）
Host: example.com
GET /logo.png HTTP/1.1 // 3つ目のリクエスト（これも待たされる…）
このように、テキストとして連続して送られていますが、サーバー側は「1つずつ順番に」処理して返さなければなりません。
—
まとめ：そして現代へ
HTTP/1.1のパイプライン処理は、当時の技術としては画期的でしたが、結局「1本の道路を順番に通る」という制約からは逃れられませんでした。
この「詰まり」を解消するために、その後のHTTP/2では「複数のリクエストを同時に並列で送る（多重化）」という、まるで道路を何車線にも増やすような進化を遂げました。
「なぜ昔の技術は遅かったのか？」「なぜ今の技術は速いのか？」
その理由を知ることは、ネットワークの設計図を描くための第一歩です。今回の「渋滞」のイメージが、皆さんのエンジニアライフのヒントになれば嬉しいです。
一歩ずつ、着実に理解を深めていきましょう！次回の解説も楽しみにしていてくださいね。
コメント