Risolvi i problemi di Cloud CDN

Scopri procedure per la risoluzione dei problemi che potrebbero esserti utili se riscontri i seguenti problemi durante l'utilizzo di Cloud CDN.

Se il problema che riscontri è correlato ai backend esterni, consulta anche Risoluzione dei problemi relativi al backend esterno e ai NEG internet.

Problemi e soluzioni generali

Questa sezione descrive alcuni problemi comuni e le relative soluzioni.

Le risposte non vengono memorizzate nella cache

Se le risposte non vengono memorizzate nella cache, controlla innanzitutto che Cloud CDN sia abilitato per il servizio di backend o il bucket di backend. Quando abiliti Cloud CDN, potrebbero essere necessari alcuni minuti prima che le risposte inizino a essere memorizzate nella cache.

Cloud CDN memorizza nella cache solo le risposte con contenuti memorizzabili nella cache. Queste informazioni vengono trasmesse nelle intestazioni delle risposte HTTP, in combinazione con la configurazione del backend. Quando configuri un'intestazione della risposta personalizzata con cdn_cache_status, puoi osservare lo stato della cache nei log di Cloud CDN e determinare se una risposta è stata pubblicata a seguito di un fallimento della cache.

Se le risposte per un URL non vengono memorizzate nella cache, controlla quali intestazioni vengono restituite per quell'URL e come viene configurata la memorizzazione nella cache per il backend.

Esistono diversi modi per controllare le intestazioni delle risposte:

L'esempio seguente mostra l'utilizzo di curl per controllare le intestazioni della risposta HTTP per http://example.com/style.css:

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

Output:

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

Il confronto di queste intestazioni con i requisiti dei contenuti memorizzabili nella cache rivela che nella risposta manca l'intestazione Cache-Control richiesta (supponendo che la modalità cache sia impostata su USE_ORIGIN_HEADERS).

Il metodo di impostazione delle intestazioni dipende dal tipo di server di origine. Se esegui un server web su Compute Engine, consulta la documentazione del software del server web per informazioni dettagliate sulla configurazione delle intestazioni della risposta. Per Cloud Storage, contrassegnare l'oggetto come condiviso pubblicamente comporta l'invio delle intestazioni appropriate.

Dopo aver riconfigurato il server di origine per aggiungere l'intestazione richiesta, puoi utilizzare di nuovo curl per controllare il risultato:

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

Output:

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

Output:

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

Output:

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

L'ultima risposta in questo esempio include un'intestazione Age. Cloud CDN aggiunge un'intestazione Age alle risposte che gestisce dalla cache. In questo caso, l'intestazione indica che la risposta è stata pubblicata correttamente dalla cache utilizzando una voce di cache creata due secondi prima.

Inoltre, se gli ETag sono abilitati sulle istanze di backend, Cloud CDN si basa sui di loro per confermare l'aggiornamento dell'oggetto. Se le istanze di backend pubblicano ETag diversi sullo stesso oggetto, Cloud CDN considera le mancate corrispondenze come un fallimento della cache e aggiorna l'oggetto. Per evitare questo problema, le istanze di backend devono pubblicare lo stesso ETag, oppure gli ETag devono essere disattivati.

Per verificarlo, esegui curl ripetutamente e osserva le variazioni del valore ETag:

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

Output:

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

Output:

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

Impossibile accedere agli oggetti Cloud Storage

Per fornire l'accesso agli oggetti in Cloud Storage, devi configurare URL firmati o concedere l'accesso pubblico al bucket e a tutti i suoi oggetti per allUsers.

Se decidi di fornire l'accesso allUsers, puoi verificare l'accesso a livello di oggetto nel seguente modo.

Console

  1. Nella console Google Cloud , apri il browser di Cloud Storage.

    Apri il browser di Storage

  2. Fai clic su un bucket per visualizzare la pagina Dettagli bucket.

  3. Nella colonna Accesso pubblico, tieni il puntatore sopra l'icona del punto esclamativo e fai clic su Modifica accesso.

    Per ogni oggetto nel bucket, assicurati che sia impostata la seguente autorizzazione:

    • Entità: User
    • Nome: allUsers
    • Accesso: Reader

Per saperne di più sul controllo dell'accesso per Cloud Storage, consulta la documentazione di Identity and Access Management (IAM) per Cloud Storage.

Per scoprire di più sugli URL firmati, consulta Utilizzo degli URL firmati.

Se gli oggetti sono accessibili ma non vengono memorizzati nella cache, consulta Le risposte non vengono memorizzate nella cache.

I contenuti privati sono stati memorizzati nella cache o i contenuti memorizzati nella cache non sono corretti

Se conosci il motivo per cui il server di origine ha pubblicato contenuti privati o errati e puoi risolvere il problema, puoi invalidare le cache di Cloud CDN utilizzando la seguente procedura:

  1. Assicurati che il server di origine non restituisca più contenuti privati o errati.
  2. Richiedi un annullamento della convalida della cache per indicare a Cloud CDN di interrompere la pubblicazione dei contenuti memorizzati nella cache.

Per saperne di più, consulta la Panoramica dell'annullamento della convalida della cache.

Cloud CDN memorizza nella cache solo le risposte con contenuti memorizzabili nella cache e gestisce le risposte dalla cache solo fino alla scadenza specificata nella risposta. Se non sai perché i contenuti sono stati memorizzati nella cache o non riesci a risolvere il problema rapidamente, ti consigliamo di disattivare Cloud CDN finché non riesci a comprendere e risolvere il problema, e quindi riattivarlo. Per saperne di più sui contenuti memorizzati nella cache e per quanto tempo, consulta la Panoramica della memorizzazione nella cache.

La percentuale successi cache è bassa

Per prestazioni e scalabilità, è importante ottimizzare la percentuale successi cache. Se riscontri una percentuale successi cache inferiore al previsto, assicurati di seguire le best practice per ottimizzare la percentuale successi cache.

Utilizza la seguente tabella per comprendere alcuni dei possibili motivi di una percentuale successi cache bassa e le potenziali soluzioni.

Motivi Commenti Correzioni
I tuoi contenuti non sono memorizzabili nella cache. Una risposta memorizzabile nella cache è una risposta HTTP che Cloud CDN può archiviare. Assicurati che i contenuti siano memorizzabili nella cache.
La modalità cache non è ottimale per la tua applicazione. Cloud CDN ha più modalità cache. Se non utilizzi le intestazioni di controllo della cache per controllare il comportamento di memorizzazione nella cache, la best practice consigliata è quella di consentire a Cloud CDN di memorizzare nella cache tutti i contenuti statici.
Il traffico è ridotto. Durante i test e gli esperimenti, la quantità di traffico che generi è probabilmente bassa. Google ha una cache distribuita a livello globale e le richieste provenienti da diverse posizioni geografiche vengono inviate a diverse località del frontend di Google. In ogni località di frontend, Google potrebbe avere più istanze discrete della cache.
  • Assicurati che a Google venga inviato un volume di traffico sufficiente per popolare tutte le cache pertinenti.
  • Durante il test, assicurati di suddividere il traffico per URL in modo che tutto il traffico per ogni set di richieste venga inviato a Google. Non suddividere in modo casuale ogni richiesta per un diverso fornitore di CDN.
Le risposte per URL particolari non vengono memorizzate nella cache. Cloud CDN incorpora l'URI della richiesta completo nelle chiavi della cache, pertanto http://example.com/cat.jpg?color=orange e http://example.com/cat.jpg?color=gray hanno voci di cache separate. Utilizza sempre un singolo URL per una determinata risorsa.

Se devi trasmettere parametri a JavaScript in esecuzione su una pagina altrimenti memorizzabile nella cache, valuta la possibilità di utilizzare gli identificatori di frammenti anziché le stringhe di query.
La cache è frammentata inutilmente a causa del campo dell'intestazione Vary. Il campo di intestazione Vary in una risposta descrive quali parti di un messaggio di richiesta (a parte il metodo, il campo di intestazione Host e il target della richiesta) potrebbero influenzare il processo di selezione e rappresentazione di una risposta del server di origine. Ad esempio, potresti voler utilizzare l'intestazione Vary: Accept-Encoding se pubblichi contenuti diversi per i client che possono gestire risposte compresse e per quelli che non possono. Utilizza l'intestazione della risposta Vary solo quando necessario.
Non utilizzi chiavi di cache personalizzate. Per impostazione predefinita, Cloud CDN utilizza l'URL della richiesta completo per creare la chiave cache. Puoi personalizzare le chiavi cache in modo da includere o omettere qualsiasi combinazione di protocollo, host e stringa di query. Ad esempio, se due domini utilizzano gli stessi contenuti statici, puoi creare una chiave cache personalizzata che omette il campo host. Utilizza chiavi cache personalizzate, se necessario.

Esistono più riempimenti della cache per gli stessi contenuti

In generale, puoi ridurre il numero di riempimenti della cache aumentando i tempi di scadenza delle risposte memorizzabili nella cache. A parità delle altre condizioni, vedrai meno riempimenti della cache per una risposta con Cache-Control: public, max-age=86400 rispetto a una con Cache-Control: public, max-age=1.

Per saperne di più sui tempi di scadenza, consulta la sezione Tempi di scadenza e richieste di convalida. Per informazioni sulla configurazione delle intestazioni delle risposte appropriate, consulta la documentazione del software del server web.

Cloud CDN gestisce numerose cache in tutto il mondo e le vecchie voci della cache vengono rimosse regolarmente per fare spazio a nuovi contenuti. Di conseguenza, durante il normale funzionamento sono previsti più riempimenti della cache per risorsa.

La compressione non funziona

Cloud CDN offre la compressione dinamica per le origini che non possono comprimere le risposte. Se possibile, ti consigliamo di utilizzare la compressione all'origine per ridurre costi di riempimento della cache.

Se le risposte gestite da Cloud CDN non sono compresse, ma dovrebbero esserlo, verifica che il software del server web in esecuzione sulle tue istanze sia configurato per comprimere le risposte. Per impostazione predefinita, alcuni software dei server web disattivano automaticamente la compressione per le richieste che includono un'intestazione Via. La presenza di un'intestazione Via indica che la richiesta è stata inoltrata da un proxy. I proxy HTTP come il bilanciatore del carico delle applicazioni esterno aggiungono un'intestazione Via a ogni richiesta come richiesto dalla specifica HTTP. Per attivare la compressione, potresti dover sostituire la configurazione predefinita del server web per indicargli di comprimere le risposte anche se la richiesta possiede un'intestazione Via.

Se utilizzi il software del server web nginx, modifica il file di configurazione nginx.conf per attivare la compressione. La posizione di questo file dipende da dove è installato nginx. In molte distribuzioni Linux, il file è archiviato in /etc/nginx/nginx.conf.

Affinché la compressione nginx funzioni con il bilanciatore del carico delle applicazioni esterno, aggiungi le due righe seguenti alla sezione http di nginx.conf:

gzip_proxied any;
gzip_vary on;

  • La prima riga attiva la compressione anche per le richieste inoltrate da un proxy come il bilanciatore del carico delle applicazioni esterno.

  • La seconda riga aggiunge un'intestazione Vary: Accept-Encoding alle risposte. Vary: Accept-Encoding comunica ai proxy di memorizzazione nella cache, come Cloud CDN, che devono mantenere voci di cache separate per le varianti compresse e non compresse delle risorse comprimibili.

Dopo aver modificato nginx.conf, devi riavviare nginx prima che utilizzi la nuova configurazione. In molte distribuzioni Linux, puoi riavviare nginx eseguendo sudo service nginx restart o /etc/init.d/nginx restart.

Le risposte terminano con errori byte_range_caching_aborted

Quando Cloud CDN assembla una risposta da più richieste di intervallo di byte, verifica se questi intervalli provengono dalla stessa versione della risorsa confrontando le intestazioni di risposta ETag e Last-Modified. Se Cloud CDN rileva che il valore di una delle intestazioni non è coerente con gli intervalli già pubblicati per il client, interrompe la risposta.

Se noti risposte che terminano in modo imprevisto, voci di log di Cloud Logging con statusDetails byte_range_caching_aborted o istanze che restituiscono risposte 412 Precondition Failed, assicurati che il software del server web in esecuzione su tutte le tue istanze di macchine virtuali (VM) restituisca gli stessi valori ETag e Last-Modified per una determinata risorsa.

Quando vengono pubblicati file dal disco, è normale che il software del server web derivi i valori ETag e Last-Modified dall'ora di modifica del file. In questo caso, puoi assicurarti che le tue istanze VM riportino valori coerenti utilizzando la stessa immagine per tutte le istanze. Per informazioni dettagliate su come il software del server web determina i valori di ETag e Last-Modified, consulta la documentazione del software del server web.

Risoluzione dei problemi relativi ai cookie firmati

I seguenti problemi possono verificarsi quando utilizzi i cookie firmati.

Codifica

Quando viene generata una firma, la richiesta viene rifiutata in modo imprevisto a causa di una mancata corrispondenza della firma.

Quando codifichi i valori URL e Signature, assicurati di utilizzare la variante sicura per URL di base64. La codifica base64 standard non riesce quando i caratteri generati non sono sicuri per l'URL. Il padding è accettato.

Firma

La tua richiesta viene rifiutata da Cloud CDN.

  • Assicurati di utilizzare HMAC-SHA-1 come algoritmo di firma e non un'altra variante di HMAC.

  • Verifica che il parametro KeyName (sensibile alle maiuscole) corrisponda a un nome di chiave valido per il servizio di backend o il bucket di backend in uso da Cloud CDN.

  • Non firmare parametri di query durante la generazione e la firma di un URLPrefix. Assicurati che URLPrefix contenga solo i componenti dello schema, dell'host e del percorso (parziale) dell'URL.

  • Assicurati che il blocco della firma (URLPrefix, Expires, KeyName e Signature) sia l'ultima sezione del cookie delimitata da :.

  • Assicurati che URLPrefix, Expires, KeyName e Signature siano in questo ordine.

  • Non includere un asterisco (*) alla fine di un URLPrefix in un cookie firmato.

Cookie

  • In genere, i browser limitano i cookie a 4 kB per dominio, con un limite di 50 cookie per dominio in totale. Prendi nota degli altri cookie che emetti e richiedi ai tuoi client di inviare, perché molti server web hanno anche limiti massimi per le intestazioni delle richieste.

  • Assicurati di utilizzare i due punti (:), il punto di codice Unicode U+003A, come delimitatore per i parametri denominati in un cookie firmato e non la e commerciale (&).

  • Assicurati che il timestamp Expires dei cookie che stai emettendo non sia innecessariamente breve. I periodi di validità inferiori a uno o due minuti potrebbero essere soggetti a problemi di discrepanza tra l'app di emissione e l'infrastruttura Cloud CDN.

  • Assicurati di non impostare più cookie per lo stesso Domain e Path con valori diversi. Imposta un singolo cookie per utente con un valore del prefisso URL che comprenda tutti i contenuti a cui l'utente deve accedere.

Messaggi di errore

Questa sezione fornisce informazioni su alcuni messaggi di errore comuni e su come risolverli.

Errori di annullamento della convalida della cache

Codice di errore Note
Invalid value for field 'resource.path'

Il valore del percorso aveva un formato non valido. I percorsi devono iniziare con un /, non devono contenere ? o # e devono avere un solo *, che deve essere un carattere finale dopo un /.

I percorsi non possono contenere più di 1024 caratteri. Se ricevi questo errore, controlla il valore del percorso e correggi eventuali errori di formato.

Questo errore riguarda solo il formato del percorso. Un percorso con un formato valido, ma che non esiste, viene comunque considerato valido.
Rate Limit Exceeded Cloud CDN limita la velocità con cui possono essere eseguite le operazioni di annullamento della convalida della cache. Puoi inviare fino a 500 richieste di annullamento della convalida al minuto. Ogni operazione può specificare un pattern del percorso che corrisponde a un numero qualsiasi di oggetti.

Problemi noti

  • L'annullamento della convalida della cache ha una limitazione di frequenza pari a un annullamento della convalida per mappa URL al minuto.

    Soluzione: attendi almeno un minuto prima di provare a invalidare un'altra mappa URL.

    Per saperne di più sulla limitazione di frequenza dell'annullamento della convalida della cache, consulta Limitazioni.