Concepts d'équilibrage de charge HTTP(S)

Ce document présente les concepts que vous devez maîtriser pour configurer l'équilibrage de charge HTTP ou HTTPS.

Principes de base

Un équilibreur de charge HTTP(S) repose sur plusieurs composants. Le schéma suivant illustre l'architecture d'un équilibreur de charge HTTP(S) complet :

Schéma de l'équilibrage de charge interrégional et basé sur le contenu (cliquez sur l'image pour l'agrandir)
Schéma de l'équilibrage de charge interrégional et basé sur le contenu (cliquez sur l'image pour l'agrandir)

Dans les sections suivantes, nous allons voir comment ces composants interagissent dans le cadre des différents types d'équilibreurs de charge. Pour obtenir une description détaillée de chaque composant, reportez-vous à la section Composants ci-dessous.

Équilibrage de charge HTTP

Un équilibreur de charge HTTP complet est structuré de la manière suivante :

  1. Une règle de transfert dirige les requêtes entrantes vers un proxy HTTP cible.
  2. Le proxy HTTP cible analyse chaque requête par rapport à un mappage d'URL afin de déterminer le service de backend approprié pour la requête.
  3. Le service de backend dirige chaque requête vers un backend adéquat en fonction de la capacité de traitement, de la zone et de l'état de fonctionnement des instances des backends qui lui sont associés. L'état de chaque instance backend est contrôlé à l'aide d'une vérification d'état HTTP, HTTPS ou HTTP/2. Si le service de backend est configuré pour utiliser une vérification d'état HTTPS ou HTTP/2, la requête est chiffrée pour être acheminée vers l'instance backend.
  4. Les sessions entre l'équilibreur de charge et l'instance peuvent utiliser le protocole HTTP, HTTPS ou HTTP/2. Si vous utilisez HTTPS ou HTTP/2, chaque instance des services de backend doit posséder un certificat SSL.

Équilibrage de charge HTTPS

Un équilibreur de charge HTTPS présente la même structure de base qu'un équilibreur de charge HTTP (décrit ci-dessus), mais il en diffère par les éléments suivants :

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 proprement dit. Toutefois, vous pouvez configurer certains clients pour qu'ils utilisent HTTP 1.1 au lieu de HTTP/2. Par exemple, avec curl, utilisez l'indicateur --http1.1.
  • Les équilibreurs de charge HTTPS n'acceptent pas l'authentification basée sur un certificat client, également appelée authentification TLS mutuelle.

Ports ouverts

Les équilibreurs de charge HTTP(S) 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. La fonctionnalité de proxy inverse est fournie par Google Front Ends (GFE).

Les règles de pare-feu que vous définissez bloquent le trafic entre les GFE et les backends, mais elles ne bloquent pas le trafic entrant vers les GFE.

Les équilibreurs de charge HTTP(S) offrent un certain nombre de ports ouverts pour les autres services Google exécutés sur la même architecture. Si vous effectuez une analyse de sécurité ou de port sur l'adresse IP externe d'un équilibreur de charge HTTP(S), vous allez constater que des ports supplémentaires semblent être ouverts.

Cela n'affecte en rien les équilibreurs de charge HTTP. Les règles de transfert externes utilisées dans la définition d'un équilibreur de charge HTTP(S) ne peuvent faire référence qu'aux ports TCP 80, 8080 et 443. Le trafic associé aux autres ports de destination TCP n'est pas transféré vers le backend de l'équilibreur de charge.

Composants

Les éléments présentés ci-dessous sont les composants des équilibreurs de charge HTTP(S).

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 basé sur le DNS n'est requis. Vous pouvez soit spécifier une adresse IP qui sera utilisée par le service, soit laisser Google 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.

Proxys cibles

Les proxys cibles interrompent les connexions HTTP(S) des clients. Une ou plusieurs règles de transfert globales 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-Forwarded-For: <unverified IP(s)>, <immediate client IP>, <global forwarding rule external IP>, <proxies running in GCP> (requêtes uniquement) : liste d'adresses IP séparées par des virgules, ajoutées par les intermédiaires ayant acheminé la requête. Si vous exécutez des proxys dans GCP qui ajoutent des données à l'en-tête X-forwarded-For, votre logiciel doit tenir compte de l'existence et du nombre de ces proxys. Seules les entrées IP <immediate client IP> (adresse IP du client immédiat) et <global forwarding rule external IP> (adresse IP externe de la règle de transfert globale) sont fournies par l'équilibreur de charge. Toutes les autres entrées de la liste sont transmises sans validation. L'entrée <immediate client IP> correspond au client qui s'est connecté directement à l'équilibreur de charge. L'entrée <global forwarding rule external IP> est l'adresse IP externe associée à la règle de transfert de l'équilibreur de charge. S'il y a davantage d'entrées, la première entrée de la liste correspond à l'adresse du client d'origine. Les autres entrées figurant avant <immediate client IP> représentent d'autres proxys ayant transmis la requête à l'équilibreur de charge.
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (requêtes uniquement)
    Paramètres pour Stackdriver Trace.

Vous pouvez créer des en-têtes de requête 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 section Créer des en-têtes de requête définis par l'utilisateur.

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 apparaître au niveau du client sous la forme server: Apache/1.0.

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 certaines situations, par exemple celle décrite dans l'exemple d'équilibrage de charge interré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 l'acheminement du trafic basé sur le contenu, le mappage d'URL vous permet de répartir votre trafic en examinant les éléments constituant l'URL afin d'envoyer les 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. Vous pouvez mettre en place jusqu'à quinze (15) certificats SSL. Ils sont utilisés par les proxys HTTPS cibles pour authentifier les communications entre l'équilibreur de charge et le client. Il peut s'agir de certificats SSL autogérés ou gérés par Google.

Pour plus d'informations sur l'installation de certificats SSL pour un équilibreur de charge HTTPS, reportez-vous à la page Certificats SSL.

Si vous utilisez HTTPS ou HTTP/2 depuis l'équilibreur de charge vers les backends, vous devez installer des certificats SSL sur chaque instance de VM. Pour installer des certificats SSL sur une instance de VM, suivez les instructions fournies dans la documentation de votre application. Ces certificats peuvent être autosignés.

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.

Contrôle géographique des emplacements où le protocole TLS est interrompu

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 GCP, et interrompre le protocole TLS sur les backends situés dans les régions correspondant à vos besoins.

Services backend

Les services de backend fournissent des informations de configuration à l'équilibreur de charge. Un équilibreur de charge HTTP(S) doit comporter au moins un service de backend, et il peut en avoir plusieurs.

Les équilibreurs de charge utilisent les informations d'un service de backend pour rediriger le trafic entrant vers un ou plusieurs backends associés.

Chaque backend est composé d'un groupe d'instances et de métadonnées de capacité de diffusion supplémentaires. La capacité de diffusion du backend peut être basée sur l'utilisation du processeur ou sur le nombre de requêtes par seconde (RPS).

L'équilibrage de charge HTTP(S) est compatible avec l'autoscaler Cloud Load Balancing, qui permet aux utilisateurs d'effectuer un autoscaling sur les groupes d'instances d'un service de backend. Pour en savoir plus, consultez la page Scaling basé sur la capacité de diffusion de l'équilibrage de charge HTTP(S).

Vous pouvez activer le drainage de connexion sur les services de backend afin de garantir à vos utilisateurs un temps d'interruption minimal dans le cas où une instance assurant la diffusion du trafic est arrêtée, supprimée manuellement ou supprimée par un autoscaler. Pour en savoir plus sur le drainage de connexion, consultez la documentation Activer le drainage de connexion.

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 35.191.0.0/16 à accéder à vos instances.

Pour en savoir plus, consultez les pages Concepts de la vérification de l'état et 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), 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.

Utilisez une vérification d'état HTTP/2 si vous utilisez HTTP/2 sur les VM de backend.

Utiliser gRPC avec vos applications Google Cloud Platform

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

Si vous souhaitez configurer un équilibreur de charge HTTP(S) utilisant HTTP/2 avec un objet Entrée Google Kubernetes Engine, consultez HTTP/2 pour l'équilibrage de charge avec l'objet Entrée.

Vous pouvez également utiliser gRPC et HTTP/2 avec un objet Entrée. Pour plus d'informations, consultez la section HTTP/2 pour l'équilibrage de charge avec l'objet Entrée.

Pour plus d'informations 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 vers les backends. Pour plus d'informations sur les limitations du protocole HTTP/2, consultez la section Limitations de HTTP/2.

Buckets backend

Les buckets backend dirigent le trafic entrant vers des buckets Google Cloud Storage. Pour voir un exemple illustrant l'ajout d'un bucket à un équilibreur de charge existant, consultez la page Ajouter des buckets Cloud Storage à des équilibreurs de charge.

Règles de pare-feu

Vous devez créer une règle de pare-feu autorisant le trafic provenant de 130.211.0.0/22 et 35.191.0.0/16 à accéder à vos instances. Il s'agit des plages d'adresses IP utilisées par l'équilibreur de charge pour se connecter aux instances backend. Cette règle autorise le trafic en provenance de l'équilibreur de charge et de la vérification d'état. La règle doit autoriser le trafic sur le port configuré pour votre règle de transfert globale et votre vérification d'état doit être configurée pour utiliser le même port. Si votre vérification d'état utilise un autre port, vous devez créer une autre règle de pare-feu pour ce port.

Notez que les règles de pare-feu permettent de bloquer ou d'autoriser le trafic au niveau des instances, et non en périphérie de réseau. Elles ne peuvent pas empêcher le trafic d'atteindre l'équilibreur de charge proprement dit.

Si vous devez identifier des adresses IP externes à un instant donné, suivez les instructions décrites dans les Questions fréquentes sur Google Compute Engine.

Chemin de retour

Pour les vérifications d'état, GCP utilise des routages spéciaux non définis dans votre réseau VPC. Pour obtenir des informations complètes à ce sujet, consultez la documentation relative aux Chemins de retour des équilibreurs de charge.

Algorithme de répartition de la charge

L'équilibrage de charge HTTP(S) fournit deux méthodes pour déterminer la charge d'une instance. Dans la ressource de service de backend, la propriété balancingMode définit le mode d'équilibrage de la charge, à partir de l'utilisation du processeur ou du nombre de requêtes par seconde (RPS). Ces deux modes permettent de spécifier une valeur maximale. L'équilibreur de charge HTTP(S) tente de s'assurer que la charge reste inférieure à la limite, mais de brefs dépassements peuvent se produire lors d'événements de basculement ou de pics de charge.

Les requêtes entrantes sont envoyées à la région la plus proche de l'utilisateur, si cette région dispose de la capacité requise. Si plusieurs zones sont configurées avec des backends au sein d'une région, le comportement par défaut de l'algorithme consiste à répartir le trafic entre les groupes d'instances dans chaque zone en fonction de la capacité de chaque groupe. Au sein d'une zone, les requêtes sont réparties uniformément sur les instances du groupe à l'aide d'un algorithme à répétition alternée (round-robin). Vous pouvez modifier ce comportement en configurant l'affinité de session. Toutefois, notez que l'affinité de session est plus efficace si vous définissez également le mode d'équilibrage sur le nombre de requêtes par seconde (RPS).

Pour consulter des exemples spécifiques concernant l'algorithme de distribution de la charge, consultez la page Fonctionnement de l'équilibrage de charge HTTP(S).

Affinité de session

L'affinité de session permet d'envoyer toutes les requêtes d'un même client à la même instance de machine virtuelle, sous réserve que l'instance soit saine et dispose d'une capacité suffisante.

Dans GCP, l'équilibrage de charge HTTP(S) propose deux types d'affinité de session :

Compatibilité du proxy WebSocket

Le protocole d'équilibrage des charges HTTP est compatible en mode natif avec le protocole WebSocket. Les backends employant WebSocket pour communiquer avec les clients peuvent utiliser l'équilibreur de charge HTTP(S) comme frontal à des fins d'évolutivité et de disponibilité. L'équilibreur de charge ne nécessite aucune configuration supplémentaire pour relayer les connexions WebSocket.

Le protocole WebSockets, défini dans le document RFC 6455, fournit un canal de communication en duplex intégral entre un client et un serveur. Le canal est mis en place à partir d'une requête HTTP(S).

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

Le délai d'expiration d'une connexion WebSocket dépend du délai avant expiration de la réponse configurable sur l'équilibreur de charge, qui est de 30 secondes par défaut. Ce délai est appliqué aux connexions WebSocket, qu'elles soient utilisées ou non. Pour plus d'informations sur le délai avant expiration de la réponse et sur sa configuration, reportez-vous à la section Délais d'expiration et nouvelles tentatives.

Si vous avez configuré l'affinité de session basée sur les adresses IP client ou sur les cookies générés pour votre équilibreur de charge HTTP(S), toutes les connexions WebSocket d'un même client sont envoyées à la même instance backend tant que ses vérifications d'état réussissent et qu'elle dispose de la capacité nécessaire.

Le protocole WebSocket est compatible avec les objets Entrée.

Utiliser le protocole QUIC pour l'équilibrage de charge HTTPS

L'équilibrage de charge HTTPS est compatible avec le protocole QUIC dans le cadre des connexions entre l'équilibreur de charge et les clients. QUIC 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. QUIC 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.

QUIC affecte les connexions entre les clients et l'équilibreur de charge, et non les connexions entre l'équilibreur de charge et les backends.

Le paramètre de remplacement QUIC du proxy cible vous permet d'activer l'un des éléments suivants :

  • lorsque c'est possible, négocier le protocole QUIC pour un équilibreur de charge OU
  • toujours désactiver QUIC pour un équilibreur de charge.

Si vous ne spécifiez pas de paramètre de remplacement QUIC, vous autorisez Google à gérer l'utilisation de QUIC. Google n'active pas QUIC lorsqu'aucun remplacement n'est spécifié. Pour plus d'informations sur l'activation et la désactivation de la compatibilité QUIC, consultez la documentation sur les Proxys cibles. Vous pouvez également activer QUIC lorsque vous créez un équilibreur de charge HTTPS à l'aide de la console Google Cloud Platform ou le désactiver lorsque vous modifiez la configuration de l'équilibreur de charge dans la console Google Cloud Platform.

Négociation du protocole QUIC

Lorsque vous activez QUIC, l'équilibreur de charge HTTPS peut annoncer sa capacité QUIC aux clients, ce qui permet aux clients compatibles de tenter d'établir des connexions QUIC avec lui. Les clients correctement mis en œuvre peuvent toujours revenir au protocole HTTPS ou HTTP/2 lorsqu'ils ne parviennent pas à établir une connexion QUIC. 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.

Lorsque QUIC est activé dans 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 de QUIC qui ne sont pas compatibles avec celles prises en charge 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 QUIC.
  • Si QUIC est désactivé de manière temporaire au niveau des équilibreurs de charge HTTPS en réponse à des bugs, des vulnérabilités ou d'autres problèmes.

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 QUIC, assurez-vous que les comportements décrits ci-dessus sont acceptables pour vos charges de travail.

Interfaces

Votre service d'équilibrage de charge HTTP(S) peut être configuré et mis à jour à travers les interfaces suivantes :

  • L'outil de ligne de commande gcloud : outil de ligne de commande inclus dans le SDK Cloud. Dans la documentation sur l'équilibrage de charge HTTP(S), l'exécution de nombreuses tâches fait appel à cet outil. Pour une présentation complète de l'outil, consultez le guide de l'outil gcloud. Vous trouverez des commandes associées à l'équilibrage de charge dans le groupe de commandes gcloud compute.

    Vous pouvez également obtenir une aide détaillée pour n'importe quelle commande gcloud à l'aide de l'indicateur --help :

    gcloud compute http-health-checks create --help
    
  • La console Google Cloud Platform : les tâches d'équilibrage de charge peuvent être effectuées via la console Google Cloud Platform.

  • L'API REST : toutes les tâches d'équilibrage de charge peuvent être réalisées à l'aide de l'API Google Cloud Load Balancing. La documentation de référence de l'API décrit les ressources et les méthodes mises à votre disposition.

Compatibilité avec TLS

Par défaut, lorsqu'il interrompt les requêtes SSL des clients, un proxy HTTPS cible accepte uniquement les protocoles TLS 1.0, 1.1 et 1.2. 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 HTTPS négocie SSL avec les clients.

Lorsque l'équilibreur de charge utilise HTTPS en tant que protocole de service de backend, il peut négocier les protocoles TLS 1.0, 1.1 ou 1.2 vers le backend.

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 de la réponse HTTP configurable, qui représente la durée pendant laquelle l'équilibreur de charges attend une réponse HTTP complète de la part de votre backend. Il ne s'agit pas d'un délai d'inactivité HTTP (keepalive). La valeur par défaut est de 30 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 la connexion est mise à jour vers une connexion WebSocket.

    Pour le trafic WebSocket envoyé via un équilibreur de charge HTTP(S) GCP, le délai d'expiration du service de backend est interprété comme la durée maximale pendant laquelle une connexion WebSocket peut rester ouverte, qu'elle soit inactive ou non. Pour plus d'informations, reportez-vous à 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 d'expiration ne s'applique pas aux connexions WebSockets.

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 Réglage 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'équilibrage de charge HTTP(S) à effectuer de nouvelles tentatives, par exemple lorsqu'il y a expiration du délai de réponse. 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. Pour plus d'informations, reportez-vous à la documentation de la Journalisation.

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

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

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 combinée de l'URL de requête et des en-têtes dépasse 15 Ko.
  • 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 128 Ko.
  • La version de HTTP est inconnue.

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…