Réinitialisation TCP de l’équilibreur de charge et délai d’inactivité

Vous pouvez utiliser Standard Load Balancer pour créer un comportement d’application plus prévisible pour vos scénarios en activant Réinitialisation TCP pendant le délai d'inactivité pour une règle donnée. Le comportement par défaut de Load Balancer consiste à supprimer silencieusement des flux lorsque le délai d’inactivité d’un flux est atteint. L’activation de la réinitialisation TCP entraîne l’envoi par l’équilibreur de charge de réinitialisations TCP bidirectionnelles (paquets de réinitialisation TCP) lors du délai d’inactivité pour informer vos points de terminaison d’application que la connexion a expiré et n’est plus utilisable. Les points de terminaison peuvent immédiatement établir une nouvelle connexion, si besoin.

Schéma montrant le comportement de réinitialisation TCP par défaut des nœuds réseau.

Réinitialisation du protocole TCP

Vous modifiez ce comportement par défaut et activez l’envoi des réinitialisations TCP pendant un délai d’inactivité, sur des règles NAT entrantes, des règles d’équilibrage de charge et des règles de trafic sortant. Lorsqu’il est activé par règle, Load Balancer envoie des réinitialisations TCP bidirectionnelles (paquets TCP RST) aux points de terminaison client et serveur pendant le délai d’inactivité de tous les flux correspondants.

Les points de terminaison recevant des paquets TCP RST ferment immédiatement le socket correspondant. Cela signale immédiatement la fermeture de la connexion du point de terminaison, et toute communication ultérieure sur cette même connexion TCP échouera. Les applications peuvent purger les connexions lorsque le socket se ferme, et les rétablir en fonction des besoins sans attendre que la connexion TCP finisse par expirer.

Pour de nombreux scénarios, une réinitialisation TCP peut réduire la nécessité d’envoyer des keepalives TCP (ou couche application) pour actualiser le délai d’inactivité d’un flux.

Choisissez entre la réinitialisation de TCP et les keepalives

Utilisez les critères suivants pour décider du mécanisme dont votre scénario a besoin :

  • Activez la réinitialisation TCP lorsque vous souhaitez que les terminaux soient informés immédiatement qu’un flux inactif est fermé, afin que les applications puissent purger et rétablir les connexions au lieu d’attendre leur propre délai TCP.
  • Utilisez les keepalives TCP lorsque vos périodes d’inactivité dépassent la plage configurable du délai d’expiration d’inactivité, ou lorsque votre application se comporte de manière inattendue lorsque les réinitialisations TCP sont activées. Les Keepalives ne sont pas recommandés pour les applications mobiles, car ils consomment plus rapidement la batterie de l’appareil.
  • Utilisez des keepalives de couche application lorsque la connexion passe par un proxy quelque part sur le chemin, car un proxy peut mettre fin à la connexion TCP que les keepalives de couche transport actualisent.

En examinant attentivement l’ensemble du scénario de bout en bout, vous pouvez déterminer les avantages d’activer les réinitialisations TCP et d’ajuster le délai d’attente au repos. Ensuite, décidez si d’autres étapes sont nécessaires pour assurer le comportement souhaité de l’application.

Délai d’inactivité TCP configurable

Azure Load Balancer Standard propose une plage de temps d’attente de 4 minutes à 100 minutes pour les règles d’équilibrage de charge et les règles NAT entrantes. Les règles sortantes ont une plage configurable de 4 à 120 minutes. Par défaut, c’est 4 minutes pour tous les types de règles. Si une période d’inactivité est supérieure à la valeur de délai d’expiration, il n’est pas garanti que la session TCP ou HTTP est maintenue entre le client et votre service cloud. Azure Load Balancer Basic (retiré) avait une plage de temps pouvant atteindre 60 minutes.

Lorsque la connexion est fermée, votre application cliente peut recevoir un message d’erreur de ce type : « Le serveur a clos la connexion sous-jacente : Le serveur a fermé une connexion qui devait être maintenue active ».

Si les réinitialisations TCP sont activées et que, pour une raison quelconque, l’une d’elles n’est pas effectuée, des réinitialisations sont appliquées à tous les paquets suivants. Si l’option de réinitialisation TCP n’est pas activée, les paquets sont supprimés en mode silencieux.

Une pratique courante consiste à utiliser TCP keep-alive. Cela permet de maintenir la connexion active pendant une période plus longue. Pour plus d’informations, consultez ces exemples .NET. avec keep-alive activé, les paquets sont envoyés au cours des périodes d’inactivité sur la connexion. Les paquets keep-alive garantissent que la valeur de délai d’inactivité n’est pas atteinte et que la connexion est maintenue pendant une longue période.

Le maintien en vie TCP décrit dans cette section s’applique uniquement aux connexions entrantes. La réinitialisation TCP et le délai d’inactivité configurable sont pris en charge séparément pour les règles sortantes. Pour éviter la perte de la connexion, configurez TCP keep-alive sur un intervalle inférieur au paramètre de délai d’inactivité ou augmentez la valeur du délai d’inactivité. Pour prendre en charge ces scénarios, la prise en charge d’un délai d’inactivité configurable est disponible.

TCP keep-alive convient aux scénarios où l’autonomie de la batterie n’est pas une contrainte. Il n’est pas recommandé de l’utiliser pour les applications mobiles. L’utilisation de TCP keep-alive depuis une application mobile peut décharger la batterie de l’appareil plus rapidement.

Ordre de priorité

Il est important de prendre en compte la façon dont les valeurs du délai d’inactivité définies pour différentes adresses IP peuvent éventuellement interagir.

Trafic entrant

  • S’il existe une règle d’équilibreur de charge (trafic entrant) avec une valeur du délai d’inactivité définie différemment du délai d’inactivité de l’adresse IP front-end qu’elle référence, le délai d’inactivité de l’adresse IP front-end de l’équilibreur de charge est prioritaire.
  • S’il existe une règle NAT de trafic entrant avec une valeur du délai d’inactivité définie différemment du délai d’inactivité de l’adresse IP front-end qu’elle référence, le délai d’inactivité de l’adresse IP front-end de l’équilibreur de charge est prioritaire.

Règle de trafic sortant

  • S’il existe une règle de trafic sortant avec une valeur de délai d’inactivité différente de 4 minutes (qui correspond à la valeur fixe du délai d’inactivité du trafic sortant de l’IP publique), le délai d’inactivité de la règle de trafic sortant prévaut.
  • Étant donné qu’une passerelle NAT est toujours prioritaire sur les règles de trafic sortant des équilibreurs de charge (et sur les adresses IP publiques affectées directement aux machines virtuelles), la valeur de délai d’inactivité affectée à la passerelle NAT est utilisée. (Dans le même sens, les délais d’inactivité de trafic sortant d’adresse IP publique verrouillés de 4 minutes de toutes les adresses IP affectées au GW NAT ne sont pas pris en compte.)

Limites

Ces limitations s’appliquent à la réinitialisation TCP et au délai d’attente sur Azure Load Balancer :

  • La réinitialisation TCP n’est envoyée que pendant une connexion TCP en état ÉTABLI.
  • Le délai d’inactivité n’est pas pris en charge pour les règles d’équilibrage de charge UDP.
  • La réinitialisation TCP n’est pas prise en charge pour les règles de ports haute disponibilité (HA) de l’équilibreur de charge interne lorsqu’une appliance virtuelle réseau (NVA) se trouve sur le chemin. Comme solution de contournement, utilisez une règle sortante avec réinitialisation TCP depuis l’appliance réseau virtuelle.
  • Le délai d’inactivité TCP n’est pas pris en charge pour les règles de ports HA de l’équilibreur de charge interne lorsqu’une route définie par l’utilisateur (UDR) achemine le trafic vers l’équilibreur de charge interne.

Étapes suivantes

  • Last updated on