HTTP/2 と HTTP/3 (QUIC)

画像が 60 個あると、ブラウザは列を作って待ち始める

1 枚のページに画像や CSS や JS が数十個ぶら下がるのは普通のことです。ところが HTTP/1.1 では、ブラウザは同じドメインに対して 6 本までしか同時につなぎません。7 個目以降は、前のどれかが終わるまで順番待ちです。

当時の回避策は、画像用に別のサブドメインを切って本数を稼ぐことでした。6 本という上限は変わらないので、ドメインを増やして掛け算する、という力技です。

1 本の接続に、全部を同時に流し込む

HTTP/2 がやったのは、接続を増やすのをやめて、1 本の中を仕切ることでした。1 つの接続の上に「ストリーム」という論理的な通り道を何本も作り、リクエストとレスポンスを細切れにして混ぜて流します。受け取った側が番号を見て組み直すので、順番待ちが消えます。

もう 1 つの改善がヘッダーです。リクエストのたびに同じ Cookie や User-Agent を丸ごと送っていたのを、2 回目からは差分だけ送る形に圧縮しました。1 つ 1 つは小さくても、数十リクエストぶん積み上がると効いてきます。

ここで、昔の最適化が逆効果に変わります。画像用にサブドメインを分けていると、ドメインごとに別の接続が張られます。せっかく 1 本にまとめられるのに、わざわざ分けて、接続を張る手間と圧縮の効きを両方捨てていることになります。HTTP/2 に上げたのに速くならないときは、この手の古い工夫が残っていないかを疑います。

パケットが 1 個落ちると、関係ない画像まで止まる

ただし HTTP/2 は TCP の上に乗っています。TCP は届いた順に並べ直して渡すので、途中の 1 個が落ちると、その後ろのデータをすでに受け取っていても渡してくれません。

困るのは、この足止めがストリームの区別なく起きることです。画像 A のパケットが 1 個落ちただけで、無関係な CSS も文章も、再送が届くまで一緒に止まります。1 本にまとめたことが、そのまま弱点になりました。

電車で回線が切り替わっても、つながったまま

HTTP/3 は、この足止めを起こす層そのものを取り替えました。土台を TCP から QUIC に変え、並べ直しの管理をストリームごとに独立させています。画像 A が待っていても、CSS は先に渡せます。

QUIC は UDP の上に作られていますが、UDP に任せているわけではありません。順番の管理も再送も混雑の制御も暗号化も、QUIC が自前で持っています。UDP は、途中のルーターに通してもらうための土台として使われているだけです。

副産物として、接続の見分け方が IP アドレスから切り離されました。電車の中で Wi-Fi からモバイル回線に切り替わっても、接続は張り直さずに続きます。

自分が見ているページがどれで通信しているかは、ブラウザの開発者ツールの Network パネルで確認できます。Protocol の列に h3、h2、http/1.1 のいずれかが出ます。同じサイトでも回線や環境によって変わるので、一度見ておくと、この 3 つが今も並存していることが実感できます。