한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Libro blanco del lag en juegos › Causas raíz de la retransmisión TCP

Límite de procesamiento superado en dispositivos intermedios (firewall, IPS, protección DDoS) Inline appliance PPS / CPU overload

ID de la causa rt-appliance-pps · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)

Abrir la ficha interactiva con gráficos y simulaciones →

Los firewalls, los sistemas de prevención de intrusiones (IPS) y los dispositivos de protección DDoS inspeccionan uno a uno los paquetes que pasan. En cuanto se supera su capacidad de inspección, descartan los paquetes que no alcanzan a procesar.

Por qué En horas pico o durante eventos llegan de golpe cientos de miles de paquetes pequeños del juego por segundo (o más), o las reglas de inspección son pesadas → Efecto Se agota la CPU o el límite de paquetes por segundo del dispositivo y este descarta paquetes. Si hay falsos positivos, bloquea también paquetes legítimos → En pantalla Congelamiento y teletransporte a la vez en todos los servidores que hay detrás de ese dispositivo; solo empeora cuando se junta mucha gente

Síntomas
Congelamiento, Cámara rápida, Teletransporte, Desconexión
Factores
Pérdida de paquetes, Latencia
A quién afecta
Todo el servidor, Una región o un ISP
Cuándo
Horas pico de la noche, Cuando se junta mucha gente
Responsable
Responsable principal Infraestructura de red (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Compartir con el equipo de infraestructura el patrón del tráfico del juego (puertos, tamaño de paquete, paquetes por segundo), juntar los mensajes pequeños de un tick y enviarlos de una vez para reducir el número de paquetes.
Tareas (Equipo de infraestructura)
Mirar la CPU, los paquetes por segundo y los contadores de descartes del dispositivo junto con las métricas del juego, dimensionar los dispositivos tomando como referencia paquetes pequeños, excluir los puertos del juego de las inspecciones pesadas, adaptar las reglas de protección DDoS al patrón del tráfico del juego.
Cifras de referencia
Los “10 Gbps” de las especificaciones de un dispositivo muchas veces se refieren a paquetes grandes de 1,500 bytes. Con el mismo ancho de banda, los paquetes del juego, de unos 100 bytes, son más de 10 veces más numerosos, así que el límite de paquetes por segundo se alcanza antes aunque el enlace parezca desahogado.
En el gráfico
Topa con el límite · Paquetes por segundo y uso de CPU del dispositivo, descartes del dispositivo
Dónde mirar
CPU, paquetes por segundo y contadores de descartes del dispositivo, y comparar con el mismo intervalo los paquetes de los puertos de switch antes y después del dispositivo. Superponerlo en una misma pantalla con los jugadores conectados a la vez y la tasa de retransmisión del servidor
Se confirma si
En horas pico o durante eventos, los paquetes por segundo o la CPU del dispositivo se quedan en un valor sin poder subir más, salen menos paquetes de los que entran y, a la misma hora, sube la tasa de retransmisión de todos los servidores que hay detrás
Se descarta si
Si los paquetes antes y después del dispositivo coinciden y no hay descartes en el dispositivo, es otra causa. Si suben los contadores de descartes de la NIC o el softnet dropped del servidor, apunta a “Descarte de paquetes en el host del servidor receptor”
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)

Fuentes

  1. RFC 2544: Benchmarking Methodology for Network Interconnect Devices IETF
    El rendimiento de un dispositivo debe probarse con varios tamaños de trama, incluidos el mínimo y el máximo (la capacidad de procesamiento cambia con el tamaño del paquete)

Ver también

Misma capa: Causas raíz de la retransmisión TCP

Causas de otras capas con el mismo síntoma (Congelamiento)

Ver la ficha interactiva con gráficos y simulaciones