Tienes una IP pública y una docena de dispositivos detrás de tu router. Tu iPad está en datos celulares, a tres redes de distancia. De algún modo, una app de escritorio remoto abre una conexión directa de uno a otro en menos de un segundo, normalmente sin relay en medio. Así funciona de verdad esa magia: ICE, STUN, TURN, hole punching y la incómoda verdad sobre el NAT simétrico.
Por qué importa
Imagina una mañana de martes. Tu Mac mini está en casa detrás de un router con una sola dirección IPv4 pública. Tu iPad está en el tren, en la red móvil de un operador con sus propias capas de traducción de direcciones. Hay al menos dos NAT entre los dos dispositivos, probablemente tres. Ninguna de las dos máquinas es accesible desde internet por defecto.
Y aun así abres Remio en el iPad, tocas la Mac y un segundo después estás viendo tu escritorio. El video y la entrada fluyen directamente entre los dos dispositivos: sin relay en la nube, sin proxy en medio recodificando tu pantalla.
La técnica que lo hace posible tiene nombre —NAT traversal— y detrás una familia de protocolos bien definidos: STUN, TURN e ICE. Son los mismos protocolos que usa WebRTC para las videollamadas en el navegador, y son la razón por la que cualquier escritorio remoto P2P moderno puede evitar pasar los fotogramas de tu pantalla por el centro de datos de un tercero. Este artículo recorre qué hace cada uno, por qué existe y cómo se combinan para encontrar la ruta de menor latencia entre dos dispositivos escondidos detrás de routers.
El problema del NAT en 60 segundos
Internet se diseñó para que cada dispositivo tuviera su propia dirección enrutable públicamente. Hay unos 4,300 millones de direcciones IPv4 en todo el espacio: muchas en 1981, y muy claramente insuficientes hacia fines de los 90.
El remedio fue la traducción de direcciones de red (NAT). Tu router recibe una dirección IPv4 pública de tu proveedor. Dentro de tu casa, cada dispositivo recibe una dirección privada de un rango reservado (normalmente 192.168.x.x o 10.x.x.x). Cuando tu laptop envía un paquete hacia fuera, el router reescribe la dirección de origen con su propia IP pública, recuerda la correspondencia y lo reenvía. Cuando llega la respuesta, el router busca la correspondencia y reescribe el destino de vuelta hacia tu laptop.
Por eso mismo las conexiones entrantes no funcionan por defecto. Desde fuera, tu laptop no tiene dirección; solo el router la tiene. El paquete de un desconocido a ip-publica-de-tu-router:5060 llega a un router que no tiene ninguna correspondencia para él y lo descarta.
Para una app P2P, este es todo el juego. Ambos pares están detrás de routers que solo reenvían paquetes cuando recuerdan haber enviado algo hacia fuera primero. Ninguno puede simplemente «llamar» al otro: tienen que cooperar con sus routers para abrir un camino temporal.
Hole punching: lograr que el firewall te deje volver a entrar
Este es el truco. La tabla NAT de tu router se indexa por una quíntupla: IP de origen, puerto de origen, IP de destino, puerto de destino y protocolo. Cuando tu dispositivo envía un paquete UDP saliente a 1.2.3.4:5678, el router crea una entrada temporal que dice «si llega algún paquete UDP de 1.2.3.4:5678 a mi IP pública en el puerto X, reenvíalo a este dispositivo en el puerto Y».
Esa entrada existe durante una ventana de tiempo —normalmente de 30 a 60 segundos— y luego caduca salvo que algo la renueve. Durante esa ventana, cualquier paquete de la dirección de destino será aceptado.
Esta es la cerradura que usan las apps P2P. Si ambos pares conocen la dirección pública del otro, cada uno puede enviar un único paquete UDP saliente al otro al mismo tiempo. El router de cada lado abre una correspondencia saliente. El primer paquete de cada lado bien puede descartarse —el otro router aún no abrió su correspondencia—, pero el segundo paquete ya tiene adónde ir. Desde ese momento, ambos routers creen que reenvían una conversación saliente normal, y los dos dispositivos hablan directamente.
Esto se llama UDP hole punching. Es levemente milagroso, está bien documentado (RFC 5128) y funciona con la gran mayoría de los NAT de consumo que existen. Los casos restantes —NAT simétrico, CGNAT, firewalls corporativos— son la razón de que exista TURN.
El hole punching no es un truco sucio. Es el contrato explícito en torno al cual se diseñó el NAT: un paquete saliente crea un permiso de entrada. Las apps P2P simplemente envían el paquete saliente a propósito.
STUN: «¿cuál es mi dirección pública?»
El hole punching necesita un requisito previo: cada par debe conocer su propia dirección de cara al público para poder decirle al otro lado adónde enviar paquetes. Esa dirección no es visible desde dentro del dispositivo. Tu iPad ve su dirección Wi-Fi local (192.168.1.42). Lo que el resto de internet ve después de que el router reescribe el paquete es algo completamente distinto.
STUN —Session Traversal Utilities for NAT, RFC 5389— es el pequeño protocolo que lo resuelve. El flujo es casi vergonzosamente simple:
- El par envía un paquete UDP a un servidor STUN público. (Remio usa los servidores STUN públicos de Cloudflare y de Google, por redundancia.)
- El servidor STUN lee la IP y el puerto de origen en el cable, que es, por definición, la dirección pública del par traducida por el NAT.
- El servidor STUN responde con esa dirección como contenido: «Por lo que puedo ver, eres
203.0.113.42:48291.» - Ahora el par sabe qué dirección anunciar al otro lado.
Esa dirección de cara al público se llama candidato server-reflexive en la terminología de ICE. Cuesta prácticamente nada: un viaje de ida y vuelta durante el establecimiento de la conexión, y cero sobrecarga de ancho de banda o latencia después. El único trabajo de STUN es presentar a dos pares entre sí; una vez que hablan, el servidor STUN ya no tiene ningún papel.
TURN: cuando falla el hole punching
El hole punching funciona con la mayoría de los NAT, pero no con todos. Los casos de fallo son reales, y una app P2P que finja que no existen simplemente no podrá conectar para una porción significativa de usuarios.
Los principales villanos:
- NAT simétrico. Un NAT que asigna un puerto público distinto para cada destino distinto. STUN le dice a tu par que estás en el puerto 48291 (porque ese es el puerto que vio el servidor STUN), pero cuando envías un paquete a la dirección de tu par, tu router elige otro puerto, digamos el 48317. El router de tu par rechaza el paquete porque viene de un puerto inesperado. El hole punching se rompe.
- NAT a nivel de operador (CGNAT). Las redes celulares y muchas de proveedores de internet añaden un segundo NAT a nivel de operador. Puede que estés detrás de dos NAT sin saberlo, y ambos tienen que cooperar. El CGNAT suele ser simétrico y no tienes acceso de administrador.
- Firewalls corporativos restrictivos. Algunas redes empresariales bloquean todo el UDP saliente, o solo lo permiten hacia destinos concretos. El hole punching necesita una ruta UDP; si no hay ninguna, no tiene ninguna oportunidad.
Para estos casos, el respaldo es TURN (Traversal Using Relays around NAT, RFC 5766). Un servidor TURN es un relay al que ambos pares pueden llegar porque tiene una dirección pública que siempre acepta tráfico entrante. Cada par hace una conexión TLS saliente normal al servidor TURN (que cualquier NAT permitirá), y el servidor reenvía los bytes entre los dos lados.
TURN tiene un costo real. Cada paquete de video tiene que atravesar un salto de red adicional. En un relay TURN regional, eso suma unos 30 a 80 milisegundos de latencia de ida y vuelta. Entre regiones —digamos un relay en Fráncfort para un par en Tokio y otro en São Paulo— puede ser de 80 a 200 milisegundos. El operador de TURN también paga el ancho de banda: cada bit de tu transmisión pasa por sus tuberías.
Por eso una app bien diseñada usa TURN solo cuando el hole punching ha fallado de forma demostrable. ICE toma esa decisión automáticamente.
ICE: probar todos los candidatos en paralelo
Interactive Connectivity Establishment, RFC 8445, es la coreografía que une todo esto. ICE no elige una estrategia de antemano. Reúne todas las direcciones candidatas posibles de cada par, intercambia la lista completa con el otro lado y luego hace que ambas pilas sondeen todos los pares de candidatos en paralelo, en una carrera por encontrar el primero que funcione.
Para cada par, ICE normalmente reúne:
- Candidatos host: cada dirección IP local en cada interfaz de red (Ethernet, Wi-Fi, interfaces virtuales, IPv4 e IPv6).
- Candidatos server-reflexive: direcciones públicas aprendidas de servidores STUN.
- Candidatos relay: direcciones asignadas en un servidor TURN.
Los dos pares intercambian estas listas por un canal de señalización; en Remio, es una pequeña conexión WebSocket a relay.remio.net que lleva los candidatos ICE y la descripción de sesión de WebRTC (el SDP), y luego no tiene nada más que hacer una vez que empieza a fluir el contenido.
Con ambas listas en mano, ICE empieza las comprobaciones de conectividad. Cada par envía un paquete STUN binding request por cada pareja de candidatos, en orden de prioridad. Las prioridades están pensadas para preferir la ruta de menor latencia:
- Host a host: ambos pares en la misma red local. Es el caso soñado: unos cientos de microsegundos de latencia, sin router de por medio.
- Host a server-reflexive, o server-reflexive a server-reflexive: pares en redes distintas, con hole punching a través de sus NAT respectivos. Esto es lo que normalmente significa «P2P por internet» en la práctica.
- Cualquier cosa con un relay: último recurso, usado solo cuando todas las rutas de mayor prioridad fallan sus comprobaciones de conectividad.
La primera pareja de candidatos en la que ambas direcciones tienen éxito se nomina ganadora, y el contenido empieza a fluir por esa ruta. Todo el proceso suele completarse en bastante menos de un segundo.
ICE también reúne candidatos de forma continua. Si aparece una ruta mejor en plena sesión —por ejemplo, tu celular deja los datos celulares y se une al Wi-Fi—, ICE puede renominar la nueva ruta sin cortar la llamada.
Por qué Remio prefiere P2P a toda costa
Remio es una app de escritorio remoto, no una videollamada. El presupuesto de latencia es brutal. Para que una sesión se sienta como estar sentado frente a la máquina host, todo el proceso —captura, codificación, red, decodificación, renderizado— tiene que ser minúsculo: en una LAN cuesta unos 8 ms, y el resto es la cadencia de actualización de 60 Hz de tu propia pantalla (unos 16,7 ms por fotograma). Cada salto extra es un pecado.
En una conexión P2P directa por LAN, la parte de red de ese presupuesto es de unos 1 a 5 milisegundos de ida y vuelta. No hay relay; los bytes van directo de un dispositivo al otro. Con el canal de Remio esto suma unos 8 ms de procesamiento en LAN (medidos internamente; el resto es la cadencia de actualización de 60 Hz de tu propia pantalla): tu entrada llega antes de que se dibuje el siguiente fotograma. La máquina remota se siente indistinguible de una local.
En una conexión por relay TURN —incluso uno regional—, la parte de red salta a 30 a 80 milisegundos. La latencia total percibida por el usuario pasa a ser de 40 a 100 ms. Sigue siendo usable para la mayoría del trabajo, pero se nota en un arrastre rápido o una secuencia rápida de clics. El trackpad ya no se siente del todo tuyo.
Esa diferencia es la razón por la que nos esforzamos tanto en mantener las sesiones en P2P. La pila WebRTC de Remio reúne candidatos IPv4 e IPv6, habla con varios servidores STUN en paralelo y prefiere con agresividad las rutas directas durante la selección de pares de candidatos de ICE. Internamente incluso usamos el RTT medido de la conexión para clasificar la red: por debajo de 15 ms sabemos que es LAN, así que el codificador arranca alto y puede usar mucho más ancho de banda. Todo lo más lento se trata como WAN y se ajusta de forma más conservadora.
Y —esto es lo que los competidores suelen omitir en silencio— la conexión tiene cifrado de extremo a extremo sin importar la ruta. Tu pantalla nunca toca nuestros servidores, e incluso un relay TURN solo ve texto cifrado: las claves se negocian directamente entre los dos pares durante el apretón de manos, antes de que se mueva un solo píxel. Ya sea que los bytes fluyan por P2P o por TURN, ni el servidor de señalización de Remio ni el operador de TURN pueden leerlos. P2P solo significa que no hay ningún tercero en la ruta de los datos.
Cuando el relay es inevitable (y está bien)
A veces los dioses de la red dicen que no. NAT simétrico en ambos extremos, doble CGNAT en un operador celular con un proveedor estricto, un firewall corporativo que solo permite TLS saliente hacia proveedores de nube conocidos: son configuraciones reales y comunes. En esos casos la sesión simplemente tiene que pasar por un relay o no ocurre.
El respaldo TURN de Remio es Cloudflare Calls, que nos da una red global de relays cerca de la mayoría de los usuarios. Cuando ICE elige una ruta por relay, la experiencia pasa de «se siente local» a «se siente como Splashtop»: sigue siendo muy usable, pero se nota. La latencia añadida es de 30 a 80 ms con un relay regional; entre regiones puede llegar a 200 ms.
Lo importante: los datos siguen cifrados de extremo a extremo. Cloudflare ve paquetes UDP cifrados que van en un sentido y paquetes UDP cifrados que van en el otro. Puede contar bytes para facturar. No puede ver tu pantalla, tus pulsaciones ni nada del contenido de tu sesión. Tampoco hay un punto de descifrado de Remio, porque no hay nube de Remio en el canal: operamos el servicio TURN a través de Cloudflare y nunca tocamos las cargas.
Esta es la arquitectura que describe con más detalle nuestro documento técnico de seguridad. En resumen: P2P o relay, el modelo de amenazas es el mismo.
La salida de emergencia de IPv6
IPv6 tiene 340 sextillones de direcciones (3,4 × 1038): suficiente para darle su propia IP pública a cada grano de arena de la Tierra, y que sobren varios billones. En un mundo solo IPv6, el NAT es en gran medida innecesario. Dos dispositivos compatibles con IPv6 pueden simplemente enviarse paquetes a sus direcciones, y el único obstáculo es el firewall del host en cada extremo.
Si tienes IPv6 en casa y en tu operador celular, quizá hayas notado que algunas apps conectan más rápido cuando ambos extremos son IPv6: eso es porque todo el baile de «reunir candidatos, sondear pares» tiene menos obstáculos. No hay traducción NAT que descubrir, no se necesita viaje a STUN, solo direcciones directas.
Pero hay un detalle: en 2026 el despliegue global sigue incompleto. Muchos routers domésticos manejan mal IPv6 o no lo manejan. Muchas redes corporativas bloquean IPv6 entrante por defecto. Algunos operadores ofrecen IPv6 en el lado de radio pero hacen puente a IPv4 en otros lados. Las rutas puras de IPv6 a IPv6 existen, pero no se puede confiar en ellas como único mecanismo.
Así que Remio —como toda pila P2P seria— reúne candidatos IPv4 e IPv6 y deja que ICE los ponga a competir. Si existe una ruta IPv6 directa y funciona, normalmente gana en latencia. Si no, toma el relevo IPv4 con hole punching. Si ambos fallan, relay. El usuario nunca ve nada de esto; la conexión simplemente se establece.
Cómo saber qué ruta usa tu sesión
¿Quieres saber en qué ruta terminó tu sesión? El indicador de conexión de Remio muestra el tipo en lenguaje claro: «Directa» para P2P, «Relay» para TURN. El panel de estadísticas para desarrolladores expone todo el estado de WebRTC, incluidos los tipos de candidatos de la pareja nominada (host, srflx, relay) y el RTT medido.
Unas interpretaciones rápidas:
- RTT menor de 5 ms, Directa: estás en la misma LAN que el host. El mejor caso. Se pueden lograr unos 8 ms de procesamiento (el resto es la cadencia de actualización de 60 Hz de tu propia pantalla).
- RTT de 5 a 15 ms, Directa: la misma red Wi-Fi pero con un salto extra de punto de acceso o malla. Sigue siendo excelente.
- RTT de 15 a 80 ms, Directa: estás en una red distinta a la del host y el hole punching funcionó. El P2P por internet está funcionando.
- RTT de 30 a 80 ms, Relay (regional): un NAT simétrico o un NAT de operador derrotó el hole punch. Tomó el relevo un TURN de Cloudflare cercano.
- RTT de 80 a 200 ms, Relay: TURN a una distancia geográfica mayor, o tú y el host están en regiones muy distintas.
Si recurres sistemáticamente al relay incluso en casa, los sospechosos habituales son un módem del proveedor con NAT simétrico, CGNAT IPv4 en tu conexión doméstica (más común de lo que crees en revendedores de fibra) o un firewall excesivamente celoso que bloquea UDP entrante. Nuestra guía para reducir el lag del escritorio remoto repasa los culpables habituales, y la página de conexión directa por LAN es el camino rápido si ambos dispositivos están en tu red.
Cifras de rendimiento del mundo real
Juntando todo, estas son las cifras de latencia que medimos en producción en las distintas rutas que puede tomar una sesión de Remio:
- P2P directo por LAN: 1–5 ms de RTT de red. De extremo a extremo (del evento de entrada a la actualización del píxel): unos 8 ms de procesamiento (el resto es la cadencia de actualización de 60 Hz de tu propia pantalla) con el resto del canal colaborando.
- Wi-Fi de la misma red con saltos extra: 5–10 ms de RTT de red.
- Relay TURN, regional: 30–80 ms de RTT de red.
- Relay TURN, entre regiones: 80–200 ms de RTT de red.
- Celular 4G/5G, P2P con hole punching: 40–100 ms de RTT de red.
Estas coinciden con las cifras de las pruebas de rendimiento de Remio y explican por qué fijamos el umbral LAN frente a WAN en 15 ms de RTT: separa con claridad las rutas directas de cualquier relay (30 ms mínimo) o ruta celular (40 ms mínimo), con muy pocos falsos positivos.
El NAT traversal es uno de esos temas donde los protocolos son simples por separado pero la combinatoria es retorcida. La mayoría de los usuarios nunca necesitará saber que existen ICE, STUN y TURN: solo experimentarán una app que conecta rápido desde cualquier lugar a cualquier lugar. Los protocolos hacen su trabajo cuando no los notas. Cuando sí los notas —una sesión tarda un instante de más, o «Directa» se convierte en «Relay»— ya tienes el modelo mental.
Para saber más sobre el canal nativo de Remio y las decisiones que convierten 1–5 ms de latencia de red en unos 8 ms de procesamiento (el resto es la cadencia de actualización de 60 Hz de tu propia pantalla), mira por qué lo nativo importa. Para el modelo de amenazas en las rutas por relay, mira el documento técnico de seguridad. O simplemente explora las funciones y descarga Remio para verlo funcionar.
