Risolvere i problemi relativi a Cloud CDN

Scopri i passaggi per la risoluzione dei problemi che potresti trovare utili se riscontri i seguenti problemi durante l'utilizzo di Cloud CDN.

Se il problema che riscontri riguarda i backend esterni, consulta anche Risolvere i problemi relativi ai backend esterni 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 la CDN di Cloud sia attivata per il servizio o il bucket di backend. Quando attivi 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 di risposta HTTP, in combinazione con la configurazione del backend. Quando configuri un'intestazione di risposta personalizzata con cdn_cache_status, puoi osservare lo stato della cache nei log di Cloud CDN e determinare se una risposta è stata inviata a seguito di un mancato recupero della cache.

Se le risposte per un URL non vengono memorizzate nella cache, controlla quali intestazioni vengono riportate per l'URL e come è configurata la memorizzazione nella cache per il tuo backend.

Esistono diversi modi per controllare le intestazioni di risposta:

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

Se confronti queste intestazioni con i requisiti dei contenuti cacheabili, noterai 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 stai eseguendo un server web su Compute Engine, consulta la documentazione del software del server web per informazioni dettagliate sulla configurazione delle intestazioni di risposta. Per Cloud Storage, se contrassegni l'oggetto come condiviso pubblicamente, vengono inviate le intestazioni appropriate.

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

Inoltre, se gli ETag sono attivati nelle istanze di backend, Cloud CDN si basa sugli ETag per confermare l'aggiornamento dell'oggetto. Se le istanze di backend pubblicano ETag diversi sullo stesso oggetto, Cloud CDN conteggia le mancate corrispondenze come una mancata corrispondenza della cache e aggiorna l'oggetto. Per evitare ciò, le istanze di backend devono restituire lo stesso ETag o gli ETag devono essere disattivati.

Per verificare, esegui curl più volte e controlla le modifiche al 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

Non è possibile accedere agli oggetti Cloud Storage

Per fornire l'accesso agli oggetti in Cloud Storage, devi configurare gli 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 come segue.

Console

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

    Apri il browser di archiviazione

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

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

    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 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 sai perché il server di origine ha pubblicato contenuti privati o errati e puoi risolvere il problema, puoi invalidare le cache di Cloud CDN seguendo questa 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 ulteriori informazioni, consulta la panoramica dell'invalidazione della cache.

Cloud CDN memorizza nella cache solo le risposte con contenuti memorizzabili nella cache e le serve dalla cache solo fino alla data e all'ora di scadenza specificate nella risposta. Se non sai perché i contenuti sono stati memorizzati nella cache o non riesci a risolvere il problema in modo pratico, ti consigliamo di disattivare Cloud CDN finché non riesci a comprendere e risolvere il problema, quindi di riattivarlo. Per ulteriori informazioni su quali contenuti vengono memorizzati nella cache e per quanto tempo, consulta la panoramica della memorizzazione nella cache.

La percentuale di hit della cache è bassa

Per le prestazioni e la scalabilità, è importante ottimizzare i rapporti di hit della cache. Se riscontri un rapporto di hit della cache inferiore alle aspettative, assicurati di seguire le best practice per ottimizzare il rapporto di hit della cache.

Utilizza la seguente tabella per comprendere alcuni dei possibili motivi di un basso rapporto di hit della cache e le potenziali correzioni.

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

Se devi passare parametri a JavaScript in esecuzione su una pagina altrimenti memorizzabile nella cache, ti consigliamo di utilizzare gli identificatori di frammento anziché le stringhe di query.
La cache è suddivisa in modo non necessario a causa del campo dell'intestazione Vary. Il campo dell'intestazione Vary in una risposta descrive quali parti di un messaggio di richiesta (a parte il metodo, il campo dell'intestazione Vary e il target della richiesta) potrebbero influire sul processo del server di origine per la selezione e la rappresentazione di una risposta.Host Ad esempio, potresti voler utilizzare l'intestazione Vary: Accept-Encoding se pubblichi contenuti diversi per i client che possono gestire le risposte compresse e per quelli che non possono. Utilizza l'intestazione di risposta Vary solo quando necessario.
Non utilizzi chiavi di cache personalizzate. Per impostazione predefinita, Cloud CDN utilizza l'URL richiesta completo per generare la chiave della 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 della cache personalizzata che omette il campo host. Utilizza chiavi di cache personalizzate, se necessario.

Esistono più riempimenti della cache per gli stessi contenuti

In generale, puoi ridurre il numero di compilazioni della cache aumentando i tempi di scadenza delle risposte memorizzabili nella cache. A parità di 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 ulteriori informazioni sulle date di scadenza, consulta Date 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 vecchie voci della cache vengono regolarmente eliminate per fare spazio ai nuovi contenuti. Di conseguenza, si prevedono più riempimenti della cache per risorsa durante il normale funzionamento.

La compressione non funziona

Cloud CDN offre la compressione dinamica per le origini che non possono comprimere le risposte. Ove possibile, consigliamo di utilizzare la compressione all'origine perché riduce i costi di compilazione della cache.

Se le risposte pubblicate 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 delle applicazioni esterno, aggiungono un'intestazione Via a ogni richiesta come richiesto dalla specifica HTTP. Per attivare la compressione, potrebbe essere necessario eseguire l'override della configurazione predefinita del server web per indicargli di comprimere le risposte anche se la richiesta conteneva 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.

Per consentire alla compressione di nginx di funzionare 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 con 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 di tipo byte_range_caching_aborted

Quando Cloud CDN assembla una risposta da più richieste di intervalli di byte, controlla 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à inviati al client, interrompe la risposta.

Se noti risposte di interruzione impreviste, voci di log di Cloud Logging con statusDetails byte_range_caching_aborted o le tue 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 dalla data e dall'ora di 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 web server determina i valori ETag e Last-Modified, consulta la documentazione del software del web server.

Risoluzione dei problemi relativi ai cookie firmati

I seguenti problemi possono verificarsi quando utilizzi 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 gli URL di base64. La codifica Base64 standard non va a buon fine quando i caratteri generati non sono sicuri per gli URL. Sono accettati spaziatura interna.

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 della chiave valido per il servizio di backend o il bucket di backend in uso da Cloud CDN.

  • Non firmare i parametri di query 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, ovvero URLPrefix, Expires, KeyName e il valore Signature stesso, siano le ultime sezioni delimitate da : del cookie.

  • Assicurati che URLPrefix, Expires, KeyName e Signature si verifichino 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 che richiedi ai tuoi clienti di inviare, perché molti server web hanno anche limiti massimi per le intestazioni delle richieste.

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

  • Assicurati che il timestamp Expires dei cookie che stai emettendo non sia singolarmente breve. I periodi di validità inferiori a uno o due minuti potrebbero essere soggetti a problemi di sfasamento dell'orologio tra l'app che emette la fattura e l'infrastruttura CDN cloud.

  • 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 includa 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 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 carattere /, non devono contenere ? o # e devono avere un solo carattere *, che deve essere un carattere finale dopo un /.

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

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

Problemi noti

  • Gli annullamenti convalida della cache sono limitati a un annullamento convalida per mappatura URL per minuto.

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

    Per ulteriori informazioni sulla limitazione della frequenza di aggiornamento dell'invalidazione della cache, consulta Limitazioni.