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) externe est un équilibreur de charge de couche 7 basé sur un proxy qui vous permet d'exécuter et de faire évoluer vos services 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 diverses plates-formes Google Cloud (telles que Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage, etc.), ainsi que les backends externes connectés à Internet ou via une connectivité hybride. Pour en savoir plus, consultez la section Cas d'utilisation.

Modes de fonctionnement

Vous pouvez configurer l'équilibrage de charge HTTP(S) externe dans les modes suivants :

  • Équilibreur de charge HTTP(S) externe global. Il s'agit d'un équilibreur de charge global mis en œuvre en tant que service géré sur Google Front End (GFE). Il utilise le proxy Envoy Open Source pour prendre en charge des fonctionnalités avancées de gestion du trafic telles que la mise en miroir du trafic, la répartition du trafic en fonction d'une pondération, les transformations d'en-tête basées sur les requêtes/réponses, etc. Cet équilibreur de charge est actuellement en version bêta.
  • Équilibreur de charge HTTP(S) externe global (classique). Il s'agit de l'équilibreur de charge HTTP(S) externe classique qui est global au niveau Premium, mais qui peut être configuré pour être régional au niveau Standard. Cet équilibreur de charge est mis en œuvre sur les serveurs GFE (Google Front End). 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.
  • Équilibreur de charge HTTP(S) externe régional. Il s'agit d'un équilibreur de charge régional mis en œuvre en tant que service géré sur le proxy Envoy Open Source. Il comprend des fonctionnalités avancées de gestion du trafic telles que la mise en miroir du trafic, la répartition du trafic en fonction d'une pondération, les transformations d'en-tête basées sur les requêtes/réponses, etc. Cet équilibreur de charge est actuellement en version bêta.
Mode d'équilibreur de charge Cas d'utilisation recommandés Fonctions
Équilibreur de charge HTTP(S) externe global (bêta) Utilisez cet équilibreur de charge pour les charges de travail HTTP(S) externes avec des utilisateurs ou des services de backend dans plusieurs régions.
Équilibreur de charge HTTP(S) externe global (classique)

Cet équilibreur de charge est global au niveau Premium, mais peut être configuré pour être régional au niveau Standard.

Dans le niveau de service réseau Premium, cet équilibreur de charge offre un équilibrage de charge multirégional, en dirigeant le trafic vers le backend opérationnel le plus proche à la capacité suffisante, qui termine le trafic HTTP(S) le plus près possible de vos utilisateurs.

Dans le niveau de service réseau standard, l'équilibrage de charge est traité au niveau régional.

  • Compatible avec GKE
  • Moins de fonctionnalités de routage du trafic.
Consultez la page Fonctionnalités d'équilibrage de charge pour obtenir la liste complète des fonctionnalités.
Équilibreur de charge HTTP(S) externe régional (version bêta)

Cet équilibreur de charge contient de nombreuses fonctionnalités de l'équilibreur de charge HTTP(S) externe global (classique) existant, ainsi que des fonctionnalités supplémentaires de gestion avancée du trafic.

Utilisez cet équilibreur de charge si vous souhaitez diffuser du contenu à partir d'une seule géolocalisation (par exemple, pour respecter les réglementations de conformité) ou si vous souhaitez utiliser le niveau de service réseau standard.

Pour obtenir la liste complète, consultez la section Fonctionnalités d'équilibrage de charge.

Identifier le mode

Pour déterminer le mode d'un équilibreur de charge, exécutez la commande suivante :

gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

Dans le résultat de la commande, vérifiez le schéma et la région de l'équilibrage de charge. Le tableau suivant récapitule comment identifier le mode de l'équilibreur de charge.

Mode d'équilibreur de charge Schéma d'équilibrage de charge Règle de transfert
Équilibreur de charge HTTP(S) externe global (bêta) EXTERNAL_MANAGED Mondial
Équilibreur de charge HTTP(S) externe global (classique) EXTERNAL Mondial
Équilibreur de charge HTTP(S) externe régional (version bêta) EXTERNAL_MANAGED Spécifie une région

Architecture

Les ressources suivantes sont requises pour déployer un équilibrage de charge HTTP(S) :

  • Pour les équilibreurs de charge HTTP(S) externes régionaux, un sous-réseau proxy réservé est utilisé pour envoyer des connexions depuis l'équilibreur de charge vers les backends.

  • 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 HTTP(S) cible accepte un nombre limité de certificats SSL.
  • Le proxy HTTP(S) exploite un mappage d'URL mondial 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 répartit les requêtes entre les backends opérationnels. Les équilibreurs de charge HTTP(S) externes globaux sont également compatibles avec les buckets backend.

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

  • Règles de pare-feu pour que vos backends acceptent les vérifications d'état. Les équilibreurs de charge HTTP(S) externes régionaux nécessitent une règle de pare-feu supplémentaire pour autoriser le trafic provenant du sous-réseau proxy réservé à atteindre les backends.

Mondial

Ce schéma montre les composants d'un déploiement d'équilibreur de charge HTTP(S) externe global. Cette architecture s'applique à la fois à l'équilibreur de charge HTTP(S) externe global avec une fonctionnalité de gestion avancée du trafic et à l'équilibreur de charge HTTP(S) externe global (classique) au niveau Premium.

Composants de l'équilibreur de charge HTTP(S) externe global
Composants de l'équilibreur de charge HTTP(S) externe global

Régional

Ce schéma montre les composants d'un déploiement d'équilibreur de charge HTTP(S) externe régional.

Composants de l'équilibreur de charge HTTP(S) externe régional
Composants de l'équilibreur de charge HTTP(S) externe régional

Sous-réseau proxy réservé

Les sous-réseaux proxy réservés ne sont requis que pour les équilibreurs de charge HTTP(S) externes régionaux.

Le sous-réseau proxy réservé fournit un ensemble d'adresses IP utilisées par Google pour exécuter des proxys Envoy en votre nom. Vous devez créer un sous-réseau proxy réservé dans chaque région du réseau VPC dans lequel vous utilisez des équilibreurs de charge HTTP(S) externes régionaux. L'option --purpose pour ce sous-réseau proxy réservé est définie sur REGIONAL_MANAGED_PROXY. Tous les équilibreurs de charge HTTP(S) externes régionaux de la même région et du même réseau VPC partagent un pool de proxys Envoy du même sous-réseau proxy réservé. En outre :

  • Les sous-réseaux proxy réservés ne sont utilisés que pour les proxys Envoy, et non pour vos backends.
  • Les VM de backend ou les points de terminaison de tous les équilibreurs de charge HTTP(S) externes régionaux d'une région et d'un réseau VPC reçoivent les connexions du sous-réseau proxy réservé.
  • L'adresse IP de l'équilibreur de charge HTTP(S) externe régional n'est pas située dans le sous-réseau proxy réservé. L'adresse IP de l'équilibreur de charge est définie par sa règle de transfert gérée en externe et décrite ci-dessous.

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, d'adresse IP et de schéma d'équilibrage de charge utilisé par les équilibreurs de charge HTTP(S) externes dépend du mode de l'équilibreur de charge et du niveau de service réseau de l'équilibreur de charge.

Mode d'équilibreur de charge Niveau de service réseau Schéma de règle de transfert, adresse IP et équilibrage de charge Routage depuis Internet vers l'interface de l'équilibreur de charge
Équilibreur de charge HTTP(S) externe global (version bêta) Niveau Premium

Règle de transfert externe globale

Adresse IP externe globale

Schéma d'équilibrage de charge :
EXTERNAL_MANAGED

Requêtes acheminées vers le GFE le plus proche du client sur Internet.
Équilibreur de charge HTTP(S) externe global (classique) Niveau Premium

Règle de transfert externe globale

Adresse IP externe globale

Schéma d'équilibrage de charge :
EXTERNAL

Requêtes acheminées vers le GFE le plus proche du client sur Internet.
Niveau Standard

Règle de transfert externe régionale

Adresse IP externe régionale

Schéma d'équilibrage de charge :
EXTERNAL

Requêtes acheminées vers un GFE dans la région de l'équilibreur de charge
Équilibreur de charge HTTP(S) externe régional (version bêta) Niveau Standard

Règle de transfert externe régionale

Adresse IP externe régionale

Schéma d'équilibrage de charge :
EXTERNAL_MANAGED

Requêtes acheminées vers les proxys Envoy de la même région que l'équilibreur de charge.

Pour obtenir la liste complète des protocoles compatibles avec les règles de transfert d'équilibrage de charge HTTP(S) dans chaque mode, 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.

Le tableau suivant spécifie le type de proxy cible requis par l'équilibrage de charge HTTP(S) dans chaque mode.

Mode d'équilibreur de charge Types de proxys cibles En-têtes ajoutés par les proxys En-têtes personnalisés compatibles Compatibilité avec Cloud Trace
Équilibreur de charge HTTP(S) externe global (bêta) 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)
Configuré sur le service de backend ou le bucket backend.

Non compatible avec Cloud CDN

Équilibreur de charge HTTP(S) externe global (classique) 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)
Configuré sur le service de backend ou le bucket backend.
Équilibreur de charge HTTP(S) externe régional (bêta) HTTP régional,
HTTPS régional
  • X-Forwarded-Proto: [http | https] (requêtes uniquement)
  • Via: 1.1 google (requêtes et réponses)
  • 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 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.

Le tableau suivant spécifie la compatibilité HTTP/3 pour l'équilibrage de charge HTTP(S) dans chaque mode.

Mode d'équilibreur de charge Compatibilité HTTP/3
Équilibreur de charge HTTP(S) externe global (bêta)
Équilibreur de charge HTTP(S) externe global (classique)
Équilibreur de charge HTTP(S) externe régional (bêta)

Configurer le protocole HTTP/3

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

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'équilibrage de charge HTTP(S) propose trois méthodes de configuration de 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 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 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.

Les mappages d'URL utilisés avec les équilibreurs de charge HTTP(S) externes globaux et les équilibreurs de charge HTTP(S) externes régionaux sont compatibles avec plusieurs fonctionnalités de gestion avancée du trafic telles que l'orientation du trafic basée sur l'en-tête, la répartition du trafic en fonction d'une pondération et la mise en miroir des requêtes. Pour en savoir plus, consultez les ressources suivantes :

Le tableau suivant spécifie le type de mappage d'URL requis par l'équilibrage de charge HTTP(S) dans chaque mode.

Mode d'équilibreur de charge Type de mappage d'URL
Équilibreur de charge HTTP(S) externe global (bêta) Détecteurs internationaux
Équilibreur de charge HTTP(S) externe global (classique) Global (avec uniquement un sous-ensemble de fonctionnalités compatibles)
Équilibreur de charge HTTP(S) externe régional (bêta) Regional (Régional)

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.

Le tableau suivant spécifie le champ d'application du certificat SSL requis par l'équilibrage de charge HTTP(S) dans chaque mode :

Mode d'équilibreur de charge Champ d'application du certificat SSL
Équilibreur de charge HTTP(S) externe global (bêta) Détecteurs internationaux
Équilibreur de charge HTTP(S) externe global (classique) Détecteurs internationaux
Équilibreur de charge HTTP(S) externe régional (bêta) Regional (Régional)

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.

Le tableau suivant spécifie la compatibilité des règles SSL avec les équilibreurs de charge dans chaque mode.

Mode d'équilibreur de charge Règles SSL compatibles
Équilibreur de charge HTTP(S) externe global (bêta)
Équilibreur de charge HTTP(S) externe global (classique)
Équilibreur de charge HTTP(S) externe régional (bêta)

Services de backend et buckets

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 HTTP(S) externe, consultez la page Configurer un équilibreur de charge avec des buckets backend.

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


Mode d'équilibreur de charge
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 NEG hybrides
Équilibreur de charge HTTP(S) externe global (bêta)
Équilibreur de charge HTTP(S) externe global (classique)
en cas d'utilisation du niveau Premium

Équilibreur de charge HTTP(S) externe régional (version bêta)

Pour en savoir plus, consultez les ressources suivantes :

Protocole de communication avec les backends

Lorsque vous configurez un service de backend pour l'équilibreur de charge, 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é.

Pour obtenir la liste complète des protocoles acceptés, consultez la section Fonctionnalités d'équilibrage de charge : Protocoles entre l'équilibreur de charge et les backends.

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.

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. 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 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 du protocole HTTP/2 avec les backends.

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

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 entrant qui autorise les instances backend. La règle de pare-feu doit autoriser les plages sources suivantes :

  • 130.211.0.0/22
  • 35.191.0.0/16

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. Pour obtenir la liste des protocoles de vérification d'état compatibles, consultez la section Fonctionnalités d'équilibrage de charge.

Le tableau suivant spécifie le champ d'application de la vérification d'état compatible avec l'équilibrage de charge HTTP(S) dans chaque mode.

Mode d'équilibreur de charge Type de vérification d'état
Équilibreur de charge HTTP(S) externe global (bêta) Détecteurs internationaux
Équilibreur de charge HTTP(S) externe global (classique) Détecteurs internationaux
Équilibreur de charge HTTP(S) externe régional (bêta) Regional (Régional)

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

Règles de pare-feu

L'équilibrage de charge HTTP(S) nécessite les règles de pare-feu suivantes :

  • Pour les équilibreurs de charge HTTP(S) externes globaux, une règle d'entrée autorisant le trafic provenant des serveurs Google Front End (GFE) vers vos backends.
    Pour l'équilibreur de charge HTTP(S) externe régional, une règle d'autorisation d'entrée autorise le trafic provenant du sous-réseau proxy réservé.
  • Une règle d'autorisation d'entrée pour autoriser le trafic provenant des plages de vérification de l'état. Pour plus d'informations sur les vérifications de l'état et découvrir pourquoi il est nécessaire d'autoriser le trafic qui en provient, consultez Plages d'adresses IP de vérification et règles de pare-feu.

Les ports de ces règles de pare-feu doivent être configurés comme suit :

  • Autorisez le trafic vers le port de destination pour la vérification d'état de chaque service de backend.

  • Pour les backends de groupe d'instances : déterminez les ports à configurer 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 de port peuvent varier entre les groupes d'instances attribués au même service de backend.

  • Pour les backends de NEG GCE_VM_IP_PORT : autorisez le trafic 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 l'équilibreur de charge HTTP(S) externe global, vous pouvez utiliser Google Cloud Armor.

Pour les équilibreurs de charge HTTP(S) externes, le tableau suivant récapitule les plages d'adresses IP requises pour les règles de pare-feu :

Mode d'équilibreur de charge Plages sources de vérification d'état Demander des plages sources
Équilibreur de charge HTTP(S) externe global (bêta)
  • 130.211.0.0/22
  • 35.191.0.0/16
La source du trafic GFE dépend du type de backend :
  • Groupes d'instances, GCE_VM_IP_PORT NEGs, et NEG NON_GCP_PRIVATE_IP_PORT :
    • 130.211.0.0/22
    • 35.191.0.0/16
  • NEG 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
Équilibreur de charge HTTP(S) externe global (classique)
  • 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.
Équilibreur de charge HTTP(S) externe régional (version bêta)
  • 130.211.0.0/22
  • 35.191.0.0/16
Le sous-réseau proxy réservé que vous configurez.

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

Connexions à l'équilibreur de charge HTTP(S) externe global

Les équilibreurs de charge HTTP(S) externes globaux sont 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 les requêtes des clients sont dirigées 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. Pour les connexions HTTP ou HTTPS, la version HTTP utilisée est HTTP 1.1.

Le message HTTP keepalive est activé par défaut, comme indiqué dans la spécification HTTP 1.1. Les messages keepalive HTTP tentent d'utiliser efficacement la même session TCP. mais il n'y a aucune garantie. 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. Bien qu'ils soient étroitement liés, un message keepalive HTTP et un délai d'inactivité TCP ne sont pas identiques. Pour en savoir plus, consultez la section Délais d'expiration et nouvelles tentatives.

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

Connexions à l'équilibreur de charge HTTP(S) externe régional

L'équilibreur de charge HTTP(S) externe régional est un service géré mis en œuvre sur le proxy Envoy. L'équilibreur de charge HTTP(S) externe régional utilise un sous-réseau partagé appelé sous-réseau proxy réservé pour provisionner un ensemble d'adresses IP utilisées par Google pour exécuter des proxys Envoy en votre nom. L'option --purpose pour ce sous-réseau proxy réservé est définie sur REGIONAL_MANAGED_PROXY. Tous les équilibreurs de charge HTTP(S) externes régionaux d'un réseau et d'une région donnés partagent ce sous-réseau.

Les clients utilisent l'adresse IP et le port de l'équilibreur de charge pour se connecter à cet équilibreur de charge. Les requêtes des clients sont dirigées vers le sous-réseau proxy réservé situé dans la même région que le client. L'équilibreur de charge interrompt les requêtes des clients, puis ouvre de nouvelles connexions entre le sous-réseau proxy réservé et vos backends. Par conséquent, les paquets envoyés à partir de l'équilibreur de charge ont des adresses IP sources du sous-réseau proxy réservé.

Selon la configuration du service de backend, le protocole utilisé par les proxys Envoy 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 proxy Envoy 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.

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 d'équilibrage de charge HTTP(S) dans chaque mode, consultez la page Fonctionnalités de l'équilibreur de charge.

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 :

Pour les équilibreurs de charge HTTP(S) externes globaux :
  • 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 VPC.

Pour les équilibreurs de charge HTTP(S) externes régionaux :

  • Connexion 1, du client d'origine vers l'équilibreur de charge (sous-réseau proxy réservé) :

    • 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 (sous-réseau proxy réservé) vers la VM de backend ou le point de terminaison :

    • Adresse IP source : une adresse IP du sous-réseau proxy réservé partagée entre tous les équilibreurs de charge basés sur Envoy déployés dans la même région en tant qu'équilibreur de charge.

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

Chemin de retour

Pour les équilibreurs de charge HTTP(S) externes globaux, Google Cloud utilise des routes spéciales non définies dans votre réseau VPC pour les vérifications d'état. Pour en savoir plus, consultez la section Chemins de retour pour les équilibreurs de charge.

Pour les équilibreurs de charge HTTP(S) externes régionaux, Google Cloud utilise des proxys Envoy Open Source pour interrompre les requêtes des clients adressées à l'équilibreur de charge. L'équilibreur de charge interrompt la session TCP et ouvre une nouvelle session TCP depuis le sous-réseau proxy réservé de la région vers votre backend. Les routes définies au sein de votre réseau VPC facilitent la communication entre les proxys Envoy et vos backends, et inversement.

Ports ouverts

Cette section ne s'applique qu'aux équilibreurs de charge HTTP(S) externes globaux mis en œuvre à l'aide des serveurs GFE.

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 un équilibreur de charge 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

Le tableau suivant récapitule la manière dont la terminaison TLS est gérée par les équilibreurs de charge HTTP(S) externes de chaque mode.

Mode d'équilibreur de charge terminaison TLS
Équilibreur de charge HTTP(S) externe global (bêta) Le protocole TLS est interrompu sur un GFE, qui peut se trouver n'importe où dans le monde.
Équilibreur de charge HTTP(S) externe global (classique) Le protocole TLS est interrompu sur un GFE, qui peut se trouver n'importe où dans le monde.
Équilibreur de charge HTTP(S) externe régional (bêta) TLS est interrompu sur les proxys Envoy situés dans un sous-réseau proxy réservé dans une région choisie par l'utilisateur. Utilisez ce mode d'équilibreur de charge si vous avez besoin d'exercer un contrôle géographique sur la région où le protocole TLS est interrompu.

Délais d'expiration et nouvelles tentatives

L'équilibrage de charge HTTP(S) externe présente deux types de délais avant expiration distincts :
  • Un délai avant expiration HTTP du service de backend configurable, qui représente la durée pendant laquelle l'équilibreur de charges 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 comprise entre 1 et 2 147 483 647 secondes.

    Par exemple, si la valeur du délai avant expiration du service de backend est la valeur par défaut de 30 secondes, les backends ont 30 secondes pour répondre aux requêtes. L'équilibreur de charge réessaye la requête HTTP GET une fois si le backend ferme la connexion ou ne parvient pas à envoyer des en-têtes de réponse à l'équilibreur de charge avant expiration du délai. Si le backend envoie des en-têtes de réponse ou si la requête envoyée au backend n'est pas une requête HTTP GET, l'équilibreur de charge n'effectue pas de nouvelle tentative. Si le backend ne répond pas du tout, l'équilibreur de charge renvoie une requête HTTP 5xx au client. Pour ces équilibreurs de charge, modifiez la valeur du délai avant expiration si vous souhaitez accorder plus ou moins de temps aux backends pour répondre aux requêtes.

    Le délai avant expiration du service de backend doit être défini sur la durée maximale possible entre le premier octet de la requête et le dernier octet de la réponse, pour l'interaction entre le GFE et votre backend. Si vous utilisez WebSockets, le délai avant expiration du service de backend doit être défini sur la durée maximale d'un WebSocket, inactif ou actif.

    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.

    Le délai avant expiration du service de backend que vous définissez est l'objectif le plus optimal. Cela ne garantit pas que les connexions TCP sous-jacentes resteront ouvertes pendant ce délai.

    Vous pouvez définir le délai avant expiration du service de backend sur la valeur de votre choix. Toutefois, définir un délai d'expiration de plus d'un jour (86 400 secondes) ne signifie pas que l'équilibreur de charge conservera une connexion TCP exécutée aussi longtemps. C'est possible, mais sans garantie. Google redémarre régulièrement les GFE pour les mises à jour logicielles et la maintenance de routine, et votre délai avant expiration du service de backend ne peut contourner cela. Plus la durée avant expiration de votre service de backend est longue, plus il est probable que Google mette fin à une connexion TCP pour la maintenance des GFE. Nous vous recommandons de mettre en œuvre une logique de nouvelle tentative pour réduire l'impact de tels événements.

    Pour en savoir plus, consultez la section Paramètres du service de backend.

    Le délai avant expiration du service de backend n'est pas un délai d'inactivité HTTP (message keepalive). Il est possible que l'entrée et la sortie (E/S) du backend soient bloquées en raison de la lenteur d'un client (un navigateur avec une connexion lente, par exemple). Ce délai d'attente n'est pas comptabilisé dans le délai avant expiration du service de backend.

    Pour les équilibreurs de charge HTTP(S) externes régionaux, le paramètre routeActions.timeout du mappage d'URL peut remplacer le délai avant expiration du service de backend. Le délai avant expiration du service de backend est utilisé comme valeur par défaut pour routeActions.timeout.

  • Un délai avant expiration HTTP keepalive, dont la valeur est fixée à 10 minutes (600 secondes). Cette valeur n'est pas configurable par la modification du 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 avant 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 avant 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;

Tentatives

La compatibilité de l'équilibrage de charge HTTP(S) pour la logique de nouvelle tentative dépend du mode de l'équilibreur de charge HTTP(S) externe.

Mode d'équilibreur de charge Logique de nouvelle tentative
Équilibreur de charge HTTP(S) externe global (bêta)

Configurable à l'aide d'une stratégie de nouvelle tentative dans le mappage d'URL. Le nombre de nouvelles tentatives par défaut (numRetries) est de 1. Le nombre maximal de nouvelles tentatives pouvant être configurées à l'aide de la stratégie de nouvelle tentative est de 25. Le délai avant expiration par défaut pour chaque tentative (perTryTimeout) est de 30 secondes avec une valeur de perTryTimeout configurable maximale de 24 heures.

Sans stratégie de nouvelle tentative, les requêtes infructueuses sans corps HTTP (par exemple, des requêtes GET) aboutissant à des réponses HTTP 502, 503 ou 504 sont relancées une seule fois. Les requêtes HTTP POST ne font pas l'objet d'une nouvelle tentative.

Équilibreur de charge HTTP(S) externe global (classique)

Vous ne pouvez pas modifier la stratégie de nouvelle tentative pour les nouvelles tentatives de connexion.

Les requêtes HTTP POST ne font pas l'objet d'une nouvelle tentative.

Les requêtes HTTP GET sont toujours relancées tant qu'au moins 80 % des backends sont opérationnels. 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.

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é. Le nombre de nouvelles tentatives d'exécution d'une requête est limité à 25. 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. Pour en savoir plus, consultez la page Journalisation et surveillance de l'équilibrage de charge HTTP(S).

Les requêtes infructueuses aboutissent à la synthèse d'une réponse HTTP 502.

Équilibreur de charge HTTP(S) externe régional (version bêta)

Configurable à l'aide d'un mappage d'URL (numRetries) dans le mappage d'URL.

Sans stratégie de nouvelle tentative, les requêtes sans corps HTTP (par exemple, les requêtes GET) sont relancées une seule fois.

Le protocole WebSocket est compatible avec GKE Ingress.

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

Il existe différentes raisons pour lesquelles l'équilibreur de charge 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.

La manière dont le trafic est réparti entre les backends dépend du mode de l'équilibreur de charge.

Équilibreur de charge HTTP(S) externe global

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 l'équilibreur de charge HTTP(S) externe global (classique), le mode d'équilibrage permet de sélectionner le backend le plus adapté (groupe d'instances ou NEG). Le trafic est ensuite distribué à tour de rôle entre les instances ou les points de terminaison du backend.

Pour l'équilibreur de charge HTTP(S) externe global, l'équilibrage de charge est réparti sur deux niveaux. Le mode d'équilibrage détermine la pondération ou la fraction du trafic à envoyer à chaque backend (groupe d'instances ou NEG). Ensuite, la règle d'équilibrage de charge (LocalityLbPolicy) détermine la manière dont le trafic est distribué aux instances ou aux points de terminaison au sein du groupe. Pour en savoir plus, consultez la page Règle de localité d'équilibrage de charge (documentation de l'API du service de backend).

Équilibreur de charge HTTP(S) externe régional

Pour les équilibreurs de charge HTTP(S) externes régionaux, la répartition du trafic est basée sur le mode d'équilibrage de charge et sur la règle d'équilibrage de charge de la localité.

Le mode d'équilibrage détermine la pondération et la fraction de trafic à envoyer à chaque groupe (groupe d'instances ou NEG). La règle de localité d'équilibrage de charge (LocalityLbPolicy) détermine la manière dont les backends du groupe sont équilibrés.

Lorsqu'un service de backend reçoit du trafic, il dirige tout d'abord le trafic vers un backend (groupe d'instances ou NEG) en fonction du mode d'équilibrage du backend. Ensuite, une fois le backend sélectionné, le trafic est réparti entre les instances ou les points de terminaison de ce groupe de backend conformément à la règle de localité d'équilibrage de charge.

Pour en savoir plus, consultez les ressources suivantes :

Distribution des requêtes

La répartition régionale du trafic ou le niveau global dépend du mode d'équilibrage de charge et 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 l'équilibreur de charge ne dirige 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 effectuée avec un hachage cohérent pour l'équilibreur de charge HTTP(S) externe global (classique) et configurable à l'aide de la règle d'équilibrage de charge de la localité pour l'équilibreur de charge HTTP(S) externe global et l'équilibreur de charge HTTP(S) externe régional.

Les équilibreurs de charge HTTP(S) externes globaux basés sur GFE utilisent le processus suivant pour répartir les requêtes entrantes :

  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. Parfois, pour le niveau Premium, les GFE de deuxième couche envoient des requêtes aux backends dans des zones de différentes régions. Ce comportement est appelé basculement.
  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 dans la région par rapport aux autres zones. Cette préférence est normale et attendue. La distribution entre les zones de la région ne se produit que lorsque l'équilibreur de charge reçoit 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é.

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

L'équilibrage de charge HTTP(S) propose les types d'affinité de session suivants :

Le tableau suivant récapitule les options d'affinité de session compatibles avec chaque mode d'équilibrage de charge HTTP(S) :

Mode d'équilibreur de charge Options d'affinité de session
  Aucun IP client Cookie généré Champ d'en-tête Cookie HTTP
Équilibreur de charge HTTP(S) externe global (bêta)
Équilibreur de charge HTTP(S) externe global (classique)
Équilibreur de charge HTTP(S) externe régional (version bêta)

Compatibilité HTTP/2

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