Fusion de connexions avec les extensions ORIGIN Frame : moins de requêtes DNS, moins de connexions

Cet article de blog présente et résume les informations contenues dans un document de recherche de Cloudflare, proposé à l'occasion du forum ACM Internet Measurement Conference, concernant la mesure et le prototypage de la fusion de connexions avec les extensions ORIGIN Frame.

Certains lecteurs seront peut-être surpris d'apprendre qu'une seule consultation d'une page web peut entraîner l'établissement de dizaines, voire de centaines de connexions web par un navigateur. Prenons l'exemple de cet article de blog. S'il s'agit de votre première consultation du blog de Cloudflare, ou si votre dernière visite remonte à un certain temps, votre navigateur établira une multitude de connexions afin d'afficher la page. Le navigateur effectuera des requêtes DNS afin d'identifier les adresses IP correspondant à l'adresse blog.cloudflare.com, puis il transmettra d'autres requêtes afin de récupérer toutes les sous-ressources de la page web nécessaires à l'affichage de la page complète. Combien de requêtes ? Au moment où nous écrivons ces lignes, 32 noms d'hôtes différents sont utilisés lors du chargement du blog de Cloudflare, ce qui signifie 32 requêtes DNS et au moins 32 connexions TCP (ou QUIC), sauf si le client est en mesure de réutiliser (ou fusionner) certaines de ces connexions.

Chaque nouvelle connexion web exerce une charge supplémentaire sur les capacités de traitement d'un serveur, au risque de provoquer des problèmes d'évolutivité en période d'affluence, mais également d'exposer au réseau les métadonnées de clients, telles que les noms d'hôte en clair auxquels accède un individu. Ces méta-informations peuvent potentiellement révéler les activités en ligne et les comportements de navigation d'un utilisateur à des acteurs malveillants et des espions présents sur le réseau.

Dans cet article de blog, nous allons examiner de plus près la « fusion de connexions ». Depuis notre première étude consacrée à la fusion basée sur les adresses IP en 2021, nous avons effectué d'autres mesures et modélisations de grande ampleur sur l'ensemble d'Internet, dans le but de comprendre et de prédire les situations dans lesquelles la fusion serait la plus efficace, le cas échéant. La gestion de la fusion d'adresses IP à grande échelle étant une entreprise difficile, l'année dernière, nous avons mis en œuvre et expérimenté une norme prometteuse appelée extension HTTP/2 ORIGIN Frame, que nous avons utilisée pour regrouper les connexions à la périphérie de notre réseau, sans nous préoccuper de la gestion des adresses IP.

Il s'avère, en fin de compte, que de nombreux grands fournisseurs ne saisissent pas les opportunités qui s'offrent à eux. Nous espérons que cet article de blog (ainsi que notre publication présentée lors du forum ACM IMC 2022, dans laquelle figurent des informations détaillées) constitue une première étape qui aidera les serveurs et les clients à tirer parti de la norme ORIGIN Frame.

Sommairement, lorsqu'un utilisateur parcourt le web, pour afficher les pages web, le navigateur récupère des sous-ressources dépendantes, afin de construire la page web complète. Ce processus ressemble étrangement à l'assemblage de produits physiques dans une usine, et en ce sens, une page web moderne peut être considérée comme une usine d'assemblage :elle dépend d'une « chaîne logistique » de ressources indispensables à la fabrication du produit final.

Dans le monde physique, une usine d'assemblage peut passer une commande unique contenant différentes pièces et recevoir une livraison unique depuis un fournisseur (similaire au processus de « kitting », permettant de maximiser la valeur et de minimiser les temps de réponse). Quels que soient le fabricant de ces pièces et l'endroit où elles sont produites, la démarche ne nécessite qu'une « connexion » avec le fournisseur ; ainsi, un camion transitant entre un fournisseur et une usine d'assemblage peut être rempli de pièces provenant d'une multitude de fabricants.

En raison de l'architecture du web, les navigateurs font habituellement l'inverse, dans la nature. Pour récupérer les images, le code JavaScript et les autres ressources d'une page web (les pièces), les clients web (les usines d'assemblage) doivent établir au moins une connexion à chaque nom d'hôte (les fabricants) défini dans le code HTML renvoyé par le serveur (le fournisseur). Peu importe que les connexions à ces noms d'hôte soient établies avec le même serveur ou non ; elles peuvent, par exemple, être établies avec un proxy inverse, tel que Cloudflare. Pour chaque fabricant, un « nouveau » camion sera nécessaire pour transporter les matériaux à l'usine d'assemblage depuis le même fournisseur ou, plus formellement, une nouvelle connexion devra être établie pour demander la transmission d'une sous-ressource depuis un nom d'hôte sur la même page web.

Without connection coalescing

Le nombre de connexions utilisées pour charger une page web peut être étonnamment élevé. Il est également fréquent que les sous-ressources nécessitent d'autres sous-sous-ressources, et que de nouvelles connexions soient donc établies à la suite des précédentes. N'oubliez pas non plus que les connexions HTTP aux noms d'hôtes sont souvent précédées de requêtes DNS ! La fusion de connexions permet d'utiliser moins de connexions_, c'est-à-dire de « réutiliser » la même flotte de camions pour transporter des pièces depuis plusieurs fabricants vers un fournisseur unique._

With connection coalescing 

La fusion des connexions a été introduite dans la spécification HTTP/2, puis reprise dans la spécification HTTP/3. Nous avons précédemment publié un article de blog consacré à la fusion de connexions (nous vous invitons à le consulter pour une introduction détaillée). Bien que l'idée soit simple, sa mise en œuvre peut comporter un certain nombre de défis techniques. Par exemple, souvenez-vous que 32 noms d'hôtes (au moment de la rédaction de cet article) sont impliqués dans le chargement de la page web que vous consultez actuellement. Parmi ces 32 noms d'hôtes, on dénombre 16 domaines uniques (définis comme « domaine de premier niveau+1 »). Alors, pouvons-nous créer moins de connexions ou « fusionner » des connexions existantes pour chaque domaine unique ? La réponse est « Oui, mais sous conditions ».

Le nombre exact de connexions impliquées dans le chargement de la page de l'article de blog est tout sauf évident à évaluer ; il est même difficile à déterminer. 32 noms d'hôtes peuvent être rattachés à 16 domaines ; toutefois, bien que cela soit contre-intuitif, cela ne signifie pas que la réponse à la question « Combien de connexions uniques sont établies ? » est 16. La véritable réponse pourrait être une connexion seulement, si tous les noms d'hôtes sont accessibles depuis un serveur unique, ou 32 connexions indépendantes, si un serveur différent et distinct est nécessaire pour accéder à chaque nom d'hôte individuel.

La réutilisation des connexions peut revêtir une multitude de formes ; il est donc important de définir la « fusion de connexions » dans l'espace HTTP. Par exemple, la réutilisation d'une connexion TCP ou TLS existante à un nom d'hôte dans le but de transmettre plusieurs demandes de sous-ressources depuis ce **même**nom d'hôte constitue une réutilisation de la connexion, mais pas une fusion.

La fusion se produit lorsqu'un canal TLS existant pour un nom d'hôte donné peut être réaffecté ou utilisé pour établir une connexion à un nom d'hôte différent. Par exemple, lorsque vous visitez blog.cloudflare.com, le code HTML renvoie vers des sous-ressources accessibles depuis cdnjs.cloudflare.com. Pour réutiliser la même connexion TLS pour les sous-ressources, il est nécessaire que les deux noms d'hôte apparaissent ensemble dans la liste « Server Alternative Name (SAN) » du certificat TLS ; cependant, cette étape n'est pas suffisante, à elle seule, pour convaincre les navigateurs de mettre en œuvre la fusion. Après tout, le service cdnjs.cloudflare.com peut ou non être accessible sur le même serveur que blog.cloudflare.com, même s'il figure sur le même certificat. Alors, comment le navigateur peut-il le déterminer ? La fusion fonctionne uniquement lorsque les serveurs mettent en place les conditions requises, mais il incombe aux clients de décider de l'utiliser ou non. Les navigateurs nécessitent donc un signal de fusion autre que la liste SAN figurant sur le certificat. Pour reprendre notre analogie, l'usine d'assemblage peut commander directement une pièce à un fabricant, sans toutefois savoir si le fournisseur possède déjà cette pièce dans son entrepôt.

Il existe deux signaux explicites qu'un navigateur peut utiliser pour décider si des connexions peuvent être fusionnées : l'un est basé sur l'adresse IP, l'autre sur l'extension ORIGIN Frame. Dans le premier cas, les opérateurs du serveur doivent configurer une liaison étroite entre les enregistrements DNS et les ressources HTTP disponibles sur le serveur. Cette approche s'avère difficile à gérer et à déployer, et crée en réalité une dépendance risquée, car toutes les ressources doivent être réunies dans un ensemble spécifique ou à une adresse IP unique. L'influence des adresses IP sur les décisions de fusion varie d'un navigateur à l'autre ; certains navigateurs sont assez conservateurs, tandis que d'autres sont plus permissifs. Par ailleurs, l'approche HTTP ORIGIN Frame constitue un signal plus facile à orchestrer pour les serveurs ; elle est également flexible et, en cas d'incident, offre une gestion simple, n'entraînant pas d'interruption du service (dans le cas d'une mise en œuvre conforme à la spécification).

La différence fondamentale entre ces deux signaux de coalescence est que les signaux de fusion basés sur l'adresse IP sont implicites, voire accidentels, et obligent les clients à déduire des possibilités de fusion qui peuvent exister ou non. Cela n'est guère surprenant, puisque les adresses IP sont conçues pour n'avoir aucun lien réel avec les noms ! En revanche, l'extension ORIGIN Frame est un signal explicite transmis depuis les serveurs aux clients, indiquant que la fusion est possible, quoi qu'indique le DNS pour un nom d'hôte donné.

Nous avons précédemment expérimenté la fusion de connexions basée sur les adresses IP ; aux fins de cet article de blog, nous allons examiner plus en détail la fusion basée sur les extensions ORIGIN Frame.

La norme ORIGIN Frame est une extension des spécifications HTTP/2et HTTP/3, une trame spéciale transmise sur le flux 0 ou le flux de contrôle de la connexion, respectivement. La trame permet aux serveurs d'envoyer aux clients, sur une connexion TLS _existante_préalablement établie, une instruction origin-set incluant les noms d'hôtes pour lesquels elle est autorisée, et qui n'entraînera pas d'erreurs HTTP 421. Les noms d'hôtes dans l'instruction origin-set doivent impérativement figurer également dans la liste SAN du certificat associé au serveur, même si ces noms d'hôtes sont annoncés sur des adresses IP différentes via le DNS.

Spécifiquement, deux étapes différentes sont requises :

1. Les serveurs web doivent transmettre une liste énumérant le contenu de l'instruction origin-set (c'est-à-dire les noms d'hôte pour lesquels une connexion donnée peut être utilisée) dans l'extension ORIGIN Frame.

2. Le certificat TLS renvoyé par le serveur web doit couvrir, dans les entrées SAN des noms DNS, les noms d'hôte supplémentaires renvoyés dans l'extension ORIGIN Frame.

Sommairement, les extensions ORIGIN Frame complètent le certificat TLS que les opérateurs peuvent joindre, comme pour dire « Pssst ! Hé, le client, voici les noms disponibles pour cette connexion sur les listes SAN ; tu peux fusionner les connexions ! ». Dans la mesure où l'extension ORIGIN Frame ne fait pas partie du certificat lui-même, son contenu peut être modifié indépendamment. Aucun nouveau certificat n'est requis,et il n'existe aucune dépendance vis-à-vis des adresses IP. Pour un nom d'hôte fusionnable, les connexions TCP/QUIC+TLS existantes peuvent être réutilisées sans nécessiter de nouvelles connexions ou requêtes DNS.

De nombreux sites web dépendent aujourd'hui de contenus servis depuis des réseaux CDN, tels que le service CDN de Cloudflare. L'utilisation de services CDN externes offre aux sites web les avantages de la vitesse et de la fiabilité, et réduit également la charge que représente le contenu servi par leurs serveurs d'origine. Servir le site web et les ressources depuis le même réseau CDN (même s'il s'agit de noms d'hôtes différents, appartenant à des entités différentes) offre des opportunités très intéressantes aux opérateurs de réseaux CDN : ils peuvent permettre la réutilisation et la fusion de connexions, puisqu'ils peuvent contrôler à la fois la gestion des certificats et les requêtes de connexion pour l'envoi d'extensions ORIGIN Frame pour le compte du serveur d'origine réel.

Malheureusement, aucune approche permettant de mettre en pratique les possibilités offertes par la norme ORIGIN Frame n'a été mise au point. À notre connaissance, jusqu'à aujourd'hui, il n'existe aucun déploiement de serveur prenant en charge les extensions ORIGIN Frame,et seul le navigateur Firefox offre la prise en charge des extensions ORIGIN Frames. Puisque la fusion basée sur les adresses IP constitue un défi et que l'extension ORIGIN Frame ne bénéficie actuellement d'aucune prise en charge, est-il intéressant d'investir du temps et de l'énergie dans le développement d'une meilleure prise en charge de la fusion de connexions ? Nous avons décidé de le découvrir en effectuant des mesures à grande échelle sur l'ensemble d'Internet, afin de comprendre les opportunités et de prévoir les possibilités, puis nous avons mis en œuvre la norme ORIGIN Frame afin de l'expérimenter sur du trafic de production.

En février 2021, nous avons collecté des données concernant 500 000 sites web parmi les plus populaires d'Interneten exécutant une session Web Page Test modifiée sur 100 machines virtuelles. Une instance automatisée du navigateur Chrome (v. 88) a été lancée pour chaque consultation d'une page web, afin d'éliminer les effets de la mise en cache (car nous voulions comprendre la fusion, et non la mise en cache). À la fin de chaque session, nous avons utilisé les outils de développement de Chrome pour récupérer et écrire les données de chargement de la page sous la forme d'un fichier au format HTTP Archive (HAR), avec une chronologie complète des événements, ainsi que des informations supplémentaires sur les certificats et leur validation. En outre, nous avons analysé les chaînes de certificats correspondant à la page web racine et aux nouvelles connexions TLS établies suite aux demandes de sous-ressources, afin (i) d'identifier les émetteurs de certificats pour les noms d'hôtes, (ii) d'inspecter la présence de l'extension Subject Alternative Name (SAN) et (iii) de valider la résolution des noms DNS à l'adresse IP utilisée. Des informations plus détaillées sur notre méthodologie et nos résultats sont disponibles dans le document technique.

La première étape consistait à comprendre quelles ressources étaient demandées par les pages web, afin d'assurer le rendu du contenu de la page, ainsi que les endroits auxquels ces ressources étaient présentes sur Internet. La fusion des connexions est possible lorsque la colocalisation des domaines de sous-ressources est idéale. Nous avons déterminé approximativement l'emplacement d'un domaine en identifiant le système autonome (AS, « Autonomous System ») correspondant. Par exemple, le domaine rattaché à cdnjs est accessible via le système AS 13335 dans la table de routage BGP, et ce numéro de système AS appartient à Cloudflare. La figure ci-dessous décrit le pourcentage de pages web ainsi que le nombre de systèmes AS uniques nécessaires au chargement d'une page web complète.

Dans environ 14 % des cas, le chargement complet des pages web nécessite deux systèmes AS, ce qui signifie qu'elles dépendent d'un système AS supplémentaire pour les sous-ressources. Dans plus de 50 % des cas, les pages web n'ont pas besoin de contacter plus de six systèmes AS pour obtenir toutes les sous-ressources nécessaires. Cette conclusion, représentée sur le graphique ci-dessus, implique qu'un nombre relativement restreint d'opérateurs fournit les contenus correspondant aux sous-ressources nécessaires à la majorité (environ 50 %) des sites web, et que l'utilisation éventuelle d'extensions ORIGIN Frame ne nécessiterait que quelques modifications pour produire l'effet escompté. De manière optimiste, on peut donc estimer que le potentiel de fusion de connexions est égal au nombre de systèmes AS uniques nécessaires à l'obtention de toutes les sous-ressources d'une page web. Dans la pratique, toutefois, cette estimation peut être supplantée par des facteurs opérationnels tels que les accords de niveau de service (SLA) ou être facilitée par des mappages flexibles entre les sockets, les noms et les adresses IP, sur lesquels Cloudflare a précédemment travaillé.

Nous avons ensuite essayé de comprendre l'impact de la fusion sur les indicateurs de connexion. Les nombres mesuré et idéal de requêtes DNS et de connexions TLS nécessaires au chargement d'une page web sont récapitulés en fonction de leurs distributions cumulées sur la figure ci-dessous.

Grâce à la modélisation et à une analyse approfondie, nous avons déterminé que la fusion de connexions mise en œuvre par le biais d'extensions ORIGIN Frame permettrait de réduire d'une valeur médiane de plus de 60 % le nombre de requêtes DNS et de connexions TLS effectuées par les navigateurs.Nous avons effectué cette modélisation en identifiant le nombre de demandes d'enregistrements DNS provenant des clients, puis en associant ces demandes à l'extension ORIGIN Frame devant idéalement être servie.

De nombreux serveurs multi-origines, tels que ceux utilisés par les réseaux CDN, ont tendance à réutiliser les certificats et à servir un même certificat avec plusieurs entrées SAN DNS. Cette approche permet aux opérateurs de gérer un nombre moins élevé de certificats pendant les cycles de création et de renouvellement de ces derniers. Bien qu'il soit théoriquement possible d'ajouter des millions de noms à un certificat, la création de ce type de certificat ne constitue pas une approche raisonnable, et sa gestion efficace serait problématique. En continuant à se fier à des certificats existants, nos mesures de modélisation mettent en lumière le volume de changements nécessaires pour permettre une fusion de connexions parfaite, tout en fournissant des informations sur l'ampleur de ces changements, comme le démontre la figure ci-dessous.

Nous identifions que plus de 60 % des certificats servis par les sites web ne nécessitent aucune modification et pourraient tirer profit des extensions ORIGIN Frame, et qu'en ajoutant au maximum 10 noms DNS SAN aux certificats, nous pouvons assurer la fusion de connexions pour plus de 92 % des sites web inclus dans nos mesures. Les modifications les plus efficaces pourraient être mises en œuvre par les fournisseurs de réseaux CDN en ajoutant à chaque certificat trois ou quatre de leurs noms d'hôtes les plus demandés.

Afin de valider nos attentes concernant la modélisation, nous avons ensuite adopté une approche plus active, au début de 2022. Notre expérience suivante s'est concentrée sur 5 000 sites web qui utilisent fréquemment cdnjs.cloudflare.com en tant que sous-ressource. En modifiant notre point de terminaison TLS expérimental, nous avons déployé la prise en charge de la spécification HTTP/2 ORIGIN Frame, telle que définie dans la norme RFC. Cette approche a nécessité la modification de la fourche interne des modules de dépendances net et http de Golang, que nous avons publiés en open source (voir ici et ici).

Pendant les expériences, la connexion à un site web inclus dans l'ensemble expérimental renvoyait cdnjs.cloudflare.com dans l'extension ORIGIN Frame, tandis que l'ensemble de contrôle renvoyait un nom d'hôte arbitraire (inutilisé). Tous les certificats périphériques existants pour les 5 000 sites web ont également été modifiés. Pour l'ensemble expérimental, les certificats correspondants ont été renouvelés, et l'adresse cdnjs.cloudflare.com a été ajoutée au certificat SAN. Pour garantir l'intégrité entre les ensembles expérimental et de contrôle, les certificats de domaines du groupe de contrôle ont également été renouvelés avec un domaine tiers valide, de taille identique, qui n'était utilisé par aucun des domaines de contrôle. Cette approche permettait de préserver la constance des modifications de la taille relative des certificats et d'éviter d'éventuels biais liés aux différences de taille des certificats. Les résultats que nous avons obtenus ont été remarquables !

En échantillonnant 1 % des requêtes reçues depuis Firefox vers les sites web inclus dans l'expérience, nous avons constaté une réduction de plus de 50 % du nombre de nouvelles connexions TLS par seconde, indiquant une diminution du nombre d'opérations de vérification cryptographique effectuées par le client, ainsi qu'une réduction de la surcharge de données de traitement au niveau du serveur. Comme prévu, aucune différence n'était observable au niveau de l'ensemble de contrôle, confirmant l'efficacité de la réutilisation de connexions telle qu'elle est perçue par les opérateurs de réseaux CDN ou de serveurs.

Si nos mesures de modélisation indiquent que nous pouvions anticiper une amélioration des performances, dans la pratique, ces dernières n'ont pas été considérablement meilleures, suggérant que le modèle mental « pas pire » constitue la meilleure approche en termes de performances. L'interaction subtile entre la taille des objets des ressources, le nombre de connexions concurrentes et le contrôle de l'encombrement dépend des conditions actuelles du réseau. La capacité de partage des goulets d'étranglement, par exemple, diminue à mesure que des connexions moins nombreuses se disputent les ressources affectées par les goulets d'étranglement sur les liaisons du réseau. Il serait intéressant de réexaminer ces mesures lorsqu'un nombre croissant d'opérateurs auront déployé la prise en charge de la norme ORIGIN Frame sur leurs serveurs.

Outre les performances, l'un des principaux avantages de la spécification ORIGIN Frame est la protection de la confidentialité. Comment cela ? Chaque connexion fusionnée dissimule les métadonnées du client qui, autrement, seraient divulguées par des connexions non fusionnées. Certaines ressources d'une page web sont chargées en fonction des interactions de l'utilisateur avec le site web. Cela signifie que pour chaque nouvelle connexion visant à obtenir une ressource sur le serveur, les métadonnées TLS transmises en clair, telles que le SNI (en l'absence d'extension Encrypted Client Hello) et au moins une requête DNS transmise en clair (si celle-ci est transmise via UDP ou TCP sur le port 53) sont exposées au réseau. La fusion de connexions permet d'éviter la nécessité, pour les navigateurs, d'ouvrir de nouvelles connexions TLS, mais également d'effectuer des requêtes DNS supplémentaires. Elle permet ainsi d'éviter les fuites de métadonnées causées par d'éventuels utilisateurs espionnant le réseau. La norme ORIGIN Frame aide à minimiser ces signaux sur le chemin réseau, et améliore ainsi la confidentialité en réduisant la quantité d'informations transmises en clair divulguées aux espions présents sur le réseau.

La réduction des calculs cryptographiques nécessaires à la vérification d'une multitude de certificats profite aux navigateurs, mais un avantage majeur de cette spécification découle du fait qu'elle offre des possibilités futures très intéressantes au regard de la planification des ressources au niveau des points de terminaison (c'est-à-dire des navigateurs et des serveurs d'origine) ; il s'agit notamment de la gestion des priorités ou encore de la prise en charge de propositions récentes telles que les indications HTTP Early Hints, qui permettent de proposer aux clients des expériences dans lesquelles les connexions ne sont pas surchargées ou en concurrence pour accéder à ces ressources. Associée au projet CERTIFICATE Frames d'IETF, cette spécification permettrait par ailleurs d'éliminer la nécessité de modifier manuellement les certificats, car un serveur pourrait prouver son autorité sur les noms d'hôtes après l'établissement de la connexion sans qu'il soit nécessaire d'ajouter des entrées SAN supplémentaires au certificat TLS du site web.

En résumé, l'écosystème actuel d'Internet offre de nombreuses opportunités de fusion de connexions, ne nécessitant qu'un nombre limité de modifications des certificats et des infrastructures de serveur. Les serveurs peuvent réduire considérablement (d'environ 50 %) le nombre de négociations TLS, tout en réduisant de plus de 60 % le nombre de requêtes DNS bloquant le rendu de pages. Ces avantages en matière de confidentialité sont également bénéfiques pour les clients, grâce à la réduction de l'exposition des informations DNS en clair aux observateurs présents sur le réseau.

Pour que ces avantages deviennent une réalité, nous prévoyons actuellement d'ajouter la prise en charge des extensions ORIGIN Frame HTTP/2 et HTTP/3 pour nos clients. Nous encourageons également les autres opérateurs gérant des ressources tierces à adopter la prise en charge de la spécification ORIGIN Frame, afin d'améliorer l'écosystème d'Internet.

Notre publication a été acceptée lors du forum ACM Internet Measurement Conference 2022 et est disponible en téléchargement. Si vous souhaitez contribuer à des projets comme celui-ci, qui vous permettront d'assister à l'évaluation concrète de nouvelles normes, consultez notre page d'offres d'emploi !