Que sont les domaines CDN multiples ?

L’utilisation de plusieurs domaines CDN répartit les URL des ressources entre des noms d’hôte distincts à des fins de séparation, de migration, de marque ou de routage. Chaque nom d’hôte peut utiliser des certificats, des politiques de cache ou des origines différents.

La répartition des ressources entre plusieurs noms d’hôte est née d’une technique d’optimisation des performances appelée répartition entre domaines. Les navigateurs limitent le nombre de connexions simultanées par domaine ; diffuser les ressources depuis plusieurs sous-domaines permettait donc à une page de télécharger davantage de fichiers en parallèle. HTTP/2 et HTTP/3 transportent de nombreuses requêtes sur une seule connexion, ce qui supprime cette justification. MDN décrit désormais l’utilisation de plusieurs domaines comme une mauvaise pratique pour les performances, car chacun peut ajouter une résolution DNS et un établissement de connexion. Restent les usages sans rapport avec les téléchargements parallèles : un nom d’hôte par client, par périmètre de sécurité, par catégorie de médias ou par CDN lors d’une migration. Pour un navigateur, chaque nom d’hôte constitue une origine distincte, et sur le CDN, chacun nécessite son propre enregistrement DNS, une couverture par certificat et un routage, même lorsqu’ils aboutissent tous au même CDN et au même serveur d’origine.

Des noms d’hôte supplémentaires accélèrent-ils encore le chargement des pages ? Pas en règle générale avec HTTP/2 ou HTTP/3. La répartition entre domaines contournait la limite de connexions par domaine du navigateur ; MDN la qualifie d’obsolète dès qu’HTTP/2 est activé, car chaque nom d’hôte supplémentaire peut entraîner une résolution DNS et une nouvelle connexion. Un navigateur ne peut réutiliser une connexion existante pour un second nom d’hôte que si le serveur fait autorité pour celui-ci. Avec HTTP/2, la RFC 9113 conditionne cette réutilisation à la résolution du nom d’hôte vers la même adresse IP et, pour les ressources https, exige en plus un certificat valide pour ce nom d’hôte ; la RFC 9110 ajoute qu’un serveur peut lever la vérification DNS en envoyant une trame ORIGIN. Avec HTTP/3, le client doit valider le certificat du serveur pour le nouveau nom d’hôte. Un serveur peut refuser la réutilisation avec une réponse 421 (Misdirected Request).
Un navigateur considère-t-il un second nom d’hôte qui m’appartient comme la même origine ? Non. Une origine combine un schéma, un hôte et un port, et la RFC 9110 précise que deux origines sont distinctes dès que l’un de ces trois éléments diffère, même si la même entité contrôle les deux. Une page sur www.example.com qui appelle fetch() sur media.example.com, ou qui y charge une police web, a besoin d’en-têtes CORS provenant du nom d’hôte des médias. Une image simplement affichée se charge sans autorisation CORS, mais la dessiner dans un canvas contamine celui-ci, et la lecture de son contenu lève alors une exception SecurityError.
Les cookies atteindront-ils un nom d’hôte distinct pour les médias ? Uniquement si leur portée le couvre, et cette portée ne garantit pas à elle seule leur envoi. Un cookie défini avec Domain=example.com peut être envoyé à example.com et à ses sous-domaines, tels que media.example.com. Un cookie défini sans attribut Domain n’est renvoyé qu’à l’hôte qui l’a défini. Aucun cookie dont la portée est limitée à example.com n’est envoyé à un nom d’hôte relevant d’un autre domaine. Même dans cette portée, la requête doit inclure des informations d’identification : une requête interorigines fetch() n’envoie aucun cookie à moins que son option credentials ne soit définie sur include, et MDN précise que les politiques relatives aux cookies tiers peuvent empêcher leur envoi même dans ce cas. Vérifiez ces deux points avant de vous fier à un contrôle d’accès par cookies sur le nom d’hôte des médias.
Que nécessite chaque nom d’hôte supplémentaire sur le CDN ? Un certificat qui le couvre, un enregistrement DNS qui assure son routage et une configuration qui l’accepte. Amazon CloudFront, par exemple, n’ajoute un nom de domaine alternatif que si le certificat associé le couvre dans ses noms alternatifs du sujet, et refuse un nom déjà présent sur une autre distribution. CloudFront n’associe qu’un certificat à la fois à une distribution ; ce certificat doit donc couvrir tous les noms d’hôte de la distribution. L’enregistrement de routage est normalement un CNAME, et CloudFront exige l’autorisation de le créer auprès du fournisseur DNS du domaine. Pour un nom d’hôte appartenant à un client, celui-ci doit donc créer cet enregistrement ou vous accorder cet accès. DNS n’autorise pas de CNAME à la racine d’un domaine (le sommet de zone) ; cela fonctionne donc pour un sous-domaine tel que media.example.net, mais pas pour example.net lui-même. Pour un sommet de zone, CloudFront documente un enregistrement d’alias dans Amazon Route 53 ou, avec un autre fournisseur DNS, des adresses IP statiques Anycast. Vous devez surveiller et renouveler les certificats importés d’une autorité tierce. AWS Certificate Manager renouvelle les certificats qu’il émet, mais pas sans condition : un certificat validé par DNS se renouvelle automatiquement tant qu’il est utilisé par un service AWS et que ses enregistrements CNAME de validation restent dans le DNS public, tandis qu’un certificat validé par e-mail nécessite une intervention du propriétaire du domaine. Pour les domaines appartenant à des clients, convenez de la personne chargée de maintenir ces enregistrements et surveillez l’expiration pour chaque nom d’hôte, pas seulement le principal.
Un fichier est-il mis en cache une seule fois ou une fois par nom d’hôte ? Cela dépend de la clé de cache du CDN. La clé par défaut de Cloudflare inclut l’hôte ; un même chemin demandé via deux noms d’hôte correspond donc à deux entrées de cache. CloudFront documente sa clé par défaut comme le nom de domaine de la distribution suivi du chemin de l’URL et précise qu’aucune autre valeur de la requête du spectateur n’est incluse par défaut. Cela importe dans les deux sens. Si chaque nom d’hôte diffuse la même bibliothèque, une clé qui distingue les noms d’hôte stocke des doublons, et CloudFront avertit que les objets en double réduisent le taux de succès du cache et augmentent les requêtes à l’origine. Si la réponse diffère selon le nom d’hôte, par exemple avec un nom d’hôte par locataire, la clé doit distinguer ces noms, car les requêtes qui produisent la même clé reçoivent le même objet en cache. La règle de CloudFront consiste à inclure dans la clé toute valeur de requête qui détermine la réponse de l’origine.

Utilisez des noms d’hôte distincts pour isoler les locataires ou les catégories de ressources, proposer des domaines de diffusion à la marque du client ou migrer progressivement entre fournisseurs. Un nom d’hôte distinct donne à un locataire sa propre origine dans le navigateur, mais pas ses propres réponses en cache : le contenu propre à chaque locataire nécessite aussi une clé de cache ou une configuration du cache qui distingue les noms d’hôte. N’ajoutez pas de noms d’hôte uniquement pour accélérer le chargement des pages avec HTTP/2 ou HTTP/3. Chaque nom d’hôte supplémentaire implique son propre enregistrement DNS, sa couverture par un certificat, son comportement CORS, la portée de ses cookies et sa configuration du cache.

Deux fonctionnalités documentées de Transloadit concernent le nom d’hôte de diffusion. Les URL du Smart CDN sont diffusées depuis un nom d’hôte propre au Workspace, [your-workspace].tlcdn.com ; chaque Workspace dispose donc de son propre nom d’hôte de diffusion. Lorsqu’une Assembly exporte vers votre propre bucket avec le Robot /s3/store, le paramètre url_prefix définit le préfixe de l’URL renvoyée dans l’Assembly Status, ce qui vous permet de fournir des liens utilisant un nom d’hôte de CDN que vous exploitez devant ce bucket.

url_prefix modifie uniquement l’URL renvoyée ; il ne change ni le bucket ni ses autorisations d’accès, et le nom d’hôte lui-même doit être configuré auprès de vos fournisseurs de CDN et de DNS. Les pages liées ici ne décrivent pas la diffusion des URL du Smart CDN depuis un domaine personnalisé.

Explorer les capacités de diffusion de Transloadit

Que sont les domaines CDN multiples ?

Fonctionnement des domaines CDN multiples

Points clés

Quand les domaines CDN multiples sont importants

Comment Transloadit facilite l’utilisation de plusieurs domaines CDN

Références

Transformer vos connaissances sur les médias en une chaîne de traitement opérationnelle