Este libro blanco explica por qué el juego va a tirones, los personajes se teletransportan o se producen desconexiones. Las causas se dividen en 13 capas, desde la pantalla de tu juego hasta la base de datos del servidor. Cada causa incluye cómo verificarla y el equipo responsable, y en las simulaciones puedes cambiar las condiciones para comprobarlo. Los ejemplos se centran en los MMO, pero la mayor parte se aplica a juegos online de cualquier género.
Hay más de cien causas, pero los factores que producen el lag se agrupan en cuatro: los paquetes llegan tarde, llegan de forma irregular, no llegan o algo detiene el procesamiento. Los juegos usan varias técnicas para disimular estos factores, y lo que se ve cuando no lo consiguen es la “forma” del lag que percibimos.
En un MMO, el mundo que ves en tu pantalla es una imagen redibujada a partir de los paquetes que envía el servidor. Depende del juego, pero un servidor suele calcular el estado del juego entre 10 y 30 veces por segundo (cada una de esas pasadas se llama tick). De ese resultado selecciona solo los cambios alrededor de cada jugador y se los envía en paquetes. Tu PC lee los paquetes que llegan y dibuja la pantalla. Por eso casi todo el lag se reduce a cómo muestra el juego “un paquete que no llegó a tiempo”.
También hay casos fuera de estos cuatro factores. Si el servidor y tu PC calculan lo mismo de forma distinta (reglas de movimiento diferentes, un bug), hay rubber banding o entidades invisibles aunque la conexión esté bien. La pista de este tipo de lag es que se repite en el mismo lugar o con la misma acción, sin importar el ping.
Piensa en un servicio de paquetería. Si el envío siempre tarda 3 días, es latencia. Si unos envíos tardan un día y otros cinco, es jitter. Si una caja desaparece, es pérdida de paquetes, y si el centro logístico cierra sus puertas, es detención. Los juegos aguantan con métodos como “si una caja llega tarde o no llega, deducir su contenido a partir de las cajas anteriores y posteriores (interpolación, extrapolación)” y “si no llega, pedir que la envíen otra vez (retransmisión)”.
Casi todo lo que se habla del lag se mide en milisegundos (ms, una milésima de segundo). Con recordar unas pocas cifras de la tabla siguiente, entenderás mucho mejor lo que dicen los equipos de desarrollo e infraestructura.
| Referencia | Tiempo | Qué significa |
|---|
CPU, disco, base de datos, router, enlace del ISP. Las capas son distintas, pero la estructura es la misma. Hay workers que procesan las solicitudes (núcleos de CPU, hilos, conexiones de BD, etc.) y delante de ellos se forma una cola. Mientras los workers están desocupados, la cola está vacía; pero cuando su nivel de ocupación (utilización) supera el 80–90%, la cola crece de golpe. Con un solo worker y solicitudes que llegan al azar, la espera media equivale al tiempo de procesamiento con una utilización del 50%, a 4 veces ese tiempo al 80% y a 9 veces al 90%. Ahí está la respuesta a “¿Por qué hay lag si a la CPU todavía le queda un 10%?”. Además, el valor de CPU de las pantallas de monitoreo suele ser un promedio de varios núcleos y de 1–5 minutos, así que oculta los casos en que un solo núcleo está al 100% o en que la carga se concentra solo unos segundos.
Trata las causas del lag durante la partida en juegos online, desde tu PC o tu teléfono, que dibujan la pantalla del juego, hasta la red doméstica, el ISP, el centro de datos, los servidores y la base de datos. No cubre el juego en la nube (cloud gaming), que recibe la pantalla del juego como video, el chat de voz, que funciona como un servicio aparte, ni la velocidad de parches y descargas, porque su estructura es distinta. Aun así, las causas de red que hay dentro de ellos (Wi-Fi, bufferbloat, congestión de enlaces, etc.) son las mismas que las de aquí.
Cuando presionas el botón de una habilidad, esa señal pasa por tu PC, tu casa, el ISP y el centro de datos hasta llegar al servidor. El resultado, procesado en varias capas dentro del servidor, recorre esas mismas capas en sentido inverso y se dibuja en tu pantalla. Son 13 capas en total, y basta con que cualquiera de ellas se atasque para que haya lag. Haz clic en una capa del mapa de abajo para ir a su capítulo.
Una pequeña simulación con un servidor, una conexión y tu PC. Rompe las condiciones una por una y observa cómo se producen los tirones, el teletransporte, el rubber banding, la cámara rápida, la cámara lenta, el input lag, el congelamiento y la desconexión. La línea de tiempo de paquetes traza una línea desde que se envía cada paquete hasta que llega. Cuanto más inclinada está la línea, más tardó el paquete, y una × marca un paquete perdido.
Los jugadores solo dicen “hay lag”, pero la forma del lag dice bastante sobre la causa. El pequeño dibujo de cada síntoma muestra el recorrido de un personaje en la pantalla. Si los puntos se superponen, se detuvo; si se separan, se aceleró o saltó.
El movimiento pierde fluidez: se para un instante y sigue, una y otra vez. Si el ping se ve normal, lo más probable es un problema de frames en tu PC (cliente o SO); si el ping sube y baja, lo más probable es jitter del Wi-Fi o de la conexión. Eso sí, el ping que muestra el juego suele medirse dentro del bucle del juego, que se ejecuta una vez por frame, así que un pico de frametime también puede disparar la cifra de ping.
Un personaje pasa de golpe a una posición lejana sin recorrer el camino. Casi siempre significa que dejaron de llegar paquetes durante un rato. Hay que revisar pérdida de paquetes, cortes breves de la conexión, detenciones del servidor y fallos de extrapolación. Si todos se ven bien y solo uno salta, lo primero que hay que sospechar es la conexión de ese jugador.
Tu personaje avanza y de pronto vuelve arrastrado al punto por el que acaba de pasar. Lo que muestra tu pantalla (predicción) y lo que validó el servidor no coinciden. O tu input no llegó al servidor (pérdida), o la validación de movimiento del servidor lo cortó, o el cliente y el servidor calculan el movimiento de forma distinta.
Cuando la pantalla detenida vuelve a moverse, los movimientos, golpes y daños acumulados pasan todos juntos a toda velocidad. En algún punto se acumularon paquetes y se liberaron de golpe. Los casos típicos son la espera por una retransmisión TCP, el servidor recuperando el retraso y el cliente atrasado en su procesamiento.
Todo se mueve despacio. El lanzamiento de habilidades y el movimiento de los monstruos parecen estirados. Según cómo esté diseñado el servidor, también puede verse a velocidad normal pero con tirones o teletransporte. El servidor no termina los ticks a tiempo. La conexión está bien, así que el ping medido fuera del juego no cambia; el ping del juego puede subir un poco si incluye la espera de procesamiento en el servidor. Hay que revisar picos de jugadores, cálculo de visibilidad, broadcast y falta de memoria.
Pasa un tiempo desde que presionas hasta que ves el resultado. La imagen en sí puede verse fluida. El tiempo de ida y vuelta (ping) es alto, o hay una cola acumulada en algún punto. Hay que revisar la distancia, la cola del router, Nagle (la función de TCP que junta paquetes pequeños antes de enviarlos) y las colas del servidor. Si el ping es bajo y aun así todo va pesado, hay que mirar tu PC (V-Sync, FPS bajos) o un diseño que espera la confirmación del servidor en cada acción (capítulo sobre modelos de netcode).
Todo lo que hay en pantalla se detiene un momento (de 0.5 s a varios segundos) y luego vuelve a moverse. Se detuvo el servidor entero (GC, deadlock, llamadas síncronas), la conexión se cortó un momento o se detuvo tu PC.
Una acción que hiciste claramente se anula como si nunca hubiera pasado, o el resultado se revierte mucho después. La solicitud se perdió (pérdida de paquetes, cola desbordada), el servidor resolvió algo distinto de lo que veías (diferencia en el momento de la validación, rechazo después del feedback anticipado) o falló el guardado (bloqueo o fallo de la BD, crash del servidor).
En plena partida se corta la conexión y vuelves a la pantalla de inicio de sesión o a la ventana de reconexión. No llegó ningún paquete dentro del timeout. Hay que revisar cortes largos de la conexión, timeouts por inactividad, crashes o reinicios del servidor, y que el servidor o tu PC se hayan detenido más tiempo que el timeout (una carga larga). Si el juego se cerró sin ningún aviso, primero hay que sospechar de un cierre forzado del cliente (crash, falta de memoria) y después de la conexión.
No logras entrar al juego, o te quedas detenido en la pantalla de carga o de entrada. Lo que acepta las conexiones nuevas (la cola de conexiones pendientes del servidor, el firewall, el servidor de login, la BD) está lleno. Es especialmente frecuente justo después de un mantenimiento.
Un NPC, monstruo o jugador que debería estar ahí falta solo en tu pantalla, o una entidad que ya desapareció sigue solo en tu pantalla. Normalmente se perdió un paquete concreto o falló el dibujado de la entidad. La velocidad tiene poco que ver. Hay que revisar diferencias de canal o de phasing, mensajes de aparición o desaparición perdidos, mensajes descartados durante la carga y fallos al cargar assets. La pista decisiva es si la entidad aparece al salir de su rango de visión y volver.
Algunos juegos van bien incluso con 150 ms de ping y otros se sienten pesados con 60 ms. Y no pasa solo en los juegos de acción. Con la misma conexión, la diferencia casi siempre viene de cómo han acordado el cliente y el servidor “qué se decide, cuándo y quién lo decide”, es decir, del diseño del netcode. Parte de eso es una decisión intencionada, y parte está realmente mal hecha.
Todos los juegos en red resuelven el mismo problema. Entre el servidor y tu PC siempre hay un desfase de tiempo, y alguno de los dos tiene que decidir cómo tratar lo que “aún no está confirmado”. Hay cuatro opciones principales.
Por eso la sensibilidad al ping depende menos del género y más de dos preguntas: cuántos viajes de ida y vuelta al servidor espera una acción clave y si el tiempo que permiten las reglas del juego supera con holgura “ping + tiempo de reacción humano”.
| Modelo | Cómo funciona | Dónde se usa | Cómo se ve con 150 ms de ping | Puntos débiles |
|---|---|---|---|---|
| Solicitud-respuesta Se muestra cuando confirma el servidor | Al presionar, se pregunta al servidor y la acción se reproduce cuando llega la respuesta. | Juegos por turnos, de cartas e idle; interfaces de tienda, intercambio y fabricación; uso de habilidades y objetos en MMO antiguos | Todas las acciones empiezan unos 0.2 s tarde. En un juego por turnos casi no se nota | Acciones encadenadas e interfaces con varios viajes de ida y vuelta en una misma pantalla |
| Sincronización de estado + interpolación Autoridad del servidor | El servidor envía el estado del juego en cada tick y el cliente dibuja el movimiento entre dos estados. | Mostrar a otros jugadores y monstruos en la mayoría de los MMO | Los demás se ven unos 0.2 s en el pasado. Normalmente casi no se nota | Jitter (variación en el tiempo de llegada de los paquetes) y pérdida → teletransporte, tick rate bajo |
| Predicción en el cliente + reconciliación con el servidor | Tus inputs se aplican al instante y, cuando llega el resultado del servidor, se comparan y se corrigen. | FPS, MMO de acción, movimiento en la mayoría de los MMO | Tus controles responden al instante. A veces, un rubber banding breve | Correcciones frecuentes si el cliente y el servidor calculan distinto |
| Compensación de lag Registro de impactos con rebobinado en el servidor | El servidor rebobina hasta el momento pasado que veía el atacante y decide si acertó. | FPS, acción sin fijación de objetivo | El que dispara lo siente justo, pero el que recibe el disparo piensa “me cubrí y aun así me dieron” | La frustración del que recibe el golpe. Cuanto más alto es el ping del atacante, más se rebobina y peor es |
| Sincronización de comandos y destinos | Solo se envía la intención, como “ve aquí” o “ataca a este objetivo”, y cada lado hace el cálculo por su cuenta. | MMO de movimiento por clic, combate tab-target, algunos MOBA | Solo el inicio se retrasa un poco; el movimiento y los ataques son fluidos | Si la ruta o el resultado no coinciden, hay que corregir |
| Eventos programados Basados en la hora del servidor | Se anuncia junto con una hora futura, como “empieza en el instante T del servidor”, y cada cliente lo reproduce a esa hora. | Patrones de jefes de raid, cinemáticas, eventos a la hora en punto | Si el aviso dura más que el ping, prácticamente no afecta | Si llega después de la hora programada, se salta el principio |
| Lockstep determinista | Se reúnen los inputs de todos y se calcula exactamente lo mismo en el mismo turno. A los inputs se les añade un retardo fijo. | RTS (tipo StarCraft), algunos juegos cooperativos y de puzles | Todos los inputs llegan con el mismo retraso (que se disimula con un sonido o una indicación en cuanto presionas). Si el jitter es alto, todos se detienen | Jitter y pérdida, el jugador más lento |
| Rollback Predicción y rebobinado | Predice el input del rival y avanza; si se equivoca, rebobina al pasado y vuelve a calcular. | Juegos de lucha (tipo GGPO), algunos juegos de acción y deportes | Respuesta casi inmediata a los controles (normalmente 1–3 frames de retardo de input). A veces los movimientos del rival saltan unos frames | Con ping alto, el rebobinado es mayor y parece teletransporte |
| Autoridad del cliente | Cada uno decide su propio resultado; el servidor solo reenvía y registra. | Algunos juegos móviles y casuales, arquitecturas P2P o con servidor intermedio (relay) | Tu pantalla va fluida. Los resultados no coinciden con la pantalla de los demás | Trampas (hacks), “yo le di y no contó” |
Los juegos reales combinan estos modelos. Lo normal es elegir uno distinto para cada acción: predicción para el movimiento, feedback anticipado y confirmación posterior para las habilidades, eventos programados para los patrones de los jefes y solicitud-respuesta para los intercambios.
1. Ninguna acción espera un viaje de ida y vuelta. Al presionar el botón, la animación, el sonido y los efectos empiezan al instante (feedback anticipado), y el resultado del servidor se usa solo en lo que no se nota si llega tarde, como los números de daño.
2. Las reglas del juego dan bastante más tiempo que el ping. Si el aviso de un jefe dura 1–2 segundos, se puede esquivar de sobra aunque el paquete llegue unos 0.2 s tarde y la reacción humana se lleve 0.25 s. Si tus habilidades también tienen tiempo de lanzamiento, la confirmación del servidor termina mientras se llena la barra de lanzamiento, y la espera queda oculta dentro de ese tiempo. Es la razón principal por la que los MMO tab-target son poco sensibles al ping. En cambio, un aviso corto de alrededor de 0.5 s ya es difícil de ver y esquivar con 150 ms de ping (ver la simulación de ventanas de tiempo más abajo).
3. Aceptan por adelantado las acciones encadenadas. Si hay un búfer de inputs (cola de habilidades) que guarda la siguiente habilidad aunque la presiones antes de que termine el cooldown, no se mete un viaje de ida y vuelta entre un paso del combo y el siguiente.
4. Absorben el jitter. El búfer de interpolación y las animaciones basadas en la hora del servidor convierten los paquetes que tardan “casi siempre 150 ms y a veces 250 ms” en un flujo constante con unos 250 ms de retraso. Se ve un poco más en el pasado, pero a cambio todo es fluido. Las personas se acostumbran enseguida a un retraso constante, pero les cuesta mucho acostumbrarse a la irregularidad. Los juegos bien hechos alargan y acortan solos el búfer según suba o baje el jitter.
5. El registro de impactos coincide con “lo que vi”. Las esquivas y los impactos se deciden según el momento que vio el jugador (compensación de lag), o se usan reglas en las que la posición no importa (fijación de objetivo).
6. El retraso de uno no hace esperar a los demás. Con autoridad del servidor, aunque tu ping sea malo, los demás juegan bien. Con lockstep o con un anfitrión (host), el jugador más lento marca la sensación de todos.
A veces un juego es sensible al ping por una decisión de diseño intencionada y a veces porque está mal hecho.
Al presionar un botón no hay animación ni sonido hasta que llega la respuesta del servidor. El ping se convierte directamente en el tiempo de respuesta.
Por qué: Las habilidades, el movimiento y la recogida de objetos se reproducen solo cuando llega la confirmación del servidor → Efecto: Desde que se presiona, no hay ninguna respuesta durante el tiempo de ida y vuelta + la espera del tick → En pantalla: Con 150 ms de ping, todas las acciones responden 0.2 s tarde
Síntomas: Input lag · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo)
Si una sola acción necesita varias idas y vueltas al servidor en secuencia, el ping se multiplica por ese número.
Por qué: Abrir la tienda → pedir la lista → consultar el precio → comprar → actualizar el inventario, cada paso como una solicitud aparte → Efecto: La siguiente solicitud solo se envía tras recibir la respuesta de la anterior → En pantalla: Con 150 ms de ping, una compra tarda casi 1 segundo. Las cargas son inusualmente largas
Síntomas: Input lag, No conecta / carga infinita · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Si no se puede presionar la siguiente habilidad hasta que el servidor confirme que terminó la anterior, cada combo arrastra un tiempo de ida y vuelta.
Por qué: El input de la siguiente habilidad solo se acepta “después de confirmarse la anterior” → Efecto: Entre una habilidad y la siguiente queda un hueco del tamaño del ping → En pantalla: Aparecen huecos en cada combo, y cuanto más ping, menos DPS
Síntomas: Input lag, Acción perdida / rollback · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo)
Si el tiempo para reaccionar es corto, como en las esquivas, los parries o los bloqueos, el ping consume ese margen y aparecen ataques imposibles de evitar.
Por qué: Ventanas de tiempo cortas, como un aviso de ataque del jefe de 0.5 s o una ventana de parry de 0.2 s → Efecto: El aviso se ve tarde (latencia servidor → cliente + interpolación) y tu input también llega tarde (latencia cliente → servidor + espera del tick) → En pantalla: Esquivaste a tiempo y aun así te golpea, el parry no sale
Síntomas: Acción perdida / rollback, Input lag · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo), Infraestructura de servidores (Equipo de infraestructura)
Si el servidor resuelve los impactos solo con “la posición actual en el servidor”, lo que viste en tu pantalla y el resultado no coinciden.
Por qué: En tu pantalla, el rival está en su posición de hace unos 0.2 s (con 150 ms de ping y 100 ms de interpolación) → Efecto: El servidor resuelve con la posición actual, y el rival ya no está donde apuntaste → En pantalla: En tu pantalla le diste, pero cuenta como fallo. Hay que disparar por delante de los objetivos en movimiento
Síntomas: Acción perdida / rollback · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Si se rebobina demasiado a favor del atacante, a quien recibe el disparo le dan aunque ya se haya escondido.
Por qué: El servidor rebobina mucho para favorecer a un atacante con ping alto → Efecto: En la pantalla de quien recibe el disparo, ya estaba a cubierto → En pantalla: “Me dieron detrás de una pared”, ventaja para quien tiene ping alto
Síntomas: Acción perdida / rollback · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Si cada cliente decide sus propios resultados, en tu pantalla todo va fluido, pero los resultados no coinciden con los de otras pantallas y el juego queda expuesto a las trampas.
Por qué: El cliente decide la posición y los impactos, y el servidor solo los reenvía → Efecto: Dos jugadores afirman haber acertado primero y el servidor no puede comprobarlo → En pantalla: El rival se teletransporta o atraviesa paredes, “yo le di y no cuenta”
Síntomas: Teletransporte, Acción perdida / rollback · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
En una arquitectura en la que todos calculan juntos el mismo turno, si el input de uno llega tarde, todos esperan.
Por qué: Cada turno solo se puede calcular cuando han llegado los inputs de todos los jugadores → Efecto: El input de un jugador llega tarde por jitter o pérdida de paquetes → En pantalla: Todos sufren un tirón a la vez y, en casos graves, aparece la ventana “Esperando a los jugadores”
Síntomas: Congelamiento, Tirones, Input lag · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Se predice el input del rival y se muestra por adelantado; si la predicción falla, se rebobina y se vuelve a calcular. Cuanto mayor es el ping, más hay que rebobinar.
Por qué: El rival cambia de input (distinto de lo predicho) → Efecto: El input real llega con un retraso de medio ping, y hay que rebobinar y recalcular ese mismo tramo → En pantalla: Las animaciones del rival se saltan algunos frames o cambian de golpe
Síntomas: Teletransporte · Responsable principal Desarrollo de cliente (Equipo de desarrollo)
Si los eventos del servidor no llevan la hora en que ocurrieron y se reproducen en cuanto llegan, el timing de las animaciones sigue tal cual el jitter de la red.
Por qué: Los eventos “inicio de ataque” o “reproducir efecto” se ejecutan en cuanto llegan → Efecto: Cada paquete tarda un tiempo distinto en llegar y los intervalos son irregulares → En pantalla: Las animaciones de ataques seguidos se aceleran y se frenan, el timing de los patrones del jefe cambia cada vez
Síntomas: Tirones, Cámara rápida · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo)
Si las solicitudes se acumulan hasta el siguiente tick para procesarlas y el resultado también se envía en el tick posterior, el intervalo de tick se suma dos veces.
Por qué: Las solicitudes recibidas se procesan en el siguiente tick → Efecto: El resultado también se acumula para enviarlo en el siguiente tick de envío → En pantalla: El ping de la conexión es bajo, pero la respuesta llega siempre con un retraso de aproximadamente 1.5 veces el intervalo de tick. En un servidor de 10 ticks, 0.15 s de media y 0.2 s en el peor caso
Síntomas: Input lag · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Si el servidor comprueba con demasiada rigidez la velocidad de movimiento, los cooldowns o el alcance, rechaza incluso inputs legítimos que llegaron juntos por el jitter.
Por qué: Criterios estrictos como “distancia máxima por tick” o “tolerancia de cooldown: 0 ms” → Efecto: Si por el jitter llegan dos comandos en el mismo tick, se consideran una infracción de las reglas → En pantalla: Rubber banding, una habilidad rechazada aunque el cooldown ya terminó
Síntomas: Rubber banding, Acción perdida / rollback · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Cuando la computadora de un jugador hace de servidor, su conexión y el rendimiento de su PC determinan lo que perciben todos.
Por qué: La computadora del anfitrión hace de servidor (P2P, listen server) → Efecto: Si la conexión o la computadora del anfitrión van lentas, afecta a todos; el anfitrión juega con ping 0 → En pantalla: Solo el anfitrión tiene ventaja; si se va, todos sufren un congelamiento o una desconexión
Síntomas: Tirones, Congelamiento, Desconexión · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo), Infraestructura de servidores (Equipo de infraestructura)
Si el servidor no acepta después un golpe o una habilidad que tu pantalla ya mostró, lo que viste claramente queda anulado.
Por qué: Los efectos de golpe y las animaciones de habilidad se reproducen antes de la confirmación del servidor (feedback anticipado) → Efecto: El servidor vuelve a comprobar el alcance, la posición del objetivo, el cooldown y los recursos, y lo rechaza → En pantalla: Salta sangre pero no hay daño, la habilidad hace la animación pero no tiene efecto, solo se activa el cooldown
Síntomas: Acción perdida / rollback, Rubber banding · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo)
Si solo se intercambia “ve aquí” y cada lado calcula la ruta por su cuenta, basta una pequeña diferencia de cálculo para que un personaje o un monstruo tome otra ruta y después vuelva arrastrado a su sitio.
Por qué: En el movimiento por clic o la persecución de monstruos, solo se envía el destino y el cliente calcula la ruta por separado → Efecto: Por diferencias en los datos del terreno, colisiones con otros personajes o un orden de cálculo distinto, se mueve por una ruta distinta a la del servidor → En pantalla: Un monstruo atraviesa una pared y de golpe aparece en otro sitio, tu personaje cambia de dirección tras el clic como si se deslizara
Síntomas: Teletransporte, Rubber banding · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Si el servidor envía las actualizaciones de posición (snapshots) solo unas pocas veces por segundo, hay que alargar en proporción el búfer de interpolación, y los demás personajes se ven más en el pasado.
Por qué: Para ahorrar tráfico, las actualizaciones de posición se envían solo 5–10 veces por segundo → Efecto: Para dibujar con fluidez, el búfer debe ser del doble del intervalo entre paquetes (200–400 ms); si es más corto, basta perder un paquete para que haya un congelamiento → En pantalla: Los cambios de dirección del rival se ven tarde y no coinciden con la resolución de impactos. Con un búfer corto hay tirones, y teletransporte cuando se pierden paquetes
Síntomas: Tirones, Teletransporte, Acción perdida / rollback · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Los reportes de lag más confusos son los que afectan solo a unas pocas personas o solo a uno de los clientes. Cómo ven los demás a un jugador lento, y si ese jugador también hace ir lentos a los demás, depende por completo de cómo procesa el servidor los inputs y del modelo de netcode. Este capítulo también trata el caso de dos clientes abiertos en la misma computadora en el que solo uno no ve los NPC.
Hoy casi todos los MMO usan una arquitectura de autoridad del servidor. El servidor decide todos los resultados y el cliente dibuja lo que recibe. Con esta arquitectura, el lag casi siempre lo nota solo el jugador lento.
Pero también hay arquitecturas en las que un jugador lento hace ir lentos a todos. Lo que tienen en común es que “alguien espera a ese jugador”.
| Cómo procesa el servidor los inputs | Lo que sufre el jugador lento | Cómo ven los demás al jugador lento | El juego de los demás |
|---|---|---|---|
| Agrupar por tick Tick fijo, todos los inputs recibidos de una vez | El resultado de las habilidades se retrasa el ping más la espera del tick (input lag). Si la validación del movimiento es estricta, rubber banding | Se traba y luego avanza varios pasos de una vez (cámara rápida o teletransporte). Con ping alto pero sin jitter, se ve fluido | Sin efecto |
| Procesar al llegar Basado en eventos, se aplica y se envía en cuanto llega | Input lag igual al ping. Solo se ahorra la espera del tick | El movimiento se acelera y se frena (cámara rápida leve). Varias habilidades acumuladas se ejecutan en un instante | Sin efecto |
| Búfer de inputs por jugador Se guardan por jugador y se aplica uno por tick | La confirmación se retrasa lo que dura el búfer | Bastante fluido. Si el búfer se vacía, se queda quieto un momento | Sin efecto |
| Registro con compensación de lag Rebobinado al momento que vio el atacante | Acierta donde apunta (dentro del límite de rebobinado) | Sus ataques aciertan aunque ya te hayas escondido | Golpes injustos (se extiende) |
| Lockstep y espera de turnos | Input lag. Si el input llega tarde, congelamiento | Todo se congela | Congelamiento. Aunque solo haya retraso, input lag (se extiende a todos) |
| Envío bloqueante y procesamiento síncrono El servidor espera a ese jugador | Congelamiento y luego cámara rápida | Van lentos todos los que atiende ese hilo del servidor | Cámara lenta y congelamiento (se extiende a los jugadores de ese hilo) |
| El jugador lento es el anfitrión P2P, listen server | Para él, ping 0 | La pantalla de todos va a tirones | Lag para todos |
| El jugador lento controla a los monstruos El cálculo del movimiento de los monstruos se delega en el cliente | En su pantalla los monstruos van bien | Los monstruos que controla se traban y luego se teletransportan | Todos los que luchan contra ese monstruo (se extiende) |
Si una persona abre dos clientes en la misma computadora y solo uno de ellos no ve los NPC, la conexión casi nunca es la causa. Los dos clientes usan el mismo router y la misma conexión. La diferencia aparece en tres puntos.
Hay tres pistas muy claras: ¿se ve el nombre sobre el personaje pero no su modelo? (el servidor lo envió y falló el dibujo), ¿aparece si sales del rango de visión y vuelves? (se perdió un mensaje de aparición) y ¿mejora si traes al frente la ventana del cliente que no lo ve? (procesamiento limitado de las ventanas en segundo plano). En cambio, una “entidad fantasma”, como un monstruo ya muerto que sigue de pie solo en tu pantalla, indica que se perdió el mensaje de desaparición.
Los inputs de alguien con mala conexión llegan al servidor de forma irregular y a ráfagas. Si el servidor aplica en cada tick lo que haya recibido, los demás ven a ese personaje detenerse un instante y luego avanzar varios pasos de golpe.
Por qué: Los comandos de movimiento del jugador con lag llegan 0 en un tick y 2–3 en otro → Efecto: El servidor los aplica todos de una vez en el tick en que llegan, y la posición de ese personaje avanza en escalones → En pantalla: En las pantallas de los demás, solo ese personaje se detiene un instante y luego avanza de golpe. El resto se ve bien
Síntomas: Cámara rápida, Teletransporte · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Externo (Externo)
En un servidor que procesa y anuncia cada paquete en cuanto llega, las acciones acumuladas de un jugador con lag se ejecutan una tras otra al instante.
Por qué: Las solicitudes de habilidades y de movimiento del jugador con lag llegan a ráfagas → Efecto: El servidor las ejecuta en orden en cuanto las recibe y las anuncia a todos de inmediato → En pantalla: Los demás ven a esa persona usar varias habilidades en un instante o moverse como en cámara rápida
Síntomas: Cámara rápida · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Si el servidor guarda un poco los inputs de cada jugador y los saca de uno en uno por tick, los demás lo ven fluido, pero el momento en que el servidor confirma las acciones de ese jugador se retrasa en la misma medida.
Por qué: El servidor acumula en un búfer los inputs del jugador con lag y aplica uno por tick → Efecto: Si el búfer es pequeño, se vacía a menudo y ese personaje se queda quieto o el servidor lo mueve suponiendo el último input; si es grande, los inputs del propio jugador se confirman tarde → En pantalla: Pequeño: los demás lo ven detenerse un instante. Grande: los resultados de sus habilidades salen tarde (input lag)
Síntomas: Tirones, Input lag · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Los inputs de quienes usan conexiones con mucho jitter llegan a ráfagas, así que caen a menudo en las comprobaciones de velocidad y cooldown del servidor.
Por qué: El jitter de las conexiones de un ISP o una región concretos aumenta por la noche → Efecto: El servidor interpreta como exceso de velocidad o infracción de cooldown los inputs legítimos que llegaron juntos → En pantalla: Solo los jugadores de ese ISP sufren rubber banding, rechazos de habilidades y, en casos graves, una desconexión porque el servidor los expulsa
Síntomas: Rubber banding, Acción perdida / rollback, Desconexión · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de red (Equipo de infraestructura)
En las mecánicas de raid en las que todos deben reaccionar juntos en un momento preciso, la reacción tardía de una sola persona con lag hace fracasar a todo el grupo.
Por qué: Mecánicas compartidas como “todos se dispersan a la vez” o “uno presiona un botón” → Efecto: El jugador con lag ve tarde el aviso y su input también llega tarde → En pantalla: El grupo entero cae (wipe) por culpa de esa persona, y los demás sienten que “fue por el que tenía lag”
Síntomas: Acción perdida / rollback, Input lag · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Para reducir la carga del servidor, algunos juegos delegan el cálculo del movimiento de un monstruo en el cliente de un jugador cercano. Si la conexión de ese jugador es mala, el monstruo se mueve raro en las pantallas de todos.
Por qué: El servidor delega el cálculo del movimiento del monstruo en el cliente del jugador más cercano (o del primero en llegar) → Efecto: Los resultados que reporta ese jugador llegan tarde o a ráfagas al servidor → En pantalla: Solo ese monstruo se detiene un instante y luego se teletransporta en las pantallas de todos los que están cerca. En la pantalla del propio jugador encargado se ve bien
Síntomas: Teletransporte, Tirones, Cámara rápida · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Un personaje con miles de objetos o correos acumulados, o con listas de amigos o de bloqueados y buffs fuera de lo normal, tiene varias veces más datos que cargar al conectarse, que guardar y que anunciar a su alrededor. Va lento solo con ese personaje, sin importar la conexión.
Por qué: Un personaje antiguo o las recompensas de eventos acumulan miles de elementos en el inventario o el buzón → Efecto: En cada conexión, cambio de zona o guardado se lee y escribe todo eso en la BD, y la información de equipamiento y buffs que se envía a los de alrededor también es grande → En pantalla: Solo ese personaje tiene cargas de entrada largas y tirones al abrir el inventario o el correo. Si el servidor espera el guardado en el hilo del juego, los de alrededor también sufren una pausa breve
Síntomas: No conecta / carga infinita, Input lag, Congelamiento · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)
Si dos personajes están en canales o instancias distintos, o en “fases” (phasing) distintas en las que los NPC visibles cambian según el progreso de las misiones, cada uno ve un mundo distinto.
Por qué: El segundo personaje está asignado a otro canal o va en otra etapa de la misión → Efecto: El servidor no le envía ese NPC a ese personaje (es lo normal) → En pantalla: El NPC solo falta en uno de los dos. Parece un bug, pero es lo previsto por el diseño
Síntomas: Entidades invisibles / fantasma · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
En cuanto el personaje entra en una zona, el servidor envía los mensajes de aparición de los NPC cercanos, pero el cliente todavía está cargando el mapa y los descarta.
Por qué: El servidor envía los mensajes de aparición de las entidades cercanas justo después de procesar la entrada → Efecto: El cliente está cargando y todavía no tiene el manejador (handler) de esos mensajes, así que los descarta → En pantalla: El servidor los da por enviados y no los repite. El NPC no se ve hasta que sale del rango de visión y vuelve
Síntomas: Entidades invisibles / fantasma · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo)
Si el momento en que un personaje se registra en la cuadrícula de visibilidad coincide con el momento en que un NPC cambia de celda, el mensaje de aparición de ese NPC puede perderse.
Por qué: El procesamiento de una entrada, un cambio de canal o una teletransportación coincide en el mismo instante con el movimiento de un NPC → Efecto: Ese NPC queda fuera del cálculo de “entidades que ahora son visibles” → En pantalla: Solo unos pocos NPC concretos no se ven, o sigue ahí un NPC que ya se fue
Síntomas: Entidades invisibles / fantasma · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Cuando el servidor envía “solo lo que cambió desde la última vez”, si se pierde la información completa que se envía una vez al principio (la referencia), los cambios posteriores no se pueden aplicar.
Por qué: El paquete con la información completa (referencia) de una entidad se pierde o se descarta antes de procesarse → Efecto: El cliente no tiene sobre qué aplicar los cambios siguientes y los ignora → En pantalla: Esa entidad no se ve, o aparece de repente mucho después
Síntomas: Entidades invisibles / fantasma, Teletransporte · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
A la inversa, si se pierde el mensaje de “ha desaparecido”, un NPC o jugador que ya murió o se fue sigue solo en tu pantalla.
Por qué: Se pierde o llega desordenado el mensaje de muerte, de salida o de abandono del rango de visión → Efecto: El cliente cree que esa entidad sigue ahí → En pantalla: Monstruos que no reaccionan al golpearlos, jugadores que ya se fueron pero siguen ahí de pie
Síntomas: Entidades invisibles / fantasma · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
En cuanto el personaje entra en una zona, el servidor envía de golpe los datos de aparición de decenas o cientos de entidades cercanas. Si se envían por un canal no confiable (unreliable), o si el búfer de recepción se desborda mientras el cliente no lee el socket porque está cargando, una parte se pierde y no vuelve a llegar.
Por qué: Justo después de entrar, los datos de aparición llegan todos en un instante → Efecto: El cliente que está cargando lee el socket tarde y se desborda el búfer de recepción del SO, o un paquete UDP grande se fragmenta y basta perder un fragmento para perderlo entero. En un canal no confiable, tampoco se reenvía → En pantalla: Solo en el cliente que carga más lento faltan algunos NPC. Al salir del rango de visión y volver, aparecen
Síntomas: Entidades invisibles / fantasma · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Si el servidor reutiliza el mismo ID de entidad cuando reaparece un NPC muerto, un cliente que se perdió el mensaje de desaparición en ese intervalo confunde el NPC nuevo con el antiguo.
Por qué: Un NPC muere y reaparece con el mismo ID de entidad → Efecto: El cliente que se perdió el mensaje de desaparición ignora el mensaje de aparición porque “ya conoce esa entidad”, o la deja en estado de muerta → En pantalla: En una sola pantalla el NPC falta o se ve caído en el suelo, y a veces se ve con el aspecto de otro NPC
Síntomas: Entidades invisibles / fantasma · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Si el cliente está hecho para usar un puerto local fijo, el segundo cliente de la misma computadora no puede usar ese puerto o se reparte los paquetes con el primero.
Por qué: Los dos clientes intentan abrir el mismo puerto UDP local (compartido a la fuerza con una opción de reutilización) → Efecto: El SO entrega los paquetes entrantes a uno solo de los sockets, o no garantiza cuál los recibe. El router y el servidor también ven a los dos clientes con la misma dirección → En pantalla: Uno de ellos no recibe los paquetes del mundo: no ve los NPC ni a otros jugadores, o se desconecta
Síntomas: Entidades invisibles / fantasma, Desconexión, No conecta / carga infinita · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo)
Si el servidor o un servidor intermedio distingue las conexiones por IP o por ID de dispositivo, toma los dos clientes de la misma computadora (la misma IP pública) por una sola persona.
Por qué: La tabla de sesiones se indexa por IP o por IP + ID de dispositivo → Efecto: Los datos del segundo cliente sobrescriben la primera sesión o se mezclan con ella → En pantalla: Uno no ve los NPC y el otro se desconecta o recibe datos ajenos
Síntomas: Entidades invisibles / fantasma, Desconexión · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Si el módulo de seguridad o una política del servidor limitan los clientes de una misma computadora, el segundo cliente no puede abrirse o conectarse, o se desconecta el que se abrió primero. Algunos juegos solo bloquean funciones del cliente adicional.
Por qué: El módulo de seguridad detecta una ejecución duplicada, o el servidor limita las conexiones adicionales desde el mismo dispositivo → Efecto: Se rechaza la segunda ejecución o conexión, o se corta una de las dos. En raras ocasiones solo se bloquean algunas funciones del cliente adicional → En pantalla: No conecta, o uno de los dos se desconecta. En los juegos que solo bloquean funciones, uno de los dos no ve los NPC o la tienda
Síntomas: No conecta / carga infinita, Entidades invisibles / fantasma, Desconexión · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo)
Cuando la ventana del cliente está en segundo plano, el juego, el motor y el SO reducen sus frames y su procesamiento. Los paquetes recibidos no se procesan a tiempo y se acumulan o desbordan.
Por qué: Límite de frames en segundo plano de las opciones del juego o del driver gráfico (p. ej., el driver de NVIDIA permite elegir entre 20 y 200 por segundo), ahorro de energía, ajuste del motor que detiene el juego en segundo plano. El SO también da prioridad de CPU y GPU a la ventana en primer plano → Efecto: Se procesan menos paquetes por frame, la cola crece y, si el búfer de recepción se desborda, se descartan → En pantalla: Al traer la ventana al frente todo aparece de golpe, o algunos NPC no llegan a verse nunca
Síntomas: Entidades invisibles / fantasma, Cámara rápida, Desconexión · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Externo (Externo)
Si dos clientes escriben a la vez en la misma carpeta de caché o bloquean archivos, uno de ellos no puede cargar los modelos o texturas de los NPC.
Por qué: Los dos clientes escriben a la vez en los archivos de caché o de parches de la misma carpeta de instalación → Efecto: Falla el bloqueo del archivo o se lee un archivo a medio escribir, y la carga falla → En pantalla: NPC con el nombre visible pero sin modelo, o transparentes
Síntomas: Entidades invisibles / fantasma · Responsable principal Desarrollo de cliente (Equipo de desarrollo)
Si dos clientes se reparten la memoria gráfica, no queda sitio para cargar los modelos y texturas nuevos que hacen falta, y algunos no se dibujan.
Por qué: Los dos clientes se reparten la VRAM y la RAM. El SO también puede reducir primero la cuota de memoria gráfica de la ventana en segundo plano → Efecto: El motor no consigue cargar modelos y texturas nuevos, o los descarga y vuelve a cargar sin parar → En pantalla: Los NPC aparecen tarde, borrosos o no aparecen, tirones
Síntomas: Entidades invisibles / fantasma, Tirones · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Externo (Externo)
Si opciones como el límite de personajes visibles, ocultar los nombres o modelos de los NPC o el modo de bajos requisitos son distintas en los dos clientes, cada uno ve cosas distintas.
Por qué: Solo un cliente tiene activado el “límite de personajes cercanos visibles” o el modo de bajos requisitos → Efecto: No se dibujan los NPC lejanos o de baja prioridad (es lo normal) → En pantalla: El NPC solo falta en uno de los dos
Síntomas: Entidades invisibles / fantasma · Responsable principal Desarrollo de cliente (Equipo de desarrollo)
Si el segundo cliente es otra instalación o no terminó de parchearse, no conoce los ID de NPC nuevos que envía el servidor y los ignora en silencio.
Por qué: Una instalación en otra carpeta, o un cliente abierto en plena instalación de un parche → Efecto: Si recibe un ID de NPC o de modelo desconocido, lo salta → En pantalla: Solo los NPC recién añadidos faltan en uno de los dos
Síntomas: Entidades invisibles / fantasma · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo)
Si el servidor limita lo que envía a cada conexión y empieza por lo más cercano, la conexión con un límite bajo recibe tarde, o nunca, los NPC lejanos.
Por qué: En zonas concurridas, el servidor envía por orden de importancia dentro del límite de envío de cada conexión → Efecto: Las conexiones con un ancho de banda estimado bajo (p. ej., la de una ventana en segundo plano que confirma tarde la recepción) aplazan una y otra vez las entidades del final de la lista → En pantalla: Los NPC lejanos se ven tarde, o no se ven, en uno solo de los clientes
Síntomas: Entidades invisibles / fantasma, Input lag · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Si la hora del servidor que estima el cliente es incorrecta, la información de entidades que acaba de llegar se retiene “porque todavía es futuro” o se descarta “porque es demasiado antigua”.
Por qué: La estimación de la hora del servidor de uno de los clientes se desvía mucho (medida durante la carga, tras reactivarse del ahorro de energía) → Efecto: La hora de referencia de la interpolación y la hora de la información de entidades no coinciden → En pantalla: Las entidades aparecen tarde o se ven quietas
Síntomas: Entidades invisibles / fantasma, Tirones · Responsable principal Desarrollo de cliente (Equipo de desarrollo)
Cuando las “retransmisiones TCP” (Retransmission) aumentan en las métricas del servidor, es habitual que los reportes de lag aumenten también. Una retransmisión es la señal de que “un paquete se perdió” o de que “se dio por perdido por error”. La causa puede estar en cualquier punto de la ruta, desde el Wi-Fi hasta la tarjeta de red del servidor, y en las conexiones que envían paquetes pequeños de forma espaciada, como las de los juegos, basta con perder un solo paquete para provocar una detención de cientos de ms. Este capítulo resume las causas raíz de la retransmisión, cómo encontrarlas y cómo solucionarlas.
| Tipo | Cuándo ocurre | Tiempo hasta recuperarse | Cómo se ve en el juego |
|---|---|---|---|
| Retransmisión rápida Fast retransmit | Cuando llegan antes los paquetes posteriores y el receptor avisa de que “falta uno intermedio” (ACK duplicados, SACK) | Tiempo de ida y vuelta + tiempo hasta que llegan 3 paquetes posteriores | Un tirón breve. Cuanto más seguidos van los paquetes, más rápido |
| RACK y TLP Detección de pérdidas por tiempo, reenvío del último paquete | Cuando llega un paquete enviado después y el anterior no aparece durante cierto tiempo; o, si no llega ningún ACK durante un rato, se reenvía una vez más el último paquete | Poco después de que llegue la confirmación de un paquete posterior (RACK; como puede ser solo un cambio de orden, espera además alrededor de 1/4 del tiempo de ida y vuelta). Sin paquetes posteriores, unas 2 veces el tiempo de ida y vuelta (TLP); si solo hay un paquete sin confirmar, espera 200 ms más por el ACK retardado | Un tirón relativamente breve incluso en un thin stream. Predeterminado en los Linux recientes |
| Retransmisión por RTO Retransmission timeout | Cuando termina la espera sin ninguna señal | Tiempo de ida y vuelta + 200 ms como mínimo, y el doble con cada fallo | Congelamiento de cientos de ms a varios segundos seguido de cámara rápida; si se alarga, desconexión |
| Retransmisión del SYN | Cuando se pierde la propia solicitud de conexión: desbordamiento de la cola de conexiones pendientes (backlog) o bloqueo del firewall | 1 s, 2 s, 4 s, 8 s … (Linux 6.5 y posteriores reenvían hasta cinco veces a intervalos de 1 s y después duplican; las versiones antiguas de Windows empiezan en 3 s) | Tras presionar el botón de conexión, retrasos de segundos redondos, como 1 s o 3 s; si sigue fallando, no conecta o se queda en carga infinita |
| Retransmisión espuria Spurious retransmission | El paquete no se perdió, pero llegó tarde o desordenado y se reenvía creyendo que se perdió | No hay nada que recuperar. Solo se reduce el ritmo de envío (Linux a veces lo revierte si lo detecta con DSACK, el aviso del receptor de “ya lo recibí”, o con las marcas de tiempo) | Ancho de banda desperdiciado y menor velocidad en las transferencias grandes. En las métricas solo se ve alta la tasa de retransmisión |
| Sonda de ventana cero Se confunde con la retransmisión | Paquete de comprobación que se envía cuando el búfer del receptor está lleno y en estado de “no envíes por ahora” | Hasta que el receptor empieza a leer | Congelamiento. La conexión está bien; el programa receptor no leyó a tiempo |
La tasa de retransmisión es “la proporción de paquetes enviados que se reenviaron”. El valor acumulado desde el arranque queda diluido en los valores normales, así que se calcula con el incremento durante un intervalo fijo, como 1 minuto. No hay un criterio oficial, pero como referencia aproximada para la media de todo el servidor: por debajo del 0.1%, sano; del 0.1 al 1%, algunos jugadores notan tirones de vez en cuando; por encima del 1%, lo notan muchos jugadores; por encima del 3%, grave. En los juegos con muchos jugadores móviles o del extranjero, el valor normal sale más alto. Por eso, además de la cifra, se mira cuántas veces ha aumentado respecto a lo normal. La media se deja arrastrar por unas pocas conexiones malas, así que separarla por región, ISP, servidor y franja horaria es el camino más corto hacia la causa. Si hay un dispositivo que recibe la conexión a mitad de camino y abre una nueva hacia el servidor (proxy, algunos balanceadores de carga o gateways), las métricas del servidor del juego solo recogen el tramo entre ese dispositivo y el servidor. Las retransmisiones del lado del jugador se miran en ese dispositivo.
| Dónde mirar | Qué mirar | Qué se averigua |
|---|---|---|
| Todo el servidor (Linux) | Incremento entre dos ejecuciones de nstat separadas 1 minuto: TcpRetransSegs ÷ TcpOutSegs y, de la familia TcpExt, TCPTimeouts, TCPLossProbes/TCPLossProbeRecovery, TCPLostRetransmit, TCPSpuriousRTOs, TCPDSACKRecv y TCPSynRetrans | Tasa de retransmisión, veces que se llegó al RTO, TLP enviados y cuántos repararon una pérdida real, veces que también se perdió el reenvío, retransmisiones de solicitudes de conexión. Muchos DSACK o Spurious significan “se reenvió sin haberse perdido”. En Linux, OutSegs no incluye las retransmisiones, así que la proporción exacta es RetransSegs ÷ (OutSegs + RetransSegs), pero alrededor del 1% la diferencia es pequeña |
| Por conexión (Linux) | retrans (en recuperación ahora/acumulado), rto, backoff, rtt, cwnd, lost, reordering y bytes_retrans de ss -ti | Si solo algunos jugadores o regiones tienen muchas retransmisiones, y cuánto ha crecido el RTO (backoff es el número de veces seguidas que el RTO se duplicó). bytes_retrans ÷ bytes_sent es la tasa de retransmisión de esa conexión |
| Cada retransmisión (Linux) | Herramienta eBPF tcpretrans (bcc). -c agrupa por conexión; -l incluye los TLP | Muestra una línea con la IP, el puerto y el estado de la conexión remota cada vez que hay una retransmisión. Permite ver, de forma ligera y sin captura de paquetes, en qué rangos de jugadores o en qué servidores se concentran |
| Tarjeta de red del servidor | dropped, missed y crc de ip -s -s link; rx_missed_errors, rx_no_buffer_count, rx_crc_errors, etc. de ethtool -S (los nombres varían según el driver; en mlx5 son rx_out_of_buffer y rx_discards_phy); 2.ª columna (dropped) y 3.ª columna (time_squeeze) de /proc/net/softnet_stat | Si la tarjeta de red del servidor descartó los paquetes nada más recibirlos (búfer circular, CPU) o si hay un cable o transceptor óptico defectuoso (CRC). softnet_stat tiene una línea por CPU y está en hexadecimal. Si time_squeeze no deja de subir, el núcleo que procesa la recepción no termina su trabajo a tiempo |
| Red en la nube | En AWS ENA, bw_in_allowance_exceeded, bw_out_allowance_exceeded, pps_allowance_exceeded, conntrack_allowance_exceeded y linklocal_allowance_exceeded de ethtool -S. No aparecen en la vista básica de CloudWatch, así que se recogen aparte con el agente de CloudWatch | Si la instancia descartó paquetes en silencio al llegar a su límite. Si los valores suben, se está superando el límite. Las demás nubes también tienen límites de ancho de banda y de conexiones según el tamaño de la VM |
| Switches, routers y firewalls | Errores CRC y de entrada en los puertos, descartes de salida, excesos del policer, uso de la tabla de sesiones, logs de descartes | Si se descartó en el tramo de equipos de red del centro de datos. Si la utilización media de 5 minutos es baja pero los descartes de salida suben, son microrráfagas (concentraciones de tráfico muy breves) |
| Ruta | Pérdida que continúa hasta el final con mtr o pathping. Hacen falta cientos de envíos o más para ver una pérdida de alrededor del 1%, y es más preciso enviar al mismo puerto TCP que usa el juego (mtr -T -P PORT) | En qué salto empieza la pérdida. Si solo un salto intermedio muestra pérdida y los siguientes están bien, ese dispositivo simplemente limita las respuestas de medición (ICMP). Como la ida y la vuelta pueden ir por rutas distintas, también se mide desde el servidor hacia el jugador |
| Captura de paquetes (en ambos extremos) | Filtro de Wireshark tcp.analysis.retransmission y, de la misma familia tcp.analysis., fast_retransmission, spurious_retransmission, duplicate_ack, lost_segment y zero_window | Si el paquete original está en la captura del emisor y no en la del receptor, se perdió entre ambos. Si también está en la del receptor, es una retransmisión espuria o el ACK se retrasó o se perdió en el camino de vuelta. Los paquetes que descarta el búfer circular del servidor receptor también aparecen en la captura como “perdidos entre ambos”, así que hay que mirarlos junto con los contadores de la tarjeta de red |
| Servidor Windows | TCPv4\Segments Retransmitted/sec ÷ Segments Sent/sec del Monitor de rendimiento, Network Interface\Packets Received Discarded, netsh int tcp show global, pktmon (integrado en Windows 10 versión 1809 y Windows Server 2019 o posteriores) | Evolución de la tasa de retransmisión, si la tarjeta de red descartó los paquetes nada más recibirlos, configuración TCP, en qué punto de Windows se descartaron |
Orden de revisión: al revisarlo con el equipo de infraestructura, este orden es el más rápido.
Si el reporte incluye la hora (al segundo), el ISP y la región del jugador, el servidor al que se conectó y el nombre del síntoma, el equipo de infraestructura puede seguir este orden de inmediato.
1. Que no se pierdan (solución de fondo)
2. Que se recuperen rápido
tcp_thin_linear_timeouts para thin streams y, en Linux 6.15 o posterior, bajar el límite superior del RTO con TCP_RTO_MAX_MSTCP_NODELAY en las conexiones del juego (si Nagle retiene los paquetes nuevos sin enviarlos, desaparecen los paquetes posteriores que usa RACK)ip route … rto_min)TCP_USER_TIMEOUT y el heartbeat del juego3. Que la retransmisión afecte menos (arquitectura)
TCP_NOTSENT_LOWAT, etc.). Así se acorta la cámara rápida tras una detención largaCasi todas las opciones relacionadas con la recuperación de retransmisiones son configuración del sistema operativo (kernel), y solo unas pocas son opciones de socket que se pueden activar solo para las conexiones del juego. TCP_NODELAY, que se confunde a menudo por su nombre, no acelera la recuperación. Pero si no se activa (se usa Nagle), los paquetes nuevos se retrasan aún más durante la recuperación. Lo siguiente se refiere a Linux; en Windows, los nombres y el alcance del soporte son distintos.
| Opción | Dónde | Qué cambia | Precauciones |
|---|---|---|---|
TCP_NODELAY | Opción de socket | Desactiva Nagle. Envía los mensajes pequeños de inmediato, sin agruparlos | Elimina la espera de 40–200 ms que aparece incluso sin pérdidas. El temporizador de retransmisión (RTO) no cambia. Pero con Nagle activado, mientras se espera la recuperación también se retienen los paquetes nuevos, que esperan un viaje de ida y vuelta más tras la recuperación; además desaparecen los paquetes posteriores en los que se apoyan la retransmisión rápida y RACK, y es fácil acabar en el RTO. Lo normal en juegos es activarlo |
net.ipv4.tcp_recovery (RACK) | Configuración del kernel | Detección de pérdidas por tiempo. Tolera bien los cambios de orden y también recupera rápido los thin streams | Valor predeterminado 1 (activado). Llegó en Linux 4.4 y tomó su forma actual hacia la 4.18. Desde la 6.17, RACK es el único método de detección de pérdidas, así que cambiarlo a 0 no tiene efecto. No funciona en conexiones sin SACK |
net.ipv4.tcp_early_retrans (TLP) | Configuración del kernel | Si no llega ningún ACK durante un tiempo (unas 2 veces el tiempo de ida y vuelta), reenvía una vez más el último paquete para detectar rápido la pérdida de los últimos paquetes (tail loss) | Valor predeterminado 3 (activado); 0 lo desactiva. Necesita SACK. Si solo hay un paquete en vuelo (in-flight), espera 200 ms más y se parece al RTO |
net.ipv4.tcp_sack, tcp_dsack, tcp_timestamps | Configuración del kernel | ACK selectivo (SACK, aviso de los huecos), aviso de recepción duplicada (DSACK), medición del tiempo de ida y vuelta (marcas de tiempo) | Todos activados por defecto. Algunos servidores siguen con ellos desactivados desde los problemas de seguridad de SACK de 2019. Si SACK está desactivado, RACK y TLP tampoco funcionan |
net.ipv4.tcp_thin_linear_timeouts / TCP_THIN_LINEAR_TIMEOUTS | Configuración del kernel / opción de socket | En las conexiones con menos de 4 paquetes en vuelo (in-flight), el RTO no se duplica durante las 6 primeras veces | Desactivado por defecto. Con la opción de socket se puede activar solo para las conexiones del juego. No reduce el primer RTO |
TCP_RTO_MAX_MS / net.ipv4.tcp_rto_max_ms | Opción de socket / configuración del kernel (Linux 6.15 o posterior) | Baja el límite superior (120 s por defecto) del RTO que se va duplicando. Mínimo 1 s | Evita que el RTO crezca hasta decenas de segundos tras pérdidas consecutivas. También acelera la detección de conexiones muertas |
net.ipv4.tcp_mtu_probing | Configuración del kernel | Si los paquetes grandes siguen desapareciendo, reduce el tamaño para atravesar el agujero negro de MTU | Valor predeterminado 0 (desactivado). 1 = solo reduce cuando las retransmisiones duran unos 3 s y se sospecha de un agujero negro (mientras tanto, la conexión se detiene). 2 = empieza desde 1,024 bytes y va probando tamaños mayores poco a poco |
ip route … rto_min | Configuración de rutas | Baja el RTO mínimo (200 ms por defecto) de esa ruta | Solo en la red interna entre servidores. Si se baja en tramos de internet, aumentan las retransmisiones espurias. En Linux 6.11 o posterior, net.ipv4.tcp_rto_min_us es un valor de todo el servidor y también cambia las conexiones por internet. Desde la 6.15, la opción de socket TCP_RTO_MIN_US permite bajarlo solo en las conexiones internas |
TCP_USER_TIMEOUT | Opción de socket | Tiempo hasta abandonar la conexión cuando las retransmisiones continúan | No acelera la recuperación. Permite cortar rápido las conexiones muertas y reconectar. Si no se configura, Linux solo corta tras unas 15 retransmisiones, unos 15 minutos (tcp_retries2) |
SO_KEEPALIVE + TCP_KEEPIDLE, etc. | Opción de socket | Comprueba si una conexión inactiva sigue viva | No tiene que ver con la retransmisión. Sirve para mantener los mapeos de NAT y LB y detectar conexiones muertas |
Cola fq + SO_MAX_PACING_RATE, BBR | Configuración de colas / opción de socket / configuración del kernel | Reparte el envío de paquetes de forma uniforme y reduce las pérdidas por ráfagas (envíos concentrados de golpe) | Sirve para “prevenir” pérdidas. No influye en la velocidad de recuperación |
El Wi-Fi y las redes móviles reintentan varias veces la transmisión en el tramo inalámbrico y, si aun así no lo consiguen, descartan el paquete. TCP vuelve a enviar ese paquete bastante después.
Por qué: La señal es débil o hay muchas interferencias, y las transmisiones en el tramo inalámbrico fallan una tras otra → Efecto: Al superar el límite de reintentos del dispositivo inalámbrico (normalmente de unos pocos a algo más de diez), el paquete se descarta → En pantalla: Congelamiento mientras dura la espera de la retransmisión TCP; los paquetes siguientes aguardan en el búfer de recepción y luego llega todo en cámara rápida
Síntomas: Congelamiento, Cámara rápida, Teletransporte · Responsable principal Externo (Externo) · También Infraestructura de servidores (Equipo de infraestructura), Desarrollo de servidor (Equipo de desarrollo), Desarrollo de cliente (Equipo de desarrollo)
Cuando se llena la cola del punto más estrecho, como el router, la interconexión entre ISP o el enlace del centro de datos, los paquetes que llegan se descartan.
Por qué: El video, las descargas o el tráfico de otras personas llenan el cuello de botella → Efecto: Mientras la cola está llena, los paquetes que llegan se descartan uno tras otro (tail drop). Los que no se descartan también esperan al final de una cola llena → En pantalla: Desaparecen varios paquetes a la vez: congelamiento largo seguido de cámara rápida, frecuente por la noche
Síntomas: Congelamiento, Cámara rápida, Rubber banding · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Externo (Externo), Desarrollo de cliente (Equipo de desarrollo)
Si el servidor envía de golpe en cada tick las actualizaciones de miles de jugadores, el pequeño búfer de un switch o el límite instantáneo de la nube se desborda en menos de 1 ms y parte de los paquetes se descarta.
Por qué: Al empezar el tick se envían a la vez los paquetes para todos los jugadores → Efecto: El búfer del puerto del switch donde confluye el tráfico de varios servidores (de cientos de KB a unos pocos MB por puerto) o el límite de la instancia en la nube se desborda por un instante (con una utilización media baja) → En pantalla: Varios jugadores sufren a la vez teletransporte y tirones; las métricas medias no muestran la causa
Síntomas: Teletransporte, Congelamiento, Cámara rápida · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura), Infraestructura de red (Equipo de infraestructura)
Los planes de los ISP, los límites de las instancias en la nube y los dispositivos de protección DDoS a veces descartan al instante, sin encolarlos, los paquetes que superan una velocidad fijada.
Por qué: El volumen enviado en un instante supera la velocidad permitida o la ráfaga permitida → Efecto: Los paquetes que sobran se descartan en el acto, sin cola (policing) → En pantalla: En cada ráfaga grande desaparecen varios paquetes: congelamiento seguido de cámara rápida, aunque la velocidad media parezca estar por debajo del límite
Síntomas: Congelamiento, Cámara rápida, Teletransporte · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Infraestructura de servidores (Equipo de infraestructura), Desarrollo de servidor (Equipo de desarrollo)
Los cables dañados, los conectores ópticos sucios y los transceptores ópticos al final de su vida útil producen errores de bit, y los dispositivos descartan en silencio los paquetes corruptos.
Por qué: Un cable, un transceptor óptico o un conector defectuoso invierte bits → Efecto: El dispositivo descarta los paquetes cuya suma de verificación (CRC) no cuadra → En pantalla: Solo los jugadores cuyo tráfico pasa por esa ruta sufren de forma constante tirones breves seguidos de cámara rápida, a cualquier hora
Síntomas: Congelamiento, Cámara rápida, Teletransporte · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Infraestructura de servidores (Equipo de infraestructura), Externo (Externo)
Si un extremo usa autonegociación y el otro tiene la velocidad y el dúplex fijos, un lado acaba funcionando en half-duplex (semidúplex) y pierde paquetes por colisiones cada vez que hay carga.
Por qué: Solo un extremo tiene la velocidad y el dúplex fijados a mano → Efecto: Un lado funciona en full-duplex y el otro en half-duplex, y se producen colisiones y colisiones tardías → En pantalla: Normalmente todo va bien, pero cuando sube el tráfico todos los jugadores que pasan por ese dispositivo sufren congelamiento seguido de cámara rápida
Síntomas: Congelamiento, Cámara rápida · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Infraestructura de servidores (Equipo de infraestructura)
Los paquetes llegan al servidor, pero se descartan porque se desborda el búfer circular de la NIC (el búfer donde se guardan un momento los paquetes que llegan) o porque se satura el núcleo que procesa la recepción en el kernel.
Por qué: Pico de conexiones, interrupciones concentradas en un solo núcleo, CPU steal en la máquina virtual o sobrecarga del switch virtual → Efecto: Descarte en el búfer circular (rx_missed_errors, etc.; el nombre cambia según el driver) o en la cola de recepción del kernel (softnet dropped) → En pantalla: Cuando se junta mucha gente, los inputs tardan en hacer efecto en todo el servidor a la vez y hay tirones
Síntomas: Input lag, Congelamiento, Cámara rápida, Teletransporte · Responsable principal Infraestructura de servidores (Equipo de infraestructura)
Los firewalls y el seguimiento de conexiones de Linux (conntrack, la función que registra en una tabla las conexiones que pasan) descartan paquetes cuando la tabla se llena o cuando consideran que no encajan con el estado de la conexión.
Por qué: La tabla de seguimiento de conexiones se llena (table full), o la ida y la vuelta van por rutas distintas y solo un sentido pasa por el firewall (ruta asimétrica) → Efecto: El firewall toma los paquetes como de una “conexión desconocida” o con un “número de secuencia fuera de la ventana” y los descarta → En pantalla: Si la tabla se llena, no entran conexiones nuevas; si las rutas no coinciden, solo los jugadores de esa ruta acaban en desconexión tras repetidas retransmisiones
Síntomas: Congelamiento, Desconexión, No conecta / carga infinita · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Infraestructura de servidores (Equipo de infraestructura), Desarrollo de servidor (Equipo de desarrollo), Desarrollo de cliente (Equipo de desarrollo)
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 · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Si un tramo intermedio pasa a aceptar paquetes más pequeños y el aviso de “demasiado grande” (ICMP) está bloqueado, los paquetes grandes siguen desapareciendo por muchas veces que se reenvíen.
Por qué: El tamaño máximo se reduce en un tramo con VPN o túnel, y un firewall bloquea los avisos de tamaño excedido → Efecto: El emisor, sin saber por qué, retransmite una y otra vez el mismo paquete grande, y el RTO se duplica cada vez → En pantalla: Todo va bien normalmente, pero en cuanto se mueven datos grandes (inventario, zonas con mucha gente, carga al entrar) se detiene todo, incluidos los paquetes pequeños que vienen detrás (congelamiento); al final, desconexión o carga infinita
Síntomas: Congelamiento, Desconexión, No conecta / carga infinita · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Infraestructura de servidores (Equipo de infraestructura), Desarrollo de servidor (Equipo de desarrollo)
Si un dispositivo intermedio borra el mapeo de una conexión inactiva (la entrada que indica a dónde reenviar esa conexión), el siguiente paquete que se envía no llega a su destino. O bien se repiten las retransmisiones hasta que la conexión se corta, o bien el dispositivo devuelve un rechazo de conexión (RST) y se corta al momento.
Por qué: Conexión sin paquetes durante un buen rato (jugador ausente, en el lobby) → Efecto: El NAT del router, el CGNAT del ISP, un firewall, un balanceador de carga o un grupo de seguridad en la nube borra el mapeo inactivo → En pantalla: Al volver a moverse, retransmisiones seguidas y luego desconexión, o desconexión inmediata
Síntomas: Desconexión, Congelamiento · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo), Infraestructura de red (Equipo de infraestructura), Infraestructura de servidores (Equipo de infraestructura)
Se pierden paquetes durante los segundos en que cambia una ruta de internet, o en las conexiones asignadas a una ruta defectuosa entre varias rutas ECMP.
Por qué: Recálculo de rutas BGP, o un dispositivo o enlace defectuoso en una de varias rutas (ECMP, LAG) → Efecto: Pérdida temporal durante el cambio de ruta, o pérdida constante solo en las conexiones que van por esa ruta → En pantalla: De repente, congelamiento de unos segundos seguido de cámara rápida, o “al reconectar se arregla” (se asigna otra ruta)
Síntomas: Congelamiento, Cámara rápida, Teletransporte · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo), Externo (Externo)
El paquete no se pierde; solo llega muy tarde por un momento. Pero si ese retraso supera el RTO, el emisor lo da por perdido y lo retransmite.
Por qué: Por bufferbloat, el ahorro de energía del Wi-Fi, un cambio de estado de la radio móvil o una pausa de la máquina virtual, la latencia sube de golpe a cientos de ms → Efecto: El RTO expira antes y se retransmite, y el original también llega enseguida (el receptor lo recibe duplicado) → En pantalla: El congelamiento y la cámara rápida se deben al propio pico de latencia. La retransmisión espuria apenas los alarga, pero sube las métricas de retransmisión y se confunde con pérdida
Síntomas: Congelamiento, Cámara rápida, Input lag · Responsable principal Externo (Externo) · También Infraestructura de servidores (Equipo de infraestructura), Desarrollo de cliente (Equipo de desarrollo)
Cuando los paquetes cambian de orden al pasar por varias rutas o por enlaces agregados, el receptor avisa con ACK duplicados de que “falta un paquete”, y el emisor reenvía paquetes que estaban bien.
Por qué: Los dispositivos que reparten el tráfico entre rutas paquete a paquete, los LAG (agregación de enlaces) que reparten paquete a paquete o el instante de un cambio de ruta desordenan los paquetes → Efecto: Los paquetes posteriores llegan antes y se acumulan 3 ACK duplicados → retransmisión rápida → En pantalla: Los paquetes del juego, que van espaciados, casi no se ven afectados. Las actualizaciones grandes en zonas con mucha gente y las descargas de parches se vuelven lentas, y a veces hay tirones
Síntomas: Tirones, Input lag · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Infraestructura de servidores (Equipo de infraestructura)
Los datos llegaron bien, pero si el ACK que confirma la recepción se retrasa o se pierde en una cola de subida llena, el emisor lo da por perdido y retransmite.
Por qué: En casa, una subida de video o una copia de seguridad en la nube satura la subida → Efecto: Los ACK se retrasan cientos de ms en la cola del router, o la cola se desborda y se descartan → En pantalla: Los paquetes del juego que envía el servidor suelen llegar a tiempo. Tus inputs, acumulados en la misma cola de subida, se retrasan: input lag y rubber banding, y a veces retransmisiones espurias
Síntomas: Input lag, Rubber banding · Responsable principal Externo (Externo) · También Desarrollo de cliente (Equipo de desarrollo)
Si se baja demasiado el RTO mínimo, cualquier pequeño retraso provoca retransmisiones espurias; y el valor predeterminado (200 ms) es demasiado largo para un juego, así que cada pérdida detiene la conexión mucho tiempo.
Por qué: Se baja mucho el RTO mínimo pensando en el centro de datos, o se deja el valor predeterminado tal cual en los tramos de internet → Efecto: Si es bajo, hay avalanchas de retransmisiones con cualquier pico de latencia; si es alto, cada pérdida implica una espera larga → En pantalla: Con el valor predeterminado, cada pérdida provoca un congelamiento de cientos de ms seguido de cámara rápida; si se baja demasiado, los congelamientos se acortan, pero las retransmisiones espurias se disparan y desperdician el enlace
Síntomas: Congelamiento, Cámara rápida, Input lag · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Cuando se envían paquetes pequeños y espaciados, como en un juego, el RTO llega antes de que se junten los “3 paquetes posteriores”. Ante la misma pérdida, la conexión se detiene mucho más tiempo que en una transferencia grande.
Por qué: Con paquetes cada 100 ms más o menos, hay muy pocos paquetes todavía sin ACK (in-flight) → Efecto: Juntar 3 ACK duplicados lleva más de 300 ms, así que antes salta el RTO (ping + 200 ms), que se duplica si hay pérdidas seguidas → En pantalla: Cada pérdida provoca un congelamiento de unos 0.3 s; si se pierde también la retransmisión, congelamiento de casi 1 segundo seguido de cámara rápida
Síntomas: Congelamiento, Cámara rápida · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura), Desarrollo de cliente (Equipo de desarrollo)
Si algunos firewalls o aceleradores eliminan o modifican las opciones TCP, cuando se pierden varios paquetes solo se recupera uno por cada ida y vuelta, o la ventana (lo que se puede enviar de una vez) se reduce, y todo va más lento.
Por qué: La “normalización TCP” de un firewall o un acelerador antiguo elimina las opciones de SACK, marcas de tiempo (timestamps) y escalado de ventana → Efecto: Si se pierden varios paquetes, se recupera uno por cada ida y vuelta, y la ventana queda limitada a 64 KB → En pantalla: Cada pérdida provoca un congelamiento mucho más largo (sin SACK tampoco se puede usar RACK-TLP), seguido de cámara rápida al liberarse. Las transferencias grandes, como los parches, también van lentas
Síntomas: Congelamiento, Cámara rápida · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Infraestructura de servidores (Equipo de infraestructura)
Cuando el programa receptor no lee el socket a tiempo y el búfer se llena, el emisor deja de enviar y solo manda sondas de ventana cero. El problema no está en la red.
Por qué: El cliente deja de procesar frames o un hilo del servidor se bloquea, y nadie lee el socket → Efecto: La ventana de recepción llega a 0, y el emisor deja de enviar y solo manda sondas (a intervalos cada vez más largos) → En pantalla: Congelamiento seguido de cámara rápida. En la captura de paquetes aparece “ZeroWindow” y no hay pérdida
Síntomas: Congelamiento, Cámara rápida · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo), Infraestructura de servidores (Equipo de infraestructura)
Si una solicitud de conexión se pierde porque se desborda la cola de conexiones pendientes (backlog) o porque la bloquea un firewall, el SO del cliente la reenvía al cabo de 1 segundo y luego a intervalos cada vez más largos.
Por qué: Justo después de un mantenimiento, una avalancha de conexiones desborda la cola de conexiones pendientes del servidor, o un firewall o la protección DDoS descarta los SYN → Efecto: El SO del cliente retransmite el SYN a intervalos predefinidos a partir de 1 segundo (en los Linux antiguos, 1 s → 2 s → 4 s) → En pantalla: Tras presionar el botón de conexión, la espera es de segundos exactos, como 1 o 3 s, y si sigue fallando, el juego no conecta o se queda en carga infinita
Síntomas: No conecta / carga infinita · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura), Infraestructura de red (Equipo de infraestructura), Desarrollo de cliente (Equipo de desarrollo)
Un mismo lag no siempre lo arregla el mismo equipo. El código del cliente y del servidor y el diseño del netcode son cosa del equipo de desarrollo; los enlaces, los equipos de red, los servidores y los servidores de BD, del equipo de infraestructura. Los problemas del lado del jugador (su PC y su red doméstica), del tramo del ISP o del proveedor de nube no los puede arreglar directamente ninguno de los dos equipos, así que se dan indicaciones, se hacen solicitudes o se buscan rodeos. Todas las fichas de causa indican el responsable principal y quién más participa, y al desplegar “Cifras de referencia·Cómo verificarlo·Acciones por equipo” en la ficha aparecen las tareas de cada equipo.
| Responsable | Ámbito | Medios de solución habituales |
|---|---|---|
| Equipo de desarrolloCliente | Código del cliente del juego: frames, GC y carga, interpolación, extrapolación y predicción, y la parte de red del cliente (incluidos el envío de heartbeats y la reconexión automática) | Cambios de código, ajuste del búfer de interpolación y de la predicción, cambios en la forma de cargar, intervalo de heartbeat y flujo de reconexión, parches del cliente |
| Equipo de desarrolloServidor | Código del servidor del juego: ticks, hilos y locks, diseño del netcode, gestión de conexiones (bucle de accept y argumentos de listen), respuesta a heartbeats y limpieza de conexiones caídas, opciones de socket, diseño de consultas y transacciones | Optimización de la lógica, llamadas asíncronas, reparto de ticks y zonas, cola de inicio de sesión, reanudación de sesión con token, opciones de socket (TCP_NODELAY, etc.), diseño de consultas e índices, parches del servidor |
| Equipo de infraestructuraRed | Enlaces y equipos de red del centro de datos (switches, routers, firewalls, balanceadores de carga, protección DDoS), ACL de red, enrutamiento de VPC y balanceadores de carga en la nube, ISP y peering | Configuración y sustitución de equipos de red, ampliación de enlaces y peering, cambios de ruta, escalado de incidencias al ISP, ajuste de timeouts por inactividad y límites de sesiones en balanceadores de carga y firewalls |
| Equipo de infraestructuraServidores/SO | Servidores físicos e instancias en la nube (incluidos grupos de seguridad y seguimiento de conexiones), configuración del SO y del kernel, NIC, entornos de despliegue y monitoreo | Ampliación y cambio de instancias, configuración del kernel (sysctl: somaxconn, conntrack, etc.), configuración de grupos de seguridad y tiempo de seguimiento de conexiones, búfer circular de la NIC y reparto de interrupciones, ajuste de los horarios de cron y copias de seguridad |
| Equipo de infraestructuraServidores de BD | Servidores y almacenamiento de BD, configuración, replicación y copias de seguridad de la BD, servidores de caché | Ampliación de la BD, IOPS suficientes en el almacenamiento, parámetros de la BD y configuración de la replicación, ajuste de copias de seguridad y checkpoints |
| ExternoJugador/ISP/nube | PC y red doméstica del jugador, tramo del ISP (fuera de nuestros contratos), proveedor de nube | Indicaciones al jugador (conexión por cable, etc.), solicitudes al ISP o al proveedor de nube, rodeos y mitigación del lado del juego |
El número en negrita es la cantidad de causas en las que ese responsable es el principal, y +número, las causas en las que también participa. Haz clic en una celda para ver abajo esas causas y las tareas del equipo.
El responsable principal es quien tiene la causa raíz o quien puede eliminarla. Aunque la causa sea la conexión o un dispositivo, el equipo de desarrollo resiste mientras tanto con diseños que reducen el impacto (búfer de interpolación, envío redundante de inputs, reconexión); y si la causa es el código del servidor, que el equipo de infraestructura añada servidores solo aplaza el problema. Los límites que más se confunden quedaron así.
En la tabla, “Primero” indica a quién llamar primero, y se decide contando los responsables principales de las fichas de causa que corresponden a esa situación. Si hay dos, el primero es el responsable principal en más fichas, y el segundo es a quién llamar también desde el principio.
| Situación | Tareas del equipo de desarrollo | Tareas del equipo de infraestructura | Métricas que mirar primero |
|---|---|---|---|
| Mucha pérdida y jitter en un ISP o una región PrimeroEquipo de infraestructuraRed | Búfer de interpolación adaptativo, envío solapado de inputs, transporte UDP resistente a la pérdida, extraer la IP, el puerto y la hora de los afectados con estadísticas de pérdida y retransmisión por conexión, relajar la validación de movimiento según el estado de la conexión | Medir la ruta en ambos sentidos con el mismo protocolo y puerto que el juego (mtr), retirar las rutas defectuosas, escalar el caso al ISP, añadir peering o enlaces | Distribución de la tasa de pérdida y del jitter por ISP, tasa de retransmisión |
| Aumento de las retransmisiones TCP PrimeroEquipo de infraestructuraRedEquipo de desarrolloServidor | TCP_NODELAY, repartir dentro del tick el envío de cada tick, leer el socket a tiempo (evitar la ventana cero), mantener los mapeos con heartbeats, mandar los paquetes en tiempo real por UDP o por otra conexión, no acumular posiciones antiguas en el búfer de envío (TCP_NOTSENT_LOWAT) | Eliminar los puntos de pérdida (cables, transceptores ópticos, dúplex, policer, seguimiento de conexiones del firewall, MTU), ajustar el MSS, búfer circular e interrupciones repartidas en el servidor, configuración de recuperación del kernel (RACK, tcp_mtu_probing) | Incremento de retransmisiones (nstat), número de ventanas cero, contadores de descartes y CRC de la NIC y de los puertos del switch |
| Ticks excedidos por CPU del servidor saturada PrimeroEquipo de desarrolloServidor | Optimizar el cálculo de visibilidad y el broadcast, repartir el tick entre varios hilos, dividir las zonas y canales concurridos, ajustar el número de hilos de trabajo al límite de CPU, registrar el tiempo de tick como métrica | CPU o instancias con alto rendimiento por núcleo (frecuencia), alertas de uso de CPU por núcleo, revisar CPU steal y throttling de CPU en contenedores, separar los núcleos que atienden interrupciones de los del hilo del tick | Tiempo de tick, uso de CPU por núcleo, steal y número de throttlings (nr_throttled) |
| Respuestas lentas de la BD PrimeroEquipo de desarrolloServidorEquipo de infraestructuraServidores de BD | Diseño de consultas, índices y transacciones (cortas, con el mismo orden de bloqueo), llamadas asíncronas fuera del hilo del juego, consultas agrupadas y caché, ajustar el tamaño del pool de conexiones y el timeout de espera | Encontrar consultas lentas, planes de ejecución y esperas de bloqueos y compartirlos con el equipo de desarrollo, configuración de checkpoints, replicación y actualización de estadísticas, IOPS del almacenamiento, comprobar que número de servidores × tamaño del pool no supere el máximo de conexiones, ampliar los servidores de BD | Log de consultas lentas, esperas de bloqueos, esperas de conexión, retraso de replicación, IOPS |
| No conecta justo después del mantenimiento PrimeroEquipo de desarrolloServidor | Que el hilo que acepta conexiones (bucle de accept) no se bloquee con otras tareas, ampliar el argumento backlog de listen, sistema de cola de inicio de sesión, agrupar las consultas de inicio de sesión (eliminar N+1), alargar el intervalo de reintento del cliente y repartirlo al azar | somaxconn y SYN cookies del kernel, límites de sesiones de firewalls y balanceadores de carga, límites de conntrack y de descriptores de archivo del servidor, precalentar la caché de la BD, escalar los servidores antes de los eventos | ListenOverflows, uso de la tabla de sesiones y de conntrack, número de consultas de inicio de sesión y esperas de conexión |
| Desconexión al quedarse inactivo PrimeroEquipo de desarrolloCliente | Cliente: enviar heartbeats a un intervalo de como máximo la mitad del timeout por inactividad más corto (para que, si uno se retrasa o se pierde, el siguiente llegue antes del timeout) y reconectar automáticamente si se corta. Servidor: responder a los heartbeats, cerrar primero la conexión si no recibe ninguno durante cierto tiempo y reanudarla con un token de sesión. | Reunir los timeouts por inactividad de los balanceadores de carga y firewalls de la ruta (Red) y el tiempo de seguimiento de conexiones de los grupos de seguridad en la nube (Servidores/SO) y compartirlos con el equipo de desarrollo; ampliarlos en nuestros dispositivos si hace falta. Los timeouts del router del jugador y del CGNAT del ISP no se pueden cambiar | Distribución del tiempo de inactividad de las conexiones cortadas (si se concentra cerca de un valor, hay un dispositivo con ese timeout), tipo de red (móvil o cable) |
| El servidor se detiene a horas fijas PrimeroEquipo de desarrolloServidorEquipo de infraestructuraServidores/SO | Repartir al azar las horas de eventos en punto, guardados, temporizadores y expiración de caché; dividir las consultas batch en trozos pequeños; elegir explícitamente un GC con pausas cortas | Repartir los horarios de cron, copias de seguridad y compresión de logs y bajar su prioridad de E/S; hacer las copias de seguridad de la BD desde una réplica y repartir los checkpoints; revisar los créditos de ráfaga del disco; limitar la velocidad de transferencia de las copias de seguridad | Hora de la detención y calendario de tareas (cron, copias de seguridad, batch, checkpoints), logs del GC |
| DDoS y avalanchas de tráfico PrimeroEquipo de infraestructuraRed | Compartir con el equipo de infraestructura el patrón de tráfico del juego (puertos, tamaño de paquete, paquetes por segundo), limitar la frecuencia de solicitudes por cuenta y personaje, bloquear pronto los paquetes anómalos | Protección DDoS (scrubbing) y reglas de protección ajustadas al tráfico del juego, ocultar las direcciones de los servidores, límite de paquetes por segundo de los dispositivos, tener en cuenta las IP compartidas de los ISP y los cibercafés en los límites por IP | Paquetes por segundo, CPU y descartes de los dispositivos, tasa de conexiones fallidas por región e ISP (para detectar falsos positivos) |
| Problemas del jugador con su Wi-Fi o su PC PrimeroExternoJugador/ISP/nubeEquipo de desarrolloCliente | Mostrar el estado de la red dentro del juego (ping, pérdida), ajustar automáticamente la longitud del búfer de interpolación según el jitter, registrar en los logs del momento en que hay lag el tipo de red y el uso de CPU de la computadora, mostrar mensajes que recomienden la conexión por cable, etc. | No se puede arreglar directamente. Si los reportes se concentran en un mismo ISP o región, reclasificar como problema de la conexión | Datos de conexión y dispositivo de los reportes, proporción de un mismo ISP o región |
Equipo de desarrollo → equipo de infraestructura
Equipo de infraestructura → equipo de desarrollo
Ambos equipos: designar a un responsable del incidente, llevar un registro cronológico en un solo canal y anunciar de antemano la hora de la siguiente actualización. Si el responsable principal pasa a otro equipo, se le entrega este registro para no repetir las mismas comprobaciones. Al terminar, con ese mismo registro se corrigen el responsable y las tareas de la ficha de la causa.
Es el propio programa del juego, que corre en la computadora o el teléfono del jugador. Aunque la red sea perfecta, si los frames se retrasan aquí, la pantalla va a tirones. Y también aquí se decide lo bien que se disimula una red mala.
El juego repite lo mismo unas 60 veces por segundo: lee los inputs, procesa los paquetes recibidos, avanza un paso el estado del juego y dibuja la pantalla. Cada iteración de este bucle es un frame, y a 60 FPS cada frame dispone de 16.7 ms (33.3 ms en un juego móvil que corre a 30 FPS). Si un frame se retrasa, la pantalla se queda quieta ese tiempo y en el siguiente frame se mueve de una vez todo lo acumulado.
En la parte de red, lo que hace el cliente es “rellenar la información que falta”. Las posiciones de los demás jugadores llegan del servidor de forma espaciada, así que hay que dibujar lo que pasa entre ellas (interpolación); si los paquetes se cortan, hay que estimar cómo se mueven (extrapolación); y tu personaje se mueve en pantalla sin esperar la confirmación del servidor (predicción). La forma en que fallan estas técnicas es justamente el teletransporte, el rubber banding y los tirones.
El cliente del juego es la sala de control de una cadena que emite en directo. Si desde el lugar de los hechos (el servidor) llegan fotos de forma espaciada, las enlaza con naturalidad para que parezcan video. Si las fotos llegan tarde, no hay nada que enlazar y la imagen se congela; y si la propia sala de edición está saturada, la emisión también se corta.
Calcular un frame tarda varias veces más de lo normal y la imagen se detiene un instante.
Por qué: Una avalancha de efectos de habilidades, spawns masivos o una actualización completa de la UI se concentran en un solo frame → Efecto: El frame no termina en 16.7 ms y tarda 50–300 ms → En pantalla: La imagen se detiene un instante y en el frame siguiente todo se mueve de golpe
Síntomas: Tirones, Congelamiento · Responsable principal Desarrollo de cliente (Equipo de desarrollo)
El juego entero se detiene mientras se recupera la memoria ya usada y desechada (basura). Lo característico son tirones a intervalos regulares.
Por qué: En cada frame se crean y se desechan cadenas de texto, arrays y listas temporales → Efecto: Cuando se acumula basura, el GC detiene el hilo principal para liberarla → En pantalla: Tirones regulares cada pocos segundos o cada varias decenas de segundos
Síntomas: Tirones, Congelamiento · Responsable principal Desarrollo de cliente (Equipo de desarrollo)
El juego se detiene para leer archivos y crear shaders justo antes de dibujar zonas, monstruos o efectos que aparecen por primera vez.
Por qué: Entrar en una zona nueva o ver por primera vez una habilidad, un equipamiento o un monstruo → Efecto: El hilo principal espera a que terminen la lectura de archivos y la compilación de shaders → En pantalla: Se detiene 0.1–1 s solo la primera vez; a partir de la segunda va bien
Síntomas: Congelamiento, Tirones · Responsable principal Desarrollo de cliente (Equipo de desarrollo)
En un almacenamiento lento como un HDD, la lectura de texturas y modelos de un mundo abierto no sigue el ritmo del desplazamiento, así que las entidades aparecen tarde o el juego da tirones mientras espera la lectura.
Por qué: Moverse rápido en montura o teletransportarse, o entrar en un sitio con mucha gente, hace que se necesiten muchas texturas y modelos nuevos a la vez → Efecto: Un almacenamiento lento como un HDD no lee a la velocidad necesaria, las solicitudes de lectura se acumulan y algunas cargas hacen esperar al hilo principal hasta que terminan → En pantalla: Texturas borrosas durante un rato, edificios y personajes que aparecen tarde, y tirones o congelamientos mientras se espera la lectura
Síntomas: Entidades invisibles / fantasma, Tirones, Congelamiento · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Externo (Externo)
Cuando cientos de jugadores entran en la misma pantalla, como en un asedio o un world boss, el costo de dibujarlos se vuelve inasumible.
Por qué: Cientos de jugadores y efectos se superponen en la misma pantalla → Efecto: El costo de animaciones, sombras, nombres sobre los personajes y efectos crece en proporción al número de jugadores → En pantalla: Los FPS caen (60 → 15), todos los movimientos van a tirones y los inputs también responden tarde
Síntomas: Tirones, Input lag · Responsable principal Desarrollo de cliente (Equipo de desarrollo)
Si el cliente solo procesa una cantidad fija de paquetes recibidos por frame, cuando llegan muchos de golpe se acumulan y se van pasando una y otra vez al frame siguiente.
Por qué: Donde hay mucha gente llegan miles de actualizaciones por segundo → Efecto: El hilo principal topa con su límite de procesamiento por frame y no alcanza a leerlas todas → En pantalla: Los movimientos de los demás se aplican cada vez más tarde y todos de golpe
Síntomas: Cámara rápida, Input lag · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo)
Si el cliente dibuja los paquetes del servidor en cuanto llegan, el jitter (variación en el tiempo de llegada de los paquetes) se ve tal cual en pantalla.
Por qué: La posición recibida se dibuja al instante, o el búfer es más corto que el jitter → Efecto: Se detiene lo que tarda el paquete retrasado y salta cuando llegan varios juntos → En pantalla: Los demás personajes se mueven a trompicones
Síntomas: Tirones · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo)
Mientras no llegan paquetes, el cliente sigue mostrando a los personajes en movimiento con su última velocidad y, cuando descubre que se equivocó, los devuelve a su sitio.
Por qué: Se cortan los paquetes y el personaje sigue avanzando con su última dirección y velocidad → Efecto: En realidad, el otro jugador se había detenido o había cambiado de dirección → En pantalla: El personaje del otro jugador avanza un buen trecho y salta de golpe a su posición real, o atraviesa paredes. Si los paquetes llegan a intervalos irregulares, se adelanta y vuelve atrás una y otra vez, y parece que tiembla
Síntomas: Teletransporte, Tirones · Responsable principal Desarrollo de cliente (Equipo de desarrollo)
Tu cliente mueve a tu personaje antes de tener respuesta del servidor; si el servidor lo calcula de otra forma, tu personaje es arrastrado hacia atrás.
Por qué: El cliente mueve al personaje antes de la confirmación del servidor (predicción) → Efecto: El servidor calcula de otra forma las colisiones, la velocidad de movimiento o los buffs, o no recibe los comandos → En pantalla: Cuando llega la confirmación, tu personaje es arrastrado hacia atrás
Síntomas: Rubber banding · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo)
Tras una pausa, el juego intenta recuperar de golpe los cálculos atrasados, y esos mismos cálculos lo vuelven a retrasar.
Por qué: La simulación del juego corre a un intervalo fijo y se detiene una vez → Efecto: Todos los pasos atrasados se calculan en un solo frame → En pantalla: Se encadenan frames largos con picos, o al topar con el límite el mundo se ralentiza
Síntomas: Tirones, Cámara rápida, Cámara lenta · Responsable principal Desarrollo de cliente (Equipo de desarrollo)
Si la hora del servidor que estima el cliente es errónea, el momento de interpolación y la validación de los cooldowns quedan desfasados.
Por qué: La hora del servidor se sincroniza una sola vez al conectar y no se ajusta aunque cambie el ping → Efecto: El momento de interpolación y la hora en que termina el cooldown se desfasan respecto al servidor → En pantalla: El otro jugador da un tirón de vez en cuando; el cooldown ya terminó y aun así la habilidad se rechaza
Síntomas: Tirones, Acción perdida / rollback · Responsable principal Desarrollo de cliente (Equipo de desarrollo)
Si el juego guarda su hora en un formato decimal de baja precisión (float), cuanto más tiempo lleva encendido, peor es la resolución temporal (la diferencia de tiempo más pequeña que se puede distinguir), y los movimientos y los efectos tiemblan.
Por qué: El tiempo transcurrido desde que se abrió el juego se acumula en un float o se pasa tal cual a los shaders → Efecto: Cuanto más tiempo lleva encendido, mayor es la diferencia mínima que puede representar el float → En pantalla: Solo en los clientes encendidos durante días tiemblan los personajes, las animaciones y los efectos con movimiento continuo; al reiniciar el juego todo va bien
Síntomas: Tirones · Responsable principal Desarrollo de cliente (Equipo de desarrollo)
Los frames que dibuja la GPU se acumulan en una cola de varios frames y salen al ritmo del monitor; mientras tanto, el input se retrasa.
Por qué: El driver gráfico acumula por adelantado 1–3 frames en la cola → Efecto: Los inputs tardan ese tiempo extra en verse en pantalla → En pantalla: El ping es bajo, pero el control se siente pesado y responde tarde
Síntomas: Input lag, Tirones · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Externo (Externo)
Cuanto más tiempo lleva encendido, más memoria usa: el juego va cada vez más lento y al final se cierra a la fuerza.
Por qué: Al ir y venir entre zonas no se liberan texturas, elementos de UI ni efectos → Efecto: El GC se ejecuta más a menudo, falta memoria en el SO y empieza el swap → En pantalla: Tras unas horas de juego, los tirones aumentan poco a poco hasta un cierre forzado (que el jugador percibe como una desconexión)
Síntomas: Tirones, Desconexión · Responsable principal Desarrollo de cliente (Equipo de desarrollo)
Un error no controlado cierra el juego. El jugador lo percibe como una desconexión, pero el servidor está bien.
Por qué: Referencia nula, falta de memoria, error del driver gráfico → Efecto: El proceso del juego se cierra a la fuerza → En pantalla: Reportes de “me echó del juego”, mientras los demás jugadores siguen bien en ese mismo momento
Síntomas: Desconexión · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Externo (Externo)
El módulo de seguridad que se ejecuta junto al juego para impedir los hacks hace escaneos periódicos. Si el escaneo es pesado o si el heartbeat (señal periódica que confirma que el cliente sigue activo) que intercambia con el servidor de seguridad llega tarde, hay tirones o desconexiones.
Por qué: El módulo de seguridad escanea periódicamente la memoria del juego, los programas en ejecución y los drivers → Efecto: Durante el escaneo se detiene el hilo del juego, o el heartbeat no sale a tiempo → En pantalla: Tirones a intervalos regulares y, en casos graves, desconexión con un aviso de error de seguridad
Síntomas: Tirones, Congelamiento, Desconexión · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo)
El juego comparte la CPU, la memoria y la red con otros programas sobre Windows, Android o iOS. Hay lag si el sistema operativo tarda en darle CPU al juego, baja la velocidad para ahorrar batería o suspende las apps en segundo plano.
El planificador (scheduler) del sistema operativo (SO) decide a quién le toca usar la CPU y reparte el tiempo de CPU entre los programas. El juego, el antivirus, el navegador y el programa de actualizaciones esperan “su turno”, y el SO les asigna los núcleos por turnos de unos pocos ms a decenas de ms (time slice). El SO da algo más de prioridad al juego en primer plano, pero si hay más trabajo que núcleos, el juego también tiene que esperar, y esa espera retrasa los frames.
La red también pasa por el SO. Los paquetes que recibe la tarjeta de red o el chip Wi-Fi se guardan en el búfer de recepción del driver y del SO hasta que el juego los recoge. Si el juego está ocupado y los recoge tarde, el búfer se desborda; si los recoge todos de golpe, aparece la cámara rápida. En los dispositivos móviles hay que tener muy en cuenta que el SO pone la conexión inalámbrica en estado de ahorro de energía para cuidar la batería y que suspende las propias apps con frecuencia.
El SO es el jefe de cocina que reparte una única cocina entre varios cocineros. Aunque el juego esté preparando un plato urgente, si el cocinero del análisis antivirus ocupa los fogones, tiene que esperar. Y si la cocina se calienta demasiado (sobrecalentamiento), además baja la potencia del fuego.
Cuando un análisis del antivirus, Windows Update, un software de streaming o un video en el navegador ocupan los núcleos, el hilo del juego espera sin recibir CPU.
Por qué: Otros programas ocupan un núcleo de la CPU durante mucho tiempo → Efecto: El hilo del juego queda en espera de CPU → En pantalla: Los frames llegan tarde y el procesamiento de los paquetes recibidos también se retrasa
Síntomas: Tirones, Cámara rápida · Responsable principal Externo (Externo) · También Desarrollo de cliente (Equipo de desarrollo)
El modo batería de una computadora portátil, el modo de ahorro de energía del teléfono o el calor del dispositivo reducen la velocidad de la CPU y la GPU. Lo característico del calor es que al principio todo va bien y la lentitud llega al cabo de un rato.
Por qué: Modo batería o de ahorro de energía, o el dispositivo se calienta → Efecto: La frecuencia de la CPU y la GPU baja un 30–50%, según el dispositivo → En pantalla: Con el ahorro de energía, nada más activarlo; con el calor, tras jugar entre unos minutos y unos 20 minutos: los FPS bajan y hay tirones
Síntomas: Tirones, Input lag · Responsable principal Externo (Externo) · También Desarrollo de cliente (Equipo de desarrollo)
El temporizador predeterminado de Windows funciona en pasos de 15.6 ms, así que “esperar solo 1 ms” se alarga en la práctica hasta el siguiente ciclo del temporizador, hasta 15.6 ms.
Por qué: El límite de FPS y el envío de paquetes se implementan con Sleep (una espera breve) → Efecto: El SO solo despierta al proceso en pasos de 15.6 ms → En pantalla: El intervalo entre frames y el intervalo de envío de inputs se vuelven irregulares
Síntomas: Tirones · Responsable principal Desarrollo de cliente (Equipo de desarrollo)
Si sales un momento de la app para ver una notificación, el SO la suspende (suspend) a los pocos segundos y, mientras tanto, el servidor te desconecta.
Por qué: Se deja el juego en segundo plano para leer un mensaje o atender una llamada → Efecto: El motor del juego detiene la partida y el SO pronto suspende también la app y la red → En pantalla: Al volver ya hay desconexión y toca reconectar
Síntomas: Desconexión · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo)
Al salir de casa, el Wi-Fi se corta y el dispositivo pasa a LTE o 5G; tu dirección IP cambia y la conexión existente deja de valer.
Por qué: La señal Wi-Fi se debilita y el dispositivo cambia a la red móvil → Efecto: Tu dirección IP cambia y ya no se pueden intercambiar datos por la conexión abierta con la dirección antigua → En pantalla: Una pausa breve y después desconexión o reconexión
Síntomas: Congelamiento, Desconexión · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo), Infraestructura de red (Equipo de infraestructura)
Si el antivirus o el firewall inspeccionan cada paquete, la latencia aumenta y, si se exceden, toman el juego por un ataque y lo bloquean.
Por qué: El software de seguridad inspecciona uno por uno los paquetes enviados y recibidos → Efecto: Cada paquete suma latencia y, si la inspección se atrasa, se descartan paquetes → En pantalla: El ping da picos irregulares o la conexión queda bloqueada
Síntomas: Tirones, No conecta / carga infinita · Responsable principal Externo (Externo) · También Desarrollo de cliente (Equipo de desarrollo)
Si el juego está ocupado y saca tarde los paquetes del socket (la interfaz de red para enviar y recibir que ofrece el SO), el búfer del SO se desborda.
Por qué: Los frames se atrasan y el juego lee el socket tarde → Efecto: El búfer de recepción del SO se llena: en UDP se descartan paquetes, y en TCP se reduce la ventana de recepción para que el emisor deje de enviar → En pantalla: Teletransporte (UDP) o cámara rápida (TCP)
Síntomas: Teletransporte, Cámara rápida · Responsable principal Desarrollo de cliente (Equipo de desarrollo)
Con decenas de pestañas del navegador abiertas junto al juego, el SO saca a disco parte de la memoria del juego.
Por qué: Falta RAM en el sistema → Efecto: El SO pasa a disco la memoria del juego que no se está usando en ese momento → En pantalla: Cuando el juego vuelve a usar esa parte, se detiene de decenas a cientos de ms según el almacenamiento
Síntomas: Congelamiento, Tirones · Responsable principal Externo (Externo) · También Desarrollo de cliente (Equipo de desarrollo)
Si las opciones gráficas piden más memoria de la que tiene la tarjeta gráfica, el SO saca texturas a la RAM del sistema y las vuelve a traer, y hay tirones.
Por qué: Las texturas en calidad alta o la enorme variedad de equipamiento y efectos de un sitio con mucha gente llenan la memoria de la tarjeta gráfica → Efecto: El SO pasa a la RAM del sistema las texturas que no se usan en ese momento y, cuando hacen falta, las vuelve a traer por el bus PCIe, que es lento → En pantalla: Un tirón cada vez que aparece una escena o un personaje nuevo, y texturas borrosas durante un rato
Síntomas: Tirones, Congelamiento · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Externo (Externo)
Mientras el SO salta periódicamente de canal en canal para buscar redes Wi-Fi cercanas, la comunicación se detiene un instante.
Por qué: El SO o el driver buscan redes Wi-Fi cercanas a intervalos fijos → Efecto: Durante la búsqueda, el envío y la recepción se detienen un instante → En pantalla: Picos de ping a intervalos exactos (p. ej., cada 60 segundos)
Síntomas: Tirones, Teletransporte · Responsable principal Externo (Externo) · También Desarrollo de cliente (Equipo de desarrollo)
Si la tarjeta de red o el chip Wi-Fi entran en ahorro de energía entre paquete y paquete, tardan en volver a activarse.
Por qué: El ahorro de energía del dispositivo de red está activado o el driver es antiguo → Efecto: Retraso de reactivación (wake-up) y, a veces, reinicio del dispositivo → En pantalla: Latencia irregular y, en raras ocasiones, congelamientos de varios segundos
Síntomas: Tirones, Congelamiento · Responsable principal Externo (Externo) · También Desarrollo de cliente (Equipo de desarrollo)
Si en la misma computadora hay una sincronización en la nube, una descarga grande o el parche de un juego, los paquetes del juego esperan en la cola.
Por qué: Otras apps usan al máximo la subida o la bajada → Efecto: Los paquetes del juego se acumulan en la cola de tu PC y la del router → En pantalla: Ping disparado, input lag, cámara rápida
Síntomas: Input lag, Cámara rápida · Responsable principal Externo (Externo) · También Desarrollo de cliente (Equipo de desarrollo)
Si miras otra ventana o minimizas el juego, el juego y Windows lo ralentizan para ahorrar energía. Al volver, los paquetes atrasados llegan de golpe o la conexión ya se cortó.
Por qué: Cambiar de ventana con Alt+Tab o minimizar el juego → Efecto: Mientras no se ve, el juego baja mucho los FPS o se detiene, y Windows también baja la prioridad de los programas que no se ven → En pantalla: Cámara rápida al volver y, si estuvo minimizado mucho tiempo, desconexión
Síntomas: Cámara rápida, Tirones, Desconexión · Responsable principal Desarrollo de cliente (Equipo de desarrollo)
Los programas de mensajería, los launchers, los grabadores y los contadores de FPS se meten en el proceso de renderizado del juego (hooking) para dibujar su propia UI encima de la imagen. Añaden trabajo en cada frame y, a veces, chocan con el juego y provocan un tirón o un cierre forzado.
Por qué: Está activado el overlay de un programa de mensajería, un launcher de juegos, la herramienta de la tarjeta gráfica o un programa de grabación → Efecto: Cada vez que se envía un frame a la pantalla, el overlay interviene y dibuja encima su propia UI → En pantalla: Los frames se retrasan un poco y, cuando aparece una notificación, hay un tirón, errores gráficos o un cierre forzado (que el jugador percibe como una desconexión)
Síntomas: Tirones, Congelamiento, Desconexión · Responsable principal Externo (Externo) · También Desarrollo de cliente (Equipo de desarrollo)
Si el ping es normal pero el control se siente pesado, puede que el procesamiento de imagen del televisor, un controlador inalámbrico o la generación de frames estén añadiendo latencia entre el input y la pantalla.
Por qué: El modo de juego del televisor está desactivado, se usa un controlador Bluetooth o inalámbrico, o la generación de frames (DLSS o FSR Frame Generation) está activada → Efecto: El televisor envía los frames tarde mientras procesa la imagen, el input inalámbrico llega con el retraso de su ciclo de envío y de las interferencias, y la generación de frames espera al siguiente frame para crear uno intermedio → En pantalla: El ping y los FPS se ven bien, pero lo que presionas tarda en verse en pantalla: input lag
Síntomas: Input lag · Responsable principal Externo (Externo) · También Desarrollo de cliente (Equipo de desarrollo)
Son los últimos metros antes de que el paquete salga de casa. La distancia es corta, pero aquí se origina buena parte de los reportes de lag. El Wi-Fi reparte un mismo canal inalámbrico entre varios dispositivos, y el router envía el tráfico de toda la familia por una sola cola.
El Wi-Fi comparte el mismo canal inalámbrico (banda de frecuencia) con los routers de los vecinos, y la banda de 2.4 GHz se solapa además con el Bluetooth y los microondas. Si al enviar hay una colisión, espera un momento y vuelve a enviar; cuando estos reintentos se acumulan, los paquetes llegan de forma irregular. El ping medio puede parecer bueno mientras salta a cada momento: es el comportamiento típico del Wi-Fi.
El router es el dispositivo por el que pasa obligatoriamente todo lo que sale de casa hacia internet. Si se envía más de lo que admite la conexión a internet, se forma una cola dentro del router o del módem, y los dispositivos sin gestión de colas (SQM) la dejan crecer hasta cientos de ms. Un router caro se comporta igual si tiene esta función desactivada. En cuanto tu hermano menor sube un video, los paquetes del juego también esperan al final de esa cola. Este fenómeno se llama bufferbloat.
El router también registra las conexiones “dispositivo interno ↔ servidor externo” en la tabla NAT, y las borra si durante un rato no pasan paquetes. Es una causa habitual de las desconexiones tras un rato inactivo. En la red móvil se suman los cambios de estación base, el estado de ahorro de energía de la radio y la señal débil.
El router es la única entrada de un conjunto residencial. Si hay una fila de camiones de mudanza (subidas de video), hasta la moto de mensajería urgente (paquete del juego) tiene que esperar detrás de ellos. Un router inteligente (SQM) abre un carril exclusivo para la mensajería.
Con señal débil o interferencias, el tramo inalámbrico tiene que reintentar el envío varias veces y los paquetes llegan de forma irregular.
Por qué: Paredes, distancia, microondas, Bluetooth o routers vecinos degradan la calidad de la señal → Efecto: Fallos de transmisión en el tramo inalámbrico → varias retransmisiones → En pantalla: Los paquetes llegan de forma irregular (jitter) y los personajes se mueven a trompicones; en casos graves, la pérdida de paquetes provoca teletransporte
Síntomas: Tirones, Teletransporte, Rubber banding · Responsable principal Externo (Externo) · También Desarrollo de cliente (Equipo de desarrollo)
En sitios con decenas de routers, como un edificio de apartamentos, hay que compartir el mismo canal y esperar turno para transmitir.
Por qué: Decenas de routers usan el mismo canal de 2.4 GHz → Efecto: Para transmitir hay que esperar a que los demás dispositivos terminen y el canal quede libre → En pantalla: Por la noche, cuando la gente vuelve a casa, aumenta el jitter (variación en el tiempo de llegada de los paquetes) y hay tirones
Síntomas: Tirones, Input lag · Responsable principal Externo (Externo) · También Desarrollo de cliente (Equipo de desarrollo)
Cuando alguien de la familia sube un video o descarga un archivo grande, se acumulan en la cola del router cientos de ms de paquetes, y los paquetes del juego también esperan detrás.
Por qué: Las subidas de video o las copias de seguridad en la nube de la familia, tu propio streaming o una descarga grande saturan la conexión → Efecto: El router o el módem acumulan los paquetes que sobran en una cola grande → En pantalla: Los paquetes del juego también esperan al final de la cola y el ping se dispara a cientos de ms
Síntomas: Input lag, Cámara rápida, Teletransporte · Responsable principal Externo (Externo) · También Desarrollo de cliente (Equipo de desarrollo)
El router borra de la tabla NAT las conexiones inactivas por las que no pasa ningún paquete durante un tiempo. Es una causa habitual de desconexión justo cuando el jugador vuelve a moverse tras un rato quieto.
Por qué: El router registra la conexión “dispositivo interno ↔ servidor externo” en la tabla NAT (tabla de traducción de direcciones) → Efecto: Si no hay paquetes durante un tiempo, la entrada se borra de la tabla (en UDP, normalmente 30–120 s) → En pantalla: Los paquetes del servidor ya no pueden entrar en la casa y se produce la desconexión
Síntomas: Desconexión · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo)
Cuando un router barato tiene decenas de dispositivos y miles de conexiones, el propio router no da abasto.
Por qué: Decenas de dispositivos y programas P2P o torrent abren miles de conexiones → Efecto: La CPU y la tabla de sesiones del router se saturan → En pantalla: Retraso y pérdida en el procesamiento de paquetes, fallos al abrir conexiones nuevas
Síntomas: Tirones, No conecta / carga infinita, Desconexión · Responsable principal Externo (Externo)
Al viajar en autobús o en metro, la comunicación se corta mientras el teléfono cambia de estación base.
Por qué: Al desplazarse, cambia la estación base a la que está conectado el dispositivo → Efecto: Normalmente es un hueco de decenas de ms, pero si la señal es mala y el cambio falla, puede cortarse de cientos de ms a varios segundos → En pantalla: Se detiene y luego hay teletransporte; si dura mucho, desconexión
Síntomas: Congelamiento, Teletransporte, Desconexión · Responsable principal Externo (Externo) · También Desarrollo de cliente (Equipo de desarrollo), Desarrollo de servidor (Equipo de desarrollo)
Si no hay comunicación durante un rato, el teléfono pasa la conexión de radio a un estado de bajo consumo, y al llegar el siguiente paquete tarda en volver a activarla.
Por qué: Tras un rato sin comunicación, el teléfono pasa la conexión de radio a ahorro de energía → Efecto: Para enviar el siguiente paquete, hay que volver a activar la conexión → En pantalla: Solo la primera acción tras un rato quieto llega especialmente tarde
Síntomas: Input lag · Responsable principal Desarrollo de cliente (Equipo de desarrollo)
En ascensores, sótanos o el interior de los edificios aumentan las retransmisiones, baja la velocidad y al final se cae la conexión.
Por qué: Moverse a un sitio con poca señal → Efecto: Más retransmisiones por radio, menor velocidad, cortes momentáneos → En pantalla: Tirones y teletransporte por el jitter y la pérdida, y al final desconexión
Síntomas: Tirones, Teletransporte, Desconexión · Responsable principal Externo (Externo) · También Desarrollo de cliente (Equipo de desarrollo)
En el interior de edificios con poca señal 5G o en el límite de la cobertura 5G, el teléfono salta a menudo entre 5G y LTE, y en cada cambio el ping da un pico o la comunicación se corta un instante.
Por qué: Estar en un sitio donde la señal 5G va y viene (interior de edificios, límite de la cobertura 5G) → Efecto: El teléfono cambia constantemente entre 5G y LTE, y cada cambio deja un hueco breve → En pantalla: Picos de ping sin patrón aun estando quieto y, de vez en cuando, congelamientos o teletransporte
Síntomas: Tirones, Teletransporte, Congelamiento · Responsable principal Externo (Externo) · También Desarrollo de cliente (Equipo de desarrollo)
La página de inicio de sesión del Wi-Fi de una cafetería o el firewall de la empresa bloquean la conexión del juego.
Por qué: Aún no se completó la autenticación en la página de inicio de sesión, o el firewall bloquea los puertos del juego o UDP → Efecto: Se bloquea el propio intento de conexión o solo pasa una parte → En pantalla: El juego no conecta, o se inicia sesión pero no se puede entrar a la partida
Síntomas: No conecta / carga infinita · Responsable principal Externo (Externo) · También Desarrollo de cliente (Equipo de desarrollo), Desarrollo de servidor (Equipo de desarrollo)
El paquete que sale de casa recorre la red del ISP, los puntos de conexión entre varios ISP y, a veces, cables submarinos hasta llegar al centro de datos donde está el servidor. La latencia de este tramo depende sobre todo de la distancia y de la elección de ruta (enrutamiento), y muchas veces la empresa del juego no puede arreglarla directamente.
Dentro de la fibra óptica, la luz recorre unos 200,000 km por segundo. Con un servidor a 1,000 km, la ida y vuelta lleva al menos 10 ms, y mientras se use fibra óptica esa cifra no baja por mucho que se mejoren los servidores o los equipos de red. Los paquetes reales no van en línea recta: dan un rodeo siguiendo los puntos donde se conectan los ISP (peering), así que normalmente tardan entre 1.5 y 2 veces el valor teórico. En tramos como Corea–Europa, donde casi no hay grandes cables en línea recta, se rodea por el sudeste asiático y Suez o por EE. UU., y se llega a 2.5–3 veces (unos 230–270 ms de ida y vuelta).
El problema es que esta ruta cambia según la hora y la situación. Entre las 9 y las 11 de la noche todo el mundo está viendo videos y los puntos de conexión entre ISP tienden a saturarse; cuando cambia la información de rutas (BGP), los paquetes dejan de llegar a su destino entre unos segundos y unas decenas de segundos (rara vez, varios minutos); y si se corta un cable submarino, el tráfico da un rodeo por rutas lejanas durante semanas. Si hay lag “solo con un ISP”, “solo por la noche” o “solo desde el extranjero”, hay que sospechar primero de esta capa.
La red de los ISP es una red de autopistas. Aunque el camino de Seúl a Busan no esté congestionado, la distancia lleva su tiempo; a la hora de salida del trabajo se atascan los peajes (tramos de peering); y si hay un accidente, el navegador te manda por un desvío largo.
Ni siquiera la luz pasa de unos 200,000 km por segundo dentro de la fibra óptica. Un servidor lejano siempre responde tarde, por muy bueno que sea.
Por qué: El servidor está lejos (servidor en el extranjero, otro continente) → Efecto: El tiempo de ida y vuelta crece con la distancia (al menos 10 ms por cada 1,000 km) → En pantalla: Input lag constante en todas las acciones y desventaja en el registro de impactos
Síntomas: Input lag · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Infraestructura de red (Equipo de infraestructura), Desarrollo de servidor (Equipo de desarrollo)
En internet satelital la señal tiene que ir al espacio y volver. Con satélites geoestacionarios, solo la ida y vuelta ya supera los 0.5 segundos. Los satélites de órbita baja como Starlink suelen ser rápidos, pero cuando se reasigna la ruta la latencia oscila y la conexión puede cortarse un instante.
Por qué: Conexión desde casa, un barco o un avión por internet satelital geoestacionario o de órbita baja, o por Wi-Fi a bordo que usa satélites → Efecto: El satélite geoestacionario está a unos 36,000 km de altura, así que el recorrido ya es largo de por sí. En órbita baja, la ruta terminal–satélite–estación terrestre se reasigna a intervalos cortos y en cada cambio aparecen latencia y pérdida de paquetes durante un momento → En pantalla: Geoestacionario: input lag grande en todas las acciones. Órbita baja: bien la mayor parte del tiempo, pero con tirones y teletransporte a intervalos regulares
Síntomas: Input lag, Tirones, Teletransporte · Responsable principal Externo (Externo) · También Desarrollo de cliente (Equipo de desarrollo), Desarrollo de servidor (Equipo de desarrollo)
Por los acuerdos de interconexión entre ISP, el tráfico hacia un servidor cercano puede dar un rodeo por un lugar lejano.
Por qué: Tu ISP y el ISP del servidor no están conectados directamente → Efecto: El tráfico pasa por otro país u otra ciudad, con más distancia y más dispositivos en el camino → En pantalla: Solo los jugadores de ciertos ISP tienen un ping especialmente alto
Síntomas: Input lag · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Externo (Externo)
Entre las 9 y las 11 de la noche, más o menos, el tráfico de video se dispara y los enlaces de interconexión entre ISP (peering) tienden a congestionarse.
Por qué: Por la noche se concentran el streaming y las descargas → Efecto: Se forman colas y hay pérdida de paquetes en los enlaces de peering → En pantalla: Solo por la noche, los jugadores de ciertos ISP sufren tirones y teletransporte
Síntomas: Tirones, Teletransporte, Rubber banding · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Externo (Externo)
Cuando se corta un cable submarino, el tráfico da un rodeo por rutas lejanas durante semanas (a veces meses) hasta que se repara, y los enlaces que quedan se saturan.
Por qué: Corte del cable o fallo de un dispositivo → Efecto: El tráfico se concentra en rutas alternativas lejanas y en los enlaces que quedan → En pantalla: Subidas bruscas de ping y pérdida de paquetes para los jugadores que se conectan desde el extranjero, durante días o semanas
Síntomas: Input lag, Teletransporte · Responsable principal Externo (Externo) · También Infraestructura de red (Equipo de infraestructura)
Cuando cambia la información de rutas de internet, se pierden paquetes durante los segundos o decenas de segundos (rara vez, unos minutos) que tarda en volver a converger.
Por qué: Cambia la información de rutas en el tramo de algún ISP → Efecto: Durante unos segundos o decenas de segundos, los paquetes desaparecen o pasan a una ruta nueva → En pantalla: Congelamiento repentino de unos segundos, y después el ping se queda en otro valor (p. ej., 40 → 70 ms)
Síntomas: Congelamiento, Teletransporte · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo), Externo (Externo)
Los ISP y los centros de datos tienen varias rutas hacia el mismo destino y asignan una a cada conexión. Si se estropea una sola ruta, solo los jugadores asignados a ella siguen con lag.
Por qué: En un tramo que agrupa varios enlaces, un enlace o un dispositivo está defectuoso o saturado → Efecto: La ruta se elige según la combinación de direcciones y puertos (hash), así que solo las conexiones asignadas a esa ruta sufren pérdida y latencia → En pantalla: En la misma región y con el mismo ISP, solo algunos jugadores sufren teletransporte constante. A veces se arregla al reconectar
Síntomas: Teletransporte, Rubber banding, Tirones · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo), Externo (Externo)
En los planes que limitan la velocidad al superar el consumo de datos o que gestionan cierto tipo de tráfico, los paquetes se retrasan o se descartan.
Por qué: Velocidad limitada al agotar los datos del plan, o restricción de cierto tráfico → Efecto: Los paquetes esperan en una cola o se descartan → En pantalla: Lag a partir de cierto consumo, sobre todo con datos móviles
Síntomas: Input lag, Teletransporte · Responsable principal Externo (Externo) · También Desarrollo de servidor (Equipo de desarrollo), Infraestructura de red (Equipo de infraestructura)
Algunas redes bloquean ciertas direcciones y puertos UDP o limitan la velocidad del UDP, y sus dispositivos de inspección de paquetes filtran los protocolos que no reconocen. En esas redes, los juegos que se comunican por UDP no conectan o se desconectan a menudo.
Por qué: Conexión desde la red de un ISP que limita la velocidad del UDP, o desde una red con dispositivos de inspección (censura) del tráfico a nivel de país o de ISP → Efecto: Se bloquean ciertas direcciones y puertos UDP, se limita la velocidad del UDP en las horas de más tráfico, se filtran los puertos y protocolos que no están en la lista de permitidos, o se dejan pasar solo los primeros paquetes y luego se bloquea → En pantalla: Solo para los jugadores de ciertos países o ISP: el juego no conecta o se queda en carga infinita, se desconecta poco después de entrar, o hay teletransporte por pérdida de paquetes en las horas de más tráfico
Síntomas: No conecta / carga infinita, Desconexión, Teletransporte · Responsable principal Externo (Externo) · También Desarrollo de cliente (Equipo de desarrollo), Desarrollo de servidor (Equipo de desarrollo), Infraestructura de red (Equipo de infraestructura)
Un conector flojo, un cableado viejo o un módem averiado provocan pérdida de paquetes constante y cortes periódicos de la conexión.
Por qué: Cable dañado, mal contacto, módem o terminal óptico (ONT) averiado → Efecto: Se descartan paquetes por errores de bits, y a veces la conexión se corta entre unos segundos y un minuto mientras vuelve a conectarse → En pantalla: Pérdida leve pero constante; a veces, congelamientos de unos segundos o desconexiones
Síntomas: Teletransporte, Congelamiento, Desconexión · Responsable principal Externo (Externo)
Si el DNS, que traduce los nombres de servidor a direcciones, va lento o falla, el juego no encuentra los servidores de login ni de parches.
Por qué: Caída o error de configuración del DNS del ISP → Efecto: No se encuentran las direcciones de los servidores de login y de parches → En pantalla: Larga espera tras presionar el botón de conectar, o no conecta. Los que ya están conectados no notan nada
Síntomas: No conecta / carga infinita · Responsable principal Externo (Externo) · También Desarrollo de cliente (Equipo de desarrollo)
Un ataque masivo dirigido a la empresa del juego, o a otro destino de la misma red, llena los enlaces compartidos.
Por qué: Se genera un gran volumen de tráfico de ataque → Efecto: El tráfico legítimo que usa los mismos enlaces también se retrasa y se descarta → En pantalla: Teletransporte, desconexiones o el juego no conecta, para muchos jugadores a la vez
Síntomas: Teletransporte, Desconexión, No conecta / carga infinita · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Externo (Externo)
En las redes móviles y en algunos ISP, varios abonados comparten una misma IP, y el mapeo de las conexiones inactivas se borra al poco tiempo.
Por qué: Un dispositivo del ISP (CGNAT) gestiona la tabla de sesiones de muchísimos abonados → Efecto: Límite de la tabla de sesiones, timeout por inactividad corto → En pantalla: Desconexión tras un rato inactivo, falsos positivos que bloquean a la vez a todos los que comparten la misma IP
Síntomas: Desconexión, No conecta / carga infinita · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo), Infraestructura de red (Equipo de infraestructura)
Con una VPN o un acelerador de juegos activado, los paquetes pasan por los servidores intermedios (relay) de esa empresa. Si el relay está lejos o saturado, la conexión acaba siendo más lenta que sin él.
Por qué: La VPN o el acelerador desvía todos los paquetes del juego por sus servidores intermedios → Efecto: Se suman la distancia hasta el servidor intermedio y su congestión, y las cabeceras del túnel también reducen la MTU (el tamaño máximo de paquete que se puede enviar de una vez) → En pantalla: Ping más alto y pérdida de paquetes; no conecta si bloquean la dirección del relay junto con todos los que la usan
Síntomas: Input lag, Teletransporte, No conecta / carga infinita · Responsable principal Externo (Externo) · También Infraestructura de red (Equipo de infraestructura), Desarrollo de servidor (Equipo de desarrollo)
Justo antes de llegar al servidor, el paquete atraviesa en orden el router, el dispositivo de protección DDoS, el firewall, el balanceador de carga y el switch. Es un tramo que normalmente tarda menos de 1 ms, pero si un dispositivo se queda sin capacidad o falla, miles de jugadores de todo el servidor se ven afectados a la vez.
Cada dispositivo tiene un papel distinto. El router decide la ruta, el dispositivo de protección DDoS filtra el tráfico de ataque y el firewall solo deja pasar las conexiones permitidas y hace seguimiento de todas ellas en la tabla de sesiones. El balanceador de carga reparte las conexiones entrantes entre varios servidores y el switch conecta los servidores entre sí.
El punto débil común de estos dispositivos es el tamaño de sus tablas y el tamaño de sus búferes. Si la tabla de sesiones del firewall se llena, no acepta conexiones nuevas; el balanceador de carga borra las conexiones inactivas pasado cierto tiempo; y los búferes pequeños del switch se desbordan en menos de 1 ms cuando varios servidores envían paquetes a miles de jugadores en el mismo instante (aparición de un world boss). Además, durante los segundos en que un dispositivo averiado pasa al de respaldo (failover), todo se detiene.
La entrada del centro de datos es el control de seguridad y la puerta de embarque de un aeropuerto. El control (firewall) solo deja pasar a quien está en la lista, y cuando la lista se llena, no admite a nadie más. El personal de la puerta (balanceador de carga) da por “ido” al pasajero que lleva mucho rato sentado sin moverse y lo borra de la lista.
El firewall registra en la tabla de sesiones cada conexión que deja pasar para hacerle seguimiento. Cuando la tabla se llena, ya no puede aceptar conexiones nuevas.
Por qué: Una avalancha de conexiones o un ataque lleva el número de sesiones al límite → Efecto: No queda ninguna entrada libre para registrar una conexión nueva, así que se rechaza → En pantalla: Para quien intenta entrar, el juego no conecta o se queda en carga infinita; algunas conexiones ya abiertas también se desconectan
Síntomas: No conecta / carga infinita, Desconexión · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo), Desarrollo de cliente (Equipo de desarrollo)
Para frenar un ataque, el tráfico se desvía a un centro de depuración (scrubbing), lo que alarga la ruta, y a veces se bloquea a jugadores legítimos tomándolos por atacantes.
Por qué: Tras detectar un ataque (o de forma permanente), el tráfico entrante se desvía a un centro de depuración → Efecto: La ruta se alarga y algunos paquetes legítimos se clasifican como ataque → En pantalla: El ping sube para todos; en ciertas regiones o ISP el juego no conecta
Síntomas: Input lag, No conecta / carga infinita, Teletransporte · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
El balanceador de carga borra las conexiones inactivas después de cierto tiempo. El juego cree que la conexión sigue abierta, hasta que el jugador sufre una desconexión.
Por qué: El jugador no envía ningún paquete durante un rato (ventana de chat abierta, ausente del teclado) → Efecto: El balanceador de carga elimina la conexión inactiva (valores por defecto habituales: 60–350 s) → En pantalla: Desconexión en el momento en que vuelve a moverse
Síntomas: Desconexión · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Desarrollo de cliente (Equipo de desarrollo), Desarrollo de servidor (Equipo de desarrollo)
El firewall asociado a un servidor en la nube (grupo de seguridad) también hace seguimiento de las conexiones, y la entrada de seguimiento de una conexión inactiva expira pasado cierto tiempo. Incluso en servidores a los que se conecta directamente, sin balanceador de carga, un jugador que estuvo quieto puede sufrir una desconexión.
Por qué: El grupo de seguridad está configurado de forma que hace seguimiento de las conexiones del juego (solo se permiten ciertas direcciones, reglas de salida restringidas, paso por un NLB, etc.) → Efecto: La entrada de seguimiento de una conexión que pasó un rato inactiva expira, y el grupo de seguridad descarta en silencio los paquetes que llegan después → En pantalla: Tras estar ausente, el jugador vuelve a moverse, no hay respuesta y llega la desconexión. El programa del servidor tarda mucho en enterarse
Síntomas: Desconexión · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de cliente (Equipo de desarrollo), Desarrollo de servidor (Equipo de desarrollo)
Cuando los servidores de una subred privada abren conexiones hacia fuera (autenticación de la plataforma, pagos, API externas), el gateway NAT cambia su dirección y su puerto antes de enviarlas. Si las conexiones simultáneas hacia un mismo destino superan el límite de puertos del gateway, las conexiones nuevas fallan.
Por qué: Los servidores abren muchas conexiones cortas hacia una misma dirección externa, como la autenticación de la plataforma o los pagos, o mantienen conexiones abiertas mucho tiempo → Efecto: El gateway NAT no puede asignar más puertos de origen para ese destino, así que las conexiones nuevas fallan → En pantalla: Dentro del juego todo va bien, pero fallan o tardan solo las funciones que llaman a servicios externos, como el inicio de sesión, los pagos o la entrega de recompensas (el juego no conecta o se queda en carga infinita; acciones perdidas o rollback)
Síntomas: No conecta / carga infinita, Acción perdida / rollback · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Las conexiones se concentran en un solo servidor, o se sigue enviando gente a un servidor que ya está caído.
Por qué: La regla de reparto no encaja o el health check no ve el estado real → Efecto: Un solo servidor sobrecargado, o intentos de conexión a un servidor caído → En pantalla: Cámara lenta, o el juego no conecta o se queda en carga infinita, solo en algunos canales o para algunos jugadores
Síntomas: Cámara lenta, No conecta / carga infinita · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Cuando varios servidores envían paquetes a miles de jugadores en el mismo instante, el pequeño búfer del puerto del switch donde se junta ese tráfico se desborda en menos de 1 ms.
Por qué: Aparición de un world boss o habilidades masivas, o ticks de varios servidores que coinciden en el mismo instante y envían todo a la vez → Efecto: Los búferes de los puntos donde varios puertos confluyen en uno o donde un puerto rápido pasa a uno lento (de cientos de KB a unos pocos MB por puerto) se llenan en un instante → En pantalla: Se descartan algunos paquetes; muchos jugadores sufren a la vez teletransporte o habilidades que no salen
Síntomas: Teletransporte, Acción perdida / rollback · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de red (Equipo de infraestructura), Infraestructura de servidores (Equipo de infraestructura)
Cuando la distribución de parches, el envío de logs o las copias de seguridad usan el mismo enlace que el juego, el enlace se llena.
Por qué: Las transferencias masivas acaparan el mismo enlace → Efecto: Aumentan las colas y la pérdida en el enlace → En pantalla: Sube el ping y hay teletransporte en todo el servidor
Síntomas: Input lag, Teletransporte · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Infraestructura de servidores (Equipo de infraestructura)
Cuando falla un router o un firewall y el tráfico pasa al dispositivo de reserva (failover), todos se quedan congelados durante unos segundos.
Por qué: Paso al dispositivo de reserva por una avería o un mantenimiento → Efecto: El cambio tarda unos segundos, y si la información de sesión no está sincronizada, las conexiones se reinician → En pantalla: Congelamiento simultáneo de todos los jugadores del servidor, desconexión masiva
Síntomas: Congelamiento, Desconexión · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo), Desarrollo de cliente (Equipo de desarrollo)
Si un transceptor óptico o un cable está defectuoso, se corrompe una proporción constante de los paquetes que pasan por esa ruta.
Por qué: Errores de bits por un transceptor óptico o un cable defectuoso → Efecto: El dispositivo descarta en silencio los paquetes corruptos → En pantalla: Solo algunos servidores o jugadores que usan esa ruta sufren teletransporte o rubber banding por una pérdida constante
Síntomas: Teletransporte, Rubber banding · Responsable principal Infraestructura de red (Equipo de infraestructura)
Si la MTU (el tamaño máximo que se puede enviar de una vez) se reduce en un tramo intermedio y los avisos de tamaño excedido están bloqueados, solo los paquetes grandes desaparecen una y otra vez.
Por qué: La MTU se reduce en un tramo con túnel o VPN → Efecto: Un firewall bloquea los avisos de tamaño excedido (ICMP) y el emisor no se entera → En pantalla: Congelamiento y luego desconexión solo al abrir pantallas grandes, como el inventario o la lista de personajes
Síntomas: Congelamiento, Desconexión, No conecta / carga infinita · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Infraestructura de servidores (Equipo de infraestructura), Desarrollo de servidor (Equipo de desarrollo)
La tarjeta de red instalada en el servidor recibe de cientos de miles a millones de paquetes por segundo y se los pasa a la CPU. Si aquí se atrasa el procesamiento, el programa del servidor pierde paquetes sin llegar a saber que llegaron.
La NIC va guardando los paquetes que llegan en el búfer circular (ring buffer, un búfer de recepción con un número fijo de slots que se reutilizan en círculo) y avisa a la CPU de que “llegaron paquetes” (interrupción). La CPU saca los paquetes del búfer circular y se los pasa al SO. Si entran más rápido de lo que la CPU los saca, se llenan todos los slots y los paquetes que llegan después se descartan. Solo suben en silencio los números de las estadísticas de la tarjeta de red (ethtool -S) y en los logs del servidor del juego no queda ningún error, así que es un lag difícil de encontrar.
Las NIC actuales tienen varias colas de recepción (búferes circulares) y reparten los avisos entre varios núcleos de CPU (RSS), pero si RSS no está configurado o el tráfico se concentra en una sola cola, un único núcleo se pone al 100% y se convierte en el cuello de botella. En un servidor en la nube, delante de la NIC hay además límites de paquetes por segundo, de ancho de banda y de conexiones, y todo lo que los supera se descarta antes de llegar al servidor. No se ve en las métricas habituales como la CPU o el búfer circular; en AWS solo queda en las estadísticas del driver ENA (pps_allowance_exceeded, etc. de ethtool -S).
La NIC es el buzón de un edificio, el búfer circular es el número de casilleros del buzón y la interrupción es el timbre del cartero. Si llega una avalancha de correo y solo hay una persona sacándolo, los casilleros se desbordan y las cartas caen al suelo. RSS consiste en poner a varias personas a sacar el correo.
Si la NIC envía las interrupciones de llegada de paquetes a un solo núcleo de CPU, ese núcleo se convierte en el cuello de botella.
Por qué: Hay una sola cola de recepción o está desactivado RSS, que reparte los paquetes entre varios núcleos → Efecto: Un núcleo llega al 100% y no saca los paquetes a tiempo → En pantalla: Pérdida y latencia en todo el servidor cuando se junta mucha gente (teletransporte, input lag)
Síntomas: Teletransporte, Rubber banding, Input lag · Responsable principal Infraestructura de servidores (Equipo de infraestructura)
Si el búfer circular, donde la NIC guarda los paquetes un momento, es pequeño, se desborda cuando llegan muchos de golpe y los paquetes se descartan.
Por qué: El búfer circular se deja en su valor por defecto, que es pequeño (256–2,048 slots según el driver) → Efecto: En una ráfaga, el búfer se desborda antes de que la CPU saque los paquetes → En pantalla: Pérdida solo en los momentos de ráfaga (teletransporte, habilidades que no salen). Sin rastro en los logs del servidor del juego
Síntomas: Teletransporte, Acción perdida / rollback · Responsable principal Infraestructura de servidores (Equipo de infraestructura)
Para reducir la carga de la CPU, la NIC junta paquetes y avisa de una sola vez, así que los paquetes se retrasan lo que dura esa espera.
Por qué: La NIC junta paquetes durante cierto tiempo o hasta cierto número antes de avisar → Efecto: Los paquetes esperan mientras se juntan → En pantalla: Leve aumento de la latencia. Normalmente es pequeño, pero si se exagera llega al orden de ms
Síntomas: Input lag · Responsable principal Infraestructura de servidores (Equipo de infraestructura)
Cada tipo de servidor en la nube tiene límites de paquetes por segundo y de ancho de banda, y lo que los supera se descarta en silencio.
Por qué: Al subir los jugadores conectados a la vez (CCU), los paquetes por segundo superan el límite de la instancia → Efecto: La red de la nube descarta el exceso → En pantalla: Teletransporte y habilidades que no salen por una pérdida sin causa aparente. La CPU del servidor va sobrada
Síntomas: Teletransporte, Acción perdida / rollback · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo), Externo (Externo)
Si una tarjeta de 1 Gbps o 10 Gbps se usa hasta su límite, la cola de transmisión crece y al final los paquetes se descartan.
Por qué: Con más broadcasts, el tráfico llega al límite de la tarjeta → Efecto: La cola de transmisión crece y, cuando se desborda, se descartan paquetes → En pantalla: Latencia y pérdida en todo el servidor (input lag, teletransporte)
Síntomas: Input lag, Teletransporte · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Cuando otras máquinas virtuales del mismo servidor físico usan mucha red o CPU, el procesamiento de nuestro servidor se retrasa de forma irregular.
Por qué: Otras máquinas virtuales del mismo servidor físico usan muchos recursos → Efecto: El procesamiento de paquetes de nuestra máquina virtual se retrasa de forma irregular → En pantalla: De vez en cuando aparece jitter (variación en el tiempo de llegada de los paquetes) sin una causa clara, y el juego va a tirones
Síntomas: Tirones · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Externo (Externo)
Cuando el proveedor de nube hace mantenimiento de un servidor físico (host), mueve las máquinas virtuales a otro host (migración en vivo) o las pausa un momento. Mientras tanto, todo el servidor se detiene y, si la pausa es larga, las conexiones se cortan.
Por qué: El proveedor mueve la máquina virtual a otro host o la pausa un momento por mantenimiento del host o por una avería prevista → Efecto: Durante el traslado, la CPU, la memoria y la red van más lentas, y al final la máquina virtual se detiene por completo un instante (de menos de 1 segundo a unos 30 segundos, según el proveedor y el método) → En pantalla: Todos los jugadores del servidor se congelan a la vez y luego hay cámara rápida y teletransporte; si la pausa dura más que el timeout, desconexión masiva
Síntomas: Congelamiento, Cámara rápida, Teletransporte, Desconexión · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo), Externo (Externo)
Cuando un bug del driver o una función que falla deja colgada la tarjeta, se corta todo el envío y la recepción mientras se reinicia.
Por qué: Bug del driver, fallo de una función de offload → Efecto: La NIC se cuelga y se reinicia (unos segundos) → En pantalla: Todos los jugadores de ese servidor se congelan a la vez y luego hay teletransporte o desconexión
Síntomas: Congelamiento, Desconexión · Responsable principal Infraestructura de servidores (Equipo de infraestructura)
Son funciones que agrupan varios paquetes en uno para reducir la carga de la CPU. Según la configuración, un paquete pequeño del juego puede esperar un momento al siguiente paquete con el que agruparse.
Por qué: La NIC y el kernel agrupan los paquetes que llegan para procesarlos juntos → Efecto: Si está activada la agrupación por hardware (LRO) o un tiempo de espera de agrupación, el paquete espera un momento al siguiente → En pantalla: Leve aumento de la latencia (normalmente decenas de µs o menos)
Síntomas: Input lag · Responsable principal Infraestructura de servidores (Equipo de infraestructura)
El kernel Linux o Windows del servidor acepta las conexiones, gestiona los búferes de socket y reparte la CPU y la memoria al programa del servidor del juego. Casi todos sus valores predeterminados son conservadores y pensados para usos variados, así que a menudo no encajan con un servidor de juego que tiene decenas de miles de jugadores conectados durante horas.
Cuando llega una conexión nueva, el kernel deja la solicitud en la cola de conexiones pendientes (backlog) y el servidor del juego las va aceptando una a una. Si la cola se llena, Linux descarta las solicitudes nuevas sin avisar y Windows devuelve una respuesta de rechazo. En Linux, cada conexión necesita un descriptor de archivo (fd), el número que se asigna a cada archivo o conexión abiertos, y el número de fd que puede tener un proceso también tiene un límite. Si justo después del mantenimiento decenas de miles de jugadores presionan a la vez el botón de conexión, lo primero en agotarse son la cola de conexiones pendientes y los fd.
Además, cuando falta memoria, el kernel la pasa al disco (swap, si está activado), y cuando de verdad se agota, Linux elige el proceso que más memoria usa y lo mata a la fuerza (OOM killer). El servidor del juego suele ser el proceso que más memoria usa en esa máquina, así que es el primero en caer. Si el contenedor tiene un límite de memoria, pasa lo mismo en cuanto se alcanza ese límite, aunque al servidor en conjunto le sobre memoria. Cosas que parecen no tener nada que ver con el juego, como la sincronización horaria (NTP), las tareas programadas, los límites de CPU de los contenedores o el CPU steal de las máquinas virtuales (el tiempo de espera mientras otra máquina virtual usa la CPU física), también detienen el servidor por momentos o desajustan los temporizadores.
El SO del servidor es la entrada y la oficina de administración de un parque de atracciones. Si a la hora de apertura (fin del mantenimiento) llega todo el mundo a la vez, la fila ante la entrada (backlog) se desborda, y si se acaban las pulseras que entregar (descriptores de archivo), no puede entrar nadie más.
Cuando decenas de miles de jugadores se conectan a la vez justo después de un mantenimiento, la cola de conexiones pendientes (backlog) del kernel se desborda y se descartan intentos de conexión.
Por qué: Al terminar el mantenimiento, las conexiones llegan más rápido de lo que el servidor del juego puede aceptarlas con accept → Efecto: La cola de conexiones pendientes del kernel (backlog: el menor entre el valor que el código del servidor pasa a listen y el límite del kernel) se llena → En pantalla: Se descartan intentos de conexión y los reintentos se repiten: el juego no conecta o se queda en carga infinita
Síntomas: No conecta / carga infinita · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura), Desarrollo de cliente (Equipo de desarrollo)
Cada conexión necesita un descriptor de archivo (fd, el número que el SO asigna a cada archivo o socket abierto), y el número de fd que puede abrir un proceso es limitado.
Por qué: Los jugadores conectados a la vez alcanzan el límite de descriptores de archivo del proceso → Efecto: El servidor no puede aceptar conexiones nuevas (Too many open files). También falla la apertura de logs y de conexiones a la BD → En pantalla: A partir de un número exacto de jugadores ya nadie puede entrar: el juego no conecta o se queda en carga infinita
Síntomas: No conecta / carga infinita · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Si los búferes de envío y recepción son pequeños, cuando llega una ráfaga de tráfico se descartan paquetes recibidos por UDP y los envíos por TCP se bloquean porque no queda espacio en el búfer.
Por qué: SO_SNDBUF y SO_RCVBUF con el valor predeterminado o demasiado pequeños → Efecto: Durante una ráfaga, o mientras el hilo que recibe se detiene un momento, el búfer de recepción UDP se desborda y se descartan paquetes; en TCP, el envío espera porque no queda espacio en el búfer de envío → En pantalla: Teletransporte (pérdida en UDP) o cámara rápida (espera en TCP)
Síntomas: Teletransporte, Cámara rápida · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Si se ejecutan muchos más hilos que núcleos, el SO gasta CPU solo en irlos turnando.
Por qué: Cientos o miles de hilos, por ejemplo uno por conexión → Efecto: Aumentan el costo de los cambios de contexto (cambiar el hilo en ejecución) y los fallos de caché → En pantalla: La CPU está ocupada pero procesa poco y el tick se vuelve irregular: tirones y cámara lenta
Síntomas: Tirones, Cámara lenta · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Mientras el servidor físico (hipervisor) cede por un momento el tiempo de CPU de la máquina virtual a otra máquina virtual (CPU steal), el servidor del juego se detiene.
Por qué: Otra máquina virtual del mismo host usa mucha CPU → Efecto: Nuestra máquina virtual pierde turnos de ejecución de varios ms a decenas de ms cada vez → En pantalla: Picos de tiempo de tick sin causa aparente: tirones y congelamiento
Síntomas: Tirones, Congelamiento · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Externo (Externo)
Si un contenedor tiene un límite de CPU, en cuanto agota su cuota dentro del periodo fijado (normalmente 100 ms), se detiene a la fuerza el resto del periodo (throttling).
Por qué: El contenedor del servidor del juego tiene un límite de CPU (limit) en Kubernetes u otro orquestador → Efecto: Cuando se acumula el cálculo del tick, agota la cuota y queda detenido decenas de ms hasta el siguiente periodo → En pantalla: La CPU media es baja, pero el tick tiene picos periódicos: tirones y cámara lenta
Síntomas: Tirones, Cámara lenta · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Los núcleos de CPU inactivos entran en estados de ahorro de energía profundos (C-states) y bajan su frecuencia para ahorrar electricidad. Cuando llega un paquete o vence un temporizador, despertar y subir la frecuencia lleva tiempo, y eso añade latencia al procesar paquetes pequeños.
Por qué: La política de escalado de frecuencia del SO (governor) o la configuración de energía de la BIOS permiten C-states profundos y frecuencias bajas → Efecto: Cada vez que un núcleo inactivo sale de un estado de ahorro profundo se retrasa hasta varios cientos de µs, y si la frecuencia se queda fijada baja, el propio cálculo del tick se vuelve lento → En pantalla: Casi siempre es imperceptible, pero con muchas llamadas entre servidores se acumula y aparece input lag, curiosamente cuando hay poca gente. Si la frecuencia se queda fijada baja, el tick se retrasa cuando se junta mucha gente: cámara lenta
Síntomas: Input lag, Cámara lenta · Responsable principal Infraestructura de servidores (Equipo de infraestructura)
Cuando Linux se queda sin memoria, elige el proceso que más memoria usa y lo mata a la fuerza. Casi siempre es el servidor del juego.
Por qué: Memoria agotada por una fuga o un pico de uso, o límite de memoria del contenedor alcanzado → Efecto: El kernel cierra a la fuerza el proceso del servidor del juego → En pantalla: Desconexión simultánea de todos los jugadores de ese servidor, con posible rollback del progreso reciente
Síntomas: Desconexión, Acción perdida / rollback · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Mientras el SO compacta la memoria para formar páginas grandes (huge pages) o recupera memoria libre, el proceso se detiene.
Por qué: Baja la memoria libre, o la función de páginas grandes (THP) ejecuta una compactación de memoria → Efecto: El hilo que pidió memoria espera hasta que terminan la recuperación y la compactación → En pantalla: Detenciones irregulares del servidor (de varios ms a cientos de ms)
Síntomas: Congelamiento, Tirones · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Si el reloj del servidor se adelanta o se atrasa varios segundos de golpe, los temporizadores que dependen del reloj del sistema se disparan todos a la vez o se detienen.
Por qué: La sincronización horaria corrige el reloj con un salto grande de una sola vez → Efecto: Los temporizadores se disparan en tropel o se detienen, y los timeouts se evalúan mal → En pantalla: Buffs y cooldowns que fallan, desconexiones simultáneas, cámara rápida
Síntomas: Cámara rápida, Desconexión, Acción perdida / rollback · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
La compresión de logs, las copias de seguridad y los análisis de seguridad que se ejecutan todos los días a la misma hora ocupan la CPU y el disco.
Por qué: Una tarea del SO se ejecuta a una hora fijada → Efecto: Comparte la CPU y el disco con el servidor del juego → En pantalla: Tirones y cámara lenta a una hora fija, por ejemplo todos los días a las 4 de la madrugada
Síntomas: Tirones, Cámara lenta · Responsable principal Infraestructura de servidores (Equipo de infraestructura)
El código del juego no cambia, pero el servidor se vuelve más lento después de actualizar el SO, el kernel, los drivers o el firmware. Las actualizaciones pueden cambiar valores predeterminados, el planificador, las mitigaciones de vulnerabilidades de la CPU (mitigations) o el comportamiento de los drivers.
Por qué: Un parche de seguridad periódico o una imagen de servidor nueva cambia el kernel, los drivers o el firmware → Efecto: Cambian los valores predeterminados o el planificador, o se activan nuevas mitigaciones: el mismo trabajo consume más tiempo de CPU y cambia el orden en que los hilos reciben CPU → En pantalla: Un servidor que iba bien va siempre un poco más lento desde el día de la actualización: input lag y, cuando se junta mucha gente, tirones y cámara lenta
Síntomas: Input lag, Tirones, Cámara lenta · Responsable principal Infraestructura de servidores (Equipo de infraestructura)
Cuando la tabla de seguimiento de conexiones (conntrack), donde el firewall de Linux registra todas las conexiones, llega a su límite, se descartan paquetes nuevos.
Por qué: Una avalancha de conexiones o conexiones cortas repetidas multiplican las entradas de seguimiento → Efecto: La tabla se llena y se descartan conexiones nuevas y algunos paquetes → En pantalla: El juego no conecta, y la pérdida de paquetes sin causa aparente provoca teletransporte
Síntomas: No conecta / carga infinita, Teletransporte · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo), Desarrollo de cliente (Equipo de desarrollo)
Si el servidor del juego abre y cierra conexiones cortas con frecuencia hacia la BD u otros servidores, las conexiones cerradas siguen ocupando su puerto un tiempo y no se pueden abrir conexiones nuevas.
Por qué: Se abre y se cierra una conexión nueva en cada solicitud → Efecto: El lado que cierra primero retiene el puerto unos 60 segundos (en Linux) en TIME_WAIT, y se agotan los puertos disponibles → En pantalla: Fallan solicitudes internas: errores al guardar y en otras funciones
Síntomas: Acción perdida / rollback, No conecta / carga infinita · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Es la parte que decide cómo envía y recibe datos el juego por la red. Con la misma conexión, según el protocolo que se use y cómo se configuren las opciones de socket, perder un paquete puede quedarse en “un pequeño salto” o convertirse en “una detención de 1 segundo y luego todo de golpe”.
TCP garantiza la entrega completa y en el orden de envío. A cambio, si se pierde un paquete, espera hasta recibirlo de nuevo sin entregar al juego nada de lo que llegó después. UDP no garantiza nada. Entrega lo que llega al instante y sin esperas, pero el juego tiene que encargarse de lo que se pierde. Por eso los juegos con mucha acción implementan por su cuenta sobre UDP solo la confiabilidad que necesitan (UDP confiable), y muchos MMO usan TCP, que es más fácil de implementar, y aceptan sus puntos débiles.
Las opciones de socket son la configuración detallada de este comportamiento: si se juntan los paquetes pequeños antes de enviarlos (TCP_NODELAY), qué tamaño tienen los búferes de envío y recepción (SO_SNDBUF, SO_RCVBUF), cuándo se detecta una conexión muerta (SO_KEEPALIVE, TCP_USER_TIMEOUT) y qué se hace con los datos pendientes al cerrar (SO_LINGER). Casi todos los valores predeterminados están pensados para enviar datos grandes de forma eficiente con pocos paquetes, así que muchas veces perjudican a los juegos, que intercambian paquetes pequeños con frecuencia.
TCP entrega los datos recibidos al juego solo en el orden en que se enviaron. Si se pierde el paquete 17, aunque ya hayan llegado del 18 al 30, todos esperan hasta que vuelva a llegar el 17 (bloqueo HOL). UDP los entrega según van llegando, así que aunque el 17 no llegue nunca, el resto se procesa a tiempo.
Por qué ocurren las retransmisiones (Wi-Fi, congestión, agujero negro de MTU, retransmisiones espurias, etc.) y cómo encontrar la causa se explican causa por causa en el capítulo 06 Retransmisión TCP.
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
Síntomas: Congelamiento, Cámara rápida · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Cada vez que una retransmisión vuelve a fallar, la espera se duplica, así que un corte breve de la conexión se convierte en una detención larga.
Por qué: La conexión se corta un momento y las retransmisiones también fallan una tras otra → Efecto: La espera hasta el siguiente intento se duplica cada vez: 0.3 → 0.6 → 1.2 → 2.4 s (con un ping de 100 ms) → En pantalla: La conexión se cortó 1 segundo, pero el juego se congela más de 2. Si el corte dura más, acaba en desconexión
Síntomas: Congelamiento, Desconexión · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
El algoritmo de Nagle, que junta paquetes pequeños antes de enviarlos, y el ACK retardado, que envía los ACK con retraso, se bloquean mutuamente, y cada mensaje escrito en varias partes se retrasa entre 40 y 200 ms.
Por qué: Se escriben mensajes pequeños en varias partes sin activar TCP_NODELAY → Efecto: El emisor espera el ACK y el receptor lo envía tarde → En pantalla: Input lag constante en todas las acciones aunque el ping de la conexión sea bajo
Síntomas: Input lag · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Si el búfer de envío de un jugador con una conexión lenta está lleno y se le envía en modo bloqueante (un envío cuya llamada no vuelve hasta que hay espacio en el búfer), el hilo del servidor se queda esperando a ese único jugador.
Por qué: El búfer de envío de un cliente lento está lleno → Efecto: Como el envío es bloqueante, el hilo del servidor espera hasta que haya espacio en el búfer → En pantalla: Congelamiento o cámara lenta para todos los jugadores que atiende ese hilo
Síntomas: Congelamiento, Cámara lenta · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Cuando a un cliente se le siguen acumulando datos pendientes de envío, el servidor descarta las actualizaciones viejas o corta la conexión.
Por qué: La conexión del cliente no da abasto con lo que envía el servidor → Efecto: El servidor descarta las actualizaciones viejas o, si se supera el límite, cierra la conexión → En pantalla: Teletransporte o desconexión solo para ese jugador
Síntomas: Teletransporte, Desconexión · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Si el otro extremo desaparece sin enviar una señal de cierre, TCP tarda mucho en detectarlo. El keepalive (la función de TCP que comprueba si una conexión inactiva sigue viva) viene desactivado por defecto y, aunque se active, no empieza a comprobar hasta que la conexión lleva 2 horas inactiva.
Por qué: El cliente desaparece sin señal de cierre porque se apaga o se corta su conexión → Efecto: El servidor da la conexión por viva (keepalive predeterminado: 7,200 segundos; si había datos pendientes de envío, unos 15 minutos hasta abandonar la retransmisión) → En pantalla: Queda un personaje fantasma y, al reconectar, aparece el error “Ya estás conectado”
Síntomas: No conecta / carga infinita, Entidades invisibles / fantasma · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo), Infraestructura de servidores (Equipo de infraestructura)
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
Síntomas: Teletransporte · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Si las reglas de retransmisión implementadas sobre UDP son demasiado conservadoras, la recuperación es lenta; si son demasiado agresivas, congestionan todavía más la conexión.
Por qué: El intervalo y el número de retransmisiones o el tamaño de la ventana no se ajustan a la conexión → Efecto: Recuperación lenta, o más congestión por los envíos duplicados → En pantalla: Habilidades que no salen, cámara rápida, más lag cuando hay congestión
Síntomas: Acción perdida / rollback, Cámara rápida · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Si una conexión TCP pasa un rato inactiva, vuelve a reducir la ventana de congestión (lo que puede enviar de una vez), y cuando de repente tiene que enviar muchos datos, los envía en varias tandas.
Por qué: Se envían muchos datos, por ejemplo al entrar en un pueblo, por una conexión que estaba inactiva → Efecto: Como la ventana de congestión está reducida, el envío se reparte en varios viajes de ida y vuelta → En pantalla: Justo después de entrar, los personajes y NPC de alrededor aparecen varios viajes de ida y vuelta más tarde (se nota más cuanto más lejos está el servidor)
Síntomas: Input lag, Entidades invisibles / fantasma · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
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 · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Si el servidor corta una conexión de forma brusca, se pierden el último aviso o la confirmación de guardado que envió.
Por qué: El servidor cierra la conexión con un cierre forzado (RST). Ocurre si SO_LINGER está en 0 segundos o si se cierra sin leer todos los datos recibidos → Efecto: Se descartan el motivo de la expulsión y los últimos datos que aún se estaban enviando → En pantalla: Mensajes de “Conexión cerrada por un error desconocido” sin motivo aparente
Síntomas: Desconexión · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
En un modelo en el que el hilo no puede hacer nada más mientras espera a un socket, todo se vuelve más lento a medida que aumentan los jugadores.
Por qué: Se espera la lectura y la escritura conexión por conexión → Efecto: El retraso de una conexión se contagia a las demás conexiones del mismo hilo → En pantalla: Cuantos más jugadores conectados, más cámara lenta e input lag para todos
Síntomas: Cámara lenta, Input lag · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Cuando varios procesos reciben en el mismo puerto, el kernel asigna cada conexión a un proceso según un hash de la dirección y no cambia esa asignación. Si ese proceso se detiene, solo esperan los jugadores asignados a él.
Por qué: El gateway o el servidor de login levanta varios procesos con SO_REUSEPORT → Efecto: Aunque un proceso se detenga por GC o sobrecarga, las conexiones nuevas y los paquetes UDP asignados a él no pasan a otros procesos → En pantalla: Solo algunos jugadores no consiguen conectar o sufren congelamientos. En los reinicios que cambian el número de procesos, se cortan algunas sesiones UDP
Síntomas: No conecta / carga infinita, Congelamiento, Desconexión · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Cuando un servidor Windows envía UDP a un cliente que ya se fue, vuelve un aviso de “puerto inalcanzable” (ICMP). Ese aviso hace que la siguiente llamada de recepción termine con error, y si el código del servidor lo trata como una avería del propio socket, todos los que usan ese socket se ven afectados.
Por qué: Se sigue enviando UDP a la dirección de un cliente que acaba de irse y vuelve un aviso de “puerto inalcanzable” (ICMP) → Efecto: Windows termina la siguiente llamada de recepción con el error WSAECONNRESET (10054), y el código del servidor deja de recibir o cierra el socket → En pantalla: Congelamiento o desconexión simultánea de todos los que usaban ese socket
Síntomas: Desconexión, Congelamiento · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Es el programa que calcula realmente la lógica del juego. El movimiento, el combate, la IA de los monstruos, el cálculo de visibilidad y el broadcast tienen que terminar dentro de un solo “tick”. Cuanta más gente se junta en un lugar, más crecen el cálculo de visibilidad y los paquetes que enviar: lo hacen con el cuadrado del número de jugadores.
El servidor calcula el estado del juego a un intervalo de tick fijo. En un servidor de 20 ticks lo hace una vez cada 50 ms, y en ese tiempo aplica los inputs de todos los jugadores, mueve los monstruos, calcula quién puede ver a quién (rango de visión, AOI) y envía los cambios a todos los que pueden verlos. Esos 50 ms son el presupuesto del tick. Si se supera, el siguiente tick se retrasa. En los servidores que avanzan una cantidad fija de tiempo de juego por tick, todo el tiempo del juego corre más despacio (cámara lenta); en los que avanzan de una vez el tiempo real transcurrido, la velocidad se mantiene, pero los paquetes se espacian y aparecen tirones y teletransporte. En ambos casos la respuesta se retrasa. Si un solo hilo del juego se encarga de todo el servidor (canal), lo sufren todos los de ese servidor; si hay un hilo por zona, lo sufren juntos los jugadores de esa zona.
El problema es el número de jugadores. Si se compara a todos con todos, 100 jugadores suponen unas 10,000 comprobaciones por tick y 1,000 jugadores, alrededor de 1 millón. Por eso el servidor divide el mapa en una cuadrícula y solo compara celdas cercanas, pero cuando todos se juntan cerca de una misma celda, como en un world boss, un asedio o un evento en la plaza de una ciudad, la cuadrícula pierde efecto y se disparan los cálculos y los datos que enviar. Si a eso se suman los locks, por los que varios hilos esperan para acceder a los mismos datos, y las llamadas síncronas, que esperan la respuesta de la BD en mitad del tick, mientras dura la espera se detienen todos los jugadores que atiende ese hilo.
El tick del servidor es el compás del director de orquesta. Cuantos más músicos (jugadores) hay, más partituras hay que atender en cada compás, y si se pierde el compás, toda la pieza se ralentiza. Si alguien se va al almacén (BD) a buscar una partitura, todos tienen que esperarlo.
Si el trabajo de un tick supera su presupuesto, el intervalo de tick del servidor se alarga y toda esa zona va más lenta o va a tirones.
Por qué: El trabajo de un tick (p. ej., 50 ms) supera su presupuesto → Efecto: El estado del juego, que debería calcularse 20 veces por segundo, se calcula solo 8 → En pantalla: Cámara lenta en toda la zona (o tirones, según el diseño del servidor), habilidades que responden tarde
Síntomas: Cámara lenta, Input lag, Tirones · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Si se compara a todos con todos para saber quién puede ver a quién, cuando el número de jugadores se multiplica por 10, el cálculo se multiplica por 100.
Por qué: Se compara la distancia entre todos los personajes, o, aun dividiendo el mapa en una cuadrícula, cientos de jugadores se juntan cerca de una misma celda → Efecto: Con 100 jugadores, unas 10,000 comparaciones; con 1,000, alrededor de 1 millón → En pantalla: En lugares abarrotados, como un world boss o un asedio, el tick se dispara: cámara lenta y tirones
Síntomas: Cámara lenta, Tirones · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Si el movimiento de un jugador se envía a todos los que lo ven, las actualizaciones que hay que enviar crecen con el cuadrado del número de jugadores reunidos.
Por qué: Los cambios de un jugador se envían a todos los que pueden verlo → Efecto: Si 1,000 jugadores se ven entre sí, hay 1 millón de actualizaciones por tick → En pantalla: La cola de envío y el ancho de banda se saturan: latencia y pérdida (input lag, cámara rápida, teletransporte)
Síntomas: Input lag, Teletransporte, Cámara rápida · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
En un diseño con un hilo por zona, si la gente se concentra en un lugar, solo ese núcleo llega al 100%.
Por qué: Un solo hilo lleva una zona (canal) → Efecto: Cuando la gente se concentra en un lugar, solo ese núcleo se satura y los demás están desocupados → En pantalla: Solo esa zona tiene lag; las demás van bien
Síntomas: Cámara lenta, Input lag · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Si varios hilos esperan un mismo lock para escribir los mismos datos, por más hilos que se añadan, solo se ejecuta uno a la vez.
Por qué: Varios hilos usan a la vez datos compartidos, como la casa de subastas o el almacén del gremio → Efecto: Los demás esperan hasta que termina el hilo que tiene el lock → En pantalla: Solo una función va lenta y, en los casos graves, se retrasa todo el tick
Síntomas: Input lag, Congelamiento · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Si dos hilos esperan cada uno el lock que tiene el otro, se quedan detenidos para siempre.
Por qué: El hilo A tiene el lock 1 y espera el lock 2; B tiene el lock 2 y espera el lock 1 → Efecto: Los dos se quedan detenidos para siempre, y los hilos relacionados también se detienen uno tras otro → En pantalla: Todo el servidor se detiene y, cuando el watchdog lo reinicia, se desconecta a todos los jugadores
Síntomas: Congelamiento, Desconexión · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Si durante un tick se espera la respuesta de la BD o una escritura en archivo, todo el avance del juego en el servidor se detiene ese tiempo.
Por qué: Dentro del tick se esperan consultas y guardados en la BD, escrituras de logs o llamadas a API externas → Efecto: Si la BD tarda 100 ms, el tick también se detiene 100 ms → En pantalla: Cada vez que la BD o el disco van lentos, toda la zona abierta sufre un tirón
Síntomas: Congelamiento, Tirones · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Si las solicitudes llegan más rápido de lo que se procesan y se acumulan en la cola, las últimas se procesan varios segundos después o se descartan.
Por qué: Las solicitudes llegan más rápido de lo que se procesan → Efecto: La cola se alarga y, al superar el límite, se descarta lo que sobra → En pantalla: Habilidades e intercambios que responden tarde o se pierden
Síntomas: Input lag, Acción perdida / rollback · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Si la reaparición de todos los monstruos, el fin de todos los buffs y las recompensas a la hora en punto caen en el mismo tick, ese tick pesa decenas de veces más.
Por qué: Los temporizadores de reaparición, expiración, recompensas y guardado automático coinciden a la misma hora → Efecto: Ese tick tiene decenas de veces más trabajo que de costumbre → En pantalla: Un tirón cada vez que llega la hora fijada
Síntomas: Congelamiento, Tirones · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Si cientos de monstruos persiguen a la vez a los jugadores calculando rutas, se consume mucha CPU.
Por qué: Muchos monstruos persiguen a la vez al agruparlos para cazar o con spawns masivos → Efecto: Cada monstruo calcula su ruta (pathfinding) → En pantalla: Cámara lenta solo en esa zona de caza
Síntomas: Cámara lenta · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Convertir a bytes y comprimir los datos que se van a enviar también consume CPU, y con mucha gente este costo se dispara.
Por qué: En cada actualización, se convierten estructuras a bytes y se comprimen → Efecto: El costo crece con el cuadrado del número de jugadores → En pantalla: El envío se retrasa: input lag
Síntomas: Input lag · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Si el proceso del servidor muere por un error no controlado, todos los jugadores de ese servidor se desconectan a la vez.
Por qué: Errores fatales como referencias a objetos que no existen (referencia nula), datos incorrectos o falta de memoria → Efecto: Termina el proceso del servidor (o de la zona) → En pantalla: Desconexión simultánea de todos; el progreso desde el último guardado puede sufrir rollback
Síntomas: Desconexión, Acción perdida / rollback · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Si todos los hilos de trabajo que procesan tareas quedan atados a trabajos lentos, las solicitudes nuevas esperan indefinidamente.
Por qué: Los hilos de trabajo quedan atados esperando respuestas de API externas o de la BD → Efecto: No quedan hilos libres para asignar a las solicitudes nuevas → En pantalla: Carga infinita en funciones concretas, como el inicio de sesión o la tienda
Síntomas: No conecta / carga infinita, Input lag, Congelamiento · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Si por un bug un tick no termina nunca, el servidor se detiene y el watchdog lo reinicia a la fuerza.
Por qué: Un bucle que no termina por una condición errónea, o una recursión desbocada → Efecto: El tick no termina y el servidor se detiene → En pantalla: Congelamiento y después desconexión de todos los jugadores
Síntomas: Congelamiento, Desconexión · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Cuando cientos de jugadores golpean a la vez a un mismo jefe, el cálculo de ese único jefe se concentra en un punto y la información de cada golpe se envía a todos los que lo ven.
Por qué: Cientos de jugadores usan sin parar habilidades, buffs y debuffs sobre un mismo jefe → Efecto: Los cálculos de vida, lista de aggro y debuffs del jefe se concentran en un punto, y por cada golpe se envían paquetes de números de daño y efectos a todos los que lo ven → En pantalla: Las habilidades entran tarde y los números de daño aparecen de golpe; cámara lenta solo alrededor del jefe
Síntomas: Input lag, Cámara rápida, Cámara lenta · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Al teletransportarse a un pueblo lleno de gente, el servidor tiene que enviar de golpe la apariencia, el equipamiento y el estado de los cientos de jugadores que ahora son visibles.
Por qué: El jugador aparece de repente en un lugar concurrido al teletransportarse, al conectarse o al cambiar de canal → Efecto: Se genera y se envía de una vez la información completa de cientos de jugadores, y tu PC también la carga de una vez → En pantalla: Una pausa breve justo al llegar; los personajes aparecen tarde, uno a uno, y los inputs responden tarde
Síntomas: Congelamiento, Input lag, Cámara rápida · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Si los objetos tirados en el suelo, las invocaciones y los temporizadores terminados que deberían desaparecer no se limpian y se acumulan, el trabajo de cada tick crece cuanto más tiempo lleva encendido el servidor.
Por qué: Los objetos del suelo, las invocaciones, los temporizadores vencidos y los datos de grupos vacíos no se borran a tiempo → Efecto: Las listas que se recorren en cada tick se alargan día a día → En pantalla: Justo después del mantenimiento todo va bien, pero al cabo de unos días ese servidor o esa zona va cada vez más pesado
Síntomas: Cámara lenta, Tirones, Input lag · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
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
Síntomas: Teletransporte, Acción perdida / rollback, Input lag · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura), Infraestructura de red (Equipo de infraestructura)
Todo lo que el servidor recuerda, es decir, personajes, monstruos, objetos y mapas, está cargado en memoria. La memoria en sí es rápida, pero hay lag en cuanto el servidor se detiene por el GC (que libera la memoria que ya no se usa), cuando la memoria se va perdiendo poco a poco (fuga) o cuando falta y aparece el swap (mover parte de la memoria al disco).
En los lenguajes que gestionan la memoria automáticamente, como Java, C# o Go, el recolector de basura (GC) reúne y libera la memoria usada que ya no sirve. Según el tipo de GC, a veces detiene todos los hilos un momento. Si se hace un GC de todo el heap (la zona de memoria que el programa pide y usa mientras se ejecuta) de una vez, cuantos más datos vivos haya, más tarda: de cientos de ms a varios segundos. Los GC modernos como ZGC reducen las pausas a menos de 1 ms a cambio de usar más CPU y memoria. Los servidores en C++ no tienen GC, pero sufren fugas, en las que se acumula memoria que se olvidó liberar, y fragmentación, en la que el espacio libre queda dividido en trozos pequeños y no se pueden usar bloques grandes. Aunque haya GC, si algo sigue referenciando objetos que ya no se usan, la fuga se produce igual.
Otra razón por la que la memoria se vuelve lenta es la jerarquía de memoria (lo lejos que está cada almacenamiento de la CPU). La caché pegada a la CPU tarda 1 ns, la RAM 100 ns, y volver a leer memoria enviada al disco (swap) tarda más de 1,000 veces lo que la RAM. En la tabla “Cifras de latencia” de abajo puedes ver esta diferencia ampliada a escala de tiempo humana.
La memoria es la mesa de trabajo de un cocinero. Si los ingredientes están al alcance de la mano (caché), todo va rápido; si hay que ir hasta el refrigerador (RAM), algo más lento; y si la mesa se llena y los ingredientes van al almacén (disco, swap), cada vez que hay que sacar algo se tarda muchísimo. Mientras se lavan los platos (GC), hay que dejar de cocinar.
Un servidor en Java o C# detiene todos sus hilos para recolectar la basura (stop-the-world), y mientras tanto todo el servidor queda detenido.
Por qué: El heap se llena y arranca el GC → Efecto: Se detienen todos los hilos del juego mientras se recolecta (cuantos más datos vivos, más tarda) → En pantalla: Congelamiento simultáneo en todo el servidor y después cámara rápida
Síntomas: Congelamiento, Cámara rápida · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Aunque el servidor esté escrito en C++, si las misiones, la IA y las habilidades se ejecutan en scripts como Lua, la zona se detiene mientras corre el GC del motor de scripts.
Por qué: En cada zona, el motor de scripts ejecuta misiones, IA y eventos, y crea una gran cantidad de objetos temporales → Efecto: Cuando el GC del motor de scripts recolecta mucho de una vez, el tick de esa zona se detiene → En pantalla: Tirones periódicos solo en ciertas zonas o durante ciertos eventos
Síntomas: Tirones, Congelamiento · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Si durante un evento se crean muchísimos objetos temporales, el GC se ejecuta mucho más a menudo que de costumbre.
Por qué: Explosión de objetos temporales por los drops de objetos, los logs de combate y las recompensas de eventos → Efecto: El GC se ejecuta varias veces más a menudo, y los objetos que no llegan a descartarse a tiempo pasan a la generación vieja (Old), lo que también adelanta el Full GC → En pantalla: Tirones periódicos solo durante los eventos
Síntomas: Tirones, Congelamiento · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
La memoria que no se libera se acumula poco a poco y, al cabo de unos días, termina en un GC excesivo, swap o un cierre forzado.
Por qué: No se libera la información de los personajes que ya se desconectaron ni los manejadores de eventos (event handlers) → Efecto: La memoria libre baja a lo largo de varios días → En pantalla: Va bien justo después del mantenimiento, cada día hay más lag y al final el servidor se cae
Síntomas: Cámara lenta, Congelamiento, Desconexión · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Cuando los datos vivos se acercan al límite del heap, el GC casi no encuentra nada que liberar y se repite sin parar.
Por qué: Por el aumento de jugadores en un evento o por una fuga, los datos vivos llenan el heap casi hasta el límite → Efecto: El GC apenas libera memoria y enseguida lanza otro Full GC; el GC se lleva la mayor parte de la CPU → En pantalla: Todo el servidor alterna cámara lenta y congelamientos durante varios minutos y acaba cerrándose por falta de memoria
Síntomas: Cámara lenta, Congelamiento, Desconexión · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Cuando falta memoria y el SO envía una parte al disco, cada vez que se usa esa memoria hay que esperar a un disco más de 1,000 veces más lento.
Por qué: La memoria usada supera la RAM física → Efecto: El SO envía una parte al disco y la vuelve a leer cuando hace falta → En pantalla: El tick se dispara a cientos de ms y todos los jugadores del servidor sufren cámara lenta y congelamientos
Síntomas: Cámara lenta, Congelamiento · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Si los datos están dispersos por la memoria, la CPU tiene que ir cada vez hasta la RAM, que es lenta, y esperar.
Por qué: Objetos dispersos y enlazados por punteros, a los que se accede sin orden → Efecto: Como no están en la caché de la CPU, se leen de la RAM cada vez (alrededor de 100 veces más lento) → En pantalla: El mismo trabajo cuesta varias veces más tiempo de tick; en casos graves, cámara lenta
Síntomas: Cámara lenta · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Si al asignar y liberar memoria una y otra vez el espacio libre queda partido en trozos pequeños, el proceso ocupa mucha más memoria de la que realmente usa.
Por qué: Varios hilos asignan y liberan durante mucho tiempo bloques de memoria de tamaños muy distintos → Efecto: El espacio libre queda disperso en trozos pequeños que no se pueden devolver al SO, y el uso sigue creciendo como si fuera una fuga → En pantalla: Cuanto más tiempo lleva encendido, más lento va por el swap y la falta de memoria, hasta que se cierra a la fuerza
Síntomas: Cámara lenta, Desconexión · Responsable principal Desarrollo de servidor (Equipo de desarrollo)
En un servidor con dos CPU, el acceso a memoria se vuelve más lento cuando un hilo usa la memoria conectada a la otra CPU.
Por qué: El hilo y su memoria quedan en sockets de CPU distintos → Efecto: El acceso a memoria se vuelve más lento (1.5–2 veces, según el hardware) → En pantalla: Diferencias de rendimiento entre procesos en servidores con las mismas especificaciones
Síntomas: Cámara lenta · Responsable principal Infraestructura de servidores (Equipo de infraestructura)
Los logs, los guardados de personajes, los datos de los mapas y los archivos de la BD están en el disco. El disco es entre cientos de veces (SSD) y 100,000 veces (HDD) más lento que la memoria, así que si el servidor del juego está diseñado de forma que espera al disco, en cuanto el disco se satura el juego también se detiene.
El rendimiento de un disco se mide en “cuántas lecturas y escrituras puede hacer por segundo” (IOPS). Un HDD antiguo hace algo más de 150, y un SSD, de decenas de miles a cientos de miles. En los discos en la nube, el límite depende de lo que se pague (el gp3 predeterminado de AWS tiene 3,000). Algunos discos en la nube y los tamaños de servidor pequeños dan créditos de ráfaga para rendir por encima de su velocidad normal durante un rato, pero si los periodos de carga se alargan, los créditos se agotan y la velocidad cae de golpe. Los reportes de “todas las noches, al cabo de unas horas, hay lag” tienen esta forma.
La clave es quién espera. Una escritura de archivo normal la recibe primero el SO en memoria y la baja al disco más tarde, así que casi siempre termina enseguida. El problema surge cuando se pide esperar “hasta que se escriba de verdad en el disco” (fsync) o cuando se llena el límite de lo que el SO puede retener en memoria. Si en ese momento el hilo del juego espera directamente (síncrono), cuando el disco se retrasa 100 ms el tick también se detiene 100 ms. Si la escritura se pasa a otro hilo (asíncrono), el juego no se detiene, pero si el servidor se cae de repente, se puede perder lo que aún no se escribió (acciones perdidas o rollback).
El disco es un almacén y los IOPS son el número de puertas del almacén. Si hay pocas puertas, los que meten y sacan cosas hacen fila. Los créditos de ráfaga son la energía para correr a toda velocidad un rato: cuando se acaban, se vuelve a paso normal.
Si el hilo del juego espera a que el disco termine cada línea de log, cuando el disco está ocupado el juego también se detiene.
Por qué: Los logs de combate e intercambios se escriben directamente en archivo desde el hilo del juego → Efecto: Si se exige escritura garantizada (fsync) o se llena el búfer de escritura del SO (caché de páginas), cada escritura tarda decenas de ms cuando el disco está ocupado → En pantalla: Tirones en los combates que generan muchos logs
Síntomas: Tirones, Congelamiento · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Pedir que los datos se escriban en disco “con garantía” cuesta, según el disco, de 0.1 ms a decenas de ms por llamada, y si se acumulan las solicitudes, la cola se alarga.
Por qué: Los guardados periódicos y las avalanchas de cierres de sesión concentran solicitudes de escritura garantizada → Efecto: La cola del disco se alarga → En pantalla: Lag en cada guardado, retrasos al cerrar sesión o cambiar de canal
Síntomas: Tirones, Input lag · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura), Infraestructura de BD (Equipo de infraestructura)
Algunos discos en la nube y las instancias pequeñas tienen créditos de ráfaga para rendir por encima de su nivel base durante un rato; si la actividad intensa se alarga y los créditos se agotan, la velocidad cae de golpe.
Por qué: Uso prolongado por encima del rendimiento base → Efecto: Se agotan los créditos de ráfaga y el rendimiento cae de golpe al nivel base → En pantalla: Cada noche, el lag empieza al cabo de unas horas
Síntomas: Tirones, Cámara lenta, Input lag · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Infraestructura de BD (Equipo de infraestructura)
Cuando se supera el número de solicitudes por segundo que el disco puede procesar, la cola se alarga y la latencia se dispara.
Por qué: Las solicitudes de lectura y escritura se acercan a la capacidad del disco → Efecto: La cola se alarga (normalmente se dispara por encima del 90% de utilización) → En pantalla: Guardados y cargas lentos; con llamadas síncronas, congelamiento
Síntomas: Input lag, Congelamiento · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo), Infraestructura de BD (Equipo de infraestructura)
Si los logs y los volcados se acumulan hasta llenar el disco, las escrituras fallan y, si no hay nada previsto, el servidor se cae.
Por qué: Logs, volcados y archivos temporales se acumulan hasta el 100% → Efecto: Fallan las escrituras. Sin manejo de errores, crash; con manejo de errores, fallos al guardar → En pantalla: Desconexión, rollback del progreso
Síntomas: Desconexión, Acción perdida / rollback · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Infraestructura de BD (Equipo de infraestructura), Desarrollo de servidor (Equipo de desarrollo)
Cuando una copia de seguridad de madrugada, la compresión de logs o un escaneo de seguridad acaparan el disco, las lecturas y escrituras del servidor del juego se retrasan.
Por qué: Empieza una tarea programada de copia de seguridad o compresión → Efecto: Ocupa la mayor parte del ancho de banda y de las IOPS del disco → En pantalla: Lag todos los días a la misma hora
Síntomas: Tirones, Input lag · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Infraestructura de BD (Equipo de infraestructura)
Si el servidor lee del disco los datos de una mazmorra o un mapa la primera vez que se los piden, el juego se detiene para todos durante ese tick.
Por qué: Alguien entra por primera vez en una mazmorra o una zona → Efecto: El servidor lee los datos del disco desde el hilo del juego → En pantalla: Congelamiento breve para todos los jugadores de ese servidor
Síntomas: Congelamiento · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Cuando el servidor se cae, escribe en disco varios GB de memoria, y eso puede retrasar el reinicio varios minutos.
Por qué: Un crash del servidor escribe toda su memoria en un archivo → Efecto: No se puede reiniciar mientras se escriben varios GB → En pantalla: Desconexión por la caída del servidor y, después, no se puede conectar durante un buen rato
Síntomas: No conecta / carga infinita · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
En un HDD el cabezal tiene que moverse sobre el plato (búsqueda, seek), así que cada lectura o escritura de datos dispersos tarda cerca de 10 ms.
Por qué: Servidores antiguos o almacenamiento económico con HDD → Efecto: Unos 10 ms por cada lectura o escritura dispersa → En pantalla: Guardados y cargas lentos en general
Síntomas: Input lag · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Infraestructura de BD (Equipo de infraestructura), Desarrollo de servidor (Equipo de desarrollo)
Es donde está lo que nunca se debe perder: personajes, objetos, moneda del juego e historial de intercambios. Si la BD se vuelve lenta, el combate va bien, pero los objetos llegan tarde, los intercambios fallan y el inicio de sesión no termina. Si el servidor del juego está diseñado de forma que espera a la BD, toda la zona abierta se detiene.
El servidor del juego abre de antemano unas cuantas conexiones con la BD (pool de conexiones) y las usa por turnos. Si una consulta (solicitud que se envía a la BD) tarda mucho, esa conexión sigue ocupada, y cuando todas las conexiones del pool están ocupadas, el resto de las solicitudes espera en la cola. Hay dos razones habituales por las que las consultas se vuelven lentas: no hay índice (como el índice de un libro) y se lee la tabla entera (escaneo completo), o varias solicitudes intentan modificar la misma fila a la vez y esperan por los bloqueos.
Para ser confiable y aceptar muchas solicitudes, la BD usa varios mecanismos: réplicas que reparten las lecturas, una BD de respaldo a la que se pasa en caso de fallo y checkpoints que escriben periódicamente en el disco los cambios acumulados. Cuando los checkpoints se concentran, todo va lento un momento. Si una réplica se retrasa, aparece “no veo el objeto que acabo de comprar”; si se pasa a la BD de respaldo con la replicación retrasada, aparece “al entrar volví a como estaba hace un rato”. Son síntomas de acciones perdidas o rollback. Si el servidor del juego solo guarda los personajes cada pocos minutos, cuando el servidor se cae pasa a ser “volví a como estaba hace 10 minutos”.
La BD es la ventanilla de un banco. El número de ventanillas (pool de conexiones) es fijo, y si una solicitud se pone a revisar el libro de cuentas entero (escaneo completo), todas las de detrás esperan. Si todos quieren abrir la misma caja fuerte (fila caliente), solo puede entrar uno cada vez.
Sin índice, encontrar las filas que cumplen una condición obliga a leer la tabla entera (escaneo completo).
Por qué: Un despliegue con una función nueva añade búsquedas por condiciones sin índice → Efecto: Se escanean millones de filas y cada consulta tarda de cientos de ms a varios segundos → En pantalla: El buzón y el historial de intercambios tardan en cargar, y como las conexiones quedan ocupadas, otras solicitudes también esperan
Síntomas: Input lag, No conecta / carga infinita · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)
Si todos intentan modificar la misma fila (el almacén del gremio, un objeto popular de la casa de subastas, un contador global del servidor), el bloqueo solo lo consigue uno cada vez.
Por qué: Un evento o un objeto popular concentra las modificaciones en la misma fila → Efecto: Las solicitudes esperan hasta conseguir el bloqueo → En pantalla: Intercambios fallidos, “Inténtalo de nuevo más tarde”, timeouts
Síntomas: Acción perdida / rollback, Input lag · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)
Si dos transacciones (operaciones de BD que se procesan como un solo bloque) esperan cada una la fila que bloqueó la otra, la BD cancela una de ellas a la fuerza.
Por qué: El intercambio A bloquea en el orden objeto→moneda y el B en el orden moneda→objeto → Efecto: La BD detecta el deadlock y hace rollback de una de las dos → En pantalla: Intercambios y fabricaciones que fallan de vez en cuando, objetos que se revierten
Síntomas: Acción perdida / rollback, Input lag · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)
El número de conexiones abiertas con la BD es fijo, así que si las consultas lentas ocupan las conexiones, las demás solicitudes esperan.
Por qué: Todas las conexiones están ocupadas por consultas lentas o por una avalancha de solicitudes → Efecto: Las solicitudes nuevas esperan a que se libere una conexión → En pantalla: Carga infinita al iniciar sesión, guardados lentos, timeouts
Síntomas: No conecta / carga infinita, Input lag · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)
Si se escribe en la BD principal y se lee de una réplica, cuando la réplica va con retraso no se ve lo que se acaba de escribir.
Por qué: Las escrituras se concentran en la BD principal y la réplica se queda varios segundos atrás → Efecto: Al leer de la réplica lo que se acaba de guardar, todavía no está → En pantalla: El objeto recién comprado no aparece, el mercado muestra precios antiguos, bugs de entregas duplicadas
Síntomas: Acción perdida / rollback · Responsable principal Infraestructura de BD (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Cuando la BD vuelca de golpe al disco, de forma periódica, los cambios que tiene en memoria, las consultas se ralentizan.
Por qué: Los cambios se acumulan y se escriben en disco periódicamente → Efecto: En ese momento el disco está muy ocupado y las consultas se retrasan → En pantalla: Guardados y cargas que se vuelven lentos periódicamente
Síntomas: Input lag, Tirones · Responsable principal Infraestructura de BD (Equipo de infraestructura)
Al reiniciar la BD, su caché en memoria está vacía, y durante un tiempo todas las consultas leen del disco.
Por qué: La BD se reinicia por un mantenimiento → Efecto: Los datos que se usaban a menudo ya no están en memoria y se leen del disco → En pantalla: Justo después del mantenimiento, el inicio de sesión y las cargas van lentos durante un rato
Síntomas: No conecta / carga infinita, Input lag · Responsable principal Infraestructura de BD (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Si cargar un personaje requiere decenas de consultas separadas, decenas de miles de inicios de sesión simultáneos se convierten en millones de consultas.
Por qué: Al cargar un personaje se consultan por separado los objetos, las habilidades y las misiones → Efecto: Justo después del mantenimiento, los inicios de sesión simultáneos disparan el número de consultas → En pantalla: Carga infinita al iniciar sesión, e incluso los guardados de quienes ya están jugando se retrasan
Síntomas: No conecta / carga infinita, Input lag · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)
Calcular rankings, enviar correo del juego en masa o limpiar datos antiguos con el servicio en marcha acapara bloqueos y disco.
Por qué: Se lanzan tareas masivas en horario de servicio → Efecto: Bloqueos de rangos amplios, disco y CPU ocupados → En pantalla: Fallos en intercambios y guardados a ciertas horas, cargas lentas
Síntomas: Input lag, Acción perdida / rollback · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)
Cuando la BD principal cae, no se puede escribir mientras se cambia a la de respaldo, y los últimos datos que no llegaron a replicarse pueden perderse.
Por qué: Por un fallo de la BD principal, se promueve la BD de respaldo → Efecto: No se puede escribir durante el cambio, que dura de varios segundos a unos minutos; con replicación asíncrona, pueden perderse los datos no replicados → En pantalla: Todos los guardados fallan durante un momento, rollback de objetos y experiencia
Síntomas: Acción perdida / rollback, Congelamiento, Desconexión, No conecta / carga infinita · Responsable principal Infraestructura de BD (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Si para reducir la carga solo se guarda una vez cada varios minutos, cuando el servidor se cae entre dos guardados se pierde el progreso.
Por qué: El estado del personaje se guarda una vez cada varios minutos → Efecto: Entre un guardado y otro se produce un crash o un fallo del servidor → En pantalla: Al volver a conectar, el personaje está como hace unos minutos (rollback)
Síntomas: Acción perdida / rollback · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)
Si la caché de unos datos populares caduca a la vez, miles de solicitudes se lanzan de golpe contra la BD.
Por qué: Los datos populares guardados en Redis u otra caché caducan a la vez → Efecto: Las solicitudes que intentan regenerar esos mismos datos se lanzan de golpe contra la BD → En pantalla: Por la sobrecarga de la BD, varias funciones se ralentizan o se congelan una tras otra
Síntomas: Input lag, Congelamiento, No conecta / carga infinita · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)
Si una transacción permanece abierta mucho tiempo, sigue reteniendo sus bloqueos y la BD no puede limpiar (purge) las versiones antiguas de los datos, así que todo se vuelve cada vez más lento.
Por qué: Se espera la respuesta de otro servidor con la transacción abierta, o se ejecuta en producción una consulta de agregación larga en la BD principal → Efecto: Los bloqueos retenidos no se liberan y las versiones antiguas pendientes de limpieza se siguen acumulando → En pantalla: Timeouts en las funciones que usan esas filas; guardados y consultas cada vez más lentos en general a lo largo de varias horas
Síntomas: Input lag, Acción perdida / rollback · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)
Redis procesa los comandos de uno en uno, así que un solo comando lento bloquea todas las solicitudes que vienen detrás.
Por qué: En producción se busca en todo el keyspace con KEYS, o se lee o borra de una vez un ranking o una lista de millones de elementos → Efecto: Todas las demás solicitudes esperan hasta que termina ese comando (de decenas de ms a varios segundos) → En pantalla: Tirones a la vez en todas las funciones que usan sesiones, rankings o caché; inicios de sesión lentos
Síntomas: Congelamiento, Input lag, No conecta / carga infinita · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)
Aunque el código no cambie, si la BD cambia la forma de procesar una consulta (el plan de ejecución), una consulta que ayer tardaba 2 ms hoy tarda cientos de ms.
Por qué: La actualización automática de estadísticas, un reinicio de la BD o un cambio en la distribución de los datos hacen que la BD calcule un plan de ejecución nuevo → Efecto: Se elige un plan que no usa índice, la misma consulta pasa a ser de decenas a cientos de veces más lenta y las conexiones quedan ocupadas → En pantalla: Sin ningún despliegue, la carga de una función concreta se vuelve lenta de repente y otras solicitudes también esperan
Síntomas: Input lag, No conecta / carga infinita · Responsable principal Infraestructura de BD (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Si se añade una columna o un índice a una tabla con el servicio en marcha, un bloqueo que solo se necesita durante un instante puede dejar esperando a todas las solicitudes que usan esa tabla.
Por qué: Un hotfix añade una columna o un índice a una tabla en producción → Efecto: El cambio de esquema espera a una transacción larga que ya estaba abierta, y todas las solicitudes que llegan después esperan al cambio de esquema → En pantalla: Las funciones que usan esa tabla (inventario, correo, etc.) se quedan congeladas por completo y dan timeout
Síntomas: Input lag, Acción perdida / rollback, No conecta / carga infinita · Responsable principal Infraestructura de BD (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Hoy casi todos los MMO funcionan con servidores de login, gateway, zona abierta, mazmorras, chat, grupos, casa de subastas, caché y BD que se llaman entre sí. Si uno falla, el fallo se extiende a los que están conectados con él, y las tareas de operación como despliegues, escalado y mantenimiento también producen lag.
Separar servidores impide que el fallo de uno se extienda a todos, pero a cambio aparecen cadenas de llamadas (servidores que llaman a otros servidores en secuencia). Por ejemplo, el servidor del juego llama al servidor de la casa de subastas, y este llama a la caché y a la BD. Si el servidor del final de la cadena se vuelve lento, los anteriores siguen ocupando hilos y conexiones mientras esperan respuesta, y al final se detienen incluso funciones que parecen no tener relación. Esto se llama fallo en cascada, y su propagación se evita con timeouts y circuit breakers (un mecanismo que corta durante un tiempo las llamadas que siguen fallando).
Las tareas de operación también causan lag. Los reinicios durante el despliegue de una actualización, los minutos que se tarda en añadir servidores automáticamente cuando llega mucha gente, el proceso de trasladar un personaje a otro servidor al cambiar de zona y la carga invisible que generan bots y macros: para el jugador, todo eso se ve como “lag”.
La arquitectura de servidores es una empresa en la que varios departamentos se pasan documentos para su aprobación. Si el departamento del final de la cadena de aprobación (la BD) se vuelve lento, los departamentos anteriores hacen fila con sus documentos y al final se paraliza el trabajo de toda la empresa. El timeout es la regla de “si no hay respuesta en más de 10 minutos, se devuelve el documento”, y el circuit breaker es la regla de “si las devoluciones continúan, durante un tiempo no se envían documentos a ese departamento y se devuelven de inmediato”.
Si se pone un servidor intermedio entre el cliente y el servidor del juego, cada paso por él suma tiempo de procesamiento y ese servidor se convierte en un punto único de fallo.
Por qué: Arquitectura cliente ↔ gateway ↔ servidor del juego → Efecto: El servidor intermedio añade procesamiento y espera; si se sobrecarga, afecta a todos → En pantalla: El ping sube para todos; si el gateway falla, todos los jugadores que pasan por él sufren una desconexión
Síntomas: Input lag, Desconexión · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura), Desarrollo de cliente (Equipo de desarrollo)
Al entrar en otra zona o mazmorra, los datos del personaje se traspasan a otro servidor, y en ese proceso surgen retrasos y fallos.
Por qué: Al entrar en una mazmorra o cambiar de continente, cambia el servidor responsable → Efecto: Guardar → transferir → cargar; si el servidor de destino está saturado o no hay instancias de mazmorra libres, toca esperar → En pantalla: Cargas largas, fallos al entrar, desconexión durante el traslado
Síntomas: No conecta / carga infinita, Congelamiento, Desconexión, Rubber banding · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Cuando un servicio se vuelve lento, los servidores que lo llaman se quedan bloqueados esperando su respuesta y hasta funciones sin relación se detienen.
Por qué: Un servicio, como la BD o la autenticación, se vuelve lento → Efecto: Los hilos y conexiones de los servidores que lo llaman quedan retenidos esperando respuesta, y los reintentos de las solicitudes fallidas suman carga → En pantalla: Hasta funciones que parecen no tener relación se vuelven lentas o se detienen
Síntomas: Congelamiento, Input lag, No conecta / carga infinita · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de red (Equipo de infraestructura)
Si falla un servidor que funciona aparte del servidor del juego, como el del chat, los grupos o la casa de subastas, solo deja de funcionar esa función.
Por qué: El servidor dedicado a una función se vuelve lento o se cae → Efecto: Solo las solicitudes de esa función se quedan sin respuesta → En pantalla: El chat no funciona, las invitaciones de grupo no responden, el mercado se queda en carga infinita (el combate va normal)
Síntomas: Acción perdida / rollback, No conecta / carga infinita · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Si al reiniciar un servidor para actualizarlo no se trasladan sus conexiones, los jugadores que estaban en él se desconectan, y los guardados justo antes del cierre y las reconexiones llegan todos de golpe.
Por qué: Se despliega un hotfix y se reinician los servidores uno tras otro → Efecto: Se apaga sin trasladar las conexiones a otro servidor, y los guardados de todos los jugadores de ese servidor se concentran en la BD → En pantalla: Desconexión sin aviso, avalancha de reconexiones
Síntomas: Desconexión, No conecta / carga infinita, Input lag · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Cuando se junta mucha gente, se añaden servidores automáticamente, pero prepararlos lleva unos minutos y mientras tanto los servidores existentes van sobrecargados.
Por qué: Empieza un evento y las conexiones se disparan → Efecto: Un servidor nuevo tarda varios minutos en arrancar y estar listo → En pantalla: Cámara lenta y el juego no conecta durante los primeros minutos del evento
Síntomas: Cámara lenta, No conecta / carga infinita · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Cuando hay un incidente, los logs se disparan, y los servidores que envían sus logs de forma síncrona se vuelven todavía más lentos por culpa de esos logs.
Por qué: Al aparecer errores, se dispara el volumen de logs y métricas enviados → Efecto: El recolector de logs se atrasa y los servidores que envían de forma síncrona se quedan esperando → En pantalla: Durante el incidente, los tirones y congelamientos empeoran por culpa de los logs
Síntomas: Tirones, Congelamiento · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Si cada servidor tiene un reloj un poco distinto, las comprobaciones de cooldowns, buffs y comienzos de evento no coinciden entre servidores.
Por qué: El reloj de un servidor cuya sincronización horaria se detuvo se desfasa de cientos de ms a varios segundos respecto a los demás → Efecto: Si se pasan horas absolutas entre servidores, como la hora en que termina un buff, las comprobaciones no coinciden → En pantalla: Tras moverse a otro servidor, un buff desaparece o el cooldown vuelve a empezar
Síntomas: Acción perdida / rollback · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Los bots envían solicitudes con mucha más frecuencia que una persona y acaparan la capacidad de procesamiento del servidor.
Por qué: Se conectan en masa bots que repiten sin descanso la caza, los desplazamientos o los intercambios → Efecto: Aumentan la carga de procesamiento del servidor y la de la BD → En pantalla: Una zona de caza concreta o todo el servidor se vuelve lento (cámara lenta, input lag)
Síntomas: Cámara lenta, Input lag · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de red (Equipo de infraestructura)
Si un servicio externo, como el login de la plataforma, los pagos o la verificación de identidad, va lento o se detiene, todo se bloquea en ese paso.
Por qué: Fallo o lentitud de un servicio externo de autenticación o de pagos → Efecto: Ese paso se queda esperando respuesta → En pantalla: No se puede iniciar sesión, los pagos fallan. Quienes ya están jugando siguen bien
Síntomas: No conecta / carga infinita, Acción perdida / rollback · Responsable principal Externo (Externo) · También Desarrollo de servidor (Equipo de desarrollo)
Si a un jugador se le asigna un servidor de una región lejana cuando hay una cercana, tiene siempre el ping alto aunque su conexión esté bien.
Por qué: Datos de GeoIP erróneos, VPN, asignación de todo el grupo según el ping medio de sus miembros, reglas que amplían la búsqueda a regiones lejanas cuando faltan jugadores, asignación según la ubicación del resolver DNS → Efecto: Se conecta a un servidor de una región al otro lado del océano aunque haya una región cercana → En pantalla: En un juego con servidores en varias regiones, solo tú (o solo tu grupo) tienes siempre el ping alto, con input lag, rubber banding y habilidades que no salen
Síntomas: Input lag, Rubber banding, Acción perdida / rollback · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo), Infraestructura de red (Equipo de infraestructura), Externo (Externo)
Si el certificado de un servidor de login, de API o de parches expira o le falta el certificado intermedio, desde ese momento falla la conexión TLS de los clientes que abren una conexión nueva.
Por qué: El certificado está fuera de su periodo de validez, el servidor lo envía sin el certificado intermedio, o la fecha y hora del dispositivo del jugador están mal → Efecto: El cliente no puede validar el certificado y corta la conexión TLS → En pantalla: El juego no conecta o se queda en carga infinita en el login o la descarga de parches, fallan solo las funciones HTTPS como la tienda. Quienes ya estaban conectados suelen seguir bien
Síntomas: No conecta / carga infinita, Acción perdida / rollback · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Infraestructura de servidores (Equipo de infraestructura), Desarrollo de cliente (Equipo de desarrollo)
Cuando la gente entra en masa justo después de un lanzamiento o un mantenimiento, la cola de inicio de sesión llega a su tope y rechaza nuevas entradas, y quien estaba esperando pierde su lugar si se desconecta un momento y vuelve al final de la cola.
Por qué: Hay más gente intentando entrar de la que el servidor de login puede aceptar a la vez, así que se usa una cola, y si se alarga demasiado se rechazan nuevas entradas para proteger el servidor → Efecto: Cuanto más larga es la cola, más dura la espera, y mientras tanto basta un corte breve del Wi-Fi o de la red móvil para perder el lugar → En pantalla: El juego no conecta o se queda en carga infinita, se cierra con un error durante la espera y hay que volver a esperar desde el final
Síntomas: No conecta / carga infinita, Desconexión · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo), Infraestructura de servidores (Equipo de infraestructura)
Cuando recibas un reporte de lag, elige solo tres cosas: “a quién, cuándo y cómo se ve”. El asistente muestra, ordenadas por puntuación, las causas de este libro blanco que mejor encajan. No es un diagnóstico definitivo, pero basta para decidir a qué equipo preguntar primero.
Cuando llega un reporte o una alerta, se acota en este orden: alcance → momento → capa. Dónde se concentra la anomalía es lo que más pesa para decidir el responsable; con qué coincide en el tiempo acota la causa; y la capa cuyas métricas son anómalas lo confirma. Si se usan juntos “En el gráfico” y “Cómo verificarlo”, que aparecen en cada ficha de causa, se pueden elegir candidatos por la forma del gráfico y encontrar enseguida dónde mirar.
¿Dónde se concentra la anomalía?
¿Con qué coincide?
¿Qué capa tiene métricas anómalas?
| Qué revisar | Si se ve así | A quién llamar primero |
|---|---|---|
| Cola de recepción del socket del servidor (Recv-Q) | Se acumula porque el proceso del servidor no lee a tiempo | Equipo de desarrolloServidor (tick detenido, GC, locks) |
| Retransmisiones y RTT por conexión | Solo algunas conexiones, concentradas en un ASN | Equipo de infraestructuraRed ExternoISP y conexión del jugador |
| Todas las conexiones de un host | Equipo de infraestructuraServidores/SO (NIC, kernel) | |
| Aumento de retransmisiones y ancho de banda en todo el servidor justo después de un parche | Cambiaron el tamaño o la frecuencia de los paquetes | Equipo de desarrolloServidor Equipo de infraestructuraRed (MTU, límites) |
| CPU steal, throttling, softirq, descartes de la NIC | Aumentan | Equipo de infraestructuraServidores/SO |
| Un solo hilo al 100%, espera en la cola de ejecución, pausas del GC | Aumentan | Equipo de desarrolloServidor |
| Sube la latencia de la BD con el mismo número de consultas | IOPS, bloqueos, otras tareas | Equipo de infraestructuraServidores de BD |
| El número o la forma de las consultas a la BD cambió tras el parche | N+1, consultas nuevas | Equipo de desarrolloServidor |
| Monitoreo sintético desde puntos en el extranjero (RTT, pérdida) | Malo | Equipo de infraestructuraRed ExternoISP |
| El monitoreo sintético es normal, pero solo los jugadores van mal | Entorno del jugador o cliente | ExternoEntorno del jugador Equipo de desarrolloCliente |
| Distribución de los motivos de desconexión | Timeout de heartbeat↑ / RST↑ / corte por el servidor↑ | NAT o ruta / dispositivos de red / servidor |
| Periodo exacto (en punto, cada N minutos) | Tareas programadas, copias de seguridad, GC, eventos | Quien creó ese calendario |
Con solo saber qué forma tiene el gráfico de monitoreo, los candidatos se reducen mucho. Para cada una de las 13 formas de abajo se reúnen las causas que la producen. Los pequeños dibujos de las fichas de causa tienen la misma forma. La línea continua es la métrica principal, la línea discontinua es la métrica que se mira junto a ella (jugadores, esperas, errores, etc.) y la línea discontinua tenue es el nivel normal.
Normalmente bajo, pero se dispara a intervalos fijos: cada pocos segundos, cada pocos minutos o a cada hora en punto.
Recolección de basura (GC) en el cliente, Escaneos del módulo anti-cheat, Escaneo de Wi-Fi en segundo plano, Tareas programadas, Temporizadores que se disparan todos a la vez, Pausa stop-the-world del GC en el servidor, Pausa del GC en el motor de scripts, Avalancha de fsync, Copias de seguridad, compresión y escaneos, Checkpoint y volcado del log, Procesos batch masivos, Estampida de caché
Se dispara de forma irregular, sin patrón, y enseguida vuelve a su nivel.
Pico de frametime, Extrapolación excesiva (dead reckoning), Error de predicción en el cliente, Espiral de recuperación con timestep fijo, Procesos en segundo plano que ocupan la CPU, Falta de memoria y swap en el cliente, Ahorro de energía y drivers de la NIC, Interferencias y señal débil en el Wi-Fi, Cambios frecuentes 5G↔LTE (en el límite de la cobertura 5G), Mala calidad de la conexión, Búfer circular (ring buffer) insuficiente, Sobrecarga de virtualización y vecino ruidoso, Búferes de socket del kernel insuficientes, CPU steal (máquinas virtuales), Pausas por recuperación y compactación de memoria, Salto del reloj del sistema (step de NTP), Envíos bloqueantes por clientes lentos, Configuración de retransmisión del UDP confiable, Pérdida de los últimos datos por un cierre forzado con RST, Llamadas síncronas en el hilo del juego, Escritura síncrona de logs, Carga diferida (lazy loading) en el servidor, Deadlock en la BD, Comandos lentos en Redis, Sobrecarga por logs y monitoreo, Espera al jugador más lento en lockstep, Predicciones fallidas en el netcode de rollback, Reproducción al llegar, sin marcas de tiempo, Validación del servidor demasiado estricta, Discrepancias de pathfinding en la sincronización de comandos, Condición de carrera en el registro de visibilidad (AOI), Pérdida del snapshot de referencia (baseline), Pérdida del mensaje de desaparición (entidad fantasma), Confusión por reutilización de IDs de entidad, Retransmisiones espurias por picos de latencia
Sube un escalón a partir de un momento concreto (un parche, un cambio de configuración, un cambio de ruta) y se queda ahí.
Fallos en cables submarinos y enlaces internacionales, Cambios de ruta BGP y convergencia, Desvío por la protección DDoS y falsos positivos, Cambios de rendimiento tras actualizar el SO, el kernel, los drivers o el firmware, Cambio del patrón de tráfico tras un parche, Consultas sin índice, Consultas lentas por un cambio en el plan de ejecución, Bloqueos por cambios de esquema (DDL) en producción, Dependencia de servicios externos, Cambio de ruta o ruta ECMP defectuosa
Sube poco a poco a lo largo de horas o días. Crece con el tiempo que lleva encendido.
Error de sincronización del reloj, Pérdida de precisión del tiempo en float, Fuga de memoria en el cliente, Ahorro de energía y thermal throttling, Fuga de memoria, Swap, Fragmentación de memoria, Disco lleno, Transacciones abiertas durante mucho tiempo, Desfase de reloj entre servidores
Sube despacio y cae de golpe al reiniciar o limpiar, una y otra vez.
Caída brusca del ritmo de envío por el control de congestión, Acumulación de entidades (objetos e invocaciones sin limpiar)
Forma una loma a la misma hora cada día, como en el pico de la noche.
Canal Wi-Fi saturado, Congestión del peering en horas pico, Falsos positivos de validación concentrados en un ISP, Desbordamiento de la cola en el cuello de botella (pérdida por congestión)
Cuando aumentan los jugadores conectados o los que se juntan en un mismo lugar, sube todavía más rápido que ellos.
Carga de renderizado de multitudes, Cuello de botella al procesar paquetes en el hilo principal, Desbordamiento del búfer de recepción, Otras apps del dispositivo que ocupan el ancho de banda, Bufferbloat (cola del router), Microrráfagas en el switch, Exceso de hilos y cambios de contexto, Throttling de CPU en contenedores (cuota de CFS), Fragmentación IP de paquetes UDP, Modelo de E/S bloqueante, Tick que excede su presupuesto, Explosión del cálculo de visibilidad (AOI, N²), Explosión de broadcast, Sobrecarga de una zona de un solo hilo (hotspot), Contención de locks, Avalancha de pathfinding, Costo de serialización y compresión, Combate concentrado en un solo objetivo (world boss), Avalancha de asignaciones, Contención de bloqueos en una fila caliente, Retraso de replicación, Paso por un gateway o proxy, Cambio de zona (traspaso entre servidores), Presupuesto de envío y prioridad por conexión, Ráfagas de envío que desbordan búferes poco profundos, Desajuste de dúplex
El throughput o el número de conexiones llega a un valor y ya no sube más; a partir de ahí aumentan las esperas y los errores.
Falta de memoria gráfica (VRAM), Router poco potente o sobrecalentado, Limitación de velocidad y gestión del tráfico del ISP, Enlaces compartidos saturados por un DDoS, Tabla de sesiones del firewall llena, Límites de conexiones y puertos del gateway NAT en la nube, Saturación del enlace del centro de datos, Interrupciones de la NIC concentradas en un solo núcleo, Límite de PPS de la nube superado, Saturación del ancho de banda de la NIC, Límite de descriptores de archivo, Tabla conntrack del servidor llena, Agotamiento de puertos efímeros en conexiones entre servidores, Acumulación en la cola de mensajes, Agotamiento del pool de hilos, Thrashing del GC (heap casi lleno), Agotamiento de los créditos de ráfaga del disco en la nube, Límite de IOPS y saturación de la cola, Agotamiento del pool de conexiones, Fallo en cascada, Tope de la cola de inicio de sesión y periodo de gracia para reconectar demasiado corto, Fallo de streaming por falta de memoria o VRAM, Descarte del exceso por un policer, Descarte de paquetes en el host del servidor receptor, Descartes del firewall o del seguimiento de conexiones, Límite de procesamiento superado en dispositivos intermedios (firewall, IPS, protección DDoS)
No tiene picos: se mantiene alto todo el tiempo. Pasa cuando la causa es estructural, como la distancia, la ruta o el diseño.
Búfer de interpolación ausente o demasiado corto, V-Sync y cola de renderizado, Resolución del temporizador, Latencia de pantalla, dispositivos de entrada y generación de frames, Retardo de propagación (distancia física), Enrutamiento con rodeos, Coalescencia de interrupciones excesiva, Retraso por agrupación en GRO/LRO, Picos de latencia por la gestión de energía del servidor (C-states, escalado de frecuencia), Algoritmo de Nagle + ACK retardado, Fallo de caché, Latencia de búsqueda (seek) en HDD, Feedback solo tras la respuesta del servidor (solicitud-respuesta), Protocolo con muchas idas y vueltas secuenciales (chatty), Sin búfer de inputs para habilidades, Autoridad del cliente, Doble espera de tick, Tasa de envío de snapshots baja, Retransmisiones rápidas espurias por reordenamiento de paquetes, RTO mal ajustado al entorno, Eliminación de opciones TCP en dispositivos intermedios
La mayoría está normal y solo algunos jugadores, regiones, ISP o dispositivos dan valores altos.
Almacenamiento lento que retrasa el streaming de assets, Crash del cliente, Inspección de paquetes del software de seguridad, Interferencias de programas de overlay, Retraso en el cambio de estado RRC (ahorro de energía de la radio móvil), Señal móvil débil y zonas sin cobertura, Restricciones en Wi-Fi público y redes corporativas, Internet satelital (órbita baja y geoestacionaria), Una ruta ECMP defectuosa, Restricciones de UDP e inspección de paquetes por país o ISP, Fallos y lentitud del DNS, Paso por una VPN o un acelerador de juegos, Desbalance del balanceador de carga y health checks erróneos, Cables defectuosos y errores de puerto, Desajuste de MTU (solo desaparecen los paquetes grandes), Política para clientes lentos (slow consumer), Keepalive con valor predeterminado de 2 horas, Slow start tras inactividad, Reparto desigual con SO_REUSEPORT, Acceso a memoria NUMA remota, Exceso de macros y bots, Errores de matchmaking y asignación de región, Ventanas de tiempo cortas que el ping consume, Registro de impactos sin compensación de lag, Compensación de lag excesiva, Arquitectura de anfitrión (host), Rechazo del servidor tras el feedback anticipado, Un jugador con lag se mueve a ráfagas en la pantalla de los demás, Cámara rápida en servidores que procesan cada paquete al llegar, Tamaño del búfer de inputs de cada jugador, Un miembro del grupo con lag y las mecánicas del jefe, Un cliente lento controla al monstruo, Personaje con datos sobredimensionados, Diferencias de canal, instancia o phasing, Mensajes de aparición descartados durante la carga, Colisión de puertos UDP fijos, Bug de sesiones identificadas por IP o dispositivo, Restricciones al multicliente, Conflictos por acceso simultáneo a archivos de caché o assets, Opciones de visualización distintas, Desajuste de versión o datos del cliente, Entidades retenidas por errores en la estimación del reloj, Pérdida en el tramo inalámbrico, Errores físicos (cables, transceptores ópticos o conectores defectuosos), Agujero negro de MTU (solo los paquetes grandes se pierden una y otra vez), ACK retrasados o perdidos (subida saturada)
Durante un rato no se recibe nada y luego llega todo de golpe.
Procesamiento limitado con la ventana minimizada o sin foco, Handover entre estaciones base (en movimiento), Mantenimiento del host en la nube y migración en vivo, Problemas de driver y firmware de la NIC, Bloqueo HOL en TCP, RTO de TCP y backoff exponencial, Procesamiento limitado de las ventanas en segundo plano, Recuperación lenta en thin streams, Ventana cero (una detención que parece retransmisión)
El número de conexiones cae de golpe o el de desconexiones se dispara en un instante.
Aplicación móvil enviada a segundo plano, Cambio Wi-Fi ↔ LTE/5G, Expiración del mapeo NAT, IP compartida del ISP (CGNAT), Timeout por inactividad del balanceador de carga, Expiración del seguimiento de conexiones en grupos de seguridad de la nube, Failover de equipos de red, OOM killer, Error WSAECONNRESET en sockets UDP de Windows, Deadlock, Crash del servidor, Bucles infinitos y lógica desbocada, Escritura de core dumps, Failover de la BD, Pérdida de progreso por intervalos de guardado largos, Caída de un servidor auxiliar, Despliegues y reinicios, Certificado TLS expirado o mal configurado, Expiración del mapeo NAT o del balanceador de carga en mitad de la conexión
Se dispara justo al abrir el servidor o al empezar un evento y luego baja poco a poco.
Carga síncrona y compilación de shaders en el hilo principal, Desbordamiento de la cola de conexiones pendientes (backlog), Avalancha de spawns al entrar en una zona concurrida, Caché fría (justo después de reiniciar), Avalancha de inicios de sesión y consultas N+1, Retraso del autoescalado, Pérdida de la ráfaga de mensajes de aparición al entrar, Retransmisión de la solicitud de conexión (SYN)
Para cada causa se contó el medio de verificación más sencillo. Con herramientas de infraestructura se verifica con herramientas del SO, de red, de la nube y de la BD y con opciones de arranque del runtime (logs del GC, etc.), sin tocar el código del juego. Los logs/métricas del juego son cosas que solo se ven si el juego las registra, como el tiempo de tick o los motivos de desconexión. Cuantas más causas de este tipo tiene una capa, más argumentos hay para pedir instrumentación al equipo de desarrollo.
La media oculta los picos. En un servidor de 20 ticks por segundo, basta con que el 1% de los ticks sea lento para que todos noten un tirón cada 5 segundos, aunque el tiempo medio de tick casi no cambie. Por eso se miran también los percentiles. p50 (mediana) es el valor que la mitad de las mediciones no supera, y p99 es el valor cercano a la medición más lenta de cada 100. Lo que los jugadores recuerdan como “lag” suele estar del lado del p99.
El intervalo de agregación también oculta los picos. En un gráfico de medias por minuto, una detención de 1 segundo se diluye a 1/60. Para encontrar detenciones, se miran también el máximo o el p99 del mismo gráfico, o un intervalo más corto.
El jitter es cuánto varía el intervalo con que llegan los paquetes. Aunque el ping medio sea bajo, si el jitter es alto, el búfer de interpolación se vacía y aparecen tirones y teletransporte.
| Método de medición | Qué mide | Precauciones |
|---|---|---|
ping (ICMP) | Tiempo de ida y vuelta hasta el dispositivo | Los routers y servidores pueden procesar tarde las respuestas ICMP o limitar cuántas envían, así que el resultado puede diferir del de los paquetes del juego. Si está bloqueado, no hay respuesta en absoluto |
mtr·traceroute | Latencia y pérdida por salto | Si solo un dispositivo intermedio muestra mucha pérdida y los saltos siguientes están bien, lo más probable es que ese dispositivo solo limite las respuestas ICMP. Solo es pérdida real la que continúa hasta el final |
RTT de TCP (rtt de ss -ti) | Tiempo de ida y vuelta que mide el kernel en cada conexión | Es el valor de la conexión real del juego, así que es el más confiable. Se puede ver por jugador desde el servidor |
| Ping del juego | Tiempo de ida y vuelta que mide el juego con sus propios mensajes | Si se mide dentro del bucle del juego, se mezcla con la espera del frame o del tick. Aunque la conexión esté bien, sube si el servidor o tu PC están ocupados |
ss -ti o herramientas eBPF y verlos por ASN.pidstat -t), espera en la cola de ejecución y logs del GC que se activan solo con opciones de arranque.mtr.Aquí se reúnen los pasos de revisión para dos situaciones frecuentes e incidentes reales publicados por los propios desarrolladores originales y operadores. Cada paso y cada caso enlaza con las fichas de las causas relacionadas.
Cuando aumentan los reportes de lag a partir de un parche o despliegue concreto. Se usa cuando se acumulan reportes del tipo “desde esta actualización va raro” o cuando un gráfico sube en escalón en cierto momento y se queda arriba.
Cuando se abre el servicio en un país nuevo o se añade una región o un centro de datos nuevos. Se usa tanto para las comprobaciones previas a la apertura como para distinguir reportes del tipo “en Corea va bien, pero los jugadores del nuevo país tienen lag”.
Solo se han elegido postmortems publicados por las propias empresas de juegos e infraestructura. Los resúmenes se limitan a lo que dice la publicación original; para conocer los detalles, consulta la publicación original.
En la gran batalla de flotas del sistema HED-GP, analizada en una retrospectiva de enero de 2014, el servidor sufrió una sobrecarga grave. Time Dilation (función que ralentiza el tiempo del juego cuando hay sobrecarga) llegó a su mínimo del 10% y todo el campo de batalla pasó a cámara lenta, pero aun así la carga siguió acumulándose. El retraso acumulado en el procesamiento de las desactivaciones y los ciclos repetidos de los módulos (Dogma Lateness) llegó a un máximo de 193 segundos de tiempo de juego, unos 32 minutos en tiempo real. En la batalla de 6VDT de julio de 2013, de un tamaño casi igual, el máximo fue de 42 segundos (unos 7 minutos en tiempo real). CCP advirtió que no podía tener certeza, porque sus herramientas de perfilado añaden carga por sí mismas y no se ejecutan en situaciones así, y señaló dos causas probables. La primera fue la carga sin procesar que siguió acumulándose a medida que la batalla se alargaba. La segunda fue el mayor uso de drones: el número de drones desplegados durante la batalla (sin contar duplicados) fue de 21,123 en 6VDT y de 38,852 en HED-GP, un 84% más. Los envíos que comunican la acción de un jugador a todos los que la ven crecen con el cuadrado del número de jugadores (O(n²)), y los drones generan más mensajes por cada ataque. Además, el código con el que los drones eligen objetivo a menudo recorre todos los objetivos atacables del mismo campo de batalla, así que su costo crece casi como n².
Cuando la carga de procesamiento de una zona abarrotada supera su límite, toda esa zona pasa a cámara lenta, y cuanto más dura la batalla, más trabajo pendiente se acumula y más crece el input lag. Señales que revisar: el tiempo de tick y el trabajo pendiente del servidor (nodo) que atiende esa zona, junto con el número de jugadores y de entidades. Lo característico es que las demás zonas siguen bien. El responsable principal es el equipo de desarrollo (servidor), y lo que hay que corregir es a cuántos destinatarios se comunica cada acción y el costo de la búsqueda de objetivos de la IA. Ralentizar el tiempo del juego no elimina la sobrecarga, pero hace que todos vayan más lentos al mismo ritmo, y así evita que solo algunas acciones se retrasen sin límite. Publicación original
Es un artículo técnico en el que Riot Games explica por qué internet no se adapta bien a los juegos en tiempo real. El tráfico real que reportó un jugador de League of Legends tenía que ir directo de San Francisco a Portland, pero pasaba por Los Ángeles, Denver y Seattle, y tardaba 70 ms en un trayecto que en línea directa habría costado 14 ms. Riot explicó que, cuando los routers se desbordan y descartan paquetes, los demás campeones parecen saltar por la pantalla y los proyectiles parecen teletransportarse. Riot señaló como causas la ruta y los routers. Los proveedores de red troncal y los ISP priorizan la ruta más barata sobre la de menor latencia, y cuando la ruta que fija BGP da un rodeo largo, también aumenta el número de routers por los que pasa el tráfico. Un router carga con un trabajo de procesamiento proporcional al número de paquetes, sea cual sea su tamaño. Los paquetes de juego rondan los 55 bytes, así que, para la misma cantidad de datos, son 27 veces más paquetes que con paquetes de 1,500 bytes, y, en la misma proporción, llenan antes los búferes de entrada de los routers. Según Riot, muchos routers descartan primero los paquetes UDP cuando se sobrecargan. Como solución, Riot creó su propia red, Riot Direct, con routers en 10 grandes nodos de internet de EE. UU. y conexiones directas (peering) con tantos ISP como fuera posible. Según la segunda parte, el porcentaje de jugadores con un ping inferior a 80 ms subió del 31% al 50% en algo más de 9 meses, y llegó al 80% de la noche a la mañana después de trasladar los servidores del juego a Chicago.
Si dentro de un mismo país solo los jugadores de un ISP concreto tienen un ping especialmente alto, hay que sospechar de la ruta. Señales que revisar: la distribución del RTT por ISP (ASN) y las ciudades de paso que aparecen en traceroute. El responsable principal es el equipo de infraestructura (red), y se corrige con peering directo con los ISP, conexión a IX (puntos de intercambio de internet) y la elección de la ubicación de los servidores. La política de rutas del lado del ISP hay que acordarla con partes externas (el ISP). Este caso también muestra que basta con acercar los servidores al centro de la distribución de los jugadores para lograr una gran mejora. Publicación original
A finales de febrero de 2020, los servidores EUW, EUNE y BR de League of Legends sufrieron varias caídas, y el número de partidas nuevas que empezaban bajó mucho. Todos los servicios de backend, como el matchmaking y los servidores de juego, estaban en buen estado, pero casi no les llegaba tráfico. Riot aplazó una semana el modo torneo (Clash) para no abrirlo en clústeres que podían ser inestables. La retrospectiva no indica cuánto duró cada caída. Coincidieron tres cosas. Las solicitudes a un servicio estaban mal construidas: en ciertos casos fallaban una y otra vez y se reintentaban sin parar, y el volumen de solicitudes se disparó. Un problema de compatibilidad conocido entre el sistema de contenedores y la versión del SO provocaba una fuga de memoria dentro del SO; la actualización solo se había completado en cerca del 60% de todo el entorno de contenedores de Riot y seguía en curso en los clústeres de Europa y Latinoamérica. Los contenedores edge, que reciben el tráfico de internet, lo filtran y lo pasan al backend, se repartían en hosts separados dentro de un mismo shard (grupo de servidores), pero nada impedía que coincidieran los de shards distintos, así que en cada caída había contenedores edge de al menos tres shards concentrados en un solo host. La avalancha de reintentos cayó sobre ese host, y la fuga de memoria terminó por detenerlo.
Si todos los servicios de backend responden que están “bien, pero no les llega tráfico”, hay que mirar lo que tienen delante (edge, gateways, balanceadores de carga). Señales que revisar: la concentración de conexiones entrantes en ciertos hosts y la tasa de fallos y reintentos de solicitudes concretas. El responsable principal es el equipo de desarrollo (servidor: la solicitud mal construida y la forma de reintentar), y el equipo de infraestructura (servidores/SO) se encarga de las reglas de ubicación de contenedores, las actualizaciones del SO y las alertas de desbalance. Riot corrigió el código de la solicitud, cambió los reintentos para que no se dispararan y, hasta implementar el reparto entre shards, configuró alertas de desbalance. Publicación original
El 22 de enero de 2021, el servidor EUW de League of Legends dejó de funcionar bien durante algo más de 5 horas. Las métricas de jugadores con sesión iniciada y de jugadores en partida se cortaron a la vez, y entre los dos reinicios los inicios de sesión aumentaban, pero casi no empezaban partidas. El servidor principal de una BD que atendía una función no crítica sufrió una avería de hardware, y esa BD no tenía configurado el failover automático a un servidor de reserva. Cada BD tenía su propio pool de conexiones, pero todos los pools usaban el mismo pool de hilos; las tareas enviadas a la BD averiada no terminaban y retenían hilos, hasta que el sistema entero se quedó sin hilos disponibles. En medio de una avalancha de alertas, el equipo sospechó primero de un ataque de red malicioso sufrido poco antes y de trabajos de hardware en otra región, y la alerta de la BD averiada no se vio hasta cerca de 1 hora después. Como todos los sistemas se ejecutaban en una sola JVM, cuando el GC detuvo el proceso varios segundos cada vez bajo la carga de reconexiones posterior al reinicio, también quedaron grandes huecos en la recopilación de métricas. Además, la cola de inicio de sesión no respetó el límite configurado, y la entrada de jugadores fue irregular.
Una sola BD auxiliar que se consideraba poco importante puede detenerlo todo a través de un recurso compartido como un pool de hilos. Señales que revisar: el número de solicitudes en espera por BD, la utilización del pool de hilos y una proporción de partidas iniciadas demasiado baja respecto a los inicios de sesión. Los responsables son el equipo de desarrollo (servidor: aislamiento de los pools de hilos, timeouts) y el equipo de infraestructura (BD: failover automático). Cuando llueven alertas, es fácil sospechar primero del último problema sufrido (un ataque, por ejemplo), así que conviene descartar una cosa tras otra siguiendo el orden de diagnóstico (alcance → momento → capa). Después de un reinicio, también hay que comprobar que la cola de inicio de sesión limita la entrada según lo configurado. Publicación original
Empezó la tarde del 28 de octubre de 2021 (hora del Pacífico) con una carga de CPU alta en un servidor de Consul. A las 16:35, el número de jugadores conectados cayó a la mitad de lo normal y después todo el servicio se detuvo. Hasta las 16:45 del 31 de octubre no pudieron volver a entrar todos los jugadores: habían pasado 73 horas desde el inicio de la caída. Roblox indicó que lo usan 50 millones de personas al día. Roblox usa HashiCorp Consul para el descubrimiento de servicios (la función con la que los servicios encuentran las direcciones de los demás), los health checks y un almacén KV, y un mismo clúster de Consul atendía varias cargas de trabajo a la vez. Hubo dos causas raíz. La primera: la nueva función de streaming de Consul, que se había ido extendiendo durante meses, se activó el día anterior a la caída también para el servicio de enrutamiento de tráfico, y el número de nodos de ese servicio se aumentó un 50%; con una carga muy alta tanto de lecturas como de escrituras, esta función provocó contención en un único recurso compartido (un canal de Go). En los servidores de doble socket (NUMA) con más núcleos que se instalaron como reemplazo durante la caída, la contención fue aún peor. La segunda: la gestión de la lista de páginas libres (freelist) de BoltDB, que Consul usa para guardar el log de Raft, se volvió patológicamente lenta y escribía 7.8 MB en disco por cada adición de 16 kB o menos. La mediana de la latencia de escritura KV, normalmente inferior a 300 ms, subió a 2 segundos, y en el servidor líder lento también se observó ventana cero (búfer TCP lleno). Como la telemetría dependía de Consul, también desaparecieron las métricas necesarias para encontrar la causa.
Cuando un sistema base del que dependen muchos servicios (descubrimiento de servicios, almacén de configuración, autenticación) se vuelve lento, todas las funciones se detienen a la vez. Señales que revisar: la latencia de escritura, los cambios de líder y la CPU de ese sistema, además de los cambios de configuración hechos justo antes de la caída. Los responsables son ambos: el equipo de desarrollo (servidor) y el equipo de infraestructura (servidores/SO). El monitoreo debe estar separado del sistema que vigila y no depender de él; así, durante una caída, las métricas siguen disponibles. En la recuperación, las cachés están vacías y dejar entrar a todos de golpe puede provocar otra caída, por eso Roblox reguló con DNS el porcentaje de jugadores que podían entrar y lo fue subiendo de un 10% en un 10% aproximadamente. Publicación original
Desde el acceso anticipado de la expansión Endwalker, en diciembre de 2021, todos los mundos (Worlds) estuvieron extremadamente congestionados. Las colas de inicio de sesión se alargaron, y el Error 2002 aparecía a menudo al iniciar sesión desde la pantalla de selección de personaje o mientras se esperaba en la cola. También hubo caídas de algunos mundos y zonas (Error 3001) y timeouts de la cola (Error 4004). En el aviso del 11 de diciembre, el octavo día del acceso anticipado, la congestión aún continuaba. El Error 2002 se produce en dos casos. El primero, cuando hay más de 17,000 jugadores esperando en un mismo centro de datos lógico: es un tope para evitar que una cola demasiado larga haga caer el servidor de login, y cuando se alcanza, el cliente se cierra por completo. El 7 de diciembre se destinó hardware de reserva del entorno de desarrollo a los servidores de lobby para subir el tope; este error disminuyó, pero las colas se hicieron todavía más largas. El segundo, cuando la conexión del jugador en espera es inestable. Al alargarse la espera, aumentaron los cortes breves de conexión por pérdida de paquetes en la ruta por internet o por un Wi-Fi inestable. El servidor de lobby espera la reconexión entre unas decenas de segundos y 1 minuto aproximadamente: quien se reconecta dentro de ese plazo conserva su posición en la cola, y quien tarda más vuelve al final. Square Enix indicó que la mayoría de los reportes correspondían a este caso. Por la escasez de semiconductores, tampoco se podían añadir mundos de inmediato.
Cuanto más larga es la cola, más a menudo un corte breve de la conexión de un jugador en espera se convierte en un error de conexión. Con la misma congestión, los errores se concentran en quienes usan Wi-Fi o conexiones inestables: es uno de esos problemas que “solo afectan a algunos”. Señales que revisar: la longitud de la cola y el tiempo de espera y, entre los motivos de desconexión, la proporción de cortes durante la espera en la cola. El responsable principal es el equipo de desarrollo (servidor: tope de la cola y periodo de gracia para reconectar), y el equipo de infraestructura colabora añadiendo servidores de lobby y de mundo. Un periodo de gracia para reconectar generoso reduce los casos en que un corte breve de la conexión del jugador termina costándole su posición en la cola. Publicación original
Muchos juegos confían su web, sus API y su protección DDoS a proveedores de CDN, así que este es un tipo de caída de infraestructura que también afecta a los juegos. El 17 de julio de 2020, durante 27 minutos, de 21:12 a 21:39 (UTC), el tráfico de toda la red de Cloudflare cayó cerca de un 50%. El impacto se limitó a los puntos de presencia (PoP) de algunas ciudades de EE. UU., Europa, Rusia y Brasil conectados a la red troncal; los demás PoP funcionaron con normalidad. Una avería en el tramo de red troncal Newark–Chicago congestionó el tramo Atlanta–Washington, y un ingeniero cambió la configuración de un router para quitarle tráfico de la red troncal a Atlanta. Tenía que desactivar todo un término de la política (term), pero solo desactivó la condición que contenía (prefix-list), y el router de Atlanta difundió todas sus rutas BGP por toda la red troncal con una prioridad más alta (local-preference 200). Cada PoP asignaba prioridad 100 a las rutas hacia sus propios servidores, así que todo el tráfico de los PoP conectados a la red troncal se fue a Atlanta. Atlanta se sobrecargó y los PoP afectados se quedaron casi sin tráfico que procesar. El servicio se recuperó al retirar el router de Atlanta de la red troncal. Cloudflare aclaró que la caída no tuvo relación con ningún ataque ni intrusión.
Si los jugadores de ciertas ciudades o regiones sufren todos a la vez desconexiones, o el juego no les conecta o se queda en carga infinita, y los demás van bien, hay que sospechar primero de un cambio reciente en la configuración de rutas. En el gráfico, la CPU y el tráfico se disparan en un solo PoP, mientras que los PoP afectados caen casi a 0. El responsable principal es el equipo de infraestructura (red); si la caída es del lado del proveedor, es externo. Cloudflare decidió fijar un tope de rutas aceptadas (maximum-prefix) en las sesiones BGP de la red troncal y ajustó las prioridades para que un PoP no pueda atraer el tráfico de los demás. Publicación original
Muchos juegos distribuyen archivos de parche, launchers y páginas web a través de una CDN, así que este es un tipo de caída de infraestructura que también afecta a los juegos. El 8 de junio de 2021, a partir de las 09:47 (UTC), el 85% de la red de Fastly empezó a devolver errores. En 49 minutos, el 95% de la red volvió a la normalidad, y el incidente quedó resuelto a las 12:35. Un despliegue de software iniciado el 12 de mayo contenía un bug que se activaba cuando una configuración concreta de un cliente cumplía ciertas condiciones. El 8 de junio, un cliente publicó un cambio de configuración válido que cumplía justo esas condiciones. Fastly detectó la anomalía en 1 minuto, y la recuperación empezó cuando localizó y desactivó la configuración del cliente que la había provocado. El despliegue de la corrección del bug empezó ese mismo día a las 17:25.
Un código desplegado semanas antes puede provocar en un instante una caída mundial cuando se encuentra con una condición poco frecuente. Del lado del juego, las señales que revisar son una subida simultánea en todas las regiones de la tasa de errores HTTP de las solicitudes de parches, launcher y web, y la página de estado del proveedor de CDN. Lo característico es que las conexiones de juego ya establecidas siguen bien si no pasan por la CDN, y solo quedan bloqueadas las conexiones nuevas, las descargas de parches y los inicios de sesión web. El responsable principal es externo (el proveedor de CDN); el equipo de desarrollo y el de infraestructura deben tener preparada una ruta alternativa, como usar más de una CDN o descargar directamente del servidor de origen. Publicación original
Es una caída de infraestructura cuyas lecciones se aplican tal cual a la red y el DNS propios de una empresa de juegos. El 4 de octubre de 2021, los servicios de Facebook (hoy Meta) quedaron inaccesibles en todo el mundo. La red troncal que une sus centros de datos se cortó por completo, y desde internet ya no se podían encontrar los servidores DNS de Facebook. La retrospectiva no indica cuánto duró la caída. Durante un trabajo de mantenimiento rutinario, un comando lanzado para evaluar la capacidad de la red troncal global cortó por error todas las conexiones de la red troncal, y la herramienta de auditoría que debía bloquear ese tipo de comandos no lo hizo por un bug. Los servidores DNS de los PoP pequeños están diseñados para marcarse como en mal estado y retirar sus anuncios BGP cuando no pueden comunicarse con los centros de datos, así que quedaron inalcanzables desde internet aunque seguían funcionando. Se cortaron tanto las vías de acceso habituales como el acceso fuera de banda (out-of-band), y las herramientas internas también perdieron el DNS, por lo que hubo que enviar ingenieros en persona a los centros de datos, y los procedimientos de seguridad alargaron aún más el proceso. En la recuperación, como el consumo eléctrico de cada centro de datos había bajado decenas de MW, se consideró que restablecerlo todo de golpe podía poner en riesgo desde las instalaciones eléctricas hasta las cachés, y la carga se subió por etapas.
Si en todas las regiones y con todos los ISP el juego deja de conectar o se queda en carga infinita a la vez, hay que mirar el DNS y las rutas BGP antes que los servidores del juego. Se puede comprobar desde fuera de la empresa con consultas a DNS externos y con la información pública de rutas BGP. El responsable principal es el equipo de infraestructura (red). Conviene verificar de antemano que la vía de acceso fuera de banda y las herramientas internas que se usarán durante una caída no dependen del mismo DNS ni de la misma red, y en la recuperación hay que subir la carga por etapas para que las reconexiones no lleguen todas de golpe. Publicación original
Muchos juegos tienen sus servidores, su inicio de sesión y sus datos en nubes públicas, así que este es un tipo de caída de infraestructura que también afecta a los juegos. El 7 de diciembre de 2021, a las 7:30 a. m. (hora estándar del Pacífico), la red interna de la región del norte de Virginia (us-east-1) se congestionó. Desde las 7:33 a. m. aumentaron los errores y la latencia de la API de EC2, y costaba lanzar instancias nuevas (el lanzamiento de instancias se recuperó a las 2:40 p. m.); después vinieron fallos de inicio de sesión en la consola, la imposibilidad de cambiar la configuración de Route 53, y retrasos y pérdidas parciales de métricas de CloudWatch. Los dispositivos de red se recuperaron por completo a las 2:22 p. m. Las instancias EC2 que ya estaban en marcha y las respuestas DNS existentes no se vieron afectadas. Una tarea automática para ampliar la capacidad de un servicio de la red principal provocó un comportamiento inesperado en una gran cantidad de clientes de la red interna, y los intentos de conexión se dispararon. Los dispositivos que unen la red interna con la red principal se saturaron y la comunicación se retrasó; a su vez, los retrasos aumentaron los intentos de conexión y los reintentos, y la congestión se mantuvo. Los clientes tenían un comportamiento de backoff que espacia las solicitudes en situaciones de congestión como esta, pero un defecto latente impidió que funcionara bien. El monitoreo interno también dependía de esa misma red, así que el equipo de operaciones tuvo que responder apoyándose en logs, sin métricas en tiempo real.
Si los reintentos no espacian sus intervalos, una congestión breve se convierte en una caída de varias horas. Desde el punto de vista del juego, aunque los servidores de juego ya en marcha sigan bien, pueden bloquearse a la vez el aumento de servidores (autoescalado), el inicio de sesión, el matchmaking y los pagos que usan la API de la nube, y el monitoreo. Señales que revisar: la página de estado del proveedor de nube, la tasa de errores de la API de la nube y los fallos al lanzar instancias. El responsable principal es externo (el proveedor de nube); el equipo de desarrollo debe aplicar a todos los reintentos un backoff exponencial con intervalos aleatorios y un límite de intentos, y el equipo de infraestructura debe preparar capacidad de reserva para aguantar aunque no se pueda escalar, además de una alternativa en otra región. Publicación original
Es la caída de un resolver de DNS público que los jugadores configuran por su cuenta en su dispositivo o router, un tipo de incidente que bloquea a la vez todos los juegos y servicios, pero solo para quienes usan esa configuración. El 14 de julio de 2025, durante 62 minutos, de 21:52 a 22:54 (UTC), el resolver 1.1.1.1 dejó de responder en todo el mundo. Cloudflare indicó que, para mucha gente, eso significó no poder usar prácticamente ningún servicio de internet. Se vieron afectadas las consultas por UDP, TCP y DNS over TLS, mientras que DNS over HTTPS, que se conecta por nombre de dominio, se mantuvo relativamente estable. El 6 de junio, al preparar la topología de servicio (la configuración que decide desde qué PoP se anuncia cada rango de IP) de otro servicio que se usaría en el futuro, los rangos de IP del resolver 1.1.1.1 quedaron incluidos por error en esa configuración. El 14 de julio, al cambiar la configuración de ese servicio, los PoP que anunciaban los rangos del resolver pasaron de ser todos a uno solo, que estaba fuera de línea, y las rutas BGP se retiraron en todo el mundo. Este cambio no pasó por un despliegue canario y se propagó directamente a todos los centros de datos. Al revertir la configuración a las 22:20, el tráfico volvió a cerca del 77%, pero entretanto se había borrado una configuración de IP necesaria en cerca del 23% de los servidores edge, y como hubo que volver a configurarla, la normalidad no llegó hasta las 22:54. Cloudflare indicó que fue un error de configuración interno, sin relación con ningún ataque ni secuestro de BGP (BGP hijacking).
Si los servidores del juego y los demás jugadores van bien, pero algunos jugadores no consiguen conectar con los servidores de login o de parches o se quedan en carga infinita, hay que sospechar del DNS que usan esos jugadores. Lo característico es que las sesiones ya conectadas se mantienen y solo fallan las conexiones nuevas. Si se les pide que cambien su configuración de DNS o que resuelvan directamente la dirección del servidor, se distingue enseguida. El responsable principal es externo (el operador del DNS o el ISP); si el equipo de desarrollo (cliente) informa de los fallos de resolución de nombres por separado de los demás errores, atención al cliente puede diagnosticarlo de inmediato. Publicación original
Muchos juegos tienen sus servidores, su inicio de sesión y sus datos en nubes públicas, así que este es un tipo de caída de infraestructura que también afecta a los juegos. Desde las 11:48 p. m. del 19 de octubre de 2025 hasta las 2:20 p. m. del día 20 (hora de verano del Pacífico), la región del norte de Virginia sufrió un impacto en tres fases. Hasta las 2:40 a. m. del día 20 aumentaron los errores de la API de DynamoDB; de 2:25 a. m. a 10:36 a. m. falló el lanzamiento de nuevas instancias EC2 (los problemas de conectividad de algunas instancias nuevas se resolvieron a la 1:50 p. m.), y de 5:30 a. m. a 2:09 p. m. aumentaron los errores de conexión en algunos Network Load Balancer (NLB). La automatización que gestiona el DNS de DynamoDB tenía una condición de carrera (race condition) latente. Entre los ejecutores que aplican los planes de DNS en distintas zonas de disponibilidad (DNS Enactor), uno que se había retrasado de forma inusual sobrescribió un plan nuevo con otro antiguo; justo después, la tarea de limpieza de otro ejecutor borró ese plan antiguo, y el registro DNS del endpoint regional (dynamodb.us-east-1.amazonaws.com) quedó vacío. La automatización no pudo corregirlo y hubo que restaurarlo a mano. El sistema de gestión de servidores físicos de EC2 dependía de DynamoDB, así que, mientras tanto, expiraron las concesiones (leases) que mantenía con cada servidor físico. Cuando DynamoDB volvió, había tantos servidores físicos que las tareas para restablecer las concesiones agotaban el tiempo antes de terminar, los reintentos volvían a acumularse y el sistema entró en un estado de “colapso por congestión” (congestive collapse). La configuración de red de las instancias recién lanzadas se propagaba con retraso, así que los health checks de NLB alternaban entre éxito y fallo, y hasta los nodos sanos salían del DNS y volvían a entrar una y otra vez.
Un error en un registro DNS de un solo lugar se extiende a los demás servicios que dependen de ese servicio, y aun después de resolver la causa, el trabajo acumulado y la inestabilidad de los health checks alargan la recuperación varias horas más. Desde el punto de vista del juego, los servidores ya en marcha pueden aguantar, pero no se pueden lanzar servidores nuevos y el autoescalado se detiene; además, si los health checks oscilan, el balanceador de carga puede sacar servidores que están bien. Señales que revisar: la página de estado de la nube, la tasa de errores de las API de servicios gestionados, los fallos al lanzar instancias y el número de destinos en buen estado del balanceador de carga. El responsable principal es externo (el proveedor de nube); el equipo de infraestructura debe limitar cuántos servidores pueden salir a la vez por fallos de health check y preparar una alternativa en otra región. Publicación original
Lo que más tiempo les lleva a los equipos de desarrollo e infraestructura al buscar la causa es averiguar “cuándo, dónde y a quién”. Si rellenas los campos de abajo, podrán encontrar ese momento enseguida en los logs y los gráficos.
Términos que aparecen a menudo al hablar con los equipos de desarrollo e infraestructura. Escribe en el buscador en español o en inglés.
Son la base de las cifras, los valores predeterminados y las descripciones de comportamiento de este libro blanco. Solo se han reunido fuentes confiables: documentos de estándares (RFC), documentación del kernel y de los SO, documentación oficial de nubes, motores y bases de datos, y ponencias y artículos. Las “Fuentes” de las fichas de causa y del final de cada capítulo enlazan con los mismos materiales. Los valores predeterminados pueden cambiar con cada versión, así que antes de aplicar algo, revisa la documentación de la versión que uses.
616 documentos de 83 editores. La lista completa está en la bibliografía de la versión de texto.