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
oderETag
(ein Validator). - Einen gültiger HTTP-
Date
-Header. - Einen gültigen
Content-Length
-Header. - Der
Content-Range
-Antwortheader als Antwort auf eineRange GET
-Anfrage. Der HeaderContent-Range
muss einen gültigen Wert im Formatbytes x-y/z
haben (wobeiz
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:
- 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 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:
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 für die Anfrage zum Ausführen des Ursprungsservers verwendet, was 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) oderHTTPS
(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 Port443
für HTTPS und HTTP/2.
Ursprüngliche Anfrageheader
Beim Herstellen einer Verbindung zu einem Ursprung verwendet Media CDN den Header Host
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
undmaxAttemptsTimeout
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ährendmaxAttemptsTimeout
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 festgelegtenmaxAttempts
angerechnet.Wenn Media CDN auf eine Antwort ohne Weiterleitung stößt, z. B. von einem Weiterleitungs- oder Failover-Ursprung stammen,
readTimeout
responseTimeout
gelten. Weitergeleitete Ursprünge verwenden die WerteconnectTimeout
,readTimeout
undresponseTimeout
, die für denEdgeCacheOrigin
konfiguriert sind, der auf die Weiterleitung gestoßen ist.Mit
responseTimeout
undreadTimeout
wird gesteuert, wie lange eine gestreamte Antwort dauern darf nehmen. Nachdem Media CDN feststellt, dass eine vorgelagerte Antwort verwendet wird, sind wederconnectTimeout
nochmaxAttemptsTimeout
relevant. Ab diesem Zeitpunkt tretenreadTimeout
undresponseTimeout
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 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 |
readTimeout | 15 Sekunden | Die maximale Wartezeit zwischen Lesevorgängen einer einzelnen HTTP-Antwort.
Das |
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 einemaxAttemptsTimeout
-Wert von5s
,maxAttempts
-Wert von1
undfailover_origin
-Wert vonOrigin B
. DerconnectTimeout
-Wert hat seinen Standardwert5s
. Wenn Sie versuchen, eine Verbindung zuOrigin A
herzustellen, und dies innerhalb von 1 fehlschlägt aufgrund eines ungültigen TLS-Zertifikats können Sie noch etwa 4 Sekunden Verbindung zuOrigin B
erfolgreich hergestellt.„
Origin C
“ gleicht Anfragen mit „/manifests/*“ ab und hat einenmaxAttemptsTimeout
-Wert10s
, einmaxAttempts
-Wert von3
undfailover_origin
nicht konfiguriert. Die DerconnectTimeout
-Wert ist auf den Standardwert5s
gesetzt. Media CDN versucht bis zu dreimal, eine Verbindung mitOrigin C
herzustellen, was bis zu 10 Sekunden dauern kann (das Limit vonmaxAttemptsTimeout
), um eine erfolgreiche Verbindung herzustellen.
Ursprungsanfragen wiederholen
Media CDN unterstützt Ursprungswiederholungen, was fehlgeschlagene an den Ursprung zu wiederholen. 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
konfigurierter Wert für
maxAttempts
, der standardmäßig auf1
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 optionalenfailoverOrigin
-Wert. DiefailoverOrigin
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
- Ursprung konfigurieren
- Privaten Amazon S3-kompatiblen Bucket als Ursprung verwenden
- Dienstrouten konfigurieren