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 automatiquement en cache les types de contenus statiques avec une Valeur TTL par défaut de 3 600 s, 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 associées à un contrôle de cache no-store ou private ou celles 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 de mise en cache associées à 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 200, 203, 206, 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451, 500, 501, 502, 503 ou 504.
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 Directives de contrôle du cache.
En-têtes de réponse	Contient une instruction 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 d'une 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 dont la taille est supérieure à 1 Mio, une origine doit inclure les éléments suivants dans les en-têtes de réponse pour à la fois pour les requêtes HEAD et GET, sauf indication contraire:

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

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

Remarque :Petites réponses (moins de 1 Mio) pour lesquelles il manque l'ensemble complet des en-têtes listés précédemment peuvent être évincés du cache plus rapidement réponses.

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. Réponses pouvant être mises en cache, mais qui correspondent "impossible de mettre en cache" ne sont pas mis en cache.

Attribut HTTP	Exigence
Code d'état	Un code d'état autre que ceux définis comme pouvant être mis en cache, par exemple 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 l'état de l'origine. La mise en cache de ces réponses empoisonnement » dans les cas où un "mauvais" événement déclenché par l'utilisateur est mise en cache pendant tous les utilisateurs.
En-têtes de requête	Pour les requêtes comportant une requête Authorization les réponses doivent inclure un Cache-Control public à mettre en cache. Une instruction no-store de la requête entraîne la réponse ne doit pas être mise en cache. Pour en savoir plus, consultez la section Instructions de contrôle de 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 Dans CACHE_ALL_STATIC ou USE_ORIGIN_HEADERS, dispose d'un no-store ou la directive de contrôle du cache private.
Taille de la réponse	Supérieure à 100 Gio.

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 envoyées par proxy telles quelles.
• Le mode cache FORCE_CACHE_ALL met en cache toutes les réponses sans condition, soumis aux exigences de non-mise en cache mentionnées précédemment.
• Le mode cache USE_ORIGIN_HEADERS nécessite que les réponses soient définies de directives de cache valides dans leurs en-têtes de réponse dans en plus d'être un code d'état pouvant être mis en cache.

Remarques :

• Les réponses qui ne sont pas mises en cache n'ont pas d'instructions de contrôle du cache les autres en-têtes ont été modifiés et sont transmis par proxy tels quels.
• 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 sera réduit 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 en tant que Cache Egress du point de vue de la facturation.

Utiliser les modes cache

Les modes de cache vous permettent de configurer quand Media CDN doit respecter les directives 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 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 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 de mettre en cache les réponses qui n'ont pas abouti plus longtemps que prévu, les codes d'état non-2xx (échec) ne sont pas mis en cache conformément à leurs Content-Type (type MIME) et ne disposent pas de la valeur TTL par défaut appliquée.

Remarque :Pour configurer la mise en cache des réponses autres que 2xx, telles que les redirections (3xx), consultez la section Mise en cache négative.

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

Mode de 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 conditions requises, consultez 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 comportent une directive 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, l'audio, les images et les éléments Web courants, tels que défini par le type MIME dans la réponse Content-Type en-tête.
FORCE_CACHE_ALL	Met en cache les réponses réussies sans condition, en ignorant tout cache définies par l'origine. Veillez à ne pas diffuser de contenu privé propre à l'utilisateur (comme du contenu HTML dynamique ou les réponses de l'API) avec ce mode 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 en cache correspond à cette clé de cache. Nous vous recommandons de n'utiliser cette option 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 met automatiquement en cache les contenus statiques courants, tels que des vidéos, de l'audio, des images, des éléments Web courants en fonction du type MIME renvoyé dans le protocole HTTP Content-Type en-tête de réponse. Toutefois, quel que soit le type de support, Media CDN donne la priorité aux en-têtes Cache-Control ou Expires explicites dans l'origine de réponse.

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

Les réponses ne sont pas automatiquement mises en cache si elles ne comportent pas de Content-Type en-tête de réponse dont la valeur correspond aux valeurs suivantes. Vous devez vous assurer que la réponse définit une directive de cache valide ; ou vous devez utiliser le mode de cache FORCE_CACHE_ALL pour mettre en cache sans condition des réponses.

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 la CLI gcloud pour importer des contenus.
• 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.

Important :Autres types de supports, 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 de valeur TTL (Time To Live) vous permettent de définir des valeurs TTL par défaut pour le contenu mis en cache et remplacer les valeurs TTL définies dans les commandes de cache max-age et s-maxage (ou en-têtes Expires) définies par vos origines.

Les TTL, qu'elles soient définies par des remplacements ou à l'aide d'une directive de cache, sont optimiste. 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)	La valeur TTL à définir lorsque l'origine n'a pas spécifié de max-age ou un en-tête s-maxage. Si l'origine spécifie un en-tête s-maxage, il est utilisé à la place. de la valeur TTL par défaut. Lorsque vous utilisez FORCE_CACHE_ALL pour mettre en cache l'ensemble des réponses de manière inconditionnelle, la valeur TTL par défaut est utilisée pour définir la valeur TTL du cache. Toutes les autres valeurs et les directives 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. Valeurs supérieures à sont plafonné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, la valeur TTL maximale autorisée dans le flux en aval (destinée au client) si elle doit être différente des autres valeurs TTL valeurs.	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 et augmente la charge vers l'origine si de façon 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 remplace une valeur TTL d'origine, le Cache-Control 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

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 introuvables (HTTP 404) plus proches des utilisateurs, et réduisent se charger plus largement si la réponse est peu susceptible de changer et peut être mise en cache.

Remarque :Pour configurer la mise en cache des réponses de réussite (codes d'état 2xx), consultez modes 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 par défaut de codes de mise en cache négative correspond à l'ensemble heuristique de mise en cache pouvant être mis en cache. codes d'état décrits dans HTTP RFC 9110, à quelques exceptions près:

• 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 Définissez 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, 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

Important :Lorsque vous configurez un negativeCachingPolicy, spécifiez tous les codes d'état (et leurs valeurs TTL) que vous souhaitez mettre en cache. Les valeurs TTL par défaut (décrites sur cette page) ne s'appliquent pas lorsqu'une règle existe.

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

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, comme only-if-cached (une instruction réservée aux clients), la valeur "N/A" est indiquée dans cette colonne.

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 nécessite avec l'origine avant de pouvoir la diffuser. Vous pouvez le remplacer pour chaque route à l'aide du paramètre Mode 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	N/A	Une réponse avec la directive public est mise en cache si la la réponse est considérée comme pouvant être mise en cache dans son ensemble et la réponse comporte une instruction max-age ou s-maxage, bien. Lorsque vous utilisez le cache CACHE_ALL_STATIC ou FORCE_CACHE_ALL, ce n'est pas obligatoire.
private	N/A	Une réponse avec la directive private n'est pas mise en cache par Media CDN, même si la réponse est autrement prise en compte pouvant être mises en cache. Il est toujours possible que les clients (tels que les navigateurs) mette en cache le résultat. Vous pouvez le remplacer pour chaque route à l'aide du paramètre Mode 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 la directive max-age est mise en cache jusqu'à la SECONDS définie.
s-maxage=SECONDS	N/A	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 à des fins de 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.	N/A
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 demande.	N/A
stale-while-revalidate=SECONDS	N/A	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	N/A	Une réponse avec must-revalidate est revalidée avec le serveur d'origine après son expiration.
proxy-revalidate	N/A	Une réponse avec proxy-revalidate est revalidée avec le serveur d'origine après son expiration.
immutable	N/A	Aucun effet. Cette instruction est transmise au client dans la réponse.
no-transform	N/A	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.	N/A

Dans la mesure du possible, Media CDN est conforme à la RFC (HTTP RFC 7234), mais privilégie optimiser le déchargement du cache et minimiser l'impact que les clients peuvent avoir sur le taux de hits 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 la valeur 0 indique que le contenu a déjà expiré et doit être revalidé.
• Media CDN ignore l'en-tête Expires si une valeur 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 directement 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	Yes	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	Yes	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 réponses différentes, 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 remplacer complètement l'origine) sans risque de "vidage" dans le cache (par exemple, lors de la migration du stockage d'origine entre des fournisseurs).
• Les clés de cache sont limitées à un EdgeCacheService. Différents EdgeCacheServices ont espaces de noms de cache différents, ce qui vous évite de mettre accidentellement en cache 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. Supprimer une EdgeCacheService invalide tous les objets mis en cache pour 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 des requêtes signées sont configurées sur une route, les attributs signés sont non incluses 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 les contenus populaires, Media CDN vérifie à nouveau que la réponse mise en cache est la dernière version en émettant une HEAD à l'origine pour confirmer que les en-têtes ont n'a pas été modifiée. Dans certains cas, Media CDN remplace envoie une requête à l'origine avec l'un des en-têtes de requête suivants, ou les deux: If-None-Match et If-Modified-Since. Dans ce cas, les origines correctement configurées doivent renvoyer un code d'état HTTP 304 (Non modifié). sans les octets du corps, si le cache possède la valeur "latest" copie de cette réponse.
• Réponses qui définissent un cache max-age ou s-maxage ou qui utilisent une 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és vos clés de cache pour exclure les paramètres qui n'identifient pas de manière unique de réponse.

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:généralement utilisé pour le Cross-Origin Resource Sharing.
• X-Goog-Allowed-Resources::prend en charge les organisations Google Cloud restriction
• Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site::utilisé pour récupérer la requête de métadonnées. en-têtes

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 (par exemple, des backends d'API), nous recommandent 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 les fragments de cache individuellement, et ne nécessite pas la récupération de l'objet entier peuvent être mises en cache en même temps.

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

Requêtes de remplissage d'origine individuelles pour chaque "fragment" (plage d'octets) sont consignées en tant que des entrées de journal discrètes et 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 données consignées, consultez les Documentation 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.

Remarque : Votre infrastructure d'origine doit également prendre en charge les objets en streaming en réponse aux requêtes Range ouvertes avant qu'elles ne soient entièrement écrites. Certaines origines, comme Cloud Storage et Amazon S3, sont compatibles avec les plages ouvertes mais ne diffuse les objets qu'une fois qu'ils ont été entièrement écrits.

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 en utilisant 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 section 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.