Los paquetes UDP que superan la MTU (el tamaño máximo que se puede enviar de una vez) se fragmentan en la capa IP, y basta con perder un fragmento para que se descarte el paquete entero.
Por qué El snapshot de un lugar con mucha gente supera los 1,500 bytes → Efecto Se envía en varios fragmentos, y si se pierde uno solo, se descarta todo → En pantalla Cuanto más grande es el paquete, más se multiplica la tasa de pérdida. Teletransporte solo en lugares concurridos
Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Dividir los paquetes por cuenta propia en 1,200 bytes o menos, enviar solo los cambios.
Cifras de referencia
En una conexión con un 2% de pérdida, un paquete dividido en 4 fragmentos se pierde alrededor del 8% de las veces. Algunos firewalls y algunos ISP descartan directamente los paquetes fragmentados, y los jugadores afectados no reciben ni un solo paquete grande.
En el gráfico
Sube con la carga · Fragmentaciones IP (IpFragCreates), tamaño del snapshot
Dónde mirar
En el servidor, incremento de IpFragCreates (fragmentos creados al enviar) en nstat -az; en el receptor, IpReasmFails (reensamblados fallidos). Distribución del tamaño de los paquetes UDP en los logs del servidor del juego o en una captura de paquetes
Se confirma si
IpFragCreates sube en los lugares donde se junta gente, hay paquetes UDP de más de 1,500 bytes y, a esa hora, aumentan los reportes de teletransporte
Se descarta si
Si IpFragCreates no sube, no hay fragmentación en lo que envía el servidor
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Fuentes
RFC 8085: UDP Usage GuidelinesIETF Si se pierde un fragmento, no se puede reensamblar y se pierde el paquete entero; las aplicaciones UDP deben evitar la fragmentación IP
net/ipv4/proc.c (Linux v6.12)Linux kernel Nombres de contador que muestra nstat: FragCreates (fragmentos creados) y ReasmFails (reensamblados fallidos) del grupo Ip