Qu’est-ce qu’un serveur périphérique ?

Un serveur périphérique traite les requêtes à proximité des utilisateurs finaux plutôt qu’exclusivement sur une origine centrale. Il peut mettre du contenu en cache ou effectuer des opérations de routage, de transformation, d’authentification et de calcul sur un site d’un réseau distribué.

Dans la terminologie HTTP, un serveur périphérique est un proxy inverse, que la RFC 9110 appelle une passerelle : il se présente au client comme le serveur d’origine et transmet à un autre serveur les requêtes auxquelles il ne peut pas répondre lui-même. Les opérateurs de CDN en exploitent un grand nombre, regroupés sur des sites que Fastly appelle points de présence (POP) et Cloudflare centres de données. Un client atteint l’un de ces sites soit parce que le DNS renvoie une adresse choisie pour ce client, soit parce que la même adresse anycast est annoncée depuis chaque site et que le routage réseau en sélectionne un. Le serveur périphérique répond ensuite depuis son cache, exécute la logique configurée pour traiter les requêtes ou transmet la requête vers l’origine. Une réponse mise en cache sur un site n’est pas automatiquement stockée sur les autres, et le chemin suivi lorsqu’elle est absente du cache dépend du CDN et de sa configuration : directement vers l’origine, ou d’abord vers un cache de niveau supérieur, comme un POP bouclier Fastly, un niveau supérieur de Cloudflare Tiered Cache ou un cache périphérique régional Amazon CloudFront.

Le serveur périphérique le plus proche traite-t-il toujours la requête ? Non. Avec l’anycast, le système de routage choisit le site selon la topologie du réseau, et la RFC 4786 précise que la proximité topologique n’est généralement pas corrélée aux performances aller-retour. Avec une sélection fondée sur le DNS, le serveur DNS faisant autorité du CDN voit l’adresse du résolveur récursif (le serveur DNS qui recherche les noms pour le compte de l’utilisateur) plutôt que l’adresse de l’utilisateur lui-même, sauf si le résolveur transmet un sous-réseau client, qui est une forme tronquée de l’adresse de l’utilisateur. Une personne utilisant un résolveur distant peut donc être dirigée vers un site proche de ce résolveur.
Une réponse mise en cache sur un site périphérique est-elle disponible sur tous les sites ? Pas automatiquement : un site qui n’a pas stocké la réponse ne la trouve pas dans son cache, et le chemin suivi dans ce cas dépend du CDN et de sa configuration. Les POP Fastly transmettent les requêtes à l’origine indépendamment les uns des autres, sauf si la protection par POP bouclier les fait passer par un même POP intermédiaire, tandis que Cloudflare Tiered Cache fait interroger un niveau supérieur par un centre de données de niveau inférieur avant de solliciter l’origine. Amazon CloudFront dispose d’un tel niveau par défaut : un POP qui ne trouve pas la réponse dans son cache interroge généralement un cache périphérique régional, qui peut déjà contenir l’objet. Aucun de ces niveaux ne garantit quelles requêtes atteignent l’origine. Cloudflare applique Tiered Cache uniquement aux requêtes admissibles à la mise en cache, CloudFront envoie les requêtes dynamiques et les méthodes telles que POST directement du POP à l’origine, et Fastly recommande au code Compute de se rabattre sur l’origine lorsque le POP bouclier est indisponible.
Quel code peut s’exécuter sur un serveur périphérique ? Cela dépend du produit et de la phase de traitement de la requête à laquelle le code est rattaché ; vérifiez donc ces points avant de concevoir une solution qui en dépend. Amazon CloudFront documente deux options : CloudFront Functions pour les opérations légères, comme la normalisation des clés de cache, la modification des en-têtes, les redirections et la validation des jetons, sans accès au réseau ni au corps de la requête ; et Lambda@Edge pour les fonctions nécessitant un accès au réseau, des bibliothèques tierces ou le corps de la requête. L’organisation en niveaux peut aussi modifier la fréquence d’exécution du code : avec la protection par POP bouclier de Fastly, le code périphérique s’exécute généralement deux fois, une fois sur le premier POP et une fois sur le POP bouclier. Une logique qui réécrit une requête ou ajoute un en-tête doit donc pouvoir être exécutée deux fois sans risque.
La validation d’une URL signée en périphérie protège-t-elle l’origine ? Uniquement pour les requêtes qui passent par la périphérie. CloudFront documente deux contrôles distincts : les URL signées ou les cookies signés restreignent l’accès aux fichiers des caches périphériques, tandis que l’accès à l’origine doit être verrouillé séparément pour empêcher les clients de contourner le CDN et d’y récupérer directement les fichiers. Pour une origine S3, cela signifie accorder à un contrôle d’accès à l’origine l’autorisation de lire le bucket et retirer à tous les autres l’autorisation de lire les fichiers via les URL S3. Pour une origine personnalisée, cela signifie utiliser un en-tête personnalisé que CloudFront ajoute aux requêtes vers l’origine et que celle-ci exige, avec HTTPS aussi bien sur la connexion du client que sur celle de l’origine, afin que l’en-tête soit chiffré en transit. Les recommandations d’AWS pour les origines derrière un équilibreur de charge précisent que cette protection fonctionne uniquement tant que le nom et la valeur de l’en-tête restent secrets, et recommandent de les renouveler. Par ailleurs, si les clients s’authentifient avec un en-tête Authorization plutôt qu’avec une URL signée, la RFC 9111 interdit à un cache partagé de réutiliser la réponse pour une requête ultérieure, sauf si la réponse l’autorise avec public, s-maxage ou must-revalidate.

Les serveurs périphériques sont particulièrement utiles lorsque de nombreux clients éloignés de l’origine demandent la même réponse : si celle-ci se trouve dans le cache, la requête reçoit une réponse sur le site périphérique et n’atteint jamais l’origine. Une requête à laquelle le serveur périphérique ne peut pas répondre à partir d’une réponse stockée est traitée à son arrivée, soit par l’origine, auquel cas la requête remonte tout de même vers celle-ci, soit par une logique périphérique qui génère elle-même la réponse. Dans ce cas, la périphérie apporte du routage, du filtrage ou une logique de traitement des requêtes plutôt qu’une copie stockée. Lorsque vous concevez une solution reposant sur un serveur périphérique, prévoyez le chemin suivi en l’absence de réponse en cache, le remplissage séparé des caches sur chaque site et les requêtes qui atteignent l’origine sans passer par la périphérie.

Le Smart CDN de Transloadit place une couche de cache périphérique en amont du traitement à la demande. Une requête adressée à une URL tlcdn.com reçoit une réponse depuis la périphérie lorsqu’une copie en cache existe. En l’absence de copie en cache, la requête exécute votre Template sous forme d’Assembly, le Robot /file/serve choisit le résultat à renvoyer et définit son en-tête Cache-Control, puis /tlcdn/deliver met ce résultat en cache et le diffuse à proximité de vos utilisateurs.

Les pages liées décrivent la mise en cache et la diffusion en périphérie ainsi que le traitement dans une Assembly. Elles ne documentent pas d’environnement d’exécution permettant d’exécuter votre propre code en périphérie. Une URL du Smart CDN peut facultativement comporter une date d’expiration et une signature ; si l’URL ou ses paramètres sont modifiés par la suite, la signature ne correspond plus. Cela empêche les tiers de modifier l’URL uniquement lorsque les requêtes non signées sont refusées. Les pages liées ne précisent pas non plus comment une requête non signée visant le même Template est traitée ; testez donc ce comportement sur votre propre Workspace avant de vous y fier. Transloadit décrit le Smart CDN comme une couche de transformation et de diffusion qui ne remplace pas la politique d’autorisation de votre application.

Explorer les capacités de diffusion de Transloadit

Qu’est-ce qu’un serveur périphérique ?

Fonctionnement des serveurs périphériques

Points clés

Quand les serveurs périphériques sont utiles

Comment Transloadit aide à utiliser les serveurs périphériques

Références

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