Ü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 Back-Ends, die auf einer Vielzahl von Google Cloud-Plattformen wie Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage usw. gehostet werden, sowie auf externe Back-Ends, die über das Internet oder Hybridkonnektivität verbunden sind. Weitere Informationen finden Sie unter Application Load Balancer: Anwendungsfälle.

Betriebsarten

Sie können einen externen Application Load Balancer in den folgenden Modi konfigurieren:

• Globaler externer Application Load Balancer. Dies ist ein globaler Load-Balancer, der als verwalteter Dienst auf Google Front Ends (GFEs) implementiert ist. Der Open-Source-Envoy-Proxy unterstützt erweiterte Funktionen zur Trafficverwaltung wie Trafficspiegelung, gewichtete Trafficaufteilung, anfrage- und antwortbasierte Header-Transformationen und mehr.
• Klassischer Application Load Balancer. Dies ist der klassische externe Application Load Balancer, der in der Premium-Stufe global ist, aber als regionale Standardstufe konfiguriert werden kann. Dieser Load-Balancer ist auf Google Front Ends (GFEs) implementiert. GFEs sind global verteilt und arbeiten über das globale Netzwerk und die Steuerungsebene von Google zusammen.
• Regionaler externer Application Load Balancer. Dies ist ein regionaler Load-Balancer, der als verwalteter Dienst im Open-Source-Envoy-Proxy implementiert ist. Dazu gehören erweiterte Funktionen zur Trafficverwaltung wie Trafficspiegelung, gewichtete Trafficaufteilung, Anfrage/Antwort-basierte Headertransformationen und mehr.

Load-Balancer-Modus	Empfohlene Anwendungsfälle	Leistungsspektrum
Globaler externer Application Load Balancer	Verwenden Sie diesen Load-Balancer für externe HTTP(S)-Arbeitslasten mit global verteilten Nutzern oder Backend-Diensten in mehreren Regionen.	Kompatibel mit GKE mithilfe von Gateway (vollständig orchestriert) oder eigenständigen NEGs (manuelle Orchestrierung). Unterstützt die erweiterte Trafficverwaltung Globale externe Anycast-IP-Adressen über Premium-Stufe Kann auf Back-Ends über mehrere Regionen zugreifen Unterstützt Cloud CDN. Unterstützt Google Cloud Armor
Klassischer Application Load Balancer	Dieser Load-Balancer ist in der Premium-Stufe global, kann aber als regional in der Standardstufe konfiguriert werden. In der Premium-Netzwerkdienststufe bietet dieser Load-Balancer multiregionales Load-Balancing, versucht, Traffic an das nächstgelegene fehlerfreie Backend mit Kapazität weiterzuleiten, und beendet HTTP(S)-Traffic so nah wie möglich an Ihren Nutzern. Weitere Informationen zum Ablauf der Anfragenverteilung finden Sie unter Trafficverteilung. In der Standard-Netzwerkdienststufe wird das Load-Balancing regional verarbeitet.	Kompatibel mit GKE mithilfe von Gateway (vollständig orchestriert), Ingress (vollständig orchestriert) oder eigenständigen NEGs (manuelle Orchestrierung). Unterstützt Google Cloud Armor Weniger Traffic-Routing-Features Eine vollständige Liste der Funktionen finden Sie auf der Seite Load-Balancing-Features.
Regionaler externer Application Load Balancer	Dieser Load Balancer enthält viele Features des bestehenden klassischen Application Load Balancers sowie erweiterte Funktionen für die Trafficverwaltung. Verwenden Sie diesen Load Balancer, wenn Sie Inhalte nur über eine bestimmte Standortbestimmung bereitstellen möchten, um beispielsweise Compliance-Bestimmungen zu erfüllen. Dieser Load Balancer kann entweder in der Premium- oder der Standardstufe konfiguriert werden.	Kompatibel mit GKE mithilfe von eigenständigen NEGs (manuelle Orchestrierung) Unterstützt erweiterte Funktionen zur Trafficverwaltung Regionale VIPs in der Standard-Netzwerkstufe Terminiert TLS in einer von Ihnen konfigurierten Region Stellt nur Inhalte aus der konfigurierten Region bereit Eine vollständige Liste finden Sie unter Load-Balancing-Features.

Modus bestimmen

Cloud Console

1. Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.
   Gehe zu „Load-Balancing“

2. Auf dem Tab Load-Balancer werden der Typ, das Protokoll und die Region des Load-Balancers angezeigt. Wenn die Region leer ist, ist der Load-Balancer global. In der folgenden Tabelle wird zusammengefasst, wie Sie den Modus des Load-Balancers bestimmen.

   Load-Balancer-Modus	Load Balancer-Typ	Zugriffstyp	Region
   Globaler externer Application Load Balancer	Anwendung	Extern
   Klassischer Application Load Balancer	Anwendung (klassisch)	Extern
   Regionaler externer Application Load Balancer	Anwendung	Extern	Gibt eine Region an

gcloud

1. Führen Sie den folgenden Befehl aus, um den Modus eines Load-Balancers zu bestimmen:

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

   Prüfen Sie in der Befehlsausgabe das Load-Balancing-Schema, die Region und die Netzwerkstufe. In der folgenden Tabelle wird zusammengefasst, wie Sie den Modus des Load-Balancers bestimmen.

   Load-Balancer-Modus	Load-Balancing-Schema	Weiterleitungsregel	Netzwerkstufe
   Globaler externer Application Load Balancer	EXTERNAL_MANAGED	Global	Premium-Support
   Klassischer Application Load Balancer	EXTERN	Global	Standard oder Premium
   Regionaler externer Application Load Balancer	EXTERNAL_MANAGED	Gibt eine Region an	Standard oder Premium

Wichtig: Nachdem Sie einen Load-Balancer erstellt haben, können Sie seinen Modus nicht mehr bearbeiten. Stattdessen müssen Sie den Load-Balancer löschen und einen neuen erstellen.

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. Die globalen externen Application Load Balancer unterstützen auch Backend-Buckets.

  • Ein oder mehrere Backends müssen mit dem Backend-Dienst oder Backend-Bucket verbunden sein.

• 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.

Global

Dieses Diagramm zeigt die Komponenten der Bereitstellung eines globalen externen Application Load Balancers. Diese Architektur gilt sowohl für den globalen externen Application Load Balancer als auch für den klassischen Application Load Balancer in der Premium-Stufe.

Komponenten des globalen externen Application Load Balancers

Regional

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

Komponenten eines regionalen externen Application Load Balancers

Nur-Proxy-Subnetz

Nur-Proxy-Subnetze sind nur für regionale externe Application Load Balancer erforderlich.

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.

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 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.

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 IP-Adresse entweder selbst angeben oder von Cloud Load Balancing zuweisen lassen.

Jede Weiterleitungsregel für einen Application Load Balancer kann auf einen einzelnen Port von 1–65535 verweisen. Damit mehrere Ports unterstützt werden können, 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.

Load-Balancer-Modus	Netzwerkdienststufe	Weiterleitungsregel, IP-Adresse und Load-Balancing-Schema	Routing aus dem Internet zum Frontend des Load-Balancers
Globaler externer Application Load Balancer	Premium-Stufe	Globale externe Weiterleitungsregel Globale externe IP-Adresse Load-Balancing-Schema: EXTERNAL_MANAGED	Anfragen, die an das GFE weitergeleitet werden, das dem Client im Internet am nächsten ist.
Klassischer Application Load Balancer	Premium-Stufe	Globale externe Weiterleitungsregel Globale externe IP-Adresse Load-Balancing-Schema: EXTERNAL	Anfragen, die an das GFE weitergeleitet werden, das dem Client im Internet am nächsten ist.
	Standardstufe	Regionale externe Weiterleitungsregel Regionale externe IP-Adresse Load-Balancing-Schema: EXTERNAL	Anfragen, die an ein GFE in der Region des Load-Balancers weitergeleitet werden
Regionaler externer Application Load Balancer	Premium- oder Standardstufe ^*	Regionale externe Weiterleitungsregel Regionale externe IP-Adresse Load-Balancing-Schema: EXTERNAL_MANAGED	Anfragen, die an die Envoy-Proxys in derselben Region wie der Load-Balancer weitergeleitet werden.

^* Sie können die Google Cloud Console nicht verwenden, um einen regionalen externen Application Load Balancer in der Premium-Stufe zu erstellen. Darüber hinaus sind für diese Load Balancer in der Google Cloud Console nur Regionen verfügbar, die die Standardstufe unterstützen. Verwenden Sie stattdessen gcloud oder API.

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.

Zielproxys

Zielproxys beenden HTTP(S)-Verbindungen von Clients. Mindestens eine Weiterleitungsregel leitet den Traffic zum Zielproxy und der Zielproxy ruft die URL-Zuordnung auf, um zu ermitteln, wie Traffic an Back-Ends 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.

Hinweis: Bei Internet-Netzwerk-Endpunktgruppen (NEGs) stammen Anfragen vom Load-Balancer aus verschiedenen IP-Bereichen, je nach Art der NEG (global oder regional). Weitere Informationen finden Sie unter Anfragen authentifizieren.

In der folgenden Tabelle ist der Typ des Zielproxys angegeben, der für externe Application Load Balancer in jedem Modus erforderlich ist.

Load-Balancer-Modus	Ziel-Proxytypen	Vom Proxy hinzugefügte Header	Unterstützte benutzerdefinierte Header	Cloud Trace wird unterstützt.
Globaler externer Application Load Balancer	Globales HTTP, globales HTTPS	Die Proxys richten HTTP-Anfrage-/Antwortheader so ein: Via: 1.1 google (Anfragen und Antworten) X-Forwarded-Proto: [http | https] (nur Anfragen) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (see X-Forwarded-For-Header) (nur Anfragen) Die Proxys können auch den Header X-Cloud-Trace-Context festlegen.	Im Backend-Dienst oder Backend-Bucket konfiguriert Wird nicht von Cloud CDN
Klassischer Application Load Balancer	Globales HTTP, globales HTTPS	Die Proxys richten HTTP-Anfrage-/Antwortheader so ein: Via: 1.1 google (Anfragen und Antworten) X-Forwarded-Proto: [http | https] (nur Anfragen) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (see X-Forwarded-For-Header) (nur Anfragen) Die Proxys können auch den Header X-Cloud-Trace-Context festlegen.	Im Backend-Dienst oder Backend-Bucket konfiguriert
Regionaler externer Application Load Balancer	Regionaler HTTP, Regionaler HTTPS	X-Forwarded-Proto: [http | https] (nur Anfragen) Via: 1.1 google (Anfragen und Antworten) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (siehe X-Forwarded-For-Header) (nur Anfragen)

Hinweis: Gemäß RFC 2616 werden die folgenden Hop-by-Hop-Header nicht vom Zielproxy weitergegeben: Connection, Keep-Alive, Proxy-Authenticate, Proxy-Authorization, TE, Trailers, Transfer-Encoding und Upgrade.

Neben den vom Zielproxy hinzugefügten Headern passt der Load Balancer andere HTTP-Header so an:

• Für den globalen externen Application Load Balancer werden sowohl Anfrage- als auch Antwortheader immer in Kleinbuchstaben umgewandelt. Beispiel: Host wird zu host und Keep-ALIVE zu keep-alive.

  Die einzige Ausnahme bildet die Verwendung globaler Internet-NEG-Backends mit HTTP/1.1. Weitere Informationen zur Verarbeitung von HTTP/1.1-Headern mit globalen Internet-NEGs finden Sie in der Übersicht über Internet-NEGs.

• Für den klassischen Application Load Balancer werden Anfrage- und Antwortheader nur in Kleinbuchstaben umgewandelt, wenn Sie HTTP/1.1 verwenden. Bei HTTP/1.1 werden Header stattdessen in der richtigen Groß- und Kleinschreibung verwendet. Der erste Buchstabe im Schlüssel des Headers und jeder Buchstabe nach einem Bindestrich (-) werden groß geschrieben, um die Kompatibilität mit HTTP/1.1-Clients zu wahren. Beispiel: user-agent wird in User-Agent geändert und content-encoding in Content-Encoding.

• 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, die durch ein einzelnes Komma getrennt sind, in der folgenden Reihenfolge an den Header X-Forwarded-For an:

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

Wenn in der eingehenden Anfrage kein X-Forwarded-For-Header vorhanden ist, stellen diese beiden IP-Adressen den gesamten Header-Wert dar.

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

Wenn die Anfrage einen X-Forwarded-For-Header enthält, behält der Load-Balancer den angegebenen Wert vor <client-ip>,<load-balancer-ip> bei:

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

Achtung: Der Load Balancer prüft keine IP-Adressen, die in diesem Header vor <client-ip>,<load-balancer-ip> stehen. Die obigen IP-Adressen können weitere Zeichen enthalten, einschließlich Leerzeichen.

Beim Ausführen einer HTTP-Reverse-Proxy-Software auf den Back-Ends des Load-Balancers kann die Software eine oder beide der folgenden IP-Adressen an das Ende des Headers X-Forwarded-For anhängen:

• Die IP-Adresse des Google Front End (GFE), das mit dem Backend verbunden ist. Diese IP-Adressen liegen in den Bereichen 130.211.0.0/22 und 35.191.0.0/16.

• Die IP-Adresse des Backend-Systems.

Daher kann ein vorgelagerter Prozess nach dem Backend Ihres Load-Balancers einen X-Forwarded-For-Header im folgenden Format erhalten:

<existing-values>,<client-ip>,<load-balancer-ip><GFE-IP><backend-IP>

URL-Zuordnungen

URL-Zuordnungen definieren die Zuordnungsmuster für eine Weiterleitung von Anfragen, die auf URLs basieren, an die passenden Back-End-Dienste. Ein Standarddienst ist so definiert, dass er alle Anfragen bearbeiten kann, für die es keine bestimmte Host- oder Pfadregel gibt. In Situationen wie dem Beispiel zum multiregionalen Load-Balancing kann es sein, dass Sie keine URL-Regeln definieren und sich nur auf den Standarddienst verlassen. Für Anfragerouting gibt Ihnen die URL-Zuordnung die Möglichkeit, den Traffic aufzuteilen. Dazu werden die URL-Komponenten untersucht, damit sie Anfragen an verschiedene Backend-Sets senden.

URL-Zuordnungen, die mit globalen externen Application Load Balancern und regionalen externen Application Load Balancern verwendet werden, unterstützen mehrere Features zur erweiterten Trafficverwaltung wie Header-basierte Trafficsteuerung, gewichtete Trafficaufteilung und Anfragespiegelung. Hier finden Sie weitere Informationen:

• Trafficverwaltung für globale externe Application Load Balancer
• Ü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.

Load-Balancer-Modus	Typ der URL-Zuordnung
Globaler externer Application Load Balancer	Global
Klassischer Application Load Balancer	Global (nur mit einer Teilmenge der unterstützten Features)
Regionaler externer Application Load Balancer	Regional

SSL-Zertifikate

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

• Google Cloud bietet zwei Konfigurationsmethoden zum Zuweisen privater Schlüssel und SSL-Zertifikate zu HTTPS-Zielproxys: Compute Engine-SSL-Zertifikate und Certificate Manager. Eine Beschreibung der einzelnen Konfigurationen finden Sie unter Methoden der Zertifikatskonfiguration in der Übersicht zu SSL-Zertifikaten.

• Google Cloud bietet zwei Zertifikatstypen: selbstverwaltet und von Google verwaltet. Eine Beschreibung der einzelnen Typen finden Sie unter Zertifikat-Typen in der Übersicht zu SSL-Zertifikaten.

• Der Typ des externen Application Load Balancers (global, regional oder klassisch) bestimmt, welche Konfigurationsmethoden und Zertifikatstypen unterstützt werden. Weitere Informationen finden Sie unter Zertifikate und Google Cloud-Load-Balancer in der Übersicht über SSL-Zertifikate.

Gegenseitiges TLS

Bei der HTTPS-Kommunikation funktioniert die Authentifizierung normalerweise nur in eine Richtung: der Client überprüft die Identität des Servers. Bei Anwendungen, die den Load-Balancer zum Authentifizieren der Identität von Clients benötigen, die eine Verbindung zu ihm herstellen, unterstützen sowohl ein globaler externer Application Load Balancer als auch ein klassischer Application Load Balancer gegenseitige TLS (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 konfigurieren, mit dem der Load-Balancer die Vertrauenskette des Clientzertifikats validiert.

Google Cloud verwendet die Ressource TrustConfig in Certificate Manager, um Zertifikate zu speichern, mit denen der Server das vom Client bereitgestellte Zertifikat prüft. Wenn Sie einen klassischen Application Load Balancer auf der Premium-Netzwerkdienststufe oder einen globalen externen Application Load Balancer verwenden, können Sie den Zertifikatmanager zur Bereitstellung und Verwaltung Ihrer SSL-Zertifikate oder TrustConfig in mehreren Instanzen des Load-Balancers in großem Umfang verwenden. Weitere Informationen finden Sie in der Übersicht zu Certificate Manager.

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

SSL-Richtlinien

SSL-Richtlinien geben die SSL-Features an, die Google Cloud-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.

Load-Balancer-Modus	Unterstützte SSL-Richtlinien
Globaler externer Application Load Balancer
Klassischer Application Load Balancer
Regionaler externer Application Load Balancer

Backend-Dienste und -Buckets

Backend-Dienste stellen Konfigurationsinformationen für den Load-Balancer bereit. Load-Balancer leiten den eingehenden Traffic anhand der Informationen in einem Backend-Dienst an einen oder mehrere verknüpfte Backends weiter. Ein Beispiel für die Einrichtung eines Load-Balancers mit einem Backend-Dienst und einem Compute Engine-Backend finden Sie unter Externen Application Load Balancer mit einem Compute Engine-Backend einrichten.

Backend-Buckets leiten eingehenden Traffic an Cloud Storage-Buckets weiter. Ein Beispiel, das zeigt, wie Sie einen Bucket zu einem externen Application Load Balancer hinzufügen, finden Sie unter Load-Balancer mit Backend-Buckets einrichten.

In der folgenden Tabelle sind die Backend-Features aufgeführt, die von externen Application Load Balancern in den einzelnen Modi unterstützt werden.

Load-Balancer-Modus	Unterstützte Backends in einem Backend-Dienst						Unterstützt Back-End-Buckets	Unterstützt Google Cloud Armor	Unterstützt Cloud CDN^4	Unterstützt IAP^4	Unterstützt Diensterweiterungen
	Instanzgruppen	Zonale NEGs	Internet-NEGs	Serverlose NEGs	Hybrid-NEGs	Private Service Connect-NEGs
Globaler externer Application Load Balancer		^2
Klassischer Application Load Balancer		^1							bei Verwendung der Premium-Stufe
Regionaler externer Application Load Balancer		^1

¹ Endpunkte des Typs GCE_VM_IP_PORT mit GKE verwenden: Eigenständige zonale NEGs verwenden oder Ingress verwenden

² Endpunkte des Typs GCE_VM_IP_PORT mit GKE verwenden: Eigenständige zonale NEGs verwenden

³ Nur mit GKE Gateway Controller unterstützt

⁴ IAP und Cloud CDN sind nicht miteinander kompatibel. Sie können nicht für denselben Backend-Dienst aktiviert werden.

Hier finden Sie weitere Informationen:

• Übersicht über Back-End-Dienste
• Was ist Cloud Storage?

Back-Ends und VPC-Netzwerke

Die Einschränkungen, wo sich Back-Ends befinden können, hängen vom Typ des Load-Balancers ab.

• Für den globalen externen Application Load Balancer und den klassischen Application Load Balancer müssen sich alle Backend-Instanzen von Instanzgruppen-Backends und alle Backend-Endpunkte von NEG-Backends im selben Projekt befinden. Ein Instanzgruppen-Backend oder eine NEG können jedoch ein anderes VPC-Netzwerk in diesem Projekt verwenden. Die verschiedenen VPC-Netzwerke müssen nicht über VPC-Netzwerk-Peering verbunden sein, da GFEs direkt mit Backends in ihren jeweiligen VPC-Netzwerken kommunizieren.
• Für den regionalen externen Application Load Balancer müssen sich alle Back-Ends im selben VPC-Netzwerk und in derselben Region befinden.

Protokoll für Back-Ends

Wenn Sie einen Backend-Dienst für den Proxy-Load-Balancer konfigurieren, legen Sie das Protokoll fest, über das der Backend-Dienst mit den Backends kommuniziert. Sie können HTTP, HTTPS oder HTTP/2 auswählen. Der Load-Balancer verwendet nur das von Ihnen angegebene Protokoll Der Load-Balancer greift nicht auf eines der anderen Protokolle zurück, wenn er mit dem angegebenen Protokoll keine Verbindung zum Back-End aushandeln kann.

Wenn Sie HTTP/2 verwenden, müssen Sie TLS verwenden. HTTP/2 ohne Verschlüsselung wird nicht unterstützt.

Eine vollständige Liste der unterstützten Protokolle finden Sie unter Load-Balancing-Features: Protokolle vom Load-Balancer zu den Back-Ends.

WebSocket-Unterstützung

HTTP(S)-basierte Load Balancer von Google Cloud bieten eingebaute Unterstützung für das WebSocket-Protokoll, wenn Sie HTTP oder HTTPS 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 Servern. Durch eine HTTP(S)-Anfrage wird der Kanal initiiert. Ausführliche Informationen zum Protokoll finden Sie unter RFC 6455.

Wenn der Load-Balancer eine WebSocket-Upgrade-Anfrage von einem HTTP(S)-Client gefolgt von einer erfolgreichen Upgrade-Antwort der Back-End-Instanz erkennt, leitet er bidirektionalen Traffic für die Dauer der aktuellen Verbindung über einen Proxy weiter. Wenn die Back-End-Instanz keine erfolgreiche Upgrade-Antwort zurückgibt, schließt der Load-Balancer die Verbindung.

Zeitüberschreitungen für WebSocket-Verbindungen hängen vom Typ des Load Balancers ab (global, regional oder klassisch). Weitere Informationen finden Sie unter Zeitüberschreitung bei Backend-Diensten.

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

gRPC mit Ihren Google Cloud-Anwendungen verwenden

gRPC ist ein Open Source-Framework für Remoteprozeduraufrufe. 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

Um gRPC mit Ihren Google Cloud-Anwendungen zu verwenden, müssen Sie Anfragen durchgehend über HTTP/2 weiterleiten. So gehen Sie dazu vor:

1. Konfigurieren Sie einen HTTPS-Load-Balancer.
2. Wählen Sie HTTP/2 als Protokoll vom Load-Balancer zu den Back-Ends aus.

Der Load-Balancer verhandelt HTTP/2 mit Clients als Teil des SSL-Handshakes und verwendet dazu die ALPN TLS-Erweiterung.

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 Lastenausgleichsmodul transformiert, um die Anfragen über HTTP/2 an die Backend-Instanzen weiterzuleiten.

Sie müssen TLS auf Ihren Back-Ends aktivieren. Weitere Informationen finden Sie unter Verschlüsselung vom Load-Balancer zu Back-Ends.

Informationen zum Konfigurieren eines externen 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 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.

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-Back-Ends 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.

Load-Balancer-Modus	Systemdiagnosetyp
Globaler externer Application Load Balancer	Global
Klassischer Application Load Balancer	Global
Regionaler externer Application Load Balancer	Regional

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 die globalen externen Application Load Balancer ist eine Regel zum Zulassen von eingehendem Traffic erforderlich, um Traffic von Google Front Ends (GFEs) zu Ihren Back-Ends zuzulassen.
  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 Google Cloud-Firewallregeln nicht verwenden, um zu verhindern, dass Traffic den Load-Balancer erreicht. Beim globalen externen Application Load Balancer und klassischen Application Load Balancer können Sie Google Cloud Armor verwenden, um dies zu erreichen.

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.

In der folgenden Tabelle sind die erforderlichen Quell-IP-Adressbereiche für die Firewallregeln zusammengefasst:

Load-Balancer-Modus	Quellbereiche für Systemdiagnosen	Quellbereiche anfragen
Globaler externer Application Load Balancer	35.191.0.0/16 130.211.0.0/22	The source of GFE traffic depends on the backend type: Instanzgruppen, zonale NEGs (GCE_VM_IP_PORT) und Hybridkonnektivitäts-NEGs (NON_GCP_PRIVATE_IP_PORT): 130.211.0.0/22 35.191.0.0/16 Internet-NEGs (INTERNET_FQDN_PORT und INTERNET_IP_PORT): 34.96.0.0/20 34.127.192.0/18 SERVERLESS-NEGs und Backend-Buckets: Das Produktionsnetzwerk von Google verarbeitet das Paketrouting.
Klassischer Application Load Balancer	35.191.0.0/16 130.211.0.0/22	The source of GFE traffic depends on the backend type: Instanzgruppen, zonale NEGs (GCE_VM_IP_PORT) und Hybridkonnektivitäts-NEGs (NON_GCP_PRIVATE_IP_PORT): 35.191.0.0/16 130.211.0.0/22 Internet-NEGs (INTERNET_FQDN_PORT und INTERNET_IP_PORT): 34.96.0.0/20 34.127.192.0/18 SERVERLESS-NEGs und Backend-Buckets: Das Produktionsnetzwerk von Google verarbeitet das Paketrouting.
Regionaler externer Application Load Balancer	35.191.0.0/16 130.211.0.0/22 Die Prüfbereiche der Systemdiagnose von Google müssen bei Hybrid-NEGs nicht auf die Zulassungsliste gesetzt werden. Wenn Sie jedoch eine Kombination aus hybriden und zonalen NEGs in einem einzelnen Backend-Dienst verwenden, müssen Sie die Prüfbereiche der Systemdiagnose von Google für die zonalen NEGs auf die Zulassungsliste setzen.	Das von Ihnen konfigurierte Nur-Proxy-Subnetz.

Wichtig: Achten Sie darauf, dass Pakete aus den vollständigen Systemdiagnosebereichen zulässig sind. Wenn Ihre Firewallregel nur Pakete aus einem Teil der Bereiche zulässt, können Systemdiagnosen fehlschlagen, weil der Load-Balancer nicht mit Ihren Back-Ends kommunizieren kann. Dies führt zu HTTP-502-Antworten.

Architektur einer freigegebenen 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 freigegebenen VPCs vertraut sind, lesen Sie die Dokumentation Freigegebene VPC – Übersicht.

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

Load-Balancer	Frontend-Komponenten	Backend-Komponenten
Globaler externer Application Load Balancer	Die globale externe IP-Adresse, die Weiterleitungsregel, der Ziel-HTTP(S)-Proxy und die zugehörige URL-Zuordnung müssen im selben Projekt definiert sein. Dieses Projekt kann das Hostprojekt oder ein Dienstprojekt sein.	Ein globaler Backend-Dienst muss im selben Host oder Dienstprojekt definiert werden wie die Backends (Instanzgruppen oder NEGs). Mit den Backend-Diensten verknüpfte Systemdiagnosen müssen auch im selben Projekt wie der Backend-Dienst definiert werden.
Klassischer Application Load Balancer	Die globale externe IP-Adresse, die Weiterleitungsregel, der Ziel-HTTP(S)-Proxy und die zugehörige URL-Zuordnung müssen im selben Host oder Dienstprojekt wie die Back-Ends definiert werden.	Ein globaler Backend-Dienst muss im selben Host oder Dienstprojekt definiert werden wie die Backends (Instanzgruppen oder NEGs). Mit den Backend-Diensten verknüpfte Systemdiagnosen müssen auch im selben Projekt wie der Backend-Dienst definiert werden.
Regionaler externer Application Load Balancer	Erstellen Sie das erforderliche Netzwerk und das Nur-Proxy-Subnetz im freigegebenen VPC-Hostprojekt. Die regionale externe IP-Adresse, die Weiterleitungsregel, der Ziel-HTTP(S)-Proxy und die zugehörige URL-Zuordnung müssen im selben Projekt definiert sein. Dieses Projekt kann das Hostprojekt oder ein Dienstprojekt sein.	Sie haben folgende Möglichkeiten: Erstellen Sie Backend-Dienste und Backends (Instanzgruppen, serverlose NEGs oder andere unterstützte Backend-Typen) im selben Dienstprojekt wie die Frontend-Komponenten. Erstellen Sie Backend-Dienste und Backends (Instanzgruppen, serverlose NEGs oder andere unterstützte Backend-Typen) in so vielen Dienstprojekten wie nötig. Eine einzelne URL-Zuordnung kann auf Backend-Dienste in verschiedenen Projekten verweisen. Diese Art der Bereitstellung wird als projektübergreifende Dienstreferenz bezeichnet. Jeder Backend-Dienst muss im selben Projekt wie die Backends definiert werden, auf die er verweist. Mit den Backend-Diensten verknüpfte Systemdiagnosen müssen auch im selben Projekt wie der Backend-Dienst definiert werden.

Sie können alle Load-Balancing-Komponenten und Backends im freigegebenen 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 freigegebenen 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.

Regionaler externer Application Load Balancer in einem freigegebenen VPC-Netzwerk

Serverlose Back-Ends in einer freigegebenen VPC-Umgebung

Bei einem Load Balancer, der ein serverloses NEG-Backend verwendet, muss sich der Backend-Cloud Run- oder Cloud Functions-Dienst im selben Projekt wie die serverlose NEG befinden.

Für den regionalen externen Application Load Balancer, der die projektübergreifende Dienstreferenz unterstützt, müssen sich außerdem der Backend-Dienst, die serverlose NEG und der Cloud Run-Dienst immer im selben Dienstprojekt befinden.

Projektübergreifender Dienstverweis

In diesem Modell befinden sich das Frontend und die URL-Zuordnung des Load-Balancers in einem Host- oder Dienstprojekt. Die Backend-Dienste und Backends des Load-Balancers können auf Projekte in der freigegebenen VPC-Umgebung verteilt werden. Auf projektübergreifende Backend-Dienste kann in einer einzelnen URL-Zuordnung verwiesen werden. Dies wird als projektübergreifender Dienstverweis bezeichnet.

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.

Informationen zum Konfigurieren der freigegebenen VPC für einen regionalen externen Application Load Balancer mit oder ohne projektübergreifenden Dienstverweis finden Sie unter Regionalen externen Application Load Balancer mit freigegebener VPC einrichten.

Bekannte Einschränkungen beim projektübergreifenden Dienstverweis

• Der projektübergreifende Dienstverweis kann mit Instanzgruppen, serverlosen NEGs und den meisten anderen unterstützten Backend-Typen verwendet werden. Es gelten jedoch die folgenden Einschränkungen:

  • Bei regionalen externen Application Load Balancern können Sie nicht auf einen projektübergreifenden Backend-Dienst verweisen, wenn der Backend-Dienst regionale Internet-NEG-Backends hat.
• Der projektübergreifende Dienstverweis wird für den globalen externen Application Load Balancer und den klassischen Application Load Balancer nicht unterstützt.
• Google Cloud unterscheidet nicht zwischen Ressourcen (z. B. Backend-Diensten), die in mehreren Projekten denselben Namen verwenden. Wenn Sie projektübergreifende Dienstreferenzen verwenden, empfehlen wir daher, für alle Projekte in Ihrer Organisation eindeutige Backend-Dienstnamen zu verwenden.

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

Im Folgenden finden Sie ein Beispiel für eine Bereitstellung, 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 IAM-Rolle compute.loadBalancerServiceUser.

Frontend und Backend des Load-Balancers in verschiedenen Dienstprojekten

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

Bei dieser Art der Bereitstellung werden das Frontend und die URL-Zuordnung des Load-Balancers im Hostprojekt und die Backend-Dienste (und Backends) in Dienstprojekten erstellt.

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 IAM-Rolle compute.loadBalancerServiceUser.

Frontend und URL-Zuordnung des Load-Balancers im Hostprojekt

Funktionsweise von Verbindungen

Verbindungen bei globalen externen Application Load Balancern

Die globalen externen Application Load Balancer werden von vielen Proxys, den sogenannten Google Front-Ends (GFEs), implementiert. Es gibt nicht nur einen Proxy. In der Premium-Stufe wird dieselbe globale externe IP-Adresse von verschiedenen Points of Presence angegeben und Clientanfragen werden an das nächste GFE des Clients weitergeleitet.

Je nachdem, wo sich Ihre Clients befinden, können mehrere GFEs HTTP(S)-Verbindungen zu Ihren Back-Ends initiieren. Von GFEs gesendete Pakete haben Quell-IP-Adressen aus demselben Bereich, der auch von Systemdiagnoseprüfern verwendet wird: 35.191.0.0/16 und 130.211.0.0/22.

Hinweis: Bei Internet-NEGs stammen Anfragen vom Load Balancer aus verschiedenen IP-Bereichen, je nach Typ der NEG (global oder regional). Weitere Informationen finden Sie unter Anfragen authentifizieren.

Abhängig von der Backend-Dienstkonfiguration kann das Protokoll, mit dem jedes GFE eine Verbindung zu Ihren Backends herstellt, HTTP, HTTPS oder HTTP/2 sein. Bei HTTP- oder HTTPS-Verbindungen wird die HTTP-Version HTTP 1.1 verwendet.

HTTP-Keepalive ist standardmäßig aktiviert, wie in der HTTP 1.1-Spezifikation angegeben. HTTP-Keepalives versuchen, dieselbe TCP-Sitzung effizient zu verwenden. Es gibt jedoch keine Garantie. Das GFE verwendet einen Client-HTTP-Keepalive-Zeitlimit von 610 Sekunden und einen Standard-Back-End-Keepalive-Zeitlimit von 600 Sekunden. Sie können das HTTP-Keepalive-Zeitlimit des Clients aktualisieren, aber das Keepalive-Zeitlimit für das Back-End ist festgelegt. Sie können das Zeitlimit für Anfragen/Antworten konfigurieren, indem Sie das Zeitlimit für den Back-End-Dienst festlegen. Ein HTTP-Keepalive und ein TCP-Leerlaufzeitlimit sind zwar ähnlich, aber nicht identisch. Weitere Informationen finden Sie unter Zeitüberschreitungen und Wiederholungsversuche.

Damit das Load-Balancing des Traffics gleichmäßig erfolgt, kann der Load-Balancer eine TCP-Verbindung ordnungsgemäß schließen. Dafür sendet er entweder nach Abschluss einer Antwort, die einen Connection: close-Header enthielt, ein FIN ACK-Paket oder er gibt einen HTTP/2-GOAWAY-Frame nach Abschluss einer Antwort aus. Dieses Verhalten beeinträchtigt keine aktiven Anfragen oder Antworten.

Die Anzahl der HTTP-Verbindungen und TCP-Sitzungen hängt von der Anzahl der GFE-Verbindungen ab, der Anzahl der Clients, die eine Verbindung zu den GFEs herstellen, dem Protokoll zu den Back-Ends und der Zone, in der Back-Ends bereitgestellt werden.

Weitere Informationen finden Sie unter Funktionsweise externer Application Load Balancer im Lösungsleitfaden "Optimierung der Anwendungskapazität mit globalem Load-Balancing".

Verbindungen bei regionalen externen Application Load Balancern

Der regionale externe Application Load Balancer ist ein verwalteter Dienst, der auf dem Envoy-Proxy implementiert wird. Der regionale externe Application Load Balancer verwendet ein freigegebenes Subnetz, das als Nur-Proxy-Subnetz bezeichnet wird, um eine Reihe von IP-Adressen bereitzustellen, mit denen Google Envoy-Proxys in Ihrem Namen ausführt. Das Flag --purpose für dieses Nur-Proxy-Subnetz ist auf REGIONAL_MANAGED_PROXY gesetzt. Alle regionalen Envoy-basierten Load-Balancer in einem bestimmten Netzwerk und einer bestimmten Region nutzen dieses Subnetz gemeinsam.

Clients verwenden die IP-Adresse und den Port des Load-Balancers, um eine Verbindung zum Load-Balancer herzustellen. Clientanfragen werden an das Nur-Proxy-Subnetz in derselben Region wie der Client weitergeleitet. Der Load-Balancer beendet Clientanfragen und öffnet dann neue Verbindungen vom Nur-Proxy-Subnetz zu Ihren Back-Ends. Daher haben die vom Load-Balancer gesendeten Pakete Quell-IP-Adressen aus dem Nur-Proxy-Subnetz.

Abhängig von der Backend-Dienstkonfiguration kann das Protokoll, mit dem Envoy-Proxys eine Verbindung zu Ihren Backends herstellen, HTTP, HTTPS oder HTTP/2 sein. Bei HTTP oder HTTPS lautet die HTTP-Version HTTP 1.1. HTTP-Keepalive ist standardmäßig aktiviert, wie in der HTTP 1.1-Spezifikation angegeben. Der Envoy-Proxy legt sowohl das Client-HTTP-Keepalive-Zeitlimit als auch das Backend-Keepalive-Zeitlimit auf einen Standardwert von jeweils 600 Sekunden fest. Sie können das HTTP-Keepalive-Zeitlimit des Clients aktualisieren, aber das Keepalive-Zeitlimit für das Back-End ist festgelegt. Sie können das Zeitlimit für Anfragen/Antworten konfigurieren, indem Sie das Zeitlimit für den Back-End-Dienst festlegen. Weitere Informationen finden Sie unter Zeitüberschreitungen und Wiederholungsversuche.

Clientkommunikation mit dem Load-Balancer

• Clients können mit dem Load-Balancer über das Protokoll HTTP 1.1 oder HTTP/2 kommunizieren.
• Bei einer HTTPS-Kommunikation verwenden moderne Clients standardmäßig HTTP/2. Dies wird auf dem Client gesteuert, nicht auf dem globalen HTTPS-Load-Balancer.
• HTTP/2 lässt sich nicht durch eine Konfigurationsänderung am Load-Balancer deaktivieren. Sie können Clients jedoch so konfigurieren, dass sie HTTP 1.1 anstelle von HTTP/2 verwenden. Verwenden Sie beispielsweise mit curl den Parameter --http1.1.
• Externe Application Load Balancer unterstützen die Antwort HTTP/1.1 100 Continue.

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.

Quell-IP-Adressen für Clientpakete

Die Quell-IP-Adresse für Pakete, die von den Back-Ends erkannt wird, ist nicht die externe Google Cloud-IP-Adresse des Load-Balancers. Mit anderen Worten: Es gibt zwei TCP-Verbindungen.

Für den globalen externen Application Load Balancer:

• Verbindung 1 vom ursprünglichen Client zum Load-Balancer (GFE):

  • Quell-IP-Adresse: Der ursprüngliche Client (oder die externe IP-Adresse, wenn sich der Client hinter NAT oder einem Weiterleitungsproxy befindet)
  • Ziel-IP-Adresse: IP-Adresse Ihres Load-Balancers

• Verbindung 2 vom Load-Balancer (GFE) zur Back-End-VM oder zum Back-End-Endpunkt:

  • Quell-IP-Adresse: IP-Adresse aus einem der unter Firewallregeln angegebenen Bereiche

  • Ziel-IP-Adresse: die interne IP-Adresse der Backend-VM oder des Containers im VPC-Netzwerk.

Hinweis: Bei Internet-NEGs stammen Anfragen vom Load-Balancer aus verschiedenen IP-Bereichen. Weitere Informationen finden Sie unter Anfragen authentifizieren.

Für die regionalen externen Application Load Balancer:

• Verbindung 1, vom ursprünglichen Client zum Load-Balancer (Nur-Proxy-Subnetz):

  • Quell-IP-Adresse: Der ursprüngliche Client (oder die externe IP-Adresse, wenn sich der Client hinter NAT oder einem Weiterleitungsproxy befindet)
  • Ziel-IP-Adresse: IP-Adresse Ihres Load-Balancers

• Verbindung 2, vom Load-Balancer (Nur-Proxy-Subnetz) zur Backend-VM oder zum Endpunkt:

  • Quell-IP-Adresse: eine IP-Adresse im Nur-Proxy-Subnetz, die von allen Envoy-basierten Load-Balancern gemeinsam verwendet wird, die in derselben Region und im selben Netzwerk wie der Load-Balancer bereitgestellt werden.

  • Ziel-IP-Adresse: die interne IP-Adresse der Backend-VM oder des Containers im VPC-Netzwerk.

Return-Path

Für die globalen externen Application Load Balancer verwendet Google Cloud spezielle Routen, die nicht in Ihrem VPC-Netzwerk für Systemdiagnosen definiert sind. Weitere Informationen finden Sie unter Load-Balancer-Rückgabepfade.

Für regionale externe Application Load Balancer verwendet Google Cloud Open-Source-Envoy-Proxys, um Clientanfragen an den Load-Balancer zu beenden. Der Load-Balancer beendet die TCP-Sitzung und öffnet eine neue TCP-Sitzung aus dem Nur-Proxy-Subnetz der Region zu Ihrem Backend. In Ihrem VPC-Netzwerk definierte Routen erleichtern die Kommunikation von Envoy-Proxys zu Ihren Back-Ends und von Ihren Back-Ends zu den Envoy-Proxys.

Offene Ports

GFEs haben mehrere offene Ports, um andere Google-Dienste, die in derselben Architektur ausgeführt werden, zu unterstützen. Wenn Sie einen Portscan ausführen, werden möglicherweise andere offene Ports für andere Google-Dienste angezeigt, die auf GFEs ausgeführt werden.

Beide GFE-basierten Load Balancer – globale externe Application Load Balancer und klassische Application Load Balancer – zeigen immer die Ports 80 und 443 zusammen mit jedem anderen Port an, den Sie in den Weiterleitungsregeln Ihres Load Balancers konfiguriert haben. Wenn Sie jedoch keine Weiterleitungsregel für Port 80 oder Port 443 konfiguriert haben, werden alle an diese Ports gesendeten Verbindungen abgelehnt. Umgekehrt werden regionale externe Load Balancer mit Envoy-Proxys implementiert und zeigen während eines Scans keine zusätzlichen offenen Ports.

Aus folgenden Gründen ist die Ausführung eines Portscans für die IP-Adresse eines GFE-basierten Load-Balancers aus Sicht der Prüfung nicht hilfreich:

• Ein Portscan (z. B. mit nmap) erwartet beim Ausführen von TCP-SYN-Tests normalerweise kein Antwortpaket oder ein TCP-RST-Paket. GFEs senden SYN-ACK-Pakete als Antwort auf SYN-Prüfungen nur für Ports, auf denen Sie eine Weiterleitungsregel konfiguriert haben. GFEs senden jedoch nur Pakete an Ihre Backends, wenn Pakete an die IP-Adresse und den Zielport Ihres Load Balancers gesendet wurden, die in seiner Weiterleitungsregel konfiguriert sind. Pakete, die an eine andere IP-Adresse oder einen anderen Port gesendet werden, werden nicht an Ihre Backends gesendet.

  GFEs implementieren Sicherheitsfunktionen wie Google Cloud Armor. Mit Google Cloud Armor Standard bieten GFEs immer aktiven Schutz vor volumetrischen und protokollbasierten DDoS-Angriffen und SYN-Floods. Dieser Schutz ist auch dann verfügbar, wenn Sie Google Cloud Armor nicht explizit konfiguriert haben. Ihnen werden nur dann Gebühren in Rechnung gestellt, wenn Sie Sicherheitsrichtlinien konfigurieren oder sich für Managed Protection Plus registrieren.

• Pakete, die an die IP-Adresse Ihres Load-Balancers gesendet werden, können von jedem GFE in der Google-Flotte beantwortet werden. Wird jedoch eine Kombination aus IP-Adresse und Zielport eines Load-Balancers gescannt, wird nur ein einziges GFE pro TCP-Verbindung abgefragt. Die IP-Adresse des Load-Balancers wird keinem einzelnen Gerät oder System zugewiesen. Wenn also die IP-Adresse eines GFE-basierten Load-Balancers gescannt wird, werden nicht alle GFEs in der Flotte von Google gescannt.

Daher können Sie die Sicherheit Ihrer Back-End-Instanzen am besten mit folgenden Methoden prüfen:

• Ein Sicherheitsprüfer sollte die Konfiguration der Weiterleitungsregeln für die Konfiguration des Load-Balancers prüfen. Die Weiterleitungsregeln definieren den Zielport, für den Ihr Load-Balancer Pakete akzeptiert und an die Back-Ends weiterleitet. Bei GFE-basierten Load-Balancern kann jede externe Weiterleitungsregel nur auf einen einzelnen TCP-Zielport verweisen. Für Load-Balancer, die TCP-Port 443 verwenden, wird UDP-Port 443 verwendet, wenn die Verbindung auf QUIC (HTTP/3) aktualisiert wird.

• Ein Sicherheitsprüfer sollte die Konfiguration der Firewallregel für Back-End-VMs prüfen. Die festgelegten Firewallregeln blockieren den Traffic von den GFEs zu den Backend-VMs, aber nicht den eingehenden Traffic zu den GFEs. Best Practices finden Sie im Abschnitt Firewallregeln.

TLS-Terminierung

In der folgenden Tabelle wird zusammengefasst, wie die TLS-Terminierung von externen Application Load Balancern in den einzelnen Modi verarbeitet wird.

Load-Balancer-Modus	TLS-Terminierung
Globaler externer Application Load Balancer	TLS wird auf einem GFE terminiert, das sich überall auf der Welt befinden kann.
Klassischer Application Load Balancer	TLS wird auf einem GFE terminiert, das sich überall auf der Welt befinden kann.
Regionaler externer Application Load Balancer	TLS wird auf Envoy-Proxys in einem Nur-Proxy-Subnetz in einer vom Nutzer ausgewählten Region terminiert. Verwenden Sie diesen Load-Balancer-Modus, wenn Sie geografische Kontrolle über die Region benötigen, in der TLS terminiert wird.

Zeitüberschreitungen und Wiederholungsversuche

Externe Application Load Balancer unterstützen die folgenden Arten von Zeitüberschreitungen:

Zeitlimittyp und Beschreibung	Standardwerte	Unterstützt benutzerdefinierte Werte
		Global	Klassisch	Regional
Zeitlimit für Backend-Dienst^1 Eine Zeitüberschreitung bei Anfrage und Antwort. Stellt die maximale Zeitspanne dar, die ablaufen kann, wenn der Load Balancer das erste Byte der HTTP-Anfrage an Ihr Backend sendet, bis Ihr Backend das letzte Byte der HTTP-Antwort zurückgibt. Wenn die gesamte HTTP-Antwort nicht innerhalb des Anfrage- oder Antwortzeitlimits an den Load Balancer zurückgegeben wurde, werden die verbleibenden Antwortdaten gelöscht. Bei WebSockets, die mit klassischen Application Load Balancern verwendet werden, die maximale Dauer des WebSockets, unabhängig davon, ob sie inaktiv oder aktiv sind.	Für serverlose NEGs in einem Backend-Dienst: 60 Minuten Für alle anderen Backend-Typen in einem Backend-Dienst: 30 Sekunden Für Backend-Buckets: 24 Stunden (86.400 Sekunden)	^2		^2
Client-HTTP-Keepalive-Zeitlimit Die maximale Zeitspanne, in der die TCP-Verbindung zwischen einem Client und dem Proxy des Load Balancers inaktiv sein kann. (Dieselbe TCP-Verbindung kann für mehrere HTTP-Anfragen verwendet werden.) Bei globalen externen Application Load Balancern und klassischen Application Load Balancern ist der Proxy des Load Balancers ein GFE der ersten Ebene. Bei regionalen externen Application Load Balancern ist der Proxy des Load Balancers die Envoy-Software.	Für einen globalen externen Application Load Balancer und einen klassischen Application Load Balancer: 610 Sekunden Für einen regionalen externen Application Load Balancer: 600 Sekunden
Backend-HTTP-Keepalive-Zeitlimit Die maximale Zeitspanne, in der die TCP-Verbindung zwischen dem Proxy des Load Balancers und einem Backend inaktiv sein kann. (Dieselbe TCP-Verbindung kann für mehrere HTTP-Anfragen verwendet werden.) Bei globalen externen Application Load Balancern und klassischen Application Load Balancern ist der Proxy des Load Balancers ein GFE der zweiten Ebene. Bei regionalen externen Application Load Balancern ist der Proxy des Load Balancers die Envoy-Software.	Für Backend-Dienste: 10 Minuten (600 Sekunden) Für Backend-Buckets: 6 Minuten (360 Sekunden)
Zeitüberschreitung bei inaktivem QUIC-Sitzung Die maximale Zeitspanne, in der eine QUIC-Sitzung zwischen dem (nachgelagerten) Client und dem GFE einer globalen externen Anwendung inaktiv sein kann Load Balancer oder ein klassischer Application Load Balancer.	Für globale externe Application Load Balancer und klassische Application Load Balancer: Das Zeitlimit bei Inaktivität für QUIC-Sitzungen ist der Mindestwert für die Zeitüberschreitung bei Inaktivität des Clients oder die Zeitüberschreitung bei Inaktivität des GFE (300 Sekunden). Das Zeitlimit bei Inaktivität für GFE ist auf 300 Sekunden festgelegt. Das Zeitlimit bei Inaktivität des Clients kann konfiguriert werden.

¹Nicht konfigurierbar für serverlose NEG-Back-Ends. Nicht für Backend-Buckets konfigurierbar.

²Die Konfigurationsunterstützung gilt nicht für WebSockets.

Zeitüberschreitung von Back-End-Dienst

Das konfigurierbare Zeitlimit des Backend-Diensts stellt die maximale Zeitspanne dar, die der Load Balancer auf die Verarbeitung einer HTTP-Anfrage durch das Backend wartet und die entsprechende HTTP-Antwort zurückgibt. Mit Ausnahme von serverlosen NEGs beträgt der Standardwert für das Zeitlimit des Backend-Diensts 30 Sekunden.

Wenn Sie beispielsweise eine Datei mit 500 MB herunterladen möchten und der Wert des Zeitlimits für den Backend-Dienst 90 Sekunden beträgt, erwartet der Load Balancer, dass das Backend die gesamte Datei mit 500 MB innerhalb von 90 Sekunden bereitstellt. Das Zeitlimit für den Backend-Dienst kann auch so konfiguriert werden, dass das Backend seine vollständige HTTP-Antwort sendet. Wenn der Load Balancer in dieser Situation zumindest HTTP-Antwortheader erhalten hat, sendet er die vollständigen Antwortheader und so viel vom Antwort-Body zurück, wie er innerhalb des Zeitlimits für den Backend-Dienst erhalten konnte.

Sie sollten das Zeitlimit für den Backend-Dienst auf die längste Zeitspanne festlegen, von der Sie erwarten, dass Ihr Backend sie zur Verarbeitung einer HTTP-Antwort benötigt. Sie sollten das Zeitlimit für den Backend-Dienst erhöhen, wenn die auf Ihrem Backend ausgeführte Software mehr Zeit benötigt, um eine HTTP-Anfrage zu verarbeiten und die gesamte Antwort zurückzugeben. Sie sollten beispielsweise das Zeitlimit erhöhen, wenn Sie HTTP-408-Antworten mit jsonPayload.statusDetail client_timed_out sehen.

Das Zeitlimit für den Backend-Dienst akzeptiert Werte zwischen 1 und 2,147,483,647 Sekunden. Größere Werte sind jedoch keine praktischen Konfigurationsoptionen. Google Cloud garantiert nicht, dass eine zugrunde liegende TCP-Verbindung für den gesamten Wert des Zeitlimits des Backend-Diensts 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.

Zusätzliche Hinweise:

• Zeitüberschreitungen für WebSocket-Verbindungen hängen vom Typ des Load-Balancers ab:

  • Bei klassischen Application Load Balancern hängt die Zeitüberschreitung für eine WebSocket-Verbindung von der konfigurierbaren Backend-Dienst-Zeitüberschreitung des Load Balancers ab, das standardmäßig 30 Sekunden beträgt. Diese Zeitüberschreitung wird auf WebSocket-Verbindungen unabhängig davon angewendet, ob sie gerade verwendet werden.
  • Bei globalen externen Application Load Balancern und regionalen externen Application Load Balancern folgen aktive WebSocket-Verbindungen nicht der Zeitüberschreitung des Backend-Dienstes. Inaktive WebSocket-Verbindungen werden nach der Zeitüberschreitung des Backend-Dienstes geschlossen.
  • Darüber hinaus werden WebSocket-Verbindungen, die von globalen externen Application Load Balancern und klassischen Application Load Balancern verwendet werden, nach 24 Stunden automatisch geschlossen. Dieses Limit von 24 Stunden ist nicht anpassbar und tritt unabhängig davon auf,ob die Verbindungen verwendet werden oder ob das Zeitlimit des Backend-Diensts auf einen Wert größer als 86.400 Sekunden (24 Stunden) festgelegt ist.

• Bei einem globalen externen Application Load Balancer oder einem klassischen Application Load Balancer werden Zeitlimits für Backend-Dienste, die größer als ein Tag (86.400 Sekunden) sind, nicht empfohlen, da Google Cloud Google Front Ends regelmäßig für Softwareupdates neu startet und andere routinemäßige Wartungen durchgeführt werden. Der Wert für das Zeitlimit des Backend-Diensts verzögert keine Wartungsaktivitäten von Google. Je länger der Wert des Zeitlimits des Backend-Diensts ist, desto wahrscheinlicher ist es, dass Google TCP-Verbindungen für die Wartung beendet.

• Bei einem regionalen externen Application Load Balancer startet Google Cloud die Anzahl der Envoy-Softwareaufgaben regelmäßig neu oder ändert sie. Je länger der Zeitlimitwert des Backend-Diensts ist, desto wahrscheinlicher ist es, dass TCP-Verbindungen durch Envoy-Aufgabenneustarts oder -ersetzungen beendet werden.

Regionale externe Application Load Balancer unterstützen den URL-Zuordnungsparameter routeActions.timeout, der das Zeitlimit des Backend-Dienstes überschreiben kann. Wenn routeActions.timeout weggelassen wird, wird der Wert des Zeitlimits für den Backend-Dienst verwendet. Wenn routeActions.timeout angegeben ist, wird das Zeitlimit des Backend-Diensts ignoriert und stattdessen der Wert von routeActions.timeout als Zeitlimit für Anfragen und Antworten verwendet.

Verwenden Sie eine der folgenden Methoden, um das Zeitlimit des Backend-Dienstes zu konfigurieren:

• Google Cloud Console: Ändern Sie das Feld Zeitlimit des Backend-Diensts des Load Balancers.
• Google Cloud CLI: Verwenden Sie den Befehl gcloud compute backend-services update, um den Parameter --timeout der Backend-Dienstressource zu ändern.
• API: Ändern Sie für einen globalen externen Application Load Balancer oder einen klassischen Application Load Balancer den Parameter timeoutSec für die globale backendServices-Ressource.
• API: Ändern Sie bei einem regionalen externen Application Load Balancer den Parameter timeoutSec für die Ressource regionBackendServices.

Client-HTTP-Keepalive-Zeitlimit

Das HTTP-Keepalive-Zeitlimit des Clients stellt die maximale Zeitspanne dar, in der eine TCP-Verbindung zwischen dem (nachgelagerten) Client und einem der folgenden Proxys inaktiv sein kann:

• Für einen globalen externen Application Load Balancer oder einen klassischen Application Load Balancer: ein Google Front End der ersten Ebene
• Für einen regionalen externen Application Load Balancer: ein Envoy-Proxy

Ein HTTP-Keepalive-Zeitlimit stellt das TCP-Leerlaufzeitlimit für die zugrunde liegenden TCP-Verbindungen dar. Das Client-HTTP-Keepalive-Zeitlimit gilt nicht für WebSockets.

• Bei einem globalen externen Application Load Balancer beträgt der Standardwert 610 Sekunden. Sie können das Client-HTTP-Keepalive-Zeitlimit mit einem Wert zwischen 5 und 1.200 Sekunden konfigurieren.
• Bei einem klassischen Application Load Balancer ist das HTTP-Keepalive-Zeitlimit des Clients auf 610 Sekunden festgelegt.
• Bei einem regionalen externen Application Load Balancer ist das HTTP-Keepalive-Zeitlimit des Clients auf 600 Sekunden festgelegt.

Verwenden Sie eine der folgenden Methoden, um den Keepalive-Zeitlimitparameter zu konfigurieren:

• Google Cloud Console: Ändern Sie das Feld HTTP-Keepalive-Zeitlimit der Frontend-Konfiguration des Load-Balancers.
• Google Cloud CLI: Verwenden Sie den Befehl gcloud compute target-http-proxies update oder den Befehl gcloud compute target-https-proxies update, um den Parameter --http-keep-alive-timeout-sec des HTTP-Ziel-Proxys oder der HTTPS-Ziel-Proxy-Ressource zu ändern.
• API: Ändern Sie den Parameter httpKeepAliveTimeoutSec für die Ressource targetHttpProxies oder die Ressource targetHttpsProxies.

Das Client-HTTP-Zeitlimit des Load Balancers sollte größer sein als das HTTP Keepalive-Zeitlimit (TCP inaktiv), das von nachgelagerten Clients oder Proxys verwendet wird. Wenn ein nachgelagerter Client ein größeres HTTP Keepalive-Zeitlimit (TCP inaktiv) hat als das HTTP Keepalive-Zeitlimit des Clients des Load Balancers, kann eine Race-Bedingung auftreten. Aus Sicht eines nachgelagerten Clients kann eine bestehende TCP-Verbindung länger als der Load Balancer inaktiv sein. Das bedeutet, dass der nachgelagerte Client Pakete senden kann, nachdem der Load Balancer die TCP-Verbindung als geschlossen betrachtet. In diesem Fall antwortet der Load Balancer mit einem TCP-Rücksetzpaket (RST).

HTTP-Keepalive-Zeitlimit des Back-Ends

Externe Application Load Balancer sind Proxys, die mindestens zwei TCP-Verbindungen verwenden:

• Bei einem globalen externen Application Load Balancer oder einem klassischen Application Load Balancer ist eine erste TCP-Verbindung zwischen dem (nachgelagerten) Client und dem GFE auf der ersten Ebene vorhanden. GFEs der ersten Ebene stellen eine Verbindung zu GFEs der zweiten Ebene her und die GFEs der zweiten Ebene öffnen dann eine zweite TCP-Verbindung zu Ihren Back-Ends.

• Bei einem regionalen externen Application Load Balancer ist eine erste TCP-Verbindung zwischen dem (nachgelagerten) Client und einem Envoy-Proxy vorhanden. Der Envoy-Proxy öffnet dann eine zweite TCP-Verbindung zu Ihren Back-Ends.

Die sekundären TCP-Verbindungen des Load Balancers werden möglicherweise nicht nach jeder Anfrage geschlossen. Sie können offen bleiben, um mehrere HTTP-Anfragen und -Antworten zu verarbeiten. Das Backend-HTTP-Keepalive-Zeitlimit definiert das TCP-Leerlaufzeitlimit zwischen dem Load Balancer und Ihren Backends. Das Backend-HTTP-Keepalive-Zeitlimit gilt nicht für WebSockets.

Das Backend für das Keepalive-Zeitlimit ist auf 10 Minuten (600 Sekunden) beschränkt und kann nicht geändert werden. Das Backend-Keepalive-Zeitlimit des Load Balancers sollte unter dem Keepalive-Zeitlimit liegen, das von Software verwendet wird, die auf Ihren Backends ausgeführt wird. Dadurch wird eine Race-Bedingung vermieden, bei der das Betriebssystem Ihrer Back-Ends TCP-Verbindungen mit einem TCP-Zurücksetzen (RST) schließen kann. Da das Backend-Keepalive-Zeitlimit für den Load-Balancer nicht konfigurierbar ist, müssen Sie Ihre Backend-Software so konfigurieren, dass der HTTP-Keepalive-Zeitlimit (TCP inaktiv) größer als 600 Sekunden ist.

In der folgenden Tabelle sind die Änderungen aufgeführt, die zum Ändern der Keepalive-Zeitüberschreitungswerte für häufig verwendete Webserversoftware erforderlich sind.

Webserversoftware	Parameter	Standardeinstellung	Empfohlene Einstellung
Apache	KeepAliveTimeout	KeepAliveTimeout 5	KeepAliveTimeout 620
nginx	keepalive_timeout	keepalive_timeout 75s;	keepalive_timeout 620s;

Zeitüberschreitung bei inaktivem QUIC-Sitzung

Das Zeitlimit bei Inaktivität für QUIC-Sitzungen stellt die maximale Zeitspanne dar, die eine QUIC-Sitzung zwischen dem Client und dem GFE eines globalen externen Application Load Balancers oder eines klassischen Application Load Balancers inaktiv sein kann.

Der Wert für die Zeitüberschreitung bei Inaktivität der QUIC-Sitzung ist als Minimum der Zeitüberschreitung bei Inaktivität oder der GFE-Zeitüberschreitung (300 Sekunden) definiert. Das Zeitlimit bei Inaktivität für GFE ist auf 300 Sekunden festgelegt. Das Zeitlimit bei Inaktivität des Clients kann konfiguriert werden.

Wiederholungsversuche

Die Unterstützung für die Wiederholungslogik hängt vom Modus des externen Application Load Balancers ab.

Load-Balancer-Modus	Wiederholungslogik
Globaler externer Application Load Balancer	Über eine Wiederholungsrichtlinie in der URL-Zuordnung konfigurierbar. Die Standardanzahl an Wiederholungen (numRetries) ist 1. Die maximale Anzahl von Wiederholungsversuchen, die mit der Wiederholungsrichtlinie konfiguriert werden kann, beträgt 25. Das Standardzeitlimit für jeden Versuch (perTryTimeout) beträgt 30 Sekunden mit einem maximal konfigurierbaren perTryTimeout von 24 Stunden. Ohne eine Wiederholungsrichtlinie werden fehlgeschlagene Anfragen ohne HTTP-Text (z. B. GET-Anfragen), die zu HTTP-Antworten 502, 503 oder 504 führen (retryConditions=["gateway-error"]), einmal wiederholt. HTTP-POST-Anfragen werden nicht wiederholt. Bei wiederholten Anfragen wird nur ein Logeintrag für die endgültige Antwort generiert.
Klassischer Application Load Balancer	Die Wiederholungsrichtlinie kann für Verbindungswiederholungen nicht geändert werden. HTTP-POST-Anfragen werden nicht wiederholt. HTTP-GET-Anfragen werden immer einmal wiederholt, solange 80 % oder mehr der Back-Ends fehlerfrei sind. Wenn eine einzelne Backend-Instanz in einer Gruppe vorhanden ist und die Verbindung zu dieser Backend-Instanz fehlschlägt, beträgt der Prozentsatz fehlerhafter Backend-Instanzen 100 %, sodass das GFE die Anfrage nicht wiederholt. Der Load-Balancer wiederholt eine fehlgeschlagene GET-Anfrage, wenn die erste Anfrage fehlgeschlagen ist, bevor Antwortheader von der Backend-Instanz empfangen werden. Bei wiederholten Requests wird nur ein Log-Eintrag für die endgültige Antwort generiert. Weitere Informationen finden Sie unter Logging und Monitoring für externe Application Load Balancer. Fehlgeschlagene Anfragen führen dazu, dass der Load-Balancer die HTTP-Antwort 502 synthetisiert.
Regionaler externer Application Load Balancer	Über eine Wiederholungsrichtlinie in der URL-Zuordnung konfigurierbar. Die Standardanzahl an Wiederholungen (numRetries) ist 1. Die maximale Anzahl von Wiederholungsversuchen, die mit der Wiederholungsrichtlinie konfiguriert werden kann, beträgt 25. Das Standardzeitlimit für jeden Versuch (perTryTimeout) beträgt 30 Sekunden mit einem maximal konfigurierbaren perTryTimeout von 24 Stunden. Ohne eine Wiederholungsrichtlinie werden fehlgeschlagene Anfragen ohne HTTP-Text (z. B. GET-Anfragen), die zu HTTP-Antworten 502, 503 oder 504 führen, einmal wiederholt. HTTP-POST-Anfragen werden nicht wiederholt. Bei wiederholten Anfragen wird nur ein Logeintrag für die endgültige Antwort generiert.

Das WebSocket-Protokoll wird für eingehenden GKE-Traffic unterstützt.

Ungültige Verarbeitung von Anfragen und Antworten

Der Load-Balancer blockiert Clientanfragen und Backend-Antworten, sodass diese das Backend oder den Client aus verschiedenen Gründen nicht erreichen. Einige haben einfach mit der HTTP/1.1-Compliance zu tun und bei anderen geht es darum, unerwartete Daten nicht von oder an die Back-Ends weiterzuleiten. Keine der Prüfungen kann deaktiviert werden.

Der Load-Balancer blockiert für die HTTP/1.1-Compliance Folgendes:

• Es kann die erste Zeile der Anfrage nicht parsen.
• In einer Überschrift fehlt das Trennzeichen ":".
• Der Header oder die erste Zeile enthalten ungültige Zeichen.
• Bei der Inhaltslänge handelt es sich nicht um eine gültige Zahl oder es gibt mehrere Header mit Inhaltslängen.
• Es gibt verschiedene Transferverschlüsselungsschlüssel oder Werte für die Transferverschlüsselung wurden nicht erkannt.
• Es gibt einen nicht unterteilten Textkörper und es ist keine Inhaltslänge angegeben.
• Textkörperblöcke können nicht geparst werden. Dies ist der einzige Fall, in dem einige Daten das Back-End erreichen. Der Load-Balancer schließt die Verbindungen zum Client und Back-End, wenn er einen Block empfängt, der nicht geparst werden kann.

Der Load-Balancer blockiert die Anfrage, wenn eine der folgenden Bedingungen zutrifft:

• Die Gesamtgröße der Anfrageheader und der Anfrage-URL überschreitet das Limit für die maximale Größe eines Anfrageheaders für externe Application Load Balancer.
• Die Anfragemethode lässt keinen Textkörper zu, die Anfrage besitzt jedoch einen Textkörper.
• Die Anfrage enthält die Überschrift Upgrade und die Überschrift Upgrade wird nicht zum Aktivieren von WebSocket-Verbindungen verwendet.
• Die HTTP-Version ist nicht bekannt.

Der Load-Balancer blockiert die Antwort des Back-Ends, wenn eine der folgenden Bedingungen zutrifft:

• Die Gesamtgröße der Antwortheader überschreitet das Limit für die maximale Größe eines Antwortheaders für externe Application Load Balancer.
• Die HTTP-Version ist nicht bekannt.

Traffic-Verteilung

Wenn Sie einem Backend-Dienst eine Backend-Instanzgruppe oder NEG hinzufügen, geben Sie einen Balancing-Modus an, der eine Methode zum Messen der Backend-Last und eine Zielkapazität definiert. Externe Application Load Balancer unterstützen zwei Balancing-Modi:

• RATE, für Instanzgruppen oder NEGs, ist die maximale Anzahl von Anfragen (Abfragen) pro Sekunde (RPS, QPS). Der maximale RPS/QPS-Wert kann überschritten werden, wenn alle Back-Ends die Kapazität erreichen oder überschreiten.

• UTILIZATION ist die Backend-Auslastung von VMs in einer Instanzgruppe.

Wie der Traffic auf Back-Ends verteilt wird, hängt vom Modus des Load-Balancers ab.

Globaler externer Application Load Balancer

Bevor ein Google Front End (GFE) Anfragen an Backend-Instanzen sendet, schätzt das GFE, welche Backend-Instanzen Anfragen empfangen können. Diese Kapazitätsschätzung erfolgt proaktiv und nicht gleichzeitig mit eingehenden Anfragen. Die GFEs erhalten regelmäßig Informationen zur verfügbaren Kapazität und verteilen eingehende Anfragen entsprechend.

Was Kapazität bedeutet, hängt zum Teil vom Balancing-Modus ab. Für den RATE-Modus ist dies relativ einfach: Ein GFE bestimmt genau, wie viele Anfragen es pro Sekunde zuweisen kann. UTILIZATION-basiertes Load-Balancing ist komplexer: Der Load-Balancer prüft die aktuelle Auslastung der Instanzen und schätzt dann eine Abfragelast, die jede Instanz verarbeiten kann. Diese Schätzung ändert sich im Laufe der Zeit, wenn sich die Instanzauslastung und die Traffic-Muster ändern.

Beide Faktoren – die Kapazitätsschätzung und die proaktive Zuweisung – beeinflussen die Verteilung zwischen Instanzen. Daher verhält sich Cloud Load Balancing anders als ein einfacher Round Robin-Load-Balancer, der Anfragen exakt im Verhältnis 50:50 auf zwei Instanzen verteilt. Stattdessen versucht Google Cloud Load Balancing, die Auswahl der Backend-Instanz für jede Anfrage zu optimieren.

Beim globalen externen Application Load Balancern ist das Load-Balancing zweistufig. Der Balancing-Modus bestimmt die Gewichtung oder den Anteil des Traffics, der an jedes Backend (Instanzgruppe oder -NEG) gesendet werden soll. Anschließend wird mit der Load-Balancing-Richtlinie (LocalityLbPolicy) festgelegt, wie der Traffic an Instanzen oder Endpunkte innerhalb der Gruppe verteilt wird. Weitere Informationen finden Sie in der Load-Balancing-Richtlinie für den Ort (API-Dokumentation für den Backend-Dienst).

Beim klassischen Application Load Balancer wird der Balancing-Modus verwendet, um das bevorzugte Backend (Instanzgruppe oder NEG) auszuwählen. Der Traffic wird dann nach dem Round-Robin-Verfahren auf Instanzen oder Endpunkte innerhalb des Back-Ends verteilt.

Anfrageverteilung

GFE-basierte externe Application Load Balancer verwenden den folgenden Prozess, um eingehende Anfragen zu verteilen:

1. Vom Client zum GFE der ersten Ebene Edge-Router bewerben die externe IP-Adresse der Weiterleitungsregel am Rand des Google-Netzwerks. Jedes Advertising listet einen nächsten Hop zu einem Layer-3/4-Load-Balancing-System (Maglev) auf. Die Maglev-Systeme leiten Traffic an ein Google Front End (GFE) der ersten Ebene weiter.
   • Bei Verwendung der Premium-Stufe bewirbt Google die IP-Adresse Ihres Load-Balancers von allen Points of Presence weltweit. Jede IP-Adresse des Load-Balancers ist eine globale Anycast-Adresse.
   • Bei Verwendung der Standardstufe bewirbt Google die IP-Adresse Ihres Load Balancers von Points of Presence, die mit der Region der Weiterleitungsregel verknüpft sind. Der Load-Balancer verwendet eine regionale externe IP-Adresse. Mit einer Weiterleitungsregel der Standardstufe können Sie nur Instanzgruppen- und zonale NEG-Backends in derselben Region wie die Weiterleitungsregel des Load Balancers verwenden.
2. Vom GFE der ersten Ebene zum GFE der zweiten Ebene: Das GFE auf der ersten Ebene beendet TLS gegebenenfalls und leitet dann den Traffic gemäß diesem Prozess an GFEs der zweiten Ebene weiter:
   • GFEs der ersten Ebene parsen die URL-Zuordnung und wählen einen Backend-Dienst oder einen Backend-Bucket aus.
   • Bei Backend-Diensten mit Internet-NEGs wählen die GFEs der ersten Ebene ein externes Weiterleitungsgateway aus, das dem GFE der ersten Ebene entspricht. Das Weiterleitungsgateway sendet Anfragen an den Internet-NEG-Endpunkt. Damit ist der Anfrageverteilungsprozess für Internet-NEGs abgeschlossen.
   • Bei Backend-Diensten mit serverlosen NEGs, PSC-NEGs (Private Service Connect) und Backend-Buckets wählen GFEs der ersten Ebene eine zweite GFE-Ebene in der Region aus, die der Region der NEG oder des Buckets entspricht. Bei multiregionalen Cloud Storage-Buckets wählen GFEs der ersten Ebene GFEs der zweiten Ebene in einer Region so nah wie möglich an den GFEs der ersten Ebene aus (definiert durch die Umlaufzeit des Netzwerks).
   • Bei Backend-Diensten mit Instanzgruppen, zonalen NEGs mit GCE_VM_IP_PORT-Endpunkten und Hybrid-NEGs informiert das Kapazitätsverwaltungssystem von Google die GFEs der ersten Ebene über die verwendete und konfigurierte Kapazität für jedes Backend. Die konfigurierte Kapazität für ein Backend wird durch den Balancing-Modus, die Zielkapazität des Balancing-Modus und den Kapazitätsskalierer definiert.
     • Standardstufe: GFEs der ersten Ebene wählen ein GFE der zweiten Ebene in der Region mit den Back-Ends enthält.
     • Premium-Stufe: GFEs der ersten Ebene wählen GFEs der zweiten Ebene aus einer Reihe von anwendbaren Regionen aus. Anwendbare Regionen sind alle Regionen, in denen Back-Ends konfiguriert wurden, mit Ausnahme der Regionen mit konfigurierten Back-Ends, die keine Kapazität haben. GFEs der ersten Ebene wählen das GFE der zweiten Ebene in einer anwendbaren Region aus (definiert durch die Umlaufzeit des Netzwerks). Wenn Back-Ends in zwei oder mehr Regionen konfiguriert sind, können GFEs der ersten Ebene Anfragen an andere anwendbare Regionen übertragen, wenn eine Region der ersten Wahl voll ist. Das Spillover in andere Regionen ist möglich, wenn alle Back-Ends in der Region der ersten Wahl ausgelastet sind.
3. GFEs der zweiten Ebene wählen Back-Ends aus. GFEs der zweiten Ebene befinden sich in Zonen einer Region. They use the following process to select a backend:
   • Bei Backend-Diensten mit serverlosen NEGs, Private Service Connect-NEGs und Backend-Buckets leiten GFEs der zweiten Ebene Anfragen an die Produktionssysteme von Google weiter. Damit ist der Anfrageverteilungsprozess für diese Back-Ends abgeschlossen.

   • Bei Backend-Diensten mit Instanzgruppen, zonalen NEGs mit GCE_VM_IP_PORT-Endpunkten und Hybrid-NEGs informieren die Systemdiagnose-Prüfsysteme von Google die GFEs der zweiten Ebene über den Systemdiagnosestatus der Backend-Instanzen oder -Endpunkte.

     Nur Premium-Stufe: Wenn das GFE der zweiten Ebene keine fehlerfreien Backend-Instanzen oder Endpunkte in seiner Region hat, kann es Anfragen an ein anderes GFE der zweiten Ebene in einer anderen anwendbaren Region mit konfigurierten Backends senden. Der Spillover zwischen GFEs der zweiten Ebene in verschiedenen Regionen erschöpft nicht alle möglichen Kombinationen zwischen Regionen. Wenn Sie Traffic von Back-Ends in einer bestimmten Region weiterleiten müssen, anstatt Back-Ends für Systemdiagnosen zu konfigurieren, sollten Sie den Kapazitätsskalierer des Back-Ends auf null setzen, damit das GFE der ersten Ebene die Region im vorherigen Schritt ausschließt.

   Das GFE der zweiten Ebene leitet dann Anfragen an Backend-Instanzen oder Endpunkte in Zonen innerhalb seiner Region weiter, wie im nächsten Schritt erläutert.

4. GFE der zweiten Ebene wählt eine Zone aus. Standardmäßig verwenden GFEs der zweiten Ebene den WATERFALL_BY_REGION-Algorithmus, bei dem jedes GFE der zweiten Ebene bevorzugt Backend-Instanzen oder Endpunkte in derselben Zone auswählt, in der auch das GFE der zweiten Ebene enthalten ist. Da mit WATERFALL_BY_REGION der Traffic zwischen den Zonen auf minimale Anforderungsraten reduziert wird, sendet das GFE der zweiten Ebene möglicherweise ausschließlich Anfragen an Back-Ends in derselben Zone wie das GFE der zweiten Ebene selbst.

   Nur bei globalen externen Application Load Balancern können GFEs der zweiten Ebene so konfiguriert werden, dass sie einen der folgenden alternativen Algorithmen mithilfe eines serviceLbPolicy verwenden:

   • SPRAY_TO_REGION: GFEs der zweiten Ebene bevorzugen keine Backend-Instanzen oder Endpunkte in derselben Zone wie das GFE der zweiten Ebene. GFEs der zweiten Ebene versuchen, den Traffic auf alle Backend-Instanzen oder Endpunkte in allen Zonen der Region zu verteilen. Hierdurch erfolgt eine gleichmäßigere Lastverteilung auf Kosten von erhöhtem Traffic zwischen den Zonen.
   • WATERFALL_BY_ZONE: GFEs der zweiten Ebene bevorzugen die Auswahl von Backend-Instanzen oder Endpunkten in derselben Zone wie das GFE der zweiten Ebene. GFEs der zweiten Ebene leiten Anfragen nur an Back-Ends in verschiedenen Zonen weiter, nachdem alle Back-Ends in der aktuellen Zone ihre konfigurierte Kapazitäten erreicht haben.
5. Das GFE der zweiten Ebene wählt Instanzen oder Endpunkte innerhalb der Zone aus. Standardmäßig verteilt ein GFE der zweiten Ebene Anfragen nach dem Round-Robin-Verfahren auf Back-Ends. Nur für globale externe Application Load Balancer können Sie dies mithilfe einer Load-Balancing-Richtlinie für den Ort (localityLbPolicy) ändern. Die Load-Balancing-Richtlinie für den Ort gilt nur für Back-Ends innerhalb der ausgewählten Zone, wie im vorherigen Schritt erläutert.

Regionaler externer Application Load Balancer

Bei regionalen externen Application Load Balancern basiert die Trafficverteilung auf dem Load-Balancing-Modus und der Load-Balancing-Richtlinie für den Ort.

Der Balancing-Modus bestimmt die Gewichtung und den Anteil des Traffics, der an jede Gruppe (Instanzgruppe oder NEG) gesendet werden soll. Die Load-Balancing-Richtlinie für den Ort (LocalityLbPolicy) bestimmt, wie Load-Balancing auf die Back-Ends innerhalb der Gruppe angewendet wird.

Wenn ein Backend-Dienst Traffic empfängt, leitet er ihn zuerst an ein Backend (Instanzgruppe oder NEG) gemäß dem Balancing-Modus des Backends weiter. Nach der Auswahl eines Backends wird der Traffic dann gemäß der Load-Balancing-Richtlinie für den Ort auf Instanzen oder Endpunkte in dieser Backend-Gruppe verteilt.

Hier finden Sie weitere Informationen:

• Balancing-Modi
• Load-Balancing-Richtlinie für den Ort (Dokumentation für regionale Backend Service API)

Sitzungsaffinität

Mit der Sitzungsaffinität wird versucht, Anfragen gemäß konfiguriertem Balancing-Modus von einem bestimmten Client an dasselbe Backend zu senden, wenn das Backend intakt ist und Kapazität hat.

Wenn Sie die Sitzungsaffinität verwenden, empfehlen wir den Balancing-Modus RATE statt UTILIZATION. Die Sitzungsaffinität funktioniert am besten, wenn Sie den Balancing-Modus auf Anfragen pro Sekunde (requests per second, RPS) einstellen.

Externe Application Load Balancer bieten die folgenden Arten von Sitzungsaffinität:

• NONE. Es ist keine Sitzungsaffinität für den Load-Balancer festgelegt.
• Client-IP-Affinität
• Generierte Cookie-Affinität
• Header-Feld-Affinität
• HTTP-Cookie-Affinität

In der folgenden Tabelle sind die unterstützten Optionen für die Sitzungsaffinität aufgeführt, die von externen Application Load Balancern in den einzelnen Modi unterstützt werden:

Load-Balancer-Modus	Optionen der Sitzungsaffinität
	–	Client-IP	Generiertes Cookie	Header-Feld	HTTP-Cookie
Globaler externer Application Load Balancer
Klassischer Application Load Balancer
Regionaler externer Application Load Balancer

HTTP/2-Unterstützung

HTTP/2 ist eine wesentliche Überarbeitung des HTTP/1-Protokolls. HTTP/2 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. Selbst wenn ein Load-Balancer für die Verwendung von HTTPS konfiguriert ist, verwenden moderne Clients standardmäßig HTTP/2. Dies wird clientseitig und nicht auf dem Load Balancer gesteuert.

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.

Damit Sie HTTP/2 verwenden können, müssen Sie TLS auf Ihren Backends aktivieren. 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 einem Google Cloud-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. Wenn ein Wert von null angekündigt wird, kann der Load-Balancer keine Anfragen an den Server weiterleiten. Das kann zu Fehlern führen.

HTTP/2-Einschränkungen

• HTTP/2 zwischen dem Load-Balancer und der Instanz kann wesentlich mehr TCP-Verbindungen zur Instanz benötigen als HTTP(S). Verbindungs-Pooling, eine Optimierung, die die Anzahl dieser Verbindungen bei HTTP(S) reduziert, ist bei HTTP/2 derzeit 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 nicht das Ausführen des WebSocket-Protokolls über einen einzelnen Stream einer HTTP/2-Verbindung (RFC 8441).
• HTTP/2 zwischen dem Load-Balancer und dem Backend unterstützt keinen Server-Push.
• Die gRPC-Fehlerrate und das Anfragevolumen sind in der Google Cloud API oder der Google Cloud Console nicht sichtbar. Wenn der gRPC-Endpunkt einen Fehler zurückgibt, melden die Load-Balancer-Logs und die Monitoring-Daten den HTTP-Antwortcode OK 200.

HTTP/3-Unterstützung

HTTP/3 ist ein Internetprotokoll der nächsten Generation. Es baut auf IETF QUIC auf, einem Protokoll, das aus dem ursprünglichen Google QUIC-Protokoll entwickelt wurde. HTTP/3 wird zwischen dem externen Application Load Balancer, Cloud CDN und Clients unterstützt.

Die Unterstützung von Google QUIC (auch als gQUIC bezeichnet) wurde im April 2023 zugunsten von HTTP/3 gegenüber IETF QUIC entfernt. Beides ist ein IETF-Standard, der gQUIC übertroffen hat.

Zum Beispiel:

• IETF QUIC ist ein Protokoll der Transportschicht, das eine Überlastungssteuerung und Zuverlässigkeit wie TCP bietet und TLS 1.3 für Sicherheit und verbesserte Leistung verwendet.
• HTTP/3 ist eine Anwendungsebene, die auf IETF QUIC basiert und QUIC für die Verarbeitung von Multiplexing, Überlastungssteuerung, Verlusterkennung und Neuübertragung verwendet.
• HTTP/3 startet die Clientverbindung schneller, entfernt Blockierungen der Hauptleitung in Multiplexströmen und unterstützt die Verbindungsmigration, wenn sich die IP-Adresse eines Clients ändert.
• HTTP/3 wird für Verbindungen zwischen Clients und dem Load-Balancer unterstützt, nicht für Verbindungen zwischen dem Load-Balancer und seinen Back-Ends.
• HTTP/3-Verbindungen verwenden das BBR-Protokoll zur Überlastungssteuerung.

HTTP/3 in Ihrem Load-Balancer kann die Ladezeiten von Webseiten verbessern, die erneute Zwischenspeicherung von Videos reduzieren und den Durchsatz für Verbindungen mit höherer Latenz verbessern.

Die folgende Tabelle enthält die HTTP/3-Unterstützung für externe Application Load Balancer in jedem Modus.

Load-Balancer-Modus	HTTP/3-Unterstützung
Globaler externer Application Load Balancer (immer Premium-Stufe)
Klassischer Application Load Balancer in der Premium-Stufe
Klassischer Application Load Balancer in der Standardstufe
Regionaler externer Application Load Balancer (Premium- oder Standardstufe)

So wird HTTP/3 ausgehandelt

Wenn HTTP/3 aktiviert ist, bewirbt der Load-Balancer diese Unterstützung gegenüber Clients. So können Clients, die HTTP/3 unterstützen, versuchen, HTTP/3-Verbindungen mit dem HTTPS-Load-Balancer herzustellen.

• Richtig implementierte Clients greifen immer auf HTTPS oder HTTP/2 zurück, wenn sie keine HTTP/3-Verbindung herstellen können.
• Clients, die HTTP/3 unterstützen, verwenden ihr im Cache gespeichertes Vorwissen der HTTP/3-Unterstützung, um unnötige Umläufe in Zukunft zu vermeiden.
• Aus diesem Grund beeinträchtigen die aktiven oder inaktiven HTTP/3-Einstellungen beim Load-Balancer nicht dessen Fähigkeit, eine Verbindung zu Clients herzustellen.

Unterstützung wird im HTTP-Antwort-Header Alt-Svc beworben. Wenn HTTP/3 aktiviert ist, enthalten Antworten vom Load-Balancer den folgenden Wert für den Header alt-svc:

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000"

Hinweis: Der Header Alt-Svc bewirbt mehrere Versionen von HTTP/3, um frühere Entwürfe zu unterstützen, die von einigen Clients verwendet werden (z. B. h3-29).

Wenn HTTP/3 explizit auf DISABLE gesetzt wurde, enthalten Antworten keinen alt-svc-Antwortheader.

Wenn Sie HTTP/3 in Ihrem HTTPS-Load-Balancer aktiviert haben, kann Ihr Client unter bestimmten Umständen auf HTTPS oder HTTP/2 zurückgreifen, anstatt HTTP/3 auszuhandeln. Dazu gehören die folgenden:

• Die Clientversion von HTTP/3 ist nicht mit den vom HTTPS-Load-Balancer unterstützten HTTP/3-Versionen kompatibel.
• Der Load-Balancer ermittelt einen blockierten UDP-Traffic oder einen beschränkten Tarif, sodass HTTP/3 nicht funktioniert
• Der Client unterstützt HTTP/3 überhaupt nicht und versucht daher nicht, eine HTTP/3-Verbindung auszuhandeln.

Wenn eine Verbindung auf HTTPS oder HTTP/2 zurückgreift, gilt dies nicht als Fehler des Load-Balancers.

Prüfen Sie vor dem Aktivieren von HTTP/3, ob die zuvor beschriebenen Verhaltensweisen für Ihre Arbeitslasten akzeptabel sind.

HTTP/3 konfigurieren

Sowohl NONE (Standardeinstellung) als auch ENABLE aktivieren HTTP/3-Unterstützung für Ihren Load-Balancer.

Wenn HTTP/3 aktiviert ist, bewirbt der Load-Balancer diese Clients. Dies ermöglicht Clients, die sie unterstützen, eine HTTP/3-Version mit dem Load-Balancer auszuhandeln. Clients, die HTTP/3 nicht unterstützen, handeln keine HTTP/3-Verbindung aus. Sie müssen HTTP/3 nicht explizit deaktivieren, es sei denn, Sie haben fehlerhafte Clientimplementierungen identifiziert.

Externe Application Load Balancer bieten drei Möglichkeiten zum Konfigurieren von HTTP/3, wie in der folgenden Tabelle dargestellt.

quicOverride-Wert	Verhalten
NONE	Unterstützung für HTTP/3 wird Clients angeboten.
ENABLE	Unterstützung für HTTP/3 wird Clients angeboten. Hinweis: TLS 0-RTT (auch als TLS Early Data bezeichnet) wird noch nicht für HTTP/3 unterstützt.
DISABLE	Deaktiviert explizit das Advertising von HTTP/3 und Google QUIC gegenüber Clients.

So aktivieren oder deaktivieren Sie HTTP/3 explizit:

Konsole: HTTPS

Hinweis: Die Einstellung der HTTP/3-Verhandlung wird derzeit nicht auf der Seite der Zielproxys unterstützt und muss durch Bearbeiten der Load-Balancer-Konfiguration konfiguriert werden.

1. Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.

   Load-Balancing aufrufen

2. Wählen Sie den Load-Balancer aus, den Sie bearbeiten möchten.

3. Klicken Sie auf Frontend-Konfiguration.

4. Wählen Sie die Frontend-IP-Adresse und den Frontend-Port aus, den Sie bearbeiten möchten. Zum Bearbeiten einer HTTP/3-Konfiguration muss das Protokoll HTTPS sein.

HTTP/3 aktivieren

1. Wählen Sie das Drop-down-Menü QUIC-Verhandlung aus.
2. Wählen Sie Aktiviert aus, um HTTP/3 für dieses Frontend explizit zu aktivieren.
3. Wenn Sie mehrere Frontend-Regeln für IPv4 und IPv6 haben, müssen Sie HTTP/3 für jede Regel aktivieren.

HTTP/3 deaktivieren

1. Wählen Sie das Drop-down-Menü QUIC-Verhandlung aus.
2. Wählen Sie Deaktiviert aus, um HTTP/3 für dieses Frontend explizit zu deaktivieren.
3. Wenn Sie mehrere Frontend-Regeln haben, die IPv4 und IPv6 darstellen, müssen Sie HTTP/3 für jede Regel deaktivieren.

gcloud: HTTPS

Bevor Sie diesen Befehl ausführen, müssen Sie eine SSL-Zertifikatressource für jedes Zertifikat erstellen.

gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
    --global \
    --quic-override=QUIC_SETTING

Ersetzen Sie QUIC_SETTING durch einen der folgenden Werte:

• NONE (Standard): ermöglicht Google die Kontrolle darüber, wann HTTP/3 beworben wird.

  HTTP/3 wird beworben, wenn Sie NONE auswählen, aber Google QUIC nicht beworben. In der Google Cloud Console heißt diese Option Automatisch (Standard).

• ENABLE: Bewirbt HTTP/3-Clients.

• DISABLE: Bewirbt HTTP/3 nicht gegenüber Clients.

API: HTTPS

POST https://www.googleapis.com/v1/compute/projects/PROJECT_ID/global/targetHttpsProxies/TARGET_PROXY_NAME/setQuicOverride

{
  "quicOverride": QUIC_SETTING
}

Ersetzen Sie QUIC_SETTING durch einen der folgenden Werte:

• NONE (Standard): Ermöglicht Google die Kontrolle darüber, wann HTTP/3 beworben wird.

  Derzeit wird HTTP/3 beworben, wenn Sie NONE auswählen, aber Google QUIC nicht beworben.

  In der Google Cloud Console heißt diese Option Automatisch (Standard).

• ENABLE: Bewirbt HTTP/3- und Google-QUIC gegenüber Clients

• DISABLE: Bewirbt HTTP/3- und Google-QUIC nicht gegenüber Clients

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 Zielproxy.
• 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 Back-Ends.
• Wenn Sie regionale externe Application Load Balancer mit Cloud Run in einer freigegebenen VPC-Umgebung verwenden, können eigenständige VPC-Netzwerke in Dienstprojekten Traffic an alle anderen Cloud Run-Dienste senden, die in anderen Dienstprojekten in derselben Umgebung einer freigegebenen VPC bereitgestellt werden. Dies ist ein bekanntes Problem. Diese Form des Zugriffs wird in Zukunft blockiert.
• Google Cloud 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.
• Sie können einen regionalen externen Application Load Balancer in der Premium-Stufe nicht mit der Google Cloud Console erstellen. Darüber hinaus sind für diese Load Balancer in der Google Cloud Console nur Regionen verfügbar, die die Standardstufe unterstützen. Verwenden Sie stattdessen die gcloud CLI oder die REST API. Verwenden Sie stattdessen die gcloud CLI oder die REST API.

Nächste Schritte

• Informationen zum Bereitstellen eines globalen externen Application Load Balancers finden Sie unter Externen Application Load Balancer mit einem Compute Engine-Backend einrichten.
• Informationen zum Bereitstellen eines regionalen externen Application Load Balancers finden Sie unter Regionalen externen Application Load Balancer mit einem Compute Engine-Backend einrichten.
• Wenn Sie bereits Nutzer des klassischen Application Load Balancers sind und eine neue Bereitstellung mit dem globalen externen Application Load Balancer planen, lesen Sie den Abschnitt Migration zum globalen externen Application Load Balancer planen.
• Informationen zum Automatisieren der Einrichtung des externen Application Load Balancers mit Terraform finden Sie unter Beispiele für Terraform-Module für externe Application Load Balancer.
• Informationen zum Konfigurieren erweiterter Trafficverwaltungsfunktionen, die mit dem globalen externen Application Load Balancer verfügbar sind, finden Sie unter Übersicht über die Trafficverwaltung für globale externe Application Load Balancer.
• 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.
• Die Standorte für Google PoPs finden Sie unter GFE-Standorte.
• Informationen zur Kapazitätsverwaltung finden Sie in der Anleitung zur Kapazitätsverwaltung mit Load-Balancing und unter Optimierung der Anwendungskapazität mit globalem Load-Balancing.
• Weitere Informationen zum Bereitstellen von Websites finden Sie unter Websites bereitstellen.
• Informationen zum Verwenden von Certificate Manager zum Bereitstellen und Verwalten von SSL-Zertifikaten finden Sie in der Übersicht über Certificate Manager.
• Konfigurieren Sie Diensterweiterungs-Callouts, um eine benutzerdefinierte Logik in den Load-Balancing-Datenpfad einzufügen.