Tiempo de espera de inactividad y restablecimiento de TCP de Load Balancer

Puede usar Standard Load Balancer para crear un comportamiento de aplicación más predecible para los escenarios si habilita el restablecimiento de TCP inactivo para una regla determinada. El comportamiento predeterminado de Load Balancer es descartar silenciosamente los flujos cuando se alcanza el tiempo de inactividad de un flujo. Habilitar el restablecimiento de TCP hace que Load Balancer envíe restablecimientos de TCP bidireccionales (paquetes de restablecimiento de TCP) en el tiempo de espera de inactividad para informar a los puntos de conexión de la aplicación de que se agota el tiempo de espera de la conexión y ya no es posible su uso. De ser necesario, los puntos de conexión pueden establecer una conexión nueva inmediatamente.

Diagrama que muestra el comportamiento predeterminado de restablecimiento de TCP para los nodos de red.

Restablecimiento de TCP

Puede cambiar este comportamiento predeterminado y habilitar el envío de restablecimientos de TCP al agotarse el tiempo de espera de inactividad en las reglas NAT de entrada, en las reglas de equilibrio de carga y en las reglas de salida. Cuando se habilita en cada regla, Load Balancer enviará restablecimientos TCP bidireccionales (paquetes TCP RST) tanto a los puntos de conexión del cliente como a los del servidor en el momento en que se agote el tiempo de espera de inactividad para todos los flujos que correspondan.

Los puntos de conexión que reciben paquetes TCP RST cierran inmediatamente el socket correspondiente. De este modo, se proporciona una notificación inmediata a la versión de la conexión de los puntos de conexión y cualquier comunicación posterior en la misma conexión TCP generará un error. Las aplicaciones pueden purgar las conexiones cuando el socket se cierra y restablecer las conexiones según sea necesario sin tener que esperar que la conexión TCP, finalmente, agote el tiempo de espera.

En muchos escenarios, un restablecimiento TCP puede reducir la necesidad de enviar keepalives TCP (o de capa de aplicación) para actualizar el tiempo de espera de inactividad de un flujo.

Elige entre el restablecimiento de TCP y los mensajes de mantenimiento

Utiliza los siguientes criterios para decidir qué mecanismo necesita tu situación:

  • Habilita el reinicio de TCP cuando quieras que los puntos de conexión reciban una notificación inmediata de que se ha cerrado un flujo inactivo, para que las aplicaciones puedan eliminar y restablecer las conexiones en lugar de esperar a que se agote su propio tiempo de espera de TCP.
  • Utiliza los keepalives de TCP cuando tus periodos de inactividad superen el intervalo configurable de tiempo de espera de inactividad, o cuando tu aplicación se comporte de forma inesperada con los restablecimientos TCP habilitados. No se recomienda Keepalives para aplicaciones móviles, porque consumen la batería del dispositivo más rápido.
  • Utiliza las señales de mantenimiento de conexión de la capa de aplicación cuando la conexión pasa por un proxy en algún punto del trayecto, porque un proxy puede cerrar la conexión TCP que renuevan las señales de mantenimiento de conexión de la capa de transporte.

Examinando cuidadosamente todo el escenario de extremo a extremo, puedes determinar los beneficios de habilitar los reinicios TCP y ajustar el tiempo de espera de inactividad. Luego decida si se requieren más pasos para asegurar el comportamiento deseado de la aplicación.

Tiempo de espera de inactividad de TCP configurable

Azure Load Balancer Standard tiene un rango de tiempo de espera de 4 minutos a 100 minutos para las reglas de balanceador de carga y las reglas NAT entrantes. Las reglas de salida tienen un rango configurable de 4 a 120 minutos. El valor predeterminado es 4 minutos para todos los tipos de reglas. Si un período de inactividad es mayor que el valor de tiempo de espera, no hay ninguna garantía de que todavía exista la sesión TCP o HTTP entre el cliente y el servicio en la nube. Azure Load Balancer Basic (retirado) tenía un rango de tiempo de espera de hasta 60 minutos.

Cuando se cierre la conexión, la aplicación cliente podría recibir un mensaje de error similar a "Se ha terminado la conexión subyacente: una conexión que se esperaba que se mantuviera activa fue cerrada por el servidor".

Si los restablecimientos de TCP están habilitados y se pierden por cualquier motivo, se enviarán para cualquier paquete posterior. Si la opción de restablecimiento de TCP no está habilitada, los paquetes se quitan silenciosamente.

Una práctica común es usar TCP Keep-alive. Esta práctica mantiene la conexión activa durante un periodo más largo. Para obtener más información, consulte estos ejemplos de .NET. Con Keep-alive habilitado, los paquetes se envían durante los periodos de inactividad en la conexión. Los paquetes de Keep-alive garantizan que no se alcance el valor de tiempo de espera de inactividad y la conexión se mantenga durante un largo período.

El sistema TCP keep-alive descrito en esta sección se aplica únicamente a conexiones entrantes. El reinicio de TCP y el tiempo de espera de inactividad configurable se admiten por separado en las reglas de salida. Para evitar la pérdida de la conexión, configure el TCP keep-alive con un intervalo menor que el valor de tiempo de espera de inactividad o aumentar el valor de tiempo de espera de inactividad. Para admitir estos escenarios, está disponible la compatibilidad con un tiempo de espera de inactividad configurable.

TCP keep-alive funciona en escenarios donde la batería no supone una restricción. No se recomienda para aplicaciones móviles. El uso de TCP Keep-alive desde una aplicación móvil puede agotarla batería del dispositivo más rápidamente.

Orden de precedencia

Es importante tener en cuenta cómo podrían interactuar los valores de tiempo de espera de inactividad establecidos para diferentes direcciones IP.

Entrada

  • Si hubiera una regla de equilibrador de carga (de entrada) con un valor de tiempo de espera de inactividad establecido de forma diferente al del tiempo de espera de inactividad de la dirección IP de front-end a la que hace referencia, el tiempo de espera de inactividad de la IP de front-end del equilibrador de carga tendrá prioridad.
  • Si hubiera una regla NAT de entrada con un valor de tiempo de espera de inactividad establecido de forma diferente al del tiempo de espera de inactividad de la dirección IP de front-end a la que hace referencia, el tiempo de espera de inactividad de la IP de front-end del equilibrador de carga tendrá prioridad.

Salida

  • Si hubiera una regla de salida con un valor de tiempo de espera de inactividad distinto de 4 minutos (que es el tiempo de espera de inactividad de salida de la dirección IP pública en el que se produce un bloqueo), el tiempo de espera de inactividad de la regla de salida tendrá prioridad.
  • Dado que una puerta de enlace NAT siempre tendrá prioridad sobre las reglas de salida del equilibrador de carga (y sobre las direcciones IP públicas asignadas directamente a las VM), se usará el valor de tiempo de espera de inactividad asignado a la puerta de enlace NAT. (A lo largo de las mismas líneas, no se tienen en cuenta los tiempos de espera de inactividad de salida de dirección IP pública bloqueados de 4 minutos de cualquier dirección IP asignada a la puerta de enlace de NAT).

Limitaciones

Estas limitaciones se aplican al reinicio TCP y al tiempo de espera en Azure Load Balancer:

  • El restablecimiento de TCP solo se envía durante la conexión TCP en el estado ESTABLECIDO.
  • El timeout de inactividad no está soportado para las reglas de balanceo de carga UDP.
  • No se admite el reinicio de TCP para las reglas de puertos de alta disponibilidad (HA) del equilibrador de carga interno cuando un dispositivo virtual de red (NVA) se encuentra en la ruta. Como solución alternativa, utiliza una regla de salida con restablecimiento de TCP desde el dispositivo virtual de red.
  • El tiempo de espera de inactividad de TCP no se admite para las reglas de puertos de alta disponibilidad (HA) del equilibrador de carga interno cuando una ruta definida por el usuario (UDR) reenvía el tráfico al equilibrador de carga interno.

Pasos siguientes

  • Last updated on