HTTP/1.1 → 2 → 3 — 何が遅くて、何を直したのか

What — 3世代で何が変わったか

まず、それぞれが何を解いたのかを切り替えて見比べてください。

接続1: [req A][... A待ち ...][res A][req B][... B待ち ...][res B]

ブラウザは同一ホストに 6 本まで接続を張ることで
無理やり並列化していた（= ドメイン分割が有効だった時代）

HOL ブロッキングが「どの層で起きるか」を追う

HTTP/2 の説明でいちばん誤解されるのが、ここです。HTTP/2 は HOL ブロッキングを解決していません。発生する層を1つ下げただけです。

HTTP/3 がわざわざ TCP を捨てて UDP に移ったのは、この「TCP の順番保証の粒度が粗すぎる」問題を、TCP の中では直せなかったからです。

Why — なぜ3回も作り直したのか

HTTP/1.1 の設計は、当時としては正しかった

HTTP/1.1 が固まった1997年、Web ページは HTML 1枚と画像が数枚でした。1リクエストずつ順番に処理する設計で困りません。むしろ実装が単純で、どんな貧弱なサーバーでも動くことが価値でした。

問題が出たのは、ページあたりのリクエスト数が10件から100件へ増えてからです。設計が間違っていたのではなく、前提が変わったのです。

現場は回避策を積み上げた

仕様が変わらないので、現場は HTTP/1.1 の制約を回避する技法を発明しました。

• ドメイン分割 — ブラウザの「同一ホスト6接続まで」を、ホストを増やして突破する
• CSS スプライト — 小さい画像を1枚に結合し、リクエスト数を減らす
• ファイル結合・インライン化 — CSS や JS を1つにまとめる

どれも「リクエスト数が多いと遅い」という制約への対処です。ここが重要で、HTTP/2 でその制約が消えると、これらはコストだけが残ります。スプライト画像は、1枚しか使わないページでも全体をダウンロードさせますし、ドメイン分割は接続を分断します。冒頭の事故はこれでした。

なぜ HTTP/2 で TCP を捨てられなかったのか

HTTP/2 の設計時も、TCP の HOL ブロッキングは認識されていました。それでも TCP を使い続けたのは、世界中の中間機器が TCP しか通さなかったからです。企業のファイアウォール、NAT、プロキシの多くは、UDP を通さないか、通しても特別扱いします。

HTTP/3 が現実的になったのは、QUIC が UDP の上で動き、暗号化によって中間機器から中身が見えなくなり、かつ「通らなければ HTTP/2 に自動で戻る」というフォールバックを持てるようになってからです。技術的な正しさだけでは普及せず、既存の設備との折り合いが必要だったという話でもあります。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。