このブログでは、ACM Internet Measurement Conferenceで発表された、ORIGINフレームを使用したconnection coalescing（接続の結束）を計測しプロトタイプ化したCloudflareの研究論文の内容を要約して紹介します。
読者の中には、1回のWebページへのアクセスで、ブラウザが何十回、時には何百回ものWeb接続を行うことがあると聞いて驚く方もいるでしょう。このブログを例にお話しします。Cloudflareのブログに初めてアクセスした場合、あるいは前回のアクセスからしばらく時間が経っている場合、ブラウザはページを描画するために複数の接続を行います。ブラウザは、blog.cloudflare.comに対応するIPアドレスを見つけるためにDNSクエリを実行し、その後、完全なページを正しく描画するために必要なWebページ上の必要なサブリソースを取得するためのリクエストを行います。その回数は？下図を見ると、この記事の執筆時点で、Cloudflareのブログの読み込みには32のホスト名が使用されています。これはクライアント側がこれらの接続の一部を再利用（または結束）できない限り、32回のDNSクエリと_最低_32回のTCP（またはQUIC）接続が発生することを意味します。
新しいWeb接続が発生するたびに、サーバーの処理能力に新たな負荷がかかる（利用がピークに達する時間帯にはスケーラビリティの問題につながる可能性があります）だけでなく、クライアントのメタデータ（個人がアクセスしている平文のホスト名など）がネットワークに公開されます。平文で公開されるメタデータは、ネットワーク経路上に敵対者や盗み見ようとする者に、ユーザーのオンライン活動や閲覧行動が知られてしまう可能性があります！
このブログでは、「connection coalescing（接続の結束）」技術について詳しく見ていきます。2021年にIP-based coalescing（IPベースの結束）を最初に見て以来、私たちはインターネット全体でさらに大規模な測定とモデリングを行い、結束が機能する場所やその可能性について理解し、予測するための取り組みを行ってきました。IP coalescingは大規模に管理することが難しいため、昨年、「HTTP/2 ORIGINフレーム拡張」と呼ばれる将来性のある標準（これを利用するとIPアドレスの管理を気にすることなくエッジへの接続を結束できる）を実装し、実験を行いました。
つまり、多くの大手プロバイダーがチャンスを逃しているのです。このブログ（ACM IMC 2022での詳細を掲載した出版物）が、サーバーとクライアントがORIGINフレーム標準を活用するための第一歩となることを願っています。
ステージの設定
大まかに言うと、ユーザーがWebを移動すると、ブラウザは依存するサブリソースを取得してWebページを描画して完全なWebページを構築します。このプロセスは、工場で物理的な製品を組み立てる様子に酷似しています。その意味で、現代のWebページは組立工場のようなものだと考えることができます。組立工場の場合、最終製品を生産するために必要な資源を供給する「サプライチェーン」に依存しています。
現実世界の組立工場では、1度の注文で複数種類の部品を注文して、1回の出荷でサプライヤーからそれらを受け取ることができます（送料などの無駄なコストを抑え、時間を短縮するためのキッティング・プロセスのようなものです）。部品の製造元や製造場所を気にすることなく、サプライヤ1社との「取引関係」があれば十分です。サプライヤーから組立工場への1台のトラックに、複数のメーカーの部品を積み込むことができます。
Webの設計により、通常、ブラウザはこの逆の性質の動作をします。Webページの画像やJavaScript、その他のリソース（部品）を取得するために、Webクライアント（組み立て工場）は、サーバー（サプライヤー）から返されたHTMLに定義されたすべてのホスト名（製造元）に対して_少なくとも_1つの接続を行う必要があります。これらのホスト名への接続が同じサーバーに接続されているかどうかは関係ありません。例えばCloudflareのようなリバースプロキシに接続することもあります。同じサプライヤーから組立工場に材料を配送するために製造業者ごとの「新しい」トラックが必要になります。より正式には、同じWebページ上のホスト名からサブリソースを要求するために新しい接続を行う必要があります。
接続の結束なし
Webページを読み込むために使用する接続の数は、驚くほど多くなることがあります。また、先行の接続の結果として新しい接続が発生するサブリソースが他のサブリソースを必要とすることもよくあります。また、多くの場合ホスト名を使用したHTTP接続には、接続前にDNSクエリが発生します。Connection coalescing（接続の結束）技術を使用することで、使用する接続の数を減らすことができます。つまり、同じトラックのセットを「再利用」して、サプライヤー1社から複数のメーカーの部品を配送することが可能になります。
接続の結束あり
Connection coalescing（接続の結束）技術の原理
Connection coalescing（接続の結束）技術はHTTP/2で導入され、HTTP/3に引き継がれました。私たちは以前、Connection coalescing（接続の結束）についてのブログを書いています（基礎に関する詳しい内容は、そのブログを読むことをお勧めします）。アイデアは単純ですが、それを実装することは多くの設計上の課題が生じる可能性があります。例えば、あなたが今読んでいるこのWebページを読み込むために必要なホスト名が32個（執筆時点）あることを思い出してください。32のホスト名の中には、ユニークな16のドメイン（「有効なTLD+1」と定義）があります。各ユニークドメインごとに作成する接続の数を減らしたり、既存の接続を「まとめる」ことはできるでしょうか？「できます。ただし、状況によります」が答えになります。
ブログページを読み込むのに必要な接続数を正確に知ることはほぼ不可能です。16のドメインに32のホスト名が関連付けられているかもしれませんが、「ユニークな接続数」が16であるとは限りません。すべてのホスト名が1台のサーバー上でホストされていれば必要な接続は_1_となり、それぞれのホスト名がそれぞれ別のサーバーでホストされていれば必要な接続数は32となります。
接続の再利用には様々な形態があるため、HTTP空間における「connection coalescing（接続の結束）」を定義することは重要です。例えば、ホスト名への既存のTCPまたはTLS接続を再利用して、_同じ_ホスト名から複数のサブリソースをリクエストすることは「接続の再利用」ですが、「結束」ではありません。
Coalescing（結束）は、あるホスト名に対する既存のTLSチャネルを再利用したり、_別の_ホスト名への接続に転用する場合に発生します。例えば、アクセスしたblog.Cloudflare.comのHTMLがcdnjs.Cloudflare.comのサブリソースを指しているとします。サブリソースに同じTLS接続を再利用するには、TLS証明書の「Server Alternative Name（SAN）」リストに両方のホスト名が一緒に記載されている必要がありますが、このステップだけではブラウザに結束を指示するには不十分です。結局のところ、cdnjs.Cloudflare.comサービスは、同じ証明書上にあっても、blog.Cloudflare.comと同じサーバー上でホストされている場合とそうでない場合があります。では、ブラウザはどのように知ることができるのでしょうか？coalescing（結束）は、サーバが適切な条件を設定した場合にのみ機能しますが、結束するかどうかの判断はクライアント側がする必要があります。先ほどの例に戻ると、組立工場は、サプライヤーがすでに倉庫に同じ部品を持っていることを知らずに、部品をメーカーに直接注文するかもしれません。
ブラウザが結束の可否を判断するための材料は2つあり、1つはIPベース、もう一つはORIGINフレームベースです。前者は、サーバオペレータがサーバ上で利用可能なHTTPリソースにDNSレコードをバインドしておく必要があります。この方法では、すべてのリソースを特定のセットまたは1つのIPアドレスの背後に配置する必要があるため、管理と展開が困難であり、実際には危険な依存関係が作成されてしまいます。IPアドレスが結束の可否に影響を与える方法はブラウザによって異なり、より保守的なものを選ぶものもあれば、より寛容なものもあります。また、HTTP ORIGINフレームはサーバーにとって調整しやすい判断材料であり、柔軟性があり、（仕様に準拠した実装であれば）サービスを中断しないグレースフル・フェイラーが可能です。
この2つの結束の可否を示す判断材料の基本的な違いは、IPベースのものは暗黙的で、偶発的であり、クライアント側が推測する必要があります（IPアドレスは名前と実際の関係を持たないように設計されているため、当然と言えます）が、それとは対照的に、ORIGINフレームはサーバーからクライアント側に提供される結束の可否を示す明示的なシグナルです（特定のホスト名に対するDNSのレスポンスは関係ありません）。
私たちは以前、IPベースの結束について実験を行いました。このブログではORIGINフレームベースの結束について詳しく見ていきます。
ORIGINフレームの規格は？
ORIGINフレームはHTTP/2とHTTP/3仕様を拡張したものです。それぞれ接続のストリーム0または制御ストリームで送信される特別なフレームであり、このフレームを使うことで、サーバーは_既存の_確立されたTLS接続でクライアントに‘origin-set’を送信することができます。これには、承認されており、HTTP 421エラーが発生しないホスト名が記載されています。origin-setに記載のあるホスト名は、たとえDNSからそのホスト名を異なるIPアドレスでアナウンスされたとしても、サーバーの証明書SANリストにも記載されている必要があります。
具体的には、2つの異なるステップが必要です：
WebサーバーがORIGINフレーム拡張を使用して配信元のセット（指定された接続が使用される可能性のあるホスト名）を列挙したリストを送信するように設定する必要があります。
送信されたORIGINフレームにある追加のホスト名を、Webサーバーから返されるTLS証明書のDNS名のSANエントリに記載する必要があります。
大まかに言えば、ORIGINフレームはTLS証明書を補完するものであり、オペレータはこれを付加して「ちょっと待って！クライアントさん、この接続で利用可能なSANの名前はこれで、結束できますよ！」と伝えることができます。ORIGINフレームは証明書自体の一部ではないため、その内容を独自に変更することができます。新しい証明書は必要ありません。また、IPアドレスに依存することもありません。ホスト名が結束可能な場合、新しい接続やDNSクエリを必要とせずに既存のTCP/QUIC+TLS接続を再利用することができます。
現在の多くのWebサイトは、Cloudflare CDNサービスのようなCDNによって提供されるコンテンツに依存しています。Webサイトの提供に外部のCDNサービスを利用することで、高速性、信頼性を高めながらコンテンツを提供する配信元サーバーの負荷を軽減することができます。同じCDNが提供することで、Webサイトとリソースがどちらも異なるホスト名、異なるエンティティによって所有されている場合も、CDNオペレータは、証明書管理とORIGINフレームを送信するための接続要求の両方を本物の配信元サーバーに代わって制御することができるため、接続を再利用し、結束させることができます。
残念ながら、ORIGINフレームが生み出した可能性を実践に移す方法はありませんでした。私たちの知る限り、今日までORIGINフレームをサポートするサーバー実装はありませんでした。数あるブラウザの中でORIGINフレームに対応しているのは唯一Firefoxだけです。IPベースの結束は、ORIGINフレームにはサポートが導入されておらず、困難が伴います。結束をより適切にサポートするために必要なエンジニアリング時間と労力は投資に見合うものでしょうか？私たちは、その機会を理解し、可能性を予測するために、インターネット全体の大規模な測定で調べることにし、ORIGINフレームを実装して、実動トラフィックでの実験を行いました。
実験1：必要な変更の規模は？
2021年2月、私たちは100台の仮想マシン上で修正したWebページテストを使用し、インターネット上で最も人気のあるWebページ50万件分のデータを収集しました。キャッシングの影響を排除するため（キャッシングではなく、結束を理解するため）、Webページへのアクセスの都度、自動化されたChrome（v88）ブラウザのインスタンスを起動しました。各セッションの正常完了後、Chromeの開発者ツールを使用して、イベントの完全なタイムラインと、証明書とその検証に関する追加情報を含むページ読み込みデータをHTTPアーカイブ形式（HAR）ファイルとして取得し、これを記録しました。さらに、ルートWebページの証明書チェーンとサブリソースリクエストによってトリガーされた新しいTLS接続を解析し、(i) ホスト名の証明書発行者の特定、(ii) Subject Alternative Name（SAN）拡張の存在の検査、(iii) DNS名が使用されたIPアドレスに解決されていることの検証、を行いました。方法と結果の詳細については、テクニカルペーパーをご覧ください。
最初のステップは、コンテンツを正常に描画するためにWebページが要求するリソースと、それらが存在する場所を把握することでした。接続の結束は、サブリソースのドメインが同じ場所でホストされている場合に可能になります。ドメインの場所は、対応する自律システム（AS）を見つけることで、おおよその位置を推定しました。たとえば、cdnjsにアタッチされたドメインは、BGPルーティングテーブルのAS 13335経由で到達可能であり、そのAS番号はCloudflareに属しているとします。下図は、Webページの割合と、Webページを完全に読み込むために必要な一意のASの数を示しています。
Webページの約14%は、完全に読み込むために2つのASを必要とします。つまり、サブリソースをもう1つのASから読み込む必要があるページです。50%以上が、必要なサブリソースをすべて取得するために最大6つのASに問い合わせが必要なページです。上記のプロットで示されているこの結果から、ORIGINフレームを使用する場合、意図した結果を実現するために必要な人員と変更は比較的少なくて済むことが推測されます。したがって、connection coalescing（接続の結束）技術を使用できる可能性は、Webページのすべてのサブリソースを取得するのに必要なユニークなASの数と同等と見積もることができます。しかし実際には、これはSLAなどの運用要因に置き換わる可能性があります、また、Cloudflareで以前取り組んでいたソケット、名前、IPアドレス間の柔軟なマッピングが有効に働く場合もあります。
私たちは次に、結束が接続メトリクスに与える影響を理解しようとしました。Webページを読み込むために必要なDNSクエリ数とTLS接続数の実測値と理想値を、それぞれのCDFでまとめると下図のようになります。
モデリングと広範な分析を通じて、ORIGINフレームによる接続の結束によって、ブラウザが行うDNSとTLS接続の数を中央値で60%以上削減できることを確認しました。このモデリングは、クライアントがDNSレコードを要求した回数を特定し、それを理想的なORIGINフレームと組み合わせることで行いました。
CDNによって運営されるような複数の配信元サーバーが存在する多くは、証明書を再利用し、同じ証明書に複数のDNS SANエントリを記載する傾向があります。これにより、運用者は、作成および更新する証明書の数を減らすことができます。理論的には、証明書に数百万以上の名前を記載することができますが、合理性に欠け、効果的に管理することはできなくなります。既存の証明書を引き続き使用することで、私たちのモデリング測定は完璧な統合を実現するために必要な変更の量を示し、以下の図に示されているように、必要な変更の規模に関する情報を提供します。
Webサイトで提供されている証明書の60%以上は修正することなく、ORIGINフレームの恩恵を受けられることを特定し、証明書に10件以下のDNS SAN名を追加することで、測定対象のWebサイトの92%以上への接続を成功させることを特定しました。CDNプロバイダーは、各証明書に最も人気のある3つまたは4つのホスト名を追加することで、最も効果的な変更を行うことができます。
実験2：ORIGINフレームの動作
私たちのモデリングへの期待を検証するため、2022年初頭、私たちはより積極的なアプローチを取りました。私たちの次の実験は、_cdnjs.Cloudflare.com_をサブリソースとして広範に使用する5,000のWebサイトに焦点を当てました。実験的なTLSエンドポイントを修正することで、RFC標準に定義されているHTTP/2 ORIGINフレームサポートを展開しました。これは、私たちがオープンソース化しているGolangの_net_と_http_依存モジュールの内部フォークを変更する必要がありました（こちらとこちらを参照してください）。
実験中、実験セット内のWebサイトに接続すると、ORIGINフレームに_cdnjs.Cloudflare.com_が返されましたが、コントロールセットでは任意の（未使用の）ホスト名が返されました。5,000のWebサイトのすべての既存のエッジ証明書も変更されました。実験グループについては、対応する証明書のSANに_cdnjs.Cloudflare.com_が追加されて更新されました。コントロールセットと実験セット間の整合性を確保するため、コントロールグループのドメイン証明書も、いずれのコントロールドメインでも使用されていない、有効で同一サイズのサードパーティドメインで更新されました。これは、証明書の相対的なサイズの変化を一定に保ち、異なる証明書サイズに起因する潜在的なバイアスを回避するために行われました。結果は驚くべきものでした！
実験でFirefoxからWebサイトに届いたリクエストの1%をサンプリングしたところ、1秒あたりの新しいTLS接続が50%以上減少していることが確認されました。これは、クライアントとサーバーの両方で実行される暗号検証操作の数が少なくなり、計算オーバーヘッドが減少したことを示しています。予想通り、CDNやサーバーのオペレータによる接続の再利用の有効性を示すコントロールセットには違いはありませんでした。
議論と洞察
私たちのモデリング測定では、ある程度のパフォーマンス向上が期待できることが示されましたが、実際には大幅な向上は見られませんでした。そのため、パフォーマンスに関しては「悪化しない」ことが適切なメンタルモデルであると言えます。リソースオブジェクトのサイズ、競合接続、輻輳制御の間の微妙な相互作用は、ネットワーク状況に左右されます。例えば、ボトルネックの共有量は、ネットワークリンクのボトルネックリソースを競合する接続が少なくなるにつれて減少します。より多くの事業者によるORIGINフレームのサーバーサポートが広まるにつれて、これらの測定を再検討してみたいと思いました。
パフォーマンスとは別に、ORIGINフレームにはプライバシーの面で大きな利点があります。結束することで、結束されていない接続では公開されていたクライアントのメタデータを隠蔽します。Webページ上の特定のリソースは、Webサイトとの対話方法に従って読み込まれます。つまり、サーバーから何らかのリソースを取得するための新しい接続が発生するたびに、SNI（Encrypted Client Helloがない場合）のようなTLSの平文のメタデータや、ポート53のUDPまたはTCPで送信される場合、少なくとも1つの平文のDNSクエリがネットワークに公開されます。接続を結束させることで、ブラウザが新しいTLS接続を開く必要がなくなり、余分なDNSクエリを実行する必要がなくなります。これにより、ネットワーク上で盗聴している人物からメタデータの漏えいを防ぐことができます。ORIGINフレームはネットワーク経路からのこれらの信号を最小化させ、ネットワーク盗聴者に経路上で漏れる平文情報の量を減らすことでプライバシーを向上させます。
ブラウザが複数の証明書を検証するために必要な暗号計算を削減する利点もありますが、主な利点は、エンドポイント（ブラウザおよび配信元サーバー）のリソースを考える際の非常に興味深い将来の可能性が開かれることです。これには、優先順位付けやHTTPアーリーヒントのような最近の提案が含まれており、クライアントによる接続過多の発生や、リソースを競合させたりすることなく、より良い体験を提供できるようになります。また、CERTIFICATEフレームのIETF draftと組み合わせることで、WebサイトのTLS証明書にSANエントリを追加することなく、接続確立後にサーバーがホスト名の権威を証明できるため、手作業による証明書の修正の必要性をさらに排除することができます。
結論と実施要請
まとめると、現在のインターネットエコシステムには、証明書とそのサーバーインフラストラクチャにわずかな変更を加えるだけで、接続を結束できる多くの機会があります。サーバーは、TLSハンドシェイクの数を約50%と大幅に削減し、描画を阻害するDNSクエリの数を60%以上削減することができます。さらに、クライアントは、ネットワークを覗き見ようとする者にさらされる平文のDNS情報を減らすことで、プライバシーの面でもメリットを享受することができます。
これを実現するために、私たちは現在HTTP/2とHTTP/3の両方のORIGINフレームのサポートを追加する予定です。また、インターネットのエコシステムを改善するために、ORIGINフレームをサポートするようサードパーティのリソースを管理する他の事業者にも働きかけています。私たちの論文投稿がACMインターネット測定会議2022に受理され、ダウンローダが可能になりました。このようなプロジェクトに携わり、新たな標準規格の重要な場面をご自身の目で確認したい方は、当社のキャリアページへアクセスしてください！