Diese Seite wurde von der Cloud Translation API übersetzt.

Quellen – Übersicht

Mit Media CDN können Sie Inhalte aus Ihrer Ursprungsinfrastruktur abrufen, unabhängig davon, ob sie in Google Cloud, in einer anderen Cloud oder lokal gehostet werden.

Jede Konfiguration kann mit einem oder mehreren Ursprungsquellen verknüpft sein. Ursprungskonfigurationen teilen Media CDN mit, wie eine Verbindung zu Ihrer Infrastruktur hergestellt wird, wann und wie ein Failover, ein Wiederholungsversuch und eine Zeitüberschreitung ausgeführt wird und welches Protokoll für die Herstellung der Verbindung verwendet wird.

Ursprünge haben folgende Funktionen:

Ursprünge können pro Host und pro Route definiert werden, sodass eine einzelne EdgeCacheService-Ressource mehreren Ursprüngen zugeordnet werden kann, die beispielsweise Manifeste, Videosegmente und andere statische Inhalte enthalten.
Ursprünge können über HTTP/2, HTTPS und unverschlüsseltes HTTP/1.1 erreicht werden.
Verhaltensweisen bei Wiederholungsversuchen und Failover sind pro Ursprung konfiguriert und erlauben es dem Dienst möglicherweise, ein Failover für schwerwiegende Fehler (z. B. Verbindungsfehler) oder einen Wiederholungsversuch basierend auf HTTP-404 Not Found- oder HTTP-429 Too Many Requests-Antworten durchzuführen.
Private Ressourcen, sowohl lokale als auch solche innerhalb von Google Cloud, können durch die Konfiguration eines externen Application Load Balancers als Ursprung hinter Media CDN erreicht werden.
Das Verhalten für das Folgen von Weiterleitungen wird pro Ursprung konfiguriert. Sie können es Media CDN ermöglichen, Weiterleitungen zu anderen Ursprungsservern zu folgen.

Anforderungen an den Ursprung

Damit Media CDN Ursprungsantworten mit einer Größe von mehr als 1 MiB im Cache speichern kann, muss ein Ursprung in den Antwortheadern für HEAD- und GET-Anfragen Folgendes enthalten, sofern nicht anders angegeben:

Einen Last-Modified- oder ETag-HTTP-Antwortheader (Validator).
Einen gültiger HTTP-Date-Header.
Einen gültigen Content-Length-Header.
Den Content-Range-Antwortheader als Antwort auf eine Range GET-Anfrage. Der Header Content-Range muss einen gültigen Wert im Format bytes x-y/z haben (wobei z die Objektgröße ist).

Das Standardprotokoll für den Ursprung ist HTTP/2. Wenn Ihre Ursprünge nur HTTP/1.1 unterstützen, können Sie das Protokollfeld für jeden Ursprung explizit festlegen.

Ursprungsabschirmung

Media CDN bietet eine deutlich abgestufte Edge-Infrastruktur, die so konzipiert ist, dass die Cache-Füllung wenn möglich aktiv minimiert wird.

Es gibt drei Hauptebenen der Caching-Infrastruktur:

Deep Edge-Caches, die den Großteil des Traffics und der Auslagerung innerhalb eines Dienstanbieternetzwerks bereitstellen.
Das Peering-Edge von Google, das mit Tausenden von Internetanbietern verbunden ist und als Cache der mittleren Ebene für Edge-Caches fungiert. Für Fälle, in denen diese nicht innerhalb eines bestimmten ISP vorhanden sind, fungiert es als nutzerseitiger Cache.
Longtail-Caches innerhalb des Google-Netzwerks, die von anderen nachgelagerten Caches vor dem Ursprung gefüllt werden. Diese Caches unterstützen erhebliches Fan-In, verfügen über eine umfangreiche Cache-Speicherkapazität und fungieren als Ursprungs-Schild.

Hier ist eine Übersicht dieser Topologie zu sehen:

Topologieübersicht (zum Vergrößern anklicken)

Alle Cacheebenen unterstützen die Anfragenminimierung (oder Konsolidierung), um die Ursprungslast weiter zu reduzieren. Basierend auf beobachteten, realen Arbeitslasten in großem Maßstab:

Bei mehr als 95% der Cache-Füllung wird ein spezieller Longtail-Cacheknoten innerhalb der Region verwendet, um die Kosten und die Latenz der Cache-Füllung zu reduzieren.
Die Cache-Füllung zwischen dem Ursprung und der eigenen Edge-Infrastruktur von Google erfolgt vollständig über das globale private Backbone-Netzwerk von Google. Dies reduziert die Latenz bei der Cache-Füllung und verbessert die Zuverlässigkeit. Beides sind aktive Vorteile für Livestreaming-Arbeitslasten.
Caches füllen sich gegenseitig, wenn dies vorteilhaft ist, wodurch die Cache-Füllungsraten weiter reduziert werden.
Media CDN verfügt über eine erhebliche Speicherkapazität über Caches hinweg, die die Entfernungsraten auch für Longtail-Inhalte minimiert, die weniger beliebt sind.

Bei Kunden treten möglicherweise unterschiedliche Auslagerungsraten auf, abhängig von ihrer Cache-Konfiguration, der Nutzerlast, den Arbeitslasten (z. B. Live vs. On-Demand), der Nutzerverteilung und der Menge an Longtail-Inhalten (Gesamtkorpusgröße), die sie Nutzern über Regionen hinweg bereitstellen.

Anfrageminimierung

Die Anfrageminimierung minimiert aktiv mehrere nutzergesteuerte Cache-Füllungsanfragen für denselben Cache-Schlüssel in einer einzigen Ursprungsanfrage pro Edge-Knoten.

In Kombination mit der Ursprungsabschirmung reduziert dies die Anforderungen an die Ursprungslast und die Bandbreite des ausgehenden Traffics weiter und stellt das Standardverhalten für Media CDN dar.

Bei minimierten Anfragen werden sowohl die clientseitige Anfrage als auch die (minimierte) Cache-Füllungsanfrage protokolliert. Der Leader der minimierten Sitzung wird zum Erstellen der Füllanfrage für den Ursprung verwendet, was bedeutet, dass der Ursprung nur die Header (einschließlich des User-Agents) dieses Clients sieht.

Anfragen, die nicht denselben Cache-Schlüssel teilen, können nicht minimiert werden.

Ursprungskonnektivität

In den folgenden Abschnitten wird beschrieben, wie Media CDN eine Verbindung zu Ursprüngen herstellt, wie HTTP-Anfragen gesendet werden und wie Sie Anfragen authentifizieren können.

Unterstützte Ursprünge und Protokolle

Media CDN unterstützt alle öffentlich erreichbaren HTTP-Endpunkte direkt als Ursprung, darunter:

Cloud Storage-Buckets, einschließlich privater Buckets, über Identity and Access Management-Dienstkonten
Externe Application Load Balancer
Amazon S3-kompatible Buckets, einschließlich privater Buckets, die AWS Signature Version 4 verwenden
Andere öffentlich verfügbare Objektspeicher, z. B. Azure Blob Storage
Öffentlich verfügbare Webserver, z. B. öffentliche VMs oder lokale Hosts

Die Verbindung zu Ursprüngen erfolgt über sichere Tunnel und das globale Backbone-Netzwerk von Google.

In der folgenden Tabelle sind die unterstützten Ursprungsprotokolle aufgeführt.

Protokoll	Unterstützt	SSL (TLS) erforderlich
HTTP/2	Ja (Standardeinstellung)	Ja
HTTPS (HTTP/1.1 über TLS)	Ja	Ja
HTTP/1.1	Ja	Nein

Media CDN verwendet standardmäßig HTTP/2 (h2), um eine Verbindung zu einem Ursprung herzustellen. HTTP/2 und HTTPS erfordern ein gültiges, öffentlich vertrauenswürdiges TLS-(SSL-)Zertifikat. Ein gültiges Zertifikat ist ein Zertifikat, das nicht abgelaufen ist, von einer öffentlichen Zertifizierungsstelle signiert wurde und einen alternativen Antragstellernamen hat, der mit dem an den Ursprung gesendeten Hostnamen übereinstimmt.

Hinweise:

Wenn Ihr Ursprung HTTP/2 nicht unterstützt, können Sie das Protokoll (pro Ursprung) explizit auf HTTP (HTTP/1.1) oder HTTPS (HTTP/1.1 über TLS) festlegen.
Beim Konfigurieren von HTTPS oder HTTP/1.1 als Ursprungsprotokoll handelt Media CDN kein alternatives Protokoll (wie HTTP/2) aus. Gleichermaßen führt die Verbindung beim Konfigurieren von HTTP/2 kein Fallback auf HTTP/1.1 aus, um das Verhalten der Ursprungskonnektivität explizit zu machen.
Media CDN verwendet automatisch den richtigen Port basierend auf dem Protokoll: Port 80 für HTTP oder Port 443 für HTTPS und HTTP/2.

Ursprungsanfrageheader

Wenn eine Verbindung zu einem Ursprung hergestellt wird, verwendet Media CDN standardmäßig den Host-Header aus der Clientanfrage.

In der folgenden Tabelle wird beschrieben, was der Ursprung in verschiedenen Konfigurationsszenarien in der eingehenden Anfrage sieht:

Clientanfrage	`EdgeCacheService.hostRewrite`	`EdgeCacheOrigin.hostRewrite`	originAddress	Host-Header / TLS SNI am Ursprung
media.example.com	–	–	backend.example.com	media.example.com
media.example.com	service.example.com	–	backend.example.com	service.example.com
media.example.com	–	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	wird automatisch anhand des Bucket-Namens festgelegt

Der primäre Ursprung und alle Failover-Ursprünge sehen denselben Host-Header, wenn sie dieselbe routeRule- oder hostRewrite-Konfiguration verwenden.

Alle hostRewrite-Einstellungen werden ignoriert, wenn ein Cloud Storage-Bucket als Ursprung verwendet wird, da alternative Hostheaderwerte von Cloud Storage-Buckets nicht unterstützt werden. Der Hostheader wird automatisch anhand des Bucket-Namens festgelegt.

Der Wert für TLS SNI (Server Name Indication) in der Anfrage (für HTTP/3-, HTTP/2- und HTTPS-Anfragen) wird auf den gleichen Wert wie der Host-Header gesetzt, der an den Ursprung gesendet wird.

Informationen zum Neuschreiben von Host-Headern für die routenspezifische Konfiguration finden Sie unter Dienstrouten konfigurieren. Informationen zum Festlegen von Überschreibungsaktionen pro Ursprung finden Sie unter Ursprungs-Failover ohne Weiterleitung.

Failover und Zeitlimits

In den folgenden Abschnitten werden diese Konfigurationsoptionen beschrieben:

Zeitlimits: Legen Sie fest, wie lange Media CDN wartet, bis es eine Verbindung zu Ihrem Ursprung herstellt wird oder bis es eine Anfrage beantwortet.
Wiederholungsversuche: Legen Sie fest, ob Media CDN eine Ursprungs-HTTP-Anfrage an Ihren Ursprung wiederholt und unter welchen Bedingungen.
Failover: Legen Sie fest, ob Media CDN versucht, eine Verbindung zu einem Failover-Ursprung herzustellen, wenn der erste nicht verfügbar ist oder einen bestimmten Statuscode zurückgibt.

Zeitlimits für den Ursprung

Mit Zeitlimits können Sie konfigurieren, wann das Wiederholungs- und Failover-Verhalten des Ursprungs ausgelöst wird und wann ein nachfolgendes Client-Failover ausgelöst werden kann.

Im Folgenden werden die konfigurierbaren Zeitlimits beschrieben, die von Media CDN unterstützt werden:

Mit connectTimeout und maxAttemptsTimeout wird begrenzt, wie lange es dauert, bis Media CDN eine verwendbare Antwort findet.

Beide Zeitüberschreitungen umfassen die Zeit, die der Ursprung benötigt, um Header zurückzugeben und zu bestimmen, ob ein Failover oder eine Weiterleitung verwendet werden soll. connectTimeout gilt unabhängig für jeden Ursprungsversuch, während maxAttemptsTimeout die Zeit einschließt, die für die Verbindung bei allen Ursprungsversuchen erforderlich ist, einschließlich Failovers und Weiterleitungen. Das Folgen einer Weiterleitung zählt als zusätzlicher Versuch, eine Verbindung zum Ursprung herzustellen, und wird auf die für den konfigurierten Ursprung festgelegten maxAttempts angerechnet.

Wenn Media CDN auf eine Antwort ohne Weiterleitung stößt, z. B. von einem Weiterleitungs- oder Failover-Ursprung, gelten die Werte readTimeout und responseTimeout. Weitergeleitete Ursprünge verwenden die Werte connectTimeout, readTimeout und responseTimeout, die für den EdgeCacheOrigin konfiguriert sind, der auf die Weiterleitung gestoßen ist.
Mit responseTimeout und readTimeout wird gesteuert, wie lange eine gestreamte Antwort dauern darf. Nachdem Media CDN feststellt, dass eine vorgelagerte Antwort verwendet wird, sind weder connectTimeout noch maxAttemptsTimeout relevant. An diesem Punkt werden readTimeout und responseTimeout wirksam.

Media CDN führt maximal vier Ursprungsversuche über alle Ursprünge hinweg aus, unabhängig von den von jedem EdgeCacheOrigin festgelegten maxAttempts. Media CDN verwendet den maxAttemptsTimeout-Wert aus dem primären EdgeCacheOrigin. Die Zeitlimitwerte pro Versuch (connectTimeout, readTimeout und responseTimeout) werden für den EdgeCacheOrigin jedes Versuchs konfiguriert.

In der folgenden Tabelle werden die Zeitlimitfelder beschrieben:

Feld	Standard	Beschreibung
connectTimeout	5 Sekunden	Der maximale Zeitraum, den Media CDN ab dem Starten der Anfrage an den Ursprung benötigen darf, bis Media CDN bestimmt, ob die Antwort verwendbar ist. In der Praxis deckt `connectTimeout` den Zeitraum ab, der mit dem Erstellen der Anfrage beginnt und in der Folge das Ausführen von DNS-Lookups und TLS-Handshakes, das Herstellen einer TCP/QUIC-Verbindung und schließlich das Abrufen der Antwortheader umfasst, die den HTTP-Statuscode enthalten. Das Zeitlimit muss ein Wert zwischen 1 Sekunde und 15 Sekunden sein.
maxAttemptsTimeout	15 Sekunden	Die maximale Zeit für alle Verbindungsversuche zum Ursprung, einschließlich Failover-Ursprünge, bevor ein Fehler an den Client zurückgegeben wird. Wenn das Zeitlimit erreicht ist, bevor eine Antwort zurückgegeben wird, wird ein HTTP 504 zurückgegeben. Das Zeitlimit muss ein Wert zwischen 1 Sekunde und 30 Sekunden sein. Diese Einstellung definiert die Gesamtdauer für alle Ursprungsverbindungsversuche, einschließlich Failover-Ursprünge, um die Gesamtzeit zu begrenzen, die Clients warten müssen, bis das Streamen von Inhalten startet. Es wird nur der erste `maxAttemptsTimeout`-Wert verwendet, wobei der erste durch den für die angegebene Route konfigurierten Ursprung definiert wird.
readTimeout	15 Sekunden	Die maximale Wartezeit zwischen Lesevorgängen einer einzelnen HTTP-Antwort. Das `readTimeout` wird durch das `responseTimeout` begrenzt. Alle Lesevorgänge der HTTP-Antwort müssen innerhalb der durch das `responseTimeout` festgelegten Frist abgeschlossen werden. Das Zeitlimit muss ein Wert zwischen 1 Sekunde und 30 Sekunden sein. Wenn dieses Zeitlimit erreicht wird, bevor die Antwort vollständig ist, wird sie abgeschnitten und protokolliert.
responseTimeout	30 Sekunden	Die maximale Dauer, bis eine Antwort abgeschlossen sein muss. Das Zeitlimit muss ein Wert zwischen 1 Sekunde und 120 Sekunden sein. Die Dauer wird ab dem Zeitpunkt gemessen, an dem die ersten Body-Bytes empfangen werden. Wenn dieses Zeitlimit erreicht wird, bevor die Antwort vollständig ist, wird sie abgeschnitten und protokolliert.

Betrachten Sie hierzu folgende Beispiele:

Origin A stimmt Anfragen mit „/segments/“ ab und hat einen maxAttemptsTimeout-Wert von 5s, einen maxAttempts-Wert von 1 und einen failover_origin-Wert von Origin B. Der Wert für connectTimeout ist der Standardwert 5s. Wenn Sie versuchen, eine Verbindung zu Origin A herzustellen, und diese innerhalb von einer Sekunde aufgrund eines ungültigen TLS-Zertifikats fehlschlägt, haben Sie noch ~4 Sekunden, um eine erfolgreiche Verbindung zu Origin B herzustellen.
Origin C stimmt Anfragen mit „/manifests/*“ ab, hat einen maxAttemptsTimeout-Wert von 10s, einen maxAttempts-Wert von 3 und failover_origin ist nicht konfiguriert. Der Wert für connectTimeout ist auf den Standardwert 5s festgelegt. Media CDN versucht, bis zu dreimal eine Verbindung zu Origin C herzustellen, wobei bis zu 10 Sekunden (maxAttemptsTimeout-Limit) zulässig sind, um eine erfolgreiche Verbindung herzustellen.

Ursprüngliche Anfragen wiederholen

Media CDN unterstützt Ursprungs-Wiederholungsversuche, sodass fehlgeschlagene Anfragen an den Ursprung wiederholt werden können. Sie können angeben, wie oft für den aktuellen Ursprung Wiederholungsversuche ausgeführt werden können, bevor ein Failover-Ursprung (falls konfiguriert) versucht wird.

Media CDN versucht, den primären Ursprung bis zum konfigurierten maxAttempts-Wert zu erreichen, der standardmäßig auf 1 gesetzt ist.
Media CDN wiederholt Ursprungsverbindungen bis zu dreimal, bevor der Prozess fehlschlägt und ein HTTP-502 Bad Gateway-Fehler an den Nutzer zurückgegeben wird. Dazu gehören auch Failover-Ursprungsverbindungen, die auf das Limit von drei angerechnet werden.
Wenn Sie eine Ursprungsressource konfigurieren, können Sie einen primären Ursprung mit dem Feld originAddress und dann optional failoverOrigin konfigurieren. Die failoverOrigin verweist auf eine andere Ursprungsressource.

Die retryConditions für jeden Ursprung geben an, welche Fehlerarten eine Wiederholung auslösen:

Bedingung	Standard	Beschreibung
CONNECT_FAILURE	✔️	Zu Wiederholungsversuchen bei Fehlern gehören Routing-, DNS- und TLS-Handshakefehler sowie TCP/UDP-Zeitüberschreitungen.
HTTP_5XX		Wiederholung bei jedem HTTP-Statuscode `5xx`.
GATEWAY_ERROR		Ähnlich wie `5xx`, gilt aber nur für die Statuscodes `502`, `503` oder `504`.
RETRIABLE_4XX		Wiederholen Sie den Vorgang bei `4xx`-Statuscodes, die wiederholt werden können, einschließlich `409` und `429`.
NOT_FOUND		Wiederholung bei einem HTTP-Statuscode `404`.
FORBIDDEN		Wiederholung bei einem HTTP-Statuscode `403`.

Wenn Sie eine aktive Systemdiagnose, Round Robin- oder lastenabhängiges Steuern über Ursprünge hinweg benötigen, können Sie einen externen Application Load Balancer als primären Ursprung konfigurieren.

Failover-Verhalten

In der folgenden Tabelle wird beschrieben, wie der Failover funktioniert und welche Antwort ein Client sehen würde:

Szenario	Failover konfiguriert	Für Nutzer sichtbarer Status
Media CDN versucht, eine Verbindung zu Ihrem Ursprung herzustellen, und erhält nach zwei Versuchen (standardmäßig) keine HTTP-Antwort.	Nein	HTTP `502 Bad Gateway`
Media CDN versucht, eine Verbindung zu Ihrem primären Ursprung herzustellen, und schlägt fehl (TLS-Handshakefehler). Es wird versucht, Ihren konfigurierten Failover-Ursprung zu erreichen, der einen HTTP-`404`-Fehler zurückgibt.	Ja	HTTP `404 Not Found`
Media CDN versucht, eine Verbindung sowohl zu Ihrem primären als auch zu Ihrem Failover-Ursprung herzustellen, erhält jedoch keinen HTTP-Statuscode.	Ja	HTTP `502 Bad Gateway`

Wenn Media CDN einen Statuscode empfängt, der mit einer konfigurierten retryConditions übereinstimmt, z. B. einen HTTP-404 Not Found- oder HTTP-429 Too Many Requests-Fehler, und nachfolgende Wiederholungs- und Failover-Ursprungsanfragen weiterhin fehlschlagen, wird dem Client nach dem Ausschöpfen der Ursprungsversuche ein HTTP-502 Bad Gateway-Fehler zurückgegeben.

Best Practices für das Failover der Quelle

Achten Sie beim Konfigurieren mehrerer Ursprünge für das Failover oder Load-Balancing darauf, dass das Verhalten Ihrer Medieninhalte und der Vary-, ETag- und Last-Modified-Header zwischen Ihren Ursprüngen konsistent ist.

Es empfiehlt sich, die Weiterleitung von Ursprüngen nur für vertrauenswürdige und von Ihnen kontrollierte Ursprünge zu konfigurieren. Sie müssen allen Ursprüngen in einer Weiterleitungskette vertrauen, da jeder Ursprung Inhalte generiert, die von Ihrem EdgeCacheService ausgeliefert werden.