QUIC

QUIC
	通信プロトコル
目的	汎用
開発者	IETF、Google
導入	2012年10月12日（14年前）
OSI階層	トランスポート層
RFC	RFC 9000、RFC 8999、RFC 9001、RFC 9002

QUIC（クイック）は、汎用のトランスポート層の通信プロトコルである。GoogleのJim Roskindによって設計され、2012年に実装・デプロイが行われ、実験が広まっていった2013年に公表され、その後IETFでの標準化が進められた。GoogleのQUICとIETFのQUICを区別して、それぞれgQUIC、iQUICと呼称することもある。QUICはChromeウェブブラウザからGoogleのサーバーへの全コネクションの半分以上で利用されている。デフォルトでは有効にされていないが、Microsoft Edge、Firefox、Safariでも実装されている。

QUICは、User Datagram Protocol（UDP）上の2つのエンドポイント間の多重化接続の集合体に対応しており、TLS/SSLと同等のセキュリティ保護を提供するだけでなく、接続と転送のレイテンシ削減やネットワーク輻輳を避けるために各方向で帯域幅（英語版）推定を行う。主な目標は現在TCPを使用するウェブアプリケーションの接続指向を最適化することである。

2015年6月、標準化のためにQUICの仕様のInternet DraftがIETFに提出された。QUIC working groupは2016年に設立された。2018年10月、IETFのHTTP Working GroupとQUIC Working Groupは共同で、世界標準を作成することに先駆けて、HTTP mapping over QUICを「HTTP/3」と呼ぶことを決定した。2021年5月、IETFは最終的にQUICをRFC 9000とそれをサポートするRFC 8999、RFC 9001、RFC 9002によって標準化した。

詳細

TCPの改善はGoogleにとって長期的な目標であり、QUICの目的は独立したTCP接続と同等に近づけることだが、できるだけレイテンシを削減（目標はラウンドトリップタイム無しの一般的な接続）とSPDY対応の推進である。もしQUICの機能の効果が実証されたら、TCPやTLSの後継バージョンにその知見を反映させることができる。

QUIC開発の動機の1つが、TCPにおけるシングルパケットの遅延がSPDYストリームの集合体全体でヘッド・オブ・ライン・ブロッキング（英語版）を引き起こす事実である。QUICでは、TCPを使用せず多重化に対応することで、パケットの遅延や破棄が発生しても影響を受けるのは関係するストリームのみに抑えられるようにしている。

物理的な制約（光速等）により定められるラウンドトリップタイムを短縮することは現在の科学的知見では不可能と言われており、それ以外で通信のレイテンシを減らす方法は通信拠点間のメッセージの往復（ラウンドトリップ）の回数を少なくすることである。QUICで行われる作業のほとんどはハンドシェイクの段階、暗号化のセットアップ、初期データの要求を含む新たな接続が来た時に必要なラウンドトリップを減らすことに集中されている。例として、1度接続したことのあるサーバーに対するレイテンシ無し (0-RTT)での接続の確立（最良の場合）が挙げられる。

QUICでは、暗号化ブロック境界やパケット境界を整列することでパケット損失（英語版）の影響を低減する。TCPが輻輳を避けるために輻輳ウインドウ（英語版）を使い（TCP輻輳回避アルゴリズム（英語版）を参照）、多重化接続には対応してないことに対し、QUICには検討中ながら現代的な技術の集合体がある。テストされた技術にはパケットペーシング（帯域幅推定をしながら）や積極的かつ推論的な再送（エラー訂正や初期の暗号化ネゴシエーションのような最も重要なパケットの重複したコピーを送信する）がある。なお、前方誤り訂正のように、ドラフト段階で採用していたものの、十分な効果が見られなかったため取り除かれた機能もある。

冗長なデータ転送（ヘッダなど）の削減や圧縮はより高レベルなアプリケーションプロトコル（SPDYのような）で実現可能としている。

接続（コネクション）

QUICは2者間のコネクション指向（英語版）のプロトコルである。したがって、QUICでは接続（コネクション）を確立したうえでデータの送受信が行われる。

それぞれの接続は接続ID（コネクションID）で識別される。通信を行う両者それぞれが接続IDを生成し、自身が生成するものを送信元接続ID (Source Connection ID)、相手側が生成するものを送信先接続ID (Destination Connection ID)と呼称する。なお、接続IDは必要に応じて変更しうる。

接続IDによって識別するため、TCPと異なりIPアドレス・ポート番号が変化しても接続が維持可能である。IPアドレス・ポート番号の変化に伴う処理をコネクションマイグレーションと言う。

ストリーム

QUICにおけるストリーム (Streams)とは、QUIC接続の中でアプリケーションデータの送受信を行う通信路である。1本のQUIC接続の中で、複数のストリームを多重化し、それぞれ並行してデータを伝送できる。各ストリームは62ビットの整数値によるストリームIDによって区別される。ストリームは、サーバー・クライアントいずれからも確立でき、1方向の伝送を行うストリームと双方向に伝送を行えるストリームがある。

QUICのストリームは、（TCPのように）順序性のあるバイト指向ストリームであり、メッセージの境界が維持される保証はない。

データグラム

QUIC接続のもとで、アプリケーションデータを送受信する2種類目の方法がデータグラムである。データグラムはRFC 9221で拡張として提起されているもので、UDPやDTLSのように信頼性のないデータの転送を目的としている。

フロー制御などはないものの、輻輳制御は行われる。

採用

QUIC上のアプリケーション層プロトコルとして、まずHTTPを利用可能にする標準化が進められている。このQUICを利用するHTTPの名称はHTTP/3となる予定である。

ブラウザ対応

QUICのコードは、2012年からGoogle Chrome内で実験的に開発され、Chromiumバージョン29（2013年8月20日公開）の一部として発表された。現在は、ChromiumおよびChromeでデフォルトで有効になっている。

Firefoxは2021年5月に対応した。

Appleは、2020年4月のSafari Technology Preview 104でWebKit engineに実験的サポートを追加した。正式なサポートはmacOS Big SurおよびiOS 14に同梱されたSafari 14で追加されたが、この機能は手動で有効にする必要がある。

クライアント対応

Androidアプリケーションでは、Google Play Services経由でロード可能なモジュールとして、QUIC向けのcronetライブラリが利用できる。

2019年9月11日にリリースされたcURL 7.66は、HTTP/3を（したがってQUICも）サポートする。

2020年10月、 FacebookはInstagramを含む各種アプリおよびサーバーインフラストラクチャをQUICにマイグレートすることに成功し、すでに75%のインターネットトラフィックがQUICを使用していることを発表した。YouTubeやGmailを含むGoogleのすべてのモバイルアプリは、QUICをサポートしている。UberのモバイルアプリもQUICを使用している。

サーバー対応

2017年現在^[update]、活発にメンテナンスされている実装が複数存在する。GoogleのサーバーはQUICをサポートしており、プロトタイプのサーバーを公表している。Akamai Technologiesは2016年7月からQUICをサポートしている。quic-goと呼ばれるGo実装も利用でき、Caddyサーバーの実験的なQUICサポートに活用されている。2017年7月11日、LiteSpeed Technologiesはロードバランサー（WebADC）とLiteSpeed Web Server（英語版）の製品でQUICの正式なサポートを開始した。2019年10月 (2019-10)現在^[update]、88.6%のQUIC対応ウェブサイトでLiteSpeedが使用されており、10.8%はNginxが使用されている。初期にはGoogleのサーバーのみがHTTP-over-QUIC接続をサポートしていたが、Facebookも2018年にこの技術を利用するようになった。CloudflareはQUICのサポートを2018年以来ベータ版として提供している。2021年3月 (2021-03)現在^[update]、全ウェブサイトの5.0%のがQUICを使用している。Microsoft Windows Server 2022は、HTTP/3とSMB over QUICプロトコルを、MsQuicを利用して対応している。CitrixのApplication Delivery Controller（Citrix ADC、NetScaler）は、バージョン13から、QUICプロキシとしても機能する。

さらに、複数の古いコミュニティプロジェクトが存在する。libquicは、ChromiumのQUIC実装を抽出し、必要な依存関係を最小化するように修正したライブラリである。libquicにはgoquicと呼ばれるGoバインディングがある。また、quic-reverse-proxyと呼ばれるDockerイメージが存在し、これは、QUICのリクエストを、オリジンサーバーが理解できる単純なHTTPリクエストに変換するリバースプロキシサーバーとして動作する。

.NET 5には、MsQuicライブラリを使用したQUICの実験的サポートが導入された。

その他のプロトコル

DNSでの利用がRFC 9250 DNS over Dedicated QUIC Connectionsで規定されている。また、マイクロソフトはSMBをQUICに対応させている。

このほか、SSH、WebRTCといったアプリケーション層プロトコルでもQUICを利用可能にすることが検討されている。

欠点

QUICではACKパケットなど制御情報も含めて暗号化されているためにTCPアクセラレーションのような手段を用いてRTTを減少させることが出来ない。

名称

当初QUICはQuick UDP Internet Connectionsの略称であるとされていたが、IETFでは何かの略語ではないということとなっている。

ソースコード

Quicを実装したソフトウェア（ライブラリ）に関する情報がImplementations · quicwg/base-drafts Wiki · GitHubに掲載されている。

GoogleによるコードはBSDライセンスで公開されていて、ライセンスファイルにも明記されている。Chromiumプロジェクトのウェブサイトでコード全文が閲覧可能かつ、Gitリポジトリとしても公開されている。