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

「送ったもん勝ち」はなぜ破綻したのか？ HTTP/1.1のパイプライン処理と「HOLブロッキング」の正体

こんにちは！ネットワークの深淵を愛するエンジニアの皆さん。今日は、Web通信の歴史の中でも少し「不器用で愛おしい」存在、HTTP/1.1のパイプライン処理についてお話ししましょう。

「リクエストを待たずに送っちゃえば速いんじゃない？」という、一見天才的なアイデアが、なぜ現場ではあまり使われず、最終的にHTTP/2という革命を引き起こすことになったのか。そのドラマを紐解いていきます。

—

HTTP/1.1のパイプライン処理を理解するために、ある郵便局の窓口を想像してみてください。

通常、私たちは窓口で「切手をください」と頼み、切手を受け取ってから「次は封筒をください」と頼みますよね。これが標準的なHTTPのやり取りです。

パイプライン処理とは、窓口の人に「切手と、封筒と、ハガキをまとめてお願い！」と一度に要求を投げつける行為です。窓口の人は、それらを順番に処理して、結果をまとめて返してくれます。

一見、往復回数が減って効率的に見えますよね？しかし、ここには致命的な「待ちぼうけ」の罠があったのです。

—

この郵便局には、実は一つだけ厳しいルールがありました。それは「注文を受けた順番通りにしか商品を渡せない」というルールです。

もし、あなたが「切手」「封筒」「ハガキ」の順に頼んだとして、たまたまその時「切手」の在庫を探すのに時間がかかってしまったらどうなるでしょう？

これが、ネットワークの世界で言うHOLブロッキング（Head-of-Line Blocking：先頭ブロック問題）です。

前のリクエストが詰まると、後ろに並んでいるすべてのリクエストが、たとえ軽いデータであっても「人質」のように拘束されてしまう。これがHTTP/1.1のパイプライン処理が抱えていた、非常に深刻なボトルネックでした。

—

実は、HTTP/1.1の仕様書には「パイプライン機能を使ってもいいよ」と書かれています。しかし、ブラウザやWebサーバーの現場では、長らくこの機能は「オフ」にされてきました。

理由は明確です。
「サーバー側で前のリクエストの処理が終わるまで、次のリクエストの結果を返せない」という仕組みは、サーバーの負荷を予測不能にするからです。

もしWebサーバーがパイプラインを受け取った時の挙動を、非常にシンプルに書くとこんな感じです。

// 擬似的なリクエスト処理のイメージ
function handleRequests(requests) {
for (let req of requests) {
// もしこの処理に時間がかかると…
const response = process(req);

// 次のreqは、前のprocess()が終わるまで「待ち」状態になる
sendToClient(response);
}
}

このコードを見るとわかる通り、途中で重い画像ファイルやデータベース検索が混ざると、その後の「軽いCSS」や「小さなアイコン」の配信まで全て止まってしまいます。これを避けるために、ブラウザは「安全のためにパイプラインはやめて、並列で接続を張る（コネクションを複数作る）」という戦略をとったのです。

—

HTTP/1.1のパイプライン処理は、「効率化を求めて先走った結果、逆に全体の流れをせき止めてしまった」という、インフラ設計における典型的な失敗例かもしれません。

この教訓があったからこそ、HTTP/2では「ストリーム」という概念が導入され、順番を気にせずバラバラにデータをやり取りできる仕組み（多重化）が誕生しました。

HTTP/1.1は「順番待ち」に弱い： 大量の小さなリクエストを送る際は、相変わらずコネクションの貼りすぎに注意が必要です。
モダンなプロトコルへの理解： なぜHTTP/2やHTTP/3が「速い」と言われるのか。それは「HOLブロッキングをどう解決したか」という歴史の積み重ねの上にあるからです。

ネットワークの世界は、こうした「先人たちの失敗と改善の繰り返し」でできています。もしトラブルシューティングでパケットキャプチャを見る機会があれば、「今、前のデータが詰まって後ろが待たされていないか？」という視点を持ってみてください。きっと、プロのインフラエンジニアへの第一歩になるはずですよ！

それでは、また次回の深掘りでお会いしましょう。ハッピー・パケット・ライフを！