Présentation de l'équilibrage de charge HTTP(S) externe

Ce document présente les concepts que vous devez maîtriser pour configurer l'équilibrage de charge HTTP(S) externe de Google Cloud.

L'équilibrage de charge HTTP(S) est un équilibreur de charge mondial de couche 7 basé sur un proxy qui vous permet d'exécuter et de faire évoluer vos services à l'échelle mondiale derrière une seule adresse IP externe. L'équilibrage de charge HTTP(S) externe répartit le trafic HTTP et HTTPS entre les backends hébergés sur Compute Engine et Google Kubernetes Engine (GKE).

L'équilibrage de charge HTTP(S) externe est mis en œuvre sur les Google Front End (GFE). Les GFE sont distribués dans le monde entier et fonctionnent conjointement grâce au réseau mondial et au plan de contrôle de Google. Au Niveau Premium, les GFE offrent un équilibrage de charge multirégional, en dirigeant le trafic vers le backend opérationnel le plus proche à la capacité suffisante, et terminent le trafic HTTP(S) le plus près possible de vos utilisateurs. Avec le Niveau Standard, l'équilibrage de charge est géré au niveau régional.

Cette page décrit l'architecture d'un équilibreur de charge HTTP(S) externe autonome. Si vous souhaitez exposer vos applications sur GKE à Internet, nous vous recommandons d'utiliser l'API intégrée GKE Ingress pour l'équilibrage de charge HTTP(S) externe.

Architecture

Les ressources suivantes définissent un équilibreur de charge HTTP(S) externe :

  • Une règle de transfert externe spécifie une adresse IP externe, un port et un proxy HTTP(S) cible mondial. Les clients utilisent l'adresse IP et le port pour se connecter à l'équilibreur de charge.

  • Un proxy HTTP(S) cible reçoit une requête du client. Le proxy HTTP(S) évalue la requête à l'aide du mappage d'URL pour prendre des décisions d'acheminement du trafic. Le proxy peut également authentifier les communications avec des certificats SSL.

  • Pour l'équilibrage de charge HTTPS, le proxy HTTPS cible prouve son identité aux clients à l'aide de certificats SSL. Un proxy HTTPS cible accepte le nombre maximal indiqué de certificats SSL.

  • Le proxy HTTP(S) exploite un mappage d'URL pour déterminer le routage en fonction d'attributs HTTP (chemin de requête, cookies ou en-têtes, par exemple). En s'appuyant sur le routage choisi, le proxy transmet les requêtes des clients à des services de backend ou des buckets backend spécifiques. Le mappage d'URL peut spécifier des actions supplémentaires, telles que l'envoi de redirections à des clients.

  • Un service de backend ou un bucket backend répartit les requêtes entre les backends opérationnels.

  • Un ou plusieurs backends doivent être connectés au service de backend ou au bucket backend.

  • Une vérification d'état surveille régulièrement la disponibilité de vos backends. Cela réduit le risque que des requêtes soient envoyées à des backends ne pouvant pas les traiter.

  • Un pare-feu permettant aux backends d'accepter les vérifications d'état.

Règles de transfert et adresses

Les règles de transfert permettent d'acheminer le trafic par adresse IP, port et protocole vers une configuration d'équilibrage de charge comprenant un proxy cible et un ou plusieurs services de backend.

Chaque règle de transfert fournit une adresse IP unique que vous pouvez utiliser dans les enregistrements DNS relatifs à votre application. Aucun équilibrage de charge DNS n'est requis. Vous pouvez soit spécifier une adresse IP qui sera utilisée par le service, soit laisser Cloud Load Balancing en attribuer une.

  • La règle de transfert d'un équilibreur de charge HTTP ne peut faire référence qu'aux ports TCP 80 et 8080.
  • La règle de transfert d'un équilibreur de charge HTTPS ne peut faire référence qu'au port TCP 443.

Le type de règle de transfert et l'adresse IP requis par les équilibreurs de charge HTTP(S) externes dépendent du niveau de service réseau de l'équilibreur de charge.

Pour obtenir la liste complète des protocoles compatibles avec les règles de transfert de l'équilibrage de charge HTTP(S), consultez la page Fonctionnalités de l'équilibreur de charge.

Proxy cibles

Les proxys cibles interrompent les connexions HTTP(S) des clients. Une ou plusieurs règles de transfert dirigent le trafic vers le proxy cible, qui consulte le mappage d'URL pour déterminer comment acheminer le trafic vers les backends.

Ne vous attendez pas à ce que le proxy préserve la casse des noms dans les en-têtes de requête ou de réponse. Par exemple, un en-tête de réponse Server: Apache/1.0 peut se présenter sous la forme server: Apache/1.0 au niveau du client.

Types de proxys cibles En-têtes ajoutés par les proxys En-têtes personnalisés compatibles Compatibilité avec Cloud Trace
HTTP mondial,
HTTPS mondial
Les proxys définissent les en-têtes de requête et de réponse HTTP comme suit :
  • Via: 1.1 google (requêtes et réponses)
  • X-Forwarded-Proto: [http | https] (requêtes uniquement)
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (requêtes uniquement)
    Contient les paramètres de Cloud Trace.
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (voir l'en-tête X-Forwarded-For) (requêtes uniquement)

En-tête d'hôte

Lorsque l'équilibreur de charge effectue la requête HTTP, il conserve l'en-tête d'hôte de la requête d'origine.

En-tête "X-Forwarded-For"

L'équilibreur de charge ajoute deux adresses IP séparées par une seule virgule à l'en-tête X-Forwarded-For dans l'ordre suivant :

  • Adresse IP du client qui se connecte à l'équilibreur de charge
  • Adresse IP de la règle de transfert de l'équilibreur de charge

Si aucun en-tête X-Forwarded-For n'est présent dans la requête entrante, ces deux adresses IP correspondent à l'intégralité de la valeur d'en-tête :

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

Si la requête inclut un en-tête X-Forwarded-For, l'équilibreur de charge conserve la valeur fournie avant le <client-ip>,<load-balancer-ip> :

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

Lorsque vous exécutez un logiciel de proxy inverse HTTP sur les backends de l'équilibreur de charge, le logiciel peut ajouter l'une des adresses IP suivantes (ou les deux) à la fin de l'en-tête X-Forwarded-For :

  • L'adresse IP du service Google Front End (GFE) connecté au backend. Ces adresses IP se trouvent dans les plages 130.211.0.0/22 et 35.191.0.0/16.

  • L'adresse IP du système backend lui-même.

Ainsi, un processus en amont après le backend de votre équilibreur de charge peut recevoir un en-tête X-Forwarded-For au format :

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

Compatibilité avec les protocoles HTTP/3 et QUIC

HTTP/3 est un protocole Internet de nouvelle génération. Il repose sur QUIC, un protocole développé à partir du protocole Google QUIC d'origine (gQUIC). Le protocole HTTP/3 assure la compatibilité entre l'équilibreur de charge HTTP(S) externe, Cloud CDN et les clients.

à savoir :

  • Le protocole QUIC d'IETF est un protocole de couche de transport offrant un contrôle de congestion semblable à TCP et une sécurité équivalente à SSL/TLS pour HTTP/2, avec des performances améliorées.
  • HTTP/3 est une couche d'application construite sur le QUIC d'IETF et s'appuie sur QUIC pour gérer le multiplexage, le contrôle de congestion et les nouvelles tentatives.
  • Le protocole HTTP/3 permet d'initier les connexions client plus rapidement, élimine le blocage en tête de ligne dans les flux multiplexés et permet de migrer la connexion lorsque l'adresse IP d'un client change.
  • Le protocole HTTP/3 affecte les connexions entre les clients et l'équilibreur de charge, mais pas les connexions entre l'équilibreur de charge et ses backends.
  • Les connexions HTTP/3 utilisent le protocole de contrôle de congestion BBR.

L'activation du protocole HTTP/3 sur votre équilibreur de charge HTTP(S) externe peut améliorer le temps de chargement des pages Web, réduire les nouvelles mises en mémoire tampon de vidéos et améliorer le débit sur les connexions à latence plus élevée.

Configurer le protocole HTTP/3

Vous pouvez explicitement activer la compatibilité HTTP/3 pour votre équilibreur de charge HTTP(S) externe en définissant quicOverride sur ENABLE. À l'avenir, HTTP/3 sera activé par défaut pour tous les clients d'équilibrage de charge HTTP(S) externe.

Les clients qui ne sont pas compatibles avec HTTP/3 ou gQUIC ne négocient pas de connexion HTTP/3. Vous n'avez pas besoin de désactiver explicitement HTTP/3, sauf si vous avez identifié des mises en œuvre clientes interrompues ou plus anciennes.

L'équilibreur de charge HTTP(S) externe propose trois modes de configuration du protocole HTTP/3, comme indiqué dans le tableau suivant.

Valeur quicOverride Comportement
NONE

Les protocoles HTTP/3 et Google QUIC ne sont pas annoncés aux clients.

Remarque : Cela est susceptible de changer à l'avenir, et le protocole HTTP/3 sera annoncé par défaut aux clients.

ENABLE

La compatibilité avec HTTP/3 et Google QUIC est annoncée aux clients. Le protocole HTTP/3 est annoncé avec une priorité plus élevée. Les clients compatibles avec les deux protocoles doivent préférer HTTP/3 à Google QUIC.

Remarque : TLS 0-RTT (également appelé données anticipées TLS) est implicitement compatible lorsque Google QUIC est négocié par le client, mais il n'est actuellement pas compatible lorsque le protocole HTTP/3 est utilisé.

DISABLE Désactive explicitement la diffusion des annonces concernant les protocoles HTTP/3 et QUIC aux clients.

Pour activer (ou désactiver) explicitement HTTP/3, procédez comme suit.

Console : HTTPS

  1. Dans Google Cloud Console, accédez à la page Équilibrage de charge.

    Accéder à la page "Équilibrage de charge"

  2. Sélectionnez l'équilibreur de charge HTTP(S) externe que vous souhaitez modifier.

  3. Cliquez sur Frontend configuration (Configuration du frontend).

  4. Sélectionnez l'adresse IP et le port de l'interface que vous souhaitez modifier. Pour modifier les configurations HTTP/3, l'adresse IP et le port doivent être définis sur HTTPS (port 443).

Activer le protocole HTTP/3

  1. Sélectionnez la liste déroulante Négociation QUIC.
  2. Pour activer explicitement HTTP/3 pour cette interface, sélectionnez Activé.
  3. Si vous disposez de plusieurs règles d'interface représentant IPv4 et IPv6, assurez-vous d'activer HTTP/3 sur chaque règle.

Désactiver le protocole HTTP/3

  1. Sélectionnez la liste déroulante Négociation QUIC.
  2. Pour désactiver explicitement HTTP/3 pour cette interface, sélectionnez Désactivé.
  3. Si vous disposez de plusieurs règles d'interface représentant IPv4 et IPv6, assurez-vous de désactiver HTTP/3 pour chaque règle.

gcloud : HTTPS

Avant d'exécuter cette commande, vous devez créer une ressource de certificat SSL pour chaque certificat.

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

Remplacez QUIC_SETTING par l'un des éléments suivants :

  • NONE (par défaut) : permet à Google de contrôler la date de négociation QUIC.

    Actuellement, lorsque vous sélectionnez NONE, QUIC est désactivé. En sélectionnant cette option, vous autorisez Google à activer automatiquement les négociations QUIC et HTTP/3 à l'avenir pour cet équilibreur de charge. Dans Cloud Console, cette option est appelée Automatique (par défaut).

  • ENABLE : annonce les protocoles HTTP/3 et QUIC aux clients.

  • DISABLE : n'annonce pas les protocoles HTTP/3 ou QUIC aux clients.

API : HTTPS

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

{
  "quicOverride": QUIC_SETTING
}

Remplacez QUIC_SETTING par l'un des éléments suivants :

  • NONE (par défaut) : permet à Google de contrôler la date de négociation QUIC.

    Actuellement, lorsque vous sélectionnez NONE, QUIC est désactivé. En sélectionnant cette option, vous autorisez Google à activer automatiquement les négociations QUIC et HTTP/3 à l'avenir pour cet équilibreur de charge. Dans Cloud Console, cette option est appelée Automatique (par défaut).

  • ENABLE : annonce les protocoles HTTP/3 et QUIC aux clients.

  • DISABLE : n'annonce pas les protocoles HTTP/3 ou QUIC aux clients.

Négociation du protocole HTTP/3

Lorsque le protocole HTTP/3 est activé, l'équilibreur de charge annonce cette compatibilité aux clients, ce qui permet aux clients compatibles avec HTTP/3 d'établir des connexions HTTP/3 avec l'équilibreur de charge HTTPS.

  • Les clients correctement mis en œuvre peuvent toujours revenir au protocole HTTPS ou HTTP/2 lorsqu'ils ne parviennent pas à établir une connexion QUIC.
  • Les clients compatibles avec HTTP/3 utilisent leurs connaissances antérieures mises en cache de la compatibilité HTTP/3 pour éviter les allers-retours inutiles.
  • Du fait de ce mécanisme, activer ou désactiver QUIC dans l'équilibreur de charge n'affecte pas sa capacité à se connecter aux clients.

La compatibilité est annoncée dans l'en-tête de réponse HTTP Alt-Svc. Lorsque HTTP/3 est configuré en tant que ENABLE sur la ressource targetHttpsProxy d'un équilibreur de charge HTTP(S) externe, les réponses de l'équilibreur de charge HTTP(S) externe incluent la valeur d'en-tête alt-svc suivante :

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"

Si le protocole HTTP/3 a été explicitement défini sur DISABLE, les réponses n'incluent pas d'en-tête de réponse alt-svc.

Lorsque QUIC est activé sur votre équilibreur de charge HTTPS, certaines circonstances peuvent amener le client à revenir au protocole HTTPS ou HTTP/2 au lieu de négocier le protocole QUIC. En voici quelques exemples :

  • Lorsqu'un client est compatible avec des versions du protocole HTTP/3 qui ne sont pas acceptées par l'équilibreur de charge HTTPS.
  • Lorsque l'équilibreur de charge détecte que le trafic UDP est bloqué ou soumis à une limitation de débit, d'une manière qui empêcherait le bon fonctionnement du protocole HTTP/3 (QUIC).
  • Le client n'est pas du tout compatible avec le protocole HTTP/3 et ne tente donc pas de négocier une connexion HTTP/3.

Lorsqu'une connexion se rabat sur HTTPS ou HTTP/2 dans ces cas de figure, nous ne comptabilisons pas ce problème comme une défaillance de l'équilibreur de charge.

Avant d'activer le protocole HTTP/3, assurez-vous que les comportements décrits ci-dessus sont acceptables pour vos charges de travail.

Mappages d'URL

Les mappages d'URL définissent des correspondances de motifs pour l'acheminement de requêtes vers les services de backend adéquats en fonction de l'URL de la requête. Un service par défaut est défini pour gérer toute requête qui ne correspond pas à une règle d'hôte ou à une règle de correspondance de chemin donnée. Dans certains cas, comme celui décrit dans l'exemple d'équilibrage de charge multirégional, vous pouvez choisir de ne définir aucune règle d'URL et de vous appuyer seulement sur le service par défaut. Pour le routage des requêtes, le mappage d'URL vous permet de répartir votre trafic en examinant les composants d'URL pour envoyer des requêtes à différents ensembles de backends.

Certificats SSL

Transport Layer Security (TLS) est un protocole de chiffrement utilisé dans les certificats SSL pour protéger les communications réseau.

Google Cloud utilise des certificats SSL pour assurer la confidentialité et la sécurité entre un client et un équilibreur de charge. Si vous utilisez l'équilibrage de charge HTTPS, vous devez installer un ou plusieurs certificats SSL sur le proxy HTTPS cible.

Pour en savoir plus sur les certificats SSL, consultez les articles suivants :

Règles SSL

Les règles SSL vous permettent de contrôler les fonctionnalités SSL que votre équilibreur de charge HTTPS négocie avec les clients HTTPS.

Par défaut, l'équilibrage de charge HTTPS utilise un ensemble de fonctionnalités SSL offrant une bonne sécurité et une compatibilité étendue. Certaines applications requièrent davantage de contrôle sur les versions SSL et les algorithmes de chiffrement utilisés pour les connexions HTTPS ou SSL. Vous pouvez définir des règles SSL contrôlant les fonctionnalités SSL que votre équilibreur de charge négocie et associer une règle SSL à votre proxy HTTPS cible.

Services de backend et buckets

Un équilibreur de charge HTTP(S) externe peut disposer de services de backend et de buckets backend.

Les services de backend fournissent des informations de configuration à l'équilibreur de charge. Les équilibreurs de charge utilisent les informations d'un service de backend pour rediriger le trafic entrant vers un ou plusieurs backends associés. Pour obtenir un exemple de configuration d'un équilibreur de charge avec un service de backend et un backend Compute Engine, consultez la pageConfigurer un équilibreur de charge HTTP(S) externe avec un backend Compute Engine.

Les buckets backend dirigent le trafic entrant vers des buckets Cloud Storage. Pour obtenir un exemple d'ajout d'un bucket à un équilibreur de charge, consultez la page Configurer un équilibreur de charge avec des buckets backend.

Si vous souhaitez configurer un équilibreur de charge HTTP(S) externe en utilisant HTTP/2 avec un objet Ingress Google Kubernetes Engine, ou en associant gRPC et HTTP/2 avec un objet Ingress, consultez la page HTTP/2 pour l'équilibrage de charge avec l'objet Ingress.

Le tableau suivant spécifie les fonctionnalités de backend compatibles avec l'équilibrage de charge HTTP(S).

Backends compatibles sur un service de backend Compatible avec les buckets backend Compatible avec Google Cloud Armor Compatible avec Cloud CDN Compatible avec IAP
Groupes d'instances NEG zonaux NEG Internet NEG sans serveur

en cas d'utilisation du niveau Premium

Pour en savoir plus, consultez les ressources suivantes :

Vérifications d'état

Chaque service de backend spécifie une vérification d'état à effectuer sur les instances backend.

Pour les vérifications d'état, vous devez créer une règle de pare-feu autorisant le trafic à accéder à vos instances. La règle de pare-feu doit autoriser les plages sources suivantes :

  • 130.211.0.0/22
  • 35.191.0.0/16

Les équilibreurs de charge HTTP(S) externes utilisent des vérifications d'état globales.

Pour en savoir plus sur les vérifications d'état, consultez les pages suivantes :

Protocole de communication avec les backends

Lorsque vous configurez un service de backend pour l'équilibreur de charge HTTP(S) externe, vous définissez le protocole utilisé par le service de backend pour communiquer avec les backends. Vous pouvez choisir parmi HTTP, HTTPS ou HTTP/2. L'équilibreur de charge utilise uniquement le protocole que vous spécifiez. S'il ne parvient pas à négocier une connexion au backend avec le protocole spécifié, l'équilibreur de charge ne recourt pas à l'un des autres protocoles.

Si vous choisissez HTTP/2, vous devez utiliser TLS. Le protocole HTTP/2 sans chiffrement n'est pas accepté.

Bien que ce ne soit pas obligatoire, il est recommandé d'utiliser une vérification d'état dont le protocole correspond à celui du service de backend. Par exemple, une vérification d'état HTTP/2 permet de tester plus précisément la connectivité HTTP/2 aux backends.

Utiliser gRPC avec vos applications Google Cloud

gRPC est un framework Open Source pour les appels de procédure à distance. Il est basé sur le standard HTTP/2. Voici quelques exemples d'utilisation de gRPC :

  • Systèmes distribués à faible latence et hautement évolutifs
  • Développement de clients mobiles communiquant avec un serveur cloud
  • Conception de nouveaux protocoles devant être précis, efficaces et indépendants du langage
  • Conception à plusieurs couches pour permettre l'extension, l'authentification et la journalisation

Pour utiliser gRPC avec vos applications Google Cloud, vous devez relayer les requêtes par proxy de bout en bout via HTTP/2. Pour y parvenir avec un équilibreur de charge HTTP(S) externe, procédez comme suit :

  1. Configurez un équilibreur de charge HTTPS.
  2. Activez HTTP/2 comme protocole à utiliser entre l'équilibreur de charge et les backends.

L'équilibreur de charge négocie le protocole HTTP/2 avec les clients dans le cadre du handshake SSL à l'aide de l'extension TLS ALPN.

L'équilibreur de charge peut toujours négocier le protocole HTTPS avec certains clients ou accepter des requêtes HTTP non sécurisées sur un équilibreur de charge HTTP(S) externe configuré pour utiliser HTTP/2 entre l'équilibreur de charge et les instances backend. Ces requêtes HTTP ou HTTPS sont transformées par l'équilibreur de charge pour relayer les requêtes par proxy via HTTP/2 vers les instances backend.

Vous devez activer le protocole TLS sur vos backends. Pour en savoir plus, consultez la section Chiffrement entre l'équilibreur de charge et les backends.

Si vous souhaitez configurer un équilibreur de charge HTTP(S) externe en utilisant HTTP/2 avec un objet Ingress Google Kubernetes Engine, ou en associant gRPC et HTTP/2 avec un objet Ingress, consultez la page HTTP/2 pour l'équilibrage de charge avec l'objet Ingress.

Pour en savoir plus sur la résolution des problèmes liés à HTTP/2, consultez la section Résoudre les problèmes liés à l'utilisation de HTTP/2 avec les backends.

Pour plus d'informations sur les limites du protocole HTTP/2, consultez la section Limites liées à HTTP/2.

Règles de pare-feu

Les instances backend doivent autoriser les connexions à partir des sources suivantes :

  • Équilibreur de charge Google Front End (GFE) pour toutes les requêtes envoyées aux backends
  • Vérifications d'état

Pour autoriser ce trafic, vous devez créer des règles de pare-feu d'entrée. Les ports de ces règles de pare-feu doivent autoriser le trafic comme suit :

  • Vers le port de destination pour la vérification d'état de chaque service de backend

  • Pour les backends de groupes d'instances : déterminé par le mappage entre le port nommé du service de backend et les numéros de port associés à ce port nommé sur chaque groupe d'instances. Les numéros peuvent varier entre les groupes d'instances attribués au même service de backend.

  • Pour les backends de NEG GCE_VM_IP_PORT : vers les numéros de port des points de terminaison

Les règles de pare-feu sont mises en œuvre au niveau de l'instance de VM, et non sur les proxys GFE. Vous ne pouvez pas utiliser les règles de pare-feu Google Cloud pour empêcher le trafic d'atteindre l'équilibreur de charge. Pour y parvenir, vous pouvez utiliser Google Cloud Armor.

Pour en savoir plus sur les vérifications d'état et découvrir pourquoi il est nécessaire d'autoriser le trafic en provenance des plages d'adresses de vérification, consultez la section Plages d'adresses IP de vérification et règles de pare-feu.

Pour les équilibreurs de charge HTTP(S) externes, le tableau suivant spécifie les plages sources de vérification d'état et des requêtes :

Plages sources de vérification d'état Plages sources des requêtes GFE
  • 130.211.0.0/22
  • 35.191.0.0/16
La source du trafic GFE dépend du type de backend :
  • Groupes d'instances, NEG zonaux (GCE_VM_IP_PORT) et NEG de connectivité hybride (NON_GCP_PRIVATE_IP_PORT) :
    • 130.211.0.0/22
    • 35.191.0.0/16
  • NEG Internet (INTERNET_FQDN_PORT et INTERNET_IP_PORT) :
    • 34.96.0.0/20
    • 34.127.192.0/18
  • NEG SERVERLESS et buckets de backend : le réseau de production de Google gère le routage des paquets.

Adresses IP sources des paquets client

Les adresses IP sources des paquets, telles qu'elles sont perçues par les backends, ne correspondent pas à l'adresse IP externe Google Cloud de l'équilibreur de charge. En d'autres termes, il existe deux connexions TCP :

  • Connexion 1, du client d'origine vers l'équilibreur de charge (GFE) :

    • Adresse IP source : le client d'origine (ou l'adresse IP externe si le client est protégé par la fonctionnalité NAT ou un proxy de transfert).
    • Adresse IP de destination : l'adresse IP de votre équilibreur de charge.
  • Connexion 2, de l'équilibreur de charge (GFE) vers la VM de backend ou le point de terminaison :

    • Adresse IP source : adresse IP située dans l'une des plages spécifiées dans les règles de pare-feu.

    • Adresse IP de destination : une adresse IP interne de la VM de backend ou du conteneur dans le réseau cloud privé virtuel (VPC).

Chemin de retour

Pour les vérifications d'état, Google Cloud utilise des routages spéciaux non définis dans votre réseau VPC. Pour en savoir plus, consultez la section Chemins de retour pour les équilibreurs de charge.

Fonctionnement des connexions dans l'équilibrage de charge HTTP(S)

L'équilibrage de charge HTTP(S) externe est un service mis en œuvre par de nombreux proxys appelés GFE (Google Front End). Il n'y a pas qu'un seul proxy. Au niveau Premium, la même adresse IP externe globale est annoncée à partir de divers points de présence et le trafic est dirigé vers le GFE le plus proche du client.

Selon l'emplacement de vos clients, plusieurs GFE peuvent initier des connexions HTTP(S) à vos backends. Les paquets envoyés à partir des GFE ont des adresses IP sources de la même plage que celle utilisée par les vérificateurs d'état : 35.191.0.0/16 et 130.211.0.0/22.

Selon la configuration du service de backend, le protocole utilisé par chaque GFE pour se connecter aux backends peut être HTTP, HTTPS ou HTTP/2. Dans le cas de HTTP ou HTTPS, la version HTTP est HTTP 1.1. Le message HTTP keepalive est activé par défaut, comme indiqué dans la spécification HTTP 1.1. Le GFE utilise un délai avant expiration de 600 secondes pour le message keepalive, et vous ne pouvez pas le configurer. Vous pouvez toutefois configurer le délai avant expiration de la requête/réponse en définissant le délai avant expiration du service de backend. Pour en savoir plus, consultez la section Délais d'expiration et nouvelles tentatives.

Les messages keepalive HTTP tentent d'utiliser efficacement la même session TCP. mais il n'y a aucune garantie. Bien qu'ils soient étroitement liés, un message keepalive HTTP et un délai d'inactivité TCP ne sont pas identiques.

Le nombre de connexions HTTP et de sessions TCP varie en fonction du nombre de GFE connectés, du nombre de clients se connectant aux GFE, du protocole de communication avec les backends et de l'emplacement des backends.

Pour en savoir plus, consultez la section Fonctionnement de l'équilibrage de charge HTTP(S) du guide "Optimiser la capacité des applications avec l'équilibrage de charge global".

Communication entre les clients et l'équilibreur de charge

  • Les clients peuvent communiquer avec l'équilibreur de charge via le protocole HTTP 1.1 ou HTTP/2.
  • Lorsque HTTPS est utilisé, les clients modernes utilisent par défaut HTTP/2. Ce fonctionnement est contrôlé au niveau du client et non au niveau de l'équilibreur de charge HTTPS.
  • Vous ne pouvez pas désactiver HTTP/2 en modifiant la configuration sur l'équilibreur de charge. Toutefois, vous pouvez configurer certains clients pour qu'ils utilisent HTTP 1.1 au lieu de HTTP/2. Par exemple, avec curl, définissez le paramètre --http1.1.
  • L'équilibrage de charge HTTP(S) accepte la réponse HTTP/1.1 100 Continue.

Pour obtenir la liste complète des protocoles compatibles avec les règles de transfert de l'équilibrage de charge HTTP(S), consultez la page Fonctionnalités de l'équilibreur de charge.

Ports ouverts

Les équilibreurs de charge HTTP(S) externes sont des équilibreurs de charge de type proxy inverse. L'équilibreur de charge interrompt les connexions entrantes, puis ouvre de nouvelles connexions entre lui-même et les backends. Ces équilibreurs de charge sont mis en œuvre à l'aide de proxys Google Front End (GFE) dans le monde entier.

Les GFE offrent plusieurs ports ouverts pour les autres services Google exécutés sur la même architecture. Pour afficher la liste de certains ports susceptibles d'être ouverts sur des GFE, consultez la section Règle de transfert : spécifications de port. Il peut y avoir d'autres ports ouverts pour d'autres services Google s'exécutant sur des GFE.

L'exécution d'une analyse de port sur l'adresse IP d'un équilibreur de charge basé sur GFE n'est pas utile du point de vue de l'audit pour les raisons suivantes :

  • Une analyse de port (par exemple, avec nmap) n'attend généralement pas de paquet de réponse ni de paquet TCP RST lors de l'exécution de la vérification TCP SYN. Les GFE envoient des paquets SYN-ACK en réponse aux vérifications SYN pour divers ports si votre équilibreur de charge utilise une adresse IP de niveau Premium. Cependant, les GFE n'envoient des paquets à vos backends qu'en réponse aux paquets envoyés à l'adresse IP de votre équilibreur de charge et au port de destination configuré sur sa règle de transfert. Les paquets envoyés à différentes adresses IP d'équilibreur de charge ou à l'adresse IP de votre équilibreur de charge sur un port non configuré dans votre règle de transfert n'entraînent pas l'envoi de paquets aux backends de votre équilibreur de charge. Les GFE mettent en œuvre des fonctionnalités de sécurité telles que Google Cloud Armor. Même sans configuration Google Cloud Armor, l'infrastructure Google et les GFE offrent une défense en profondeur contre les attaques DDoS et inondations SYN.

  • Les paquets envoyés à l'adresse IP de votre équilibreur de charge peuvent recevoir une réponse de n'importe quel GFE du parc de Google. Cependant, l'analyse d'une combinaison d'adresse IP et de port de destination d'un équilibreur de charge n'interroge qu'un seul GFE par connexion TCP. L'adresse IP de votre équilibreur de charge n'est pas attribuée à un seul appareil ou système. Ainsi, l'analyse de l'adresse IP d'un équilibreur de charge basé sur un GFE n'analyse pas tous les GFE du parc de Google.

En gardant cela à l'esprit, voici quelques moyens plus efficaces d'auditer la sécurité de vos instances backend :

  • Un auditeur de sécurité doit inspecter la configuration des règles de transfert pour la configuration de l'équilibreur de charge. Les règles de transfert définissent le port de destination pour lequel votre équilibreur de charge accepte les paquets et les transfère aux backends. Pour les équilibreurs de charge basés sur GFE, chaque règle de transfert externe ne peut référencer qu'un seul port TCP de destination. Pour les équilibreurs de charge HTTP(S) externes utilisant le port TCP 443, le port UDP 443 est utilisé lorsque la connexion est mise à niveau vers QUIC (HTTP/3).

  • Un auditeur de sécurité doit inspecter la configuration des règles de pare-feu applicable aux VM de backend. Les règles de pare-feu que vous définissez bloquent le trafic entre les GFE et les VM de backends, mais elles ne bloquent pas le trafic entrant vers les GFE. Pour connaître les bonnes pratiques, consultez la section Règles de pare-feu.

terminaison TLS

L'équilibreur de charge HTTPS interrompt le protocole TLS dans les emplacements distribués à l'échelle mondiale, de manière à réduire la latence entre les clients et l'équilibreur de charge. Si vous avez besoin d'exercer un contrôle géographique sur ces emplacements, vous devez plutôt faire appel à l'équilibrage de charge au niveau du réseau de Google Cloud, et interrompre le protocole TLS sur les backends situés dans les régions correspondant à vos besoins.

Délais d'expiration et nouvelles tentatives

L'équilibrage de charge HTTP(S) présente deux types de délais d'expiration distincts :

  • Un délai avant expiration HTTP du service de backend configurable, qui représente la durée pendant laquelle l'équilibreur de charge attend une réponse HTTP complète de la part de votre backend. La valeur par défaut du délai avant expiration du service de backend est de 30 secondes. La plage complète des valeurs de délai avant expiration autorisées est de 1 à 2 147 483 647 secondes.

    Vous pouvez envisager d'augmenter ce délai dans les cas suivants :

    • si vous pensez qu'un backend va mettre plus de temps à renvoyer des réponses HTTP ;
    • si une réponse HTTP 408 de type jsonPayload.statusDetailclient_timed_out s'affiche ;
    • si la connexion est mise à niveau vers une connexion WebSocket.

Par exemple, la valeur d'un délai avant expiration pratique pour les équilibreurs de charge HTTP(S) externes est de 1 jour (86 400 secondes). Notez que des événements tels que les redémarrages de GFE peuvent entraîner l'arrêt des sessions plus tôt que ce délai.

Lorsque vous envoyez le trafic WebSocket via l'équilibreur de charge, le délai avant expiration du service de backend est interprété comme la durée maximale pendant laquelle une connexion WebSocket peut rester ouverte, qu'elle soit active ou inactive. Pour en savoir plus, consultez la section Paramètres du service de backend.

  • Un délai d'expiration de la session TCP, dont la valeur est fixée à 10 minutes (600 secondes). Ce délai d'expiration de session est parfois appelé "keepalive" ou délai d'inactivité, et sa valeur ne peut pas être configurée par modification de votre service de backend. Pour empêcher la fermeture prématurée des connexions par le backend, vous devez configurer le logiciel de serveur Web utilisé par vos backends afin que son délai d'expiration "keepalive" soit supérieur à 600 secondes. Ce délai avant expiration ne s'applique pas aux connexions WebSocket.

Le tableau suivant présente les modifications à effectuer pour modifier les délais d'expiration "keepalive" des logiciels de serveur Web courants :

Logiciel de serveur Web Paramètre Réglage par défaut Réglage recommandé
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

Certaines circonstances d'échec de requêtes GET conduisent l'équilibreur de charge à effectuer de nouvelles tentatives, par exemple lorsque le délai avant expiration du service de backend est écoulé. L'équilibreur ne tente pas de relancer les requêtes POST ayant échoué. La limite est de deux nouvelles tentatives. Les requêtes faisant l'objet d'une nouvelle tentative ne génèrent qu'une seule entrée de journal associée à la réponse finale.

Un GFE n'effectue pas de nouvelle tentative si plus de 80 % des instances backend ne sont pas opérationnelles. Si un groupe ne comprend qu'une seule instance backend et que la connexion à celle-ci échoue, le pourcentage d'instances backend non opérationnelles est de 100 %. Le GFE ne tente donc pas de relancer la requête. Pour en savoir plus, consultez la page Journalisation et surveillance de l'équilibrage de charge HTTP(S).

Le protocole WebSocket est compatible avec les objets Ingress.

Traitement des requêtes et réponses illégales

Il existe différentes raisons pour lesquelles l'équilibreur de charge HTTP(S) externe peut être amené à empêcher des requêtes client ou des réponses du backend d'atteindre, respectivement, le backend ou le client. Certaines raisons sont strictement liées à la conformité avec le protocole HTTP/1.1. D'autres visent à éviter de transmettre des données inattendues en provenance ou à destination des backends. Aucune vérification ne peut être désactivée.

L'équilibreur de charge bloque les requêtes dans les cas de figure suivants pour assurer la conformité avec le protocole HTTP/1.1 :

  • Il ne peut pas analyser la première ligne de la requête.
  • Le délimiteur : manque dans un en-tête.
  • Les en-têtes ou la première ligne contiennent des caractères non valides.
  • La longueur du contenu n'est pas un nombre valide, ou il existe plusieurs en-têtes de longueur de contenu.
  • Il existe plusieurs clés de codage de transfert ou des valeurs de codage de transfert non reconnues.
  • La requête présente un corps non découpé en blocs et aucune longueur de contenu n'est spécifiée.
  • Les blocs de corps ne peuvent pas être analysés. C'est le seul cas de figure où certaines données parviennent au backend. L'équilibreur de charge ferme les connexions au client et au backend lorsqu'il reçoit un bloc impossible à analyser.

L'équilibreur de charge bloque la requête si l'une des conditions suivantes est remplie :

L'équilibreur de charge bloque la réponse du backend si l'une des conditions suivantes est remplie :

  • La taille totale des en-têtes de réponse dépasse la taille d'en-tête de réponse maximale autorisée pour l'équilibrage de charge HTTP(S) externe.
  • La version de HTTP est inconnue.

Distribution du trafic

Lorsque vous ajoutez un groupe d'instances backend ou un NEG à un service de backend, vous spécifiez un mode d'équilibrage, qui définit une méthode mesurant la charge du backend et une capacité cible. L'équilibrage de charge HTTP(S) externe accepte deux modes d'équilibrage :

  • RATE, pour les groupes d'instances ou les NEG, est le nombre cible maximal de requêtes par seconde (RPS). La valeur RPS cible maximale peut être dépassée si tous les backends ont une capacité égale ou supérieure.

  • UTILIZATION est l'utilisation du backend des VM dans un groupe d'instances.

Avant qu'un serveur GFE (Google Front End) envoie des requêtes aux instances backend, le GFE estime quelles instances backend peuvent recevoir des requêtes. Cette estimation de la capacité est effectuée de manière proactive, et non au moment où les requêtes arrivent. Les GFE reçoivent régulièrement des informations sur la capacité disponible et distribuent les requêtes entrantes en conséquence.

La capacité dépend en partie du mode d'équilibrage. Pour le mode RATE, c'est relativement simple : un GFE détermine exactement le nombre de requêtes qu'il peut attribuer par seconde. L'équilibrage de charge basé sur UTILIZATION est plus complexe : l'équilibreur de charge vérifie l'utilisation actuelle des instances, puis estime une charge de requête que chaque instance peut gérer. Cette estimation évolue au fil du temps lorsque l'utilisation des instances et les modèles de trafic changent.

Ces deux facteurs (l'estimation de la capacité et l'attribution proactive) influencent la répartition entre les instances. Ainsi, Cloud Load Balancing se comporte différemment d'un simple équilibreur de charge round robin (à tour de rôle) qui répartit exactement les requêtes à 50/50 entre deux instances. Au lieu de cela, l'équilibrage de charge Google Cloud tente d'optimiser la sélection de l'instance backend pour chaque requête.

Pour en savoir plus, consultez la section Distribution du trafic.

Pour en savoir plus sur les modes d'équilibrage, consultez la section Mode d'équilibrage.

Distribution des requêtes

Le trafic est distribué au niveau régional ou mondial en fonction du niveau de service réseau utilisé.

Pour le niveau Premium :

  • Google annonce l'adresse IP de votre équilibreur de charge à partir de tous les points de présence dans le monde. Toutes les adresses IP de l'équilibreur de charge sont Anycast globales.
  • Si vous configurez un service de backend avec des backends dans plusieurs régions, les GFE (Google Front End) tentent de diriger les requêtes vers des groupes d'instances backend ou des NEG opérationnels dans la région la plus proche de l'utilisateur. Vous trouverez des détails sur le processus sur cette page.

Pour le niveau Standard :

  • Google annonce l'adresse IP de votre équilibreur de charge à partir des points de présence associés à la région de la règle de transfert. L'équilibreur de charge utilise une adresse IP externe régionale.

  • Vous pouvez configurer des backends dans la même région que la règle de transfert. Le processus documenté ici s'applique toujours, mais les GFE ne dirigent les requêtes que vers les backends opérationnels dans cette région.

Processus de distribution des requêtes :

Le mode d'équilibrage et le choix de la cible définissent l'utilisation maximale du backend du point de vue de chaque NEG GCE_VM_IP_PORT zonal, groupe d'instance zonal ou zone d'un groupe d'instance régional. La distribution au sein d'une zone est ensuite effectuée avec un hachage cohérent.

L'équilibreur de charge utilise le processus suivant :

  1. L'adresse IP externe de la règle de transfert est annoncée par les routeurs périphériques aux limites du réseau de Google. Chaque annonce répertorie un saut suivant vers un système d'équilibrage de charge (Maglev) de couche 3/4 au plus près de l'utilisateur.
  2. Les systèmes Maglev inspectent l'adresse IP source du paquet entrant. Ils dirigent la requête entrante vers les systèmes Maglev que les systèmes de géolocalisation IP de Google déterminent au plus près de l'utilisateur.
  3. Les systèmes Maglev acheminent le trafic vers un GFE (Google Front End) de première couche. Le GFE de première couche interrompt le protocole TLS si nécessaire, puis achemine le trafic vers les GFE de deuxième couche en suivant le processus suivant :
    1. Le mappage d'URL sélectionne un service de backend.
    2. Si un service de backend utilise un groupe d'instances ou des backends NEG GCE_VM_IP_PORT, les GFE de première couche préfèrent les GFE de deuxième couche au sein de ou à proximité de la région qui contient le groupe d'instances ou le NEG.
    3. Pour les buckets de backend et les services de backend avec des NEG hybrides, des NEG sans serveur et des NEG Internet, les GFE de première couche choisissent des GFE de deuxième couche dans un sous-ensemble de régions, afin de réduire le délai aller-retour entre les deux GFE.

      La préférence des GFE de deuxième couche n'est pas une garantie. Elle peut changer de manière dynamique en fonction des conditions du réseau et de la maintenance de Google.

      Les GFE de deuxième couche connaissent l'état des vérifications d'état et l'utilisation réelle de la capacité du backend.

  4. Le GFE de deuxième couche dirige les requêtes vers les backend des zones de sa région.
  5. Au Niveau Premium, les GFE de deuxième couche envoient parfois des requêtes aux backends dans des zones de différentes régions. Ce comportement est appelé débordement.
  6. Le débordement est régi par deux principes :

    • Le débordement est possible lorsque tous les backends connus d'un GFE de deuxième couche sont au maximum de leur capacité ou non opérationnels.
    • Le GFE de deuxième couche contient des informations sur les backends disponibles et opérationnels dans les zones d'une autre région.

    Les GFE de deuxième couche sont généralement configurés pour desservir un sous-ensemble d'emplacements de backend.

    Le débordement n'épuise pas toutes les zones Google Cloud possibles. Pour détourner le trafic des backends d'une zone spécifique ou d'une région entière, vous devez définir le scaler de capacité sur zéro. Configurer les backends pour qu'ils échouent aux vérifications d'état ne garantit pas le débordement du GFE de deuxième couche sur les backends des zones d'une autre région.

  7. Lors de la distribution des requêtes vers les backends, les GFE fonctionnent au niveau zonal.

    Avec un faible nombre de requêtes par seconde, les GFE de deuxième couche préfèrent parfois une zone d'une région aux autres zones. Cette préférence est normale et attendue. La distribution entre les zones de la région ne se poursuit même pas tant que l'équilibreur de charge ne reçoit pas davantage de requêtes par seconde.

Affinité de session

L'affinité de session tente au mieux d'envoyer les requêtes d'un client donné au même backend, à condition qu'il soit opérationnel et dispose d'une capacité suffisante, en fonction du mode d'équilibrage configuré.

Dans Google Cloud, l'équilibrage de charge HTTP(S) propose trois types d'affinité de session :

Lorsque vous utilisez l'affinité de session, nous vous recommandons d'utiliser le mode d'équilibrage RATE au lieu de UTILIZATION. L'affinité de session est plus efficace si vous définissez le mode d'équilibrage sur le nombre de requêtes par seconde (RPS).

Assistance WebSocket

Les équilibreurs de charge HTTP(S) de Google Cloud sont compatibles en mode natif avec le protocole WebSocket lorsque vous utilisez HTTP ou HTTPS en tant que protocole avec le backend. L'équilibreur de charge ne nécessite aucune configuration pour relayer les connexions WebSocket par proxy.

Le protocole WebSocket fournit un canal de communication en duplex intégral entre clients et serveurs. Une requête HTTP(S) initialise le canal. Pour en savoir plus sur le protocole, consultez la RFC 6455.

Lorsque l'équilibreur de charge reconnaît une requête WebSocket Upgrade d'un client HTTP(S) suivie d'une réponse Upgrade réussie de la part de l'instance backend, l'équilibreur de charge relaie le trafic bidirectionnel par proxy pendant la durée de la connexion en cours. Si l'instance backend ne renvoie pas de réponse Upgrade réussie, l'équilibreur de charge ferme la connexion.

Le délai avant expiration d'une connexion WebSocket dépend du délai avant expiration du service backend configurable de l'équilibreur de charge, qui est de 30 secondes par défaut. Ce délai s'applique aux connexions WebSocket, qu'elles soient utilisées ou non.

L'affinité de session pour WebSockets fonctionne de la même manière que pour toute autre requête. Pour en savoir plus, consultez la section Affinité de session.

Nombre maximal de flux simultanés HTTP/2

Le paramètre SETTINGS_MAX_CONCURRENT_STREAMS HTTP/2 décrit le nombre maximal de flux accepté par le point de terminaison (flux lancés par le point de terminaison pair). La valeur annoncée par un client HTTP/2 à un équilibreur de charge Google Cloud est sans importance, car l'équilibreur de charge ne lance pas de flux vers le client.

Dans le cas où l'équilibreur de charge utilise HTTP/2 pour communiquer avec un serveur qui s'exécute sur une VM, l'équilibreur de charge respecte la valeur SETTINGS_MAX_CONCURRENT_STREAMS annoncée par le serveur. Si une valeur "zéro" est annoncée, l'équilibreur de charge ne peut pas transférer les requêtes vers le serveur, et cela peut générer des erreurs.

Limites liées à HTTP/2

  • Le protocole HTTP/2 entre l'équilibreur de charge et l'instance peut nécessiter beaucoup plus de connexions TCP à l'instance que HTTP(S). Le regroupement de connexions, une optimisation qui réduit le nombre de ces connexions avec HTTP(S), n'est pas disponible actuellement avec HTTP/2.
  • Le protocole HTTP/2 entre l'équilibreur de charge et le backend n'est pas compatible avec l'exécution du protocole WebSocket sur un seul flux d'une connexion HTTP/2 (RFC 8441).
  • Le protocole HTTP/2 entre l'équilibreur de charge et le backend n'est pas compatible avec le serveur push.
  • Le taux d'erreur gRPC et le volume des requêtes ne sont pas visibles dans l'API Google Cloud ni dans Cloud Console. Si le point de terminaison gRPC renvoie une erreur, les journaux de l'équilibreur de charge et les données de surveillance signalent le code de réponse HTTP "OK 200".

Étape suivante