Para mantener el orden, TCP no entrega al juego los paquetes que llegaron después de uno perdido hasta que vuelve a recibir ese paquete.
Por qué Se pierde un paquete → Efecto Los paquetes siguientes ya llegaron, pero esperan en el búfer de recepción → En pantalla Congelamiento y después todo se libera de golpe: cámara rápida
Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Servidor: usar UDP para las posiciones en tiempo real, enviar de forma confiable solo lo imprescindible, repartir el tráfico en varios flujos (streams). Cliente: cambiar el código de red para usar el mismo modelo que el servidor (UDP, canales separados).
Cifras de referencia
Perder un paquete detiene todo como mínimo un tiempo de ida y vuelta más algo de margen; si también se pierde la retransmisión, de cientos de ms a varios segundos.
En el gráfico
Hueco y luego ráfaga · Datos recibidos por conexión, retransmisiones
Dónde mirar
Captura de paquetes en el servidor (tcpdump, Wireshark) para ver, en la conexión de ese jugador, los paquetes retransmitidos y los huecos antes y después; para todo el servidor, incremento de TcpRetransSegs en nstat -az
Se confirma si
El tramo detenido empieza con la retransmisión de un paquete y, justo después de que llega, los datos acumulados se procesan de golpe (lo recibido se queda en 0 y luego llega todo junto)
Se descarta si
No aplica si el juego se comunica por UDP. Si se detiene sin retransmisiones, revisar el tick del servidor (“Tick que excede su presupuesto”)
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
RFC 5681: TCP Congestion ControlIETF Detecta la pérdida con 3 ACK duplicados y hace una retransmisión rápida; si no, espera al temporizador de retransmisión