Quellen – Übersicht

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

Jeder Konfiguration können ein oder mehrere Ursprünge zugeordnet 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 die folgenden Merkmale:

  • 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.
  • Auf Ursprünge kann über HTTP/2, HTTPS und unverschlüsseltes HTTP/1.1 zugegriffen 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 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 (ein 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 explizit für jeden Ursprung 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 primäre Ebenen der Caching-Infrastruktur:

  1. Deep Edge-Caches, die den Großteil des Traffics und der Auslagerung innerhalb eines Dienstanbieternetzwerks bereitstellen.
  2. 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.
  3. Longtail-Caches innerhalb des Google-Netzwerks, die von anderen nachgelagerten Caches vor dem Ursprung gefüllt werden. Diese Caches unterstützen erhebliches Fan-In, haben eine umfangreiche Cache-Speicherkapazität und fungieren als Ursprungs-Schild.

Hier sehen Sie eine Übersicht über diese Topologie:

Topologieübersicht
Topologieübersicht (zum Vergrößern anklicken).

Media CDN bietet standardmäßig eine Ursprungsabschirmung mit einer begrenzten Anzahl wichtiger globaler Standorte. Die standardmäßige Ursprungsschilderung basiert auf dem Standort des Endnutzers und nicht des Ursprungs. Das funktioniert gut und bietet erhebliche Vorteile beim Offload, wenn sich Endnutzer und Ursprungsserver in derselben Region befinden und wenn globale Ursprungsserver in mehreren Regionen gehostet werden.

Flexibler Schutz

In Szenarien, in denen sich Ihr Ursprung an einem zentralen Ort in einer Region befindet, Ihre Nutzer aber weltweit verteilt sind, ist das standardmäßige Ursprungsschutzverhalten, das auf dem Nutzerstandort basiert, möglicherweise in folgenden Punkten suboptimal:

  • Erhöhte Latenz bei Cache-Fehlern, wenn sich der Standardschildstandort geografisch weit von Ihrem zentralen Ursprungsserver entfernt befindet
  • Reduzierte Ursprungsentlastung durch Verteilung von Cache-Fill-Anfragen auf mehrere globale Standardschildstandorte anstatt Konzentration

Mit dem flexiblen Ursprungsschutz können Sie diese Einschränkungen umgehen, indem Sie eine einzelne, bestimmte geografische Region für den Ursprungsschutz konfigurieren. Diese wird in der Regel in der Nähe Ihres zentralen Ursprungs ausgewählt. Beim flexiblen Shielding werden alle Cache-Füllanfragen über Shield-Caches weitergeleitet, die sich in der konfigurierten Region oder in der Nähe befinden. Dadurch wird die Last auf Ihren Ursprungsserver über diese regional ausgerichteten Caches konsolidiert.

Wenn Sie eine Region für flexiblen Schutz in derselben geografischen Region wie Ihr zentralisierter Ursprung konfigurieren, können Sie Folgendes optimieren:

  • Cache-Trefferquote auf der Shield-Ebene
  • Ursprungs-Offload
  • Latenz bei Cache-Fehlern und nicht cachefähigen Inhalten
  • Leistungsstabilität

Die flexible Abschirmung ist mit jedem in Media CDN konfigurierten Ursprungstyp kompatibel.

Anfrageminimierung

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

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

  • > 95% der Cache-Füllung verwenden einen dedizierten Longtail-Cache-Knoten innerhalb der Region, 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 erhebliche Speicherkapazität über Caches hinweg, die die Entfernungsraten auch für Longtail-Inhalte minimieren, 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.

In Kombination mit der Ursprungsabschirmung reduziert die Minimierung von Anfragen 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 haben, 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 gestellt 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 Dienstkonten für Identity and Access Management
  • Externe Application Load Balancer
  • Amazon S3-kompatible Buckets, einschließlich privater Buckets, die AWS Signature Version 4 verwenden
  • Anderer öffentlich verfügbarer Objektspeicher wie Azure Blob Storage
  • Öffentlich verfügbare Webserver wie ö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 kein HTTP/2 unterstützt, können Sie das Protokoll (auf Ursprungsbasis) 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 ist dokumentiert, was der Ursprung in der eingehenden Anfrage in verschiedenen Konfigurationsszenarien 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 Hostheader-Werte von Cloud Storage-Buckets nicht unterstützt werden. Der Host-Header 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 Folgen von Weiterleitungen.

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.

Ursprungszeitlimits

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 konfigurierbare Zeitlimits beschrieben, die von Media CDN unterstützt werden:

  • connectTimeout und maxAttemptsTimeout begrenzen, wie lange Media CDN benötigt, um eine verwendbare Antwort zu finden.

    Beide Zeitüberschreitungen umfassen die Zeit, die der Ursprung benötigt, um Header zurückzugeben und festzulegen, 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 trifft, 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 kann. Nachdem Media CDN feststellt, dass eine vorgelagerte Antwort verwendet wird, sind weder connectTimeout noch maxAttemptsTimeout relevant. An diesem Punkt treten readTimeout und responseTimeout in Kraft.

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 die Antwort 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 die Antwort 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 connectTimeout-Wert hat den Standardwert von 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 etwa 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 keinen konfigurierten failover_origin. Der Wert von connectTimeout ist auf dem Standardwert 5s. Media CDN versucht, bis zu dreimal eine Verbindung zu Origin C herzustellen, wobei bis zu 10 Sekunden (das maxAttemptsTimeout-Limit) zulässig sind, um eine erfolgreiche Verbindung herzustellen.

Ursprungsanfragen 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 sollen, 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-Fehler 502 Bad Gateway an den Nutzer zurückgegeben wird. Dazu gehören auch alle 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. Der 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 Wiederholung 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 das Failover funktioniert und welche Antwort ein Client erhält:

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, aber die Verbindung schlägt fehl (TLS-Handshake-Fehler). Es wird versucht, Ihren konfigurierten Failover-Ursprung zu erreichen, der einen HTTP-Fehler 404 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 einem konfigurierten retryConditions übereinstimmt, z. B. einen HTTP-Fehler 404 Not Found oder 429 Too Many Requests, und nachfolgende Wiederholungs- und Failover-Ursprungsanfragen weiterhin fehlschlagen, wird nach Erschöpfung der Ursprungsversuche ein HTTP-Fehler 502 Bad Gateway an den Client zurückgegeben.

Best Practices für das Origin-Failover

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.

Als Best Practice sollten Sie die Ursprungsweiterleitung nur für Ursprünge konfigurieren, denen Sie vertrauen und die Sie kontrollieren. Sie müssen jedem Ursprung in einer Weiterleitungskette vertrauen, da jeder Ursprung Inhalte erzeugt, die von Ihrem EdgeCacheService bereitgestellt werden.

Nächste Schritte