Ü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 von Google Cloud ist ein globaler, proxybasierter Layer-7-Load-Balancer, mit dem Sie Ihre Dienste weltweit hinter einer einzelnen externen IP-Adresse ausführen und skalieren können. Das externe HTTP(S)-Load-Balancing verteilt HTTP- und HTTPS-Traffic an Back-Ends, die in Compute Engine und Google Kubernetes Engine (GKE) gehostet werden.

Externes HTTP(S)-Load-Balancing ist auf Google Front Ends (GFEs) implementiert. GFEs sind global verteilt und arbeiten über das globale Netzwerk und die Steuerungsebene von Google zusammen. Auf der Premium-Stufe bieten GFEs multiregionales Load-Balancing, bei dem Traffic an das nächstgelegene fehlerfreie Back-End mit Kapazität weitergeleitet und HTTP(S)-Traffic so nahe wie möglich bei den Nutzern beendet wird. Bei der Standard-Stufe wird das Load-Balancing regional verarbeitet.

Informationen über die unterschiedlichen Google Cloud-Load-Balancer finden Sie in den folgenden Dokumenten:

Anwendungsfälle

Die externen HTTP(S)-Load-Balancer sind für zahlreiche Anwendungsfälle vorgesehen. In diesem Abschnitt werden einige allgemeine Beispiele aufgeführt.

Dreistufige Webdienste

Zur Unterstützung traditioneller dreistufiger Webdienste können Sie das externe HTTP(S)-Load-Balancing verwenden. Das folgende Beispiel zeigt, wie Sie mit drei Arten von Google Cloud-Load-Balancern drei Stufen skalieren können. Auf jeder Stufe hängt die Art des Load-Balancers von Ihrem Traffictyp ab:

  • Webstufe: Der Traffic geht über das Internet ein und wird mithilfe eines externen HTTP(S)-Load-Balancers entsprechend verteilt.

  • Anwendungsstufe: Die Anwendungsstufe wird mithilfe eines regionalen internen HTTP(S)-Load-Balancers skaliert.

  • Datenbankstufe: Die Datenbankstufe wird mithilfe eines internen TCP/UDP-Load-Balancers skaliert.

Das Diagramm zeigt, wie sich der Traffic durch die Ebenen bewegt:

  1. Ein externer HTTP(S)-Load-Balancer (Gegenstand dieser Übersicht) verteilt den Traffic aus dem Internet an eine Gruppe von Web-Front-End-Instanzgruppen in verschiedenen Regionen.
  2. Diese Web-Front-Ends senden den HTTP(S)-Traffic an eine Gruppe regionaler interner HTTP(S)-Load-Balancer. Damit der externe HTTP(S)-Load-Balancer Traffic an einen internen HTTP(S)-Load-Balancer weiterleiten kann, muss der externe HTTP(S)-Load-Balancer Back-End-Instanzen mit Webserversoftware wie Netscaler oder NGNIX so konfiguriert haben, dass der Traffic an das Front-End des internen HTTP(S)-Load-Balancers weitergeleitet wird.
  3. Die internen HTTP(S)-Load-Balancer verteilen den Traffic auf Middleware-Instanzgruppen.
  4. Diese Middleware-Instanzgruppen senden den Traffic an interne TCP/UDP-Load-Balancer, die den Traffic auf Datenspeichercluster verteilen.

Auf Layer 7 basiertes Routing für interne Ebenen in einer mehrstufigen Anwendung.
Auf Layer 7 basiertes Routing für interne Ebenen in einer mehrstufigen Anwendung

Multiregionales Load-Balancing

Darstellung des multiregionalen Load-Balancing

Wenn Sie einen externen HTTP(S)-Load-Balancer in der Premium-Stufe konfigurieren, wird eine globale externe IP-Adresse verwendet und Anfragen von Nutzern können basierend auf ihrer Entfernung intelligent an die nächste Back-End-Instanzgruppe oder NEG weitergeleitet werden. Wenn Sie beispielsweise Instanzgruppen in Nordamerika, Europa und Asien einrichten und sie an den Back-End-Dienst eines Load-Balancers anhängen, werden Nutzeranfragen weltweit automatisch an die VMs gesendet, die den Nutzern am nächsten sind, wenn die VMs die Systemdiagnosen bestehen und genügend Kapazität haben (definiert durch den Balancing-Modus). Wenn die nächsten VMs fehlerhaft sind oder die nächste Instanzgruppe ausgelastet ist, eine andere Instanzgruppe aber nicht, sendet der Load-Balancer automatisch Anfragen an die nächste Region mit Kapazität.


Load-Balancing mit Anfragerouting

Darstellung von inhaltsbasiertem Load-Balancing.

HTTP(S)-Load-Balancing unterstützt Anfragerouting durch URL-Zuordnungen, um einen Back-End-Dienst anhand des angefragten Hostnamens, Anfragepfads oder von beiden auszuwählen. Sie können beispielsweise mit Instanzgruppen oder NEGs Ihre Videoinhalte und mit einer anderen Gruppe alles andere verarbeiten.

Sie können HTTP(S)-Load-Balancing auch mit Cloud Storage-Buckets verwenden. Nachdem Sie Ihren Load-Balancer eingerichtet haben, können Sie ihm Cloud Storage-Buckets hinzufügen.


Load-Balancing mithilfe mehrerer Back-End-Typen

Externes HTTP(S)-Load-Balancing unterstützt die folgenden Back-End-Typen:

Ein häufiger Anwendungsfall ist das Load-Balancing zwischen verschiedenen Diensten. Im folgenden Beispiel können externe IPv4- und IPv6-Clients über dieselbe Basis-URL mit den Pfaden /api, /video und /images Video-, API- und Bildinhalte anfordern.

Mit der URL-Zuordnung des externen HTTP(S)-Load-Balancers wird Folgendes angegeben:

  • Anfragen an den Pfad /api werden zu einem Back-End-Dienst mit einer VM-Instanzgruppe oder einem zonalen NEG-Back-End geleitet.
  • Anfragen an den Pfad /images werden zu einem Back-End-Bucket mit einem Cloud Storage-Back-End geleitet.
  • Anfragen an den Pfad /video werden zu einem Back-End-Dienst geleitet, der auf eine Internet-NEG mit einem externen Endpunkt verweist, der sich an einem lokalen Speicherort außerhalb von Google Cloud befindet.

Wenn ein Client eine Anfrage an die externe IPv4- oder IPv6-Adresse des Load-Balancers sendet, wertet der Load-Balancer die Anfrage gemäß der URL-Zuordnung aus und sendet sie an den richtigen Dienst.

Das folgende Diagramm veranschaulicht diesen Anwendungsfall.

Load-Balancing-Diagramm mit einem externen Back-End.
Load-Balancing-Diagramm mit einem externen Back-End (zum Vergrößern klicken)

Bei jedem Back-End-Dienst können Sie optional Cloud CDN und Google Cloud Armor aktivieren. Wenn Sie Google Cloud Armor mit Cloud CDN verwenden, werden Sicherheitsrichtlinien nur für Anfragen für dynamischen Inhalt, Cache-Fehlschläge oder andere Anfragen umgesetzt, die für den CDN-Ursprungsserver bestimmt sind. Cache-Treffer werden auch dann gezeigt, wenn die nachgelagerte Google Cloud Armor-Sicherheitsrichtlinie verhindern würde, dass die Anfrage Ihren Ursprungsserver erreicht.

Cloud CDN wird in Back-End-Buckets unterstützt, Google Cloud Armor jedoch nicht.

Kombinierten Load-Balancer erstellen

Sie können einen externen HTTP(S)-Load-Balancer in der Premium-Stufe konfigurieren, um sowohl ein multiregionales Load-Balancing als auch mehrere Back-End-Dienste mit jeweils Back-End-Instanzgruppen oder NEGs in mehreren Regionen zu ermöglichen. Sie können die Anwendungsfälle kombinieren und erweitern, um einen externen HTTP(S)-Load-Balancer zu konfigurieren, der Ihren Anforderungen entspricht.

Darstellung von multiregionalem Load-Balancing.
Darstellung des multiregionalen Load-Balancing

Architektur

Das folgende Diagramm zeigt die Google Cloud-Ressourcen, die für einen externen HTTP(S)-Load-Balancer erforderlich sind.

HTTP(S)-Load-Balancing-Komponenten.
HTTP(S)-Load-Balancing-Komponenten

Die folgenden Ressourcen definieren einen internen HTTP(S)-Load-Balancer:

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

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

  • Wenn Sie HTTPS-Load-Balancing verwenden, verwendet der HTTPS-Zielproxy globale SSL-Zertifikate, um seine Identität gegenüber Clients nachzuweisen. Ein HTTP(S)-Zielproxy unterstützt bis zur dokumentierten Anzahl von SSL-Zertifikaten.

  • Der HTTP(S)-Proxy verwendet eine globale 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 oder ein Back-End-Bucket verteilt Anfragen an fehlerfreie Back-Ends.

  • Ein oder mehrere Back-Ends müssen mit dem Back-End-Dienst oder Back-End-Bucket verbunden sein. Back-Ends können Instanzgruppen, NEGs oder Buckets in einer der folgenden Konfigurationen sein:

    • Verwaltete Instanzgruppen (zonal oder regional)
    • Nicht verwaltete Instanzgruppen (zonal)
    • Netzwerk-Endpunktgruppen (zonal)
    • Netzwerk-Endpunktgruppen (Internet)
    • Cloud Storage-Buckets

    Sie können nicht sowohl Instanzgruppen als auch NEGs für denselben Back-End-Dienst haben.

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

  • Eine Firewall für Ihre Back-Ends, um Systemdiagnoseprüfungen zu akzeptieren.

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.

Welche Art von Weiterleitungsregel für externe HTTP(S)-Load-Balancer erforderlich ist, hängt davon ab, auf welcher Netzwerkdienststufe sich der Load-Balancer befindet.

  • Die externen HTTP(S)-Load-Balancer in der Premium-Stufe verwenden globale externe Weiterleitungsregeln.
  • Die externen HTTP(S)-Load-Balancer in der Standardstufe verwenden regionale externe Weiterleitungsregeln.

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

Die Proxys richten Header für HTTP-Anfragen/Antworten wie folgt 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.

Erstellen Sie benutzerdefinierte Anfrage- und Antwortheader, wenn die Standardheader nicht Ihren Anforderungen entsprechen. Weitere Informationen zu diesem Feature finden Sie unter Benutzerdefinierte Header erstellen.

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.

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>

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.

SSL-Zertifikate

Wenn Sie das HTTPS-basierte Load-Balancing verwenden, müssen Sie ein oder mehrere SSL-Zertifikate auf dem HTTPS-Ziel-Proxy installieren.

Diese Zertifikate werden von HTTPS-Ziel-Proxys verwendet, um die Kommunikation zwischen dem Load-Balancer und dem Client zu sichern.

Informationen zur Anzahl und zu den Kontingenten von SSL-Zertifikaten finden Sie auf der Seite mit den Load-Balancing-Kontingenten unter SSL-Zertifikate.

Um optimale Sicherheit zu erhalten, verwenden Sie bei der Bereitstellung des HTTPS-Load-Balancers eine Ende-zu-Ende-Verschlüsselung. Weitere Informationen finden Sie unter Verschlüsselung vom Load-Balancer zu Back-Ends.

Allgemeine Informationen darüber, wie Google Nutzertraffic verschlüsselt, finden Sie im Whitepaper Verschlüsselung bei der Übertragung in Google Cloud.

SSL-Richtlinien

Mit SSL-Richtlinien können Sie steuern, welche SSL-Funktionen das HTTPS-Load-Balancer 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

Ein externer HTTP(S)-Load-Balancer kann entweder Back-End-Dienste oder Back-End-Buckets haben.

Back-End-Dienste

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

Back-End-Buckets leiten eingehenden Traffic an Cloud Storage-Buckets weiter.

Ein Beispiel, das zeigt, wie Sie einen Bucket zu einem Load-Balancer hinzufügen, finden Sie unter Load-Balancer mit Back-End-Buckets einrichten.

Systemdiagnosen

Der Back-End-Dienst legt außerdem fest, welche Systemdiagnose für die verfügbaren Instanzen ausgeführt werden. Damit die Systemdiagnosetests korrekt ausgeführt werden können, müssen Sie eine Firewallregel erstellen, die Traffic von 130.211.0.0/22 und 35.191.0.0/16 an Ihre Instanzen zulässt.

Weitere Informationen zu Systemdiagnosen finden Sie unter Systemdiagnosen erstellen.

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.

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.

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

Firewallregeln

Die Back-End-Instanzen müssen Verbindungen von den GFE- / Systemdiagnosebereichen des Load-Balancers zulassen. Dies bedeutet, dass Sie eine Firewallregel zum Zulassen von eingehendem Traffic erstellen müssen, um Traffic von 130.211.0.0/22 und 35.191.0.0/16 an Ihre Back-End-Instanzen oder -Endpunkte weiterzuleiten. Diese IP-Adressbereiche werden als Quellen für Systemdiagnose-Pakete und für alle Pakete mit Load-Balancing verwendet, die an Ihre Back-Ends gesendet werden.

Die Ports, die Sie für diese Firewallregel konfigurieren, müssen die folgenden Voraussetzungen erfüllen:

  • Sie müssen den Traffic an den Zielport zulassen, der für die konfigurierte Systemdiagnose jedes Back-End-Dienstes erforderlich ist.

  • Instanzgruppen-Back-Ends müssen den Traffic an den Zielport zulassen, der mit der Portnummer übereinstimmt, die der benannte Port des Back-End-Dienstes abonniert.

  • GCE_VM_IP_PORT-NEG-Back-Ends müssen den Traffic zu den Ports der Endpunkte in den NEGs zulassen.

Firewallregeln werden auf VM-Instanzebene und nicht auf GFE-Proxys (Google Front End) implementiert. Sie können Google Cloud-Firewallregeln nicht verwenden, um zu verhindern, dass Traffic den Load-Balancer erreicht.

Weitere Informationen zu Systemdiagnosetests und dazu, warum Traffic von 130.211.0.0/22 und 35.191.0.0/16 zugelassen werden muss, finden Sie unter Prüfungs-IP-Bereiche und Firewallregeln.

Return-Path

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

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

Das externe HTTP(S)-Load-Balancing 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 der Traffic an das nächste GFE des Kunden 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 lautet die HTTP-Version HTTP 1.1. HTTP-Keepalive ist standardmäßig aktiviert, wie in der HTTP 1.1-Spezifikation angegeben. 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. Weitere Informationen finden Sie unter Zeitüberschreitungen und Wiederholungsversuche.

HTTP-Keepalives versuchen, dieselbe TCP-Sitzung effizient zu verwenden. Es gibt jedoch keine Garantie. Ein HTTP-Keepalive und ein TCP-Leerlaufzeitlimit sind zwar ähnlich, aber nicht identisch.

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

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 von HTTP(S)-Load-Balancing-Weiterleitungsregeln unterstützten Protokolle finden Sie unter Load-Balancer-Features.

Quell-IP-Adressen für Clientpakete

Die Quell-IP-Adressen für Pakete, die von jeder Instanz oder jedem Container des Back-Ends der virtuellen Maschine erkannt werden, sind Adressen aus folgenden Bereichen:

  • 35.191.0.0/16
  • 130.211.0.0/22

Die Quell-IP-Adresse für tatsächlichen Traffic mit Load-Balancing liegt innerhalb der Systemdiagnose-IP-Bereiche.

Die Quell-IP-Adressen für den Traffic, die von den Back-Ends erkannt werden, entsprechen nicht der externen Google Cloud-IP-Adresse des Load-Balancers. Mit anderen Worten: Es gibt zwei HTTP-, SSL- oder TCP-Sitzungen:

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

    • Quell-IP-Adresse: Der ursprüngliche Client (oder die externe IP-Adresse, wenn der Client hinter NAT liegt)
    • Ziel-IP-Adresse: IP-Adresse Ihres Load-Balancers
  • Sitzung 2 vom Load-Balancer (GFE) zur Back-End-VM oder zum Back-End-Container:

    • Quell-IP-Adresse: IP-Adresse aus einem der folgenden Bereiche: 35.191.0.0/16 oder 130.211.0.0/22

      Eine Vorhersage der tatsächlichen Quelladresse ist nicht möglich.

    • Ziel-IP-Adresse: Interne IP-Adresse der Back-End-VM oder des Containers im VPC-Netzwerk (Virtual Private Cloud)

Offene Ports

Externe HTTP(S)-Load-Balancer sind Reverse-Proxy-Load-Balancer. Der Load-Balancer beendet eingehende Verbindungen und öffnet dann neue Verbindungen vom Load-Balancer zu den Back-Ends. Diese Load-Balancer werden mit Google Front End-Proxys (GFE) weltweit implementiert.

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 externe HTTP(S)-Load-Balancer, die TCP-Port 443 verwenden, wird UDP-Port 443 verwendet, wenn die Verbindung auf QUIC aktualisiert wird (HTTP/3).

  • 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

Der HTTPS-Load-Balancer beendet TLS an global verteilten Orten, um die Latenz zwischen Clients und Load-Balancer zu minimieren. Wenn Sie steuern müssen, wo TLS geografisch beendet wird, sollten Sie stattdessen das Netzwerk-Load-Balancing von Google Cloud verwenden und TLS auf Back-Ends beenden, die sich in Regionen befinden, die für Ihren Bedarf geeignet sind.

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.

    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.

Beim Senden von WebSocket-Traffic über den Load-Balancer wird das Zeitlimit für den Back-End-Dienst als die maximale Zeit verstanden, die eine WebSocket-Verbindung geöffnet sein kann – im Leerlauf oder aktiv. Weitere Informationen finden Sie unter Einstellungen für Back-End-Dienste.

  • Eine TCP-Sitzungszeitüberschreitung, deren Wert unveränderlich bei 10 Minuten (600 Sekunden) liegt. Diese Sitzungszeitüberschreitung wird manchmal als Keepalive- oder Leerlaufzeitüberschreitung bezeichnet. Ihr Wert kann nicht über eine Änderung im Back-End-Dienst konfiguriert werden. 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;

Der Load-Balancer wiederholt fehlerhafte GET-Anfragen unter bestimmten Umständen, etwa wenn das Zeitlimit des Back-End-Diensts abgelaufen ist. Fehlerhafte POST-Anfragen werden nicht wiederholt. Es gibt maximal zwei Wiederholungsversuche. Bei wiederholten Anfragen wird nur ein Logeintrag für die endgültige Antwort generiert.

Ein GFE führt keinen erneuten Versuch aus, wenn mehr als 80 % der Back-End-Instanzen fehlerhaft 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. Weitere Informationen finden Sie unter Logging und Monitoring für das HTTP(S)-Load-Balancing.

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.

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.

Weitere Informationen zu den Balancing-Modi finden Sie unter Balancing-Modus.

Verhalten in verschiedenen Netzwerkdienststufen

Ob der Traffic regional oder global verteilt ist, hängt davon ab, welche Netzwerkdienststufe verwendet wird.

Premium-Stufe

Bei Nutzung der Premium-Stufe werden Anfragen an den externen HTTP(S)-Load-Balancer an Back-End-Instanzgruppen oder NEGs in der Region gesendet, die dem Nutzer am nächsten sind, sofern ein Back-End in dieser Region ausreichend Kapazität hat. (Die verfügbare Kapazität wird durch den Balancing-Modus des Load-Balancers konfiguriert.)

Sie können mehrere Back-End-Dienste in einer Region haben und Back-End-Dienste in mehreren Regionen erstellen, die alle von demselben globalen Load-Balancer bedient werden. So wird der Traffic auf die Back-End-Dienste verteilt:

  1. Wenn eine Anfrage von einem Nutzer eingeht, bestimmt der Load-Balancing-Dienst den ungefähren Ursprung der Anfrage anhand der Quell-IP-Adresse.
  2. Der Load-Balancing-Dienst berücksichtigt die Speicherorte der Instanzen, die zum Back-End-Dienst gehören, deren Gesamtkapazität und deren aktuelle Gesamtnutzung.
  3. Wenn die für den Nutzer nächstgelegenen Instanzen ausreichend Kapazität haben, wird die Anfrage an diese Instanzen weitergeleitet.
  4. Eingehende Anfragen an eine bestimmte Region werden gleichmäßig über alle verfügbaren Back-End-Dienste und Instanzen in dieser Region verteilt. Bei sehr kleinen Arbeitslasten kann sich die Verteilung als ungleichmäßig darstellen.
  5. Wenn keine fehlerfreien Instanzen mit verfügbaren Kapazitäten in einer bestimmten Region vorhanden sind, sendet der Load-Balancer die Anfrage stattdessen an die nächstgelegene Region mit verfügbarer Kapazität.

Standardstufe

Bei Nutzung der Standardstufe ist der externe HTTP(S)-Load-Balancer ein regionaler Dienst. Die Back-End-Instanzgruppen oder NEGs müssen sich alle in der Region befinden, die von der externen IP-Adresse und Weiterleitungsregel des Load-Balancers verwendet wird.

Regionen und Zonen

Nachdem der externe HTTP(S)-Load-Balancer eine Region ausgewählt hat, passiert Folgendes:

  • Wenn Sie Back-Ends in mehreren Zonen innerhalb der Region konfiguriert haben, versucht der externe HTTP(S)-Load-Balancer, Anfragen entsprechend der Back-End-Instanzkapazität undSitzungsaffinität möglichst gleichmäßig über die Zonen zu verteilen.

  • Innerhalb einer Zone versucht der externe HTTP(S)-Load-Balancer, Anfragen anhand des Load-Balancing-Algorithmus gleichmäßig zu verteilen. Dies ist abhängig von der verfügbaren Kapazität und der Sitzungsaffinität.

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.

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

  • NONE. Es ist keine Sitzungsaffinität für den Load-Balancer festgelegt.
  • Mit Client-IP-Affinität werden Anfragen von derselben Client-IP-Adresse an dasselbe Back-End gesendet.
  • Mit Cookie-Affinität wird bei der ersten Anfrage ein Client-Cookie festgelegt. Anschließend werden Anfragen mit diesem Cookie an dasselbe Back-End gesendet.

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.

Failover

Wenn ein Back-End fehlerhaft wird, wird der Traffic automatisch zu fehlerfreien Back-Ends in derselben Region weitergeleitet. Wenn alle Back-Ends innerhalb einer Region fehlerhaft sind, wird der Traffic an fehlerfreie Back-Ends in anderen Regionen verteilt (nur Premium-Stufe). Wenn alle Back-Ends fehlerhaft sind, gibt der Load-Balancer die Antwort HTTP 502 Bad Gateway zurück.

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.

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.

TLS-Support

Standardmäßig akzeptiert ein HTTPS-Zielproxy nur TLS 1.0, 1.1 , 1.2 und 1,3, wenn SSL-Requests von Clients beendet werden. Sie können dieses Standardverhalten mithilfe von SSL-Richtlinien ändern und steuern, wie der Load-Balancer SSL mit Clients aushandelt.

Wenn der externe HTTP(S)-Load-Balancer HTTPS als Back-End-Dienstprotokoll verwendet, kann er TLS 1.0, 1.1 oder 1.2 mit dem Back-End aushandeln.

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.

Beschränkungen

  • Die auf einem Clientzertifikat basierte Authentifizierung, auch als gegenseitige TLS-Authentifizierung bezeichnet, wird von HTTPS-Load-Balancern nicht unterstützt.
  • 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.

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

Cloud CDN-Einschränkung

  • Es ist nicht möglich, Identity-Aware Proxy und Cloud CDN für denselben Back-End-Dienst zu aktivieren. Wenn Sie dies versuchen, kann der Konfigurationsvorgang nicht ausgeführt werden.

Nächste Schritte