【入門編】HTTP/1.1のパイプライン処理(Pipelining)の仕様と制限 – HTTPプロトコル・通信規格実践ガイド

「なぜWebサイトは重くなるのか？」HTTPパイプライン処理とHOLBの正体を解き明かす

こんにちは！ネットワークの世界へようこそ。日頃、何気なくブラウザにURLを入力してWebサイトを見ていますが、その裏側では一体どんなドラマが繰り広げられているのでしょうか？

今日は、Web通信の歴史の中でも、特に「効率を追い求めた結果、皮肉にも渋滞を引き起こしてしまった」という、ちょっと切ないHTTP/1.1のパイプライン処理という仕組みについてお話しします。

—

HTTPを郵便配達に例えてみましょう。

1. あなた（ブラウザ）が「この手紙（リクエスト）を届けて！」と頼む。
2. 郵便屋さん（HTTP）が相手の家（サーバー）へ走る。
3. 相手が手紙を読み、返事（レスポンス）を書く。
4. 郵便屋さんがその返事を持って戻ってくる。

これがHTTPの基本です。しかし、Webサイトには画像やスタイルシートなど、たくさんのファイルが隠れています。1つずつ順番に手紙を出し、返事を待っていたら、Webページが表示されるまでに日が暮れてしまいますよね。

—

そこで登場したのが「パイプライン処理（Pipelining）」です。

これは、「返事が来るのを待たずに、次の手紙をどんどん郵便箱に放り込んでしまおう！」という作戦です。

これによって、ネットワークの往復時間を大幅に短縮できるはずでした。しかし、ここで大きな問題が立ちはだかります。

—

パイプライン処理は一見完璧ですが、一つだけ大きな弱点があります。それが「ヘッド・オブ・ライン・ブロッキング（HOLB：先頭の列による詰まり）」です。

想像してみてください。あなたは郵便屋さんに「手紙A」「手紙B」「手紙C」を順番に渡しました。ルール上、郵便屋さんは「受け取った順番通りに返事を届けなければならない」のです。

もし、先頭の「手紙A」の処理に時間がかかったらどうなるでしょうか？
後ろに控えている「手紙B」や「手紙C」の準備がどんなに早く終わっていても、手紙Aが戻ってくるまで、あなたはそれらを受け取ることができません。

「前の人が窓口でモタモタしているせいで、後ろの全員が待たされる」

これがHOLBの正体です。Webの世界では、巨大な画像データの読み込みが詰まるだけで、その後の小さなテキストデータまで全てストップしてしまう……そんな現象が現場では頻繁に起きていました。

—

実は、このHOLB問題があまりにも深刻だったため、現在のモダンなブラウザ（ChromeやFirefoxなど）では、HTTP/1.1のパイプライン処理はあえて無効化されています。

もしあなたがWebサーバーの設定を確認するなら、以下のようなイメージになります。

Nginxの設定例（イメージです）
http {
# 現代のWebサーバーでは、パイプライン処理はデフォルトでOFF、
# もしくは非常に限定的な対応となっていることがほとんどです。
keepalive_requests 100; # 1つの接続で最大100リクエストまで受け付ける設定

# パイプライン処理を強制的に「使わせない」ようにする設定項目は
# 実はあまり存在しません。ブラウザ側が「パイプラインを諦めた」からです。
}

エンジニアとして覚えておいてほしいのは、「パイプライン処理という古い工夫は、HOLBという壁にぶつかって限界を迎えた」という歴史的な事実です。

—

この問題を根本から解決するために生まれたのが、現代の主流であるHTTP/2です。HTTP/2は、手紙を順番に並べるのではなく、バラバラに分解して（ストリーム化）、パズルのように並行して運ぶことで、この「詰まり」を解消しました。

「ネットワークは生き物だ」とよく言われます。今回のHTTP/1.1の教訓は、「ただ速くするだけではダメで、詰まりを作らない設計が必要だ」という、インフラエンジニアにとって最も大切な哲学を教えてくれています。

—

ネットワークのトラブルシューティングをしていると、「なぜか特定のファイルだけ読み込みが遅い……」という場面に遭遇することがあります。そんな時、ぜひこの「渋滞」の仕組みを思い出してみてください。一歩ずつ理解すれば、パケットの流れがもっと鮮明に見えてくるはずですよ！