QUIC
QUIC（クイック）は、Googleのエンジニア、ジム・ロスキンドによって設計された、汎用的なトランスポート層プロトコルです。2012年に実装とテストが開始され、2013年に公表されました。その後、IETF（Internet Engineering Task Force）で標準化が進められ、Google版QUICをgQUIC、IETF版QUICをiQUICと呼んで区別することがあります。現在、Google ChromeブラウザとGoogleサーバー間の接続の半分以上でQUICが利用されており、Microsoft Edge、Firefox、Safariといった主要ブラウザでも実装が進んでいます。
QUICは、UDP上に多重化された接続を確立し、TLS/SSLと同等のセキュリティを提供します。また、接続とデータ転送のレイテンシを削減し、ネットワーク輻輳を避けるために、各方向で帯域幅を推定する機能を備えています。主な目的は、TCPを使用するWebアプリケーションの接続性能を最適化することです。
2015年6月、IETFにQUICの仕様に関するインターネットドラフトが提出され、2016年にはQUICワーキンググループが設立されました。2018年10月には、HTTPワーキンググループとQUICワーキンググループが共同で、QUIC上でのHTTPマッピングを「HTTP/3|HTTP_3」と呼ぶことを決定しました。そして、2021年5月、IETFはQUICを正式に標準化し、RFC 9000として公開しました。
QUICの開発は、TCPの改善を目指すGoogleの長期的な目標の一環として始まりました。QUICの主な目的は、TCP接続と同等の機能を提供しつつ、レイテンシを可能な限り削減すること、具体的には、ラウンドトリップタイム（RTT）なしの接続を実現すること、そしてSPDY（HTTP/2|HTTP_2の前身プロトコル）との互換性を促進することです。QUICの技術が効果を発揮すれば、その知見はTCPやTLSの後継バージョンに反映される可能性があります。
TCPでは、単一パケットの遅延がSPDYストリーム全体でヘッド・オブ・ライン・ブロッキングを引き起こすという問題がありました。QUICは、多重化に対応することで、パケットの遅延や破棄による影響を関連ストリームのみに限定します。
物理的な制約によりRTTを短縮することは困難ですが、QUICは通信拠点の間のラウンドトリップ回数を減らすことでレイテンシを削減します。特に、QUICではハンドシェイクの段階、暗号化のセットアップ、初期データ要求といった新しい接続に必要なラウンドトリップを減らすことに注力しています。例えば、一度接続したことがあるサーバーに対しては、0-RTT（レイテンシなし）で接続を確立できる場合があります。
QUICは、パケット境界を揃えることでパケット損失の影響を軽減します。TCPが輻輳ウインドウを使って輻輳を避けるのに対し、QUICには、パケットペーシング（帯域幅を推定しながらのパケット送信）や、積極的にパケットを再送する（エラー訂正や初期の暗号化ネゴシエーションの重要なパケットの複製を送信する）といった、より現代的な技術が組み込まれています。ただし、前方誤り訂正のように効果が不十分と判断され、採用が見送られた機能もあります。
冗長なデータ転送の削減や圧縮は、SPDYのようなアプリケーションプロトコルで行うことが可能です。
QUICは、コネクション指向のプロトコルです。接続を確立した上でデータの送受信を行います。各接続は接続IDで識別され、通信を行う双方が接続IDを生成し、送信元と送信先のIDを区別します。接続IDは必要に応じて変更でき、TCPとは異なり、IPアドレスやポート番号が変化しても接続を維持できます（コネクションマイグレーション）。
QUICにおけるストリームは、アプリケーションデータの送受信を行う通信路です。1つのQUIC接続の中で複数のストリームを多重化し、並行してデータ転送ができます。ストリームは、62ビットの整数値によるIDによって識別されます。ストリームはサーバーとクライアントのどちらからも確立でき、一方向の伝送と双方向の伝送が可能です。QUICのストリームは順序性のあるバイト指向ストリームですが、メッセージの境界が維持される保証はありません。
データグラムは、QUIC接続においてアプリケーションデータを送受信するもう一つの方法です。これは、RFC 9221で拡張として提案されており、UDPやDTLSのように信頼性のないデータ転送を目的としています。データグラムはフロー制御は行いませんが、輻輳制御は行われます。
QUICは、まずHTTP上で利用可能にするための標準化が進められており、QUICを利用したHTTPはHTTP/3|HTTP_3として知られています。ブラウザでは、Google Chromeが2013年からQUICを実装し、現在ではデフォルトで有効になっています。Firefoxは2021年5月、SafariはmacOS Big SurとiOS 14で手動で有効化することでQUICを利用できます。
クライアントでは、AndroidアプリでGoogle Play Servicesからロードできるcronetライブラリを通じてQUICが利用可能です。cURL 7.66以降もHTTP/3|HTTP_3（QUIC）に対応しています。また、FacebookはInstagramを含むアプリとサーバーインフラストラクチャをQUICに移行させ、すでに75%のインターネットトラフィックがQUICを使用しています。YouTube、Gmail、UberのモバイルアプリもQUICをサポートしています。
サーバー側では、Google、Akamai、LiteSpeed TechnologiesなどがQUICをサポートしており、Microsoft Windows Server 2022は、HTTP/3|HTTP_3とSMB over QUICに対応しています。2019年10月時点で、QUIC対応ウェブサイトの88.6%がLiteSpeedを使用し、10.8%がNginxを使用しています。さらに、Cloudflare、Citrixの製品もQUICをサポートしています。
QUICは、DNS（RFC 9250）やSMB（マイクロソフト）などのプロトコルでも利用可能です。SSHやWebRTCなどのアプリケーション層プロトコルでの利用も検討されています。
QUICの欠点として、ACKパケットなど制御情報を含めて暗号化されているため、TCPアクセラレーションのような手段でRTTを減少させることができない点が挙げられます。
当初、QUICはQuick UDP Internet Connectionsの略称とされていましたが、IETFでは何の略語でもないとされています。QUICを実装したソフトウェア（ライブラリ）に関する情報はGitHubのWikiで公開されています。GoogleによるコードはBSDライセンスで公開されており、ChromiumプロジェクトのウェブサイトやGitリポジトリで閲覧可能です。
QUICは、UDP上に多重化された接続を確立し、TLS/SSLと同等のセキュリティを提供します。また、接続とデータ転送のレイテンシを削減し、ネットワーク輻輳を避けるために、各方向で帯域幅を推定する機能を備えています。主な目的は、TCPを使用するWebアプリケーションの接続性能を最適化することです。
標準化とHTTP/3|HTTP_3
2015年6月、IETFにQUICの仕様に関するインターネットドラフトが提出され、2016年にはQUICワーキンググループが設立されました。2018年10月には、HTTPワーキンググループとQUICワーキンググループが共同で、QUIC上でのHTTPマッピングを「HTTP/3|HTTP_3」と呼ぶことを決定しました。そして、2021年5月、IETFはQUICを正式に標準化し、RFC 9000として公開しました。
QUICの設計思想
QUICの開発は、TCPの改善を目指すGoogleの長期的な目標の一環として始まりました。QUICの主な目的は、TCP接続と同等の機能を提供しつつ、レイテンシを可能な限り削減すること、具体的には、ラウンドトリップタイム（RTT）なしの接続を実現すること、そしてSPDY（HTTP/2|HTTP_2の前身プロトコル）との互換性を促進することです。QUICの技術が効果を発揮すれば、その知見はTCPやTLSの後継バージョンに反映される可能性があります。
TCPでは、単一パケットの遅延がSPDYストリーム全体でヘッド・オブ・ライン・ブロッキングを引き起こすという問題がありました。QUICは、多重化に対応することで、パケットの遅延や破棄による影響を関連ストリームのみに限定します。
物理的な制約によりRTTを短縮することは困難ですが、QUICは通信拠点の間のラウンドトリップ回数を減らすことでレイテンシを削減します。特に、QUICではハンドシェイクの段階、暗号化のセットアップ、初期データ要求といった新しい接続に必要なラウンドトリップを減らすことに注力しています。例えば、一度接続したことがあるサーバーに対しては、0-RTT（レイテンシなし）で接続を確立できる場合があります。
QUICの輻輳制御
QUICは、パケット境界を揃えることでパケット損失の影響を軽減します。TCPが輻輳ウインドウを使って輻輳を避けるのに対し、QUICには、パケットペーシング（帯域幅を推定しながらのパケット送信）や、積極的にパケットを再送する（エラー訂正や初期の暗号化ネゴシエーションの重要なパケットの複製を送信する）といった、より現代的な技術が組み込まれています。ただし、前方誤り訂正のように効果が不十分と判断され、採用が見送られた機能もあります。
冗長なデータ転送の削減や圧縮は、SPDYのようなアプリケーションプロトコルで行うことが可能です。
コネクションとストリーム
QUICは、コネクション指向のプロトコルです。接続を確立した上でデータの送受信を行います。各接続は接続IDで識別され、通信を行う双方が接続IDを生成し、送信元と送信先のIDを区別します。接続IDは必要に応じて変更でき、TCPとは異なり、IPアドレスやポート番号が変化しても接続を維持できます（コネクションマイグレーション）。
QUICにおけるストリームは、アプリケーションデータの送受信を行う通信路です。1つのQUIC接続の中で複数のストリームを多重化し、並行してデータ転送ができます。ストリームは、62ビットの整数値によるIDによって識別されます。ストリームはサーバーとクライアントのどちらからも確立でき、一方向の伝送と双方向の伝送が可能です。QUICのストリームは順序性のあるバイト指向ストリームですが、メッセージの境界が維持される保証はありません。
データグラム
データグラムは、QUIC接続においてアプリケーションデータを送受信するもう一つの方法です。これは、RFC 9221で拡張として提案されており、UDPやDTLSのように信頼性のないデータ転送を目的としています。データグラムはフロー制御は行いませんが、輻輳制御は行われます。
採用状況
QUICは、まずHTTP上で利用可能にするための標準化が進められており、QUICを利用したHTTPはHTTP/3|HTTP_3として知られています。ブラウザでは、Google Chromeが2013年からQUICを実装し、現在ではデフォルトで有効になっています。Firefoxは2021年5月、SafariはmacOS Big SurとiOS 14で手動で有効化することでQUICを利用できます。
クライアントでは、AndroidアプリでGoogle Play Servicesからロードできるcronetライブラリを通じてQUICが利用可能です。cURL 7.66以降もHTTP/3|HTTP_3（QUIC）に対応しています。また、FacebookはInstagramを含むアプリとサーバーインフラストラクチャをQUICに移行させ、すでに75%のインターネットトラフィックがQUICを使用しています。YouTube、Gmail、UberのモバイルアプリもQUICをサポートしています。
サーバー側では、Google、Akamai、LiteSpeed TechnologiesなどがQUICをサポートしており、Microsoft Windows Server 2022は、HTTP/3|HTTP_3とSMB over QUICに対応しています。2019年10月時点で、QUIC対応ウェブサイトの88.6%がLiteSpeedを使用し、10.8%がNginxを使用しています。さらに、Cloudflare、Citrixの製品もQUICをサポートしています。
その他の利用と欠点
QUICは、DNS（RFC 9250）やSMB（マイクロソフト）などのプロトコルでも利用可能です。SSHやWebRTCなどのアプリケーション層プロトコルでの利用も検討されています。
QUICの欠点として、ACKパケットなど制御情報を含めて暗号化されているため、TCPアクセラレーションのような手段でRTTを減少させることができない点が挙げられます。
名称とソースコード
当初、QUICはQuick UDP Internet Connectionsの略称とされていましたが、IETFでは何の略語でもないとされています。QUICを実装したソフトウェア（ライブラリ）に関する情報はGitHubのWikiで公開されています。GoogleによるコードはBSDライセンスで公開されており、ChromiumプロジェクトのウェブサイトやGitリポジトリで閲覧可能です。
関連プロトコル
- - HTTP/3|HTTP_3
- - HTTP/2|HTTP_2
- - SPDY
- - DTLS (Datagram Transport Layer Security)
- - RUDP (Reliable User Datagram Protocol)
- - SCTP (Stream Control Transmission Protocol)
- - RTMFP (Real Time Media Flow Protocol)
- - UDT (UDP-based Data Transfer Protocol)
外部リンク
- - RFC 8999: QUICのバージョンに依存しないプロパティ
- - RFC 9000: QUICの仕様
- - RFC 9001: QUICのTLS利用
- - RFC 9002: QUICの損失検出と輻輳制御
- - RFC 9221: QUICの信頼性の低いデータグラム拡張
- - QUICのデザインドキュメントと仕様
- - QUIC FAQ for Geeks
- - Linux Weekly NewsのQUICに関する記事
- - Chromiumのソースコード
- - Chromium Blog: QUICの実験について
- - YouTube動画: QUICの解説
もう一度検索
【記事の利用について】
タイトルと記事文章は、記事のあるページにリンクを張っていただければ、無料で利用できます。
※画像は、利用できませんのでご注意ください。
【リンクついて】
リンクフリーです。