Fastly が QUIC と HTTP/3 を好む理由
Fastly では、非常に意図的かつ厳選して自社リソースを配置しています。これは、私たちがプロジェクトの規模ではなく、その種類や影響を重視しているからです。これが、 Fastly が今日のインターネットが使用しているものよりもレスポンスが早く、安全で柔軟性の高い新たなトランスポートプロトコルである QUIC への大きな投資を喜んでいる理由です。
QUIC は、 Internet Engineering Task Force (IETF) で標準化が進められており、IETF の QUIC ワーキンググループの議長および主要ドキュメントのエディターに Fastly のエンジニアリングチームが含まれています。また、私たちはこの新規プロトコルの独自実装であるquicly にも取り組んでいます。それでは、QUIC の詳細や Fastly が QUIC にリソースを費やす理由をご紹介していきましょう。
QUIC (および HTTP/3) とは
QUIC (頭字語ではありません) はまったく新しいインターネットトランスポートプロトコルで、現在最も広く使用されているトランスポート、TCP に置き換わるものです。TCP は、パケットロスが発生してもクライアントとサーバーが安定して通信し、アプリケーション間でリソースを円滑に共有し、送信時と同じ順番でデータが送信されるための方法を提供しています。
今の TCP は、1981 年に公開された RFC 793 で定義されたコアプロトコルに対する何十年にもわたる実験、経験、拡張の結果です。遡ること2013 年、HTTP ワーキンググループが HTTP/2 を開発するというタスクを引き受けた際、そのほとんどの焦点は HTTP による TCP の利用方法の最適化でした。このグループの目標は、ヘッドオブラインブロッキング (未処理の HTTP リクエストがレスポンスを受け取るまで接続の使用を効果的に阻止するもの) の排除でした。これに取り組むため、HTTP/2 はリクエストの多重化を導入し、単一の TCP 接続をはるかに効率的に使用できるようになりました。
しかし、HTTP の最適化には別の問題がありました。それは、TCP は受信先のアプリケーションへデータを順番に送信するため、TCP にもヘッドオブラインブロッキングが存在するということです。パケットロスが発生した場合、失われたパケットの再送信を受信するまで、TCP レシーバはその接続のすべての後続受信パケットを保留状態にします。その結果、後続受信パケットを使用できたとしても、アプリケーションは再送信を受信するまで待機しなければならなくなるのです (HTTP/2 のような複数の転送が一度に発生するプロトコルでも、TCP 接続の使用は一度切りです)。
この TCP のヘッドオブラインブロッキング問題は、HTTP/2 にさまざまな形で出現します。HTTP/2 はほとんどの場面で HTTP/1 より優れたパフォーマンスを発揮しますが、損失が多い接続や、損失は少ないけれどレイテンシが大きい接続など、接続が悪い場合はそれほど優れていません。
QUIC は、HTTP/2 のストリームレイヤーを一般的なトランスポートレイヤーに移動させることでこの問題に対処し、アプリケーションレイヤーとトランスポートレイヤーの両方でヘッドオブラインブロッキング問題を回避しています。これは UDP の上に TCP を構築するような、新たなサービスを構築することで実現しています。UDP には TCP のような順序保証や信頼性の高い配信、輻輳制御は搭載されていません。そこで QUIC は、UDP の上のレイヤーにこれらの機能を構築したのです。
さらに、QUIC は TLS 1.3 の過程を再利用する暗号化スキームを取り入れ、アプリケーション接続の機密性、認証性、完全性保護を保証しています。TLS は HTTPS のデータを保護する技術と同じですが、QUIC では TLS がデータもトランスポートプロトコルそのものも保護しています。このアプローチにより、データ転送をより早く開始することができるので、QUIC は TCP より早いレスポンスが可能になります。
この新しいトランスポートプロトコルを初めて適用したのが HTTP/3 です。これは QUIC の機能を活用するために設計された HTTP のバージョンですが、重要なことは、HTTP/3 では HTTP のセマンティクス (URL や HTTP ヘッダーの定義) が HTTP/2 と変わっていないということです。QUIC を使用することにより、HTTP/3 はアプリケーション (HTTP を使用するものすべて) コードを変更する必要なく、HTTP/2 のパフォーマンスの問題を処理します。HTTP/3 が HTTP/2 の完全互換であることは、素晴らしい改善です。
しかし、これは始まりに過ぎません。インターネットユーザーにとって、QUIC は他にどんな利点があるでしょうか?
ラストマイルのために作成
レイテンシの影響を受けやすい Web サービスが増加しており、インフラストラクチャの提供にこれまでにない要求が課されています。同時に、接続の悪いネットワークの背後に非常に多数のユーザーがいます。インターネットインフラストラクチャが劇的に改善されたとはいえ、世界的にインターネットを利用するユーザーが増えれば増えるほど、その数は増える傾向にあります。
QUIC は、損失やレイテンシのラストマイル問題を軽減することでパフォーマンス問題を改善し、特に貧弱な接続のユーザーに対して、現在良好な接続のユーザーよりも大きなメリットを与えるよう設計されています。この前提に従うならば、ほとんどの Web サイトやユーザー、特にオーストラリア奥地やインドの田舎、南太平の島々などの世界のサービスが行き届いていない地域のユーザーは、パフォーマンスが改善されるでしょう。Fastly は、世界のインターネット普及率が上がるほど QUIC の価値が高まると考えています。
Google が独自に開発したQUICの標準化前のバージョンでは、まさにこういった状況 (高損失や高レイテンシのネットワーク) での大幅な改善が見られます。具体的に Google は、一番レイテンシの高いデスクトップ接続におけるエンドツーエンドの検索レイテンシで 16.7 % の減少、また一番レイテンシの高いモバイル接続で 14.3 % の減少を確認しました。Google の検索ページが高度に最適化された URL であることを考えると、これは驚くべき改善です。動画については、最もトラブルの多いモバイルでの接続で再バッファリングが 8.7 % 減少しました。こうしたメリットは、QUIC のレイテンシ最適化ハンドシェイクや優れた損失回復から得られており、さらに重要なのは TCP やTCP 周りに構築されたインターネットエコシステムにおけるバグや非効率性をバイパスすることからもメリットを得ているということです。
アジリティの新たな兆し
私たちが使用するトランスポートプロトコルは、ますます要求の厳しくなるアプリケーションとその配下の混沌としたインターネットを効果的に繋ぐものとしての役割を果たし続けるために、適応し、進化する必要があります。現在、TCP ではこれが簡単でにはいかないのには 2 つの理由があります。
まず、TCP は通常クライアントとサーバー両方のオペレーティングシステム (OS) のカーネル内に実装されており、TCP への変更にはカーネルの変更やアップグレードが必要です。カーネルの変更はシステム全体へ影響するので、通常は慎重かつゆっくりとサーバーにデプロイされるものです。
より速いアップグレードサイクルを持つモバイル OS でも、クライアントは問題だらけです。これは相当数のユーザーが最新 OS やカーネルから何年も前のバージョンを使用していたり、OS をまったくアップグレードしないユーザーも多く存在するためです。その結果、現在のインターネットではシンプルなトランスポートレベルの変更でも展開するのに何年もかかっています。
QUIC は UDP の上に構築され、一般的にユーザースペースで実行されるため、急速な進化に適しており、サーバーとクライアント両方で迅速な変更の展開が可能です。
次に、インターネットエコシステムはもはや TCP の変更を許可しません。TCP ヘッダーの検査や修正する TCP 「最適化」ボックスなど、過去 20 年にわたるインターネットの成長で、サーバーとクライアント間のネットワーク要素の数が大幅に増加しました。ミドルボックスと呼ばれるこれらのネットワーク要素が介在することで、サーバーとクライアントのどちらも望んでいたとしても、TCP ヘッダーや動作への変更を意図せず許可しないことが多くあります。結果として、インターネットエコシステムは TCP の固定化、つまり TCP の小さな変更も意図しない結果なしには展開できなくなりました。TCP Fast Open (TFO) は、そのような TCP の修正の一例です。TFO は初回提案から 8 年経っても広まっていませんが、この大部分はミドルボックスが原因です。
これも QUIC の設計力が光る部分です。QUIC は、トランスポートデータとプロトコル自体を暗号化し、さらに暗号的に認証し、ミドルボックスによるプロトコルヘッダーの検査や変更を防いで、その過程でプロトコルの将来性を保証します。また、QUIC にはバージョニングが搭載されています (TCP にはありません)。これにより、今後の必要性に応じて自由に深く広範囲な変更を検討することができます。また、バージョニングのおかげで POP 内で構築、調整、デプロイできる代替バージョンを検討することもできます。これについては、これからご説明します。
よりスマートな POP
Fastly は、QUIC が Fastly の Points of Presence (POP、つまりデータセンター) 内のトラフィックを管理しながらもエッジの接続処理やスケーラビリティを改善できる方法は 2 つあると考えています。
まず、輻輳制御や損失回復などのさまざまなトランスポートの修正を試し、Fastly POP のサーバー間のトラフィックレイテンシや効率性を改善したいと考えています。ユーザースペースにある QUIC は、Fastly のツールやロギングインフラストラクチャともより良い形でより深く統合することができ、各種実験からさらに容易に実行、学習することができるようになります。
第二に、QUIC はトラフィック送信者の目的を受信者の目的から切り離すことで、多大な柔軟性をもたらします。ここで苦境に陥ることなく 2 つを分離するということは、原則的には受信者に変更を強いることなくサービスを最適化できるということを意味します。つまり、エンドユーザーに何の変更を強いることなく、Fastly 独自の CDN や POP のアーキテクチャに効果的に合わせて QUIC の仕様を形成することができ、結果としてユーザーにより低レイテンシを提供できる可能性があるのです。Fastly はこの領域でアイディアを探索しており、その秘めた可能性に期待しています！
そしてもちろんQUIC には、扱っているアーキテクチャに関係なく、CDN やその他のサーバー事業者が興味を持つであろうことがまだまだ多くあります。例えば、より多くのトランスポートを暗号化して、ユーザーをより安全にする方法などです。また、ステートレスな負荷分散や接続モビリティを可能にし、クライアントが接続を失うことなくネットワーク間 (例えばWi-Fi と携帯ネットワーク間など) をシームレスに移動できるようにする方法もあります。
今後の展望
QUIC はまだ標準化段階です。現在 IETF 版には 20 以上の実装 (Fastly を含め) がありますが、相互運用性と完全な HTTP 機能に向けて皆熱心に取り組んでいます。ワーキンググループは、主なドラフトを今年中に最終化したいと考えており、IETF 版の QUIC も年内中にブラウザで利用できるようになる予定です。
QUIC の利点は、Google の制限された環境外で Web サイトや事例の多様性を証明する必要があります。私たちは、サーバーとブラウザの実装両方に最適化、強化、運用経験が必要となる期間が長くなるのではないかと考えています。終わりは見えてきていますが、まだやることはあります。
それはもちろん問題ありません。Fastly、そしてインターネット全体にとって、投資し、待つだけの価値があると考えているからです。HTTP/3 のサポートが一般に利用可能なクライアントで使えるようになり、お客様と共にこの刺激的な新技術をテスト、デプロイ、革新できることを楽しみにしています。
