Panoramica di Origini

Media CDN ti consente di recuperare i contenuti dall'infrastruttura di origine, che questi siano ospitati all'interno di Google Cloud, in un altro cloud oppure on-premise.

Ogni configurazione può avere una o più origini associate. Le configurazioni dell'origine indicano a Media CDN come connettersi alla tua infrastruttura, quando e come eseguire il failover, nuovi tentativi e timeout e il protocollo da utilizzare per la connessione.

Le origini dispongono delle seguenti funzionalità:

  • Le origini possono essere definite per host e per route, il che consente a una singola risorsa EdgeCacheService di mappare a più origini che contengono, ad esempio, manifest, segmenti video e altri contenuti statici.
  • Le origini possono essere raggiunte tramite HTTP/2, HTTPS e HTTP/1.1 non crittografato.
  • I nuovi tentativi e i comportamenti di failover vengono configurati in base all'origine e possono consentire il failover del servizio in caso di errori rigidi (come un errore di connettività) o riprovare 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 di Media CDN.
  • Il comportamento del reindirizzamento seguente è configurato in base all'origine. Puoi abilitare Media CDN in modo che segua i reindirizzamenti ad altri server di origine.

Requisiti dell'origine

Per consentire a Media CDN di memorizzare nella cache risposte di origine 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 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 il campo del protocollo in modo esplicito per ogni origine.

Protezione origine

Media CDN offre un'infrastruttura perimetrale profonda a più livelli, progettata per ridurre attivamente al minimo il riempimento della cache laddove possibile.

Esistono tre livelli principali di infrastruttura di memorizzazione nella cache:

  1. Cache perimetrali profonde, che gestiscono la maggior parte del traffico e svincolano il carico all'interno della rete di un provider di servizi.
  2. Perimetro del peering di Google, che è connesso a migliaia di ISP e funge da cache di livello medio per le cache perimetrali; nei casi in cui non sono presenti all'interno di un determinato ISP, è la cache rivolta all'utente.
  3. Cache long-tail all'interno della rete Google che vengono riempite da altre cache downstream prima dell'origine. Queste cache supportano un numero elevato di fan-in, hanno una notevole capacità di archiviazione nella cache e fungono da scudo dell'origine.

Una panoramica di questa topologia è riportata qui:

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

Tutti i livelli di memorizzazione nella cache supportano le richieste di compressione (o coalescenza) per ridurre ulteriormente il carico dall'origine. Basato sui carichi di lavoro reali osservati su larga scala:

  • Oltre il 95% del riempimento della cache utilizza un nodo di cache long-tail dedicato all'interno della regione al fine di ridurre i costi e la latenza del riempimento della cache.
  • Il riempimento della cache tra l'origine e l'infrastruttura perimetrale di Google si estende interamente sulla 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 in live streaming.
  • Il crossfill delle cache l'uno dall'altro è vantaggioso, riducendo ulteriormente i tassi di riempimento della cache.
  • Media CDN ha una capacità di archiviazione significativa nelle cache, che riduce al minimo i tassi di eliminazione anche per i contenuti long-tail e meno popolari.

I clienti potrebbero notare percentuali di offload diverse 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 (dimensioni totali del corpus) pubblicati per gli utenti nelle varie regioni.

Richiedi compressione

La richiesta di compressione comprime attivamente più richieste di riempimento della cache guidate dall'utente per la stessa chiave di cache in un'unica richiesta di origine, per nodo perimetrale.

In combinazione con la schermatura 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 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 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 autenticare le richieste.

Origini e protocolli supportati

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

  • Bucket Cloud Storage, inclusi bucket privati tramite gli account di servizio Identity and Access Management
  • Bilanciatori del carico delle applicazioni esterni
  • Bucket compatibili con Amazon S3, compresi i bucket privati che utilizzano la versione 4 della firma AWS
  • 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.

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. 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 la tua 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 utilizza HTTP/1.1 per indicare esplicitamente il comportamento di 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 ti connetti a un'origine, Media CDN utilizza l'intestazione Host della richiesta del client per impostazione predefinita.

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

Richiesta del client EdgeCacheService.hostRewrite EdgeCacheOrigin.hostRewrite originAddress Intestazione host /
SNI TLS all'origine
media.example.com Nessuna Nessuna backend.example.com media.example.com
media.example.com service.example.com Nessuna backend.example.com service.example.com
media.example.com Nessuna 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.

Qualsiasi impostazione di hostRewrite viene ignorata quando utilizzi un bucket Cloud Storage come origine, perché i valori di intestazione host alternativi 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 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 sulla configurazione delle 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 connettersi all'origine o prima che risponda a una richiesta.
  • Tentativi: determina se Media CDN ripristina 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 successivo del client.

Di seguito vengono 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 impiegato dall'origine per restituire le intestazioni e per determinare se utilizzare un failover o un reindirizzamento. connectTimeout si applica in modo indipendente a ogni tentativo dell'origine, mentre maxAttemptsTimeout include il tempo necessario per la connessione tra tutti i tentativi di connessione, inclusi failover e reindirizzamenti. Seguendo un reindirizzamento viene conteggiato un ulteriore tentativo di connessione all'origine e viene conteggiato ai fini del calcolo di maxAttempts impostato per l'origine configurata.

    Quando Media CDN rileva una risposta senza reindirizzamenti, ad esempio da un'origine di reindirizzamento o failover, si applicano 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 determinato che utilizzerà una risposta upstream, né connectTimeout né maxAttemptsTimeout. A questo punto, readTimeout e responseTimeout entrano in vigore.

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

Nella tabella seguente vengono descritti i campi relativi al timeout:

Campo Predefinita Descrizione
connectTimeout 5 secondi

La quantità massima di tempo Media CDN può richiedere 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 l'esecuzione delle ricerche DNS, quindi l'esecuzione degli handshake TLS, la creazione della connessione TCP/QUIC e il recupero delle intestazioni delle risposte 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 di tutti i tentativi di connessione all'origine, incluse le origini di failover, al fine di limitare il tempo totale che i client devono attendere prima che il contenuto inizi l'avvio del flusso di dati. 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 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 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 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 di failover_origin pari a Origin B. Il valore predefinito di connectTimeout è 5s. Se tenti di connetterti a Origin A, ma non riesce entro 1 secondo a causa di un certificato TLS non valido, hai circa 4 secondi rimanenti per stabilire una connessione a Origin B.

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

Riprova richieste di origine

Media CDN supporta i nuovi tentativi dell'origine, consentendo di ritentare le richieste non riuscite all'origine. Puoi specificare il numero di nuovi tentativi dell'origine attuale 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 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 all'utente. Ciò include eventuali connessioni con origini 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 elemento 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 Predefinita Descrizione
CONNECT_FAILURE ✔️ Riprova in caso di errori, tra cui errori di routing, handshake DNS e TLS e 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 i codici di stato 4xx 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 reindirizzamento round-robin o di reindirizzamento sensibile al 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 osservata da un client:

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 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 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 successive richieste di origine di nuovo e failover continuano a non riuscire, al client viene restituito un errore HTTP 502 Bad Gateway dopo l'esaurimento dei tentativi dell'origine.

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 delle intestazioni Vary, ETag e Last-Modified siano coerenti tra le origini.

Come best practice, configura il reindirizzamento delle origini solo per le origini che ritieni attendibili e controllate. Assicurati di considerare attendibile ogni origine in una catena di reindirizzamento, perché ognuna produce contenuti pubblicati da EdgeCacheService.

Passaggi successivi