QUIC

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

QUICは、User Datagram Protocol上の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を9000}}とそれをサポートする8999}}、9001}}、9002}}によって標準化した。

1. 詳細
-----

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

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

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

QUICでは、暗号化ブロック境界やパケット境界を整列することでパケット損失の影響を低減する。TCPが輻輳を避けるために輻輳ウインドウを使い、多重化接続には対応してないことに対し、QUICには検討中ながら現代的な技術の集合体がある。テストされた技術にはパケットペーシングや積極的かつ推論的な再送がある。なお、前方誤り訂正のように、ドラフト段階で採用していたものの、十分な効果が見られなかったため取り除かれた機能もある。

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

1.1. 接続
-------

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

それぞれの接続は接続IDで識別される。通信を行う両者それぞれが接続IDを生成し、自身が生成するものを送信元接続ID 、相手側が生成するものを送信先接続ID と呼称する。 なお、接続IDは必要に応じて変更しうる。

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

1.2. ストリーム
----------

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

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

1.3. データグラム
-----------

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

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

2. 採用
-----

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

2.1. ブラウザ対応
-----------

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

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

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

2.2. クライアント対応
-------------

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

2019年9月11日にリリースされたcURL 7.66は、HTTP/3をサポートする。

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

2.3. サーバー対応
-----------

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

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

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

2.4. その他のプロトコル
--------------

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

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

3. 欠点
-----

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

4. 名称
-----

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

5. ソースコード
---------

Quicを実装したソフトウェアに関する情報が[1]に掲載されている。

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

6. 脚注
-----

7. 関連項目
-------

HTTP/3
HTTP/2
SPDY
Datagram Transport Layer Security 
Reliable User Datagram Protocol 
Stream Control Transmission Protocol 
Real Time Media Flow Protocol 
UDP-based Data Transfer Protocol  – UDP型転送プロトコル

8. 外部リンク
--------

8999}} Version-Independent Properties of QUIC
9000}} QUIC: A UDP-Based Multiplexed and Secure Transport
9001}} Using TLS to Secure QUIC
9002}} QUIC Loss Detection and Congestion Control
9221}} An Unreliable Datagram Extension to QUIC
[2]
[3]
[4]
[5]
https://src.chromium.org/viewvc/chrome?revision=162259&view=revision
[6]