Cambio del patrón de tráfico tras un parche Patch changes traffic pattern
ID de la causa sp-patch-traffic · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura), Infraestructura de red (Equipo de infraestructura)
Si nuevo contenido, efectos o campos sincronizados aumentan el tamaño y la frecuencia de los paquetes, un servidor que iba bien empieza a chocar tras el parche con los límites de MTU, ancho de banda o número de paquetes.
Por qué El parche añade efectos de habilidades, campos sincronizados o datos de objetos, y los paquetes se vuelven más grandes o más frecuentes → Efecto Los paquetes grandes superan la MTU y se fragmentan, y el volumen añadido choca con el ancho de banda, el límite de PPS de la nube o el búfer de envío → En pantalla Desde el parche, teletransporte, habilidades que no salen e input lag en los lugares concurridos. La pérdida aumenta aunque no se haya cambiado nada en la infraestructura
Todo el servidor, Una zona o un canal, Una región o un ISP
Cuándo
Cuando se junta mucha gente, Horas pico de la noche, Siempre
Responsable
Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura), Infraestructura de red (Equipo de infraestructura)
Tareas (Equipo de desarrollo)
Dividir los paquetes por cuenta propia en 1,200 bytes o menos, enviar solo los cambios de los nuevos campos sincronizados y bajar su frecuencia según la distancia y la importancia, comparar antes del despliegue, en un servidor de pruebas, los paquetes y bytes por segundo por jugador y el tamaño del paquete más grande con la build anterior, registrar la versión de la build en las métricas de tráfico.
Tareas (Equipo de infraestructura)
Servidores/SO: marcar la hora del despliegue en los gráficos y comparar antes y después los paquetes y bytes por segundo por jugador y el tamaño medio de paquete, alertar con los contadores de límite superado de la instancia, pasar a una instancia mayor si hace falta. Red: revisar los límites de procesamiento de los firewalls, balanceadores de carga y dispositivos de protección DDoS, y si bloquean fragmentos.
Cifras de referencia
Lo seguro para paquetes UDP es 1,200 bytes o menos; la MTU de una ruta por internet suele ser de 1,500 bytes, y menor al pasar por túneles (1,476 bytes en un túnel GRE). Los paquetes que superan la MTU de la ruta se fragmentan o se descartan, y en un paquete fragmentado basta con perder un fragmento para perderlo entero. Si los paquetes por segundo de cada jugador suben un 20%, los de todo el servidor también suben un 20%, y una instancia que trabajaba cerca del límite lo supera enseguida.
En el gráfico
Salto en escalón · Paquetes y bytes por segundo por jugador, tamaño medio de paquete
Dónde mirar
Paquetes y bytes por segundo de la NIC del servidor (rxpck/s, txpck/s, rxkB/s y txkB/s de sar -n DEV; en EC2, NetworkPacketsOut y NetworkOut) divididos por los jugadores conectados a la vez, comparando antes y después de la hora del despliegue. Tamaño medio de paquete = bytes ÷ paquetes; la distribución de tamaños, con las estadísticas Packet Lengths de Wireshark sobre una captura de paquetes
Se confirma si
Desde justo después del despliegue, los paquetes y bytes por jugador o el tamaño medio de paquete suben un escalón y se quedan ahí, y desde esa misma hora aumentan los fragmentos creados por el servidor (fragcrt/s de sar -n IP) o los contadores de límite superado de la instancia (pps_allowance_exceeded y bw_out_allowance_exceeded de ENA de AWS)
Se descarta si
Si el patrón de tráfico es igual antes y después del despliegue y solo aumentaron la latencia y la pérdida, revisar los cambios de infraestructura de esa misma hora (configuración, rutas, dispositivos, actualizaciones del SO o del kernel)
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
Cuando llega un reporte de que “antes del parche iba bien”, esta es la causa del lado del juego que hay que revisar primero, junto con los cambios de infraestructura. Aunque las notas del parche no mencionen cambios de red, un solo efecto o campo sincronizado nuevo se multiplica por cientos de jugadores en un lugar concurrido. Dónde choca en realidad el tráfico añadido se trata en “Fragmentación IP de paquetes UDP”, “Límite de PPS de la nube superado”, “Saturación del ancho de banda de la NIC”, “Búferes de socket del kernel insuficientes” y “Límite de procesamiento superado en dispositivos intermedios (firewall, IPS, protección DDoS)”. Esta entrada cubre el caso en que el punto de partida que llevó a ese límite es un parche del juego, así que, antes de subir el límite, hay que reducir el tráfico que añadió el parche. Si a la misma hora también se actualizaron el SO o el kernel, se distingue de “Cambios de rendimiento tras actualizar el SO, el kernel, los drivers o el firmware” comprobando si cambió el tráfico por jugador.
Fuentes
RFC 8085: UDP Usage GuidelinesIETF Las aplicaciones UDP no deberían enviar (SHOULD NOT) datagramas que superen la MTU de la ruta; si se pierde un fragmento, se pierde el paquete fragmentado entero, y algunos NAT y firewalls descartan todos los fragmentos
sar(1) — Linux manual pagesysstat rxpck/s y txpck/s (paquetes por segundo) y rxkB/s y txkB/s (KB por segundo) de sar -n DEV; fragcrt/s (fragmentos IP creados por segundo, ipFragCreates) de sar -n IP