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

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

Pour en savoir plus sur les différences entre les équilibreurs de charge Google Cloud, consultez les documents suivants :

Cas d'utilisation

Les équilibreurs de charge HTTP(S) externes permettent de répondre à de nombreux cas d'utilisation. Cette section fournit des exemples généraux.

Services Web à trois niveaux

L'équilibrage de charge HTTP(S) externe vous permet d'assurer la compatibilité avec les services Web classiques à trois niveaux. L'exemple suivant décrit comment effectuer le scaling de trois niveaux grâce à trois types d'équilibreurs de charge Google Cloud. À chaque niveau, le type d'équilibreur de charge dépend de votre type de trafic :

Le schéma suivant illustre la façon dont le trafic transite par les différents niveaux :

  1. Un équilibreur de charge HTTP(S) externe (sujet de cette présentation) répartit le trafic provenant d'Internet entre un ensemble de groupes d'instances frontend Web dans différentes régions.
  2. Ces interfaces Web envoient le trafic HTTP(S) vers un ensemble d'équilibreurs de charge HTTP(S) internes régionaux. Pour que l'équilibreur de charge HTTP(S) externe puisse transférer le trafic vers un équilibreur de charge HTTP(S) interne, celui-ci doit disposer d'instances backend avec un logiciel de serveur Web (tel que Netscaler ou NGNIX) configuré pour transférer le trafic vers l'interface de l'équilibreur de charge HTTP(S) interne.
  3. Les équilibreurs de charge HTTP(S) internes répartissent le trafic entre les groupes d'instances middleware.
  4. Ces groupes d'instances middleware envoient le trafic aux équilibreurs de charge TCP/UDP internes qui équilibrent la charge du trafic entre les clusters de stockage de données.
Routage basé sur la couche 7 pour les niveaux internes d'une application à plusieurs niveaux
Routage basé sur la couche 7 pour les niveaux internes d'une application à plusieurs niveaux

Équilibrage de charge multirégional

Représentation de l'équilibrage de charge multirégional

Lorsque vous configurez un équilibreur de charge HTTP(S) externe de niveau Premium, celui-ci utilise une adresse IP externe globale et peut acheminer intelligemment les requêtes des utilisateurs vers le groupe d'instances de backend ou NEG le plus proche, en fonction de la proximité. Par exemple, si vous configurez des groupes d'instances en Amérique du Nord, en Europe et en Asie, et que vous les associez au service de backend d'un équilibreur de charge, les requêtes des utilisateurs du monde entier sont automatiquement envoyées aux VM les plus proches des utilisateurs, à condition que les VM réussissent les vérifications d'état et possèdent une capacité suffisante (définie par le mode d'équilibrage). Si les VM les plus proches sont toutes considérées comme non opérationnelles, ou si le groupe d'instances le plus proche est au maximum de sa capacité et qu'un autre groupe d'instances ne l'est pas, l'équilibreur de charge envoie automatiquement des requêtes à la prochaine région la plus proche disposant de la capacité nécessaire.


Équilibrage de charge avec routage des requêtes

Représentation de l'équilibrage de charge basé sur le contenu

L'équilibrage de charge HTTP(S) prend en charge le routage des requêtes en utilisant des mappages d'URL pour sélectionner un service de backend en fonction du nom d'hôte demandé, du chemin de requête ou des deux. Vous pouvez par exemple utiliser un ensemble de groupes d'instances ou NEG pour gérer votre contenu vidéo et un autre ensemble pour gérer tout le reste.

Vous pouvez également utiliser l'équilibrage de charge HTTP(S) avec des buckets Cloud Storage. Une fois que vous avez configuré votre équilibreur de charge, vous pouvez y ajouter des buckets Cloud Storage.


Équilibrage de charge avec plusieurs types de backends

L'équilibrage de charge HTTP(S) externe est compatible avec les types de backend suivants :

Un cas d'utilisation courant consiste à équilibrer la charge du trafic entre les services. Dans l'exemple suivant, les clients IPv4 et IPv6 externes peuvent demander des vidéos, du contenu d'API et des images en utilisant la même URL de base, avec les chemins d'accès /api, /video et /images.

Le mappage d'URL de l'équilibreur de charge HTTP(S) externe spécifie que :

  • les requêtes vers le chemin /api sont envoyées au service de backend avec un groupe d'instances de VM ou un backend NEG zonal ;
  • les requêtes vers le chemin /images sont envoyées à un bucket backend à l'aide d'un backend Cloud Storage ;
  • les requêtes vers le chemin /video sont envoyées à un service de backend qui pointe vers un NEG Internet contenant un point de terminaison externe situé sur un site en dehors de Google Cloud.

Lorsqu'un client envoie une requête à l'adresse IPv4 ou IPv6 externe de l'équilibreur de charge, cet équilibreur évalue la requête en fonction du mappage d'URL et l'envoie au service approprié.

Le schéma suivant illustre ce cas d'utilisation.

Schéma de l'équilibrage de charge avec un backend externe.
Schéma de l'équilibrage de charge avec un backend externe (cliquez pour agrandir)

Sur chaque service de backend, vous pouvez éventuellement activer Cloud CDN et Google Cloud Armor. Si vous utilisez Google Cloud Armor avec Cloud CDN, les règles de sécurité ne sont appliquées que pour les requêtes de contenu dynamique, les défauts de cache (miss) ou d'autres requêtes destinées au serveur d'origine du CDN. Les succès de cache (hit) sont diffusés même si la règle de sécurité Google Cloud Armor en aval empêche cette requête d'atteindre le serveur CDN d'origine.

Cloud CDN est compatible avec les buckets backend, contrairement à Google Cloud Armor.

Créer un équilibreur de charge combiné

Vous pouvez configurer un équilibreur de charge HTTP(S) externe de niveau Premium pour fournir à la fois un équilibrage de charge multirégional à l'aide de plusieurs services de backend, chacun avec des groupes d'instances de backend ou des NEG dans plusieurs régions. Vous pouvez combiner et étendre les cas d'utilisation afin de configurer un équilibreur de charge HTTP(S) externe adapté à vos besoins.

Représentation de l'équilibrage de charge multirégional
Représentation de l'équilibrage de charge multirégional

Architecture

Le schéma suivant présente les ressources Google Cloud requises pour un équilibreur de charge HTTP(S) externe.

Composants de l'équilibrage de charge HTTP(S)
Composants de l'équilibrage de charge HTTP(S)

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

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

  • Un proxy HTTP(S) régional 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.

  • Si vous utilisez l'équilibrage de charge HTTPS, le proxy HTTPS cible prouve son identité aux clients à l'aide de certificats SSL mondiaux. Un proxy HTTPS cible accepte le nombre maximal indiqué 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 ou un bucket backend répartit les requêtes entre les backends opérationnels.

  • Un ou plusieurs backends doivent être connectés au service de backend ou au bucket backend. Les backends peuvent être des groupes d'instances, des NEG ou des buckets ayant l'une des configurations suivantes :

    • Groupes d'instances gérés (zonaux ou régionaux)
    • Groupes d'instances non gérés (zonaux)
    • Groupes de points de terminaison du réseau (zonaux)
    • Groupes de points de terminaison du réseau (Internet)
    • Buckets Cloud Storage

    Vous ne pouvez pas utiliser à la fois des groupes d'instances et des groupes de points de terminaison du réseau sur le même service de backend.

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

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

Règles de transfert et adresses

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

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

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

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

  • Les équilibreurs de charge HTTP(S) externes de niveau Premium utilisent des règles de transfert externes mondiales.
  • Les équilibreurs de charge HTTP(S) externes de niveau Standard utilisent des règles de transfert externes régionales.

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

Proxy cibles

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

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 des paramètres pour Cloud Trace.

Vous pouvez créer des en-têtes de requête et de réponse personnalisés si les en-têtes par défaut ne répondent pas à vos besoins. Pour en savoir plus sur cette fonctionnalité, consultez la page Créer des en-têtes personnalisés.

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.

En-tête d'hôte

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

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

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

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

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

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

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

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

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

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

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

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

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

Mappages d'URL

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

Certificats SSL

Si vous utilisez l'équilibrage de charge HTTPS, vous devez installer un ou plusieurs certificats SSL sur le proxy HTTPS cible.

Ces certificats sont utilisés par les proxys HTTPS cibles pour sécuriser les communications entre l'équilibreur de charge et le client.

Pour en savoir plus sur les limites et les quotas des certificats SSL, consultez la section Certificats SSL sur la page des quotas d'équilibrage de charge.

Pour une sécurité optimale, utilisez le chiffrement de bout en bout pour le déploiement de votre équilibreur de charge HTTPS. Pour en savoir plus, consultez la section Chiffrement entre l'équilibreur de charge et les backends.

Pour plus d'informations sur la façon dont Google chiffre le trafic des utilisateurs, consultez le livre blanc Chiffrement en transit sur Google Cloud.

Règles SSL

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

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

Services de backend et buckets

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

Services de backend

Les services de backend fournissent des informations de configuration à l'équilibreur de charge. Les équilibreurs de charge utilisent les informations d'un service de backend pour rediriger le trafic entrant vers un ou plusieurs backends associés.

Pour obtenir un exemple de configuration d'un équilibreur de charge avec un service de backend et un backend Compute Engine, consultez la pageConfigurer un équilibreur de charge HTTP(S) externe avec un backend Compute Engine.

Buckets de backend

Les buckets backend dirigent le trafic entrant vers des buckets Cloud Storage.

Pour obtenir un exemple d'ajout d'un bucket à un équilibreur de charge, consultez la page Configurer un équilibreur de charge avec des buckets backend.

Vérifications d'état

Chaque service de backend spécifie également les vérifications d'état à effectuer sur chaque instance disponible. Pour que les tests de vérification d'état fonctionnent correctement, vous devez créer une règle de pare-feu autorisant le trafic provenant de 130.211.0.0/22 et de 35.191.0.0/16 à accéder à vos instances.

Pour en savoir plus sur les vérifications d'état, consultez la page Créer des vérifications d'état.

Protocole de communication avec les backends

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

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

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

Utiliser gRPC avec vos applications Google Cloud

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

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

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

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

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

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

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

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

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

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

Règles de pare-feu

Les instances backend doivent autoriser les connexions à partir des plages GFE ou de vérification d'état de l'équilibreur de charge. Cela signifie que vous devez créer une règle de pare-feu autorisant le trafic entrant pour le trafic provenant de 130.211.0.0/22 et 35.191.0.0/16 et à destination de vos instances ou points de terminaison principaux. Ces plages d'adresses IP sont utilisées comme sources pour les paquets de vérification de l'état et pour tous les paquets à charge équilibrée envoyés à vos backends.

Les ports que vous configurez pour cette règle de pare-feu doivent :

  • Autoriser le trafic vers le port de destination requis par la vérification d'état configurée de chaque service de backend.

  • Pour les backends de groupes d'instances : autorisez le trafic vers les ports de destination correspondant aux numéros de port auxquels le port nommé du service de backend s'abonne.

  • Pour les backends de NEG GCE_VM_IP_PORT : autorisez le trafic vers les ports des points de terminaison des NEG.

Les règles de pare-feu sont mises en œuvre au niveau de l'instance de VM, et non sur les proxys Google Front End (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 plus d'informations sur les vérifications de l'état et découvrir pourquoi il est nécessaire d'autoriser le trafic en provenance de 130.211.0.0/22 et de 35.191.0.0/16, consultez la section Plages d'adresses IP de vérification et règles de pare-feu.

Chemin de retour

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

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

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

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

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

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

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

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

Communication entre les clients et l'équilibreur de charge

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

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

Adresses IP sources des paquets client

Les adresses IP sources des paquets, telles qu'elles sont perçues par chaque instance de machine virtuelle (VM) ou conteneur backend, proviennent des plages suivantes :

  • 35.191.0.0/16
  • 130.211.0.0/22

L'adresse IP source du trafic réel à équilibrage de charge est identique à celle des plages d'adresses IP des vérifications d'état.

Les adresses IP sources du trafic, telles qu'elles sont perçues par les backends, sont différentes de l'adresse IP externe Google Cloud de l'équilibreur de charge. En d'autres termes, il existe deux sessions HTTP, SSL ou TCP :

  • Session 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).
    • Adresse IP de destination : l'adresse IP de votre équilibreur de charge.
  • Session 2, de l'équilibreur de charge (GFE) vers la VM de backend ou le conteneur :

    • Adresse IP source : une adresse IP située dans l'une de ces plages : 35.191.0.0/16 ou 130.211.0.0/22.

      Vous ne pouvez pas prédire l'adresse source réelle.

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

Ports ouverts

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

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

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

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

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

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

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

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

terminaison TLS

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

Délais d'expiration et nouvelles tentatives

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

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

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

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

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

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

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

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

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

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

Le protocole WebSocket est compatible avec les objets Ingress.

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

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

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

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

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

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

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

Distribution du trafic

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

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

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

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

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

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

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

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

Comportement dans les différents niveaux de service réseau

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

Niveau Premium

Lorsque le Niveau Premium est utilisé, les requêtes envoyées à l'équilibreur de charge HTTP(S) externe sont transmises aux groupes d'instances backend ou aux NEG de la région la plus proche de l'utilisateur, si un backend de cette région dispose de la capacité nécessaire. (La capacité disponible est configurée par le mode d'équilibrage de l'équilibreur de charge.)

Vous pouvez avoir plusieurs services de backend dans une région et en créer dans plusieurs régions, tous desservis par le même équilibreur de charge mondial. Le trafic est alloué aux services de backend de la manière suivante :

  1. Lorsqu'une requête utilisateur arrive, le service d'équilibrage de charge détermine son origine approximative à partir de l'adresse IP source.
  2. Le service d'équilibrage de charge connaît les emplacements des instances détenues par le service de backend, leur capacité globale et leur utilisation actuelle globale.
  3. Si les instances les plus proches de l'utilisateur ont de la capacité disponible, la requête est transmise à l'ensemble d'instances le plus proche.
  4. Les requêtes envoyées vers la région donnée sont distribuées de manière équitable entre l'ensemble des instances et des services de backend disponibles dans cette région. Toutefois, pour des charges très faibles, la distribution peut sembler non équitable.
  5. Si aucune instance opérationnelle d'une région donnée n'a de capacité disponible, l'équilibreur de charge envoie la requête à la région la plus proche avec de la capacité disponible.

Niveau Standard

Lorsque le Niveau Standard est utilisé, l'équilibreur de charge HTTP(S) externe est un service régional. Ses groupes d'instances backend ou ses NEG doivent tous être situés dans la région utilisée par l'adresse IP externe et la règle de transfert de l'équilibreur de charge.

Régions et zones

Une fois que l'équilibreur de charge HTTP(S) externe a sélectionné une région :

  • Si vous avez configuré des backends dans plusieurs zones de la région, l'équilibreur de charge HTTP(S) externe tente de répartir les requêtes aussi uniformément que possible entre les zones, sous réserve de la capacité de l'instance backend et de l'affinité de session.

  • Au sein d'une zone, l'équilibreur de charge HTTP(S) externe tente de répartir les requêtes à l'aide de l'algorithme d'équilibrage de charge, en fonction de la capacité disponible et de l'affinité de session.

Affinité de session

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

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

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

Basculement

Si un backend n'est plus opérationnel, le trafic est automatiquement redirigé vers des backends opérationnels dans la même région. Si aucun des backends d'une région n'est opérationnel, le trafic est distribué aux backends opérationnels d'autres régions (niveau Premium uniquement). Si aucun des backends n'est opérationnel, l'équilibreur de charge affiche une réponse HTTP 502 Bad Gateway.

Assistance WebSocket

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

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

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

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

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

Compatibilité avec les protocoles HTTP/3 et QUIC

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

à savoir :

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

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

Configurer le protocole HTTP/3

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

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

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

Valeur quicOverride Comportement
NONE

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

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

ENABLE

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

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

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

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

Console : HTTPS

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

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

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

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

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

Activer le protocole HTTP/3

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

Désactiver le protocole HTTP/3

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

gcloud : HTTPS

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

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

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

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

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

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

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

API : HTTPS

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

{
  "quicOverride": QUIC_SETTING
}

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

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

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

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

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

Négociation du protocole HTTP/3

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

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

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

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

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

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

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

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

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

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. Vous pouvez utiliser des règles SSL pour modifier ce comportement par défaut et contrôler la manière dont votre équilibreur de charge négocie SSL avec les clients.

Lorsque l'équilibreur de charge HTTP(S) externe utilise HTTPS comme protocole de service de backend, il peut négocier les protocoles TLS 1.0, 1.1 ou 1.2 vers le backend.

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

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

Limites liées à HTTP/2

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

Restriction concernant Cloud CDN

  • Vous ne pouvez pas activer à la fois Identity-Aware Proxy et Cloud CDN sur le même service de backend. Si vous tentez de le faire, le processus de configuration échoue.

Étape suivante