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

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.

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 benutzerdefinierter Quelle (zum Vergrößern klicken)
Load-Balancing-Diagramm mit benutzerdefinierter Quelle (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.

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 Front-Ends senden den HTTP(S)-Traffic an eine Gruppe regionaler interner HTTP(S)-Load-Balancer.
  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 basierendes Routing für interne Ebenen in einer mehrstufigen Anwendung (zum Vergrößern klicken)
Auf Layer 7 basiertes Routing für interne Ebenen in einer mehrstufigen Anwendung

Regionenübergreifendes Load-Balancing

Darstellung von regionenübergreifendem 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.


Inhaltsbasiertes Load-Balancing

Darstellung von inhaltsbasiertem Load-Balancing

HTTP(S)-Load-Balancing unterstützt inhaltsbasiertes Load-Balancing mithilfe von URL-Zuordnungen, um einen Back-End-Dienst anhand des angeforderten 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.


Kombinierten Load-Balancer erstellen

Darstellung von inhaltsbasiertem und regionenübergreifendem Load-Balancing

Sie können einen externen HTTP(S)-Load-Balancer in der Premium-Stufe konfigurieren, um sowohl inhaltsbasierten als auch regionenübergreifenden Load-Balancing bereitzustellen. Dabei werden mehrere Back-End-Dienste mit jeweils Back-End-Instanzgruppen oder NEGs in mehreren Regionen verwendet. Sie können die Anwendungsfälle kombinieren und erweitern, um einen externen HTTP(S)-Load-Balancer zu konfigurieren, der Ihren Anforderungen entspricht.


Konfigurationsbeispiel

Informationen zum direkten Einsteigen und Erstellen eines funktionierenden Load-Balancers für Testzwecke erhalten Sie unter Einfachen externen HTTP-Load-Balancer einrichten oder unter Einfachen externen HTTPS-Load-Balancer einrichten.

Ein komplexeres Beispiel für inhaltsbasiertes und regionenübergreifendes Load-Balancing finden Sie unter HTTPS-Load-Balancer erstellen.

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

Architektur und Ressourcen

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

HTTP(S)-Load-Balancing-Komponenten (zum Vergrößern klicken)
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 zu einer 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.

Quell-IP-Adressen

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)

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

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. Die Reverse-Proxy-Funktionalität wird von den Google-Front-Ends (GFEs) bereitgestellt.

Die festgelegten Firewallregeln blockieren den Traffic von den GFEs zu den Back-Ends, aber nicht den eingehenden Traffic zu den GFEs.

Die externen HTTP(S)-Load-Balancer haben eine Reihe von offenen Ports zur Unterstützung anderer Google-Dienste, die in derselben Architektur ausgeführt werden. Wenn Sie einen Sicherheits- oder Portscan für die externe IP-Adresse Ihres externen HTTP(S)-Load-Balancers in Google Cloud ausführen, scheint es, als wären weitere Ports offen.

Dies hat keine Auswirkungen auf externe HTTP(S)-Load-Balancer. Externe Weiterleitungsregeln, die in der Definition eines HTTP(S)-Load-Balancers verwendet werden, können nur auf die TCP-Ports 80, 8080 und 443 verweisen. Traffic mit einem anderen TCP-Zielport wird nicht an das Back-End des Load-Balancers weitergeleitet.

Komponenten

Externe HTTP(S)-Load-Balancer umfassen die folgenden Komponenten.

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.

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

Sie können benutzerdefinierte Anfrage- und Antwortheader erstellen, wenn die Standard-Header Ihren Anforderungen nicht entsprechen. Weitere Informationen zu dieser Funktion finden sich 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 an den X-Forwarded-For-Header an:

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

  • Die IP-Adresse 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. Wenn die Anfrage einen X-Forwarded-For-Header hat, werden andere Informationen wie die von Proxys auf dem Weg zum Load-Balancer aufgezeichneten IP-Adressen vor den beiden IP-Adressen gespeichert. Der Load-Balancer überprüft keine IP-Adressen, die vor den letzten beiden IP-Adressen in diesem Header liegen.

Wenn Sie auf Ihrer Back-End-Instanz einen Proxy ausführen, hängt dieser Proxy in der Regel weitere Informationen an den X-Forwarded-For-Header an und Ihre Software muss dies möglicherweise berücksichtigen. Die Proxy-Anfragen des Load-Balancers stammen von einer IP-Adresse im Bereich 130.211.0.0/22 oder 35.191.0.0/16. Ihr Proxy auf der Back-End-Instanz zeichnet diese Adresse und die eigene IP-Adresse der Back-End-Instanz möglicherweise auf.

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 regionenübergreifenden Load-Balancing kann es sein, dass Sie keine URL-Regeln definieren und sich nur auf den Standarddienst verlassen. Für eine inhaltsbasierte Weiterleitung von Traffic 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 schicken.

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

Beendigung von TLS geografisch steuern

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.

Back-End-Dienste

Back-End-Dienste stellen Konfigurationsinformationen für den Load-Balancer bereit. Ein externer HTTP(S)-Load-Balancer muss mindestens einen Back-End-Dienst und kann mehrere Back-End-Dienste haben.

Load-Balancer leiten den eingehenden Traffic anhand der Informationen in einem Back-End-Dienst an einen oder mehrere verknüpfte Back-Ends weiter.

Die Back-Ends eines Back-End-Dienstes können entweder Instanzgruppen oder Netzwerk-Endpunktgruppen (NEGs) sein, aber keine Kombination aus beidem. Wenn Sie eine Back-End-Instanzgruppe oder NEG hinzufügen, legen Sie einen Balancing-Modus fest, der eine Methode zum Verteilen von Anfragen und eine Zielkapazität definiert. Weitere Informationen finden Sie in der Dokumentation unter Lastenverteilungsalgorithmus.

HTTP(S)-Load-Balancing unterstützt Cloud Load Balancing-Autoscaling, mit dem Nutzer eine automatische Skalierung für die Instanzgruppen in einem Back-End ausführen können. Weitere Informationen finden Sie unter Basierend auf der HTTP(S)-Load-Balancing-Bereitstellungskapazität skalieren.

Sie können für Back-End-Dienste den Verbindungsausgleich aktivieren, um Dienstausfälle für Nutzer zu minimieren, wenn eine Instanz, die Traffic bereitstellt, beendet bzw. manuell oder durch Autoscaling entfernt wird. Weitere Informationen finden Sie unter Verbindungsausgleich aktivieren.

Änderungen an einem Back-End-Dienst, der mit einem externen HTTP(S)-Load-Balancer verknüpft ist, erfolgen nicht sofort. Es kann einige Minuten dauern, bis Änderungen im gesamten Netzwerk wirksam werden.

Verhalten des Load-Balancers in verschiedenen Netzwerkdienststufen

HTTP(S)-Load-Balancing ist ein globaler Dienst, wenn die Premium-Netzwerkdienststufe verwendet wird. Sie haben möglicherweise mehrere Back-End-Dienste in einer Region und können Back-End-Dienste in mehreren Regionen erstellen, für die alle der gleiche globale Load-Balancer genutzt wird. Der Traffic wird so 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.

HTTP(S)-Load-Balancing ist ein regionaler Dienst, wenn die Standard-Netzwerkdienststufe verwendet wird. 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.

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 Load-Balancer transformiert, um die Anfragen über HTTP/2 an die Back-End-Instanzen weiterzuleiten.

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.

Back-End-Buckets

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

Wie im folgenden Diagramm dargestellt, können Sie mit dem Load-Balancer Traffic über den Pfad /static an einen Storage-Bucket und alle anderen Anfragen an Ihre anderen Back-Ends senden.

Verteilung des Traffics auf verschiedene Back-End-Typen mit HTTP(S)-Load-Balancing (zum Vergrößern klicken)
Verteilung des Traffics auf verschiedene Back-End-Typen mit HTTP(S)-Load-Balancing (zum Vergrößern klicken)

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

Firewallregeln

Die Back-End-Instanzen müssen Verbindungen von den GFE- / Systemdiagnosebereichen des Load-Balancers zulassen. Dies bedeutet, dass Sie eine Firewallregel erstellen müssen, die Traffic von 130.211.0.0/22 und 35.191.0.0/16 zulässt, um Ihre Back-End-Instanzen oder Endpunkte zu erreichen. 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 Traffic zu Back-End-Instanzen oder -Endpunkten zulassen:

  • Sie müssen die von jeder Weiterleitungsregel verwendeten Ports zulassen.
  • Sie müssen die von jeder Systemdiagnose verwendeten Ports zulassen, die für jeden Back-End-Dienst konfiguriert sind.

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.

Rückgabepfad

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.

Lastenverteilungsalgorithmus

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.

Netzwerkdienststufen

Wenn ein externer HTTP(S)-Load-Balancer der Premium-Stufe zugeordnet ist, werden an den Load-Balancer gesendete Anfragen an Back-End-Instanzgruppen oder NEGs in der Region geliefert, die dem Nutzer am nächsten ist, wenn ein Back-End in dieser Region Kapazität hat. (Die verfügbare Kapazität wird durch den Balancing-Modus des Load-Balancers konfiguriert.)

Wenn ein externer HTTP(S)-Load-Balancer der Standardstufe zugeordnet ist, müssen sich alle seine Back-End-Instanzgruppen oder NEGs in der Region befinden, die von der externen IP-Adresse und Weiterleitungsregel des Load-Balancers verwendet wird.

Regionen und Zonen

Nach Auswahl einer Region:

  • Wenn Sie Back-Ends in mehreren Zonen innerhalb der Region konfigurieren, versucht ein externer HTTP(S)-Load-Balancer, Anfragen abhängig von der Back-End-Instanzkapazität und der Sitzungsaffinität so gleichmäßig wie möglich über die Zonen zu verteilen.

  • Innerhalb einer Zone versucht ein externer HTTP(S)-Load-Balancer, Anfragen je nach verfügbarer Kapazität und Sitzungsaffinität mithilfe des Load-Balancing-Algorithmus gleichmäßig zu verteilen.

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.

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. Weitere Informationen zum Zeitlimit des Back-End-Diensts und zu dessen Konfiguration finden Sie unter Zeitüberschreitungen und Wiederholungsversuche.

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

QUIC-Protokollunterstützung für HTTPS-Load-Balancing

HTTPS-Load-Balancing unterstützt das QUIC-Protokoll bei Verbindungen zwischen dem Load-Balancer und den Clients. 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. QUIC startet die Clientverbindung schneller, entfernt Blockierungen der Hauptleitung in Multiplexströmen und unterstützt die Verbindungsmigration, wenn sich die IP-Adresse eines Clients ändert.

QUIC wirkt sich auf Verbindungen zwischen Clients und dem Load-Balancer aus, nicht auf Verbindungen zwischen dem Load-Balancer und seinen Back-Ends.

Mit der QUIC-Überschreibeinstellung des Zielproxys können Sie eine der folgenden Optionen aktivieren:

  • Handeln Sie für einen Load-Balancer nach Möglichkeit QUIC aus.
  • QUIC für einen Load-Balancer immer deaktivieren

Wenn Sie keinen Wert für die QUIC-Überschreibeinstellung angeben, gestatten Sie Google bei Verwendung von QUIC die Verwaltung. Google aktiviert QUIC nur, wenn das Flag --quic-override im gcloud-Befehlszeilentool auf ENABLE oder das Flag quicOverride in der REST API auf ENABLE eingestellt ist.

Informationen zum Aktivieren und Deaktivieren der QUIC-Unterstützung finden Sie unter Zielproxys. So aktivieren oder deaktivieren Sie die QUIC-Unterstützung:

So wird QUIC ausgehandelt

Wenn Sie QUIC auswählen, kündigt der Load-Balancer seine QUIC-Funktionalität den Clients an. So können die Clients versuchen, QUIC-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. Aus diesem Grund beeinträchtigen die aktiven oder inaktiven QUIC-Einstellungen beim Load-Balancer nicht dessen Fähigkeit, eine Verbindung zu Clients herzustellen.

Wenn QUIC im HTTPS-Load-Balancer ausgewählt ist, kann der Client aus folgenden Gründen auf HTTPS oder HTTP/2 zurückgreifen, anstatt QUIC auszuhandeln:

  • Die QUIC-Version eines Client ist nicht kompatibel mit der QUIC-Version, die vom HTTPS-Load-Balancer unterstützt wird
  • Der Load-Balancer ermittelt blockierten UDP-Traffic oder einen beschränkten Tarif, sodass QUIC nicht funktioniert
  • QUIC ist vorübergehend für HTTPS-Load-Balancer deaktiviert, z. B. wegen Fehlern, Sicherheitslücken oder anderen Problemen

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

Falls die oben beschriebenen Verhaltensweisen für Ihre Arbeitslasten ungeeignet sind, sollten Sie QUIC nicht aktivieren.

SSL-Zertifikate

Sie müssen auf einem oder mehreren SSL-Zertifikaten auf dem Ziel-HTTPS-Proxy verweisen.

Mit den Zertifikaten sichert der SSL-Ziel-Proxy die Kommunikation zwischen einem Google-Front-End (GFE) und dem Client. Diese können selbstverwaltete oder von Google verwaltete SSL-Zertifikate sein.

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

Für die bestmögliche Sicherheit können Sie auch Traffic von GFEs zu Ihren Back-Ends verschlüsseln. Weitere Informationen finden Sie unter Verschlüsselung vom Load-Balancer zu Back-Ends.

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

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 Load-Balancer HTTPS als Back-End-Dienstprotokoll verwendet, kann er TLS 1.0, 1.1 oder 1.2 mit dem Back-End aushandeln.

Zeitüberschreitungen und Wiederholungsversuche

HTTP(S)-Load-Balancing umfasst zwei verschiedene Zeitüberschreitungstypen:
  • Ein konfigurierbares HTTP-Zeitlimit des Back-End-Diensts, das sich danach richtet, 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. 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

    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.

Weitere Informationen finden Sie unter Logging und Monitoring für 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.

Spezifikationen und Einschränkungen

  • HTTP(S)-Load-Balancing unterstützt die Antwort HTTP/1.1 100 Continue.

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 bietet keine Unterstützung für:
    • Server-Push
    • WebSockets
  • 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".

Einschränkung bei der Verwendung von Cloud CDN

  • Sie können Identity-Aware Proxy oder Cloud CDN nicht mit demselben Back-End-Dienst aktivieren. Wenn Sie dies versuchen, kann der Konfigurationsvorgang nicht ausgeführt werden.

Weitere Informationen