Cette page a été traduite par l'API Cloud Translation.

Présentation des origines

Media CDN vous permet de récupérer du contenu à partir de votre infrastructure d'origine, qu'il soit hébergé dans Google Cloud, dans un autre cloud ou sur site.

Chaque configuration peut être associée à une ou plusieurs origines. Les configurations d'origine indiquent à Media CDN comment se connecter à votre infrastructure, quand et comment basculer entre les différentes infrastructures, effectuer une nouvelle tentative ou faire expirer une tentative en cours, et quel protocole utiliser pour la connexion.

Les origines présentent les caractéristiques suivantes:

Les origines peuvent être définies par hôte et par route, ce qui permet à une seule ressource EdgeCacheService d'être mappée vers plusieurs origines contenant, par exemple, des fichiers manifestes, des séquences vidéo et d'autres contenus statiques.
Les origines sont accessibles via HTTP/2, HTTPS et HTTP/1.1 non chiffré.
Les nouvelles tentatives et les comportements de basculement sont configurés par origine et peuvent autoriser au service de basculer en cas d'erreurs matérielles (comme un échec de connectivité) ou de réessayer en fonction des réponses HTTP 404 Not Found ou HTTP 429 Too Many Requests.
Les ressources privées dans Google Cloud ou sur site sont accessibles en configurant un équilibreur de charge d'application externe d'origine derrière Media CDN.
Le comportement de suivi de redirection est configuré individuellement par origine. Vous pouvez activer le suivi des redirections vers d'autres serveurs d'origine sur Media CDN.

Exigences d'origine

Pour permettre à Media CDN de mettre en cache les réponses d'origine dont la taille est supérieure à 1 Mio, une origine doit inclure les éléments suivants dans les en-têtes de réponse pour à la fois pour les requêtes HEAD et GET, sauf indication contraire:

Un en-tête de réponse HTTP Last-Modified ou ETag (un programme de validation)
Un en-tête HTTP Date valide.
Un en-tête Content-Length valide.
En-tête de réponse Content-Range, en réponse à une requête Range GET. L'en-tête Content-Range doit avoir une valeur valide au format bytes x-y/z (où z correspond à la taille de l'objet).

Le protocole d'origine par défaut est HTTP/2. Si vos origines ne sont compatibles qu'avec HTTP/1.1, vous pouvez définir le champ de protocole de manière explicite pour chaque origine.

Protection d'origine

Media CDN offre une infrastructure périphérique élevée à plusieurs niveaux conçue pour minimiser activement le remplissage de cache dans la mesure du possible.

Il existe trois couches principales d'infrastructure de mise en cache :

Les caches périphériques profonds, qui desservent la majorité du trafic et le déchargent au sein du réseau d'un fournisseur de services.
Le point d'appairage périphérique de Google, qui est connecté à des milliers de FAI et joue le rôle de cache de niveau intermédiaire pour les caches périphériques et, dans les cas où les caches périphériques ne sont pas présents dans un FAI donné, le rôle de cache visible par les utilisateurs.
Caches à longue traîne dans le réseau de Google qui sont remplis par d'autres caches en aval avant l'origine. Ces caches acceptent un nombre important de distributions uniques, une capacité importante de stockage du cache, et agissent en tant que bouclier d'origine.

Une présentation de cette topologie est présentée ici :

Présentation de la topologie (cliquez pour agrandir).

Toutes les couches de mise en cache autorisent le repli (ou coalescing) des demandes pour réduire la charge de l'origine. En se basant sur des charges de travail réelles et à grande échelle :

> 95% du remplissage du cache utilise un nœud de cache à longue traîne dédié de la région, afin de réduire les coûts et la latence du remplissage du cache.
Le remplissage de cache entre l'origine et l'infrastructure périphérique de Google est entièrement effectué sur le réseau backbone privé mondial de Google, ce qui réduit la latence de remplissage du cache et améliore la fiabilité, soit deux avantages actifs pour les charges de travail de diffusion en direct.
Les caches se remplissent mutuellement les uns avec les autres lorsque cela est avantageux, ce qui réduit d'autant les taux de remplissage de cache.
Media CDN offre une capacité de stockage importante ce qui réduit les taux d'éviction, même pour les requêtes de longue traîne contenus.

Les clients peuvent constater des taux de déchargement différents en fonction de leur cache. charge utilisateur, charges de travail (en direct ou à la demande, par exemple), et la quantité de contenu en longue traîne (taille totale du corpus) qu'ils diffusent d'utilisateurs dans plusieurs régions.

Demande de réduction

La réduction des requêtes consiste à réduire activement plusieurs requêtes de remplissage de cache pilotées par l'utilisateur pour la même clé de cache en une seule requête d'origine par nœud périphérique.

En association avec le bouclier d'origine, cela réduit davantage la charge d'origine et les besoins en bande passante de sortie. Il s'agit du comportement par défaut de Media CDN.

Les requêtes réduites incluent à la fois la requête côté client et la requête de remplissage de cache (réduite). Le leader de la session réduite permet d'effectuer la requête de remplissage d'origine, ce qui signifie que l'origine ne voit que les en-têtes (y compris le user-agent) de ce client.

Les requêtes qui ne partagent pas la même clé de cache ne peuvent pas être réduites.

Connectivité d'origine

Les sections suivantes décrivent la manière dont Media CDN se connecte aux origines, comment les requêtes HTTP sont effectuées et comment vous pouvez authentifier les requêtes.

Origines et protocoles acceptés

Media CDN est directement compatible avec n'importe quel point de terminaison HTTP accessible au public en tant qu'origine, y compris :

Les buckets Cloud Storage, y compris les buckets privés via les comptes de service IAM (Identity and Access Management).
Équilibreurs de charge d'application externes
Les buckets compatibles avec Amazon S3, dont des buckets privés qui utilisent AWS Signature version 4
Les autres espaces de stockage d'objets accessibles au public, tel qu'Azure Blob Storage.
Les serveurs Web accessibles au public, tels que des VM publiques ou des hôtes sur site.

La connectivité aux origines se fait via des tunnels sécurisés et via le réseau backbone de Google.

Le tableau suivant détaille les protocoles d'origine compatibles.

Protocole	Compatible	SSL (TLS) requis
HTTP/2	Oui (par défaut)	Yes
HTTPS (HTTP/1.1 via TLS)	Oui	Oui
HTTP/1.1	Oui	Non

Media CDN utilise le protocole HTTP/2 (h2) pour se connecter par défaut à une origine. Les protocoles HTTP/2 et HTTPS nécessitent tous deux un certificat TLS (SSL) valide et publiquement approuvé. Un certificat valide est un certificat non expiré qui est signé par une autorité de certification publique et dont le nom alternatif d'objet correspond au nom d'hôte envoyé à l'origine.

Remarques :

Si votre origine n'est pas compatible avec HTTP/2, vous pouvez définir explicitement le protocole (par origine) sur HTTP (HTTP/1.1) ou HTTPS (HTTP/1.1 via TLS).
Lorsque vous configurez HTTPS ou HTTP/1.1 en tant que protocole d'origine, Media CDN ne négocie pas de protocole alternatif (tel que HTTP/2). De même, lors de la configuration du protocole HTTP/2, la connexion utiliser le protocole HTTP/1.1 pour préciser la connectivité d'origine comportemental.
Media CDN utilise automatiquement le port approprié en fonction du Protocol: port 80 pour HTTP ou port 443 pour HTTPS et HTTP/2.

En-têtes de requêtes d'origine

Lors de la connexion à une origine, Media CDN utilise l'en-tête Host de la requête du client par défaut.

Le tableau suivant documente ce que l'origine voir dans la requête entrante dans différents scénarios de configuration :

Requête client	`EdgeCacheService.hostRewrite`	`EdgeCacheOrigin.hostRewrite`	originAddress	En-tête d'hôte / SNI TLS à l'origine
media.example.com	Aucun	Aucun	backend.example.com	media.example.com
media.example.com	service.example.com	Aucun	backend.example.com	service.example.com
media.example.com	Aucun	origin.example.com	backend.example.com	origin.example.com
media.example.com	service.example.com	origin.example.com	backend.example.com	origin.example.com
media.example.com	service.example.com	origin.example.com	gs://vod-content-bucket	défini automatiquement en fonction du nom de bucket

L'origine principale et toutes les origines de basculement voient le même en-tête d'hôte, si elles partagent la même configuration routeRule ou hostRewrite.

Tous les paramètres hostRewrite sont ignorés lors de l'utilisation d'un bucket Cloud Storage comme origine, car les valeurs d'en-tête d'hôte alternatives ne sont pas acceptées par les buckets Cloud Storage. L'en-tête d'hôte est automatiquement défini en fonction du nom du bucket.

La valeur SNI (Indication du nom de serveur) TLS dans la requête (pour les requêtes HTTP/3, HTTP/2 et HTTPS) est définie sur la même valeur que l'en-tête d'hôte envoyé à l'origine.

Pour savoir comment réécrire les en-têtes d'hôte pour une configuration par route, consultez la section Configurez les routes de service. Pour en savoir plus sur la configuration actions de forçage par origine, consultez la section Basculement d'origine sans suivi de redirection.

Basculement et délais avant expiration

Les sections suivantes décrivent ces options de configuration :

Délais avant expiration : déterminer la durée pendant laquelle Media CDN attend la connexion à votre origine ou la réponse à une requête.
Nouvelles tentatives : déterminer si Media CDN tente de renvoyer une requête HTTP d'origine vers votre origine et sous quelles conditions.
Basculement : déterminer si Media CDN tente de se connecter à une origine de basculement si la première est indisponible ou s'il renvoie plutôt un code d'état spécifique.

Délais avant expiration de l'origine

Les délais avant expiration vous permettent de configurer le moment où les comportements de nouvelle tentative et de basculement de l'origine et quand un basculement client ultérieur peut être déclenché.

La section suivante décrit les délais avant expiration configurables que Media CDN peut utiliser compatible avec:

connectTimeout et maxAttemptsTimeout limitent le temps nécessaire à Media CDN pour trouver une réponse utilisable.

Les deux délais avant expiration incluent le temps nécessaire à l'origine pour renvoyer des en-têtes et pour déterminer s'il convient d'utiliser un basculement ou une redirection. connectTimeout s'applique indépendamment pour chaque tentative d'origine, tandis que maxAttemptsTimeout inclut le temps nécessaire pour se connecter à toutes les tentatives d'origine, en incluant les basculements et les redirections. Le suivi d'une redirection est considéré comme une tentative supplémentaire de connexion à l'origine et est comptabilisé dans le maxAttempts défini pour l'origine configurée.

Lorsque Media CDN rencontre une réponse de non redirection, par exemple en provenance d'une origine de redirection ou de basculement, les valeurs readTimeout et responseTimeout s'appliquent. Les origines redirigées utilisent les valeurs connectTimeout, readTimeout et responseTimeout configurées pour le EdgeCacheOrigin qui a rencontré la redirection.
responseTimeout et readTimeout contrôlent la durée maximale d'une réponse en flux continu. Une fois que Media CDN a déterminé qu'il utilisera une réponse en amont, ni connectTimeout, ni maxAttemptsTimeout n'ont d'importance. À ce stade, readTimeout et responseTimeout entrent en vigueur.

Media CDN effectue au maximum quatre tentatives d'origine sur toutes les origines, quel que soit le paramètre maxAttempts défini par chaque EdgeCacheOrigin. Media CDN utilise la valeur maxAttemptsTimeout de la EdgeCacheOrigin principale. Les valeurs de délai d'expiration par tentative (connectTimeout, readTimeout et responseTimeout) sont configurées pour la EdgeCacheOrigin de chaque tentative.

Le tableau suivant décrit les champs de délai avant expiration :

Champ	Par défaut	Description
connectTimeout	5 secondes	Durée maximale utilisable par Media CDN, entre le lancement de la requête et l'origine, avant que Media CDN détermine si la réponse est utilisable. En pratique, `connectTimeout` couvre le temps nécessaire à la création de la requête, aux recherches DNS, aux handshakes TLS et à l'établissement de connexions TCP/QUIC, jusqu'à l'obtention des en-têtes de réponse qui contiennent le code d'état HTTP. Le délai avant expiration doit être compris entre 1 et 15 secondes.
maxAttemptsTimeout	15 secondes	Délai maximal pour toutes les tentatives de connexion à l'origine (y compris les origines de basculement) avant qu'une erreur soit renvoyée au client. Une erreur HTTP 504 est renvoyée si le délai avant expiration est atteint avant le renvoi d'une réponse. Le délai avant expiration doit être compris entre 1 et 30 secondes. Ce paramètre définit la durée totale de toutes les tentatives de connexion d'origine, en incluant les origines de basculement, afin de plafonner le temps total d'attente des clients avant de lancer la diffusion. Seule la première valeur `maxAttemptsTimeout` est utilisée, la première valeur étant définie par l'origine configurée pour la route donnée.
readTimeout	15 secondes	Durée maximale d'attente entre les lectures d'une seule réponse HTTP. Le `readTimeout` est limité par le `responseTimeout`. Toutes les lectures de la réponse HTTP doivent être effectuées dans le délai défini par le `responseTimeout`. Le délai avant expiration doit être compris entre 1 et 30 secondes. Si ce délai avant expiration est atteint avant que la réponse ne soit complète, la réponse est tronquée et enregistrée.
responseTimeout	30 seconds	Durée maximale autorisée pour l'obtention d'une réponse complète. Le délai avant expiration doit être compris entre 1 et 120 secondes. La durée est mesurée à partir du moment où les premiers octets du corps sont reçus. Si ce délai avant expiration est atteint avant que la réponse ne soit complète, la réponse est tronquée et enregistrée.

Prenons les exemples suivants :

Origin A met en correspondance les demandes avec "/segments/" et comporte un 5s pour maxAttemptsTimeout, valeur 1 pour maxAttempts et Valeur failover_origin de Origin B. La valeur par défaut de connectTimeout est 5s. Si vous tentez de vous connecter à Origin A et que l'opération échoue dans un délai de 1 seconde en raison d'un certificat TLS non valide, il vous reste environ quatre secondes pour connexion à Origin B réussie.
Origin C met en correspondance les requêtes avec "/manifests/*" et a une valeur maxAttemptsTimeout 10s, une valeur maxAttempts de 3, et failover_origin non configuré. La La valeur par défaut de connectTimeout est 5s. Media CDN tente de se connecter à Origin C jusqu'à trois fois, avec un délai maximal de 10 secondes (limite maxAttemptsTimeout) pour établir une connexion.

Nouvelles tentatives pour les requêtes d'origine

Media CDN accepte les nouvelles tentatives d'origine, ce qui permet de requêtes envoyées à l'origine pour une nouvelle tentative. Vous pouvez spécifier combien de fois l'origine actuelle peut faire l'objet de nouvelles tentatives avant une origine de basculement (si elle est configurée) ; est tentée.

Media CDN tente d'atteindre l'origine principale jusqu'au la valeur configurée pour maxAttempts, définie par défaut sur 1.
Media CDN relance les connexions d'origine (trois tentatives maximum) fois avant d'échouer et de renvoyer une erreur HTTP 502 Bad Gateway au utilisateur. Cela inclut toutes les connexions d'origine de basculement, qui sont prises en compte dans la limite de trois.
Lors de la configuration d'une ressource d'origine, vous pouvez configurer une origine principale à l'aide du champ originAddress, puis une failoverOrigin facultative. L'élément failoverOrigin pointe vers une autre ressource d'origine.

Le paramètre retryConditions pour chaque origine spécifie les types d'échecs qui déclenchent une nouvelle tentative :

Condition	Par défaut	Description
CONNECT_FAILURE	✔️	Les nouvelles tentatives en cas d'échec incluent les erreurs de routage, de handshake DNS et TLS, et Délais avant expiration TCP/UDP.
HTTP_5XX		Réessayez avec n'importe quel code d'état HTTP `5xx`.
GATEWAY_ERROR		Semblable à `5xx`, mais ne s'applique qu'aux codes d'état `502`, `503` ou `504`.
RETRIABLE_4XX		Réessayer pour `4xx` codes d'état qui peuvent faire l'objet d'une nouvelle tentative, y compris `409` et `429`.
NOT_FOUND		Réessayez avec un code d'état HTTP `404`.
FORBIDDEN		Réessayez avec un code d'état HTTP `403`.

Si vous avez besoin d'une vérification de l'état active, d'un round robin (à tour de rôle) ou d'une orientation basée sur la charge différentes origines, vous pouvez Configurez un équilibreur de charge d'application externe. en tant qu'origine principale.

Comportement de basculement

Le tableau suivant décrit le fonctionnement du basculement et les réponses qu'un client pourrait observer :

Scénario	Basculement configuré	État visible pour les utilisateurs
Media CDN tente de se connecter à votre origine et ne reçoit aucune réponse HTTP après deux tentatives (configuration par défaut).	Non	HTTP `502 Bad Gateway`
Media CDN tente de se connecter à votre origine principale mais n'y parvient pas (erreur de handshake TLS). Une tentative est faite contre votre origine de basculement configurée, qui renvoie un `404` HTTP .	Oui	HTTP `404 Not Found`
Media CDN tente de se connecter à la fois à votre origine principale et à votre origine de basculement, mais ne reçoit aucun code d'état HTTP.	Oui	HTTP `502 Bad Gateway`

Si Media CDN reçoit un code d'état correspondant à un retryConditions configuré, tel qu'une erreur HTTP 404 Not Found ou HTTP 429 Too Many Requests, et que les tentatives de nouvelle tentative et de basculement de l'origine suivantes continuent d'échouer, une erreur HTTP 502 Bad Gateway est renvoyée au client une fois les tentatives d'origine épuisées.

Bonnes pratiques pour le basculement d'origine

Lorsque vous configurez plusieurs origines pour le basculement ou l'équilibrage de charge, assurez-vous que votre contenu multimédia et les comportements des en-têtes Vary, ETag et Last-Modified cohérentes entre vos origines.

Nous vous recommandons de configurer la redirection d'origine uniquement pour les origines fiables et contrôlées. Assurez-vous que toutes les origines d'une chaîne de redirection sont fiables, car chacune d'elles produit du contenu diffusé par votre EdgeCacheService.