Lorsqu'un point de présence (POP) CDN ne dispose pas en cache de la ressource demandée, il la récupère depuis votre serveur d'origine : c'est ce qu'on appelle une récupération à l'origine. Une récupération à l'origine se produit également lorsque vous exécutez une tâche de préchargement. Alibaba Cloud CDN vous offre un contrôle précis sur la manière dont les POP communiquent avec votre origine : le protocole à utiliser, la réécriture des URL et des en-têtes, le délai d'attente avant expiration, ainsi que le routage des requêtes vers plusieurs origines.
Fonctionnement
Un client (par exemple, un navigateur) envoie une requête à un POP CDN. L'URL de la requête pointe vers le nom de domaine accéléré par le CDN.
Le POP vérifie son cache. Si la ressource est mise en cache, le POP la renvoie directement au client.
Si la ressource n'est pas en cache, le POP envoie une requête au serveur d'origine selon les politiques d'origine configurées.
Le serveur d'origine renvoie la ressource en fonction de l'URL et des paramètres.
Le POP met la ressource en cache pour les requêtes suivantes.
Le POP renvoie la ressource au client, ce qui achève la requête.
Paramètres de récupération à l'origine
Accès aux buckets OSS privés
Si votre serveur d'origine est Object Storage Service (OSS) d'Alibaba Cloud et que la liste de contrôle d'accès (ACL) du bucket est définie sur privé, les POP CDN ne peuvent pas récupérer les ressources sans autorisations d'accès explicites. Accordez à Alibaba Cloud CDN les autorisations nécessaires afin que les POP puissent récupérer les ressources depuis le bucket privé.
Accorder à Alibaba Cloud CDN des autorisations d'accès sur les buckets OSS privés
Protocole d'origine
Spécifie le protocole utilisé par les POP lors de l'envoi de requêtes à l'origine. Trois options sont disponibles :
|
Option |
Comportement |
|
|
Les POP utilisent toujours HTTP pour les requêtes à l'origine |
|
|
Les POP utilisent toujours HTTPS pour les requêtes à l'origine |
|
|
Les POP utilisent le même protocole que la requête cliente entrante |
Utilisez Follow lorsque votre origine prend en charge à la fois HTTP et HTTPS et que vous souhaitez préserver le protocole du client de bout en bout. Utilisez HTTPS pour imposer une communication chiffrée entre les POP et votre origine, quel que soit le protocole du client.
Hôte d'origine
L'en-tête d'hôte d'origine spécifie le site auquel un POP accède sur le serveur d'origine. Cela est important lorsque plusieurs sites web sont hébergés sur le même serveur d'origine : sans l'en-tête d'hôte correct, le serveur d'origine ne peut pas acheminer la requête vers le bon site.
Configurez un hôte d'origine par défaut global ou spécifiez différents hôtes d'origine pour chaque serveur d'origine.
Réécriture d'URL d'origine
Utilisez la réécriture d'URL d'origine lorsque le chemin d'accès à la ressource sur votre serveur d'origine a changé, mais que vous devez conserver les URL visibles par le client inchangées. Lorsqu'un POP récupère la ressource, il réécrit le chemin d'URL demandé vers le nouveau chemin selon les règles configurées, sans que le client ne soit informé du changement.
Paramètres d'origine
Configurez des règles pour réécrire les paramètres de requête dans les requêtes à l'origine. Les options incluent :
Supprimer tous les paramètres
Conserver uniquement des paramètres spécifiques
Supprimer des paramètres spécifiques
Utilisez cette fonctionnalité pour supprimer les paramètres de suivi ou d'analyse avant qu'ils n'atteignent votre origine, ou pour normaliser les URL afin d'améliorer l'efficacité du cache.
En-têtes de requête d'origine
Ajoutez, modifiez ou supprimez les en-têtes de requête HTTP que les POP envoient à votre serveur d'origine lors de la récupération à l'origine. Cas d'utilisation courants :
Identification du trafic CDN : ajoutez un en-tête personnalisé pour distinguer les requêtes d'origine CDN du trafic direct, ce qui vous aide à détecter les contournements de cache ou à attribuer les sources de trafic lorsque vous utilisez plusieurs fournisseurs CDN.
Transmission du contexte client : transférez des informations relatives à l'utilisateur (telles que la région géographique du client) à l'origine afin que votre application puisse personnaliser les réponses.
Contrôle de l'accès à l'origine : configurez votre origine pour rejeter les requêtes dépourvues d'un en-tête secret spécifique, empêchant ainsi l'accès direct qui contourne le CDN.
Activation du partage de ressources cross-origin (CORS) : ajoutez l'en-tête
Originaux requêtes d'origine lorsque des clients ne prenant pas en charge CORS doivent accéder à des ressources cross-origin.
SNI d'origine et liste blanche Common Name
Ces paramètres s'appliquent lorsque le protocole d'origine est HTTPS.
SNI (Server Name Indication) d'origine spécifie le nom de domaine qu'un POP envoie lors de la négociation TLS. Configurez ce paramètre lorsque plusieurs sites HTTPS avec des certificats différents partagent la même adresse IP d'origine : sans le SNI correct, le serveur d'origine renvoie le mauvais certificat et la négociation TLS échoue.
La liste blanche Common Name ajoute une étape de vérification après la négociation TLS : le POP vérifie que le Common Name ou le Subject Alternative Name (SAN) du certificat d'origine correspond au SNI configuré. Activez cette option pour vous protéger contre la substitution de certificats et les attaques de type « man-in-the-middle » sur la connexion POP-vers-origine.
En-têtes de réponse d'origine
Configurez des règles pour ajouter, modifier ou supprimer les en-têtes de réponse HTTP renvoyés par le serveur d'origine, avant que le POP ne transmette la ressource au client. Par exemple, ajoutez des en-têtes de réponse cross-origin tels que Access-Control-Allow-Origin lorsque l'origine ne les inclut pas.
Redirection 301/302
Par défaut, lorsque votre origine renvoie une redirection 301 ou 302, le POP transmet la réponse de redirection directement au client. Le client envoie ensuite une nouvelle requête à l'adresse redirigée, ce qui entraîne un aller-retour supplémentaire.
Activez la fonctionnalité de redirection 301/302 pour que les POP suivent la redirection et récupèrent la ressource depuis l'adresse redirigée pour le compte du client. Cela élimine l'aller-retour supplémentaire du client et réduit la latence totale de la requête.
Délai d'expiration
Définit le temps maximal pendant lequel un POP attend pour établir une connexion avec le serveur d'origine et recevoir une réponse complète. Si l'origine ne répond pas dans ce délai, le POP interrompt la connexion et renvoie une erreur 5xx au client.
Définissez un délai d'expiration correspondant au temps de réponse habituel de votre origine. Un délai plus court permet un échec rapide et empêche les clients d'attendre indéfiniment une origine lente. Un délai plus long convient aux origines qui génèrent des réponses volumineuses ou complexes.
Configurer le délai d'expiration des requêtes HTTP d'origine
Origine conditionnelle
Acheminez les requêtes vers différentes origines en fonction des règles configurées dans le moteur de règles. Filtrez les requêtes par attributs tels que l'en-tête de requête, le paramètre de chaîne de requête, le chemin ou l'IP client. Lorsqu'une requête correspond à une règle, le POP l'achemine vers l'origine spécifiée. Utilisez le type de correspondance URI dans le moteur de règles avec des caractères génériques (* et ?) pour le routage d'origine basé sur le chemin.
Origine avancée
Acheminez différentes requêtes vers différents serveurs d'origine en fonction de conditions telles que les paramètres de requête ou les adresses IP client. Utilisez l'origine avancée lorsque vous disposez de plusieurs serveurs d'origine et avez besoin d'un contrôle granulaire sur l'origine qui gère chaque requête — par exemple, acheminer le trafic API vers un serveur et les actifs statiques vers un autre.
Récupération à l'origine via IPv6
Si votre serveur d'origine prend en charge IPv6, activez la récupération à l'origine via IPv6 afin que les POP privilégient le protocole IPv6 lors de la connexion à l'origine. Configurez un basculement automatique vers IPv4 pour maintenir la disponibilité du service en cas d'échec d'une connexion IPv6.