Ursprünge

Mit Media CDN können Sie Inhalte von Ihrem Ursprung abrufen ob Inhalte in Google Cloud, in einem anderen in der Cloud oder lokal.

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 Merkmale:

  • Die Startorte können pro Host und pro Route definiert werden, sodass ein einzelner Ressource EdgeCacheService, die mehreren Ursprüngen zugeordnet werden soll die zum Beispiel Manifeste, Videosegmente und andere statische Inhalte.
  • 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 in Google Cloud oder lokal sind erreichbar indem Sie einen externen Application Load Balancer als hinter Media CDN.
  • 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 im Cache speichern kann, die größer sind als 1 MiB hat, muss ein Ursprung Folgendes in den Antwortheadern für HEAD- und GET-Anfragen, 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 im Google-Netzwerk, die von anderen nachgelagerten Caches gefüllt werden vor dem Ursprung liegen. Diese Caches unterstützen erhebliches Fan-In, haben eine erhebliche Cache-Speicherkapazität bieten und als Ursprungsschild dienen.

Eine Übersicht über diese Topologie finden Sie hier:

<ph type="x-smartling-placeholder">
</ph> Topologieübersicht.
Topologieübersicht (zum Vergrößern klicken)

Alle Ebenen der Caching-Supportanfrage 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

Durch das Minimieren der Anfrage werden mehrere nutzergesteuerte Cache-Füllanfragen für denselben Cache-Schlüssel in einer einzigen Ursprungsanfrage pro Edge-Knotens.

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 verwenden, 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
  • 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) für die Verbindung zu einem Ursprung. HTTP/2 und HTTPS erfordern ein gültiges, öffentlich vertrauenswürdiges TLS-(SSL-)Zertifikat. A Ein gültiges Zertifikat ist ein Zertifikat, das nicht abgelaufen ist und von einem öffentlichen Zertifikat signiert wurde und hat einen alternativen Antragstellernamen, der dem Hostnamen entspricht, der an den „origin“.

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.

Ursprüngliche Anfrageheader

Beim Herstellen einer Verbindung zu einem Ursprung verwendet Media CDN den Header Host standardmäßig aus der Clientanfrage.

In der folgenden Tabelle wird dokumentiert, was der Ursprung in der eingehenden Anfrage sieht unter verschiedene Konfigurationsszenarien:

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 Host-Header wird automatisch anhand der den Bucket-Namen.

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 Konfigurieren Sie Dienstrouten. Weitere Informationen zum Überschreibungsaktionen pro Ursprung finden Sie unter Ursprungs-Failover ohne folgende 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.

Ursprungszeitüberschreitungen

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 Media CDN unterstützt:

  • connectTimeout und maxAttemptsTimeout begrenzen die Dauer des Media CDN um eine brauchbare Antwort zu finden.

    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 Wert maxAttemptsTimeout 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 diese Zeitüberschreitung erreicht wird, bevor die Antwort abgeschlossen ist, Antwort wird abgeschnitten und protokolliert.

Betrachten Sie hierzu folgende Beispiele:

  • Origin A ordnet Anfragen mit „/segments/“ zu und hat eine maxAttemptsTimeout-Wert von 5s, maxAttempts-Wert von 1 und failover_origin-Wert von Origin B. Der connectTimeout-Wert hat seinen Standardwert 5s. Wenn Sie versuchen, eine Verbindung zu Origin A herzustellen, und dies innerhalb von 1 fehlschlägt aufgrund eines ungültigen TLS-Zertifikats können Sie noch etwa 4 Sekunden Verbindung zu Origin B erfolgreich hergestellt.

  • „Origin C“ gleicht Anfragen mit „/manifests/*“ ab und hat einen maxAttemptsTimeout-Wert 10s, ein maxAttempts-Wert von 3 und failover_origin nicht konfiguriert. Die Der connectTimeout-Wert ist auf den Standardwert 5s gesetzt. Media CDN versucht bis zu dreimal, eine Verbindung mit Origin C herzustellen, was bis zu 10 Sekunden dauern kann (das Limit von maxAttemptsTimeout), um eine erfolgreiche Verbindung herzustellen.

Ursprungsanfragen wiederholen

Media CDN unterstützt Ursprungswiederholungen, was fehlgeschlagene an den Ursprung. 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 zu der konfigurierter Wert für maxAttempts, der standardmäßig auf 1 festgelegt ist.
  • Media CDN wiederholt Ursprungsverbindungen bis zu drei Mal vor dem Fehlschlagen und der Rückgabe des HTTP-Fehlers 502 Bad Gateway an den Nutzer. Dazu gehören alle Failover-Ursprungsverbindungen, die auf das Limit von drei zu überschreiten.
  • Beim Konfigurieren einer Ursprungsressource können Sie einen primären Ursprung konfigurieren, indem Sie mithilfe des Felds originAddress und dann einem optionalen failoverOrigin-Wert. 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 Versuchen Sie es noch einmal mit einem HTTP-Statuscode 404.
FORBIDDEN Versuchen Sie es noch einmal mit 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 kann keine Verbindung herstellen (TLS-Handshake-Fehler). 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 Ursprungsweiterleitung als Best Practice nur für Ursprünge, denen Sie vertrauen und Kontrolle. Achten Sie darauf, dass Sie jedem Ursprung in einer Weiterleitungskette vertrauen. Jeder Ursprung erzeugt Inhalte, die von Ihrer EdgeCacheService bereitgestellt werden.

Nächste Schritte