QUIC

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ
QUIC
通信プロトコル
目的一般的用途
開発者IETF
序章2012年10月12日; 9年前 (2012-10-12
OSI層トランスポート層
RFC(s)RFC 9000、RFC 8999、RFC 9001、RFC 9002

QUIC(「quick」と発音)は、汎用[2] トランスポート層[3] ネットワークプロトコルであり、最初はGoogleでJim Roskindによって設計され[4]実装され、2012年に展開され、[5]実験が拡大するにつれて2013年に公表されました。 、[6] [7] [8]であり、 IETF会議で説明されています。[9] QUICは、 ChromeウェブブラウザからGoogleのサーバーへのすべての接続の半分以上で使用されています。[10] Microsoft Edge(Chromeの派生物)[11] [廃止されたソース] そしてFirefox [12]はそれをサポートしています。Safariはプロトコルを実装しますが、デフォルトでは有効になっていません。[13]

その名前は当初「QuickUDPInternet Connections」の頭字語として提案されましたが、[4] [9] IETFによるQUICという単語の使用は頭字語ではありません。それは単にプロトコルの名前です。[2] QUICは、現在TCPを使用しているコネクション型Webアプリケーションのパフォーマンスを向上させます。[3] [10]これは、ユーザーデータグラムプロトコル(UDP)を使用して2つのエンドポイント間に多数の多重接続を確立することで実現され、多くのアプリケーションのトランスポート層でTCPを廃止するように設計されているため、プロトコルに「TCP」というニックネームが付けられます。 / 2 "。[14]

QUICはHTTP / 2の多重化接続と連携して動作し、データの複数のストリームがすべてのエンドポイントに独立して到達できるようにします。したがって、他のストリームに関連するパケット損失とは無関係です。対照的に、伝送制御プロトコル(TCP)でホストされているHTTP / 2は、TCPパケットのいずれかが遅延または失われた場合、すべての多重化ストリームの ヘッドオブラインブロッキング遅延を被る可能性があります。

QUICの第2の目標には、接続とトランスポートの遅延の削減、および輻輳を回避するための各方向の帯域幅の見積もりが含まれます。また、輻輳制御アルゴリズムをカーネルスペースではなく、両方のエンドポイントのユーザースペースに移動します。これにより、これらのアルゴリズムをより迅速に改善できると主張されています。さらに、プロトコルを前方誤り訂正(FEC)で拡張して、エラーが予想される場合のパフォーマンスをさらに向上させることができます。これは、プロトコルの進化における次のステップと見なされます。

2015年6月、QUICの仕様のインターネットドラフトが標準化のためにIETFに提出されました。[15] [16] QUICワーキンググループは2016年に設立されました。[17] 2018年10月、IETFのHTTPおよびQUICワーキンググループは、QUICを介したHTTPマッピングを世界規模にする前に共同で「 HTTP / 3 」と呼ぶことを決定しました。標準。[18] 2021年5月、IETFはRFC  9000でQUICを標準化し、 RFC 8999RFC 9001RFC9002でサポートされました。[19]   

QUIC over UDPは現在、UDPポート443を使用しています。[20]

背景

伝送制御プロトコル(TCP)は、2つのエンドポイント間でデータのストリームを送信するためのインターフェイスを提供することを目的としています。データはTCPシステムに渡されます。これにより、データがまったく同じ形式でもう一方の端に到達することが保証されます。そうでない場合、接続はエラー状態が存在することを示します。[21]

これを行うために、TCPはデータをネットワークパケットに分割し、各パケットに少量のデータを追加します。この追加データには、失われたパケットや順不同で到着したパケットを検出するために使用されるシーケンス番号と、パケットデータ内のエラーを検出できるようにするチェックサムが含まれます。いずれかの問題が発生すると、TCPは自動再送要求(ARQ)を使用して、失われたパケットまたは破損したパケットを再送信するように送信者に指示します。[21]

ほとんどの実装では、TCPは接続のエラーをブロック操作と見なし、エラーが解決されるか接続が失敗したと見なされるまで、それ以上の転送を停止します。HTTP / 2プロトコルの場合のように、単一の接続を使用して複数のデータストリームを送信している場合、問題が発生する可能性があるのは1つだけですが、これらのストリームはすべてブロックされます。たとえば、ファビコンに使用されるGIF画像のダウンロード中に単一のエラーが発生した場合、その問題が解決されるまで、ページの残りの部分全体が待機します。[21]

TCPシステムは「データパイプ」またはストリームのように見えるように設計されているため、送信するデータについての理解が意図的にほとんど含まれていません。そのデータにTLSを使用した暗号化などの追加要件がある場合、これはTCP上で実行されているシステムによって設定され、TCPを使用して接続のもう一方の端にある同様のソフトウェアと通信する必要があります。これらの種類のセットアップタスクには、それぞれ独自のハンドシェイクプロセスが必要です。これには、接続が確立されるまで、要求と応答のラウンドトリップが数回必要になることがよくあります。長距離通信には固有の遅延があるため、これにより、伝送全体にかなりのオーバーヘッドが追加される可能性があります。[21]

特徴

TLS1.2を使用したTCPと比較したQUICのハンドシェイク

QUICは、TCP接続とほぼ同等であるが、待ち時間が大幅に短縮されることを目指しています。これは主に、HTTPトラフィックの動作の理解に依存する2つの変更を通じて行われます。[21]

最初の変更は、接続セットアップ中のオーバーヘッドを大幅に削減することです。ほとんどのHTTP接続はTLSを要求するため、QUICはセットアップキーとサポートされているプロトコルの交換を最初のハンドシェイクプロセスの一部にします。クライアントが接続を開くと、応答パケットには、将来のパケットが暗号化を使用するために必要なデータが含まれます。これにより、TCP接続をセットアップしてから、追加のパケットを介してセキュリティプロトコルをネゴシエートする必要がなくなります。他のプロトコルも同じ方法で処理でき、複数のステップを1つの要求/応答に組み合わせます。このデータは、初期設定での後続の要求と、別の接続としてネゴシエートされる将来の要求の両方に使用できます。[21]

2番目の変更は、TCPではなくUDPをベースとして使用することです。これには、損失回復は含まれません。代わりに、各QUICストリームは個別にフロー制御され、失われたデータはUDPではなくQUICのレベルで再送信されます。これは、上記のファビコンの例のように1つのストリームでエラーが発生した場合、プロトコルスタックが他のストリームに個別にサービスを提供し続けることができることを意味します。これは、エラーが発生しやすいリンクのパフォーマンスを向上させるのに非常に役立ちます。ほとんどの場合、TCPがパケットの欠落または破損に気付く前にかなりの追加データが受信され、エラーが修正されている間、このデータはすべてブロックされるか、フラッシュされることさえあります。QUICでは、単一の多重化ストリームが修復されている間、このデータは自由に処理できます。[22]

QUICには、全体的なレイテンシーとスループットを改善する、他のよりありふれた変更がいくつか含まれています。たとえば、パケットは個別に暗号化されるため、暗号化されたデータが部分的なパケットを待機することはありません。これは、暗号化レコードがバイトストリームにあり、プロトコルスタックがこのストリーム内の上位層の境界を認識しないTCPでは一般的に不可能です。これらは上で実行されているレイヤーによってネゴシエートできますが、QUICはこれらすべてを単一のハンドシェイクプロセスで実行することを目指しています。[9]

QUICシステムのもう1つの目標は、モバイルデバイスのユーザーがローカルWiFiホットスポットからモバイルネットワークに移動したときに発生するような、ネットワークスイッチイベント中のパフォーマンスを向上させることでしたこれがTCPで発生すると、長いプロセスが開始され、既存のすべての接続が1つずつタイムアウトしてから、オンデマンドで再確立されます。この問題を解決するために、QUICには、ソースに関係なくサーバーへの接続を一意に識別する接続識別子が含まれています。これにより、ユーザーのIPアドレスが変更されても元の接続IDが引き続き有効であるため、常にこのIDを含むパケットを送信するだけで接続を再確立できます。[23] [より良い情報源が必要]

QUICは、オペレーティングシステムのカーネルではなく、アプリケーションスペースに実装できますこれは通常、データがアプリケーション間で移動されるときにコンテキストスイッチが原因で追加のオーバーヘッドを引き起こします。ただし、QUICの場合、プロトコルスタックは単一のアプリケーションで使用することを目的としており、各アプリケーションはQUICを使用して独自の接続をUDPでホストします。全体的なHTTP / 2スタックの多くはすでにアプリケーション(またはより一般的にはそれらのライブラリ)にあるため、最終的には違いは非常に小さい可能性があります。これらのライブラリに残りの部分を配置すること、つまり本質的にエラー訂正は、HTTP / 2スタックのサイズや全体的な複雑さにほとんど影響を与えません。[9]

この編成では、更新のためにカーネルを変更する必要がないため、将来の変更をより簡単に行うことができます。QUICの長期的な目標の1つは、前方誤り訂正(FEC)と改善された輻輳制御のための新しいシステムを追加することです。[23]

TCPからUDPへの移行に関する懸念の1つは、TCPが広く採用されており、インターネットインフラストラクチャの「ミドルボックス」の多くがTCPとレート制限、さらにはUDPをブロックするように調整されていることです。Googleはこれを特徴づけるためにいくつかの探索的実験を実施し、この方法でブロックされた接続はごくわずかであることがわかりました。[4]これにより、TCPへの迅速なフォールバックが使用されました。Chromiumのネットワークスタックは、QUIC接続と従来のTCP接続の両方を同時に開きます。これにより、ごくわずかな遅延でフォールバックできます。[24]

Google QUIC(gQUIC)

Googleによって作成され、QUICという名前でIETFに導入されたプロトコル(すでに2012年にはQUICバージョン20前後)は、IETF内で進化と改良を続けてきたQUICとはまったく異なります。オリジナルのGoogleQUICは、汎用プロトコルとして設計されましたが、当初はChromiumでHTTP(S)をサポートするプロトコルとして導入されました。IETF QUICプロトコルの現在の進化は、汎用トランスポートプロトコルです。Chromium開発者は、ChromiumのQUICの最新のインターネット標準を採用し、完全に準拠するためのIETFQUICの標準化の取り組みの進化を追跡し続けました。

採用

ブラウザのサポート

QUICコードは2012年からGoogleChromeで実験的に開発され[5]、Chromiumバージョン29(2013年8月20日にリリース)の一部として発表されました。[18]現在、ChromiumとChromeではデフォルトで有効になっています。[要出典]

Firefoxのサポートは2021年5月に到着しました。[25] [12]

Appleは、 2020年4月にSafari Technology Preview104を介してWebKitエンジンに実験的なサポートを追加しました。[26]公式サポートがSafari14に追加され、 macOS BigSurおよびiOS14含まれています[27]が、この機能は手動でオンにする必要があります。[28]

クライアントサポート

QUICおよびその他のプロトコル用のクロネットライブラリは、GooglePlayサービスを介してロード可能なモジュールとしてAndroidアプリケーションで利用できます。[29]

2019年9月11日にリリースされたcURL7.66は、HTTP / 3(したがってQUIC)をサポートします。[30] [31]

2020年10月、FacebookはInstagramを含むアプリとサーバーインフラストラクチャをQUICに正常に移行し、インターネットトラフィックの75%がすでにQUICを使用していることを発表しました[32] 。YouTubeGmailを含むGoogleのすべてのモバイルアプリはQUICをサポートしています[33] [34] UberのモバイルアプリもQUICを使用しています。[34]

サーバーサポート

2017年の時点で、アクティブに維持されている実装がいくつかあります。GoogleサーバーはQUICをサポートしており、Googleはプロトタイプサーバーを公開しています。[35] AkamaiTechnologiesは2016年7月からQUICをサポートしています。[36] [37] quic-go [38]と呼ばれるGo実装も利用可能であり、 Caddyサーバーでの実験的なQUICサポートを強化します[39] 2017年7月11日、LiteSpeed Technologiesは、ロードバランサー(WebADC)[40]およびLiteSpeed WebServer製品でQUICのサポートを正式に開始しました。[41] 2019年10月の時点で、QUIC Webサイトの88.6%がLiteSpeedを使用し、10.8%が使用されていますNginx[42]最初はGoogleサーバーのみがHTTP-over-QUIC接続をサポートしていましたが、Facebookも2018年にテクノロジーを開始し[18]Cloudflareは2018年からベータベースでQUICサポートを提供しています。[43] 2021年3月現在、すべてのウェブサイトの5.0%がQUICを使用しています。[44] Microsoft Windows Server 2022は、 MsQuicを介してHTTP / 3 [45]とSMBover QUIC [46] [47]プロトコルの両方をサポートします。CitrixのApplicationDelivery Controller (Citrix ADC、NetScaler)は、バージョン13以降のQUICプロキシとして機能できます。[48] [49]

さらに、いくつかの古いコミュニティプロジェクトがあります。libquic [50]は、QUICのChromium実装を抽出し、依存関係の要件を最小限に抑えるように変更することで作成されました。goquic [51]は、libquicのGoバインディングを提供します。最後に、quic-reverse-proxy [52]は、リバースプロキシサーバーとして機能するDockerイメージであり、QUICリクエストをオリジンサーバーが理解できるプレーンなHTTPに変換します。

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

ソースコード

以下のQUICまたはgQUICの実装は、ソース形式で入手できます。
実装 ライセンス 言語 説明
クロム BSDライセンス C ++ これは、ChromeウェブブラウザのソースコードとリファレンスgQUIC実装です。テストに使用できるスタンドアロンのgQUICおよびQUICクライアントおよびサーバープログラムが含まれています。閲覧可能なソースコードこのバージョンは、LINEステライトとGoogleのクロネットの基礎でもあります。
QUICライブラリ(mvfst) MITライセンス C ++ mvfst(高速移動と発音)は、FacebookによるC ++でのIETFQUICプロトコルのクライアントおよびサーバー実装です。
LiteSpeed QUICライブラリ(lsquic) MITライセンス C これは、 LiteSpeedWebサーバーOpenLiteSpeedで使用されるQUICとHTTP / 3の実装です。
ngtcp2 MITライセンス C これは、暗号ライブラリに依存せず、OpenSSLまたはGnuTLSで動作するQUICライブラリです。HTTP / 3の場合、nghttp3のような別のライブラリが必要です。
キッシュ BSD-2-Clauseライセンス さび ソケットに依存せず、C / C ++アプリケーションで使用するためのCAPIを公開します。
すばやく MITライセンス C このライブラリは、H2OWebサーバーのQUIC実装です。
quic-go MITライセンス 行け このライブラリは、CaddyWebサーバーでQUICサポートを提供しますクライアント機能も利用できます。
クイン Apacheライセンス2.0 さび
Neqo Apacheライセンス2.0 さび このMozillaからの実装は、FirefoxWebブラウザで使用されるネットワークライブラリであるNeckoに統合される予定です。
aioquic BSD-3-Clauseライセンス Python このライブラリは、クライアントとサーバーの両方に埋め込むのに適したI / OフリーのAPIを備えています。
picoquic BSD-3-Clauseライセンス C IETF仕様に沿ったQUICの最小限の実装
pquic MITライセンス C プラグインとして拡張機能を動的にロードできるeBPF仮想マシンを含む拡張可能なQUIC実装
MsQuic MITライセンス C 汎用QUICライブラリとして設計さ れたMicrosoftのクロスプラットフォームQUIC実装。
クオンツ BSD-2-Clauseライセンス C Quantは、組み込みシステムだけでなく、従来のPOSIXプラットフォーム(Linux、MacOS、FreeBSDなど)もサポートしています。
quic BSD-3-Clauseライセンス Haskell このパッケージは、Haskell軽量スレッドに基づくQUICを実装します。
netty-incubator-codec-quic Apacheライセンス2.0 Java このパッケージは、 Quicheの実装に基づいてnettyでQUICを実装します。
nodejs-quic MITライセンス NodeJ この実験的なパッケージは、Nodejs用のQUICを実装しています。
s2n-quic Apacheライセンス2.0 さび アマゾンウェブサービスからのオープンソースのRust実装

も参照してください

参考文献

  1. ^ W. Richard Stevens、 TCP / IP Illustrated、Volume 1:The Protocols、Addison Wesley、1994、ISBN0-201-63346-9。
  2. ^ a b RFC 9000-QUIC:UDPベースの多重化された安全なトランスポートIETF土井10.17487 / RFC9000RFC9000 _ 2022-02-08を取得
  3. ^ ab ネイサンウィリス「QUICで接続する」Linuxウィークリーニュース2013年7月16日取得
  4. ^ a b c "QUIC:設計ドキュメントと仕様の理論的根拠"クロムロスキンド、クロムコントリビューター。
  5. ^ a b "最初のChromiumコードランディング:CL 11125002:QuicFramerとその仲間を追加" 2012年10月16日取得
  6. ^ 「QUICで実験する」Chromium公式ブログ2013年7月16日取得
  7. ^ 「QUIC、Googleはウェブをより速くしたい」FrançoisBeaufort、クロムエバンジェリスト。
  8. ^ 「QUIC:UDPを介した次世代の多重化トランスポート」YouTube 2014年4月4日取得
  9. ^ a b c d "QUIC:IETF-88 TSVエリアプレゼンテーション" (PDF)ジムロスキンド、グーグル2013年11月7日取得
  10. ^ a b ラルディノア、フレデリック。「GoogleはQUICプロトコルでWebを高速化したいと考えています」TechCrunch 2016年10月25日取得
  11. ^ クリストファーフェルナンデス(2018年4月3日)。「Microsoftは、Windows 10 Redstone5でGoogleのQUIC高速インターネットプロトコルのサポートを追加します」2020年5月8日取得
  12. ^ a b Dragana Damjanovic(2021-04-16)。「FirefoxNightlyとBetaでQUICとHTTP / 3がサポートされるようになりました」Mozilla 2021-10-11を取得
  13. ^ 「QUICとHTTP / 32020の状態」www.fastly.com 2020年10月21日取得
  14. ^ 辻川達弘。「ngtcp2」GitHub 2020年10月17日取得
  15. ^ 「GoogleはIETF標準としてQUICを提案します」InfoQ 2016年10月25日取得
  16. ^ 「IDアクション:draft-tsvwg-quic-protocol-00.txt」id-announce(メーリングリスト)。2015年6月17日。
  17. ^ 「QUIC-IETFワーキンググループ」datatracker.ietf.org 2016年10月25日取得
  18. ^ a b c Cimpanu、カタリン(2018年11月12日)。「HTTP-over-QUICはHTTP / 3に名前が変更されます」ZDNet
  19. ^ 「QUICはRFC9000になりました」www.fastly.com2021-05-27 2021-05-28を取得{{cite web}}:CS1 maint:url-status(link
  20. ^ 「QUICの概要」blog.apnic.net2022-01-12 2022-01-12を取得{{cite web}}:CS1 maint:url-status(link
  21. ^ a b c d e f ブライト、ピーター(2018年11月12日)。「HTTPの次のバージョンはTCPを使用しません」Arstechnica
  22. ^ Behr、Michael; Swett、Ian。「HTTPSロードバランシングのQUICサポートの紹介」Google CloudPlatformブログ2018年6月16日取得
  23. ^ a b サイモン、クレイトン(2021年5月)。「QUIC:UDPベースの多重化された安全なトランスポート」IETF.org{{cite web}}:CS1 maint:url-status(link
  24. ^ 「QUICトランスポートプロトコルの適用性」IETFネットワークワーキンググループ2018年10月22日。
  25. ^ Cimpanu、カタリン(2019年9月26日)。「Cloudflare、Google Chrome、FirefoxはHTTP / 3サポートを追加します」ZDNet 2019年9月27日取得
  26. ^ 「SafariTechnologyPreview104のリリースノート」webkit.org2020年4月8日2020年8月7日取得
  27. ^ 「Safari14リリースノート」developer.apple.com 2020年12月4日取得
  28. ^ 「Chrome / Firefox / SafariでHTTP3を有効にする方法」bram.us。 _ 2020年4月8日。
  29. ^ 「Cronetを使用してネットワーク操作を実行する」Android開発者2019年7月20日取得
  30. ^ 「カール-変更」curl.haxx.se。_ 2019年9月30日取得
  31. ^ "curl 7.66.0 –並列HTTP / 3の未来はここにあります| daniel.haxx.se" 2019年9月30日取得
  32. ^ 「FacebookがQUICを数十億にもたらす方法」Facebookエンジニアリング2020-10-21 2020年10月23日取得
  33. ^ 「GoogleのQUICプロトコルがネットワークセキュリティとレポートに与える影響」Fastvue2020-10-21 2021年6月26日取得
  34. ^ a b グリーン、エミリー(2020年9月30日)。「これは、新しいQUICプロトコルについて知っておく必要があることです」NordVPN 2021年6月26日取得
  35. ^ https://code.google.com/p/chromium/codesearch#chromium/src/net/tools/quic/quic_server.cc
  36. ^ AkamaiによるQUICサポート、 2020年5月20日取得。
  37. ^ QUIC in the Wild、Passive Active Measurements Conference(PAM)、2018、2020年5月20日取得。
  38. ^ "lucas-clemente / quic-go"2020年8月7日2020年8月7日–GitHub経由で取得。
  39. ^ CaddyでのQUICサポート、 2016年7月13日取得。
  40. ^ 「LiteSpeedWebADC-ロードバランサー-LiteSpeedテクノロジー」www.litespeedtech.com 2020年8月7日取得
  41. ^ LiteSpeed Technologies QUICブログ投稿、2017年7月11日取得。
  42. ^ 「QUICを使用するWebサイト間のWebサーバーの分散」w3techs.com 2020年8月7日取得
  43. ^ 「QUICで有利なスタートを切る」2018-09-25 2019年7月16日取得
  44. ^ 「ウェブサイトのためのQUICの使用統計、2021年3月」w3techs.com 2021-03-04を取得
  45. ^ https://techcommunity.microsoft.com/t5/networking-blog/enabling-http-3-support-on-windows-server-2022/ba-p/2676880
  46. ^ https://docs.microsoft.com/en-us/windows-server/storage/file-server/smb-over-quic
  47. ^ https://redmondmag.com/articles/2021/08/26/native-quic-in-windows-edge.aspx
  48. ^ https://docs.citrix.com/en-us/citrix-adc/13/system/http3-over-quic-protocol/http3-policy-configuration.html
  49. ^ https://norz.at/?p=2022
  50. ^ "devsisters / libquic"2020年8月5日2020年8月7日–GitHub経由で取得。
  51. ^ 「devsisters / goquic」2020年8月5日2020年8月7日–GitHub経由で取得。
  52. ^ 「Dockerハブ」hub.docker.com 2020年8月7日取得
  53. ^ 「。NET5ネットワークの改善」.NETブログ2021-01-11 2021-01-26を取得

外部リンク