El algoritmo de Nagle, que junta paquetes pequeños antes de enviarlos, y el ACK retardado, que envía los ACK con retraso, se bloquean mutuamente, y cada mensaje escrito en varias partes se retrasa entre 40 y 200 ms.
Por qué Se escriben mensajes pequeños en varias partes sin activar TCP_NODELAY → Efecto El emisor espera el ACK y el receptor lo envía tarde → En pantalla Input lag constante en todas las acciones aunque el ping de la conexión sea bajo
Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Servidor: activar TCP_NODELAY, juntar los mensajes de un tick y escribirlos de una vez, no depender de desactivar el ACK retardado en el receptor (TCP_QUICKACK de Linux solo dura un momento y en Windows hay que modificar el registro en cada PC), porque el juego no puede controlarlo con seguridad. Cliente: activar TCP_NODELAY, juntar los mensajes de un frame y escribirlos de una vez.
Cifras de referencia
En Linux, el ACK retardado suele ser de 40 ms (hasta 200 ms según la situación). En Windows, las versiones antiguas usaban 200 ms y las actuales, 40 ms (la plantilla predeterminada de Windows Server 2019 usa 40 ms). Como el ACK retardado lo decide el SO del receptor, si el servidor envía los mensajes en partes con Nagle activado, cada mensaje puede retrasarse entre 40 y 200 ms según el sistema que lo recibe.
En el gráfico
Siempre alto · Tiempo de respuesta a las acciones (RTT dentro del juego)
Dónde mirar
Intervalo entre solicitud y respuesta en una captura de paquetes en el servidor (tcpdump, Wireshark); comprobar si el código del servidor y del cliente activa TCP_NODELAY
Se confirma si
Con un ping bajo, se repiten huecos de unos 40 ms (200 ms en versiones antiguas de Windows) entre paquetes pequeños, y cada hueco termina justo después de llegar el ACK del otro extremo. Desaparecen al activar TCP_NODELAY
Se descarta si
Si el intervalo de respuesta se parece al ping de la conexión, no es esta causa. Si el servidor del juego tarda en generar la respuesta, apunta al procesamiento del servidor (“Acumulación en la cola de mensajes”)
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Fuentes
RFC 9293: Transmission Control Protocol (TCP)IETF Nagle retiene los datos pequeños mientras haya datos sin ACK; debe poder desactivarse por conexión; el ACK retardado debe ser menor de 0.5 segundos; el problema de que ambos se bloqueen mutuamente
Design issues - Sending small data segments over TCP with WinsockMicrosoft En el TCP de las versiones antiguas de Windows, al recibir datos se activa un temporizador de ACK retardado de 200 ms y Nagle viene activado por defecto, así que los paquetes pequeños esperan al ACK; se resuelve con TCP_NODELAY