Configurare il comportamento della memorizzazione nella cache

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 o Expires, 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).

  • Non memorizza nella cache le risposte con direttive cache-control no-store o private 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 possono essere memorizzate 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 cacheabili 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 Cache-Control: max-age=3600, public.

Ha una modalità cache che memorizza nella cache i contenuti o ha un'intestazione Expires con una data futura.
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 o ETag (un convalidatore).
  • Un'intestazione HTTP Date valida.
  • Un'intestazione Content-Length valida.
  • L'intestazione della risposta Content-Range in risposta a una richiesta Range GET. L'intestazione Content-Range deve avere un valore valido nel formato bytes x-y/z (dove z è 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 Authorization, le risposte devono includere un'istruzione public Cache-Control per essere memorizzate nella cache.

Una direttiva no-store nella richiesta impedisce la memorizzazione nella cache della risposta. Per ulteriori informazioni, consulta Direttive Cache-Control.
Intestazioni della risposta

Contiene un'intestazione Set-Cookie.

Ha un'intestazione Vary diversa da Accept, Accept-Encoding, Origin, X-Origin, X-Goog-Allowed-Resources, Sec-Fetch-Dest, Sec-Fetch-Mode o Sec-Fetch-Site.

In modalità CACHE_ALL_STATIC o USE_ORIGIN_HEADERS, ha una direttiva di controllo della cache no-store o private.
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à di memorizzazione nella 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 sottoposte a proxy così come sono.
  • Le intestazioni Cache-Control e Expires delle risposte possono essere compresse in un unico campo Cache-Control. Ad esempio, una risposta con Cache-Control: public e Cache-Control: max-age=100 su righe separate verrebbe compressa come Cache-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 o s-maxage) impostando il campo cdnPolicy.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 no-store o private. Le direttive di memorizzazione nella cache valide dell'origine hanno la priorità.

I contenuti statici includono video, audio, immagini e asset web comuni come definito dal tipo MIME nell'intestazione della rispostaContent-Type.
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 CACHE_ALL_STATIC.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 alla 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 max-age o s-maxage.

Se l'origine specifica un'intestazione s-maxage, viene utilizzata al posto del valore TTL predefinito.

Quando utilizzi FORCE_CACHE_ALL per memorizzare incondizionatamente tutte le risposte nella cache, viene utilizzato il TTL predefinito per impostare il TTL della cache. Tutti gli altri valori e le direttive vengono ignorati.

CACHE_ALL_STATIC

FORCE_CACHE_ALL
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.

CACHE_ALL_STATIC

FORCE_CACHE_ALL

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'intestazione Expires viene sostituita con un'intestazione Cache-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 il danneggiamento 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 di negativeCachingPolicy.
  • Per ignorare esplicitamente le direttive della cache dell'origine per un codice stato specifico, imposta cdnPolicy.negativeCachingPolicy[].ttl su 0 (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 no-cache viene memorizzata nella cache, ma richiede la convalida con l'origine prima di poter essere pubblicata.

Questo valore può essere ignorato su base per percorso con la FORCE_CACHE_ALL modalità cache.
no-store La risposta a una richiesta con no-store non viene memorizzata nella cache.

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

Questo valore può essere ignorato su base per percorso con la FORCE_CACHE_ALL modalità cache.
public N/D

Una risposta con la direttiva public viene memorizzata nella cache se la risposta è considerata memorizzabile nella cache nel suo complesso e contiene anche una direttiva max-age o s-maxage.

Se utilizzi la modalità cache CACHE_ALL_STATIC o FORCE_CACHE_ALL, non è necessario.
private N/D

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

Questo valore può essere ignorato su base per percorso con la FORCE_CACHE_ALL modalità cache.

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

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

Se sono presenti sia max-age che s-maxage, s-maxage viene utilizzato dal server.

Tieni presente che s-max-age (due trattini) non è valido ai fini della memorizzazione nella cache.
min-fresh=SECONDS L'istruzione di richiesta min-fresh viene ignorata. Viene restituita una risposta memorizzata nella cache come se questa intestazione non fosse inclusa nella richiesta. N/D
max-stale=SECONDS

L'istruzione di richiesta max-stale viene ignorata.

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 must-revalidate viene convalidata nuovamente con il server di origine dopo la scadenza.
proxy-revalidate N/D

Una risposta con proxy-revalidate viene convalidata nuovamente con il server di origine dopo la scadenza.
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 definita 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'intestazione Cache-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 che 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 cacheKeyPolicy.includeProtocol su true per i percorsi associati.
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 cdnPolicy.excludeHost su true.
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 cacheKeyPolicy.excludeQueryString su true.

Se in una chiave cache devono essere inclusi solo alcuni parametri di ricerca, imposta includedQueryParameters o excludedQueryParameters, a seconda dei casi.
Intestazioni No

Imposta cacheKeyPolicy.includedHeaderNames con i nomi delle intestazioni da includere nella chiave cache.

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 cacheKeyPolicy.includedCookieNames con i nomi dei cookie da includere nella chiave cache.

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 e If-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 o s-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 un carico 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 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 o Content-Range valida.
  • Un convalidatore delle risposte (ETag o Last-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