Media CDN bietet erweiterte HTTP-Routingfunktionen, mit denen Sie Traffic genau bestimmten Edge-Konfigurationen und Ursprüngen zuordnen können.
Anfragen mit Übereinstimmung
Eine Media CDN-Konfiguration enthält eine Reihe von Routen, die im
Routenplanung
für ein
EdgeCacheService
.
Diese Routen stimmen mit Anfragen mindestens auf der Grundlage eines Hosts überein. Weitere Informationen dazu, wie
zu einem Ursprung geleitet wird, siehe
HostRule
und PathMatcher
.
Für jede Route kann eine eigene CDN-Konfiguration,
Überschreibungen, Weiterleitungen
CORS-Richtlinien, benutzerdefinierte HTTP-Header und Ursprungszuordnung.
Routen können Ursprünge teilen.
Sie können beispielsweise Manifestanfragen an einen bestimmten Ursprung weiterleiten eine kurzlebige Cache-TTL und einen Richtlinie für negatives Caching. Anfragen für Segmente können mithilfe von Header und Suchparameter um bestimmte Manifest-Typen oder Nutzer aufzuschlüsseln.
Das folgende Beispiel zeigt, wie Anfragen weitergeleitet werden, die mit einem bestimmten Header übereinstimmen.
Abfrageparameter und Pfadpräfix für den Host media.example.com
an:
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 10 origin: staging-live-origin matchRules: - prefixMatch: /vod/ headerMatches: - headerName: "x-staging-client" presentMatch: true queryParameterMatches: - name: "live" exactMatch: "yes" routeAction: cdnPolicy: defaultTtl: 5s
Pfadabgleich
Media CDN unterstützt den vollständigen (genauen), Präfix- und Platzhalter-Pfadabgleich. Der Pfadabgleich kann mit einer host-, header- und abfrageparameterbasierten Übereinstimmung kombiniert werden, um detaillierte Anfragenrouting-Regeln zu erstellen.
Es gibt drei Möglichkeiten für den Abgleich mit einem URL-Pfad.
Feld | Beschreibung | Beispiel |
---|---|---|
matchRules[].fullPathMatch
|
Die Bedingung fullPathMatch entspricht dem vollständigen URL-Pfad, der den Abfragestring nicht enthält. Sie müssen gegebenenfalls Schrägstriche angeben.
|
Eine Route mit der Übereinstimmungsregel Ein |
matchRules[].prefixMatch
|
Die Bedingung prefixMatch entspricht dem URL-Pfadpräfix. URLs, die mit demselben String beginnen, werden übereinstimmen.
|
Eine Route mit der Übereinstimmungsregel |
matchRules[].pathTemplateMatch
|
Die Bedingung pathTemplateMatch unterstützt Platzhalteroperatoren, sodass Sie komplexe URL-Muster und Pfadsegmente abgleichen und benannte Variablen zum Umschreiben von URLs erfassen können.
|
Eine Route mit der Übereinstimmungsregel Sowohl Weitere Beispiele finden Sie im Abschnitt Musterabgleich. |
Weitere Einzelheiten finden Sie in der API-Spezifikation für
MatchRule
Wenn Sie beispielsweise alle Anfragen anhand von /stream/
abgleichen möchten, erstellen Sie eine Routingregel ähnlich der folgenden:
name: prod-service routing: hostRules: - hosts: - media.example.com - *.vod.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 matchRules: - prefixMatch: /stream/
In diesem Beispiel wird der abschließende Schrägstrich ausdrücklich in die Übereinstimmungsregel aufgenommen:
- Eine Anfrage an
media.example.com/stream/id/1234/hls/manifest.m3u8
entspricht dieser Route. - Eine Anfrage an
media.example.com/stream-eu/id/4567/hls/manifest.m3u8
entspricht nicht dieser Route.
Im zweiten Fall gibt Media CDN einen HTTP 404
-Fehler zurück, es sei denn, es wurde eine andere Route oder eine Catchall-Route konfiguriert.
Informationen zur Funktionsweise der Rangfolge für Routen mit ähnlichen Präfixen finden Sie im Abschnitt Routenpriorität und -reihenfolge.
Pattern (wildcard) matching
Mit dem Musterabgleich können Sie mehrere Teile einer URL abgleichen, einschließlich Teil-URLs und Suffixe (Dateierweiterungen) unter Verwendung der Platzhaltersyntax.
Sie können auch eine oder mehrere Pfadkomponenten mit benannten Variablen in dem Feld pathTemplateMatch
verknüpfen und dann auf diese Variablen verweisen, wenn Sie die URL in dem Feld pathTemplateRewrite
umschreiben. Auf diese Weise können Sie URL-Komponenten neu anordnen und entfernen, bevor die Anfrage an Ihren Ursprung gesendet wird.
Das folgende Beispiel zeigt, wie Sie zwei verschiedene URL-Suffixe abgleichen können:
# EdgeCacheService.routing.pathMatchers[] routeRules: - priority: 1 description: "Match video segments" matchRules: - pathTemplateMatch: "/**.ts" - pathTemplateMatch: "/**.m4s" origin: prod-video-storage
Die unterstützte Syntax umfasst Folgendes:
Operator | Stimmt überein mit | Beispiel |
---|---|---|
*
|
Entspricht einer einzelnen Pfadkomponente bis zum nächsten Pfadtrennzeichen: /
|
/videos/*/*/*.m4s entspricht /videos/123414/hls/1080p5000_00001.m4s . |
**
|
Entspricht null oder mehr Pfadsegmenten. Falls vorhanden, muss es sich um den letzten Operator handeln. | /**.mpd entspricht /content/123/india/dash/55/manifest.mpd . |
{name} or {name=*}
|
Eine benannte Variable, die einem Pfadsegment entspricht.
Entspricht einer einzelnen Pfadkomponente bis zum nächsten Pfadtrennzeichen: |
/content/{format}/{lang}/{id}/{file}.vtt entspricht /content/hls/en-us/12345/en_193913.vtt und erfasst format="hls" , lang="en-us" , id="12345" und file="en_193913" als Variablen.
|
{name=videos/*}
|
Eine benannte Variable, die mit mehr als einem Pfadsegment übereinstimmt. Die mit videos/* übereinstimmende Pfadkomponente wird als benannte Variable erfasst.
|
/videos/{language=lang/*}/* gleicht /videos/lang/en/video.m4s ab und füllt die Pfadvariable language mit dem Wert lang/en aus.
|
{name=**}
|
Eine benannte Variable, die null oder mehr Pfadsegmenten entspricht. Falls vorhanden, muss es sich um den letzten Operator handeln. |
|
Hinweise:
- Wenn Sie keine URL neu schreiben, verwenden Sie die einfacheren Operatoren
*
und**
. - Wenn Sie zum Erfassen von Pfadkomponenten Variablen verwenden,
nicht durch eine Variable erfasst werden, kann in einer nachfolgenden
pathTemplateRewrite
Ein Beispiel finden Sie im Abschnitt Pfadvariablen erfassen. - Sie können nicht auf Variablen in einem nachfolgenden
pathTemplateRewrite
verweisen, die nicht in derpathTemplateMatch
auf derselben Route vorhanden sind. - Bei Variablen wird die Groß- und Kleinschreibung berücksichtigt, wobei
{FORMAT}
,{forMAT}
und{format}
für verschiedene Variablen und Werte stehen. - Sie können in einer Übereinstimmung bis zu zehn Operatoren (Platzhalter oder Variablen) angeben.
Die Felder
pathTemplateMatch
undpathTemplateRewrite
dürfen 255 Zeichen nicht überschreiten Zeichen.
Beispiel: Übereinstimmung mit einer Dateiendung
Das folgende Beispiel zeigt einen häufigen Anwendungsfall für Platzhalteroperatoren: Abgleich aller Pfadkomponenten bis zu einem Suffix.
In diesem Fall tun Sie Folgendes:
- Rufen Sie Videomanifeste (Playlists) mit der Endung
.m3u8
und.mpd
vom Ursprung des Manifest ab, wobei eine kurze TTL (5 Sekunden) auf diese Antworten angewendet wird, da sie sich regelmäßig ändern. - Rufen Sie Videosegmente mit den Endungen
.ts
und.m4s
vom Ursprungsort des Segments ab, und wenden Sie auf diese Antworten eine längere TTL (1 Tag) an.
Dieser Ansatz wird häufig bei der Verwendung von SSAI- (Server-Side Ad Injection) oder DAI-Diensten (Dynamic Ad Insertion) sowie bei Live-Videos verwendet, bei denen das Manifest alle paar Sekunden aktualisiert wird.
Die folgende Konfiguration zeigt, wie Sie Ihr Media CDN-Routing so konfigurieren, dass es dies unterstützt:
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: # the first route only matches video manifests - priority: 1 matchRules: - pathTemplateMatch: "/**.m3u8" # "**" matches all path segments - pathTemplateMatch: "/**.mpd" origin: manifest-origin routeAction: cdnPolicy: cacheMode: FORCE_CACHE_ALL defaultTtl: 5s # the second route matches video segments, fetches them # from a separate origin server, caching them for a longer # duration (1 day). - priority: 2 matchRules: - pathTemplateMatch: "/**.ts" - pathTemplateMatch: "/**.m4s" origin: segment-origin routeAction: cdnPolicy: cacheMode: FORCE_CACHE_ALL defaultTtl: 86400s
Beispiel: Pfadvariablen erfassen
Im folgenden Beispiel wird gezeigt, wie benannte Variablen zur Beschreibung einer oder mehrerer Pfadkomponenten verwendet werden.
Diese Variablen können in einem pathTemplateRewrite
verwendet werden, um den Pfad vor dem Senden der Anfrage an den Ursprung umzuschreiben oder um einen komplexen selbstbeschreibenden pathTemplateMatch
zu erstellen.
routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 matchRules: # Matches a request of "/us/en/hls/123139139/segments/00001.ts" - pathTemplateMatch: "/{country}/{lang}/{format}/{id}/{file=**}" origin: my-origin routeAction: urlRewrite: # Rewrites to "/123139139/hls/segments/00001.ts" pathTemplateRewrite: "/{id}/{format}/{file}"
Zum Beispiel:
- Jede Variable
{name}
erfasst ein einzelnes Pfadsegment. Ein Pfadsegment besteht aus allen Zeichen zwischen einem/
-Paar (Schrägstriche) in einem URL-Pfad. - Eine
{name=**}
-Variable erfasst alle verbleibenden Pfadsegmente. In diesem Fall entspricht es sowohlsegments/00001.ts
als auchmaster.m3u8
. - Im
pathTemplateRewrite
auf derselben Route verweisen Sie auf einige der Variablen, die Sie impathTemplateMatch
erfasst haben. Sie explizit die Variablen{country}
und{lang}
auslassen, da sie nicht mit den Verzeichnisstruktur am Ursprung.
In diesem Beispiel geschieht Folgendes:
- Eine eingehende Anfrage-URL von
/us/en/hls/123139139/segment_00001.ts
entspricht dempathTemplateMatch
und wird zu/123139139/hls/segment_00001.ts
umgeschrieben, bevor sie an den Ursprung gesendet wird. - Eine eingehende Anfrage-URL von
/us/123139139/master.m3u8
entspricht nicht dempathTemplateMatch
und erhält eine HTTP404 (Not Found)
-Antwort. - Eine eingehende Anfrage-URL von
/br/es/dash/c966cbbe6ae3/subtitle_00001.vtt
entspricht ebenfalls dempathTemplateMatch
und wird zu/c966cbbe6ae3/dash/subtitle_00001.vtt
umgeschrieben, bevor sie an den Ursprung gesendet wird.
Weitere Informationen zur Funktionsweise des Platzhalterabgleichs mit der URL-Umschreibung finden Sie im Abschnitt Umschreibungen.
Hostabgleich
Jeder Dienst kann mehrere Hostnamen abgleichen, wobei jede Gruppe von Hostnamen eine eigene Gruppe von Routen enthält (Pfad-Matcher). Im häufigsten Fall werden alle Hostnamen für einen Dienst einem einzelnen Satz freigegebener Routen mit einer einzelnen Liste von Hosts und einem einzelnen Pfad-Matcher zugeordnet.
name: prod-service routing: hostRules: - hosts: - media.example.com - *.vod.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: # list of routes for the configured hosts - priority: 999 matchRules: - prefixMatch: / origin: DEFAULT_ORIGIN
Für nicht übereinstimmende Hosts wird eine 404
-Standard-HTTP-Seite bereitgestellt. Wenn Sie einen Host akzeptieren möchten, können Sie das Platzhalterzeichen *
als hostRules[].hosts[]
-Eintrag einfügen.
Sie können auch Gruppen von Routen definieren (z. B. nach Land oder Live vs. On demand gruppieren). Da jeder Dienst eine einzelne Sicherheitsrichtlinie hat, empfehlen wir im Allgemeinen einen Dienst für jeden Markt (Geografie) oder jede Arbeitslast, die Sie haben.
Hinweise:
- Hostheader (oder HTTP/2
:authority
) mit einem Port werden implizit mit einem konfigurierten Host abgeglichen. Sie müssen nicht explizit angeben, Ports. - Wenn die Anfrage über HTTP erfolgt, entspricht ein
hostRules[].hosts[]
-Eintrag von*.vod.example.com
den Wertenus.vod.example.com
undus.vod.example.com:80
. - Wenn die Anfrage über HTTPS (TLS) erfolgt, entspricht ein
hostRules[].hosts[]
-Eintrag von*.vod.example.com
dem Wertus.vod.example.com:443
.
Weitere Einzelheiten finden Sie in der API-Spezifikation für
HostRule
Abgleich mit Headern und Abfrageparametern
Sie können Routen so konfigurieren, dass sie auf bestimmte Header- und Abfrageparameternamen sowie auf das Vorhandensein eines Headerwerts (Präfix, Suffix oder exakte Übereinstimmung) abgeglichen werden.
Der Abgleich von Abfrageparametern und Headern ist ein logisches „UND“. Die Anfrage muss mit allen Abfrageparametern und Header-Schlüsseln (und Werten, falls angegeben) übereinstimmen, um der angegebenen Route zu entsprechen.
Wenn Sie beispielsweise Anfragen mit einem bestimmten Headerfeldnamen und Headerwert an einen Ursprung namens alternate-origin
weiterleiten möchten, konfigurieren Sie die Übereinstimmungsbedingungen in routeRules[].matchRules[].headerMatches[]
:
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: alternate-origin matchRules: - prefixMatch: "/videos/" headerMatches: - headerName: "x-device-name" exactMatch: "roku"
In diesem Beispiel stimmen Anfragen mit /videos/
am Anfang der URL und dem Header x-device-name: roku
mit dieser Route überein. Anfragen, denen dieser Header-Name fehlt oder die einen anderen Wert haben, stimmen nicht mit dieser Route überein.
Weitere Einzelheiten finden Sie in der API-Spezifikation für
HeaderMatch
Für einen Abgleich mit Abfrageparametern geben Sie einen oder mehrere queryParameterMatches
so an:
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: eu-live-origin-prod matchRules: - prefixMatch: "/videos/" queryParameterMatches: - name: "playback_type" exactMatch: "live" - name: "geo" exactMatch: "eu"
In diesem Beispiel entspricht eine Clientanfrage von https://cdn.example.com/videos/1234/abcd/xyz.m3u8?playback_type=live&geo=eu
dieser Route.
Weitere Einzelheiten finden Sie in der API-Spezifikation für
QueryParameterMatcher
Catchall-Route definieren (Standard)
Standardmäßig gibt Media CDN einen HTTP 404 (Not Found)
-Fehler zurück, wenn eine Anfrage mit keiner der konfigurierten Routen übereinstimmt.
So konfigurieren Sie eine Catchall-Route für einen bestimmten pathMatcher
(Sammlung von Routen):
- Erstellen Sie eine
routeRule
mit der niedrigsten Priorität (höchste Zahl), z. B. 999, also die niedrigste Route-Priorität. - Konfigurieren Sie eine
matchRule
mit dem Präfixabgleich/
(stimmt mit allen Anfragepfaden überein). - Konfigurieren Sie (eins davon) einen
origin
oderurlRedirect
auf der Route.
Um beispielsweise eine Catchall-Route zu konfigurieren, die alle nicht übereinstimmenden Anfragen an einen Standardursprung mit dem Namen my-origin
weiterleitet, erstellen Sie so eine neue Route mit priority: 999
und einem matchRules[].prefixMatch
von /
:
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 999 origin: my-origin matchRules: - prefixMatch: /
Sie können die URL optional vor dem Ursprungsabruf neu schreiben oder zu einer Standardseite (z. B. Ihrer Landingpage) weiterleiten, anstatt die Anfrage unverändert an den Ursprung zu senden.
Routenpriorität und -bestellung
Jeder Route in einem Array von routeRules[]
muss eine priority
zugeordnet sein.
Für spezifischere Routen sollten Sie eine höhere Priorität (kleinere Zahl) festlegen. Eine Route, die mit dem Präfix /stream/
und der Priorität 1 übereinstimmt, verhindert andernfalls, dass die spezifischere Route /stream/live/eu/
mit einer Priorität von 5 mit Anfragen abgeglichen wird.
- Die Route mit der höchsten Priorität ist „1“ und die niedrigste ist „999“.
- Sie können nicht zwei oder mehr routeRules mit derselben Priorität konfigurieren. Für jede Regel muss die Priorität mit einer Zahl zwischen 1 bis einschließlich 999 festgelegt werden.
- Wenn Sie eine Catchall-Route definieren, nicht übereinstimmende Anfragen an einen Standardursprung oder eine Weiterleitung an eine Landingpage oder einen Endpunkt weiterleiten.
Im folgenden Beispiel sehen Sie, dass die Route /live/us/
nie abgeglichen wird, da die Route /live/
eine höhere Priorität hat:
routeRules: - priority: 1 description: "Live routes" matchRules: - prefixMatch: /live/ routeAction: cdnPolicy: defaultTtl: 5s - priority: 2 description: "U.S based live streams" matchRules: # This would never be matched, as the /live/ prefixMatch at priority 1 # would always take precedence. - prefixMatch: /live/us/ routeAction: cdnPolicy: defaultTtl: 5s - priority: 999 description: "Catch-all route" matchRules: - prefixMatch: /
Zur Behebung dieses Problems legen Sie die spezifischere (längere) Route mit einer höheren Priorität fest:
routeRules: - priority: 1 description: "U.S based live streams" matchRules: # The more specific (longer) match is at a higher priority, and now # matches requests as expected. - prefixMatch: /live/us/ routeAction: cdnPolicy: defaultTtl: 5s - priority: 2 description: "Live routes" matchRules: - prefixMatch: /live/ routeAction: cdnPolicy: defaultTtl: 5s - priority: 999 description: "Catch-all route" matchRules: - prefixMatch: /
Dadurch kann die spezifischere Route Anfragen korrekt abgleichen. Eine Anfrage mit dem Präfix /live/eu/
würde trotzdem der Route /live/
mit der Priorität 2 zugeordnet werden.
Methodenfilterung
Standardmäßig nutzt Media CDN nur einen Proxy für GET
, HEAD
und OPTIONS
zu Ihrem Ursprung hinzu und filtert die Methoden heraus, die Ihren Ursprung ändern können.
In der Vorschau können Sie diese Standardeinstellung überschreiben
für eine bestimmte Routingregel, indem Sie die Methoden angeben,
z. B. zur Weiterleitung an Ihren Ursprung. Neben GET
, HEAD
und OPTIONS
Media CDN unterstützt PUT
, POST
, DELETE
und PATCH
.
Um die Unterstützung für eine Reihe von Methoden für eine Routingregel zu konfigurieren, geben Sie eine
Abschnitt routeMethods
mit einem allowed_methods
-Wert für jede Methode.
routeRules: - priority: 5 description: "Video uploads" routeMethods: allowedMethods: ["PUT", "POST", "OPTIONS"] matchRules: - pathTemplateMatch: "/uploads/**.ts" origin: prod-video-storage - priority: 10 description: "Video serving" routeMethods: allowedMethods: ["GET", "HEAD"] matchRules: - pathTemplateMatch: "/videos/**.ts" origin: prod-video-storage
In der Vorabversion ermöglicht Media CDN das Aktualisieren und Aufrufen dieser
mit der v1alpha1 Network Services API konfigurieren.
Alternativ können Sie den Befehl gcloud alpha edge-cache services export
verwenden.
und den Befehl gcloud alpha edge-cache services import
um Ihre YAML-Dateien für die Dienstkonfiguration zu aktualisieren.
Pfadnormalisierung
Die Pfadnormalisierung beschreibt, wie Media CDN mehrere Darstellungen einer URL in einer bestimmten, kanonischen Darstellung unter bestimmten Szenarien kombiniert.
Die Pfadnormalisierung kann die Cache-Trefferraten direkt verbessern. Dazu wird die Anzahl der Anforderungs-URLs reduziert, die denselben Inhalt repräsentieren, und es werden Herkunftsfehler für Ursprünge verringert, die normalisierte Pfade erwarten.
Eingehende Anfragen werden so normalisiert:
- Mehrere aufeinanderfolgende Schrägstriche werden zu einem einzelnen Schrägstrich zusammengeführt. Beispielsweise wird ein URL-Pfad von
/videos///12345/manifest.mpd
auf/videos/12345/manifest.mpd
normalisiert. - Pfadsegmente werden gemäß RFC 3986, Abschnitt 6.2.2.3 normalisiert.
Beispielsweise wird der Pfad
/a/b/c/./../../g
auf der Grundlage des in RFC 3986 definierten Algorithmus Punktsegmente entfernen auf/a/g
normalisiert. Diese Normalisierung erfolgt, bevor der Cache überprüft oder die Anfrage an den Ursprung weitergeleitet wird. - Anfragen werden nicht mit Prozentcodierung normalisiert. Beispielsweise wird eine URL mit einem prozentcodierten Schrägstrich (
%2F
) nicht in die nicht unverschlüsselte Form umgewandelt.
Bei URLs wird weiterhin zwischen Groß- und Kleinschreibung unterschieden und die Großschreibung nicht normalisiert. Viele URLs enthalten base64-Codierungen bei Groß- und Kleinschreibung, einschließlich URLs mit signierten Anfragetokens.
Umschreibungen und Weiterleitungen
In den folgenden Abschnitten finden Sie Beispiele für das Umschreiben von Anfragen und die Konfiguration von Umleitungen.
Anfrage-URLs umschreiben
Media CDN unterstützt das Umschreiben von Hosts und Pfaden. Durch Umschreibungen wird die an den Ursprung gesendete URL geändert und Sie können nach Bedarf Hosts und Pfade ändern. Host- und Pfadumschreibungen erfolgen auf Routenebene, sodass Sie festlegen können, welche spezifischen Anfragen auf der Grundlage eines beliebigen Matchers, einschließlich Pfad, Abfrageparameter und Anfrageheader, umgeschrieben werden.
Weitere Einzelheiten finden Sie in der API-Spezifikation für
RouteAction.UrlRewrite
Es gibt drei Möglichkeiten, eine Anfrage neu zu schreiben:
Feld | Beschreibung |
---|---|
urlRewrite.pathPrefixRewrite
|
Schreibt den Pfad neu und entfernt das in der
In einer einzelnen Routingregel kann nur entweder |
urlRewrite.pathTemplateRewrite
|
In einer einzelnen Routingregel kann nur entweder |
urlRewrite.hostRewrite
|
Der Host wird neu geschrieben, bevor die Anfrage an den Ursprungsserver gesendet wird. |
Hinweise:
- Umgeschriebene URLs ändern den Cache-Schlüssel nicht. Der Cache-Schlüssel basiert auf der vom Client gesendeten Anfrage-URL.
- Das Umschreiben erfolgt nach dem Routenabgleich und der Validierung der signierten Anfrage. Routen werden nicht mit einer anderen Übereinstimmungsregel neu abgeglichen.
Beispiel: Pfadpräfix entfernen
Um beispielsweise die Clientanfrage-URL von /vod/videos/hls/1234/abc.ts
in /videos/hls/1234/abc.ts
umzuschreiben (wobei /vod
aus dem Pfad entfernt wird), können Sie die Funktion pathPrefixRewrite
verwenden:
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: my-origin matchRules: - prefixMatch: "/vod/videos/" routeAction: urlRewrite: pathPrefixRewrite: "/videos/"
Ein pathPrefixRewrite
ersetzt die gesamte im matchRules[].prefixMatch
übereinstimmende Pfadkomponente durch den Wert von pathPrefixRewrite
.
Um einen Hostnamen umzuschreiben (z. B. cdn.example.com
auf my-bucket.s3.us-west-2.amazonaws.com
), können Sie Folgendes konfigurieren:
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: my-origin matchRules: - prefixMatch: "/videos/" routeAction: urlRewrite: hostRewrite: "my-bucket.s3.us-west-2.amazonaws.com"
In diesem Fall würde sich die ursprüngliche Anfrage-URL von cdn.example.com/videos/*
in my-bucket.s3.us-west-2.amazonaws.com/videos/*
ändern.
Sie können auch Host- und Pfadumschreibungen innerhalb einer einzigen Route kombinieren.
Beispiel: Variablen zum Umschreiben von URLs verwenden
Wie Sie pathTemplateMatch
und pathTemplateRewrite
verwenden, um Teile einer eingehenden Anfrage-URL umzuschreiben, erfahren Sie im Abschnitt über Variablen erfassen.
Anfragen weiterleiten
Media CDN unterstützt drei Arten von Weiterleitungen:
- Hostweiterleitungen, die nur den Host (Domain) weiterleiten, wobei die Pfad- und Abfrageparameter unverändert bleiben.
- Pfadweiterleitungen, die den Pfad vollständig ersetzen.
- Pfadpräfixweiterleitungen, die nur das übereinstimmende Präfix ersetzen.
Weiterleitungen sind standardmäßig auf HTTP 301 (Moved Permanently)
gesetzt, können jedoch so konfiguriert werden, dass sie unterschiedliche Weiterleitungsstatuscodes pro Route zurückgeben.
Die folgende Konfiguration ist ein Beispiel
für eine präfixbasierte Weiterleitung.
bei denen Nutzer, die https://cdn.example.com/on-demand/*
besuchen, zu folgender URL weitergeleitet werden:
https://cdn.example.com/streaming/*
.
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 10 matchRules: - prefixMatch: "/on-demand/" urlRedirect: # The prefix matched in matchRules.prefixMatch is replaced # by this value prefixRedirect: "/streaming/" redirectResponseCode: TEMPORARY_REDIRECT # corresponds to a HTTP 307
In diesem Beispiel wird die Umleitung auch in eine temporäre Umleitung umgewandelt, die verhindert, dass Clients (z. B. Browser) sie zwischenspeichern können. Dies kann nützlich sein, wenn Sie davon ausgehen, dass sie in naher Zukunft geändert werden soll.
Die unterstützten redirectResponseCode
-Werte sind in der folgenden Tabelle aufgeführt.
Antwortcode weiterleiten | HTTP-Statuscode |
---|---|
MOVED_PERMANENTLY_DEFAULT |
HTTP 301 (Dauerhaft verschoben) |
FOUND |
HTTP 302 (Gefunden) |
SEE_OTHER |
HTTP 303 (Weitere anzeigen) |
TEMPORARY_REDIRECT |
HTTP 307 (Vorübergehende Weiterleitung) |
PERMANENT_REDIRECT |
HTTP 308 (Permanente Weiterleitung) |
Hinweise:
- Eine Route kann entweder Traffic an einen Ursprung weiterleiten oder eine Weiterleitung an den Client zurückgeben. Sie können nicht sowohl
origin
als auchurlRedirect
festlegen gleichzeitig aktualisieren. - Für Routen, die an HTTPS weiterleiten, muss mindestens ein SSL-Zertifikat mit dem Dienst verbunden sein.
Weitere Einzelheiten finden Sie in der API-Spezifikation für
RouteRule.UrlRedirect
Alle Anfragen an HTTPS weiterleiten
Um alle Anfragen auf HTTPS (anstelle von HTTP) umzuleiten, können Sie jeden Ihrer Dienste so konfigurieren, dass alle Client-Anfragen automatisch auf HTTPS umgeleitet werden. Clients, die sich über HTTP verbinden, erhalten eine HTTP 301 (Permanent Redirect)
-Antwort mit dem Header Location
, der auf dieselbe URL gesetzt ist, wobei „https://“ anstelle von „http://“ verwendet wird.
gcloud
gcloud edge-cache services update MY_SERVICE \ --require-tls
Request issued for: [MY_SERVICE] Updated service [MY_SERVICE].
Der Befehl gibt eine Beschreibung Ihres Dienstes zurück, wobei requireTls
jetzt auf true
gesetzt ist.
name: MY_SERVICE requireTls: true
Sie können auch die Strenge Transportsicherheit -Header als Antwort-Header, damit Clients immer eine direkte Verbindung über HTTPS
Speicher-Back-Ends von Drittanbietern verwenden
Media CDN unterstützt die Verbindung zu öffentlich erreichbaren HTTP-Endpunkten außerhalb von Google Cloud, einschließlich AWS S3-Storage-Buckets, Azure Blob Storage und anderen Speicheranbietern. Dies kann nützlich sein, wenn Sie Multi-Cloud-Architektur haben oder noch keine Daten zu Cloud Storage migriert haben, mithilfe des Storage Transfer Service
Eine minimale Ursprungskonfiguration, die einen virtuellen gehosteten Bucket in AWS S3 konfiguriert:
name: MY_S3_ORIGIN originAddress: BUCKET-NAME.s3.REGION.amazonaws.com
Wenn Sie keinen Bucket-Namen verwenden, der mit den für Ihre EdgeCacheService
-Ressourcen konfigurierten Hostnamen übereinstimmt, müssen Sie auch eine Hostumschreibung für Routen konfigurieren, die mit diesem Ursprung (oder diesen Ursprüngen) verbunden sind. Andernfalls wird der von der Clientanfrage festgelegte Host-Header beim Abrufen vom Ursprung verwendet.
Wenn Sie beispielsweise alle Anfragen mit dem Pfadpräfix /legacy/
Ihrem externen Bucket zuordnen möchten, können Sie sowohl einen hostRewrite
als auch einen pathPrefixRewrite
konfigurieren, um dieses Präfix aus der ursprünglichen Anfrage zu entfernen:
routeRules: - description: legacy backend matchRules: - prefixMatch: "/legacy/" routeAction: urlRewrite: hostRewrite: BUCKET-NAME.s3.REGION.amazonaws.com pathPrefixRewrite: / cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 3600s
Weitere Informationen dazu, wie der Hostheader bei Ursprungsanfragen festgelegt wird, finden Sie in der Dokumentation Ursprungsanfragenheader.
Cross-Origin Resource Sharing (CORS)
Cross-Origin Resource Sharing
(CORS) ist ein browserorientierter Ansatz zum sicheren Senden ursprungsübergreifender Anfragen.
Mit CORS-Richtlinien können Sie CORS-Header automatisch festlegen, z. B.
Access-Control-Allow-Origins
, basierend auf einer Richtlinie pro Route.
CORS konfigurieren
Mit Media CDN können Sie eine CORS-Richtlinie für eine Route für ein
EdgeCacheService
In einer CORS-Richtlinie werden diese Regeln mit einem gemeinsamen Satz von HTTP-Headern definiert. Sie können
allgemeine CORS-Header in Antworten festlegen, z. B.
Access-Control-Allow-Origin
, Access-Control-Max-Age
,
und Access-Control-Allow-Headers
. Mithilfe dieser Überschriften können Sie
ursprungsübergreifenden Aufrufen an Ihre Media CDN-Dienste gesendet,
die auf einer anderen Domain (Ursprung) gehostet werden als das Frontend Ihrer Website
ursprungsübergreifende Anfragen zu verhindern, die Sie nicht ausdrücklich genehmigen.
Beispielsweise sind player.example.com
und api.example.com
unterschiedliche Ursprünge
(im Browser-Sinne) und Sie möchten vielleicht, dass Ihre Front-End-Anwendung
Anfragen an api.example.com
senden, um die nächste Playlist abzurufen, oder eine
mit ähnlichen Inhalten. In ähnlicher Weise muss player.example.com
möglicherweise
Wende dich an cdn.example.com
, um Videoplaylists und Videosegmente abzurufen:
cdn.example.com
muss angeben, dass dies in Ordnung ist und
player.example.com
ist ein allowed origin
sowie alle anderen Regeln.
(zulässige Header und Angaben zur Aufnahme von Cookies).
Ein weiteres Beispiel: Wenn Sie stream.example.com
als Ursprung zulassen möchten,
und einem X-Client-ID
-Header in CORS-Anfragen haben, können Sie corsPolicy
auf einer
wie folgt ab:
corsPolicy: maxAge: 600 allowOrigins: ["stream.example.com"] allowHeaders: ["X-Client-ID"]
Eine corsPolicy
ist konfiguriert unter
routing.pathMatchers[].routeRules[].routeAction.corsPolicy
innerhalb von
EdgeCacheService. Für jedes routeRule
kann ein anderes corsPolicy
definiert werden als
oder gar keine.
Wenn Sie einen corsPolicy
-Wert definieren und auch einen benutzerdefinierten Antwortheader durch
unter Verwendung der responseHeadersToAdd
-Felder auf einer Route mit demselben Namen, der
hat Vorrang vor dem Header
corsPolicy
-Wert.
Wenn in der Ursprungsantwort HTTP-Header festgelegt sind und Sie einen corsPolicy
-Wert haben
festgelegt ist, werden stattdessen die Werte corsPolicy
verwendet. Die Werte sind nicht minimiert.
oder kombiniert werden, um zu verhindern, dass ungültige Headerwerte an einen Client gesendet werden, oder
wenn Sie ungewollt eine weitergehende Richtlinie festlegen als beabsichtigt.
Die spezielle {origin_request_header}
wird mit dem HTTP-Header Origin
ausgefüllt.
in der Clientanfrage. Dies kann als benutzerdefinierter Antwortheaderwert auf einem
Route für den Access-Control-Allow-Origin
-Header.
Weitere Informationen finden Sie in der API
Spezifikation für
RouteAction.CORSPolicy
CORS-Richtlinienfelder
In der folgenden Tabelle werden die Felder beschrieben, die eine CORS-Richtlinie enthält.
Feld | Beschreibung | Beispiel |
---|---|---|
allowOrigins |
Legt den Antwortheader
Wenn Ihre Videoinhalte beispielsweise von |
Access-Control-Allow-Origins: https://stream.example.com
|
maxAge |
Legt den Antwortheader Einige Browser begrenzen diesen Wert auf zwei Stunden oder weniger, auch wenn der Höchstwert (86.400 s) angegeben ist. |
Access-Control-Max-Age: 7200
|
allowMethods |
Legt den Antwortheader Standardmäßig unterstützt Media CDN nur die |
Access-Control-Allow-Methods: GET, OPTIONS, HEAD
|
allowHeaders |
Legt den Header Dies wird häufig von Videoplayern benötigt, die auf einige Antwortheader für Videoinhalte zugreifen müssen, wenn sie diese ursprungsübergreifend anfordern. |
Access-Control-Allow-Headers: Content-Type, If-Modified-Since,
Range, User-Agent
|
exposeHeaders |
Legt den Antwortheader Dies wird häufig von Videodateien benötigt, die möglicherweise auf bestimmte Antwortheader für Videoinhalte zugreifen müssen, wenn quellenübergreifend angefordert wird. |
Access-Control-Expose-Headers: Date, Cache-Status, Content-Type,
Content-Length
|
allowCredentials |
Legt den Antwort-Header Dieser Header wird weggelassen, wenn er auf „false“ gesetzt wird. |
Access-Control-Allow-Credentials: true
|
disabled |
Deaktiviert corsPolicy , ohne sie zu entfernen. Preflight-OPTIONS -Anfragen werden an den Ursprung weitergeleitet.
|
– |
Beispiel für corsPolicy
Das folgende Konfigurationsbeispiel zeigt eine einfache corsPolicy
-Konfiguration:
routeRules: - priority: 1 matchRules: - prefixMatch: /stream/ routeAction: cdnPolicy: defaultTtl: 3600s corsPolicy: allowOrigins: - "https://stream.example.com" - "https://stream-staging.example.com" maxAge: 86400s # some browsers might only honor up to 7200s or less allowMethods: - "GET" - "HEAD" - "OPTIONS" allowHeaders: - "Content-Type" - "If-Modified-Since" - "Range" - "User-Agent" exposeHeaders: - "Content-Type" - "Content-Length" - "Date"
Fehlerbehebung beim Routing
Wenn bei einigen Anfragen keine übereinstimmenden Ergebnisse abgerufen oder Fehler zurückgegeben werden, überprüfen Sie die Folgendes:
- Eine Route muss eine
matchRule
mit genau einem der WerteprefixMatch
,fullPathMatch
oderpathTemplateMatch
definieren. Die API gibt einen Fehler zurück, wenn eines dieser Felder fehlt. - Achten Sie darauf, dass die
priority
jeder Route korrekt festgelegt ist: Spezifischere (längere) Routen sollten eine höhere Priorität gegenüber kürzeren, breiteren Routen erhalten. - Standardmäßig werden nur
GET
-,HEAD
- undOPTIONS
-Anfragen unterstützt. Unter Vorabversion können Sie hier die Unterstützung für anderen Methoden finden Sie unter Routenmethoden. Die Methoden, die für eine bestimmte Route nicht aktiviert sind, werden mit HTTP-405 (Method Not Allowed)
-Fehler - HTTP-
GET
-Anfragen mit Textkörper oder Anfragen mit Trailern werden abgelehnt. mit einem HTTP-400
-Fehler, da Anfragetexte inGET
nicht zulässig sind -Anfragen. - Der Abgleich von Suchparametern und Headern erfolgt logisch in UND: Die Anfrage muss Übereinstimmung mit allen Suchparametern- oder Headerschlüsseln (und Werten, falls angegeben) an die angegebene Route angepasst werden.
Nächste Schritte
- Lesen Sie die Dokumentation zum Konfigurieren von Caching.
- Informieren Sie sich darüber, wie Sie Verbindungen zu verschiedenen Ursprüngen herstellen.
- Richten Sie TLS-Zertifikate (SSL) für Ihren Dienst ein.
- Konfigurieren Sie signierte Anfragen, um den Zugriff auf Inhalte zu authentifizieren.