¿Qué es mejor usar al desarrollar software: tecnologías nativas o web? Holivar sobre este tema no terminará pronto, pero pocos argumentarán que es útil duplicar funciones nativas para usar en navegadores o WebView. Y si antes las aplicaciones para llamadas existían exclusivamente por separado del navegador, ahora son fáciles de implementar en la web. El desarrollador Grigory Kuznetsov explicó cómo usar la tecnología WebRTC para las conexiones P2P.
- Como todos saben, en los últimos años hay muchas aplicaciones basadas en el intercambio directo de datos entre dos navegadores, es decir, P2P. Estos son todo tipo de mensajería instantánea, chats, marcadores, videoconferencias. También pueden ser aplicaciones que realizan algún tipo de computación distribuida. Los límites de la fantasía no están limitados de ninguna manera.
¿Cómo hacemos tal tecnología? Imagine que queremos hacer una llamada de un navegador a otro. E imagine qué pasos necesitamos para lograr este objetivo. En primer lugar, parece que la llamada es nuestra imagen, nuestra voz, imagen, y necesitamos tener acceso a los dispositivos multimedia conectados a la computadora: a la cámara y al micrófono. Después de obtener acceso, necesita sus dos navegadores, dos clientes, para encontrarse. Es necesario ayudarlos de alguna manera a conectarse, llegar, transmitir metainformación.
Cuando llegue, debe comenzar a transferir datos en modo P2P, es decir, para garantizar la transmisión de flujos de medios. Tenemos todos los elementos necesarios, estamos listos para implementar nuestra nueva bicicleta genial. Pero esto es una broma, somos ingenieros y entendemos que es costoso, injustificado y arriesgado. Por lo tanto, como ingenieros clásicos, primero pensemos en las soluciones que ya existen.
En primer lugar, la vieja tecnología Adobe Flash que se está muriendo. Ella realmente se está muriendo, y Adobe dejará de apoyarlo para 2020. La tecnología realmente le permitirá acceder a sus dispositivos multimedia, en su interior puede implementar todas las mecánicas necesarias para ayudar a los navegadores a conectarse, para que comiencen a transmitir información P2P, pero inventará su bicicleta nuevamente, porque no hay un estándar único, un enfoque único para implementar este método transferencia de datos
Puedes escribir un complemento de navegador. Así es como funciona Skype para aquellos navegadores que no admiten tecnologías más modernas. Tendrá que implementar su bicicleta, porque no hay un estándar único, y también es malo para los usuarios, ya que el usuario tendrá que instalar algún tipo de complemento en su navegador, realizar acciones adicionales. A los usuarios no les gusta esto y no quieren hacerlo.
Y hay tecnología WebRTC: Google Hangouts, Facebook Messenger trabajan con ella. Voximplant lo usa para que pueda hacer sus llamadas. Analicemos con más detalle. Esta es una nueva tecnología en desarrollo, apareció en 2011 y continúa desarrollándose. ¿Qué le permite hacer ella? Obtenga acceso a la cámara y al micrófono. Establezca una conexión P2P entre dos computadoras, dos navegadores. Naturalmente, le permite transferir transmisiones de medios en tiempo real. Además, le permite transferir información, es decir, cualquier fecha binaria, también puede transmitir P2P, puede hacer su propio sistema informático distribuido.
Un punto importante: WebRTC no proporciona a los navegadores una forma de encontrarse. Podemos generar toda la metainformación necesaria sobre nuestros seres queridos, pero ¿cómo puede un navegador aprender sobre la existencia de otro? ¿Cómo conectarlos? Considera un ejemplo.
Hay dos clientes El primer cliente quiere hacer una llamada al segundo cliente. WebRTC le brinda toda la información que necesita para identificarse. Pero la pregunta sigue siendo cómo encontrar otro navegador, cómo enviar esta metainformación, cómo inicializar la llamada. Esto está a merced de los desarrolladores, podemos usar absolutamente cualquier método, tomar esta metainformación, imprimirla en una hoja de papel, enviarla por mensajería, otra la usará y todo funcionará.
Y podemos encontrar algún mecanismo de señalización. En este caso, este es un mecanismo de terceros que nos permitirá, si conocemos a nuestros clientes, garantizar la transferencia entre ellos de la información necesaria para establecer una conexión.
Considere un ejemplo usando un servidor de señal. Hay un servidor de señal que mantiene una conexión constante con nuestros clientes, por ejemplo, a través de sockets web o usando HTTP. El primer cliente genera metainformación y la envía al servidor de señales mediante sockets web o HTTP. También envía una parte de la información con la que desea conectarse, por ejemplo, un apodo o alguna otra información.
El servidor de señales que usa este identificador determina qué cliente necesita redirigir nuestra metainformación y la reenvía. El segundo cliente lo toma, lo usa, se instala, forma una respuesta y, utilizando el mecanismo de señalización, lo envía al servidor de señal, que a su vez lo transmite al primer cliente. Por lo tanto, ambos clientes tienen actualmente toda la fecha y metainformación necesarias para establecer una conexión P2P. Listo
Echemos un vistazo más de cerca a lo que intercambian exactamente los clientes; están intercambiando un datagrama SDP, Protocolo de descripción de sesión.
Este es esencialmente un archivo de texto que contiene toda la información necesaria para establecer una conexión. Hay información sobre la dirección IP, sobre los puertos que se usan, sobre qué tipo de información se está persiguiendo entre clientes, qué es: audio, video, qué códecs se usan. Todo lo que necesitamos está ahí.
Presta atención a la segunda línea. Muestra la dirección IP del cliente, 192.168.0.15. Obviamente, esta es la dirección IP de una computadora que está en alguna red local. Si tenemos dos computadoras, cada una de las cuales está en la red local, cada una de las cuales conoce su dirección IP dentro de esta red, quieren llamar. ¿Serán capaces de hacer esto con tal datagrama? Obviamente no, no conocen las direcciones IP externas. Como ser
Hagamos a un lado y veamos cómo funciona NAT. En Internet, muchas computadoras están ocultas detrás de los enrutadores. Hay redes locales dentro de las cuales las computadoras conocen sus direcciones, hay un enrutador que tiene una dirección IP externa y todas estas computadoras se destacan con la dirección IP de este enrutador. Cuando un paquete de una computadora en la red local va al enrutador, el enrutador mira a dónde debe reenviarse. Si se encuentra en otra de esta red local, simplemente la retransmite, y si necesita enviarla al exterior, a Internet, se compila una tabla de enrutamiento.
Completamos la dirección IP interna de la computadora que desea reenviar el paquete, su puerto, establecer la dirección IP externa, la dirección IP del enrutador y también hacer un cambio de puerto. Para que sirve Imagine que dos computadoras están accediendo al mismo recurso, y necesitamos enrutar correctamente los paquetes de respuesta. Los identificaremos por puerto, el puerto será único para cada una de las computadoras, mientras que la dirección IP externa coincidirá.
¿Cómo vivir si hay NAT, si las computadoras sobresalen bajo la misma dirección IP, pero en el interior se conocen entre sí?
El marco ICE para el establecimiento de conectividad a Internet viene al rescate. Describe formas de omitir NAT, cómo establecer una conexión si tenemos NAT.
Este marco utiliza el llamado atributo del servidor STUN.
Este es un servidor tan especial, en referencia al cual, puede encontrar su dirección IP externa. Por lo tanto, en el proceso de establecer una conexión P2P, cada cliente debe realizar una solicitud a este servidor STUN para averiguar su dirección IP y generar información adicional, IceCandidate e intercambiar IceCandidate con el mecanismo de señalización. Luego, los clientes se conocerán unos a otros con las direcciones IP correctas y podrán establecer una conexión P2P.
Sin embargo, hay casos más complicados. Por ejemplo, cuando la computadora está oculta detrás del doble NAT. En este caso, el marco ICE requiere el uso de un servidor TURN.
Este es un servidor tan especial que convierte una conexión cliente-cliente, P2P, en una conexión cliente-servidor-cliente, es decir, actúa como un relé. La buena noticia para los desarrolladores es que, independientemente de cuál de los tres escenarios se realizó la conexión, si estamos en la red local, si necesitamos recurrir a un servidor STUN o TURN, la tecnología API será idéntica para nosotros. Simplemente indicamos al principio la configuración de los servidores ICE y TURN, indicamos cómo acceder a ellos, y luego la tecnología hace todo por nosotros bajo el capó.
Un breve resumen Para establecer una conexión, debe seleccionar e implementar algún tipo de mecanismo de señalización, un cierto intermediario que nos ayudará a enviar metainformación. WebRTC nos dará todo el meta necesario para esto.
Tenemos que luchar con NAT, este es nuestro principal enemigo en esta etapa. Pero para evitarlo, usamos el servidor STUN para averiguar nuestra dirección IP externa, y usamos el servidor TURN como un relé.
¿Qué estamos transmitiendo exactamente? Sobre las transmisiones de medios.
Las transmisiones multimedia son canales que contienen pistas dentro de sí mismos. Las pistas dentro del flujo de medios están sincronizadas. El audio y el video no divergirán, vendrán con un solo momento. Puede hacer cualquier cantidad de pistas dentro de la transmisión de medios, las pistas se pueden controlar por separado, por ejemplo, puede silenciar el audio, dejando solo una imagen. También puede transferir cualquier cantidad de transmisiones multimedia, lo que le permite, por ejemplo, implementar una conferencia.
¿Cómo acceder a los medios desde un navegador? Hablemos de la API.
Hay un método getUserMedia que acepta un conjunto de constantes como entrada. Este es un objeto especial donde usted indica a qué dispositivos desea acceder, qué cámara, qué micrófono. Usted especifica las características que desea tener, qué resolución, y también hay dos argumentos: successCallback y errorCallback, que se llama en caso de éxito o falla. Las implementaciones de tecnología más modernas usan promesas.
También hay un método conveniente enumerateDevices que devuelve una lista de todos los dispositivos multimedia conectados a su computadora, que le brinda la oportunidad de mostrárselos al usuario, dibuje algún tipo de selector para que el usuario elija qué cámara en particular quiere usar.
El objeto central en la API es RTCPeerConnection. Cuando hacemos la conexión, tomamos la clase RTCPeerConnection, que devuelve el objeto peerConnection. Como configuración, especificamos un conjunto de servidores ICE, es decir, servidores STUN y TURN, a los que accederemos durante el proceso de instalación. Y hay un evento onicecandidate importante que se dispara cada vez que necesitamos la ayuda de nuestro mecanismo de señalización. Es decir, la tecnología WebRTC realizó una solicitud, por ejemplo, a un servidor STUN, reconocimos nuestra dirección IP externa, apareció un nuevo candidato a ICEC y necesitamos reenviarlo utilizando un mecanismo de terceros, el evento fue más difícil.
Cuando establecemos una conexión y queremos inicializar la llamada, utilizamos el método createOffer () para formar el SDP inicial, ofrecer SDP, la misma metainformación que debe enviarse al socio.
Para establecerlo en PeerConnection, utilizamos el método setLocalDescription (). El interlocutor recibe esta información mediante el mecanismo de señalización, la establece a sí mismo utilizando el método setRemoteDescription () y genera una respuesta utilizando el método createAnswer (), que también se envía al primer cliente utilizando el mecanismo de señalización.
Cuando obtuvimos acceso a los medios, obtuvimos el flujo de medios, lo transferimos a nuestra conexión P2P utilizando el método addStream, y nuestro interlocutor se entera de que tiene el evento onaddstream cortado. Recibirá nuestra transmisión y podrá mostrarla.
También puede trabajar con flujos de datos. Es muy similar a formar una peerConnection regular, solo especifique RtpDataChannels: true y llame al método createDataChannel (). No me detendré en esto en detalle, porque dicho trabajo es muy similar a trabajar con sockets web.
Algunas palabras sobre seguridad. WebRTC solo funciona en HTTPS, su sitio debe estar firmado con un certificado. Las transmisiones multimedia también están encriptadas, utilizando DTLS. La tecnología no requiere la instalación de nada adicional, sin complementos, y eso es bueno. Y no funcionará para hacer una aplicación de software espía, el sitio no escuchará ni espía al usuario, le mostrará al usuario un aviso especial, le solicitará acceso y lo recibirá solo si el usuario permite el acceso a dispositivos de audio y medios.
En cuanto a la compatibilidad con el navegador, IE permanece y permanece rojo. A fines del año pasado, se agregó el soporte de Safari, es decir, todos los navegadores modernos ya pueden trabajar con esta tecnología y podemos usarla de manera segura.
Quiero compartir un conjunto de todo tipo de utilidades que lo ayudarán si desea trabajar con WebRTC. Esto es principalmente un
adaptador . Las tecnologías están en constante evolución, y hay una diferencia en las API del navegador. La biblioteca de adaptadores elimina esta diferencia y facilita el trabajo. Una biblioteca conveniente para trabajar con flujos de datos es
Peerjs . También puede ver las implementaciones de código abierto de los
servidores STUN y
TURN . Hay un gran conjunto de tutoriales, ejemplos y artículos en la
página impresionante-webrtc , lo recomiendo encarecidamente.
La última herramienta útil para la depuración es webrtc-internals. Durante el desarrollo, puede escribir un comando especial en la barra de direcciones; por ejemplo, en el navegador Chrome, este es Chrome: // webrtc-internals. Verá una página con toda la información sobre su conexión WebRTC actual. Habrá secuencias de llamadas en los métodos y todos los datagramas intercambiados entre navegadores y gráficos que de alguna manera caracterizan su conexión. En general, habrá toda la información que se necesitará durante la depuración y el desarrollo. Gracias por su atencion