目次
QUICとは？
QUIC（Quick UDP Internet Connections）は、インターネット接続の速度、信頼性、セキュリティを向上させる最新のトランスポートプロトコルです。UDP上に構築されたQUICは、接続セットアップのレイテンシーを最小限に抑え、伝送制御プロトコル（TCP）の主要な制限であるヘッドオブラインブロッキングを排除します。これはHTTP/3の基盤となるトランスポートプロトコルであり、様々なネットワーク条件において、より高速なデータ配信とより安定したパフォーマンスを実現します。
当初はGoogleによって開発され、その後IETFによって標準化されたQUICは、現在、ウェブ通信のシェアを急速に拡大しています。W3Techsによると、QUICは全ウェブサイトの8.9%で使用されており、HTTP/3の採用率は38.7%に達しています。
以下のセクションでは、QUICの仕組み、重要性、そして使用例について説明します。
QUICの仕組み
QUICプロトコルを理解する一つの方法は、それをネットワークプロトコルスタックのトランスポート層でUDP上で動作するHTTP/2 + TLS + UDPと考えることです。
QUICは、その中核としてトランスポート層にUDPプロトコルを使用し、TCPプロトコルよりも低レイテンシーと高スループットを提供すると同時に、TCP接続を妨害することが多いネットワークミドルボックスを回避します。
QUICはトランスポート層セキュリティ（TLS 1.3）を統合しており、エンドポイント間で暗号化されたTLS接続を確立するために、以前のバージョン（TLS 1.2など）と比較してパフォーマンスとセキュリティを向上させ、第三者によるトラフィックの傍受や改ざんを著しく困難にします。
UDPの効率性、TLSのセキュリティ、そして上位層でのHTTP/2の多重化機能を組み合わせることで、QUICは今日のインターネット通信に高性能なトランスポートを提供します。
なぜQUICはTCPよりも優れているのか？
従来のTCPベースのプロトコルは、特にレイテンシー、柔軟性、信頼性の面で、現代のネットワーク環境において限界に直面しています。
QUICは、以下のようないくつかの重要な改善により、これらの課題に対処しています。
1. 高速なハンドシェイクと接続確立
TCPとTLSのハンドシェイクには複数のラウンドトリップが必要であり、接続確立に顕著な遅延が発生します。
QUICは、トランスポート層でUDPプロトコルを使用し、TLS 1.3をハンドシェイクプロセスに直接統合することで、このオーバーヘッドを削減します。
1-RTT接続確立をサポートし、キャッシュされたセッションキーを使用して戻ってくるクライアントに対して0-RTT再開を可能にします。その結果、クライアントはリクエスト開始後、より早くデータを送信できるようになり、最新のウェブアプリケーションのパフォーマンスが向上します。
2. 認証および暗号化されたパケット
TCPプロトコルヘッダーは暗号化も認証もされておらず、改ざん、インジェクション、傍受の脆弱性があります。
対照的に、QUICパケットはセキュリティ面で強力に保護されています。 初期ハンドシェイクで使用される一部の保護されていないパケット（InitialやRetryパケットなど）を除き、すべてのメッセージ本文は暗号化されています。したがって、QUICパケットへのいかなる変更も受信側で即座に検出でき、セキュリティリスクを効果的に低減します。
下図に示すように、紫色の部分はストリームフレームパケットの認証ヘッダーであり、黄色の部分は暗号化されたデータです。
3. 多重化の改善によるHoLブロッキングの回避
TCP接続では、単一のパケットが損失すると、ヘッドオブラインブロッキングによってすべてのストリームが遅延する可能性があります。
HTTP/2では、複数のデータストリームが単一のTCP接続を共有し、順番に配信される必要があります。パケットが損失すると、失われたパケットが再送信されるまで、たとえ他のストリームがすでに到着していても、後続のデータを処理できません。
QUICはトランスポート層で多重化を導入し、各ストリームがUDP上で独立して動作できるようにすることで、ウェブサーバーが複数の同時接続を効率的に処理し、接続全体に影響するヘッドオブラインブロッキング問題を解決します。
例えば、下図のストリーム1でパケット損失が発生した場合、影響を受けるのはそのストリームのみであり、他のストリーム（ストリーム2と3）は中断なくデータ伝送を続けます。
さらに、HPACKヘッダー圧縮のバリエーションであるQPACKは、冗長なデータ伝送を削減し、不安定なネットワーク条件下でのパフォーマンスをさらに向上させます。
4. プラガブルな輻輳制御
従来のネットワークスタックでは、輻輳制御はオペレーティングシステムのTCP実装と密接に結合されており、更新やカスタマイズが困難でした。
QUICは、Cubic、BBR、Renoなどのプラガブルな輻輳制御アルゴリズムや、特定のシナリオ向けのカスタムアルゴリズムをサポートします。 これらのアルゴリズムは、QUICが通常ユーザースペースに展開されるため、オペレーティングシステムやカーネルのサポートを必要とせず、アプリケーション層で実装できます。
同じアプリケーション内の異なる接続で異なる輻輳制御戦略を使用でき、システムのアップグレードやサービス中断なしに更新を適用できます。
5. 接続マイグレーション
TCP接続は、送信元インターネットプロトコル（IP）、送信元ポート、宛先IP、宛先ポートの4タプルに基づいています。これらの値のいずれかが変更されると、接続は切断されます。
しかし、QUIC接続は可変長の接続IDに基づいています。 接続IDが同じである限り、接続は切断や再接続なしで維持されます。
例えば、クライアントがIP1を使用してパケット1と2を送信し、その後ネットワークを切り替えてIP2に変更し、パケット3と4を送信した場合、サーバーはパケットヘッダーの接続IDフィールドに基づいて、4つのパケットすべてが同じクライアントから送信されたことを認識できます。
QUICが接続マイグレーションを実現できるのは、基盤となるユーザーデータグラムプロトコル（UDP）がコネクションレス型だからです。
6. 前方誤り訂正（FEC）
パケット損失は、特に不安定なネットワーク環境において、パフォーマンスに大きな影響を与える可能性があります。
QUICはFECをサポートしており、受信側は冗長パケットを使用して失われたデータを回復できるため、再送信の必要性が減り、ネットワーク状態が悪い状況での信頼性が向上します。
7. 継続的な進化のためのバージョニング
TCPのようなトランスポートプロトコルは、更新がオペレーティングシステムの変更に依存することが多いため、進化させることが困難です。
QUICは組み込みのバージョニングを導入しており、複数のプロトコルバージョンの共存と、既存の接続を切断することなく段階的なアップグレードを可能にしています。
8. カスタムフレームによる拡張性
QUICは拡張フレームもサポートしており、コアプロトコルを変更することなく新しい機能を導入できます。 拡張機能は標準化することも、特定のシナリオのためにプライベートで使用することもでき、相互運用性を維持しながらプロトコルレベルの革新を可能にします。
QUICとHTTP/3は今日どこで使用されているのか？
HTTP/3とQUICの採用が進むにつれ、レイテンシー、信頼性、接続安定性におけるその利点は、さまざまなネットワーク環境において、ますます多くのユースケースを可能にしています。
リアルタイム通信とストリーミング
HTTP/3とQUICは、低レイテンシーと安定した接続が重要なビデオ会議、オンラインゲーム、ライブストリーミングなどのリアルタイム通信やストリーミングに非常に適しています。
QUICの接続マイグレーションと劣悪なネットワーク条件下でのパフォーマンス向上は、起動遅延、バッファリング、リクエスト失敗の削減に役立ちます。
IoT（モノのインターネット）
モノのインターネット（IoT）環境では、デバイスは高速移動、洋上作業、山岳地帯など、不安定でリソースが制約された条件下で動作することがよくあります。メッセージキューイングテレメトリトランスポート（MQTT）などのTCPベースのプロトコルは、頻繁な再接続や高いオーバーヘッドに悩まされる可能性があります。
QUICは、より高速な接続確立と信頼性の低いネットワークでのパフォーマンス向上により効率を改善し、中断と伝送コストを削減します。
クラウドコンピューティング
より多くのサービスがクラウドに移行するにつれて、効率的で信頼性の高いクライアント・サーバー間通信がますます重要になっています。QUICは、多重化されたストリームとより高速な接続セットアップをサポートすることでクラウドパフォーマンスを強化し、分散アプリケーションの応答性を向上させます。
Eコマースとデジタル決済
Eコマースや決済システムにとって、パフォーマンスと信頼性はユーザー体験と取引成功率に直接影響します。QUICは、より高速なページ読み込み、ピークトラフィック時のより安定した接続、重要な操作のための安全なデータ伝送を確保するのに役立ちます。
CDNetworksは完全なQUICプロトコルサポートを提供します
CDNetworksは、QUICプロトコルの可能性を早期に認識し、その開発をリードしてきました。
CDNetworksはプラットフォーム全体でHTTP/3とQUICをサポートし、gQUIC（Google QUIC）と標準化されたiQUIC（IETF QUIC）のすべてのバージョンをサポートするように完全にアップグレードしています。
CDNetworksは内部で、プラットフォームのフレーム処理能力を向上させ、リソース消費を削減するためにプラットフォームパフォーマンスを最適化しました。
内部ベンチマークでは、1 MbpsのQUICストリームプルシナリオにおいて、同一の同時実行条件下で帯域幅パフォーマンスが41%向上し、平均CPU使用率は28%低下しています。
特にメディア配信に関して、CDNetworksはQUICの再送信効率とレートサンプリング精度を向上させるために広範な最適化を実施しました。また、UDPパケット伝送とGSO（汎用セグメンテーションオフロード）戦略も改善し、地域をまたぐネットワーク状態が悪い場合の不安定なビデオ品質に効果的に対処しました。
ライブストリーミングプルシナリオでQUICとTCPを比較した内部テストに基づき、以下の主な結果が得られました。
1. ネットワーク損失下でのビットレート安定性
安定したネットワークでは、QUICとTCPは同様のパフォーマンスを示します。20%のパケット損失下では、QUICは安定したコードレートを維持しますが、TCPのパフォーマンスは著しく低下します。
2. 様々なネットワーク条件下での再生スムーズさ
パケット損失のない環境では、QUICはアプリケーション層での追加の暗号化オーバーヘッドにより、わずかにスムーズさが低下します。しかし、パケット損失条件下では、QUICはTCPよりも著しく優れたパフォーマンスを発揮します。
3. パケット損失条件下での最初のバイトまでの時間（TTFB）
QUICは20%のパケット損失下で一貫した最初のバイトレイテンシーを維持しますが、TCPは顕著な遅延を経験します。
CDNetworksがどのように最速のQUICストリーミングを支援できるかについて詳しくは、お問い合わせいただくか、無料トライアルはこちらをクリックしてください。
QUIC FAQ
QUICを使用しているアプリは？
Chrome、YouTube、Gmail、Google Maps、Facebookなどの多くのウェブブラウザがQUICを使用しています。多くのストリーミングプラットフォームやクラウドサービスもQUICを採用しています。
QUICをブロックすべきですか？
QUICのブロックは詳細なトラフィック検査を必要とする企業に適していますが、ユーザー体験を劣化させ、コンテンツ配信を遅くする可能性があります。
QUICはTLSプロトコルを置き換えるのですか？
QUICはTLS 1.3をプロトコルに直接統合しており、セキュリティ標準として置き換えるのではなく、強化しています。
QUICがセキュリティ上の懸念となり得る理由は？
暗号化されたUDPトラフィックは、従来のファイアウォールの可視性を制限し、トラフィック検査を複雑にする可能性があります。