Dienstrouten konfigurieren

Media CDN bietet erweiterte HTTP-Routingfunktionen, mit denen Sie Traffic genau bestimmten Edge-Konfigurationen und Ursprüngen zuordnen können.

Routingregel konfigurieren

Konfigurieren Sie eine Routingregel für einen Media CDN-Dienst.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Media CDN auf.

    Zum Media CDN

  2. Klicken Sie auf den Namen des Dienstes, um die Seite Details des Dienstes zu öffnen, für den Sie eine Routenregel konfigurieren möchten.

  3. Klicken Sie auf die Schaltfläche Bearbeiten, um in den Bearbeitungsmodus zu wechseln.

  4. Klicken Sie auf Weiter, um zum Abschnitt Routing zu gehen.

  5. Geben Sie mindestens eine Hostregel an. Klicken Sie auf Hostregel hinzufügen. Führen Sie dann die folgenden Schritte aus:

    1. Geben Sie unter Hosts mindestens einen Host für den Abgleich an.

    2. Geben Sie unter Beschreibung eine kurze Beschreibung der Hostregel ein.

    Alternativ können Sie eine Hostregel bearbeiten, indem Sie auf den Pfeil klicken, um sie zu maximieren.

  6. Geben Sie mindestens eine Routingregel an. Klicken Sie auf Weiterleitungsregel hinzufügen.

    Alternativ können Sie eine Routenregel bearbeiten, indem Sie in der entsprechenden Zeile auf Bearbeiten klicken.

  7. Legen Sie im Bereich Routingregel bearbeiten für Priorität einen Wert für Routenpriorität.

  8. Geben Sie unter Beschreibung eine kurze Beschreibung ein, damit in einer Liste von Regeln.

  9. Geben Sie im Bereich Abgleich mindestens eine Übereinstimmungsbedingung an. Klicken Sie auf Fügen Sie eine Übereinstimmungsbedingung hinzu. Gehen Sie anschließend so vor:

    1. Wählen Sie für Übereinstimmungstyp eine beliebige Option für Übereinstimmung mit Pfad aus.

    2. Geben Sie unter Pfadübereinstimmung die Namen, Pfade oder Vorlagen an. Sie können den Platzhalterabgleich verwenden.

      Wählen Sie bei Bedarf auch Groß-/Kleinschreibung für Pfadwert aktivieren aus.

    3. Optional: Wählen Sie Übereinstimmung der Header und Übereinstimmung mit Abfrageparametern aus. Klicken Sie dann auf die entsprechenden Schaltflächen, um Header und Abfrageparameter hinzuzufügen. Geben Sie für jedes Element den Namen, die Keyword-Option und den Wert an.

      Weitere Informationen finden Sie unter Abgleich mit Headern und Abfrageparametern.

    4. Klicken Sie auf Fertig, um die Abgleichbedingung zu speichern.

  10. Wählen Sie für Primäre Aktion eine der folgenden Optionen aus:

    • Von einem Ursprung abrufen: Um Anfragen an einen bestimmten Ursprung weiterzuleiten, wählen Sie diese Option und dann einen Startort aus.

    • URL-Weiterleitung: Wenn Sie Anfragen weiterleiten möchten, wählen Sie diese Option aus. Geben Sie dann die Art der Weiterleitung, den Pfad und den Statuscode.

      Optional können Sie die Optionen auswählen, um alle Antworten an HTTPS weiterzuleiten oder die Abfrage zu entfernen.

  11. Klicken Sie auf Erweiterte Konfigurationen.

    1. Klicken Sie im Bereich Header-Aktion auf Element hinzufügen.

      Wählen Sie einen Aktionstyp aus und geben Sie dann einen Header als Namen und Wert an Paar zusammen. Klicken Sie anschließend auf Fertig.

    2. Klicken Sie im Bereich Routenaktion auf Element hinzufügen.

      Geben Sie einen Aktionstyp und die zugehörigen Optionen an. Klicken Sie anschließend auf Fertig.

  12. Wählen Sie für HTTP-Filtermethode die Option HTTP-Filtermethode anpassen aus.

    Wählen Sie dann die HTTP-Methoden den Sie zu Ihrem Ursprung weiterleiten möchten.

  13. Klicken Sie zum Speichern der Routingregel auf Speichern.

  14. Klicken Sie auf Dienst aktualisieren, um die Änderungen am Dienst zu speichern.

gcloud und YAML

  1. Media CDN-Konfiguration exportieren in eine YAML-Datei umwandeln. Verwenden Sie die Methode gcloud edge-cache services export-Befehl

    gcloud edge-cache services export SERVICE_NAME \
    --destination=FILENAME.yaml

    Ersetzen Sie Folgendes:

    • SERVICE_NAME: der Name Ihres Dienstes
    • FILENAME: der Name der YAML-Datei

  2. Aktualisieren Sie die YAML-Datei mit der erforderlichen Konfiguration, wie in den Abschnitten auf dieser Seite beschrieben.

  3. Wenn du den Dienst aktualisieren möchtest, importiere die Media CDN-Konfiguration aus der YAML-Datei. Verwenden Sie die Methode gcloud edge-cache services import-Befehl

    gcloud edge-cache services import SERVICE_NAME \
    --source=FILENAME.yaml

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 überein, die auf mindestens einem Host basieren. Weitere Informationen dazu, wie Traffic an einen Ursprung weitergeleitet wird, findest du unter HostRule und PathMatcher. Jede Route kann ihre eigene CDN-Konfiguration, Umschreibungen, Weiterleitungen, CORS-Richtlinien, benutzerdefinierte HTTP-Header und Ursprungszuordnung definieren. Routen können Ursprünge teilen.

Sie können beispielsweise Anfragen für Manifeste an einen bestimmten Ursprung weiterleiten und eine kurzlebige Cache-TTL und eine negative Caching-Richtlinie definieren. Anfragen für Segmente können mithilfe von Header und Abfrageparameter um bestimmte Manifesttypen oder Nutzer aufzuschlüsseln.

Das folgende Beispiel zeigt, wie Anfragen weitergeleitet werden, die einem bestimmten Header, Abfrageparameter und Pfadpräfix für den Host media.example.com entsprechen:

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 fullPathMatch: "/stream/" stimmt mit /stream/ überein, aber nicht mit /stream oder /stream/us/hls/1234.ts.

Ein fullPathMatch ist eine explizite (exakte) Übereinstimmung.
matchRules[].prefixMatch Die Bedingung prefixMatch entspricht dem URL-Pfadpräfix. URLs, die mit demselben String beginnen, werden übereinstimmen.

Eine Route mit der Übereinstimmungsregel prefixMatch: "/videos/" stimmt sowohl mit /videos/hls/58481314/manifest.m3u8 als auch mit /videos/dash überein, da beide das Präfix /videos/ enthalten.
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 pathTemplateMatch: "/**.m3u8" entspricht jedem URL-Pfad, der mit .m3u8 endet.

Sowohl /content/en-GB/13/51491/manifest_193193.m3u8 als auch /p/abc/1234/manifest_1080p5000.m3u8 entsprechen diesem Muster.

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.

/**.m3u8 oder /{path=**}.m3u8 entspricht allen Pfadsegmenten bis zur Erweiterung.

/videos/{file=**} entspricht /videos/en-GB/def566/manifest.m3u8, einschließlich der Erweiterung, und erfasst die Pfadvariable file="en-GB/def566/manifest.m3u8.

Hinweise:

  • Wenn Sie keine URL neu schreiben, verwenden Sie die einfacheren Operatoren * und **.
  • Wenn Sie Variablen zum Erfassen von Pfadkomponenten verwenden, können Teile der URL, die nicht von einer Variablen erfasst werden, in einem nachfolgenden pathTemplateRewrite referenziert werden. Ein Beispiel finden Sie im Abschnitt Pfadvariablen erfassen.
  • Sie können nicht auf Variablen in einem nachfolgenden pathTemplateRewrite verweisen, die nicht in der pathTemplateMatch 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 bis zu zehn Operatoren (Platzhalter oder Variablen) in einer Übereinstimmung angeben. Die Felder pathTemplateMatch und pathTemplateRewrite dürfen 255 Zeichen nicht überschreiten.

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 sowohl segments/00001.ts als auch master.m3u8.
  • Im pathTemplateRewrite auf derselben Route verweisen Sie auf einige der Variablen, die Sie im pathTemplateMatch 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 dem pathTemplateMatch 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 dem pathTemplateMatch und erhält eine HTTP 404 (Not Found)-Antwort.
  • Eine eingehende Anfrage-URL von /br/es/dash/c966cbbe6ae3/subtitle_00001.vtt entspricht ebenfalls dem pathTemplateMatch 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 Werten us.vod.example.com und us.vod.example.com:80.
  • Wenn die Anfrage über HTTPS (TLS) erfolgt, entspricht ein hostRules[].hosts[]-Eintrag von *.vod.example.com dem Wert us.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 Informationen 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 Informationen 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 oder urlRedirect 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, können Sie alle nicht übereinstimmenden Anfragen an einen Standardursprung senden oder sie 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.

Methodenfilter

Standardmäßig werden mit Media CDN nur die Methoden GET, HEAD und OPTIONS an deinen Ursprung weitergeleitet. Methoden, die deinen Ursprung ändern können, werden herausgefiltert.

Sie können dieses Standardverhalten für eine bestimmte Routingregel überschreiben, indem Sie die Methoden, die zu Ihrem Ursprung weitergeleitet werden sollen. Neben GET, HEAD, und OPTIONS unterstützt Media CDN PUT, POST, DELETE und PATCH

Wenn Sie die Unterstützung für eine Reihe von Methoden für eine Routenregel konfigurieren möchten, geben Sie einen Abschnitt routeMethods mit einem allowed_methods-Wert für jede Methode an.

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

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 Informationen 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 prefixMatch angegebene Präfix, das der Anfrage entspricht.

In einer einzelnen Routingregel kann nur entweder pathPrefixRewrite oder pathTemplateRewrite angegeben werden.

urlRewrite.pathTemplateRewrite

pathTemplateRewrite kann nur mit einer entsprechenden pathTemplateMatch-Übereinstimmungsregel auf derselben Route verwendet werden.

In einer einzelnen Routingregel kann nur entweder pathPrefixRewrite oder pathTemplateRewrite angegeben werden.

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 der Nutzer, die https://cdn.example.com/on-demand/* besuchen, auf https://cdn.example.com/streaming/* umgeleitet werden.

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 auch urlRedirect festlegen hinzufügen.
  • Für Routen, die an HTTPS weiterleiten, muss mindestens ein SSL-Zertifikat mit dem Dienst verbunden sein.

Weitere Informationen 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 den Header Strict-Transport-Security als Antwortheader festlegen, damit Clients immer direkt über HTTPS eine Verbindung herstellen.

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 browserbasierter Ansatz, um plattformübergreifende Anfragen sicher zu senden. 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 kannst du eine CORS-Richtlinie für eine Route für eine EdgeCacheService definieren.

Eine CORS-Richtlinie definiert diese Regeln mit einer gemeinsamen Reihe von HTTP-Headern. Sie können gängige 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 und ursprungsübergreifende Anfragen zu verhindern, die Sie nicht ausdrücklich genehmigen.

Angenommen, player.example.com und api.example.com sind unterschiedliche Ursprünge (im Browsersinn). Du möchtest, dass deine Frontend-Anwendung Anfragen an api.example.com sendet, um die nächste Playlist abzurufen oder eine Liste ähnlicher Inhalte zu aktualisieren. 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"]

Ein 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 festlegen, indem Sie die responseHeadersToAdd-Felder in einer Route mit demselben Namen verwenden, hat der benutzerdefinierte Antwortheader Vorrang vor dem corsPolicy-Wert und wird anstelle dieses Werts verwendet.

Wenn in der Ursprungsantwort HTTP-Header festgelegt sind und Sie einen corsPolicy-Wert haben festgelegt ist, werden stattdessen die Werte corsPolicy verwendet. Die Werte werden nicht minimiert oder kombiniert, um zu verhindern, dass ungültige Header-Werte an einen Client gesendet oder versehentlich eine weniger restriktive Richtlinie als beabsichtigt festgelegt wird.

Die spezielle {origin_request_header} wird mit dem HTTP-Header Origin ausgefüllt. in der Clientanfrage. Dieser kann als benutzerdefinierter Antwortheaderwert für eine Route für den Access-Control-Allow-Origin-Header festgelegt werden.

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 Access-Control-Allow-Origins fest, der angibt, welche Ursprünge quellenübergreifende Anfragen in einer Browserumgebung senden können.

Wenn Ihre Videoinhalte beispielsweise von https://video.example.com bereitgestellt werden, Ihr nutzerseitiges Portal jedoch von https://stream.example.com, würden Sie https://stream.example.com als zulässigen Ursprung hinzufügen.

Access-Control-Allow-Origins: https://stream.example.com
maxAge

Legt den Antwortheader Access-Control-Max-Age fest, der angibt, wie lange ein Browserclient die Antwort in Sekunden in einer CORS-Preflight-Anfrage speichern soll.

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 Access-Control-Allow-Methods fest, der angibt, welche HTTP-Methoden auf die Ressource zugreifen dürfen.

Standardmäßig unterstützt Media CDN nur die GET, HEAD- und OPTIONS-Methoden. Informationen zum Konfigurieren der Unterstützung für andere Methoden finden Sie unter Routenmethoden.

 Access-Control-Allow-Methods: GET, OPTIONS, HEAD
allowHeaders

Legt den Header Access-Control-Allow-Headers fest, der bestimmt, welche Header in einer CORS-Anfrage gesendet werden können.

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 Access-Control-Expose-Headers fest, der bestimmt, auf welche Header von clientseitigem JavaScript zugegriffen werden kann.

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 Access-Control-Allow-Credentials fest, der es clientseitigem JavaScript ermöglicht, die Antwort auf Anfragen mit enthaltenen Anmeldeinformationen zu prüfen.

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 zurückgegeben werden oder Fehler auftreten, prüfen Sie Folgendes:

  • Eine Route muss eine matchRule mit genau einem der Werte prefixMatch, fullPathMatch oder pathTemplateMatch 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- und OPTIONS-Anfragen unterstützt. Informationen zum Konfigurieren des Supports für andere 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 in GET nicht zulässig sind -Anfragen.
  • Der Abgleich von Abfrageparametern und Headern ist ein logisches „UND“. Die Anfrage muss mit allen Abfrageparametern oder Header-Schlüsseln (und Werten, falls angegeben) übereinstimmen, um der angegebenen Route zu entsprechen.

Nächste Schritte