¿Cómo funciona WebRTC?

Question

Me interesan las conexiones punto a punto en el navegador. Dado que esto parece ser posible con WebRTC, me pregunto cómo funciona exactamente.

He leído algunas explicaciones y vi diagramas al respecto y ahora está claro para mí que el establecimiento de la conexión funciona sobre el servidor. El servidor parece intercambiar algunos datos entre el cliente que están dispuestos a conectarse entre sí, para que puedan iniciar una conexión directa, que es independiente del servidor.

Pero eso es exactamente lo que no entiendo. Hasta ahora, pensaba que la única forma de crear conexiones es escuchar en un puerto en la computadora A y conectar con ese puerto desde la computadora B. Pero este no parece ser el caso en WebRTC. Creo que ninguno de los clientes comienza a escuchar en un puerto. De alguna manera, pueden crear una conexión sin escuchar en los puertos y aceptar conexiones. Ni el cliente A, ni el cliente B comienzan a actuar como servidor.

¿Pero cómo? ¿Qué datos se intercambian en el servidor WebRTC, que los clientes pueden usar para conectarse entre sí?

Gracias por sus explicaciones para esto :)

Editar

encontré this artículo. No está relacionado con WebRTC, pero creo que responde una parte de mi pregunta. No estoy seguro, es difícil. Todavía sería genial, si alguien pudiera explicarme y darme algunos enlaces adicionales.

Answer 1

WebRTC ofrece SDP Offer al cliente de la aplicación JS para enviar (aunque la aplicación JS lo desee) al otro dispositivo, que usa eso para generar una Respuesta SDP.

El truco es que el SDP incluye candidatos ICE (efectivamente "intenta hablar conmigo en esta dirección IP y este puerto"). ICE trabaja para perforar puertos abiertos en los firewalls; aunque si ambos lados son NAT simétricos, generalmente no será posible, y se puede usar un candidato alternativo (en un servidor TURN).

Una vez que están hablando directamente (o mediante TURN, que es efectivamente un reflejo de paquete), pueden abrir una conexión DTLS y utilizarla para codificar las secuencias de medios SRTP-DTLS y enviar DataChannels a través de DTLS.

Editar: Acrónimos aquí: http://blog.1click.io/10-jargons-abbreviations-for-webrtc-fans/ para el resto, hay Google. La mayoría de estos son definidos por el IETF (http://ietf.org/)

Editar 2: Firefox y Chrome (y la especificación) se han movido a la utilización de "goteo" para los candidatos de ICE, así que los candidatos de hielo se añade generalmente después de-la-cara a PeerConnection e intercambiado independientemente del SDP inicial (aunque puede esperar hasta que los candidatos iniciales estén listos antes de enviar una oferta y agruparlos). Ver https://webrtcglossary.com/trickle-ice/ y https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/

Answer 2

una muy buena explicación se puede encontrar en este libro http://chimera.labs.oreilly.com/books/1230000000545/ch03.html#STUN_TURN_ICE que proporciona los fundamentos sobre cómo utiliza la tecnología WebRTC ICE.

En particular asumiendo la dirección IP del servidor STUN se sabe, la aplicación WebRTC envía primero una solicitud de unión al servidor STUN. El servidor STUN responde con una respuesta que contiene la dirección IP pública y el puerto del cliente como se ve desde la red pública.

Ahora la aplicación descubre su IP pública y la tupla del puerto que puede enviar al otro interlocutor a través de SDP. (tenga en cuenta que los SDP se envían a través de un canal de señalización externo, websocket fi establecido a través de un servicio web)

Con este mecanismo en su lugar, cada vez que dos pares desean comunicarse entre sí a través de UDP, pueden usar la IP pública establecida y tuplas de puertos para intercambiar datos.

Desafortunadamente, en algunos casos el UDP puede ser bloqueado por un firewall. Para solucionar este problema, siempre que STUN falle, podemos utilizar los Transmisores de Uso Transversal en torno al protocolo NAT (TURN) como una alternativa, que puede ejecutarse en UDP y cambiar a TCP si falla todo lo demás.

Answer 3

Establecer una conexión P2P WebRTC tiene 3 pasos (10.000 pies general):

1. Paso 1: señalización: ambos pares se conectan a un servidor de señalización (usando websockets sobre 80/443, cometa, SIP , etc ..) e intercambio de información (acerca de sus capacidades multimedia, IP pública: pares de puertos cuando estén disponibles, etc.)

2. Paso 2: Descubrimiento : los dispositivos conectados a la LAN o redes móviles no son conscientes de su IP pública (y puerto) donde Se puede contactar con ellos para que utilicen los servidores STUN/TURN ubicados en Internet público para descubrir su par ip: puerto (candidatos ICE). En el proceso que perforar un agujero a través de la NAT/enrutador que se usa en Paso 3:

3. Paso 3: P2P conexión: una vez que los candidatos de ICE se intercambian a través del canal de señalización inicial cada par es consciente de IP del otro : puerto (y los agujeros han sido perforados en NAT/enrutadores) para que se pueda establecer una conexión UDP de igual a igual.

El esquema anterior explica el proceso con 2 dispositivos conectados a redes locales. Es parte de un artículo que escribí que trata de troubleshooting connection issues pero explica cómo funciona WebRTC.