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.

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 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.
  • Wiederholungsversuche und Failover-Verhaltensweisen werden pro Ursprung konfiguriert und können Der Dienst führt bei schwerwiegenden Fehlern (wie Verbindungsfehlern) ein Failover oder einen neuen Versuch durch. basierend auf HTTP-404 Not Found- oder HTTP-429 Too Many Requests-Antworten.
  • 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 HTTP-Antwortheader Last-Modified oder ETag (ein Validator).
  • Einen gültiger HTTP-Date-Header.
  • Einen gültigen Content-Length-Header.
  • Der 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 standardmäßige Ursprungsprotokoll ist HTTP/2. Wenn Ihre Quellen 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 erhebliche Cache-Speicherkapazität bieten und als Ursprungsschild dienen.

Hier ist eine Übersicht dieser Topologie zu sehen:

Topologieübersicht
Topologieübersicht (zum Vergrößern klicken)

Alle Ebenen der Caching-Unterstützung werden minimiert (oder zusammengefasst), um die Unterstützung weiter zu verbessern. die Ursprungslast zu reduzieren. Basierend auf beobachteten, realen Arbeitslasten in großem Maßstab:

  • > 95% der Cache-Füllung nutzt einen dedizierten Long-Tail-Cache-Knoten innerhalb um die Kosten für die Cache-Füllung und die Latenz 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 beträchtliche Speicherkapazität bei Caches gespeichert, wodurch die Bereinigungsraten auch bei Longtail- und weniger beliebten Inhalte.

Kunden können je nach Cache unterschiedliche Auslagerungsraten sehen Konfiguration, Nutzerlast, Arbeitslasten (z. B. Live oder On-Demand), Nutzer Verteilung und wie viel Longtail-Inhalte (Gesamtkorpusgröße) sie liefern, für Nutzer in verschiedenen Regionen.

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 wird dadurch Bandbreite für den Ursprungs- und ausgehenden Traffic und ist das Standardverhalten für Media CDN.

Bei minimierten Anfragen werden sowohl die clientseitige Anfrage als auch die (minimierte) Cache-Füllungsanfrage protokolliert. Der Leader der minimierten Sitzung ist die für die Anfrage zum Ausfüllen des Ursprungsservers verwendet wurde. Dies bedeutet, dass der Ursprung die nur der Header (einschließlich User-Agent) dieses Clients.

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 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 bis Dienstkonten für Identity and Access Management
  • Externe Application Load Balancer
  • Mit Amazon S3 kompatible Buckets, einschließlich privaten Buckets mit AWS Signature Version 4
  • Andere öffentlich zugängliche 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) für die Verbindung zu einem Ursprung. 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 explizit festlegen (pro Ursprung) zu HTTP (HTTP/1.1) oder HTTPS (HTTP/1.1 über TLS).
  • Beim Konfigurieren von HTTPS oder HTTP/1.1 als Ursprungsprotokoll handelt Media CDN kein alternatives Protokoll (wie HTTP/2) aus. Ebenso verhält es sich bei der HTTP/2-Konfiguration, Fallback auf HTTP/1.1, um die Ursprungsverbindung explizit anzugeben. verhalten.
  • 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

Beim Herstellen einer Verbindung zu einem Ursprung verwendet Media CDN den Header Host 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 bei Verwendung eines Cloud Storage-Elements ignoriert Bucket als Ursprung, da alternative Hostheaderwerte nicht unterstützt werden nach Cloud Storage-Buckets. 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 Umschreiben von Host-Headern für die Konfiguration pro Route 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 Zeitüberschreitungen können Sie konfigurieren, wann der Ursprungswiederholungs- und das Failover-Verhalten 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 Zeitlimits umfassen die Zeit, die der Ursprung benötigt, um Header zurückzugeben und 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 stammen, readTimeoutresponseTimeout gelten. 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 nehmen. Nachdem Media CDN feststellt, dass eine vorgelagerte Antwort verwendet wird, sind weder connectTimeout noch maxAttemptsTimeout relevant. Ab diesem Zeitpunkt 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 diese Zeitüberschreitung erreicht wird, bevor die Antwort abgeschlossen ist, Antwort wird 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 Textbyte erhalten haben. 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. Die Der connectTimeout-Wert ist auf den Standardwert 5s gesetzt. 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.

Ursprungsanfragen wiederholen

Media CDN unterstützt Ursprungs-Wiederholungsversuche, sodass fehlgeschlagene Anfragen an den Ursprung wiederholt werden können. Sie können festlegen, wie oft der Der aktuelle Ursprung kann vor einem Failover-Ursprung wiederholt werden (falls konfiguriert). wird versucht.

  • 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 alle Failover-Ursprungsverbindungen, die auf das Limit von drei zu überschreiten.
  • 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 den Wiederholungsversuchen bei Fehlern zählen Routing-, DNS- und TLS-Handshake-Fehler und TCP/UDP-Zeitüberschreitungen.
HTTP_5XX Versuche es bei einem beliebigen HTTP-5xx-Statuscode noch einmal.
GATEWAY_ERROR Ähnlich wie 5xx, gilt aber nur für Statuscodes 502, 503 oder 504.
RETRIABLE_4XX Versuchen Sie es noch einmal, um 4xx Statuscodes zu erhalten. einschließlich 409 und 429.
NOT_FOUND Wiederholung bei einem HTTP-Statuscode 404.
FORBIDDEN Wiederholen Sie den Vorgang bei einem HTTP-Statuscode 403.

Wenn Sie eine aktive Systemdiagnose, Round-Robin- oder lastbasierte Steuerung benötigen verschiedenen Ursprüngen, können Sie einen externen Application Load Balancer konfigurieren als primären Ursprung festlegen.

Failover-Verhalten

In der folgenden Tabelle wird beschrieben, wie ein Failover funktioniert und welche Antwort ein Client gibt würden Sie Folgendes feststellen:

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, Ihre konfigurierte Failover-Quelle, die einen HTTP-404-Wert zurückgibt Fehler. 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 der konfigurierten retryConditions, wie z. B. der HTTP-Fehler 404 Not Found oder HTTP 429 Too Many Requests, und nachfolgende Wiederholungs- und Failover-Ursprungsanfragen werden weiterhin fehlgeschlagen ist, wird nach dem Ursprung der HTTP-Fehler 502 Bad Gateway an den Client zurückgegeben. sind erschöpft.

Best Practices für das Ursprungs-Failover

Wenn Sie mehrere Ursprünge für Failover oder Load-Balancing konfigurieren, achten Sie darauf, dass Ihre Medieninhalte und das Verhalten der Header Vary, ETag und Last-Modified sind zwischen Ihren Ursprüngen einheitlich sind.

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

Nächste Schritte