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, consentendo un EdgeCacheService risorsa da mappare a più origini che contengono, ad esempio, manifest, segmenti video e altri contenuti.
  • Le origini possono essere raggiunte tramite HTTP/2, HTTPS e HTTP/1.1 non criptato.
  • I nuovi tentativi e i comportamenti di failover sono configurati in base all'origine e possono consentire il failover del servizio in caso di errori gravi (come un errore di connettività) o riprovare in base alle risposte HTTP 404 Not Found o HTTP 429 Too Many Requests.
  • È possibile raggiungere risorse private all'interno di Google Cloud o on-premise configurando un bilanciatore del carico delle applicazioni esterno come dietro Media CDN.
  • Il comportamento del reindirizzamento seguente è configurato in base all'origine. Puoi attivare Media CDN per seguire i reindirizzamenti ad altri server di origine.

Requisiti per l'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 della risposta HTTP Last-Modified o ETag (un convalidatore).
  • 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 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 di primo livello, che gestiscono la maggior parte del traffico e lo off-load 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 compilano 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 supporto della memorizzazione nella cache vengono compressi (o coalescenza) e ridurre il carico dall'origine. In base ai carichi di lavoro reali osservati su larga scala:

  • > Il 95% del riempimento della cache utilizza un nodo di cache long-tail dedicato all'interno regione, al fine di ridurre i costi e la latenza di riempimento della cache.
  • Il riempimento della cache tra l'origine e l'infrastruttura perimetrale di Google interamente sulla rete backbone privata globale di Google, che riduce la cache la latenza di riempimento e migliora l'affidabilità: entrambi sono vantaggi attivi per i live streaming carichi di lavoro in modalità flusso.
  • Il cross-fill delle cache l'uno dall'altro è vantaggioso. riducono 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 vedere diversi tassi di offload a seconda della cache configurazione, carico utente, carichi di lavoro (ad esempio live e on demand), utente distribuzione e la quantità di contenuti long-tail (dimensioni totali del corpus) in cui vengono pubblicati in più 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 viene registrata sia la richiesta lato client sia richiesta di riempimento della cache (compressa) registrata. Il responsabile della sessione compressa è utilizzata per effettuare la richiesta di riempimento dell'origine, il che significa che l'origine vede intestazioni (incluso lo User-Agent) del solo client.

Le richieste che non condividono la stessa chiave 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 autenticare le richieste.

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 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 in ogni rete.

Nella tabella seguente sono descritti 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

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 la tua origine non supporta HTTP/2, puoi impostare esplicitamente il protocollo (in base all'origine) a 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 come HTTP/2). Analogamente, quando configuri HTTP/2, la connessione utilizzare HTTP/1.1 per essere esplicita in merito alla connettività dell'origine comportamento degli utenti.
  • 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 ti connetti a un'origine, Media CDN utilizza l'intestazione Host dalla richiesta del client.

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

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 impostata automaticamente in base al nome del bucket

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

Quando utilizzi Cloud Storage, tutte le impostazioni di hostRewrite vengono ignorate bucket come origine perché valori di intestazione host alternativi non sono supportati in base ai bucket Cloud Storage. L'intestazione dell'host viene impostata automaticamente in base il 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:

  • Timeout: determina il tempo di attesa di Media CDN per la connessione alla tua origine o affinché risponda a una richiesta.
  • Nuovi tentativi: determina se Media CDN riprova 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 consentono di configurare il momento in cui i comportamenti di ripetizione e failover dell'origine vengono e quando può essere attivato il failover successivo del client.

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

  • connectTimeout e maxAttemptsTimeout limitano il tempo di 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. Si applicano connectTimeout in modo indipendente per ogni tentativo di origine, mentre maxAttemptsTimeout include il tempo necessario per connettersi tra tutti i tentativi di origine, inclusi di failover e 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 reindirizzamenti, ad esempio da un'origine di reindirizzamento o failover, readTimeout e responseTimeout si applicano i valori corrispondenti. Le origini reindirizzate utilizzano i valori connectTimeout, readTimeout e responseTimeout configurati per l'EdgeCacheOrigin che ha rilevato il reindirizzamento.

  • responseTimeout e readTimeout controllano per quanto tempo una risposta trasmessa in streaming può . Dopo che Media CDN avrà determinato che utilizzerà un 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 ogni EdgeCacheOrigin. Media CDN utilizza il valore maxAttemptsTimeout dell'istanza principale EdgeCacheOrigin. I valori di timeout per tentativo (connectTimeout, readTimeout e responseTimeout) sono configurati per EdgeCacheOrigin per ogni tentativo.

La seguente tabella descrive i campi di timeout:

Campo Predefinito Descrizione
connectTimeout 5 secondi

La quantità massima di tempo che Media CDN può richiedere avviando la richiesta all'origine finché Media CDN non determina se la risposta è usabile. In pratica, connectTimeout copre la fase iniziale di creazione della richiesta, per poi eseguire quindi eseguire handshake TLS, stabilire una connessione TCP/QUIC mediante il recupero delle intestazioni delle risposte che contengono il codice di stato HTTP.

Il timeout deve essere un valore compreso tra 1 secondo e 15 secondi.
maxAttemptsTimeout 15 secondi

Il tempo massimo in tutti i tentativi di connessione all'origine, inclusi 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 secondo e 30 secondi.

Questa impostazione definisce la durata totale per tutte le origini di connessione, incluse le origini di failover, per limitare Tempo totale che i client devono attendere prima che inizi lo streaming. 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 readTimeout è limitato dal 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 consentita per il completamento di una risposta.

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

La durata viene misurata a partire dal momento in cui i primi byte del corpo vengono ricevuto. Se questo timeout viene raggiunto prima che la risposta sia completa, 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.

Riprova richieste di origine

Media CDN supporta i nuovi tentativi dell'origine, consentendo errori non riusciti richieste all'origine da ritentare. Puoi specificare quante volte È possibile ritentare l'origine attuale prima di un'origine di failover (se configurata) di un nuovo tentativo di accesso.

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

Il retryConditions per ogni origine specifica i tipi di errori attiva 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 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 Riprova per i codici di stato 4xx per i quali è possibile riprovare, inclusi 409 e 429.
NOT_FOUND Riprova in base a un codice di stato HTTP 404.
VIETATO Riprova in base a un codice di stato HTTP 403.

Se hai bisogno di un controllo di integrità attivo, di un sistema round-robin o di un sistema di sterzo sensibile al carico. tra 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 riesce a farlo (errore di handshake TLS). Viene fatto un tentativo contro l'origine di failover configurata, che restituisce un 404 HTTP . Sì HTTP 404 Not Found
Media CDN tenta di connettersi sia all'account principale di failover, ma non riceve 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 origini attendibili e controllo. Assicurati di considerare attendibili tutte le origini in una catena di reindirizzamento, perché ciascuna produce contenuti pubblicati dal tuo EdgeCacheService.

Passaggi successivi