QUICとは？
HTTP/3と、それ以来の最新かつ最高のバージョンのHTTPプロトコルを使用して、インターネットの未来に備えることができます。 HTTP3がすでに登場しているため、Webサイトの所有者とインターネットユーザは、これまで以上に高速で信頼性が高く、安全なオンラインエクスペリエンスを期待できます。これはすべて、QUIC（Quick UDP Internet Connection）として知られる革新的な新しいトランスポートプロトコルの基盤によるものです。
2021年5月、 IETFはRFC 9000でQUICを標準化し、RFC 8999 、RFC 9001および RFC 9002でサポートされました。その後、2022年6月7日に、IETFはRFC 9114で標準案としてQUICベースのHTTP/3を正式に公開しました。
現在、世界中でQUICの導入が加速しています。 QUIC IETF-v1プロトコル標準の出現により、ますます多くのWebサイトがQUICトラフィックを使用し始めています。W3Techsの統計によると、約25.5%のWebサイトが当面HTTP/3を使用しています。ネットワーク分野のパイオニアとして、CDNetworksはQUICプロトコルの包括的なサポートを完成させることに率先して取り組んできました。以下の表は、CDNetworksがサポートする現在のQUICバージョンを示しています。
QUICはどのように機能しますか？
ある側面からの説明として、QUIC = HTTP/2 + TLS + UDP であり、UDP + QUIC = トランスポート層です。
QUICはトランスポートプロトコルとしてUDP を採用しており、TCPよりもレイテンシが低く、スループットが高く、TCPに干渉する可能性のあるネットワークミドルボックスをQUIC がバイパスすることもできます。 QUICには TLS 1.3に基づく組み込みの暗号化プロトコルが含まれており、エンドポイント間の安全な通信を提供し、第三者がインターネットトラフィックを傍受して操作することを困難にします。SMBのようなプロトコルのコマンドとバージョン・コントロールに、新しいプロトコルのコンセプトと効率性をミックスしたのがQUICです。UDPのスピードと効率性、TLSのセキュリティ、そしてHTTP/2の機能を組み合わせることで、現代のインターネットのための信頼性が高く高性能なトランスポート・プロトコルが誕生しました。
QUICが重要である理由
QUICがリリースされる前は、HTTPでデータを転送するための基本プロトコルとしてTCPが使用されていました。ただし、モバイルインターネットが発展し続けるにつれて、リアルタイムの対話とより多様なネットワークシナリオに対する需要が高まっています。さらに、スマートフォンとポータブルデバイスがますます主流になり、現在60%を超えるインターネットトラフィックがワイヤレスで送信されています。
ただし、40年以上にわたって使用されてきたトランスポート層通信プロトコルである従来のTCPには、現在の大規模な長距離、貧弱なモバイルネットワーク、および頻繁に発生するネットワークスイッチングという状況では、固有のパフォーマンスボトルネックがあります。主に次の三つの理由による要求です。
1. 接続確立時のハンドシェイク遅延が大きい
HTTP1.0/1.1であろうと、HTTPS、HTTP2であろうと、それらはすべて伝送に TCPを使用します。 HTTPSとHTTP2では、安全な伝送のためにTLSプロトコルを使用する必要もあります。これにより、二つのハンドシェイク遅延が発生します。
TCPの3ウェイ・ハンドシェイクによって生じるTCPコネクション確立の遅延。
完全なTLSハンドシェイクを確立するには、少なくとも二つのRTTが必要であり、単純化されたハンドシェイクには一つのRTTハンドシェイク遅延が必要です。
多くの短い接続シナリオでは、このようなハンドシェイクの遅延は重大な影響を及ぼし、排除することはできません。
2. 行頭ブロッキング
HTTP/2の多重化を例にとると、複数のデータ要求が同じTCP接続で異なるストリームとして送信され、アプリケーション層のすべてのストリームを順番に処理する必要があります。ストリームのデータが失われた場合、その背後にある他のストリームのデータは、失われたデータが再送信されるまでブロックされ、受信側が後続のストリームのデータパケットを既に受信していても、アプリケーション層には通知されません。この問題は、TCPストリームのヘッドオブラインブロッキング（HoL）と呼ばれます。
3. TCPプロトコルの更新を促す難しさ
TCPプロトコルは、当初、ポート、オプション、および機能の追加と変更をサポートするために設計されました。ただし、TCPプロトコルとよく知られているポートとオプションの長い歴史により、多くのミドルボックス（ファイアウォールやルーター等）はこれらの暗黙のルールに依存するようになりました。その結果、プロトコルの変更がこれらのミドルボックスで適切にサポートされない可能性があり、相互運用性の問題が発生する可能性があります。
TCPプロトコルはオペレーティング システムのカーネルに実装されていますが、Windows XP等の多くの古いシステムプラットフォームには依然として多数のユーザが存在するため、ユーザ側のオペレーティングシステムのバージョンをアップグレードすることは非常に困難です。さらに、TCPユーザはその機能に満足しており、その動作に影響を与える可能性のある変更に抵抗する可能性があります。そのため、TCPプロトコルの更新を迅速にプロモートするのはそれほど簡単ではありません。
なぜQUICが必要なのか?
QUICの出現により、ラスト1マイルでのネットワーク伝送の問題が解決されました。 QUICによる主な改善点は次の通りです。
高速ハンドシェイクと接続確立
QUICは次の二つの側面で最適化されています。
- トランスポート層は UDPを使用して、TCPの3ウェイ・ハンドシェイクで1回の1-RTTの遅延を減らします。
- TLSプロトコル採用の最新バージョンであるTLS 1.3は、クライアントがTLSハンドシェイクが完了する前にアプリケーションデータを送信できるようにし、1-RTTと0-RTTの両方をサポートします。 QUICプロトコルでは、最初のハンドシェイクネゴシエーションに1-RTTかかりますが、以前に接続したクライアントは、キャッシュされた情報を使用してTLS接続を0-1 RTTだけで復元できます。
認証および暗号化されたパケット
従来のTCPプロトコルヘッダは暗号化も認証もされていないため、仲介者による改ざん、インジェクション、盗聴に対して脆弱です。対照的に、QUICパケットはセキュリティのために強力に武装されています。 PUBLIC_RESETやCHLOなどのいくつかのメッセージを除いて、すべてのパケット ヘッダーが認証され、すべてのメッセージ本文が暗号化されます。このようにして、QUICパケットの変更は受信側で即座に検出され、セキュリティ リスクが効果的に軽減されます。
下図に示すように、紫色のコンテンツはストリームフレームパケットの認証されたヘッダであり、黄色の部分は暗号化されたコンテンツです：
HoLブロッキングを回避するための多重化の改善
QUICは、接続上で複数のストリームを多重化するという概念を導入しました。ストリームごとに個別のフロー制御を設計および実装することにより、QUICは、接続全体に影響を与えるヘッドオブラインブロッキングの問題を解決します。
QUICの多重化はHTTP/2に似ています。複数のHTTPリクエスト（ストリーム）を単一のQUIC接続で同時に送信できます。しかし、QUICの多重化がHTTP/2を上回っているのは、単一の接続上の各ストリーム間に連続的な依存関係がないことです。つまり、ストリーム2がUDPパケットを失った場合、ストリーム2の処理にのみ影響し、次のストリームをブロックすることはありません。 データ送信 結果として、このソリューションはヘッドオブラインブロッキングを引き起こしません。
さらに、QPACKと呼ばれるHPACKヘッダ圧縮形式のバリエーションは、QUICの新機能として、ネットワーク上で送信される冗長データの量を減らし、ヘッドオブラインブロッキングを軽減するように設計されています。このように、QUICは週のネットワーク シナリオでTCPよりも多くのデータを受信できます。
プラグ可能な輻輳制御
QUICは、Cubic、BBR、Renoなどのプラグ可能な輻輳制御アルゴリズムをサポートするか、特定のシナリオに基づいてプライベートアルゴリズムをカスタマイズします。 "プラグ可能"とは、柔軟に発効、変更、停止できることを意味します。これは、次の側面に反映されます。
- オペレーティングシステムやカーネルサポートを必要とせずに、さまざまな輻輳制御アルゴリズムをアプリケーション層に実装できますが、従来のTCP輻輳制御では、制御効果を得るためにエンドツーエンドのネットワークプロトコルスタックが必要です。
- 単一のアプリケーションの異なる接続は、異なる輻輳制御構成をサポートすることができます。
- アプリケーションはダウンタイムやアップグレードなしに輻輳制御を変更できる。私たちがすることは、コンフィギュレーションを変更し、それをサーバ側でリロードするだけです。
接続の移行
TCP接続は、送信元IP、送信元ポート、宛先IP、および宛先ポートの四つのタプルに基づいています。これらの変更のいずれかが発生した場合、接続を再確立する必要があります。ただし、QUIC接続は64ビットの接続IDに基づいているため、接続IDが同じままである限り、接続を切断して再接続することなく接続を維持できます。
例えば、クライアントがIP1を使用してパケット1と2を送信し、その後ネットワークを切り替えてIP2に変更し、パケット3と4を送信する場合、サーバーはパケットヘッダのConnection IDフィールドに基づいて、四つのパケットすべてが同じクライアントからのものであることを認識できます。QUICがコネクションマイグレーションを実現できる基本的な理由は、基礎となるUDPプロトコルがコネクションレスであることです。
前方誤り訂正 (FEC)
QUICは前方誤り訂正（FEC）もサポートしており、FECパケットを動的に追加することで再送の回数を減らし、劣悪なネットワーク環境での伝送効率を向上させることができます。
HTTP/3とQUICは、より多くの分野でその価値を発揮します
HTTP/3とQUICが勢いを増し、より広く採用されるにつれて、ライブ＆ビデオストリーミング、ビデオオンデマンド、ダウンロード、またはWebアクセラレーションのいずれであっても、幅広いユース ケースが出現することが期待できます。これらのテクノロジの最も有望なアプリケーションシナリオには、次のようなものがあります。
リアルタイム アプリケーション
HTTP/3 と QUIC は、低遅延で高スループットの接続を必要とするリアルタイム アプリケーションに最適です。これには、ビデオ会議、オンライン ゲーム、ライブ ストリーミングなどのアプリケーションが含まれます。 QUIC の強力なネットワーク機能と接続の移行に基づいて、ビデオの起動時間を効果的に改善し、ビデオのスタッタリング率とリクエストの失敗率を減らすことができます。
IoT
端末デバイスが使用される IoT シナリオでは、デバイスが使用できるネットワーク リソースが非常に限られている高速移動、オフショア、山岳環境など、多くの場合、複雑で混沌としています。 TCP に基づく Message Queuing Telemetry Transport (MQTT) IoT 通信プロトコルでは、頻繁に接続が中断され、再接続中にサーバー/クライアントのオーバーヘッドが大きくなることがよくあります。ただし、QUIC の 0 RTT 再接続/1 RTT 確立機能と多重化特性の利点は、貧弱で不安定なネットワークで実証され、コンテンツ伝送効率を向上させ、ユーザー エクスペリエンスを向上させることができます。
Cloud Computing
(クラウドコンピューティング)
ますます多くのアプリケーションとサービスがクラウドに移行するにつれて、クライアントとサーバー間のより効率的で信頼性の高い接続が必要になります。多重化されたストリーム、低遅延のハンドシェイク、ゼロ ラウンド トリップ時間の再開を処理する機能により、QUIC はクラウドベースのコンピューティング システムのパフォーマンスを向上させることができます。
電子商取引と金融決済
E コマースでは、QUIC の信頼性と速度の向上により、顧客はトラフィックのピーク時でもシームレスでスムーズなショッピング体験を得ることができます。 QUIC は、高速ページ読み込み時間や安全な支払いトランザクションなど、E コマース アプリケーションをサポートするために必要なパフォーマンスとセキュリティ機能を提供します。
テクノロジーが進化し成熟するにつれて、さらに多様で革新的なユースケースが出現し、新しいアプリケーションやサービスの開発が促進されることが期待できます。
CDNetworks はフル プラットフォームで HTTP/3 と QUIC をサポート
CDNetworks は QUIC プロトコルの機能の可能性を予見し、その開発をリードしました。 HTTP/3 の新時代を受け入れるために、CDNetworks は 5 年前にプラットフォームに QUIC プロトコルのサポートを実装し、HTTP/3 標準の正式リリース後の市場の要求に応えて、プラットフォーム全体をアップグレードしました。 gQUIC (Google QUIC) と iQUIC (IETF QUIC) のすべてのバージョンを完全にサポートするオリジナルの QUIC。
内部的には、CDNetworks はプラットフォームのフレーム処理能力を向上させ、パフォーマンスを最適化してマシンの消費を削減しました。内部テスト データの一部によると、ビットレート 1Mbps の QUIC ストリーム プル シナリオでは、新しいプラットフォームは、同じビジネス同時実行条件下で帯域幅パフォーマンスを 41% 向上させることができ、平均 CPU 消費量は 28% 削減されます。
ライブ ストリーミング シナリオでは、CDNetworks は高強度の品質最適化を実行して QUIC プロトコルの再送信効率とレート サンプリング計算能力を改善し、最適化された UDP パケット送信と GSO (Generic Segmentation Offload) 戦略により、不安定なビデオ ストリーミング品質の問題を効果的に解決しました。地域全体の貧弱なネットワーク環境で。 QUIC プロトコルと TCP プロトコルを使用してビデオ再生を比較したライブ ストリーミング プル シナリオに関するテスト結果の 1 つによると、次のデータが表示されます。
【コードレート】
非パケット損失環境では、QUIC と TCP のコード レートは類似していますが、20% パケット損失の下では、QUIC は一貫したコード レートを維持しますが、TCP は大幅に低下します。
【動画の滑らかさ】
スムーズさに関しては、1 時間ごとのサイクル中にプレーヤーのバッファーが補充される場合、テスト サンプルは吃音としてカウントされます。非パケット損失環境では、QUIC は、アプリケーション層のパッケージ化のための追加の暗号化操作により、TCP よりもわずかに滑らかさが低くなります。ただし、パケット損失の状況では、QUIC は TCP よりもはるかに優れています。
[TTFB]
テスト マシンによる再生要求の開始と最初のビデオ パケットの受信との間の時間間隔である TTFB (Time to First Byte) に関して、QUIC は 20% パケット損失の下で一貫した最初のパケット配信時間を維持します。一方、TCP は大幅な遅延を追加します。
QUIC関連製品
CDNetworks が最速の QUIC ストリーミングにどのように役立つかについて詳しく知りたい場合は、 コンタクト 私たちまたはクリック ここ 無料トライアル用。
