Expiración del mapeo NAT o del balanceador de carga en mitad de la conexión NAT / load balancer mapping expired mid-connection
ID de la causa rt-mapping · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo), Infraestructura de red (Equipo de infraestructura), Infraestructura de servidores (Equipo de infraestructura)
Si un dispositivo intermedio borra el mapeo de una conexión inactiva (la entrada que indica a dónde reenviar esa conexión), el siguiente paquete que se envía no llega a su destino. O bien se repiten las retransmisiones hasta que la conexión se corta, o bien el dispositivo devuelve un rechazo de conexión (RST) y se corta al momento.
Por qué Conexión sin paquetes durante un buen rato (jugador ausente, en el lobby) → Efecto El NAT del router, el CGNAT del ISP, un firewall, un balanceador de carga o un grupo de seguridad en la nube borra el mapeo inactivo → En pantalla Al volver a moverse, retransmisiones seguidas y luego desconexión, o desconexión inmediata
Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo), Infraestructura de red (Equipo de infraestructura), Infraestructura de servidores (Equipo de infraestructura)
Tareas (Equipo de desarrollo)
Cliente: enviar heartbeats a intervalos de como mucho la mitad del timeout por inactividad más corto (los mapeos del router del jugador y del CGNAT del ISP solo se renuevan con seguridad con paquetes que salen desde dentro, y sus timeouts no los podemos cambiar, así que los envía el cliente), reconectar automáticamente si se corta. Servidor: responder a los heartbeats y cerrar la conexión por su cuenta si no los recibe durante cierto tiempo (acortar el intervalo del keepalive TCP con opciones de socket como TCP_KEEPIDLE, detectar antes con TCP_USER_TIMEOUT), retomar la sesión con un token de sesión.
Tareas (Equipo de infraestructura)
Red: reunir los timeouts por inactividad de los firewalls y balanceadores de carga de la ruta y compartirlos con el equipo de desarrollo, ampliarlos en nuestros firewalls y balanceadores si hace falta. Servidores/SO: comprobar el tiempo de seguimiento de conexiones de los grupos de seguridad en la nube y compartirlo con el equipo de desarrollo.
Cifras de referencia
El tiempo que se mantiene un mapeo TCP varía según el dispositivo, de unos minutos a varias horas. Si el grupo de seguridad en la nube hace seguimiento de la conexión, en los tipos de instancia Nitro v6 de AWS la entrada de seguimiento se borra por defecto a los 350 segundos (en los demás tipos, a los 5 días; ver la entrada “Expiración del seguimiento de conexiones en grupos de seguridad de la nube”). El keepalive TCP de Linux tiene como valor predeterminado “comprobar tras 2 horas de inactividad”, más tarde que la mayoría de los dispositivos.
En el gráfico
Desconexión masiva · Desconexiones, tiempo inactivo antes de la desconexión
Dónde mirar
Los últimos minutos de las conexiones cortadas con una captura de paquetes en el servidor, y el tiempo inactivo de las conexiones vivas con lastsnd y lastrcv de ss -ti (ms desde el último envío y la última recepción). También TcpExtTCPAbortOnTimeout de nstat (conexiones abandonadas al agotarse el temporizador)
Se confirma si
En cada conexión cortada, el tiempo inactivo previo superó un valor parecido (el timeout por inactividad de un dispositivo de la ruta; p. ej., 350 s en el grupo de seguridad de las instancias Nitro v6 de AWS), y desde el primer paquete tras la inactividad solo hay retransmisiones sin ACK hasta el abandono, o vuelve un RST al momento
Se descarta si
Si se corta también en plena partida, sin relación con el tiempo inactivo, es otra causa (“Cambio de ruta o ruta ECMP defectuosa”, “Descartes del firewall o del seguimiento de conexiones”). Si por la conexión pasan heartbeats a intervalos de como mucho la mitad del timeout por inactividad más corto, se descarta esta causa
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Fuentes
RFC 5382: NAT Behavioral Requirements for TCPIETF Recomendación de que el timeout por inactividad de las conexiones TCP en un NAT sea de al menos 2 horas y 4 minutos (partiendo de que los dispositivos pueden borrar antes las sesiones inactivas)
Amazon EC2 security group connection trackingAWS Timeout por inactividad del seguimiento TCP por defecto: 350 segundos en los tipos de instancia Nitro v6 y 432,000 segundos (5 días) en los demás. Recomendación de keepalive a intervalos menores de 5 minutos
IP SysctlLinux kernel tcp_keepalive_time: 2 horas por defecto
tcp(7) — Linux manual pageLinux man-pages TCP_KEEPIDLE (tiempo inactivo antes de empezar el keepalive), TCP_USER_TIMEOUT (tiempo que pueden quedar datos sin confirmar antes de que se cierre la conexión)
RFC 5482: TCP User Timeout OptionIETF Timeout de usuario de TCP: cuánto tiempo pueden quedar sin confirmar los datos enviados antes de cerrar la conexión
ss(8) — Linux manual pageiproute2 lastsnd y lastrcv de ss -i: tiempo transcurrido desde el último envío y la última recepción (ms)
SNMP counterLinux kernel TcpExtTCPAbortOnTimeout: conexiones abandonadas sin RST al agotarse un temporizador TCP