クイック

QUIC（/ k w ɪ k / ）は、 Googleのジム・ロスキンドが最初に設計した汎用トランスポート層 ネットワークプロトコルです。^{[1] [2] [3]}最初に実装され、展開されたのは2012年です。^[4]実験が拡大したため、2013年に公表され、IETFの会議で説明されました。^{[5] [6] [7] [8] QUICは、} ChromeウェブブラウザからGoogleのサーバーへの接続の半分以上で使用されています。^[9] Microsoft Edge（バージョン79以降、オープンソースのChromiumブラウザの派生）、^{[10] [11]} Firefox、^[12] Safariがこれをサポートしています。^[13]

当初、QUIC という名前は「Quick UDP Internet Connections」の頭字語として提案されましたが、IETF では QUIC という単語は頭字語ではなく、単にプロトコルの名前として使用されています。^{[3] [8] [1] QUIC は、現在}伝送制御プロトコル(TCP)を使用している接続指向のWeb アプリケーションのパフォーマンスを向上させます。 ^{[2] [9]}これは、ユーザー データグラム プロトコル(UDP) を使用して 2 つのエンドポイント間に多数の多重化された接続を確立することによって実現され、多くのアプリケーションのトランスポート層で TCP を廃止するように設計されているため、このプロトコルは「TCP/2」というニックネームで呼ばれることがあります。^[14]

QUIC はHTTP/3の多重接続と連携して動作し、複数のデータ ストリームがすべてのエンドポイントに独立して到達できるようにするため、他のストリームに関連するパケット損失の影響を受けません。対照的に、TCP でホストされる HTTP/2 では、複数のストリームが TCP 接続で多重化され、その接続上の TCP パケットのいずれかが遅延または損失すると、ヘッドオブライン ブロッキングによる遅延が発生する可能性があります。

QUIC の二次的な目標には、接続と転送の遅延の削減、輻輳を回避するための各方向の帯域幅の推定などがあります。また、輻輳制御アルゴリズムをカーネル空間ではなく、両方のエンドポイントのユーザー空間に移動します。これにより、これらのアルゴリズムをより迅速に改善できると^[誰が主張しているのですか? ^]。さらに、このプロトコルは、エラーが予想される場合のパフォーマンスをさらに改善するために、前方誤り訂正(FEC) で拡張することができ、これはプロトコルの進化の次のステップと見なされています。プロトコルの硬直化を回避するように設計されているため、大幅な硬直化を被った TCP とは異なり、進化し続けることができます。

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  8999、RFC  9001、RFC  9002でサポートされました。 ^[19] DNS-over-QUICは別のアプリケーションです。

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

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

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

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

TCPはプロトコルの骨化に悩まされてきた^[21]。これはTCPのワイヤイメージが平文であるため、ミドルボックスによって見えやすく、変更しやすいためである^[22] 。ある測定によると、インターネット上のパスの3分の1はTCPメタデータを変更する少なくとも1つの仲介者に遭遇し、6.5%のパスは仲介者による有害な骨化効果に遭遇している。^[23] TCPの拡張も影響を受けており、マルチパスTCP (MPTCP)の設計はミドルボックスの動作によって制約され^{[24] 、 [25] 、} TCP Fast Openの展開も同様に妨げられている^{[ 26]。 [21]}

暗号化された HTTPトラフィックをサポートするという点では、QUICはTCPと同様の役割を果たしますが、接続セットアップ時の遅延が短縮され、複数のHTTPストリームが単一の接続で多重化されている場合の損失回復がより効率的になります。これは主に、HTTPトラフィックの動作を理解することに依存する2つの変更によって実現されます。^[20]

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

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

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

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

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

この構成により、アップデートのためにカーネルを変更する必要がないため、将来の変更がより簡単に行えるようになります。QUICの長期的な目標の1つは、前方誤り訂正（FEC）と輻輳制御の改善のための新しいシステムを追加することです。^[28]

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

QUICは、展開可能、進化可能、そして骨化防止特性を持つように特別に設計されている。 ^[30]これらの目的のためにワイヤイメージを意図的に最小限に抑えた最初のIETFトランスポートプロトコルである。 ^[31]暗号化されたヘッダー以外にも、「グリース」が施されており^[32]、プロトコル不変条件が明示的に指定されている。^[33]

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

QUICはHTTPを念頭に置いて開発され、HTTP/3がその最初のアプリケーションでした。^{[34] [35]} DNS-over-QUICは、DNS-over-TLSと同様に、リゾルバ間で転送されるデータのセキュリティを提供する、QUICを名前解決に適用したものです。^{[36] IETFは、安全な}ネットワークトンネリング^[35]とストリーミングメディア配信のためのQUICのアプリケーションを開発しています。 ^[37] XMPPは、実験的にQUICを使用するように適応されています。^[38]もう1つのアプリケーションは、SMB over QUICで、Microsoftによると、ユーザーエクスペリエンスに影響を与えずに「SMB VPN」を提供できます。^[39] SMBクライアントはデフォルトでTCPを使用し、TCPの試行が失敗した場合、または意図的にQUICが必要な場合はQUICを試みます。

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

Firefoxでのサポートは2021年5月に開始されました。^{[41] [12]}

Appleは2020年4月にSafari Technology Preview 104を通じてWebKitエンジンに実験的なサポートを追加しました。^{[42]公式サポートは}Safari 14で追加され、 macOS Big SurとiOS 14に含まれていますが、^[43]この機能を有効にするには手動でオンにする必要があります。^[44]その後、Safari 16でデフォルトで有効になりました。^[13]

QUICやその他のプロトコル用のcronetライブラリは、 Google Play Servicesを介してロード可能なモジュールとしてAndroidアプリケーションで利用できます。^[45]

2019年9月11日にリリースされたcURL 7.66は、HTTP/3（およびQUIC）をサポートしています。^{[46] [47]}

2020年10月、FacebookはInstagramを含むアプリとサーバーインフラをQUICに移行し、すでにインターネットトラフィックの75%がQUICを使用していると発表しました^{[48] 。Googleのすべてのモバイルアプリは、} YouTubeやGmailを含め、QUICをサポートしています。^{[49] [50]} UberのモバイルアプリもQUICを使用しています。^[50]

2017年現在^[update]、積極的にメンテナンスされている実装がいくつかあります。GoogleサーバーはQUICをサポートしており、Googleはプロトタイプサーバーを公開しています。^[51] Akamai Technologiesは2016年7月からQUICをサポートしています。 ^{[52] [53]} quic-go ^{[54]と呼ばれる}Go実装も利用可能で、Caddyサーバーでの実験的なQUICサポートを強化しています。^[55] 2017年7月11日、LiteSpeed Technologiesは、ロードバランサー（WebADC）^[56]とLiteSpeed Web Server製品でQUICのサポートを正式に開始しました。^[57] 2019年10月現在、QUICウェブサイトの88.6％がLiteSpeedを使用し、10.8％がNginxを使用しています。^[58]当初はGoogleサーバーのみがHTTP-over-QUIC接続をサポートしていましたが、Facebookも2018年にこの技術を立ち上げ、^[18] Cloudflareは2018年からベータ版でQUICサポートを提供しています。^[59] HAProxyロードバランサーは2022年3月にQUICの実験的サポートを追加し、^[60] 2023年3月に本番環境対応を宣言しました。^[61] 2023年4月現在、すべてのウェブサイトの8.9%がQUICを使用しており、^[62] 2021年3月の5%から増加しています。Microsoft Windows Server 2022は、MsQuicを介してHTTP/3 ^[63]とSMB over QUIC ^{[64] [10]}プロトコルの両方をサポートしています。 Citrixのアプリケーション配信コントローラー（Citrix ADC、NetScaler）は、バージョン13以降、QUICプロキシとして機能できます。^{[65] [66][update][update]}

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

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

• 制約付きアプリケーションプロトコル(CoAP) – REST モデルを利用した UDP ベースのプロトコル
• データグラム輻輳制御プロトコル(DCCP)
• データグラム トランスポート層セキュリティ(DTLS)
• 高速かつ安全なプロトコル
• HTTP/3
• LEDBAT (低遅延バックグラウンドトランスポート)
• マイクロトランスポートプロトコル(μTP)
• 多目的トランザクション プロトコル(MTP/IP) – Data Expedition, Inc. による QUIC の代替手段。
• リアルタイム メディア フロー プロトコル(RTMFP)
• 信頼性の高いユーザー データグラム プロトコル(RUDP)
• スパイディ
• ストリーム制御伝送プロトコル(SCTP UDP カプセル化、RFC 6951)
• 構造化ストリームトランスポート
• UDPベースのデータ転送プロトコル（UDT） – UDPベースのトランスポートプロトコル

• Trammell , Brian; Kuehlewind, Mirja (2019 年 4 月)。ネットワーク プロトコルのワイヤ イメージ。doi : 10.17487/ RFC8546。RFC 8546 。
• Thomson, Martin (2021 年5月). QUIC のバージョンに依存しない特性。doi : 10.17487/RFC8999 . RFC 8999。
• Fairhurst, Gorry; Perkins, Colin (2021 年 7 月)。トランスポート ヘッダーの機密性、ネットワーク操作、およびインターネット トランスポート プロトコルの進化に関する考慮事項。doi : 10.17487 / RFC9065。RFC 9065 。
• Thomson , Martin; Pauly, Tommy (2021 年 12 月)。プロトコル拡張メカニズムの長期的な実行可能性。doi : 10.17487/ RFC9170。RFC 9170 。
• Raiciu、Paasch、Barre、Ford、Honda、Duchene、Bonaventure、Handley (2012)。「どれほど難しいことか? 展開可能なマルチパス TCP の設計と実装」。Usenix NSDI : 399–412。
• Hesmans, Benjamin; Duchene, Fabien; Paasch, Christoph; Detal, Gregory; Bonaventure, Olivier (2013). TCP 拡張はミドルボックス耐性がありますか? HotMiddlebox '13. doi :10.1145/2535828.2535830.
• Corbet, Jonathan (2018 年 1 月 29 日)。「プロトコルの骨化に対する解決策としての QUIC」。LWN.net。
• Edeline, Korian; Donnet, Benoit (2019)。トランスポート層の骨化に関するボトムアップ調査。2019 ネットワーク トラフィック測定および分析会議 (TMA)。doi :10.23919/TMA.2019.8784690。
• Rybczyńska, Marta (2020 年 3 月 13 日)。「HTTP/3 の QUIC の概要」。LWN.net。

• 公式サイト
• GitHub上の IETF QUIC ワーキング グループ
• RFC  8999 – QUIC のバージョンに依存しない特性
• RFC  9000 – QUIC: UDP ベースの多重化された安全なトランスポート
• RFC  9001 – TLS を使用して QUIC を保護する
• RFC  9002 – QUIC 損失検出と輻輳制御
• Chromium : QUIC、UDP 経由の多重化ストリーム転送
• QUIC: 設計文書と仕様の根拠、Jim Roskind のオリジナル文書 (2012/2013)
• ダニエル・ステンバーグ：HTTP/3 の説明
• Linux Weekly News : QUIC での接続 (2013)
• QUIC:、IETF-88 TSV エリア プレゼンテーション (2013-11-07)
• Chromium ブログ: QUIC の実験 (2013)
• QUIC: UDP を介した次世代の多重化トランスポート (Google Developers、2014)
• UDP 経由の HTTP: QUIC の実験的調査
• マルチパス QUIC (QUIC の拡張)
• QUIC による交通の革新: 設計アプローチと研究上の課題 (2017)
• EPIQ 2018 基調講演 – Facebook の IETF QUIC 導入、YouTube の Subodh Iyengar
• EPIQ 2021 基調講演 – Microsoft の QUIC、YouTube の Nick Bankson
• Google の QUIC (2020) – David Schinazi の YouTube 動画
• Apple の QUIC (2021) – Tommy Pauly の YouTube 動画
• qvis: QUIC および HTTP/3 視覚化スイート。
• 図解 QUIC 接続