Configurare il comportamento della memorizzazione nella cache

Media CDN distribuisce i contenuti il più vicino possibile agli utenti utilizzando l'infrastruttura di memorizzazione in una cache perimetrale globale di Google per memorizzare nella cache i contenuti 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 della richiesta del client e ai tuoi requisiti di aggiornamento.

Memorizzabile nella cache

Le sezioni seguenti descrivono le risposte memorizzate nella cache di Media CDN e come migliorare l'offload della cache.

Comportamento di memorizzazione nella cache predefinito

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

• Modalità cache predefinita di CACHE_ALL_STATIC:

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

• Non memorizza nella cache le risposte con direttive di controllo della cache no-store o private o che non sono memorizzabili nella cache per altri motivi.

Le risposte che non sono contenuti statici o a cui mancano direttive di memorizzazione nella cache valide non vengono memorizzate nella cache, a meno che la memorizzazione nella cache non sia configurata in modo esplicito. Per scoprire come eseguire l'override del comportamento predefinito, consulta la documentazione sulle modalità di cache .

Il comportamento predefinito equivale al seguente cdnPolicy. Le route 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ò archiviare e recuperare rapidamente, consentendo tempi di caricamento più rapidi. Non tutte le risposte HTTP sono memorizzabili nella cache.

Puoi configurare le modalità di memorizzazione nella cache per ogni route per ignorare questo comportamento (ad esempio, utilizzando la modalità di memorizzazione nella cache CACHE_ALL_STATIC per memorizzare nella cache i tipi di contenuti multimediali 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 hanno la precedenza sulla memorizzabilità nella cache.

La seguente tabella descrive i requisiti per memorizzare nella cache determinate risposte HTTP. Entrambe le risposte GET e HEAD devono rispettare questi requisiti.

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

Per ulteriori informazioni su come Media CDN interpreta le direttive di memorizzazione nella cache HTTP, consulta Direttive di controllo della cache.

Requisiti di origine

Per consentire a Media CDN di memorizzare nella cache le risposte dell'origine di dimensioni superiori a 1 MiB, un'origine deve includere quanto segue nelle intestazioni della risposta per le richieste HEAD e GET, se non diversamente specificato:

• Un'intestazione della risposta HTTP Last-Modified o ETag (un validatore).
• 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 descrive gli attributi di richiesta e risposta che impediscono la memorizzazione nella cache di una risposta. Le risposte memorizzabili nella cache che corrispondono ai criteri "non memorizzabili nella cache" non vengono memorizzate nella cache.

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 delle risposte. Le altre risposte vengono inviate tramite proxy così come sono.
• La modalità cache FORCE_CACHE_ALL memorizza nella cache tutte le risposte incondizionatamente, 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 delle risposte, oltre a essere un codice di stato memorizzabile nella cache.

Note:

• Le risposte non memorizzate nella cache non hanno direttive di controllo della cache o altre intestazioni modificate e vengono sottoposte a proxy così come sono.
• Le risposte possono avere le intestazioni Cache-Control e Expires 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 verranno 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 memorizzazione nella cache vengono configurate a livello di route e, combinate con gli override TTL, consentono di configurare il comportamento della cache in base a host, percorso,parametri di ricercay e intestazioni (qualsiasi parametro di richiesta corrispondente).

• 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 qualsiasi direttiva della cache specificata dall'origine per le risposte memorizzabili nella cache.
• Puoi aumentare o diminuire la durata (TTL) della cache applicata alle risposte senza una durata (TTL) della cache esplicita impostata (una direttiva max-age o s-maxage) impostando il campo cdnPolicy.defaultTtl in una route.
• Per evitare la memorizzazione nella cache delle risposte non riuscite per un periodo di tempo superiore a quello previsto, i codici di stato non 2xx (non riusciti) non vengono memorizzati nella cache in base al loro Content-Type (tipo MIME) e non viene applicato il TTL predefinito.

Le modalità di memorizzazione nella cache disponibili, impostate nel cdnPolicy.cacheMode di ogni percorso, sono mostrate nella tabella seguente.

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 della risposta HTTP Content-Type. Tuttavia, indipendentemente dal tipo di media, Media CDN assegna la priorità a qualsiasi intestazione Cache-Control o Expires nella risposta dell'origine.

La tabella seguente elenca 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'intestazione di risposta Content-Type con un valore corrispondente 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 nella cache le risposte.

Tieni presente quanto segue:

• Il software del server web dell'origine deve impostare Content-Type per ogni risposta. Molti server web impostano automaticamente l'intestazione Content-Type, tra cui NGINX, Varnish e Apache.
• Cloud Storage imposta automaticamente l'intestazione Content-Type al momento del caricamento quando utilizzi la console Google Cloud o 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 riuscite vengono memorizzate nella cache in base ai valori predefiniti di Cloud Storage, a meno che tu non modifiche esplicitamente i metadati di controllo della cache per gli oggetti in Cloud Storage o utilizzi la modalità FORCE_CACHE_ALL per ignorare i 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 media, come HTML (text/html) e JSON (application/json), non vengono memorizzati nella cache per impostazione predefinita. Questi tipi di risposte sono in genere dinamici (per utente) e non sono adatti all'architettura di Media CDN. Ti consigliamo di utilizzare Cloud CDN per pubblicare asset web e memorizzare nella cache le risposte API.

Configura i TTL della cache

Gli override della durata (TTL) ti consentono di impostare valori TTL predefiniti per i contenuti memorizzati nella cache e di eseguire l'override dei valori TTL impostati nelle direttive di controllo della cache max-age e s-maxage (o nelle intestazioni Expires) impostate dalle origini.

I TTL, impostati tramite override o utilizzando una direttiva della cache, sono ottimistici. I contenuti a cui si accede raramente o impopolari potrebbero essere rimossi dalla cache prima del raggiungimento del TTL.

La tabella seguente mostra tre impostazioni TTL.

L'impostazione di un valore TTL pari a zero (0 secondi) comporta la convalida di ogni richiesta con l'origine prima che venga pubblicata una risposta e aumenta il carico sull'origine se l'impostazione è troppo ampia.

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 massimo deve essere sempre maggiore o uguale al valore del TTL predefinito.
• Il valore del 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, l'intestazione Cache-Control al client riflette anche questo valore.
• Se l'origine imposta un'intestazione Expires e Media CDN esegue l'override del 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 la modalità di memorizzazione nella cache dei codici di stato HTTP non riusciti (diversi da 2xx) da parte di Media CDN.

In questo modo puoi memorizzare nella cache le risposte di errore, ad esempio i reindirizzamenti (HTTP 301 e 308) e le risposte non trovate (HTTP 404) più vicine agli utenti, nonché ridurre il carico dell'origine in modo più ampio se è improbabile che la risposta cambi e possa 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 è abilitata e negativeCachingPolicy non viene utilizzato.

Il set predefinito di codici di memorizzazione memorizzazione nella cache negativa corrisponde ai codici di stato memorizzabili nella cache euristica descritti nel protocollo RFC 9110 HTTP, con le seguenti eccezioni:

• Il codice HTTP 414 (URI troppo lungo) non è supportato per la memorizzazione nella cache, per evitare il cache poisoning.
• Il codice HTTP 451 (Unavailable for Legal Reasons) è supportato per la memorizzazione nella cache, come descritto in RFC 7725 HTTP.

Se devi configurare i tuoi TTL per codice di stato e ignorare il 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 il cache poisoning, non consigliamo di attivare la memorizzazione nella cache per i codici di stato 400 (Richiesta errata) o 403 (Accesso negato). Assicurati che il server di origine restituisca uno dei due codici dopo aver esaminato solo i componenti della richiesta inclusi nella chiave della cache. L'avvelenamento della cache può verificarsi, ad esempio, quando il server di origine risponde con un errore 403 in assenza di un'intestazione Authorization corretta. In questo caso, la memorizzazione nella cache della risposta di errore 403 comporta la pubblicazione della risposta di errore 403 da parte di Media CDN 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 di memorizzazione nella cache negativa, imposta cdnPolicy.negativeCaching: false su una route. Tieni presente che le risposte provenienti dall'origine con direttive di memorizzazione nella cache valide e codici di stato memorizzabili nella cache vengono comunque memorizzate nella cache.
• Per impedire la memorizzazione nella cache negativa per un codice di stato specifico, ma rispettare comunque le direttive della cache di origine, ometti il codice di stato (cdnPolicy.negativeCachingPolicy[].code) nella definizione di negativeCachingPolicy.
• Per ignorare esplicitamente le direttive della cache di origine per un codice di stato specifico, imposta cdnPolicy.negativeCachingPolicy[].ttl su 0 (zero) per quel codice di stato.

Note:

• Quando negativeCaching è abilitato su 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 e viene 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 superiore vengono rispettate.
• Se la modalità cache è configurata come FORCE_CACHE_ALL, le direttive di origine vengono ignorate in tutti i casi.

Direttive di controllo cache

Il comportamento di Media CDN rispetto alle direttive Cache-Control è definito qui.

Se la direttiva non è applicabile a una richiesta o a una risposta, ad esempio only-if-cached (una direttiva solo per i client), nella colonna viene indicato "N/A".

Ove possibile, Media CDN è conforme alla RFC (HTTP RFC 7234), ma favorisce l'ottimizzazione per l'offload della cache e la riduzione al minimo dell'impatto che i client possono avere sul tasso di hit e sul carico complessivo dell'origine.

Per le risposte che utilizzano l'intestazione HTTP/1.1 Expires:

• Il valore dell'intestazione Expires deve essere una data HTTP valida come definita nel documento RFC 7231.
• Un valore di data nel passato, una data non valida o un valore di 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 HTTP/1.0 Pragma, se presente in una risposta, viene ignorata e trasmessa al client così com'è.

Chiavi cache

Puoi ridurre il numero di volte in cui Media CDN deve contattare l'origine considerando ciò che identifica in modo univoco una richiesta e rimuovendo i componenti che potrebbero cambiare spesso tra le richieste. L'insieme dei componenti della richiesta viene spesso definito "chiave della cache".

Le sezioni seguenti descrivono come configurare le chiavi della cache.

Componenti chiave di cache

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

Per impostazione predefinita, le chiavi cache per i servizi Edge Cache includono l'host, il percorso e parametri di ricerca della richiesta e sono limitate a un EdgeCacheService specifico.

Tieni presente quanto segue:

• Le chiavi della cache non sono associate a un'origine configurata, il che ti consente di aggiornare una configurazione di origine (o sostituire completamente l'origine) senza il rischio di "svuotare" la cache (ad esempio, durante la migrazione dell'archiviazione di origine tra provider).
• Le chiavi della cache sono vincolate a un EdgeCacheService. I diversi EdgeCacheServices hanno spazi dei nomi della cache diversi, il che impedisce di memorizzare accidentalmente nella cache gli oggetti tra gli ambienti di produzione, gestione temporanea e altri ambienti di test, anche se l'host, il percorso o altri componenti della chiave cache corrispondono. L'eliminazione di un EdgeCacheService invalida effettivamente tutti gli oggetti memorizzati nella cache per quel servizio.
• Le chiavi della cache non sono limitate a una singola route. Più route potrebbero fare riferimento alla stessa chiave della cache, soprattutto se corrispondono a componenti non inclusi nella chiave della cache, come le intestazioni delle richieste o i parametri esclusi. Questo può essere utile se vuoi che più route condividano la stessa cache, ma restituiscano intestazioni di risposta o configurazione CORS diverse.
• Le chiavi della cache non includono la configurazione di riscrittura degli URL. Ad esempio, una chiave della cache si basa sulla richiesta rivolta all'utente e non sulla richiesta "riscritta" finale.
• Quando le richieste firmate sono configurate su una route, gli attributi firmati non sono inclusi nella chiave cache. La richiesta viene trattata come se i parametri di ricerca o il componente del percorso (con firma), a partire da edge-cache-token e fino al separatore di percorso successivo ("/"), non facessero parte dell'URL.

Includere o escludere 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 una determinata route.

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 Analytics, gli ID sessione di riproduzione o altri parametri univoci solo per il client. 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 cache, puoi scegliere quelli da escludere. Ad esempio, per escludere dalla chiave della cache l'ID di riproduzione e le informazioni sul 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 tuttiparametri di ricercay dalla chiave della cache per una route. Per farlo, imposta excludeQueryString su true nel seguente modo:

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

Se le richieste firmate sono attivate su una route, 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 unica ogni richiesta dell'utente e richiede che ogni richiesta venga servita dall'origine.

Ordinamento dei parametri di query

I parametri di query (stringhe di query) vengono ordinati per impostazione predefinita per migliorare le percentuali di successo della cache, perché 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 vengono ordinati come a=hello&b=world&p=paris&z=zulu prima di derivare la chiave cache. In questo modo, entrambe le richieste vengono mappate allo stesso oggetto memorizzato nella cache, evitando una richiesta non necessaria all'origine (e la relativa risposta).

Se sono presenti più istanze di una chiave di parametro query, ognuna con valori distinti, i parametri vengono ordinati in base al loro 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 minuscolo 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-
• accept-encoding
• accept
• authorization
• 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 variazione di lettere maiuscole o minuscole non possono essere utilizzati nella chiave della cache.

Riconvalida, eliminazione e scadenza

Le reti CDN (Content Delivery Network), inclusa 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, limita la necessità di eliminare anche i contenuti impopolari. I contenuti a cui si accede un numero ridotto di volte al giorno potrebbero alla fine essere eliminati.

• Le risposte memorizzate nella cache che raggiungono il TTL configurato potrebbero non essere eliminate immediatamente. Per i contenuti più popolari, Media CDN verifica nuovamente che la risposta memorizzata nella cache sia l'ultima versione inviando una richiesta HEAD all'origine per confermare che le intestazioni non siano cambiate.
• Le risposte che impostano una max-age o una s-maxage direttiva cache o che utilizzano un override del 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 vi si accede di rado.

Se noti un tasso elevato di espulsioni, assicurati di aver configurato le chiavi della cache in modo da escludere i parametri che non identificano in modo univoco una risposta.

Altre considerazioni

Potrebbero essere applicate anche le seguenti considerazioni relative alla memorizzazione nella cache.

Intestazioni Vary

L'intestazione Vary indica che la risposta varia a seconda delle intestazioni della 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 di 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
• Origine/X-Origin: in genere utilizzato per la condivisione delle risorse tra origini
• X-Goog-Allowed-Resources: supporta la limitazione dell'organizzazione Google Cloud
• Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site: utilizzato per recuperare le intestazioni delle richieste di metadati

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

Media CDN memorizza nella cache fino a 100 varianti per una determinata chiave della cache e rimuove casualmente le varianti dalla cache oltre questo limite. Quando annulli esplicitamente la cache per un determinato URL o tag della cache, tutte le varianti vengono invalidate.

Ignorare la cache

Puoi configurare la modalità cache BYPASS_CACHE su una route per bypassare intenzionalmente la cache nelle richieste corrispondenti. 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 gestire risposte dinamiche, come i backend API, ti consigliamo di configurare un bilanciatore del carico delle applicazioni esterno.

Ti consigliamo di 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 calcolato in base alle tariffe per il traffico in uscita da internet.

Annullamento convalida cache

Vedi annullamento della convalida della cache.

Richieste di intervallo di byte

Media CDN supporta le richieste di intervallo HTTP come definito in RFC 9110.

Inoltre, Media CDN utilizza le richieste di intervallo per recuperare risposte più grandi dall'origine. In questo modo, Media CDN può memorizzare nella cache singoli intervalli di byte e non richiede il recupero dell'intero oggetto in una sola volta per essere memorizzato nella cache.

• Gli oggetti di dimensioni superiori a 1 MiB vengono recuperati come richieste di intervalli di byte fino a 2 MiB ciascuna.
• Le risposte fino a 1 MiB possono essere recuperate senza supporto per gli intervalli di byte all'origine.
• Le risposte di dimensioni superiori a 1 MiB non vengono pubblicate se gli intervalli di byte non sono supportati dall'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 validatore della risposta (ETag o Last-Modified).

Le singole richieste di riempimento dell'origine per ogni intervallo di byte vengono registrate come voci di log discrete e associate alla richiesta client principale. Puoi raggruppare queste richieste abbinando il valore di jsonPayload.cacheKeyFingerprint per ogni richiesta.

Per ulteriori dettagli su ciò che viene registrato, consulta la documentazione di Cloud Logging.

Richieste di intervalli multiparte

Media CDN supporta le richieste di intervallo in più parti, che consentono agli utenti di richiedere più segmenti non contigui di un file in una singola richiesta HTTP, ad esempio Range: bytes=0-499, 1000-1499.

Per massimizzare le prestazioni del client e l'offload dell'origine, Media CDN può servire gli intervalli di byte individuali richiesti dalla cache, consolidandoli in un'unica risposta con un codice di stato HTTP 206 Partial Response al client con Content-Type impostato su multipart/byteranges.

Per le risposte memorizzabili nella cache, quando un client richiede un intervallo multipart, Media CDN ottimizza il processo convertendo la richiesta in un insieme di richieste di intervallo in una sola parte. Ogni richiesta ha una dimensione di 2 MB per coprire tutte le parti degli intervalli di byte richiesti dal client. Media CDN utilizza quindi le risposte per generare una singola risposta multipart all'edge. Questo approccio consente un utilizzo efficiente della cache, riduce i recuperi ridondanti dell'origine e supporta casi d'uso ad alto volume, come i download dagli app store e gli aggiornamenti del sistema operativo.

Per i contenuti non memorizzabili nella cache, Media CDN inoltra direttamente la richiesta all'origine.

Richieste di intervallo aperte

Media CDN supporta le richieste "aperte" Range (ad esempio, una richiesta 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 i byte nel cavo) o scade.

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

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

  #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 come multiplo (ad esempio, 2x) della durata target.

Passaggi successivi

• Consulta il routing avanzato.
• Scopri come connetterti a origini diverse.
• Configura i certificati TLS (SSL) per il tuo servizio.
• Configura le richieste firmate per autenticare l'accesso ai contenuti.
• Per maggiori dettagli sulla configurazione delle risorse EdgeCacheService utilizzando Terraform, consulta la documentazione del registro Terraform.