Risolvere i problemi di Cloud CDN

Scopri i passaggi per la risoluzione dei problemi, utili in caso di problemi con l'utilizzo di Cloud CDN.

Se il problema riscontrato è relativo ai backend esterni, consulta anche Risoluzione dei problemi relativi a backend esterni e NEG Internet.

Problemi e soluzioni generali

Le risposte non vengono memorizzate nella cache

Se le risposte non vengono memorizzate nella cache, verifica 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. Se le risposte per un URL non vengono memorizzate nella cache, controlla quali intestazioni vengono restituite per l'URL e in che modo la cache viene configurata per il tuo 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 obbligatoria (supponendo che la modalità cache sia impostata su USE_ORIGIN_HEADERS).

Il metodo per l'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 i dettagli sulla configurazione delle intestazioni delle risposte. Per Cloud Storage, contrassegnare l'oggetto come condiviso pubblicamente fa sì che le intestazioni appropriate vengano inviate.

Dopo aver riconfigurato il server di origine per aggiungere l'intestazione richiesta, puoi utilizzare nuovamente curl per verificare 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 pubblicate dalla cache. In questo caso, l'intestazione indica che la risposta è stata pubblicata dalla cache utilizzando una voce della cache creata due secondi fa.

Inoltre, se ETag è abilitato sulle istanze di backend, Cloud CDN si basa su ETag per confermare l'aggiornamento dell'oggetto. Se le istanze di backend gestiscono ETag diversi sullo stesso oggetto, Cloud CDN conteggia le corrispondenze errate come un fallimento della cache e aggiorna l'oggetto. Per evitare che questo accada, le istanze di backend devono gestire lo stesso ETag o gli ETag devono essere disabilitati.

Per verificarlo, esegui curl ripetutamente e controlla le modifiche 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 gli URL firmati o concedere al bucket l'accesso pubblico e a tutti i suoi oggetti per allUsers.

Se decidi di fornire l'accesso allUsers, puoi verificare l'accesso a livello di oggetto come segue.

Console

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

    Apri il browser Storage

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

  3. Nella colonna Accesso pubblico, passa il mouse sopra l'icona a forma di punto esclamativo e fai clic su Accesso in modifica.

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

    • Entità: utente
    • Nome: allUsers
    • Accesso: lettore

Per scoprire 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 Utilizzare gli URL firmati.

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

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

Se sai perché 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ù i contenuti privati o errati.
  2. Richiedi l'annullamento della convalida della cache per indicare a Cloud CDN di interrompere la pubblicazione dei contenuti memorizzati nella cache.

Per ulteriori informazioni, consulta la panoramica dell'annullamento della convalida della cache.

Cloud CDN memorizza nella cache solo le risposte con contenuti memorizzabili nella cache e pubblica le risposte solo dalla cache fino alla scadenza specificata nella risposta. Se non sai perché i contenuti sono stati memorizzati nella cache o non riesci a risolvere il problema in modo rapido, ti consigliamo di disattivare Cloud CDN finché non riesci a comprendere e risolvere il problema, quindi di riattivarlo. Per ulteriori informazioni sui contenuti memorizzati nella cache e per quanto tempo, consulta la panoramica sulla memorizzazione nella cache.

Il tasso di successo della cache è basso

Per prestazioni e scalabilità, è importante ottimizzare i report sugli hit dalla cache. Se riscontri percentuali di successo della cache più basse del previsto, assicurati di seguire le best practice per ottimizzare il rapporto delle corrispondenze nella cache.

Utilizza la seguente tabella per comprendere alcuni dei possibili motivi di un basso tasso di percentuale successi cache e delle potenziali correzioni.

Motivi Commenti Correzioni
I tuoi contenuti non possono essere memorizzati 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 dispone di diverse modalità cache. Se non utilizzi le intestazioni di controllo della cache per controllare il comportamento della memorizzazione nella cache, la best practice consigliata consente a Cloud CDN di memorizzare nella cache tutti i contenuti statici.
Il traffico è ridotto. Durante i test e la sperimentazione, è probabile che la quantità di traffico generata sia bassa. Google dispone di una cache distribuita globale e le richieste da diverse località geografiche vengono inviate alle diverse località di frontend Google. In ogni località di frontend, Google potrebbe avere più istanze discrete della cache.
  • Assicurati che il volume di traffico inviato a Google sia sufficiente per completare tutte le cache pertinenti.
  • Durante il test, assicurati di eseguire il sharding del traffico in base all'URL, in modo che tutto il traffico per ogni insieme di richieste venga inviato a Google. Non eseguire il sharding casuale di ogni richiesta a un altro provider CDN.
Le risposte relative a determinati URL non vengono memorizzate nella cache. Cloud CDN incorpora l'URI completo della richiesta nelle chiavi della cache, in modo che http://example.com/cat.jpg?color=orange e http://example.com/cat.jpg?color=gray abbiano voci di cache separate. Utilizza sempre un unico URL per una determinata risorsa.

Se devi passare i parametri a JavaScript in esecuzione su una pagina altrimenti memorizzabile nella cache, valuta di utilizzare gli identificatori di frammento anziché le stringhe di query.
La cache è inutilmente partizionata a causa del campo di 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 la destinazione della richiesta) potrebbero influire sul processo del server di origine per la selezione e la rappresentazione di una risposta. Ad esempio, potresti utilizzare l'intestazione Vary: Accept-Encoding se pubblichi contenuti diversi per i client che possono gestire risposte compresse e quelli che non possono rispondere. 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 completa per creare la chiave cache. Puoi personalizzare le chiavi della 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 ometti il campo Host. Se necessario, utilizza chiavi di cache personalizzate.

Esistono diversi riempimenti della cache per gli stessi contenuti

In generale, puoi ridurre il numero di riempimenti della cache aumentando le date di scadenza delle risposte memorizzabili nella cache. Se rimane tutto uguale, vedrai meno riempimenti della cache per una risposta con Cache-Control: public, max-age=86400 rispetto a uno con Cache-Control: public, max-age=1.

Per ulteriori informazioni sulle scadenze, consulta l'articolo Tempi di scadenza e richieste di convalida. Per informazioni sulla configurazione delle intestazioni di risposta appropriate, consulta la documentazione del software del server web.

Cloud CDN gestisce numerose cache in tutto il mondo e le voci precedenti vengono eliminate regolarmente per fare spazio a nuovi contenuti. Di conseguenza, sono previsti più riempimenti della cache per risorsa nell'ambito del normale funzionamento.

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 perché riduce i costi di riempimento della cache.

Se le risposte fornite da Cloud CDN non sono compresse, ma dovrebbero esserlo, controlla che il software del server web in esecuzione sulle tue istanze sia configurato per comprimere le risposte. Per impostazione predefinita, alcuni software per 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 dell'applicazione esterno aggiungono un'intestazione Via a ogni richiesta, come richiesto dalla specifica HTTP. Per abilitare la compressione, potrebbe essere necessario eseguire l'override della configurazione predefinita del tuo server web per ottenere la compressione delle risposte anche se la richiesta aveva un'intestazione Via.

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

Per consentire la compressione di nginx con il bilanciatore del carico dell'applicazione esterno, aggiungi le seguenti due righe alla sezione http di nginx.conf:

gzip_proxied any;
gzip_vary on;

  • La prima riga consente la compressione anche per le richieste inoltrate da un proxy come il bilanciatore del carico dell'applicazione 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 di mantenere voci di cache separate per le varianti di risorse comprimibili e non compresse.

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 byte_range_caching_aborted errors

Quando Cloud CDN assembla una risposta da più richieste di intervallo di byte, controlla se tali 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 terminate inaspettate, voci di log di Cloud Logging con stato byte_range_caching_abortedDettagli o istanze che restituiscono 412 Precondition Failed risposte, assicurati che il software del server web in esecuzione su tutte le istanze di macchine virtuali (VM) restituisca gli stessi valori ETag e Last-Modified per una determinata risorsa.

Quando pubblichi file da disco, è comune per il software del server web ricavare i valori ETag e Last-Modified dal momento della modifica del file. In questo caso, puoi assicurarti che le istanze VM registrino valori coerenti utilizzando la stessa immagine per tutte le istanze. Per informazioni dettagliate su come il software del server web determina i valori ETag e Last-Modified, consulta la documentazione del software del server web.

Risoluzione dei problemi relativi ai cookie firmati

Quando utilizzi i cookie firmati, possono verificarsi i seguenti problemi.

Codifica

Quando generi 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 con protezione dell'URL di base64. L'elemento Standard base64 non riesce quando i caratteri generati non sono sicuri per l'URL. L'imbottitura è accettata.

Firma

La tua richiesta è stata 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 chiave valido per il servizio di backend o il bucket di backend utilizzato da Cloud CDN.

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

  • Assicurati che il blocco della firma (URLPrefix, Expires, KeyName e Signature stesso) sia le ultime sezioni del cookie delimitate da :.

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

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

Cookie

  • In genere, i browser limitano i cookie a 4 kB per dominio, con un limite totale di 50 cookie per dominio. Prendi nota degli altri cookie che invii e chiedi ai tuoi client di inviarli perché molti server web hanno anche limiti massimi di intestazioni di richiesta.

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

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

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

Messaggi di errore

Errori di annullamento della convalida della cache

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

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

I percorsi non devono superare i 1024 caratteri. Se ricevi questo errore, controlla il valore del percorso e correggi eventuali errori nel formato.

Questo errore riguarda solo il formato del percorso. Un percorso in formato valido, ma che non esiste, viene comunque considerato valido.
Rate Limit Exceeded Cloud CDN limita la frequenza di esecuzione delle operazioni di annullamento della convalida della cache. È consentita una sola annullamento della convalida al minuto. Tuttavia, ogni operazione può specificare un pattern del percorso che corrisponde a un numero qualsiasi di oggetti.

Problemi noti

  • Le invalidazioni della cache sono limitate a una sola annullamento della convalida per mappa URL al minuto.

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

    Per ulteriori informazioni sulla limitazione di frequenza di annullamento della convalida della cache, consulta la pagina Limitazioni.