Résoudre les problèmes liés à Cloud CDN

Découvrez les étapes de dépannage pouvant être utiles si vous rencontrez les problèmes suivants avec Cloud CDN.

Si le problème que vous rencontrez est lié aux backends externes, consultez également la section Résoudre les problèmes liés aux backends externes et aux NEG Internet.

Problèmes d'ordre général et solutions

Les réponses ne sont pas mises en cache

Si les réponses ne sont pas mises en cache, vérifiez d'abord que Cloud CDN est activé pour le service ou bucket de backend. Lorsque vous activez Cloud CDN, la mise en cache des réponses peut prendre quelques minutes.

Cloud CDN ne met en cache que les réponses dont le contenu peut être mis en cache. Ces informations sont transmises dans les en-têtes de réponse HTTP, associées à la configuration du backend. Si les réponses ne sont pas mises en cache dans le cas d'une URL, vérifiez les en-têtes renvoyés pour cette URL et de quelle façon la mise en cache est configurée pour votre backend.

Il existe plusieurs façons de vérifier les en-têtes de réponse :

L'exemple suivant montre comment utiliser curl pour vérifier les en-têtes de réponse HTTP pour http://example.com/style.css :

curl -s -D - -o /dev/null http://example.com/style.css

Sortie :

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:00 GMT
Content-Type: text/css
Content-Length: 1977
Via: 1.1 google

La comparaison de ces en-têtes avec les exigences applicables aux contenus pouvant être mis en cache révèle que l'en-tête Cache-Control requis est absent de la réponse (en supposant que le mode de cache soit défini sur USE_ORIGIN_HEADERS).

La méthode de définition des en-têtes dépend du type de serveur d'origine. Si vous exécutez un serveur Web sur Compute Engine, consultez la documentation du logiciel serveur pour plus de détails sur la configuration des en-têtes de réponse. Pour Cloud Storage, le marquage de l'objet comme étant partagé en mode public entraîne l'envoi des en-têtes appropriés.

Après avoir reconfiguré le serveur d'origine pour ajouter l'en-tête requis, vous pouvez à nouveau utiliser curl pour vérifier le résultat :

curl -s -D - -o /dev/null http://example.com/style.css

Sortie :

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:30 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google

curl -s -D - -o /dev/null http://example.com/style.css

Résultat :

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:31 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google

curl -s -D - -o /dev/null http://example.com/style.css

Résultat :

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:30 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google
Age: 2

Dans cet exemple, la dernière réponse inclut l'en-tête Age. Cloud CDN ajoute un en-tête Age aux réponses qu'il diffuse à partir du cache. Ici, l'en-tête indique que la réponse a été diffusée avec succès depuis le cache à l'aide d'une entrée de cache créée il y a deux secondes.

En outre, si les ETags sont activés sur les instances backend, Cloud CDN s'appuie dessus pour confirmer l'actualisation de l'objet. Si les instances backend diffusent différents ETags pour le même objet, Cloud CDN comptabilise les erreurs de correspondance comme un défaut de cache (miss) et actualise l'objet. Pour éviter ce comportement, les instances backend doivent diffuser le même ETag ou les ETags doivent être désactivés.

Pour vérifier cela, exécutez curl plusieurs fois et observez les modifications de la valeur ETag :

curl -s -D - -o /dev/null http://example.com/image.png

Résultat :

HTTP/2 200
date: Fri, 20 Mar 2020 15:02:30 GMT
server: Apache
strict-transport-security: max-age=31536000; includeSubDomains
last-modified: Mon, 16 Mar 2020 04:20:59 GMT
etag: "10f-5a0f1256f1402"
accept-ranges: bytes
content-length: 271
cache-control: public, max-age=864000
expires: Mon, 30 Mar 2020 15:02:30 GMT
vary: Accept-Encoding
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
content-type: image/png
via: 1.1 google
alt-svc: clear

curl -s -D - -o /dev/null http://example.com/image.png

Résultat :

HTTP/2 200
date: Fri, 20 Mar 2020 15:03:11 GMT
server: Apache
strict-transport-security: max-age=31536000; includeSubDomains
last-modified: Mon, 16 Mar 2020 04:18:31 GMT
etag: "10f-5a0f11ca09b7a"
accept-ranges: bytes
content-length: 271
cache-control: public, max-age=864000
expires: Mon, 30 Mar 2020 15:03:11 GMT
vary: Accept-Encoding
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
content-type: image/png
via: 1.1 google
alt-svc: clear

Les objets Cloud Storage ne sont pas accessibles

Pour fournir un accès aux objets dans Cloud Storage, vous devez configurer des URL signées ou accorder au bucket et à tous ses objets un accès public à allUsers.

Si vous décidez d'accorder un accès à allUsers, vous pouvez vérifier l'accès au niveau de l'objet comme suit :

Console

  1. Dans la console Google Cloud, ouvrez le navigateur Cloud Storage.

    Ouvrir le navigateur Cloud Storage

  2. Cliquez sur un bucket pour afficher la page Informations sur le bucket.

  3. Dans la colonne Accès public, passez la souris sur l'icône de point d'exclamation et cliquez sur Modifier l'accès.

    Pour chaque objet du bucket, vérifiez que les autorisations suivantes sont définies :

    • Entité : utilisateur
    • Nom : allUsers
    • Accès : lecteur

Pour en savoir plus sur le contrôle des accès de Cloud Storage, consultez la documentation sur la gestion de l'authentification et des accès (IAM) pour Cloud Storage.

Pour en savoir plus sur les URL signées, consultez la page Utiliser des URL signées.

Si les objets sont accessibles, mais ne sont pas mis en cache, reportez-vous à la section Les réponses ne sont pas mises en cache.

Du contenu privé a été mis en cache ou le contenu mis en cache est incorrect

Si vous savez pourquoi le serveur d'origine a diffusé le contenu privé ou incorrect et que vous pouvez résoudre le problème, vous pouvez invalider les caches Cloud CDN comme suit :

  1. Assurez-vous que le serveur d'origine ne renvoie plus le contenu privé ou incorrect.
  2. Demandez une invalidation de cache pour indiquer à Cloud CDN de cesser de diffuser le contenu mis en cache.

Pour en savoir plus, consultez la Présentation de l'invalidation de cache.

Cloud CDN ne met en cache que les réponses comportant du contenu pouvant être mis en cache et ne diffuse les réponses du cache qu'à l'heure d'expiration spécifiée dans la réponse. Si vous ne savez pas pourquoi le contenu a été mis en cache ou ne pouvez pas régler le problème rapidement, vous pouvez désactiver Cloud CDN jusqu'à ce que vous puissiez comprendre et résoudre le problème, puis le réactiver. Pour plus d'informations sur le contenu mis en cache et sa durée de conservation, consultez la section Présentation de la mise en cache.

Le taux d'accès au cache est faible

Pour améliorer les performances et l'évolutivité, il est important d'optimiser les taux d'accès au cache. Si les taux d'accès au cache sont inférieurs aux prévisions, assurez-vous de suivre les bonnes pratiques pour optimiser le taux d'accès au cache.

Le tableau suivant vous permet de comprendre certaines des causes possibles d'un faible taux d'accès au cache et vous présente des correctifs potentiels.

Raisons Commentaires Corrections
Votre contenu ne peut pas être mis en cache. Une réponse pouvant être mise en cache est une réponse HTTP que Cloud CDN peut stocker. Assurez-vous que votre contenu peut être mis en cache.
Le mode de cache n'est pas optimal pour votre application. Cloud CDN propose plusieurs modes de cache. Si vous n'utilisez pas des en-têtes de contrôle de cache pour contrôler le comportement de mise en cache, il est recommandé d'autoriser Cloud CDN à mettre en cache l'ensemble du contenu statique.
Le trafic est faible. Pendant les tests et essais, la quantité de trafic que vous générez risque d'être faible. Google dispose d'un cache distribué à l'échelle mondiale, et les requêtes provenant de différents emplacements géographiques sont envoyées à différents emplacements. Dans chaque emplacement d'interface, Google peut disposer de plusieurs instances discrètes du cache.
  • Assurez-vous qu'un volume de trafic suffisant est envoyé à Google pour remplir tous les caches pertinents.
  • Lors des tests, veillez à segmenter le trafic par URL afin que tout le trafic de chaque ensemble de requêtes soit bien transmis à Google. Ne partitionnez pas chaque requête de manière aléatoire auprès d'un fournisseur CDN différent.
Les réponses pour certaines URL ne sont pas mises en cache. Cloud CDN incorpore l'URI de requête complet dans ses clés de cache. http://example.com/cat.jpg?color=orange et http://example.com/cat.jpg?color=gray disposent donc d'entrées de cache distinctes. Utilisez toujours une seule URL pour une ressource donnée.

Si vous devez transmettre des paramètres à un script JavaScript exécuté sur une page pouvant être mise en cache, utilisez des identifiants de fragment plutôt que des chaînes de requête.
Le cache est inutilement segmenté à cause du champ d'en-tête Vary. Le champ d'en-tête Vary dans une réponse décrit les parties d'un message de requête (hormis la méthode, le champ d'en-tête Host et la cible de requête) qui peuvent influencer le processus du serveur d'origine pour la sélection et la représentation d'une réponse. Par exemple, vous pouvez utiliser l'en-tête Vary: Accept-Encoding si vous diffusez différents contenus pour les clients capables de gérer des réponses compressées et ceux qui ne le peuvent pas. Utilisez l'en-tête de réponse Vary uniquement si nécessaire.
Vous n'utilisez pas de clés de cache personnalisées. Par défaut, Cloud CDN crée la clé de cache à partir de l'URL complète de la demande. Vous pouvez personnaliser les clés de cache pour inclure ou omettre toute combinaison de protocole, d'hôte et de chaîne de requête. Par exemple, si deux domaines utilisent le même contenu statique, vous pouvez créer une clé de cache personnalisée qui omet le champ hôte. Utilisez des clés de cache personnalisées, si nécessaire.

Plusieurs remplissages de cache correspondent à un même contenu

En général, vous pouvez réduire le nombre de remplissages de cache en augmentant les délais d'expiration des réponses pouvant être mises en cache. Toutes choses égales par ailleurs, vous constaterez moins de remplissages de cache avec une réponse comportant Cache-Control: public, max-age=86400 qu'avec une réponse comportant Cache-Control: public, max-age=1.

Pour en savoir plus sur les délais d'expiration, consultez la section Délais d'expiration et requêtes de validation. Pour plus d'informations sur la configuration des en-têtes de réponse appropriés, consultez la documentation de votre logiciel serveur Web.

Cloud CDN exploite de nombreux caches dans le monde entier et les anciennes entrées de cache sont systématiquement supprimées pour laisser la place à de nouveaux contenus. Par conséquent, plusieurs remplissages de cache par ressource sont attendus dans le cadre d'un fonctionnement normal.

La compression ne fonctionne pas

Cloud CDN propose la compression dynamique pour les origines qui ne peuvent pas compresser leurs réponses. Dans la mesure du possible, nous vous recommandons d'utiliser la compression à l'origine, car elle réduit les coûts de remplissage du cache.

Si les réponses diffusées par Cloud CDN ne sont pas compressées alors qu'elles doivent l'être, vérifiez que le logiciel serveur Web exécuté sur les instances est configuré pour compresser les réponses. Par défaut, certains logiciels serveur Web désactivent automatiquement la compression pour les requêtes comportant l'en-tête Via. La présence d'un en-tête Via indique que la requête a été transmise par un proxy. Les proxys HTTP tels que l'équilibreur de charge d'application externe ajoutent un en-tête Via à chaque requête, comme requis par la spécification HTTP. Pour activer la compression, vous devrez peut-être remplacer la configuration par défaut de votre serveur Web pour lui indiquer de compresser les réponses même si la requête comporte un en-tête Via.

Si vous utilisez le logiciel de serveur Web nginx, modifiez le fichier de configuration nginx.conf pour activer la compression. L'emplacement de ce fichier dépend de l'emplacement d'installation de nginx. Dans de nombreuses distributions Linux, ce fichier est stocké dans /etc/nginx/nginx.conf.

Pour permettre le fonctionnement de la compression nginx avec votre équilibreur de charge d'application externe, ajoutez les deux lignes suivantes à la section http du fichier nginx.conf:

gzip_proxied any;
gzip_vary on;

  • La première ligne permet la compression même pour les requêtes transmises par un proxy tel que l'équilibreur de charge d'application externe.

  • La deuxième ligne ajoute un en-tête Vary: Accept-Encoding aux réponses. Vary: Accept-Encoding indique aux proxys de mise en cache tels que Cloud CDN de conserver des entrées de cache distinctes pour les variantes compressées et non compressées des ressources compressibles.

Une fois que vous avez modifié nginx.conf, vous devez redémarrer nginx pour utiliser la nouvelle configuration. Dans de nombreuses distributions Linux, vous pouvez redémarrer nginx en exécutant sudo service nginx restart ou /etc/init.d/nginx restart.

Les réponses se terminent par des erreurs byte_range_caching_aborted

Lorsque Cloud CDN assemble une réponse à partir de plusieurs requêtes de plage d'octets, il vérifie si ces plages proviennent de la même version de la ressource en comparant les en-têtes de réponse ETag et Last-Modified. Si Cloud CDN détecte que la valeur de l'un des en-têtes est incohérente par rapport aux plages déjà fournies au client, la réponse est abandonnée.

Si vous remarquez des réponses terminées de manière inattendue ou des entrées de journal Cloud Logging comportant l'élément statusDetails byte_range_caching_aborted, ou si des instances renvoient des réponses 412 Precondition Failed, assurez-vous que le logiciel serveur Web exécuté sur toutes les instances de machine virtuelle (VM) renvoie les mêmes valeurs ETag et Last-Modified pour une ressource donnée.

Lors de la diffusion de fichiers à partir d'un disque, il est courant que le logiciel serveur Web dérive les valeurs ETag et Last-Modified à partir de la date de modification du fichier. Dans ce cas, vous pouvez vous assurer que vos instances de VM signalent des valeurs cohérentes en utilisant la même image pour toutes les instances. Pour savoir comment votre logiciel serveur Web détermine les valeurs ETag et Last-Modified, consultez la documentation de votre logiciel serveur Web.

Résoudre les problèmes liés aux cookies signés

Les problèmes suivants peuvent se produire lorsque vous utilisez des cookies signés.

Encodage

Lors de la génération d'une signature, la requête est rejetée de manière inattendue en raison d'une erreur de correspondance de signature.

Lorsque vous encodez les valeurs URL et Signature, assurez-vous d'utiliser la variante sécurisée pour les URL de base64. L'encodage base64 standard échoue lorsque les caractères générés ne sont pas sécurisés pour les URL. Le remplissage est accepté.

Signature

Votre requête est rejetée par Cloud CDN.

  • Assurez-vous d'utiliser l'algorithme de signature HMAC-SHA-1, et non une autre variante de HMAC.

  • Vérifiez que le paramètre KeyName (sensible à la casse) correspond à un nom de clé valide pour le service de backend ou le bucket backend utilisé par Cloud CDN.

  • Ne signez pas de paramètres de requête lorsque vous générez et signez un élément URLPrefix. Assurez-vous que URLPrefix ne contient que les composants de schéma, d'hôte et de chemin d'accès (partiel) de l'URL.

  • Assurez-vous que le bloc de signature (URLPrefix, Expires, KeyName et Signature) correspond bien aux dernières sections du cookie, délimitées par :.

  • Assurez-vous que URLPrefix, Expires, KeyName et Signature apparaissent dans cet ordre.

  • N'incluez pas d'astérisque (*) à la fin d'un élément URLPrefix dans un cookie signé.

Cookies

  • Les navigateurs limitent généralement les cookies à 4 Ko par domaine et le nombre maximal de cookies à 50 par domaine. Prenez note des autres cookies que vous émettez et que vous demandez à vos clients d'envoyer, car de nombreux serveurs Web appliquent également des limites maximales d'en-tête de requête.

  • Assurez-vous d'utiliser le caractère deux-points (:) (point de code Unicode U+003A) comme délimiteur des paramètres nommés dans un cookie signé, et non le caractère esperluette (&).

  • Assurez-vous que l'horodatage Expires des cookies que vous émettez n'est pas inutilement trop court. Les périodes de validité inférieures à une ou deux minutes peuvent entraîner des problèmes de variation d'horloge entre l'application émettrice et l'infrastructure de Cloud CDN.

  • Assurez-vous de ne pas définir plusieurs cookies pour les mêmes attributs Domain et Path avec des valeurs différentes. Définissez un cookie unique par utilisateur avec une valeur de préfixe d'URL qui englobe tout le contenu auquel l'utilisateur doit accéder.

Messages d'erreur

Erreurs d'invalidation de cache

Code d'erreur Remarques
Invalid value for field 'resource.path'

La valeur du chemin a un format non valide. Les chemins d'accès doivent commencer par / et ne doivent pas contenir ? ou #. Ils ne doivent comporter qu'un seul *, qui doit être un caractère final après /.

Les chemins ne doivent pas dépasser 1024 caractères. Si vous recevez cette erreur, vérifiez la valeur du chemin et corrigez les erreurs de format.

Cette erreur ne concerne que le format du chemin. Un chemin de format valide, mais inexistant, est toujours considéré comme valide.
Rate Limit Exceeded Cloud CDN limite la vitesse à laquelle les opérations d'invalidation de cache peuvent être effectuées. Une seule invalidation par minute est autorisée. Cependant, chaque opération peut spécifier un format de chemin correspondant à un nombre quelconque d'objets.

Problèmes connus

  • Les invalidations de cache sont limitées à une invalidation par mappage d'URL et par minute.

    Solution: patientez au moins une minute avant d'essayer d'invalider un autre mappage d'URL.

    Pour en savoir plus sur la limitation du débit'invalidation du cache, consultez la section Limites.