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

  • Article

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 TCP RST) lors du délai d’inactivité pour informer vos points de terminaison d’application de ce que la connexion a expiré et n’est plus utilisable. Les points de terminaison peuvent immédiatement établir une nouvelle connexion, si besoin.

Diagram shows default TCP reset behavior of network nodes.

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 les paquets TCP RST ferment aussitôt le socket correspondant. Une notification immédiate est fournie à la version de communication du point de terminaison et toute communication ultérieure sur cette même connexion TCP est vouée à l’échec. Les applications peuvent supprimer définitivement les connexions à la fermeture du socket, et les rétablir selon les besoins sans attendre le dépassement du délai d’expiration de la connexion TCP.

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

Si vos durées d’inactivité sont supérieures à celles autorisées par la configuration, ou si votre application présente un comportement indésirable lorsque les réinitialisations TCP sont activées, vous pouvez peut-être continuer à utiliser des conservations de connexion active TCP (ou des conservations de connexion active de la couche Application) pour surveiller l’activité des connexions TCP. De plus, les conservations de connexion active peuvent également se révéler utiles lorsque la connexion est transmise par proxy à un endroit quelconque sur le chemin, en particulier les conservations de connexion active de la couche Application.

En examinant attentivement le scénario de bout en bout, vous pouvez déterminer les avantages que présente l’activation des réinitialisations TCP et de l’ajustement du délai d’inactivité. Vous décidez ensuite si d’autres étapes peuvent être nécessaires pour garantir le comportement souhaité de l’application.

Délai d’inactivité TCP configurable

Azure Load Balancer a un délai d’expiration de 4 à 100 minutes pour les règles de Load Balancer, les règles de trafic sortant et les règles NAT de trafic entrant. La valeur par défaut est de 4 minutes. 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.

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

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 paramètre fonctionne uniquement pour les connexions entrantes. 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.

Entrante

  • 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 du délai d’inactivité différente de 4 minutes (ce qui correspond au délai d’inactivité du trafic sortant de l’adresse IP publique verrouillée), le délai d’inactivité de la règle de trafic sortant est prioritaire.
  • É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é verrouillés du trafic sortant de l’adresse IP publique de 4 minutes de toutes les adresses IP affectées au NAT GW ne sont pas pris en compte.)

Limites

  • Réinitialisation TCP envoyée uniquement au cours d’une connexion TCP dont l’état est ESTABLISHED.
  • Le délai d’inactivité TCP n’affecte pas les règles d’équilibrage de charge sur le protocole UDP.
  • La réinitialisation TCP n’est pas prise en charge pour les ports HA d’équilibrage de charge interne quand une appliance virtuelle réseau se trouve dans le chemin. Une solution de contournement consiste à utiliser une règle de trafic sortant avec la réinitialisation TCP à partir de l’appliance virtuelle réseau.

Étapes suivantes