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 directives de cache d'origine, telles que Cache-Control ou Expires, jusqu'à une valeur TTL maximale configurable.
    • Met automatiquement en cache les types de contenus statiques avec une valeur TTL par défaut de 3 600 secondes, en l'absence d'instructions de cache d'origine.
    • 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 qui comportent les instructions de contrôle du cache no-store ou private, ou qui ne peuvent 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 à respecter pour mettre en cache des réponses HTTP spécifiques. Les réponses GET et HEAD doivent respecter ces exigences.

Attribut HTTP Conditions requises
Code d'état Le code d'état de la réponse doit être l'un des suivants : 200, 203, 206, 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451, 500, 501, 502, 50.
Méthodes HTTP GET et HEAD
En-têtes de requête La plupart des directives de requête de mise en cache sont ignorées. Pour en savoir plus, consultez la section Instructions de contrôle du cache.
En-têtes de réponse

Contient une directive de mise en cache HTTP valide telle que Cache-Control: max-age=3600, public.

dispose d'un mode de cache qui met en cache ce contenu, ou comporte un en-tête Expires avec une date située dans le futur ;

Taille de la réponse Jusqu'à 100 Gio.

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 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.

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 qui peuvent être mises en cache, mais qui correspondent aux critères "ne pouvant pas être mises en cache" ne sont pas mises en cache.

Attribut HTTP Prérequis
Code d'état

Un code d'état autre que ceux définis comme pouvant être mis en cache, tels que HTTP 401, HTTP 412 ou HTTP 505.

Ces codes d'état sont généralement représentatifs des problèmes rencontrés par les clients et non de l'état d'origine. La mise en cache de ces réponses peut entraîner des scénarios d'"empoisonnement du cache" où une "mauvaise" réponse déclenchée par l'utilisateur est mise en cache pour tous les utilisateurs.

En-têtes de requête

Pour les requêtes comportant un en-tête de requête Authorization, les réponses doivent inclure une instruction Cache-Control public à mettre en cache.

L'ajout d'une instruction no-store à la requête empêche la mise en cache de la réponse. Pour en savoir plus, consultez la section Instructions de contrôle du cache.

En-têtes de réponse

Comporte un en-tête Set-Cookie.

Comporte un en-tête Vary autre que Accept, Accept-Encoding, Origin, X-Origin, X-Goog-Allowed-Resources, Sec-Fetch-Dest, Sec-Fetch-Mode ou Sec-Fetch-Site.

En mode CACHE_ALL_STATIC ou USE_ORIGIN_HEADERS, dispose d'une directive de contrôle du cache no-store ou private.

Taille de la réponse Supérieure à 100 Gio.

Ces règles s'appliquent en plus du mode de cache configuré. à savoir :

  • Lorsque le mode cache CACHE_ALL_STATIC est configuré, seules les réponses considérées comme du contenu statique ou les réponses comportant des instructions de cache valides dans leurs en-têtes de réponse sont mises en cache. Les autres réponses sont envoyées par proxy telles quelles.
  • Le mode cache FORCE_CACHE_ALL met en cache toutes les réponses sans condition, sous réserve des exigences d'incapacité à mettre en cache mentionné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'un code d'état pouvant être mis en cache.

Remarques :

  • Les instructions de contrôle du cache et les autres en-têtes ne sont pas modifiés pour les réponses qui ne sont pas mises en cache, et sont transmises telles quelles.
  • Les en-têtes Cache-Control et Expires des réponses peuvent être réduits dans un seul champ Cache-Control. Par exemple, une réponse contenant Cache-Control: public et Cache-Control: max-age=100 sur des lignes distinctes serait réduite sous la forme Cache-Control: public,max-age=100.
  • Les réponses ne pouvant pas être mises en cache (réponses qui ne seraient jamais mises en cache) ne sont pas comptabilisées comme Cache Egress du point de vue de la facturation.

Utiliser les modes cache

Les modes de cache vous permettent de définir quand Media CDN doit respecter les directives de cache d'origine, mettre en cache les types de contenus multimédias statiques et mettre en cache toutes les réponses de l'origine, quelles que soient les directives 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 contenus multimé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 non réussies pendant plus longtemps que prévu, les codes d'état autres que 2xx (échec) ne sont pas mis en cache en fonction de leur Content-Type (type MIME) et la valeur TTL par défaut n'est pas appliquée.

Les modes de cache disponibles, définis sur le cdnPolicy.cacheMode de chaque route, sont présentés dans le tableau suivant.

Mode cache Comportement
USE_ORIGIN_HEADERS Exige que les réponses issues de l'origine définissent des instructions de cache et des en-têtes de mise en cache valides. Pour obtenir la liste complète des exigences, consultez la section Réponses pouvant être mises en cache.
CACHE_ALL_STATIC

Met automatiquement en cache les réponses réussies avec du contenu statique, sauf si elles contiennent une instruction no-store ou private. La priorité est donnée aux instructions de mise en cache valides de l'origine.

Le contenu statique inclut les vidéos, les fichiers audio, les images et les éléments Web courants tels que définis par le type MIME dans l'en-tête de réponse Content-Type.

FORCE_CACHE_ALL

Met en cache les réponses réussies sans condition, en ignorant les instructions de cache définies par l'origine.

Assurez-vous de ne pas diffuser de contenu privé propre à l'utilisateur (comme les réponses HTML dynamiques ou d'API) lorsque ce mode est configuré.

BYPASS_CACHE

Toute requête correspondant à une route pour laquelle ce mode de cache est configuré contourne le cache, même si un objet mis en cache correspond à cette clé de cache.

Nous vous recommandons de n'utiliser ce service que pour le débogage, car Media CDN est conçu comme une infrastructure de cache à l'échelle mondiale et non comme un proxy à usage général.

Types MIME de contenu statique

Le mode de cache CACHE_ALL_STATIC permet à Media CDN de mettre automatiquement en cache le contenu statique courant, tel que des vidéos, de l'audio, des images et des éléments 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, Media CDN donne la priorité aux en-têtes Cache-Control ou Expires explicites dans la réponse d'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 si elles ne comportent pas d'en-tête de réponse Content-Type dont la valeur correspond aux valeurs suivantes. Vous devez vous assurer que la réponse définit une directive de cache valide ou utiliser le mode de cache FORCE_CACHE_ALL pour mettre en cache les réponses sans condition.

Catégorie Types MIME
Éléments Web text/css text/ecmascript text/javascript application/javascript
Polices Tout type de contenu correspondant à font/*
Images Tout type de contenu correspondant à image/*
Vidéos Tout type de contenu correspondant à video/*
Audio Tout type de contenu correspondant à audio/*
Types de documents formatés application/pdf and application/postscript

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 l'outil gsutil pour importer des contenus.
  • Si une réponse peut être mise en cache en fonction de son type MIME, mais qu'elle possède une instruction de réponse Cache-Control définie sur private ou no-store, ou un en-tête Set-Cookie, elle n'est pas mise en cache.

Configurer les valeurs TTL de cache

Les remplacements de valeur 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 directives de contrôle du cache max-age et s-maxage (ou les en-têtes Expires) définies par vos origines.

Les valeurs TTL, qu'elles soient définies par des remplacements ou à l'aide d'une directive 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.

Paramètre Par défaut Minimum Maximum Description Modes de cache applicables
Default TTL 1 heure
(3 600 secondes)
0 seconde 1 an
(31 536 000 secondes)

Valeur TTL à définir lorsque l'origine n'a pas spécifié d'en-tête max-age ou s-maxage.

Si l'origine spécifie un en-tête s-maxage, celui-ci est utilisé à la place de la valeur TTL par défaut.

Lorsque vous utilisez FORCE_CACHE_ALL pour mettre en cache toutes les réponses sans condition, la valeur TTL par défaut est utilisée pour définir la valeur TTL du cache. Toutes les autres valeurs et instructions sont ignorées.

CACHE_ALL_STATIC

FORCE_CACHE_ALL

Max TTL 1 jour
(86 400 secondes)
0 seconde 1 an
(31 536 000 secondes)
Pour les réponses pouvant être mises en cache, valeur TTL maximale autorisée. Les valeurs supérieures sont limitées à la valeur de maxTtl. CACHE_ALL_STATIC
Client TTL Non défini par défaut. 0 seconde 1 jour
(86 400 secondes)
Pour les réponses pouvant être mises en cache, valeur TTL maximale à autoriser dans la réponse en aval (côté client) si elle doit être différente des autres valeurs TTL.

CACHE_ALL_STATIC

FORCE_CACHE_ALL

La définition d'une valeur TTL sur zéro (0 seconde) entraîne la revalidation de chaque requête avec l'origine avant la diffusion d'une réponse. Elle augmente la charge vers l'origine si elle est définie trop largement.

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 piloter 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 remplace une valeur TTL d'origine, l'en-tête Cache-Control envoyé au 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

La mise en cache négative définit la manière dont les codes d'état HTTP qui échouent (ceux 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 réponses introuvables (HTTP 404) plus proches des utilisateurs, et de réduire davantage la charge de l'origine si la réponse est peu susceptible de changer et peut être mise en cache.

Par défaut, la mise en cache négative est désactivée. 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é.

Codes d'état Reason-phrase TTL
HTTP 300 Choix multiples 10 minutes
HTTP 301 et HTTP 308 Redirection permanente 10 minutes
HTTP 404 Introuvable 120 secondes
HTTP 405 Méthode introuvable 60 secondes
HTTP 410 Gone 120 secondes
HTTP 451 Inaccessible pour des raisons d'ordre juridique 120 secondes
HTTP 501 Non mise en oeuvre 60 secondes

L'ensemble de codes de mise en cache négative par défaut correspond aux codes d'état pouvant être mis en cache de manière 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 de n'importe quel code d'état autorisé par Media CDN : 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451, 500, 501, 502, 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 de Media CDN par rapport aux instructions Cache-Control est défini ici.

Si l'instruction n'est pas applicable à une requête ou à une réponse, telle que only-if-cached (instruction client uniquement), la colonne "N/A" est marquée comme "N/A".

Directive Requête Réponse
no-cache L'instruction de requête no-cache est ignorée pour empêcher les clients de lancer ou de forcer la revalidation dans l'origine.

Une réponse avec no-cache est mise en cache, mais elle doit être validée auprès de l'origine avant de pouvoir être diffusée.

Ce paramètre peut être ignoré pour chaque route à l'aide du mode de cache FORCE_CACHE_ALL.

no-store La réponse à une requête avec no-store n'est pas mise en cache.

Une réponse avec no-store n'est pas mise en cache.

Cette instruction peut être ignorée en fonction de la route à l'aide du mode de cache FORCE_CACHE_ALL.

public Non disponible

Une réponse avec l'instruction public est mise en cache si la réponse est considérée comme pouvant être mise en cache dans son ensemble et si elle contient une instruction max-age ou s-maxage.

Lorsque vous utilisez le cache CACHE_ALL_STATIC ou les modes FORCE_CACHE_ALL, ce n'est pas obligatoire.

private Non disponible

Une réponse avec l'instruction private n'est pas mise en cache par Media CDN, même si elle est considérée comme pouvant être mise en cache. Il est toujours possible que les clients (tels que les navigateurs) mette en cache le résultat.

Ce paramètre peut être ignoré pour chaque route à l'aide du mode de cache FORCE_CACHE_ALL.

Utilisez no-store pour empêcher toute mise en cache des réponses.

max-age=SECONDS L'instruction de requête max-age est ignorée. Une réponse mise en cache est renvoyée comme si cet en-tête n'était pas inclus dans la requête. Une réponse avec l'instruction max-age est mise en cache jusqu'à la valeur SECONDS définie.
s-maxage=SECONDS Non disponible

Une réponse avec l'instruction s-maxage est mise en cache jusqu'à la valeur SECONDS définie.

Si max-age et s-maxage sont tous deux présents, s-maxage est utilisé par le serveur.

Notez que s-max-age (deux traits d'union) n'est pas valide pour la mise en cache.

min-fresh=SECONDS L'instruction de requête min-fresh est ignorée. Une réponse mise en cache est renvoyée comme si cet en-tête n'était pas inclus dans la requête. Non disponible
max-stale=SECONDS

L'instruction de requête max-stale est ignorée.

Une réponse mise en cache est renvoyée comme si cet en-tête n'était pas inclus dans la requête.

Non disponible
stale-while-revalidate=SECONDS Non disponible Aucun effet. Cette instruction est transmise au client dans la réponse.
stale-if-error=SECONDS L'instruction de requête stale-if-error est ignorée. Une réponse mise en cache est renvoyée comme si cet en-tête n'était pas inclus dans la requête. Aucun effet. Cette instruction est transmise au client dans la réponse.
must-revalidate Non disponible

Une réponse comportant must-revalidate est revalidée avec le serveur d'origine après son expiration.

proxy-revalidate Non disponible

Une réponse comportant proxy-revalidate est revalidée avec le serveur d'origine après son expiration.

immutable Non disponible Aucun effet. Cette instruction est transmise au client dans la réponse.
no-transform Non disponible Aucune transformation n'est appliquée par Media CDN.
only-if-cached L'instruction de requête only-if-cached est ignorée. Une réponse mise en cache est renvoyée comme si cet en-tête n'était pas inclus dans la requête. Non disponible

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

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 valeur de date passée, une date non valide ou une valeur 0 indique que le contenu a déjà expiré et doit être revalidé.
  • 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 tel quel au client.

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.

Composant Inclus par défaut ? Détails
Protocole Non

Les requêtes via HTTP et HTTPS font référence au même objet mis en cache.

Si vous souhaitez renvoyer des réponses différentes aux requêtes HTTP et HTTPS, définissez cacheKeyPolicy.includeProtocol sur "true" sur les routes associées.

Organisateur Oui

Différents hôtes ne font pas référence aux mêmes objets mis en cache.

Si plusieurs noms d'hôte sont dirigés vers le même EdgeCacheService et qu'ils diffusent le même contenu, définissez cdnPolicy.excludeHost sur "true".

Chemin d'accès Oui Toujours inclus dans la clé de cache et impossible à supprimer. Le chemin d'accès est la représentation minimale d'un objet dans le cache.
Paramètres de requête Oui

Si les paramètres de requête ne font pas la distinction entre les différentes réponses, définissez cacheKeyPolicy.excludeQueryString sur "true".

Si seuls certains paramètres de requête doivent être inclus dans une clé de cache, définissez includedQueryParameters ou excludedQueryParameters, le cas échéant.

En-têtes Non

Définissez cacheKeyPolicy.includedHeaderNames avec les noms des en-têtes à inclure dans la clé de cache.

La spécification de plusieurs en-têtes combinés pour obtenir une large plage de valeurs (par exemple, des valeurs d'en-tête combinées n'identifiant qu'un seul utilisateur) réduit considérablement le taux de succès de mise en cache et peut entraîner un taux d'éviction plus élevé ainsi qu'une baisse des performances.

Cookies Non

Définissez cacheKeyPolicy.includedCookieNames avec les noms des cookies à inclure dans la clé de cache.

La spécification de plusieurs cookies combinés pour obtenir une large plage de valeurs (par exemple, des valeurs de cookies combinées n'identifiant qu'un seul utilisateur) réduit considérablement le taux de succès de mise en cache et peut entraîner un taux d'éviction plus élevé ainsi qu'une baisse des performances.

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 remplacer complètement l'origine) sans risque de "vider" le cache (par exemple, lors de la migration du stockage de l'origine entre les fournisseurs).
  • Les clés de cache sont limitées à un EdgeCacheService. Chaque EdgeCacheServices possède des espaces de noms de cache différents, ce qui vous évite de mettre accidentellement en cache des objets entre les environnements de production, de préproduction et d'autres environnements 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 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 de configuration de réécriture d'URL. Par exemple, une clé de cache est basée sur la requête visible par l'utilisateur et non sur la requête "réécrite" finale.
  • Lorsque des 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 vérifie à nouveau que la réponse mise en cache est 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 à la place une requête à l'origine avec l'un des en-têtes de requête If-None-Match et If-Modified-Since, ou les deux. Dans ce cas, les origines correctement configurées doivent renvoyer une réponse HTTP 304 (non modifié), sans les octets du corps, si le cache dispose de la copie "dernière" de cette réponse.
  • Les réponses qui définissent une directive de cache max-age ou s-maxage, ou qui utilisent un remplacement de la valeur 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 élevé d'évictions, assurez-vous d'avoir configuré vos clés de cache pour exclure les paramètres qui n'identifient pas de manière unique une réponse.

Autres points à noter

Les considérations suivantes peuvent également s'appliquer concernant la mise en 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 (Accepter) : permet d'indiquer les types de supports acceptés par le client.
  • Accept-Encoding (codage accepté) : indique les types de compression acceptés par le client.
  • Available-Dictionary:utilisé pour fournir le hachage d'un dictionnaire disponible pour la compression
  • Origin/X-Origin:généralement utilisé pour le Cross-Origin Resource Sharing.
  • X-Goog-Allowed-Resources::accepte les restrictions d'organisation Google Cloud.
  • Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site::utilisé pour extraire 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 le document RFC 7233.

De plus, Media CDN utilise également des requêtes de plage pour récupérer des réponses plus importantes à partir de l'origine. Cela permet à Media CDN de mettre en cache les fragments individuellement, sans que la mise en cache de l'objet entier ne soit nécessaire.

  • Les objets d'une taille supérieure à 1 Mio sont récupérés sous forme de requêtes de plage d'octets ("segments") d'une taille maximale de 2 Mio chacun.
  • Des réponses jusqu'à 1 Mio peuvent être récupérées sans prise en charge des 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 prise en charge de l'origine pour les requêtes de plage d'octets est déterminée par les éléments suivants:

  • Code d'état HTTP 200 (OK) ou 206 (Contenu partiel).
  • Un en-tête de réponse Content-Length ou Content-Range valide.
  • Un outil de validation des réponses (ETag ou Last-Modified).

Les requêtes de remplissage provenant de l'origine individuelle pour chaque "fragment" (plage d'octets) sont consignées en tant qu'entrées de journal discrètes et associées à leur requête client parente. 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 la maintiennent ouverte sur l'origine jusqu'à ce que la réponse soit fermée par l'origine (par exemple, si l'origine écrit tous les octets sur le réseau) ou qu'elle expire.

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 délai 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.

Étapes suivantes