HTTP/3とQUICプロトコル
HTTP/3の代表的な実用例
Webブラウザ: Chrome、Firefox、Edge、Safari等のモダンブラウザで標準対応
CDN（Cloudflare、AWS CloudFront等）: 34%以上のトップサイトが採用
REST API: 従来のREST APIもHTTP/3で高速化
Spring Boot / Spring Cloud Gateway: 2024年からHTTP/3対応
WebTransport API: リアルタイムデータ送信に特化
Cloudflareによると、2024年時点で113,000以上のゾーンがHTTP/3を有効化しており、実際の使用例が急速に拡大
QUICの汎用性について
QUICはHTTP/3専用ではない。
QUIC の HTTP以外での利用例
IoTデバイス通信: 低遅延でリアルタイム通信が必要な場面
リアルタイムゲーム: Google Stadiaなどクラウドゲーミング
ビデオストリーミング: YouTube、Meta（Facebook、Instagram、WhatsApp）
チャット・メッセージング: WhatsAppなどでの利用
IoV（Internet of Vehicles）: 自動車間通信での低遅延通信
「QUICはHTTP/3のための高性能、高信頼性、高セキュリティトランスポートプロトコル提供が目標だが、QUIC は非HTTPトラフィックにも適している」
RESTは完全にHTTP/3と互換性あり
HTTP/2とHTTP/3の主要な違い
1. 基盤トランスポート層
HTTP/2: TCP + TLS（別レイヤー）
HTTP/3: QUIC（UDP + 組み込みTLS）
https://scrapbox.io/files/68c617659fc86fa906cda238.png
code:sh
アプリケーション層: REST API / Web アプリケーション
HTTPプロトコル層: HTTP/1.1 / HTTP/2 / HTTP/3
基盤トランスポート層: TCP + TLS / QUIC
ネットワーク層: IP
物理層: Ethernet / WiFi
2. Head-of-Line Blocking問題
HTTP/2: TCPレベルでのブロッキングが発生
HTTP/3: ストリーム単位で独立、パケットロス影響を最小化
3. 接続確立速度
HTTP/2: 3-way handshake + TLS handshake
HTTP/3: 0-RTT接続（再接続時）で大幅な高速化
https://scrapbox.io/files/68c6174ddbf5ac62d877c302.svg
4. パフォーマンス比較
table: Cloudflareの実測データ
項目 HTTP/2 HTTP/3 改善率
Time to First Byte 201ms 176ms 12.4%向上
小サイズページ（15KB） 458ms 443ms 3.3%向上
大サイズページ（1MB） 2.30s 2.33s わずかに劣る
5. ネットワーク切り替え対応
HTTP/2: 接続切断が発生
HTTP/3: Wi-Fi ⟷ セルラー間でシームレスな移行
各HTTPの代表例
HTTP/1.1の代表例: REST API（当時の主流）
HTTP/2の代表例: gRPC（HTTP/2の新機能を活用）
HTTP/3の代表例: 特定のものはなく、既存のWebアプリやREST APIがそのまま高速化
QUICとHTTP/3の関係
QUIC = 基盤トランスポート層のプロトコル HTTP/3 = QUICの上で動くHTTPプロトコル
HTTP/3は「QUIC上で動くHTTP」の正式名称
QUIC単体では他の用途（IoT、ゲーム等）でも使用可能
TCP + TLS（HTTP/2まで）
1. TCP接続確立（3-way handshake）
2. TLS接続確立（別途handshake）
3. HTTPデータ送信開始
QUIC（HTTP/3）
1. QUIC接続確立（TLS組み込み、1回のhandshake）
2. HTTPデータ送信開始
通常の接続確立プロセス
code: HTTP/1.1 & HTTP/2（TCP + TLS）
クライアント → サーバー
1. TCP SYN (1 RTT)
2. TCP SYN-ACK ← サーバー
3. TCP ACK
4. TLS ClientHello (1 RTT)
5. TLS ServerHello ← サーバー
6. TLS Finished (1 RTT)
7. HTTP Request (1 RTT)
8. HTTP Response ← サーバー
合計: 4 RTT (Round Trip Time)
code:HTTP/3（QUIC）初回接続
クライアント → サーバー
1. QUIC Initial + TLS ClientHello (1 RTT)
2. QUIC + TLS ServerHello ← サーバー
3. QUIC + TLS Finished (1 RTT)
4. HTTP Request (1 RTT)
5. HTTP Response ← サーバー
合計: 3 RTT (TCP+TLSより1RTT削減)
0-RTT接続（再接続時）
0-RTT = Zero Round Trip Timeとは、再接続時に事前のhandshakeなしでデータ送信を開始すること。
code:HTTP/3での0-RTT再接続
クライアント → サーバー
1. HTTP Request + 暗号化済みデータ (0 RTT!)
2. HTTP Response ← サーバー
合計: 1 RTT (データ送受信のみ)
初回接続（1-RTT）
クライアントとサーバーが初めて通信
暗号化キーの交換が必要
QUICでもTLS handshakeが必要（ただし統合されているため高速）
再接続時（0-RTT）
以前の接続で暗号化キーを保存
再接続時に保存済みキーを使用してすぐにデータ送信
handshake完了を待たずにHTTPリクエスト送信可能
0-RTTには制限あり：
Replay攻撃のリスク（同じリクエストが重複実行される可能性）
冪等性のあるリクエスト（GET等）でのみ安全
状態変更リクエスト（POST等）では通常使用されない