Eliminación de opciones TCP en dispositivos intermedios Middlebox strips TCP options
ID de la causa rt-sack-stripped · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Infraestructura de servidores (Equipo de infraestructura)
Si algunos firewalls o aceleradores eliminan o modifican las opciones TCP, cuando se pierden varios paquetes solo se recupera uno por cada ida y vuelta, o la ventana (lo que se puede enviar de una vez) se reduce, y todo va más lento.
Por qué La “normalización TCP” de un firewall o un acelerador antiguo elimina las opciones de SACK, marcas de tiempo (timestamps) y escalado de ventana → Efecto Si se pierden varios paquetes, se recupera uno por cada ida y vuelta, y la ventana queda limitada a 64 KB → En pantalla Cada pérdida provoca un congelamiento mucho más largo (sin SACK tampoco se puede usar RACK-TLP), seguido de cámara rápida al liberarse. Las transferencias grandes, como los parches, también van lentas
Responsable principal Infraestructura de red (Equipo de infraestructura) · También Infraestructura de servidores (Equipo de infraestructura)
Tareas (Equipo de infraestructura)
Red: desactivar la normalización TCP en ese dispositivo, revisar también la aleatorización de números de secuencia del firewall, comparar las opciones del SYN con capturas de paquetes en los dos extremos. Servidores/SO: comprobar en ss -ti si las conexiones sin sack ni wscale se concentran en una ruta concreta (en Windows, ts puede estar desactivado según la configuración, así que si solo falta ts puede ser normal), comprobar que net.ipv4.tcp_sack del servidor vale 1.
En el gráfico
Siempre alto · Recuperaciones iniciadas sin SACK (TcpExtTCPRenoRecovery)
Dónde mirar
Si cada conexión muestra sack y wscale en ss -ti, la proporción entre TcpExtTCPRenoRecovery (recuperaciones iniciadas sin SACK) y TcpExtTCPSackRecovery en nstat, y TcpExtTCPSACKDiscard (bloques SACK descartados por incoherentes). En las rutas sospechosas, capturar el SYN en los dos extremos y comparar las opciones (tcp.options.sack_perm de Wireshark, etc.)
Se confirma si
Solo las conexiones que pasan por una ruta o un dispositivo concreto carecen de sack y wscale, y TcpExtTCPRenoRecovery pesa mucho. La opción de SACK permitido que llevaba el SYN del emisor no aparece en el SYN que recibe el otro extremo. Si la causa es la aleatorización de números de secuencia, las opciones siguen ahí, pero sube TcpExtTCPSACKDiscard
Se descarta si
Si sack falta en todas las conexiones, revisar primero el valor de net.ipv4.tcp_sack del servidor. Si las opciones están intactas y TcpExtTCPSACKDiscard no cambia, la lentitud de la recuperación viene de otro lado (“Recuperación lenta en thin streams”)
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
SACK puede romperse aunque las opciones sigan presentes. Si la aleatorización de números de secuencia (sequence randomization) del firewall cambia solo el número de secuencia de la cabecera y deja intactos los números dentro del SACK, el emisor descarta esos SACK incoherentes. El resultado es el mismo si en el servidor se puso tcp_sack=0 durante el problema de seguridad de SACK de 2019 y luego se olvidó volver a activarlo.
SNMP counterLinux kernel TcpExtTCPRenoRecovery (recuperación iniciada sin SACK) y TcpExtTCPSackRecovery (recuperación iniciada con SACK), TcpExtTCPSACKDiscard (bloques SACK no válidos)