Media CDN pubblica i contenuti il più vicino possibile agli utenti utilizzando l'infrastruttura di memorizzazione in una cache perimetrale globale di Google per memorizzare i contenuti nella cache e ridurre il carico sull'infrastruttura di origine.
Puoi controllare la modalità di memorizzazione nella cache dei contenuti per ogni route. In questo modo, puoi ottimizzare il comportamento in base al tipo di contenuti, agli attributi delle richieste dei client e ai tuoi requisiti di aggiornamento.
Cacheabilità
Le sezioni seguenti descrivono le risposte memorizzate nella cache da Media CDN e come migliorare lo sgravio della cache.
Comportamento di memorizzazione nella cache predefinito
Per impostazione predefinita, a ogni servizio della cache Edge vengono applicate le seguenti impostazioni relative alla cache:
Modalità cache predefinita di
CACHE_ALL_STATIC
:- Rispetta le direttive della cache dell'origine, ad esempio
Cache-Control
oExpires
, fino a un TTL max configurabile. - Memorizza automaticamente nella cache i tipi di contenuti multimediali statici con un TTL predefinito di 3600 secondi, se non sono presenti direttive cache dell'origine.
- Memorizza nella cache i codici di stato HTTP 200 e 206 (la memorizzazione nella cache negativa non è attivata).
- Rispetta le direttive della cache dell'origine, ad esempio
Non memorizza nella cache le risposte con direttive cache-control
no-store
oprivate
o che non sono memorizzabili in cache.
Le risposte che non sono contenuti statici o che non contengono direttive di cache valide non vengono memorizzate nella cache, a meno che la memorizzazione nella cache non sia configurata esplicitamente. Per scoprire come eseguire l'override del comportamento predefinito, consulta la documentazione sulle modalità della cache .
Il comportamento predefinito è equivalente al seguente cdnPolicy
. I percorsi senza un cdnPolicy
esplicito configurato si comportano come se avessero la seguente configurazione:
cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 3600s cacheKeyPolicy: includeProtocol: false excludeHost: false excludeQueryString: false signedRequestMode: DISABLED negativeCaching: false
Risposte memorizzabili nella cache
Una risposta memorizzabile nella cache è una risposta HTTP che Media CDN può memorizzare e recuperare rapidamente, consentendo tempi di caricamento più rapidi. Non tutte le risposte HTTP sono memorizzabili nella cache.
Puoi configurare le modalità di cache per ogni route per ignorare questo comportamento (ad esempio, utilizzando la modalità di cache CACHE_ALL_STATIC
per memorizzare nella cache i tipi di media comuni) anche se l'origine non imposta una direttiva di controllo della cache nella risposta.
Le richieste e le risposte che soddisfano i criteri definiti in risposte non memorizzabili nella cache sostituiscono la memorizzazione nella cache.
La seguente tabella descrive i requisiti per memorizzare nella cache determinate risposte HTTP. Sia le risposte GET
che HEAD
devono rispettare questi requisiti.
Attributo HTTP | Requisiti |
---|---|
Codice stato | Il codice di stato della risposta deve essere uno tra 200, 203, 206, 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451, 500, 501, 502, 503 o 504. |
Metodi HTTP | GET e HEAD |
Intestazioni delle richieste | La maggior parte delle istruzioni di richiesta di memorizzazione nella cache viene ignorata. Per ulteriori informazioni, consulta Direttive Cache-Control. |
Intestazioni della risposta | Contiene una direttiva di memorizzazione nella cache HTTP valida, ad esempio Ha una modalità cache che memorizza nella cache i contenuti o ha un' |
Dimensioni risposta | Fino a 100 GiB. |
L'intestazione HTTP Age
viene impostata in base al momento in cui Media CDN ha eseguito per la prima volta la cache della risposta e in genere rappresenta i secondi trascorsi dal momento in cui l'oggetto è stato memorizzato nella cache in una località di schermo dell'origine. Se la tua origine genera un'intestazione di risposta Age, utilizza la modalità cache FORCE_CACHE_ALL
per impedire le verifiche di convalida quando Age supera il TTL della cache.
Per ulteriori informazioni su come Media CDN interpreta le direttive di memorizzazione nella cache HTTP, consulta Direttive Cache-Control.
Requisiti dell'origine
Per consentire a Media CDN di memorizzare nella cache le risposte dell'origine più grandi di 1 MiB, un'origine deve includere quanto segue nelle intestazioni di risposta sia per le richieste HEAD
che GET
, se non diversamente specificato:
- Un'intestazione della risposta HTTP
Last-Modified
oETag
(un convalidatore). - Un'intestazione HTTP
Date
valida. - Un'intestazione
Content-Length
valida. - L'intestazione della risposta
Content-Range
in risposta a una richiestaRange GET
. L'intestazioneContent-Range
deve avere un valore valido nel formatobytes x-y/z
(dovez
è la dimensione dell'oggetto).
Il protocollo di origine predefinito è HTTP/2. Se le tue origini supportano solo HTTP/1.1, puoi impostare il campo del protocollo in modo esplicito per ogni origine.
Risposte non memorizzabili nella cache
La seguente tabella illustra gli attributi di richiesta e risposta che impediscono la memorizzazione nella cache di una risposta. Le risposte che sono memorizzabili nella cache, ma che corrispondono ai criteri "non memorizzabili nella cache", non vengono memorizzate nella cache.
Attributo HTTP | Requisito |
---|---|
Codice stato | Un codice di stato diverso da quelli definiti come memorizzabili nella cache, ad esempio HTTP 401, HTTP 412 o HTTP 505. Questi codici di stato sono in genere rappresentativi di problemi relativi al cliente e non dello stato di origine. La memorizzazione nella cache di queste risposte può portare a scenari di "cache poisoning" in cui una risposta "errata" attivata dall'utente viene memorizzata nella cache per tutti gli utenti. |
Intestazioni delle richieste | Per le richieste con un'intestazione
Una direttiva |
Intestazioni della risposta | Contiene un'intestazione Ha un'intestazione In modalità |
Dimensioni risposta | Più di 100 GiB. |
Queste regole si applicano in aggiunta alla modalità cache configurata. In particolare:
- Con la modalità cache
CACHE_ALL_STATIC
configurata, vengono memorizzate nella cache solo le risposte considerate contenuti statici o le risposte con direttive di memorizzazione nella cache valide nelle intestazioni di risposta. Le altre risposte vengono proxyizzate così come sono. - La modalità cache
FORCE_CACHE_ALL
memorizza incondizionatamente tutte le risposte, in base ai requisiti di non memorizzazione nella cache indicati in precedenza. - La modalità cache
USE_ORIGIN_HEADERS
richiede che le risposte impostino direttive di memorizzazione nella cache valide nelle intestazioni di risposta, oltre a essere un codice di stato memorizzabile nella cache.
Note:
- Le risposte che non vengono memorizzate nella cache non hanno le direttive di controllo della cache o altre intestazioni modificate e vengono proxyizzate così come sono.
- Le intestazioni
Cache-Control
eExpires
delle risposte possono essere compresse in un unico campoCache-Control
. Ad esempio, una risposta conCache-Control: public
eCache-Control: max-age=100
su righe separate verrebbe compressa comeCache-Control: public,max-age=100
. - Le risposte non memorizzabili nella cache (risposte che non verrebbero mai memorizzate nella cache) non vengono conteggiate come
Cache Egress
dal punto di vista della fatturazione.
Utilizzo delle modalità cache
Le modalità cache ti consentono di configurare quando Media CDN deve rispettare le direttive di memorizzazione nella cache dell'origine, memorizzare nella cache i tipi di contenuti multimediali statici e memorizzare nella cache tutte le risposte dall'origine, indipendentemente dalle direttive impostate.
Le modalità di cache vengono configurate a livello di route e, combinate con le sostituzioni TTL, consentono di configurare il comportamento della cache in base a host, percorso, parametri di ricerca e intestazioni (qualsiasi parametro di richiesta che può essere associato).
- Per impostazione predefinita, Media CDN utilizza la modalità cache
CACHE_ALL_STATIC
, che memorizza automaticamente nella cache i tipi di contenuti multimediali statici comuni per 1 ora (3600 secondi), dando la priorità a eventuali direttive di cache specificate dall'origine per le risposte memorizzabili nella cache. - Puoi aumentare o diminuire la durata (TTL) della cache applicata alle risposte senza impostare un valore TTL della cache esplicito (una direttiva
max-age
os-maxage
) impostando il campocdnPolicy.defaultTtl
in un percorso. - Per evitare di memorizzare nella cache le risposte non andate a buon fine per più tempo del previsto,
i codici di stato non 2xx (non andati a buon fine) non vengono memorizzati nella cache in base al loro
Content-Type
(tipo MIME) e non viene applicato il TTL predefinito.
Le modalità di cache disponibili, impostate su cdnPolicy.cacheMode
di ogni route, sono riportate nella tabella seguente.
Modalità cache | Comportamento |
---|---|
USE_ORIGIN_HEADERS |
Richiede risposte provenienti dall'origine per impostare valide direttive di memorizzazione nella cache e valide intestazioni di memorizzazione nella cache. Per un elenco completo dei requisiti, consulta Risposte memorizzabili nella cache. |
CACHE_ALL_STATIC |
Memorizza automaticamente nella cache le risposte positive con contenuti statici,
a meno che non abbiano una direttiva I contenuti statici includono video, audio, immagini e asset web comuni come
definito dal tipo MIME nell'intestazione della risposta |
FORCE_CACHE_ALL |
Memorizza incondizionatamente le risposte corrette nella cache, ignorando qualsiasi direttiva di memorizzazione nella cache impostata dall'origine. Assicurati di non pubblicare contenuti privati per utente (come HTML dinamico o risposte dell'API) con questa modalità configurata. |
BYPASS_CACHE | Qualsiasi richiesta che corrisponde a una route con questa modalità cache configurata aggira la cache, anche se esiste un oggetto memorizzato nella cache che corrisponde a quella chiave. Ti consigliamo di utilizzarlo solo per il debug perché Media CDN è progettata come un'infrastruttura di cache a livello mondiale e non come un proxy per uso generale. |
Tipi MIME dei contenuti statici
La modalità cache CACHE_ALL_STATIC
consente a Media CDN di memorizzare automaticamente nella cache i contenuti statici comuni come video, audio, immagini e asset web comuni in base al tipo MIME restituito nell'intestazione di risposta HTTP Content-Type
. Tuttavia, indipendentemente dal tipo di media, Media CDN dà la priorità a eventuali intestazioni Cache-Control
o Expires
esplicite nella risposta dell'origine.
La tabella seguente elenca i tipi MIME che possono essere memorizzati nella cache automaticamente
con la modalità cache CACHE_ALL_STATIC
.
Le risposte non vengono memorizzate automaticamente nella cache se non hanno un'intestazione di risposta Content-Type
con un valore che corrisponde ai seguenti valori. Devi assicurarti che la risposta imposti una direttiva di memorizzazione nella cache valida oppure devi utilizzare la modalità cache FORCE_CACHE_ALL
per memorizzare incondizionatamente le risposte nella cache.
Categoria | Tipi MIME |
---|---|
Asset web | text/css text/ecmascript text/javascript application/javascript |
Caratteri | Qualsiasi corrispondenza di Content-Type font/* |
Immagini | Qualsiasi corrispondenza di Content-Type image/* |
Video | Qualsiasi corrispondenza di Content-Type video/* |
Audio | Qualsiasi corrispondenza di Content-Type audio/* |
Tipi di documenti formattati | application/pdf and application/postscript |
Tieni presente quanto segue:
- Il software del server web dell'origine deve impostare
Content-Type
per ogni risposta. Molti server web impostano automaticamente l'Content-Type
header, tra cui NGINX, Varnish e Apache. - Cloud Storage imposta l'intestazione
Content-Type
automaticamente al caricamento quando utilizzi la console Google Cloud o l'interfaccia a gcloud CLI per caricare i contenuti. - Cloud Storage fornisce sempre un'intestazione
Cache-Control
a Media CDN. Se non viene scelto esplicitamente alcun valore, viene inviato un valore predefinito. Di conseguenza, tutte le risposte di Cloud Storage andate a buon fine vengono memorizzate nella cache in base ai valori predefiniti di Cloud Storage, a meno che non modifichi esplicitamente i metadati di controllo della cache per gli oggetti in Cloud Storage o utilizzi la modalitàFORCE_CACHE_ALL
per eseguire l'override dei valori inviati da Cloud Storage.
Se una risposta è memorizzabile nella cache in base al tipo MIME, ma ha una direttiva di risposta Cache-Control
di private
o
no-store
o un'intestazione Set-Cookie
, non viene memorizzata nella cache.
Altri tipi di contenuti multimediali, come HTML (text/html
) e JSON
(application/json
), non vengono memorizzati nella cache per impostazione predefinita. Questi tipi di risposte sono tipicamente dinamiche (per utente) e non sono molto adatte all'architettura di Media CDN. Ti consigliamo di utilizzare
Cloud CDN per pubblicare asset web e per memorizzare nella cache le risposte dell'API.
Configura i TTL della cache
Le sostituzioni della durata (TTL) ti consentono di impostare valori TTL predefiniti per i contenuti memorizzati nella cache e di sostituire i valori TTL impostati nelle direttive di controllo della cache max-age
e s-maxage
(o negli header Expires
) impostati dalle origini.
I TTL, impostati tramite override o utilizzando una direttiva cache, sono ottimistici. I contenuti a cui si accede raramente o che non sono molto apprezzati potrebbero essere eliminati dalla cache prima del raggiungimento del TTL.
La tabella seguente mostra tre impostazioni TTL.
Impostazione | Predefinito | Minimo | Massimo | Descrizione | Modalità cache applicabili |
---|---|---|---|---|---|
Default TTL | 1 ora (3600 secondi) |
0 secondi | 1 anno (31.536.000 secondi) |
Il TTL da impostare quando l'origine non ha specificato un'intestazione Se l'origine specifica un'intestazione Quando utilizzi |
|
Max TTL | 1 giorno (86400 secondi) |
0 secondi | 1 anno (31.536.000 secondi) |
Per le risposte memorizzabili nella cache, il TTL massimo da consentire. I valori superiori
a questo sono limitati al valore di maxTtl .
|
CACHE_ALL_STATIC |
Client TTL | Non impostata per impostazione predefinita. | 0 secondi | 1 giorno (86400 secondi) |
Per le risposte memorizzabili nella cache, il TTL massimo da consentire nella risposta a valle (visibile al client) se deve essere diverso da altri valori TTL. |
|
L'impostazione di un valore TTL su zero (0 secondi) comporta la convalida di ogni richiesta con l'origine prima che venga inviata una risposta e aumenta il carico sull'origine se impostato in modo troppo generico.
Quando la modalità cache è impostata su Use Origin Headers
, le impostazioni TTL non possono essere configurate perché Media CDN si basa sull'origine per determinare il comportamento.
Note:
- Il valore del TTL max deve sempre essere maggiore (o uguale) al valore del TTL predefinito.
- Il valore del TTL client deve sempre essere minore (o uguale) al valore del TTL massimo.
- Quando Media CDN sostituisce un valore TTL di origine, anche l'intestazione
Cache-Control
inviata al client riflette questo valore. - Se l'origine imposta un'intestazione
Expires
e Media CDN sovrascrive il TTL effettivo (in base al timestamp), l'intestazioneExpires
viene sostituita con un'intestazioneCache-Control
nella risposta downstream al client.
Memorizzazione nella cache negativa
La memorizzazione nella cache negativa definisce in che modo i codici di stato HTTP non di successo (diversi da 2xx) vengono memorizzati nella cache da Media CDN.
In questo modo puoi memorizzare nella cache le risposte di errore come i reindirizzamenti (HTTP 301 e 308) e le risposte di tipo non trovato (HTTP 404) più vicine agli utenti, nonché ridurre il caricamento dell'origine in modo più generale se la risposta è improbabile che cambi e può essere memorizzata nella cache.
Per impostazione predefinita, la memorizzazione nella cache negativa è disattivata. La tabella seguente mostra i valori predefiniti per ogni codice di stato quando la memorizzazione nella cache negativa è attivata e non viene utilizzato negativeCachingPolicy
.
Codici di stato | Motivo-frase | TTL |
---|---|---|
HTTP 300 | Scelte multiple | 10 minuti |
HTTP 301 e HTTP 308 | Reindirizzamento permanente | 10 minuti |
HTTP 404 | Non trovato | 120 secondi |
HTTP 405 | Metodo non trovato | 60 secondi |
HTTP 410 | Gone (Non più disponibile) | 120 secondi |
HTTP 451 | Unavailable for Legal Reasons | 120 secondi |
HTTP 501 | Non implementato | 60 secondi |
L'insieme predefinito di codici di memorizzazione nella cache negativa corrisponde ai codici di stato memorizzabili in modo euristico descritti nel RFC 9110 HTTP, con le seguenti eccezioni:
- Il codice HTTP 414 (URI troppo lungo) non è supportato per la memorizzazione nella cache, per evitare l'avvelenamento della cache.
- Il codice HTTP 451 (Non disponibile per motivi legali) è supportato per la memorizzazione nella cache, come descritto nel RFC 7725 HTTP.
Se devi configurare i tuoi TTL per codice di stato e eseguire l'override del comportamento predefinito, puoi configurare un cdnPolicy.negativeCachingPolicy
. In questo modo puoi impostare il TTL per uno qualsiasi dei codici di stato consentiti da Media CDN: 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451, 500, 501, 502, 503 e 504.
Ad esempio, per impostare un TTL breve di 5 secondi per le risposte HTTP 404 (Pagina non trovata) e un TTL di 10 secondi per le risposte HTTP 405 (Metodo non consentito), utilizza la seguente definizione YAML su ogni route applicabile:
cdnPolicy: negativeCaching: true negativeCachingPolicy: "404": 5s "405": 10s # other status codes to apply TTLs for
Per evitare l'avvelenamento della cache, non è consigliabile attivare la memorizzazione nella cache per i codici stato 400 (Richiesta non valida) o 403 (Forbidden). Assicurati che il server di origine giri uno dei due codici in seguito all'esame solo dei componenti della richiesta inclusi nella chiave della cache. L'avvelenamento della cache può verificarsi, ad esempio, quando il server di origine risponde con una risposta di errore 403 in assenza di un'intestazione Authorization
corretta. In questo caso, la memorizzazione nella cache della risposta di errore 403 fa sì che Media CDN la invii a tutte le richieste successive fino alla scadenza del TTL, anche se le richieste hanno un'intestazione Authorization
corretta.
Per disattivare la memorizzazione nella cache negativa:
- Per disattivare il comportamento predefinito della memorizzazione nella cache negativa, imposta
cdnPolicy.negativeCaching: false
su un percorso. Tieni presente che le risposte dell'origine con direttive di cache valide e codici di stato memorizzabili nella cache vengono comunque memorizzate nella cache. - Per evitare la memorizzazione nella cache negativa per un codice di stato specifico, rispettando al contempo le direttive della cache dell'origine, ometti il codice di stato (
cdnPolicy.negativeCachingPolicy[].code
) nella definizione dinegativeCachingPolicy
. - Per ignorare esplicitamente le direttive della cache dell'origine per un codice stato specifico, imposta
cdnPolicy.negativeCachingPolicy[].ttl
su0
(zero) per quel codice stato.
Note:
- Quando
negativeCaching
è abilitato in un percorso e una risposta definisce direttive di memorizzazione nella cache valide, le direttive di memorizzazione nella cache nella risposta hanno la precedenza. - Se configuri un
negativeCachingPolicy
esplicito ed è definito un TTL per il codice di stato specificato, viene sempre utilizzato il TTL definito nel criterio. - Il valore massimo per un TTL impostato da
negativeCachingPolicy
è 1800 secondi (30 minuti), ma le direttive della cache di origine con un TTL più elevato vengono rispettate. - Se la modalità cache è configurata come
FORCE_CACHE_ALL
, le direttive di origine vengono ignorate in tutti i casi.
Istruzioni di controllo cache
Il comportamento della CDN multimediale rispetto alle direttive Cache-Control
è definito qui.
Se la direttiva non è applicabile a una richiesta o a una risposta, ad esempioonly-if-cached
(una direttiva solo per il client), in quella colonna viene contrassegnato il valore "N/A".
Direttiva | Richiesta | Risposta |
---|---|---|
no-cache |
La direttiva di richiesta no-cache viene ignorata per impedire ai client di
potenzialmente avviare o forzare la convalida dell'origine. |
Una risposta con Questo valore può essere ignorato su base per percorso con la
|
no-store |
La risposta a una richiesta con no-store non viene memorizzata nella cache. |
Una risposta con Questo valore può essere ignorato su base per percorso con la
|
public |
N/D | Una risposta con la direttiva Se utilizzi la modalità cache |
private |
N/D | Una risposta con la direttiva Questo valore può essere ignorato su base per percorso con la
Utilizza |
max-age=SECONDS |
L'istruzione della richiesta max-age viene ignorata. Viene restituita una risposta memorizzata nella cache come se questa intestazione non fosse inclusa nella richiesta. | Una risposta con la direttiva max-age viene memorizzata nella cache fino al valore SECONDS definito. |
s-maxage=SECONDS |
N/D | Una risposta con la direttiva Se sono presenti sia Tieni presente che |
min-fresh=SECONDS |
L'istruzione di richiesta min-fresh viene ignorata. Viene restituita una risposta memorizzata nella cache come se questa intestazione non fosse inclusa nella richiesta. |
N/D |
max-stale=SECONDS |
L'istruzione di richiesta Viene restituita una risposta memorizzata nella cache come se questa intestazione non fosse inclusa nella richiesta. |
N/D |
stale-while-revalidate=SECONDS |
N/D | Nessun effetto. Questo viene trasmesso al client nella risposta. |
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. |
Nessun effetto. Questo viene trasmesso al client nella risposta. |
must-revalidate |
N/D | Una risposta con |
proxy-revalidate |
N/D | Una risposta con |
immutable |
N/D | Nessun effetto. Questo viene trasmesso al client nella risposta. |
no-transform |
N/D | Media CDN non applica trasformazioni. |
only-if-cached |
L'istruzione di richiesta only-if-cached viene ignorata. Viene restituita una risposta memorizzata nella cache come se questa intestazione non fosse inclusa nella richiesta. |
N/D |
Ove possibile, Media CDN è conforme allo standard RFC (RFC 7234 HTTP), ma favorisce l'ottimizzazione per lo scambio della cache e riduce al minimo l'impatto che i client possono avere sul tasso di hit e sul carico complessivo dell'origine.
Per le risposte che utilizzano l'intestazione Expires
HTTP/1.1:
- Il valore dell'intestazione
Expires
deve essere una data HTTP valida come definito nel documento RFC 7231 - Un valore di data passato, una data non valida o un valore
0
indica che i contenuti sono già scaduti e richiedono una nuova convalida. - Media CDN ignora l'intestazione
Expires
se nella risposta è presente un'intestazioneCache-Control
.
L'intestazione Pragma
HTTP/1.0, se presente in una risposta, viene ignorata e passata così com'è al client.
Chiavi cache
Puoi ridurre il numero di volte in cui Media CDN deve contattare la tua origine tenendo conto di ciò che identifica in modo univoco una richiesta e rimuovendo i componenti che potrebbero cambiare spesso da una richiesta all'altra. L'insieme di componenti della richiesta è spesso indicato come "chiave della cache".
Le sezioni seguenti descrivono come configurare le chiavi della cache.
Componenti chiave di cache
Una chiave cache è l'insieme di parametri di richiesta (ad esempio i parametri host, percorso e query) a cui fa riferimento un oggetto memorizzato nella cache.
Per impostazione predefinita, le chiavi della cache per i servizi Edge Cache includono l'host della richiesta, il percorso e parametri di ricerca della richiesta e sono limitate a un servizio EdgeCache specifico.
Componente | È incluso per impostazione predefinita? | Dettagli |
---|---|---|
Protocollo | No | Le richieste tramite HTTP e HTTPS fanno riferimento allo stesso oggetto memorizzato nella cache. Se vuoi restituire risposte diverse alle richieste http: e https:,
imposta |
Organizzatore | Sì | Host diversi non fanno riferimento agli stessi oggetti memorizzati nella cache. Se hai più nomi host indirizzati allo stesso EdgeCacheService e
questi pubblicano gli stessi contenuti, imposta
|
Percorso | Sì | È sempre incluso nella chiave della cache e non può essere rimosso. Il percorso è la representatione minima di un oggetto in cache. |
Parametri di query | Sì | Se parametri di ricerca non distinguono tra risposte diverse,
imposta Se in una chiave cache devono essere inclusi solo alcuni parametri di ricerca, imposta
|
Intestazioni | No | Imposta La specifica di più intestazioni che si combinano per avere un ampio intervallo di valori (ad esempio, i valori dell'intestazione combinati identificano un singolo utente) consente di ridurre drasticamente il tasso di successo della cache e può comportare un tasso di espulsione più elevato e prestazioni ridotte. |
Cookie | No | Imposta La specifica di più cookie che si combinano per avere un ampio intervallo di valori (ad esempio, i valori combinati dei cookie identificano un singolo utente) consente di ridurre drasticamente il tasso di successo della cache e può comportare un tasso di espulsione più elevato e prestazioni ridotte. |
Tieni presente quanto segue:
- Le chiavi della cache non sono associate a un'origine configurata, il che ti consente di aggiornare la configurazione di un'origine (o di sostituirla completamente) senza il rischio di "svuotare" la cache (ad esempio, durante la migrazione dello spazio di archiviazione dell'origine tra provider).
- Le chiavi della cache sono vincolate a un EdgeCacheService. I diversi EdgeCacheService hanno diversi spazi dei nomi della cache, il che impedisce di memorizzare nella cache per errore oggetti tra ambienti di produzione, di gestione temporanea e altri ambienti di test, anche se gli host, i percorsi o altri componenti delle chiavi della cache corrispondono. L'eliminazione di un servizio EdgeCacheService invalida in modo efficace tutti gli oggetti memorizzati nella cache per quel servizio.
- Le chiavi della cache non sono limitate a una singola route. Più percorsi potrebbero fare riferimento alla stessa chiave della cache, in particolare se corrispondono a componenti non inclusi nella chiave della cache, come gli intestazioni di richiesta o i parametri esclusi. Questa operazione può essere utile se vuoi che più route condividano la stessa cache, ma che rimandino intestazioni di risposta o configurazioni CORS diverse.
- Le chiavi della cache non includono la configurazione della riscrittura dell'URL. Ad esempio, una chiave della cache si basa sulla richiesta rivolta agli utenti e non sulla richiesta finale "riscritta".
- Quando le richieste firmate sono configurate su un percorso, gli attributi firmati non sono inclusi nella chiave cache. La richiesta viene trattata come se i parametri di ricerca (firmati) o il componente del percorso, che iniziano con
edge-cache-token
e terminano con il successivo separatore di percorso ("/"), non facessero parte dell'URL.
Includi o escludi parametri di ricerca
Puoi includere o escludere parametri di ricerca specifici da una chiave cache aggiungendo il nome del parametro alla configurazione della chiave cache includedQueryParameters
o excludedQueryParameters
in un determinato percorso.
Ad esempio, per includere i parametri di ricerca contentID
e country
e ignorare tutti gli altri dalla chiave cache:
cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 86400s cacheKeyPolicy: includedQueryParameters: ["contentID", "country"]
Assicurati di includere i parametri di ricerca che identificano in modo univoco i contenuti ed escludi quelli che non lo fanno. Ad esempio, escludi parametri di ricerca di analisi, gli ID sessione di riproduzione o altri parametri che sono univoci solo per il cliente. L'inclusione di più parametri di ricerca del necessario può ridurre i tassi di successo della cache.
In alternativa, anziché specificare i parametri da includere nella chiave della cache, puoi scegliere quelli da escludere. Ad esempio, per escludere dalla chiave della cache le informazioni relative all'ID di riproduzione e al timestamp specifici del client, configura quanto segue:
cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 86400s cacheKeyPolicy: excludedQueryParameters: ["playback-id", "timestamp"]
Per un determinato percorso, puoi specificare includedQueryParameters
o
excludedQueryParameters
.
Se parametri di ricerca non vengono mai utilizzati per identificare in modo univoco i contenuti nelle richieste,
puoi rimuovere tutti parametri di ricerca dalla chiave della cache per un percorso. Per farlo, imposta excludeQueryString
su true
, come segue:
cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 3600s cacheKeyPolicy: excludeQueryString: true
Se in un percorso sono attivate le richieste firmate, parametri di ricerca utilizzati per la firma non sono inclusi nella stringa di query e vengono ignorati se inclusi. L'inclusione dei parametri firmati nella chiave della cache rende effettivamente univoca ogni richiesta dell'utente e richiede che ogni richiesta sia pubblicata dall'origine.
Ordinamento dei parametri di query
I parametri di query (stringhe di query) sono ordinati per impostazione predefinita per migliorare i tassi di successo della cache, in quanto i client potrebbero riordinare o richiedere in altro modo lo stesso oggetto memorizzato nella cache con un ordine diverso dei parametri di ricerca.
Ad esempio, i parametri di ricerca b=world&a=hello&z=zulu&p=paris
e
p=paris&a=hello&z=zulu&b=world
sono ordinati come a=hello&b=world&p=paris&z=zulu
prima che venga ricavata la chiave cache. In questo modo, entrambe le richieste vengono associate allo stesso oggetto memorizzato nella cache, evitando una richiesta non necessaria all'origine (e una risposta da parte dell'origine).
Se sono presenti più istanze di una chiave del parametro di query, ciascuna con valori distinti, i parametri vengono ordinati in base al valore completo (ad esempio, a=hello
viene ordinato prima di a=world
). L'ordinamento non può essere disattivato.
Includi intestazioni
I nomi delle intestazioni non fanno distinzione tra maiuscole e minuscole e vengono convertiti in minuscole da Media CDN.
Le seguenti intestazioni non possono essere incluse nella chiave della cache:
- Qualsiasi intestazione che inizia con
access-control-
- Qualsiasi intestazione che inizia con
sec-fetch-
- Qualsiasi intestazione che inizia con
x-amz-
- Qualsiasi intestazione che inizia con
x-goog-
- Qualsiasi intestazione che inizia con
x-media-cdn-
accept-encoding
accept
authorization
cdn-loop
connection
content-md5
content-type
cookie
date
forwarded
from
host
if-match
if-modified-since
if-none-match
origin
proxy-authorization
range
referer
referrer
user-agent
want-digest
x-csrf-token
x-csrftoken
x-forwarded-for
Per includere il metodo HTTP nella chiave cache, utilizza il nome dell'intestazione speciale:method
.
Includi cookie
I nomi dei cookie sono sensibili alle maiuscole.
I cookie che iniziano con edge-cache-
in qualsiasi combinazione di lettere maiuscole o minuscole
non possono essere utilizzati nella chiave della cache.
Riconvalida, eliminazione e scadenza
Le reti CDN (Content Delivery Network), tra cui Media CDN, funzionano memorizzando nella cache i contenuti più popolari il più vicino possibile agli utenti.
L'ampio spazio di archiviazione di Media CDN, nonché la protezione dell'origine, riducono la necessità di eliminare anche i contenuti meno popolari. I contenuti a cui si accede un numero ridotto di volte al giorno potrebbero essere eliminati.
- Le risposte memorizzate nella cache che raggiungono il TTL configurato potrebbero non essere eliminate immediatamente. Per i contenuti popolari, Media CDN conferma che la risposta memorizzata nella cache è la versione più recente inviando una richiesta
HEAD
all'origine per verificare che le intestazioni non siano cambiate. In alcuni casi, Media CDN invia invece una richiesta all'origine con una o entrambe le seguenti intestazioni di richiesta:If-None-Match
eIf-Modified-Since
. In questo caso, le origini configurate correttamente dovrebbero restituire una risposta HTTP 304 (Non modificato), senza i byte del corpo, se la cache contiene la copia "più recente" di quella risposta. - Le risposte che impostano una direttiva cache
max-age
os-maxage
o che utilizzano una sostituzione TTL per specificare un valore TTL elevato (ad esempio 30 giorni) potrebbero non essere memorizzate nella cache per l'intero TTL. Non è garantito che un oggetto venga memorizzato nella cache per l'intera durata, soprattutto se viene acceduto di rado.
Se noti un tasso elevato di espulsioni, devi assicurarti di aver configurato le chiavi della cache in modo da escludere i parametri che non identificano in modo univoco una risposta.
Altre considerazioni
Le seguenti considerazioni potrebbero essere valide anche per la memorizzazione nella cache.
Intestazioni Vary
L'intestazione Vary
indica che la risposta varia in base alle intestazioni di richiesta del client. Se nella risposta è presente un'intestazione Vary
, Media CDN non la memorizza nella cache, a meno che l'intestazione non specifichi una delle intestazioni configurate come impostazione della chiave della cache o uno dei seguenti valori:
- Accept: utilizzato per indicare i tipi di media accettati dal client
- Accept-Encoding:utilizzato per indicare i tipi di compressione accettati dal client
- Available-Dictionary: utilizzato per fornire l'hash di un dizionario disponibile per la compressione
- Origin/X-Origin: in genere utilizzato per la condivisione delle risorse tra origini (CORS)
- X-Goog-Allowed-Resources: supporta le limitazioni dell'organizzazione Google Cloud
- Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site: utilizzato per recuperare le intestazioni della richiesta di metadati
Media CDN memorizza nella cache le risposte con un'intestazione Vary
utilizzando il valore dell'intestazione come parte della chiave della cache. Se l'intestazione Vary
nella risposta ha più valori, questi vengono ordinati in ordine alfabetico per garantire che la chiave della cache sia deterministica.
Media CDN memorizza nella cache fino a 100 varianti per una determinata chiave della cache ed elimina in modo casuale le varianti dalla cache oltre questo limite. Se annulli esplicitamente la cache per un determinato URL o tag cache, tutte le varianti vengono annullate.
Ignorare la cache
Puoi configurare la modalità cache BYPASS_CACHE
in un percorso per aggirare intenzionalmente la cache per le richieste corrispondenti. Questa operazione può essere utile se devi bypassare la cache per una piccola parte di traffico non critico o eseguire il debug della connettività dell'origine.
Per i casi in cui devi fornire risposte dinamiche, come i backend dell'API, consigliamo di configurare un bilanciatore del carico delle applicazioni esterno.
In genere, ti consigliamo di limitare l'utilizzo di questa opzione agli scenari di debug per evitare il caricamento involontario dell'origine. Il traffico in uscita quando viene aggirata la cache viene calcolato in base alle tariffe per il traffico in uscita da internet.
Annullamento convalida cache
Consulta la sezione sull'annullamento della convalida della cache.
Richieste con intervallo di byte
Media CDN supporta le richieste di intervallo HTTP con una sola parte come definito nel protocollo RFC 7233.
Inoltre, Media CDN utilizza anche le richieste di intervallo per recuperare risposte più grandi dall'origine. In questo modo, Media CDN può memorizzare i chunk singolarmente e non è necessario recuperare l'intero oggetto contemporaneamente per memorizzarlo nella cache.
- Gli oggetti di dimensioni maggiori di 1 MiB vengono recuperati come richieste di intervallo di byte ("chunk") di massimo 2 MiB ciascuno.
- È possibile recuperare risposte fino a 1 MiB senza il supporto per gli intervalli di byte all'origine.
- Le risposte più grandi non vengono pubblicate se gli intervalli di byte non sono supportati nell'origine.
Il supporto dell'origine per le richieste di intervallo di byte è determinato da quanto segue:
- Un codice di stato HTTP 200 (OK) o 206 (contenuto parziale).
- Un'intestazione della risposta
Content-Length
oContent-Range
valida. - Un convalidatore delle risposte (
ETag
oLast-Modified
).
Le singole richieste di riempimento dell'origine per ogni "chunk" (intervallo di byte) vengono registrate come voci di log distinte e associate alla richiesta del client principale. Puoi agrupare queste richieste abbinandole a quelle su jsonPayload.cacheKeyFingerprint
.
Per ulteriori dettagli su cosa viene registrato, consulta la documentazione di Cloud Logging.
Richieste di intervalli aperti
Media CDN supporta le richieste Range
"aperte" (ad esempio una richiesta con Range: bytes=0-
) che mantengono aperta una richiesta all'origine fino a quando la risposta non viene chiusa dall'origine (ad esempio, l'origine scrive tutti i byte sul cavo) o scade il tempo di attesa.
Gli intervalli di byte aperti vengono in genere utilizzati dai client che richiedono i segmenti HLS a bassa latenza di Apple: quando ogni chunk CMAF viene scritto sulla rete, la CDN può memorizzare nella cache e caricare il chunk sui client.
In altri casi, ad esempio quando l'interoperabilità con DASH non è richiesta, la playlist media indica al player quali byte rappresentano ogni chunk:
#EXTINF:4.08, fs270.mp4 #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=20000@0 #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=23000@20000 #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=18000@43000 #EXT-X-PRELOAD-HINT:TYPE=PART,URI="fs271.mp4",BYTERANGE-START=61000
Puoi configurare il tempo di attesa di Media CDN tra le letture utilizzando il valore di configurazione EdgeCacheOrigin.timeouts.readTimeout
. In genere, questo valore deve essere configurato su un multiplo (ad es. 2 volte) della durata target.
Passaggi successivi
- Esamina il routing avanzato.
- Scopri come collegarti a origini diverse.
- Configura i certificati TLS (SSL) per il tuo servizio.
- Configura le richieste firmate per autenticare l'accesso ai contenuti.