Übersicht über externes HTTP(S)-Load-Balancing

In diesem Dokument werden die Konzepte vorgestellt, die Sie verstehen sollten, wenn Sie das externe HTTP(S)-Load-Balancing von Google Cloud konfigurieren möchten.

HTTP(S)-Load-Balancing ist ein proxybasierter Layer-7-Load-Balancer, mit dem Sie Ihre Dienste hinter einer einzelnen externen IP-Adresse ausführen und skalieren können. Das externe HTTP(S)-Load-Balancing 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 Anwendungsfälle.

Auf dieser Seite wird die Architektur eines eigenständigen externen HTTP(S)-Load-Balancers beschrieben. Wenn Sie Ihre Anwendungen in GKE im Internet freigeben möchten, empfehlen wir die Verwendung des integrierten GKE Ingress für externes HTTP(S)-Load-Balancing.

Modi externer HTTP(S)-Load-Balancer

Sie können das externe HTTP(S)-Load-Balancing in den folgenden Modi konfigurieren:

  • Externer HTTP(S)-Load-Balancer. Dies ist der externe HTTP(S)-Load-Balancer, der regional in der Standardstufe und global in der Premium-Stufe ist. Der externe HTTP(S)-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 HTTP(S)-Load-Balancer (Vorschau). 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 Rechte
Externer HTTP(S)-Load-Balancer

Dies ist der externe HTTP(S)-Load-Balancer, der regional in der Standardstufe und global in der Premium-Stufe ist.

In der Premium-Netzwerkdienststufe bietet der externe HTTP(S)-Load-Balancer multiregionales Load-Balancing, das Traffic an das nächstgelegene fehlerfreie Back-End mit Kapazität weiterleitet und HTTP(S)-Traffic so nah wie möglich an Ihren Nutzern beendet.

In der Standard-Netzwerkdienststufe wird das Load-Balancing regional verarbeitet.

Eine vollständige Liste der Funktionen finden Sie auf der Seite Load-Balancing-Features.
Regionaler externer HTTP(S)-Load-Balancer mit erweiterten Funktionen zur Trafficverwaltung (Vorschau)

Dieser Load-Balancer enthält viele Features des bestehenden externen HTTP(S)-Load-Balancers sowie zusätzliche erweiterte Funktionen für die Trafficverwaltung.

Dies ist der empfohlene externe HTTP(S)-Load-Balancer, mit dem Inhalte nur aus einer Standortbestimmung bereitgestellt werden (z. B. um Compliance-Bestimmungen zu erfüllen).

Verwenden Sie diesen Load-Balancer, wenn nur regionale Back-End-Dienste benötigt werden oder die Standard-Netzwerkdienststufe gewünscht wird.

Eine vollständige Liste finden Sie unter Load-Balancing-Features.

Architektur

Die folgenden Ressourcen sind erforderlich, um einen externen HTTP(S)-Load-Balancer bereitzustellen:

  • Bei regionalen externen HTTP(S)-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 Back-End-Dienste oder Back-End-Buckets weiter. In der URL-Zuordnung können zusätzliche Aktionen angegeben werden, z. B. Weiterleitungen an Clients.

  • Ein Back-End-Dienst verteilt Anfragen an fehlerfreie Back-Ends. Der externe HTTP(S)-Load-Balancer unterstützt auch Back-End-Buckets.

    • Ein oder mehrere Back-Ends müssen mit dem Back-End-Dienst oder Back-End-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 HTTP(S)-Load-Balancer erfordern eine zusätzliche Firewallregel, damit Traffic vom Nur-Proxy-Subnetz die Back-Ends erreichen kann.

Globaler Modus

Dieses Diagramm zeigt die Komponenten einer externen HTTP(S)-Load-Balancer-Bereitstellung.

Komponenten des externen HTTP(S)-Load-Balancers
Komponenten des externen HTTP(S)-Load-Balancers

Regionaler Modus

Dieses Diagramm zeigt die Komponenten der Bereitstellung eines regionalen externen HTTP(S)-Load-Balancers.

Komponenten eines regionalen externen HTTP(S)-Load-Balancers
Komponenten eines regionalen externen HTTP(S)-Load-Balancers

Nur-Proxy-Subnetz

Nur-Proxy-Subnetze sind nur für regionale externe HTTP(S)-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 interne HTTP(S)-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 externen HTTP(S)-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.
  • Back-End-VMs bzw. Endpunkte aller regionalen externen HTTP(S)-Load-Balancer in einer Region und einem VPC-Netzwerk empfangen Verbindungen vom Nur-Proxy-Subnetz.
  • Die IP-Adresse des regionalen externen HTTP(S)-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.

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.

  • Weiterleitungsregeln für einen HTTP-Load-Balancer können nur auf die TCP-Ports 80 und 8080 verweisen.
  • Weiterleitungsregeln für einen HTTPS-Load-Balancer können nur auf den TCP-Port 443 verweisen.

Die Art der Weiterleitungsregel, die IP-Adresse und das Load-Balancing-Schema, die von externen HTTP(S)-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 Front-End des Load-Balancers
Externer HTTP(S)-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 HTTP(S)-Load-Balancer 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.

Eine vollständige Liste der Protokolle, die von HTTP(S)-Load-Balancing-Weiterleitungsregeln 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.

In der folgenden Tabelle ist der Typ des Zielproxys angegeben, der für externe HTTP(S)-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.
Externer HTTP(S)-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-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (nur Anfragen)
    Enthält Parameter für Cloud Trace.
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (see X-Forwarded-For-Header) (nur Anfragen)
Im Back-End-Dienst oder Back-End-Bucket konfiguriert
Regionaler externer HTTP(S)-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)

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>

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 Back-End verbunden ist. Diese IP-Adressen liegen in den Bereichen 130.211.0.0/22 und 35.191.0.0/16.

  • Die IP-Adresse des Back-End-Systems.

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

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

HTTP-/3- und QUIC-Protokollunterstützung

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

Zum Beispiel:

  • IETF QUIC ist ein Protokoll der Transportschicht, das eine Überlastungssteuerung ähnlich wie TCP bietet und mit SSL/TLS vergleichbare Sicherheitsfunktionen für HTTP/2 mit verbesserter Leistung bereitstellt.
  • HTTP/3 ist eine Anwendungsebene, die auf IETF QUIC aufbaut. Es basiert auf QUIC, um Multiplexing, Überlastungssteuerung und Wiederholungsversuche zu bewältigen.
  • 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 wirkt sich auf Verbindungen zwischen Clients und dem Load-Balancer aus, nicht auf Verbindungen zwischen dem Load-Balancer und seinen Back-Ends.
  • HTTP/3-Verbindungen verwenden das BBR-Protokoll zur Überlastungssteuerung.

Das Aktivieren von HTTP/3 in Ihrem externen HTTP(S)-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.

HTTP/3 konfigurieren

Sie können die HTTP/3-Unterstützung für Ihren externen HTTP(S)-Load-Balancer explizit aktivieren, indem Sie quicOverride auf ENABLE setzen. In Zukunft wird HTTP/3 standardmäßig für alle externen HTTP(S)-Load-Balancer-Clients aktiviert.

Clients, die HTTP/3 oder gQUIC nicht unterstützen, handeln keine HTTP/3-Verbindung aus. Sie müssen HTTP/3 nur dann explizit deaktivieren, wenn Sie fehlerhafte oder ältere Clientimplementierungen identifiziert haben.

Der externe HTTP(S)-Load-Balancer bietet drei Modi zum Konfigurieren von HTTP/3, wie in der folgenden Tabelle gezeigt.

quicOverride-Wert Verhalten
NONE

HTTP/3 und Google QUIC werden nicht gegenüber Kunden beworben.

Hinweis: Dies kann sich in Zukunft ändern. HTTP/3 wird standardmäßig für Clients beworben.

ENABLE

Die Unterstützung für HTTP/3 und Google QUIC wird den Clients angezeigt. HTTP/3 wird mit einer höheren Priorität beworben. Clients, die beide Protokolle unterstützen, sollten HTTP/3 gegenüber Google QUIC bevorzugen.

Hinweis: TLS 0-RTT (auch als TLS Early Data bezeichnet) wird implizit unterstützt, wenn Google QUIC vom Client ausgehandelt wird. Es wird jedoch derzeit nicht unterstützt, wenn HTTP/3 verwendet.

DISABLE Deaktiviert explizit das Advertising von HTTP/3 und Google QUIC gegenüber Clients.

So aktivieren oder deaktivieren Sie HTTP/3 explizit:

Konsole: HTTPS

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

    Load-Balancing aufrufen

  2. Wählen Sie den externen HTTP(S)-Load-Balancer aus, den Sie bearbeiten möchten.

  3. Klicken Sie auf Front-End-Konfiguration.

  4. Wählen Sie die Front-End-IP-Adresse und den Front-End-Port aus, den Sie bearbeiten möchten. Zum Bearbeiten von HTTP/3-Konfigurationen müssen die IP-Adresse und der Port HTTPS (Port 443) 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 Front-End explizit zu aktivieren.
  3. Wenn Sie mehrere Front-End-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 Front-End explizit zu deaktivieren.
  3. Wenn Sie mehrere Front-End-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 (Standardeinstellung): Damit kann Google steuern, wann QUIC ausgehandelt wird.

    Derzeit ist QUIC aktiviert, wenn Sie NONE auswählen. Wenn Sie diese Option auswählen, erlauben Sie Google, QUIC-Verhandlungen und HTTP/3 für diesen Load-Balancer in Zukunft automatisch zu aktivieren. In der 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

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 (Standardeinstellung): Damit kann Google steuern, wann QUIC ausgehandelt wird.

    Derzeit ist QUIC aktiviert, wenn Sie NONE auswählen. Wenn Sie diese Option auswählen, erlauben Sie Google, QUIC-Verhandlungen und HTTP/3 für diesen Load-Balancer in Zukunft automatisch zu aktivieren. In der 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

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 QUIC-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 QUIC-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 in der targetHttpsProxy-Ressource eines externen HTTP(S)-Load-Balancers als ENABLE konfiguriert ist, enthalten Antworten vom externen HTTP(S)-Load-Balancer den folgenden alt-svc-Header-Wert:

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,
h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,
quic=":443"; ma=2592000; v="46,43"

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

Wenn QUIC im HTTPS-Load-Balancer ausgewählt ist, kann der Client aus bestimmten Gründen auf HTTPS oder HTTP/2 zurückgreifen, anstatt QUIC 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 blockierten UDP-Traffic oder einen beschränkten Tarif, sodass HTTP/3 (QUIC) nicht funktioniert.
  • Der Client unterstützt HTTP/3 überhaupt nicht und versucht daher nicht, eine HTTP/3-Verbindung auszuhandeln.

Wenn eine Verbindung aus diesen Gründen 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.

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 Back-End-Sets senden.

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

Load-Balancer-Modus Typ der URL-Zuordnung
Externer HTTP(S)-Load-Balancer Global (nur mit einer Teilmenge der unterstützten Features)
Regionaler externer HTTP(S)-Load-Balancer Regional

SSL-Zertifikate

Transport Layer Security (TLS) ist ein Verschlüsselungsprotokoll, das in SSL-Zertifikaten zum Schutz der Netzwerkkommunikation verwendet wird.

Google Cloud verwendet SSL-Zertifikate, um für einen Load-Balancer Datenschutz und Sicherheit von einem Client bereitzustellen. Wenn Sie das HTTPS-basierte Load-Balancing verwenden, müssen Sie ein oder mehrere SSL-Zertifikate auf dem HTTPS-Ziel-Proxy installieren.

In der folgenden Tabelle wird der Bereich für das SSL-Zertifikat angegeben, das von externen HTTP(S)-Load-Balancern in den einzelnen Modi benötigt wird:

Load-Balancer-Modus SSL-Zertifikatsbereich
Externer HTTP(S)-Load-Balancer Global
Regionaler externer HTTP(S)-Load-Balancer Regional

Weitere Informationen zu SSL-Zertifikaten finden Sie hier:

SSL-Richtlinien

Mit SSL-Richtlinien können Sie steuern, welche SSL-Funktionen das HTTPS-Lastenausgleichsmodul mit den HTTPS-Clients aushandelt.

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 SSL-Richtlinien definieren, die steuern, welche SSL-Funktionen vom Load-Balancer ausgehandelt werden, und eine SSL-Richtlinie mit dem Ziel-HTTPS-Proxy verknüpfen.

Back-End-Dienste und -Buckets

Der externe HTTP(S)-Load-Balancer kann Back-End-Dienste und Back-End-Buckets haben. Der regionale externe HTTP(S)-Load-Balancer unterstützt keine Back-End-Buckets.

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

Back-End-Buckets leiten eingehenden Traffic an Cloud Storage-Buckets weiter. Ein Beispiel, das zeigt, wie Sie einen Bucket zu einem externen HTTP(S)-Load-Balancer hinzufügen, finden Sie unter Load-Balancer mit Back-End-Buckets einrichten.

Informationen zum Konfigurieren eines externen HTTP(S)-Load-Balancers über HTTP/2 mit Google Kubernetes Engine Ingress oder über gRPC und HTTP/2 mit Ingress finden Sie unter HTTP/2 für Load-Balancing mit Ingress.

In der folgenden Tabelle sind die Back-End-Features aufgeführt, die vom HTTP(S)-Load-Balancing unterstützt werden.


Load-Balancer-Modus
Unterstützte Back-Ends in einem Back-End-Dienst Unterstützt Back-End-Buckets Unterstützt Google Cloud Armor Unterstützt Cloud CDN. Unterstützt IAP
Instanzgruppen Zonale NEGs Internet-NEGs Serverlose NEGs Hybrid-NEGs
Externer HTTP(S)-Load-Balancer
bei Verwendung der Premium-Stufe

Regionaler externer HTTP(S)-Load-Balancer

Hier finden Sie weitere Informationen:

Protokoll für Back-Ends

Wenn Sie einen Back-End-Dienst für den externen HTTP(S)-Load-Balancer konfigurieren, legen Sie das Protokoll fest, das der Back-End-Dienst für die Kommunikation mit den Back-Ends verwendet. 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 native Unterstützung für das WebSocket-Protokoll, wenn Sie HTTP oder HTTPS als Protokoll für das Back-End 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.

Die Zeitüberschreitung für eine WebSocket-Verbindung hängt vom konfigurierbaren Back-End-Dienst-Zeitlimit 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.

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:

  • Geringe Latenzzeiten, hoch skalierbare, verteilte Systeme
  • 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 Logging zu ermöglichen

Um gRPC mit Ihren Google Cloud-Anwendungen zu verwenden, müssen Sie Anfragen durchgehend über HTTP/2 weiterleiten. So setzen Sie dies mit einem HTTP(S)-Load-Balancer um:

  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.

Mit manchen Clients kann der Load-Balancer aber weiterhin HTTPS aushandeln und an einem externen HTTP(S)-Load-Balancer unsichere HTTP-Anfragen annehmen, auch wenn dieser für die Verwendung von HTTP/2 zwischen dem Load-Balancer und den Back-End-Instanzen konfiguriert ist. Diese HTTP- oder HTTPS-Anfragen werden vom Lastenausgleichsmodul transformiert, um die Anfragen über HTTP/2 an die Back-End-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 HTTP(S)-Load-Balancers über HTTP/2 mit Google Kubernetes Engine Ingress oder über gRPC und HTTP/2 mit Ingress 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 Back-End-Dienst gibt eine Systemdiagnose für Back-End-Instanzen an.

Für die Systemdiagnoseprüfungen müssen Sie eine Firewallregel zum Zulassen von eingehendem Traffic erstellen, damit der Traffic Ihre Back-End-Instanzen erreichen kann. Die Firewallregel muss die folgenden Quellbereiche zulassen:

  • 130.211.0.0/22
  • 35.191.0.0/16

Es ist zwar nicht unbedingt erforderlich, jedoch eine Best Practice, eine Systemdiagnose zu verwenden, deren Protokoll dem Protokoll des Back-End-Dienstes entspricht. So lässt sich beispielsweise mit einer HTTP/2-Systemdiagnose die HTTP/2-Konnektivität zu Back-Ends am genauesten testen. Eine Liste der unterstützten Systemdiagnoseprotokolle finden Sie unter Load-Balancing-Features.

In der folgenden Tabelle wird der Bereich der Systemdiagnose angegeben, der von den externen HTTP(S)-Load-Balancern in den einzelnen Modi unterstützt wird.

Load-Balancer-Modus Systemdiagnosetyp
Externer HTTP(S)-Load-Balancer Global
Regionaler externer HTTP(S)-Load-Balancer Regional

Weitere Informationen zu Systemdiagnosen finden Sie hier:

Firewallregeln

Für einen externen HTTP(S)-Load-Balancer sind die folgenden Firewallregeln erforderlich:

  • Externer HTTP(S)-Load-Balancer: eine Regel zum Zulassen von eingehendem Traffic, um Traffic von Google Front Ends (GFEs) zu Ihren Back-Ends zuzulassen.
    Regionaler externer HTTP(S)-Load-Balancer: eine Regel zum Zulassen von eingehendem Traffic, um Traffic vom Nur-Proxy-Subnetz 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.

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

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

  • Instanzgruppen-Back-Ends: Bestimmen Sie die Ports, die durch die Zuordnung zwischen dem benannten Port des Back-End-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 Back-End-Dienst zugewiesen ist, variieren.

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

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. Für externe HTTP(S)-Load-Balancer können Sie dies mit Google Cloud Armor erreichen.

In der folgenden Tabelle sind für externe HTTP(S)-Load-Balancer die erforderlichen IP-Adressbereiche für die Firewallregeln zusammengefasst:

Load-Balancer-Modus Quellbereiche für Systemdiagnosen Quellbereiche anfordern
Externer HTTP(S)-Load-Balancer
  • 130.211.0.0/22
  • 35.191.0.0/16
Die Quelle des GFE-Traffics hängt vom Back-End-Typ ab:
  • 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 Back-End-Buckets: Das Produktionsnetzwerk von Google verarbeitet das Paketrouting.
Regionaler externer HTTP(S)-Load-Balancer
  • 130.211.0.0/22
  • 35.191.0.0/16
Das von Ihnen konfigurierte Nur-Proxy-Subnetz.

Funktionsweise von Verbindungen im HTTP(S)-Load-Balancing

Externe HTTP(S)-Load-Balancer-Verbindungen

Der externe HTTP(S)-Load-Balancer ist ein Dienst, der von vielen Proxys, den sogenannten Google Front-Ends (GFEs) implementiert wird. 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.

Abhängig von der Back-End-Dienstkonfiguration kann das Protokoll, mit dem jedes GFE eine Verbindung zu Ihren Back-Ends 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 ein Keepalive-Zeitlimit von 600 Sekunden, das Sie nicht konfigurieren können. Sie können das Zeitlimit für Anfragen/Antworten jedoch 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.

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 des HTTP(S)-Load-Balancings im Lösungsleitfaden "Optimierung der Anwendungskapazität mit globalem Load-Balancing".

Regionale externe HTTP(S)-Load-Balancer-Verbindungen

Der regionale externe HTTP(S)-Load-Balancer ist ein verwalteter Dienst, der auf dem Envoy-Proxy implementiert wird. Der regionale externe HTTP(S)-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 externen HTTP(S)-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 Back-End-Dienstkonfiguration kann das Protokoll, mit dem Envoy-Proxys eine Verbindung zu Ihren Back-Ends 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 verwendet ein Keepalive-Zeitlimit von 600 Sekunden, das Sie nicht konfigurieren können. Sie können das Zeitlimit für Anfragen/Antworten jedoch 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.
  • HTTP(S)-Load-Balancing unterstützt die Antwort HTTP/1.1 100 Continue.

Eine vollständige Liste der Protokolle, die von HTTP(S)-Load-Balancing-Weiterleitungsregeln 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 externen HTTP(S)-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 Back-End-VM oder des Containers im VPC-Netzwerk.

Für den regionalen externen HTTP(S)-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 Back-End-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 Back-End-VM oder des Containers im VPC-Netzwerk.

Return-Path

Für externe HTTP(S)-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 HTTP(S)-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 Back-End. In Ihrem VPC-Netzwerk definierte Routen vereinfachen die Kommunikation von Envoy-Proxys zu Ihren Back-Ends und von Ihren Back-Ends zu den Envoy-Proxys.

Offene Ports

Dieser Abschnitt gilt nur für den externen HTTP(S)-Load-Balancer, der mit GFEs implementiert wird.

GFEs haben mehrere offene Ports, um andere Google-Dienste, die in derselben Architektur ausgeführt werden, zu unterstützen. Eine Liste der Ports, die in GFEs wahrscheinlich geöffnet sind, finden Sie unter Weiterleitungsregel: Portspezifikationen. Möglicherweise gibt es andere offene Ports für andere Google-Dienste, die auf GFEs ausgeführt werden.

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 für eine Vielzahl von Ports, wenn Ihr Load-Balancer eine IP-Adresse der Premium-Stufe verwendet. GFEs senden jedoch nur Pakete an Ihre Back-Ends, wenn Pakete an die IP-Adresse und den Zielport Ihres Load-Balancers gesendet wurden, die in seiner Weiterleitungsregel konfiguriert sind. Pakete, die an verschiedene IP-Adressen des Load-Balancers oder an die IP-Adresse Ihres Load-Balancers an einem Port gesendet werden, der nicht in Ihrer Weiterleitungsregel konfiguriert ist, führen nicht dazu, dass Pakete an die Back-Ends Ihres Load-Balancers gesendet werden. GFEs implementieren Sicherheitsfunktionen wie Google Cloud Armor. Auch ohne Google Cloud Armor-Konfiguration bieten die Google-Infrastruktur und die GFEs gestaffelte Sicherheitsebenen für DDoS-Angriffe und SYN-Floods.

  • 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 einen externen HTTP(S)-Load-Balancer, der den TCP-Port 443 verwendet, 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 Back-End-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 HTTP(S)-Load-Balancern in den einzelnen Modi Modus verarbeitet wird.

Load-Balancer-Modus TLS-Terminierung
Externer HTTP(S)-Load-Balancer TLS wird auf einem GFE terminiert, das sich überall auf der Welt befinden kann.
Regionaler externer HTTP(S)-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

HTTP(S)-Load-Balancing umfasst zwei verschiedene Zeitüberschreitungstypen:
  • Ein konfigurierbares HTTP-Zeitlimit des Back-End-Diensts, das angibt, wie lange der Load-Balancer auf eine vollständige HTTP-Antwort vom Back-End wartet. Der Standardwert für das Zeitlimit des Back-End-Diensts beträgt 30 Sekunden. Zulässig sind Zeitlimitwerte im Bereich von 1 bis 2.147.483.647 Sekunden.

    Bei HTTP-Traffic ist dieses Zeitlimit die maximale Dauer der HTTP-Anfrage und -Antwort.

    Bei WebSocket-Traffic ist dieses Zeitlimit die maximale Zeit, die eine WebSocket-Verbindung geöffnet sein kann – im Leerlauf oder aktiv.

    Unter diesen Umständen sollten Sie dieses Zeitlimit eventuell erhöhen:

    • Sie erwarten, dass HTTP-Antworten von einem Back-End länger dauern.
    • Sie sehen eine HTTP-408-Antwort mit jsonPayload.statusDetail client_timed_out.
    • Die Verbindung wurde zu einem WebSocket hochgestuft.

    Ein praktischer Zeitlimitwert für externe HTTP(S)-Load-Balancer ist beispielsweise 1 Tag (86.400 Sekunden). Beachten Sie, dass Ereignisse wie GFE-Neustarts Sitzungen früher beenden können.

    Das Zeitlimit des Back-End-Diensts ist keine HTTP-Leerlaufzeitüberschreitung (Keepalive-Zeitüberschreitung). Es kann vorkommen, dass die Ein- und Ausgabe (E/A) des Back-Ends aufgrund eines langsamen Clients, z. B. ein Browser mit langsamer Verbindung, blockiert wird. Diese Wartezeit wird nicht auf das Zeitlimit des Back-End-Dienstes angerechnet.

    Bei regionalen externen HTTP(S)-Load-Balancern kann der Parameter routeActions.timeout der URL-Zuordnung das Zeitlimit des Back-End-Dienstes überschreiben. Das Zeitlimit für den Back-End-Dienst wird als Standardwert für routeActions.timeout verwendet.

  • Ein HTTP-Keepalive-Zeitlimit, dessen Wert unveränderlich bei 10 Minuten (600 Sekunden) liegt. Dieser Wert kann nicht konfiguriert werden, indem Ihr Back-End-Dienst geändert wird. Sie müssen die von den Back-Ends verwendete Webserversoftware so konfigurieren, dass die darin angegebene Keepalive-Zeitüberschreitung länger als 600 Sekunden ist, damit Verbindungen nicht vorzeitig vom Back-End geschlossen werden. Dieses Zeitlimit gilt nicht für WebSockets.

    In dieser Tabelle werden die Änderungen dargestellt, die erforderlich sind, um Keepalive-Zeitlimits bei häufig verwendeter Webserversoftware zu ändern:

    Webserversoftware Parameter Standardeinstellung Empfohlene Einstellung
    Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
    nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;
Die Unterstützung von HTTP(S)-Load-Balancing für die Wiederholungslogik hängt vom Modus des externen HTTP(S)-Load-Balancers ab.

Load-Balancer-Modus Wiederholungslogik
Externer HTTP(S)-Load-Balancer

Wiederholungsrichtlinie kann 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 Back-End-Instanz in einer Gruppe vorhanden ist und die Verbindung zu dieser Back-End-Instanz fehlschlägt, beträgt der Prozentsatz fehlerhafter Back-End-Instanzen 100 %, sodass das GFE die Anfrage nicht wiederholt.

Der Load-Balancer wiederholt fehlerhafte GET-Anfragen unter bestimmten Umständen, etwa wenn das Zeitlimit des Back-End-Diensts abgelaufen ist. Es gibt maximal zwei Wiederholungsversuche. Bei wiederholten Anfragen wird nur ein Logeintrag für die endgültige Antwort generiert. Weitere Informationen finden Sie unter Logging und Monitoring für das HTTP(S)-Load-Balancing.

Fehlgeschlagene Anfragen führen dazu, dass der Load-Balancer die HTTP-Antwort 502 synthetisiert.

Regionaler externer HTTP(S)-Load-Balancer

Über eine Wiederholungsrichtlinie in der URL-Zuordnung konfigurierbar

Ohne eine Wiederholungsrichtlinie werden Anfragen ohne HTTP-Text (z. B. GET-Anfragen) einmal wiederholt.

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

Ungültige Verarbeitung von Anfragen und Antworten

Der externe HTTP(S)-Load-Balancer kann Clientanfragen und Back-End-Antworten aus verschiedenen Gründen blockieren, sodass diese das Back-End bzw. den Client 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 das externe HTTP(S)-Load-Balancing.
  • Die Anfragemethode lässt keinen Textkörper zu, die Anfrage enthält 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 das externe HTTP(S)-Load-Balancing.
  • Die HTTP-Version ist nicht bekannt.

Traffic-Verteilung

Wenn Sie einem Back-End-Dienst eine Back-End-Instanzgruppe oder NEG hinzufügen, geben Sie einen Balancing-Modus an, der eine Methode zum Messen der Back-End-Last und eine Zielkapazität definiert. Das externe HTTP(S)-Load-Balancing unterstützt 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 Back-End-Auslastung von VMs in einer Instanzgruppe.

Wie der Traffic zwischen Back-Ends verteilt wird, hängt vom Modus des externen HTTP(S)-Load-Balancers ab.

Trafficverteilung über externen HTTP(S)-Load-Balancer

Bevor ein Google Front End (GFE) Anfragen an Back-End-Instanzen sendet, schätzt das GFE, welche Back-End-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 Back-End-Instanz für jede Anfrage zu optimieren.

Weitere Informationen finden Sie unter Trafficverteilung.

Trafficverteilung über regionalen externen HTTP(S)-Load-Balancer

Bei einem regionalen externen HTTP(S)-Load-Balancer basiert die Trafficverteilung auf dem Load-Balancing-Modus und der Load-Balancing-Richtlinie für den Ort.

Der Balancing-Modus bestimmt die Gewichtung/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 Back-End-Dienst Traffic empfängt, leitet er ihn zuerst an ein Back-End (Instanzgruppe oder NEG) gemäß dem Balancing-Modus des Back-Ends weiter. Nach der Auswahl eines Back-Ends wird der Traffic dann gemäß der Load-Balancing-Richtlinie für den Ort auf Instanzen oder Endpunkte in dieser Back-End-Gruppe verteilt.

Weitere Informationen finden Sie unter:

Anfrageverteilung

Ob der Traffic regional oder global verteilt ist, hängt davon ab, welcher Load-Balancer-Modus und welche Netzwerkdienststufe verwendet werden.

In der Premium-Stufe (gilt nur für externe HTTP(S)-Load-Balancer):

  • Google bewirbt die IP-Adresse Ihres Load-Balancers von allen Points of Presence weltweit. Jede IP-Adresse des Load-Balancers ist eine globale Anycast-Adresse.
  • Wenn Sie einen Back-End-Dienst mit Back-Ends in mehreren Regionen konfigurieren, versuchen Google Front Ends (GFEs) Anfragen an fehlerfreie Back-End-Instanzgruppen oder NEGs in der Region weiterzuleiten, die dem Nutzer am nächsten ist. Weitere Informationen zu diesem Vorgang finden Sie auf dieser Seite.

Standardstufe:

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

  • Sie können Back-Ends in derselben Region wie die Weiterleitungsregel konfigurieren. Der hier dokumentierte Prozess gilt weiterhin, aber GFEs leiten Anfragen nur an fehlerfreie Back-Ends in dieser Region weiter.

Ablauf der Anfrageverteilung:

Der Balancing-Modus und die Auswahl des Ziels definieren die Back-End-Vollständigkeit aus der Perspektive jeder zonalen GCE_VM_IP_PORT-NEG, zonalen Instanzgruppe oder Zone einer regionalen Instanzgruppe. Die Verteilung innerhalb einer Zone erfolgt anschließend mit konsistentem Hashing.

Der Load-Balancer verwendet den folgenden Prozess:

  1. Die externe IP-Adresse der Weiterleitungsregel wird durch Edge-Router an den Rändern des Google-Netzwerks beworben. Jede Anzeige enthält einen nächsten Hop zu einem Layer-Load-Balancing-System mit 3/4-Ebene (Maglev) in größtmöglicher Nähe des Nutzers.
  2. Maglev-Systeme prüfen die Quell-IP-Adresse des eingehenden Pakets. Sie leiten die eingehende Anfrage an die Maglev-Systeme weiter, die von den Geo-IP-Systemen von Google so nah wie möglich am Nutzer ermittelt werden.
  3. Die Maglev-Systeme leiten Traffic an ein Google Front End (GFE) der ersten Ebene weiter. Das GFE auf der ersten Ebene beendet TLS gegebenenfalls und leitet dann den Traffic gemäß diesem Prozess an GFEs der zweiten Ebene weiter:
    1. Die URL-Zuordnung wählt einen Back-End-Dienst aus.
    2. Wenn ein Back-End-Dienst eine Instanzgruppe oder GCE_VM_IP_PORT-NEG-Back-Ends verwendet, bevorzugen die GFEs der ersten Ebene GFEs der zweiten Ebene, die sich innerhalb oder in der Nähe der Region mit der Instanzgruppe oder NEG befinden.
    3. Bei Back-End-Buckets und Back-End-Diensten mit Hybrid-NEGs, serverlosen NEGs und Internet-NEGs wählen die GFEs der ersten Ebene GFEs der zweiten Ebene in einer Teilmenge von Regionen aus, sodass die Umlaufzeit zwischen den beiden GFEs minimiert wird.

      Die GFE-Einstellung der zweiten Ebene ist keine Garantie und kann sich je nach den Netzwerkbedingungen und Wartungsaktivitäten von Google dynamisch ändern.

      GFEs der zweiten Ebene erkennen den Status der Systemdiagnose und die tatsächliche Nutzung der Back-End-Kapazität.

  4. Das GFE der zweiten Ebene leitet Anfragen an Back-Ends in Zonen innerhalb seiner Region weiter.
  5. Bei der Premium-Stufe senden GFEs der zweiten Ebene manchmal Anfragen an Back-Ends in Zonen unterschiedlicher Regionen. Dieses Verhalten wird als Spillover bezeichnet.
  6. Das Spillover unterliegt zwei Prinzipien:

    • Ein Spillover ist möglich, wenn alle Back-Ends, die einem GFE einer zweiten Ebene bekannt sind, ausgelastet oder fehlerhaft sind.
    • Das GFE der zweiten Ebene enthält Informationen für fehlerfreie, verfügbare Back-Ends in Zonen einer anderen Region.

    Die GFEs der zweiten Ebene sind in der Regel so konfiguriert, dass sie eine Teilmenge der Back-End-Standorte bereitstellen.

    Das Spillover-Verhalten schöpft nicht alle möglichen Google Cloud-Zonen aus. Wenn Sie Traffic von Back-Ends in einer bestimmten Zone oder einer gesamten Region weiterleiten müssen, legen Sie den Kapazitätsskalierer auf null fest. Wenn Sie Back-Ends für Systemdiagnosen konfigurieren, ist nicht garantiert, dass das GFE der zweiten Ebene Anfragen an Back-Ends in Zonen einer anderen Region weiterleitet.

  7. Beim Verteilen von Anfragen an Back-Ends arbeiten GFEs auf einer zonalen Ebene.

    Bei einer geringen Anzahl von Anfragen pro Sekunde bevorzugen GFEs der zweiten Ebene manchmal eine bestimmte Zone innerhalb einer Region. Dieses Verhalten ist normal und wird erwartet. Die Verteilung der Zonen in der Region ist erst gleichmäßig, wenn der Load-Balancer mehr Anfragen pro Sekunde erhält.

Sitzungsaffinität

Mit der Sitzungsaffinität wird versucht, Anfragen gemäß konfiguriertem Balancing-Modus von einem bestimmten Client an dasselbe Back-End zu senden, wenn das Back-End 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.

Das HTTP(S)-Load-Balancing von Google Cloud bietet die folgenden Arten von Sitzungsaffinität:

In der folgenden Tabelle sind die unterstützten Sitzungsaffinitätsoptionen für jeden Modus externer HTTP(S)-Load-Balancer zusammengefasst:

Load-Balancer-Modus Optionen der Sitzungsaffinität
  Client-IP Generiertes Cookie Header-Feld HTTP-Cookie
Externer HTTP(S)-Load-Balancer
Regionaler externer HTTP(S)-Load-Balancer

HTTP/2-Unterstützung

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

  • Bei externen HTTP(S)-Load-Balancern kann HTTP/2 zwischen dem Load-Balancer und der Instanz 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.
  • HTTP/2 zwischen dem Load-Balancer und dem Back-End 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 Back-End unterstützt keinen Server-Push.
  • Die gRPC-Fehlerrate und das Anfragevolumen sind in der Google Cloud API oder der Cloud Console nicht sichtbar. Wenn der gRPC-Endpunkt einen Fehler zurückgibt, melden die Load-Balancer-Logs und der Bericht mit den Monitoring-Daten den HTTP-Antwortcode "OK 200".

Nächste Schritte