tutorial - webrtc test

¿Cómo funciona WebRTC?

Question

Estoy interesado en 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 tus 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

El establecimiento de una conexión p2p WebRTC tiene 3 pasos (vista general de 10.000 pies):

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 intercambian información (sobre sus capacidades de medios, IP pública: pares de puertos cuando estén disponibles, etc.)

2. Paso 2: Descubrimiento : los dispositivos conectados a redes LAN o móviles no conocen su IP pública (y puerto) donde pueden ser localizados, por lo que usan servidores STUN / TURN ubicados en Internet público para descubrir su par ip: puerto (ICE candidatos). En el proceso, perforan el NAT / enrutador que se usa en el paso 3:

3. Paso 3: conexión P2P : una vez intercambiados los candidatos ICE a través del canal de señalización inicial, cada par conoce el puerto ip: port (y se han perforado los agujeros en NAT / enrutadores) para establecer una conexión UDP punto a punto.

El esquema anterior explica el proceso con 2 dispositivos conectados a redes locales. Es parte de un artículo que escribí que trata sobre la solución de problemas de conexión, pero explica cómo funciona WebRTC.

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 WebRTC utiliza la tecnología ICE.

En particular, suponiendo que se conoce la dirección IP del servidor STUN, la aplicación WebRTC primero envía una solicitud de enlace 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, fi websocket establecido a través de un servicio web)

Con este mecanismo en su lugar, cada vez que dos pares quieren hablar entre sí a través de UDP, pueden usar las IP públicas públicas y las tuplas de puertos para intercambiar datos.

Desafortunadamente, en algunos casos 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

WebRTC ofrece la oferta de SDP a la aplicación JS del cliente 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 en realidad es un espejo de paquetes), pueden abrir una conexión DTLS y usarla para codificar las secuencias de medios SRTP-DTLS y para enviar DataChannels a través de DTLS.

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

Editar 2: Firefox y Chrome (y las especificaciones) se han movido a usar "goteo" para los candidatos de ICE, por lo que los candidatos de ICE generalmente se agregan después de la cara a la PeerConnection y se intercambian independientemente del SDP inicial (aunque puede esperar hasta 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/