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

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

L'équilibrage de charge HTTP(S) externe est un équilibreur de charge de couche 7 basé sur un proxy qui vous permet d'exécuter et de faire évoluer vos services derrière une seule adresse IP externe. L'équilibrage de charge HTTP(S) externe répartit le trafic HTTP et HTTPS entre les backends hébergés sur diverses plates-formes Google Cloud (telles que Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage, etc.), ainsi que les backends externes connectés à Internet ou via une connectivité hybride. Pour en savoir plus, consultez la section Cas d'utilisation.

Modes de fonctionnement

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

• Équilibreur de charge HTTP(S) externe global Il s'agit d'un équilibreur de charge global mis en œuvre en tant que service géré sur Google Front End (GFE). Il utilise le proxy Envoy Open Source pour prendre en charge des fonctionnalités avancées de gestion du trafic telles que la mise en miroir du trafic, la répartition du trafic en fonction du poids, les transformations d'en-tête basé sur les requêtes/réponses, etc.
• Équilibreur de charge HTTP(S) externe global (classique). Il s'agit de l'équilibreur de charge HTTP(S) externe classique qui est global au niveau Premium, mais qui peut être configuré pour être régional au niveau Standard. Cet équilibreur de charge est mis en œuvre sur les serveurs GFE (Google Front End). Les GFE sont distribués dans le monde entier et fonctionnent conjointement grâce au réseau mondial et au plan de contrôle de Google.
• Équilibreur de charge HTTP(S) externe régional Il s'agit d'un équilibreur de charge régional mis en œuvre en tant que service géré sur le proxy Envoy Open Source. Il comprend des fonctionnalités avancées de gestion du trafic telles que la mise en miroir du trafic, la répartition du trafic en fonction d'une pondération, les transformations d'en-tête basées sur les requêtes/réponses, etc.

Mode d'équilibreur de charge	Cas d'utilisation recommandés	Capacités
Équilibreur de charge HTTP(S) 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 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 (hormis la gestion des bots) Compatible avec GKE en utilisant des NEG autonomes (orchestration manuelle).
Équilibreur de charge HTTP(S) externe global (classique)	Cet équilibreur de charge est global au niveau Premium, mais peut être configuré pour être régional au niveau Standard. Dans le niveau de service réseau Premium, cet équilibreur de charge offre un équilibrage de charge multirégional, en dirigeant le trafic vers le backend opérationnel le plus proche à la capacité suffisante, qui termine le trafic HTTP(S) le plus près possible de vos utilisateurs. Dans le niveau de service réseau standard, l'équilibrage de charge est traité au niveau régional.	Compatible avec GKE en utilisant un objet Ingress ou Gateway (entièrement orchestré). Compatible avec Google Cloud Armor (y compris la gestion des bots). Moins de fonctionnalités de routage du trafic Consultez la page Fonctionnalités d'équilibrage de charge pour obtenir la liste complète des fonctionnalités.
Équilibreur de charge HTTP(S) externe régional	Cet équilibreur de charge contient de nombreuses fonctionnalités de l'équilibreur de charge HTTP(S) externe global (classique) existant, ainsi que des fonctionnalités supplémentaires de gestion avancée du trafic. Utilisez cet équilibreur de charge si vous souhaitez diffuser du contenu à partir d'une seule géolocalisation (par exemple, pour respecter les réglementations de conformité) ou si vous souhaitez utiliser le niveau de service réseau standard.	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'équilibrage de charge	Région	Niveau de réseau
   Équilibreur de charge HTTP(S) externe global	HTTP(S)		PREMIUM
   Équilibreur de charge HTTP(S) externe global (classique)	HTTP(S) (classique)		Standard ou Premium
   Équilibreur de charge HTTP(S) externe régional	HTTP(S)	Spécifie une région	STANDARD

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 HTTP(S) externe global	EXTERNAL_MANAGED	Mondial	PREMIUM
   Équilibreur de charge HTTP(S) externe global (classique)	EXTERNAL	Mondial	Standard ou Premium
   Équilibreur de charge HTTP(S) externe régional	EXTERNAL_MANAGED	Spécifie une région	STANDARD

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 équilibrage de charge HTTP(S) :

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

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

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

  • Pour l'équilibrage de charge HTTPS, le proxy HTTPS cible prouve son identité aux clients à l'aide de certificats SSL. Un proxy HTTP(S) cible accepte un nombre limité de certificats SSL.

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

• Un service de backend répartit les requêtes entre les backends opérationnels. Les équilibreurs de charge HTTP(S) externes globaux sont également compatibles avec les buckets backend.

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

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

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

Mondial

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

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

Régional

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

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

Sous-réseau proxy réservé

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

Le sous-réseau proxy réservé fournit un ensemble d'adresses IP utilisées par Google pour exécuter des proxys Envoy en votre nom. Vous devez créer un sous-réseau proxy réservé dans chaque région du réseau VPC dans lequel vous utilisez des équilibreurs de charge HTTP(S) externes régionaux. L'option --purpose pour ce sous-réseau proxy réservé est définie sur REGIONAL_MANAGED_PROXY. Tous les équilibreurs de charge régionaux basés sur Envoy dans la même région et 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 HTTP(S) externes régionaux d'une région et d'un réseau VPC reçoivent les connexions du sous-réseau proxy réservé.
• L'adresse IP de l'équilibreur de charge HTTP(S) externe régional n'est pas située dans le sous-réseau proxy réservé. L'adresse IP de l'équilibreur de charge est définie par sa règle de transfert gérée en externe et décrite ci-dessous.

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

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

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

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

Le type de règle de transfert, d'adresse IP et de schéma d'équilibrage de charge utilisé par les équilibreurs de charge HTTP(S) externes dépend du mode de l'équilibreur de charge et du niveau de service réseau de l'équilibreur de charge.

Mode d'équilibreur de charge	Niveau de service réseau	Schéma de règle de transfert, adresse IP et équilibrage de charge	Routage depuis Internet vers l'interface de l'équilibreur de charge
Équilibreur de charge HTTP(S) externe global	Niveau Premium	Règle de transfert externe globale Adresse IP externe globale Schéma d'équilibrage de charge : EXTERNAL_MANAGED	Requêtes acheminées vers le GFE le plus proche du client sur Internet.
Équilibreur de charge HTTP(S) externe global (classique)	Niveau Premium	Règle de transfert externe globale Adresse IP externe globale Schéma d'équilibrage de charge : EXTERNAL	Requêtes acheminées vers le GFE le plus proche du client sur Internet.
	Niveau Standard	Règle de transfert externe régionale Adresse IP externe régionale Schéma d'équilibrage de charge : EXTERNAL	Requêtes acheminées vers un GFE dans la région de l'équilibreur de charge
Équilibreur de charge HTTP(S) externe régional	Niveau Standard	Règle de transfert externe régionale Adresse IP externe régionale Schéma d'équilibrage de charge : EXTERNAL_MANAGED	Requêtes acheminées vers les proxys Envoy de la même région que l'équilibreur de charge.

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

Proxy cibles

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

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

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.

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

Mode d'équilibreur de charge	Types de proxys cibles	En-têtes ajoutés par les proxys	En-têtes personnalisés compatibles	Compatibilité avec Cloud Trace
Équilibreur de charge HTTP(S) externe global	HTTP mondial, HTTPS mondial	Les proxys définissent les en-têtes de requête et de réponse HTTP comme suit : Via: 1.1 google (requêtes et réponses) X-Forwarded-Proto : [http | https] (requêtes uniquement) X-Cloud-Trace-Context : <trace-id>/<span-id>;<trace-options> (requêtes uniquement) Contient les paramètres de Cloud Trace. X-Forwarded-For : [<supplied-value>,]<client-ip>,<load-balancer-ip> (voir l'en-tête X-Forwarded-For) (requêtes uniquement)	Configuré sur le service de backend ou le bucket backend. Non compatible avec Cloud CDN
Équilibreur de charge HTTP(S) externe global (classique)	HTTP mondial, HTTPS mondial	Les proxys définissent les en-têtes de requête et de réponse HTTP comme suit : Via: 1.1 google (requêtes et réponses) X-Forwarded-Proto : [http | https] (requêtes uniquement) X-Cloud-Trace-Context : <trace-id>/<span-id>;<trace-options> (requêtes uniquement) Contient les paramètres de Cloud Trace. X-Forwarded-For : [<supplied-value>,]<client-ip>,<load-balancer-ip> (voir l'en-tête X-Forwarded-For) (requêtes uniquement)	Configuré sur le service de backend ou le bucket backend.
Équilibreur de charge HTTP(S) externe régional	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)

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

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>

Mappages d'URL

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

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

• Présentation de la gestion du trafic pour l'équilibreur de charge HTTP(S) externe régional
• Présentation de la gestion du trafic pour l'équilibreur de charge HTTP(S) externe régional

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

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

Certificats SSL

Les équilibreurs de charge HTTP(S) 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 propose deux méthodes de configuration pour l'attribution de clés privées et de 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 : les certificats autogérés et les certificats 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 mode de l'équilibreur de charge HTTP(S) externe détermine les méthodes de configuration et les types de certificats compatibles. Pour en savoir plus, consultez la section Certificats et équilibreurs de charge Google Cloud 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 les équilibreurs de charge Google Cloud lors de la négociation SSL avec les 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 HTTP(S) externe global
Équilibreur de charge HTTP(S) externe global (classique)
Équilibreur de charge HTTP(S) externe régional

Services de backend et buckets

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

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

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

Mode d'équilibreur de charge	Backends compatibles sur un service de backend						Compatible avec les buckets backend	Compatible avec Google Cloud Armor	Compatible avec Cloud CDN	Compatible avec IAP
	Groupes d'instances	NEG zonaux	NEG Internet	NEG sans serveur	NEG hybrides	NEG Private Service Connect
Équilibreur de charge HTTP(S) externe global
Équilibreur de charge HTTP(S) externe global (classique)									en cas d'utilisation du niveau Premium
Équilibreur de charge HTTP(S) externe régional

Pour en savoir plus, consultez les ressources suivantes :

• Présentation des services de backend
• Qu'est-ce que Cloud Storage ?

Backends et réseaux VPC

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

• Pour l'équilibreur de charge HTTP(S) externe global et l'équilibreur de charge HTTP(S) externe global (classique), tous les backends doivent être situés dans le même projet, mais peuvent se trouver sur différents réseaux VPC. Les différents réseaux VPC n'ont pas besoin d'être connectés via l'appairage de réseaux VPC, car les systèmes de proxy GFE communiquent directement avec les backends dans leurs réseaux VPC respectifs.
• Pour l'équilibreur de charge HTTP(S) externe régional, tous les backends doivent être situés dans le même réseau VPC et dans la même région.

Protocole de communication avec les backends

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

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

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

Assistance WebSocket

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

Remarque : Le protocole HTTP/2 n'est pas compatible.

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

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

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

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

Utiliser gRPC avec vos applications Google Cloud

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

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

Pour utiliser gRPC avec vos applications Google Cloud, vous devez relayer les requêtes par proxy de bout en bout via HTTP/2. Procédez comme suit :

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

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

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

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

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

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

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

Vérifications d'état

Chaque service de backend spécifie une vérification d'état 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 HTTP(S) 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 HTTP(S) 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 l'équilibrage de charge HTTP(S) dans chaque mode.

Mode d'équilibreur de charge	Type de vérification d'état
Équilibreur de charge HTTP(S) externe global	Monde
Équilibreur de charge HTTP(S) externe global (classique)	Monde
Équilibreur de charge HTTP(S) 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'équilibrage de charge HTTP(S) nécessite les règles de pare-feu suivantes :

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

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 HTTP(S) externe global	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) : 130.211.0.0/22 35.191.0.0/16 NEG SERVERLESS et buckets de backend : le réseau de production de Google gère le routage des paquets
Équilibreur de charge HTTP(S) externe global (classique)	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 HTTP(S) externe régional	35.191.0.0/16 130.211.0.0/22 Actuellement, les vérifications d'état pour les NEG hybrides proviennent du mécanisme de vérification d'état centralisé de Google. Si vous ne pouvez pas autoriser le trafic provenant des plages de vérification d'état de Google à atteindre vos points de terminaison hybrides, et si vous préférez que les vérifications d'état proviennent d'adresses IP privées, adressez-vous à votre responsable de compte Google pour que votre projet soit autorisé à effectuer les vérifications d'état Envoy distribuées.	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.

Architecture du VPC partagé

L'équilibrage de charge HTTP(S) est compatible 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 l'équilibrage de charge HTTP(S) 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 HTTP(S) externe global, équilibreur de charge HTTP(S) externe global (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 HTTP(S) 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 le 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 modèle ne distingue pas les responsabilités des administrateurs réseau et des développeurs de services.

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, Cloud Functions ou App Engine de sauvegarde doit se trouver dans le même projet que le NEG sans serveur.

En outre, pour l'équilibreur de charge HTTP(S) externe régional compatible avec le référencement interservices, 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

Dans ce modèle, le mappage d'URL et l'interface de l'équilibreur de charge se trouve dans un projet hôte ou de service. Les services de backend et les backends de l'équilibreur de charge peuvent être répartis entre les projets de l'environnement VPC partagé. Les services de backend inter-projets peuvent être référencés dans un seul mappage d'URL. C'est ce que l'on appelle la référence du service inter-projets.

Le référencement de services inter-projets permet aux organisations 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).

Pour apprendre à configurer un VPC partagé pour un équilibreur de charge HTTP(S) externe régional (avec et sans référencement de services inter-projets), consultez la page Configurer un équilibreur de charge HTTP(S) externe régional avec un VPC partagé.

Le référencement des services inter-projets peut être utilisé avec des groupes d'instances, des NEG sans serveur ou tout autre type de backend compatible. Si vous utilisez des NEG sans serveur, vous devez créer une VM dans le réseau VPC sur lequel vous souhaitez créer l'interface de l'équilibreur de charge. Pour apprendre à créer la VM, consultez la page Configurer un équilibreur de charge HTTP(S) externe régional avec Cloud Run.

Le référencement des services inter-projets n'est pas compatible avec l'équilibreur de charge HTTP(S) externe global et l'équilibreur de charge HTTP(S) externe global (classique).

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

Voici un exemple de déploiement 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 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 du projet de service B attribuent le rôle IAM 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

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

Dans ce type de déploiement, 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) sont créés 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 projets de service accordent le rôle IAM 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 et mappage d'URL de l'équilibreur de charge dans le projet hôte

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

Dans ce modèle, tous les composants et les backends de l'équilibreur de charge se trouvent dans un projet de service. Ce modèle de déploiement est compatible avec tous les équilibreurs de charge HTTP(S).

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

Équilibreur de charge HTTP(S) externe régional sur un réseau VPC partagé

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

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

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

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

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.

Selon la configuration du service de backend, le protocole utilisé par chaque GFE pour se connecter aux backends peut être HTTP, HTTPS ou HTTP/2. Pour les connexions HTTP ou HTTPS, la version HTTP utilisée est HTTP 1.1.

Le message HTTP keepalive est activé par défaut, comme indiqué dans la spécification HTTP 1.1. Les messages keepalive HTTP tentent d'utiliser efficacement la même session TCP. mais il n'y a aucune garantie. Le GFE utilise un délai avant expiration de 600 secondes pour le message keepalive, et vous ne pouvez pas le configurer. Vous pouvez toutefois configurer le délai avant expiration de la requête/réponse en définissant le délai avant expiration du service de backend. Bien qu'ils soient étroitement liés, un message keepalive HTTP et un délai d'inactivité TCP ne sont pas identiques. Pour en savoir plus, consultez la section Délais d'expiration et nouvelles tentatives.

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

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

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

L'équilibreur de charge HTTP(S) externe régional est un service géré mis en œuvre sur le proxy Envoy. L'équilibreur de charge HTTP(S) externe régional utilise un sous-réseau partagé appelé sous-réseau proxy réservé pour provisionner un ensemble d'adresses IP utilisées par Google pour exécuter des proxys Envoy en votre nom. L'option --purpose pour ce sous-réseau proxy réservé est définie sur REGIONAL_MANAGED_PROXY. Tous les équilibreurs de charge 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 utilise un délai avant expiration de 600 secondes pour le message keepalive, et vous ne pouvez pas le configurer. Vous pouvez toutefois configurer le délai avant expiration de la requête/réponse en définissant le délai avant expiration du service de backend. Pour en savoir plus, consultez la section Délais d'expiration et nouvelles tentatives.

Communication entre les clients et l'équilibreur de charge

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

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

Adresses IP sources des paquets client

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

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

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

  • Adresse IP source : le client d'origine (ou l'adresse IP externe si le client est protégé par la fonctionnalité NAT ou un proxy de transfert).
  • Adresse IP de destination : l'adresse IP de votre équilibreur de charge.

• Connexion 2, de l'équilibreur de charge (GFE) vers la VM de backend ou le point de terminaison :

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

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

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 HTTP(S) externes régionaux :

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

  • Adresse IP source : le client d'origine (ou l'adresse IP externe si le client est protégé par la fonctionnalité NAT ou un proxy de transfert).
  • Adresse IP de destination : l'adresse IP de votre équilibreur de charge.

• Connexion 2, de l'équilibreur de charge (sous-réseau proxy réservé) vers la VM de backend ou le point de terminaison :

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

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

Chemin de retour

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

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

Ports ouverts

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

Remarque : L'équilibreur de charge HTTP(S) externe régional est mis en œuvre à l'aide des proxys Envoy, qui ne sont compatibles qu'avec les ports 80, 8080 et 443.

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

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

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

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

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

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

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

terminaison TLS

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

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

Délais d'expiration et nouvelles tentatives

L'équilibrage de charge HTTP(S) externe présente les délais avant expiration suivants :

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

  Remarque : Le paramètre de délai avant expiration du service de backend n'est pas configurable sur les services de backend avec des backends de NEG sans serveur.

  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 la valeur par défaut de 30 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 30 secondes. Le délai avant expiration du service de backend peut être configuré de sorte qu'il ne soit pas assez long pour que le backend envoie sa 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, 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.

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

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

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

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

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

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

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

  • Console Google Cloud : modifiez le champ Délai avant expiration du service de backend de l'équilibreur de charge.
  • Google Cloud CLI : utilisez la commande gcloud compute backend-services update pour modifier le paramètre --timeout de la ressource du service de backend.
  • API : modifiez le paramètre timeoutSec pour la ressource globale ou régionale du service de backend.

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

• Deux délais avant expiration s'appliquent lorsque des buckets backend sont utilisés avec l'équilibreur de charge HTTP(S) externe global et l'équilibreur de charge HTTP(S) externe global (classique) :
• Un délai avant expiration fixé à six minutes. Cela signifie que les flux HTTP du bucket backend sont considérés comme inactifs après six minutes d'inactivité.
• Un autre délai avant expiration incluant le temps pris par l'équilibreur de charge et Cloud Storage pour le traitement de la réponse complète. Ce délai avant expiration est fixé à 24 heures.

• Un délai d'expiration HTTP keepalive, dont la valeur est fixée à 10 minutes (600 secondes). Cette valeur n'est pas configurable par la modification du service de backend. Pour empêcher la fermeture prématurée des connexions par le backend, vous devez configurer le logiciel de serveur Web utilisé par vos backends afin que son délai avant expiration "keepalive" soit supérieur à 600 secondes. Ce délai avant expiration ne s'applique pas aux connexions WebSocket. Le tableau suivant présente les modifications à effectuer pour modifier les délais avant expiration "keepalive" des logiciels de serveur Web courants :

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

Tentatives

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

Mode d'équilibreur de charge	Logique de nouvelle tentative
Équilibreur de charge HTTP(S) externe global	Configurable à l'aide d'une stratégie de nouvelle tentative dans le mappage d'URL. Le nombre de nouvelles tentatives par défaut (numRetries) est de 1. Le nombre maximal de nouvelles tentatives pouvant être configurées à l'aide de la stratégie de nouvelle tentative est de 25. Le délai avant expiration par défaut pour chaque tentative (perTryTimeout) est de 30 secondes avec une valeur de perTryTimeout configurable maximale de 24 heures. Sans stratégie de nouvelle tentative, les requêtes infructueuses sans corps HTTP (par exemple, des requêtes GET) aboutissant à des réponses HTTP 502, 503 ou 504 (retryConditions=["gateway-error"]) sont relancées une seule 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 HTTP(S) externe global (classique)	Vous ne pouvez pas modifier la stratégie de nouvelle tentative pour les nouvelles tentatives de connexion. Les requêtes HTTP POST ne font pas l'objet d'une nouvelle tentative. Les requêtes HTTP GET sont toujours relancées tant qu'au moins 80 % des backends sont opérationnels. Si un groupe ne comprend qu'une seule instance backend et que la connexion à celle-ci échoue, le pourcentage d'instances backend non opérationnelles est de 100 %. Le GFE ne tente donc pas de relancer la requête. Certaines circonstances d'échec de requêtes GET conduisent l'équilibreur de charge à effectuer de nouvelles tentatives, par exemple lorsque le délai avant expiration du service de backend est écoulé. Le nombre de nouvelles tentatives d'exécution d'une requête est limité à 25. Les requêtes faisant l'objet d'une nouvelle tentative ne génèrent qu'une seule entrée de journal associée à la réponse finale. Pour en savoir plus, consultez la page Journalisation et surveillance de l'équilibrage de charge HTTP(S). Les requêtes infructueuses aboutissent à la synthèse d'une réponse HTTP 502.
Équilibreur de charge HTTP(S) externe régional	Configurable à l'aide d'une stratégie de nouvelle tentative dans le mappage d'URL. Le nombre de nouvelles tentatives par défaut (numRetries) est de 1. Le nombre maximal de nouvelles tentatives pouvant être configurées à l'aide de la stratégie de nouvelle tentative est de 25. Le délai avant expiration par défaut pour chaque tentative (perTryTimeout) est de 30 secondes avec une valeur de perTryTimeout configurable maximale de 24 heures. Sans stratégie de nouvelle tentative, les requêtes infructueuses sans corps HTTP (par exemple, des requêtes GET) aboutissant à des réponses HTTP 502, 503 ou 504 sont relancées une seule fois. Les requêtes HTTP POST ne font pas l'objet d'une nouvelle tentative. 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.

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 l'équilibrage de charge HTTP(S) externe.
• 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.

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

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

Distribution du trafic

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

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

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

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

Équilibreur de charge HTTP(S) externe global

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

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

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

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

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

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

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

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

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

Pour en savoir plus, consultez les ressources suivantes :

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

Distribution des requêtes

La répartition régionale du trafic ou le niveau global dépend du mode d'équilibrage de charge et du niveau de service réseau utilisé.

Pour le niveau Premium :

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

Pour le niveau Standard :

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

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

Processus de distribution des requêtes :

Le mode d'équilibrage et le choix de la cible définissent l'utilisation maximale du backend du point de vue de chaque NEG GCE_VM_IP_PORT zonal, groupe d'instance zonal ou zone d'un groupe d'instance régional. La distribution au sein d'une zone est effectuée avec un hachage cohérent pour l'équilibreur de charge HTTP(S) externe global (classique) et configurable à l'aide de la règle d'équilibrage de charge de la localité pour l'équilibreur de charge HTTP(S) externe global et l'équilibreur de charge HTTP(S) externe régional.

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

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

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

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

3. Le GFE de deuxième couche dirige les requêtes vers les backend des zones de sa région.
4. Parfois, pour le niveau Premium, les GFE de deuxième couche envoient des requêtes aux backends dans des zones de différentes régions. Ce comportement est appelé basculement.

Le débordement est régi par deux principes :

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

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

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

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

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

Affinité de session

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

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

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

• 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

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

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

Compatibilité HTTP/2

Nombre maximal de flux simultanés HTTP/2

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

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

Limites liées à HTTP/2

• Le protocole HTTP/2 entre l'équilibreur de charge et l'instance peut nécessiter beaucoup plus de connexions TCP à l'instance que HTTP(S). Le regroupement de connexions, une optimisation qui réduit le nombre de ces connexions avec HTTP(S), n'est pas disponible actuellement avec HTTP/2. Par conséquent, vous pouvez 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'API Google 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 OK 200.

Compatibilité HTTP/3 et Google QUIC

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 HTTP(S) externe, Cloud CDN et les clients.

Google QUIC inclut à la fois la couche d'application et de transport dans le modèle OSI. Il s'agit de l'ancienne version de la combinaison de HTTP/3 et de IETF QUIC.

à savoir :

• Le protocole QUIC d'IETF est un protocole de couche de transport offrant un contrôle de congestion semblable à TCP et une sécurité équivalente à SSL/TLS pour HTTP/2, avec des performances améliorées.
• HTTP/3 est une couche d'application 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 affecte les connexions entre les clients et l'équilibreur de charge, mais pas les connexions entre l'équilibreur de charge et ses backends.
• Les connexions HTTP/3 utilisent l'algorithme de contrôle de congestion BBR.

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

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

Mode d'équilibreur de charge	Compatibilité HTTP/3
Équilibreur de charge HTTP(S) externe global (toujours du niveau Premium)
Équilibreur de charge HTTP(S) externe global (classique) au niveau Premium
Équilibreur de charge HTTP(S) externe global (classique) au niveau Standard
Équilibreur de charge HTTP(S) externe régional (toujours au niveau 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 configuré en tant que ENABLE sur la ressource targetHttpsProxy d'un équilibreur de charge HTTP(S) externe, les réponses de l'équilibreur de charge incluent la valeur d'en-tête alt-svc suivante :

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,
h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,
quic=":443"; ma=2592000; v="46,43"

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), ainsi que les versions de Google QUIC (h3-Q050) qui sont également utilisées. Les anciennes versions des deux protocoles seront supprimées de l'annonce Alt-Svc.

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 HTTP/3

Vous pouvez explicitement activer la compatibilité HTTP/3 pour votre équilibreur de charge en définissant quicOverride sur ENABLE.

Lorsque vous activez HTTP/3, 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 mises en œuvre clientes défectueuses.

L'équilibrage de charge HTTP(S) propose trois méthodes de configuration de HTTP/3, comme indiqué dans le tableau suivant.

Valeur quicOverride	Comportement
NONE	La compatibilité du protocole HTTP/3 est annoncée aux clients.
ENABLE	La compatibilité avec HTTP/3 et Google QUIC est annoncée aux clients. Le protocole HTTP/3 est annoncé avec une priorité plus élevée. Les clients compatibles avec les deux protocoles doivent préférer HTTP/3 à Google QUIC. Remarque : TLS 0-RTT (également appelé données anticipées TLS) est implicitement compatible lorsque Google QUIC est négocié par le client, mais il n'est pas compatible lorsque le protocole HTTP/3 est utilisé.
DISABLE	Désactive explicitement la diffusion des annonces concernant les protocoles HTTP/3 et QUIC aux clients.

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

Console : HTTPS

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"

2. Sélectionnez l'équilibreur de charge que vous souhaitez modifier.

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

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

Activer le protocole HTTP/3

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

Désactiver le protocole HTTP/3

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

gcloud : HTTPS

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

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

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

• NONE (par défaut) : permet à Google de contrôler l'annonce du protocole HTTP/3.

  Actuellement, lorsque vous sélectionnez NONE, HTTP/3 est annoncé aux clients, mais pas Google QUIC.

  Dans Google Cloud Console, 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.

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.

  Actuellement, lorsque vous sélectionnez NONE, HTTP/3 est annoncé aux clients, mais pas Google QUIC.

  Dans Google Cloud Console, 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.

Limites

• Les équilibreurs de charge HTTPS n'acceptent pas l'authentification basée sur un certificat client, également appelée authentification TLS mutuelle.
• 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 HTTP(S) 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.
• reCAPTCHA Enterprise pour WAF avec Google Cloud Armor n'est compatible qu'avec l'équilibreur de charge HTTP(S) externe global (classique). Il n'est pas compatible avec l'équilibreur de charge HTTP(S) externe global bénéficiant des fonctionnalités avancées de gestion du trafic.

Étapes suivantes

• Pour apprendre à déployer un équilibreur de charge HTTP(S) externe global, consultez la page Configurer un équilibreur de charge HTTP(S) externe avec un backend Compute Engine.
• Pour savoir comment déployer un équilibreur de charge HTTP(S) externe régional, consultez la page Configurer un équilibreur de charge HTTP(S) externe régional avec un backend Compute Engine.
• Si vous êtes déjà un utilisateur de l'équilibreur de charge HTTP(S) externe global (classique), veillez à consulter la page Planifier votre migration vers l'équilibreur de charge HTTP(S) externe global lorsque vous planifiez un nouveau déploiement avec l'équilibreur de charge HTTP(S) externe global.
• Pour apprendre à automatiser votre configuration d'équilibrage de charge HTTP(S) externe avec Terraform, consultez la page Exemples de modules Terraform pour les équilibreurs de charge HTTP(S) externes.
• Pour apprendre à configurer des fonctionnalités avancées de gestion du trafic avec l'équilibreur de charge HTTP(S) externe global, consultez la page Présentation de la gestion du trafic pour les équilibreurs de charge HTTP(S) externes globaux.
• Pour apprendre à configurer les fonctionnalités avancées de gestion du trafic disponibles avec l'équilibreur de charge HTTP(S) externe régional, consultez la page Présentation de la gestion du trafic pour les équilibreurs de charge HTTP(S) externes régionaux.
• 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 en savoir plus sur la diffusion de sites Web, consultez la page Diffuser un site Web.
• 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.