Retransmisión de la solicitud de conexión (SYN) SYN retransmission on connect
ID de la causa rt-syn · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura), Infraestructura de red (Equipo de infraestructura), Desarrollo de cliente (Equipo de desarrollo)
Si una solicitud de conexión se pierde porque se desborda la cola de conexiones pendientes (backlog) o porque la bloquea un firewall, el SO del cliente la reenvía al cabo de 1 segundo y luego a intervalos cada vez más largos.
Por qué Justo después de un mantenimiento, una avalancha de conexiones desborda la cola de conexiones pendientes del servidor, o un firewall o la protección DDoS descarta los SYN → Efecto El SO del cliente retransmite el SYN a intervalos predefinidos a partir de 1 segundo (en los Linux antiguos, 1 s → 2 s → 4 s) → En pantalla Tras presionar el botón de conexión, la espera es de segundos exactos, como 1 o 3 s, y si sigue fallando, el juego no conecta o se queda en carga infinita
Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura), Infraestructura de red (Equipo de infraestructura), Desarrollo de cliente (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Servidor: aumentar el argumento backlog de listen (junto con somaxconn), hacer que el servidor del juego llame a accept a tiempo, implantar un sistema de cola de inicio de sesión. Cliente: alargar el intervalo entre reintentos de conexión (repartidos al azar).
Tareas (Equipo de infraestructura)
Servidores/SO: detectar el desbordamiento de la cola de conexiones pendientes con TcpExtListenOverflows y TcpExtListenDrops de nstat y con el aviso “Possible SYN flooding” del log, aumentar somaxconn (junto con el argumento de listen), usar SYN cookies. Red: relajar los límites de SYN del firewall y de la protección DDoS.
Cifras de referencia
En Linux (Android incluido), la primera retransmisión del SYN es al cabo de 1 segundo. Los kernels antiguos duplican después el intervalo cada vez, así que reenvían a los 1, 3, 7, 15 s …; los 6.5 y posteriores reenvían cinco veces, a los 1, 2, 3, 4 y 5 s, y después duplican el intervalo (7, 11, 19 s …) (tcp_syn_linear_timeouts=4). Muchos teléfonos Android siguen usando el kernel con el que salieron aunque se actualice el SO, así que puede variar entre dispositivos con la misma versión de Android. En cualquier caso, si todo falla, se abandona al cabo de unos 2 minutos. En Windows, según la versión y la configuración, el intervalo empieza en 1 o 3 segundos y va creciendo, y como se reenvía de 2 a 4 veces, se abandona en 20–30 segundos (el valor de esa computadora se ve en Max SYN Retransmissions de netsh int tcp show global).
En el gráfico
Avalancha tras la apertura · Intentos de conexión, desbordamientos de la cola de conexiones pendientes
Dónde mirar
TcpExtListenOverflows y TcpExtListenDrops en el nstat del servidor y el aviso “Possible SYN flooding on port” en dmesg, y si con ss -lnt el Recv-Q (conexiones esperando accept) del socket de escucha llega al Send-Q (límite del backlog). Con una captura en el servidor, comprobar si llegan los SYN y si se devuelve el SYN-ACK
Se confirma si
En la avalancha de conexiones justo después del mantenimiento, sube TcpExtListenOverflows y el Recv-Q se queda pegado al Send-Q. En la captura, los SYN del mismo cliente vuelven a llegar a intervalos de segundos y el servidor no responde
Se descarta si
Si los SYN no llegan al servidor y sus contadores no cambian, los descartó el firewall o la protección DDoS de delante: revisar los límites de SYN y los logs de descartes de ese dispositivo. Si el servidor envió el SYN-ACK y aun así la conexión tarda, hay pérdida en el sentido de vuelta
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Fuentes
include/net/tcp.hLinux kernel Primer RTO: TCP_TIMEOUT_INIT = 1 segundo (valor inicial de RFC 6298)
IP SysctlLinux kernel tcp_syn_retries: 6 por defecto; tcp_syn_linear_timeouts: 4 por defecto (RTO del SYN 1, 1, 1, 1, 1, 2, 4 …); última retransmisión a los 67 s y abandono a los 131 s; somaxconn: 4096 por defecto; tcp_syncookies: 1 por defecto
tcp: make the first N SYN RTO backoffs linearLinux kernel Commit que convierte las primeras retransmisiones del SYN en intervalos fijos, desde Linux 6.5 (el valor predeterminado 4 sigue el comportamiento de macOS e iOS)
Android common kernelsAndroid (Google) Se mantienen a la vez los kernels comunes 5.10 a 6.18, y un kernel de una plataforma anterior (p. ej., android14-6.1) puede usarse para lanzar o actualizar dispositivos Android nuevos
TcpMaxConnectRetransmissionsMicrosoft Valor predeterminado de los Windows antiguos: 2 retransmisiones del SYN, empezando con una espera de 3 segundos que se duplica cada vez; tras la última, espera el doble y abandona (3+6+12=21 segundos)
TCP/IP connectivity issues troubleshootingMicrosoft El número de retransmisiones del SYN varía según el SO y se ve en Max SYN Retransmissions de netsh int tcp show global
listen(2) — Linux manual pageLinux man-pages El argumento backlog de listen se recorta a somaxconn (4096 por defecto desde Linux 5.4; antes, 128)
SNMP counterLinux kernel Cuando la cola de accept se llena, se descartan los SYN y suben a la vez TcpExtListenOverflows y TcpExtListenDrops; TcpExtTCPSynRetrans
net/ipv4/tcp_input.cLinux kernel Mensaje de log “Possible SYN flooding on port …”
net/ipv4/tcp_diag.cLinux kernel En un socket de escucha, el Recv-Q de ss es el número de conexiones que esperan accept, y el Send-Q, el límite del backlog