Cómo funciona JS: comunicaciones WebRTC y P2P

Hoy publicamos una traducción de la parte 18 de una serie de materiales dedicados a todo lo relacionado con JavaScript. Aquí hablaremos sobre la tecnología WebRTC, que tiene como objetivo organizar el intercambio directo de datos entre las aplicaciones del navegador en tiempo real.

Revisar

¿Qué es WebRTC? Para empezar, vale la pena decir que la abreviatura RTC significa comunicación en tiempo real (comunicación en tiempo real). Esto solo brinda mucha información sobre esta tecnología.

WebRTC ocupa un nicho muy importante entre los mecanismos de la plataforma web. Anteriormente, las tecnologías P2P (redes punto a punto, conexiones punto a punto, redes punto a punto, punto a punto) utilizadas por aplicaciones como los chats de escritorio les brindaban oportunidades que los proyectos web no tenían. WebRTC marca la diferencia para las tecnologías web.

WebRTC, si consideramos esta tecnología en términos generales, permite que las aplicaciones web creen conexiones P2P, que discutiremos a continuación. Además, cubriremos los siguientes temas aquí para mostrar la imagen completa de la estructura interna de WebRTC:

• Comunicaciones P2P.
• Cortafuegos y tecnología NAT Traversal.
• Señalización, sesiones y protocolos.
• API de WebRTC

Comunicaciones P2P

Supongamos que dos usuarios han lanzado, cada uno en su propio navegador, una aplicación que le permite organizar un chat de video usando WebRTC. Quieren establecer una conexión P2P. Después de tomar la decisión, necesitamos un mecanismo que permita a los navegadores de los usuarios encontrarse y establecer comunicación teniendo en cuenta los mecanismos de protección de la información disponibles en los sistemas. Después de establecer una conexión, los usuarios podrán intercambiar información multimedia en tiempo real.

Una de las principales dificultades asociadas con las conexiones P2P del navegador es que los navegadores primero necesitan descubrirse entre sí y luego establecer una conexión de red basada en sockets para proporcionar transferencia de datos bidireccional. Sugerimos discutir las dificultades asociadas con la instalación de tales conexiones.

Cuando una aplicación web necesita algunos datos o recursos, los descarga del servidor y eso es todo. La dirección del servidor es conocida por la aplicación. Si estamos hablando, por ejemplo, de crear un chat P2P, cuya operación se basa en la conexión directa de los navegadores, las direcciones de estos navegadores no se conocen de antemano. Como resultado, para establecer una conexión P2P, tendrá que lidiar con algunos problemas.

Cortafuegos y protocolo transversal NAT

Las computadoras ordinarias, por regla general, no tienen direcciones IP externas estáticas asignadas a ellas. La razón de esto es que tales computadoras generalmente están ubicadas detrás de firewalls y dispositivos NAT.

NAT es un mecanismo que traduce las direcciones IP locales internas ubicadas detrás de un firewall en direcciones IP globales externas. La tecnología NAT se utiliza, en primer lugar, por razones de seguridad y, en segundo lugar, debido a las restricciones impuestas por IPv4 en la cantidad de direcciones IP globales disponibles. Es por eso que las aplicaciones web que usan WebRTC no deberían basarse en el hecho de que el dispositivo actual tiene una dirección IP estática global.

Veamos cómo funciona NAT. Si está en una red corporativa y está conectado a WiFi, a su computadora se le asignará una dirección IP que solo existe detrás de su dispositivo NAT. Supongamos que esta es la dirección IP 172.0.23.4. Sin embargo, para el mundo exterior, su dirección IP puede parecer 164.53.27.98. Como resultado, el mundo exterior considera que sus solicitudes provienen de la dirección 164.53.27.98, pero gracias a NAT, las respuestas a las solicitudes realizadas por su computadora a servicios externos se enviarán a su dirección interna 172.0.23.4. Esto sucede usando tablas de traducción. Tenga en cuenta que además de la dirección IP, también se requiere un número de puerto para la conexión en red.

Dado que NAT está involucrado en el proceso de interacción de su sistema con el mundo exterior, su navegador, para establecer una conexión WebRTC, necesita conocer la dirección IP de la computadora en la que se está ejecutando el navegador que desea comunicar.

Aquí es donde los servidores STUN (Session Traversal Utilities for NAT) y TURN (Traversal Using Relys around NAT) entran en escena. Para garantizar el funcionamiento de la tecnología WebRTC, primero se realiza una solicitud al servidor STUN para averiguar su dirección IP externa. De hecho, estamos hablando de una solicitud hecha a un servidor remoto para averiguar desde qué dirección IP el servidor recibe esta solicitud. Habiendo recibido una solicitud similar, el servidor remoto enviará una respuesta que contiene la dirección IP visible para él.

Basado en el supuesto de que este esquema es operativo y que recibió información sobre su dirección IP y puerto externos, puede informar a otros participantes en el sistema (los llamaremos pares) sobre cómo contactarlo directamente. Estos pares también pueden hacer lo mismo usando los servidores STUN o TURN y pueden decirle qué direcciones se les asignan.

Señalización, sesiones y protocolos.

El proceso de encontrar la información de red descrita anteriormente es una de las partes de un gran sistema de señalización que, en el caso de WebRTC, se basa en el estándar JSEP (Protocolo de establecimiento de sesión de JavaScript). La señalización incluye descubrimiento de recursos de red, creación y administración de sesiones, seguridad de comunicación, coordinación de parámetros de medios, manejo de errores.

Para que la conexión funcione, los pares deben acordar los formatos de datos que intercambiarán y recopilar información sobre las direcciones de red de la computadora en la que se ejecuta la aplicación. El mecanismo de señalización para compartir esta información crítica no forma parte de la API de WebRTC.

La señalización no está definida por el estándar WebRTC, y no está implementada en su API para proporcionar flexibilidad en las tecnologías y protocolos utilizados. La señalización y los servidores que la soportan son responsabilidad del desarrollador de la aplicación WebRTC.

Basado en el supuesto de que su aplicación WebRTC que se ejecuta en el navegador puede determinar la dirección IP externa del navegador utilizando STUN, como se describió anteriormente, el siguiente paso es analizar los parámetros de la sesión y establecer una conexión con otro navegador.

La discusión inicial de los parámetros de sesión y el establecimiento de una conexión se realiza utilizando un protocolo de señalización / comunicación especializado en comunicaciones multimedia. Este protocolo, además, es responsable de cumplir con las reglas bajo las cuales se administra y finaliza la sesión.

Uno de estos protocolos se llama SIP (Protocolo de inicio de sesión). Tenga en cuenta que debido a la flexibilidad del subsistema de señalización WebRTC, SIP no es el único protocolo de señalización que se puede utilizar. El protocolo de señalización seleccionado, además, debe funcionar con un protocolo de capa de aplicación llamado SDP (Protocolo de descripción de sesión), que se utiliza cuando se usa WebRTC. Todos los metadatos relacionados con los datos multimedia se transmiten utilizando el protocolo SDP.

Cualquier par (es decir, una aplicación que utiliza WebRTC) que intenta ponerse en contacto con otro par genera un conjunto de rutas candidatas para el protocolo ICE (Establecimiento de conectividad interactiva). Los candidatos representan una combinación de dirección IP, puerto y protocolo de transporte que se pueden usar. Tenga en cuenta que una computadora puede tener muchas interfaces de red (cableadas, inalámbricas, etc.), por lo que se le pueden asignar varias direcciones IP, una para cada interfaz.

Aquí hay un diagrama con MDN que ilustra el proceso anterior de intercambio de datos.

El proceso de intercambio de datos necesarios para establecer una conexión P2P

Establecer una conexión

Cada par primero descubre su dirección IP externa como se describe anteriormente. Luego, se crean dinámicamente "canales" de datos de señalización, que sirven para detectar pares y apoyar el intercambio de datos entre ellos, para discutir los parámetros de sesión y su instalación.

Estos "canales" son desconocidos e inaccesibles para el mundo exterior, se requiere un identificador único para acceder a ellos.

Tenga en cuenta que debido a la flexibilidad de WebRTC y al hecho de que el proceso de señalización no está definido por el estándar, el concepto de "canales" y el orden de su uso pueden variar ligeramente según las tecnologías utilizadas. De hecho, algunos protocolos no requieren un mecanismo de "canal" para organizar el intercambio de datos. A los fines de este material, suponemos que se utilizan los "canales" en la implementación del sistema.

Si dos o más pares están conectados al mismo "canal", los pares tienen la oportunidad de intercambiar datos y discutir información de la sesión. Este proceso es similar a una plantilla de editor-suscriptor . En general, el par que inicia la conexión envía una "oferta" utilizando un protocolo de señalización como SIP o SDP. El iniciador espera recibir una "respuesta" del destinatario de la propuesta, que está conectada al "canal" considerado.

Después de recibir la respuesta, se lleva a cabo el proceso de determinar y discutir los mejores candidatos de ICE recolectados por cada fiesta. Después de seleccionar los candidatos ICE óptimos, se acuerdan los parámetros de datos que se intercambiarán entre pares y el mecanismo de enrutamiento de la red (dirección IP y puerto).

Luego, se establece una sesión de socket de red activa entre pares. Además, cada par crea flujos de datos locales y puntos finales de canales de datos, y la transmisión bidireccional de datos multimedia comienza a usar la tecnología aplicada.

Si el proceso de negociación para elegir el mejor candidato de ICE no tiene éxito, lo que a veces ocurre debido a la falla de los cortafuegos y los sistemas NAT, se usa una opción de respaldo, que consiste en usar, como un relé, un servidor TURN. Este proceso involucra un servidor que actúa como intermediario que transmite los datos intercambiados entre pares. Tenga en cuenta que este esquema no es una conexión P2P real en la que los pares transmiten datos directamente entre sí.

Cuando se utiliza una reserva con TURN para el intercambio de datos, cada par ya no necesita saber cómo comunicarse con los demás y cómo transferirle datos. En cambio, los pares necesitan saber qué servidor TURN externo necesita enviar datos multimedia en tiempo real y desde qué servidor deben recibir durante la sesión de comunicación.

Es importante comprender que ahora era una forma alternativa de organizar las comunicaciones. Los servidores TURN deben ser muy confiables, tener un gran ancho de banda y una gran potencia de cómputo, admitir el trabajo con cantidades potencialmente grandes de datos. El uso de un servidor TURN, por lo tanto, obviamente conlleva costos adicionales y un aumento en la complejidad del sistema.

API de WebRTC

Hay tres categorías principales de API que existen en WebRTC:

• La API de captura y transmisión de medios es responsable de la captura y transmisión de medios. Esta API le permite conectarse a dispositivos de entrada, como micrófonos y cámaras web, y recibir transmisiones multimedia de ellos.
• API RTCPeerConnection Usando la API de esta categoría, es posible, desde un punto final de WebRTC, enviar, en tiempo real, la secuencia capturada de datos de audio o video a través de Internet a otro punto final de WebRTC. Con esta API, puede crear conexiones entre la máquina local y el par remoto. Proporciona métodos para conectarse a un par remoto, para administrar la conexión y para monitorear su estado. Sus mecanismos se utilizan para cerrar conexiones innecesarias.
• RTCDataChannel API Los mecanismos representados por esta API permiten la transferencia de datos arbitrarios. Cada canal de datos está asociado con una interfaz RTCPeerConnection.

Hablemos de estas API.

API Media Capture y Streams

Media Capture and Streams API, a menudo denominada Media Stream API o Stream API, es una API que admite trabajar con flujos de datos de audio y video, métodos para trabajar con ellos. Usando esta API, puede establecer restricciones relacionadas con los tipos de datos, aquí hay devoluciones de llamada para completar con éxito y sin éxito las operaciones que se utilizan cuando se utilizan mecanismos asincrónicos para trabajar con datos y eventos que se generan durante la operación.

El método getUserMedia() de la API getUserMedia() le pide al usuario permiso para trabajar con dispositivos de entrada que producen transmisiones MediaStream con pistas de audio o video que contienen los tipos de medios solicitados. Dicha transmisión puede incluir, por ejemplo, una pista de video (su fuente es una fuente de video virtual o de hardware, como una cámara, una grabadora de video, un servicio para compartir pantalla, etc.), una pista de audio (las fuentes de audio físicas o virtuales pueden formarla de manera similar, como un micrófono, un convertidor de analógico a digital, etc.) y posiblemente otros tipos de pistas.

Este método devuelve la promesa que se resuelve en el objeto MediaStream . Si el usuario rechaza la solicitud de permiso o el medio correspondiente no está disponible, la promesa se resolverá, respectivamente, con un NotFoundError PermissionDeniedError o NotFoundError .

Puede acceder al Singleton de MediaDevice través del objeto navigator :

 navigator.mediaDevices.getUserMedia(constraints) .then(function(stream) { /*   */ }) .catch(function(err) { /*   */ }); 

Tenga en cuenta que cuando llama al método getUserMedia() , debe pasarle un objeto de constraints que le indique a la API qué tipo de flujo debe devolver. Aquí puede configurar muchas cosas, incluida la cámara que desea usar (frontal o posterior), velocidad de fotogramas, resolución, etc.

A partir de la versión 25, los navegadores basados ​​en Chromium permiten la transferencia de datos de audio de getUserMedia() elementos de audio o video (sin embargo, tenga en cuenta que, por defecto, los elementos multimedia estarán deshabilitados).

El método getUserMedia() también se puede usar como un nodo de entrada para la API de audio web :

 function gotStream(stream) {   window.AudioContext = window.AudioContext || window.webkitAudioContext;   var audioContext = new AudioContext();   //  AudioNode     var mediaStreamSource = audioContext.createMediaStreamSource(stream);   //       ,    ,   //       !   mediaStreamSource.connect(audioContext.destination); } navigator.getUserMedia({audio:true}, gotStream); 

Limitaciones relacionadas con la protección de la información personal.

La captura no autorizada de datos de un micrófono o cámara es una interferencia grave con la vida personal del usuario. Por lo tanto, el uso de getUserMedia() proporciona la implementación de requisitos muy específicos para notificar al usuario sobre lo que está sucediendo y para administrar los permisos. El método getUserMedia() siempre debe obtener el permiso del usuario antes de abrir cualquier dispositivo de entrada que recopile medios, como una cámara web o un micrófono. Los navegadores pueden ofrecer la opción de una configuración de permiso única para un dominio, pero deben solicitar permiso al menos la primera vez que acceden a dispositivos de medios, y el usuario debe otorgar explícitamente dicho permiso.

Además, las reglas relacionadas con la notificación al usuario sobre lo que está sucediendo son importantes aquí. Los navegadores deben mostrar un indicador que indique el uso de un micrófono o una cámara. La visualización de dicho indicador no depende de la presencia en el sistema de indicadores de hardware que indiquen el funcionamiento de dichos dispositivos. Además, los navegadores deben mostrar un indicador de que se ha otorgado permiso para usar el dispositivo de entrada, incluso si el dispositivo no se usa en algún momento para registrar datos relevantes.

Interfaz RTCPeerConnection

La interfaz RTCPeerConnection es una conexión WebRTC entre la computadora local y el par remoto. Proporciona métodos para conectarse a un sistema remoto, para soportar la conexión y monitorear su estado, y para cerrar la conexión después de que ya no sea necesaria.

Aquí hay un diagrama de arquitectura WebRTC que demuestra el papel de RTCPeerConnection.


RTCPeerConnection Role

Desde una perspectiva de JavaScript, el conocimiento principal que se puede extraer del análisis de este diagrama es que RTCPeerConnection abstrae al desarrollador web de mecanismos complejos ubicados en niveles más profundos del sistema. Los códecs y protocolos utilizados por WebRTC hacen un gran trabajo para permitir el intercambio de datos en tiempo real, incluso cuando se utilizan redes no confiables. Estas son algunas de las tareas resueltas por estos mecanismos:

• Pérdida de paquetes de enmascaramiento.
• Cancelación de eco.
• Adaptación de ancho de banda.
• Búfer dinámico para eliminar la fluctuación de fase.
• Control automático de volumen.
• Reducción de ruido y supresión.
• "Limpiando" la imagen.

RTCDataChannel API

Al igual que con los datos de audio y video, WebRTC admite la transmisión en tiempo real de otros tipos de datos. La API RTCDataChannel le permite organizar un intercambio P2P de datos arbitrarios.

Hay muchos escenarios para usar esta API. Aquí hay algunos de ellos:

• Juegos
• Chats de texto en tiempo real.
• Transferencia de archivos.
• Organización de redes descentralizadas.

Esta API está dirigida al uso más eficiente de las capacidades de la API RTCPeerConnection y le permite organizar un sistema de intercambio de datos potente y flexible en un entorno P2P. Entre sus características están las siguientes:

• Trabajo efectivo con sesiones usando RTCPeerConnection.
• Soporte para múltiples canales de comunicación utilizados simultáneamente con priorización.
• Soporte para métodos confiables y poco confiables de entrega de mensajes.
• Gestión de seguridad incorporada (DTLS) y congestión.

La sintaxis aquí es similar a la utilizada cuando se trabaja con la tecnología WebSocket. El método send() y el evento de message se aplican aquí:

 var peerConnection = new webkitRTCPeerConnection(servers,   {optional: [{RtpDataChannels: true}]} ); peerConnection.ondatachannel = function(event) {   receiveChannel = event.channel;   receiveChannel.onmessage = function(event){       document.querySelector("#receiver").innerHTML = event.data;   }; }; sendChannel = peerConnection.createDataChannel("sendDataChannel", {reliable: false}); document.querySelector("button#send").onclick = function (){   var data = document.querySelector("textarea#send").value;   sendChannel.send(data); } 

WebRTC en el mundo real

En el mundo real, la comunicación WebRTC requiere servidores. Los sistemas no son demasiado complicados; gracias a ellos, se implementa la siguiente secuencia de acciones:

• Los usuarios se descubren e intercambian información unos de otros, por ejemplo, nombres.
• Las aplicaciones de cliente WebRTC (pares) intercambian información de red.
• Los pares intercambian información sobre datos multimedia, como el formato y la resolución de video.
• Las aplicaciones de cliente WebRTC establecen una conexión que pasa por alto las puertas de enlace NAT y los firewalls.

En otras palabras, WebRTC necesita cuatro tipos de funciones de servidor:

• Medios para descubrir usuarios y organizar su interacción.
• Señalización
• Omitir NAT y firewalls.
• Servidores de retransmisión utilizados cuando no se puede establecer una conexión P2P.

El protocolo STUN y su extensión TURN son utilizados por ICE para permitir que RTCPeerConnection funcione con mecanismos de derivación NAT y para hacer frente a otras dificultades encontradas al transmitir datos a través de una red.

Como ya se mencionó, ICE es un protocolo para conectar pares, como dos clientes de video chat. Al comienzo de la sesión de comunicación, ICE intenta conectar pares directamente, con el menor retraso posible, a través de UDP. Durante este proceso, los servidores STUN tienen una única tarea: permitir que los pares detrás de NAT conozcan su dirección pública y puerto. Eche un vistazo a esta lista de servidores STUN disponibles (Google también tiene dichos servidores).


Servidores STUN

Detección de candidatos de ICE

Si no se puede establecer la conexión UDP, ICE intenta establecer una conexión TCP: primero, a través de HTTP, luego, a través de HTTPS. Si no se puede establecer una conexión directa, en particular, debido a la incapacidad de eludir los NAT y firewalls corporativos, ICE utiliza un intermediario (retransmisión) en forma de servidor TURN. En otras palabras, ICE primero intentará usar STUN con UDP para la conexión directa de sus pares, y si esto no funciona, usará una opción alternativa con un inquilino en forma de servidor TURN. El término "búsqueda de candidatos" se refiere al proceso de búsqueda de interfaces de red y puertos.


Encontrar interfaces de red y puertos adecuados

Seguridad

Las aplicaciones de comunicaciones en tiempo real o los complementos relacionados pueden generar problemas de seguridad. En particular, estamos hablando de lo siguiente:

• Los datos de medios no cifrados u otros datos pueden ser interceptados a lo largo de la ruta entre navegadores, o entre un navegador y un servidor.
• Una aplicación puede, sin el conocimiento del usuario, grabar y transmitir datos de video y audio a un atacante.
• Junto con un complemento o aplicación de aspecto inofensivo, un virus u otro software malicioso puede llegar a la computadora del usuario.

WebRTC tiene varios mecanismos diseñados para hacer frente a estas amenazas:

• Las implementaciones de WebRTC utilizan protocolos seguros como DTLS y SRTP .
• Para todos los componentes de los sistemas WebRTC, el uso del cifrado es obligatorio. Esto también se aplica a los mecanismos de señalización.
• WebRTC no es un complemento. Los componentes de WebRTC se ejecutan en el entorno limitado del navegador y no en un proceso separado. Los componentes se actualizan cuando se actualiza el navegador.
• El acceso a la cámara y al micrófono debe darse explícitamente. Y, cuando se usa una cámara o un micrófono, este hecho se muestra claramente en la interfaz de usuario del navegador.

Resumen

WebRTC es una tecnología muy interesante y poderosa para proyectos que utilizan la transferencia de cualquier información entre navegadores en tiempo real. El autor del material dice que su empresa, SessionStack , utiliza mecanismos tradicionales para intercambiar datos con los usuarios, lo que implica el uso de servidores. Sin embargo, si usaran WebRTC para resolver los problemas correspondientes, esto permitiría organizar el intercambio de datos directamente entre los navegadores, lo que reduciría el retraso en la transferencia de datos y reduciría la carga en la infraestructura de la compañía.

Estimados lectores! ¿Utiliza la tecnología WebRTC en sus proyectos?