Übersicht über externen Application Load Balancer

In diesem Dokument werden die grundlegenden Konzepte zum Konfigurieren eines externen Application Load Balancers vorgestellt.

Ein externer Application Load Balancer ist ein proxybasierter Layer-7-Load-Balancer, mit dem Sie Ihre Dienste hinter einer einzelnen externen IP-Adresse ausführen und skalieren können. Der externe Application Load Balancer verteilt HTTP- und HTTPS-Traffic auf Backends, die auf einer Vielzahl vonCloud de Confiance -Plattformen wie Compute Engine, Google Kubernetes Engine (GKE) und Cloud Storage gehostet werden, sowie auf externe Backends, die über das Internet oder über Hybridkonnektivität verbunden sind. Weitere Informationen finden Sie unter Application Load Balancer: Anwendungsfälle.

Betriebsarten

Dieser Load Balancer ist im regionalen Modus verfügbar und wird im Folgenden als regionaler externer Application Load Balancer bezeichnet. Der Load Balancer wird als verwalteter Dienst auf Grundlage des Open-Source-Envoy-Proxys implementiert. Dazu gehören erweiterte Funktionen zur Trafficverwaltung wie Trafficspiegelung, gewichtete Trafficaufteilung und Anfrage- oder Antwort-basierte Headertransformationen. Der regionale Modus sorgt dafür, dass sich alle Clients und Backends in einer bestimmten Region befinden. Verwenden Sie diesen Load Balancer, wenn Sie Inhalte nur über eine bestimmte Standortbestimmung bereitstellen möchten, um beispielsweise Compliance-Bestimmungen zu erfüllen.

Architektur

Die folgenden Ressourcen sind für die Bereitstellung eines externen Application Load Balancers erforderlich:

• Bei regionalen externen Application Load Balancern ausschließlich wird ein Nur-Proxy-Subnetz verwendet, um Verbindungen vom Load-Balancer zu den Back-Ends zu senden.

• Eine externe Weiterleitungsregel gibt eine externe IP-Adresse, einen Port und einen HTTP(S)-Ziel-Proxy an. Clients verwenden die IP-Adresse und den Port, um eine Verbindung zum Load-Balancer herzustellen.

• Ein HTTP(S)-Ziel-Proxy empfängt eine Anfrage vom Client. Der HTTP(S)-Proxy wertet die Anfrage mithilfe der URL-Zuordnung aus, um Entscheidungen zum Routing des Traffics zu treffen. Der Proxy kann auch die Kommunikation mithilfe von SSL-Zertifikaten authentifizieren.

  • Beim HTTPS-Load-Balancing verwendet der HTTPS-Zielproxy SSL-Zertifikate, um seine Identität gegenüber Clients nachzuweisen. Ein HTTPS-Zielproxy unterstützt bis zu einer dokumentierten Anzahl von SSL-Zertifikaten.

• Der HTTP(S)-Proxy verwendet eine URL-Zuordnung, um anhand von HTTP-Attributen (z. B. Anfragepfad, Cookies oder Header) eine Routingentscheidung zu treffen. Basierend auf der Routingentscheidung leitet der Proxy Clientanfragen an bestimmte Backend-Dienste oder Backend-Buckets weiter. In der URL-Zuordnung können zusätzliche Aktionen angegeben werden, z. B. Weiterleitungen an Clients.

• Ein Backend-Dienst verteilt Anfragen an fehlerfreie Backends.

• Eine Systemdiagnose überwacht regelmäßig die Bereitschaft Ihrer Back-Ends. Dadurch besteht ein geringeres Risiko, dass Anfragen an Back-Ends gesendet werden, die die Anfrage nicht verarbeiten können.

• Firewallregeln für Ihre Back-Ends, um Systemdiagnoseprüfungen zu akzeptieren. Regionale externe Application Load Balancer erfordern eine zusätzliche Firewallregel, damit Traffic vom Nur-Proxy-Subnetz die Back-Ends erreichen kann.

Regional

Dieses Diagramm zeigt die Komponenten der Bereitstellung eines regionalen externen Application Load Balancers.

Nur-Proxy-Subnetz

Das Nur-Proxy-Subnetz stellt eine Reihe von IP-Adressen bereit, die Google zum Ausführen von Envoy-Proxys in Ihrem Namen verwendet. Sie müssen in jeder Region eines VPC-Netzwerks, in dem Sie regionale externe Application Load Balancer verwenden, ein Nur-Proxy-Subnetz erstellen. Das Flag --purpose für dieses Nur-Proxy-Subnetz ist auf REGIONAL_MANAGED_PROXY gesetzt. Alle regionalen Envoy-basierten Load-Balancer in derselben Region und demselben VPC-Netzwerk teilen einen Pool von Envoy-Proxys aus demselben Nur-Proxy-Subnetz. Weiter:

• Nur-Proxy-Subnetze werden nur für Envoy-Proxys und nicht für Ihre Back-Ends verwendet.
• Backend-VMs bzw. Endpunkte aller regionalen externen Application Load Balancer in einer Region und einem VPC-Netzwerk empfangen Verbindungen vom Nur-Proxy-Subnetz.
• Die IP-Adresse des regionalen externen Application Load Balancers befindet sich nicht im Nur-Proxy-Subnetz. Die IP-Adresse des Load-Balancers wird durch seine extern verwaltete Weiterleitungsregel definiert, die unten beschrieben ist.
• Nur-Proxy-Subnetze können mit dem Stack-Typ IPV4_IPV6 oder IPV4_ONLY konfiguriert werden.

Wenn Sie zuvor ein Nur-Proxy-Subnetz mit --purpose=INTERNAL_HTTPS_LOAD_BALANCER erstellt haben, müssen Sie den Zweck des Subnetzes zu REGIONAL_MANAGED_PROXY migrieren, bevor Sie andere Envoy-basierte Load Balancer in derselben Region des VPC-Netzwerks erstellen können.

Weiterleitungsregeln und IP-Adressen

Weiterleitungsregeln leiten Traffic abhängig von der IP-Adresse, dem Port und dem Protokoll an eine Load-Balancing-Konfiguration weiter, die aus einem Zielproxy, einer URL-Zuordnung und mindestens einem Back-End-Dienst besteht.

IP-Adressspezifikation Jede Weiterleitungsregel stellt eine einzelne IP-Adresse bereit, die in DNS-Einträgen für die Anwendung verwendet werden kann. Ein Load-Balancing für DNS ist nicht erforderlich. Sie können die zu verwendende IPv4- oder IPv6-Adresse entweder selbst angeben oder von Cloud Load Balancing zuweisen lassen.

Portspezifikation Jede Weiterleitungsregel für einen Application Load Balancer kann auf einen einzelnen Port von 1–65535 verweisen. Wenn Sie mehrere Ports unterstützen möchten, müssen Sie mehrere Weiterleitungsregeln konfigurieren. Sie können mehrere Weiterleitungsregeln so konfigurieren, dass sie dieselbe externe IP-Adresse (VIP) verwenden und auf denselben Ziel-HTTP(S)-Proxy verweisen, solange die gesamte Kombination von IP-Adresse, Port und Protokoll für jede Weiterleitungsregel eindeutig ist. Auf diese Weise können Sie einen einzelnen Load Balancer mit einer freigegebenen URL-Zuordnung als Proxy für mehrere Anwendungen verwenden.

Die Art der Weiterleitungsregel, die IP-Adresse und das Load-Balancing-Schema, die von externen Application Load Balancern verwendet werden, hängen vom Modus des Load-Balancers und von der Netzwerkdienststufe ab, in der sich der Load-Balancer befindet.

Eine vollständige Liste der Protokolle, die von Weiterleitungsregeln des externen Application Load Balancers in den einzelnen Modi unterstützt werden, finden Sie unter Load-Balancer-Features.

Weiterleitungsregeln und VPC-Netzwerke

In diesem Abschnitt wird beschrieben, wie Weiterleitungsregeln, die von externen Application Load Balancern verwendet werden, mit VPC-Netzwerken verknüpft werden.

Ziel-Proxys

Ziel-Proxys beenden HTTP(S)-Verbindungen von Clients. Mindestens eine Weiterleitungsregel leitet den Traffic zum Ziel-Proxy und der Ziel-Proxy ruft die URL-Zuordnung auf, um zu ermitteln, wie Traffic an Backends weitergeleitet wird.

Der Proxy behält die Groß- und Kleinschreibung im Namen eines Anfrage- oder Antwortheaders nicht unbedingt bei. Beispiel: Der Antwortheader Server: Apache/1.0 könnte auf dem Client als server: Apache/1.0 angezeigt werden.

In der folgenden Tabelle ist der Typ des Ziel-Proxys angegeben, der für externe Application Load Balancer erforderlich ist.

Zusätzlich zu den vom Ziel-Proxy hinzugefügten Headern passt der Load Balancer andere HTTP-Header so an:

• Einige Header werden zusammengeführt. Wenn mehrere Instanzen mit demselben Headerschlüssel vorhanden sind, z. B. Via, kombiniert der Load-Balancer deren Werte in einer durch Kommas getrennten Liste zu einem einzelnen Headerschlüssel. Es werden nur Header zusammengeführt, deren Werte als durch Kommas getrennte Liste dargestellt werden können. Andere Header wie Set-Cookie werden nie zusammengeführt.

Host-Header

Wenn der Load-Balancer die HTTP-Anfrage stellt, behält der Load-Balancer den Host-Header der ursprünglichen Anfrage bei.

X-Forwarded-For-Header

Der Load Balancer hängt zwei IP-Adressen an den Header X-Forwarded-For an, die durch ein einzelnes Komma getrennt sind, in der folgenden Reihenfolge:

1. Die IP-Adresse des Clients, der eine Verbindung zum Load-Balancer herstellt
2. Die IP-Adresse der Weiterleitungsregel des Load-Balancers

Wenn die eingehende Anfrage keinen X-Forwarded-For-Header enthält, sieht der resultierende Header so aus:

X-Forwarded-For: <client-ip>,<load-balancer-ip>

Wenn die eingehende Anfrage bereits einen X-Forwarded-For-Header enthält, hängt der Load Balancer seine Werte an den vorhandenen Header an:

X-Forwarded-For: <existing-value>,<client-ip>,<load-balancer-ip>

Vorhandene Headerwerte mit einem benutzerdefinierten Anfrageheader entfernen

Sie können vorhandene Headerwerte mithilfe von benutzerdefinierten Anfrageheadern im Backend-Dienst entfernen. Im folgenden Beispiel wird das Flag --custom-request-header verwendet, um den Header X-Forwarded-For mit den Variablen client_ip_address und server_ip_address neu zu erstellen. Bei dieser Konfiguration wird der eingehende X-Forwarded-For-Header nur durch die IP-Adresse des Clients und des Load Balancers ersetzt.

--custom-request-header=x-forwarded-for:{client_ip_address},{server_ip_address}

Wie die Backend-Reverse-Proxy-Software den X-Forwarded-For-Header ändern kann

Wenn auf den Backends Ihres Load Balancers HTTP-Reverse-Proxy-Software ausgeführt wird, hängt die Software möglicherweise eine oder beide der folgenden IP-Adressen an das Ende des X-Forwarded-For-Headers an:

1. Die IP-Adresse des GFE, das mit dem Backend verbunden ist. Die GFE-Proxybereiche sind im Dokument Firewallregeln aufgeführt.

2. Die IP-Adresse des Backend-Systems.

Daher kann ein vorgelagertes System einen X-Forwarded-For-Header mit der folgenden Struktur sehen:

<existing-value>,<client-ip>,<load-balancer-ip>,<GFE-ip>,<backend-ip>

Cloud Trace-Unterstützung

Trace wird bei Application Load Balancern nicht unterstützt. Der globale und der klassische Application Load Balancer fügen den Header X-Cloud-Trace-Context hinzu, wenn er nicht vorhanden ist. Der regionale externe Application Load Balancer fügt diesen Header nicht hinzu. Wenn der X-Cloud-Trace-Context-Header bereits vorhanden ist, wird er unverändert durch die Load Balancer geleitet. Der Load Balancer exportiert jedoch keine Traces oder Spans.

URL-Zuordnungen

URL-Zuordnungen definieren die Zuordnungsmuster für eine Weiterleitung von Anfragen, die auf URLs basieren, an die passenden Back-End-Dienste. Mit der URL-Zuordnung können Sie den Traffic aufteilen. Dazu werden die URL-Komponenten untersucht, damit sie Anfragen an verschiedene Back-End-Sets senden. Ein Standarddienst ist so definiert, dass er alle Anfragen bearbeiten kann, für die es keine bestimmte Host- oder Pfadregel gibt.

URL-Zuordnungen unterstützen mehrere Features zur erweiterten Trafficverwaltung wie Header-basierte Trafficsteuerung, gewichtete Trafficaufteilung und Anfragespiegelung. Hier finden Sie weitere Informationen:

• Übersicht über die Trafficverwaltung für regionale externe Application Load Balancer

In der folgenden Tabelle ist der Typ der URL-Zuordnung angegeben, der von externen Application Load Balancern in den einzelnen Modi benötigt wird.

SSL-Zertifikate

Externe Application Load Balancer, die HTTPS-Zielproxys verwenden, benötigen als Teil der Load-Balancer-Konfiguration private Schlüssel und SSL-Zertifikate.

Regionale externe Application Load Balancer, die HTTPS-Zielproxys verwenden, benötigen als Teil der Load-Balancer-Konfiguration private Schlüssel und SSL-Zertifikate.

Regionale externe Application Load Balancer unterstützen selbstverwaltete Compute Engine-SSL-Zertifikate.

SSL-Richtlinien

SSL-Richtlinien geben die SSL-Features an, die Cloud de Confiance -Load-Balancer beim Aushandeln von SSL mit Clients verwenden.

Standardmäßig verwendet der HTTPS-Load-Balancer eine Reihe von SSL-Funktionen, die eine hohe Sicherheit und umfassende Kompatibilität bieten. Einige Anwendungen erfordern mehr Kontrolle darüber, welche SSL-Versionen und -Chiffren für ihre HTTPS- oder SSL-Verbindungen verwendet werden. Sie können eine SSL-Richtlinie definieren, um die Gruppe von SSL-Features anzugeben, die der Load-Balancer beim Aushandeln von SSL mit Clients verwendet. Darüber hinaus können Sie diese SSL-Richtlinie auf Ihren Ziel-HTTPS-Proxy anwenden.

In der folgenden Tabelle ist die Unterstützung von SSL-Richtlinien für Load-Balancer in den einzelnen Modi aufgeführt.

Backend-Dienste

Ein Backend-Dienst stellt dem Load Balancer Konfigurationsinformationen bereit, damit er Anfragen an seine Backends weiterleiten kann, z. B. Compute Engine-Instanzgruppen oder Netzwerk-Endpunktgruppen (NEGs). Weitere Informationen zu Backend-Diensten finden Sie unter Backend-Dienste – Übersicht.

Bereich des Backend-Dienstes

In der folgenden Tabelle ist aufgeführt, welche Backend-Dienstressource und welcher Bereich von externen Application Load Balancern verwendet wird:

Protokoll für Back-Ends

Backend-Dienste für Application Load Balancer müssen eines der folgenden Protokolle verwenden, um Anfragen an Backends zu senden:

• HTTP, das HTTP/1.1 und kein TLS verwendet
• HTTPS, das HTTP/1.1 und TLS verwendet
• HTTP/2, das HTTP/2 und TLS verwendet (HTTP/2 ohne Verschlüsselung wird nicht unterstützt)
• H2C, das HTTP/2 über TCP verwendet. TLS ist nicht erforderlich. H2C wird für klassische Application Load Balancer nicht unterstützt.

Der Load Balancer verwendet nur das von Ihnen angegebene Backend-Dienstprotokoll, um mit seinen Backends zu kommunizieren. Der Load Balancer greift nicht auf ein anderes Protokoll zurück, wenn er nicht mit Backends über das angegebene Backend-Dienstprotokoll kommunizieren kann.

Das Protokoll des Backend-Dienstes muss nicht mit dem Protokoll übereinstimmen, das von Clients für die Kommunikation mit dem Load Balancer verwendet wird. Clients können beispielsweise Anfragen mit HTTP/2 an den Load Balancer senden, der Load Balancer kann jedoch mit Backends über HTTP/1.1 (HTTP oder HTTPS) kommunizieren.

Back-Ends

Ein regionaler externer Application Load Balancer unterstützt die folgenden Backend-Typen:

• Instanzgruppen
• Zonale NEGs
• Internet-NEGs

Back-Ends und VPC-Netzwerke

Für Backends von regionalen externen Application Load Balancern gilt Folgendes:

• Bei Instanzgruppen, zonalen NEGs und NEGs mit Hybrid-Konnektivität müssen sich alle Backends im selben Projekt und in derselben Region wie der Backend-Dienst befinden. Ein Load Balancer kann jedoch auf ein Backend verweisen, das ein anderes VPC-Netzwerk im selben Projekt wie der Backend-Dienst verwendet. Die Verbindung zwischen dem VPC-Netzwerk des Load Balancers und dem Backend-VPC-Netzwerk kann entweder über VPC-Netzwerk-Peering, Cloud VPN-Tunnel oder Cloud Interconnect-VLAN-Anhänge konfiguriert werden.

  Definition des Backend-Netzwerks

  • Bei zonalen NEGs und Hybrid-NEGs geben Sie das VPC-Netzwerk explizit an, wenn Sie die NEG erstellen.
  • Bei verwalteten Instanzgruppen wird das VPC-Netzwerk in der Instanzvorlage definiert.
  • Bei nicht verwalteten Instanzgruppen wird das VPC-Netzwerk der Instanzgruppe so festgelegt, dass es mit dem VPC-Netzwerk der Schnittstelle nic0 für die erste VM übereinstimmt, die der Instanzgruppe hinzugefügt wird.

  Anforderungen an das Backend-Netzwerk

  Das Netzwerk deines Backends muss eine der folgenden Netzwerkanforderungen erfüllen:

  • Das VPC-Netzwerk des Back-Ends muss genau mit dem VPC-Netzwerk der Weiterleitungsregel übereinstimmen.

  • Das VPC-Netzwerk des Back-Ends muss über VPC-Netzwerk-Peering mit dem VPC-Netzwerk der Weiterleitungsregel verbunden sein. Sie müssen den Austausch von Subnetzrouten konfigurieren, um die Kommunikation zwischen dem Nur-Proxy-Subnetz im VPC-Netzwerk der Weiterleitungsregel und den von den Backend-Instanzen oder -Endpunkten verwendeten Subnetzen zu ermöglichen.

  Anforderungen an das IPv6-Subnetz des Backends

  Die für die Frontend-Verbindung verwendete IP-Version ist unabhängig von der Backend-Verbindung. Da das Nur-Proxy-Subnetz Dual-Stack (IPV4_IPV6) ist, kann es mit Backends über IPv4 oder IPv6 kommunizieren.

  Wenn Ihre Backend-Instanzen IPv6-Traffic verarbeiten, kann das Backend-Subnetz mit dem Stack-Typ IPV4_ONLY oder IPV4_IPV6 (Dual-Stack) konfiguriert werden. Wenn der Stacktyp des Backend-Subnetzes IPv6 enthält, müssen Sie den IPv6-Zugriffstyp des Subnetzes explizit auf EXTERNAL festlegen.

• Bei allen anderen Backend-Typen müssen sich alle Backends im selben VPC-Netzwerk und in derselben Region befinden.

  Regionale externe Application Load Balancer unterstützen auch Umgebungen mit freigegebene VPC, in denen Sie VPC-Netzwerke und die zugehörigen Ressourcen projektübergreifend freigeben können. Wenn sich der Backend-Dienst und die Backends des regionalen externen Application Load Balancers in einem anderen Projekt als die Weiterleitungsregel befinden sollen, müssen Sie den Load Balancer in einer gemeinsam genutzten VPC-Umgebung mit projektübergreifendem Dienstverweis konfigurieren.

Backends und Netzwerkschnittstellen

Wenn Sie Instanzgruppen-Backends verwenden, werden Pakete immer an nic0 gesendet. Wenn Sie Pakete an Schnittstellen senden möchten, die nicht vom Typ nic0 sind (entweder vNICs oder Dynamic Network Interfaces), verwenden Sie stattdessen NEG-Backends.

Wenn Sie zonale NEG-Backends verwenden, werden Pakete an die Netzwerkschnittstelle gesendet, die durch den Endpunkt in der NEG dargestellt wird. Die NEG-Endpunkte müssen sich im selben VPC-Netzwerk wie das explizit definierte VPC-Netzwerk der NEG befinden.

Systemdiagnosen

Jeder Backend-Dienst gibt eine Systemdiagnose an, die regelmäßig die Bereitschaft der Backends überwacht, eine Verbindung vom Load-Balancer zu erhalten. Dadurch besteht ein geringeres Risiko, dass Anfragen an Back-Ends gesendet werden, die die Anfrage nicht verarbeiten können. Systemdiagnosen prüfen nicht, ob die Anwendung selbst funktioniert.

Für die Systemdiagnoseprüfungen müssen Sie eine Firewallregel zum Zulassen von eingehendem Traffic erstellen, damit Systemdiagnoseprüfungen Ihre Backend-Instanzen erreichen können. In der Regel gehen Systemdiagnoseprüfungen vom zentralen Systemdiagnosemechanismus von Google aus.

Regionale externe Application Load Balancer, die Hybrid-NEG-Back-Ends verwenden, sind eine Ausnahme von dieser Regel, da ihre Systemdiagnosen stattdessen vom Nur-Proxy-Subnetz ausgehen. Weitere Informationen finden Sie in der Übersicht zu Hybrid-NEGs.

Systemdiagnoseprotokoll

Obwohl es nicht erforderlich und nicht immer möglich ist, empfiehlt es sich, eine Systemdiagnose zu verwenden, deren Protokoll dem Protokoll des Backend-Dienstes entspricht. So lässt sich beispielsweise mit einer HTTP/2-Systemdiagnose die HTTP/2-Konnektivität zu Back-Ends am genauesten testen. Im Gegensatz dazu unterstützen regionale externe Application Load Balancer, die Hybrid-NEG-Backends verwenden, keine gRPC-Systemdiagnosen. Eine Liste der unterstützten Systemdiagnoseprotokolle finden Sie unter Load-Balancing-Features.

In der folgenden Tabelle wird der Bereich der Systemdiagnosen angegeben, die von externen Application Load Balancern in den einzelnen Modi unterstützt werden.

Weitere Informationen zu Systemdiagnosen finden Sie hier:

• Übersicht über Systemdiagnosen
• Systemdiagnosen erstellen

Firewallregeln

Für den Load Balancer sind die folgenden Firewallregeln erforderlich:

• Für den regionalen externen Application Load Balancer ist eine Regel zum Zulassen von eingehendem Traffic erforderlich, um den Traffic aus dem Nur-Proxy-Subnetz zu Ihren Back-Ends zuzulassen.
• Eine Regel zum Zulassen von eingehendem Traffic, um Traffic von den Bereichen der Systemdiagnoseprüfungen zuzulassen. Weitere Informationen zu Systemdiagnoseprüfungen und dazu, warum Traffic von ihnen zugelassen werden muss, finden Sie unter Prüfungs-IP-Bereiche und Firewallregeln.

Firewallregeln werden auf VM-Instanzebene und nicht auf GFE-Proxys implementiert. Sie können keine Cloud de Confiance Firewallregeln verwenden, um zu verhindern, dass Traffic den Load Balancer erreicht.

Die Ports für diese Firewallregeln müssen so konfiguriert werden:

• Lassen Sie Traffic zum Zielport für die Systemdiagnose der einzelnen Backend-Dienste zu.

• Instanzgruppen-Backends: Bestimmen Sie die Ports, die durch die Zuordnung zwischen dem benannten Port des Backend-Dienstes und den mit diesem benannten Port verknüpften Portnummern in jeder Instanzgruppe konfiguriert werden sollen. Die Portnummern können je nach Instanzgruppe, die demselben Backend-Dienst zugewiesen ist, variieren.

• GCE_VM_IP_PORT-NEG-Back-Ends: Lassen Sie Traffic zu den Portnummern der Endpunkte zu.

GKE-Support

GKE verwendet externe Application Load Balancer auf folgende Weise:

• Externe Gateways, die mit dem GKE-Gateway-Controller erstellt wurden, können jeden Modus eines externen Application Load Balancers verwenden. Sie steuern den Modus des Load Balancers, indem Sie eine GatewayClass auswählen. Der GKE-Gateway-Controller verwendet immer zonale NEG-Back-Ends vom Typ GCE_VM_IP_PORT.

  Wenn Cloud CDN für Back-Ends aktiviert ist, die vom GKE-Gateway verwaltet werden, wird das Caching mithilfe der GKE-GCPHTTPFilter-Filter konfiguriert, die an HTTPRoute-Ressourcen angehängt sind. Informationen zum Konfigurieren des Cachings finden Sie unter Cloud CDN für Gateway konfigurieren.

• Sie können von GKE-Diensten erstellte und verwaltete zonale GCE_VM_IP_PORT-NEGs als Backends für beliebige Application Load Balancer oder Proxy-Network-Load-Balancer verwenden. Weitere Informationen finden Sie unter Containernatives Load Balancing über eigenständige zonale NEGs.

Architektur einer freigegebene VPC

Externe Application Load Balancer unterstützen Netzwerke, die eine freigegebene VPC verwenden. Eine freigegebene VPC ermöglicht Organisationen, Ressourcen aus mehreren Projekten mit einem gemeinsamen VPC-Netzwerk zu verbinden, sodass sie sicher und effizient über interne IP-Adressen dieses Netzwerks miteinander kommunizieren können. Wenn Sie noch nicht mit freigegebene VPC vertraut sind, lesen Sie die Dokumentation freigegebene VPC Übersicht.

Es gibt viele Möglichkeiten, einen externen Application Load Balancer in einem freigegebene VPC-Netzwerk zu konfigurieren. Unabhängig vom Bereitstellungstyp müssen sich alle Komponenten des Load-Balancers in derselben Organisation befinden.

Sie können alle Load-Balancing-Komponenten und Backends im freigegebene VPC-Hostprojekt erstellen, aber die Zuständigkeiten für Netzwerkverwaltung und Dienstentwicklung werden bei diesem Modell nicht getrennt.

Alle Load-Balancer-Komponenten und Back-Ends in einem Dienstprojekt

Das folgende Architekturdiagramm zeigt eine standardmäßige Bereitstellung einer freigegebene VPC, bei der sich alle Load-Balancer-Komponenten und Backends in einem Dienstprojekt befinden. Dieser Bereitstellungstyp wird von allen Application Load Balancern unterstützt.

Die Komponenten und Back-Ends des Load-Balancers müssen dasselbe VPC-Netzwerk verwenden.

Projektübergreifender Dienstverweis

Die projektübergreifende Dienstreferenzierung ist ein Bereitstellungsmodell, bei dem sich das Frontend und die URL-Zuordnung des Load Balancers in einem Projekt und der Backend-Dienst und die Backends des Load Balancers in einem anderen Projekt befinden.

Mit projektübergreifenden Dienstreferenzen können Organisationen einen zentralen Load Balancer konfigurieren und Traffic an Hunderte von Diensten weiterleiten, die über mehrere verschiedene Projekte verteilt sind. Sie können alle Regeln und Richtlinien für das Traffic-Routing zentral in einer URL-Zuordnung verwalten. Sie können den Load-Balancer auch mit einem einzelnen Satz von Hostnamen und SSL-Zertifikaten verknüpfen. Sie können daher die Anzahl der für die Bereitstellung Ihrer Anwendung erforderlichen Load-Balancer optimieren und die Verwaltungs-, Betriebskosten- und Kontingentanforderungen reduzieren.

Wenn Sie für jedes Ihrer funktionalen Teams unterschiedliche Projekte verwenden, können Sie auch eine Trennung der Rollen innerhalb Ihrer Organisation erreichen. Dienstinhaber können sich auf das Erstellen von Diensten in Dienstprojekten konzentrieren, während Netzwerkteams Load-Balancer in einem anderen Projekt bereitstellen und verwalten können. Beide Dienste können über projektübergreifende Dienstreferenzen verbunden werden.

Dienstinhaber können die Autonomie der Freigabe ihrer Dienste aufrechterhalten und steuern, welche Nutzer über den Load-Balancer auf ihre Dienste zugreifen können. Dies wird durch eine spezielle IAM-Rolle mit der Bezeichnung Nutzer von Compute-Load-Balancer-Diensten (roles/compute.loadBalancerServiceUser) erreicht.

Die Unterstützung für projektübergreifende Dienstreferenzen hängt vom Typ des Load Balancers ab:

• Für globale externe Application Load Balancer: Das Frontend und die URL-Zuordnung Ihres Load Balancers können auf Backend-Dienste oder Backend-Buckets aus einem beliebigen Projekt innerhalb derselben Organisation verweisen. Es gelten keine Einschränkungen für VPC-Netzwerk. Sie können eine freigegebene VPC-Umgebung verwenden, um eine projektübergreifende Bereitstellung zu konfigurieren, wie in diesem Beispiel gezeigt. Dies ist jedoch nicht erforderlich.

• Für regionale externe Application Load Balancer: Sie müssen den Load Balancer in einer freigegebene VPC-Umgebung erstellen. Das Frontend und die URL-Zuordnung des Load Balancers müssen sich in einem Host- oder Dienstprojekt befinden. Die Backend-Dienste und Backends des Load Balancers können auf Host- oder Dienstprojekte in derselben freigegebene VPC-Umgebung verteilt werden.

Informationen zum Konfigurieren der freigegebene VPC für einen regionalen externen Application Load Balancer mit und ohne projektübergreifenden Dienstverweis finden Sie unter Regionalen externen Application Load Balancer mit gemeinsam genutzter VPC einrichten.

Hinweise zur Verwendung von projektübergreifenden Dienstverweisen

• Cloud de Confiance unterscheidet nicht zwischen Ressourcen (z. B. Backend-Diensten), die in mehreren Projekten denselben Namen verwenden. Wenn Sie projektübergreifende Dienstverweise verwenden, empfehlen wir daher, eindeutige Backend-Dienstnamen für alle Projekte in Ihrer Organisation zu verwenden.
• Wenn Sie einen Fehler wie „Projektübergreifende Verweise für diese Ressource sind nicht zulässig“ sehen, prüfen Sie, ob Sie die Berechtigung zur Verwendung der Ressource haben. Ein Administrator des Projekts, dem die Ressource gehört, muss Ihnen die Rolle „Nutzer von Compute-Load-Balancer-Diensten“ (roles/compute.loadBalancerServiceUser) zuweisen. Diese Rolle kann auf Projekt- oder Ressourcenebene zugewiesen werden. Ein Beispiel finden Sie unter Dem Compute-Load-Balancer-Administrator die Berechtigungen erteilen, den Backend-Dienst oder den Backend-Bucket zu verwenden.

Beispiel 1: Load-Balancer-Frontend und -Backend in verschiedenen Dienstprojekten

Im Folgenden finden Sie ein Beispiel für eine Bereitstellung mit freigegebene VPC, bei der das Frontend und die URL-Zuordnung des Load-Balancers in Dienstprojekt A erstellt werden. Die URL-Zuordnung verweist auf einen Backend-Dienst in Dienstprojekt B.

In diesem Fall benötigen Netzwerkadministratoren oder Load-Balancer-Administratoren im Dienstprojekt A Zugriff auf Backend-Dienste im Dienstprojekt B. Administratoren des Dienstprojekts B gewähren Load-Balancer-Administratoren im Dienstprojekt A, die auf den Backend-Dienst im Dienstprojekt B verweisen möchten, die Rolle „Nutzer von Compute-Load-Balancer-Diensten“ (roles/compute.loadBalancerServiceUser).

Beispiel 2: Load-Balancer-Frontend im Hostprojekt und Back-Ends in Dienstprojekten

Im Folgenden finden Sie ein Beispiel für eine Bereitstellung mit einer freigegebene VPC, bei der das Frontend und die URL-Zuordnung des Load Balancers im Hostprojekt und die Backend-Dienste (und Backends) in Dienstprojekten erstellt werden.

In diesem Fall benötigen Netzwerkadministratoren oder Load-Balancer-Administratoren im Hostprojekt Zugriff auf Backend-Dienste im Dienstprojekt. Dienstprojektadministratoren erteilen Load-Balancer-Administratoren im Hostprojekt A, die auf den Backend-Dienst im Dienstprojekt verweisen möchten, die Rolle „Nutzer von Compute-Load-Balancer-Diensten“ (roles/compute.loadBalancerServiceUser).

Beispiel 3: Load-Balancer-Frontend und -Backends in verschiedenen Projekten

Im Folgenden finden Sie ein Beispiel für eine Bereitstellung, bei der das Frontend und die URL-Zuordnung des globalen externen Application Load Balancers in einem anderen Projekt als der Backend-Dienst und die Backends des Load Balancers erstellt werden. Bei dieser Art der Bereitstellung wird keine freigegebene VPC verwendet. Sie wird nur für globale externe Application Load Balancer unterstützt.

Weitere Informationen zu dieser Einrichtung finden Sie unter Projektübergreifende Dienstreferenzierung mit einem Backend-Dienst und einem Backend-Bucket einrichten.

Hochverfügbarkeit und Failover

Hochverfügbarkeit und Failover in externen Application Load Balancern können auf Load-Balancer-Ebene konfiguriert werden. Dazu werden regionale externe Sicherungs-Application Load Balancer in jeder Region erstellt, in der Sie eine Sicherung benötigen.

In der folgenden Tabelle wird das Failover-Verhalten beschrieben.

HTTP/2-Unterstützung

HTTP/2 ist eine wesentliche Überarbeitung des HTTP/1-Protokolls. Es gibt zwei Modi der HTTP/2-Unterstützung:

• HTTP/2 über TLS
• HTTP/2-Klartext über TCP

HTTP/2 über TLS

HTTP/2 über TLS wird für Verbindungen zwischen Clients und dem externen Application Load Balancer sowie für Verbindungen zwischen dem Load Balancer und seinen Backends unterstützt.

Der Load Balancer verhandelt automatisch HTTP/2 mit Clients als Teil des TLS-Handshakes und verwendet dazu die ALPN TLS-Erweiterung. Auch wenn ein Load Balancer für die Verwendung von HTTPS konfiguriert ist, verwenden moderne Clients standardmäßig HTTP/2. Dies wird auf dem Client gesteuert, nicht auf dem Load Balancer.

Wenn ein Client HTTP/2 nicht unterstützt und der Load Balancer für die Verwendung von HTTP/2 zwischen dem Load Balancer und den Backend-Instanzen konfiguriert ist, kann er trotzdem eine HTTPS-Verbindung aushandeln oder unsichere HTTP-Anfragen akzeptieren. Diese HTTPS- oder HTTP-Anfragen werden dann vom Load-Balancer transformiert, um die Anfragen über HTTP/2 an die Backend-Instanzen weiterzuleiten.

Wenn Sie HTTP/2 über TLS verwenden möchten, müssen Sie TLS auf Ihren Backends aktivieren und das Backend-Dienstprotokoll auf HTTP2 festlegen. Weitere Informationen finden Sie unter Verschlüsselung vom Load Balancer zu Backends.

Maximale Anzahl gleichzeitiger HTTP/2-Streams

Die HTTP/2-Einstellung SETTINGS_MAX_CONCURRENT_STREAMS beschreibt die maximale Anzahl von Streams, die ein Endpunkt akzeptiert, die vom Peer initiiert wurden. Der von einem HTTP/2-Client zu einemCloud de Confiance -Load-Balancer angekündigte Wert hat quasi keine Bedeutung, da der Load-Balancer keine Streams an den Client initiiert.

In Fällen, in denen der Load Balancer HTTP/2 für die Kommunikation mit einem Server verwendet, der auf einer VM ausgeführt wird, berücksichtigt der Load Balancer den vom Server angekündigten Wert SETTINGS_MAX_CONCURRENT_STREAMS bis zu einem Höchstwert von 100. In der Anfragerichtung (Cloud de Confiance Load Balancer → gRPC-Server) verwendet der Load Balancer den ersten SETTINGS-Frame vom gRPC-Server, um zu bestimmen, wie viele Streams pro Verbindung gleichzeitig verwendet werden können. Wenn der Server einen Wert höher als 100 angibt, verwendet der Load Balancer 100 als maximale Anzahl gleichzeitiger Streams. Wenn ein Wert von null angekündigt wird, kann der Load-Balancer keine Anfragen an den Server weiterleiten. Das kann zu Fehlern führen.

Größe der dynamischen HTTP/2-Headertabelle

HTTP/2 bietet gegenüber HTTP/1.1 erhebliche Verbesserungen, z. B. Multiplexing und HPACK-Header-Komprimierung. HPACK verwendet eine dynamische Tabelle, die die Header-Komprimierung verbessert und alles beschleunigt. Informationen zu den Auswirkungen von dynamischen Änderungen der Header-Tabellengröße in HTTP/2, wie diese Funktion die Leistung verbessern kann und wie ein bestimmter Fehler in verschiedenen HTTP-Clientbibliotheken Probleme bei der HPACK-Header-Komprimierung verursachen kann, finden Sie im Community-Artikel.

HTTP/2-Einschränkungen

• HTTP/2 zwischen dem Load Balancer und der Instanz kann wesentlich mehr TCP-Verbindungen zur Instanz benötigen als HTTP oder HTTPS. Verbindungs-Pooling, eine Optimierung, die die Anzahl dieser Verbindungen bei HTTP oder HTTPS reduziert, ist bei HTTP/2 nicht möglich. Dies kann zu hohen Backend-Latenzen führen, da Backend-Verbindungen häufiger hergestellt werden.
• HTTP/2 zwischen dem Load Balancer und dem Backend unterstützt keinen Server-Push.
• Die gRPC-Fehlerrate und das Anfragevolumen sind in derCloud de Confiance API oder der Cloud de Confiance Console nicht sichtbar. Wenn der gRPC-Endpunkt einen Fehler zurückgibt, melden die Load-Balancer-Logs und die Monitoring-Daten den HTTP-Statuscode 200 OK.

HTTP/2 über Klartext-TCP

Mit HTTP/2 über Klartext-TCP, dargestellt durch den String „h2c“ gemäß RFC 7540, können Sie HTTP/2 ohne TLS-Verschlüsselung verwenden. Sie wird für die folgenden Verbindungen unterstützt:

• Client zu Load Balancer: Wird automatisch auf regionalen externen Application Load Balancern unterstützt. Es ist keine spezielle Konfiguration erforderlich.

• Load-Balancer zu seinen Backends: Unterstützt durch Festlegen des Backend-Dienstprotokolls auf H2C.

H2C-Unterstützung ist auch für Load Balancer verfügbar, die mit dem GKE-Gateway-Controller und Cloud Service Mesh erstellt wurden.

WebSocket-Unterstützung

Cloud de Confiance HTTP(S)-basierte Load Balancer unterstützen das WebSocket-Protokoll, wenn Sie HTTP/1.1 (HTTP oder HTTPS) oder HTTP/2 als Protokoll für das Backend verwenden. Der Load Balancer benötigt zum Weiterleiten von WebSocket-Verbindungen über einen Proxy keine Konfiguration.

Das WebSocket-Protokoll bietet einen Vollduplex-Kommunikationskanal zwischen Clients und dem Load Balancer. Weitere Informationen finden Sie unter RFC 6455.

Bei HTTP/1.1-Verbindungen verwendet das WebSocket-Protokoll den HTTP/1.1-Mechanismus Upgrade, um eine TCP-Verbindung von HTTP in eine WebSocket-Verbindung umzuwandeln. Das WebSocket-Protokoll über HTTP/1.1 funktioniert so:

1. Der Load Balancer erkennt eine WebSocket-Upgrade-Anfrage von einem HTTP- oder HTTPS-Client. Die Anfrage enthält die Header Connection: Upgrade und Upgrade: websocket, gefolgt von anderen relevanten WebSocket-bezogenen Anfrageheadern.
2. Das Backend sendet eine WebSocket-Upgrade-Antwort. Diese besteht aus einer 101 Switching Protocols-Antwort mit Connection: Upgrade- und Upgrade: websocket-Headern sowie anderen WebSocket-bezogenen Antwortheadern.
3. Der Load Balancer leitet für die Dauer der aktuellen Verbindung bidirektionalen Traffic über einen Proxy weiter.

Wenn die Backend-Instanz den Statuscode HTTP 426 oder HTTP 502 zurückgibt, schließt der Load Balancer die Verbindung.

Bei HTTP/2-Verbindungen verwendet das WebSocket-Protokoll die erweiterte CONNECT-Methode zusammen mit Pseudo-Header-Feldern (z. B. :protocol), um einen Tunnel in einem einzelnen HTTP/2-Stream zu erstellen, der Daten für WebSockets übertragen kann (RFC 8441). Das WebSocket-Protokoll über HTTP/2 funktioniert so:

1. Der Backend-Server sendet einen HTTP/2-SETTINGS-Frame, in dem der Parameter SETTINGS_ENABLE_CONNECT_PROTOCOL auf 1 gesetzt ist. Dadurch wird dem Load Balancer mitgeteilt, dass das Backend die erweiterte CONNECT-Methode unterstützt.

2. Wenn der Load Balancer diese Einstellung empfängt, erkennt er sie und kann WebSocket-Upgradeanfragen weiterleiten. Die Upgradeanfrage wird mit der erweiterten CONNECT-Methode an das Backend gesendet. Die Anfrage enthält die Pseudo-Header :method: CONNECT und :protocol: websocket sowie andere relevante WebSocket-bezogene Anfrageheader.

3. Das Backend sendet eine WebSocket-Erfolgsantwort. Der Backend-Server sendet eine 200 OK-Antwort (anstelle der in HTTP/1.1 verwendeten 101 Switching Protocols-Antwort), um den WebSocket-Tunnel über einen einzelnen Stream einer HTTP/2-Verbindung einzurichten.

4. Der Load Balancer leitet bidirektionalen Traffic über den eingerichteten HTTP/2-Stream weiter.

Wenn die Backend-Instanz den Statuscode 426 oder 502 zurückgibt, erfolgt kein WebSocket-Upgrade und der Statuscode wird an den Client weitergegeben.

Die Sitzungsaffinität für WebSockets funktioniert wie für jede andere Anfrage. Weitere Informationen finden Sie unter Sitzungsaffinität.

gRPC-Unterstützung

gRPC ist ein Open Source-Framework für Remote-Prozeduraufrufe. Es basiert auf dem HTTP/2-Standard. Anwendungsfälle für gRPC sind:

• Hoch skalierbare, verteilte Systeme mit geringer Latenz
• Entwicklung mobiler Clients, die mit einem Cloud-Server kommunizieren
• Entwurf neuer Protokolle, die genau, effizient und sprachunabhängig sein müssen
• Layerdesign, um Erweiterung, Authentifizierung und Protokollierung zu ermöglichen

Wenn Sie gRPC mit Ihren Cloud de Confiance -Anwendungen verwenden möchten, müssen Sie Anfragen End-to-End über HTTP/2 weiterleiten. Dazu erstellen Sie einen Application Load Balancer mit einer der folgenden Konfigurationen:

• HTTP/2 über TLS zwischen dem Client und dem Load Balancer und H2C zwischen dem Load Balancer und dem Backend: Sie erstellen einen HTTPS-Load-Balancer (konfiguriert mit einem HTTPS-Zielproxy und einem SSL-Zertifikat). Außerdem konfigurieren Sie den Load Balancer so, dass er HTTP/2 für unverschlüsselte Verbindungen zwischen dem Load Balancer und seinen Backends verwendet. Dazu setzen Sie das Protokoll des Backend-Dienstes auf H2C.

• Ende-zu-Ende-verschlüsselter Traffic mit HTTP/2 über TLS: Sie erstellen einen HTTPS-Load-Balancer (konfiguriert mit einem HTTPS-Zielproxy und einem SSL-Zertifikat). Der Load Balancer verhandelt HTTP/2 mit Clients als Teil des SSL-Handshakes und verwendet dazu die ALPN TLS-Erweiterung.

  Außerdem müssen Sie dafür sorgen, dass die Backends TLS-Traffic verarbeiten können, und den Load Balancer so konfigurieren, dass er HTTP/2 für verschlüsselte Verbindungen zwischen dem Load Balancer und seinen Backends verwendet. Dazu legen Sie das Backend-Dienstprotokoll auf HTTP2 fest.

  Der Load Balancer kann mit einigen Clients weiter HTTPS aushandeln oder unsichere HTTP-Anfragen auf einem Load Balancer akzeptieren, der für die Verwendung von HTTP/2 zwischen dem Load Balancer und den Backend-Instanzen konfiguriert ist. Diese HTTP- oder HTTPS-Anfragen werden vom Load Balancer transformiert, um die Anfragen über HTTP/2 an die Backend-Instanzen weiterzuleiten.

Informationen zum Konfigurieren eines Application Load Balancers mit HTTP/2 mit Google Kubernetes Engine Ingress oder mit gRPC und HTTP/2 finden Sie unter HTTP/2 für Load Balancing mit Ingress.

Informationen zum Konfigurieren eines externen Application Load Balancers mit HTTP/2 mit Cloud Run finden Sie unter HTTP/2 hinter einem Load Balancer verwenden.

Informationen zur Fehlerbehebung bei HTTP/2 finden Sie unter Fehlerbehebung für HTTP/2 zu den Back-Ends.

Informationen zu Einschränkungen von HTTP/2 finden Sie unter HTTP/2-Einschränkungen.

TLS-Support

Standardmäßig akzeptiert ein HTTPS-Ziel-Proxy nur TLS 1.0, 1.1, 1.2 und 1.3, wenn SSL-Anfragen von Clients beendet werden.

Wenn der klassische Application Load Balancer HTTPS als Backend-Dienstprotokoll verwendet, kann er TLS 1.0, 1.1, 1.2 oder 1.3 mit dem Backend aushandeln.

Unterstützung für gegenseitiges TLS

Gegenseitiges TLS (mTLS) ist ein Branchenstandardprotokoll für die gegenseitige Authentifizierung zwischen einem Client und einem Server. mTLS trägt dazu bei, dass sich sowohl der Client als auch der Server gegenseitig authentifizieren. Dazu wird geprüft, ob beide ein gültiges Zertifikat haben, das von einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) ausgestellt wurde. Im Gegensatz zu Standard-TLS, bei dem nur der Server authentifiziert wird, müssen bei mTLS sowohl der Client als auch der Server Zertifikate vorlegen, um die Identität beider Parteien zu bestätigen, bevor die Kommunikation hergestellt wird.

Alle Application Load Balancer unterstützen mTLS. Bei mTLS fordert der Load Balancer an, dass der Client während des TLS-Handshakes mit dem Load Balancer ein Zertifikat sendet, um sich zu authentifizieren. Sie können einen Trust Store im Zertifikatmanager konfigurieren, mit dem der Load Balancer dann die Vertrauenskette des Clientzertifikats validiert.

Weitere Informationen zu mTLS finden Sie unter Gegenseitige TLS-Authentifizierung.

Unterstützung für TLS 1.3 Early Data

TLS 1.3 Early Data wird auf dem HTTPS-Zielproxy der folgenden externen Application Load Balancer sowohl für HTTPS über TCP (HTTP/1.1, HTTP/2) als auch für HTTP/3 über QUIC unterstützt:

• Globale externe Application Load Balancer
• Klassische Application Load Balancer

TLS 1.3 wurde in RFC 8446 definiert und führt das Konzept von Early Data ein, auch bekannt als Zero-Umlaufzeit-Daten (0-RTT), die die Anwendungsleistung für fortgesetzte Verbindungen um 30 % bis 50 % verbessern können.

Bei TLS 1.2 sind zwei Hin- und Rückflüge erforderlich, bevor Daten sicher übertragen werden können. TLS 1.3 reduziert dies auf einen Roundtrip (1-RTT) für neue Verbindungen, sodass Clients Anwendungsdaten sofort nach der ersten Serverantwort senden können. Darüber hinaus wird mit TLS 1.3 das Konzept von Early Data für fortgesetzte Sitzungen eingeführt. Dadurch können Clients Anwendungsdaten mit dem ersten ClientHello senden, was die effektive Roundtrip-Zeit auf null (0-RTT) reduziert. Mit TLS 1.3 Early Data kann der Backend-Server mit der Verarbeitung von Clientdaten beginnen, bevor der Handshake-Prozess mit dem Client abgeschlossen ist. Dadurch wird die Latenz reduziert. Es muss jedoch darauf geachtet werden, Replay-Risiken zu minimieren.

Da „Early Data“ vor Abschluss des Handshakes gesendet werden, kann ein Angreifer versuchen, Anfragen abzufangen und zu wiederholen. Um dies zu vermeiden, muss der Backend-Server die Nutzung von Early Data sorgfältig kontrollieren und auf idempotente Anfragen beschränken. HTTP-Methoden, die idempotent sein sollen, aber nicht idempotente Änderungen auslösen können (z. B. eine GET-Anfrage, die eine Datenbank ändert), dürfen keine Early Data akzeptieren. In solchen Fällen muss der Backend-Server Anfragen mit dem HTTP-Header Early-Data: 1 ablehnen, indem er einen HTTP-Statuscode 425 Too Early zurückgibt.

Bei Anfragen mit Early Data ist der HTTP-Early-Data-Header auf den Wert 1 gesetzt. Das zeigt dem Backend-Server, dass die Anfrage in TLS-Early-Data übertragen wurde. Außerdem wird damit angegeben, dass der Client den HTTP-Statuscode 425 Too Early versteht.

TLS-Early-Data-Modi (0-RTT)

Sie können TLS Early Data mit einem der folgenden Modi für die HTTPS-Zielproxy-Ressource des Load Balancers konfigurieren.

• STRICT. Dadurch wird TLS 1.3 Early Data für Anfragen mit sicheren HTTP-Methoden (GET, HEAD, OPTIONS, TRACE) und HTTP-Anfragen ohne Suchparameter aktiviert. Anfragen, die Early Data mit nicht idempotenten HTTP-Methoden (z. B. POST oder PUT) oder mit Suchparametern senden, werden mit dem HTTP-Statuscode 425 abgelehnt.

• PERMISSIVE. Dadurch wird TLS 1.3 Early Data für Anfragen mit sicheren HTTP-Methoden (GET, HEAD, OPTIONS, TRACE) aktiviert. In diesem Modus werden Anfragen mit Suchparametern nicht abgelehnt. Der Anwendungsinhaber muss dafür sorgen, dass die Verwendung von Early Data für jeden Anfragepfad sicher ist, insbesondere für Endpunkte, bei denen die Wiederholung von Anfragen unbeabsichtigte Nebenwirkungen verursachen kann, z. B. Logging oder Datenbankaktualisierungen, die durch GET-Anfragen ausgelöst werden.

• DISABLED. TLS 1.3 Early Data wird nicht beworben und alle (ungültigen) Versuche, Early Data zu senden, werden abgelehnt. Wenn Ihre Anwendungen nicht für die sichere Verarbeitung von Early Data-Anfragen ausgelegt sind, müssen Sie Early Data deaktivieren. TLS 1.3 Early Data ist standardmäßig deaktiviert.

• UNRESTRICTED (für die meisten Arbeitslasten nicht empfohlen). Dadurch werden TLS 1.3-Early Data für Anfragen mit beliebigen HTTP-Methoden aktiviert, einschließlich nicht idempotenter Methoden wie POST. Dieser Modus erzwingt keine weiteren Beschränkungen. Dieser Modus kann für gRPC-Anwendungsfälle nützlich sein. Wir empfehlen diese Methode jedoch nur, wenn Sie Ihren Sicherheitsstatus bewertet und das Risiko von Replay-Angriffen mit anderen Mechanismen minimiert haben.

TLS Early Data konfigurieren

So aktivieren oder deaktivieren Sie TLS Early Data explizit:

PATCH https://compute.googleapis.com/compute/v1/projects/{project}/global/targetHttpsProxies/TARGET_HTTPS_PROXY
{
    "tlsEarlyData":"TLS_EARLY_DATA_MODE",
    "fingerprint": "FINGERPRINT"
}

Nachdem Sie TLS Early Data konfiguriert haben, können Sie Anfragen von einem HTTP-Client senden, der TLS Early Data unterstützt. Bei fortgesetzten Anfragen ist die Latenz geringer.

Wenn ein nicht RFC-konformer Client eine Anfrage mit einer nicht idempotenten Methode oder mit Suchparametern sendet, wird die Anfrage abgelehnt. In den Load-Balancer-Logs wird der HTTP-Statuscode 425 Early und die folgende HTTP-Antwort angezeigt:

  HTTP/1.1 425 Too Early
  Content-Type: text/html; charset=UTF-8
  Referrer-Policy: no-referrer
  Content-Length: 1558
  Date: Thu, 03 Aug 2024 02:45:14 GMT
  Connection: close
  <!DOCTYPE html>
  <html lang=en>
  <title>Error 425 (Too Early)</title>
  <p>The request was sent to the server too early, please retry. That's
  all we know.</p>
  </html>
  

Google-Tag-Gateway für Werbetreibende

Mit dem Google-Tag-Gateway können Websiteinhaber Google-Tags über Google Cloud hosten und bereitstellen. Mit diesen Google-Tags können Sie den Traffic auf Ihrer Website analysieren. Sie können einen globalen externen Application Load Balancer verwenden, um den Mess-Traffic auf Ihrer Website über Ihre Domain weiterzuleiten und so die Genauigkeit der Messdaten zu verbessern. So erhalten Sie zuverlässigere Daten für die Optimierung von Werbekampagnen.

Das Google-Tag-Gateway wird nur auf globalen externen Application Load Balancern unterstützt. Wenn Sie einen klassischen Application Load Balancer verwenden, migrieren Sie Ihre Ressourcen vom klassischen zum globalen externen Application Load Balancer.

Die Konfiguration und Verwaltung des Google-Tag-Gateways erfolgt außerhalb der Cloud de Confiance Console. Sie müssen diese Funktion über die Google Tag Manager-Oberfläche konfigurieren.

• In der Cloud de Confiance Console wird auf der Seite Details zum Load Balancer eine schreibgeschützte visuelle Anzeige eingeblendet, die angibt, dass das Google-Tag-Gateway aktiviert ist.
• Sie können die Google-Tag-Gateway-Konfiguration nicht über dieCloud de Confiance Console bearbeiten oder löschen.

Eine vollständige Anleitung zum Einrichten des Google-Tag-Gateways für Werbetreibende finden Sie unter Google-Tag-Gateway für Werbetreibende einrichten.

Die Konfiguration wird zwar mit Google Ads verwaltet, die Anfrageverarbeitung und die Google-Tag-Injektionen, die vom Gateway ausgeführt werden, werden jedoch im Logging und Monitoring Ihres globalen externen Application Load Balancers aufgezeichnet. Weitere Informationen finden Sie unter Logging und Monitoring für globale externe Application Load Balancer.

Informationen zur Fehlerbehebung bei Problemen mit Google-Tag-Gateways finden Sie unter Probleme beim Einfügen des Google-Tag-Gateways beheben.

Wenn bei der Einrichtung Probleme auftreten, die sich nicht mithilfe der Dokumentation beheben lassen, wenden Sie sich an den Google Ads-Support.

Beschränkungen

• HTTPS-Load-Balancer senden keine Benachrichtigung zum Schließen close_notify, wenn SSL-Verbindungen beendet werden. Das heißt, der Load-Balancer schließt die TCP-Verbindung, statt einen SSL-Shutdown auszuführen.

• HTTPS-Load-Balancer unterstützen nur Kleinbuchstaben in Domains mit einem gemeinsamen Namen (CN) oder einem alternativen Antragstellernamen (SAN) des Zertifikats. Zertifikate mit Großbuchstaben in Domains werden nur zurückgegeben, wenn sie als primäres Zertifikat im Ziel-Proxy festgelegt wurden.

• HTTPS-Load-Balancer verwenden beim Herstellen einer Verbindung zum Backend nicht die Erweiterung „Server Name Indication“ (SNI), mit Ausnahme von Load-Balancern mit Internet-NEG-Backends. Weitere Informationen finden Sie unter Verschlüsselung vom Load Balancer zu Backends.

• Cloud de Confiance kann nicht garantieren, dass eine zugrunde liegende TCP-Verbindung während des gesamten festgelegten Zeitlimits für den Backend-Dienst geöffnet bleibt. Clientsysteme müssen eine Wiederholungslogik implementieren, anstatt sich auf eine TCP-Verbindung zu verlassen, die über einen längeren Zeitraum offen ist.

• Wenn Sie einen regionalen externen Application Load Balancer in der Premium-Stufe mit derCloud de Confiance Console erstellen, sind in der Cloud de Confiance Console nur Regionen verfügbar, die die Standardstufe unterstützen. Verwenden Sie für den Zugriff auf andere Regionen entweder die gcloud CLI oder die API.

Nächste Schritte

• Informationen zum Bereitstellen eines regionalen externen Application Load Balancers finden Sie unter Regionalen externen Application Load Balancer mit einem Compute Engine-Backend einrichten.

• Informationen zum Konfigurieren erweiterter Trafficverwaltungsfunktionen, die mit dem regionalen externen Application Load Balancer verfügbar sind, finden Sie unter Übersicht über die Trafficverwaltung für regionale externe Application Load Balancer.