Panoramica delle origini

Media CDN ti consente di recuperare i contenuti dall'infrastruttura di origine, indipendentemente dal fatto che siano ospitati in Google Cloud, in un altro cloud o on-premise.

A ogni configurazione possono essere associate una o più origini. Le configurazioni dell'origine indicano a Media CDN come connettersi alla tua infrastruttura, quando e come eseguire il failover, riprovare e impostare il timeout e quale protocollo utilizzare per la connessione.

Le origini hanno le seguenti caratteristiche:

• Le origini possono essere definite per host e per percorso, il che consente a una singola risorsa EdgeCacheService di essere mappata a più origini che contengono, ad esempio, manifest, segmenti video e altri contenuti statici.
• Le origini sono raggiungibili tramite HTTP/2, HTTPS e HTTP/1.1 non criptato.
• I comportamenti di nuovi tentativi e failover vengono configurati per origine e possono consentire al servizio di eseguire il failover in caso di errori irreversibili (ad esempio un errore di connettività) o di riprovare in base alle risposte HTTP 404 Not Found o HTTP 429 Too Many Requests.
• È possibile raggiungere le risorse private all'interno di Google Cloud o on-premise configurando un bilanciatore del carico delle applicazioni esterno come origine dietro Media CDN.
• Il comportamento di follow dei reindirizzamenti è configurato per origine. Puoi attivare Media CDN per seguire i reindirizzamenti ad altri server di origine.

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.

Protezione origine

Media CDN fornisce un'infrastruttura perimetrale a più livelli, progettata per ridurre al minimo il riempimento della cache quando possibile.

Esistono tre livelli principali di infrastruttura di memorizzazione nella cache:

1. Cache edge profonde, che gestiscono la maggior parte del traffico e lo scaricano all'interno della rete di un fornitore di servizi.
2. Il peering edge di Google, che è connesso a migliaia di ISP e funge da cache di livello intermedio per le cache edge e, nei casi in cui queste non sono presenti in un determinato ISP, la cache rivolta agli utenti.
3. Cache long tail all'interno della rete di Google che altre cache downstream riempiono prima dell'origine. Queste cache supportano un fan-in significativo, hanno una notevole capacità di archiviazione della cache e fungono da scudo dell'origine.

Ecco una panoramica di questa topologia:

Media CDN fornisce la protezione dell'origine per impostazione predefinita utilizzando un insieme limitato di località globali chiave. La protezione dell'origine predefinita funziona in base alla posizione dell'utente finale e non dell'origine. Questa soluzione funziona bene e offre vantaggi di offload significativi quando gli utenti finali e i server di origine si trovano nella stessa regione e quando i server di origine globali si trovano in più regioni.

Protezione flessibile

Negli scenari in cui l'origine è centralizzata in una regione, ma gli utenti sono distribuiti a livello globale, il comportamento predefinito di protezione dell'origine, basato sulla posizione dell'utente, potrebbe essere non ottimale nei seguenti modi:

• Aumenta la latenza per gli errori della cache quando la posizione dello scudo predefinita è geograficamente distante dall'origine centralizzata
• Riduzione dell'offload dell'origine distribuendo le richieste di riempimento della cache in più posizioni di protezione predefinite globali anziché concentrarle

La protezione flessibile ti aiuta a superare queste limitazioni configurando una singola regione geografica specifica per la protezione dell'origine, in genere selezionata in modo che si trovi vicino all'origine centralizzata. La protezione flessibile instrada tutte le richieste di riempimento della cache tramite le cache di protezione situate nella regione configurata o nelle sue vicinanze. In questo modo, il carico viene consolidato sull'origine tramite queste cache incentrate a livello regionale.

Se configuri una regione di protezione flessibile nella stessa regione geografica dell'origine centralizzata, puoi ottimizzare quanto segue:

• Percentuale di successo della cache a livello di scudo
• Offload dell'origine
• Latenza per i fallimenti della cache e i contenuti non memorizzabili nella cache
• Stabilità del rendimento

La protezione flessibile è compatibile con qualsiasi tipo di origine configurato in Media CDN.

Richiedi compressione

La compressione delle richieste comprime attivamente più richieste di riempimento della cache generate dagli utenti per la stessa chiave della cache in un'unica richiesta di origine, per nodo edge.

Tutti i livelli di memorizzazione nella cache supportano il raggruppamento delle richieste (o unione) per ridurre ulteriormente il carico sull'origine. In base ai carichi di lavoro reali osservati su larga scala:

• > Il 95% del riempimento della cache utilizza un nodo della cache long tail dedicato all'interno della regione, per ridurre i costi e la latenza del riempimento della cache.
• Il riempimento della cache tra l'origine e l'infrastruttura edge di Google avviene interamente tramite la rete backbone privata globale di Google, il che riduce la latenza di riempimento della cache e migliora l'affidabilità. Entrambi sono vantaggi attivi per i carichi di lavoro di streaming live.
• Le cache si riempiono a vicenda quando è vantaggioso farlo, riducendo ulteriormente i tassi di riempimento della cache.
• Media CDN dispone di una notevole capacità di archiviazione nelle cache, il che riduce al minimo i tassi di eliminazione anche per i contenuti meno popolari e a coda lunga.

I clienti potrebbero visualizzare tassi di offload diversi a seconda della configurazione della cache, del carico utente, dei carichi di lavoro (ad esempio live e on demand), della distribuzione degli utenti e della quantità di contenuti long tail (dimensione totale del corpus) che pubblicano per gli utenti nelle varie regioni.

In combinazione con la protezione dell'origine, il raggruppamento delle richieste riduce ulteriormente il carico dell'origine e le esigenze di larghezza di banda in uscita ed è il comportamento predefinito per Media CDN.

Le richieste compresse hanno registrato sia la richiesta rivolta al client sia la richiesta di riempimento della cache (compressa). Il leader della sessione compressa viene utilizzato per effettuare la richiesta di riempimento dell'origine, il che significa che l'origine vede le intestazioni (incluso User-Agent) solo di quel client.

Le richieste che non condividono la stessa chiave della cache non possono essere compresse.

Connettività origine

Le seguenti sezioni descrivono come Media CDN si connette alle origini, come vengono effettuate le richieste HTTP e come puoi autenticare le richieste.

Origini e protocolli supportati

Media CDN supporta direttamente qualsiasi endpoint HTTP raggiungibile pubblicamente come origine, inclusi i seguenti:

• Bucket Cloud Storage, inclusi i bucket privati tramite account di servizio Identity and Access Management
• Bilanciatori del carico delle applicazioni esterni
• Bucket compatibili con Amazon S3, inclusi i bucket privati che utilizzano la versione 4 della firma AWS
• Altro spazio di archiviazione di oggetti disponibile pubblicamente, ad esempio Azure Blob Storage
• Server web disponibili pubblicamente, come VM pubbliche o host on-premise

La connettività alle origini avviene tramite tunnel sicuri e la rete backbone globale di Google.

La tabella seguente mostra in dettaglio i protocolli di origine supportati.

Protocollo	Supportato	SSL (TLS) obbligatorio
HTTP/2	Sì (impostazione predefinita)	Sì
HTTPS (HTTP/1.1 su TLS)	Sì	Sì
HTTP/1.1	Sì	No

Media CDN utilizza HTTP/2 (h2) per connettersi a un'origine per impostazione predefinita. HTTP/2 e HTTPS richiedono entrambi un certificato TLS (SSL) valido e considerato attendibile pubblicamente. Un certificato valido è un certificato non scaduto, firmato da un'autorità di certificazione pubblica e con un nome alternativo del soggetto corrispondente al nome host inviato all'origine.

Note:

• Se l'origine non supporta HTTP/2, puoi impostare esplicitamente il protocollo (in base all'origine) su HTTP (HTTP/1.1) o HTTPS (HTTP/1.1 su TLS).
• Quando configuri HTTPS o HTTP/1.1 come protocollo di origine, Media CDN non negozia un protocollo alternativo (ad esempio HTTP/2). Analogamente, quando si configura HTTP/2, la connessione non esegue il fallback a HTTP/1.1, per essere espliciti sul comportamento della connettività di origine.
• Media CDN utilizza automaticamente la porta corretta in base al protocollo: la porta 80 per HTTP o la porta 443 per HTTPS e HTTP/2.

Intestazioni delle richieste di origine

Quando si connette a un'origine, Media CDN utilizza l'intestazione Host della richiesta del client per impostazione predefinita.

La tabella seguente documenta ciò che l'origine vede nella richiesta in entrata in diversi scenari di configurazione:

Richiesta del cliente	EdgeCacheService.hostRewrite	EdgeCacheOrigin.hostRewrite	originAddress	Intestazione host / SNI TLS all'origine
media.example.com	Nessuno	Nessuno	backend.example.com	media.example.com
media.example.com	service.example.com	Nessuno	backend.example.com	service.example.com
media.example.com	Nessuno	origin.example.com	backend.example.com	origin.example.com
media.example.com	service.example.com	origin.example.com	backend.example.com	origin.example.com
media.example.com	service.example.com	origin.example.com	gs://vod-content-bucket	impostato automaticamente in base al nome del bucket

L'origine principale e le origini di failover vedono lo stesso host header se condividono la stessa configurazione routeRule o hostRewrite.

Qualsiasi impostazione hostRewrite viene ignorata quando utilizzi un bucket Cloud Storage come origine perché i valori alternativi dell'intestazione host non sono supportati dai bucket Cloud Storage. L'intestazione host viene impostata automaticamente in base al nome del bucket.

Il valore SNI (Server Name Indication) TLS nella richiesta (per le richieste HTTP/3, HTTP/2 e HTTPS) è impostato sullo stesso valore dell'intestazione host inviata all'origine.

Per informazioni sulla riscrittura delle intestazioni host per la configurazione per route, vedi Configurare le route di servizio. Per informazioni sull'impostazione di azioni di override per origine, vedi Failover dell'origine senza seguire il reindirizzamento.

Failover e timeout

Le sezioni seguenti descrivono queste opzioni di configurazione:

• Timeout: determina per quanto tempo Media CDN attende di connettersi all'origine o che risponda a una richiesta.
• Tentativi: determina se Media CDN ritenta una richiesta HTTP di origine alla tua origine e in quali condizioni.
• Failover: determina se Media CDN tenta di connettersi a un'origine di failover se la prima non è disponibile o restituisce un codice di stato specifico.

Timeout origine

I timeout consentono di configurare quando vengono attivati i comportamenti di ripetizione e failover dell'origine e quando può essere attivato il failover del client successivo.

Di seguito sono descritti i timeout configurabili supportati da Media CDN:

• connectTimeout e maxAttemptsTimeout limitano il tempo necessario a Media CDN per trovare una risposta utilizzabile.

  Entrambi i timeout includono il tempo necessario all'origine per restituire le intestazioni e per determinare se utilizzare un failover o un reindirizzamento. connectTimeout viene applicato indipendentemente per ogni tentativo di origine, mentre maxAttemptsTimeout include il tempo necessario per connettersi a tutti i tentativi di origine, inclusi i failover e i reindirizzamenti. Un reindirizzamento viene conteggiato come un ulteriore tentativo di connessione all'origine e viene conteggiato ai fini del limite maxAttempts impostato per l'origine configurata.

  Quando Media CDN rileva una risposta non di reindirizzamento, ad esempio da un'origine di reindirizzamento o di failover, vengono applicati i valori readTimeout e responseTimeout. Le origini reindirizzate utilizzano i valori connectTimeout, readTimeout e responseTimeout configurati per EdgeCacheOrigin che ha riscontrato il reindirizzamento.

• responseTimeout e readTimeout controllano la durata di una risposta in streaming. Dopo che Media CDN ha stabilito che utilizzerà una risposta upstream, né connectTimeout né maxAttemptsTimeout sono importanti. A questo punto, entrano in vigore readTimeout e responseTimeout.

Media CDN esegue al massimo quattro tentativi di origine in tutte le origini, indipendentemente dal valore di maxAttempts impostato da ogni EdgeCacheOrigin. Media CDN utilizza il valore maxAttemptsTimeout del EdgeCacheOrigin principale. I valori di timeout per tentativo (connectTimeout, readTimeout e responseTimeout) sono configurati per EdgeCacheOrigin di ogni tentativo.

La tabella seguente descrive i campi relativi al timeout:

Campo	Predefinito	Descrizione
connectTimeout	5 secondi	Il tempo massimo che Media CDN può impiegare dall'avvio della richiesta all'origine fino a quando Media CDN determina se la risposta è utilizzabile. In pratica, connectTimeout copre il tempo che inizia con la creazione della richiesta, quindi con le ricerche DNS, poi con gli handshake TLS, la creazione della connessione TCP/QUIC, fino a ottenere le intestazioni della risposta che contengono il codice di stato HTTP. Il timeout deve essere un valore compreso tra 1 e 15 secondi.
maxAttemptsTimeout	15 secondi	Il tempo massimo in tutti i tentativi di connessione all'origine, incluse quelle di failover, prima di restituire un errore al client. Viene restituito un errore HTTP 504 se il timeout viene raggiunto prima che venga restituita una risposta. Il timeout deve essere un valore compreso tra 1 e 30 secondi. Questa impostazione definisce la durata totale per tutti i tentativi di connessione all'origine, incluse le origini di failover, per limitare il tempo totale che i client devono attendere prima che inizi lo streaming dei contenuti. Viene utilizzato solo il primo valore maxAttemptsTimeout, dove il primo è definito dall'origine configurata per la route specificata.
readTimeout	15 secondi	La durata massima di attesa tra le letture di una singola risposta HTTP. Il valore readTimeout è limitato dal valore responseTimeout. Tutte le letture della risposta HTTP devono essere completate entro la scadenza stabilita da responseTimeout. Il timeout deve essere un valore compreso tra 1 e 30 secondi. Se questo timeout viene raggiunto prima che la risposta sia completa, la risposta viene troncata e registrata.
responseTimeout	30 secondi	La durata massima consentita per il completamento di una risposta. Il timeout deve essere un valore compreso tra 1 e 120 secondi. La durata viene misurata a partire dal momento in cui vengono ricevuti i primi byte del corpo. Se questo timeout viene raggiunto prima che la risposta sia completa, la risposta viene troncata e registrata.

Considera i seguenti esempi:

• Origin A corrisponde alle richieste a "/segments/" e ha un valore maxAttemptsTimeout di 5s, un valore maxAttempts di 1 e un valore failover_origin di Origin B. Il valore connectTimeout è impostato sul valore predefinito di 5s. Se tenti di connetterti a Origin A e l'operazione non va a buon fine entro 1 secondo a causa di un certificato TLS non valido, hai a disposizione circa 4 secondi per stabilire una connessione riuscita a Origin B.

• Origin C corrisponde alle richieste a "/manifests/*", ha un valore maxAttemptsTimeout di 10s, un valore maxAttempts di 3 e failover_origin non configurato. Il valore connectTimeout è impostato sul valore predefinito 5s. Media CDN tenta di connettersi a Origin C fino a tre volte, consentendo fino a 10 secondi (il limite maxAttemptsTimeout) per stabilire una connessione riuscita.

Riprova le richieste di origine

Media CDN supporta i tentativi di ripetizione dell'origine, consentendo di riprovare le richieste all'origine non andate a buon fine. Puoi specificare il numero di tentativi che possono essere eseguiti sull'origine corrente prima di tentare un'origine di failover (se configurata).

• Media CDN tenta di raggiungere l'origine principale fino al valore maxAttempts configurato, che per impostazione predefinita è 1.
• Media CDN ritenta le connessioni all'origine fino a un massimo di tre volte prima di non riuscire e restituire un errore HTTP 502 Bad Gateway all'utente. Sono incluse le connessioni di origine di failover, che vengono conteggiate nel limite di tre.
• Quando configuri una risorsa di origine, puoi configurare un'origine principale utilizzando il campo originAddress e poi un failoverOrigin facoltativo. failoverOrigin punta a un'altra risorsa di origine.

Il retryConditions per ogni origine specifica i tipi di errori che attivano un nuovo tentativo:

Condizione	Predefinito	Descrizione
CONNECT_FAILURE	✔️	Il nuovo tentativo in caso di errore include gli errori di routing, DNS e handshake TLS, nonché i timeout TCP/UDP.
HTTP_5XX		Riprova in caso di codice di stato HTTP 5xx.
GATEWAY_ERROR		Simile a 5xx, ma si applica solo ai codici di stato 502, 503 o 504.
RETRIABLE_4XX		Nuovo tentativo per i codici di stato 4xx per cui è possibile riprovare, inclusi 409 e 429.
NOT_FOUND		Riprova con un codice di stato HTTP 404.
FORBIDDEN		Riprova con un codice di stato HTTP 403.

Se hai bisogno di controlli di integrità attivi, round robin o routing basato sul carico tra le origini, puoi configurare un bilanciatore del carico delle applicazioni esterno come origine principale.

Comportamento di failover

La tabella seguente descrive il funzionamento del failover e la risposta che un client osserverebbe:

Scenario	Failover configurato	Stato rivolto all'utente
Media CDN tenta di connettersi all'origine e non riceve alcuna risposta HTTP dopo due tentativi (impostazione predefinita).	No	HTTP 502 Bad Gateway
Media CDN tenta di connettersi all'origine principale, ma la connessione non va a buon fine (errore di handshake TLS). Viene effettuato un tentativo sull'origine di failover configurata, che restituisce un errore HTTP 404.	Sì	HTTP 404 Not Found
Media CDN tenta di connettersi sia all'origine principale sia a quella di failover, ma non riceve alcun codice di stato HTTP.	Sì	HTTP 502 Bad Gateway

Se Media CDN riceve un codice di stato corrispondente a uno dei retryConditions configurati, ad esempio un errore HTTP 404 Not Found o HTTP 429 Too Many Requests, e i successivi tentativi e richieste di failover dell'origine continuano a non riuscire, al client viene restituito un errore HTTP 502 Bad Gateway dopo che i tentativi di origine sono esauriti.

Best practice per il failover dell'origine

Quando configuri più origini per il failover o il bilanciamento del carico, verifica che il comportamento delle intestazioni dei contenuti multimediali e di Vary, ETag e Last-Modified sia coerente tra le origini.

Come best practice, configura il reindirizzamento dell'origine solo per le origini di cui ti fidi e che controlli. Assicurati di considerare attendibile ogni origine in una catena di reindirizzamento perché ogni origine produce contenuti pubblicati dal tuo EdgeCacheService.

Passaggi successivi

• Configurare un'origine
• Utilizzare un bucket privato compatibile con Amazon S3 come origine
• Configurare le route di servizio