HTTP/2とHTTP/3(QUIC)の違いとHead-of-Line Blocking解消の仕組み
HTTP Performance Network Frontend
結論
パケットロス時の巻き添え停止（HOL Blocking）を防ぐため HTTP/3 (QUIC) を導入します。
# HTTP/3 (QUIC) 有効化を示すレスポンスヘッダー例
Alt-Svc: h3=":443"; ma=86400Cloudflare / RFC 9114公式仕様：HTTP/2 と HTTP/3 の比較マトリクス
| 評価軸 | HTTP/2 | HTTP/3 |
|---|---|---|
| トランスポート層プロトコル | TCP | QUIC (UDP ベース) |
| パケットロス時の挙動 | 全ストリームが再送完了まで巻き添え停止 | 損失した 1ストリームのみ停止（他は即時通信） |
| Head-of-Line (HOL) Blocking | ❌ TCP層で依然発生する | ◯ 完全解消（ストリームが完全独立） |
| ハンドシェイク接続確立 | 2-RTT (TCP + TLS 1.3) | 0-RTT 〜 1-RTT (QUIC統合暗号) |
| 接続切り替え (Wi-Fi ↔ 5G) | 切断・再接続が必要 | Connection ID により切断なしで継続 |
実際に起こる障害：HTTP/2 での TCP Head-of-Line (HOL) Blocking 事故
HTTP/2 は 1つの TCP 接続上に複数のリクエスト（画像、CSS、JS）を「多重化（Multiplexing）」して送信することで高速化を達成しています。
しかし、パケットロス率が 1〜2% 発生するモバイル回線環境において、TCP は「すべてのデータが順番通り正しく届くこと」を全ストリームに対して強制します。
そのため、たった 1つの画像データのパケットが途中で欠損しただけで、まったく関係のない別の JavaScript や CSS の読み込みまで全停止（Head-of-Line Blocking）し、画面全体が数秒間白くフリーズする大障害 が発生します。
導入の手順
- Web サーバー（Nginx, Caddy, Cloudflare, AWS CloudFront）で HTTP/3 (QUIC) サポートを有効化する
- レスポンスヘッダーに
Alt-Svc: h3=":443"; ma=86400を付与し、ブラウザへ HTTP/3 へのアップグレードを通知する - ブラウザ（Chrome, Firefox, Safari）が UDP 443 ポート経由で HTTP/3 ネゴシエーションに成功したことを DevTools の Network タブ（Protocol:
h3）で確認する