Tech Learning Daily

HTTP/1.1: 1本の接続の中でリクエストは順番を待つ

HTTP/1.1 の接続は Keep-Alive で使い回されるが、1本の接続で同時に運べるリクエスト・レスポンスの組は1つだけだ。仕様上は複数のリクエストを続けて送りつける「パイプライニング」という仕組みもあるが、サーバーは受け取った順番通りにしかレスポンスを返せない。先頭のレスポンスの生成が遅れると、後続のレスポンスがすでに完成していても待たされてしまう。この「先頭が詰まると後続まで止まる」現象をHead-of-Line Blocking（先頭ブロッキング）と呼ぶ。

この問題があるため、パイプライニングは実質ほとんどのブラウザ・サーバーで使われず、代わりにブラウザは同じオリジンへ複数の TCP 接続を並行して張るという力技で対応してきた。多くのブラウザは1オリジンあたり最大 6 本程度に接続数を制限している。これは仕様が定めた固定値ではなくブラウザの実装判断で、接続を増やすほど TCP のハンドシェイクやスロースタートのコストもかさむため、無制限に増やせば速くなるわけではない。

HTTP/2: バイナリフレーミングで1本の接続に多重化する

HTTP/2 は、テキストベースだった HTTP/1.1 を、フレームという単位でやり取りするバイナリプロトコルに作り替えた。これをバイナリフレーミングレイヤーと呼ぶ。1つのリクエスト・レスポンスのやり取りはストリームという独立した論理的な流れに割り当てられ、各フレームにはどのストリームに属するかを示す ID が付く。異なるストリームのフレームは同じ TCP 接続の中で入り乱れて送られてもよく、受信側は ID を見て元のストリームに組み立て直す。これが多重化であり、1つのリクエストの処理が遅れても、他のストリームの処理はブロックされない。

接続の確立時には、TLS ハンドシェイクに含まれるALPN（Application-Layer Protocol Negotiation）という拡張を使って、クライアントとサーバーがその場で「HTTP/2 で話せるか」をすり合わせ、対応していなければ HTTP/1.1 にフォールバックする。1本の接続に集約する設計になったため、HTTP/1.1 時代にドメインを分割して接続数を稼いでいた「ドメインシャーディング」という小細工は、HTTP/2 ではむしろ逆効果になる。

┌ HTTP/1.1: オリジンへ複数のTCP接続 ──┐
│ [conn1][conn2][conn3]…[conn6]      │
│  各接続は1リクエストずつ順番待ち   │
└─────────────────────────────────────┘

┌ HTTP/2: 1本のTCP接続に多重化 ───────┐
│ [stream1][stream2][stream3]…       │
│  1本の接続の中を並行して流れる     │
│  ただしパケットロス1つで全停止 ⚠️  │
└─────────────────────────────────────┘

ついでに削られた無駄: HPACK によるヘッダー圧縮

HTTP/1.1 では、cookie や user-agent などほぼ同じ内容のヘッダーを、リクエストのたびにテキストのまま送り直していた。HTTP/2 はこの重複をHPACK という圧縮方式で圧縮する。頻出するヘッダー名・値をあらかじめ登録した静的テーブルと、接続中に一度出てきた値を覚えておく動的テーブルを組み合わせ、2回目以降は差分やテーブルの参照番号だけを送ればよくなる。

それでも消えていない TCP層の Head-of-Line Blocking

ここまでだけ聞くと、HTTP/2 は文句なしに速いように思える。しかし実際には、1本の接続に集約したことが別の問題を生んでいる。TCP はバイト列を送信した順序のまま届けることを保証するプロトコルで、途中のパケットが1つ失われると、再送が完了するまでは、それより後に届いたデータがたとえ別のストリームに属していてもアプリケーションに渡されない。HTTP/1.1 が複数の独立した接続を張っていたときは、1本の接続でパケットが失われても他の接続には影響しなかった。HTTP/2 は接続を1本にまとめたことで、この独立性を手放している。

影響が顕著に出るのは、Wi-Fi の切り替わりやモバイル回線などパケットロス率が高いネットワークだ。多重化によってアプリケーション層のブロッキングは解消されたのに、接続を集約したことで生まれた別のブロッキングが足を引っ張るという逆転が起こり得る。

次の一手: UDP の上に作り直した HTTP/3

この TCP層の Head-of-Line Blocking を解決するために設計されたのが、UDP の上に QUIC という新しいトランスポートを載せる HTTP/3 だ。QUIC はストリームごとに独立して順序管理と再送を行うため、あるストリームでパケットが失われても他のストリームは影響を受けずに進める。HTTP/2 がアプリケーション層で多重化を実現したのに対し、HTTP/3 はトランスポート層まで多重化を持ち込んだ設計だと言える。