ブログ | CTO オフィス

QUIC がインターネットを食い尽くす

F5 サムネイル
F5
2021年2月22日公開


QUIC (頭字語ではありません) はユニークな存在ですが、インターネットにおける長年の多くの問題を解決し、TCP、TLS、SCTP、IPSec、HTTP/2 によって提供される価値のほとんどを獲得する新しいトランスポート プロトコルと考えるのが最適です。 HTTP/3 と呼ばれる HTTP の新しいバージョンがあり、TCP/TLS ではなく UDP/QUIC 上で動作するように設計されてます。

Google は 2014 年に早くも、ブラウザと Web サーバーに HTTP over QUIC の初期バージョンを導入しました。 IETF 標準化プロセスは 2016 年に開始されました。 多くの進化とデータ収集を経て、2021 年初頭に最初の RFC バッチが完成する予定です。 F5 を含むいくつかの大手インターネット企業は、QUIC を使用する製品を出荷しているか、自社のインフラストラクチャに QUIC を導入しています。 2020 年 10 月現在、 Facebook のトラフィックの 75% はHTTP/3 と QUIC 経由です。

これらの早期導入と、IETF における QUIC をベースとした新しい標準に対する熱意は、これがインターネット上の最先端のアプリケーションにとって重要な、そしておそらくは支配的な基盤となることを示しています。

技術概要 - なぜ QUIC なのか?

クイックレイヤー
図1. QUIC は多くのレガシー プロトコルから機能を引き出します。

図 1 は、QUIC が何をするのかを読者に示します。 しかし、この機能分解では、業界の早期導入者がなぜ QUIC に移行しているのかは明らかになりません。

  1. レイテンシが低い。 Web のようなデータ転送は、TCP 用に 1 つ、TLS 用に少なくとも 1 つ、HTTP 要求/応答用に 1 つという 3 つの層のハンドシェイクの遅延によって左右されます。 TCP/TLS の最近の開発により、原理的にはこれを 1 回の往復に短縮できますが、実際にはほとんど機能しません。 QUIC はこれを 1 回の往復、最大 2 回に削減します。

  2. ストリーム。 HTTP/2 と同様に、QUIC はアプリケーションに複数のバイト ストリームを提供し、同じ接続を介して配信される概念的に異なるデータの独立性を高めます。 輸送中にこれを行うと、この独立性は高まるだけです。 ストリームはストリーミング ビデオ配信のニーズに自然に適合しており、主要なインターネット コンテンツ プロバイダーは QUIC 経由でのストリーミング配信に向けて順調に進んでいます。

  3. 損失への対応が向上。 QUIC の設計により、TCP のパケット損失を検出して回復する能力が向上します。 さらに、単一の順序どおりのバイト ストリームではなく多重化されたストリームを提示することで、1 つのオブジェクトを含むパケットが失われても、別のオブジェクトの配信が遅れることはありません。

  4. マルチホーミング。 MPTCP や SCTP と同様に、QUIC 接続はエンドポイントごとに複数の IP アドレスに関連付けることができます。 これらのプロトコルとは異なり、QUIC は、馴染みのないプロトコル番号や TCP ヘッダー オプションをドロップするインターネット上でも成功する可能性が高いです。

  5. セキュリティとプライバシー。 QUIC は、トランスポート層の上層ではなく、トランスポート層で暗号化を適用します。 UDP ペイロード全体が認証され、仲介者による透過的な変更が防止され、ほぼすべてのトランスポート情報が暗号化されます。 この影響はそれ自体がホワイトペーパーになるほどです。 これによりプライバシー特性が大幅に向上し、TCP が提供する攻撃対象領域が実質的に排除されると言うだけで十分でしょう。 IPSec とは異なり、これは現在 Web 規模で実行されています。 また、次のような結果も生じます。

  6. 拡張性。 TCP は、作成者が拡張スペースを限定的に残しており、ミドルボックスが古い TCP の動作を強制するため、変更が困難です。 QUIC は明示的なバージョン管理とミドルボックスへの不透明性を組み合わせることで、トランスポートにおけるさらなる革新を可能にします。 これにより、将来のユースケースをサポートし、最終的には TCP と比較してバルク転送容量を向上させることができます。

慣性の他に、一部のアプリケーションが QUIC に移行しない理由は 2 つあります。

  • 複雑さ:単一のバイトストリームのみを必要とし、暗号化を気にしないアプリケーションでは、これらの機能に関連する追加のワークロードは必要ありません。

  • ミドルボックス: インターネット パスの無視できない割合は UDP を許可しません。 HTTP/3 はこれらのパスに対して TCP フォールバックを使用するように設計されていますが、監視を希望する国家が別の方法を義務付けている場合を除き、最終的には主要な Web サイト (Google、Facebook など) へのパフォーマンスへの影響により、責任のあるデバイスが廃止される可能性があります。

インターネットを食い尽くしている

Google Chrome、Google アプリ クライアント、Facebook アプリはすでに HTTP/3 をサポートしています。 Safari、Edge、Firefox の実装ではこれをサポートしていますが、(現時点では) デフォルトではオフになっています。

サーバー側では、Google、Microsoft、Facebook、Apple、Cloudflare、LiteSpeed、F5 BIG-IP、NGINX、Fastly、Akamai による実装や展開がすでに出荷されているか、出荷間近です。 最近、ヨーロッパの大手 ISP は、パケットの 20% が QUIC であると報告しました。2021 年 2 月時点でHTTP/3 を使用している Web サイトは約 5% ですが、RFC が公開されるとこの割合は増加すると予想されます。

さらに、標準化団体では、QUIC を HTTP の使用例を超えて活用するための作業が盛んに行われています。 IETF の標準草案では、DNS、Websocket、SIP、および QUIC 経由の TCP と UDP トンネルの両方が提案されています。QUIC は 5G アーキテクチャに完全に組み込まれるには少し遅すぎましたが、サービス プロバイダーにとって QUIC が関心を集め、適用可能であることは明らかです。 最後に、HTTP/2 と HTTP/3 の上位 API は非常に似ているため、HTTP/2 上で実行されるプロトコルやアプリケーションは、TCP ではなく HTTP/3 および QUIC 上で実行するように簡単に移植できます。

脅威と機会

QUIC と HTTP/3 はさまざまな市場を形成します。 高性能な Web サイトやアプリケーションは、エコシステムが完全に成熟すると HTTP/3 と QUIC に切り替える強い動機があり、お客様は HTTP/2 の導入と同程度のペースで HTTP/3 のサポートを要求すると予想しています。

QUIC ベースのインターネットでは、セキュリティ製品を根本的に再評価する必要があります。 TLS セッション キーにアクセスできない場合、パケット検査は非常に困難になります。TLS セッション キーへのアクセスは、通常、ドメインの秘密キーを所有している場合にのみ可能です。 これにより、一連の単機能デバイスではなく、アプリケーション レベルのプロキシと統合されたセキュリティ ソリューションの価値が向上します。

さらに、従来の DDoS 防御には調整が必要です。 パケットの識別と検査が困難になるだけでなく、TCP シンクッキーが「再試行パケット」に置き換えられ、仲介者が簡単に偽装できなくなります。 サーバーが再試行パケットの生成と検証をオフロードできるように調整する標準的な方法はありますが、この場合も開発作業が必要になります。

従来のレイヤー 4 ロード バランシングでは、アドレスまたはポートを変更するフローを自身に関連付けて同じサーバーにルーティングすることができないため、QUIC アドレスの移行が中断されます。 繰り返しになりますが、この問題を調整して克服するための標準は存在しますが、それには投資が必要です。

IETF のMASQUE ワーキング グループは、次世代 VPN スキームの基礎となる可能性のある、QUIC を介した汎用トラフィック トンネリングに取り組んでいます。 QUIC の特性は、TCP 経由の TLS よりも任意のフローを多重化するのに適しています。 これらのトンネルは、IPSec トンネルを Web スケールの暗号化に置き換えて、一部のサービス プロバイダーのユース ケースを改善し、さらに、明示的なクライアントの同意を得てモバイル リンク タイプ向けに QUIC 接続を最適化する方法も提供します。

QUIC には、新しいネットワーク測定および分析ツールが必要になります。 TCP の遅延と損失を測定できるシステムはこれらの信号を使用できませんが、ネットワークへの明示的な遅延信号があり、他の信号が送信中である可能性があります。 暗号化によって隠された転送情報が増えると、パケット キャプチャの有用性は低下します。 ただし、多くの QUIC 実装が従う新しい標準ログ形式があり、それを活用する分析ツールが構築されています。

F5は動向を注視している

F5 のスタッフは長年にわたり IETF の標準化の取り組みを監視し、お客様の役に立つと思われる分野に貢献してきました。 BIG-IP は、TMOS v15.1.0.1 以降の公開リリースを含め、QUIC および HTTP/3 のドラフト リリースを当初から追跡してきました。 NGINX にはHTTP/3 アルファリリースがあり、まもなくメインラインにマージされる予定です。

当社はこの分野の動向を引き続き注視し、これらのプロトコルが提供する新しい機能を反映した新しい魅力的な製品を構築していきます。

結論

QUIC は業界で幅広くサポートされており、インターネット経由でビジネス価値を提供するほとんどのアプリケーションの基盤となる可能性があります。 インターネット経由でアプリケーションを配信する人は誰でも、これらのプロトコルがもたらす新たな脅威と機会を反映して、自社の運用をどのように変更すべきかについて考え始める必要があります。