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 permettre au service de basculer en cas d'erreurs matérielles (par exemple, un échec de connectivité) ou de nouvelle tentative basée sur 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 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 autoriser Media CDN à mettre en cache les réponses d'origine supérieures à 1 Mo, 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 valideur).
  • Un en-tête HTTP Date valide.
  • Un en-tête Content-Length valide.
  • L'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 qui sont remplis par d'autres caches en aval avant l'origine. Ces caches acceptent une distribution unique importante, disposent d'une capacité de stockage de cache considérable et agissent comme un 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 sont compatibles avec les demandes de réduction (ou coalescence) pour réduire davantage la charge sur l'origine. En se basant sur des charges de travail réelles et à grande échelle :

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

Les clients peuvent constater des taux de déchargement différents en fonction de la configuration de cache, de la charge utilisateur, des charges de travail (en direct et à la demande), de la distribution des utilisateurs et de la quantité de contenus "longue traîne" (taille totale des corpus) qu'ils diffusent aux utilisateurs de 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 ne partageant pas la même clé de cache ne peuvent pas faire l'objet d'une réduction.

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 Amazon S3, y compris les buckets privés qui utilisent la signature AWS 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, lorsque vous configurez HTTP/2, la connexion ne "bascule" pas sur HTTP/1.1 en cas d'erreur, afin d'être explicite sur le comportement de la connectivité d'origine.
  • Media CDN utilise automatiquement le port approprié en fonction du protocole, c'est-à-dire le port 80 pour HTTP ou le 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 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 en savoir plus sur la réécriture d'en-têtes d'hôtes pour la configuration par route, consultez la section Configurer des routes de service. Pour en savoir plus sur la définition des actions de remplacement 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 sont déclenchés, et le moment où le basculement client ultérieur peut être déclenché.

La section suivante décrit les délais avant expiration configurables et 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 correspond aux requêtes vers "/segments/" et possède 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 essayez de vous connecter à Origin A et qu'elle échoue dans un délai d'une seconde en raison d'un certificat TLS non valide, il vous reste environ quatre secondes pour établir une connexion réussie à Origin B.

  • Origin C correspond aux requêtes vers "/manifests/*", possède une valeur maxAttemptsTimeout de 10s, une valeur maxAttempts de 3 et failover_origin n'est pas configuré. La valeur connectTimeout est définie sur sa valeur par défaut, 5s. Media CDN tente de se connecter à Origin C jusqu'à trois fois, ce qui offre jusqu'à 10 secondes (limite maxAttemptsTimeout) pour établir une connexion.

Nouvelles tentatives pour les requêtes d'origine

Media CDN accepte les nouvelles tentatives pour les requêtes d'origine, ce qui permet de relancer les requêtes d'origine. Vous pouvez spécifier le nombre de tentatives d'exécution de l'origine actuelle avant qu'une origine de basculement (le cas échéant) ne soit utilisée.

  • Media CDN tente d'atteindre l'origine principale jusqu'à atteindre la valeur maxAttempts configurée, qui est définie par défaut sur 1.
  • Media CDN relance jusqu'à trois fois les connexions d'origine avant de déterminer un échec et de renvoyer une erreur HTTP 502 Bad Gateway à l'utilisateur. Cela inclut toutes les connexions à des origines 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, de DNS et de handshake TLS, ainsi que les délais d'expiration TCP/UDP.
HTTP_5XX Nouvelle tentative pour 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 Nouvelle tentative pour les codes d'état 4xx pouvant être réessayés, y compris 409 et 429.
NOT_FOUND Nouvelle tentative en cas de code d'état HTTP 404.
FORBIDDEN Nouvelle tentative en cas de code d'état HTTP 403.

Si vous avez besoin d'une vérification d'état active, d'un round-robin (tentatives à 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 configurée, 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 à 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 le comportement des en-têtes Vary, ETag et Last-Modified de vos contenus multimédias est cohérent 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.

Étape suivante