QUICとは
QUICは、UDP上で暗号化、信頼性、複数ストリームを統合し、接続待ち時間を減らす通信プロトコルです。QUIC（クイック）と読みます。開発初期にはQuick UDP Internet Connectionsという展開名が使われましたが、IETF標準ではQUICを固有のプロトコル名として扱います。
OSが提供するUDPを外側の配送に使い、その内側で接続、暗号化、確認応答、損失回復、輻輳制御、複数ストリームを実装します。UDPを使うから信頼性がないのではなく、QUIC自身が用途に合う信頼性を提供します。
QUICの大きな違いは、接続全体を一つの順序付きバイト列にせず、独立したストリームごとに順序を管理することです。一つのストリームで損失が起きても、別ストリームの完成データまで同じ欠落を待つ必要はありません。
パケット、フレーム、ストリームは同じ単位ではない
IP経路を通るUDPデータグラムへ、一つ以上のQUICパケットを収められる
接続ID、パケット番号などのヘッダーと、暗号化されたフレームを持つ
STREAM、ACK、接続終了、最大データ量など目的別の情報を表す
ストリーム内だけ順序をそろえ、片方向・双方向を用途に応じて開く
暗号鍵、輻輳制御、接続ID、接続全体のフロー上限を管理する
HTTP/3などが、どのストリームとフレームを何に使うか定める
TLS 1.3を統合し、通信の大部分を最初から暗号保護する
QUICはTLS 1.3のハンドシェイクを利用し、サーバー認証と鍵合意をトランスポート接続の確立へ組み込みます。TCP接続を作ってから別にTLSを開始する構成ではないため、初回接続で必要な往復を重ねずに済みます。
パケット番号や一部ヘッダーも保護され、多くの制御情報は暗号化されます。一方、接続を届けるためのIP・UDPヘッダー、短い接続IDなどは外側に必要です。0-RTTは再接続を早められますが、TLSと同様にリプレイ可能性を考え、繰り返せない操作を載せません。
ACKは受信パケット範囲を伝え、損失データを新しいパケットで回復する
受信側はACKフレームで受信済みパケット番号の範囲と遅延を返します。送信側は後続ACK、経過時間、往復時間から損失を推定し、まだ必要なSTREAMフレームや制御情報を新しいパケットへ入れ直します。
QUICのパケット番号は単調に進み、再送で同じ番号を使いません。これにより、遅れて届いた元パケットと回復用パケットを区別できます。パケットの到着保証と、ストリームのデータ到着保証を分けて観測することが、QUIC解析の基本です。
ストリーム間の待ち合わせは減るが、ネットワーク容量は共有する
あるストリームの途中が欠ければ、そのストリーム内では後続データの受け渡しを待ちます。しかし、別ストリームの連続したデータはアプリへ渡せます。TCP上に複数の通信を載せた場合に起きる、接続全体のhead-of-line blocking（ヘッド・オブ・ライン・ブロッキング／先頭待ちによる停滞）を減らせます。
接続全体は同じ経路と輻輳制御を共有するため、損失で送信可能量が減れば他ストリームの速度にも影響します。QUICは「損失の影響が一切ない」方式ではありません。ストリーム単位と接続全体のフロー制御で、受信バッファーも守ります。
接続IDにより、IPアドレスが変わっても同じ接続として確かめられる
TCP接続は通常IPアドレスとポートの組へ強く結び付きます。QUICはconnection ID（コネクション・アイディー／接続ID）を使い、Wi-Fiから携帯回線などへ経路が変わっても接続を識別できます。
新しい経路ではPATH_CHALLENGEとPATH_RESPONSEで相手へ到達できることを検証し、送信量制限を守ってから移します。接続IDは負荷分散にも利用できますが、追跡可能性を抑えるため複数IDの切替や廃止を管理します。
UDPが遮断・制限される環境では、別方式へ戻る設計も必要になる
一部の古いファイアウォールやネットワークはUDPを広く制限し、QUIC接続を通さない、短時間でNAT状態を消すなどの挙動をします。サーバーはアンプ攻撃を防ぐため、送信元検証前の送信量も制限します。
QUICを導入するだけで常に高速化するのではなく、往復遅延、損失、UDP到達性、CPU暗号処理、MTU、フォールバックを実測します。HTTP/3では、失敗時にHTTP/2へ戻れることも利用体験の一部です。
仕様の確認資料：RFC 9000「QUIC: A UDP-Based Multiplexed and Secure Transport」、RFC 9001「Using TLS to Secure QUIC」、RFC 9002「QUIC Loss Detection and Congestion Control」