Présentation de l'équilibreur de charge d'application externe

Ce document présente les concepts que vous devez maîtriser pour configurer un équilibreur de charge d'application externe.

Un équilibreur de charge d'application 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'équilibreur de charge d'application externe distribue le trafic HTTP et HTTPS aux backends hébergés sur diverses plates-formesGoogle Cloud (telles que Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage, etc.), ainsi qu'à des backends externes connectés sur Internet ou via une connectivité hybride. Pour en savoir plus, consultez la page Présentation de l'équilibreur de charge d'application: cas d'utilisation.

Modes de fonctionnement

Vous pouvez configurer un équilibreur de charge d'application externe dans les modes suivants :

• Équilibreur de charge d'application externe mondial. 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 du poids, les transformations d'en-tête basé sur les requêtes/réponses, etc.
• Équilibreur de charge d'application classique. Il s'agit de l'équilibreur de charge d'application 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 d'application 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.

Mode d'équilibreur de charge	Cas d'utilisation recommandés	Capacités
Équilibreur de charge d'application externe global	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.	Compatible avec GKE en utilisant un objet Gateway (entièrement orchestré) ou des NEG autonomes (orchestration manuelle). Compatible avec la gestion avancée du trafic Adresses IP externes globales Anycast sur le niveau Premium Peut accéder aux backends dans plusieurs régions Compatible avec Cloud CDN Compatible avec Google Cloud Armor
Équilibreur de charge d'application classique	Cet équilibreur de charge est mondial et inclut le niveau Premium. Dans le niveau de service réseau Premium, cet équilibreur de charge offre un équilibrage de charge multirégional, tente de diriger le trafic vers le backend opérationnel le plus proche dont la capacité est suffisante, et termine le trafic HTTP(S) le plus près possible de vos utilisateurs. Pour en savoir plus sur le processus de distribution des requêtes, consultez la section Distribution du trafic. Dans le niveau de service réseau standard, cet équilibreur de charge ne peut distribuer le trafic qu'aux backends d'une seule région.	Compatible avec GKE en utilisant un objet Gateway (entièrement orchestré), Ingress (entièrement orchestré) ou des NEG autonomes (orchestration manuelle). Compatible avec Google Cloud Armor 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 d'application externe régional	Cet équilibreur de charge contient de nombreuses fonctionnalités de l'équilibreur de charge d'application 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é). Cet équilibreur de charge peut être configuré en niveau Premium ou Standard.	Compatible avec GKE en utilisant des NEG autonomes (orchestration manuelle). Compatibilité avec les fonctionnalités avancées de gestion du trafic Adresses IP virtuelles régionales utilisant le niveau de réseau Standard Met fin au protocole TLS dans une seule région que vous configurez. Ne diffuse que le contenu de la région configurée Pour obtenir la liste complète, consultez la section Fonctionnalités d'équilibrage de charge.

Identifier le mode

Cloud Console

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

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

2. Dans l'onglet Équilibreurs de charge, le type, le protocole et la région de l'équilibreur de charge sont affichés. Si la région est vide, l'équilibreur de charge est global. Le tableau suivant récapitule comment identifier le mode de l'équilibreur de charge.

Mode d'équilibreur de charge	>Type d'équilibreur de charge	Type d'accès	Région
Équilibreur de charge d'application externe global	Application	Externe
Équilibreur de charge d'application classique	Application (classique)	Externe
Équilibreur de charge d'application externe régional	Application	Externe	Spécifie une région

gcloud

1. 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 d'équilibrage de charge, la région et le niveau de réseau. 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	Niveau de réseau
Équilibreur de charge d'application externe global	EXTERNAL_MANAGED	Mondial	Premium
Équilibreur de charge d'application classique	EXTERNAL	Mondial	Standard ou Premium
Équilibreur de charge d'application externe régional	EXTERNAL_MANAGED	Spécifie une région	Standard ou Premium

Important : Une fois que vous avez créé un équilibreur de charge, vous ne pouvez plus modifier son mode. Vous devez supprimer l'équilibreur de charge et en créer un autre.

Architecture

Les ressources suivantes sont requises pour déployer un équilibreur de charge d'application externe :

• Pour les équilibreurs de charge d'application 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 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 distribue les requêtes aux backends opérationnels. Les équilibreurs de charge d'application externes globaux acceptent également 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 d'application 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.

Monde

Ce schéma montre les composants d'un déploiement de l'équilibreur de charge d'application externe global. Cette architecture s'applique à la fois à l'équilibreur de charge d'applications externe global et à l'équilibreur de charge d'application classique au niveau Premium.

Composants de l'équilibreur de charge d'application externe global (cliquez pour agrandir).

Régional

Ce schéma montre les composants d'un déploiement d'équilibreur de charge d'application externe régional.

Composants de l'équilibreur de charge d'application externe régional (cliquez pour agrandir).

Sous-réseau proxy réservé

Les sous-réseaux proxy réservés ne sont requis que pour les équilibreurs de charge d'application 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 d'application 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 régionaux basés sur Envoy situés dans la même région et sur le 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 d'application 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 d'application 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.

Si vous avez déjà créé un sous-réseau proxy réservé avec --purpose=INTERNAL_HTTPS_LOAD_BALANCER, vous devez migrer l'objectif du sous-réseau vers REGIONAL_MANAGED_PROXY avant de pouvoir créer d'autres équilibreurs de charge basés sur Envoy dans la même région du réseau VPC.

Règles de transfert et adresses IP

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.

Spécification d'adresse IP. 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.

Spécification du port Chaque règle de transfert d'un équilibreur de charge d'application peut référencer un port unique compris entre 1 et 65 535. Pour accepter plusieurs ports, vous devez configurer plusieurs règles de transfert. Vous pouvez configurer plusieurs règles de transfert pour utiliser la même adresse IP externe (VIP) et référencer le même proxy HTTP(S) cible tant que la combinaison globale de l'adresse IP, du port et du protocole sont uniques pour chaque règle de transfert. Vous pouvez ainsi utiliser un seul équilibreur de charge avec un mappage d'URL partagé en tant que proxy pour plusieurs applications.

Le type de règle de transfert, d'adresse IP et de schéma d'équilibrage de charge utilisé par les équilibreurs de charge d'application 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	Règle de transfert, adresse IP et schéma d'équilibrage de charge	Routage depuis Internet vers l'interface de l'équilibreur de charge
Équilibreur de charge d'application externe global	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 d'application 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 d'application externe régional	Niveau Premium ou Standard	Règle de transfert externe régionale Adresse IP externe régionale Schéma d'équilibrage de charge : EXTERNAL_MANAGED	Les requêtes atteignent Google Cloud au niveau du PoP le plus proche du client. Les requêtes sont ensuite acheminées via le réseau backbone premium de Google Cloudjusqu'à ce qu'elles atteignent les proxys Envoy situés dans la même région que l'équilibreur de charge.

^* Il est possible d'associer des services de backend EXTERNAL_MANAGED aux règles de transfert EXTERNAL. Toutefois, les services de backend EXTERNAL ne peuvent pas être associés à des règles de transfert EXTERNAL_MANAGED. Pour profiter des nouvelles fonctionnalités disponibles uniquement avec l'équilibreur de charge d'application externe global, nous vous recommandons de migrer vos ressources EXTERNAL existantes vers EXTERNAL_MANAGED à l'aide du processus de migration décrit dans la section Migrer des ressources d'un équilibreur de charge d'application externe global vers un équilibreur de charge d'application externe global.

Pour obtenir la liste complète des protocoles compatibles avec les règles de transfert d'équilibreur de charge d'application externe dans chaque mode, consultez la page Fonctionnalités de l'équilibreur de charge.

Règles de transfert et réseaux VPC

Cette section décrit comment les règles de transfert utilisées par les équilibreurs de charge d'application externes sont associées aux réseaux VPC.

Mode d'équilibreur de charge	Association de réseau VPC
Équilibreur de charge d'application externe global, Équilibreur de charge d'application classique	Aucun réseau VPC associé. La règle de transfert utilise toujours une adresse IP située en dehors du réseau VPC. Par conséquent, la règle de transfert n'est associée à aucun réseau VPC.
Équilibreur de charge d'application externe régional	Le réseau VPC de la règle de transfert est le réseau sur lequel le sous-réseau proxy réservé a été créé. Vous spécifiez le réseau lorsque vous créez la règle de transfert. Selon que vous utilisez une adresse IPv4 ou une plage d'adresses IPv6, il existe toujours un réseau VPC explicite ou implicite associé à la règle de transfert. Les adresses IPv4 externes régionales existent toujours en dehors des réseaux VPC. Toutefois, lorsque vous créez la règle de transfert, vous devez spécifier le réseau VPC sur lequel le sous-réseau proxy réservé a été créé. Par conséquent, la règle de transfert possède une association réseau explicite. Les plages d'adresses IPv6 externes régionales existent toujours dans un réseau VPC. Lorsque vous créez la règle de transfert, vous devez spécifier le sous-réseau à partir duquel la plage d'adresses IP est extraite. Ce sous-réseau doit se trouver dans la même région et le même réseau VPC que celui où un sous-réseau proxy réservé a été créé. Il existe donc une association de réseau implicite.

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.

Remarque : Pour les groupes de points de terminaison du réseau (NEG) Internet, les requêtes de l'équilibreur de charge proviennent de différentes plages d'adresses IP en fonction du type de NEG (global ou régional). Pour en savoir plus, consultez la section Authentifier les requêtes.

Le tableau suivant spécifie le type de proxy cible requis par les équilibreurs de charge d'application externes.

Mode d'équilibreur de charge	Types de proxys cibles	En-têtes ajoutés par les proxys	En-têtes personnalisés compatibles
Équilibreur de charge d'application externe global	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-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (voir l'en-tête X-Forwarded-For) (requêtes uniquement) Les proxys définissent également l'en-tête X-Cloud-Trace-Context s'il n'est pas déjà présent.	Configuré sur le service de backend ou le bucket backend. Non compatible avec Cloud CDN
Équilibreur de charge d'application 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-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (voir l'en-tête X-Forwarded-For) (requêtes uniquement) Les proxys définissent également l'en-tête X-Cloud-Trace-Context s'il n'est pas déjà présent.	Configuré sur le service de backend ou le bucket backend.
Équilibreur de charge d'application externe régional	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)	Configuré dans le mappage d'URL

Remarque : Conformément à la norme RFC 2616, les en-têtes de prochain saut ne sont pas propagés par le proxy cible : Connection, Keep-Alive, Proxy-Authenticate, Proxy-Authorization, TE, Trailers, Transfer-Encoding et Upgrade.

En plus des en-têtes ajoutés par le proxy cible, l'équilibreur de charge ajuste certains autres en-têtes HTTP comme suit :

• Pour l'équilibreur de charge d'application externe global, les en-têtes de requête et de réponse peuvent être convertis en minuscules.

  La seule exception à cette règle s'applique lorsque vous utilisez des backends NEG Internet globaux avec HTTP/1.1. Pour en savoir plus sur le traitement des en-têtes HTTP/1.1 avec les NEG Internet globaux, consultez la présentation des NEG Internet.

• Pour l'équilibreur de charge d'application classique, les en-têtes de requête et de réponse sont convertis en minuscules, sauf lorsque vous utilisez HTTP/1.1. Avec HTTP/1.1, les en-têtes sont traités comme des noms propres. La première lettre de la clé d'en-tête et chaque lettre suivant un trait d'union (-) sont mises en majuscule afin de préserver la compatibilité avec les clients HTTP/1.1. Par exemple, user-agent est remplacé par User-Agent, et content-encoding devient Content-Encoding.

• Certains en-têtes sont fusionnés. Lorsqu'il existe plusieurs instances de la même clé d'en-tête (par exemple, Via), l'équilibreur de charge combine leurs valeurs dans une même liste d'éléments séparés par des virgules correspondant à une clé d'en-tête unique. Seuls les en-têtes dont les valeurs peuvent être représentées sous la forme d'une liste d'éléments séparés par des virgules sont fusionnés. Les autres en-têtes, tels que Set-Cookie, ne sont jamais fusionnés.

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>

Attention  : L'équilibreur de charge ne vérifie pas les adresses IP qui précèdent <client-ip>,<load-balancer-ip> dans cet en-tête. Les adresses IP précédentes peuvent contenir d'autres caractères, y compris des espaces.

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>

Assistance Cloud Trace

Trace n'est pas compatible avec les équilibreurs de charge d'application. Les équilibreurs de charge d'application globaux et classiques ajoutent l'en-tête X-Cloud-Trace-Context s'il n'est pas présent. L'équilibreur de charge d'application externe régional n'ajoute pas cet en-tête. Si l'en-tête X-Cloud-Trace-Context est déjà présent, il passe par les équilibreurs de charge sans modification. Toutefois, aucune trace ni aucun délai n'est exporté par l'équilibreur de charge.

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. Le mappage d'URL vous permet de diviser votre trafic en examinant les composants d'URL permettant d'envoyer des requêtes à différents ensembles de backends. 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 spécifiée.

Dans certains cas, comme dans l'exemple d'équilibrage de charge multirégional, vous pouvez ne définir aucune règle d'URL et vous appuyer uniquement sur le service par défaut.

Les mappages d'URL sont compatibles avec plusieurs fonctionnalités avancées de gestion 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 :

• Présentation de la gestion du trafic pour les équilibreurs de charge d'application externes mondiaux

• Présentation de la gestion du trafic pour les équilibreurs de charge d'application externes régionaux

Le tableau suivant spécifie le type de mappage d'URL requis par les équilibreurs de charge d'application externes dans chaque mode.

Mode d'équilibreur de charge	Type de mappage d'URL
Équilibreur de charge d'application externe global	Global
Équilibreur de charge d'application classique	Global (avec uniquement un sous-ensemble de fonctionnalités compatibles)
Équilibreur de charge d'application externe régional	Regional (Régional)

Certificats SSL

Les équilibreurs de charge d'application externes utilisant des proxys HTTPS cibles nécessitent des clés privées et des certificats SSL dans le cadre de la configuration de l'équilibreur de charge.

• Google Cloud fournit deux méthodes de configuration permettant d'attribuer des clés privées et des certificats SSL aux proxys HTTPS cibles: les certificats SSL Compute Engine et le gestionnaire de certificats. Pour obtenir une description de chaque configuration, consultez la section Méthodes de configuration des certificats dans la présentation des certificats SSL.

• Google Cloud fournit deux types de certificats: autogérés et gérés par Google. Pour obtenir une description de chaque type, consultez la section Types de certificats dans la présentation des certificats SSL.

Le type d'équilibreur de charge d'application externe (global, régional ou classique) détermine les méthodes de configuration et les types de certificats compatibles. Pour en savoir plus, consultez la section Certificats et Google Cloud équilibreurs de charge dans la présentation des certificats SSL.

Règles SSL

Les règles SSL spécifient l'ensemble des fonctionnalités SSL utilisées par Google Cloud les équilibreurs de charge lors des négociations SSL avec des clients.

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 une règle SSL pour spécifier l'ensemble des fonctionnalités SSL utilisées par votre équilibreur de charge lors de la négociation SSL avec les clients. En outre, vous pouvez appliquer cette 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 d'application externe global
Équilibreur de charge d'application classique
Équilibreur de charge d'application externe régional

Services de backend

Un service de backend fournit des informations de configuration à l'équilibreur de charge afin qu'il puisse diriger les requêtes vers ses backends, par exemple des groupes d'instances Compute Engine ou des groupes de points de terminaison du réseau (NEG). Pour en savoir plus sur les services de backend, consultez la page Présentation des services de backend.

Pour obtenir un exemple de configuration d'un équilibreur de charge avec un service de backend et un backend Compute Engine, consultez la section Configurer un équilibreur de charge d'application externe avec un backend Compute Engine.

Champ d'application du service de backend

Le tableau suivant indique la ressource et le champ d'application de service de backend utilisés par les équilibreurs de charge d'application externes:

Mode d'équilibreur de charge	Ressources du service de backend
Équilibreur de charge d'application externe global	backendServices (monde entier)
Équilibreur de charge d'application classique	backendServices (monde entier)
Équilibreur de charge d'application externe régional	regionBackendServices (régional)

Protocole de communication avec les backends

Les services de backend pour les équilibreurs de charge d'application doivent utiliser l'un des protocoles suivants pour envoyer des requêtes aux backends:

• HTTP, qui utilise HTTP/1.1 et aucun protocole TLS
• HTTPS, qui utilise HTTP/1.1 et TLS
• HTTP/2, qui utilise HTTP/2 et TLS (HTTP/2 sans chiffrement n'est pas compatible).
• H2C, qui utilise HTTP/2 sur TCP. TLS n'est pas requis. H2C n'est pas compatible avec les équilibreurs de charge d'application classiques.

L'équilibreur de charge n'utilise que le protocole de service de backend que vous spécifiez pour communiquer avec ses backends. L'équilibreur de charge ne revient pas à un protocole différent s'il ne peut pas communiquer avec les backends à l'aide du protocole de service de backend spécifié.

Le protocole de service de backend n'a pas besoin de correspondre au protocole utilisé par les clients pour communiquer avec l'équilibreur de charge. Par exemple, les clients peuvent envoyer des requêtes à l'équilibreur de charge via HTTP/2, mais l'équilibreur de charge peut communiquer avec les backends à l'aide de HTTP/1.1 (HTTP ou HTTPS).

Buckets backend

Les buckets backend dirigent le trafic entrant vers des buckets Cloud Storage. Pour obtenir un exemple montrant comment ajouter un bucket à un équilibreur de charge d'application externe, consultez la page Configurer un équilibreur de charge avec des buckets backend. Pour obtenir des informations générales sur Cloud Storage, consultez la page Qu'est-ce que Cloud Storage ?

Backends

Le tableau suivant spécifie les backends et les fonctionnalités associées compatibles avec les équilibreurs de charge d'application externes 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^#	Compatible avec les extensions de service
	Groupes d'instances^†	NEG zonaux^‡	NEG Internet	NEG sans serveur	NEG hybrides	NEG Private Service Connect
Équilibreur de charge d'application externe global
Équilibreur de charge d'application classique									Niveau Premium
Équilibreur de charge d'application externe régional

^* Les backends d'un service de backend doivent être du même type: tous les groupes d'instances ou tous le même type de NEG. Une exception à cette règle est que les NEG zonaux GCE_VM_IP_PORT et les NEG hybrides peuvent être utilisés sur le même service de backend pour prendre en charge une architecture hybride.

^† Les combinaisons de groupes d'instances zonaux non gérés, gérés zonaux et gérés régionaux sont acceptées sur le même service de backend. Lorsque vous utilisez l'autoscaling pour un groupe d'instances géré qui est le backend de deux services de backend ou plus, configurez la règle d'autoscaling du groupe d'instances pour qu'elle utilise plusieurs signaux.

^‡ Les NEG zonaux doivent utiliser des points de terminaison GCE_VM_IP_PORT.

^# IAP et Cloud CDN sont incompatibles. Vous ne pouvez pas les activer toutes les deux sur le même service de backend.

Backends et réseaux VPC

Les restrictions concernant l'emplacement des backends dépendent du type d'équilibreur de charge.

Pour les backends d'équilibreur de charge d'application externe global, les conditions suivantes s'appliquent:

• Les instances backend (pour les backends de groupe d'instances) et les points de terminaison de backend (pour les backends NEG) peuvent se trouver dans n'importe quel réseau VPC au sein de la même organisation. Il n'est pas nécessaire de connecter les différents réseaux VPC à l'aide de l'appairage de réseaux VPC, car les GFE communiquent directement avec les backends dans leurs réseaux VPC respectifs.

• Les buckets Cloud Storage ne sont pas associés à un réseau VPC. Ils peuvent se trouver dans n'importe quel projet de la même organisation.

  Les équilibreurs de charge d'application externes globaux sont également compatibles avec les environnements VPC partagés dans lesquels vous pouvez partager des réseaux VPC et leurs ressources associées entre des projets. Toutefois, pour les équilibreurs de charge d'application externes globaux, il n'est pas nécessaire de configurer le VPC partagé pour pouvoir référencer des services de backend ou des buckets backend d'autres projets de votre organisation.

Pour les backends d'équilibreur de charge d'application classique, les conditions suivantes s'appliquent:

• Toutes les instances backend des backends de groupes d'instances et tous les points de terminaison de backend des backends NEG doivent se trouver dans le même projet. Toutefois, un backend de groupe d'instances ou un NEG peut utiliser un réseau VPC différent dans ce projet. Les différents réseaux VPC n'ont pas besoin d'être connectés à l'aide de l'appairage de réseaux VPC, car les GFE communiquent directement avec les backends dans leurs réseaux VPC respectifs.

• Les buckets Cloud Storage ne sont pas associés à un réseau VPC. Toutefois, ils doivent être situés dans le même projet que l'équilibreur de charge.

Pour les backends d'équilibreur de charge d'application externe régional, les conditions suivantes s'appliquent:

• Pour les groupes d'instances, les NEG zonaux et les NEG de connectivité hybride, tous les backends doivent se trouver dans le même projet et la même région que le service de backend. Toutefois, un équilibreur de charge peut référencer un backend qui utilise un réseau VPC différent dans le même projet que le service de backend (cette fonctionnalité est disponible en version preview). La connectivité entre le réseau VPC de l'équilibreur de charge et le réseau VPC de backend peut être configurée à l'aide de l'appairage de réseaux VPC, de tunnels Cloud VPN, de rattachements de VLAN Cloud Interconnect ou d'un framework Network Connectivity Center.

  Définition du réseau backend

  • Pour les NEG zonaux et les NEG hybrides, vous spécifiez explicitement le réseau VPC lorsque vous créez le NEG.
  • Pour les groupes d'instances gérés, le réseau VPC est défini dans le modèle d'instance.
  • Pour les groupes d'instances non gérés, le réseau VPC du groupe d'instances est configuré pour correspondre au réseau VPC de l'interface nic0 pour la première VM ajoutée au groupe d'instances.

  Configuration requise pour le réseau de backend

  Le réseau de votre backend doit répondre à l'une des exigences réseau suivantes :

  • Le réseau VPC du backend doit correspondre exactement au réseau VPC de la règle de transfert.

  • Le réseau VPC du backend doit être connecté au réseau VPC de la règle de transfert à l'aide de l'appairage de réseaux VPC. Vous devez configurer des échanges de routes de sous-réseau pour autoriser la communication entre le sous-réseau proxy réservé du réseau VPC de la règle de transfert et les sous-réseaux utilisés par les instances ou points de terminaison backend.

• Le réseau VPC du backend et celui de la règle de transfert doivent être des spokes VPC sur le même hub Network Connectivity Center. Les filtres d'importation et d'exportation doivent permettre la communication entre le sous-réseau proxy réservé du réseau VPC de la règle de transfert et les sous-réseaux utilisés par les instances backend ou les points de terminaison.

• Pour tous les autres types de backends, tous les backends doivent être situés dans le même réseau VPC et la même région.

  Les équilibreurs de charge d'application externes régionaux sont également compatibles avec les environnements VPC partagés dans lesquels vous pouvez partager des réseaux VPC et leurs ressources associées entre des projets. Si vous souhaitez que le service de backend et les backends de l'équilibreur de charge d'application externe régional se trouvent dans un projet différent de celui de la règle de transfert, vous devez configurer l'équilibreur de charge dans un environnement VPC partagé avec référencement de services inter-projets.

Backends et interfaces réseau

Si vous utilisez des backends de groupes d'instances, les paquets sont toujours distribués à nic0. Si vous souhaitez envoyer des paquets à différentes cartes réseau, utilisez plutôt des backends de NEG.

Si vous utilisez des backends de NEG zonaux, les paquets sont envoyés à l'interface réseau représentée par le point de terminaison dans le NEG. Les points de terminaison du NEG doivent se trouver dans le même réseau VPC que le réseau VPC défini explicitement pour le NEG.

Vérifications d'état

Chaque service de backend spécifie une vérification d'état qui vérifie régulièrement que les backends sont disponibles et aptes à recevoir une connexion de l'équilibreur de charge. Cela réduit le risque que des requêtes soient envoyées à des backends ne pouvant pas les traiter. Les vérifications d'état ne vérifient pas si l'application elle-même fonctionne.

Pour les vérifications d'état, vous devez créer une règle de pare-feu autorisant le trafic entrant qui permet aux vérifications d'état d'atteindre vos instances backend. En règle générale, les vérifications d'état proviennent du mécanisme de vérification d'état centralisé de Google.

Les équilibreurs de charge d'application externes régionaux qui utilisent des backends NEG hybrides font exception à cette règle car leurs vérifications d'état proviennent du sous-réseau proxy réservé. Pour plus d'informations, consultez la présentation des NEG hybrides.

Protocole de vérification d'état

Bien que ce ne soit pas obligatoire et pas toujours possible, 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. En revanche, les équilibreurs de charge d'application externes régionaux qui utilisent des backends NEG hybrides ne sont pas compatibles avec les vérifications d'état gRPC. 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 des vérifications d'état compatibles avec les équilibreurs de charge d'application externes dans chaque mode.

Mode d'équilibreur de charge	Type de vérification d'état
Équilibreur de charge d'application externe global	Global
Équilibreur de charge d'application classique	Global
Équilibreur de charge d'application externe régional	Regional (Régional)

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

• Présentation des vérifications d'état
• Créer des vérifications d'état

Règles de pare-feu

L'équilibreur de charge nécessite les règles de pare-feu suivantes :

• Pour les équilibreurs de charge d'application externes globaux, une règle d'autorisation d'entrée permet au trafic provenant des Google Front End (GFE) d'atteindre vos backends. Pour l'équilibreur de charge d'application externe régional, une règle d'autorisation d'entrée autorise le trafic provenant du sous-réseau proxy réservé à atteindre vos backends.
• 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 règles de pare-feu sont implémentées au niveau de l'instance de VM, et non sur les proxys GFE. Vous ne pouvez pas utiliser de règles de pare-feu Google Cloud pour empêcher le trafic d'atteindre l'équilibreur de charge. Pour ce faire, vous pouvez utiliser Google Cloud Armor pour l'équilibreur de charge d'application externe global et l'équilibreur de charge d'application classique.

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.

Le tableau suivant récapitule les plages d'adresses IP sources 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 d'application externe mondial	35.191.0.0/16 130.211.0.0/22 Pour le trafic IPv6 vers les backends : 2600:2d00:1:b029::/64	La source du trafic GFE dépend du type de backend : Groupes d'instances et NEG zonaux (GCE_VM_IP_PORT) : 130.211.0.0/22 35.191.0.0/16 Pour le trafic IPv6 vers les backends : 2600:2d00:1:1::/64 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 d'application classique	35.191.0.0/16 130.211.0.0/22	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) : 35.191.0.0/16 130.211.0.0/22 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 d'application externe régional	35.191.0.0/16 130.211.0.0/22 Pour le trafic IPv6 vers les backends : 2600:2d00:1:b029::/64 L'ajout de plages de vérification de l'état à la liste d'autorisation de Google n'est pas nécessaire pour les NEG hybrides. Toutefois, si vous utilisez à la fois des NEG hybrides et zonaux dans un service de backend, vous devez ajouter les plages de vérification de l'état Google à la liste d'autorisation pour les NEG zonaux.	Le sous-réseau proxy réservé que vous configurez.

Important:Veillez à autoriser les paquets provenant des plages de vérification d'état complètes. Si votre règle de pare-feu n'autorise les paquets qu'à partir d'un sous-ensemble de plages, vous risquez de rencontrer des échecs lors de la vérification d'état, car l'équilibreur de charge ne peut pas communiquer avec vos backends. Cela entraîne des réponses HTTP 502.

Assistance GKE

GKE utilise les équilibreurs de charge d'application externes de différentes manières:

• Les passerelles externes créées à l'aide du contrôleur de passerelle GKE peuvent utiliser n'importe quel mode d'équilibreur de charge d'application externe. Vous pouvez contrôler le mode de l'équilibreur de charge en choisissant une classe GatewayClass. Le contrôleur de passerelle GKE utilise toujours des backends de NEG zonaux GCE_VM_IP_PORT.

• Les entrées externes créées à l'aide du contrôleur d'entrée GKE sont toujours des équilibreurs de charge d'application classiques. Le contrôleur GKE Ingress préfère utiliser des backends de NEG zonaux GCE_VM_IP_PORT, bien que les backends de groupe d'instances soient également compatibles.

• Vous pouvez utiliser un NEG zonal GCE_VM_IP_PORT créé et géré par les services GKE comme backends pour n'importe quel équilibreur de charge d'application ou équilibreur de charge réseau proxy. Pour en savoir plus, consultez la page Équilibrage de charge natif en conteneurs via des NEG zonaux autonomes.

Architecture du VPC partagé

Les équilibreurs de charge d'application externes sont compatibles avec les réseaux qui utilisent un VPC partagé. Un VPC partagé permet à des organisations de connecter des ressources provenant de différents projets à un réseau VPC commun, afin de pouvoir communiquer entre elles de manière sécurisée et efficace à l'aide d'adresses IP internes de ce réseau. Si vous n'êtes pas familiarisé avec le VPC partagé, consultez la présentation du VPC partagé.

Il existe plusieurs façons de configurer un équilibreur de charge d'application externe dans un réseau VPC partagé. Quel que soit le type de déploiement, tous les composants de l'équilibreur de charge doivent appartenir à la même organisation.

Équilibreur de charge	Composants d'interface	Composants backend
Équilibreur de charge d'application externe global	Si vous utilisez un réseau VPC partagé pour vos backends, créez le réseau requis dans le projet hôte de VPC partagé. L'adresse IP externe globale, la règle de transfert, le proxy HTTP(S) cible et le mappage d'URL associé doivent être définis dans le même projet. Ce projet peut être un projet hôte ou un projet de service.	Vous pouvez effectuer l'une des actions suivantes : Créez des services de backend, des buckets backend et des backends (groupes d'instances, NEG sans serveur ou tout autre type de backend compatible) dans le même projet de service que les composants d'interface. Créez des services de backend, des buckets backend et des backends (groupes d'instances, NEG sans serveur ou tout autre type de backend compatible) dans les projets de service. Un seul mappage d'URL peut référencer des services de backend sur différents projets. Ce type de déploiement est appelé référence de services inter-projets. Chaque service de backend doit être défini dans le même projet que les backends auxquels il fait référence. Les vérifications d'état associées aux services de backend doivent aussi être définies dans le même projet que le service de backend. Les backends peuvent faire partie d'un réseau VPC partagé du projet hôte ou d'un réseau VPC autonome, c'est-à-dire d'un réseau VPC non partagé dans le projet de service.
Équilibreur de charge d'application classique	L'adresse IP externe globale, la règle de transfert, le proxy HTTP(S) cible et le mappage d'URL associé doivent être définis dans le même projet hôte ou de service que les backends.	Un service de backend global doit être défini dans le même projet hôte ou de service que les backends (groupes d'instances ou NEG). Les vérifications d'état associées aux services de backend doivent également être définies dans le même projet que le service de backend.
Équilibreur de charge d'application externe régional	Créez le réseau et le sous-réseau proxy réservé requis dans le projet hôte de VPC partagé. L'adresse IP externe régionale, la règle de transfert, le proxy HTTP(S) cible et le mappage d'URL associé doivent être définis dans le même projet. Ce projet peut être un projet hôte ou un projet de service.	Vous pouvez effectuer l'une des actions suivantes : Créer des services de backend et des backends (groupes d'instances, NEG sans serveur ou autres types de backends compatibles) dans le même projet de service que les composants d'interface. Créer des services de backend et des backends (groupes d'instances, NEG sans serveur ou autres types de backends compatibles) dans autant de projets de service que nécessaire. Un seul mappage d'URL peut référencer des services de backend sur différents projets. Ce type de déploiement est appelé référence de services inter-projets. Chaque service de backend doit être défini dans le même projet que les backends auxquels il fait référence. Les vérifications de l'état associées aux services de backend doivent également être définies dans le même projet que le service de backend.

Bien que vous puissiez créer tous les composants et les backends d'équilibrage de charge dans le projet hôte de VPC partagé, ce type de déploiement ne sépare pas les responsabilités d'administration réseau et de développement de services.

Tous les composants et les backends de l'équilibreur de charge dans un projet de service

Le schéma d'architecture suivant illustre un déploiement de VPC partagé standard dans lequel tous les composants et les backends de l'équilibreur de charge se trouvent dans un projet de service. Ce type de déploiement est compatible avec tous les équilibreurs de charge d'application.

Les composants et les backends de l'équilibreur de charge doivent utiliser le même réseau VPC.

Équilibreur de charge d'application externe régional sur un réseau VPC partagé

Backends sans serveur dans un environnement VPC partagé

Pour un équilibreur de charge qui utilise un backend de NEG sans serveur, le service Cloud Run ou Cloud Run Functions de backend doit se trouver dans le même projet que le NEG sans serveur.

En outre, pour l'équilibreur de charge d'application externe régional compatible avec le référencement de services inter-projets, le service de backend, le NEG sans serveur et le service Cloud Run doivent toujours se trouver dans le même projet de service.

Référence de services inter-projets

Le référencement de services inter-projets est un modèle de déploiement dans lequel l'interface et le mappage d'URL de l'équilibreur de charge se trouvent dans un seul projet, tandis que le service de backend et les backends de l'équilibreur de charge se trouvent dans un projet différent.

Le référencement de services inter-projets permet aux entreprises de configurer un équilibreur de charge central et d'acheminer le trafic vers des centaines de services répartis sur plusieurs projets différents. Vous pouvez gérer toutes les règles et stratégies de routage du trafic de manière centralisée dans un mappage d'URL. Vous pouvez également associer l'équilibreur de charge à un seul ensemble de noms d'hôte et de certificats SSL. Par conséquent, vous pouvez optimiser le nombre d'équilibreurs de charge nécessaires au déploiement de votre application et réduire les coûts de gestion, d'exploitation et de quota.

En disposant de projets différents pour chacune de vos équipes fonctionnelles, vous pouvez également assurer la séparation des rôles au sein de votre organisation. Les propriétaires de service peuvent se concentrer sur la création de services dans des projets de service, tandis que les équipes réseau peuvent provisionner et gérer des équilibreurs de charge dans un autre projet, et les deux peuvent être connectées à l'aide du référencement de services inter-projets.

Les propriétaires de services peuvent conserver leur autonomie quant à l'exposition de leurs services et contrôler quels utilisateurs peuvent y accéder à l'aide de l'équilibreur de charge. Ce procédé fait appel à un rôle IAM spécial appelé Rôle "Utilisateur des services d'équilibreur de charge Compute" (roles/compute.loadBalancerServiceUser).

La compatibilité du référencement des services inter-projets diffère selon le type d'équilibreur de charge:

• Pour les équilibreurs de charge d'application externes globaux: l'interface et le mappage d'URL de votre équilibreur de charge peuvent référencer des services de backend ou des buckets backend à partir de n'importe quel projet au sein de la même organisation. Aucune restriction de réseau VPC ne s'applique. Bien que vous puissiez utiliser un environnement VPC partagé pour configurer un déploiement inter-projets comme indiqué dans cet exemple, ce n'est pas obligatoire.

• Pour les équilibreurs de charge d'application externes régionaux: vous devez créer l'équilibreur de charge dans un environnement VPC partagé. L'interface et le mappage d'URL de l'équilibreur de charge doivent se trouver dans un projet hôte ou de service, et les services de backend et les backends de l'équilibreur de charge peuvent être répartis sur plusieurs projets hôtes ou de service dans le même environnement VPC partagé.

Pour savoir comment configurer un VPC partagé pour un équilibreur de charge d'application externe global, avec et sans référencement de services inter-projets, consultez la page Configurer un équilibreur de charge d'application externe global avec un VPC partagé.

Pour savoir comment configurer le VPC partagé pour un équilibreur de charge d'application externe régional, avec et sans référencement de services inter-projets, consultez la page Configurer un équilibreur de charge d'application externe régional avec un VPC partagé.

Remarques sur l'utilisation du référencement de services inter-projets

• La référence de services inter-projets peut être utilisée avec des groupes d'instances, des NEG sans serveur et avec la plupart des autres types de backends compatibles. Toutefois, les restrictions suivantes s'appliquent :

  • Avec les équilibreurs de charge d'application externes globaux, vous ne pouvez pas référencer un service de backend inter-projets si le service de backend dispose de backends de NEG sans serveur avec App Engine.

  • Avec les équilibreurs de charge d'application externes régionaux, vous ne pouvez pas référencer de service de backend inter-projets si le service de backend dispose de backends NEG Internet régionaux.
• Le référencement des services inter-projets n'est pas compatible avec l'équilibreur de charge d'application classique.
• Google Cloud ne fait pas de distinction entre les ressources (par exemple, les services de backend) utilisant le même nom sur plusieurs projets. Par conséquent, lorsque vous utilisez le référencement de services multiprojets, nous vous recommandons d'utiliser des noms de service de backend uniques pour tous les projets de votre organisation.
• Si vous voyez une erreur telle que "Les références inter-projets à cette ressource ne sont pas autorisées", vérifiez que vous êtes autorisé à utiliser la ressource. Un administrateur du projet propriétaire de la ressource doit vous attribuer le rôle d'utilisateur des services d'équilibrage de charge Compute (roles/compute.loadBalancerServiceUser). Ce rôle peut être attribué au niveau du projet ou de la ressource. Pour obtenir un exemple, consultez la section Accorder des autorisations à l'administrateur de l'équilibreur de charge Compute pour qu'il utilise le service de backend ou le bucket backend.

Exemple 1 : interface et backend de l'équilibreur de charge dans des projets de service différents

Voici un exemple de déploiement de VPC partagé dans lequel l'interface et le mappage d'URL de l'équilibreur de charge sont créés dans le projet de service A, et le mappage d'URL fait référence à un service de backend dans le projet de service B.

Dans ce cas, les administrateurs réseau ou les administrateurs d'équilibrage de charge du projet de service A nécessitent un accès aux services de backend du projet de service B. Les administrateurs de projet de service accordent le rôle Utilisateur des services d'équilibreur de charge Compute (roles/compute.loadBalancerServiceUser) aux administrateurs de l'équilibreur de charge du projet de service A qui souhaitent référencer le service de backend dans le projet de service B.

Interface et backend de l'équilibreur de charge dans différents projets de service (cliquez pour agrandir).

Exemple 2 : interface de l'équilibreur de charge dans le projet hôte et backends dans les projets de service

Voici un exemple de déploiement de VPC partagé dans lequel l'interface et le mappage d'URL de l'équilibreur de charge sont créés dans le projet hôte, et les services de backend (et les backends) dans les projets de service.

Dans ce cas, les administrateurs réseau ou les administrateurs d'équilibreur de charge du projet hôte requièrent un accès aux services de backend dans les projets de service. Les administrateurs de projet de service accordent le rôle Utilisateur des services d'équilibreur de charge Compute (roles/compute.loadBalancerServiceUser) aux administrateurs de l'équilibreur de charge du projet hôte A, qui souhaitent référencer le service de backend dans le projet de service.

Interface de l'équilibreur de charge et mappage d'URL dans le projet hôte (cliquez pour agrandir).

Exemple 3: Interface et backends d'équilibreur de charge dans différents projets

Voici un exemple de déploiement dans lequel l'interface et le mappage d'URL de l'équilibreur de charge d'application externe global sont créés dans un projet différent de celui du service de backend et des backends de l'équilibreur de charge. Ce type de déploiement n'utilise pas de VPC partagé et n'est compatible qu'avec les équilibreurs de charge d'application externes globaux.

Interface et backends de l'équilibreur de charge dans différents projets (cliquez pour agrandir).

Fonctionnement des connexions

Connexions à l'équilibreur de charge d'application externe global

Les équilibreurs de charge d'application 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.

Remarque : Pour les NEG Internet, les requêtes de l'équilibreur de charge proviennent de différentes plages d'adresses IP en fonction du type de NEG (global ou régional). Pour en savoir plus, consultez la section Authentifier les requêtes.

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 du message keepalive HTTP client de 610 secondes et un délai avant expiration par défaut du message keepalive du backend de 600 secondes. Vous pouvez mettre à jour le délai avant expiration du message keepalive HTTP client, mais la valeur du délai avant expiration du message keepalive du backend est fixe. Vous pouvez 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.

Pour garantir que le trafic est équilibré de manière égale, l'équilibreur de charge peut fermer correctement une connexion TCP en envoyant un paquet FIN ACK après avoir terminé une réponse incluant un en-tête Connection: close, ou en émettant un encadrement HTTP/2 GOAWAY après avoir terminé une réponse. Ce comportement n'interfère pas avec les requêtes ou réponses actives.

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 des équilibreurs de charge d'application externes du guide "Optimiser la capacité des applications avec l'équilibrage de charge global".

Connexions à l'équilibreur de charge d'application externe régional

L'équilibreur de charge d'application externe régional est un service géré mis en œuvre sur le proxy Envoy. L'équilibreur de charge d'application 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 régionaux basés sur Envoy dans un réseau et une région spécifiques 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 définit à la fois le délai avant expiration du message keepalive HTTP client et le délai avant expiration du message keepalive du backend sur une valeur par défaut de 600 secondes chacun. Vous pouvez mettre à jour le délai avant expiration du message keepalive HTTP client, mais la valeur du délai avant expiration du message keepalive du backend est fixe. Vous pouvez 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.
• Les équilibreurs de charge d'application externes acceptent la réponse HTTP/1.1 100 Continue.

Pour obtenir la liste complète des protocoles compatibles avec les règles de transfert d'équilibreur de charge d'application externe dans chaque mode, consultez la page Fonctionnalités de l'équilibreur de charge.

Adresses IP sources des paquets client

L'adresse IP source des paquets, telle qu'elle est perçue par les backends, n'est pas l'Google Cloud adresse IP externe de l'équilibreur de charge. En d'autres termes, il existe deux connexions TCP :

Pour les équilibreurs de charge d'application 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.

Remarque : Pour les NEG Internet, les requêtes de l'équilibreur de charge proviennent de différentes plages d'adresses IP. Pour en savoir plus, consultez la section Authentifier les requêtes.

Pour les équilibreurs de charge d'application 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.

Chemins de routage spéciaux

Google Cloud utilise des routes spéciales non définies dans votre réseau VPC pour acheminer les paquets destinés aux types de trafic suivants:

• Pour les vérifications d'état, à l'exception des vérifications d'état distribuées Envoy. Pour en savoir plus, consultez la section Chemins d'accès pour les vérifications d'état.

• Entre les GFE et les backends des équilibreurs de charge d'application externes mondiaux et des équilibreurs de charge d'application classiques. Pour en savoir plus, consultez la section Chemins d'accès entre Google Front End et les backends Google.

Google Cloud utilise des routes de sous-réseau pour les sous-réseaux proxy réservés afin d'acheminer les paquets pour les types de trafic suivants:

• En cas d'utilisation de vérifications d'état Envoy distribuées

Pour les équilibreurs de charge d'application externes régionaux, Google Cloud utilise des proxys Envoy Open Source pour mettre fin aux requêtes client 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

Les GFE offrent plusieurs ports ouverts pour les autres services Google exécutés sur la même architecture. Lorsque vous exécutez une analyse de port, d'autres ports ouverts peuvent s'afficher pour d'autres services Google s'exécutant sur des GFE.

Les équilibreurs de charge basés sur GFE (équilibreurs de charge d'application externes globaux et équilibreurs de charge d'application classiques) affichent toujours les ports 80 et 443 comme ouverts (ainsi que tout autre port que vous avez configuré dans les règles de transfert de votre équilibreur de charge). Toutefois, si vous n'avez pas configuré de règle de transfert pour le port 80 ou 443, toutes les connexions envoyées à ces ports sont refusées. À l'inverse, les équilibreurs de charge d'application externes régionaux sont mis en œuvre à l'aide de proxys Envoy et n'affichent pas de ports ouverts supplémentaires lors d'une analyse.

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 n'envoient des paquets SYN-ACK en réponse aux vérifications SYN que pour les ports sur lesquels vous avez configuré une règle de transfert. 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 à une adresse IP ou à un port différents ne sont pas envoyés à vos backends.

  Les GFE mettent en œuvre des fonctionnalités de sécurité telles que Google Cloud Armor. Avec Google Cloud Armor Standard, les GFE offrent une protection permanente contre les attaques DDoS volumétriques et basées sur un protocole, et les inondations SYN. Cette protection est disponible même si vous n'avez pas explicitement configuré Google Cloud Armor. Vous ne serez facturé que si vous configurez des règles de sécurité ou si vous vous inscrivez au niveau Managed Protection Plus.

• 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 d'application externes.

Mode d'équilibreur de charge	terminaison TLS
Équilibreur de charge d'application externe global	Le protocole TLS est interrompu sur un GFE, qui peut se trouver n'importe où dans le monde.
Équilibreur de charge d'application classique	Le protocole TLS est interrompu sur un GFE, qui peut se trouver n'importe où dans le monde.
Équilibreur de charge d'application externe régional	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

Les équilibreurs de charge d'application externes sont compatibles avec les types de délais d'expiration suivants pour le trafic HTTP/HTTPS :

Type de délai d'expiration et description	Valeurs par défaut	Accepte les valeurs de délai avant expiration personnalisées
		Monde	Classique	Régional
Délai avant expiration du service de backend^1 Un délai avant expiration de la requête et de la réponse Représente la durée maximale autorisée entre l'envoi du premier octet d'une requête au backend par l'équilibreur de charge et l'envoi par le backend du dernier octet de la réponse HTTP à l'équilibreur de charge. Si le backend n'a pas renvoyé l'intégralité de la réponse HTTP à l'équilibreur de charge dans ce délai, les données de réponse restantes sont supprimées.	Pour les NEG sans serveur sur un service de backend : 60 minutes Pour tous les autres types de backends sur un service de backend : 30 secondes Pour les buckets backend : 24 heures (86 400 secondes)
Délai avant expiration du message keepalive HTTP du client Durée maximale d'inactivité de la connexion TCP entre un client et le proxy de l'équilibreur de charge. (La même connexion TCP peut être utilisée pour plusieurs requêtes HTTP.) Pour les équilibreurs de charge d'application externes globaux et les équilibreurs de charge d'application classiques, le proxy de l'équilibreur de charge est un GFE de première couche. Pour les équilibreurs de charge d'application externes régionaux, le proxy de l'équilibreur de charge correspond au logiciel Envoy.	Pour un équilibreur de charge d'application externe global et un équilibreur de charge d'application classique : 610 secondes Pour un équilibreur de charge d'application externe régional : 600 secondes
Délai avant expiration du message keepalive HTTP du backend Durée maximale d'inactivité de la connexion TCP entre le proxy de l'équilibreur de charge et un backend. (La même connexion TCP peut être utilisée pour plusieurs requêtes HTTP.) Pour les équilibreurs de charge d'application externes globaux et les équilibreurs de charge d'application classiques, le proxy de l'équilibreur de charge est un GFE de deuxième couche. Pour les équilibreurs de charge d'application externes régionaux, le proxy de l'équilibreur de charge correspond au logiciel Envoy.	Pour les services de backend : 10 minutes (600 secondes) Pour les buckets backend : 6 minutes (360 secondes)
Délai d'inactivité de la session QUIC Durée maximale d'inactivité d'une session QUIC entre le client (en aval) et le GFE d'un équilibreur de charge d'application externe global ou d'un équilibreur de charge d'application classique.	Pour les équilibreurs de charge d'application externes mondiaux et équilibreurs de charge d'application classiques, procédez comme suit : Le délai d'inactivité de la session QUIC correspond au délai d'inactivité minimal du client ou au délai d'inactivité du GFE (300 secondes). Le délai d'inactivité du GFE est fixé à 300 secondes. Le délai d'inactivité du client peut être configuré.

¹Non configurable pour les backends de NEG sans serveur. Non configurable pour les buckets backend.

Délai avant expiration du service de backend

Le délai avant expiration du service backend configurable représente la durée maximale pendant laquelle l'équilibreur de charges attend que de votre backend traite une requête HTTP et renvoie la réponse HTTP correspondante. À l'exception des NEG sans serveur, la valeur par défaut du délai avant expiration du service de backend est de 30 secondes.

Par exemple, si vous souhaitez télécharger un fichier de 500 Mo et que la valeur du délai avant expiration du service de backend est de 90 secondes, l'équilibreur de charge s'attend à ce que le backend fournisse l'intégralité du fichier de 500 Mo dans un délai de 90 secondes. Le délai avant expiration du service de backend peut être configuré de sorte qu'il soit insuffisant pour envoyer une réponse HTTP complète. Dans ce cas, si l'équilibreur de charge a au moins reçu des en-têtes de réponse HTTP du backend, il renvoie les en-têtes de réponse complets et tout ce qu'il a pu tirer du corps de réponse dans le délai avant expiration du service de backend.

Vous devez définir le délai avant expiration du service de backend sur la durée la plus longue attendue par votre backend pour traiter une réponse HTTP. Vous devez augmenter le délai avant expiration du service de backend si le logiciel exécuté sur votre backend a besoin de plus de temps pour traiter une requête HTTP et renvoyer sa réponse complète. Par exemple, vous devez augmenter le délai avant expiration si des réponses HTTP 408 s'affichent avec jsonPayload.statusDetail client_timed_out.

Le délai avant expiration du service de backend accepte des valeurs comprises entre 1 et 2,147,483,647 secondes. Toutefois, des valeurs plus élevées ne sont pas des options de configuration pratiques.Google Cloud ne garantit pas non plus qu'une connexion TCP sous-jacente peut rester ouverte pendant toute la durée du délai avant expiration du service de backend. Dans le cas des équilibreurs de charge d'application globaux et classiques, les GFE imposent un délai avant expiration maximal effectif du service de backend de 86,400 secondes (un jour). Les systèmes clients doivent mettre en œuvre une logique de nouvelle tentative au lieu de dépendre d'une connexion TCP pour rester ouverte pendant de longues périodes.

Pour configurer le délai avant expiration du service de backend, utilisez l'une des méthodes suivantes :

Console

Modifiez le champ Délai avant expiration du service de backend de l'équilibreur de charge.

gcloud

Utilisez la commande gcloud compute backend-services update pour modifier le paramètre --timeout de la ressource du service de backend.

API

Pour un équilibreur de charge d'application externe global ou classique, modifiez le paramètre timeoutSec de la ressource backendServices globale.

Pour un équilibreur de charge d'application externe régional, modifiez le paramètre timeoutSec de la ressource regionBackendServices.

Les délais d'expiration de la connexion WebSocket ne sont pas toujours identiques à ceux du service de backend. Les délais avant expiration de la connexion WebSocket dépendent du type d'équilibreur de charge :

Mode d'équilibreur de charge	Valeurs par défaut	Description du délai d'inactivité pour les Websockets
Équilibreur de charge d'application externe mondial	Délai avant expiration du service de backend : 30 secondes	Les connexions WebSocket actives n'utilisent pas le délai avant expiration du service de backend configuré de l'équilibreur de charge. Les connexions sont automatiquement fermées au bout de 24 heures (86 400 secondes). Cette limite de 24 heures est fixe et remplace le délai avant expiration du service de backend si elle est supérieure à 24 heures. Les connexions WebSocket inactives sont fermées après l'expiration du délai du service de backend. Nous déconseillons de définir des valeurs de délai avant expiration du service de backend supérieures à 24 heures (86 400 secondes), car Google Cloud redémarre périodiquement les GFE pour des mises à jour logicielles et d'autres opérations de maintenance de routine. La valeur du délai avant expiration du service de backend ne retarde pas les activités de maintenance. Plus la valeur du délai avant expiration du service de backend est longue, plus il est probable que Google Cloudinterrompe les connexions TCP à des fins de maintenance.
Équilibreur de charge d'application classique	Délai avant expiration du service de backend : 30 secondes	Les connexions WebSocket, qu'elles soient inactives ou actives, se ferment automatiquement après l'expiration du délai du service de backend. Nous déconseillons de définir des valeurs de délai avant expiration du service de backend supérieures à 24 heures (86 400 secondes), car Google Cloud redémarre périodiquement les GFE pour des mises à jour logicielles et d'autres opérations de maintenance de routine. La valeur du délai avant expiration du service de backend ne retarde pas les activités de maintenance. Plus la valeur du délai avant expiration du service de backend est longue, plus il est probable que Google Cloudinterrompe les connexions TCP à des fins de maintenance.
Équilibreur de charge d'application externe régional	Délai avant expiration du service de backend : 30 secondes	Les connexions WebSocket actives n'utilisent pas le délai avant expiration du service de backend de l'équilibreur de charge. Les connexions WebSocket inactives sont fermées après l'expiration du délai du service de backend. Google Cloud redémarre périodiquement le nombre de tâches logicielles Envoy de diffusion ou en modifie le nombre. Plus la valeur du délai avant expiration du service de backend est longue, plus il est probable que les tâches Envoy redémarrent ou interrompent les connexions TCP.

Les équilibreurs de charge d'application externes régionaux utilisent le paramètre routeActions.timeout configuré du mappage d'URL et ignore le délai avant expiration du service de backend. Lorsque routeActions.timeout n'est pas configuré, la valeur du délai avant expiration du service de backend est utilisée. Lorsque routeActions.timeout est fourni, le délai avant expiration du service de backend est ignoré et la valeur de routeActions.timeout est utilisée comme délai avant expiration de la requête et de la réponse.

Délai d'expiration du message keepalive HTTP client

Le délai d'expiration du message keepalive HTTP client représente la durée maximale pendant laquelle une connexion TCP peut être inactive entre le client en aval et l'un des types de proxys suivants :

• Pour un équilibreur de charge d'application externe global ou un équilibreur de charge d'application classique : un Google Front End de première couche

• Pour un équilibreur de charge d'application externe régional : un proxy Envoy

Un délai d'expiration du message keepalive HTTP représente le délai d'inactivité TCP pour les connexions TCP sous-jacentes. Le délai avant expiration du message keepalive HTTP du client ne s'applique pas aux websockets.

• Pour un équilibreur de charge d'application externe global, la valeur par défaut est de 610 secondes. Vous pouvez configurer le délai d'expiration HTTP du client avec une valeur comprise entre 5 et 1 200 secondes.
• Pour un équilibreur de charge d'application classique, le délai avant expiration du message keepalive HTTP client est fixé à 610 secondes.
• Pour un équilibreur de charge d'application externe régional, la valeur par défaut est de 600 secondes. Vous pouvez configurer le délai avant expiration du message keepalive HTTP du client sur une valeur comprise entre 5 et 600 secondes.

Pour configurer le paramètre de délai d'expiration du message keepalive, utilisez l'une des méthodes suivantes :

Console

Modifiez le champ Délai avant expiration du message keepalive HTTP dans la configuration de l'interface de l'équilibreur de charge.

gcloud

Utilisez les commandes gcloud compute target-http-proxies update ou gcloud compute target-https-proxies update pour modifier le paramètre --http-keep-alive-timeout-sec du proxy HTTP cible ou la ressource de proxy HTTPS cible.

Remarque :

Pour un équilibreur de charge d'application externe régional, vous ne pouvez pas mettre directement à jour le paramètre de délai avant expiration du message keepalive d'un proxy HTTP(S) cible régional. Pour mettre à jour le paramètre de délai avant expiration du message keepalive d'un proxy cible régional, procédez comme suit:

1. Créez un proxy cible avec les paramètres de délai avant expiration prévus.
2. Dupliquer tous les autres paramètres du proxy cible actuel sur le nouveau. Pour les proxys HTTPS cibles, cela inclut l'association de certificats SSL ou de mappages de certificats au nouveau proxy cible.
3. Mettez à jour les règles de transfert pour qu'elles pointent vers le nouveau proxy cible.
4. Supprimez l'ancien proxy cible.

API

Modifiez le paramètre httpKeepAliveTimeoutSec de la ressource targetHttpProxies ou de la ressource targetHttpsProxies.

Remarque :

Pour un équilibreur de charge d'application externe régional, vous ne pouvez pas mettre directement à jour le paramètre de délai avant expiration du message keepalive d'un proxy HTTP(S) cible régional. Pour mettre à jour le paramètre de délai avant expiration du message keepalive d'un proxy cible régional, procédez comme suit:

1. Créez un proxy cible avec les paramètres de délai avant expiration prévus.
2. Dupliquer tous les autres paramètres du proxy cible actuel sur le nouveau. Pour les proxys HTTPS cibles, cela inclut l'association de certificats SSL ou de mappages de certificats au nouveau proxy cible.
3. Mettez à jour les règles de transfert pour qu'elles pointent vers le nouveau proxy cible.
4. Supprimez l'ancien proxy cible.

Le délai d'expiration du message keepalive HTTP client de l'équilibreur de charge doit être supérieur au délai d'expiration du message keepalive HTTP (TCP inactif) utilisé par les clients ou les proxys en aval. Si un client en aval possède un délai avant expiration du message keepalive HTTP (TCP inactif) supérieur à celui de l'équilibreur de charge, il est possible qu'une condition de concurrence se produise. Du point de vue d'un client en aval, une connexion TCP établie est autorisée à être inactive plus longtemps que l'équilibreur de charge ne le permet. Cela signifie que le client en aval peut envoyer des paquets après que l'équilibreur de charge considère la connexion TCP comme fermée. Dans ce cas, l'équilibreur de charge répond par un paquet de réinitialisation TCP (RST).

Lorsque le délai avant expiration du message keepalive HTTP du client expire, le GFE ou le proxy Envoy envoie un message TCP FIN au client pour fermer la connexion en douceur.

Délai avant expiration du message keepalive HTTP du backend

Les équilibreurs de charge d'application externes sont des proxys qui utilisent au moins deux connexions TCP :

• Pour un équilibreur de charge d'application externe global ou un équilibreur de charge d'application classique, une première connexion TCP existe entre le client (en aval) et un GFE de première couche. Les GFE de première couche se connectent aux GFE de deuxième couche, puis les GFE de deuxième couche ouvrent une deuxième connexion TCP à vos backends.

• Pour un équilibreur de charge d'application externe régional, une première connexion TCP existe entre le client (en aval) et un proxy Envoy. Le proxy Envoy ouvre ensuite une deuxième connexion TCP à vos backends.

les connexions TCP secondaires de l'équilibreur de charge peuvent ne pas être fermées après chaque requête ; elles peuvent rester ouvertes pour gérer plusieurs requêtes et réponses HTTP. Le délai avant expiration du message keepalive HTTP du backend définit le délai d'inactivité TCP entre l'équilibreur de charge et vos backends. Le délai avant expiration du message keepalive HTTP du backend ne s'applique pas aux websockets.

Le délai avant expiration du message keepalive du backend est fixé à 10 minutes (600 secondes) et ne peut pas être modifié. Cela garantit que l'équilibreur de charge conserve des connexions inactives pendant au moins 10 minutes. Passé ce délai, l'équilibreur de charge peut envoyer des paquets d'arrêt au backend à tout moment.

Le délai avant expiration du message keepalive du backend de l'équilibreur de charge doit être inférieur à celui utilisé par les logiciels exécutés sur vos backends. Cela permet d'éviter une condition de concurrence où le système d'exploitation de vos backends risque de fermer les connexions TCP avec une réinitialisation TCP (RST). Étant donné que le délai avant expiration du message keepalive du backend pour l'équilibreur de charge n'est pas configurable, vous devez configurer votre logiciel backend de sorte que sa valeur du délai avant expiration du message keepalive HTTP (TCP inactif) soit supérieure à 600 secondes.

Lorsque le délai avant expiration du message keepalive HTTP du backend arrive à expiration , le GFE ou le proxy Envoy envoie un indicateur TCP FIN à la VM backend pour fermer correctement la connexion.

Le tableau suivant répertorie les modifications à effectuer pour modifier les valeurs du délai d'expiration du message keepalive pour les logiciels de serveur Web courants.

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

Délai d'inactivité de la session QUIC

Le délai d'inactivité de la session QUIC représente la durée maximale d'inactivité d'une session QUIC entre le client et le GFE d'un équilibreur de charge d'application externe global ou d'un équilibreur de charge d'application classique.

La valeur du délai d'inactivité de la session QUIC est définie comme la valeur minimale du délai d'inactivité du client ou du délai d'inactivité du GFE (300 secondes). Le délai d'inactivité du GFE est fixé à 300 secondes. Le délai d'inactivité du client peut être configuré.

Tentatives

La compatibilité de la logique de nouvelle tentative dépend du mode de l'équilibreur de charge d'application externe.

Mode d'équilibreur de charge	Logique de nouvelle tentative
Équilibreur de charge d'application externe global	Configurable à l'aide d'une stratégie de nouvelle tentative dans le mappage d'URL. Le nombre de 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. La valeur perTryTimeout configurable maximale est de 24 heures. Sans stratégie de nouvelle tentative, les requêtes infructueuses sans corps HTTP (par exemple, des requêtes GET) qui aboutissent à des réponses HTTP 502, 503 ou 504 (retryConditions=["gateway-error"]) sont relancées une fois. Les requêtes HTTP POST ne font pas l'objet d'une nouvelle tentative. 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.
Équilibreur de charge d'application 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. L'équilibreur de charge relance une requête GET ayant échoué si la première requête a échoué avant de recevoir les en-têtes de réponse de l'instance backend. 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 section Journalisation et surveillance de l'équilibreur de charge d'application externe. Les requêtes infructueuses aboutissent à la synthèse d'une réponse HTTP 502
Équilibreur de charge d'application externe régional	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. La valeur perTryTimeout configurable maximale est de 24 heures. Sans stratégie de nouvelle tentative, les requêtes infructueuses sans corps HTTP (par exemple, des requêtes GET) qui aboutissent à des réponses HTTP 502, 503 ou 504 sont relancées. une fois. Les requêtes HTTP POST ne font pas l'objet d'une nouvelle tentative. 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.

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.

Gestion des requêtes

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

• La taille totale des en-têtes et de l'URL de la requête dépasse la taille d'en-tête de requête maximale autorisée pour les équilibreurs de charge d'application externes.
• La requête présente un corps bien que la méthode de la requête l'interdise.
• La requête contient un en-tête Upgrade et cet en-tête Upgrade n'est pas utilisé pour activer les connexions WebSocket.
• La version de HTTP est inconnue.

Gestion des réponses

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 les équilibreurs de charge d'application externes.
• La version de HTTP est inconnue.

Lors du traitement de la requête et de la réponse, l'équilibreur de charge peut supprimer ou écraser les en-têtes saut par saut dans HTTP/1.1 avant de les transférer vers la destination prévue.

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. Les équilibreurs de charge d'application externes sont compatibles avec 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 d'application externe mondial

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, Google Cloud l'équilibrage de charge tente d'optimiser la sélection de l'instance backend pour chaque requête.

Pour l'équilibreur de charge d'application externe global, l'équilibrage de charge est réparti sur deux niveaux. Le mode d'équilibrage détermine la pondération/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 d'équilibrage de charge de la zone (documentation de l'API du service de backend).

Pour l'équilibreur de charge d'application 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.

Distribution des requêtes

Les équilibreurs de charge d'application externes basés sur GFE utilisent le processus suivant pour répartir les requêtes entrantes :

1. Du client au GFE de première couche. Les routeurs de périphérie annoncent l'adresse IP externe de la règle de transfert à la périphérie du réseau de Google. Chaque annonce répertorie un prochain saut vers un système d'équilibrage de charge de couche 3/4 (Maglev). Les systèmes Maglev acheminent le trafic vers un GFE (Google Front End) de première couche.
   • Lorsque vous utilisez le niveau Premium, Google annonce l'adresse IP de votre équilibreur de charge à partir de tous les points of presence dans le monde. Toutes les adresses IP de l'équilibreur de charge sont anycast mondiales.
   • Lorsque vous utilisez le niveau Standard, Google annonce l'adresse IP de votre équilibreur de charge à partir des points of presence associés à la région de la règle de transfert. L'équilibreur de charge utilise une adresse IP externe régionale. L'utilisation d'une règle de transfert de niveau Standard vous limite à un groupe d'instances et à des backends de NEG zonaux dans la même région que la règle de transfert de l'équilibreur de charge.
2. Du GFE de première couche au GFE de deuxième 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 :
   • Les GFE de première couche analysent le mappage d'URL et sélectionnent un service de backend ou un bucket backend.
   • Pour les services de backend dotés de NEG Internet, les GFE de première couche sélectionnent une passerelle de transfert externe de deuxième couche colocalisée avec le GFE de première couche. La passerelle de transfert envoie des requêtes au point de terminaison du NEG Internet. Ainsi s'achève le processus de répartition des requêtes pour les NEG Internet.
   • Pour les services de backend avec des NEG sans serveur et des NEG Private Service Connect (PSC), et des buckets backend dans une seule région, les GFE de première couche sélectionnent un GFE de deuxième couche dans la région correspondant à la région du NEG ou du bucket. Pour les buckets Cloud Storage multirégionaux, les GFE de première couche sélectionnent les GFE de deuxième couche soit dans la région du bucket, soit dans une région aussi proche que possible du bucket multirégional (défini par le délai aller-retour du réseau).
   • Pour les services de backend dotés de groupes d'instances, de NEG zonaux avec des points de terminaison GCE_VM_IP_PORT et de NEG hybrides, le système de gestion de la capacité de Google informe les GFE de première couche de la capacité utilisée et configurée pour chaque backend. La capacité configurée pour un backend est définie par le mode d'équilibrage, la capacité cible du mode d'équilibrage et le scaler de capacité.
     • Niveau Standard : Les GFE de première couche sélectionnent un GFE de deuxième couche dans la région contenant les backends.
     • Niveau Premium : les GFE de première couche sélectionnent des GFE de deuxième couche dans un ensemble de régions applicables. Les régions applicables correspondent à toutes les régions dans lesquelles les backends ont été configurés, à l'exception de celles comportant des backends configurés sans capacité. Les GFE de première couche sélectionnent les GFE de deuxième couche les plus proches dans une région applicable (définis par le délai aller-retour du réseau). Si les backends sont configurés dans au moins deux régions, les GFE de première couche peuvent transférer des requêtes vers d'autres régions applicables si une région de premier choix est saturée. Le basculement vers d'autres régions est possible lorsque tous les backends de la région de premier choix sont saturés.
3. Les GFE de deuxième couche sélectionnent des backends. Les GFE de deuxième couche sont situés dans des zones d'une région. Ils sélectionnent un backend en suivant le processus suivant :
   • Pour les services de backend dotés de NEG sans serveur, de NEG Private Service Connect et de buckets backend, les GFE de deuxième couche transfèrent les requêtes vers les systèmes de production de Google. Ainsi s'achève le processus de répartition des requêtes pour ces backends.

   • Pour les services de backend dotés de groupes d'instances, de NEG zonaux avec des points de terminaison GCE_VM_IP_PORT et de NEG hybrides, les systèmes de vérification d'état de Google informent les GFE de deuxième couche de l'état de la vérification d'état des instances backend ou des points de terminaison.

     Niveau Premium uniquement : Si le GFE de deuxième couche ne possède pas d'instances backend ni de points de terminaison opérationnels dans sa région, il peut envoyer des requêtes à un autre GFE de deuxième couche dans une autre région applicable avec des backends configurés. Le basculement entre les GFE de deuxième couche dans différentes régions n'épuise pas toutes les combinaisons de région à région possibles. Si vous devez détourner le trafic des backends d'une région particulière, au lieu de configurer les backends pour qu'ils échouent aux vérifications d'état, vous devez définir le scaler de capacité du backend sur zéro afin que le GFE de première couche exclut la région à l'étape précédente.

   Le GFE de deuxième couche achemine ensuite les requêtes vers des instances backend ou des points de terminaison dans des zones de sa région, comme indiqué à l'étape suivante.

4. Le GFE de deuxième couche sélectionne une zone. Par défaut, les GFE de deuxième couche utilisent l'algorithme WATERFALL_BY_REGION, dans lequel chaque GFE de deuxième couche privilégie la sélection d'instances backend ou de points de terminaison dans la zone contenant le GFE de deuxième couche. Comme WATERFALL_BY_REGION minimise le trafic entre les zones, à des taux de requêtes faibles, chaque GFE de deuxième couche peut envoyer exclusivement des requêtes aux backends situés dans la zone du GFE de deuxième couche.

   Pour les équilibreurs de charge d'application externes globaux uniquement, les GFE de deuxième couche peuvent être configurés pour utiliser l'un des algorithmes alternatifs suivants à l'aide d'une règle serviceLbPolicy :

   • SPRAY_TO_REGION : les GFE de deuxième couche ne privilégient pas la sélection d'instances backend ou de points de terminaison dans la même zone que le GFE de deuxième couche. Les GFE de deuxième couche tentent de répartir le trafic vers l'ensemble des instances backend ou des points de terminaison de toutes les zones de la région. Cela peut entraîner une répartition plus équitable de la charge au détriment de la hausse du trafic entre les zones.
   • WATERFALL_BY_ZONE : les GFE de deuxième couche préfèrent fortement sélectionner des instances backend ou des points de terminaison dans la même zone que le GFE de deuxième couche. Les GFE de deuxième couche n'acheminent les requêtes vers les backends de différentes zones qu'une fois que tous les backends de la zone actuelle ont atteint leurs capacités configurées.
5. Le GFE de deuxième couche sélectionne des instances ou des points de terminaison dans la zone. Par défaut, un GFE de deuxième couche répartit les requêtes entre les backends à tour de rôle. Pour les équilibreurs de charge d'application externes globaux uniquement, vous pouvez modifier ce comportement à l'aide d'une règle d'équilibrage de charge de localité (localityLbPolicy). Celle-ci ne s'applique qu'aux backends de la zone sélectionnée décrite à l'étape précédente.

Équilibreur de charge d'application externe régional

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

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 :

• Modes d'équilibrage
• Règle d'équilibrage de charge de la localité (documentation de l'API sur le service de backend régional)

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

Les équilibreurs de charge d'application externes offrent les types d'affinité de session suivants :

• NONE. L'affinité de session n'est pas définie pour l'équilibreur de charge.
• Affinité basée sur les adresses IP client
• Affinité basée sur les cookies générés
• Affinité basée sur le champ d'en-tête
• Affinité basée sur les cookies HTTP
• Affinité de session basée sur les cookies avec état

Le tableau suivant récapitule les options d'affinité de session compatibles avec les équilibreurs de charge d'application externes:

Mode d'équilibreur de charge	Options d'affinité de session
	Aucun	IP client	Cookie généré	Champ d'en-tête	Cookie HTTP	Cookie avec état
Équilibreur de charge d'application externe global
Équilibreur de charge d'application classique
Équilibreur de charge d'application externe régional

Haute disponibilité et basculement

La haute disponibilité et le basculement dans les équilibreurs de charge d'application externes peuvent être configurés au niveau de l'équilibreur de charge. Pour gérer cette situation, créez des équilibreurs de charge d'application externes régionaux de sauvegarde dans toute région où une sauvegarde est nécessaire.

Le tableau suivant décrit le comportement du basculement.

Mode d'équilibreur de charge	Méthodes de basculement
Équilibreur de charge d'application externe global, Équilibreur de charge d'application classique	Vous pouvez opter pour une configuration de basculement actif-passif dans laquelle le trafic bascule vers un équilibreur de charge d'application externe régional de sauvegarde. Vous utilisez les vérifications de l'état pour détecter les pannes et les règles de routage Cloud DNS pour acheminer le trafic lorsque le basculement est déclenché.
Équilibreur de charge d'application externe régional	Utilisez l'une des méthodes suivantes pour garantir un déploiement à haute disponibilité : Vous pouvez opter pour une configuration de basculement actif-passif dans laquelle le trafic bascule vers un équilibreur de charge d'application externe régional de sauvegarde. Vous utilisez des vérifications d'état pour détecter les pannes et une règle de routage avec basculement Cloud DNS pour acheminer le trafic lorsque le basculement est déclenché par l'échec des vérifications d'état. Pour en savoir plus, consultez la section Basculement pour les équilibreurs de charge d'application externes. Vous pouvez configurer une configuration de basculement actif-actif dans laquelle vous déployez plusieurs équilibreurs de charge d'application externes régionaux individuels dans les régions qui, selon vous, prennent le mieux en charge le trafic de votre application. Utilisez une règle de routage de géolocalisation Cloud DNS pour acheminer le trafic vers la région appropriée en fonction de l'origine de la requête client. Vous pouvez également utiliser les vérifications de l'état pour détecter les pannes et acheminer le trafic uniquement vers les équilibreurs de charge opérationnels. Pour en savoir plus, consultez la section Haute disponibilité pour les équilibreurs de charge d'application externes régionaux.

Compatibilité HTTP/2

HTTP/2 est une révision majeure du protocole HTTP/1. Il existe deux modes de compatibilité avec HTTP/2:

• HTTP/2 sur TLS
• HTTP/2 en texte clair via TCP

HTTP/2 sur TLS

Le protocole HTTP/2 sur TLS est compatible avec les connexions entre les clients et l'équilibreur de charge d'application externe, ainsi que pour les connexions entre l'équilibreur de charge et ses backends.

L'équilibreur de charge négocie automatiquement le protocole HTTP/2 avec les clients dans le cadre du handshake TLS à l'aide de l'extension TLS ALPN. Même si un équilibreur de charge est configuré pour utiliser HTTPS, les clients modernes utilisent HTTP/2 par défaut. Ce paramètre est contrôlé côté client, et non au niveau de l'équilibreur de charge.

Si un client n'est pas compatible avec le protocole HTTP/2 et que l'équilibreur de charge est configuré pour utiliser HTTP/2 entre l'équilibreur de charge et les instances backend, l'équilibreur de charge peut toujours négocier une connexion HTTPS ou accepter des requêtes HTTP non sécurisées. Ces requêtes HTTPS ou HTTP sont ensuite transformées par l'équilibreur de charge pour transmettre les requêtes par proxy via HTTP/2 aux instances backend.

Pour utiliser HTTP/2 sur TLS, vous devez activer TLS sur vos backends et définir le protocole de service de backend sur HTTP2. Pour en savoir plus, consultez la section Chiffrement entre l'équilibreur de charge et les backends.

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 chargeGoogle Cloud n'a en fait aucun sens, 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 avec HTTP/2. Vous risquez par conséquent de constater des latences de backend élevées, car les connexions backend sont établies plus fréquemment.
• 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 de requêtes ne sont pas visibles dans l'APIGoogle Cloud ni dans la console Google Cloud. 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 200 OK.

HTTP/2 en texte clair via TCP (H2C)

Le protocole HTTP/2 en texte clair sur TCP, également appelé H2C, vous permet d'utiliser HTTP/2 sans TLS. H2C est compatible avec les deux connexions suivantes:

• Connexions entre les clients et l'équilibreur de charge Aucune configuration spéciale n'est requise.

• Connexions entre l'équilibreur de charge et ses backends Cette fonctionnalité est disponible en version preview.

  Pour configurer la fonctionnalité H2C pour les connexions entre l'équilibreur de charge et ses backends, vous devez définir le protocole de service de backend sur H2C.

H2C n'est pas compatible avec les équilibreurs de charge d'application classiques.

Compatibilité HTTP/3

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

La compatibilité de Google QUIC (également appelé gQUIC) a été supprimée en avril 2023 au profit de HTTP/3 par rapport à IETF QUIC, qui est une norme IETF et s'est révélé plus performant que gQUIC.

Plus précisément :

• IETF QUIC est un protocole de couche de transport qui offre un contrôle de congestion et une fiabilité semblables à TCP, qui utilise TLS 1.3 pour une sécurité optimale, et qui fournit des performances améliorées.
• HTTP/3 est une couche d'application basée sur IETF QUIC qui s'appuie sur QUIC pour gérer le multiplexage, le contrôle de congestion, la détection de perte et la retransmission.
• 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 accepte 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 l'algorithme de contrôle de congestion BBR.

L'utilisation 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 les équilibreurs de charge d'application externes dans chaque mode.

Mode d'équilibreur de charge	Compatibilité HTTP/3
Équilibreur de charge d'application externe global (toujours au niveau Premium)
Équilibreur de charge d'application classique au niveau Premium
Équilibreur de charge d'application classique au niveau Standard
Équilibreur de charge d'application externe régional (niveau Premium ou Standard)

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 HTTP/3.
• 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 HTTP/3 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 activé, 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"

Remarque : L'en-tête Alt-Svc annonce plusieurs versions de HTTP/3 afin de prendre en charge les brouillons précédents utilisés par certains clients (par exemple h3-29).

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 HTTP/3 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 HTTP/3. En voici quelques-unes :

• 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 de HTTP/3.
• 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, 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.

Configurer le protocole HTTP/3

Les valeurs NONE (par défaut) et ENABLE activent toutes deux la compatibilité HTTP/3 pour votre équilibreur de charge.

Lorsque le protocole HTTP/3 est activé, l'équilibreur de charge l'annonce aux clients. Ainsi, les clients compatibles peuvent négocier une version HTTP/3 avec l'équilibreur de charge. Les clients qui ne sont pas compatibles avec HTTP/3 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 implémentations clientes défectueuses.

Les équilibreurs de charge d'application externes proposent trois méthodes de configuration du protocole HTTP/3, comme indiqué dans le tableau suivant.

Valeur quicOverride	Comportement
NONE	La compatibilité du protocole HTTP/3 est annoncée aux clients.
ENABLE	La compatibilité du protocole HTTP/3 est annoncée aux clients.
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

Remarque : La définition de la négociation HTTP/3 n'est actuellement pas possible sur la page des proxys cibles et doit être configurée en modifiant la configuration de l'équilibreur de charge.

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

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

1. Sélectionnez l'équilibreur de charge que vous souhaitez modifier.
2. Cliquez sur Frontend configuration (Configuration du frontend).
3. Sélectionnez l'adresse IP et le port de l'interface que vous souhaitez modifier. Pour modifier une configuration HTTP/3, le protocole doit être HTTPS.

Activer le protocole HTTP/3

1. Sélectionnez le menu 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 le menu 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 l'annonce du protocole HTTP/3.

  Lorsque vous sélectionnez NONE, HTTP/3 est annoncé aux clients, mais pas Google QUIC. Dans la console Google Cloud, cette option est appelée Automatique (par défaut).

• ENABLE : annonce le protocole HTTP/3 aux clients.

• DISABLE : n'annonce pas le protocole HTTP/3 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 l'annonce du protocole HTTP/3.

  Lorsque vous sélectionnez NONE, HTTP/3 est annoncé aux clients, mais pas Google QUIC. Dans la console Google Cloud, cette option est appelée Automatique (par défaut).

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

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

Assistance WebSocket

Google Cloud Les équilibreurs de charge HTTP(S) sont compatibles avec le protocole WebSocket lorsque vous utilisez HTTP ou HTTPS comme 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 full-duplex entre les clients et l'équilibreur de charge. Pour plus d'informations, consultez la norme RFC 6455.

Le protocole WebSocket fonctionne comme suit :

1. L'équilibreur de charge reconnaît une requête WebSocket Upgrade d'un client HTTP(S). La requête contient les en-têtes Connection: Upgrade et Upgrade: websocket, suivis d'autres en-têtes de requête liés au WebSocket.
2. Le backend envoie une réponse WebSocket Upgrade. L'instance backend envoie une réponse 101 switching protocol avec des en-têtes Connection: Upgrade, Upgrade: websocket et d'autres en-têtes de réponse liés au WebSocket.
3. L'équilibreur de charge établit un trafic bidirectionnel par proxy pendant la durée de la connexion actuelle.

Si l'instance backend renvoie une réponse d'erreur avec le code de réponse 426 ou 502, l'équilibreur de charge ferme la connexion.

Les délais avant expiration des connexions WebSocket dépendent du type d'équilibreur de charge (mondial, régional ou classique). Pour en savoir plus, consultez la section Délai avant expiration du service de backend.

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

Compatibilité avec gRPC

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 Google Cloud applications, vous devez transmettre les requêtes par proxy de bout en bout via HTTP/2. Pour ce faire, vous devez créer un équilibreur de charge d'application avec l'une des configurations suivantes:

• Pour le trafic non chiffré de bout en bout (sans TLS): créez un équilibreur de charge HTTP (configuré avec un proxy HTTP cible). En outre, vous configurez l'équilibreur de charge afin qu'il utilise le protocole HTTP/2 pour les connexions non chiffrées entre l'équilibreur de charge et ses backends en définissant le protocole du service de backend sur H2C (cette fonctionnalité est disponible en version preview).

• Pour le trafic chiffré de bout en bout (avec TLS): créez un équilibreur de charge HTTPS (configuré avec un proxy HTTPS cible et un certificat SSL). 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.

  En outre, vous devez vous assurer que les backends peuvent gérer le trafic TLS et configurer l'équilibreur de charge pour qu'il utilise HTTP/2 pour les connexions chiffrées entre l'équilibreur de charge et ses backends en définissant le protocole de service de backend sur HTTP2.

  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 transmettre les requêtes par proxy aux instances backend via HTTP/2.

Si vous souhaitez configurer un équilibreur de charge d'application 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 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.

Compatibilité avec TLS

Par défaut, lorsqu'il interrompt les requêtes SSL des clients, un proxy HTTPS cible n'accepte que les protocoles TLS 1.0, 1.1, 1.2 et 1.3.

Lorsque l'équilibreur de charge utilise HTTPS comme protocole de service de backend, il peut négocier TLS 1.0, 1.1, 1.2 ou 1.3 avec le backend.

Compatibilité avec TLS mutuel

Le protocole TLS mutuel (ou mTLS) est un protocole standard dans l'industrie d'authentification mutuelle entre un client et un serveur. Il garantit que le client et le serveur s'authentifient mutuellement en vérifiant qu'ils détiennent chacun un certificat valide émis par une autorité de certification de confiance. Contrairement au protocole TLS standard, où seul le serveur est authentifié, mTLS exige que le client et le serveur présentent des certificats, ce qui confirme l'identité des deux parties avant que la communication ne soit établie.

Tous les équilibreurs de charge d'application sont compatibles avec mTLS. Avec mTLS, l'équilibreur de charge demande au client d'envoyer un certificat pour s'authentifier lors du handshake TLS avec l'équilibreur de charge. Vous pouvez configurer un magasin de confiance du Gestionnaire de certificats que l'équilibreur de charge utilisera ensuite pour valider la chaîne de confiance du certificat client.

Pour en savoir plus sur mTLS, consultez la page Authentification TLS mutuelle.

Prise en charge anticipée des données TLS 1.3

Remarque :Les données précoces TLS 1.3 ou le DAR 0-RTT ne sont compatibles qu'avec la reprise de sessions précédentes entre les clients et Cloud CDN ou l'équilibreur de charge. Cloud CDN ou l'équilibreur de charge ne peuvent pas utiliser les données précoces TLS lors du transfert de requêtes aux serveurs d'origine.

Les données précoces TLS 1.3 sont prises en charge sur le proxy HTTPS cible des équilibreurs de charge d'application externes suivants pour HTTPS sur TCP (HTTP/1.1, HTTP/2) et HTTP/3 via QUIC:

• Équilibreurs de charge d'application externes globaux
• Équilibreurs de charge d'application classiques

Le protocole TLS 1.3 a été défini dans la RFC 8446 et introduit le concept de données précoces, également appelées données sans délai aller-retour (0-RTT), qui peuvent améliorer les performances des applications pour les connexions réactivées de 30 à 50%.

Avec TLS 1.2, deux allers-retours sont nécessaires pour que les données puissent être transmises de manière sécurisée. TLS 1.3 réduit cette valeur à un aller-retour (1-DAR) pour les nouvelles connexions, ce qui permet aux clients d'envoyer des données d'application immédiatement après la première réponse du serveur. De plus, TLS 1.3 introduit le concept de données précoces pour les sessions reprises, ce qui permet aux clients d'envoyer des données d'application avec le ClientHello initial, ce qui réduit le temps d'arrondi effectif à zéro (0-DAR). Les données précoces TLS 1.3 permettent au serveur backend de commencer à traiter les données client avant la fin du processus de handshake avec le client, ce qui réduit la latence. Toutefois, il faut veiller à limiter les risques de relecture.

Étant donné que les premières données sont envoyées avant la fin du handshake, un pirate informatique peut tenter de capturer et de relire les requêtes. Pour atténuer ce problème, le serveur backend doit contrôler soigneusement l'utilisation précoce des données, en limitant son utilisation aux requêtes idempotentes. Les méthodes HTTP destinées à être idempotentes, mais pouvant déclencher des modifications non idempotentes, telles qu'une requête GET modifiant une base de données, ne doivent pas accepter les données précoces. Dans ce cas, le serveur backend doit rejeter les requêtes comportant l'en-tête HTTP Early-Data: 1 en renvoyant un code d'état HTTP 425 Too Early.

L'en-tête HTTP Early-Data des requêtes comportant des données précoces est défini sur la valeur 1, ce qui indique au serveur backend que la requête a été transmise dans les données précoces TLS. Elle indique également que le client comprend le code d'état HTTP 425 Too Early.

Modes des données précoces TLS (0-RTT)

Vous pouvez configurer les données précoces TLS à l'aide de l'un des modes suivants sur la ressource proxy HTTPS cible de l'équilibreur de charge.

• STRICT. Cela active les données précoces TLS 1.3 pour les requêtes utilisant des méthodes HTTP sécurisées (GET, HEAD, OPTIONS, TRACE) et les requêtes HTTP sans paramètres de requête. Les requêtes qui envoient des données précoces contenant des méthodes HTTP non idempotentes (telles que POST ou PUT) ou avec des paramètres de requête sont rejetées avec un code d'état HTTP 425.

• PERMISSIVE. Cela active les données précoces de TLS 1.3 pour les requêtes avec des méthodes HTTP sécurisées (GET, HEAD, OPTIONS, TRACE). Ce mode ne refuse pas les requêtes qui incluent des paramètres de requête. Le propriétaire de l'application doit s'assurer que les premières données peuvent être utilisées en toute sécurité pour chaque chemin de requête, en particulier pour les points de terminaison où la relecture des requêtes peut entraîner des effets secondaires inattendus, tels que la journalisation ou les mises à jour de base de données déclenchées par des requêtes GET.

• DISABLED. Les données précoces TLS 1.3 ne sont pas annoncées et toute tentative (non valide) d'envoi de données précoces est rejetée. Si vos applications ne sont pas en mesure de traiter les requêtes de données précoces en toute sécurité, vous devez désactiver les données précoces. Les données précoces TLS 1.3 sont désactivées par défaut.

• UNRESTRICTED (non recommandé pour la plupart des charges de travail). Cela active les données précoces TLS 1.3 pour les requêtes utilisant n'importe quelle méthode HTTP, y compris les méthodes non idempotentes, telles que POST. Ce mode n'applique aucune autre limite. Ce mode peut être utile pour les cas d'utilisation de gRPC. Toutefois, nous ne recommandons pas cette méthode, sauf si vous avez évalué votre stratégie de sécurité et atténué le risque d'attaques par rejeu à l'aide d'autres mécanismes.

Configurer les données précoces TLS

Pour activer ou désactiver explicitement les données précoces TLS, procédez comme suit:

Console

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 pour lequel vous devez activer les données précoces.

3. Cliquez sur Modifier ().

4. Cliquez sur Configuration de l'interface.

5. Sélectionnez l'adresse IP et le port de l'interface que vous souhaitez modifier. Pour activer le protocole TLS pour les données précoces, le protocole doit être HTTPS.

6. Dans la liste Données précoces (0-DAR), sélectionnez un mode de données précoces TLS.

7. Cliquez sur OK.

8. Pour mettre à jour l'équilibreur de charge, cliquez sur Mettre à jour.

gcloud

1. Configurez le mode de données précoces TLS sur le proxy HTTPS cible d'un équilibreur de charge d'application.

   gcloud compute target-https-proxies update TARGET_HTTPS_PROXY \
     --tls-early-data=TLS_EARLY_DATA_MODE
   

   Remplacez les éléments suivants :

   • TARGET_HTTPS_PROXY: proxy HTTPS cible de votre équilibreur de charge
   • TLS_EARLY_DATA_MODE: STRICT, PERMISSIVE, DISABLED ou UNRESTRICTED

API

PATCH https://compute.googleapis.com/compute/v1/projects/{project}/global/targetHttpsProxies/TARGET_HTTPS_PROXY
{
    "tlsEarlyData":"TLS_EARLY_DATA_MODE",
    "fingerprint": "FINGERPRINT"
}

Remplacez les éléments suivants :

• TARGET_HTTPS_PROXY: proxy HTTPS cible de votre équilibreur de charge
• TLS_EARLY_DATA_MODE: STRICT, PERMISSIVE, DISABLED ou UNRESTRICTED
• FINGERPRINT: chaîne encodée en base64. Une empreinte à jour doit être fournie pour corriger le proxy HTTPS cible. Dans le cas contraire, la requête échoue avec un code d'état HTTP 412 Precondition Failed.

Une fois que vous avez configuré les données précoces TLS, vous pouvez envoyer des requêtes à partir d'un client HTTP compatible avec les données précoces TLS. Vous pouvez observer une latence plus faible pour les requêtes réactivées.

Si un client non conforme à la documentation RFC envoie une requête avec une méthode non idempotente ou avec des paramètres de requête, celle-ci est refusée. Un code d'état HTTP 425 Early s'affiche dans les journaux de l'équilibreur de charge, ainsi que la réponse HTTP suivante:

  HTTP/1.1 425 Too Early
  Content-Type: text/html; charset=UTF-8
  Referrer-Policy: no-referrer
  Content-Length: 1558
  Date: Thu, 03 Aug 2024 02:45:14 GMT
  Connection: close
  <!DOCTYPE html>
  <html lang=en>
  <title>Error 425 (Too Early)</title>
  <p>The request was sent to the server too early, please retry. That's
  all we know.</p>
  </html>
  

Limites

• Les équilibreurs de charge HTTPS n'envoient pas d'alerte de fermeture close_notify lorsqu'ils mettent fin aux connexions SSL. En d'autres termes, l'équilibreur de charge ferme la connexion TCP au lieu de procéder à l'arrêt d'une connexion SSL.
• Les équilibreurs de charge HTTPS n'acceptent que les minuscules dans les domaines d'un attribut de nom commun (CN) ou d'un autre nom d'objet (SAN) du certificat. Les certificats dont les domaines contiennent des majuscules ne sont renvoyés que lorsqu'ils sont définis comme certificat principal dans le proxy cible.
• Les équilibreurs de charge HTTPS n'utilisent pas l'extension SNI (Server Name Indication) lors de la connexion au backend, à l'exception des équilibreurs de charge avec des backends NEG Internet. Pour en savoir plus, consultez la section Chiffrement entre l'équilibreur de charge et les backends.

• Lorsque vous utilisez des équilibreurs de charge d'application externes régionaux avec Cloud Run dans un environnement VPC partagé, les réseaux VPC autonomes des projets de service peuvent envoyer du trafic vers d'autres services Cloud Run déployés dans d'autres projets de service au sein du même environnement VPC partagé. Il s'agit d'un problème connu. Ce type d'accès sera bloqué à l'avenir.

• Google Cloud ne garantit pas qu'une connexion TCP sous-jacente peut rester ouverte pendant toute la durée du délai avant expiration du service de backend. Les systèmes clients doivent mettre en œuvre une logique de nouvelle tentative au lieu de compter sur une connexion TCP pour être ouverte pendant de longues périodes.

• Vous ne pouvez pas créer d'équilibreur de charge d'application externe régional au niveau Premium avec la console Google Cloud. De plus, seules les régions compatibles avec le niveau Standard sont disponibles pour ces équilibreurs de charge dans la console Google Cloud. Utilisez plutôt la gcloud CLI ou l'API. Utilisez plutôt gcloud CLI ou l'API.

• Cloud CDN vous permet de forcer le cache à ignorer un objet ou un ensemble d'objets en demandant une invalidation de cache. Lorsque vous utilisez un équilibreur de charge d'application externe global avec une référence de service inter-projets de VPC partagé, par défaut, les administrateurs de projet de service ne disposent pas des autorisations requises pour invalider un cache. En effet, l'invalidation de cache est configurée dans le projet d'interface (c'est-à-dire le projet contenant la règle de transfert, le proxy cible et le mappage d'URL de l'équilibreur de charge). Ainsi, les invalidations de cache ne peuvent être émises que par des comptes principaux disposant des rôles IAM permettant de configurer des ressources liées à l'équilibreur de charge dans les projets frontend (par exemple, le rôle Administrateur de réseau Compute). Les administrateurs de services, qui contrôlent le provisionnement des services de backend dans un projet distinct, doivent collaborer avec l'administrateur de l'équilibreur de charge du projet d'interface pour émettre une invalidation de cache pour leurs services inter-projets.

Étape suivante

• Pour savoir comment déployer un équilibreur de charge d'application externe global, consultez la page Configurer un équilibreur de charge d'application externe avec un backend Compute Engine.

• Pour savoir comment déployer un équilibreur de charge d'application externe régional, consultez la page Configurer un équilibreur de charge d'application externe régional avec un backend Compute Engine.

• Si vous êtes déjà un utilisateur de l'équilibreur de charge d'application classique, veillez à consulter la section Présentation de la migration lorsque vous planifiez un nouveau déploiement avec l'équilibreur de charge d'application externe global.

• Pour apprendre à automatiser votre configuration d'équilibreur de charge d'application externe avec Terraform, consultez la page Exemples de modules Terraform pour les équilibreurs de charge d'application externes.

• Pour apprendre à configurer des fonctionnalités avancées de gestion du trafic avec l'équilibreur de charge d'application externe global, consultez la page Présentation de la gestion du trafic pour les équilibreurs de charge d'application externes globaux.

• Pour apprendre à configurer des fonctionnalités avancées de gestion du trafic avec l'équilibreur de charge d'application externe régional, consultez la page Présentation de la gestion du trafic pour les équilibreurs de charge d'application externes régionaux.

• Pour en savoir plus sur la diffusion de sites Web, consultez la page Diffuser un site Web.

• Pour connaître les emplacements des points de présence (POP) de Google, consultez la page Emplacements des GFE.

• Pour en savoir plus sur la gestion de la capacité, consultez les pages Gérer la capacité à l'aide de l'équilibrage de charge et Optimiser la capacité des applications avec l'équilibrage de charge global.

• Pour savoir comment utiliser le Gestionnaire de certificats afin de provisionner et gérer les certificats SSL, consultez la page Présentation du Gestionnaire de certificats.

• Pour insérer une logique personnalisée dans le chemin d'accès aux données d'équilibrage de charge, configurez des plug-ins ou appels d'extensions de service.

• Pour les équilibreurs de charge d'application externes régionaux uniquement, vous pouvez essayer d'utiliser Apigee Shadow API Discovery pour rechercher des API fantômes (également appelées API non documentées) dans votre infrastructureGoogle Cloud existante. Veillez à prendre connaissance des limites associées avant d'activer Shadow API Discovery.