Cette page traite du cache intégré Cloud Storage. Cloud Storage est également compatible avec les CDN tiers.
Présentation
Lorsqu'un objet Cloud Storage est mis en cache, des copies de ses données sont stockées dans un cache Google ou Internet, ce qui permet de diffuser votre objet plus rapidement dans les futures requêtes. Bien que la mise en cache puisse améliorer les performances, vous risquez également de diffuser du contenu obsolète si vous mettez à jour votre objet, mais qu'un cache continue à diffuser l'ancienne version de l'objet.
Mise en cache intégrée pour Cloud Storage
Cloud Storage peut se comporter comme un réseau de diffusion de contenu (CDN) sans intervention de votre part, car les données d'un objet sont mises en cache dans le réseau Cloud Storage si ses métadonnées Cache-Control
sont définies pour autoriser le cache et que les critères suivants sont remplis:
- L'objet est accessible au public.
- L'objet n'est pas stocké dans un bucket pour lequel les paiements du demandeur sont activés et ne se trouve pas dans un périmètre de service de cloud privé virtuel.
- L'objet n'est pas chiffré à l'aide de clés de chiffrement gérées par le client ni de clés de chiffrement fournies par le client.
Cloud Storage respecte les valeurs standards pour Cache-Control
, telles que :
public
: l'objet peut être mis en cache.private
: l'objet ne sera pas mis en cache par Cloud Storage, mais il peut l'être dans le cache local du demandeur.no-cache
: l'objet peut être mis en cache, mais il ne peut pas être utilisé pour répondre aux requêtes futures, sauf s'il a été préalablement validé par Cloud Storage.no-store
: l'objet ne peut pas être mis en cache.max-age=TIME_IN_SECONDS
: durée pendant laquelle un objet peut être mis en cache avant d'être considéré comme obsolète. Vous pouvez définirmax-age
sur n'importe quelle durée. Les objets obsolètes ne sont plus diffusés à partir d'un cache, sauf dans certains cas.
Pour définir les métadonnées Cache-Control
d'un objet, consultez la section Modifier des métadonnées d'objets.
Comportement de la mise en cache intégrée avec les stratégies de refus IAM
Lorsqu'une stratégie de refus IAM au niveau de l'organisation limite l'accès en lecture à un objet à partir de l'identifiant principal allUsers
, la mise en cache intégrée est désactivée pour l'objet, même s'il existe une stratégie IAM au niveau du bucket qui accorde un accès en lecture à l'objet pour allUsers
.
Toutefois, si la stratégie de refus IAM ne limite que des utilisateurs individuels, la mise en cache intégrée reste activée pour l'objet.
Considérations sur les performances
Les performances peuvent être bien meilleures pour les objets pouvant être mis en cache en mode public. Pour désactiver la mise en cache d'un objet permettant de contrôler de nombreux clients, et ainsi fournir les données les plus récentes, procédez comme suit :
Envisagez plutôt de définir les métadonnées
Cache-Control
de l'objet surpublic
avec la valeurmax-age
comprise entre 15 et 60 secondes. La plupart des applications peuvent tolérer la présence d'un objet obsolète pendant quelques secondes, en échange d'améliorations de performances.Servez-vous de la valeur
Cache-Control: no-store
afin d'indiquer que l'objet ne doit pas être mis en cache pour les requêtes ultérieures dans n'importe quel cache.
Étapes suivantes
- Informez-vous sur les métadonnées
Cache-Control
. - Apprenez-en davantage sur les directives RFC
Cache-Control
.