Panoramica delle origini

Media CDN ti consente di recuperare contenuti dalla tua origine di archiviazione dei contenuti, sia che i contenuti siano ospitati all'interno di Google Cloud, nel cloud o on-premise.

Ogni configurazione può avere una o più origini associate. Origine indicano a Media CDN come connettersi dell'infrastruttura, quando e come eseguire il failover, riprovare e il timeout, nonché il protocollo per la connessione.

Le origini dispongono delle 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 crittografato.
  • 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 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.

Protezione origine

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

Esistono tre livelli principali di infrastruttura di memorizzazione nella cache:

  1. Cache perimetrali, che gestiscono la maggior parte del traffico e svincolano il carico all'interno una rete di provider di servizi.
  2. Il perimetro del peering di Google, che è connesso a migliaia di ISP e agisce come la cache di livello medio per le cache perimetrali e nei casi in cui all'interno di un dato ISP, la cache rivolta all'utente.
  3. Cache long-tail all'interno della rete Google che vengono riempite da altre cache downstream da una regione precedente all'origine. Queste cache supportano un numero elevato di fan-in, hanno una notevole capacità di archiviazione della cache e funge da scudo di origine.

Una panoramica di questa topologia è riportata qui:

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. Basato sui 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 ha una capacità di archiviazione significativa in di cache, il che riduce al minimo i tassi di rimozione anche per i modelli long-tail, contenuti.

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.

Richiedi compressione

La richiesta di compressione comprime attivamente più file richieste di riempimento della cache per la stessa chiave cache in una singola richiesta di origine, nodo periferico.

In combinazione con la protezione dell'origine, questo riduce ulteriormente carico di origine e di larghezza di banda in uscita ed è il comportamento predefinito 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 seguenti sezioni descrivono come Media CDN si connette alle origini, come vengono effettuate le richieste HTTP e come è possibile autenticare le richieste.

Origini e protocolli supportati

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

  • ai bucket Cloud Storage, inclusi i bucket privati tramite Account di servizio Identity and Access Management
  • Bilanciatori del carico delle applicazioni esterni
  • I bucket compatibili con Amazon S3, inclusi bucket privati che utilizzano Firma AWS versione 4
  • Altro spazio di archiviazione di oggetti disponibile pubblicamente, ad esempio Archiviazione BLOB di Azure
  • 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 in ogni rete.

Nella tabella seguente sono descritti in dettaglio i protocolli di origine supportati.

Protocollo Supportato SSL (TLS) richiesto
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. HTTP/2 e HTTPS richiedono un certificato TLS (SSL) valido e pubblicamente attendibile. R un certificato valido è un certificato non scaduto, firmato da un certificato pubblico e ha un nome alternativo del soggetto corrispondente al nome host inviato al 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 SNI (Server Name Indication) TLS nella richiesta (per HTTP/3, HTTP/2, e HTTPS) sia impostato sullo stesso valore dell'intestazione host inviata origine dati.

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

Failover e timeout

Nelle sezioni seguenti vengono descritte 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 riesegue un nuovo tentativo HTTP dell'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 uno stato specifico le API nel tuo codice.

Timeout 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 vengono descritti i timeout configurabili che Media CDN supporta:

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

    Entrambi i timeout includono il tempo impiegato dall'origine per restituire le intestazioni e 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. L'esecuzione di un reindirizzamento viene conteggiata come tenta di connettersi all'origine e viene conteggiato ai fini del set di maxAttempts 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 connectTimeout, readTimeout, e responseTimeout valori configurati per EdgeCacheOrigin che ha riscontrato 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, readTimeout e responseTimeout entrano in vigore.

Media CDN effettua al massimo quattro tentativi per l'origine tra 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.

Nella tabella seguente vengono descritti i campi relativi al 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. 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. Solo il primo Viene utilizzato il 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 readTimeout è limitato dal responseTimeout. Tutte le letture della risposta HTTP devono essere completate entro la scadenza impostata dalla responseTimeout. Il timeout deve essere un valore compreso tra 1 secondo e 30 secondi. Se questo timeout viene raggiunto prima che la risposta sia completa, la risposta è 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 è troncata e registrata.

Considera i seguenti esempi:

  • Origin A corrisponde alle richieste a "/segments/" e ha un Valore maxAttemptsTimeout di 5s, valore maxAttempts di 1 e un Valore failover_origin di Origin B. Il valore connectTimeout è al suo il valore predefinito è 5s. Se tenti di connetterti a Origin A, ma l'operazione non riesce entro 1 a causa di un certificato TLS non valido, hai circa 4 secondi rimanenti per connessione a Origin B riuscita.

  • Origin C corrisponde alle richieste a "/manifests/*, ha un valore maxAttemptsTimeout di 10s, un valore maxAttempts pari a 3 e failover_origin non configurato. La Il valore predefinito di connectTimeout è 5s. CDN multimediale tenta di connettersi a Origin C per tre volte, con un intervallo di tempo massimo di 10 secondi (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 il valore di 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, poi un failoverOrigin facoltativo. La failoverOrigin punta 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 ✔️ Riprova in caso di errori, tra cui errori di routing, DNS e handshake TLS. 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 ricevere 4xx codici di stato che è possibile riprovare. tra cui 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 fornita da un client potrebbe osservare:

Scenario Failover configurato Stato rivolto agli utenti
Media CDN tenta di connettersi alla tua origine e non riceve risposta HTTP dopo due tentativi (impostazione predefinita). No HTTP 502 Bad Gateway
Media CDN tenta di connettersi all'origine principale, e non riesce a connettersi (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, ad esempio un errore HTTP 404 Not Found o HTTP 429 Too Many Requests e le successive richieste di origine di nuovo e failover continuano su non riesce, viene restituito al client un errore HTTP 502 Bad Gateway dopo l'origine tentativi esauriti.

Best practice per il failover dell'origine

Quando configuri più origini per il failover o il bilanciamento del carico, assicurati che: i tuoi contenuti multimediali e i comportamenti delle intestazioni Vary, ETag e Last-Modified sono coerente tra le tue origini.

Come best practice, configura il reindirizzamento delle origini solo per origini attendibili e controllo. Assicurati di considerare attendibile ogni origine in una catena di reindirizzamento ogni origine produce contenuti pubblicati da EdgeCacheService.

Passaggi successivi