Configura il comportamento della memorizzazione nella cache

Media CDN pubblica i contenuti il più vicino possibile agli utenti utilizzando L'infrastruttura globale di memorizzazione in una cache perimetrale di Google per memorizzare i contenuti nella cache e ridurre il carico dell'infrastruttura di origine.

Puoi controllare il modo in cui i contenuti vengono memorizzati nella cache per ogni percorso. Questo consente di ottimizzare il comportamento del cliente in base al tipo di contenuti, agli attributi della richiesta del client e requisiti di aggiornamento.

Memorizzabilità nella cache

Le seguenti sezioni descrivono quali risposte Media CDN memorizza nella cache e come migliorare l'offload della cache.

Comportamento predefinito per la memorizzazione nella cache

Per impostazione predefinita, a ogni cache perimetrale si applicano le seguenti impostazioni relative alla cache servizio:

  • Modalità cache predefinita di CACHE_ALL_STATIC:

    • Rispetta le istruzioni di cache dell'origine, come Cache-Control o Expires, fino a un TTL massimo configurabile.
    • Memorizza automaticamente nella cache tipi di contenuti multimediali statici con un TTL predefinito di 3600 s, se non sono presenti direttive di cache dell'origine.
    • Memorizza nella cache i codici di stato HTTP 200 e 206 (la memorizzazione nella cache negativa non è abilitata).

  • Non memorizza nella cache le risposte con controllo della cache no-store o private o che non sono altrimenti memorizzabili nella cache.

Risposte che non sono contenuti statici o prive di direttive di memorizzazione nella cache valide. non vengono memorizzate nella cache a meno che non sia configurata in modo esplicito. Per informazioni su come eseguire l'override il comportamento predefinito, consulta la documentazione sulle modalità cache .

Il comportamento predefinito è equivalente al seguente cdnPolicy. Percorsi senza un elemento cdnPolicy esplicito configurato si comporta come se avesse quanto segue 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ò archiviare. e recuperarli rapidamente, consentendo tempi di caricamento più rapidi. Non tutte le richieste HTTP le risposte possono essere memorizzate nella cache.

Puoi configurare le modalità cache per ogni route per eseguire l'override di questo (ad esempio, utilizzo della modalità cache CACHE_ALL_STATIC per memorizzare nella cache tipi di media) anche se l'origine non imposta un istruzione di controllo cache nella risposta.

Richieste e risposte che soddisfano i criteri definiti in Le risposte non memorizzabili nella cache hanno la precedenza sulla memorizzabilità nella cache.

La tabella seguente descrive i requisiti per memorizzare nella cache particolari HTTP diverse. Sia le risposte GET che HEAD devono rispettare questi requisiti.

Attributo HTTP Requisiti
Codice di stato Il codice di stato della risposta deve essere uno dei seguenti: 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, vedi Istruzioni di controllo della cache.
Intestazioni delle risposte

Contiene una memorizzazione nella cache HTTP valida come Cache-Control: max-age=3600, public.

Dispone di una modalità cache che memorizza tali contenuti o presenta Intestazione Expires con una data futura.
Dimensioni della risposta Fino a 100 GiB.

L'intestazione Age HTTP è impostata in base a quando Media CDN ha memorizzato per la prima volta la risposta e in genere rappresenta i secondi da quando l'oggetto è stato memorizzato nella cache a posizione di protezione dell'origine. Se le tue genera un'intestazione della risposta "Age", usa la modalità cache FORCE_CACHE_ALL per impediscono le riconvalide quando l'età supera il TTL della cache.

Per ulteriori informazioni su come Media CDN interpreta la memorizzazione nella cache HTTP vedi Istruzioni di controllo della cache.

Requisiti dell'origine

Consentire a Media CDN di memorizzare nella cache risposte dell'origine maggiori di 1 MiB, un'origine deve includere quanto segue nelle intestazioni della risposta per richieste sia HEAD che GET, se non diversamente specificato:

  • Un'intestazione di risposta HTTP Last-Modified o ETag (uno strumento di convalida).
  • Un'intestazione HTTP Date valida.
  • Un'intestazione Content-Length valida.
  • 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 esplicitamente il campo del protocollo per ogni origine.

Risposte non memorizzabili nella cache

La tabella seguente descrive in dettaglio gli attributi di richiesta e risposta che impediscono una risposta verrà memorizzata nella cache. Risposte memorizzabili nella cache ma corrispondenti "non memorizzabile nella cache" criteri non vengono memorizzati nella cache.

Attributo HTTP Requisito
Codice di stato

Un codice di stato diverso da quelli definiti come memorizzabile nella cache, ad esempio HTTP 401, HTTP 412 o HTTP 505.

Questi codici di stato sono in genere rappresentativi di problemi rivolti al cliente e non lo stato di origine. La memorizzazione nella cache di tali risposte può avvelenamento" scenari in cui un utente ha attivato "non buona" viene memorizzata nella cache per tutti gli utenti.
Intestazioni delle richieste

Per le richieste con una richiesta Authorization le risposte devono includere un public Cache-Control da memorizzare nella cache.

Un'istruzione no-store nella richiesta genera non venga memorizzata nella cache. Per ulteriori informazioni, vedi Istruzioni di controllo della cache.
Intestazioni delle risposte

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

Tra CACHE_ALL_STATIC o Modalità USE_ORIGIN_HEADERS, ha un no-store o private istruzione di controllo della cache.
Dimensioni della 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, solo le risposte che sono considerati contenuti o risposte statici con istruzioni cache valide nelle intestazioni delle risposte. vengono memorizzate nella cache. Le altre risposte vengono inviate tramite proxy così come sono.
  • La modalità cache FORCE_CACHE_ALL memorizza tutte le risposte incondizionatamente nella cache, soggetti ai requisiti di non memorizzabilità della cache indicati in precedenza.
  • La modalità cache USE_ORIGIN_HEADERS richiede l'impostazione delle risposte direttive 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 loro istruzioni di controllo della cache o altre intestazioni vengono modificate e inviate tramite proxy così come sono.
  • Le intestazioni Cache-Control e Expires delle risposte possono essere compresse in un singolo campo Cache-Control. Ad esempio, una risposta con Cache-Control: public e Cache-Control: max-age=100 su righe separate verrebbe compresso 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 direttive cache di origine, memorizza nella cache tipi di contenuti multimediali statici e memorizza nella cache tutte le risposte dall'origine, indipendentemente dalle direttive impostate.

Le modalità cache sono configurate a livello di route e, combinate con gli override TTL, di configurare il comportamento della cache in base a host, percorso, (qualsiasi parametro di richiesta associabile).

  • Per impostazione predefinita, Media CDN utilizza la modalità cache CACHE_ALL_STATIC, che memorizza automaticamente nella cache i tipi di media statici comuni per un'ora (3600 secondi), dando la priorità a eventuali istruzioni di cache specificate dall'origine per risposte memorizzabili nella cache.
  • Puoi aumentare o diminuire il TTL della cache applicato alle risposte senza un TTL esplicito impostato (un'istruzione max-age o s-maxage) impostando il valore cdnPolicy.defaultTtl su una route.
  • Per evitare la memorizzazione nella cache di risposte riuscite per un periodo di tempo più lungo del previsto, i codici di stato non 2xx (operazione non riuscita) non vengono memorizzati nella cache in base al loro Content-Type (tipo MIME) e non hanno il TTL predefinito applicati.

Le modalità cache disponibili, impostate su cdnPolicy.cacheMode di ogni vengono visualizzate nella tabella seguente.

Modalità cache Comportamento
USE_ORIGIN_HEADERS Richiede risposte dell'origine per impostare valide direttive di memorizzazione nella cache e una memorizzazione nella cache valida headers. Per un elenco completo dei requisiti, vedi Risposte memorizzabili nella cache.
CACHE_ALL_STATIC

Memorizza automaticamente nella cache le risposte riuscite con contenuti statici, a meno che non abbia un no-store o private . Viene assegnata la priorità alle direttive di memorizzazione nella cache valide dall’origine.

I contenuti statici includono video, audio, immagini e asset web comuni definito dal tipo MIME nella risposta Content-Type intestazione.
FORCE_CACHE_ALL

Memorizza nella cache incondizionatamente le risposte riuscite, eseguendo l'override di qualsiasi cache direttive impostate dall'origine.

Accertati di non pubblicare contenuti privati per utente (ad esempio HTML dinamico) o risposte API) con questa modalità configurata.
BYPASS_CACHE

Qualsiasi richiesta corrispondente a una route con questa modalità cache configurata viene ignorata cache, anche se è presente un oggetto memorizzato nella cache che corrisponde alla chiave cache.

Ti consigliamo di utilizzarla solo per il debug, in quanto Media CDN è progettata come infrastruttura di cache su scala globale e non per uso generico proxy.

Tipi MIME per i contenuti statici

La modalità cache CACHE_ALL_STATIC consente a Media CDN di memorizzare nella cache automaticamente contenuti statici comuni, come video, audio, immagini asset web comuni basati sul tipo MIME restituito nell'HTTP Content-Type l'intestazione della risposta. Tuttavia, indipendentemente dal tipo di media, Media CDN dà la priorità a qualsiasi intestazione Cache-Control o Expires esplicita nell'origine risposta.

Nella tabella seguente sono elencati i tipi MIME che possono essere memorizzati automaticamente nella cache con la modalità cache CACHE_ALL_STATIC.

Le risposte non vengono memorizzate automaticamente nella cache se non hanno un Content-Type un'intestazione di risposta con un valore che corrisponde ai seguenti valori. Devi assicurarti che la risposta imposti un'istruzione cache valida, oppure devi utilizzare la modalità cache FORCE_CACHE_ALL per memorizzare nella cache in modo incondizionato diverse.

Categoria Tipi MIME
Asset web text/css text/ecmascript text/javascript application/javascript
Caratteri Qualsiasi tipo di contenuto corrispondente a font/*
Immagini Qualsiasi tipo di contenuto corrispondente a image/*
Video Qualsiasi tipo di contenuto corrispondente a video/*
Audio Qualsiasi tipo di contenuto corrispondente a audio/*
Tipi di documenti formattati application/pdf and application/postscript

Tieni presente quanto segue:

  • Il software del server web della tua origine deve impostare Content-Type per ciascuna risposta. Molti server web impostano automaticamente Content-Type, tra cui NGINX, Varnish e Apache.
  • Cloud Storage imposta l'intestazione Content-Type automaticamente al caricamento quando utilizzi la console Google Cloud o lo strumento gsutil per caricare i contenuti.
  • Se una risposta può essere memorizzata nella cache in base al tipo MIME, ma presenta un Istruzione di risposta Cache-Control di private o no-store o Set-Cookie, non viene memorizzata nella cache.

Configura i TTL della cache

Gli override della durata (TTL) consentono di impostare valori TTL predefiniti per i contenuti memorizzati nella cache ed eseguire l'override dei valori TTL impostati nel controllo cache max-age e s-maxage (o Expiresintestazioni) impostate dalle tue origini.

I TTL, impostati tramite override o utilizzando un'istruzione cache, vengono ottimista. I contenuti a cui si accede raramente o impopolari potrebbero essere rimossi dalla pagina della cache prima del raggiungimento del TTL.

La tabella seguente mostra tre impostazioni di 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 max-age o un'intestazione s-maxage.

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

Quando usi FORCE_CACHE_ALL per memorizzare nella cache tutti i contenuti in modo incondizionato viene utilizzato il TTL predefinito per impostare il TTL della cache. Tutti gli altri valori e direttive vengono ignorate.

CACHE_ALL_STATIC

FORCE_CACHE_ALL
Max TTL 1 giorno
(86.400 secondi)		 0 secondi 1 anno
(31.536.000 secondi)		 Per le risposte memorizzabili nella cache, il TTL massimo consentito. Valori superiori a il cui valore è limitato a maxTtl. CACHE_ALL_STATIC
Client TTL Non impostato per impostazione predefinita. 0 secondi 1 giorno
(86.400 secondi)		 Per le risposte memorizzabili nella cache, il TTL massimo consentito nel downstream (rivolto al client) se deve essere diverso da un altro TTL e i relativi valori.

CACHE_ALL_STATIC

FORCE_CACHE_ALL

L'impostazione di qualsiasi valore TTL su zero (0 secondi) comporta la riconvalida di ogni richiesta con l'origine prima che venga fornita una risposta e aumenta il carico sull'origine se un valore troppo ampio.

Se la modalità cache è impostata su Use Origin Headers, le impostazioni TTL non possono essere configurata perché Media CDN si basa sull'origine per generare comportamento degli utenti.

Note:

  • Il valore del TTL massimo deve essere sempre maggiore (o uguale) al valore di predefinito.
  • Il valore per il TTL client deve essere sempre inferiore o uguale al valore del TTL massimo.
  • Quando Media CDN esegue l'override di un valore TTL di origine, il parametro Cache-Control al client riflette anche questo valore.
  • Se l'origine imposta un'intestazione Expires e Media CDN sostituisce il TTL effettivo (in base al timestamp), l'intestazione Expires viene sostituita con un'intestazione Cache-Control nella risposta downstream al di alto profilo.

Memorizzazione nella cache negativa

La memorizzazione nella cache negativa definisce il modo in cui i codici di stato HTTP non riusciti (diversi da 2xx) vengono memorizzate nella cache da Media CDN.

In questo modo puoi memorizzare nella cache risposte di errore come i reindirizzamenti (HTTP 301 e 308) risposte non trovate (HTTP 404) più vicine agli utenti e riducono vengono caricate in modo più ampio se è improbabile che la risposta cambi e può essere memorizzata nella cache.

La memorizzazione nella cache negativa è disattivata per impostazione predefinita. La tabella seguente mostra il valore predefinito per ogni codice di stato quando la memorizzazione nella cache negativa è abilitata negativeCachingPolicy non è in uso.

Codici di stato Frase del motivo 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 Non disponibile per motivi legali 120 secondi
HTTP 501 Non implementato 60 secondi

L'insieme predefinito di codici di memorizzazione nella cache negativa corrisponde alla descritti in HTTP RFC 9110 con le seguenti eccezioni:

  • Il codice HTTP 414 (URI troppo lungo) non è supportato per la memorizzazione nella cache, per evitare la memorizzazione nella cache avvelenamento.
  • Il codice HTTP 451 (Non disponibile per motivi legali) è supportato per la memorizzazione nella cache, come descritti in HTTP RFC 7725.

Se devi configurare i TTL personalizzati per ogni codice di stato ed eseguire l'override del valore predefinito puoi configurare un cdnPolicy.negativeCachingPolicy. Questo consente di Imposta il TTL per uno 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 breve TTL di 5 secondi per le risposte HTTP 404 (non trovato), e un TTL di 10 secondi per le risposte HTTP 405 (Method Not Allowed), utilizza 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, consigliamo di non abilitare la memorizzazione nella cache per codice di stato 400 (Richiesta non valida) o 403 (Accesso negato). Assicurati che il server di origine restituisce uno dei due codici dopo aver esaminato solo i componenti della richiesta incluse nella chiave cache. L'avvelenamento della cache può verificarsi, ad esempio, quando il server di origine risponde con una risposta di errore 403 in assenza di una risposta Intestazione Authorization. In questo caso, la memorizzazione nella cache della risposta di errore 403 Media CDN fornisce la risposta di errore 403 a tutte le successive richieste fino alla scadenza del TTL, anche se presentano un Intestazione Authorization.

Per disattivare la memorizzazione nella cache negativa:

  • Per disattivare il comportamento predefinito di memorizzazione nella cache negativa, imposta cdnPolicy.negativeCaching: false su un percorso. Tieni presente che le risposte dell'origine con istruzioni cache valide e stato memorizzabile nella cache i codici rimangono memorizzati nella cache.
  • Per impedire la memorizzazione nella cache negativa per uno specifico codice di stato, rispettando comunque lo stesso direttive di cache dell'origine, ometti il codice di stato (cdnPolicy.negativeCachingPolicy[].code) in negativeCachingPolicy definizione di Kubernetes.
  • Ignorare esplicitamente le istruzioni della cache dell'origine per uno stato specifico , imposta cdnPolicy.negativeCachingPolicy[].ttl su 0 (zero) codice di stato.

Note:

  • Quando negativeCaching è abilitato su una route e una risposta definisce istruzioni cache valide, le istruzioni cache nel risposta ha la precedenza.
  • Se configuri un valore negativeCachingPolicy esplicito ed è presente un TTL definito per il codice di stato specificato, il TTL definito nel criterio è sempre in uso.
  • Il valore massimo per un TTL impostato da negativeCachingPolicy è 1800 secondi (30 minuti), ma vengono rispettate le direttive della cache di origine con un TTL più alto.
  • Se la modalità cache è configurata come FORCE_CACHE_ALL, origine vengono ignorate in tutti i casi.

Istruzioni di controllo della cache

Comportamento di Media CDN in relazione Cache-Control istruzioni definita qui.

Se la direttiva non è applicabile a una richiesta o risposta, come only-if-cached (un'istruzione solo client), poi "N/A" in quella colonna.

Direttiva Richiesta Risposta
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 richiede una convalida con l'origine prima di poter essere pubblicato.

Questa opzione può essere ignorata in base alle singole route Modalità cache FORCE_CACHE_ALL.
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.

Questa opzione può essere ignorata in base alle singole route Modalità cache FORCE_CACHE_ALL.
public N/D

Una risposta con l'istruzione public viene memorizzata nella cache se la risposta è considerata memorizzabile nella cache nel suo complesso e la risposta ha un'istruzione max-age o s-maxage come beh.

Se utilizzi la cache di CACHE_ALL_STATIC oppure FORCE_CACHE_ALL modalità, non è obbligatorio.
private N/D

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

Questa opzione può essere ignorata in base alle singole route Modalità cache FORCE_CACHE_ALL.

Utilizza no-store per impedire tutte le risposte nella cache.
max-age=SECONDS L'istruzione di 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 a il valore SECONDS definito.
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 dal server.

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

L'istruzione della richiesta max-stale viene ignorata.

Viene restituita una risposta memorizzata nella cache come se questa intestazione non fosse inclusa nel la richiesta.

 N/D
stale-while-revalidate=SECONDS N/D Nessun effetto. Questo viene trasmesso al client nella risposta.
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. Nessun effetto. Questo viene trasmesso al client nella risposta.
must-revalidate N/D

Una risposta con must-revalidate viene riconvalidata con server di origine dopo che è scaduto.
proxy-revalidate N/D

Una risposta con proxy-revalidate viene riconvalidata con l'origine server web dopo la scadenza.
immutable N/D Nessun effetto. Questo viene trasmesso al client nella risposta.
no-transform N/D Media CDN non applica alcuna trasformazione.
only-if-cached L'istruzione della richiesta only-if-cached viene ignorata. Una copia cache come se questa intestazione non fosse inclusa nella richiesta. N/D

Ove possibile, Media CDN è compatibile con RFC (HTTP RFC 7234), ma favorisce ottimizzando l'offload della cache e riducendo al minimo l'impatto che i client possono avere 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 definita in RFC 7231
  • Un valore data nel passato, una data non valida o un valore 0 indica che i contenuti sono già scaduti e devono essere riconvalidati.
  • Media CDN ignora l'intestazione Expires se un Cache-Control è presente nella risposta.

L'intestazione HTTP/1.0 Pragma, se presente in una risposta, viene ignorata e passata così come sono al client.

Chiavi cache

Puoi ridurre il numero di volte in cui Media CDN deve contattare il tuo prendendo in considerazione ciò che identifica in modo univoco una richiesta e rimuovendo e componenti che potrebbero cambiare spesso da una richiesta all'altra. L'insieme di richieste sono spesso definiti "chiave cache".

Le seguenti sezioni descrivono come configurare le chiavi cache.

Componenti chiave di cache

Una chiave cache è l'insieme di parametri della richiesta (ad esempio host, percorso e query ) a cui fa riferimento un oggetto memorizzato nella cache.

Per impostazione predefinita, le chiavi cache per i servizi di cache perimetrale includono l'host della richiesta, il percorso e parametri di ricerca della richiesta e l'ambito è una specifica EdgeCacheService.

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 le diverse risposte alle richieste http: e https:, imposta cacheKeyPolicy.includeProtocol su true nella proprietà associata route.
Organizzatore Sì

Host diversi non fanno riferimento agli stessi oggetti memorizzati nella cache.

Se hai più nomi host diretti allo stesso EdgeCacheService e stanno pubblicando gli stessi contenuti, impostano cdnPolicy.excludeHost su true.
Percorso Sì Sempre incluso nella chiave cache e non può essere rimosso. Il percorso è minima di un oggetto nella cache.
Parametri di query Sì

Se parametri di ricerca non distinguono tra le diverse risposte, imposta cacheKeyPolicy.excludeQueryString su true.

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

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

Specifica più intestazioni che si combinano per avere un ampio intervallo di (ad esempio, i valori di intestazione combinati identificano un singolo utente) riduce drasticamente la percentuale di successo della cache e può comportare un tasso di rimozione più elevato e una riduzione delle prestazioni.
Cookie No

Imposta cacheKeyPolicy.includedCookieNames con i nomi di cookie da includere nella chiave cache.

Specifica più cookie che si combinano per avere un'ampia gamma (ad esempio, i valori combinati dei cookie identificano un singolo utente) riduce drasticamente la percentuale di successo della cache e può comportare un tasso di rimozione più elevato e una riduzione delle prestazioni.

Tieni presente quanto segue:

  • Le chiavi cache non sono collegate a un'origine configurata, puoi eseguire l'aggiornamento una configurazione dell'origine (o sostituire del tutto l'origine) senza rischio di "flushing" cache (ad esempio, durante la migrazione dello spazio di archiviazione dell'origine tra provider).
  • Le chiavi cache sono vincolate a un EdgeCacheService. EdgeCacheServices diversi ha diversi spazi dei nomi della cache, evitando così di memorizzare accidentalmente nella cache di oggetti tra ambienti di produzione, di gestione temporanea e altri ambienti di test, anche se l'host, il percorso o altri componenti chiave cache corrispondono. L'eliminazione di un EdgeCacheService invalida in modo efficace tutti gli oggetti memorizzati nella cache per quel servizio.
  • Le chiavi cache non sono limitate all'ambito di una singola route. Più itinerari possono fare riferimento allo stesso di cache, soprattutto se queste route corrispondono a componenti che non sono incluse nella chiave cache, come le intestazioni delle richieste o i parametri esclusi. Questo può essere utile se vuoi che più route condividano la stessa cache, che restituiscono intestazioni delle risposte o configurazioni CORS diverse.
  • Le chiavi cache non includono la configurazione di riscrittura dell'URL, ad esempio una chiave cache è basata sulla richiesta rivolta agli utenti e non sull'ultima "riscritta" richiesta.
  • Quando le richieste con firma sono configurate su una route, gli attributi con firma vengono non incluso nella chiave cache. La richiesta viene trattata come se fosse parametri di ricerca o componente del percorso, che iniziano con edge-cache-token e che termina al separatore di percorso successivo ("/") non fanno 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 in includedQueryParameters o excludedQueryParameters configurazione delle chiavi di cache su una determinata route.

Ad esempio, per includere i parametri di ricerca contentID e country e ignora 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 e escludere quelli che non lo fanno. Ad esempio, escludi parametri di ricerca di analisi, ID sessione di riproduzione o altri parametri univoci soltanto per il client. L'inclusione di più parametri di ricerca del necessario può ridurre le percentuali di successo della cache.

In alternativa, invece di specificare quali parametri includere nella cache, puoi scegliere i parametri da escludere dalla chiave cache. Ad esempio: per escludere dalla cache informazioni di timestamp e ID riproduzione specifici del client configura quanto segue:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 86400s
  cacheKeyPolicy:
    excludedQueryParameters: ["playback-id", "timestamp"]

Per un determinato percorso, puoi specificare uno tra 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 cache per una route. Per farlo Impostando excludeQueryString su true, come segue:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 3600s
  cacheKeyPolicy:
    excludeQueryString: true

Se le Richieste firmate sono abilitate su una route, parametri di ricerca utilizzati per la firma non sono inclusi nella stringa di query e sono ignorato se incluso. Inclusione dei parametri firmati nella chiave cache rende unica ogni richiesta dell'utente e richiede che ogni richiesta fornito dall'origine.

Ordinamento dei parametri di query

I parametri di query (stringhe di query) vengono ordinati per impostazione predefinita per migliorare il successo della cache perché i clienti potrebbero riordinare o richiedere in altro modo gli stessi 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 della derivazione della chiave cache. In questo modo entrambe le richieste possono essere mappate dell'oggetto memorizzato nella cache, evitando richieste (e risposte) non necessarie all'oggetto origine dati.

Se sono presenti più istanze di una chiave parametro di query, ciascuna con caratteristiche , i parametri vengono ordinati in base al valore completo (ad esempio, a=hello è ordinati 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 lettere minuscole dal Media CDN.

Le seguenti intestazioni non possono essere incluse nella chiave 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 speciale dell'intestazione :method.

Includi cookie

I nomi dei cookie sono sensibili alle maiuscole.

Cookie che iniziano con edge-cache- e qualsiasi variante in maiuscolo o minuscolo non è possibile utilizzare lettere nella chiave cache.

Riconvalida, eliminazione e scadenza

Le reti CDN (Content Delivery Network), tra cui Media CDN, operano memorizzando nella cache i contenuti più popolari il più vicino possibile agli utenti.

l'ampio spazio di archiviazione di Media CDN, nonché protetto dall'origine, limita la necessità di rimuovere anche elementi contenuti. I contenuti a cui si accede un numero ridotto di volte al giorno potrebbero e alla fine essere rimossi.

  • Le risposte memorizzate nella cache che raggiungono il TTL configurato potrebbero non essere immediatamente rimosso. Per i contenuti popolari, Media CDN riconvalida che la risposta memorizzata nella cache è la versione più recente inviando un HEAD all'origine per confermare che le intestazioni siano non modificato. In alcuni casi, Media CDN anziché invia una richiesta all'origine con una o entrambe le seguenti intestazioni della richiesta: If-None-Match e If-Modified-Since. In questo caso, le origini configurate correttamente devono restituire un errore HTTP 304 (non modificato) risposta, senza i byte del corpo, se la cache ha il "più recente" copia di la risposta.
  • Risposte che impostano una cache max-age o s-maxage o che usano un TTL override per specificare un valore TTL elevato (ad esempio, 30 giorni) potrebbero non essere archiviati nella cache per l'intero TTL. Non vi è alcuna garanzia che un oggetto sia archiviato nella cache per l'intera durata, soprattutto se si accede raramente.

Se registri un tasso di rimozione elevato, assicurati di avere configurato le tue chiavi cache in modo da escludere i parametri che non identificano in modo univoco un risposta.

Altre considerazioni

Le seguenti considerazioni potrebbero essere valide anche per la memorizzazione nella cache.

Vary intestazioni

L'intestazione Vary indica che la risposta varia in base alla risposta del client intestazioni delle richieste. Se nella risposta è presente un'intestazione Vary, Media CDN non lo memorizza nella cache, a meno che l'intestazione non specifichi una delle intestazioni configurate come impostazione chiave cache o uno dei seguenti valori:

  • Accetta: utilizzato per indicare i tipi di media accettati dal client.
  • Accetta-Codifica: utilizzato per indicare i tipi di compressione del client. accetta
  • Dizionario disponibile: utilizzato per fornire l'hash di un dizionario per compressione
  • Origin/X-Origin: di solito utilizzato per la condivisione delle risorse tra origini
  • X-Goog-Allowed-Resources::supporta l'organizzazione Google Cloud limitazione
  • Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site::utilizzato per recuperare la richiesta di metadati intestazioni

Media CDN memorizza nella cache le risposte con un'intestazione Vary nella risposta in base a utilizzando il valore dell'intestazione come parte della chiave cache. Se l'intestazione Vary la risposta ha più valori, questi sono ordinati lessicograficamente per garantire che la chiave cache sia deterministica.

Media CDN memorizza nella cache fino a 100 varianti per una determinata chiave di cache e rimuove le varianti dalla cache oltre questo limite. Se in modo esplicito invalidare la cache per un determinato URL oppure , tutte le varianti sono state invalidate.

Ignora la cache

Puoi configurare la modalità cache BYPASS_CACHE su una route per intenzionalmente di ignorare la cache per le richieste corrispondenti. Questo può essere utile se devi bypassare cache per una piccola porzione di traffico non critico oppure origine di debug e la connettività privata.

Nei casi in cui devi fornire risposte dinamiche, come i backend delle API, consigliamo di configurare un bilanciatore del carico delle applicazioni esterno.

In genere è consigliabile limitare l'utilizzo di questa funzionalità agli scenari di debug, per evitare il caricamento involontario dell'origine. Il traffico in uscita quando si bypassa la cache viene al prezzo delle tariffe del traffico in uscita da internet.

Annullamento convalida cache

Vedi invalidazione della cache.

Richieste di intervalli di byte

Media CDN supporta richieste di intervallo HTTP a parte singola come definito in RFC 7233.

Inoltre, Media CDN utilizza anche richieste di intervallo Recuperare risposte più grandi dall'origine. In questo modo Media CDN di singoli blocchi della cache e non è necessario il recupero dell'intero oggetto per poter essere memorizzate nella cache.

  • Gli oggetti di dimensioni superiori a 1 MiB vengono recuperati come richieste di intervalli di byte ("blocchi") di massimo 2 MiB ciascuno.
  • Le risposte fino a 1 MiB possono essere recuperate senza supporto per i byte all'origine.
  • Le risposte di dimensioni maggiori non vengono pubblicate se gli intervalli di byte non sono supportati su l'origine.

Il supporto dell'origine per le richieste di intervalli di byte è determinato da quanto segue:

  • Un codice di stato HTTP 200 (OK) o 206 (Contenuto parziale).
  • Un'intestazione di risposta Content-Length o Content-Range valida.
  • Uno strumento di convalida delle risposte (ETag o Last-Modified).

Richieste di riempimento dell'origine individuali per ogni "chunk" (intervallo di byte) vengono registrati come voci di log discrete e associate alla richiesta del client padre. Puoi raggruppa queste richieste abbinando le richieste jsonPayload.cacheKeyFingerprint.

Per ulteriori dettagli sui dati registrati, vedi documentazione di Cloud Logging.

Richieste di intervallo aperto

Media CDN supporta i dati "aperti" Richieste Range (ad esempio, con Range: bytes=0-) che mantengono una richiesta aperta rispetto all'origine finché la risposta non viene chiusa dall'origine (ad esempio, l'origine scrive tutti byte al cavo) o si verifica il timeout.

Gli intervalli di byte aperti in genere vengono utilizzati dai client che richiedono HLS a bassa latenza segmenti: man mano che ogni blocco CMAF viene scritto sul cavo, la CDN può memorizzare nella cache per consegnare quel blocco ai clienti.

In altri casi, ad esempio quando l'interoperabilità con DASH non è richiesta, playlist multimediale indica al player quali byte rappresentano ciascun blocco:

  #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 una lettura e l'altra utilizzando il valore di configurazione EdgeCacheOrigin.timeouts.readTimeout. Questa operazione dovrebbe in genere deve essere configurata su un multiplo (ad esempio 2x) della durata target.

Passaggi successivi