動機
QUIC のことを調べてはすぐに記憶から霧散して、いつも同じことを調べてコンピューティングリソースを無駄にしているので自分用にまとめ。
大まかに覚えていることまとめ
- QUIC とは
- RFC 9000 で標準化されたトランスポートプロトコル (2021 年 5 月)
- 元々は Google が開発し、 IETF で標準化された
- UDP 上のトランスポートプロトコル
- TCP はカーネル実装のため OS アップデートが必要で開発イテレーションが遅い
- UDP 上でユーザースペース実装することで迅速な改善が可能
- HTTP/2 で解決できなかった Head of Line ブロッキング問題を回避できる
- 0-RTT ハンドシェイク
- 以前接続したことのあるサーバーに対しては、最初のパケットからデータを送信できる
- TCP + TLS では 1-RTT〜2-RTT 必要だったのが 0-RTT で接続可能
- コネクションマイグレーション
- IP アドレスが変わっても (WiFi → モバイル回線など) コネクションを維持できる
- Connection ID で接続を識別するため、 IP/ポートが変わっても継続可能
- 暗号化がデフォルト
- TLS 1.3 が組み込まれており、すべての通信が暗号化される
- TCP のように平文での通信はできない
- HTTP/3 とは
- QUIC 上で動作する HTTP の次世代バージョン (RFC 9114)
- HTTP/1.1 → TCP 上
- HTTP/2 → TCP 上 (多重化あり、だが TCP レベルで HoL ブロッキング)
- HTTP/3 → QUIC (UDP) 上 (多重化あり、 HoL ブロッキング回避)
- HTTP/2 の機能 (ヘッダ圧縮、サーバープッシュなど) を引き継ぎつつ、 QUIC のメリットを享受
すぐ曖昧になることまとめ
- QUIC Datagram とは
- RFC 9221 で定義されている QUIC の拡張機能
- QUIC ストリームの信頼性保証 (再送・順序保証) を使わず、 UDP のように信頼性のない (unreliable) データ転送を可能にする
- 低遅延が重要なユースケース (リアルタイムゲーム、ライブストリーミング、 VoIP など) に適している
- QUIC のコネクション確立・暗号化のメリットは享受しつつ、データグラム単位で送受信できる
- WebTransport とは
- HTTP/3 (QUIC) をベースにした Web 向けトランスポート層 API
- WebSocket の後継的な位置づけで、より低遅延かつ柔軟な双方向通信を実現
- サーバーとクライアント間で複数のストリームを多重化できる
- 以下の 2 つの API を提供:
- WebTransport Datagram API とは
- QUIC Datagram を利用した信頼性のないデータ転送 API
- UDP みたいなやつ
- 順序保証なし、再送なし
- パケットロスを許容できるが低遅延が重要なユースケース向け (ゲームの位置情報、ビデオフレームなど)
- WebTransport Stream API とは
- QUIC Stream を利用した信頼性のあるデータ転送 API
- TCP みたいなやつ
- 順序保証あり、再送あり
- 複数の独立したストリームを同時に開けるため、 1 つのストリームが詰まっても他に影響しない (HoL ブロッキング回避)