Demander l'isolation des performances avec l'en-tête Origin-Agent-Cluster

Un nouvel en-tête de réponse HTTP pour limiter les scripts au niveau du domaine et demander des ressources dédiées au navigateur.

Domenic Denicola
Domenic Denicola
X GitHub

Origin-Agent-Cluster est un nouvel en-tête de réponse HTTP qui indique au navigateur d'empêcher l'accès à des scripts synchrones entre des pages multi-origines d'un même site. Les navigateurs peuvent également utiliser Origin-Agent-Cluster pour indiquer que votre origine doit obtenir ses propres ressources distinctes, telles qu'un un processus dédié dédié.

Compatibilité du navigateur

Actuellement, l'en-tête Origin-Agent-Cluster n'est implémenté que dans Chrome 88 et versions ultérieures. Il a été conçu en étroite collaboration avec des représentants de Mozilla Firefox qui ont indiqué qu'elle présentait la valeur le prototypage, et dispose d'une préliminaire positif réception de de WebKit, le moteur de navigation utilisé par Safari.

Cependant, vous pouvez déployer l'en-tête Origin-Agent-Cluster sur toutes vos instances les utilisateurs d'aujourd'hui. Les navigateurs qui ne le comprennent pas l’ignoreront. Et, puisque les pages en Les clusters d'agents selon l'origine peuvent en fait effectuer moins de tâches que ceux liés au site (les par défaut), il n'y a aucun problème d'interopérabilité à craindre.

Pourquoi les navigateurs ne peuvent pas séparer automatiquement les origines du même site

Le Web repose sur les règles de même origine, une fonctionnalité de sécurité qui limite la façon dont les documents et les scripts peuvent interagir avec les ressources d'un autre origin. Par exemple, une page hébergée à l'adresse https://a.example se trouve à un une origine différente de celle de https://b.example ou de https://sub.a.example.

En arrière-plan, les navigateurs utilisent de différentes manières la séparation fournie par les origines. Dans l'ancien jours, même si des origines distinctes ne seraient pas en mesure d'accéder à leurs données respectives, elles partager des ressources telles que les threads du système d'exploitation, les processus et l'allocation de mémoire. Cela signifiait que si un onglet était lent, il ralentirait tous les autres onglets. Ou si un onglet utilisait trop de mémoire, entraînerait le plantage de tout le navigateur.

De nos jours, les navigateurs sont plus sophistiqués et tentent de séparer les origines en différentes processus. Le fonctionnement varie selon les navigateurs: la plupart des navigateurs présentent un certain niveau de séparation. entre les onglets, mais différents iFrames au sein d'un même onglet peuvent partager un processus. Et comme les processus s'accompagnent d'une surcharge de mémoire, ils utilisent des méthodes heuristiques pour éviter d'en générer trop: Firefox par exemple. a une limite de processus configurable par l'utilisateur, Chrome se comporte différemment selon qu'il s'agit d'un ordinateur de bureau (où la mémoire est plus abondante) et d'un appareil mobile (où il est rare).

Ces méthodes heuristiques ne sont pas parfaites. Elles sont soumises à une limitation importante : des exceptions à la règle d'origine commune qui autorisent les sous-domaines tels que https://sub.a.example et https://a.example à communiquer entre eux, les navigateurs ne peuvent pas séparer automatiquement les sous-domaines de les uns les autres.

Ce comportement par défaut est appelé "clusters d'agents selon le site", c'est-à-dire que le navigateur regroupe les pages en fonction sur leur site. Le nouvel en-tête Origin-Agent-Cluster demande au navigateur de modifier cette valeur par défaut d'une page donnée, en la plaçant dans un cluster d'agents selon l'origine, de sorte qu'elle soit regroupée qu'avec d'autres pages ayant exactement la même origine. En particulier, les pages multi-origines sur un même site sera exclu du cluster d'agents.

Cette séparation avec acceptation permet aux navigateurs d'attribuer à ces nouveaux clusters d'agents selon l'origine ressources dédiées, qui ne sont pas combinées à celles d’autres origines. Par exemple, ces pages peuvent obtenir leur propre processus ou être programmés sur des threads distincts. En ajoutant le paramètre Origin-Agent-Cluster à votre page, vous indiquez au navigateur que la page de ces ressources dédiées.

Toutefois, pour effectuer cette séparation et bénéficier de ces avantages, le navigateur doit désactiver certaines anciennes fonctionnalités.

Ce que les pages selon l'origine ne peuvent pas faire

Lorsque votre page se trouve dans un cluster d'agents selon l'origine, vous renoncez à certaines capacités de communication avec le même site multi-origines auparavant disponibles. En particulier :

  • Vous ne pouvez plus définir document.domain Il s'agit d'un qui permet normalement aux pages multi-origines d'un même site d'accéder à chacune d'elles de manière synchrone d'un autre DOM, mais il est désactivé dans les clusters d'agents selon l'origine.

  • Vous ne pouvez plus envoyer de messages WebAssembly.Module vers d'autres pages multi-origines du même site via postMessage().

  • (Chrome uniquement) Vous ne pouvez plus envoyer SharedArrayBuffer ou WebAssembly.Memory vers d'autres pages multi-origines sur le même site.

Quand utiliser des clusters d'agents selon l'origine ?

L'en-tête Origin-Agent-Cluster bénéficie le plus des origines suivantes:

  • Pour obtenir de meilleurs résultats avec leurs propres ressources dédiées, si possible. Exemples : les jeux gourmands en performances, les sites de visioconférence ou les applications de création multimédia.

  • Contient des iFrames gourmands en ressources, d'origine différente, mais sur le même site. Par exemple, si https://mail.example.com intègre https://chat.example.com iFrames, keying de l'origine https://mail.example.com/ garantit que le code écrit par l'équipe de chat ne peut pas accidentellement interfère avec le code écrit par l'équipe de messagerie et peut suggérer au navigateur de les séparer processus pour les planifier de manière indépendante et réduire leur impact sur les performances les uns sur les autres.

  • Ils s'attendent à être intégrés sur des pages d'origines différentes et situées sur le même site, mais savent qu'ils le sont et gourmandes en ressources. Par exemple, si https://customerservicewidget.example.com s'attend à utiliser de nombreuses ressources pour le chat vidéo et s'intégreront de diverses origines https://*.example.com, l'équipe qui gère ce widget pourrait utiliser Origin-Agent-Cluster. pour essayer de réduire l'impact sur les performances des intégrateurs.

De plus, vous devez vous assurer que vous pouvez désactiver les fonctionnalités rarement utilisées de communication multi-origines et que votre site utilise HTTPS.

Mais au bout du compte, ce ne sont que des lignes directrices. Déterminer si les clusters d'agents selon l'origine sont utiles pour votre site est déterminée par des mesures. En particulier, vous devez mesurer vos Web Vitals, et potentiellement votre mémoire , pour voir l'impact de la clé d'origine. (Utilisation de la mémoire dans particulier peut s'avérer préoccupante, car l'augmentation du nombre de processus en jeu peut la surcharge de mémoire par processus). Ne vous contentez pas de déployer la détection de l'origine en espérant que tout ira bien.

Quel est le lien avec l'isolation multi-origine ?

La mise en correspondance de l'origine des clusters d'agents via l'en-tête Origin-Agent-Cluster est liée à, mais elle les sépare l'isolation multi-origine via Cross-Origin-Opener-Policy et En-têtes Cross-Origin-Embedder-Policy.

Tout site isolé multi-origine désactivera également le même site multi-origine sur un même site des fonctionnalités de communication comme lors de l'utilisation de l'en-tête Origin-Agent-Cluster. Toutefois, L'en-tête Origin-Agent-Cluster peut toujours être utile en plus de l'isolation multi-origine, Conseil au navigateur pour qu'il modifie ses heuristiques d'allocation des ressources. Vous devez donc toujours considérer en appliquant l'en-tête Origin-Agent-Cluster et en mesurant les résultats, même sur les pages déjà isolé multi-origine.

Utiliser l'en-tête Origin-Agent-Cluster

Pour utiliser l'en-tête Origin-Agent-Cluster, configurez votre serveur Web afin qu'il envoie l'en-tête HTTP suivant : en-tête de réponse:

Origin-Agent-Cluster: ?1

La valeur de ?1 est la en-tête pour une valeur booléenne true .

Il est important d'envoyer cet en-tête à toutes les réponses de votre origine, et pas seulement à certaines pages. Sinon, vous risquez d'obtenir des résultats incohérents, où le navigateur "se souviendra" l'identification de l'origine demandée et donc il utilise les clés d'origine même sur les pages qui ne le demandent pas. À l'inverse, si la première page qu'un utilisateur visite n'a pas d'en-tête, le navigateur se souviendra que votre origine ne veut pas selon l'origine, et ignore l'en-tête sur les pages suivantes.

Pourquoi le navigateur ne peut-il pas toujours respecter l'en-tête ?

La raison de ce « mémoire » consiste à assurer la cohérence du chiffrement pour une origine. Si certaines pages d'un étaient liées à l'origine, contrairement à d'autres, vous pourriez avoir deux pages d'origine identiques, ont été placés dans différents clusters d'agents et n'étaient donc pas autorisés à communiquer entre eux. Ce serait très étrange, à la fois pour les développeurs Web et pour les composants internes du navigateur. Ainsi, la spécification pour Origin-Agent-Cluster ignore l'en-tête s'il n'est pas cohérent avec ce qu'il était auparavant pour une origine donnée. Dans Chrome, un avertissement s'affiche dans la console.

Cette cohérence est limitée à un groupe de contexte de navigation, c'est-à-dire un groupe d'onglets, de fenêtres ou des cadres iFrame qui peuvent tous communiquer entre eux via des mécanismes tels que window.opener, frames[0] ou window.parent Cela signifie qu'une fois que la clé d'origine ou de site d'une origine a été définie (par navigateur qui voit ou ne voit pas l'en-tête). Pour le modifier, vous devez ouvrir une nouvelle fenêtre onglet pas connecté à l’ancien.

Ces détails peuvent être importants pour tester l'en-tête Origin-Agent-Cluster. Lors de son ajout pour la première fois vers votre site, il ne suffit pas d'actualiser la page. vous devez fermer cet onglet et en ouvrir un nouveau 1.

Pour vérifier si l'en-tête Origin-Agent-Cluster est appliqué, utilisez l'API JavaScript window.originAgentCluster. Il s'agit de true si l'en-tête (ou une autre tels que l'isolation multi-origine) a entraîné la création de clé d'origine. false alors que ce n'était pas le cas ; et undefined dans les navigateurs qui n'implémentent pas l'en-tête Origin-Agent-Cluster. L'enregistrement de ces données sur votre plate-forme d'analyse permet de vérifier que vous avez configuré votre serveur correctement.

Enfin, notez que l'en-tête Origin-Agent-Cluster ne fonctionne que sur les adresses sécurisées de contexte, c'est-à-dire sur HTTPS ou sur http://localhost. Les pages HTTP autres que localhost ne sont pas compatibles avec les agents selon l'origine clusters.

La clé d'origine n'est pas une fonctionnalité de sécurité

L'utilisation d'un cluster d'agents selon l'origine isole votre origine de l'accès synchrone pages multi-origines sur le même site, il n'offre pas la protection des des en-têtes liés à la sécurité tels que Cross-Origin-Resource-Policy et Cross-Origin-Opener-Policy. En particulier, il ne s'agit pas d'une protection fiable contre les attaques par canal secondaire, comme Spectre :

Cela peut être un peu surprenant, car la traçabilité de l'origine peut parfois amener votre origine à se propre des processus distincts, et des processus distincts constituent une défense importante contre les attaques par canal auxiliaire. Mais n'oubliez pas que l'en-tête Origin-Agent-Cluster n'est qu'une indication à cet égard. Le navigateur n'est sous l'obligation de suivre un processus distinct pour votre origine. Cela peut s'expliquer par plusieurs raisons:

  • Il est possible qu'un navigateur ne mette pas en œuvre la technologie nécessaire pour le faire. (par exemple, Safari et Firefox pour le moment). peuvent placer des onglets distincts dans leurs propres processus, mais pas encore pour les iFrames.

  • Le navigateur peut décider qu'un processus distinct n'en vaut pas la peine. Par exemple, sur sur les appareils Android à faible capacité de mémoire ou dans Android WebView, Chrome utilise le moins de processus possible.

  • Le navigateur peut vouloir respecter la requête indiquée par l'en-tête Origin-Agent-Cluster, mais elle pourrait le faire en utilisant une technologie d'isolation différente de celle des processus. Par exemple, Chrome est exploration à l'aide de threads au lieu de processus pour ce type d'isolation des performances.

  • L'utilisateur, ou le code exécuté sur un autre site, a peut-être déjà accédé à une page associée au site. sur votre origine, ce qui entraîne l'activation de la garantie de cohérence et l'activation Origin-Agent-Cluster doit être complètement ignoré.

C'est pourquoi il est important de ne pas considérer les clusters d'agents selon l'origine comme une fonctionnalité de sécurité. Au contraire, c'est un moyen d'aider le navigateur à hiérarchiser l'allocation des ressources, en laissant entendre que votre bénéficierait de ressources dédiées (et que vous êtes prêt à renoncer à certaines en échange).

Commentaires

L'équipe Chrome aimerait connaître votre avis si vous utilisez ou envisagez d'utiliser Origin-Agent-Cluster en-tête. Votre intérêt général et votre assistance nous aident à hiérarchiser les fonctionnalités et à aux fournisseurs de navigateurs à quel point ils sont importants. envoyez un tweet à @ChromiumDev. faites part de vos réflexions et de votre expérience aux développeurs Chrome.

Si vous avez d'autres questions sur les spécifications ou sur le fonctionnement de la fonctionnalité, vous pouvez Signalez un problème dans le dépôt GitHub standard HTML. Et si vous rencontrez des problèmes d'implémentation avec Chrome, vous pouvez signaler un bug à l'adresse new.crbug.com avec le champ "Composants" défini sur Internals>Sandbox>SiteIsolation.

En savoir plus

Pour en savoir plus sur les clusters d'agents selon l'origine, consultez les liens suivants: