QUICとはUDPをベースとした汎用通信プロトコルである。IETF（Internet Engineering Task Force）が2021年に「RFC 9000」として勧告し、新たなインターネット標準技術となった。2022年に「RFC 9114」にて勧告されたHTTP／3は、トランスポート層プロトコルとしてQUICを採用した。
特徴はHTTP／2のトランスポート層で使われているTCPと比べ、高速化を実現したことだ。TCPを使う場合、サーバーとクライアント間で接続制御情報をやり取りする「3ウェイハンドシェーク」を通じてコネクションを確立してからアプリケーションデータを送信している。QUICではクライアントからサーバーへ送る最初のパケットに制御情報だけでなく送信データ自体を乗せることで、通信に要するやり取りを1回分少なくできる。この機能を「0-RTT（Round-Trip Time）」と呼ぶ。0-RTTはTLS1.3で実装されたものの、相互接続テストが進まずTCPではあまり活用されていないという。
QUICに詳しいIIJ 技術研究所の山本和彦技術開発室室長は「TCPでも最初のパケットからデータを送るというアイデアは昔からあったが、なかなか使えない状態であった」と話す。ファイアウオールなどの中間装置は信頼できる通信以外はすべて遮断する、ホワイトリスト方式を採用しているものも多い。端末間の交渉（ネゴシエーション）の最初のパケットに当たるSYNパケットにデータが乗っているとそのパケットを破棄したり、未知のTCPオプションを削除したりする場合がある。
QUICは中間装置による解析や破棄を難しくするための対策を施している。その1つがペイロードを暗号化してパケットのフラグを見えないようにすることだ。「TCPの高速化の取り組みで判明したあらゆる課題がQUICパケットを保護するための予防線として活用されている」（山本室長）。
「QUIC Version 2」の開発も進んでいる。Version 1では最初のパケットに当たるInitialパケットのヘッダーに暗号鍵の生成情報が含まれることから、中間装置がペイロードを比較的容易に復号できるという課題があった。Version 2ではサーバーがクライアントに通信バージョンを伝えること、および鍵の生成元情報を変えることが可能になる。互換性を考慮すると、クライアントは最初Version 1を用いて接続を試行することが想定できる。ネゴシエーションの結果Version 2を使えると判明した場合、クライアント側でバージョンをアップグレードできる。以降の通信では初回と異なる暗号鍵を使用することで、中間装置が復号しにくくなることが期待できる。
山本室長は「Version 2はQUICが今後も進化できるよう、準備を進めるという位置づけだ」と評価する。2022年11月にIESG（Internet Engineering Steering Group）が承認しており、近日中にRFCとして公開される見込みだ。
