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 possono essere memorizzate 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 la modalità di memorizzazione nella cache delle risposte, se Cloud CDN rispetta le istruzioni cache inviate dall'origine e come vengono applicati i TTL Cache.
Le modalità cache disponibili sono mostrate nella seguente tabella:
Modalità cache | Comportamento |
---|---|
CACHE_ALL_STATIC |
Memorizza automaticamente nella cache le risposte positive con contenuti statici che non sono altrimenti memorizzabili nella cache.
Anche le risposte di origine che impostano istruzioni di memorizzazione nella cache valide vengono memorizzate nella cache. Questo è il comportamento predefinito per i backend abilitati per Cloud CDN creati mediante l'interfaccia a riga di comando di Google Cloud o l'API REST. |
USE_ORIGIN_HEADERS |
Richiede risposte di origine corrette per impostare istruzioni di cache valide e intestazioni di memorizzazione nella cache valide. Le risposte positive senza queste istruzioni
vengono deviate dall'origine. |
FORCE_CACHE_ALL |
Memorizza nella cache risposte incondizionate, sostituendo tutte le istruzioni cache impostate dall'origine. Questa modalità non è appropriata se il backend pubblica contenuti privati per utente, ad esempio risposte HTML API o risposte dinamiche. |
Le risposte agli errori potrebbero essere memorizzate nella cache anche in assenza di istruzioni valide per le cache.
Prima di impostare la modalità cache su FORCE_CACHE_ALL
, tieni presente i seguenti comportamenti:
Per URL firmati o cookie firmati,
FORCE_CACHE_ALL
sostituisce l'età massima specificata tramite l'impostazione Età massima della cache in Google Cloud Console o l'opzionegcloud --signed-url-cache-max-age
.FORCE_CACHE_ALL
modifica la durata (TTL) dei contenuti memorizzati nella cache in precedenza. Con questa modifica, alcune voci considerate in precedenza aggiornate (a causa di TTL più lunghi dalle intestazioni origine) potrebbero essere considerate non aggiornate e alcune voci precedentemente considerate non aggiornate.FORCE_CACHE_ALL
sostituisce le istruzioni cache (Cache-Control
eExpires
), ma non le altre intestazioni delle risposte di origine. In particolare, un'intestazioneVary
è ancora rispettata e può ostacolare la memorizzazione nella cache anche in presenza diFORCE_CACHE_ALL
. Per ulteriori informazioni, consulta la sezione Intestazioni Vary.
Per istruzioni sulla configurazione, consulta la sezione Impostare la modalità cache.
Contenuto statico
I contenuti statici sono sempre gli stessi, anche se sono accessibili da utenti diversi. Il codice CSS che utilizzi per definire lo stile del tuo sito, JavaScript per fornire l'interattività, i video e i contenuti delle immagini in genere non cambia per ogni utente per un determinato URL (chiave cache), e di conseguenza può essere memorizzato nella cache sulla rete perimetrale globale di Cloud CDN.
Quando imposti la modalità cache su CACHE_ALL_STATIC
, Cloud CDN memorizza automaticamente le risposte nella cache per:
- 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 (image/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 esamina l'intestazione della 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 l'elemento
Content-Type
per ogni risposta. Molti server web impostano automaticamente l'intestazioneContent-Type
, inclusi NGINX, Varnish e Apache.Cloud Storage imposta l'intestazione
Content-Type
automaticamente al caricamento quando utilizzi Cloud Console o lo strumentogsutil
per caricare i contenuti.Se una risposta è memorizzabile nella cache in base al tipo MIME, ma ha un'intestazione della risposta
Cache-Control
diprivate
ono-store
oppure un'intestazioneSet-Cookie
(vedi l'elenco completo delle regole), non viene memorizzata nella cache.
Cloud CDN non utilizza le estensioni di file nel percorso dell'URL per determinare se una risposta è memorizzabile nella cache perché molte risposte memorizzabili nella cache non vengono applicate negli URL.
Se vuoi memorizzare i tipi di contenuti text/html
e application/json
nella cache, devi impostare intestazioni Cache-Control
esplicite nella risposta, facendo attenzione a non memorizzare nella cache i dati di un utente e a mostrarli a tutti gli utenti.
Contenuti memorizzabili nella cache
Cloud CDN memorizza nella cache le risposte che soddisfano tutti i requisiti in 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 i contenuti vengono memorizzati nella cache. Se vuoi impedire esplicitamente a Cloud CDN di memorizzare i tuoi contenuti nella cache, segui le linee guida nel documento RFC 7234 per determinare come specificare una risposta garantita senza cache. Consulta anche la sezione Contenuti non memorizzabili nella cache in base alle intestazioni delle origini.
Cloud CDN memorizza le risposte nella cache se si verificano tutte le condizioni seguenti.
Attributo | Requisito |
---|---|
Fornito da | Servizio di backend, bucket di backend o un backend esterno con Cloud CDN abilitato |
In risposta a | GET richiesta |
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 di 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 | Contiene un'intestazione Ad esempio, un'intestazione |
Dimensioni | Minore o uguale alla dimensione massima.
Per le risposte con dimensioni comprese tra 10 MB e 5 TB, consulta i vincoli di cache aggiuntivi descritti in Richieste di intervallo di byte. |
Per i bucket di backend Cloud Storage, ecco alcuni modi per soddisfare questi requisiti:
Rendi il bucket pubblicamente leggibile. È 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. Si consiglia di dedicare bucket specifici per gli oggetti pubblici. Per ulteriori informazioni, consulta la sezione Architettura del bucket consigliata.
Rendi i singoli oggetti leggibili pubblicamente. Sconsigliamo questo approccio.
Per impostazione predefinita, quando l'intero bucket è pubblico o i singoli oggetti sono pubblici e i singoli oggetti non specificano 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 HTTP(S) esterno con un bucket di backend, consulta la sezione Configurare Cloud CDN con un bucket di backend.
Dimensioni massime
Cloud CDN applica una dimensione massima per ogni risposta. Qualsiasi risposta con corpo più grande della 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 le richieste dell'intervallo di byte.
Il server di origine supporta le richieste di intervalli di byte | Il server di origine non supporta le richieste di intervalli di byte |
---|---|
5 TB (5.497.558.138.880 byte) | 10 MB (10.485.760 byte) |
Quasi tutti i server web moderni (tra cui NGINX, Apache e Varnish) supportano le richieste di intervalli di byte.
Contenuti non memorizzabili nella cache in base alle intestazioni di origine
Sono presenti controlli che bloccano la memorizzazione nella cache delle risposte. Cloud CDN potrebbe modificare periodicamente l'esatto insieme di condizioni in cui i contenuti vengono memorizzati nella cache, pertanto se vuoi impedire esplicitamente a Cloud CDN di memorizzare i tuoi contenuti nella cache, segui le linee guida standard (RFC 7234) per determinare come specificare una risposta garantita e non memorizzabile nella cache.
Cloud CDN non memorizza nella cache una risposta se non soddisfa i requisiti per i contenuti memorizzabili nella cache o se si verifica una delle seguenti condizioni.
Attributo | Requisito |
---|---|
Fornito da | Servizio di backend o backend esterno per cui non è abilitato Cloud CDN |
Cookie | Ha un'intestazione Set-Cookie |
Intestazione Vary |
Ha un valore diverso da Accept , Accept-Encoding , Origin o X-Origin
|
Istruzione di risposta | La risposta ha un'intestazione Cache-Control con l'istruzione no-store o private (a meno che non utilizzi la modalità cache di FORCE_CACHE_ALL , nel qual caso l'intestazione Cache-Control viene ignorata) |
Istruzione di richiesta | La richiesta ha un'istruzione Cache-Control: no-store |
Richiedi autorizzazione | La richiesta ha un'intestazione Authorization , a meno che
non venga sostituita dalla risposta
Cache-Control. |
Dimensioni | Più grande della dimensione massima |
Se sono presenti Cache-Control: no-store
o private
, ma i contenuti sono ancora in 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.
Evitare la memorizzazione nella cache
Per evitare che le informazioni private vengano memorizzate nella cache della cache di Cloud CDN, procedi nel seguente modo:
- Assicurati che la modalità cache di Cloud CDN non sia impostata sulla modalità
FORCE_CACHE_ALL
, che memorizza in modo incondizionato 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 gli URL che forniscono accesso a informazioni private. Quando gli utenti accedono ai contenuti utilizzando un URL firmato, sono potenzialmente idonei alla memorizzazione nella cache, indipendentemente dalle istruzioni
Cache-Control
presenti nella risposta. - Per le richieste di origine (riempimento della cache) che includono l'intestazione della richiesta
Authorization
, Cloud CDN memorizza nella cache solo le risposte che includono le istruzioni di controllo cachepublic
,must-revalidate
os-maxage
quando la modalità cache è impostata suUSE_ORIGIN_HEADERS
oCACHE_ALL_STATIC
. Questo impedisce la memorizzazione accidentale nella cache di contenuti per utente e/o di contenuti che richiedono l'autenticazione. La modalità cacheFORCE_CACHE_ALL
non ha questa limitazione.
Aggiunta di intestazioni della risposta personalizzate
Con le intestazioni delle risposte personalizzate puoi specificare le intestazioni che il bilanciatore del carico HTTP(S) esterno globale (classico) aggiunge alle risposte inviate tramite proxy. Le intestazioni delle risposte personalizzate consentono di riflettere lo stato della cache per i tuoi client, i dati geografici del client e le tue intestazioni delle risposte statiche.
Per l'elenco delle intestazioni, consulta la sezione Variabili che possono essere visualizzate nel valore dell'intestazione.
Per le istruzioni, consulta la sezione Utilizzare le intestazioni delle risposte personalizzate.
Le intestazioni delle risposte personalizzate non sono supportate per i deployment di Cloud CDN sui bilanciatori del carico HTTP(S) esterni globali.
Chiavi cache
Ogni voce di cache in una cache Cloud CDN è identificata da una chiave cache. Quando una richiesta arriva nella cache, la cache converte l'URI della richiesta in una chiave cache, per poi confrontarla 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 di richiesta completo come chiave cache.
Ad esempio, https://example.com/images/cat.jpg
è l'URI completo di una
richiesta specifica per l'oggetto cat.jpg
. Questa stringa viene utilizzata come chiave cache predefinita. Solo le richieste con questa corrispondenza esatta della stringa. 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 è la chiave cache, che consiste nell'URI senza protocollo o host. Per impostazione predefinita, solo i 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 vengono risolti 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 cambiare le parti dell'URI utilizzate nella chiave cache. Il nome file e il percorso devono essere sempre inclusi nella chiave, ma puoi includere o omettere qualsiasi combinazione di protocollo, host o stringa di query quando personalizzi la chiave cache. L'utilizzo delle chiavi cache descrive come personalizzare le chiavi cache.
Parte URI | Personalizzazione | Esempi di URL con 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 in modo selettivo le parti della stringa di query. |
|
Oltre a includere o omettere l'intera stringa di query, puoi utilizzare le parti della stringa di query utilizzando elenchi di inclusione ed esclusione.
Elenco di stringhe di query incluse
Puoi controllare selettivamente quali parametri di stringa di query incorpora Cloud CDN nelle chiavi cache. Ad esempio, se crei un elenco di inclusione di
user
,https://example.com/images/cat.jpg?user=user1&color=blue
viene creata anche una chiave cache di https://example.com/images/cat.jpg?user=user1
che
corrisponde 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.
La stringa di query include l'elenco per le chiavi cache di Cloud Storage
L'inclusione dei parametri di ricerca degli URL nelle chiavi cache per i bucket Cloud Storage consente di supportare il busting della cache. Il busting della cache è il processo che consente a un utente di trovare una nuova versione del file caricato, anche se la versione precedente è ancora validamente memorizzata nella cache da TTL.
Puoi includere parametri di query specifici per l'elenco nella chiave cache utilizzata per la pubblicazione di risposte da un bucket di backend. Anche se Cloud Storage non gestisce contenuti o route diversi in base ai parametri di ricerca, puoi scegliere di includere parametri che ti consentano di memorizzare nella cache i contenuti statici archiviati nei bucket Cloud Storage.
Ad esempio, puoi aggiungere un parametro di ricerca ?version=VERSION
o ?hash=HASH
basato sui contenuti sottostanti. Questo limita la necessità di invalidare proattivamente i contenuti e si allinea ai moderni flussi di lavoro di sviluppo web, in cui il framework e gli URL web utilizzano un hash dei contenuti per evitare di pubblicare oggetti obsoleti nei deployment.
Poiché l'inclusione dei parametri di ricerca nella chiave cache è abilitata solo per l'attivazione, Cloud CDN non supporta l'esclusione dei parametri di ricerca da una chiave cache a un bucket di backend.
Elenco di esclusione delle stringhe di query
Puoi controllare selettivamente quali parametri della stringa di query vengono ignorati da Cloud CDN 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 un 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
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 ricerca
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 chiavi cache HTTP di intestazioni HTTP e cookie
Puoi migliorare i tassi di successo della cache e l'offload dell'origine con le seguenti impostazioni di configurazione delle chiavi cache.
- Per i servizi e i bucket di backend: utilizza le intestazioni HTTP come parte delle chiavi cache includendo le intestazioni denominate nella configurazione delle chiavi cache.
- Solo per i servizi di backend: utilizza i cookie HTTP con nome come chiavi cache, ad esempio per test A/B (multivariati), canary e scenari simili.
Le richieste cache che includono intestazioni HTTP aggiuntive o cookie HTTP nella richiesta vengono memorizzate nella terza richiesta in una posizione cache per la chiave cache. In questo modo si riduce l'impatto di valori di intestazione/cookie ad alta cardinalità sui tassi di rimozione della cache. In circostanze normali e nelle condizioni del traffico utente, ciò non dovrebbe essere evidente e garantisce che i contenuti popolari rimangano memorizzati nella cache.
Include intestazioni delle richieste
Per memorizzare nella cache ulteriori varianti di una risposta, puoi includere intestazioni di richiesta aggiuntive nella chiave cache.
Alcune intestazioni non sono consentite nelle chiavi cache, perché in genere hanno una cardinalità molto elevata. Nella maggior parte dei casi, i valori di queste intestazioni sono
unici per utente (Cookie
,Authorization
) o hanno migliaia di probabili
valori (Referer
, User-Agent
, Accept
). Ad esempio, l'intestazione User-Agent
può avere oltre 5000 valori univoci dato l'ampia varietà di browser,
dispositivi utente e sistemi operativi. Questi tipi di intestazioni avrebbero un grave impatto negativo sulle percentuali di successo della cache.
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
utilizzati da Django e Ruby su 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-
Note:
- I valori di intestazione della richiesta vengono utilizzati per generare la chiave cache prima di qualsiasi aggiunta o modifica eseguita con intestazioni personalizzate.
- Sono accettati solo nomi di campo di intestazione HTTP validi per il documento RFC 7230.
- I nomi dei campi delle intestazioni non fanno distinzione tra maiuscole e minuscole e i duplicati vengono rifiutati.
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 supponendo 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, in modo che il client abbia le seguenti caratteristiche:
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 sulla stessa riga o come intestazioni di richiesta Cookie
discrete con un cookie per intestazione.
Puoi fornire un elenco di nomi dei cookie (fino a 3).
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 troppo grandi) perché lo user agent potrebbe non inviare tutti i cookie in una richiesta. Ciò può influire sulla ricezione di una risposta specifica memorizzata nella cache.
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 di cookie, solo la prima viene rispettata.
Istruzioni di controllo cache
Le istruzioni di controllo della cache HTTP influiscono sul comportamento di Cloud CDN, come spiegato nella tabella seguente.
N/D indica che un'istruzione non è applicabile a una richiesta o risposta.
Istruzione | Risorse richieste: | Risposta |
---|---|---|
no-store |
Se presente in una richiesta, Cloud CDN lo rispetta e non memorizza la risposta nella cache. |
Una risposta con
È possibile eseguire l'override
per ogni backend con la modalità cache |
no-cache |
L'istruzione di richiesta no-cache viene ignorata per impedire ai client di avviare o forzare potenzialmente la riconvalida dell'origine.
|
Una risposta con
È possibile eseguire l'override
per ogni backend con la modalità cache |
public |
N/A |
Questa istruzione non è richiesta per la memorizzazione nella cache, ma è consigliabile includerla per i contenuti che devono essere memorizzati nella cache dai proxy. |
private |
N/A |
Una risposta con istruzione
È possibile eseguire l'override
per ogni backend con la modalità cache |
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 istruzione max-age viene memorizzata nella cache fino al valore
SECONDS definito.
|
s-maxage=SECONDS
|
N/A |
Una risposta con istruzione
Se sono presenti sia Le risposte con questa istruzione non sono aggiornate.
|
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/A |
max-stale=SECONDS
|
L'istruzione della richiesta Cloud CDN risponde in questo modo e restituisce una risposta
inattiva solo nella cache solo se l'affidabilità della risposta è inferiore
all'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 di richiesta stale-if-error viene ignorata. Viene restituita una risposta memorizzata nella cache come se questa intestazione non fosse inclusa nella richiesta.
|
L'intestazione della risposta non ha alcun effetto. |
must-revalidate |
N/A |
Una risposta con Le risposte con questa istruzione non sono aggiornate. |
proxy-revalidate |
Una risposta con Le risposte con questa istruzione non sono aggiornate. |
|
immutable |
N/A | Nessun effetto. Viene trasmesso al client nella risposta. |
no-transform |
N/A | Nessuna trasformazione applicata da Cloud CDN. |
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/A |
Ove possibile, Cloud CDN cerca di rendere conforme lo standard RFC (HTTP 7234), ma favorisce l'ottimizzazione per il offload della cache e la riduzione al minimo dell'impatto che i client possono avere sulla percentuale di hit e/o sul carico complessivo delle origini.
Per le risposte che utilizzano l'intestazione HTTP/1.1 Expires
:
- Il valore dell'intestazione
Expires
deve essere una data HTTP valida come definita in RFC 7231. - Un valore data passato, una data non valida o un valore
0
indica che i contenuti sono già scaduti e richiedono una riconvalida. - Se nella risposta è presente un'intestazione
Cache-Control
, Cloud CDN ignora l'intestazioneExpires
.
La presenza di un'intestazione Expires
futura valida nella risposta consente di inserire nella cache la risposta
e non richiede alcuna istruzione di memorizzazione nella cache.
L'intestazione HTTP/1.0 Pragma
, se presente in una risposta, viene ignorata e trasmessa
al client così com'è. Le richieste del client con questa intestazione vengono trasmesse all'origine e non influiscono sulla modalità di risposta di Cloud CDN.
Vary
intestazioni
L'intestazione Vary
indica che la risposta varia a seconda delle 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 cache per le richieste che specificano Accept: image/webp,image/*,*/*;q=0.8
e un'altra per le richieste che specificano Accept: */*
.
La tabella presente nella sezione Contenuti non memorizzabili nella cache elenca le intestazioni Vary
che consentono la memorizzazione dei contenuti nella cache. Altri valori intestazione Vary
impediscono la memorizzazione dei contenuti nella cache.
La modalità cache di FORCE_CACHE_ALL
non ha la precedenza su 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 di tali risposte nella cache.
Talvolta vengono usate intestazioni Vary
per la pubblicazione di contenuti compressi.
Cloud CDN non comprime o decomprime le risposte, ma può pubblicare 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
.
Tempi di scadenza e richieste di convalida
La data di scadenza di una voce memorizzata nella cache definisce la durata della voce della cache.
Il valore fornito dal valore s-maxage
(o max-age
o expires
) consente
la convalida automatica di contenuti memorizzati nella cache generati dagli utenti.
Quando Cloud CDN riceve una richiesta, cerca la voce della cache corrispondente e controlla la sua età. Se la voce della cache esiste ed è sufficientemente recente, la risposta può essere fornita dalla cache. Se il tempo di scadenza è trascorso, Cloud CDN tenta di riconvalidare la voce della cache contattando uno dei backend. Questo avviene prima della risposta, a meno che non abiliti service-while-stale, nel qual caso la riconvalida viene eseguita in modo asincrono.
Per alcune modalità della cache, puoi impostare valori TTL. Per ulteriori informazioni, consulta Utilizzo delle impostazioni e degli override TTL.
La modalità cache influisce sulla modalità di determinazione dell'aggiornamento.
Modalità cache | Comportamento di convalida |
---|---|
CACHE_ALL_STATIC |
Le intestazioni di origine (Cache-Control: s-maxage ,
Cache-Control: max-age o Expires ) vengono consultate
per determinare l'aggiornamento. Per i contenuti statici, se non sono presenti intestazioni di origine, l'elemento default_ttl configurato determina l'aggiornamento. Una volta che i contenuti statici risalgono a più di default_ttl , Cloud CDN li riconvalida. |
USE_ORIGIN_HEADERS |
Ogni voce di cache in una cache Cloud CDN ha una data di scadenza
definita dalle intestazioni Cache-Control: s-maxage ,
Cache-Control: max-age o Expires in
conformità a
RFC 7234. |
FORCE_CACHE_ALL |
Anziché le intestazioni dell'origine, l'elemento default_ttl configurato
determina l'aggiornamento. Dopo che i contenuti sono più vecchi di
default_ttl , Cloud CDN li riconvalida. |
Se sono presenti più numeri, Cache-Control: s-maxage
ha
precedenza su Cache-Control: max-age
e
Cache-Control: max-age
ha la precedenza su Expires
.
Per impostazione predefinita, quando il valore della data di scadenza supera i 30 giorni (2.592.000 secondi), Cloud CDN considera il valore della scadenza come se fosse 2.592.000 secondi. I client downstream registrano ancora i valori accurati di max-age
e
s-maxage
, anche se superano i 30 giorni.
Rimozione
Non vi è alcuna garanzia che una voce memorizzata nella cache rimanga nella cache fino alla scadenza, perché le voci impopolari possono essere rimosse prima della scadenza in qualsiasi momento per fare spazio a nuovi contenuti. Come limite superiore, le voci della cache che non vengono accese per 30 giorni vengono rimosse automaticamente.
Per ulteriori informazioni, consulta la sezione Evizione e scadenza.
Utilizzare le richieste condizionali per la convalida
Cloud CDN può tentare di utilizzare le informazioni nelle intestazioni della risposta memorizzate nella cache per convalidare la voce della cache con il backend. ovvero quando si verificano entrambe le seguenti condizioni:
- La risposta memorizzata nella cache in precedenza ha un'intestazione
Last-Modified
oETag
. - La richiesta 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 nella cache utilizzando le richieste dell'intervallo 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 client e inoltra la richiesta modificata al backend.
Se la copia 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, non il corpo della risposta. Cloud CDN inserisce le nuove intestazioni della risposta nella cache, aggiorna la data di scadenza e fornisce le nuove intestazioni della risposta e il corpo della risposta memorizzata nella cache al client.
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 client al backend non modificato.
Supporto per le richieste di intervallo 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
- Intestazione:
Accept-Ranges: bytes
- Intestazione:
Content-Length
e/oContent-Range
- Intestazione:
Last-Modified
e/oETag
con uno strumento di convalida valido
Cloud Storage supporta le richieste di intervalli di byte per la maggior parte degli oggetti. Tuttavia, Cloud Storage non supporta le richieste di intervallo di byte per gli oggetti con metadati Content-Encoding: gzip
, a meno che la richiesta client non includa un'intestazione Accept-
Encoding: gzip
. Se gli oggetti Cloud Storage sono più grandi di 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 server web più utilizzato supporta anche le richieste di intervalli di byte. Consulta la documentazione del software del tuo server web per informazioni dettagliate su come abilitare l'assistenza. Per ulteriori informazioni sulle richieste di intervalli di byte, consulta la specifica HTTP.
Quando un server di origine supporta richieste di intervallo di byte, una 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 parte dei contenuti.
- Il corpo della risposta è maggiore di 1 MB (1.048.576 byte).
In questo caso, se la risposta soddisfa i normali requisiti di memorizzazione nella cache, il cache registra che il server di origine supporta le richieste di intervalli di byte per quella chiave della cache, inoltre inoltra la risposta del server di origine al client.
Se la cache non funziona, la cache controlla se il server di origine è noto per supportare le richieste di intervalli di byte. Se è noto che le richieste di intervalli di byte sono supportate per la chiave cache, la cache non inoltra la richiesta client al bilanciatore del carico HTTP(S) esterno.
La cache avvia, invece, le proprie richieste di riempimento della cache con intervalli di byte per le parti mancanti dei contenuti. Se il tuo server di origine restituisce
l'intervallo di byte richiesto in una risposta 206 Partial Content
, la cache può
memorizzare tale 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 intervalli di byte per quella chiave della cache, una determinata cache non archivia contenuti di dimensioni superiori a 1 MB fino al secondo accesso ai contenuti.
A causa della sua natura distribuita, a volte Cloud CDN può recuperare il blocco finale dall'origine più di una volta per località. Questa operazione influisce solo sulle prime poche richieste per chiave cache.
Compressione delle richieste (coalescenza)
La compressione di richieste (anche denominata coalescing) comprime attivamente più richieste di riempimento della cache basate sugli utenti per la stessa chiave 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 direttamente) che alle
richieste chunk, in cui
Cloud CDN utilizza le richieste Range
per recuperare gli oggetti più grandi in modo
più efficiente.
La compressione di richieste è attivata per impostazione predefinita.
Le richieste compresse si comportano nel seguente modo:
- Le richieste compresse registrano sia la richiesta lato client sia la richiesta di riempimento della cache (compressa).
- Il leader della sessione compressa viene utilizzato per effettuare la richiesta di riempimento dell'origine.
- Richiedi gli attributi che non fanno parte della chiave cache, ad esempio 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 si integrano le richieste:
Invece, con la compressione delle richieste disabilitata o per le richieste che non possono essere coalate, il numero di richieste e risposte di origine 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 è attiva per impostazione predefinita. Per i tipi di richiesta di elementi, puoi disattivare la compressione. Consigliamo di disattivare la compressione per le richieste di elementi in scenari sensibili ad alta latenza, come la pubblicazione di annunci, in cui il caricamento dell'origine non è una considerazione.
La tabella seguente riassume il comportamento e la configurabilità predefiniti per diversi tipi di richieste.
Tipo di richiesta | Comportamento predefinito | Configurabile | Vantaggi della compressione |
---|---|---|---|
Richieste di blocchi | Abilitato | No | Può ridurre notevolmente la larghezza di banda di origine |
Richieste di articoli | Abilitato | Sì | Può ridurre il volume di richieste dell'origine |
Per disattivare la compressione delle richieste di elementi utilizzando l'interfaccia a riga di comando di Google Cloud per un bucket di backend che fa riferimento a un bucket di Cloud Storage:
gcloud
Usa i comandi gcloud compute backend-services
o backend-buckets
:
gcloud compute backend-services update BACKEND_SERVICE_NAME \ --no-request-coalescing
Per attivare la compressione delle richieste di elementi su un bucket di backend utilizzando l'interfaccia a riga di comando di Google Cloud:
gcloud
Usa il comando gcloud compute backend-buckets
:
gcloud compute backend-buckets update BACKEND_BUCKET_NAME \ --request-coalescing
Per attivare la compressione delle richieste di elementi utilizzando l'interfaccia a riga di comando di Google Cloud per un servizio di backend, inclusi i gruppi di VM e i 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 tuo server di origine supporta le richieste dell'intervallo di byte, Cloud CDN può inviare più richieste al tuo server di reazione in risposta a una singola richiesta client. Cloud CDN può avviare due tipi di richieste: richieste di convalida e richieste di intervalli di byte.
Se la risposta che indicava che il server di origine supportava le richieste di intervalli di byte per una determinata chiave della cache è scaduta, Cloud CDN avvia una richiesta di convalida per verificare che i contenuti non siano cambiati 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 i tempi di scadenza utilizzando le intestazioni delle risposte Cache-Control
e Expires
.
Nel caso di un errore relativo alla cache, Cloud CDN avvia le richieste di riempimento della cache per un insieme di intervalli di byte che si sovrappongono alla richiesta del client. Se alcuni intervalli di contenuti del client richiesti sono presenti nella cache, Cloud CDN gestisce tutto ciò che può dalla cache e invia le richieste di intervallo di byte solo per gli intervalli mancanti al tuo 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 2.097.136 byte. Ad eccezione dell'intervallo finale, ogni intervallo è pari a 2.097.136 byte. Se i contenuti non sono multipli di queste dimensioni, l'intervallo finale è inferiore. Le dimensioni e gli offset utilizzati nelle richieste di intervalli di byte potrebbero cambiare in futuro.
Ad esempio, considera una richiesta client 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. Ne risultano 4.194.272 byte di riempimento della cache 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 addebitate tutte le richieste GET elaborate da Cloud Storage, incluse tutte le richieste avviate da Cloud CDN. Quando una risposta viene fornita interamente da una cache di Cloud CDN, non viene inviata alcuna richiesta GET a Cloud Storage e non 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
Ignora cache consente alle richieste contenenti intestazioni di richiesta specifiche di ignorare la cache, anche se i contenuti erano stati memorizzati nella cache in precedenza.
Questa sezione fornisce informazioni su come aggirare la cache con intestazioni HTTP,
come Pragma
e Authorization
. Questa funzionalità è utile quando vuoi assicurarti che gli utenti o i clienti dispongano sempre dei contenuti più recenti recuperati dal server di origine. Ti consigliamo di eseguire questa operazione per i test, la configurazione di directory temporanee o gli script.
Se un'intestazione specificata corrisponde, la cache viene bypassata per tutte le impostazioni della modalità cache, anche di FORCE_CACHE_ALL
. Se l'intestazione specificata è comune a molte richieste, la chiusura della cache genera un numero elevato di fallimenti della cache.
Prima di iniziare
Assicurati che Cloud CDN sia abilitato; per le istruzioni, vedi Utilizzare Cloud CDN.
Se necessario, esegui l'aggiornamento all'ultima versione dell'interfaccia a riga di comando di Google Cloud:
gcloud components update
Configurazione della bypass della cache
Puoi specificare fino a cinque nomi di intestazione HTTP. I valori non fanno distinzione tra maiuscole e minuscole. Il nome dell'intestazione deve essere un token del campo di intestazione HTTP valido. Il nome dell'intestazione non deve apparire più di una volta nell'elenco delle intestazioni aggiunte. Per le regole relative ai nomi delle intestazioni validi, consulta la sezione Come funzionano le intestazioni personalizzate.
Console
- In Google Cloud Console, vai alla pagina Bilanciamento del carico.
- Fai clic sul nome del bilanciatore del carico HTTP(S) 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.
- Nella sezione Ignora l'intestazione della cache su richiesta, fai clic su Aggiungi intestazione.
- Digita un nome di 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 Method: backendbuckets.insert, Method: backendbuckets.update, o metodo: backendbuckets.patch.
Per i servizi di backend, utilizza la chiamata API Method: 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 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 Method: backendServices.insert o Metodo: servizi backend.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 come le modalità cache facilitano la memorizzazione dei contenuti nella cache, consulta la sezione Utilizzare le modalità cache.
- Per attivare Cloud CDN per le istanze e i bucket di archiviazione bilanciati con carico HTTP(S), vedi Utilizzo di Cloud CDN.
- Per informazioni sull'annullamento della convalida delle cache, consulta la panoramica sulla invalidamento della cache.
- Per trovare i punti di presenza GFE, vedi Posizione della cache.