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

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

Domenic Denicola

Origin-Agent-Cluster: 新しい HTTP レスポンス ヘッダーで、ブラウザに対して 同一サイトのクロスオリジン ページ間で同期スクリプト アクセスを行うことがあります。ブラウザによっては Origin-Agent-Cluster: オリジンが独自の個別のリソース（ 専用のプロセスを使用します。

ブラウザの互換性

現在、Origin-Agent-Cluster ヘッダーは Chrome 88 以降でのみ実装されています。この設計は、 価値のある Mozilla Firefox の担当者と緊密に連携 プロトタイピングであり、 予備選挙 受信 Safari で使用されているブラウザ エンジン、WebKit の代表者です。

当面は、Origin-Agent-Cluster ヘッダーをすべてのインスタンスにデプロイしても問題ありません。 現在のユーザー数ですブラウザを理解できないと、ブラウザは無視されます。また、 オリジンキー エージェント クラスタが実行できる処理は、サイトキー エージェント クラスタよりも少ない 相互運用性の問題は生じません。

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

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

ブラウザはバックグラウンドで、さまざまな方法でオリジンの分離を使用しています。従来の 異なるオリジンが互いのデータにアクセスできなくても、 オペレーティング システムのスレッド、プロセス、メモリ割り当てなどのリソースを共有する。つまり 他のタブも動作が遅くなっていました。1 つのタブでメモリ使用量が多すぎると ブラウザ全体がクラッシュします

最近のブラウザはより洗練されているため、異なるオリジンをそれぞれ別のオリジンに分けようとしている プロセスです。この仕組みはブラウザごとに異なり、ほとんどのブラウザはある程度分割されています。 ただし、1 つのタブ内の異なる iframe でプロセスが共有される場合があります。しかも メモリのオーバーヘッドが伴うため、ヒューリスティックを使用して過剰な生成を回避します（例: Firefox ユーザーが構成可能なプロセス上限がある。 Chrome の動作は、メモリが多いパソコンの場合とモバイルの場合（メモリが多い場合）で異なります。 希少なもの）。

こうしたヒューリスティックは完璧ではありません。そして、大きな制約にも悩まされています。それはなぜなら、 同一オリジン ポリシーの例外（https://sub.a.example や https://a.example で相互に通信するため、ブラウザはサブドメインを自動的に 相互に通信します。

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

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

ただし、分離を実行してこれらのメリットを得るには、ブラウザで いくつかあります。

オリジンキー ページでできないこと

ページがオリジンキー エージェント クラスタ内にある場合、同じサイトと通信する機能が一部放棄される クロスオリジン ページを利用できます。具体的には、次のとおりです。

• 設定できなくなりました document.domain。これは 従来の機能によって、同一サイトのクロスオリジン ページから各ページに同期して オリジンキー エージェント クラスタでは無効になります。

• 送信できなくなりました WebAssembly.Module 他の同一サイトのクロスオリジン ページに postMessage() でオブジェクトを追加する。

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

オリジンキー エージェント クラスタを使用する場合

Origin-Agent-Cluster ヘッダーによるメリットが最も大きいオリジンは次のとおりです。

• 可能であれば、独自の専用リソースで最高のパフォーマンスを発揮します。以下に例を示します。 高パフォーマンスのゲーム、ビデオ会議サイト、マルチメディア作成アプリなどに使用されています。

• オリジンが異なるが、同じサイトのリソースを大量に消費する iframe が含まれます。たとえば https://mail.example.com が https://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 の値は、構造化された header ブール値の構文 true あります。

このヘッダーは、一部のページだけでなく、配信元からのすべてのレスポンスで送信することが重要です。 そうしないと、一貫性のない結果になってしまい、ブラウザが「記憶」オリジンキーの オリジンキーが要求されていないページでもオリジンキーが 取得されます逆に、検索結果の最初のページが ヘッダーがない場合、ブラウザはオリジンがリクエストを に指定され、後続のページのヘッダーは無視されます。

Origin-Agent-Cluster ヘッダーが適用されているかどうかを確認するには、JavaScript を使用します。 window.originAgentCluster プロパティ。trueヘッダー（または クロスオリジン分離などのメカニズムにより、オリジンキーが発生しました。false できなかったとき。Origin-Agent-Cluster ヘッダーを実装していないブラウザでは undefined が返されます。 このデータを分析プラットフォームに記録することで、構成済みの重要なチェックを行うことができます。 確認します。

なお、Origin-Agent-Cluster ヘッダーは安全な HTTPS 上で転送されます。 ページまたはhttp://localhostで表示されます。localhost 以外の HTTP ページはオリジンキー エージェントをサポートしません 説明します。

オリジンキーはセキュリティ機能ではない

オリジンキー エージェント クラスタを使用すると、オリジンが同期アクセスから 同一サイトのクロスオリジン ページでは、サイトの保護は などのセキュリティ関連のヘッダー Cross-Origin-Resource-Policy および Cross-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 チームまでご連絡ください。 できます。公共の利益やご支援は、機能の優先順位付けや、 重要度が高くなります@ChromiumDev でツイートしてください。 Chrome DevRel に感想や経験をお寄せください。

仕様や機能の詳細についてご不明な点がある場合は、 HTML 標準 GitHub リポジトリで問題を報告してください。もし Chrome の実装で問題が発生した場合は、 new.crbug.com [Components] フィールドを Internals>Sandbox>SiteIsolation に設定しました。

その他の情報

オリジンキー エージェント クラスタの詳細については、次のリンクをご覧ください。

• デモとデモ 出典
• 説明
• の仕様
• バグの追跡: Chrome、 Firefox、 Safari