⏱️ Lectura: 14 min
Desde mediados de marzo de 2026, jugadores de Israel reportan un problema sistémico: cualquier juego que use Steam Networking para partidas P2P les dispara el ping a unos 120 ms, mientras que conexiones equivalentes contra rivales europeos rondan los 60-80 ms. El caso está documentado en el issue #398 del repositorio GameNetworkingSockets de Valve y apunta a un problema de enrutamiento en la red de relés de Steam, no a las operadoras locales.
📑 En este artículo
- TL;DR
- Qué pasó exactamente
- Steam Networking, SDR y por qué tu tráfico no va directo
- La pista que incrimina a Steam: PC contra PS5
- Cómo viaja un paquete en una partida P2P
- Los números, en contexto
- Por qué esto le importa a quien juega o desarrolla en LATAM
- Cómo diagnosticar tu propia ruta
- Qué puede hacer Valve y qué sigue
- Preguntas frecuentes
- Referencias
La pista más reveladora aparece en Street Fighter 6: una conexión PC contra PS5 (crossplay) mantiene 5-10 ms, mientras que PC contra PC supera los 120 ms. Misma región, mismos proveedores, latencia radicalmente distinta. Eso descarta al ISP y señala a la capa que ambos PC comparten.
TL;DR
- Desde el 13 de marzo de 2026, partidas P2P sobre Steam Networking en Israel muestran ~120 ms de ping entre dos PC, frente a 60-80 ms con europeos.
- El crossplay PC vs PS5 en Street Fighter 6 mantiene 5-10 ms, lo que descarta al ISP local como causa del problema.
- Juegos P2P que no usan Steam Networking, como Tekken 8, no presentan la degradación de latencia.
- El reporte afecta a decenas de jugadores en múltiples ISP de Israel; hay reportes sin confirmar desde Egipto.
- El issue #398 sigue abierto en GitHub sin respuesta oficial de Valve ni etiquetas asignadas.
- La causa más probable es enrutamiento subóptimo hacia un PoP lejano dentro de la red Steam Datagram Relay (SDR).
- GameNetworkingSockets usa ICE de WebRTC para NAT traversal y relés SDR para ocultar la IP y mitigar ataques DDoS.
Qué pasó exactamente
El 24 de marzo de 2026, un usuario identificado como boazazulay abrió el issue #398 en el repositorio público de GameNetworkingSockets. Su comunidad de jugadores competitivos venía notando desde alrededor del 13 de marzo una subida brusca y persistente de la latencia en todo juego que dependa de la infraestructura de red de Steam para partidas entre pares.
El ejemplo central es Street Fighter 6, un juego de pelea donde cada milisegundo cuenta: por encima de los 100 ms, las mecánicas que dependen de reacción (los llamados reversals, los castigos a movimientos inseguros) se vuelven prácticamente imposibles de ejecutar con consistencia. Dos jugadores israelíes conectados PC a PC ven 120 ms; uno israelí contra un europeo ve 60-80 ms, una latencia jugable. La asimetría es contraintuitiva: lo cercano funciona peor que lo lejano.
El autor del reporte detalla que el problema afecta a varias decenas de personas con distintos ISP, que ya descartaron port forwarding y revisaron con sus operadoras sin encontrar fallas de su lado. Y suma un dato que acota el diagnóstico: juegos P2P que no usan Steam Networking, como Tekken 8, funcionan con normalidad. Es decir, el cuello de botella no está en la conexión a internet del jugador, sino en una capa concreta del stack.
Steam Networking, SDR y por qué tu tráfico no va directo
Para entender el problema hay que entender qué hace Steam Networking por debajo. La biblioteca de código abierto que lo implementa, GameNetworkingSockets, ofrece a los desarrolladores una API orientada a conexión (como TCP) pero basada en mensajes (como UDP), con cifrado, fragmentación y control de congestión incluidos. Sobre eso, Valve construyó dos servicios que solo existen en la versión integrada en Steam.
El primero es el NAT traversal. La mayoría de los jugadores está detrás de un router con NAT, sin IP pública directa. Para que dos PC se vean, GameNetworkingSockets usa ICE (la misma implementación de WebRTC que usan las videollamadas), que prueba candidatos de conexión: dirección local, dirección pública descubierta por STUN, y como último recurso un relé. Si la conexión directa falla, el tráfico cae a un relevo.
El segundo servicio es Steam Datagram Relay (SDR), y aquí está el meollo. SDR no es solo un plan B para cuando falla el NAT: es una red troncal privada de Valve con puntos de presencia (PoP) repartidos por el mundo. Cuando una partida usa SDR, el tráfico de los jugadores entra a esa red por el relé más cercano, viaja por el backbone privado de Valve hasta el PoP del otro jugador, y sale. Las ventajas son reales: oculta la IP de los jugadores (clave contra el swatting y los ataques DDoS dirigidos en escena competitiva) y suele ofrecer rutas más estables que el internet público.
💭 Clave: SDR cambia el modelo mental: tu paquete no busca al otro jugador, busca al relé de Valve más cercano. Si ese primer salto te manda a un PoP equivocado, toda la ruta se alarga aunque el rival esté en tu misma ciudad.
La pista que incrimina a Steam: PC contra PS5
El detalle del crossplay es lo que convierte una queja difusa en un diagnóstico. En Street Fighter 6, una partida PC contra PS5 mantiene 5-10 ms. Si el problema fuera del ISP israelí, del cableado submarino o de un peering roto, ese tráfico también se vería afectado, porque sale por la misma conexión física. Pero no: solo se degrada el PC contra PC.
La explicación más coherente es que la ruta PC-PC sobre Steam Networking está pasando por la red SDR y siendo enrutada hacia un PoP lejano (por ejemplo, en Europa occidental en lugar de uno regional cercano), mientras que la ruta PC-PS5 toma un camino distinto que no sufre ese desvío. Un cambio del 13 de marzo —una reconfiguración de PoP, un ajuste de peering BGP, el retiro temporal de un relé regional— encajaría con la fecha de inicio y con que el resto del internet del jugador siga funcionando bien.
📌 Nota: Es un diagnóstico por evidencia circunstancial, no una confirmación de Valve. El issue sigue abierto sin respuesta oficial. Lo que sí es sólido es la inferencia de que la causa está en la capa de Steam Networking, no en el ISP.
Cómo viaja un paquete en una partida P2P
El siguiente diagrama resume las dos rutas observadas. La diferencia no está en los extremos, sino en por dónde pasa el tráfico de Steam Networking en el medio.
flowchart TD
A["PC Israel A"] -->|"PC vs PS5: 5-10 ms"| PS["PS5 sin SDR"]
A -->|"PC vs PC: ~120 ms"| SDR["Red Steam Datagram Relay"]
SDR -->|"enrutamiento a PoP lejano"| B["PC Israel B"]En un escenario sano, el relé SDR más cercano a ambos PC estaría en la región o en un PoP de baja latencia, y el ping rondaría los mismos 5-30 ms que vemos en el crossplay. El salto a 120 ms sugiere que el primer salto a la red de Valve añade un tramo intercontinental de ida y vuelta que no debería existir para dos máquinas vecinas.
Los números, en contexto
Para dimensionar por qué 120 ms rompe un juego de pelea, conviene mirar las escalas. La velocidad de la luz en fibra ronda los 200.000 km/s, así que un viaje de ida y vuelta de 120 ms equivale a unos 12.000 km de cable: básicamente cruzar de Medio Oriente a la costa este de Estados Unidos y volver. Que dos PC en Israel necesiten ese recorrido para hablarse es el síntoma exacto de un relé mal asignado.
En términos de jugabilidad, los géneros toleran latencias muy distintas. Un juego por turnos no nota 200 ms. Un shooter compite mejor por debajo de 50 ms. Los juegos de pelea son el caso más exigente: la comunidad competitiva considera 0-60 ms como bueno, 60-90 ms como jugable con esfuerzo, y por encima de 100 ms la experiencia se degrada hasta lo injugable porque el rollback netcode tiene que predecir e interpolar demasiados cuadros. A 120 ms, el motor de predicción corrige tantas veces que el personaje parece teletransportarse.
Por qué esto le importa a quien juega o desarrolla en LATAM
Aunque el reporte sea de Israel, el patrón es perfectamente reconocible para América Latina, una región históricamente mal servida por la infraestructura de relés de las grandes plataformas. Cuando un PoP regional no existe o se satura, el tráfico se desvía a Estados Unidos o incluso a Europa, y un jugador en San Salvador termina con más ping contra su vecino que contra alguien en Miami. Es exactamente la misma asimetría del issue #398, solo que crónica en lugar de repentina.
Para quien desarrolla juegos o aplicaciones en tiempo real desde LATAM, la lección es de arquitectura. Delegar el transporte en Steam Networking te da NAT traversal y protección DDoS gratis, pero también te ata al mapa de PoP de un tercero. Si tu público está en una región mal cubierta, vale la pena medir antes de comprometerse, y considerar fallbacks: relés propios (TURN), conexión directa cuando el NAT lo permite, o servidores regionales en proveedores con presencia local.
💡 Tip: Antes de elegir tu capa de red, mide la latencia real desde tu mercado objetivo, no desde tu oficina. Una herramienta de relé que brilla en Norteamérica puede degradar tu producto en regiones con pocos PoP.
Cómo diagnosticar tu propia ruta
Si sospechás que tu tráfico de juego se está desviando, podés empezar por un traceroute hacia el relé o el servidor de la partida para ver dónde se va la latencia. Estos comandos funcionan en las tres plataformas principales:
# Windows (CMD o PowerShell)
tracert -d 162.254.197.36
Test-NetConnection 162.254.197.36 -InformationLevel Detailed
# macOS
traceroute 162.254.197.36
networkQuality # mide latencia bajo carga (macOS 12+)
# Linux
mtr -rwzbc 50 162.254.197.36
traceroute 162.254.197.36La IP del ejemplo es ilustrativa: reemplazala por la del relé o servidor que querés medir. Lo que buscás es el salto donde el tiempo da un brinco grande y se queda alto; si ese salto está geográficamente lejos (lo podés inferir por el nombre del host o por bases de datos de geolocalización de IP), ahí está tu desvío. En los juegos de Valve también podés activar la consola de desarrollador y los gráficos de red (net_graph en títulos Source) para ver el ping y la pérdida de paquetes en vivo.
Para quien quiera entender el lado del código, GameNetworkingSockets expone el estado detallado de cada conexión, incluido si está usando un relé y la latencia estimada de cada extremo:
// C++: inspeccionar el estado en tiempo real de una conexión
SteamNetConnectionRealTimeStatus_t status;
SteamNetConnectionRealTimeLaneStatus_t laneStatus;
SteamNetworkingSockets()->GetConnectionRealTimeStatus(
hConn, &status, 0, &laneStatus);
printf("ping: %d ms | calidad: %.2f | via relay: %s\n",
status.m_nPing,
status.m_flConnectionQualityLocal,
status.m_eState == k_ESteamNetworkingConnectionState_Connected
? "si" : "verificar");Ese m_nPing es justamente la métrica que los jugadores del issue ven anclada en 120 ms, y el campo de calidad ayuda a separar un problema de latencia pura de uno de pérdida de paquetes.
Qué puede hacer Valve y qué sigue
Del lado de Valve, la solución no requiere tocar el código de los juegos: si el diagnóstico es correcto, basta con corregir la asignación de PoP o el enrutamiento dentro de la red SDR para que el tráfico de Israel vuelva a tomar un relé regional. Ese tipo de ajuste es operativo, no un parche de software que los jugadores tengan que instalar.
El problema, por ahora, es de visibilidad: el issue está en el repositorio de la biblioteca, no en un canal de soporte de la infraestructura SDR, y sigue sin respuesta oficial ni etiquetas. Históricamente, los problemas de enrutamiento de Steam se resuelven cuando ganan tracción pública y alguien dentro de Valve los conecta con el equipo de red. Mientras tanto, la comunidad afectada queda en un limbo: no es un bug que puedan arreglar ellos, pero tampoco hay un botón para reportarlo a quien sí puede.
Para el resto de nosotros, el episodio es un recordatorio útil de cuánta complejidad invisible hay detrás de un simple ping. Cuando todo funciona, una red de relés global como SDR es magia que oculta IP, frena ataques y estabiliza rutas. Cuando un PoP se asigna mal, esa misma magia convierte a dos vecinos en una llamada intercontinental.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué es Steam Networking?
Es el conjunto de servicios de red que Valve ofrece a los juegos en Steam, implementado sobre la biblioteca de código abierto GameNetworkingSockets. Incluye NAT traversal mediante ICE y la red de relés Steam Datagram Relay (SDR), que enruta el tráfico P2P por el backbone privado de Valve para ocultar la IP de los jugadores y mitigar ataques DDoS.
¿Por qué el crossplay PC contra PS5 funciona pero PC contra PC no?
Porque la ruta PC-PS5 parece tomar un camino distinto al de la red SDR, mientras que la conexión PC-PC sobre Steam Networking se está desviando a un relé lejano. Que el crossplay mantenga 5-10 ms demuestra que la conexión física del jugador está sana y que el problema está en la capa de enrutamiento de Steam.
¿Es un problema de mi ISP o de mi router?
Según el reporte, no. Los afectados usan distintos ISP, ya probaron port forwarding y revisaron con sus operadoras sin hallar fallas. Además, juegos P2P que no usan Steam Networking (como Tekken 8) funcionan bien, lo que aísla la causa a la infraestructura de Valve.
¿Cómo puedo medir si mi tráfico se está desviando?
Con un traceroute (tracert en Windows, traceroute o mtr en macOS y Linux) hacia el relé o servidor de la partida. Buscá el salto donde la latencia pega un brinco grande; si ese salto está geográficamente lejos, ahí está el desvío. En juegos de Valve también podés activar net_graph para ver ping y pérdida en vivo.
¿Afecta esto a jugadores de LATAM?
El reporte específico es de Israel y posiblemente Egipto, pero el patrón —tráfico desviado a un PoP lejano por falta de cobertura regional— es un viejo conocido en América Latina. Si jugás P2P desde la región y notás más ping contra vecinos que contra rivales lejanos, podrías estar viendo el mismo fenómeno de forma crónica.
¿Valve ya respondió o lo está arreglando?
Al momento del reporte, el issue #398 seguía abierto, sin asignados, sin etiquetas y sin respuesta oficial. La corrección, de confirmarse el diagnóstico, sería del lado de Valve (reasignar el PoP o el enrutamiento SDR) y no requeriría acción de los jugadores.
Referencias
- GitHub Issue #398 — reporte original de los problemas de P2P en Israel y Medio Oriente.
- ValveSoftware/GameNetworkingSockets — repositorio de la biblioteca de red de Steam, base de SDR.
- README_P2P.md — documentación oficial de P2P, ICE y relés en GameNetworkingSockets.
- NAT traversal (Wikipedia) — fundamentos de ICE, STUN, TURN y conexión entre pares.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios