Una risposta memorizzabile nella cache è una risposta HTTP che Cloud CDN può archiviare 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 i tuoi contenuti nella cache.
Cloud CDN offre tre modalità cache che definiscono il modo in cui le risposte vengono memorizzate nella cache, se Cloud CDN rispetta le direttive di cache inviate dall'origine e come vengono applicati i TTL della cache.
Le modalità cache disponibili sono mostrate nella tabella seguente:
Modalità cache | Comportamento |
---|---|
CACHE_ALL_STATIC |
Memorizza automaticamente nella cache le risposte riuscite con
contenuti statici che non sono
altrimenti 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 Google Cloud CLI o l'API REST. |
USE_ORIGIN_HEADERS |
Richiede risposte dell'origine riuscite per impostare istruzioni di cache valide e intestazioni di memorizzazione nella cache valide. Le risposte riuscite senza queste istruzioni vengono inoltrate dall'origine. |
FORCE_CACHE_ALL |
Memorizza nella cache le risposte riuscite in modo incondizionato, eseguendo l'override di eventuali istruzioni di memorizzazione nella cache impostate dall'origine. Questa modalità non è appropriata se il backend pubblica contenuti privati per utente, come risposte HTML dinamiche o API. |
Le risposte di errore possono essere memorizzate nella cache anche in assenza di istruzioni di cache valide.
Prima di impostare la modalità cache su FORCE_CACHE_ALL
, considera i seguenti
comportamenti:
Per URL firmati o cookie firmati,
FORCE_CACHE_ALL
sostituisce l'età massima specificata tramite l'impostazione Età massima delle voci della cache nella console Google Cloud o l'opzionegcloud --signed-url-cache-max-age
.FORCE_CACHE_ALL
modifica la durata (TTL) di eventuali contenuti precedentemente memorizzati nella cache. Questa modifica può far sì che alcune voci precedentemente considerate aggiornate (a causa della presenza di TTL più lunghi dalle intestazioni dell'origine) vengano considerate inattive. Inoltre, alcune voci precedentemente considerate obsolete possono essere considerate come nuove.FORCE_CACHE_ALL
esegue l'override delle istruzioni cache (Cache-Control
eExpires
), ma non di altre intestazioni della risposta dell'origine. In particolare, un'intestazioneVary
viene comunque rispettata e potrebbe eliminare la memorizzazione nella cache anche in presenza diFORCE_CACHE_ALL
. Per ulteriori informazioni, consulta Intestazioni Vary.
Per istruzioni di configurazione, consulta la sezione Impostazione della modalità cache.
Contenuti statici
I contenuti statici sono contenuti sempre uguali, anche se accessibili da utenti diversi. Il CSS che utilizzi per definire lo stile del tuo sito, il codice JavaScript per fornire interattività, contenuti video e immagini, in genere non cambia per ogni utente per un determinato URL (chiave cache) e, di conseguenza, può trarre vantaggio dalla memorizzazione nella cache nella rete perimetrale globale di Cloud CDN.
Quando imposti la modalità cache su CACHE_ALL_STATIC
e una risposta non ha istruzioni di memorizzazione nella cache esplicite nelle intestazioni Cache-Control
o Expires
, Cloud CDN memorizza automaticamente nella cache la risposta per quanto segue:
- Asset web, inclusi CSS (
text/css
), JavaScript (application/javascript
) e tutti i caratteri web, incluso WOFF2 (font/woff2
) - Immagini, incluse JPEG (
image/jpg
) e PNG (image/png
) - Video, inclusi H.264, H.265 e MP4 (
video/mp4
) +. File audio, tra cui MP3 (audio/mpeg
) e MP4 (audio/mp4
) - Documenti formattati, incluso 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 controlla l'intestazione della risposta HTTP Content-Type
, che riflette il tipo MIME
dei contenuti pubblicati.
Tieni presente quanto segue:
Il software del server web della tua origine deve impostare
Content-Type
per ogni risposta. Molti server web impostano automaticamente l'intestazioneContent-Type
, tra cui NGINX, Varnish e Apache.Cloud Storage imposta l'intestazione
Content-Type
automaticamente al caricamento quando utilizzi la console Google Cloud o lo strumentogsutil
per caricare i contenuti.Se una risposta può essere memorizzata nella cache in base al tipo MIME, ma ha un'intestazione
Cache-Control
di rispostaprivate
ono-store
oppure un'intestazioneSet-Cookie
(vedi l'elenco completo delle regole), non viene memorizzata nella cache.
Cloud CDN non utilizza estensioni di file nel percorso dell'URL per determinare se una risposta può essere memorizzata nella cache perché molte risposte valide memorizzabili nella cache non vengono indicate negli URL.
Se vuoi memorizzare nella cache i tipi di contenuto text/html
e application/json
, devi impostare intestazioni Cache-Control
esplicite nella risposta, prestando attenzione a non memorizzare accidentalmente nella cache i dati di un utente e pubblicarli per 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 da RFC 7234 e altri sono specifici di Cloud CDN.
Cloud CDN potrebbe modificare periodicamente l'esatto insieme di condizioni in cui memorizza i contenuti nella cache. Se vuoi impedire esplicitamente a Cloud CDN di memorizzare nella cache i tuoi contenuti, segui le linee guida in RFC 7234 per determinare come specificare una risposta garantita non memorizzabile nella cache. Vedi anche la sezione relativa ai contenuti non memorizzabili nella cache in base alle intestazioni di origine.
Cloud CDN archivia le risposte nella cache se tutte le seguenti condizioni sono vere.
Attributo | Requisito |
---|---|
Servito da | Servizio di backend, bucket di backend o backend esterno con Cloud CDN abilitato |
In risposta a | Richiesta di GET |
Codice di stato |
|
Aggiornamento | La risposta ha un'intestazione Per le risposte memorizzabili nella cache senza un'età (ad esempio, con
Con la modalità cache Con la modalità cache Se la memorizzazione nella cache negativa è abilitata e il codice di stato corrisponde a uno per cui la memorizzazione nella cache negativa specifica un TTL, la risposta è idonea per la memorizzazione nella cache, anche senza istruzioni di aggiornamento esplicite. |
Contenuti | Per le origini HTTP/1, la risposta deve contenere un'intestazione
Per le origini che utilizzano versioni più avanzate del protocollo HTTP (HTTP/2 e versioni successive), la risposta non deve contenere queste intestazioni. |
Dimensioni | Inferiore o uguale alla dimensione massima.
Per le risposte con dimensioni comprese tra 10 MB e 100 GB, consulta i vincoli aggiuntivi di memorizzabilità nella cache descritti in Richieste di intervalli di byte. |
Per i bucket di backend Cloud Storage, esistono diversi modi per soddisfare questi requisiti:
Rendi il bucket leggibile pubblicamente. Questo è l'approccio che consigliamo per i contenuti pubblici. Con questa impostazione, chiunque su internet può visualizzare ed elencare i tuoi oggetti e i relativi metadati, esclusi gli ACL. È consigliabile dedicare bucket specifici per gli oggetti pubblici.
Utilizza le cartelle gestite per rendere pubblicamente leggibile una parte del bucket.
Rendi i singoli oggetti leggibili pubblicamente. Sconsigliamo di utilizzare questo approccio perché utilizza un sistema di autorizzazioni legacy specifico per Cloud Storage.
Per impostazione predefinita, quando un oggetto è pubblico e non specifica metadati Cache-Control
, Cloud Storage assegna un'intestazione Cache-Control: public, max-age=3600
all'oggetto. 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 superiore alla dimensione massima non viene memorizzata nella cache, ma viene comunque recapitata al client.
La dimensione massima varia a seconda che il server di origine supporti o meno le richieste di intervalli di byte.
Il server di origine supporta le richieste di intervallo di byte | Il server di origine non supporta le richieste di intervalli di byte |
---|---|
100 GB (107.374.182.400 byte) | 10 MB (10.485.760 byte) |
Quasi tutti i server web moderni (tra cui NGINX, Apache e Varnish) supportano richieste con intervallo di byte.
Contenuti non memorizzabili nella cache in base alle intestazioni di origine
Esistono dei controlli che bloccano la memorizzazione nella cache delle risposte. Cloud CDN può modificare periodicamente l'insieme esatto di condizioni in cui memorizza i contenuti nella cache, 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 memorizzata nella 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 |
---|---|
Servito da | Servizio di backend o backend esterno in cui non è abilitato Cloud CDN |
Cookie | Ha 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 di cache.
|
Istruzione di risposta | La risposta ha un'intestazione Cache-Control con
istruzione no-store o private (a meno che non venga utilizzata la modalità cache FORCE_CACHE_ALL , in questo caso l'intestazione Cache-Control viene ignorata) |
Istruzione richiesta | La richiesta ha un'istruzione Cache-Control: no-store |
Richiedi autorizzazione | La richiesta ha un'intestazione Authorization , a meno che
non venga sovrascritta dalla risposta
Cache-Control. |
Dimensioni | Più grandi della dimensione massima |
Se è presente Cache-Control: no-store
o private
, ma i contenuti sono ancora in fase di 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.
Prevenire la memorizzazione nella cache
Per evitare che le informazioni private vengano memorizzate nella cache di Cloud CDN, segui questi passaggi:
- Assicurati che la modalità cache di Cloud CDN non sia impostata sulla modalità
FORCE_CACHE_ALL
, che memorizza incondizionatamente tutte le risposte riuscite. - Includi un'intestazione
Cache-Control: private
nelle risposte che non devono essere archiviate nelle cache di Cloud CDN oppure un'intestazioneCache-Control: no-store
nelle risposte che non devono essere archiviate in nessuna cache, nemmeno nella cache di un browser web. - 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 da eventuali istruzioni
Cache-Control
nella risposta. - Per le richieste di origine (riempimento cache) che includono l'intestazione della richiesta
Authorization
, Cloud CDN memorizza nella cache solo le risposte che includono le istruzioni di controllo della cachepublic
,must-revalidate
os-maxage
quando la modalità cache è impostata suUSE_ORIGIN_HEADERS
oCACHE_ALL_STATIC
. In questo modo si impedisce la memorizzazione accidentale nella cache dei contenuti per utente e/o dei contenuti che richiedono l'autenticazione. La modalità cacheFORCE_CACHE_ALL
non ha questa limitazione.
Aggiunta di intestazioni delle risposte personalizzate
Con le intestazioni delle risposte personalizzate, puoi specificare le intestazioni che l'Application Load Balancer classico aggiunge alle risposte inviate tramite proxy. Le intestazioni delle risposte personalizzate consentono di riflettere lo stato della cache per i client, i dati geografici del client e le tue intestazioni di risposta statiche.
Per l'elenco delle intestazioni, consulta Variabili che possono essere visualizzate nel valore dell'intestazione.
Per le istruzioni, vedi Utilizzo delle intestazioni delle risposte personalizzate.
Le intestazioni delle risposte personalizzate non sono supportate per i deployment di Cloud CDN su Application Load Balancer esterni globali.
Chiavi cache
Ogni voce di cache in una cache di Cloud CDN è identificata da una chiave cache. Quando una richiesta arriva nella cache, l'URI della richiesta viene convertito in una chiave cache e quindi lo 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 completo come chiave cache.
Ad esempio, https://example.com/images/cat.jpg
è l'URI completo per una
determinata richiesta per l'oggetto cat.jpg
. Questa stringa viene utilizzata come chiave
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 della cache sia costituita dall'URI senza il protocollo o l'host. Per impostazione predefinita, solo parametri di ricerca noti a Cloud Storage sono inclusi nella chiave cache (ad esempio, "generation").
Di conseguenza, per un determinato bucket di backend, i seguenti URI si 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 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 quando personalizzi la chiave cache. La sezione Utilizzo delle chiavi cache descrive come personalizzare le chiavi cache.
Parte URI | Personalizzazione | URL di esempio che hanno la stessa chiave cache |
---|---|---|
Protocollo | Ometti il protocollo dalla chiave cache. |
|
Host | Ometti l'host dalla chiave cache. |
|
Stringa di query | Ometti la stringa di query dalla chiave cache. Ometti o includi parti della stringa di query in modo selettivo. |
|
Oltre a includere o omettere l'intera stringa di query, puoi utilizzare parti della stringa di query utilizzando gli elenchi di inclusione ed esclusione.
Elenco di inclusione della stringa di query
Puoi controllare selettivamente i parametri della stringa di query che Cloud CDN
incorpora nelle chiavi cache. Ad esempio, se crei un elenco di inclusione di
user
, https://example.com/images/cat.jpg?user=user1&color=blue
crea una chiave 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 il busting della cache. Il busting della cache è il processo che consente a un utente di trovare una nuova versione del file che è stata caricata, anche se la versione precedente è ancora validamente memorizzata nella cache in base a TTL.
Puoi includere parametri di ricerca specifici nella chiave cache utilizzata per gestire le risposte da un bucket di backend. Sebbene Cloud Storage non pubblichi contenuti o route diversi in base ai parametri di ricerca, puoi scegliere di includere parametri che consentono di eseguire il busto della 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 in modo proattivo i contenuti e si allinea ai moderni flussi di lavoro di sviluppo web, in cui i framework web e gli URL utilizzano un hash dei contenuti per evitare di pubblicare oggetti inattivi nei vari deployment.
Poiché l'inclusione dei parametri di ricerca nella chiave cache è solo attivabile, Cloud CDN non supporta l'esclusione dei parametri di ricerca da una chiave cache a un bucket di backend.
Elenco di esclusione della stringa di query
Puoi controllare selettivamente i parametri della stringa di query che Cloud CDN
ignora utilizzando un elenco di esclusione. Ad esempio, se crei un elenco di esclusione di user
, nella chiave cache vengono utilizzati tutti i parametri della stringa di query tranne user
.
Con l'elenco di esclusione configurato e l'input di
https://example.com/images/cat.jpg?user=user1&color=blue
, Cloud CDN
crea una chiave 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 cache generata non dipende dall'ordine dei parametri di ricerca.
Ad esempio, i seguenti parametri di ricerca generano la stessa chiave 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 l'offload dell'origine con le seguenti impostazioni di configurazione delle chiavi cache.
- Per i servizi di backend e i bucket: utilizza le intestazioni HTTP come parte delle chiavi cache includendo intestazioni denominate nella configurazione della chiave cache.
- Solo per i servizi di backend: utilizza cookie HTTP denominati come chiavi cache, ad esempio per test A/B (multivariati), canarying e scenari simili.
Le richieste cache che includono intestazioni HTTP aggiuntive o cookie HTTP nella richiesta vengono memorizzate nella cache alla terza richiesta in una posizione cache per quella chiave cache. Questo riduce l'impatto dei valori di intestazione/cookie ad alta cardinalità sui tassi di eliminazione della cache. In circostanze normali e in condizioni di traffico degli utenti, questo aspetto non dovrebbe essere evidente e garantisce che i contenuti popolari rimangano memorizzati nella cache.
Includere le intestazioni delle richieste
Per memorizzare nella cache ulteriori varianti di una risposta, puoi includere ulteriori intestazioni di richiesta nella chiave cache.
Alcune intestazioni non sono consentite nelle chiavi cache perché hanno
solitamente una cardinalità molto elevata. Nella maggior parte dei casi, i valori di queste intestazioni sono
univoci 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 degli utenti e sistemi operativi. Questi tipi di intestazioni avrebbero
un impatto negativo grave sulle percentuali di successo della cache.
Sono accettati solo nomi di campi di intestazione HTTP validi in base a RFC 7230. 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 delle richieste della chiave cache configurate nella risposta Vary
. Non è obbligatorio per Cloud CDN, ma
può essere utile per le cache downstream. Per maggiori
informazioni, consulta Varia intestazioni.
Cloud CDN non consente l'inclusione delle seguenti intestazioni nell'elenco:
Accept
Accept-Encoding
Authority
, perché questo è controllato dalla configurazione (cdnPolicy.includeHost
)Authorization
, di solito per utente come nei token OAuthBearer
CDN-Loop
Connection
Content-MD5
Content-Type
Cookie
Date
Forwarded
, spesso per client o per proxyFrom
Host
, perché questo è controllato dalla configurazione (cdnPolicy.includeHost
)If-Match
,If-Modified-Since
oIf-None-Match
Origin
Proxy-Authorization
Range
Referer
(oReferrer
)User-Agent
Want-Digest
X-CSRFToken
eX-CSRF-Token
come utilizzati da Django e Ruby on RailsX-Forwarded-For
, spesso per client o per proxyX-User-IP
- Qualsiasi intestazione che inizia con quanto segue:
Access-Control-
, ad esempioAccess-Control-Request-Headers
eAccess-Control-Request-Method
Sec-Fetch-
Sec-GFE-
Sec-Google-
X-Amz-
X-GFE-
X-Goog-
X-Google-
Stesse intestazioni con valori diversi
Supponiamo che l'utente invii più intestazioni con lo stesso nome con valori di intestazione diversi, ad esempio:
My-Header: Value1
My-Header: Value2
In questo caso, Cloud CDN modifica la richiesta presupponendo 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 da inviare al backend, come se il client avesse inviato quanto segue:
My-Header: Value1, Value2
Include i cookie denominati
Un cookie HTTP è un accoppiamento name=value
e una richiesta può includere più cookie HTTP, separati da un punto e virgola sulla stessa riga, o come intestazioni di richiesta Cookie
discrete 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 archiviati per dominio a 4 kB. Assicurati di non inviare troppi cookie (o di dimensioni troppo grandi), poiché lo user agent potrebbe non inviare tutti i cookie in una richiesta. Ciò può influire sulla ricezione o meno di una specifica risposta memorizzata nella cache da parte di un utente.
Se pubblichi contenuti statici da un nome host diverso da cui
emetti i cookie, assicurati che l'attributo Domain
del cookie
(e l'attributo Path
) consenta l'invio del cookie insieme alle richieste
di contenuti statici.
Se una richiesta include più istanze dello stesso nome cookie, viene soddisfatta solo la prima.
Istruzioni di controllo della cache
Le istruzioni di controllo della cache HTTP influiscono sul comportamento di Cloud CDN, come descritto nella tabella seguente.
N/A indica che un'istruzione non è applicabile a una richiesta o risposta.
Direttiva | Richiesta | Risposta |
---|---|---|
no-store |
Quando presente in una richiesta, Cloud CDN rispetta questa condizione e non archivia la risposta nella cache. |
Una risposta con
L'override di questa operazione può essere eseguito a livello di backend con la modalità cache |
no-cache |
L'istruzione della richiesta no-cache viene ignorata per impedire ai client di
avviare o forzare la riconvalida nell'origine.
|
Una risposta con
L'override di questa operazione può essere eseguito a livello di backend con la modalità cache |
public |
N/A |
Questa istruzione non è richiesta ai fini della cache, ma è una best practice includerla per i contenuti che devono essere memorizzati nella cache tramite proxy. |
private |
N/A |
Una risposta con l'istruzione
L'override di questa operazione può essere eseguito a livello di backend con la modalità cache |
max-age=SECONDS
|
L'istruzione della richiesta max-age viene ignorata. Viene restituita una risposta memorizzata nella cache come se questa intestazione non fosse inclusa nella richiesta.
|
Una risposta con l'istruzione max-age viene memorizzata nella cache fino al valore
SECONDS definito.
|
s-maxage=SECONDS
|
N/A |
Una risposta con l'istruzione
Se sono presenti sia Le risposte con questa istruzione non vengono pubblicate obsolete.
|
min-fresh=SECONDS
|
L'istruzione della richiesta min-fresh viene ignorata. Viene restituita una risposta memorizzata nella cache come se questa intestazione non fosse inclusa nella richiesta.
|
N/A |
max-stale=SECONDS
|
L'istruzione della richiesta Cloud CDN rispetta questa condizione e restituisce una risposta memorizzata nella cache inattiva solo se l'inattività della risposta è inferiore a quella dell'istruzione |
N/A |
stale-while-revalidate=SECONDS
|
N/A |
Una risposta con
Questo comportamento può essere abilitato per tutte le risposte impostando
|
stale-if-error=SECONDS
|
L'istruzione della richiesta stale-if-error viene ignorata. Viene restituita una risposta memorizzata nella cache come se questa intestazione non fosse inclusa nella richiesta.
|
Questa intestazione della risposta non ha alcun effetto. |
must-revalidate |
N/A |
Una risposta con Le risposte con questa istruzione non vengono pubblicate obsolete. |
proxy-revalidate |
Una risposta con Le risposte con questa istruzione non vengono pubblicate obsolete. |
|
immutable |
N/A | Nessun effetto. Questo viene trasmesso al client nella risposta. |
no-transform |
N/A | Cloud CDN non applica alcuna trasformazione. |
only-if-cached |
L'istruzione della richiesta only-if-cached viene ignorata. Viene restituita una risposta memorizzata nella cache come se questa intestazione non fosse inclusa nella richiesta.
|
N/A |
Ove possibile, Cloud CDN cerca di essere compatibile con RFC (HTTP RFC7234), ma favorisce l'ottimizzazione per l'offload della cache e la riduzione al minimo dell'impatto che i client possono avere sulla percentuale di hit e/o sul carico dell'origine complessivo.
Per le risposte che utilizzano l'intestazione Expires
HTTP/1.1:
- Il valore dell'intestazione
Expires
deve essere una data HTTP valida come definito in RFC 7231. - Un valore data nel passato, una data non valida o un valore
0
indicano che i contenuti sono già scaduti e devono essere riconvalidati. - Se nella risposta è presente un'intestazione
Cache-Control
, Cloud CDN ignora l'intestazioneExpires
.
La presenza di un'intestazione Expires
futura valida nella risposta consente alla
risposta di essere memorizzata nella cache e non richiede la specifica di altre istruzioni di cache.
L'intestazione HTTP/1.0 Pragma
, se presente in una risposta, viene ignorata e trasmessa al client così com'è. Le richieste dei client con questa intestazione vengono passate all'origine e non influiscono sul modo in cui una risposta viene fornita da Cloud CDN.
Vary
intestazioni
L'intestazione Vary
indica che la risposta varia in base alle intestazioni della richiesta del client. Oltre all'URI della richiesta, Cloud CDN rispetta le intestazioni Vary
che i server di origine includono 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: */*
.
Nella tabella nella sezione Contenuto non memorizzabile nella cache sono elencate 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 ignora 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
fare in modo che
le risposte vengano memorizzate nella cache.
Le intestazioni Vary
vengono a volte utilizzate durante la pubblicazione di contenuti compressi.
Cloud CDN non comprime o decomprime le risposte stesse (a meno che non sia abilitata la compressione dinamica), ma può fornire 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 della richiesta Accept-Encoding
, assicurati che la risposta specifichi Vary: Accept-Encoding
.
Quando utilizzi le intestazioni HTTP nella chiave cache,
Cloud CDN memorizza nella cache più copie della risposta in base ai valori
delle intestazioni delle richieste specificate, in modo simile al supporto Vary
, ma senza
la necessità che il server di origine specifichi esplicitamente qualsiasi intestazione della risposta Vary
.
Se l'origine specifica le intestazioni della chiave cache 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 scadenza di una voce della cache definisce per quanto tempo una voce della cache rimane valida.
Il valore fornito dal valore s-maxage
(o max-age
o expires
) consente
la riconvalida 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. Se la voce della cache esiste ed è sufficientemente aggiornata, la risposta può essere fornita dalla cache. Se la scadenza è trascorsa, Cloud CDN tenta di riconvalidare la voce della cache contattando uno dei tuoi backend. Questo viene fatto prima di inviare la risposta, a meno che non attivi serve-while-stale, nel qual caso la riconvalida viene eseguita in modo asincrono.
Per alcune modalità cache, puoi impostare valori TTL. Per ulteriori informazioni, consulta Utilizzare le impostazioni e gli override TTL.
La modalità cache influisce sul modo in cui viene determinato l'aggiornamento.
Modalità cache | Comportamento di convalida |
---|---|
CACHE_ALL_STATIC |
Viene consultata l'intestazione dell'origine (intestazioni Cache-Control: s-maxage ,
Cache-Control: max-age o Expires ) per determinarne l'aggiornamento. Per i contenuti statici, se le intestazioni di origine non sono presenti, l'elemento default_ttl configurato determina l'aggiornamento. Se i contenuti statici hanno più di default_ttl , Cloud CDN li convalida nuovamente. |
USE_ORIGIN_HEADERS |
Ogni voce di cache in una cache di Cloud CDN ha una scadenza
definita dalle intestazioni Cache-Control: s-maxage ,
Cache-Control: max-age o Expires in
conformità con
RFC 7234. |
FORCE_CACHE_ALL |
Invece delle intestazioni di origine, l'elemento default_ttl configurato
determina l'aggiornamento. Se i contenuti sono più vecchi di default_ttl , Cloud CDN li convalida nuovamente. |
Se ne sono presenti più, 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 scadenza supera i 30 giorni (2.592.000 secondi), Cloud CDN tratta questo valore come se fosse pari a 2.592.000 secondi. I clienti downstream continuano a vedere i valori precisi di max-age
e
s-maxage
, anche se superano i 30 giorni.
Rimozione
Non vi è alcuna garanzia che una voce della cache rimanga nella cache fino alla scadenza, perché le voci impopolari 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 si accede per 30 giorni vengono rimosse automaticamente.
Per maggiori informazioni, vedi Rimozione e scadenza.
Utilizzare le richieste condizionali per la convalida
Cloud CDN può tentare di utilizzare le informazioni nelle intestazioni delle risposte memorizzate nella cache per convalidare la voce della cache con il backend. Ciò si verifica quando entrambe le seguenti condizioni sono vere:
- La risposta precedentemente memorizzata nella cache ha un'intestazione
Last-Modified
oETag
. - La richiesta del client è una richiesta
GET
che non contiene intestazioniIf-Modified-Since
oIf-None-Match
.
Cloud CDN esegue questa convalida in modo leggermente diverso a seconda che la risposta sia stata memorizzata o meno nella cache utilizzando richieste di intervalli di byte:
- Se la risposta è stata memorizzata nella cache utilizzando richieste di intervalli di byte, Cloud CDN avvia una richiesta di convalida separata che include intestazioni
If-Modified-Since
e/oIf-None-Match
. - In caso contrario, Cloud CDN aggiunge le intestazioni
If-Modified-Since
e/oIf-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 esistente della cache inviando una risposta 304 Not Modified
. In questo caso, il backend invia solo le intestazioni della risposta, non il corpo della risposta. Cloud CDN inserisce le nuove intestazioni della risposta nella cache, aggiorna la data di scadenza e pubblica al client le nuove intestazioni e il corpo della risposta memorizzata nella cache.
Se la risposta memorizzata nella cache in precedenza non ha un'intestazione Last-Modified
o ETag
, Cloud CDN ignora la voce della cache scaduta e inoltra la richiesta del client al backend senza modificarla.
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
o206 Partial Content
- Titolo:
Accept-Ranges: bytes
- Intestazione:
Content-Length
e/oContent-Range
- Intestazione:
Last-Modified
e/oETag
con uno strumento di convalida efficace
Cloud Storage supporta 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 Visualizzare e modificare i metadati degli oggetti.
I più diffusi software server web supportano anche le richieste con intervallo di byte. Consulta la documentazione del software del server web per i dettagli su come attivare il supporto. Per ulteriori informazioni sulle richieste di intervalli di byte, consulta la specifica HTTP.
Quando un server di origine supporta le richieste di intervallo di byte, la cache di Cloud CDN rifiuta di archiviare 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 una parte dei contenuti.
- Il corpo della risposta è superiore a 1 MB (1.048.576 byte).
In questo caso, se altrimenti la risposta soddisferebbe i normali requisiti di memorizzazione nella cache, la cache registra che il server di origine supporta le richieste di intervalli di byte per quella chiave 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 è noto per supportare le richieste di intervalli di byte. Se è noto che le richieste con intervallo di byte sono supportate per la chiave cache, la cache non inoltra la richiesta del client al bilanciatore del carico delle applicazioni esterno.
Al contrario, la cache avvia le proprie richieste di riempimento della cache dell'intervallo 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ò archiviare questo intervallo per le richieste future.
Una cache archivia 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 avesse precedentemente registrato che
il server di origine supporta richieste di intervalli di byte per la chiave di cache, una determinata cache
non archivia contenuti superiori a 1 MB fino al secondo accesso
al contenuto.
Data la sua natura distribuita, Cloud CDN a volte potrebbe recuperare il blocco finale dall'origine più di una volta per località. Questo influisce solo sulle prime richieste per chiave cache.
Richiesta di compressione (coalescing)
La compressione (o coalescing) della richiesta comprime attivamente più richieste di riempimento della cache guidate dall'utente per la stessa chiave di cache in una singola richiesta di origine per nodo perimetrale. Ciò può ridurre attivamente il carico sull'origine e si applica sia alle richieste item (risposte recuperate direttamente) sia alle richieste di chunk, dove Cloud CDN utilizza le richieste Range
per recuperare oggetti più grandi in modo più efficiente.
La compressione delle richieste è attivata per impostazione predefinita.
Le richieste compresse si comportano nel seguente modo:
- Le richieste compresse registrano sia la richiesta rivolta al client sia la richiesta di riempimento della cache (compressa).
- Il leader della sessione compressa viene utilizzato per effettuare la richiesta di riempimento dell'origine.
- Gli attributi della richiesta che non fanno parte della chiave cache,
come l'intestazione
User-Agent
oAccept-Encoding
, riflettono solo il leader della sessione compressa. - Le richieste che non hanno la stessa chiave cache non possono essere compresse.
Il seguente diagramma mostra come vengono combinate le richieste:
In confronto, se la compressione delle richieste è disabilitata o per le richieste che non possono essere connesse, il numero di richieste di origine e risposte può essere uguale al numero di client che tentano di recuperare un oggetto non attualmente memorizzato nella cache.
Per tutti i tipi di richieste, la compressione è abilitata per impostazione predefinita. Per i tipi di richiesta di elementi, puoi disattivare la compressione. Consigliamo di disattivare la compressione per le richieste di articoli in scenari sensibili ad alta latenza, come la pubblicazione di annunci, in cui il carico dell'origine non deve essere preso in considerazione.
La tabella seguente riassume il comportamento predefinito e la configurabilità per i diversi tipi di richiesta.
Tipo di richiesta | Comportamento predefinito | Configurabile | Vantaggi della compressione |
---|---|---|---|
Richieste di chunk | Abilitata | No | Può ridurre notevolmente la larghezza di banda di origine |
Richieste di articoli | Abilitata | Sì | Può ridurre il volume delle richieste di origine |
Per disabilitare la compressione della richiesta di elementi utilizzando Google Cloud CLI per un bucket di backend che fa riferimento a un bucket Cloud Storage:
gcloud
Usa il comando gcloud compute backend-services
o backend-buckets
:
gcloud compute backend-services update BACKEND_SERVICE_NAME \ --no-request-coalescing
Per abilitare la compressione delle richieste degli elementi in un bucket di backend utilizzando Google Cloud CLI:
gcloud
Usa il comando gcloud compute backend-buckets
:
gcloud compute backend-buckets update BACKEND_BUCKET_NAME \ --request-coalescing
Per abilitare la compressione delle richieste degli elementi utilizzando Google Cloud CLI per un servizio di backend, inclusi gruppi di VM e backend esterni:
gcloud
Usa 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 di intervallo di byte, Cloud CDN può inviare più richieste al server di origine in reazione a una singola richiesta del client. Cloud CDN può avviare due tipi di richieste: richieste di convalida e richieste con intervallo di byte.
Se la risposta che indicava che il server di origine supportava le richieste di intervalli di byte per una determinata chiave cache è scaduta, Cloud CDN avvia una richiesta di convalida per confermare che il contenuto non è cambiato e che il server di origine supporta ancora richieste di intervallo per i contenuti. Se il tuo server di origine risponde con una risposta 304 Not Modified
, Cloud CDN procede per gestire i contenuti utilizzando intervalli di byte. In caso contrario, Cloud CDN inoltra la risposta del server di origine al client. Puoi controllare i tempi di scadenza utilizzando le intestazioni della 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 di contenuti richiesti dal client sono presenti nella cache, Cloud CDN fornisce tutto il possibile 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 da un offset che è un multiplo di 2.097.136 byte. Con la possibile eccezione dell'intervallo finale, ogni intervallo è pari a 2.097.136 byte. Se i contenuti non sono un multiplo di quella dimensione, l'intervallo finale è inferiore. Le dimensioni e gli offset utilizzati nelle richieste di intervalli di byte potrebbero cambiare in futuro.
Considera ad esempio una richiesta del client per 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. In questo modo si ottengono 4.194.272 byte di riempimento della cache anche se il client ha richiesto solo 3.000.000 di byte.
Quando utilizzi un bucket Cloud Storage come origine, ogni richiesta GET viene fatturata come operazione di classe B separata. Ti vengono addebitate tutte le richieste GET elaborate da Cloud Storage, incluse le richieste avviate da Cloud CDN. Quando una risposta viene fornita interamente da una cache di Cloud CDN, non vengono inviate richieste GET a Cloud Storage e non ti viene addebitato alcun costo per le 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 Cloud Logging httpRequest.userAgent
, Cloud-CDN-Google
indica che Cloud CDN ha avviato la richiesta.
Ignorare la cache
L'esclusione della cache consente alle richieste contenenti intestazioni di richieste specifiche di ignorare la cache, anche se i contenuti erano stati precedentemente memorizzati nella cache.
Questa sezione fornisce informazioni su come bypassare la cache con 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. Può essere utile per eseguire test, configurare
directory di gestione temporanea o script.
Se un'intestazione specificata corrisponde, la cache viene ignorata per tutte le impostazioni della modalità cache, anche per FORCE_CACHE_ALL
. L'esclusione della cache provoca un numero elevato di
errori della cache se le intestazioni specificate sono comuni a molte richieste.
Prima di iniziare
Assicurati che Cloud CDN sia abilitato. Per le istruzioni, vedi Utilizzo di Cloud CDN.
Se necessario, esegui l'aggiornamento alla versione più recente di Google Cloud CLI:
gcloud components update
Configurare il 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 valido per il campo di intestazione HTTP. Il nome di un'intestazione non deve apparire più di una volta nell'elenco delle intestazioni aggiunte. Per le regole sui nomi di intestazione validi, vedi Funzionamento delle intestazioni personalizzate.
Console
- Nella console Google Cloud, vai alla pagina Bilanciamento del carico.
- Fai clic sul nome del bilanciatore del carico delle applicazioni esterno.
- Fai clic su Modifica .
- In Configurazione backend, seleziona un backend e fai clic su Modifica .
- Assicurati che l'opzione Abilita Cloud CDN sia selezionata.
- Nella parte inferiore della finestra, fai clic su Configurazioni avanzate.
- In Ignora cache nell'intestazione della richiesta, fai clic su Aggiungi intestazione.
- Digita un nome per l'intestazione, ad esempio
Pragma
oAuthorization
. - Fai clic su Update (Aggiorna).
- 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 Metodo: backendBuckets.insert, Metodo: backendBuckets.update o Metodo: backendBuckets.patch.
Per i servizi di backend, utilizza la chiamata API Method: backendServices.insert, Method: backendServices.update o Method: 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 } ] }
Disabilitazione del bypass della cache in corso...
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 Method: backendServices.insert o Method: 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
- Per capire in che modo le modalità cache semplificano la memorizzazione dei contenuti nella cache, consulta la sezione Utilizzare le modalità cache.
- Per abilitare Cloud CDN per le tue istanze con bilanciamento del carico HTTP(S) e i bucket di archiviazione, consulta Utilizzo di Cloud CDN.
- Per informazioni sull'annullamento della convalida delle cache, consulta Panoramica dell'annullamento della convalida delle cache.
- Per trovare i punti di presenza GFE, consulta Posizioni della cache.