Wikipedia

QUIC

曖昧さ回避 決済サービスの「QUICPay」とは異なります。

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

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

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

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

詳細

編集

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

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

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

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

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

接続（コネクション）

編集

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

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

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

ストリーム

編集

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

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

データグラム

編集

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

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

採用

編集

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

ブラウザ対応

編集

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

Firefoxは2021年5月に対応した[24][25]。

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

クライアント対応

編集

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

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

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

サーバー対応

編集

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

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

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

その他のプロトコル

編集

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

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

欠点

編集

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

名称

編集

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

ソースコード

編集

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

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

脚注

編集
  1. ^ QUICQuick UDP Internet ConnectionsMultiplexed Stream Transport over UDP, IETF, https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf 
  2. ^ “Experimenting with QUIC”. Chromium Official Blog. 2013年7月16日閲覧。
  3. ^ “QUIC: next generation multiplexed transport over UDP”. YouTube. 2014年4月4日閲覧。
  4. ^ 前田薫 (2018年5月26日). “第3回 TCP＋TLSに代わる高速プロトコル、Google生まれの「QUIC」の特徴と標準化の行方”. 進化するインターネット技術／IETFトピックス2016-17. インプレス. 2018年1月21日閲覧。
  5. ^ “JPNIC News & Views vol.1647【臨時号】第103回IETF報告 [第4弾] トランスポートエリア関連報告 ～HTTP over QUICからHTTP/3への改称～”. 日本ネットワークインフォメーションセンター (2018年12月13日). 2021年5月29日閲覧。 “しかし、Google社の開発したQUICとIETFのQUICは、同じ技術をベースとしながらも現状では異なるものになってしまっており、それらを明示的に区別して前者をgQUIC、後者をiQUICと呼び分けています。”
  6. ^ Lardinois, Frederic. “Google Wants To Speed Up The Web With Its QUIC Protocol”. TechCrunch. 2016年10月25日閲覧。
  7. ^ Christopher Fernandes (April 3, 2018). “Microsoft to add support for Google's QUIC fast internet protocol in Windows 10 Redstone 5”. 2020年5月8日閲覧。
  8. ^ “How to enable HTTP3 in Chrome / Firefox / Safari”. bram.us (April 8, 2020). 2021年5月31日閲覧。
  9. ^ “The state of QUIC and HTTP/3 2020”. www.fastly.com. 2020年10月21日閲覧。
  10. ^ a b Nathan Willis. “Connecting on the QUIC”. Linux Weekly News. 2013年7月16日閲覧。
  11. ^ “Google Will Propose QUIC As IETF Standard”. InfoQ. 2016年10月25日閲覧。
  12. ^ "I-D Action: draft-tsvwg-quic-protocol-00.txt". i-d-announce (Mailing list). 17 June 2015.
  13. ^ “QUIC - IETF Working Group”. datatracker.ietf.org. 2016年10月25日閲覧。
  14. ^ Cimpanu, Catalin (12 November 2018). “HTTP-over-QUIC to be renamed HTTP/3”. https://www.zdnet.com/article/http-over-quic-to-be-renamed-http3/ 
  15. ^ Jana Iyengar (2021年5月27日). “QUIC is now RFC 9000”. Fastly BLOG. 2021年5月29日閲覧。 “The IETF just published QUIC as RFC 9000, supported by RFC 9001, RFC 9002, and RFC 8999.”
  16. ^ Jana Iyengar (2019年11月11日). “QUICの成熟”. Fastly blog. 2021年6月8日閲覧。
  17. ^ “1. An Extremely Abstract Description of QUIC” (英語). RFC 8999 Version-Independent Properties of QUIC. (May 2021). doi:10.17487/rfc8999. ISSN 2070-1721. https://www.rfc-editor.org/rfc/rfc8999.html#name-an-extremely-abstract-descr 2021年6月9日閲覧. "QUIC is a connection-oriented protocol between two endpoints." 
  18. ^ Jana Iyengar (2019年11月11日). “QUICの成熟”. Fastly blog. 2021年6月8日閲覧。 “数回の繰り返しの後、最終的にこの設計は、対応するエンドポイントによって選択された各方向に1つずつ、2つの可変長の接続IDを使用することに置き換えられました。グループは両方のエンドポイントにその接続 ID を接続中に変更する仕組みも構築しました。”
  19. ^ “2.2. Sending and Receiving Data” (英語). RFC 9000 QUIC: A UDP-Based Multiplexed and Secure Transport. (May 2021). doi:10.17487/rfc9000. ISSN 2070-1721. https://www.rfc-editor.org/rfc/rfc9000.html#name-sending-and-receiving-data 2021年6月3日閲覧. "Streams are an ordered byte-stream abstraction with no other structure visible to QUIC. STREAM frame boundaries are not expected to be preserved when data is transmitted, retransmitted after packet loss, or delivered to the application at a receiver." 
  20. ^ RFC 9221 5.4. Congestion Control
  21. ^ 渡瀬圭一 (2018年1月26日). “TCPに代わる高速プロトコルの標準化――QUIC【IETF100 Update Meeting】”. INTERNET Watch. 2021年6月2日閲覧。 “当面はDNSなどを諦めてv1ではアプリケーションとしてHTTPをターゲットとしたことなどが報告された。”
  22. ^ a b Cimpanu, Catalin (12 November 2018). “HTTP-over-QUIC to be renamed HTTP/3”. https://www.zdnet.com/article/http-over-quic-to-be-renamed-http3/ 
  23. ^ Liebetrau, Etienne (2018年6月22日). “How Google's QUIC Protocol Impacts Network Security and Reporting” (英語). Fastvue - Simple Internet Usage Reporting. 2022年4月2日閲覧。
  24. ^ Cimpanu, Catalin (Sep 26, 2019). “Cloudflare, Google Chrome, and Firefox add HTTP/3 support”. ZDNet. Sep 27, 2019閲覧。
  25. ^ Dragana Damjanovic (2021年4月16日). “QUIC and HTTP/3 Support now in Firefox Nightly and Beta”. Mozilla. 2021年10月11日閲覧。
  26. ^ “Release Notes for Safari Technology Preview 104”. webkit.org (8 April 2020). 7 August 2020閲覧。
  27. ^ “Safari 14 Release Notes”. developer.apple.com. 4 December 2020閲覧。
  28. ^ “How to enable HTTP3 in Chrome / Firefox / Safari”. bram.us (April 8, 2020). 2022年4月10日閲覧。
  29. ^ “Perform network operations using Cronet” (英語). Android Developers. 2019年7月20日閲覧。
  30. ^ “curl - Changes”. curl.haxx.se. 2019年9月30日閲覧。
  31. ^ “curl 7.66.0 – the parallel HTTP/3 future is here | daniel.haxx.se” (英語). 2019年9月30日閲覧。
  32. ^ “How Facebook is bringing QUIC to billions” (英語). Facebook Engineering (2020年10月21日). 2020年10月23日閲覧。
  33. ^ “How Google's QUIC Protocol Impacts Network Security and Reporting” (英語). Fastvue (2020年10月21日). 26 June 2021閲覧。
  34. ^ a b Green, Emily (30 September 2020). “This is what you need to know about the new QUIC protocol” (英語). NordVPN. 26 June 2021閲覧。
  35. ^ https://code.google.com/p/chromium/codesearch#chromium/src/net/tools/quic/quic_server.cc
  36. ^ QUIC support in Caddy, Retrieved 13 July 2016.
  37. ^ “LiteSpeed Web ADC - Load Balancer - LiteSpeed Technologies”. www.litespeedtech.com. Aug 7, 2020閲覧。
  38. ^ “Distribution of Web Servers among websites that use QUIC”. w3techs.com. Aug 7, 2020閲覧。
  39. ^ “Get a head start with QUIC” (2018年9月25日). 2019年7月16日閲覧。
  40. ^ “Usage Statistics of QUIC for Websites, March 2021”. w3techs.com. 2021年3月4日閲覧。
  41. ^ “Enabling HTTP/3 support on Windows Server 2022” (英語). TECHCOMMUNITY.MICROSOFT.COM (2021年8月24日). 2022年4月2日閲覧。
  42. ^ nedpyle. “SMB over QUIC” (英語). docs.microsoft.com. 2022年4月2日閲覧。
  43. ^ Mackie, By Kurt. “Microsoft Embracing Native QUIC in Newer Windows OSes and Edge Browser -- Redmondmag.com” (英語). Redmondmag. 2022年4月2日閲覧。
  44. ^ “Policy configuration for HTTP/3 traffic | Citrix ADC 13.0”. docs.citrix.com. 2022年4月2日閲覧。
  45. ^ “Need for speed? – Just an other Citrix ADC Blog”. norz.at. 2022年4月2日閲覧。
  46. ^ “devsisters/libquic” (Aug 5, 2020). Aug 7, 2020閲覧。
  47. ^ “devsisters/goquic” (Aug 5, 2020). Aug 7, 2020閲覧。
  48. ^ “Docker Hub”. hub.docker.com. Aug 7, 2020閲覧。
  49. ^ “.NET 5 Networking Improvements” (英語). .NET Blog (2021年1月11日). 2021年1月26日閲覧。
  50. ^ “Windows Server 2022正式版がひっそりとリリース。セキュアコアサーバ搭載、SMB over QUICでVPN不要のファイルアクセスなど”. Publickey (2021年8月23日). 2022年5月20日閲覧。
  51. ^ “draft-bider-ssh-quic-09” (英語). datatracker.ietf.org. 2022年4月2日閲覧。
  52. ^ V (2019年2月1日). “WebRTC over QUIC”. Medium. 2021年5月30日閲覧。
  53. ^ ASnoKaze (1555859367). “QUICの暗号化と鍵の導出について”. ASnoKaze blog. 2021年10月25日閲覧。
  54. ^ 大森敏行 (2019年5月13日). “HTTP/3が必要な理由（3ページ目）”. 日経クロステック（xTECH）. 2021年6月10日閲覧。 “グーグルが開発した当初はQuick UDP Internet Connectionsの略だったが、現在は略語ではないとされている。”
  55. ^ “1.2. Terms and Definitions” (英語). RFC 9000 QUIC: A UDP-Based Multiplexed and Secure Transport. (May 2021). doi:10.17487/rfc9000. ISSN 2070-1721. https://www.rfc-editor.org/rfc/rfc9000.html#name-terms-and-definitions 2021年6月10日閲覧. "QUIC is a name, not an acronym." 
  56. ^ [chrome] Index of /trunk/src/net/quic
  57. ^ quic - chromium/src/net - Git at Google

関連項目

編集

外部リンク

編集
「https://ja.wikipedia.org/w/index.php?title=QUIC&oldid=101878472」から取得