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 di origine indicano a Media CDN come connettersi alla tua infrastruttura, quando e come eseguire il failover, le riavviate e il timeout e quale protocollo utilizzare per la connessione.

Le origini hanno le seguenti funzionalità:

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

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.

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 dell'infrastruttura di memorizzazione nella cache:

  1. Cache di primo livello, che gestiscono la maggior parte del traffico e lo offrono 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 perimetrali e, nei casi in cui queste non siano presenti all'interno di un determinato ISP, la cache rivolta agli utenti.
  3. Cache long-tail all'interno della rete di Google che altre cache a valle riempiono prima dell'origine. Queste cache supportano un fan-in significativo, hanno una notevole capacità di archiviazione della cache e fungono da scudo delle origini.

Di seguito è riportata una panoramica di questa topologia:

Panoramica della topologia.
Panoramica della topologia (fai clic per ingrandire).

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

  • Oltre 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 sulla rete backbone privata globale di Google, il che riduce la latenza del riempimento della cache e migliora l'affidabilità, entrambi vantaggi attivi per i carichi di lavoro di live streaming.
  • Le cache si riempiono in modo incrociato se è vantaggioso, 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 espulsione anche per i contenuti long-tail meno popolari.

I clienti potrebbero riscontrare tassi di offload diversi a seconda della configurazione della cache, del carico utente, dei carichi di lavoro (ad esempio contenuti dal vivo o on demand), della distribuzione degli utenti e della quantità di contenuti long-tail (dimensioni totali del corpus) che offrono agli utenti nelle varie regioni.

Collasso delle richieste

Il collasso delle richieste comprime attivamente più richieste di compilazione della cache basate sugli utenti per la stessa chiave della cache in una singola richiesta di origine, per ogni nodo edge.

Se combinato con la protezione dell'origine, riduce ulteriormente il carico dell'origine e le esigenze di larghezza di banda in uscita ed è il comportamento predefinito per Media CDN.

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

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

Connettività origine

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

Origini e protocolli supportati

Media CDN supporta direttamente qualsiasi endpoint HTTP accessibile pubblicamente come origine, tra cui:

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

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

La tabella seguente illustra 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

Per impostazione predefinita, Media CDN utilizza HTTP/2 (h2) per connettersi a un'origine. Sia HTTP/2 che HTTPS richiedono 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 dell'oggetto che corrisponde al nome host inviato all'origine.

Note:

  • Se l'origine non supporta HTTP/2, puoi impostare esplicitamente il protocollo (su base di 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 (come HTTP/2). Analogamente, quando configuri HTTP/2, la connessione non ricorre a HTTP/1.1 per essere esplicita sul comportamento della connettività dell'origine.
  • Media CDN utilizza automaticamente la porta corretta in base al protocollo: porta 80 per HTTP o porta 443 per HTTPS e HTTP/2.

Intestazioni delle richieste di origine

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

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

Richiesta del client 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 eventuali origini di failover vedono lo stesso intestazione host se condividono la stessa configurazione routeRule o hostRewrite.

Eventuali impostazioni hostRewrite vengono ignorate quando si utilizza un bucket Cloud Storage come origine perché i valori dell'intestazione host alternativa non sono supportati dai bucket Cloud Storage. L'intestazione host viene impostata automaticamente in base al nome del bucket.

Il valore TLS SNI (Server Name Indication) 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, consulta Configurare i route del servizio. Per informazioni su come impostare le azioni di override per ogni origine, consulta Failover dell'origine senza il reindirizzamento.

Failover e timeout

Le sezioni seguenti descrivono queste opzioni di configurazione:

  • Tempo di attesa: determina il tempo di attesa di Media CDN per connettersi alla tua origine o per rispondere a una richiesta.
  • Nuovi tentativi: determina se Media CDN esegue nuovamente una richiesta HTTP dell'origine all'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 stato specifico.

Timeout dell'origine

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

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 si applica in modo indipendente per ogni tentativo di origine, mentre maxAttemptsTimeout include il tempo necessario per la connessione in tutti i tentativi di origine, inclusi i failover e i reindirizzamenti. Il follow di un reindirizzamento viene conteggiato come un ulteriore tentativo di connessione all'origine e viene conteggiato ai fini del valore maxAttempts impostato per l'origine configurata.

    Quando Media CDN rileva una risposta senza reindirizzamento, ad esempio proveniente 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 l'EdgeCacheOrigin che ha rilevato il reindirizzamento.

  • responseTimeout e readTimeout controllano il tempo necessario per una risposta in streaming. Una volta che Media CDN ha stabilito che utilizzerà una risposta upstream, né connectTimeout né maxAttemptsTimeout sono importanti. A questo punto, vengono applicati readTimeout e responseTimeout.

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

La seguente tabella descrive i campi di timeout:

Campo Predefinito Descrizione
connectTimeout 5 secondi

Il tempo massimo che Media CDN può impiegare dall'inizio della richiesta all'origine fino a quando Media CDN non determina se la risposta è utilizzabile. In pratica, connectTimeout copre il tempo che inizia con la creazione della richiesta, poi con le ricerche DNS, poi con gli handshake TLS, la creazione della connessione TCP/QUIC, fino all'ottenimento delle intestazioni di risposta contenenti 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. Verrà visualizzato 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 di 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 primo è definito dall'origine configurata per il percorso specificato.
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 impostata da responseTimeout. Il timeout deve essere un valore compreso tra 1 e 30 secondi. Se questo timeout viene raggiunto prima del completamento della risposta, la risposta viene troncata e registrata.
responseTimeout 30 secondi

La durata massima per consentire il completamento di una risposta.

Il timeout deve essere un valore compreso tra 1 e 120 secondi.

La durata viene misurata dal momento in cui vengono ricevuti i primi byte del corpo. Se questo timeout viene raggiunto prima del completamento della risposta, la risposta viene troncata e registrata.

Considera gli esempi seguenti:

  • 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 5s. Se il tentativo di connessione a Origin A non va a buon fine entro 1 secondo a causa di un certificato TLS non valido, hai circa 4 secondi di tempo per effettuare 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 di maxAttemptsTimeout) per stabilire una connessione riuscita.

Riprova le richieste di origine

Media CDN supporta i tentativi di origine, consentendo di riprovare le richieste non andate a buon fine all'origine. Puoi specificare quante volte è possibile riprovare con l'origine corrente prima di tentare con 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 riprova a connettersi all'origine fino a un massimo di tre volte prima di non riuscire e di restituire un errore HTTP 502 Bad Gateway all'utente. Sono incluse eventuali connessioni di origine di failover, che vengono conteggiate ai fini del limite di tre.
  • Quando configuri una risorsa di origine, puoi configurare un'origine principale utilizzando il campo originAddress e un failoverOrigin facoltativo. failoverOrigin fa riferimento a un'altra risorsa di origine.

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

Condizione Predefinito Descrizione
CONNECT_FAILURE ✔️ Nuovo tentativo in caso di errore, inclusi gli errori di routing, DNS e handshake TLS, nonché i timeout TCP/UDP.
HTTP_5XX Riprova con qualsiasi codice di stato HTTP 5xx.
GATEWAY_ERROR Simile a 5xx, ma si applica solo ai codici di stato 502, 503 o 504.
RETRIABLE_4XX Riprova per i codici di stato 4xx per i quali è 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 stato attivi, di un criterio di assegnazione round robin o di gestione del 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 osserva:

Scenario Failover configurato Stato rivolto agli utenti
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 non ci riesce (errore di handshake TLS). Viene effettuato un tentativo contro l'origine di failover configurata, che restituisce un errore HTTP 404. Sì HTTP 404 Not Found
Media CDN tenta di connettersi sia all'origine principale che 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 qualsiasi retryConditions configurato, ad esempio un errore HTTP 404 Not Found o HTTP 429 Too Many Requests, e le richieste di origine di ripetizione e failover successive continuano a non riuscire, viene restituito un errore HTTP 502 Bad Gateway al client dopo che i tentativi di origine sono stati esauriti.

Best practice per il failover dell'origine

Quando configuri più origini per il failover o il bilanciamento del carico, assicurati che i contenuti multimediali e i comportamenti degli header Vary, ETag e Last-Modified siano coerenti tra le origini.

Come best practice, configura il reindirizzamento delle origini solo per quelle di cui ti fidi e che controlli. Assicurati di considerare attendibili tutte le origini in una catena di reindirizzamento, perché ciascuna produce contenuti pubblicati dal tuo EdgeCacheService.

Passaggi successivi