Por qué la latencia importa en los servidores de juego y la experiencia del jugador

Lo que la latencia realmente le hace a un juego multijugador

La latencia es el retraso entre el momento en que un jugador hace algo y el momento en que el mundo del juego reacciona. Aprietas el gatillo, y transcurre un instante antes de que el servidor confirme el disparo, decida si acertaste, y le diga a los demás clientes qué ha pasado. Mantén ese margen pequeño y constante, y el juego se siente preciso: los disparos impactan donde apuntas, el movimiento es nítido, los demás jugadores se mueven con fluidez. Deja que crezca o fluctúe, y el mismo juego se siente blando, injusto o roto, aunque en realidad nada haya fallado en ninguna máquina.

Lo más útil de entender es que el ping no cuenta toda la historia. El ping mide un solo tramo del trayecto, el ida y vuelta de red. Lo que siente un jugador es una cadena más larga que también incluye la frecuencia con la que el servidor actualiza el mundo, cómo el cliente disimula el retraso, y si la conexión es estable o inestable. Un servidor puede mostrar un ping excelente y aun así sentirse fatal, y un servidor a dos mil kilómetros puede sentirse bien para el género adecuado.

Para un proveedor, la respuesta en una línea es breve: sitúa el servidor cerca de tus jugadores, en hardware que mantenga su tick rate bajo carga. Todo lo que sigue explica por qué esos dos factores dominan, y qué puedes y no puedes hacer con el resto.

Este artículo complementa nuestra guía sobre cómo alojar servidores de juego en bare metal y el análisis más profundo sobre el rendimiento de juego en bare metal frente a la virtualización. Aquí el enfoque es más concreto: de dónde viene el retraso, y cómo llega hasta el jugador.

La anatomía de un ida y vuelta

Cuando un jugador hace clic, el retraso que siente es la suma de varias etapas, de las cuales solo algunas son de red. Siguiendo una entrada desde el ratón hasta la pantalla:

1. Muestreo de la entrada. El cliente consulta el ratón y el teclado según su propio ciclo. Tu clic puede esperar uno o dos fotogramas antes de que el bucle del juego siquiera lo lea. A 120 fps eso son unos pocos milisegundos; a 30 fps son más de 30.
2. Envío del cliente. El cliente empaqueta la entrada y la envía. Los clientes también agrupan y envían según su propia cadencia, así que puede haber una breve espera antes de que el paquete salga.
3. Última milla. El paquete atraviesa la propia conexión del jugador: Wi-Fi, router doméstico, la red de acceso, hasta el primer salto real. Aquí es donde nace gran parte de la latencia del usuario doméstico, y la mayor parte del jitter.
4. Tránsito y peering. El paquete atraviesa una o varias redes hasta llegar a la del servidor. Lo directo que sea el trayecto depende del peering: una ruta bien conectada por peering entrega el tráfico en un punto de intercambio de internet en la misma región; una mala rodea primero por otro país.
5. Cola del servidor. El paquete llega y espera a que el proceso del juego lo lea.
6. Alineación con el tick. Esta es la etapa que se olvida. El servidor no actúa sobre tu entrada en el instante en que llega. Actúa en el siguiente tick de simulación. Si el servidor hace 20 ticks por segundo, tu entrada puede esperar hasta 50 ms hasta el siguiente tick antes de que le pase nada, sin importar lo rápida que fuera la red.
7. Procesamiento. El tick ejecuta la simulación: aplica tu entrada, resuelve los impactos, mueve las entidades y determina el nuevo estado del mundo. Si el servidor está sobrecargado y un tick tarda más de lo que su presupuesto permite, esta etapa se alarga y todos los jugadores lo sienten a la vez.
8. Trayecto de vuelta. El servidor envía de regreso el estado actualizado, y todo el trayecto de red se repite a la inversa antes de que tu pantalla muestre el resultado.

El ping mide, a grandes rasgos, las etapas tres, cuatro y ocho, y nada más. Por eso el ping es necesario pero no suficiente. Dos servidores con un ping idéntico de 30 ms pueden sentirse distintos porque las etapas uno, dos, seis y siete difieren. La alineación con el tick, en particular, es invisible para el ping y a menudo mayor que el retraso de red en un juego de tick rate bajo.

El tick rate y la latencia son dos relojes distintos

Un servidor simula el mundo en pasos discretos llamados ticks. El tick rate es cuántos de esos pasos se ejecutan por segundo, y fija la granularidad de todo lo que hace el servidor. Es un reloj distinto de la latencia de red, y hay que mantener ambos cortos.

La aritmética es simple. Minecraft ejecuta su mundo a 20 ticks por segundo, un tick cada 50 ms, según el propio modelo de tick del juego. Así que incluso en un servidor en el mismo edificio, una entrada de Minecraft puede esperar hasta 50 ms al siguiente tick, y el timing de la redstone está cuantizado en pasos de 50 ms. Eso no es lag causado por un mal proveedor; es el diseño del juego.

Los shooters competitivos van mucho más rápido porque necesitan un timing más fino. Riot construyó Valorant sobre servidores de 128 ticks, un tick cada 7.8 ms, específicamente para que un defensor tenga tiempo de reaccionar ante un atacante que asoma por una esquina. Counter-Strike 2 tomó un camino distinto: sus servidores funcionan a 64 ticks, pero Valve añadió un sistema de subtick que marca la hora de cada entrada al milisegundo y la aplica en el momento exacto en que ocurrió en lugar de redondearla al siguiente tick, lo cual busca cerrar la mayor parte de la brecha hacia una sensación real de 128 ticks. Si lo logra por completo sigue siendo tema de debate entre jugadores, pero la intención de diseño es clara: reducir el retraso de alineación con el tick sin duplicar la carga de trabajo del servidor.

Los juegos de supervivencia y sandbox se sitúan más abajo y se apoyan en la configurabilidad. Rust y ARK exponen el tick rate como ajuste del servidor, y las instancias gestionadas por la comunidad suelen dejarlo alrededor de 30, sacrificando capacidad de respuesta a cambio de margen de CPU en máquinas que alojan mundos grandes. Lo importante no es la cifra exacta de un título concreto, que cambia entre parches, sino el patrón.

Los tick rates cambian entre versiones del juego y son configurables en títulos autoalojados; tómalo como una idea aproximada, no como una ficha técnica. Comprueba la cifra actual de tu versión antes de citarla.

Subir el tick rate acorta la espera de alineación con el tick, y nada más. No acorta el cable. Un servidor de 128 ticks en el continente equivocado sigue haciendo esperar a los jugadores el ida y vuelta; un servidor de 20 ticks en la ciudad correcta sigue haciéndolos esperar 50 ms hasta el siguiente tick. Ambos relojes son reales, y un buen proveedor cuida los dos.

Cómo el netcode oculta el retraso, y dónde se rompe la ilusión

Ningún tick rate ni peering llevan la latencia a cero, así que los juegos mienten de forma convincente en su lugar. El netcode es el conjunto de trucos que ocultan el retraso al jugador. Cuatro son los que más importan.

Predicción del lado del cliente. En lugar de esperar a que el servidor confirme tu movimiento, el cliente lo muestra de inmediato, prediciendo lo que el servidor casi con toda seguridad aceptará. Tu personaje se mueve en el instante en que pulsas avanzar. Cuando llega la actualización con autoridad del servidor y coincide, no lo notas. Cuando difiere, el cliente corrige.

Interpolación de entidades. Las posiciones de los demás jugadores llegan como instantáneas discretas, espaciadas según el tick rate y distorsionadas por la red. Para dibujarlas con fluidez, el cliente mantiene un pequeño buffer y las renderiza ligeramente en el pasado, interpolando entre las dos últimas posiciones conocidas. Por eso los demás jugadores se ven fluidos incluso en una conexión modesta. También significa que siempre estás viendo a todos los demás con un ligero retraso respecto a dónde están realmente en el servidor.

Compensación de lag. Cuando disparas, un juego con autoridad de servidor rebobina su propio estado según tu latencia para juzgar el disparo respecto a dónde estaba el objetivo en tu pantalla cuando disparaste, no dónde está ahora. Riot describe exactamente este rebobinado en su artículo sobre el netcode. Sin ello, los jugadores con ping alto nunca podrían acertar a un objetivo en movimiento. Con ello, tienen una oportunidad justa.

Rollback. Los juegos de lucha, que no toleran ningún retraso de entrada, usan netcode de rollback. El cliente asume las siguientes entradas del oponente, simula hacia delante sin ningún retraso, y si la suposición era errónea, rebobina el estado del juego hasta el punto de divergencia, lo vuelve a simular, y luego avanza rápido hasta el presente. La técnica se popularizó con el SDK GGPO y hoy es lo esperado en los juegos de lucha competitivos. Bien hecho, el juego en línea se siente como el juego local, hasta que la conexión empeora lo suficiente como para que las correcciones se vuelvan visibles.

La ilusión se rompe en lugares predecibles, y todo jugador los ha sentido:

• Ventaja del que asoma la esquina (peeker's advantage). El jugador que rodea una esquina ve al defensor inmóvil antes de que el defensor lo vea a él, porque la interpolación y el ida y vuelta hacen que el cliente del defensor muestre el pasado. Combinado con la compensación de lag, el atacante suele ganar el intercambio. Riot cita esto como la razón específica por la que eligió servidores de 128 ticks.
• La disputa del «yo disparé primero». Te cubres tras una esquina, y mueres un instante después. En tu pantalla estabas a salvo; en la pantalla del tirador, rebobinada por la compensación de lag, seguías expuesto en el momento en que disparó. El servidor respetó lo que él vio. Nadie hizo trampa.
• Rubber-banding y teletransportaciones. Cuando la predicción falla o se pierden actualizaciones, la corrección hace saltar a tu personaje, o a otro jugador, hasta donde el servidor dice que debería estar. Ese tirón hacia atrás es la ilusión fallando en tiempo real, y casi siempre lo causa el packet loss o una conexión con jitter, no el ping en bruto.

Cuánta latencia puede ocultar cada género

El netcode compra distintos márgenes de holgura según el género, así que no existe una cifra única de latencia «aceptable». El marco más citado es el modelo de 2006 de Claypool y Claypool, publicado en Communications of the ACM, que vincula la tolerancia a la latencia de un juego con la perspectiva del jugador y con lo precisas y urgentes que son sus acciones.

Su hallazgo, en cifras redondas: los juegos en primera persona como los shooters y las carreras, donde controlas un avatar directamente y actúas con plazos ajustados, empiezan a degradarse en torno a los 100 ms. Los juegos en tercera persona con avatar, como muchos juegos de rol, siguen siendo jugables hasta unos 500 ms porque las acciones son menos urgentes. Los juegos omnipresentes, donde mandas sobre unidades desde arriba como en la estrategia en tiempo real, toleran más; trabajos posteriores sobre el género sitúan un límite superior utilizable cerca de los 1,000 ms, ya que dar una orden no es un acto reflejo.

La lectura práctica de esa investigación, más allá de los umbrales exactos:

• Los shooters y juegos de lucha competitivos son los menos indulgentes. Los jugadores notan decenas de milisegundos, y la consistencia importa tanto como el promedio. Este es el género donde la ubicación del servidor es casi innegociable.
• Los MOBA y los RPG de acción se sitúan en un punto intermedio. Ocultan más retraso mediante la predicción y entradas menos urgentes, pero el juego competitivo sigue premiando una latencia baja y estable.
• Los MMO y los juegos de estrategia son los que más toleran. Los juegos por turnos y los de tiempo real más lentos pueden repartir a los jugadores por todo un continente y aun así funcionar bien.

Toma esto como orientativo. Las cifras varían según el juego concreto, la habilidad del jugador y la calidad del netcode. La regla de diseño prudente es dimensionar la ubicación y el hardware del servidor para la acción más sensible a la latencia que tus jugadores vayan a realizar en él.

Por qué el jitter y el packet loss perjudican más que un ping alto pero estable

La latencia no es solo cuán alta es, sino cuán estable. Una conexión que mantiene un 80 ms constante suele sentirse mejor que una que promedia 50 ms pero oscila bruscamente, y la razón es el netcode descrito arriba.

Tanto la interpolación como la predicción asumen un retraso más o menos constante. Dales un ping estable y encuentran su ritmo; el tamaño del buffer y la cadencia de las correcciones dejan de moverse, y el propio timing del jugador se adapta. El jitter rompe eso. Cuando el ida y vuelta se sacude entre 40 ms y 120 ms, el cliente no puede elegir un buffer que sea a la vez pequeño y seguro, así que o bien agranda el buffer, añadiendo retraso para todos, o lo mantiene ajustado y sufre instantáneas que llegan tarde y se manifiestan como tirones.

El packet loss es aún peor. Una actualización perdida no es un fotograma retrasado; es uno que falta. El cliente entonces mantiene el último estado conocido, lo que congela a otro jugador a mitad de zancada, o extrapola más allá y luego se recoloca de golpe cuando llega la verdad. Ese recolocado brusco es el rubber-banding. Un packet loss constante de entre el 1 y el 2 % hace que un juego se sienta roto incluso con un ping que de otro modo sería excelente.

La lección de diseño para un proveedor es que una ruta bien conectada por peering con un timing estable gana a una ruta ligeramente más corta que se congestiona. Una ruta que ocasionalmente satura un enlace y pierde paquetes se sentirá peor que otra marginalmente más larga que nunca lo hace.

La geografía y el enrutamiento deciden lo esencial

De todo lo que un proveedor influye, la distancia física es el factor más grande y menos negociable. La luz en la fibra óptica viaja a unos dos tercios de su velocidad en el vacío, aproximadamente 200 km por milisegundo, lo que da la regla general útil de cerca de 1 ms de retraso de ida y vuelta por cada 100 km de cable, antes de cualquier sobrecarga de enrutamiento. De Ámsterdam a Fráncfort son unos pocos milisegundos por cable; de Ámsterdam a Sídney no puede bajar de unos 150 ms en un solo sentido por mucho que pagues, porque el planeta tiene ese tamaño.

El enrutamiento determina cuánto te acercas realmente a ese suelo físico. Dos servidores a la misma distancia pueden diferir en decenas de milisegundos según cómo se transporte su tráfico. Una red bien conectada por peering entrega el tráfico a otras redes directamente en un punto de intercambio de internet en la misma región, manteniendo la ruta corta. Una red mal conectada depende de tránsito que puede llevar tus paquetes a través de una ciudad lejana antes de dar la vuelta, añadiendo latencia y saltos donde los paquetes pueden perderse o retrasarse. Por eso nuestra página de red publica nuestro peering: la ruta forma parte del producto.

La conclusión para un proveedor es contundente. La ubicación del servidor domina cualquier otra palanca de latencia que controles, porque fija el suelo dentro del cual luego operan el tick rate y el netcode. Una base de jugadores europea debería servirse desde una ubicación europea bien conectada, no enrutada a través de un océano hacia donde la capacidad resultara más barata. Por eso nuestra ubicación de Ámsterdam existe como una opción diferenciada: para los jugadores en Europa, alojar allí elimina más latencia percibida que cualquier ajuste que puedas hacer en la propia máquina.

La latencia que controlas como proveedor

La distancia y el enrutamiento fijan el suelo. Las etapas del lado del servidor en el ida y vuelta son donde un proveedor mantiene ese suelo o lo destroza, y esta es la parte que realmente operas.

El mayor riesgo del lado del servidor es un tick que se pasa de presupuesto. Un servidor de 20 ticks tiene 50 ms para terminar cada tick; uno de 64 ticks tiene unos 15 ms. Si la simulación no puede terminar en esa ventana, los ticks se retrasan, la frecuencia efectiva cae, y cada jugador conectado siente un retraso añadido en el mismo instante. Eso es a lo que suele referirse «el servidor va con lag», a diferencia del ping de un jugador concreto. Es un problema de CPU, y las simulaciones de juego dependen del rendimiento monohilo, razón por la cual núcleos rápidos superan a muchos núcleos lentos para esta carga de trabajo. Profundizamos en ese compromiso en el artículo sobre rendimiento bare metal frente a VM.

El hosting compartido sobrevendido es la forma habitual en que esto sale mal. Cuando un proveedor amontona demasiadas instancias en una sola máquina física, tu proceso de juego compite por tiempo de CPU que creía tener. En hosts virtualizados esto aparece como CPU steal: ciclos que el hipervisor cede a un vecino en lugar de a ti. El steal time se convierte en ticks retrasados, y los ticks retrasados se convierten en latencia percibida para cada jugador de tu servidor, sin que la red tenga culpa alguna. Una máquina dedicada elimina por completo al vecino, lo cual es el principal argumento de latencia a favor de alojar servidores de juego en bare metal.

Los ataques también son una fuente de latencia, no solo de caídas. Un ataque DDoS volumétrico que satura el enlace de subida dispara la latencia y el packet loss para los jugadores legítimos mucho antes de dejar el servidor completamente fuera de línea; el juego se siente como si se ahogara en jitter. Una mitigación que limpia la inundación aguas arriba mantiene la ruta despejada, lo cual es un beneficio de latencia tanto como de disponibilidad.

El resto es disciplina de hosting corriente: dar al proceso del juego los núcleos que necesita, mantener el bucle de tick dentro de presupuesto, y no dejar que una tarea en segundo plano o un vecino ruidoso robe ciclos durante las horas punta.

Cómo medirla correctamente

Si estás diagnosticando la latencia, una sola cifra de ping es la herramienta menos útil, porque reduce todo el trayecto a un solo número y oculta dónde reside el retraso.

ping te da el ida y vuelta hasta el servidor y, ejecutado durante un rato, una idea del jitter y el packet loss. Responde a «a qué distancia, y con qué estabilidad», y nada sobre la ruta.

ping -c 50 203.0.113.10

mtr combina traceroute y ping: hace ping a cada salto de la ruta de forma continua y muestra el packet loss y la latencia por salto. Eso es lo que te dice dónde está el problema. Si la latencia y el packet loss aparecen en el salto 3 y se mantienen altos hasta el servidor, el problema es temprano, cerca del jugador. Si todo está limpio hasta el último salto, mira hacia el servidor. Si un salto intermedio muestra pérdidas pero los saltos posteriores están limpios, es probable que ese salto simplemente esté limitando la tasa de sus propias respuestas ICMP, y puede ignorarse.

                             Packets               Pings
 Host                       Loss%   Snt   Avg  Best  Wrst
 1. 203.0.113.1              0.0%    50   0.5   0.3   1.2
 2. 198.51.100.9             0.0%    50   3.4   2.9   9.8
 3. 198.51.100.40            0.0%    50  11.5  10.9  24.6
 4. 192.0.2.50               0.0%    50  18.9  18.3  31.4

El net graph integrado en el juego es la medida que mejor coincide con lo que siente el jugador, porque incluye la alineación con el tick y el procesamiento del servidor que el ping no puede ver. La mayoría de los títulos competitivos exponen uno: muestra la latencia cliente-servidor, el retraso de interpolación, el packet loss, y a menudo el propio rendimiento de tick del servidor. Cuando el ping de un jugador parece correcto pero el juego se siente mal, el net graph suele mostrar al verdadero culpable: un buffer de interpolación estirado o un servidor cuyo tick rate ha caído.

Las cifras anteriores son ilustrativas y usan rangos de IP reservados para documentación. Tus propios valores variarán según la ubicación, la ruta y la hora del día; ejecuta los comandos contra tu servidor real e interpreta la forma del resultado, no estas cifras concretas.

Desplegar en Serverside

La latencia se decide en su mayor parte antes de que se conecte el primer jugador, según dónde se sitúa el servidor y cómo se enruta su red. Un servidor de juego Serverside funciona en bare metal sobre nuestra propia red (AS55285), de modo que tu bucle de tick obtiene una máquina entera sin ningún vecino ruidoso robando ciclos, y la ruta hacia tus jugadores discurre por un enrutamiento que nosotros peereamos y publicamos, en lugar del tránsito más barato disponible. Una mitigación DDoS siempre activa se sitúa delante de la interfaz pública, lo que evita que una inundación se convierta en jitter para los jugadores que realmente están ahí. El aprovisionamiento tarda menos de un minuto, así que puedes colocar una máquina en el lugar correcto y probar la ruta antes de comprometerte.

Para una base de jugadores europea, nuestra ubicación de Ámsterdam es la que elimina más latencia percibida, bien conectada por peering a los puntos de intercambio de la región para que el tiempo de cable hasta los jugadores de la UE se mantenga cerca de su suelo físico. Si primero quieres ver todo el abanico de ubicaciones, empieza por el configurador de servidores dedicados y elige el sitio más cercano a los jugadores para los que estás construyendo.

Preguntas frecuentes

¿Cuál es la diferencia entre el ping y la latencia en un juego?

El ping es una medida de la latencia: el tiempo de ida y vuelta de un paquete pequeño hasta el servidor y de regreso, normalmente por ICMP. La latencia tal como la siente un jugador es más amplia. Incluye el ping, más el tiempo que espera tu entrada antes de ser muestreada, el tiempo que el servidor espera hasta su siguiente tick de simulación antes de actuar sobre tu paquete, el procesamiento que realiza ese tick, y el trayecto de vuelta. Dos jugadores con el mismo ping de 30 ms pueden sentir cantidades de retraso distintas si uno está en un servidor de 20 ticks y el otro en uno de 128 ticks, porque la espera del tick forma parte de la latencia percibida y el ping no la mide.

¿Un tick rate más alto reduce la latencia?

Reduce un componente específico de ella. Un tick rate más alto acorta la espera media entre el muestreo del mundo por parte del servidor y la actuación sobre tu entrada, porque los ticks ocurren con más frecuencia. Un servidor de 20 ticks se actualiza cada 50 ms, así que una entrada puede esperar hasta 50 ms antes de procesarse; un servidor de 128 ticks se actualiza cada 7.8 ms, así que esa espera es mucho menor. Lo que un tick rate más alto no cambia es el ida y vuelta de red. Si el servidor está a 5,000 km, ningún tick rate corrige los aproximadamente 50 ms que el paquete pasa en el cable en cada sentido. El tick rate y la distancia de red son dos relojes distintos, y hay que mantener ambos cortos.

¿Por qué pierdo combates que creía haber ganado, incluso con ping bajo?

Normalmente la compensación de lag combinada con la ventaja del que asoma la esquina (peeker's advantage). Los shooters con autoridad de servidor rebobinan el estado del juego según tu latencia para juzgar un disparo, así que el jugador que se mueve y asoma por una esquina suele resolverse como el que disparó primero, porque en su pantalla te vio a ti antes de que tu pantalla lo viera a él. El servidor respeta lo que cada cliente vio en el momento en que actuó. Por eso quien rodea una esquina suele ganar el intercambio, y por eso el defensor siente que lo mataron después de cubrirse. Es una decisión de diseño, no un error, y una latencia más baja y estable en ambos extremos reduce esa diferencia.

¿Es peor el jitter o el packet loss que un ping alto?

En la mayoría de los juegos, sí. Un 80 ms estable es predecible, y tanto el netcode como el propio timing del jugador se adaptan a él. El jitter, cuando el ida y vuelta oscila por ejemplo entre 40 ms y 120 ms, arruina esa adaptación porque el buffer de interpolación y la predicción del cliente no logran asentarse en un retraso constante. El packet loss es aún peor: una actualización perdida significa que el cliente congela el último estado conocido o extrapola y luego corrige, que es lo que son el rubber-banding y las teletransportaciones. Una conexión que promedia un ping más alto pero se mantiene estable suele sentirse mejor que una de promedio más bajo que sufre picos y pierde paquetes.

¿A qué distancia debe estar un servidor de juego de mis jugadores?

Lo bastante cerca para que el retraso de propagación quepa dentro de la tolerancia de tu género. La luz en la fibra viaja aproximadamente 200 km por milisegundo, así que una regla general es cerca de 1 ms de retraso de ida y vuelta por cada 100 km de cable, antes de cualquier sobrecarga de enrutamiento. Un shooter competitivo quiere jugadores dentro de unos pocos cientos de kilómetros para un tiempo de cable de un solo dígito en milisegundos; un juego de estrategia o un MMO puede repartirse mucho más ampliamente. Para una base de jugadores europea, eso significa alojar en una ubicación europea bien conectada por peering en lugar de enrutar a todos a través de un océano, que es la decisión de latencia más importante que toma un proveedor.