はじめに
Webサイトの表示では、通信相手との接続を確立し、データの欠損や順序の入れ替わりに対応しながら、安全に情報を送る必要があります。従来のWeb通信ではTCPとTLSを組み合わせてきましたが、接続の確立や複数の通信を扱う方法には改善できる点があります。
QUICは、UDPデータグラムで運ばれながら、QUIC自身が接続状態、信頼性、輻輳制御、暗号化された通信を提供するトランスポートプロトコルです。この記事では、QUICの位置づけと、UDP・TCP・HTTP/3との関係、主な仕組みを解説します。
この記事で分かること
- QUICがどのようなトランスポートプロトコルか
- UDPを利用しながら接続状態や信頼性を管理できる理由
- TLS 1.3、ストリーム、Connection IDの役割
- QUICとTCPの主な違い
- QUICとHTTP/3の関係
QUICとは
QUICは、UDPデータグラムで運ばれる、セキュアなコネクション型のトランスポートプロトコルです。QUICは英単語の頭文字を並べた略称ではなく、プロトコルの名称です。
UDPはQUICパケットをネットワーク上で運ぶ土台として使われます。一方、通信相手との接続状態、データの到着確認、失われた情報の再送、フロー制御、輻輳制御、暗号化などはQUICが担当します。そのため、UDPを利用していても、QUICの通信全体がコネクションレス型になるわけではありません。
QUICの主な仕組みと役割は、次のように整理できます。
| 仕組み | 主な役割 |
|---|---|
| UDPによる転送 | QUICパケットを既存のネットワーク上で運ぶ |
| コネクション管理 | 通信する端点間の状態を管理する |
| 複数のストリーム | 1つの接続内で複数のデータの流れを扱う |
| 損失検出と輻輳制御 | 損失を検出して必要な情報を再送し、混雑に応じて送信量を調整する |
| TLS 1.3との統合 | 通信相手の認証とデータの機密性・完全性を提供する |
| Connection ID | IPアドレスやポート番号が変わった後も接続を識別する |
QUICとUDP・TCPの関係
UDPはQUICパケットを運ぶ土台
UDPは、接続確立、再送、順序制御を行わず、データグラム単位で情報を送るプロトコルです。QUICは、1つ以上のQUICパケットをUDPデータグラムに格納して送受信します。
QUICがUDPを利用する理由の一つは、既存のOSやネットワークで広く利用できるUDP上に、新しいトランスポート機能を実装しやすくすることです。ただし、UDPを利用するだけで通信が高速になるわけではありません。実際の性能は、通信経路、混雑状況、アプリケーションの利用方法などによって変わります。
TCPとUDPを含むトランスポート層の役割は、トランスポート層とは?役割とTCP・UDPの違いを分かりやすく解説で解説しています。
接続や信頼性はQUIC自身が提供する
TCPは、順序どおりの1本のバイトストリームとしてデータをアプリケーションへ渡します。データの一部が失われると、その部分が再送されるまで、後続データをアプリケーションへ渡せない場合があります。
QUICも失われた情報を再送し、各ストリーム内のデータを順序どおりに届けますが、1つの接続内に複数の独立したストリームを持てます。あるストリームのデータが失われても、失われたパケットに含まれていない別のストリームは処理を続けられます。
QUICはUDPで運ばれますが、QUIC自体は接続状態を管理するコネクション型です。接続状態と信頼性を分けて考える方法は、コネクション型とコネクションレス型の違い|TCP・UDPの具体例で解説を参照してください。
QUICの主な仕組み
TLS 1.3を統合して安全な接続を確立する
QUICはTLS 1.3を利用し、通信相手の認証と、データの機密性・完全性を提供します。TCP上でTLSを別に開始する構成とは異なり、QUICでは暗号化のためのハンドシェイクとトランスポートの接続確立が連携します。
この構造により、接続を確立してアプリケーションデータを送信できるまでの待ち時間を抑えられます。過去に接続した相手との再接続では、条件を満たす場合に0-RTTで早期データを送れることもあります。
ただし、0-RTTは常に利用できる機能ではなく、リプレイ攻撃の影響を受ける可能性があります。そのため、アプリケーションは0-RTTで安全に扱える操作やデータを選ぶ必要があります。
複数のストリームを独立して扱う
QUICのストリームは、順序が管理されたデータの流れです。1つのQUIC接続内に複数のストリームを作り、それぞれのデータを並行して送受信できます。
TCP上で複数の処理を多重化する場合、TCPのバイトストリームでパケット損失が発生すると、無関係な処理も再送待ちになることがあります。QUICではストリームごとにデータの順序を管理するため、損失の影響を関係するストリームに限定できます。
ただし、1つのQUICパケットに複数ストリームのデータが含まれていた場合、そのパケットを失うと、含まれていたすべてのストリームが再送待ちになります。「パケットを一つ失っても、他の通信には一切影響しない」という意味ではありません。
Connection IDで経路の変更に対応する
TCPの接続は、送信元と宛先のIPアドレスおよびポート番号によって識別されます。そのため、端末がWi-Fiからモバイル回線へ切り替わるなどしてIPアドレスが変わると、従来の接続を継続できないことがあります。
QUICはConnection IDを使って接続を識別します。ハンドシェイクが確認された後にクライアントの通信経路が変わった場合でも、新しい経路を検証できれば、同じQUIC接続を継続できます。これはNATのアドレスやポートの対応が変わるNATリバインディングへの対応にも利用されます。
ただし、経路が変われば必ず接続を維持できるわけではありません。接続移行にはConnection IDと新しい経路の検証が必要で、利用できるネットワークや実装の条件にも左右されます。
QUICとHTTP/3の関係
HTTP/3は、HTTPの通信をQUIC上で実現するためのプロトコルです。HTTPのリクエストとレスポンスをQUICのストリームへ割り当て、QUICが提供する多重化、フロー制御、暗号化、損失回復などを利用します。
QUICとHTTP/3は同じものではありません。QUICはアプリケーション間のデータ転送を担当する汎用的なトランスポートプロトコルで、HTTP/3はその上でHTTPの意味やメッセージ形式を扱います。
HTTP/3では、通常、1組のリクエストとレスポンスに1つの双方向QUICストリームを使用します。あるストリームが損失の影響を受けても、別のリクエストを扱うストリームは処理を続けられるため、TCP上のHTTP/2で発生する接続全体の待ちを避けやすくなります。
QUICを理解するときの注意点
QUICは、UDPを利用することだけを理由に高速になるプロトコルではありません。低遅延な接続確立、複数ストリーム、接続移行などの仕組みを組み合わせ、アプリケーションが必要とする通信を効率化します。
また、ネットワーク機器やファイアウォールがUDP通信を制限している環境では、QUICを利用できない場合があります。その場合、HTTPではTLSを利用するTCP上の通信へ切り替えることがあります。
この記事では、QUICの位置づけを理解するために必要な範囲を扱いました。QUICパケットやフレームの詳細な形式、損失検出アルゴリズム、個別の輻輳制御アルゴリズムは、独立した発展知識です。
まとめ
QUICは、UDPデータグラムで運ばれながら、QUIC自身が接続状態、信頼性、輻輳制御、暗号化された通信を提供するトランスポートプロトコルです。
- QUICはTCPの改良版ではなく、独立したコネクション型のプロトコル
- UDPはQUICパケットを運び、接続や信頼性はQUICが管理する
- TLS 1.3を統合し、安全性と接続確立を一体として扱う
- 複数ストリームにより、損失の影響を関係するストリームへ限定できる
- Connection IDを使い、条件を満たせば経路変更後も接続を継続できる
- HTTP/3はQUIC上でHTTPを扱うアプリケーションプロトコル
QUICを理解するときは、「UDPを利用しているからコネクションレス型」と判断せず、どのプロトコルが接続状態と信頼性を担当しているかを確認することが重要です。


コメント