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

  • Artículo

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 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 los paquetes de restablecimiento de TCP 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, el restablecimiento de TCP puede evitar que haya que enviar paquetes keepalive de TCP (o en la capa de la aplicación) para actualizar el tiempo de inactividad de un flujo.

Si la duración de la inactividad superase los límites de configuración o la aplicación mostrase un comportamiento no deseado con los restablecimientos de TCP habilitados, es posible que siga siendo necesario usar paquetes keepalive de TCP o de la capa de la aplicación para supervisar el estado de las conexiones TCP. Además, los paquetes keepalive también pueden seguir siendo útiles cuando la conexión atraviesa un proxy en algún lugar de la ruta de acceso, especialmente en el caso de los paquetes keepalive de la capa de la aplicación.

Al examinar cuidadosamente todo el escenario de un extremo a otro, puede determinar las ventajas de habilitar los restablecimientos de TCP y ajustar el tiempo de espera de inactividad. A continuación, decidirá si se necesitarán más pasos para garantizar el comportamiento deseado de la aplicación.

Tiempo de espera de inactividad de TCP configurable

Azure Load Balancer Estándar tiene un intervalo de tiempo de espera de 4 a 100 minutos para las reglas de Load Balancer, las reglas de salida y las reglas NAT de entrada. El valor predeterminado es de 4 minutos. 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 Básico tiene un intervalo de tiempo de espera de hasta 30 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.

La configuración funciona solo para conexiones entrantes. 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 prioridad

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

Entrante

  • 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

  • El restablecimiento de TCP solo se envía durante la conexión TCP en el estado ESTABLECIDO.
  • El tiempo de espera de inactividad de TCP no afecta a las reglas de equilibrio de carga en el protocolo UDP.
  • El restablecimiento de TCP no es compatible con puertos de alta disponibilidad de Load Balancer internos cuando hay una aplicación virtual de red en la ruta de acceso. Una solución alternativa podría consistir en usar una regla de salida con el restablecimiento de TCP desde la aplicación virtual de red.

Pasos siguientes