Configurer le comportement de mise en cache

Media CDN diffuse du contenu aussi près que possible des utilisateurs en utilisant l'infrastructure de mise en cache périphérique mondiale de Google afin de mettre en cache le contenu et de réduire la charge sur l'infrastructure d'origine.

Vous pouvez contrôler la mise en cache du contenu pour chaque route. Cela vous permet d'optimiser le comportement en fonction du type de contenu, des attributs de requête du client et de vos exigences d'actualisation.

Exigences de mise en cache

Les sections suivantes décrivent les réponses mises en cache par Media CDN et expliquent comment améliorer le déchargement du cache.

Comportement de mise en cache par défaut

Par défaut, les paramètres suivants liés au cache s'appliquent à chaque service de cache périphérique :

• Mode de cache par défaut de CACHE_ALL_STATIC :

  • Respecte les instructions de mise en cache d'origine, telles que Cache-Control ou Expires, jusqu'à une valeur TTL maximale configurable.
  • Met en cache automatiquement les types de contenu multimédia statique, avec une valeur TTL par défaut de 3 600 secondes, si aucune instruction de cache d'origine n'est présente.
  • Met en cache les codes d'état HTTP 200 et 206 (le cache négatif n'est pas activé).

• Ne met pas en cache les réponses avec les instructions de contrôle de cache no-store ou private, ou les réponses ne pouvant pas être mises en cache.

Les réponses qui ne sont pas du contenu statique ou qui ne disposent pas d'instructions de mise en cache valides ne sont pas mises en cache, sauf si la mise en cache est explicitement configurée. Pour savoir comment remplacer le comportement par défaut, consultez la documentation sur les modes de cache.

Le comportement par défaut est équivalent à la cdnPolicy suivante. Les routes sans cdnPolicy explicite se comportent comme si elles avaient la configuration suivante :

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 3600s
  cacheKeyPolicy:
    includeProtocol: false
    excludeHost: false
    excludeQueryString: false
  signedRequestMode: DISABLED
  negativeCaching: false

Réponses pouvant être mises en cache

Une réponse pouvant être mise en cache est une réponse HTTP que Media CDN peut stocker et récupérer rapidement, accélérant ainsi les temps de chargement. Certaines réponses HTTP ne peuvent pas être mises en cache.

Vous pouvez configurer les modes de cache pour chaque route afin d'outrepasser ce comportement (par exemple, en utilisant le mode de cache CACHE_ALL_STATIC pour mettre en cache les types de médias courants), même si l'origine ne définit pas une instruction de contrôle du cache dans la réponse.

Les requêtes et les réponses qui répondent aux critères définis dans la section Réponses ne pouvant pas être mises en cache prévalent aux exigences de mise en cache.

Le tableau suivant décrit les exigences de mise en cache associées à des réponses HTTP spécifiques. Les réponses GET et HEAD doivent respecter ces exigences.

L'en-tête HTTP Age est défini en fonction du moment où Media CDN a mis en cache la réponse pour la première fois et représente généralement les secondes écoulées depuis que l'objet a été mis en cache à un emplacement de protection d'origine. Si votre origine génère un en-tête de réponse "Age", utilisez le mode de cache FORCE_CACHE_ALL pour éviter les revalidations lorsque l'âge dépasse la valeur TTL du cache.

Pour plus d'informations sur la manière dont Media CDN interprète les instructions de mise en cache HTTP, consultez la section Instructions de contrôle de cache.

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.

Réponses ne pouvant pas être mises en cache

Le tableau suivant détaille les attributs de requête et de réponse qui empêchent la mise en cache d'une réponse. Les réponses pouvant être mises en cache, mais qui correspondent à des critères "ne pouvant pas être mis en cache", ne sont pas mises en cache.

Ces règles s'appliquent en plus du mode de cache configuré. Plus précisément :

• Lorsque le mode de cache CACHE_ALL_STATIC est configuré, seules les réponses considérées comme du contenu statique ou les réponses avec des instructions de cache valides dans leurs en-têtes de réponse sont mises en cache. Les autres réponses sont transmises par proxy en l'état.
• Le mode de cache FORCE_CACHE_ALL met en cache toutes les réponses sans condition, sous réserve des exigences d'impossibilité de mise en cache indiquées précédemment.
• Le mode de cache USE_ORIGIN_HEADERS exige que les réponses définissent des instructions de cache valides dans leurs en-têtes de réponse, en plus d'être un code d'état pouvant être mis en cache.

Remarques :

• Pour les réponses qui ne sont pas mises en cache, les instructions de contrôle du cache ou d'autres en-têtes ne sont pas modifiés et sont transmis par proxy "en l'état".
• Les en-têtes Cache-Control et Expires des réponses peuvent être réduits à un seul champ Cache-Control. Par exemple, une réponse avec Cache-Control: public et Cache-Control: max-age=100 sur des lignes distinctes sera réduite à Cache-Control: public,max-age=100.
• Les réponses ne pouvant pas être mises en cache (les réponses qui ne seraient jamais mises en cache) ne sont pas comptabilisées en tant que Cache Egress pour ce qui est de la facturation.

Utiliser les modes cache

Les modes de cache vous permettent de configurer à quel moment Media CDN doit respecter les instructions de cache d'origine, mettre en cache les types de médias statiques et mettre en cache toutes les réponses de l'origine, quelles que soient les instructions définies.

Les modes de cache sont configurés au niveau de la route et, en association avec des remplacements TTL, vous permettent de configurer le comportement du cache en fonction de l'hôte, du chemin d'accès, des paramètres de requête et des en-têtes (tous les paramètres de requête pouvant être mis en correspondance).

• Par défaut, Media CDN utilise le mode de cache CACHE_ALL_STATIC, qui met automatiquement en cache les types de médias statiques courants pendant une heure (3 600 secondes), tout en donnant la priorité aux instructions de cache spécifiées par l'origine pour les réponses pouvant être mises en cache.
• Vous pouvez augmenter ou diminuer la valeur TTL de cache appliquée aux réponses sans définir de valeur TTL explicite (instruction max-age ou s-maxage) en définissant le champ cdnPolicy.defaultTtl sur une route.
• Pour éviter la mise en cache des réponses négatives plus longtemps que prévu, les codes d'état non-2xx (échecs) ne sont pas mis en cache conformément à leur Content-Type (type MIME) et n'ont pas la valeur TTL par défaut appliquée.

Les modes de cache disponibles, qui sont définis sur la valeur cdnPolicy.cacheMode de chaque route, sont indiqués dans le tableau suivant.

Types MIME de contenu statique

Le mode de cache CACHE_ALL_STATIC permet à Media CDN de mettre en cache automatiquement le contenu statique commun, tel que les éléments vidéo, audio, image et Web courants, en fonction du type MIME renvoyé dans l'en-tête de réponse HTTP Content-Type. Toutefois, quel que soit le type de contenu multimédia, Media CDN donne la priorité à tous les en-têtes Cache-Control ou Expires explicites dans la réponse de l'origine.

Le tableau suivant répertorie les types MIME pouvant être mis en cache automatiquement avec le mode de cache CACHE_ALL_STATIC.

Les réponses ne sont pas automatiquement mises en cache s'il n'y a pas d'en-tête de réponse Content-Type avec une valeur correspondant aux valeurs suivantes. Vous devez vous assurer que la réponse définit une instruction de cache valide ou que vous utilisez le mode de cache FORCE_CACHE_ALL pour mettre les réponses en cache sans condition.

Veuillez noter les points suivants :

• Le logiciel serveur Web d'origine doit définir le paramètre Content-Type pour chaque réponse. De nombreux serveurs Web définissent automatiquement l'en-tête Content-Type, y compris NGINX, Varnish et Apache.
• Cloud Storage définit l'en-tête Content-Type automatiquement lors de l'importation lorsque vous utilisez la console Google Cloud ou gcloud CLI pour importer des contenus.
• Cloud Storage fournit toujours un en-tête Cache-Control à Media CDN. Si aucune valeur n'est choisie explicitement, une valeur par défaut est envoyée. Par conséquent, toutes les réponses Cloud Storage réussies sont mises en cache selon les valeurs par défaut de Cloud Storage, sauf si vous ajustez explicitement les métadonnées de contrôle de la mise en cache pour les objets dans Cloud Storage ou si vous utilisez le mode FORCE_CACHE_ALL pour remplacer les valeurs envoyées par Cloud Storage.

Si une réponse peut être mise en cache sur la base de son type MIME, mais qu'elle comporte une directive de réponse Cache-Control égale à private ou no-store, ou un en-tête Set-Cookie, elle n'est pas mise en cache.

Les autres types de médias, tels que HTML (text/html) et JSON (application/json), ne sont pas mis en cache par défaut. Ces types de réponses sont généralement dynamiques (par utilisateur) et ne sont pas adaptés à l'architecture de Media CDN. Nous vous recommandons d'utiliser Cloud CDN pour diffuser les éléments Web et pour mettre en cache les réponses de l'API.

Configurer les valeurs TTL de cache

Les remplacements TTL ("Time To Live") vous permettent de définir des valeurs TTL par défaut pour le contenu mis en cache et de remplacer les valeurs TTL définies dans les instructions de contrôle de cache max-age et s-maxage (ou les en-têtes Expires) de vos origines.

Les valeurs TTL, qu'elles soient définies par des remplacements ou à l'aide d'une instruction de cache, sont optimistes. Tout contenu rarement consulté ou peu populaire peut être évincé du cache avant que la valeur TTL ne soit atteinte.

Le tableau suivant présente trois paramètres TTL.

Si vous définissez une valeur TTL sur zéro (0 seconde), chaque requête est revalidée avec l'origine avant la diffusion d'une réponse, ce qui augmente la charge sur l'origine si elle est définie de manière trop large.

Lorsque le mode de cache est défini sur Use Origin Headers, les paramètres TTL ne peuvent pas être configurés, car Media CDN s'appuie sur l'origine pour contrôler le comportement.

Remarques :

• La valeur TTL maximale doit toujours être supérieure (ou égale) à la valeur TTL par défaut.
• La valeur TTL du client doit toujours être inférieure (ou égale) à la valeur TTL maximale.
• Lorsque Media CDN ignore une valeur TTL d'origine, l'en-tête Cache-Control du client reflète également cette valeur.
• Si l'origine définit un en-tête Expires et que Media CDN remplace la valeur TTL effective (en fonction de l'horodatage), l'en-tête Expires est remplacé par un en-tête Cache-Control dans la réponse en aval envoyée au client.

Cache négatif

Le cache négatif définit la façon dont les codes d'état HTTP d'échec (autres que 2xx) sont mis en cache par Media CDN.

Cela vous permet de mettre en cache les réponses d'erreur telles que les redirections (HTTP 301 et 308) et les pages introuvables (HTTP 404) plus près des utilisateurs, et aussi de réduire la charge sur l'origine si la réponse est peu susceptible de changer et peut être mis en cache.

Par défaut, le cache négatif est désactivé. Le tableau suivant indique les valeurs par défaut pour chaque code d'état lorsque le cache négatif est activé et que negativeCachingPolicy n'est pas utilisé.

L'ensemble de codes de cache négatif par défaut correspond aux codes d'état pouvant être mis en cache de façon heuristique décrits dans le document HTTP RFC 9110, avec les exceptions suivantes:

• Le code HTTP 414 (URI trop long) n'est pas compatible avec la mise en cache, afin d'éviter l'empoisonnement du cache.
• Le code HTTP 451 (non disponible pour des raisons juridiques) est compatible avec la mise en cache, comme décrit dans le document HTTP RFC 7725.

Si vous devez configurer vos propres valeurs TTL par code d'état et remplacer le comportement par défaut, vous pouvez configurer un cdnPolicy.negativeCachingPolicy. Cela vous permet de définir la valeur TTL pour n'importe lequel des codes d'état autorisés par Media CDN : 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451, 500, 501, 502, 503 et 504.

Par exemple, pour définir une valeur TTL courte de 5 secondes pour les réponses HTTP 404 (page introuvable), et une valeur TTL de 10 secondes pour les réponses HTTP 405 (méthode non autorisée), utilisez la définition YAML suivante pour chaque route applicable :

cdnPolicy:
  negativeCaching: true
  negativeCachingPolicy:
    "404": 5s
    "405": 10s
  # other status codes to apply TTLs for

Pour éviter l'empoisonnement du cache, nous vous déconseillons d'activer la mise en cache pour les codes d'état HTTP 400 (requête incorrecte) ou HTTP 403 (interdit). Assurez-vous que votre serveur d'origine renvoie l'un de ces codes lorsqu'il examine uniquement les composants de la requête inclus dans la clé de cache. L'empoisonnement du cache peut se produire, par exemple, lorsque le serveur d'origine répond par une erreur HTTP 403 en l'absence d'un en-tête Authorization correct. Dans ce cas, la mise en cache de la réponse d'erreur HTTP 403 implique que Media CDN diffuse la réponse d'erreur HTTP 403 à toutes les requêtes suivantes jusqu'à ce que la valeur TTL expire, même si ces requêtes disposent d'un en-tête Authorization correct.

Pour désactiver le cache négatif, procédez comme suit :

• Pour désactiver le comportement de cache négatif par défaut, définissez cdnPolicy.negativeCaching: false sur une route. Notez que les réponses issues de l'origine qui incluent des instructions de cache valides et des codes d'état pouvant être mis en cache sont systématiquement mises en cache.
• Pour empêcher la mise en cache négatif pour un code d'état spécifique, tout en respectant les instructions de cache de l'origine, omettez le code d'état (cdnPolicy.negativeCachingPolicy[].code) dans votre définition negativeCachingPolicy.
• Pour ignorer explicitement les instructions de cache de l'origine pour un code d'état spécifique, définissez cdnPolicy.negativeCachingPolicy[].ttl sur 0 (zéro) pour ce code d'état.

Remarques :

• Lorsque negativeCaching est activé sur une route et qu'une réponse définit des instructions de cache valides, les instructions de cache dans la réponse sont prioritaires.
• Si vous configurez une valeur negativeCachingPolicy explicite et qu'une valeur TTL est définie pour le code d'état donné, la valeur TTL définie dans la stratégie est systématiquement utilisée.
• La valeur maximale d'une valeur TTL définie par negativeCachingPolicy est de 1 800 secondes (30 minutes), mais les instructions de cache d'origine avec une valeur TTL supérieure sont respectées.
• Si le mode de cache est configuré en tant que FORCE_CACHE_ALL, les instructions d'origine sont ignorées dans tous les cas.

Instructions pour le contrôle du cache

Le comportement du CDN multimédia par rapport aux directives Cache-Control est défini ici.

Si l'instruction n'est pas applicable à une requête ou à une réponse, comme only-if-cached (une instruction réservée aux clients), la valeur "N/A" est indiquée dans cette colonne.

Dans la mesure du possible, Media CDN est conforme à la norme RFC (RFC 7234 HTTP), mais préfère optimiser le déchargement du cache et minimiser l'impact que les clients peuvent avoir sur le taux de succès et la charge d'origine globale.

Pour les réponses qui utilisent l'en-tête HTTP/1.1 Expires, les éléments suivants s'appliquent :

• La valeur de l'en-tête Expires doit être une date HTTP valide telle que définie dans le document RFC 7231.
• Une date passée, une date non valide ou une valeur 0 indique que le contenu a déjà expiré et qu'il nécessite une nouvelle validation.
• Media CDN ignore l'en-tête Expires si un en-tête Cache-Control est présent dans la réponse.

L'en-tête HTTP/1.0 Pragma, s'il est présent dans une réponse, est ignoré et transmis au client en l'état.

Clés de cache

Vous pouvez réduire le nombre de fois où Media CDN doit contacter votre origine en prenant en compte les éléments qui identifient une requête de manière unique et en supprimant les composants qui changent souvent entre les requêtes. Le terme "clé de cache" est souvent utilisé pour désigner l'ensemble des composants de requête.

Les sections suivantes expliquent comment configurer des clés de cache.

Composants de la clé du cache

Une clé de cache correspond à l'ensemble des paramètres de requête (tels que l'hôte, le chemin d'accès et les paramètres de requête) qui référencent un objet mis en cache.

Par défaut, les clés de cache des services de cache périphérique incluent l'hôte, le chemin d'accès et les paramètres de requête de la requête. De plus, ces clés sont limitées à un EdgeCacheService spécifique.

Veuillez noter les points suivants :

• Les clés de cache ne sont pas associées à une origine configurée, ce qui vous permet de mettre à jour une configuration d'origine (ou de la remplacer complètement) sans risque de "vider" le cache (par exemple, lors de la migration du stockage d'origine entre différents fournisseurs).
• Les clés de cache sont limitées à un EdgeCacheService. Différents EdgeCacheServices ont des espaces de noms de cache différents, ce qui empêche la mise en cache accidentelle d'objets entre des environnements de production, de préproduction et de test, même si l'hôte, le chemin d'accès ou d'autres composants de clé de cache correspondent. La suppression d'un EdgeCacheService invalide effectivement tous les objets mis en cache pour ce service.
• Les clés de cache ne sont pas limitées à une route individuelle. Plusieurs routes peuvent faire référence à la même clé de cache, en particulier si ces routes sont mises en correspondance avec des composants qui ne sont pas inclus dans la clé de cache, tels que des en-têtes de requête ou des paramètres exclus. Cela peut être utile si vous souhaitez que plusieurs routes partagent le même cache, mais renvoient des en-têtes de réponse ou une configuration CORS différents.
• Les clés de cache n'incluent pas la configuration de réécriture d'URL. Par exemple, une clé de cache est basée sur la requête destinée à l'utilisateur plutôt que sur la requête "réécrite" finale.
• Lorsque les requêtes signées sont configurées sur une route, les attributs signés ne sont pas inclus dans la clé de cache. La requête est traitée comme si les paramètres de requête (signés) ou le composant de chemin, commençant par edge-cache-token et se terminant au séparateur de chemin ("/"), ne faisait pas partie de l'URL.

Inclure ou exclure des paramètres de requête

Vous pouvez inclure ou exclure des paramètres de requête spécifiques dans une clé de cache en ajoutant le nom du paramètre à la configuration de clé de cache includedQueryParameters ou excludedQueryParameters sur une route donnée.

Par exemple, pour inclure les paramètres de requête contentID et country et ignorer toutes les autres dans la clé de cache :

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 86400s
  cacheKeyPolicy:
    includedQueryParameters: ["contentID", "country"]

Veillez à inclure les paramètres de requête qui identifient de manière unique le contenu et à exclure ceux qui ne le font pas. Par exemple, excluez les paramètres de requête d'analyse et les ID de session de lecture ou autres paramètres qui ne sont propres qu'au client. Inclure plus de paramètres de requête que nécessaire peut réduire le taux de succès de mise en cache.

Au lieu de spécifier les paramètres à inclure dans la clé de cache, vous pouvez également choisir les paramètres à exclure de la clé de cache. Par exemple, pour exclure de la clé de cache les informations d'ID de lecture et d'horodatage spécifiques au client, configurez les éléments suivants :

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 86400s
  cacheKeyPolicy:
    excludedQueryParameters: ["playback-id", "timestamp"]

Pour une route donnée, vous pouvez spécifier l'une des options includedQueryParameters ou excludedQueryParameters.

Si les paramètres de requête ne sont jamais utilisés pour identifier du contenu de manière unique entre les requêtes, vous pouvez supprimer tous les paramètres de requête de la clé de cache pour une route. Pour ce faire, définissez excludeQueryString sur true, comme suit :

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 3600s
  cacheKeyPolicy:
    excludeQueryString: true

Si les requêtes signées sont activées sur une route, les paramètres de requête utilisés pour la signature ne sont pas inclus dans la chaîne de requête et sont ignorés s'ils sont inclus. L'inclusion des paramètres signés dans la clé de cache rend chaque requête utilisateur unique, ce qui implique que chaque requête doit être desservie directement par l'origine.

Tri des paramètres de requête

Les paramètres de requête (chaînes de requête) sont triés par défaut afin d'améliorer le taux de succès de mise en cache, car les clients peuvent réorganiser les paramètres ou demander un même objet mis en cache avec un ordre de paramètres de requête différent.

Par exemple, les paramètres de requête b=world&a=hello&z=zulu&p=paris et p=paris&a=hello&z=zulu&b=world sont triés comme a=hello&b=world&p=paris&z=zulu avant de dériver la clé de cache. Cela permet aux deux requêtes de mapper le même objet mis en cache, évitant ainsi à l'origine de traiter une requête inutile (et la réponse associée).

S'il existe plusieurs instances d'une clé de paramètre de requête, chacune avec des valeurs distinctes, les paramètres sont triés en fonction de leur valeur complète (par exemple, a=hello est trié avant a=world). Le tri ne peut pas être désactivé.

Inclure des en-têtes

Les noms d'en-têtes ne sont pas sensibles à la casse et sont convertis en minuscules par Media CDN.

Les en-têtes suivants ne peuvent pas être inclus dans la clé de cache :

• Tout en-tête commençant par access-control-
• Tout en-tête commençant par sec-fetch-
• Tout en-tête commençant par x-amz-
• Tout en-tête commençant par x-goog-
• Tout en-tête commençant par x-media-cdn-
• accept-encoding
• accept
• authorization
• cdn-loop
• connection
• content-md5
• content-type
• cookie
• date
• forwarded
• from
• host
• if-match
• if-modified-since
• if-none-match
• origin
• proxy-authorization
• range
• referer
• referrer
• user-agent
• want-digest
• x-csrf-token
• x-csrftoken
• x-forwarded-for

Pour inclure la méthode HTTP dans la clé de cache, utilisez le nom d'en-tête spécial :method.

Inclure des cookies

Les noms de cookies sont sensibles à la casse.

Les cookies commençant par edge-cache- dans n'importe quelle variante de lettres majuscules ou minuscules ne peuvent pas être utilisés dans la clé de cache.

Revalidation, éviction et expiration

Les réseaux de diffusion de contenu, y compris Media CDN, mettent en cache le contenu le plus populaire aussi proche que possible des utilisateurs.

Le stockage étendu de Media CDN et la protection d'origine limitent le besoin d'évincer le contenu, même peu populaire. Tout contenu consulté peu de fois chaque jour peut finir par être évincé.

• Les réponses mises en cache qui atteignent leur valeur TTL configurée peuvent ne pas être immédiatement supprimées. Pour le contenu populaire, Media CDN revalide que la réponse mise en cache est bien la dernière version en envoyant une requête HEAD à l'origine pour confirmer que les en-têtes n'ont pas changé. Dans certains cas, Media CDN envoie plutôt une requête à l'origine avec l'un ou les deux en-têtes de requête suivants : If-None-Match et If-Modified-Since. Dans ce cas, les origines correctement configurées doivent renvoyer une réponse HTTP 304 (Non modifié), sans les octets de corps, si le cache dispose de la "dernière" copie de cette réponse.
• Les réponses qui définissent une instruction de cache max-age ou s-maxage, ou qui utilisent un remplacement TTL pour spécifier une valeur TTL élevée (par exemple, 30 jours), peuvent ne pas être stockées dans le cache pour la valeur TTL complète. Rien ne garantit qu'un objet sera stocké dans le cache pendant toute la durée, en particulier s'il n'est que rarement consulté.

Si vous constatez un taux d'éviction élevé, vous devez vérifier que vous avez bien configuré vos clés de cache pour exclure les paramètres qui n'identifient pas une réponse de façon unique.

Autres points à noter

Les considérations suivantes peuvent également s'appliquer au cache.

En-têtes Vary

L'en-tête Vary indique que la réponse varie en fonction des en-têtes de requête du client. Si un en-tête Vary est présent dans la réponse, Media CDN ne le met pas en cache, sauf si l'en-tête spécifie l'un des en-têtes configurés en tant que paramètre de clé de cache ou l'une des valeurs suivantes:

• Accept (Accepté) : indique les types de contenu multimédia acceptés par le client.
• Accept-Encoding (codage accepté) : indique les types de compression acceptés par le client.
• Available-Dictionary:permet de fournir le hachage d'un dictionnaire disponible pour la compression.
• Origin/X-Origin (origine/X-Origin) : généralement utilisé pour le Cross-Origin Resource Sharing.
• X-Goog-Allowed-Resources::compatible avec la restriction d'organisation Google Cloud
• Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site::permet de récupérer les en-têtes de requête de métadonnées

Media CDN met en cache les réponses incluant un en-tête Vary en utilisant la valeur de l'en-tête comme élément de clé de cache. Si l'en-tête Vary de la réponse comporte plusieurs valeurs, celles-ci sont triées de façon lexicographique pour garantir que la clé de cache est déterministe.

Media CDN peut mettre en cache jusqu'à 100 variantes pour une clé de cache donnée. Au-delà de cette limite, Media CDN évince les variantes du cache de manière aléatoire. Lorsque vous invalidez explicitement le cache pour une URL ou un tag de cache donné, toutes les variantes sont invalidées.

Contourner le cache

Vous pouvez configurer le mode de cache BYPASS_CACHE sur une route pour contourner intentionnellement le cache lors du traitement des requêtes correspondantes. Cela peut être utile si vous devez contourner le cache pour une petite partie du trafic non critique ou pour déboguer la connectivité d'origine.

Pour les cas où vous devez diffuser des réponses dynamiques, telles que des backends d'API, nous vous recommandons de configurer un équilibreur de charge d'application externe.

En règle générale, il est recommandé de limiter l'utilisation de cette méthode aux scénarios de débogage afin d'éviter toute charge d'origine involontaire. Le trafic sortant en cas de contournement du cache est facturé aux tarifs de sortie Internet.

Invalidation de cache

Voir invalidation de cache.

Requêtes de plage d'octets

Media CDN accepte les requêtes de plage HTTP en une seule partie telles que définies dans la norme RFC 7233.

En outre, Media CDN utilise également les requêtes de plage pour récupérer des réponses plus volumineuses à partir de l'origine. Cela permet à Media CDN de mettre en cache des fragments de façon individuelle, ce qui ne nécessite pas de récupérer l'intégralité de l'objet en une fois pour sa mise en cache.

• Les objets de plus de 1 Mo sont récupérés sous forme de requêtes de plage d'octets ("fragments") de 2 Mo maximum chacun.
• Une réponse jusqu'à 1 Mo peut être récupérée sans compatibilité avec les plages d'octets au niveau de l'origine.
• Sans compatibilité avec les plages d'octets sur l'origine, les réponses plus volumineuses ne sont pas diffusées.

La compatibilité de l'origine avec les requêtes de plage d'octets est déterminée par les éléments suivants:

• Un code d'état HTTP 200 (OK) ou 206 (contenu partiel).
• Un en-tête de réponse Content-Length ou Content-Range valide.
• Un validateur de réponse (ETag ou Last-Modified).

Les requêtes de remplissage d'origine individuelle pour chaque "fragment" (plage d'octets) sont consignées en tant qu'entrées de journal distinctes et sont associées à leur requête client parent. Vous pouvez regrouper ces requêtes en faisant correspondre les requêtes sur jsonPayload.cacheKeyFingerprint.

Pour en savoir plus sur les éléments consignés, consultez la documentation de Cloud Logging.

Requêtes de plage ouverte

Media CDN accepte les requêtes Range ouvertes (par exemple, une requête avec Range: bytes=0-) qui maintiennent une requête ouverte jusqu'à ce que la réponse soit fermée par l'origine (par exemple, si l'origine a écrit tous les octets) ou atteigne son délai d'expiration.

Les plages d'octets ouvertes sont généralement utilisées par les clients demandant des segments HLS à faible latence : au moment de l'écriture de chaque fragment CMAF sur le réseau, le CDN peut mettre en cache le fragment et le diffuser aux clients.

Dans d'autres cas, par exemple lorsque l'interopératibilité avec DASH n'est pas requise, la playlist multimédia indique au lecteur quels octets représentent chaque fragment :

  #EXTINF:4.08,
  fs270.mp4
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=20000@0
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=23000@20000
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=18000@43000
  #EXT-X-PRELOAD-HINT:TYPE=PART,URI="fs271.mp4",BYTERANGE-START=61000

Vous pouvez configurer le temps d'attente de Media CDN entre les lectures à l'aide de la valeur de configuration EdgeCacheOrigin.timeouts.readTimeout. Cette valeur doit généralement être configurée sur un multiple (par exemple, deux fois) de votre durée cible.

Étape suivante

• Consultez la page Routage avancé.
• Découvrez comment vous connecter à différentes origines.
• Configurez des certificats TLS (SSL) pour votre service.
• Configurez des requêtes signées pour authentifier l'accès au contenu.