# Libro blanco del lag en juegos (Game Lag White Paper)

> Libro blanco que explica las 228 causas del lag en juegos online (tirones, teletransporte, rubber banding, cámara rápida, input lag, congelamiento, desconexión, etc.), desde tu pantalla hasta la base de datos del servidor, organizadas en 13 capas y 3 temas (diseño del netcode, problemas que solo afectan a algunos y retransmisión TCP). Está escrito a partir de casos de MMO, pero casi todo se aplica a cualquier juego online, sea del género que sea. Para cada causa incluye tres pasos (por qué → efecto → en pantalla), los síntomas relacionados, cifras de referencia, el responsable de solucionarla (equipo de desarrollo, equipo de infraestructura o externo) con las tareas de cada equipo, la forma del gráfico y cómo verificarla, y fuentes confiables (RFC, documentación oficial de kernel, SO, nube, motores y BD, y artículos académicos).

Cada causa se identifica por su ID (p. ej., mem-gc) y tiene su propia página (p. ej., https://jungrok5.github.io/mmo-lag-anatomy/es/c/mem-gc.html). Las cifras son valores típicos de un servicio en condiciones habituales; los valores por defecto y las versiones están respaldados por las fuentes de cada página de causa. Para citar, usa la dirección de la página de la causa. Licencia MIT. El original está en coreano y esta versión es una traducción: https://jungrok5.github.io/mmo-lag-anatomy/

## Documentos

- [Contenido completo (Markdown)](https://jungrok5.github.io/mmo-lag-anatomy/es/llms-full.txt): Todas las causas, síntomas, responsables, términos y fuentes en un solo archivo
- [Versión de texto](https://jungrok5.github.io/mmo-lag-anatomy/es/text.html): HTML con el mismo contenido en una sola página, sin JavaScript
- [Libro blanco del lag en juegos](https://jungrok5.github.io/mmo-lag-anatomy/es/): Versión original con gráficos y simulaciones interactivas

## Causas por síntoma

- [Tirones](https://jungrok5.github.io/mmo-lag-anatomy/es/s/stutter.html): Causas: 60. El movimiento pierde fluidez: se para un instante y sigue, una y otra vez.
- [Teletransporte](https://jungrok5.github.io/mmo-lag-anatomy/es/s/teleport.html): Causas: 47. Un personaje pasa de golpe a una posición lejana sin recorrer el camino.
- [Rubber banding](https://jungrok5.github.io/mmo-lag-anatomy/es/s/rubber.html): Causas: 14. Tu personaje avanza y de pronto vuelve arrastrado al punto por el que acaba de pasar.
- [Cámara rápida](https://jungrok5.github.io/mmo-lag-anatomy/es/s/burst.html): Causas: 36. Cuando la pantalla detenida vuelve a moverse, los movimientos, golpes y daños acumulados pasan todos juntos a toda velocidad.
- [Cámara lenta](https://jungrok5.github.io/mmo-lag-anatomy/es/s/slowmo.html): Causas: 24. 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.
- [Input lag](https://jungrok5.github.io/mmo-lag-anatomy/es/s/delay.html): Causas: 76. Pasa un tiempo desde que presionas hasta que ves el resultado. La imagen en sí puede verse fluida.
- [Congelamiento](https://jungrok5.github.io/mmo-lag-anatomy/es/s/freeze.html): Causas: 67. Todo lo que hay en pantalla se detiene un momento (de 0.5 s a varios segundos) y luego vuelve a moverse.
- [Acción perdida / rollback](https://jungrok5.github.io/mmo-lag-anatomy/es/s/dropped.html): Causas: 36. Una acción que hiciste claramente se anula como si nunca hubiera pasado, o el resultado se revierte mucho después.
- [Desconexión](https://jungrok5.github.io/mmo-lag-anatomy/es/s/disconnect.html): Causas: 51. 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 conecta / carga infinita](https://jungrok5.github.io/mmo-lag-anatomy/es/s/noconnect.html): Causas: 45. No logras entrar al juego, o te quedas detenido en la pantalla de carga o de entrada.
- [Entidades invisibles / fantasma](https://jungrok5.github.io/mmo-lag-anatomy/es/s/invisible.html): Causas: 20. 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.

## L1 Proceso del juego en el cliente

- [Pico de frametime](https://jungrok5.github.io/mmo-lag-anatomy/es/c/cg-hitch.html): Calcular un frame tarda varias veces más de lo normal y la imagen se detiene un instante.
- [Recolección de basura (GC) en el cliente](https://jungrok5.github.io/mmo-lag-anatomy/es/c/cg-gc.html): El juego entero se detiene mientras se recupera la memoria ya usada y desechada (basura). Lo característico son tirones a intervalos regulares.
- [Carga síncrona y compilación de shaders en el hilo principal](https://jungrok5.github.io/mmo-lag-anatomy/es/c/cg-sync-load.html): El juego se detiene para leer archivos y crear shaders justo antes de dibujar zonas, monstruos o efectos que aparecen por primera vez.
- [Almacenamiento lento que retrasa el streaming de assets](https://jungrok5.github.io/mmo-lag-anatomy/es/c/cg-asset-stream.html): 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.
- [Carga de renderizado de multitudes](https://jungrok5.github.io/mmo-lag-anatomy/es/c/cg-crowd.html): Cuando cientos de jugadores entran en la misma pantalla, como en un asedio o un world boss, el costo de dibujarlos se vuelve inasumible.
- [Cuello de botella al procesar paquetes en el hilo principal](https://jungrok5.github.io/mmo-lag-anatomy/es/c/cg-net-mainthread.html): 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.
- [Búfer de interpolación ausente o demasiado corto](https://jungrok5.github.io/mmo-lag-anatomy/es/c/cg-no-buffer.html): 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.
- [Extrapolación excesiva (dead reckoning)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/cg-extrap.html): 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.
- [Error de predicción en el cliente](https://jungrok5.github.io/mmo-lag-anatomy/es/c/cg-predict.html): 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.
- [Espiral de recuperación con timestep fijo](https://jungrok5.github.io/mmo-lag-anatomy/es/c/cg-fixed-step.html): Tras una pausa, el juego intenta recuperar de golpe los cálculos atrasados, y esos mismos cálculos lo vuelven a retrasar.
- [Error de sincronización del reloj](https://jungrok5.github.io/mmo-lag-anatomy/es/c/cg-clock.html): 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.
- [Pérdida de precisión del tiempo en float](https://jungrok5.github.io/mmo-lag-anatomy/es/c/cg-float-time.html): 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.
- [V-Sync y cola de renderizado](https://jungrok5.github.io/mmo-lag-anatomy/es/c/cg-vsync.html): 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.
- [Fuga de memoria en el cliente](https://jungrok5.github.io/mmo-lag-anatomy/es/c/cg-leak.html): 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.
- [Crash del cliente](https://jungrok5.github.io/mmo-lag-anatomy/es/c/cg-crash.html): Un error no controlado cierra el juego. El jugador lo percibe como una desconexión, pero el servidor está bien.
- [Escaneos del módulo anti-cheat](https://jungrok5.github.io/mmo-lag-anatomy/es/c/cg-anticheat.html): 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.

## L2 SO y dispositivo del cliente

- [Procesos en segundo plano que ocupan la CPU](https://jungrok5.github.io/mmo-lag-anatomy/es/c/co-background.html): 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.
- [Ahorro de energía y thermal throttling](https://jungrok5.github.io/mmo-lag-anatomy/es/c/co-power.html): 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.
- [Resolución del temporizador](https://jungrok5.github.io/mmo-lag-anatomy/es/c/co-timer.html): 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.
- [Aplicación móvil enviada a segundo plano](https://jungrok5.github.io/mmo-lag-anatomy/es/c/co-mobile-bg.html): 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.
- [Cambio Wi-Fi ↔ LTE/5G](https://jungrok5.github.io/mmo-lag-anatomy/es/c/co-netswitch.html): 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.
- [Inspección de paquetes del software de seguridad](https://jungrok5.github.io/mmo-lag-anatomy/es/c/co-security.html): 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.
- [Desbordamiento del búfer de recepción](https://jungrok5.github.io/mmo-lag-anatomy/es/c/co-rcvbuf.html): 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.
- [Falta de memoria y swap en el cliente](https://jungrok5.github.io/mmo-lag-anatomy/es/c/co-swap.html): Con decenas de pestañas del navegador abiertas junto al juego, el SO saca a disco parte de la memoria del juego.
- [Falta de memoria gráfica (VRAM)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/co-vram.html): 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.
- [Escaneo de Wi-Fi en segundo plano](https://jungrok5.github.io/mmo-lag-anatomy/es/c/co-wifi-scan.html): Mientras el SO salta periódicamente de canal en canal para buscar redes Wi-Fi cercanas, la comunicación se detiene un instante.
- [Ahorro de energía y drivers de la NIC](https://jungrok5.github.io/mmo-lag-anatomy/es/c/co-driver.html): 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.
- [Otras apps del dispositivo que ocupan el ancho de banda](https://jungrok5.github.io/mmo-lag-anatomy/es/c/co-other-apps.html): 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.
- [Procesamiento limitado con la ventana minimizada o sin foco](https://jungrok5.github.io/mmo-lag-anatomy/es/c/co-unfocused.html): 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ó.
- [Interferencias de programas de overlay](https://jungrok5.github.io/mmo-lag-anatomy/es/c/co-overlay.html): 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.
- [Latencia de pantalla, dispositivos de entrada y generación de frames](https://jungrok5.github.io/mmo-lag-anatomy/es/c/co-display-input.html): 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.

## L3 Red doméstica

- [Interferencias y señal débil en el Wi-Fi](https://jungrok5.github.io/mmo-lag-anatomy/es/c/hn-wifi.html): 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.
- [Canal Wi-Fi saturado](https://jungrok5.github.io/mmo-lag-anatomy/es/c/hn-channel.html): En sitios con decenas de routers, como un edificio de apartamentos, hay que compartir el mismo canal y esperar turno para transmitir.
- [Bufferbloat (cola del router)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/hn-bufferbloat.html): 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.
- [Expiración del mapeo NAT](https://jungrok5.github.io/mmo-lag-anatomy/es/c/hn-nat.html): 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.
- [Router poco potente o sobrecalentado](https://jungrok5.github.io/mmo-lag-anatomy/es/c/hn-router.html): Cuando un router barato tiene decenas de dispositivos y miles de conexiones, el propio router no da abasto.
- [Handover entre estaciones base (en movimiento)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/hn-handover.html): Al viajar en autobús o en metro, la comunicación se corta mientras el teléfono cambia de estación base.
- [Retraso en el cambio de estado RRC (ahorro de energía de la radio móvil)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/hn-rrc.html): 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.
- [Señal móvil débil y zonas sin cobertura](https://jungrok5.github.io/mmo-lag-anatomy/es/c/hn-weak-cell.html): En ascensores, sótanos o el interior de los edificios aumentan las retransmisiones, baja la velocidad y al final se cae la conexión.
- [Cambios frecuentes 5G↔LTE (en el límite de la cobertura 5G)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/hn-5g-flip.html): 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.
- [Restricciones en Wi-Fi público y redes corporativas](https://jungrok5.github.io/mmo-lag-anatomy/es/c/hn-captive.html): 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.

## L4 Ruta por internet

- [Retardo de propagación (distancia física)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/isp-distance.html): 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.
- [Internet satelital (órbita baja y geoestacionaria)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/isp-satellite.html): 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.
- [Enrutamiento con rodeos](https://jungrok5.github.io/mmo-lag-anatomy/es/c/isp-routing.html): Por los acuerdos de interconexión entre ISP, el tráfico hacia un servidor cercano puede dar un rodeo por un lugar lejano.
- [Congestión del peering en horas pico](https://jungrok5.github.io/mmo-lag-anatomy/es/c/isp-peak.html): 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.
- [Fallos en cables submarinos y enlaces internacionales](https://jungrok5.github.io/mmo-lag-anatomy/es/c/isp-cable.html): 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.
- [Cambios de ruta BGP y convergencia](https://jungrok5.github.io/mmo-lag-anatomy/es/c/isp-bgp.html): 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.
- [Una ruta ECMP defectuosa](https://jungrok5.github.io/mmo-lag-anatomy/es/c/isp-ecmp.html): 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.
- [Limitación de velocidad y gestión del tráfico del ISP](https://jungrok5.github.io/mmo-lag-anatomy/es/c/isp-shaping.html): 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.
- [Restricciones de UDP e inspección de paquetes por país o ISP](https://jungrok5.github.io/mmo-lag-anatomy/es/c/isp-udp-block.html): 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.
- [Mala calidad de la conexión](https://jungrok5.github.io/mmo-lag-anatomy/es/c/isp-line.html): 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.
- [Fallos y lentitud del DNS](https://jungrok5.github.io/mmo-lag-anatomy/es/c/isp-dns.html): 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.
- [Enlaces compartidos saturados por un DDoS](https://jungrok5.github.io/mmo-lag-anatomy/es/c/isp-ddos-path.html): Un ataque masivo dirigido a la empresa del juego, o a otro destino de la misma red, llena los enlaces compartidos.
- [IP compartida del ISP (CGNAT)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/isp-cgnat.html): 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.
- [Paso por una VPN o un acelerador de juegos](https://jungrok5.github.io/mmo-lag-anatomy/es/c/isp-vpn.html): 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.

## L5 Equipos de red del centro de datos

- [Tabla de sesiones del firewall llena](https://jungrok5.github.io/mmo-lag-anatomy/es/c/dc-firewall.html): 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.
- [Desvío por la protección DDoS y falsos positivos](https://jungrok5.github.io/mmo-lag-anatomy/es/c/dc-ddos.html): 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.
- [Timeout por inactividad del balanceador de carga](https://jungrok5.github.io/mmo-lag-anatomy/es/c/dc-lb-idle.html): 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.
- [Expiración del seguimiento de conexiones en grupos de seguridad de la nube](https://jungrok5.github.io/mmo-lag-anatomy/es/c/dc-cloud-conntrack.html): 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.
- [Límites de conexiones y puertos del gateway NAT en la nube](https://jungrok5.github.io/mmo-lag-anatomy/es/c/dc-nat-gateway.html): 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.
- [Desbalance del balanceador de carga y health checks erróneos](https://jungrok5.github.io/mmo-lag-anatomy/es/c/dc-lb-imbalance.html): Las conexiones se concentran en un solo servidor, o se sigue enviando gente a un servidor que ya está caído.
- [Microrráfagas en el switch](https://jungrok5.github.io/mmo-lag-anatomy/es/c/dc-microburst.html): 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.
- [Saturación del enlace del centro de datos](https://jungrok5.github.io/mmo-lag-anatomy/es/c/dc-uplink.html): 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.
- [Failover de equipos de red](https://jungrok5.github.io/mmo-lag-anatomy/es/c/dc-failover.html): Cuando falla un router o un firewall y el tráfico pasa al dispositivo de reserva (failover), todos se quedan congelados durante unos segundos.
- [Cables defectuosos y errores de puerto](https://jungrok5.github.io/mmo-lag-anatomy/es/c/dc-bad-cable.html): Si un transceptor óptico o un cable está defectuoso, se corrompe una proporción constante de los paquetes que pasan por esa ruta.
- [Desajuste de MTU (solo desaparecen los paquetes grandes)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/dc-mtu.html): 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.

## L6 Tarjeta de red del servidor

- [Interrupciones de la NIC concentradas en un solo núcleo](https://jungrok5.github.io/mmo-lag-anatomy/es/c/nic-irq.html): 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.
- [Búfer circular (ring buffer) insuficiente](https://jungrok5.github.io/mmo-lag-anatomy/es/c/nic-ring.html): 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.
- [Coalescencia de interrupciones excesiva](https://jungrok5.github.io/mmo-lag-anatomy/es/c/nic-coalesce.html): 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.
- [Límite de PPS de la nube superado](https://jungrok5.github.io/mmo-lag-anatomy/es/c/nic-cloud-pps.html): 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.
- [Saturación del ancho de banda de la NIC](https://jungrok5.github.io/mmo-lag-anatomy/es/c/nic-saturate.html): 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.
- [Sobrecarga de virtualización y vecino ruidoso](https://jungrok5.github.io/mmo-lag-anatomy/es/c/nic-noisy.html): 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.
- [Mantenimiento del host en la nube y migración en vivo](https://jungrok5.github.io/mmo-lag-anatomy/es/c/nic-host-maintenance.html): 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.
- [Problemas de driver y firmware de la NIC](https://jungrok5.github.io/mmo-lag-anatomy/es/c/nic-reset.html): 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.
- [Retraso por agrupación en GRO/LRO](https://jungrok5.github.io/mmo-lag-anatomy/es/c/nic-offload.html): 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.

## L7 SO del servidor (kernel)

- [Desbordamiento de la cola de conexiones pendientes (backlog)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/so-backlog.html): 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.
- [Límite de descriptores de archivo](https://jungrok5.github.io/mmo-lag-anatomy/es/c/so-fd.html): 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.
- [Búferes de socket del kernel insuficientes](https://jungrok5.github.io/mmo-lag-anatomy/es/c/so-sockbuf.html): 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.
- [Exceso de hilos y cambios de contexto](https://jungrok5.github.io/mmo-lag-anatomy/es/c/so-context.html): Si se ejecutan muchos más hilos que núcleos, el SO gasta CPU solo en irlos turnando.
- [CPU steal (máquinas virtuales)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/so-steal.html): 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.
- [Throttling de CPU en contenedores (cuota de CFS)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/so-cpu-quota.html): 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).
- [Picos de latencia por la gestión de energía del servidor (C-states, escalado de frecuencia)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/so-cstate.html): 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.
- [OOM killer](https://jungrok5.github.io/mmo-lag-anatomy/es/c/so-oom.html): 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.
- [Pausas por recuperación y compactación de memoria](https://jungrok5.github.io/mmo-lag-anatomy/es/c/so-reclaim.html): Mientras el SO compacta la memoria para formar páginas grandes (huge pages) o recupera memoria libre, el proceso se detiene.
- [Salto del reloj del sistema (step de NTP)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/so-timejump.html): 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.
- [Tareas programadas](https://jungrok5.github.io/mmo-lag-anatomy/es/c/so-cron.html): 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.
- [Cambios de rendimiento tras actualizar el SO, el kernel, los drivers o el firmware](https://jungrok5.github.io/mmo-lag-anatomy/es/c/so-os-update.html): 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.
- [Tabla conntrack del servidor llena](https://jungrok5.github.io/mmo-lag-anatomy/es/c/so-conntrack.html): 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.
- [Agotamiento de puertos efímeros en conexiones entre servidores](https://jungrok5.github.io/mmo-lag-anatomy/es/c/so-ports.html): 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.

## L8 Sockets y protocolos

- [Bloqueo HOL en TCP](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sk-hol.html): 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.
- [RTO de TCP y backoff exponencial](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sk-rto.html): 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.
- [Algoritmo de Nagle + ACK retardado](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sk-nagle.html): 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.
- [Envíos bloqueantes por clientes lentos](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sk-block-send.html): 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.
- [Política para clientes lentos (slow consumer)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sk-slow-client.html): Cuando a un cliente se le siguen acumulando datos pendientes de envío, el servidor descarta las actualizaciones viejas o corta la conexión.
- [Keepalive con valor predeterminado de 2 horas](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sk-keepalive.html): 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.
- [Fragmentación IP de paquetes UDP](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sk-fragment.html): 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.
- [Configuración de retransmisión del UDP confiable](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sk-reliable-udp.html): 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.
- [Slow start tras inactividad](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sk-slowstart.html): 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.
- [Caída brusca del ritmo de envío por el control de congestión](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sk-congestion.html): 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.
- [Pérdida de los últimos datos por un cierre forzado con RST](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sk-linger.html): Si el servidor corta una conexión de forma brusca, se pierden el último aviso o la confirmación de guardado que envió.
- [Modelo de E/S bloqueante](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sk-blocking-io.html): 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.
- [Reparto desigual con SO_REUSEPORT](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sk-reuseport.html): 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.
- [Error WSAECONNRESET en sockets UDP de Windows](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sk-udp-connreset.html): 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.

## L9 Proceso del juego en el servidor

- [Tick que excede su presupuesto](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sp-tick-overrun.html): 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.
- [Explosión del cálculo de visibilidad (AOI, N²)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sp-aoi.html): 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.
- [Explosión de broadcast](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sp-broadcast.html): 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.
- [Sobrecarga de una zona de un solo hilo (hotspot)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sp-hotzone.html): En un diseño con un hilo por zona, si la gente se concentra en un lugar, solo ese núcleo llega al 100%.
- [Contención de locks](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sp-lock.html): 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.
- [Deadlock](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sp-deadlock.html): Si dos hilos esperan cada uno el lock que tiene el otro, se quedan detenidos para siempre.
- [Llamadas síncronas en el hilo del juego](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sp-sync-call.html): 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.
- [Acumulación en la cola de mensajes](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sp-queue.html): 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.
- [Temporizadores que se disparan todos a la vez](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sp-timer-burst.html): 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.
- [Avalancha de pathfinding](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sp-pathfinding.html): Si cientos de monstruos persiguen a la vez a los jugadores calculando rutas, se consume mucha CPU.
- [Costo de serialización y compresión](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sp-serialize.html): Convertir a bytes y comprimir los datos que se van a enviar también consume CPU, y con mucha gente este costo se dispara.
- [Crash del servidor](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sp-crash.html): Si el proceso del servidor muere por un error no controlado, todos los jugadores de ese servidor se desconectan a la vez.
- [Agotamiento del pool de hilos](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sp-threadpool.html): Si todos los hilos de trabajo que procesan tareas quedan atados a trabajos lentos, las solicitudes nuevas esperan indefinidamente.
- [Bucles infinitos y lógica desbocada](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sp-infinite-loop.html): Si por un bug un tick no termina nunca, el servidor se detiene y el watchdog lo reinicia a la fuerza.
- [Combate concentrado en un solo objetivo (world boss)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sp-hot-entity.html): 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.
- [Avalancha de spawns al entrar en una zona concurrida](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sp-spawn-burst.html): 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.
- [Acumulación de entidades (objetos e invocaciones sin limpiar)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sp-entity-buildup.html): 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.
- [Cambio del patrón de tráfico tras un parche](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sp-patch-traffic.html): 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.

## L10 Memoria

- [Pausa stop-the-world del GC en el servidor](https://jungrok5.github.io/mmo-lag-anatomy/es/c/mem-gc.html): 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.
- [Pausa del GC en el motor de scripts](https://jungrok5.github.io/mmo-lag-anatomy/es/c/mem-script-gc.html): 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.
- [Avalancha de asignaciones](https://jungrok5.github.io/mmo-lag-anatomy/es/c/mem-alloc.html): Si durante un evento se crean muchísimos objetos temporales, el GC se ejecuta mucho más a menudo que de costumbre.
- [Fuga de memoria](https://jungrok5.github.io/mmo-lag-anatomy/es/c/mem-leak.html): 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.
- [Thrashing del GC (heap casi lleno)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/mem-gc-thrash.html): Cuando los datos vivos se acercan al límite del heap, el GC casi no encuentra nada que liberar y se repite sin parar.
- [Swap](https://jungrok5.github.io/mmo-lag-anatomy/es/c/mem-swap.html): 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.
- [Fallo de caché](https://jungrok5.github.io/mmo-lag-anatomy/es/c/mem-cache-miss.html): Si los datos están dispersos por la memoria, la CPU tiene que ir cada vez hasta la RAM, que es lenta, y esperar.
- [Fragmentación de memoria](https://jungrok5.github.io/mmo-lag-anatomy/es/c/mem-fragment.html): 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.
- [Acceso a memoria NUMA remota](https://jungrok5.github.io/mmo-lag-anatomy/es/c/mem-numa.html): 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.

## L11 Disco

- [Escritura síncrona de logs](https://jungrok5.github.io/mmo-lag-anatomy/es/c/dk-sync-log.html): 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.
- [Avalancha de fsync](https://jungrok5.github.io/mmo-lag-anatomy/es/c/dk-fsync.html): 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.
- [Agotamiento de los créditos de ráfaga del disco en la nube](https://jungrok5.github.io/mmo-lag-anatomy/es/c/dk-burst.html): 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.
- [Límite de IOPS y saturación de la cola](https://jungrok5.github.io/mmo-lag-anatomy/es/c/dk-iops.html): Cuando se supera el número de solicitudes por segundo que el disco puede procesar, la cola se alarga y la latencia se dispara.
- [Disco lleno](https://jungrok5.github.io/mmo-lag-anatomy/es/c/dk-full.html): 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.
- [Copias de seguridad, compresión y escaneos](https://jungrok5.github.io/mmo-lag-anatomy/es/c/dk-backup.html): 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.
- [Carga diferida (lazy loading) en el servidor](https://jungrok5.github.io/mmo-lag-anatomy/es/c/dk-lazy-load.html): 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.
- [Escritura de core dumps](https://jungrok5.github.io/mmo-lag-anatomy/es/c/dk-coredump.html): Cuando el servidor se cae, escribe en disco varios GB de memoria, y eso puede retrasar el reinicio varios minutos.
- [Latencia de búsqueda (seek) en HDD](https://jungrok5.github.io/mmo-lag-anatomy/es/c/dk-hdd.html): 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.

## L12 Base de datos

- [Consultas sin índice](https://jungrok5.github.io/mmo-lag-anatomy/es/c/db-no-index.html): Sin índice, encontrar las filas que cumplen una condición obliga a leer la tabla entera (escaneo completo).
- [Contención de bloqueos en una fila caliente](https://jungrok5.github.io/mmo-lag-anatomy/es/c/db-hot-row.html): 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.
- [Deadlock en la BD](https://jungrok5.github.io/mmo-lag-anatomy/es/c/db-deadlock.html): 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.
- [Agotamiento del pool de conexiones](https://jungrok5.github.io/mmo-lag-anatomy/es/c/db-pool.html): 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.
- [Retraso de replicación](https://jungrok5.github.io/mmo-lag-anatomy/es/c/db-replica-lag.html): 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.
- [Checkpoint y volcado del log](https://jungrok5.github.io/mmo-lag-anatomy/es/c/db-checkpoint.html): Cuando la BD vuelca de golpe al disco, de forma periódica, los cambios que tiene en memoria, las consultas se ralentizan.
- [Caché fría (justo después de reiniciar)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/db-cold-cache.html): Al reiniciar la BD, su caché en memoria está vacía, y durante un tiempo todas las consultas leen del disco.
- [Avalancha de inicios de sesión y consultas N+1](https://jungrok5.github.io/mmo-lag-anatomy/es/c/db-login-storm.html): 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.
- [Procesos batch masivos](https://jungrok5.github.io/mmo-lag-anatomy/es/c/db-batch.html): Calcular rankings, enviar correo del juego en masa o limpiar datos antiguos con el servicio en marcha acapara bloqueos y disco.
- [Failover de la BD](https://jungrok5.github.io/mmo-lag-anatomy/es/c/db-failover.html): 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.
- [Pérdida de progreso por intervalos de guardado largos](https://jungrok5.github.io/mmo-lag-anatomy/es/c/db-save-interval.html): 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.
- [Estampida de caché](https://jungrok5.github.io/mmo-lag-anatomy/es/c/db-cache-stampede.html): Si la caché de unos datos populares caduca a la vez, miles de solicitudes se lanzan de golpe contra la BD.
- [Transacciones abiertas durante mucho tiempo](https://jungrok5.github.io/mmo-lag-anatomy/es/c/db-long-tx.html): 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.
- [Comandos lentos en Redis](https://jungrok5.github.io/mmo-lag-anatomy/es/c/db-redis-block.html): Redis procesa los comandos de uno en uno, así que un solo comando lento bloquea todas las solicitudes que vienen detrás.
- [Consultas lentas por un cambio en el plan de ejecución](https://jungrok5.github.io/mmo-lag-anatomy/es/c/db-plan-flip.html): 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.
- [Bloqueos por cambios de esquema (DDL) en producción](https://jungrok5.github.io/mmo-lag-anatomy/es/c/db-ddl-lock.html): 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.

## L13 Arquitectura y operación de servidores

- [Paso por un gateway o proxy](https://jungrok5.github.io/mmo-lag-anatomy/es/c/in-gateway.html): 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.
- [Cambio de zona (traspaso entre servidores)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/in-zone-transfer.html): Al entrar en otra zona o mazmorra, los datos del personaje se traspasan a otro servidor, y en ese proceso surgen retrasos y fallos.
- [Fallo en cascada](https://jungrok5.github.io/mmo-lag-anatomy/es/c/in-cascade.html): 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.
- [Caída de un servidor auxiliar](https://jungrok5.github.io/mmo-lag-anatomy/es/c/in-subservice.html): 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.
- [Despliegues y reinicios](https://jungrok5.github.io/mmo-lag-anatomy/es/c/in-deploy.html): 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.
- [Retraso del autoescalado](https://jungrok5.github.io/mmo-lag-anatomy/es/c/in-autoscale.html): Cuando se junta mucha gente, se añaden servidores automáticamente, pero prepararlos lleva unos minutos y mientras tanto los servidores existentes van sobrecargados.
- [Sobrecarga por logs y monitoreo](https://jungrok5.github.io/mmo-lag-anatomy/es/c/in-monitoring.html): 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.
- [Desfase de reloj entre servidores](https://jungrok5.github.io/mmo-lag-anatomy/es/c/in-clock-skew.html): Si cada servidor tiene un reloj un poco distinto, las comprobaciones de cooldowns, buffs y comienzos de evento no coinciden entre servidores.
- [Exceso de macros y bots](https://jungrok5.github.io/mmo-lag-anatomy/es/c/in-bots.html): Los bots envían solicitudes con mucha más frecuencia que una persona y acaparan la capacidad de procesamiento del servidor.
- [Dependencia de servicios externos](https://jungrok5.github.io/mmo-lag-anatomy/es/c/in-external.html): 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.
- [Errores de matchmaking y asignación de región](https://jungrok5.github.io/mmo-lag-anatomy/es/c/in-region-match.html): 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.
- [Certificado TLS expirado o mal configurado](https://jungrok5.github.io/mmo-lag-anatomy/es/c/in-cert.html): 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.
- [Tope de la cola de inicio de sesión y periodo de gracia para reconectar demasiado corto](https://jungrok5.github.io/mmo-lag-anatomy/es/c/in-login-queue.html): 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.

## Diseño del netcode

- [Feedback solo tras la respuesta del servidor (solicitud-respuesta)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sy-request-response.html): 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.
- [Protocolo con muchas idas y vueltas secuenciales (chatty)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sy-chatty.html): Si una sola acción necesita varias idas y vueltas al servidor en secuencia, el ping se multiplica por ese número.
- [Sin búfer de inputs para habilidades](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sy-no-queue.html): 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.
- [Ventanas de tiempo cortas que el ping consume](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sy-short-window.html): 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.
- [Registro de impactos sin compensación de lag](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sy-no-lagcomp.html): 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.
- [Compensación de lag excesiva](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sy-lagcomp-overreach.html): Si se rebobina demasiado a favor del atacante, a quien recibe el disparo le dan aunque ya se haya escondido.
- [Autoridad del cliente](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sy-client-auth.html): 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.
- [Espera al jugador más lento en lockstep](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sy-lockstep.html): En una arquitectura en la que todos calculan juntos el mismo turno, si el input de uno llega tarde, todos esperan.
- [Predicciones fallidas en el netcode de rollback](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sy-rollback.html): 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.
- [Reproducción al llegar, sin marcas de tiempo](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sy-no-timestamp.html): 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.
- [Doble espera de tick](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sy-double-tick.html): 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.
- [Validación del servidor demasiado estricta](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sy-strict-check.html): 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.
- [Arquitectura de anfitrión (host)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sy-host.html): Cuando la computadora de un jugador hace de servidor, su conexión y el rendimiento de su PC determinan lo que perciben todos.
- [Rechazo del servidor tras el feedback anticipado](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sy-optimistic-reject.html): Si el servidor no acepta después un golpe o una habilidad que tu pantalla ya mostró, lo que viste claramente queda anulado.
- [Discrepancias de pathfinding en la sincronización de comandos](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sy-path-mismatch.html): 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.
- [Tasa de envío de snapshots baja](https://jungrok5.github.io/mmo-lag-anatomy/es/c/sy-low-send-rate.html): 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.

## Problemas que solo afectan a algunos

- [Un jugador con lag se mueve a ráfagas en la pantalla de los demás](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-slow-burst.html): 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.
- [Cámara rápida en servidores que procesan cada paquete al llegar](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-event-server.html): 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.
- [Tamaño del búfer de inputs de cada jugador](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-input-buffer.html): 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.
- [Falsos positivos de validación concentrados en un ISP](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-isp-validation.html): 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.
- [Un miembro del grupo con lag y las mecánicas del jefe](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-raid-member.html): 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.
- [Un cliente lento controla al monstruo](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-mob-control.html): 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.
- [Personaje con datos sobredimensionados](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-heavy-char.html): 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.
- [Diferencias de canal, instancia o phasing](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-phase.html): 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.
- [Mensajes de aparición descartados durante la carga](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-loading-drop.html): 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.
- [Condición de carrera en el registro de visibilidad (AOI)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-aoi-race.html): 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.
- [Pérdida del snapshot de referencia (baseline)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-baseline.html): 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.
- [Pérdida del mensaje de desaparición (entidad fantasma)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-ghost.html): 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.
- [Pérdida de la ráfaga de mensajes de aparición al entrar](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-spawn-burst.html): 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.
- [Confusión por reutilización de IDs de entidad](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-id-reuse.html): 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.
- [Colisión de puertos UDP fijos](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-port-collision.html): 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.
- [Bug de sesiones identificadas por IP o dispositivo](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-session-key.html): 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.
- [Restricciones al multicliente](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-multiclient.html): 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.
- [Procesamiento limitado de las ventanas en segundo plano](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-background.html): 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.
- [Conflictos por acceso simultáneo a archivos de caché o assets](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-asset-lock.html): 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.
- [Fallo de streaming por falta de memoria o VRAM](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-vram.html): 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.
- [Opciones de visualización distintas](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-display-option.html): 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.
- [Desajuste de versión o datos del cliente](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-version.html): 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.
- [Presupuesto de envío y prioridad por conexión](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-priority.html): 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.
- [Entidades retenidas por errores en la estimación del reloj](https://jungrok5.github.io/mmo-lag-anatomy/es/c/pt-clock-hold.html): 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”.

## Causas raíz de la retransmisión TCP

- [Pérdida en el tramo inalámbrico](https://jungrok5.github.io/mmo-lag-anatomy/es/c/rt-wireless.html): 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.
- [Desbordamiento de la cola en el cuello de botella (pérdida por congestión)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/rt-queue-drop.html): 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.
- [Ráfagas de envío que desbordan búferes poco profundos](https://jungrok5.github.io/mmo-lag-anatomy/es/c/rt-burst.html): 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.
- [Descarte del exceso por un policer](https://jungrok5.github.io/mmo-lag-anatomy/es/c/rt-policer.html): 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.
- [Errores físicos (cables, transceptores ópticos o conectores defectuosos)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/rt-physical.html): 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.
- [Desajuste de dúplex](https://jungrok5.github.io/mmo-lag-anatomy/es/c/rt-duplex.html): 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.
- [Descarte de paquetes en el host del servidor receptor](https://jungrok5.github.io/mmo-lag-anatomy/es/c/rt-host-drop.html): 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.
- [Descartes del firewall o del seguimiento de conexiones](https://jungrok5.github.io/mmo-lag-anatomy/es/c/rt-stateful-fw.html): 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.
- [Límite de procesamiento superado en dispositivos intermedios (firewall, IPS, protección DDoS)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/rt-appliance-pps.html): 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.
- [Agujero negro de MTU (solo los paquetes grandes se pierden una y otra vez)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/rt-mtu.html): 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.
- [Expiración del mapeo NAT o del balanceador de carga en mitad de la conexión](https://jungrok5.github.io/mmo-lag-anatomy/es/c/rt-mapping.html): 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.
- [Cambio de ruta o ruta ECMP defectuosa](https://jungrok5.github.io/mmo-lag-anatomy/es/c/rt-path.html): 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.
- [Retransmisiones espurias por picos de latencia](https://jungrok5.github.io/mmo-lag-anatomy/es/c/rt-spurious-delay.html): 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.
- [Retransmisiones rápidas espurias por reordenamiento de paquetes](https://jungrok5.github.io/mmo-lag-anatomy/es/c/rt-reorder.html): 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.
- [ACK retrasados o perdidos (subida saturada)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/rt-ack-path.html): 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.
- [RTO mal ajustado al entorno](https://jungrok5.github.io/mmo-lag-anatomy/es/c/rt-rto-setting.html): 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.
- [Recuperación lenta en thin streams](https://jungrok5.github.io/mmo-lag-anatomy/es/c/rt-thin.html): 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.
- [Eliminación de opciones TCP en dispositivos intermedios](https://jungrok5.github.io/mmo-lag-anatomy/es/c/rt-sack-stripped.html): 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.
- [Ventana cero (una detención que parece retransmisión)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/rt-zero-window.html): 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.
- [Retransmisión de la solicitud de conexión (SYN)](https://jungrok5.github.io/mmo-lag-anatomy/es/c/rt-syn.html): 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.

## Diagnóstico y casos

- [Diagnosticar con datos de monitoreo](https://jungrok5.github.io/mmo-lag-anatomy/es/#judge): Flujo de diagnóstico alcance → momento → capa, tabla de señales, 13 formas de gráfico y cómo leer las cifras (media y p99)
- [Procedimientos por situación](https://jungrok5.github.io/mmo-lag-anatomy/es/text.html#playbooks): Lag tras un parche, lanzamiento en un nuevo país o región
- [Incidentes reales](https://jungrok5.github.io/mmo-lag-anatomy/es/text.html#cases): Postmortems publicados por los desarrolladores originales y los operadores, con sus causas relacionadas

## Otros idiomas

- [한국어 (Korean)](https://jungrok5.github.io/mmo-lag-anatomy/llms.txt)
- [English](https://jungrok5.github.io/mmo-lag-anatomy/en/llms.txt)
- [日本語 (Japanese)](https://jungrok5.github.io/mmo-lag-anatomy/ja/llms.txt)
- [简体中文 (Chinese (Simplified))](https://jungrok5.github.io/mmo-lag-anatomy/zh-cn/llms.txt)
- [繁體中文 (Chinese (Traditional, Taiwan))](https://jungrok5.github.io/mmo-lag-anatomy/zh-tw/llms.txt)
- [Deutsch (German)](https://jungrok5.github.io/mmo-lag-anatomy/de/llms.txt)
- [ไทย (Thai)](https://jungrok5.github.io/mmo-lag-anatomy/th/llms.txt)
- [Tiếng Việt (Vietnamese)](https://jungrok5.github.io/mmo-lag-anatomy/vi/llms.txt)
- [Русский (Russian)](https://jungrok5.github.io/mmo-lag-anatomy/ru/llms.txt)
- [Português (Brasil) (Portuguese (Brazil))](https://jungrok5.github.io/mmo-lag-anatomy/pt-br/llms.txt)
- [Bahasa Indonesia (Indonesian)](https://jungrok5.github.io/mmo-lag-anatomy/id/llms.txt)

## Optional

- [Repositorio en GitHub](https://github.com/jungrok5/mmo-lag-anatomy): Código fuente, formato de los datos y cómo contribuir
- [Autor: Jeongrok Oh](https://jungrok5.github.io/resume/en/): Currículum