Expiración del seguimiento de conexiones en grupos de seguridad de la nube Cloud security group connection tracking timeout
ID de la causa dc-cloud-conntrack · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de cliente (Equipo de desarrollo), Desarrollo de servidor (Equipo de desarrollo)
El firewall asociado a un servidor en la nube (grupo de seguridad) también hace seguimiento de las conexiones, y la entrada de seguimiento de una conexión inactiva expira pasado cierto tiempo. Incluso en servidores a los que se conecta directamente, sin balanceador de carga, un jugador que estuvo quieto puede sufrir una desconexión.
Por qué El grupo de seguridad está configurado de forma que hace seguimiento de las conexiones del juego (solo se permiten ciertas direcciones, reglas de salida restringidas, paso por un NLB, etc.) → Efecto La entrada de seguimiento de una conexión que pasó un rato inactiva expira, y el grupo de seguridad descarta en silencio los paquetes que llegan después → En pantalla Tras estar ausente, el jugador vuelve a moverse, no hay respuesta y llega la desconexión. El programa del servidor tarda mucho en enterarse
Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de cliente (Equipo de desarrollo), Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Cliente: enviar heartbeats a intervalos de como mucho la mitad del timeout por inactividad más corto (175 s o menos si son 350 s en TCP, 90 s o menos si son 180 s en streams UDP), reconectar automáticamente si se corta. Servidor: responder a los heartbeats y cerrar primero la conexión si no llegan durante cierto tiempo, retomar la sesión con un token de sesión.
Tareas (Equipo de infraestructura)
Revisar el tiempo de seguimiento de conexiones de la instancia (TcpEstablishedTimeout) y ampliarlo si hace falta (en UDP no se puede, porque 180 s ya es el máximo), estudiar una configuración del grupo de seguridad que no genere seguimiento (puertos del juego abiertos a todas las direcciones y todas las salidas permitidas; las conexiones que pasan por un NLB se siguen igualmente), hacer pruebas de inactividad al migrar a una nueva generación de instancias.
Cifras de referencia
En AWS, los tipos de instancia Nitro v6 borran por defecto la entrada de seguimiento de una conexión TCP inactiva a los 350 segundos (5 días en los demás tipos). En UDP, el valor por defecto es de 180 segundos para los flujos con varios intercambios de solicitud y respuesta (streams) y de 30 segundos para los flujos que fueron en un solo sentido o tuvieron una sola solicitud y respuesta.
En el gráfico
Desconexión masiva · Desconexiones, tiempo inactivo antes de la desconexión
Dónde mirar
Revisar el tiempo de seguimiento configurado en la instancia y las reglas del grupo de seguridad (si la configuración genera seguimiento), y reunir el tiempo inactivo de las conexiones cortadas. Justo después de una desconexión, ver con ss -tnoi en el servidor si esa conexión sigue en ESTABLISHED con el temporizador de retransmisión (timer:(on,…)) activo y un backoff cada vez mayor
Se confirma si
El tiempo inactivo de las conexiones cortadas se concentra justo después de 350 s en TCP, 180 s en streams UDP o 30 s en UDP de un solo sentido, y el socket del servidor sigue en ESTABLISHED sin detectar el corte (si el servidor tiene datos que enviar, solo repite retransmisiones)
Se descarta si
Si el grupo de seguridad no hace seguimiento (puertos del juego abiertos a todas las direcciones, todas las salidas permitidas, sin pasar por un NLB), no es esta causa. Si pasa por un NLB, comparar los valores con “Timeout por inactividad del balanceador de carga”
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Fuentes
Amazon EC2 security group connection trackingAWS Seguimiento de TCP inactivo: 350 s por defecto (Nitro v6; 432,000 s = 5 días en los demás), UDP en un solo sentido 30 s y stream 180 s (máximo 180); las reglas que permiten todas las direcciones no generan seguimiento; las conexiones que pasan por un NLB siempre se siguen
ss(8) — Linux manual pageiproute2 En -o, timer:(on,…) es el temporizador de retransmisión; en -i, backoff es el número de veces que la espera de retransmisión se ha duplicado