QUICとは？ HTTP/3 をどのように強化するのか?

2023年3月7日

CDNetworks を無料で試す

当社のほとんどの製品には、14 日間の無料試用版があります。クレジットカードは必要ありません。

この投稿を共有

QUICとは？

HTTP/3 と、それ以来の最新かつ最高のバージョンの HTTP プロトコルを使用して、インターネットの未来に備えることができます。 HTTP3 がすでに登場しているため、Web サイトの所有者とインターネットユーザーは、これまで以上に高速で信頼性が高く、安全なオンラインエクスペリエンスを期待できます。これはすべて、QUIC (Quick UDP Internet Connection) として知られる革新的な新しいトランスポートプロトコルの基盤によるものです。

2021 年 5 月には、 IETF 標準化されたQUIC RFC 9000、RFC でサポート 8999、RFC 9001 およびRFC 9002その後、2022 年 6 月 7 日、IETF は QUIC ベースの HTTP/3 を公式に公開しました。提案された基準 RFCで 9114.

現在、世界中でQUICの導入が加速しています。 QUIC IETF-v1 プロトコル標準の出現により、ますます多くの Web サイトが QUIC トラフィックを使用し始めています。の統計によると、 W3Techs、約 25.5% の Web サイトが当面 HTTP/3 を使用します。
ネットワーク分野のパイオニアとして、CDNetworks は QUIC プロトコルの包括的なサポートを完成させることに率先して取り組んできました。以下の表は、CDNetworks がサポートする現在の QUIC バージョンを示しています。

それはどのように機能しますか?

ある側面からの説明として、QUIC = HTTP/2 + TLS + UDP であり、UDP + QUIC = トランスポート層です。

QUIC はトランスポートプロトコルとして UDP を採用しており、TCP よりもレイテンシが低く、スループットが高く、TCP に干渉する可能性のあるネットワークミドルボックスを QUIC がバイパスすることもできます。 QUIC には TLS 1.3 に基づく組み込みの暗号化プロトコルが含まれており、エンドポイント間の安全な通信を提供し、第三者がインターネットトラフィックを傍受して操作することを困難にします。 SMB のようなプロトコルからのコマンドとバージョン管理のダッシュを散りばめ、次に新しいプロトコルの概念と効率のセットを混ぜ合わせます。そこで QUIC の出番です。UDP の速度と効率、TLS のセキュリティ、そして TLS の機能を組み合わせます。 HTTP/2: 最新のインターネット向けの信頼性が高く高性能なトランスポートプロトコルを作成します。

QUIC が重要な理由

QUIC がリリースされる前は、HTTP でデータを転送するための基本プロトコルとして TCP が使用されていました。ただし、モバイルインターネットが発展し続けるにつれて、リアルタイムの対話とより多様なネットワークシナリオに対する需要が高まっています。さらに、スマートフォンとポータブルデバイスがますます主流になり、現在 60% を超えるインターネットトラフィックがワイヤレスで送信されています。

ただし、40 年以上にわたって使用されてきたトランスポート層通信プロトコルである従来の TCP には、現在の大規模な長距離、貧弱なモバイルネットワーク、および頻繁に発生するネットワークスイッチングという状況では、固有のパフォーマンスボトルネックがあります。主に次の 3 つの理由による要求:

接続確立時のハンドシェイク遅延が大きい

HTTP1.0/1.1 であろうと、HTTPS、HTTP2 であろうと、それらはすべて伝送に TCP を使用します。 HTTPS と HTTP2 では、安全な伝送のために TLS プロトコルを使用する必要もあります。これにより、2 つのハンドシェイク遅延が発生します。

TCP 3 ウェイハンドシェイクによって発生する TCP 接続確立の遅延。

完全な TLS ハンドシェイクを確立するには、少なくとも 2 つの RTT が必要であり、単純化されたハンドシェイクには 1 つの RTT ハンドシェイク遅延が必要です。

多くの短い接続シナリオでは、このようなハンドシェイクの遅延は重大な影響を及ぼし、排除することはできません。

行頭ブロッキング

HTTP/2 の多重化を例にとると、複数のデータ要求が同じ TCP 接続で異なるストリームとして送信され、アプリケーション層のすべてのストリームを順番に処理する必要があります。ストリームのデータが失われた場合、その背後にある他のストリームのデータは、失われたデータが再送信されるまでブロックされ、受信側が後続のストリームのデータパケットを既に受信していても、アプリケーション層には通知されません。この問題は、TCP ストリームのヘッドオブラインブロッキング (HoL) と呼ばれます。

TCP プロトコルの更新を促進するのはそれほど簡単ではありません

TCP プロトコルは、当初、ポート、オプション、および機能の追加と変更をサポートするために設計されました。ただし、TCP プロトコルとよく知られているポートとオプションの長い歴史により、多くのミドルボックス (ファイアウォールやルーターなど) はこれらの暗黙のルールに依存するようになりました。その結果、プロトコルの変更がこれらのミドルボックスで適切にサポートされない可能性があり、相互運用性の問題が発生する可能性があります。

TCP プロトコルはオペレーティングシステムのカーネルに実装されていますが、Windows XP などの多くの古いシステムプラットフォームには依然として多数のユーザーが存在するため、ユーザー側のオペレーティングシステムのバージョンをアップグレードすることは非常に困難です。さらに、TCP ユーザーはその機能に満足しており、その動作に影響を与える可能性のある変更に抵抗する可能性があります。そのため、TCP プロトコルの更新を迅速にプロモートするのはそれほど簡単ではありません。

なぜQUICが必要なのか?

QUIC の出現により、ラストマイルでのネットワーク伝送の問題が解決されました。 QUIC の主な改善点は次のとおりです。

高速ハンドシェイクと接続確立

QUIC は次の 2 つの側面で最適化されています。

トランスポート層は 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 パケットの変更は受信側で即座に検出され、セキュリティリスクが効果的に軽減されます。

下の図に示すように、紫色のコンテンツはストリームフレームパケットの認証されたヘッダーであり、黄色の部分は暗号化されたコンテンツです：

QUIC は、接続上で複数のストリームを多重化するという概念を導入しました。ストリームごとに個別のフロー制御を設計および実装することにより、QUIC は、接続全体に影響を与えるヘッドオブラインブロッキングの問題を解決します。

QUIC の多重化は HTTP/2 に似ています。複数の HTTP リクエスト (ストリーム) を 1 つの QUIC 接続で同時に送信できます。しかし、QUIC の多重化が HTTP/2 を凌駕するのは、単一接続上の各ストリーム間に連続的な依存関係がないことです。つまり、ストリーム 2 が UDP パケットを失った場合、ストリーム 2 の処理にのみ影響し、ストリーム 1 と 3 のデータ転送はブロックされません。その結果、このソリューションはヘッドオブラインブロッキングにつながりません。

さらに、QPACK と呼ばれる HPACK ヘッダー圧縮形式のバリエーションは、QUIC の新機能として、ネットワーク上で送信される冗長データの量を減らし、ヘッドオブラインブロッキングを軽減するように設計されています。このように、QUIC は週のネットワークシナリオで TCP よりも多くのデータを受信できます。

プラグ可能な輻輳制御

QUIC は、Cubic、BBR、Reno などのプラグ可能な輻輳制御アルゴリズムをサポートするか、特定のシナリオに基づいてプライベートアルゴリズムをカスタマイズします。「プラグ可能」とは、柔軟に発効、変更、停止できることを意味します。これは、次の側面に反映されます。

オペレーティングシステムやカーネルサポートを必要とせずに、さまざまな輻輳制御アルゴリズムをアプリケーション層に実装できますが、従来の TCP 輻輳制御では、制御効果を得るためにエンドツーエンドのネットワークプロトコルスタックが必要です。
単一のアプリケーションの異なる接続は、異なる輻輳制御構成をサポートすることができます。
アプリケーションは、ダウンタイムやアップグレードなしで輻輳制御を変更できます。私たちが行う唯一のことは、構成を変更してサーバー側で再ロードすることです。

接続の移行

TCP 接続は、送信元 IP、送信元ポート、宛先 IP、および宛先ポートの 4 つのタプルに基づいています。これらの変更のいずれかが発生した場合、接続を再確立する必要があります。ただし、QUIC 接続は 64 ビットの接続 ID に基づいているため、接続 ID が同じままである限り、接続を切断して再接続することなく接続を維持できます。

たとえば、クライアントが IP1 を使用してパケット 1 と 2 を送信し、ネットワークを切り替えて IP2 に変更し、パケット 3 と 4 を送信した場合、サーバーは、パケットの接続 ID フィールドに基づいて、4 つのパケットすべてが同じクライアントからのものであることを認識できます。ヘッダ。 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 よりもはるかに優れています。