インターネット プロトコルとアーキテクチャの開発を担当する Internet Engineering Task Force (IETF) は、QUIC プロトコルの RFC を完成させ、RFC 8999 (バージョンに依存しないプロトコル プロパティ)、RFC 9000 (トランスポート) という識別子で関連仕様を公開しました。 over UDP)、RFC 9001 (QUIC 通信チャネルの TLS 暗号化)、および RFC 9002 (データ送信中の輻輳制御とパケット損失検出)。
RFC は「標準案」のステータスを取得し、その後、RFC に標準草案 (標準草案) のステータスを与える作業が開始されます。これは、実際には、作成されたすべてのコメントを考慮してプロトコルを完全に安定化することを意味します。 HTTP/3 のトランスポートとして QUIC プロトコルの使用を定義する HTTP/2 プロトコルはまだ仕様草案の段階にありますが、まもなく IETF によって最終的に標準化される予定です。
QUICの標準化は、このプロトコルの幅広い採用と、WebTransport（ブラウザとサーバー間でデータを送受信する技術）やMASQUEなど、それに基づく拡張機能の開発に弾みを与えることが期待されています。 (SOCKS と HTTP CONNECT の機能を拡張し、トランスポートとして QUIC 経由で HTTPS を使用する接続プロキシ テクノロジ)。
QUIC (Quick UDP Internet Connections) プロトコルは、Web 用の TCP+TLS の組み合わせの代替として 2013 年以来 Google によって開発されていることを思い出してください。これにより、TCP での接続の長いセットアップとネゴシエーション時間に関する問題が解決され、接続時の遅延が解消されます。データ転送中にパケットが失われます。 QUIC は、複数の接続の多重化をサポートし、TLS/SSL と同等の暗号化方式を提供する UDP プロトコルの拡張です。 IETF 標準の開発中にプロトコルに変更が加えられ、これにより 3 つの並列ブランチが出現しました。XNUMX つは HTTP/XNUMX 用で、もう XNUMX つは Google によってサポートされています (Chrome は両方のオプションをサポートし、Firefox は IETF バージョンをサポートします)。 。
QUIC の主な機能:
- TLS と同様の高いセキュリティ (基本的に QUIC は UDP 上で TLS を使用する機能を提供します)。
- フロー整合性制御によりパケット損失を防止します。
- 接続を即座に確立し (0-RTT、約 75% の場合、接続セットアップ パケットの送信直後にデータを送信できます)、要求の送信と応答の受信の間の遅延 (RTT、往復時間) を最小限に抑える機能;
- パケットを再送信するときに別のシーケンス番号を使用します。これにより、受信パケットを識別する際のあいまいさが回避され、タイムアウトがなくなります。
- パケットの損失は、それに関連付けられたストリームの配信にのみ影響し、現在の接続を通じて送信される並列ストリームでのデータの配信は停止しません。
- 失われたパケットの再送信による遅延を最小限に抑えるエラー修正機能。 パケットレベルで特別なエラー訂正コードを使用して、失われたパケットデータの再送信が必要な状況を軽減します。
- 暗号化ブロックの境界は QUIC パケットの境界と一致しているため、後続のパケットの内容のデコードにおけるパケット損失の影響が軽減されます。
- TCP キューのブロックには問題はありません。
- 接続識別子のサポート。モバイル クライアントの再接続の確立にかかる時間を短縮します。
- 高度な接続輻輳制御メカニズムを接続する可能性。
- 方向ごとのスループット予測技術を使用して、パケットが最適なレートで送信されるようにし、パケットの輻輳やパケット損失の発生を防ぎます。
- TCP と比較してパフォーマンスとスループットが大幅に向上します。 YouTube などのビデオ サービスの場合、QUIC はビデオ視聴時の再バッファリング操作を 30% 削減することが示されています。
出所： オープンネット.ru