Origin-Agent-Cluster ヘッダーを使用したパフォーマンス分離のリクエスト

ドメイン全体のスクリプトを制限し、ブラウザから専用リソースをリクエストする新しい HTTP レスポンス ヘッダー。

Domenic Denicola
Domenic Denicola

Origin-Agent-Cluster は、同一サイトのクロスオリジン ページ間の同期スクリプト アクセスを防ぐようブラウザに指示する新しい HTTP レスポンス ヘッダーです。ブラウザは、オリジンが専用のプロセスなど、独自の個別のリソースを取得する必要があるというヒントとして Origin-Agent-Cluster を使用することもあります。

ブラウザの互換性

現在、Origin-Agent-Cluster ヘッダーは Chrome 88 以降でのみ実装されています。このプロトタイプは、Mozilla Firefox の担当者と緊密に連携して設計されました。Mozilla Firefox の担当者は、このプロトタイプをプロトタイピングに値すると評価しています。また、Safari で使用されているブラウザ エンジンである WebKit の担当者からは前向きな評価を受けています。

ただし、現時点では、すべてのユーザーに Origin-Agent-Cluster ヘッダーをデプロイしても問題ありません。これを理解していないブラウザでは無視されます。また、オリジンキー エージェント クラスタ内のページは、サイトキー(デフォルト)のページよりも実際にできることが少ないため、相互運用性の問題を心配する必要はありません。

ブラウザが同一サイトのオリジンを自動的に分離できない理由

ウェブは同一生成元ポリシーに基づいて構築されています。これは、ドキュメントとスクリプトが別のオリジンのリソースとやり取りする方法を制限するセキュリティ機能です。たとえば、https://a.example でホストされているページは、https://b.example または https://sub.a.example のページとは異なるオリジンにあります。

ブラウザは、オリジンが提供する分離をさまざまな方法で使用します。以前は、個別のオリジンが互いのデータにアクセスできない場合でも、オペレーティング システムのスレッド、プロセス、メモリ割り当てなどのリソースを共有していました。つまり、1 つのタブが遅いと、他のすべてのタブも遅くなります。1 つのタブでメモリ使用量が多すぎると、ブラウザ全体がクラッシュする可能性があります。

最近のブラウザはより高度になり、異なるオリジンを異なるプロセスに分離しようとしています。具体的な仕組みはブラウザによって異なります。ほとんどのブラウザではタブは一定のレベルで分離されていますが、1 つのタブ内の iframe はプロセスを共有する場合があります。また、プロセスにはメモリ オーバーヘッドがあるため、ヒューリスティクスを使用して、プロセスの過剰な生成を回避します。たとえば、Firefox にはユーザーが構成可能なプロセスの上限があり、Chrome は、デスクトップ(メモリが豊富)とモバイル(メモリが少ない)で動作が異なります。

これらのヒューリスティクスは完璧ではありません。また、重要な制限があります。https://sub.a.examplehttps://a.example などのサブドメインが相互に通信できるようにする例外が同じオリジン ポリシーに存在するため、ブラウザはサブドメインを自動的に分離できません。

このデフォルトの動作は「サイトキー エージェント クラスタ」と呼ばれます。つまり、ブラウザはサイトに基づいてページをグループ化します。新しい Origin-Agent-Cluster ヘッダーは、特定のページに対してこのデフォルトの動作を変更し、オリジンキー エージェント クラスタに配置するようブラウザに指示します。これにより、同じオリジンを持つ他のページとのみグループ化されます。特に、同一サイトのクロスオリジン ページはエージェント クラスタから除外されます。

このオプトインによる分離により、ブラウザはこれらの新しいオリジンキー エージェント クラスタに独自の専用リソースを割り当てることができます。このリソースは、他のオリジンのリソースと結合されません。たとえば、このようなページは独自のプロセスを取得したり、別々のスレッドでスケジュールされたりする場合があります。Origin-Agent-Cluster ヘッダーをページに追加すると、ページがそのような専用リソースの恩恵を受けることをブラウザに示します。

ただし、分離を実行してこれらのメリットを得るには、ブラウザで一部のレガシー機能を無効にする必要があります。

オリジンキーを使用するページでできないこと

ページがオリジンキーによるエージェント クラスタ内にある場合、以前は利用可能だった、同じサイトのクロスオリジン ページとの通信機能の一部が失われます。具体的には、次のとおりです。

  • document.domain を設定できなくなりました。これは従来の機能で、通常は同一サイトのクロスオリジン ページが互いの DOM に同期的にアクセスできるようにしますが、オリジンキー エージェント クラスタでは無効になります。

  • postMessage() を介して、同じサイトのクロスオリジン ページに WebAssembly.Module オブジェクトを送信できなくなります。

  • (Chrome のみ)SharedArrayBuffer オブジェクトまたは WebAssembly.Memory オブジェクトを、同一サイトのクロスオリジンの他のページに送信できなくなりました。

オリジンキー エージェント クラスタを使用するタイミング

Origin-Agent-Cluster ヘッダーから最もメリットを得られるオリジンは、次の条件を満たすものです。

  • 可能であれば、専用のリソースを使用するとパフォーマンスが向上します。たとえば、パフォーマンスを重視したゲーム、ビデオ会議サイト、マルチメディア作成アプリなどです。

  • オリジンが異なるが同じサイトにある、リソースを大量に消費する iframe が含まれている。たとえば、https://mail.example.comhttps://chat.example.com iframe を埋め込む場合、オリジン キーイング https://mail.example.com/ により、チャット チームが作成したコードがメール チームが作成したコードと誤って干渉することがなくなります。また、ブラウザに別々のプロセスを割り当て、個別にスケジュールを設定することで、相互のパフォーマンスへの影響を軽減できます。

  • 異なるオリジンの同じサイトのページに埋め込まれることを想定していますが、リソースを大量に消費します。たとえば、https://customerservicewidget.example.com がビデオチャットに多くのリソースを使用すると想定され、https://*.example.com 全体のさまざまな送信元に埋め込まれる場合、そのウィジェットを管理するチームは Origin-Agent-Cluster ヘッダーを使用して、埋め込み元のパフォーマンスへの影響を軽減できます。

また、前述のあまり使用されていないクロスオリジン通信機能を無効にしても問題ないこと、サイトが HTTPS を使用していることも確認する必要があります。

ただし、これらはあくまでガイドラインにすぎません。オリジンキー エージェント クラスタがサイトに役立つかどうかは、最終的には測定によって判断するのが最善です。特に、ウェブ バイタルズメモリ使用量を測定して、オリジン キー設定の影響を確認することをおすすめします。(特にメモリ使用量は懸念事項です。実行中のプロセス数が増えると、プロセスあたりのメモリ オーバーヘッドが増加する可能性があります)。オリジン キーを導入するだけでは、期待どおりの結果は得られません。

これはクロスオリジン分離とどのように関係していますか?

Origin-Agent-Cluster ヘッダーによるエージェント クラスタのオリジンキーは、Cross-Origin-Opener-Policy ヘッダーと Cross-Origin-Embedder-Policy ヘッダーによるクロスオリジン分離に関連していますが、分離は異なります。

クロスオリジンを分離するサイトでは、Origin-Agent-Cluster ヘッダーを使用する場合と同じ同一サイトのクロスオリジン通信機能も無効になります。ただし、Origin-Agent-Cluster ヘッダーは、リソース割り当てヒューリスティックを変更するためのブラウザへの追加ヒントとして、クロスオリジン分離に加えて引き続き有用です。そのため、すでにクロスオリジン分離されているページでも、Origin-Agent-Cluster ヘッダーの適用と結果の測定を検討する必要があります。

Origin-Agent-Cluster ヘッダーの使用方法

Origin-Agent-Cluster ヘッダーを使用するには、次の HTTP レスポンス ヘッダーを送信するようにウェブサーバーを構成します。

Origin-Agent-Cluster: ?1

?1 の値は、ブール値 true構造化ヘッダー構文です。

一部のページだけでなく、送信元からのすべてのレスポンスでこのヘッダーを送信することが重要です。そうしないと、ブラウザがオリジンキー設定リクエストを「記憶」し、リクエストしていないページでもオリジンキー設定が行われるといった、一貫性のない結果になる可能性があります。またはその逆の場合: ユーザーが最初にアクセスしたページにヘッダーがない場合、ブラウザはオリジンがオリジンキーを希望していないことを記憶し、以降のページのヘッダーを無視します。

ブラウザがヘッダーを常に尊重できないのはなぜですか?

この「メモリ」は、オリジンのキー設定の整合性を確保するために使用されます。オリジンの一部がオリジンキー付きで、一部がオリジンキーなしの場合、同じオリジンの 2 つのページが異なるエージェント クラスタに配置され、相互に通信できなくなる可能性があります。これは、ウェブ デベロッパーとブラウザの内部にとって非常に奇妙なことになります。そのため、Origin-Agent-Cluster の仕様では、特定の送信元で以前に確認されたものと一致しないヘッダーは無視されます。Chrome では、コンソールに警告が表示されます。

この整合性は、ブラウジング コンテキスト グループに限定されます。ブラウジング コンテキスト グループとは、window.openerframes[0]window.parent などのメカニズムを通じて相互にアクセスできるタブ、ウィンドウ、iframe のグループです。つまり、送信元の送信元キーまたはサイトキーが確定すると(ブラウザがヘッダーを検出するか、検出しないかによって)、それを変更するには、まったく新しいタブを開く必要があります。古いタブとは一切接続されません。

これらの詳細は、Origin-Agent-Cluster ヘッダーのテストに重要です。サイトに初めて追加する場合、ページを再読み込みしても機能しません。タブを閉じて新しいタブを開く必要があります。

Origin-Agent-Cluster ヘッダーが適用されているかどうかを確認するには、JavaScript の window.originAgentCluster プロパティを使用します。これは、ヘッダー(またはクロスオリジン分離などの他のメカニズム)がオリジン キーイングを引き起こした場合は true、引き起こさなかった場合は falseOrigin-Agent-Cluster ヘッダーを実装していないブラウザでは undefined になります。このデータを分析プラットフォームにロギングすると、サーバーが正しく設定されていることを確認できます。

最後に、Origin-Agent-Cluster ヘッダーは安全なコンテキスト(HTTPS ページまたは http://localhost)でのみ機能することに注意してください。ローカルホスト以外の HTTP ページは、オリジンキーによるエージェント クラスタをサポートしていません。

オリジン キーはセキュリティ機能ではありません

オリジンキー エージェント クラスタを使用すると、同じサイトのクロスオリジン ページからの同期アクセスからオリジンを分離できますが、Cross-Origin-Resource-PolicyCross-Origin-Opener-Policy などのセキュリティ関連ヘッダーの保護は提供されません。特に、Spectre などのサイドチャネル攻撃に対する信頼できる保護ではありません。

これは少し意外に思えるかもしれません。オリジン キーングによってオリジンが独自のプロセスを取得することがあるためです。個別のプロセスは、サイドチャネル攻撃に対する重要な防御手段です。ただし、Origin-Agent-Cluster ヘッダーはヒントでしかありません。ブラウザは、オリジンに個別のプロセスを割り当てる義務はなく、さまざまな理由で割り当てられない場合があります。

  • ブラウザに、そのための技術が実装されていない場合があります。たとえば、現在 Safari と Firefox では、個別のタブを独自のプロセスに配置できますが、iframe についてはまだできません。

  • ブラウザは、別のプロセスのオーバーヘッドに見合う価値がないと考えるかもしれません。たとえば、メモリ不足の Android デバイスや Android WebView では、Chrome は可能な限り少ないプロセスを使用します。

  • ブラウザは Origin-Agent-Cluster ヘッダーで指定されたリクエストを尊重できますが、プロセスとは異なる分離技術を使用して行うことができます。たとえば、Chrome では、このようなパフォーマンス分離にプロセスではなくスレッドを使用することを検討しています。

  • ユーザーまたは別のサイトで実行されているコードが、オリジンのサイトキー付きページにすでに移動している場合、一貫性保証が適用され、Origin-Agent-Cluster ヘッダーが完全に無視される可能性があります。

そのため、オリジンキーによるエージェント クラスタはセキュリティ機能と見なさないことが重要です。代わりに、生成元が専用リソースの恩恵を受けることをヒントとして伝えることで、ブラウザがリソースの割り当てに優先順位を付けるのを支援する方法です(その代わりに特定の機能を放棄することを承諾します)。

フィードバック

Origin-Agent-Cluster ヘッダーを使用している場合や、使用を検討している場合は、Chrome チームまでご意見をお寄せください。皆様の関心とご支援は、Google が機能の優先順位を決め、他のブラウザ ベンダーにその重要性を示すうえで役立ちます。@ChromiumDev にツイートして、Chrome DevRel にご意見やご感想をお知らせください。

仕様や機能の仕組みについてご不明な点がある場合は、HTML Standard GitHub リポジトリで問題を報告してください。Chrome の実装で問題が発生した場合は、new.crbug.com でバグを報告してください。コンポーネント フィールドを Internals>Sandbox>SiteIsolation に設定してください。

その他の情報

送信元キーによるエージェント クラスタについて詳しくは、次のリンクをご覧ください。