Que sont les serveurs d’origine ?

Les serveurs d’origine stockent ou génèrent la version de référence du contenu. Les caches et les réseaux de diffusion de contenu récupèrent ce contenu auprès de l’origine lorsqu’ils ne peuvent pas répondre localement à une requête.

HTTP définit un serveur d’origine comme un programme capable de produire des réponses faisant autorité pour une ressource cible donnée. Dans une architecture de diffusion, il s’agit du système en amont qu’un CDN ou un proxy inverse contacte lorsqu’il ne dispose d’aucune réponse stockée réutilisable : un stockage d’objets, un serveur web, un outil de mise en paquet qui assemble des manifestes ou un service qui génère des versions dérivées à la demande. Pour le client, le CDN lui-même apparaît comme le serveur d’origine ; HTTP appelle un tel intermédiaire une passerelle, ou un proxy inverse. Les durées de fraîcheur, les validateurs, les clés de cache et la prise en charge des requêtes par plages déterminent le nombre de requêtes qui atteignent l’origine. Un objet très demandé qui expire, ou qui n’a jamais été mis en cache, peut y concentrer ces requêtes. Ce terme est sans rapport avec une origine web, la combinaison du schéma, de l’hôte et du port que les navigateurs utilisent pour la politique de même origine et CORS.

Faut-il télécharger à nouveau chaque objet expiré depuis l’origine ? Pas si l’origine envoie des validateurs. Un cache contenant une réponse périmée peut effectuer une requête conditionnelle avec la valeur ETag stockée (dans If-None-Match) ou la date Last-Modified (dans If-Modified-Since). Si son contenu n’a pas changé, l’origine répond 304 (Not Modified) sans renvoyer la représentation. L’origine doit toujours recevoir chaque requête de validation qui lui est transmise et y répondre. Les validateurs réduisent donc le nombre d’octets transférés, mais ne réduisent pas, à eux seuls, le nombre de requêtes.
Comment éviter que de nombreux points de présence récupèrent chacun le même objet ? Faites passer leurs requêtes sans résultat en cache par un niveau de cache partagé devant l’origine. Sans ce niveau, chaque point de cache qui ne trouve pas de résultat peut envoyer sa propre requête pour le même contenu. Amazon CloudFront Origin Shield, la protection de l’origine de Fastly et Cloudflare Smart Tiered Cache acheminent tous ces requêtes par un niveau supérieur désigné ; la topologie Generic Global de Cloudflare sélectionne plutôt les niveaux supérieurs dans des groupes régionaux. CloudFront et Fastly regroupent aussi les requêtes simultanées pour un même objet absent du cache, jusqu’à n’envoyer qu’une seule requête à l’origine. Fastly signale une limite : si la réponse s’avère impossible à mettre en cache, par exemple parce qu’elle est privée et propre à un utilisateur, chaque requête en attente doit alors être envoyée indépendamment à l’origine. AWS indique qu’Origin Shield peut être mal adapté au contenu dynamique transmis à l’origine par proxy, au contenu peu propice à la mise en cache ou au contenu rarement demandé, et qu’il est facturé séparément.
Que reçoivent les utilisateurs lorsque l’origine est indisponible ? Les réponses encore fraîches dans un cache continuent d’être servies. Pour les réponses périmées, la règle HTTP interdit à un cache de les servir, sauf s’il est déconnecté ou en a reçu l’autorisation explicite. Cela reste toujours interdit si la réponse contient no-cache ou must-revalidate ou, pour un cache partagé tel qu’un CDN, proxy-revalidate ou s-maxage. Lorsqu’aucune de ces directives ne s’applique, la directive stale-if-error de la RFC 5861 donne cette autorisation quand l’origine renvoie un code 500, 502, 503 ou 504, ou est injoignable. Sa valeur limite l’ancienneté autorisée de la réponse, calculée à partir de son expiration et non du début de la panne : avec max-age=600, stale-if-error=1200, la réponse peut être utilisée en cas d’erreur jusqu’à ce que son âge total atteigne 1800 secondes. Pour couvrir une maintenance planifiée, la valeur doit englober le temps écoulé depuis l’expiration et la durée de l’interruption. Le comportement des CDN diffère dans les détails : CloudFront indique appliquer stale-if-error lorsque l’origine est injoignable ou renvoie un statut 5xx, dans la limite de la valeur de la directive ou de son TTL maximal, selon la plus petite des deux valeurs. Il précise aussi qu’en l’absence de cette directive, il sert tout de même un objet expiré qu’il détient lorsque l’origine renvoie un statut 5xx. Aucun réglage ne peut aider pour un objet qui n’a jamais été mis en cache ou qui n’est plus stocké, et CloudFront indique pouvoir évincer un objet rarement demandé alors que l’origine est toujours en panne.
Une origine qui fonctionne correctement peut-elle malgré tout diffuser la mauvaise variante via un CDN ? Oui, lorsque la réponse dépend d’un élément que la clé de cache ne prend pas en compte. HTTP fixe deux règles : une réponse stockée avec un en-tête Vary ne peut être réutilisée que pour des requêtes dont les champs d’en-tête désignés correspondent, et un cache partagé ne doit pas réutiliser la réponse à une requête contenant Authorization, sauf si la réponse l’autorise explicitement. Un CDN n’applique pas nécessairement la règle Vary telle qu’elle est écrite : Cloudflare indique ne pas prendre en compte par défaut les valeurs de Vary dans ses décisions de mise en cache, et ne les respecter que pour Vary: Accept-Encoding ou lorsqu’un réglage Vary a été configuré. Vérifiez donc que votre CDN respecte les en-têtes nommés dans Vary, ou ajoutez-les vous-même à sa clé de cache. Il en va de même pour toute autre donnée qui modifie la réponse, par exemple un cookie ou un paramètre de requête que le CDN est configuré pour ignorer : ajoutez-la à la clé de cache ou marquez la réponse comme non stockable en cache.
Les clients peuvent-ils contourner le CDN et interroger directement l’origine ? Oui, si l’origine est accessible publiquement et que son adresse devient connue, ce qui contourne la mise en cache et les protections du CDN. La documentation de Cloudflare énumère les options : n’autoriser que les plages d’adresses IP du CDN (une option qu’elle juge modérément sûre et vulnérable à l’usurpation d’adresse IP), exiger un en-tête de requête secret, authentifier le CDN avec un certificat client TLS (Authenticated Origin Pulls), ou établir la connexion par un tunnel uniquement sortant pour que l’origine n’ait aucune adresse routable publiquement. Pour les origines Amazon S3, AWS énumère trois tâches : créer un contrôle d’accès à l’origine CloudFront, qui signe les requêtes de CloudFront vers le bucket, et l’associer à la distribution ; lui donner l’autorisation de lire les fichiers, ce que la documentation réalise avec une politique de bucket limitée à cette distribution ; et retirer à toute autre identité l’autorisation de lire les fichiers via les URL Amazon S3. La signature seule laisse un bucket lisible publiquement accessible.

Configurez une origine pour n’exposer que les ressources et les opérations nécessaires au CDN. Les lenteurs ou les pannes de l’origine retardent les requêtes sans résultat en cache, les revalidations et le contenu non stockable en cache, car les caches en périphérie ne peuvent pas répondre localement à ces requêtes. Les objets encore frais en périphérie peuvent continuer d’être servis.

Avec le Smart CDN de Transloadit, il existe deux niveaux en amont. Vos fichiers originaux restent dans votre propre stockage, par exemple un bucket Amazon S3, et un Template les importe depuis ce stockage. Lorsque le CDN n’a aucune copie en cache pour une URL demandée, Transloadit exécute le Template et le Robot /file/serve remet le résultat au CDN. L’exécution du Template joue donc le rôle d’origine pour tlcdn.com, et votre bucket est la source située en amont. /file/serve définit l’en-tête Cache-Control de cette réponse ; son paramètre cache_duration définit à la fois max-age et s-maxage, ce qui détermine à quelle fréquence les requêtes reviennent au Template et à votre stockage.

La documentation de /file/serve déconseille de l’utiliser sans CDN devant lui, car chaque requête sans résultat en cache relancerait la transformation. Les pages liées ici ne décrivent pas ce qui est servi lorsque votre stockage est injoignable lors d’une absence de résultat en cache, ni si un résultat expiré peut encore être servi.

Explorer les capacités de diffusion de Transloadit

Que sont les serveurs d’origine ?

Fonctionnement des serveurs d’origine

Points clés

Quand les serveurs d’origine sont importants

Comment Transloadit vous aide avec les serveurs d’origine

Références

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