HTTP/2とHTTP/3
HTTPの進化の背景
[[HTTP]] は長らく HTTP/1.1 が使われてきましたが、Webページが数十〜数百のファイルを読み込む時代になると限界が見えてきました。最大の問題がHoLブロッキング(Head-of-Line blocking)です。
- HTTP/1.1 は1つの接続で一度に1つのリクエストしか処理できない
- 先頭の応答が遅いと、後続がすべて待たされる
- ブラウザは接続を6本ほど並列に張って誤魔化していたが、根本解決ではない
この行列問題を解消するために生まれたのが HTTP/2 と HTTP/3 です。
HTTP/2 — 1本の接続で多重化
HTTP/2(2015年標準化)の中心は多重化(マルチプレキシング)です。
- 1本のTCP接続の中に複数のストリームを作り、リクエスト・レスポンスを並行して流す
- テキストだったやり取りをバイナリ形式に変えて効率化
- 繰り返し送られるヘッダーをHPACKで圧縮
ただし弱点が残りました。土台のTCPは「1本の順序付きの流れ」なので、パケットが1つ欠けるとTCP層で全ストリームが止まるのです。行列はHTTP層からTCP層へ引っ越しただけ、とも言えます。
HTTP/3 — QUICでトランスポートから再発明
HTTP/3(2022年標準化)は、TCPを捨てて [[UDP]] の上に構築された QUIC というトランスポートを使います。
| HTTP/2 | HTTP/3 | |
|---|---|---|
| 土台 | TCP | QUIC([[UDP]] 上) |
| パケットロス時 | 全ストリームが待たされる | 失われたストリームだけが待つ |
| 接続確立 | TCP+TLSで複数往復 | 暗号化込みで最短1往復(再接続は0往復も) |
| 暗号化 | TLSを併用(事実上必須) | QUICに組み込み(常に暗号化) |
QUICはストリームごとに独立して再送するためHoLブロッキングが根本解決され、[[HTTPS・TLS]] 相当の暗号化も最初から組み込まれています。モバイル回線とWi-Fiの切り替えで接続を維持できるのも強みです。
初学者向けポイント
- ブラウザとサーバーが自動で最適なバージョンを選ぶため、アプリのコードを書き換える必要は基本的にない — サーバーやCDN側の対応で恩恵を受けられる
- 開発者ツールのNetworkタブで Protocol 列(h2 / h3)を表示すると、実際にどのバージョンで通信しているか確認できる
- [[Webパフォーマンス最適化]] の文脈では「HTTP/1.1前提の最適化(ドメイン分割など)はHTTP/2以降では逆効果になりうる」ことも知っておくと良い
関連技術とのつながり
- [[HTTP]] — 意味論(メソッドやステータスコード)はそのまま、運び方が進化した
- [[HTTPS・TLS]] — HTTP/2は事実上TLS必須、HTTP/3は暗号化が組み込み
- [[UDP]] — QUICはUDPの上に信頼性と暗号化を実装している
- [[Webパフォーマンス最適化]] — プロトコル選択は表示速度改善の土台
Q: HTTP/1.1の主な課題として本文で挙げられているのはどれ?
- [x] 1接続で一度に1リクエストしか処理できず、先頭の応答待ちで後続が詰まる
- [ ] 暗号化が仕様上禁止されている
- [ ] テキストではなくバイナリ形式でやり取りする
解説: これがHoLブロッキングです。ブラウザは複数接続で緩和していましたが、根本解決はHTTP/2以降に持ち越されました。
Q: HTTP/2の中心的な改善はどれ?
- [ ] UDPの採用
- [x] 1本のTCP接続内で複数ストリームを並行処理する多重化
- [ ] ヘッダーの完全な廃止
解説: HTTP/2は多重化・バイナリ化・ヘッダー圧縮(HPACK)で高速化しました。UDP採用はHTTP/3(QUIC)です。
Q: HTTP/3(QUIC)がHTTP/2より有利な点として正しいのはどれ?
- [ ] 暗号化を省略して高速化できる
- [ ] TCPの再送制御をそのまま利用できる
- [x] パケットロス時に失われたストリームだけが待てばよい
解説: QUICはストリームごとに独立して再送するため、TCP由来のHoLブロッキングが解消されます。暗号化はむしろ常時組み込みです。