Caída brusca del ritmo de envío por el control de congestión Congestion control backoff

ID de la causa sk-congestion · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)

Abrir la ficha interactiva con gráficos y simulaciones →

TCP interpreta la pérdida como señal de congestión y reduce la velocidad de envío entre un 30 y un 50%. Reacciona igual ante la pérdida en el Wi-Fi.

Por qué Con mucho que enviar, hay algo de pérdida en el Wi-Fi o en la conexión → Efecto TCP reduce mucho la velocidad de envío y se recupera despacio (CUBIC, el predeterminado en Linux y Windows, la reduce un 30%) → En pantalla En los lugares con mucha gente las actualizaciones se atrasan: cámara rápida e input lag

Síntomas: Cámara rápida, Input lag
Factores: Latencia, Detención
A quién afecta: Solo yo
Cuándo: Cuando se junta mucha gente
Responsable: Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo): Reducir lo que se envía (área de interés, solo los cambios), repartir los envíos para no mandarlo todo de golpe.
Tareas (Equipo de infraestructura): Cambiar a un control de congestión como BBR (tcp_congestion_control).
En el gráfico: Diente de sierra · Ventana de congestión (cwnd) y tasa de envío por conexión
Dónde mirar: Varias tomas con ss -ti de la conexión del jugador con actualizaciones atrasadas: cambios de cwnd y ssthresh, nombre del control de congestión (cubic, bbr) y si se acumula el Send-Q
Se confirma si: Tras una pérdida, la cwnd cae mucho y sube despacio una y otra vez, y mientras está reducida se acumula el Send-Q, coincidiendo con la hora de los reportes de cámara rápida e input lag
Se descarta si: Si la cwnd es holgada y aun así hay atraso, apunta a la ventana del receptor (“Ventana cero (una detención que parece retransmisión)”) o al envío del servidor
Se verifica con: Con herramientas de infraestructura (no hace falta código del juego)

Fuentes

RFC 9438: CUBIC for Fast and Long-Distance Networks IETF
Ante una pérdida, CUBIC multiplica la ventana por 0.7 (reducción del 30%) y Reno, por 0.5; CUBIC es el predeterminado en Linux, Windows y Apple
TCP BBR congestion control comes to GCP – your Internet just got faster Google Cloud
El control de congestión basado en pérdidas reduce mucho la tasa de envío incluso ante pérdidas que no se deben a congestión; BBR decide según la tasa de entrega y el RTT
IP Sysctl Linux kernel
Elegir el algoritmo de control de congestión de las conexiones nuevas con tcp_congestion_control
ss(8) — Linux manual page iproute2
cwnd, ssthresh y nombre del algoritmo de control de congestión de -i
net/ipv4/tcp_diag.c (Linux v6.12) Linux kernel
Valores Recv-Q y Send-Q de ss: en un socket de escucha, conexiones esperando accept y límite del backlog; en un socket conectado, bytes que la aplicación aún no ha leído y bytes enviados que no han recibido ACK

Ver también

Misma capa: L8 Sockets y protocolos

Causas de otras capas con el mismo síntoma (Cámara rápida)

Cuello de botella al procesar paquetes en el hilo principal L1 Proceso del juego en el cliente
Espiral de recuperación con timestep fijo L1 Proceso del juego en el cliente
Procesos en segundo plano que ocupan la CPU L2 SO y dispositivo del cliente
Desbordamiento del búfer de recepción L2 SO y dispositivo del cliente
Otras apps del dispositivo que ocupan el ancho de banda L2 SO y dispositivo del cliente
Procesamiento limitado con la ventana minimizada o sin foco L2 SO y dispositivo del cliente
Bufferbloat (cola del router) L3 Red doméstica
Mantenimiento del host en la nube y migración en vivo L6 Tarjeta de red del servidor

Ver la ficha interactiva con gráficos y simulaciones