Panoramica della memorizzazione nella cache

Una risposta memorizzabile nella cache è una risposta HTTP che Cloud CDN può archiviare e rapidamente recuperando i dati, consentendo tempi di caricamento più rapidi. Non tutte le risposte HTTP vengono 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 determinano come le risposte vengono memorizzate nella cache, se Cloud CDN rispetta le direttive di memorizzazione nella cache inviate dall'origine e come vengono applicati i TTL della cache.

Le modalità 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 possono essere memorizzati nella cache. Anche le risposte provenienti dall'origine, che impostano valide direttive di memorizzazione nella cache, vengono memorizzate nella cache.

Questo è il comportamento predefinito per i backend abilitati per Cloud CDN creati utilizzando l'interfaccia a riga di comando Google Cloud o l'API REST.
USE_ORIGIN_HEADERS Richiede risposte dell'origine riuscite per impostare istruzioni di cache valide e regole di memorizzazione nella cache. Risposte riuscite senza queste istruzioni vengono inoltrati dall'origine.
FORCE_CACHE_ALL Memorizza nella cache incondizionatamente le risposte riuscite, eseguendo l'override di qualsiasi cache direttive impostate dall'origine. Questa modalità non è appropriata se il backend pubblica contenuti privati per ciascun utente, come risposte dell'API o HTML dinamici.

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

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

  • Per URL o cookie firmati: FORCE_CACHE_ALL sostituisce l'età massima specificata tramite Cache l'impostazione di età massima delle voci nella console Google Cloud o l'opzione gcloud --signed-url-cache-max-age.

  • FORCE_CACHE_ALL modifica la durata (TTL) di qualsiasi cache precedentemente memorizzata contenuti. Questa modifica può causare la presenza di alcune voci prese in precedenza nuovi (a causa della presenza di TTL più lunghi dalle intestazioni delle origini) siano considerati inattivi, e può far sì che alcune voci precedentemente considerate obsolete siano considerati aggiornati.

  • FORCE_CACHE_ALL esegue l'override delle istruzioni di cache (Cache-Control e Expires) ma non sostituisce altre intestazioni di risposta dell'origine. In particolare, un Vary header viene ancora rispettato e può eliminare la memorizzazione nella cache anche in presenza di FORCE_CACHE_ALL. Per ulteriori informazioni, vedi Vary intestazioni.

Per istruzioni di configurazione, consulta la sezione Impostazione della cache .

Contenuti statici

I contenuti statici sono sempre gli stessi, anche se vi accedono utenti diversi. Il CSS che utilizzi per definire lo stile del tuo sito, il codice JavaScript per fornire i contenuti video, di immagine e di interattività solitamente non cambiano per ogni utente un determinato URL (chiave cache) e, di conseguenza, trarre vantaggio dall'essere memorizzati nella cache rete perimetrale globale di Cloud CDN.

Quando imposti la modalità cache su CACHE_ALL_STATIC e ricevi una risposta non ha istruzioni di memorizzazione nella cache esplicite in Cache-Control o Expires intestazioni, Cloud CDN memorizza automaticamente nella cache la risposta per seguenti:

  • Asset web, incluso 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, inclusi 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 lo MIME tipo 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'intestazione Content-Type, tra cui NGINX, Varnish e Apache.

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

  • Se una risposta può essere memorizzata nella cache in base al tipo MIME, ma presenta un valore Cache-Control un'intestazione della risposta di private o no-store oppure un Set-Cookie (visualizza l'elenco completo delle regole), non viene memorizzato nella cache.

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

Se vuoi memorizzare nella cache i tipi di contenuto text/html e application/json, devi Impostare intestazioni Cache-Control esplicite nella risposta, essendo facendo 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 specifiche di Cloud CDN.

Cloud CDN potrebbe modificare periodicamente l'esatto insieme di condizioni in in cui memorizza nella cache i contenuti. Se vuoi impedire esplicitamente a Cloud CDN di memorizzare nella cache i tuoi contenuti, segui le linee guida riportate in RFC 7234 per determinare come specificare una risposta non memorizzabile in cache garantita. Vedi anche 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
Pubblicato da Servizio di backend, bucket di backend o backend esterno con Cloud CDN abilitato
In risposta a Richiesta GET
Codice di stato

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

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

Per le risposte memorizzabili nella cache senza età (ad esempio, con no-cache), l'istruzione public deve essere esplicitamente fornito.

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

Con la modalità cache FORCE_CACHE_ALL, qualsiasi risposta positiva è idoneo per la memorizzazione nella cache. Ciò potrebbe causare la memorizzazione nella cache di dati (identificabili dall'utente). Dovresti impostare solo FORCE_CACHE_ALL su backend che non gestiscono servizi privati o ad esempio i bucket Cloud Storage.

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

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

Per le origini che utilizzano versioni più avanzate del protocollo HTTP (HTTP/2 e in seguito), la risposta non deve contenere queste intestazioni.
Dimensioni Inferiore o uguale alla dimensione massima.

Per risposte con dimensioni comprese tra 10 MB e 100 GB, consulta vincoli aggiuntivi di memorizzabilità nella cache descritti in richieste di intervallo di byte.

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

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

Per un esempio che mostra come configurare un bilanciatore del carico delle applicazioni esterno con un backend consulta la sezione Configurare Cloud CDN con un backend del bucket.

Dimensioni massime

Cloud CDN applica una dimensione massima per ogni risposta. Qualsiasi risposta con un corpo di dimensioni superiori a quelle massime non viene memorizzato nella cache, ma viene comunque inviato di alto profilo.

La dimensione massima varia a seconda che il server di origine supporti o meno byte di intervallo di indirizzi.

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)

Supporto di quasi tutti i server web moderni (tra cui NGINX, Apache e Varnish) richieste di intervalli di byte.

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

Esistono dei controlli che bloccano la memorizzazione nella cache delle risposte. Cloud CDN può modificare periodicamente l'esatto insieme di condizioni in cui memorizza i contenuti nella cache, perciò se vuoi impedire esplicitamente Cloud CDN dalla memorizzazione nella cache dei contenuti, segui le linee guida dello standard (RFC 7234) per stabilire come specificare una una risposta garantita e non memorizzabile nella cache.

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

Attributo Requisito
Servito da Servizio di backend o backend esterno che non dispone Cloud CDN abilitato
Cookie Contiene un'intestazione Set-Cookie
Intestazione Vary Ha un valore diverso da Accept, Accept-Encoding, Access-Control-Request-Headers, Access-Control-Request-Method Origin Sec-Fetch-Dest, Sec-Fetch-Mode Sec-Fetch-Site, X-Goog-Allowed-Resources X-Origin o una delle intestazioni configurate per essere parte delle impostazioni della chiave cache.
Istruzione di risposta La risposta ha un'intestazione Cache-Control con la direttiva no-store o private (a meno che non venga utilizzata la modalità cache FORCE_CACHE_ALL, nel qual caso l'intestazione Cache-Control viene ignorata).
Istruzione richiesta La richiesta ha un'istruzione Cache-Control: no-store
Richiedi autorizzazione La richiesta ha un'intestazione Authorization, a meno che ignorato dalla risposta Controllo cache
Dimensioni Più grandi della dimensione massima

Se Cache-Control: no-store o private è presente, ma i contenuti sono ancora in fase di memorizzazione nella cache per uno dei seguenti motivi:

  • 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

Impedire che le informazioni private vengano memorizzate nella cache in Cloud CDN :

  1. Assicurati che la modalità cache di Cloud CDN non sia impostata su Modalità FORCE_CACHE_ALL, che memorizza incondizionatamente tutti i contenuti nella cache diverse.
  2. Includi un'intestazione Cache-Control: private nelle risposte che non dovrebbero essere archiviati nelle cache di Cloud CDN o un Cache-Control: no-store un'intestazione nelle risposte che non devono essere memorizzate in nessuna cache, nemmeno nelle nella cache del browser.
  3. Non firmare URL che forniscono accesso a proprietà private informazioni. Quando si accede ai contenuti utilizzando un URL firmato, questi ultimi per la memorizzazione nella cache indipendentemente da eventuali istruzioni Cache-Control nel risposta.
  4. Per le richieste di origine (riempimento cache) che includono la richiesta Authorization , Cloud CDN memorizza nella cache solo le risposte che includono public, Istruzioni di controllo della cache must-revalidate o s-maxage quando è attiva la modalità cache è impostato su USE_ORIGIN_HEADERS o CACHE_ALL_STATIC. In questo modo memorizzano accidentalmente nella cache i contenuti per utente e quelli che richiedono autenticazione. La modalità cache FORCE_CACHE_ALL non presenta questa limitazione.

Aggiunta di intestazioni delle risposte personalizzate

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

Per l'elenco delle intestazioni, consulta Variabili che possono essere visualizzate nell'intestazione predefinito.

Per istruzioni, consulta l'articolo Come utilizzare le risposte personalizzate. intestazioni.

Chiavi cache

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

Per i servizi di backend, Cloud CDN utilizza per impostazione predefinita l'URI della richiesta 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 è utilizzata come stringa predefinita . Solo le richieste con questa stringa esatta corrisponde. Richieste di http://example.com/images/cat.jpg o https://example.com/images/cat.jpg?user=user1 non corrispondono.

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

Di conseguenza, per un determinato bucket di backend, i seguenti URI si risolvono nello stesso bucket 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 durante la personalizzazione della chiave cache. L'articolo Utilizzo delle chiavi di cache descrive come personalizzare le chiavi di cache.

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

Ometti la stringa di query dalla chiave cache.

Ometti o includi parti della stringa di query in modo selettivo.
  • https://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2

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

Elenco di inclusione della stringa di query

Puoi controllare selettivamente i parametri delle stringhe di query di Cloud CDN incorpora nelle chiavi cache. Ad esempio, se crei un elenco di inclusione user, poi 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 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

Inclusione parametri di ricerca dell'URL nelle chiavi cache per i bucket Cloud Storage supporta il busting della cache. Il busting della cache consente a un utente di recuperare una nuova versione del file che è stato caricato, anche se la versione precedente è ancora valida memorizzati nella cache in base all'impostazione TTL.

Puoi includere parametri di ricerca specifici nella chiave cache utilizzata per che fornisce risposte da un bucket di backend. Sebbene Cloud Storage non pubblicare contenuti o percorsi diversi in base a parametri di ricerca, puoi scegliere in modo da includere parametri che permettono di eseguire il busting della cache dei contenuti statici di archiviazione dei bucket Cloud Storage.

Ad esempio, puoi aggiungere un parametro di query ?version=VERSION o ?hash=HASH basato sui contenuti sottostanti. Questo limita la necessità di intervenire in modo proattivo invalidano i contenuti e si allinea ai moderni flussi di lavoro di sviluppo web, in cui framework e URL usano un hash dei contenuti per evitare di pubblicare oggetti inattivi nei vari deployment.

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

Elenco esclusioni stringa di query

Puoi controllare selettivamente i parametri delle stringhe di query di Cloud CDN ignora utilizzando un elenco di esclusione. Ad esempio, se crei un elenco di esclusione 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 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 e specificare un campo non vuoto escludi 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 la seguente chiave cache le impostazioni di configurazione.

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

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

Includere le intestazioni delle richieste

Per memorizzare nella cache varianti aggiuntive di una risposta, puoi includere nella chiave cache.

Alcune intestazioni non sono consentite nelle chiavi cache perché sono di solito 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 (Referer, User-Agent, Accept). Ad esempio, l'intestazione User-Agent può avere oltre 5000 valori univoci data l'ampia gamma di browser, dispositivi-utente e sistemi operativi. Questi tipi di intestazioni avrebbero un grave impatto negativo 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 la chiave cache configurata intestazioni di richiesta nella risposta Vary. Non è obbligatorio per Cloud CDN, ma può essere utile per le cache downstream. Per ulteriori informazioni consulta Varia intestazioni.

Cloud CDN non consente l'inclusione delle seguenti intestazioni nel file di intestazioni:

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

Stessa intestazione con valori diversi

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

My-Header: Value1
My-Header: Value2

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

My-Header: Value1, Value2

Inclusi i cookie denominati

Un cookie HTTP è un accoppiamento di name=value e una richiesta può includere più cookie HTTP, separati da un punto e virgola sulla stessa riga oppure 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 memorizzati per dominio a 4 KB. Assicurati di non inviare troppi cookie (o cookie di dimensioni troppo grandi), poiché l'user agent potrebbe non inviare tutti i cookie in una richiesta. Ciò può influire 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 utilizzi pubblicare cookie, assicurati che l'attributo Domain del cookie (e Path) consente di inviare il cookie insieme alle richieste per i contenuti statici.

Se una richiesta include più istanze dello stesso nome cookie, solo la prima una è onorata.

Istruzioni di controllo cache

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

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

Direttiva Richiesta Risposta
no-store Quando è presente in una richiesta, Cloud CDN lo rispetta. non archivia la risposta nella cache.

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

È possibile eseguire l'override di questa funzione a livello di backend con Modalità cache FORCE_CACHE_ALL.

no-cache L'istruzione di richiesta no-cache viene ignorata per impedire ai client di potenzialmente avviando o forzando la riconvalida all'origine.

Una risposta con no-cache viene memorizzata nella cache, ma deve essere riconvalidato con l'origine prima della pubblicazione.

È possibile eseguire l'override di questa funzione a livello di backend con Modalità cache FORCE_CACHE_ALL.

public N/D

Questa istruzione non è obbligatoria per poter essere memorizzata nella cache, ma è una soluzione ottimale di includerlo nei contenuti che devono essere memorizzati nella cache da proxy.

private N/D

Una risposta con l'istruzione private non viene memorizzata nella cache da Cloud CDN, anche se la risposta viene considerata in altro modo memorizzabili nella cache. I client (ad esempio i browser) potrebbero comunque memorizzare nella cache il risultato.

È possibile eseguire l'override di questa funzione a livello di backend con Modalità cache FORCE_CACHE_ALL. Utilizza no-store per impedire la memorizzazione nella cache di tutte le risposte.

max-age=SECONDS L'istruzione della richiesta max-age viene ignorata. 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 SECONDS.
s-maxage=SECONDS N/D

Una risposta con l'istruzione s-maxage viene memorizzata nella cache fino a il valore SECONDS definito.

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

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

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

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/D
max-stale=SECONDS

L'istruzione della richiesta max-stale determina il numero massimo inattività (in secondi) che il cliente è disposto ad accettare.

Cloud CDN rispetta questa operazione e restituisce una cache inattiva solo se il livello di inattività della risposta è inferiore a max-stale. In caso contrario, viene riconvalidato prima della pubblicazione la richiesta.

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

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

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

stale-if-error=SECONDS L'istruzione della richiesta stale-if-error viene ignorata. Una copia cache come se questa intestazione non fosse inclusa nella richiesta.

Questa intestazione della risposta non ha alcun effetto.

must-revalidate N/D

Una risposta con must-revalidate viene riconvalidata con il valore server di origine alla scadenza.

Le risposte con questa istruzione non vengono pubblicate obsolete.

proxy-revalidate

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

Le risposte con questa istruzione non vengono pubblicate obsolete.

immutable N/D Nessun effetto. Questo viene trasmesso al client nella risposta.
no-transform N/D 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/D

Ove possibile, Cloud CDN cerca di essere compatibile con RFC (HTTP RFC) 7234), ma favorisce l'ottimizzazione per l'offload della cache e la riduzione al minimo dell'impatto che che i client possono avere in termini di percentuale di hit e 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 nello standard RFC 7231.
  • Un valore data nel passato, una data non valida o un valore 0 indica che il contenuto è già scaduto e deve essere riconvalidato.
  • Se nella risposta è presente un'intestazione Cache-Control, Cloud CDN ignora l'intestazione Expires.

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

L'intestazione Pragma HTTP/1.0, se presente in una risposta, viene ignorata e passata così com'è al client. Le richieste del client con questa intestazione sono passati all'origine e non influiscono sul modo in cui la risposta viene fornita con Cloud CDN.

Vary intestazioni

La Vary indica che la risposta varia in base alla query intestazioni delle richieste. Oltre all'URI della richiesta, Cloud CDN rispetta Intestazioni Vary che i server di origine includono nelle risposte. Ad esempio, se un risposta specifica Vary: Accept, Cloud CDN utilizza una voce della cache che specificano Accept: image/webp,image/*,*/*;q=0.8 e un altro per richieste che specificano Accept: */*.

La tabella nella sezione Elenchi delle sezioni dei contenuti non memorizzabili nella cache le intestazioni Vary che consentono di memorizzare i contenuti nella cache. Altri valori di intestazione Vary impedire la memorizzazione nella cache dei contenuti.

La modalità cache FORCE_CACHE_ALL non ignora questo comportamento. Vary sono importanti per evitare l'inquinamento della cache tra più possibili origini risposte del server. Sarebbe pericoloso per FORCE_CACHE_ALL causare quegli eventi memorizzarle nella cache.

Le intestazioni Vary vengono a volte utilizzate durante la pubblicazione di contenuti compressi. Cloud CDN non comprime o decomprime le risposte (a meno che compressione dinamica è abilitato), ma può fornire risposte compresse dal server di origine. Se le tue server di origine sceglie se pubblicare contenuti compressi o contenuti non compressi sul valore dell'intestazione della richiesta Accept-Encoding, accertati che La risposta specifica 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 della richiesta specificate, come per l'assistenza Vary ma senza il server di origine deve specificare in modo esplicito 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 intestazioni non sono state 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 per la riconvalida automatica dei contenuti memorizzati nella cache obsoleti e generati dagli utenti.

Quando Cloud CDN riceve una richiesta, cerca l'oggetto dalla voce della cache e ne controlla l'età. Se la voce della cache esiste ed è sufficientemente aggiornata, la risposta può essere fornita dalla cache. Se il tempo di scadenza è trascorso, Cloud CDN tenta di convalidare nuovamente la voce della cache contattando uno dei tuoi backend. Questo viene fatto prima di inviare la risposta, a meno che tu attivare serve-Mentre-stazioni, in in questo caso la riconvalida viene eseguita in modo asincrono.

Per alcune modalità cache, puoi impostare valori TTL. Per ulteriori informazioni, vedi Utilizzo delle impostazioni e degli override TTL.

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

Modalità cache Comportamento di convalida
CACHE_ALL_STATIC Le intestazioni dell'origine (Cache-Control: s-maxage, Cache-Control: max-age o Expires) sono consultato per verificarne l'aggiornamento. Per i contenuti statici, se le intestazioni di origine vengono non presente, il valore configurato (default_ttl) ne determina l'aggiornamento. Quando i contenuti statici sono più vecchi di default_ttl, Cloud CDN la riconvalida.
USE_ORIGIN_HEADERS Ogni voce di cache in una cache di Cloud CDN ha una scadenza definito dal Cache-Control: s-maxage, Cache-Control: max-age o Expires in in conformità con RFC 7234.
FORCE_CACHE_ALL Al posto delle intestazioni di origine, l'elemento default_ttl configurato ne determina l'aggiornamento. Quando i contenuti sono più vecchi di default_ttl, Cloud CDN la riconvalida.

Se ne sono presenti più di una, Cache-Control: s-maxage richiede 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 il valore della scadenza come se fosse 2.592.000 secondi. I client a valle continuano a vedere i valori accurati di max-age e s-maxage, anche se superano i 30 giorni.

Sfratto

Non vi è alcuna garanzia che una voce della cache rimanga nella cache fino alla scadenza perché le voci impopolari possono essere rimosse prima della scadenza in qualsiasi momento per fai spazio per nuovi contenuti. Come limite superiore, le voci della cache a cui non si accede per 30 giorni vengono automaticamente rimosse.

Per ulteriori informazioni, consulta Eviction ed eliminazione.

Utilizzare le richieste condizionali per la convalida

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

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

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

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

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

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

Supporto per le richieste di intervalli di byte

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

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

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

I più diffusi software server web supportano anche le richieste con intervallo di byte. Consulta il relativa al server web per i dettagli su come attivare il supporto. Per per ulteriori informazioni sulle richieste di intervalli di byte, Specifica HTTP.

Quando un server di origine supporta le richieste di intervallo di byte, La cache 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 questi casi, la risposta soddisferebbe altrimenti il normale requisiti di memorizzazione nella cache, la cache registra che l'origine supporta le richieste di intervalli di byte per quella chiave cache e inoltra l'origine la risposta del server al client.

In caso di fallimento della cache, la cache controlla se il server di origine è noto per il supporto richieste di intervalli di byte. Se è noto che le richieste di intervalli di byte sono supportate , la cache non inoltra la richiesta del client al bilanciatore del carico delle applicazioni esterno. La cache avvia invece il proprio 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ò per archiviare l'intervallo per le richieste future.

Una cache memorizza una risposta 206 Partial Content solo quando viene ricevuta in risposta a una richiesta di intervallo di byte avviata dalla cache. Poiché una cache non avvia una richiesta di intervallo di byte a meno che non avesse precedentemente registrato che server di origine supporta le richieste di intervalli di byte per quella chiave cache, non archivia contenuti superiori a 1 MB fino alla seconda volta l'accesso ai contenuti.

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

Richiesta di compressione (coalescing)

La richiesta di compressione (chiamata anche coalescing) comprime attivamente più elementi richieste di riempimento della cache guidate dall'utente per la stessa chiave cache in un'unica origine richiesta per nodo perimetrale. Ciò può ridurre attivamente il carico sull'origine si applica sia alle richieste item (risposte recuperate direttamente) sia richieste di chunk, in cui Cloud CDN utilizza richieste Range per recuperare maggiormente gli oggetti più grandi in modo efficiente.

La compressione delle richieste è attivata per impostazione predefinita.

Le richieste compresse si comportano nel seguente modo:

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

Il seguente diagramma mostra come vengono unite le richieste:

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

In confronto, se la compressione delle richieste è disabilitata o per le richieste che non possono essere coalescati, il numero di richieste di origine e di risposte può essere uguale al di client che tentano di recuperare un oggetto non memorizzato nella cache.

Cloud CDN senza compressione delle richieste abilitato.
Cloud CDN senza compressione delle richieste abilitato (fai clic per ingrandire).

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

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

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

Per disabilitare la richiesta di elementi in un bucket di backend utilizzando Google Cloud CLI 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

Utilizza 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

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

Se la risposta che indicava che il server di origine supportava richieste di intervalli di byte chiave cache è scaduta, Cloud CDN avvia una richiesta di convalida per confermare che i contenuti non siano cambiati e che i tuoi il server di origine supporta ancora le richieste di intervallo per i contenuti. Se la tua origine server risponde con una risposta 304 Not Modified, Cloud CDN gestisce il contenuto utilizzando intervalli di byte. Altrimenti, Cloud CDN inoltra la risposta del server di origine al messaggio di alto profilo. Puoi controllare le date di scadenza utilizzando le intestazioni di risposta Cache-Control e Expires.

In caso di mancata corrispondenza nella 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 siano presenti nella cache i contenuti richiesti dal client Cloud CDN gestisce tutto ciò che può dalla cache e invia i byte solo per gli intervalli mancanti al server di origine.

Ogni richiesta di intervallo di byte avviata da Cloud CDN specifica un intervallo che inizia con un offset che è un multiplo di 2.097.136 byte. Con la possibile fatta eccezione per l'intervallo finale, ogni intervallo è anche pari a 2.097.136 byte. Se se i contenuti non sono multipli di quella dimensione, l'intervallo finale è inferiore. La le dimensioni e gli offset utilizzati nelle richieste di intervalli di byte potrebbero cambiare in futuro.

Ad esempio, prendiamo in considerazione una richiesta del client per i byte da 1.000.000 a 3.999.999 di contenuti non presenti nella cache. In questo esempio, Cloud CDN potrebbe avviare due richieste GET, una per la prima 2.097.136 byte di contenuto e un altro per i secondi 2.097.136 byte. Questo produce 4.194.272 byte di riempimento della cache anche se il client ha richiesto solo 3.000.000 di byte.

Quando usi un bucket Cloud Storage come origine, ogni richiesta GET viene e fatturate 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 interamente gestite dalla cache di Cloud CDN, non vengono inviate richieste GET Cloud Storage e non ti viene addebitato alcun costo per Cloud Storage operazioni aziendali.

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

Nella sezione 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 anche se i contenuti erano stati precedentemente memorizzati nella cache.

Questa sezione fornisce informazioni su come bypassare la cache con le intestazioni HTTP, come Pragma e Authorization. Questa funzione è utile quando vuoi assicurati che i tuoi utenti o clienti abbiano sempre a disposizione i contenuti più recenti dal server di origine. Potresti volerlo fare per testare, configurare directory di staging o script.

Se un'intestazione specificata corrisponde, la cache viene ignorata per tutte le impostazioni della modalità cache, anche per FORCE_CACHE_ALL. L'esclusione della cache provoca un elevato numero di falliranno nella 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 campo intestazione HTTP valido di accesso. Il nome di un'intestazione non deve apparire più di una volta nell'elenco delle intestazioni aggiunte. Per le regole relative ai nomi di intestazione validi, consulta Come funzionano le intestazioni personalizzate.

Console

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

    Vai alla pagina Bilanciamento del carico

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

gcloud

Per i bucket di backend, utilizza gcloud compute backend-buckets crea o gcloud compute backend-buckets comando 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 Metodo: backendBuckets.insert, Metodo: backendBuckets.update, oppure Metodo: backendBuckets.patch chiamata API.

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

Ad esempio:

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

Aggiungi il seguente snippet al corpo della richiesta JSON:

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

Disabilitazione del bypass della cache in corso...

gcloud

Per i bucket di backend, utilizza gcloud compute backend-buckets crea o gcloud compute backend-buckets comando 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 Metodo: backendBuckets.insert o Metodo: backendBuckets.update chiamata API.

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

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