Panoramica della memorizzazione nella cache

Una risposta memorizzabile nella cache è una risposta HTTP che Cloud CDN può memorizzare e recuperare rapidamente, consentendo tempi di caricamento più rapidi. Non tutte le risposte HTTP sono memorizzabili nella cache.

Modalità cache

Con le modalità cache puoi controllare i fattori che determinano se Cloud CDN memorizza o meno i tuoi contenuti nella cache.

Cloud CDN offre tre modalità cache che determinano come le risposte vengono memorizzate nella cache, se Cloud CDN rispetta le direttive di memorizzazione nella cache inviate dall'origine e come vengono applicati i TTL della cache.

Le modalità di cache disponibili sono riportate nella tabella seguente:

Le risposte di errore possono essere memorizzate nella cache anche in assenza di direttive di cache valide.

Prima di impostare la modalità cache su FORCE_CACHE_ALL, tieni presente i seguenti comportamenti:

• Per gli URL o i cookie firmati, FORCE_CACHE_ALL sostituisce la data di scadenza massima specificata tramite l'impostazione Data di scadenza massima della voce della cache nella console Google Cloud o l'opzione gcloud --signed-url-cache-max-age.

• FORCE_CACHE_ALL modifica la durata (TTL) di qualsiasi contenuto memorizzato nella cache in precedenza. Questa modifica può causare il fatto che alcune voci precedentemente considerate aggiornate (a causa di TTL più lunghi dagli intestazioni di origine) vengano considerate obsolete e che alcune voci precedentemente considerate obsolete vengano considerate aggiornate.

• FORCE_CACHE_ALL sostituisce le direttive di memorizzazione nella cache (Cache-Control e Expires), ma non sostituisce le altre intestazioni di risposta dell'origine. In particolare, un Vary header potrebbe eliminare la memorizzazione nella cache anche se la modalità cache è FORCE_CACHE_ALL. Per maggiori informazioni, consulta la sezione Intestazioni Vary.

Per le istruzioni di configurazione, vedi Impostare la modalità cache.

Contenuti statici

I contenuti statici sono sempre gli stessi, anche se acceduti da diversi utenti. In genere, i CSS utilizzati per dare stile al sito, il codice JavaScript per fornire interattività, i video e i contenuti delle immagini non cambiano per ogni utente per un determinato URL (chiave della cache) e quindi beneficiano della memorizzazione nella cache nella rete perimetrale globale di Cloud CDN.

Quando imposti la modalità cache su CACHE_ALL_STATIC e una risposta non contiene direttive di memorizzazione nella cache esplicite nelle intestazioni Cache-Control o Expires, Cloud CDN memorizza automaticamente la risposta per quanto segue:

• Asset web, inclusi CSS (text/css), JavaScript (application/javascript) e tutti i caratteri web, incluso WOFF2 (font/woff2)
• Immagini, inclusi JPEG (image/jpg) e PNG (image/png)
• Video, inclusi H.264, H.265 e MP4 (video/mp4)
• File audio, inclusi MP3 (audio/mpeg) e MP4 (audio/mp4)
• Documenti formattati, inclusi i PDF (application/pdf)

La tabella seguente offre un riepilogo.

Cloud CDN ispeziona l'intestazione di risposta HTTP Content-Type, che riflette il tipo MIME dei contenuti pubblicati.

Tieni presente quanto segue:

• Il software del server web di origine deve impostare Content-Type per ogni risposta. Molti server web impostano automaticamente l'intestazione Content-Type, tra cui NGINX, Varnish e Apache.

• Cloud Storage imposta l'intestazione Content-Type automaticamente quando utilizzi la console Google Cloud o l'Google Cloud CLI per caricare i contenuti.

• Cloud Storage fornisce sempre un'intestazione Cache-Control a Cloud CDN. Se non viene scelto esplicitamente alcun valore, viene inviato un valore predefinito. Di conseguenza, tutte le risposte di Cloud Storage andate a buon fine vengono memorizzate nella cache in base ai valori predefiniti di Cloud Storage, a meno che non aggiusti esplicitamente i metadati di controllo della cache per gli oggetti in Cloud Storage o utilizzi la modalità FORCE_CACHE_ALL per eseguire l'override dei valori inviati da Cloud Storage.

• Se vuoi memorizzare nella cache i tipi di contenuti text/html e application/json, devi impostare intestazioni Cache-Control esplicite nella risposta, facendo attenzione a non memorizzare accidentalmente nella cache i dati di un utente e a servirli a tutti gli utenti.

Se una risposta è memorizzabile nella cache in base al tipo MIME, ma ha un'intestazione di risposta Cache-Control private o no-store o un'intestazione Set-Cookie, non viene memorizzata nella cache. Per saperne di più, consulta le regole di cacheabilità.

Altri tipi di contenuti, come HTML (text/html) e JSON (application/json), non vengono memorizzati nella cache per impostazione predefinita per le risposte riuscite. Questi tipi di risposte sono in genere dinamiche (per utente). Alcuni esempi sono i carrelli degli acquisti, le pagine dei prodotti con personalizzazione utente e le risposte dell'API autenticate. Tuttavia, la memorizzazione nella cache negativa, se attivata, può comunque causare la memorizzazione nella cache per determinati codici di stato.

Cloud CDN non utilizza le estensioni dei file nel percorso dell'URL per determinare se una risposta è memorizzabile nella cache perché molte risposte memorizzabili nella cache valide non sono riportate negli URL.

Contenuti memorizzabili nella cache

Cloud CDN memorizza nella cache le risposte che soddisfano tutti i requisiti di questa sezione. Alcuni di questi requisiti sono specificati dalla RFC 7234, mentre altri sono specifici di Cloud CDN.

Cloud CDN potrebbe modificare periodicamente l'insieme esatto di condizioni in base alle quali memorizza in cache i contenuti. Se vuoi impedire esplicitamente a Cloud CDN di memorizzare nella cache i tuoi contenuti, segui le linee guida riportate in RFC 7234 per determinare come specificare una risposta non memorizzabile in cache garantita. Consulta anche la sezione Contenuti non memorizzabili nella cache in base alle intestazioni di origine.

Cloud CDN memorizza le risposte nella cache se si verificano tutte le seguenti condizioni.

Per i bucket di backend Cloud Storage, segui questi suggerimenti aggiuntivi:

• Rendi pubblicamente leggibile il bucket. Questo è l'approccio che consigliamo per i contenuti pubblici. Con questa impostazione, chiunque su internet può visualizzare ed elencare gli oggetti e i relativi metadati, esclusi gli ACL. La prassi consigliata è di dedicare secchi specifici per gli oggetti pubblici.

• Utilizza le cartelle gestite per rendere pubblicamente leggibile una parte del bucket.

• Rendi singolarmente leggibili gli oggetti. Sconsigliamo questo approccio perché utilizza un sistema di autorizzazioni legacy specifico per Cloud Storage.

• Non archiviare l'oggetto in un bucket in cui è attiva l'opzione Chiedi al richiedente di pagare o che si trova all'interno di un perimetro di servizio Virtual Private Cloud.

• Non criptare l'oggetto utilizzando le chiavi di crittografia gestite dal cliente o le chiavi di crittografia fornite dal cliente.

Per impostazione predefinita, quando un oggetto è pubblico e non specifica i metadati Cache-Control, Cloud Storage assegna all'oggetto un'intestazione Cache-Control: public, max-age=3600. Puoi impostare valori diversi utilizzando i metadati Cache-Control.

Per un esempio che mostra come configurare un bilanciatore del carico delle applicazioni esterno con un bucket di backend, consulta Configurazione di Cloud CDN con un bucket di backend.

Dimensioni massime

Cloud CDN applica una dimensione massima per ogni risposta. Qualsiasi risposta con un corpo più grande delle dimensioni massime non viene memorizzata nella cache, ma viene comunque inviata al client.

La dimensione massima varia a seconda che il server di origine supporti le richieste di intervallo di byte.

Quasi tutti i server web moderni (inclusi NGINX, Apache e Varnish) supportano le richieste con intervallo di byte.

Contenuti non memorizzabili nella cache in base alle intestazioni dell'origine

Esistono controlli che bloccano la memorizzazione nella cache delle risposte. Cloud CDN potrebbe modificare periodicamente l'insieme esatto di condizioni in base alle quali memorizza i contenuti, quindi, se vuoi impedire esplicitamente a Cloud CDN di memorizzare i tuoi contenuti nella cache, segui le linee guida dello standard (RFC 7234) per determinare come specificare una risposta non memorizzabile in cache garantita.

Cloud CDN non memorizza nella cache una risposta se non soddisfa i requisiti per i contenuti memorizzabili nella cache o se una delle seguenti condizioni è vera.

Se è presente Cache-Control: no-store o private, ma i contenuti vengono comunque memorizzati nella cache, il motivo è uno dei seguenti:

• La firma dell'URL è configurata.
• La modalità cache di Cloud CDN è impostata per forzare la memorizzazione nella cache di tutte le risposte.

Impedire la memorizzazione nella cache

Per impedire la memorizzazione nella cache delle informazioni private nelle cache di Cloud CDN, procedi nel seguente modo:

1. Assicurati che la modalità cache di Cloud CDN non sia impostata suFORCE_CACHE_ALL, che memorizza nella cache incondizionatamente tutte le risposte positive.
2. Includi un'intestazione Cache-Control: private nelle risposte che non devono essere memorizzate nelle cache di Cloud CDN o un'intestazione Cache-Control: no-store nelle risposte che non devono essere memorizzate in nessuna cache, nemmeno nella cache di un browser web.
3. Non firmare URL che forniscono accesso a informazioni private. Quando si accede ai contenuti utilizzando un URL firmato, questi sono potenzialmente idonei per la memorizzazione nella cache, indipendentemente dalle eventuali direttive Cache-Control nella risposta.
4. Per le richieste di origine (compilazione della cache) che includono l'intestazione di richiesta Authorization, Cloud CDN memorizza nella cache solo le risposte che includono le direttive di controllo della cache public, must-revalidate o s-maxage quando la modalità cache è impostata su USE_ORIGIN_HEADERS o CACHE_ALL_STATIC. In questo modo si impedisce di memorizzare erroneamente nella cache i contenuti per utente e quelli che richiedono l'autenticazione. La modalità cache FORCE_CACHE_ALL non presenta questa limitazione.

Intestazioni delle risposte personalizzate

Con le intestazioni delle risposte personalizzate, puoi specificare le intestazioni aggiunte dal bilanciatore del carico delle applicazioni classico alle risposte inviate tramite proxy. Le intestazioni delle risposte personalizzate ti consentono di riflettere lo stato della cache ai tuoi clienti, ai dati geografici dei clienti e alle tue intestazioni delle risposte statiche.

Per le istruzioni, consulta Configurare le intestazioni di risposta personalizzate.

Chiavi cache

Ogni voce della cache in una cache Cloud CDN è identificata da una chiave della cache. Quando una richiesta arriva nella cache, questa converte l'URI della richiesta in una chiave cache e la confronta con le chiavi delle voci memorizzate nella cache. Se trova una corrispondenza, la cache restituisce l'oggetto associato a quella chiave.

Per i servizi di backend, Cloud CDN utilizza per impostazione predefinita l'URI della richiesta completa come chiave della cache. Ad esempio, https://example.com/images/cat.jpg è l'URI completo di una determinata richiesta per l'oggetto cat.jpg. Questa stringa viene utilizzata come chiave della cache predefinita. Solo le richieste con questa stringa esatta corrispondono. Le richieste per http://example.com/images/cat.jpg o https://example.com/images/cat.jpg?user=user1 non corrispondono.

Per i bucket di backend, l'impostazione predefinita prevede che la chiave cache sia costituita dall'URI senza protocollo o host. Per impostazione predefinita, solo parametri di ricerca noti a Cloud Storage sono inclusi nella chiave cache (ad esempio, "generation").

Pertanto, per un determinato bucket di backend, i seguenti URI risolvono nello stesso oggetto memorizzato nella cache:

• http://example.com/images/cat.jpg
• https://example.com/images/cat.jpg
• https://example.com/images/cat.jpg?user=user1
• http://example.com/images/cat.jpg?user=user1
• https://example.com/images/cat.jpg?user=user2
• https://media.example.com/images/cat.jpg
• https://www.example.com/images/cat.jpg

Puoi modificare le parti dell'URI utilizzate nella chiave della cache. Anche se il nome file e il percorso devono sempre far parte della chiave, puoi includere o omettere qualsiasi combinazione di protocollo, host o stringa di query durante la personalizzazione della chiave cache. L'articolo Utilizzo delle chiavi di cache descrive come personalizzare le chiavi di cache.

Oltre a includere o omettere l'intera stringa di query, puoi utilizzare alcune parti della stringa di query utilizzando gli elenchi di inclusione e di esclusione.

Elenco di inclusione della stringa di query

Puoi controllare in modo selettivo i parametri della stringa di query che Cloud CDN incorpora nelle chiavi cache. Ad esempio, se crei un elenco di inclusioni diuser, https://example.com/images/cat.jpg?user=user1&color=blue crea una chiave della cache di https://example.com/images/cat.jpg?user=user1 che corrisponde anche a https://example.com/images/cat.jpg?user=user1&color=red.

Per utilizzare questa opzione, devi includere la stringa di query, specificare un elenco di inclusione non vuoto e non specificare un elenco di esclusione.

Elenco di inclusione della stringa di query per le chiavi cache di Cloud Storage

L'inclusione parametri di ricerca dell'URL nelle chiavi cache per i bucket Cloud Storage contribuisce a supportare la rimozione della cache. La rimozione della cache consente a un utente di recuperare una nuova versione del file che è stato caricato, anche se la versione precedente è ancora memorizzata nella cache in base all'impostazione TTL.

Puoi utilizzare un elenco di inclusione con i parametri della stringa di query nella chiave cache utilizzata per la pubblicazione delle risposte da un bucket di backend. Anche se Cloud Storage non pubblica contenuti o percorsi diversi in base ai parametri di ricerca, puoi scegliere di includere parametri che ti consentano di svuotare la cache dei contenuti statici archiviati nei bucket Cloud Storage.

Ad esempio, puoi aggiungere un parametro di query ?version=VERSION o ?hash=HASH basato sui contenuti sottostanti. Ciò limita la necessità di invalidare proattivamente i contenuti e si allinea ai flussi di lavoro di sviluppo web moderni, in cui gli URL e i framework web utilizzano un hash dei contenuti per evitare di pubblicare oggetti obsoleti nei vari implementazioni.

Poiché l'inclusione dei parametri di ricerca nella chiave della cache è facoltativa, Cloud CDN non supporta l'esclusione dei parametri di ricerca da una chiave della cache in un bucket di backend.

Elenco esclusioni stringa di query

Puoi controllare in modo selettivo i parametri della stringa di query ignorati da Cloud CDN utilizzando un elenco di esclusione. Ad esempio, se crei un elenco di esclusione di user, tutti i parametri della stringa di query tranne user vengono utilizzati nella chiave della cache.

Con l'elenco di esclusione configurato e un input di https://example.com/images/cat.jpg?user=user1&color=blue, Cloud CDN crea una chiave della cache di https://example.com/images/cat.jpg?color=blue che corrisponde anche a https://example.com/images/cat.jpg?user=user2&color=blue, ma non a https://example.com/images/cat.jpg?user=user1&color=red.

Per utilizzare questa opzione, devi includere la stringa di query, specificare un elenco di esclusione non vuoto e non specificare un elenco di inclusione.

Ordine dei parametri di query

La chiave della cache generata non dipende dall'ordine dei parametri di ricerca.

Ad esempio, i seguenti parametri di ricerca generano la stessa chiave della cache:

• info=123&variant=13e&geography=US
• geography=US&variant=13e&info=123

Impostazioni delle chiavi cache per le intestazioni HTTP e i cookie HTTP

Puoi migliorare le percentuali di successo della cache e lo sgravio dell'origine con le seguenti impostazioni di configurazione della chiave della cache.

• Per i servizi e i bucket di backend: utilizza le intestazioni HTTP come parte delle chiavi cache includendo le intestazioni con nome nella configurazione della chiave cache.
• Solo per i servizi di backend: utilizza i cookie HTTP denominati come chiavi della cache, ad esempio per i test A/B (multivariati), le implementazioni canary e scenari simili.

Le richieste in cache che includono intestazioni HTTP o cookie HTTP aggiuntivi nella richiesta vengono memorizzate nella cache alla terza richiesta in una posizione della cache per quella chiave cache. In questo modo si riduce l'impatto dei valori di cookie o intestazioni ad alta cardinalità sui tassi di espulsione della cache. In circostanze normali e in condizioni di traffico utente, questo non dovrebbe essere evidente e contribuisce a garantire che i contenuti popolari rimangano memorizzati nella cache.

Intestazioni delle richieste incluse

Per memorizzare nella cache altre varianti di una risposta, puoi includere altre intestazioni di richiesta nella chiave cache.

Alcune intestazioni non sono consentite nelle chiavi della cache perché hanno tipicamente una cardinalità molto elevata. Nella maggior parte dei casi, i valori di queste intestazioni sono unici per utente (Cookie,Authorization) o hanno migliaia di valori probabili (Referer, User-Agent, Accept). Ad esempio, l'intestazione User-Agent può avere oltre 5000 valori univoci, data la grande varietà di browser, dispositivi utente e sistemi operativi. Questi tipi di intestazioni avrebbero un impatto negativo grave sui tassi di successo della cache.

In base al documento RFC 7230, sono accettati solo nomi di campi di intestazione HTTP validi. I nomi dei campi delle intestazioni non fanno distinzione tra maiuscole e minuscole e i duplicati vengono rifiutati.

Facoltativamente, puoi configurare il server di origine in modo da includere le intestazioni di richiesta della chiave della cache configurata nella risposta Vary. Non è obbligatorio per Cloud CDN, ma può essere utile per le cache a valle. Per ulteriori informazioni, consulta la sezione Intestazioni Vary.

Cloud CDN non consente di includere le seguenti intestazioni nell'elenco di intestazioni:

• Accept
• Accept-Encoding
• Authority, perché è controllato dalla configurazione (cdnPolicy.includeHost)
• Authorization, in genere per utente, come nei token OAuth Bearer
• CDN-Loop
• Connection
• Content-MD5
• Content-Type
• Cookie
• Date
• Forwarded, spesso per client o per proxy
• From
• Host, perché è controllato dalla configurazione (cdnPolicy.includeHost)
• If-Match, If-Modified-Since o If-None-Match
• Origin
• Proxy-Authorization
• Range
• Referer (o Referrer)
• User-Agent
• Want-Digest
• X-CSRFToken e X-CSRF-Token come utilizzati da Django e Ruby on Rails
• X-Forwarded-For, spesso per client o per proxy
• X-User-IP
• Qualsiasi intestazione che inizia con quanto segue:
  • Access-Control-, ad esempio Access-Control-Request-Headers e Access-Control-Request-Method
  • Sec-Fetch-
  • Sec-GFE-
  • Sec-Google-
  • X-Amz-
  • X-GFE-
  • X-Goog-
  • X-Google-

Stessa intestazione con valori diversi

Supponiamo che l'utente invii più intestazioni con lo stesso nome e valori diversi, ad esempio:

My-Header: Value1
My-Header: Value2

In questo caso, Cloud CDN modifica la richiesta assumendo che l'intestazione debba seguire la convenzione standard che consente ad alcune intestazioni di avere più valori. Cloud CDN li comprime in un elenco separato da virgole per inviarli al backend, quindi è come se il client avesse inviato quanto segue:

My-Header: Value1, Value2

Inclusi i cookie denominati

Un cookie HTTP è un accoppiamento name=value e una richiesta può includere più cookie HTTP, separati da un punto e virgola nella stessa riga o come intestazioni di richiesta Cookie distinte con un cookie per intestazione.

Puoi fornire un elenco di massimo cinque nomi di cookie.

Gli user agent (come i browser web) spesso limitano il numero di cookie memorizzati per dominio a 4 KB. Assicurati di non inviare troppi cookie (o cookie di dimensioni troppo grandi), poiché l'user agent potrebbe non inviare tutti i cookie in una richiesta. Ciò può influire sul fatto che un utente riceva una risposta specifica memorizzata nella cache.

Se pubblichi i contenuti statici da un nome host diverso da quello da cui emetti i cookie, assicurati che l'attributo Domain del cookie (e l'attributo Path) consenta l'invio del cookie insieme alle richieste per i contenuti statici.

Se una richiesta include più istanze dello stesso nome di cookie, viene rispettata solo la prima.

Istruzioni di controllo cache

Le direttive di controllo della cache HTTP influiscono sul comportamento di Cloud CDN, come indicato nella tabella seguente.

N/A indica che un'istruzione non è applicabile a una richiesta o a una risposta.

Ove possibile, Cloud CDN si impegna a essere conforme allo standard RFC (HTTP RFC 7234), ma favorisce l'ottimizzazione per lo scambio della cache e riduce al minimo l'impatto che i client possono avere sul tasso di hit e sul carico complessivo dell'origine.

Per le risposte che utilizzano l'intestazione Expires HTTP/1.1:

• Il valore dell'intestazione Expires deve essere una data HTTP valida come definito nel documento RFC 7231.
• Un valore della data passato, una data non valida o un valore 0 indica che i contenuti sono già scaduti e richiedono una nuova convalida.
• Se nella risposta è presente un'intestazione Cache-Control, Cloud CDN ignora l'intestazione Cache-Control.Expires

La presenza di un'intestazione Expires futura valida nella risposta consente di memorizzare la risposta nella cache e non richiede la specifica di altre direttive di cache.

L'intestazione Pragma HTTP/1.0, se presente in una risposta, viene ignorata e passata così com'è al client. Le richieste client con questa intestazione vengono comunicate all'origine e non influiscono sulla modalità di invio di una risposta da parte di Cloud CDN.

Intestazioni Vary

L'intestazione Vary indica che la risposta varia in base alle intestazioni di richiesta del client. Oltre all'URI della richiesta, Cloud CDN rispetta le intestazioni Vary incluse dai server di origine nelle risposte. Ad esempio, se una risposta specifica Vary: Accept, Cloud CDN utilizza una voce della cache per le richieste che specificano Accept: image/webp,image/*,*/*;q=0.8 e un'altra per le richieste che specificano Accept: */*.

La tabella nella sezione Contenuti non cacheabili elenca le intestazioni Vary che consentono la memorizzazione nella cache dei contenuti. Altri valori di intestazione Vary impediscono la memorizzazione nella cache dei contenuti.

La modalità cache FORCE_CACHE_ALL non sostituisce questo comportamento. Le intestazioni Vary sono importanti per evitare l'avvelenamento della cache tra più possibili risposte del server di origine. Sarebbe pericoloso per FORCE_CACHE_ALL causare la memorizzazione nella cache di queste risposte.

Le intestazioni Vary vengono talvolta utilizzate per la pubblicazione di contenuti compressi. Cloud CDN non comprime o decomprime le risposte (a meno che non sia attivata la compressione dinamica), ma può pubblicare le risposte compresse dal server di origine. Se il server di origine sceglie se pubblicare contenuti compressi o non compressi in base al valore dell'intestazione di richiesta Accept-Encoding, assicurati che la risposta specifichi Vary: Accept-Encoding.

Quando utilizzi le intestazioni HTTP nella chiave della cache, Cloud CDN memorizza nella cache più copie della risposta in base ai valori delle intestazioni di richiesta specificate, in modo simile al supporto di Vary, ma senza che il server di origine debba specificare esplicitamente un'intestazione di risposta Vary. Se l'origine specifica le intestazioni cache-key nella risposta Vary, Cloud CDN tratta la risposta correttamente, come se le intestazioni non fossero menzionate nella risposta Vary.

Tempi di scadenza e richieste di convalida

La data e l'ora di scadenza di una voce della cache ne definiscono la durata. Il valore fornito dal valore s-maxage (o max-age o expires) consente la convalida automatica dei contenuti memorizzati nella cache obsoleti e generati dagli utenti.

Quando Cloud CDN riceve una richiesta, cerca la voce della cache corrispondente e ne controlla la data di creazione. Se la voce della cache esiste ed è sufficientemente aggiornata, la risposta può essere inviata dalla cache. Se il tempo di scadenza è trascorso, Cloud CDN tenta di convalidare nuovamente la voce della cache contattando uno dei tuoi backend. Questo viene fatto prima di inviare la risposta, a meno che non attivi la funzionalità pubblicazione mentre non è aggiornata, nel qual caso la convalida viene eseguita in modo asincrono.

Per alcune modalità di cache, puoi impostare i valori TTL. Per ulteriori informazioni, consulta Utilizzare le impostazioni e gli override TTL.

La modalità della cache influisce sul modo in cui viene determinata l'aggiornamento.

Se sono presenti più di uno, Cache-Control: s-maxage ha la precedenza su Cache-Control: max-age e Cache-Control: max-age ha la precedenza su Expires.

Per impostazione predefinita, quando il valore della data e dell'ora di scadenza supera 30 giorni (2.592.000 secondi), Cloud CDN tratta il valore di scadenza come se fosse 2.592.000 secondi. I client a valle continuano a vedere i valori accurati di max-age e s-maxage, anche se superano i 30 giorni.

Sfratto

Non vi è alcuna garanzia che una voce della cache rimanga nella cache fino alla scadenza, poiché le voci non popolari possono essere eliminate prima della scadenza in qualsiasi momento per fare spazio a nuovi contenuti. Come limite superiore, le voci della cache a cui non viene eseguito accesso per 30 giorni vengono espulse automaticamente.

Per ulteriori informazioni, consulta Eviction ed eliminazione.

Utilizzare le richieste condizionali per la convalida

Cloud CDN può tentare di utilizzare le informazioni negli intestazioni della risposta memorizzata nella cache per convalidare la voce della cache con il backend. Ciò si verifica quando si verificano entrambe le seguenti condizioni:

• La risposta memorizzata nella cache in precedenza ha un'intestazione Last-Modified o ETag.
• La richiesta del client è una richiesta GET che non contiene intestazioni If-Modified-Since o If-None-Match.

Cloud CDN esegue questa convalida in modo leggermente diverso a seconda che la risposta sia stata memorizzata nella cache utilizzando richieste con intervallo di byte:

• Se la risposta è stata memorizzata nella cache utilizzando richieste con intervallo di byte, Cloud CDN avvia una richiesta di convalida separata che include le intestazioni If-Modified-Since e If-None-Match.
• In caso contrario, Cloud CDN aggiunge le intestazioni If-Modified-Since e If-None-Match alla richiesta del client e inoltra la richiesta modificata al backend.

Se la copia memorizzata nella cache è ancora aggiornata, il backend può convalidare la voce della cache esistente inviando una risposta 304 Not Modified. In questo caso, il backend invia solo le intestazioni di risposta, non il corpo della risposta. Cloud CDN inserisce le nuove intestazioni di risposta nella cache, aggiorna la data e l'ora di scadenza e invia al client le nuove intestazioni di risposta e il corpo della risposta memorizzato nella cache.

Se la risposta memorizzata nella cache in precedenza non ha un Last-Modified o un ETag come intestazione, Cloud CDN ignora la voce della cache scaduta e inoltra la richiesta del client al backend non modificata.

Supporto per le richieste di intervalli di byte

Una risposta che soddisfa i seguenti criteri indica che il server di origine supporta le richieste di intervalli di byte:

• Codice di stato: 200 OK o 206 Partial Content
• Intestazione: Accept-Ranges: bytes
• Intestazione: Content-Length e, per una risposta 206 Partial Content, un valore Content-Range che indica la lunghezza completa dell'oggetto di origine. Ad esempio, Content-length: 0-100/999 è memorizzabile nella cache, mentre Content-length: 0-100/* non lo è.
• Intestazione: Last-Modified e ETag con un validatore avanzato.

Cloud Storage supporta le richieste di intervalli di byte per la maggior parte degli oggetti. Tuttavia, Cloud Storage non supporta le richieste di intervalli di byte per gli oggetti con metadati Content-Encoding: gzip, a meno che la richiesta del client non includa un'intestazione Accept- Encoding: gzip. Se hai oggetti Cloud Storage di dimensioni superiori a 10 MB, assicurati che non abbiano metadati Content-Encoding: gzip. Per informazioni su come modificare i metadati degli oggetti, consulta Visualizzazione e modifica dei metadati degli oggetti.

Il software dei server web più diffusi supporta anche le richieste con intervallo di byte. Per informazioni dettagliate su come attivare l'assistenza, consulta la documentazione del tuo server web. Per maggiori informazioni sulle richieste con intervallo di byte, consulta la specifica HTTP.

Quando un server di origine supporta le richieste con intervallo di byte, la cache di Cloud CDN rifiuta di memorizzare una risposta altrimenti memorizzabile nella cache la prima volta che viene richiesta se una delle seguenti condizioni è vera:

• Il corpo della risposta è incompleto perché il client ha richiesto solo parte dei contenuti.
• Il corpo della risposta è superiore a 1 MB (1.048.576 byte).

In questo caso, se la risposta soddisferebbe altrimenti i normali requisiti di memorizzazione nella cache, la cache registra che il server di origine supporta le richieste di intervallo di byte per quella chiave della cache e inoltra la risposta del server di origine al client.

In caso di fallimento della cache, la cache controlla se il server di origine supporta le richieste di intervallo di byte. Se è noto che le richieste di intervalli di byte sono supportate per la chiave della cache, la cache non inoltra la richiesta del client all'Application Load Balancer esterno. La cache avvia invece le proprie richieste di riempimento della cache per intervalli di byte per le parti mancanti dei contenuti.

Il server di origine restituisce una risposta 206 Partial Content quando Cloud CDN avvia la propria richiesta di riempimento della cache per l'intervallo di byte. Affinché una risposta 206 Partial Content venga considerata durante la memorizzazione nella cache, deve includere un'intestazione Content-Range con un'istruzione complete-length che non includa asterischi, ad esempio 0-100/999. Cloud CDN inserisce quindi nella cache la risposta 206 Partial Content restituita e la utilizza per rispondere alle future richieste del cliente per questi contenuti.

Una cache memorizza una risposta 206 Partial Content solo quando viene ricevuta in risposta a una richiesta di intervallo di byte avviata dalla cache. Poiché una cache non avvia una richiesta di intervallo di byte a meno che non abbia registrato in precedenza che il server di origine supporta le richieste di intervallo di byte per la chiave della cache, una determinata cache non memorizza contenuti di dimensioni superiori a 1 MB fino alla seconda volta che viene eseguito l'accesso ai contenuti.

A causa della sua natura distribuita, a volte Cloud CDN potrebbe recuperare il frammento finale dall'origine più di una volta per località. Questo influisce solo sulle prime richieste per chiave della cache.

Riduzione delle richieste (unione)

Il raggruppamento delle richieste (chiamato anche unione) comprime attivamente più richieste di riempimento della cache basate sugli utenti per la stessa chiave della cache in una singola richiesta di origine per nodo edge. In questo modo è possibile ridurre attivamente il carico sull'origine e si applica sia alle richieste di elementi (risposte recuperate direttamente) sia alle richieste di chunk, in cui Cloud CDN utilizza le richieste Range per recuperare oggetti di dimensioni maggiori in modo più efficiente.

L'aggregazione delle richieste è attiva per impostazione predefinita.

Le richieste raggruppate si comportano nel seguente modo:

• Le richieste compresse registrano sia la richiesta rivolta al client sia la richiesta di compilazione della cache (compressa).
• Il leader della sessione compressa viene utilizzato per effettuare la richiesta di completamento dell'origine.
• Gli attributi della richiesta che non fanno parte della chiave della cache, come l'intestazione User-Agent o Accept-Encoding, riflettono solo il leader della sessione compressa.
• Le richieste che non hanno la stessa chiave della cache non possono essere compresse.

Il seguente diagramma mostra come vengono unite le richieste:

In confronto, con il collasso delle richieste disattivato o per le richieste che non possono essere unite, il numero di richieste e risposte di origine può essere uguale al numero di client che tentano di recuperare un oggetto non memorizzato nella cache.

Per tutti i tipi di richieste, il collasso è abilitato per impostazione predefinita. Per i tipi di richieste di articoli, puoi disattivare il collasso. Ti consigliamo di disattivare il collasso per le richieste di elementi in scenari molto sensibili alla latenza, come la pubblicazione di annunci, dove il caricamento dell'origine non è un fattore da considerare.

La tabella seguente riassume il comportamento predefinito e la configurabilità per diversi tipi di richieste.

Per disattivare il raggruppamento delle richieste di articoli utilizzando Google Cloud CLI per un bucket di backend che fa riferimento a un bucket Cloud Storage:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --no-request-coalescing

Per attivare il raggruppamento delle richieste di articoli in un bucket di backend utilizzando Google Cloud CLI:

gcloud compute backend-buckets update BACKEND_BUCKET_NAME \
    --request-coalescing

Per attivare il raggruppamento delle richieste di articoli utilizzando l'interfaccia a Google Cloud CLI per un servizio di backend, tra cui gruppi di VM e backend esterni:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --request-coalescing

Richieste avviate da Cloud CDN

Quando il server di origine supporta le richieste con intervallo di byte, Cloud CDN può inviare più richieste al server di origine in risposta a una singola richiesta del client. Cloud CDN può avviare due tipi di richieste: richieste di convalida e richieste di intervallo di byte.

Se la risposta che indicava che il server di origine supportava le richieste di intervallo di byte per una determinata chiave della cache è scaduta, Cloud CDN avvia una richiesta di convalida per verificare che i contenuti non siano stati modificati e che il server di origine supporti ancora le richieste di intervallo per i contenuti. Se il server di origine risponde con una risposta 304 Not Modified, Cloud CDN procede a pubblicare i contenuti utilizzando gli intervalli di byte. In caso contrario, Cloud CDN inoltra la risposta del server di origine al client. Puoi controllare le date di scadenza utilizzando le intestazioni di risposta Cache-Control e Expires.

In caso di fallimento della cache, Cloud CDN avvia richieste di riempimento della cache per un insieme di intervalli di byte che si sovrappongono alla richiesta del client. Se alcuni intervalli dei contenuti richiesti dal client sono presenti nella cache, Cloud CDN pubblica tutto ciò che può dalla cache e invia richieste di intervalli di byte solo per gli intervalli mancanti al server di origine.

Ogni richiesta di intervallo di byte avviata da Cloud CDN specifica un intervallo che inizia con un offset che è un multiplo di 2097136 byte. Con la possibile eccezione dell'intervallo finale, ogni intervallo è anche di 2.097.136 byte. Se i contenuti non sono un multiplo di queste dimensioni, l'intervallo finale è inferiore. Le dimensioni e gli offset utilizzati nelle richieste di intervallo di byte potrebbero cambiare in futuro.

Ad esempio, prendiamo in considerazione una richiesta del client per i byte da 1.000.000 a 3.999.999 di contenuti non presenti nella cache. In questo esempio, Cloud CDN potrebbe avviare due richieste GET, una per i primi 2.097.136 byte dei contenuti e un'altra per i secondi 2.097.136 byte. Ciò comporta un riempimento della cache di 4.194.272 byte anche se il client ha richiesto solo 3.000.000 byte.

Quando utilizzi un bucket Cloud Storage come origine, ogni richiesta GET viene fatturata come operazione di classe B separata. Ti vengono addebitati tutti i costi relativi alle richieste GET elaborate da Cloud Storage, incluse le richieste avviate da Cloud CDN. Quando una risposta viene presentata interamente da una cache Cloud CDN, non vengono inviate richieste GET a Cloud Storage e non ti vengono addebitate operazioni di Cloud Storage.

Quando Cloud CDN avvia una richiesta di convalida o una richiesta di intervallo di byte, non include intestazioni specifiche del client come Cookie o User-Agent.

Nel campo httpRequest.userAgent di Cloud Logging, Cloud-CDN-Google indica che Cloud CDN ha avviato la richiesta.

Ignorare la cache

Il bypass della cache consente alle richieste contenenti intestazioni specifiche di bypassare la cache, anche se i contenuti sono stati memorizzati nella cache in precedenza.

Questa sezione fornisce informazioni su come bypassare la cache con le intestazioni HTTP, come Pragma e Authorization. Questa funzionalità è utile quando vuoi assicurarti che i tuoi utenti o clienti abbiano sempre i contenuti più recenti recuperati dal server di origine. Potresti voler eseguire questa operazione per testare, configurare directory di staging o script.

Se un'intestazione specificata corrisponde, la cache viene ignorata per tutte le impostazioni della modalità cache, anche FORCE_CACHE_ALL. Il bypass della cache comporta un numero elevato di mancate hit della cache se le intestazioni specificate sono comuni a molte richieste.

Prima di iniziare

• Assicurati che Cloud CDN sia abilitato. Per istruzioni, consulta Utilizzare Cloud CDN.

• Se necessario, esegui l'aggiornamento alla versione più recente di Google Cloud CLI:

  gcloud components update
  

Configurazione del bypass della cache

Puoi specificare fino a cinque nomi di intestazioni HTTP. I valori non fanno distinzione tra maiuscole e minuscole. Il nome dell'intestazione deve essere un token di campo di intestazione HTTP valido. Un nome di intestazione non deve comparire più di una volta nell'elenco delle intestazioni aggiunte. Per le regole relative ai nomi delle intestazioni validi, consulta Come funzionano le intestazioni personalizzate.

gcloud compute backend-buckets (create | update) BACKEND_BUCKET_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

gcloud compute backend-services (create | update) BACKEND_SERVICE_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

gcloud compute backend-services update my-backend-service
    --bypass-cache-on-request-headers=Pragma
    --bypass-cache-on-request-headers=Authorization

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets

"cdnPolicy": {
  "bypassCacheOnRequestHeaders": [
    {
      "headerName": string
    }
  ]
}

Disattivazione dell'aggiramento della cache

gcloud compute backend-services (create | update) (BACKEND_SERVICE_NAME | BACKEND_BUCKET_NAME)
    --no-bypass-cache-on-request-headers

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE

"cdnPolicy": {
  "fields": "bypassCacheOnRequestHeaders"
}

Passaggi successivi

• Per capire in che modo le modalità di cache semplificano la memorizzazione nella cache dei contenuti, consulta Utilizzare le modalità di cache.
• Per attivare Cloud CDN per le istanze con bilanciamento del carico HTTP(S) e per i bucket di archiviazione, consulta Utilizzare Cloud CDN.
• Per scoprire di più sull'annullamento della convalida delle cache, consulta la Panoramica dell'annullamento della convalida della cache.
• Per trovare i punti di presenza GFE, consulta Località delle cache.