Últimamente esta muy en boca las nuevas características de conexión p2p entre navegadores. Es decir, un browser se comunica directamente con otro, sin necesidad de servidores que intervengan durante todo el ciclo de la comunicación, solo para determinadas tareas, normalmente el inicio del dialogo entre los navegadores. Dichas características se están empleando sobre todo para realizar streaming de contenido multimedia entre navegadores. ¿Pero como es posible dicha mágia?.
Para establecer una conexión de un punto a otro, en redes IP, necesitamos una dirección, un puerto, un protocolo (TCP o UDP normalmente) y dos participantes, el iniciador o cliente y el que escucha (listener). El listener estará escuchando por un puerto y cuando el iniciador se conecte a el, empezara una serie de intercambios de información entre el iniciador y el listener. Esta es la teoría conocida por todos en conexiones punto a punto. ¿Cual es el problema?, que Internet hace tiempo que dejo de ser una topología de IPs donde todas se veían entre todas.
A día de hoy la arquitectura predominante, por motivos de seguridad y de economía de direcciónes IP, son las subredes detras de routers haciendo NAT.
Es decir, que una conexión p2p desde el cliente 1 al cliente 3 que esté detras de un NAT, es complicado a no ser que abramos puertos en el NAT que apunten directamente al cliente, haciendo la traslación de red.
En la anterior figura, si un iniciador quiere conectarse al cliente 1, puerto 80, tendrá que conectarse en realidad a la IP 80.80.80.43, tambien llamada IP pública ya que el router, en su configuración NAT, todo que llege al puerto 80 por la IP pública lo enrutará a la IP del cliente 1, al puerto 80 u otro puerto.
Entonces, en una arquitectura así, ¿como es posible realizar p2p?. Si alguien ha trasteado con los tipicos clientes p2p, como torrent o emule, para tener la máxima velocidad habrán tenido que “abrir los puertos” en el router, es decir, configurar el NAT del router. Esta solución es un poco inviable ya que por cada aplicación que quiera usar las características p2p, deberíamos abrir un puerto en el router con los consiguientes problemas de administración de la red. Existen otras soluciónes más dinámicas y normalmente se trata de “engañar” al router. Para engañar al router se suelen seguir varias estrategias en función de si uno o los dos clientes están detras de un NAT.
Un cliente con IP pública y otro detras de NAT.
En este caso un dispositivo conectado a internet con una IP pública intenta establecer una conexión p2p con un dispositivo detras de un NAT y no puede ya que la IP privada no es accesible desde internet. Como no queremos abrir puertos en el NAT, se suele recurrir a una conexión pasiva con ayuda de un tercero.
En el dibujo se puede ver como el dispositivo recurre a ayuda de un tercer, un servidor, para anunciar su disponibilidad de servicio, manteniendo una conexión con el servidor.
Cuando el dispositivo cliente o iniciador quiere conectarse, lanza la petición al servidor y el servidor comunica al listener que abra una conexión con el cliente. En el momento que el cliente detecta dicha conexión de entrada, empieza el intercambio de información como si la conexión la hubiese abierto el.
Dos clientes detras de NAT
Este es el escenario más habitual y más complejo de resolver, aunque a día de hoy ya con exito.
Dos dispositivos detras de NAT, con lo cual ninguno puede abrir una conexión con el otro. En este caso vamos a empezar en como se resuelve cuando queremos usar el protocolo UDP, el cual no está orientado a conexión, no garantiza la recepción ni el orden de llegada de los paquetes y es mas rápido, por lo tanto candidato ideal para hacer streaming donde no importa perder paquetes ni el orden, ya que como mucho tendremos peor calidad, pero seguiremos manteniendo la comunicación en tiempo real y con baja latencia.
UDP Hole Punching
Esta palabreja (UDP Hole Punching) nombra una técnica donde los dos clientes mantienen una conexión activa UDP anunciándose en un servidor Rendezvous o de citas. En el momento que un dispositivo quiere abrir una conexión p2p, preguntará al servidor Rendezvous su IP pública y empezará a inyectar paquetes por dicha conexión suplantando al servidor Rendezvous.
La técnica tiene su intriga pero puede verse más información en esta url donde describen los pasos para saber si los dos dispositivos están detras del mismo NAT o no y diferentes tecnicas.
http://www.brynosaurus.com/pub/net/p2pnat/
Servidor STUN y STUNT
Un servidor STUN (Simple traversal of User Datagram Protocol) es simplemente un servidor rendezvous descrito en el punto anterior, pero estandarizado bajo la norma RFC 3489. STUNT, con T al final, es lo mismo pero aceptando el protocolo TCP, pero no suele ser muy habitual.
Por tanto, y volviendo al tema original, esta claro que si queremos conseguir una comunicación de browser a brwoser, necesitaremos un servidor STUN, entre otras cosas.
Y para que sirve todo esto
Hoy en dia existe una corriente muy fuerte para llevar el p2p al navegador y ya se van viendo proyectos donde usan dicha técnica para poder comunicarse, como pro ejemplo WebRTC
Este proyecto está basado sobre todo en la transmisión multimedia, con lo que dentro de su arquitectura ya contempla diferentes codecs de audio y video.
Si nos fijamos en la capa de transporte, sección p2p, veremos STUN, además de una extensión llamada TURN y ICE, un protocolo de agentes que se apoyan en STUN/TURN.
Espero que con esta pequeña introducción ya no sea tan mágico como funciona las conexiones p2p hoy en día.