HTTP/1.1の「パイプライニング」という幻影——なぜ私たちはHOLブロッキングに苦しめられたのか
こんにちは。現場の最前線でパケットの断末魔を聞き続けてきたネットワークアーキテクトです。
今日は、Web技術の歴史において「期待されながらも、結局は挫折を味わった」ある機能について話をしよう。HTTP/1.1のパイプライニング（Pipelining）だ。現在、HTTP/2やHTTP/3が普及した現代において、なぜこの技術が「失敗したのか」、そしてなぜ我々が長年「Head-of-Line (HOL) ブロッキング」という悪魔に翻弄されてきたのか。その深淵を覗いていく。
—
1. パイプライニング：効率化の美しき夢
HTTP/1.0の頃、通信は「リクエスト→レスポンス→次のリクエスト」という、極めて律儀な往復運動だった。RTT（往復遅延時間）が重なるたびにページ表示は遅延する。そこでHTTP/1.1で導入されたのが「パイプライニング」だ。
これは、「レスポンスを待たずに、次のリクエストをTCPのバッファに詰め込む」という仕組みである。
通信フローの比較
- 従来のHTTP/1.1（Keep-Alive）:
`Req1 -> Res1 -> Req2 -> Res2`
- パイプライニング:
`Req1 -> Req2 -> Req3 -> (Res1 -> Res2 -> Res3)`
一見すると、RTTのロスを極限まで減らせる魔法のように思えるだろう。しかし、ここにWebの世界を長年苦しめる「呪い」が潜んでいた。
—
2. 呪いの正体：HOLブロッキング
パイプライニングが抱える致命的な欠陥が、Head-of-Line (HOL) ブロッキングだ。
HTTP/1.1の仕様（RFC 7230）では、「リクエストの順序通りにレスポンスを返さなければならない」と厳格に定められている。もし、1番目のリクエストが巨大なファイルのダウンロードで、2番目が軽いCSSの取得だった場合、2番目のレスポンスは「1番目の処理が完了して送信されるまで」、TCPの受信バッファで完全に「詰まる」ことになる。
これがHOLブロッキングの正体だ。ネットワークのパイプは空いているのに、先頭が詰まることで後続の全てが死ぬ。現場では、ロードバランサーのログを見て「なぜかレスポンスが極端に遅いリクエストが混ざっている」という怪奇現象として観測されることになる。
—
3. 実践：curlでパイプライニングをシミュレートする
かつて、この機能を意図的に利用しようと試みたエンジニアは多い。現代のモダンブラウザはほぼ無効化しているが、`curl`を使って「無理やりリクエストを投げる」挙動を観察してみよう。
–next オプションを使うと、複数のURLを一つのコネクションで投げられる
ただし、現在のcurlやサーバーの多くはパイプライニングをサポートしていない
curl -v –next http://example.com/large-file.zip \
–next http://example.com/style.css
# -v でパケットのやり取りを観察すると、
# 実際には多くのサーバーが一度コネクションを閉じるか、
# パイプライニングを無視して処理していることがわかるはずだ
※注：現代の多くのWebサーバー（Nginx, Apacheなど）は、パイプライニングを意図的に無効化、あるいはサポート対象外としている。これは、セキュリティリスク（リソース枯渇攻撃）と、HOLブロッキングによるパフォーマンス悪化がメリットを上回ったからだ。
—
4. なぜ私たちは諦めたのか？
実務の観点から言えば、パイプライニングの限界は以下の3点に集約される。
1. RFCの堅牢性の欠如: サーバー側がパイプライニングに対応しているか、完全に安全に処理できるかをクライアントが判断する術がない。
2. HOLブロッキングの回避不能性: TCPというプロトコル自体が「順序保証」を前提としているため、HTTP層でどう頑張っても、一つのリクエストが詰まればそのTCPストリームは全滅する。
3. ブラウザの実装コスト: IEや古いChromeでこの機能を有効にすると、特定のプロキシサーバーと相性問題を起こし、Webページが真っ白になるという事故が多発した。
—
5. 次の一手：HTTP/2への移行
もしあなたが今、Web APIの設計でパフォーマンスに悩んでいるなら、パイプライニングの微調整などという無駄な努力は今すぐやめるべきだ。
HTTP/2の「ストリーム多重化（Multiplexing）」こそが、HOLブロッキングに対する唯一かつ正解の回答だ。HTTP/2は一つのTCPコネクションの中で、リクエストとレスポンスを「フレーム」単位で細切れにして送る。これにより、1番目のリクエストが詰まっても、2番目のリクエストを追い越してレスポンスを返すことができる。
現場のエンジニアへのアドバイス
- 古いインフラ資産の確認: まだHTTP/1.1だけで運用しているレガシーシステムがあるなら、まずはHTTP/2対応のロードバランサー（ALBやCloudFrontなど）をフロントに配置せよ。
- コネクションの最適化: HTTP/1.1の時代のように「ドメインシャーディング（複数のホスト名で接続を分散する）」を行うのは、HTTP/2時代にはむしろ負債になる。HTTP/2を有効にするだけで、HOLブロッキングによる遅延は劇的に解消するはずだ。
まとめ
パイプライニングは「プロトコル設計の理想と、実装の現実」が衝突した、非常に教育的な失敗例だ。教科書通りに「リクエストを並べれば速くなる」と信じてはいけない。ネットワークエンジニアは、パケットが物理的なケーブルの中をどう流れるか、TCPのウィンドウサイズがどう変化するかを想像しなければならない。
次に「Webが遅い」という報告が上がった時、ブラウザのキャッシュを疑う前に、その裏側にあるHTTPの通信シーケンスをパケットキャプチャして眺めてみてほしい。そこには、教科書には書かれていない「現場の真実」が必ず刻まれているはずだ。
コメント