HTTP/1.1の「パイプライン化」という名の幻想と、Head-of-Line Blockingという冷酷な現実
インフラの最前線でパケットを追い続けていると、たまに「なぜ歴史的な技術が、こうも現場で愛され、そして苦しめられるのか」と考えさせられることがある。その代表格が、HTTP/1.1のパイプライン化（HTTP Pipelining）だ。
教科書的には「リクエストを待たずに次のリクエストを投げられるから効率的」と教わる。しかし、実務の現場でパケットキャプチャを広げれば、それがどれほど危ういバランスの上に成り立っているか、すぐに理解できるはずだ。
今日は、HTTP/1.1のパイプライン化がなぜ現代のWebで「封印」されているのか、その技術的真実を紐解いていこう。
—
パイプライン化の甘い誘惑と通信フロー
HTTP/1.0では「1リクエスト・1レスポンス」ごとにTCP接続を確立していた。これではオーバーヘッドが大きすぎる。そこで登場したのがHTTP/1.1の「持続的接続（Persistent Connection）」と、その進化系としての「パイプライン化」だ。
通常のHTTP/1.1（Keep-Alive）
1. Client -> Server: GET /img.jpg
2. Server -> Client: (200 OK + Data)
3. Client -> Server: GET /style.css
4. Server -> Client: (200 OK + Data)
パイプライン化されたHTTP/1.1
1. Client -> Server: GET /img.jpg \n GET /style.css
2. Server -> Client: (200 OK + Data) \n (200 OK + Data)
一見すると効率的だが、ここに「FIFO（First-In, First-Out）の呪縛」が潜んでいる。サーバーはリクエストを受信した順序通りにレスポンスを返さなければならない。これがパイプライン化最大の弱点だ。
—
Head-of-Line Blocking（HOLB）という名の渋滞
パイプライン化の最大の課題、それが「Head-of-Line Blocking（先頭行のブロッキング）」だ。
想像してみてほしい。最初の画像ファイル（img.jpg）が巨大で、サーバー側での生成に時間がかかっているとする。しかし、その後ろに続くCSSファイル（style.css）のリクエストは、たとえサーバー側で既に読み込みが完了していたとしても、前のimg.jpgのレスポンスが完了するまで、ネットワークに乗ることができない。
前のリクエストが詰まれば、後ろの全てが停止する。 これがHTTP/1.1のパイプライン化が抱える構造的な欠陥だ。
—
実践：パイプライン化を体験する（curlでの確認）
今、ブラウザはほぼ例外なくパイプライン化を無効化している。なぜなら、多くのプロキシやミドルウェアが正しく実装できておらず、接続が切断されるリスクが高いからだ。
試しに、`curl`を使って「無理やり」パイプライン化に近い挙動をさせると、現代のサーバーがどう反応するか見てみよう。
複数のリクエストをパイプライン的に送るシミュレーション
–next オプションで複数のリクエストを連結できるが、
現代のWebサーバー（Nginx等）はこれをシリアルに処理する。
curl -v http://example.com/api/data1 –next http://example.com/api/data2
もし自前でHTTP実装を書くなら、パケットがどう並ぶかを確認するために、以下のPythonコードでソケットを直叩きしてみるといい。
import socket
HTTP/1.1のリクエストを連結して送信
request = (
“GET /index.html HTTP/1.1\r\nHost: example.com\r\n\r\n”
“GET /style.css HTTP/1.1\r\nHost: example.com\r\n\r\n”
)
with socket.create_connection((“example.com”, 80)) as sock:
sock.sendall(request.encode())
# ここでレスポンスを待つが、最初の行が遅いと全てが待たされる
response = sock.recv(4096)
print(response.decode())
—
なぜ現代のブラウザはこれを捨てたのか？
ChromeやFirefoxなどの主要ブラウザは、2010年代半ばからパイプライン化を無効化、あるいは削除した。理由はシンプルだ。
1. ミドルウェアとの相性最悪: 古いプロキシやルーターが「リクエストが複数ある」ことを正しく解釈できず、コネクションをリセットするケースが多発した。
2. HOLBの解決不能: HTTP/1.1の仕様上、どうしても「順序」が守られるため、TCPレベルでのブロッキングを回避できない。
3. HTTP/2の登場: HTTP/2の「ストリーム多重化（Multiplexing）」こそが、パイプライン化が目指した夢を、HOLBなしで実現した解だ。
—
エンジニアへのアドバイス：今、何をすべきか
実務でWeb APIを設計・運用している諸君に伝えたい。
- HTTP/1.1に固執しない: もし高トラフィックなサービスを運用しているなら、迷わずHTTP/2、あるいはQUIC（HTTP/3）を採用すべきだ。多重化の恩恵は、パイプライン化の比ではない。
- Keep-Aliveの最適化: まだHTTP/1.1を使わざるを得ない環境なら、パイプライン化を期待するのではなく、`Keep-Alive`のタイムアウト設定（`keepalive_timeout`など）を適切にチューニングし、コネクション再利用の効率を高めることに注力してほしい。
- デバッグの視点: 通信が遅いと感じたら、ChromeのDeveloper Toolsの「Network」タブで、リクエストが「Stalled」していないか確認せよ。もし1つのコネクションでリクエストが並んでいるなら、それはブラウザの同時接続制限（通常6本）に引っかかっている証拠だ。
HTTP/1.1のパイプライン化は、技術史における「勇敢な失敗」だった。しかし、その失敗があったからこそ、現代の我々はHTTP/2のストリーム制御という洗練された仕組みを手にしている。
インフラは、過去の仕様がなぜ捨てられたかを知ることで、初めて次世代の設計図が描けるようになる。現場のパケットに耳を澄ませ、常に「なぜその挙動になるのか」を問い続けてほしい。それが、一流のエンジニアへの近道だ。
コメント