Présentation des origines

Media CDN vous permet d'extraire du contenu depuis 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 de correspondre à 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 permettre au service de basculer en cas d'erreurs réelles (telles que l'échec de la connectivité) ou de réessayer en fonction des réponses HTTP 404 Not Found ou 429 Too Many Requests.
  • Il est possible d'accéder aux ressources privées dans Google Cloud ou sur site en configurant un équilibreur de charge d'application externe en tant qu'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 d'une taille supérieure à 1 Mio, une origine doit inclure les éléments suivants dans les en-têtes de réponse 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 :

  1. 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.
  2. 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.
  3. Caches à longue traîne au sein du réseau de Google que d'autres caches en aval remplissent avant l'origine. Ces caches acceptent une distribution unique, offrent une capacité de stockage de cache importante et agissent en tant que bouclier d'origine.

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

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

Toutes les couches de mise en cache acceptent le repli (ou coalescing) des requêtes afin de réduire davantage la charge de l'origine. En se basant sur des charges de travail réelles et à grande échelle :

  • Plus de 95% du remplissage du cache utilise un nœud de cache à longue traîne dédié dans la région, afin de réduire les coûts et la latence du remplissage de 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 dispose d'une capacité de stockage importante dans tous les caches, ce qui réduit les taux d'éviction, même pour les contenus en longue traîne moins populaires.

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

Demande de réduction

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

Combiné à la protection de l'origine, ce mécanisme réduit davantage les besoins en charge de l'origine et 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). L'instance principale de la session réduite est utilisée pour envoyer la requête de remplissage de l'origine, ce qui signifie que l'origine ne voit les en-têtes (y compris le user-agent) que 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, y compris les 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) Oui
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 de HTTP/2, la connexion ne recourt pas à HTTP/1.1 afin d'être explicite sur le comportement de connectivité d'origine.
  • Media CDN utilise automatiquement le port approprié en fonction du protocole: 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 par défaut l'en-tête Host de la requête client.

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 Aucune Aucune backend.example.com media.example.com
media.example.com service.example.com Aucune backend.example.com service.example.com
media.example.com Aucune 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 plus d'informations sur la réécriture des en-têtes d'hôte pour la configuration par route, consultez la section Configurer les routes de service. Pour plus d'informations sur la définition des actions de remplacement par origine, consultez la section Basculement de l'origine sans redirection suivant.

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 sont déclenchés, et à quel moment le basculement client ultérieur peut être déclenché.

La section suivante décrit les délais avant expiration configurables compatibles avec Media CDN:

  • 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 requêtes avec "/segments/" et présente une valeur maxAttemptsTimeout de 5s, une valeur maxAttempts de 1 et une 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 la seconde qui suit en raison d'un certificat TLS non valide, il vous reste environ quatre secondes pour établir une connexion réussie à Origin B.

  • Origin C met en correspondance les requêtes avec "/manifests/*", a une valeur maxAttemptsTimeout de 10s, une valeur maxAttempts de 3 et une valeur failover_origin non configurée. La valeur par défaut de connectTimeout est 5s. Media CDN tente de se connecter à Origin C jusqu'à trois fois, ce qui laisse jusqu'à 10 secondes (limite maxAttemptsTimeout) pour établir une connexion réussie.

Nouvelles tentatives pour les requêtes d'origine

Media CDN est compatible avec les nouvelles tentatives de l'origine, ce qui permet de relancer les requêtes envoyées à l'origine qui n'ont pas abouti. Vous pouvez spécifier le nombre de tentatives d'exécution de l'origine actuelle avant toute tentative d'une origine de basculement (si elle est configurée).

  • Media CDN tente d'atteindre l'origine principale jusqu'à la valeur maxAttempts configurée, qui est définie par défaut sur 1.
  • Media CDN relance les connexions d'origine jusqu'à trois fois avant d'échouer et de renvoyer une erreur HTTP 502 Bad Gateway à l'utilisateur. Cela inclut toutes les connexions d'origine de basculement, qui sont comptabilisées 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, les erreurs de handshake DNS et TLS et les 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éessayez pour les codes d'état 4xx 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 entre les origines, vous pouvez configurer 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 effectuée sur l'origine de basculement que vous avez configurée, ce qui renvoie une erreur HTTP 404. 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 à une erreur retryConditions configurée, par exemple une erreur HTTP 404 Not Found ou HTTP 429 Too Many Requests, et que les requêtes d'origine de nouvelle tentative et de basculement qui suivent 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 sont cohérents 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.

Étapes suivantes