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:

Modalità cache Comportamento
CACHE_ALL_STATIC Memorizza automaticamente nella cache le risposte positive con contenuti statici che non sono in altro modo non memorizzabili nella cache. Anche le risposte provenienti dall'origine, che impostano valide direttive di memorizzazione nella cache, vengono memorizzate nella cache.

Questo è il comportamento predefinito per i backend abilitati per Cloud CDN creati utilizzando l'interfaccia a riga di comando Google Cloud CLI o l'API REST.
USE_ORIGIN_HEADERS Richiede risposte provenienti dall'origine per impostare direttive di memorizzazione nella cache e intestazioni di memorizzazione nella cache valide. Le risposte corrette senza queste direttive vengono inoltrate dall'origine.
FORCE_CACHE_ALL Memorizza incondizionatamente le risposte positive nella cache, ignorando qualsiasi direttiva di memorizzazione nella cache impostata dall'origine. Questa modalità non è appropriata se il backend pubblica contenuti privati per ciascun utente, come risposte dell'API o HTML dinamici.

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 viene ancora rispettato e può eliminare la memorizzazione nella cache anche in presenza di FORCE_CACHE_ALL. Per ulteriori informazioni, consulta Intestazioni Vary.

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

Contenuti statici

I contenuti statici sono sempre gli stessi, anche se vi accedono utenti diversi. In genere, il CSS utilizzato 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.

Categoria Tipi MIME
Asset web text/css text/ecmascript text/javascript application/javascript
Caratteri Qualsiasi Content-Type corrispondente a font/*
Immagini Qualsiasi Content-Type corrispondente a image/*
Video Qualsiasi Content-Type corrispondente a video/*
Audio Qualsiasi Content-Type corrispondente a audio/*
Tipi di documenti formattati application/pdf e application/postscript

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 al caricamento quando utilizzi la console Google Cloud o lGoogle Cloud CLI per caricare i contenuti.

  • Se una risposta è memorizzabile nella cache in base al tipo MIME, ma ha un'intestazione di risposta Cache-Controlprivate o no-store o un'intestazione Set-Cookie (vedi l'elenco completo delle regole), non viene memorizzata nella cache.

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.

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.

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.

Attributo Requisito
Pubblicato da Servizio di backend, bucket di backend o un backend esterno con Cloud CDN abilitato
In risposta a Richiesta GET
Codice di stato

200, 203, 204, 206, 300, 301, 302, 307, 308, 404, 405, 410, 421, 451 o 501.
Aggiornamento

La risposta ha un'intestazione Cache-Control con una direttiva max-age o s-maxage oppure un'intestazione Expires con un timestamp futuro.

Per le risposte memorizzabili nella cache senza età (ad esempio con no-cache), la direttiva public deve essere fornita esplicitamente.

Con la modalità di memorizzazione nella cache CACHE_ALL_STATIC, se non sono presenti direttive di aggiornamento, una risposta positiva con tipo di contenuti statici è comunque idonea per la memorizzazione nella cache.

Con la modalità cache FORCE_CACHE_ALL, qualsiasi risposta riuscita è idonea per la memorizzazione nella cache. Ciò potrebbe comportare la memorizzazione nella cache di contenuti privati per ciascun utente (utente identificabile). Devi impostare FORCE_CACHE_ALL solo sui backend che non forniscono contenuti privati o dinamici, come i bucket Cloud Storage.

Se la memorizzazione nella cache negativa è attivata e il codice di stato corrisponde a uno per il quale la memorizzazione nella cache negativa specifica un TTL, la risposta è idonea per la memorizzazione nella cache, anche senza direttive di aggiornamento esplicite.
Contenuti

Per le origini HTTP/1, la risposta deve contenere un'intestazione Content-Length, Content-Range o Transfer-Encoding: chunked valida.

Per le origini che utilizzano versioni del protocollo HTTP più avanzate (HTTP/2 e versioni successive), la risposta non deve avere queste intestazioni.
Dimensioni Deve essere inferiore o uguale alla dimensione massima.

Per le risposte con dimensioni comprese tra 10 MiB e 100 GiB, consulta i vincoli aggiuntivi di memorizzazione nella cache descritti nelle richieste con intervallo di byte.

Per i bucket di backend Cloud Storage, di seguito sono riportati diversi modi per soddisfare questi requisiti:

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.

Il server di origine supporta le richieste di intervalli di byte Il server di origine non supporta le richieste di intervallo di byte
100 GiB (107.374.182.400 byte) 10 MiB (10.485.760 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.

Attributo Requisito
Pubblicato da Servizio di backend o backend esterno per cui non è attivata Cloud CDN
Cookie Contiene un'intestazione Set-Cookie
Intestazione Vary Ha un valore diverso da Accept, Accept-Encoding, Access-Control-Request-Headers, Access-Control-Request-Method, Origin, Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site, X-Goog-Allowed-Resources, X-Origin o una delle intestazioni configurate per far parte delle impostazioni della chiave della cache.
Direttiva di risposta La risposta ha un'intestazione Cache-Control con la direttiva no-store o private (a meno che non venga utilizzata la modalità cache FORCE_CACHE_ALL, nel qual caso l'intestazione Cache-Control viene ignorata).
Istruzione di richiesta La richiesta contiene una direttiva Cache-Control: no-store
Richiedi autorizzazione La richiesta ha un'intestazione Authorization, a meno che non sia stata soprascritta dall'intestazione Cache-Control della risposta.
Dimensioni Più grande delle dimensioni massime

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 i contenuti 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, vedi 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.

Parte dell'URI Personalizzazione URL di esempio con la stessa chiave della cache
Protocollo Ometti il protocollo dalla chiave della cache.
  • https://example.com/images/cat.jpg
  • http://example.com/images/cat.jpg
Host Ometti l'host dalla chiave della cache.
  • https://example.com/images/cat.jpg
  • https://example2.com/images/cat.jpg
Stringa di query

Ometti la stringa di query dalla chiave cache.

Omettere o includere selettivamente parti della stringa di query.
  • https://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2

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 della 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 distruzione 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 valida nella cache in base all'impostazione TTL.

Puoi includere un elenco di parametri di ricerca specifici 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 il tasso 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 cookie HTTP denominati come chiavi della cache, ad esempio per i test A/B (multivariati), i 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 la chiave cache in questione. 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 possibili (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.

Direttiva Richiesta Risposta
no-store Se presente in una richiesta, Cloud CDN lo rispetta e non memorizza la risposta nella cache.

Una risposta con no-store non viene memorizzata nella cache.

Questo valore può essere ignorato in base al backend con la FORCE_CACHE_ALL modalità cache.

no-cache La direttiva di richiesta no-cache viene ignorata per impedire ai client di potenzialmente avviare o forzare la convalida dell'origine.

Una risposta con no-cache viene memorizzata nella cache, ma deve essere riconvalidata con l'origine prima di essere pubblicata.

Questo valore può essere ignorato in base al backend con la FORCE_CACHE_ALL modalità cache.

public N/D

Questa direttiva non è obbligatoria per la memorizzazione nella cache, ma è una best practice includerla per i contenuti che devono essere memorizzati nella cache dai proxy.

private N/D

Una risposta con la direttiva private non viene memorizzata nella cache da Cloud CDN, anche se la risposta è considerata memorizzabile nella cache. I client (ad esempio i browser) potrebbero comunque memorizzare nella cache il risultato.

Questo valore può essere ignorato in base al backend con la FORCE_CACHE_ALL modalità cache. Utilizza no-store per impedire la memorizzazione nella cache di tutte le risposte.

max-age=SECONDS L'istruzione di richiesta max-age viene ignorata. Viene restituita una risposta memorizzata nella cache come se questa intestazione non fosse inclusa nella richiesta. Una risposta con la direttiva max-age viene memorizzata nella cache fino al valore SECONDS definito.
s-maxage=SECONDS N/D

Una risposta con la direttiva s-maxage viene memorizzata nella cache fino al valore SECONDS definito.

Se sono presenti sia max-age che s-maxage, s‑maxage viene utilizzato da Cloud CDN.

Le risposte con questa direttiva non vengono pubblicate come non aggiornate.

s-max-age (due trattini) non è valido ai fini della memorizzazione nella cache.

min-fresh=SECONDS L'istruzione di richiesta min-fresh viene ignorata. Viene restituita una risposta memorizzata nella cache come se questa intestazione non fosse inclusa nella richiesta. N/D
max-stale=SECONDS

La direttiva di richiesta max-stale indica il valore massimo di obsolescenza (in secondi) che il cliente è disposto ad accettare.

Cloud CDN rispetta questa impostazione e restituisce una risposta memorizzata nella cache obsoleta solo se l'obsolescenza della risposta è inferiore alla direttiva max-stale. In caso contrario, viene convalidato di nuovo prima di soddisfare la richiesta.

 N/D
stale-while-revalidate=SECONDS N/D

Una risposta con stale-while-revalidate viene inviata a un cliente per un massimo di SECONDS mentre la convalida viene eseguita in modo asincrono.

Questo comportamento può essere attivato per tutte le risposte impostando cdnPolicy.serveWhileStale sul backend.

stale-if-error=SECONDS L'istruzione di richiesta stale-if-error viene ignorata. Viene restituita una risposta memorizzata nella cache come se questa intestazione non fosse inclusa nella richiesta.

Questa intestazione di risposta non ha alcun effetto.

must-revalidate N/D

Una risposta con must-revalidate viene convalidata nuovamente con il server di origine dopo la scadenza.

Le risposte con questa direttiva non vengono pubblicate in modo obsoleto.

proxy-revalidate

Una risposta con proxy-revalidate viene convalidata nuovamente con il server di origine dopo la scadenza.

Le risposte con questa direttiva non vengono pubblicate in modo obsoleto.

immutable N/D Nessun effetto. Questo viene trasmesso al client nella risposta.
no-transform N/D Cloud CDN non applica trasformazioni.
only-if-cached L'istruzione di richiesta only-if-cached viene ignorata. Viene restituita una risposta memorizzata nella cache come se questa intestazione non fosse inclusa nella richiesta. N/D

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 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 memorizzabili nella cache 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 delle richieste 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 da 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.

Modalità cache Comportamento di convalida
CACHE_ALL_STATIC Per determinare l'aggiornamento, vengono consultate le intestazioni di origine (Cache-Control: s-maxage, Cache-Control: max-age o Expires). Per i contenuti statici, se le intestazioni di origine non sono presenti, il valore default_ttl configurato determina l'aggiornamento. Quando i contenuti statici risalgono a più di default_ttl, Cloud CDN li convalida di nuovo.
USE_ORIGIN_HEADERS Ogni voce della cache in una cache Cloud CDN ha una data e un'ora di scadenza definite dalle intestazioni Cache-Control: s-maxage, Cache-Control: max-age o Expires in conformità con RFC 7234.
FORCE_CACHE_ALL Anziché le intestazioni di origine, l'default_ttl configurato determina l'aggiornamento. Se i contenuti risalgono a più di default_ttl, Cloud CDN li convalida di nuovo.

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 la 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. Se il server di origine restituisce l'intervallo di byte richiesto in una risposta 206 Partial Content, la cache può memorizzare l'intervallo per le richieste future.

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)

L'aggregazione delle richieste (chiamata 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:

Cloud CDN con il raggruppamento delle richieste abilitato.
Cloud CDN con il collasso delle richieste abilitato (fai clic per ingrandire).

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.

Cloud CDN senza il raggruppamento delle richieste abilitato.
Cloud CDN senza il collasso delle richieste abilitato (fai clic per ingrandire).

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.

Tipo di richiesta Comportamento predefinito Configurabile Vantaggi del collasso
Richieste di chunk Abilitato No Può ridurre notevolmente la larghezza di banda dell'origine
Richieste di articoli Abilitato Sì Può ridurre il volume delle richieste di origine

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

gcloud

Utilizza il comando gcloud compute backend-services o backend-buckets:

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

Utilizza il comando gcloud compute backend-buckets:

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

Utilizza il comando gcloud compute backend-services:

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 indica che il server di origine supporta 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 serve 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 per le 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 per 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 Utilizzo di 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.

Console

  1. Nella console Google Cloud, vai alla pagina Bilanciamento del carico.

    Vai alla pagina Bilanciamento del carico

  2. Fai clic sul nome dell'Application Load Balancer esterno.
  3. Fai clic su Modifica .
  4. In Configurazione backend, seleziona un backend e fai clic su Modifica .
  5. Assicurati che l'opzione Attiva Cloud CDN sia selezionata.
  6. Nella parte inferiore della finestra, fai clic su Configurazioni avanzate.
  7. In Ignora cache per intestazione della richiesta, fai clic su Aggiungi intestazione.
  8. Digita un nome di intestazione, ad esempio Pragma o Authorization.
  9. Fai clic su Aggiorna.
  10. Fai di nuovo clic su Aggiorna.

gcloud

Per i bucket di backend, utilizza il comando gcloud compute backend-buckets create o gcloud compute backend-buckets update con il flag --bypass-cache-on-request-headers.

Per i servizi di backend, utilizza il comando gcloud compute backend-services create o gcloud compute backend-services update con il flag --bypass-cache-on-request-headers.

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

Ad esempio:

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

api

Per i bucket di backend, utilizza la chiamata API Method: backendBuckets.insert, Method: backendBuckets.update o Method: backendBuckets.patch.

Per i servizi di backend, utilizza la chiamata API Metodo: backendServices.insert, Metodo: backendServices.update o Metodo: backendServices.patch.

Ad esempio:

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

Aggiungi il seguente snippet al corpo della richiesta JSON:

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

Disattivazione del bypass della cache

gcloud

Per i bucket di backend, utilizza il comando gcloud compute backend-buckets create o gcloud compute backend-buckets update con il flag --no-bypass-cache-on-request-headers.

Per i servizi di backend, utilizza il comando gcloud compute backend-services create o gcloud compute backend-services update con il flag --no-bypass-cache-on-request-headers.

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

api

Per i bucket di backend, utilizza la chiamata API Method: backendBuckets.insert o Method: backendBuckets.update.

Per i servizi di backend, utilizza la chiamata API Metodo: backendServices.insert o Metodo: backendServices.update.

Utilizza una delle seguenti chiamate API:

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

Aggiungi il seguente snippet al corpo della richiesta JSON:

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

Passaggi successivi