Después de la introducción de las partes anteriores, debe tener una comprensión general del proceso de interacción de audio y video P2P. Puede sentir que el proceso es engorroso e incluso involucra la capa inferior de la red. Pero no se preocupe, WebRTC ha hecho mucho por nosotros, facilitándonos el desarrollo de audio y video. Entonces, ¿qué es exactamente WebRTC?
WebRTC (Web Real-Time Communications) es una tecnología de comunicación en tiempo real que permite que aplicaciones o sitios de red establezcan una conexión peer-to-peer (Peer-to-Peer) entre navegadores sin intermediarios para lograr el streaming de video y/o la transmisión de secuencias de audio u otros datos arbitrarios. Estos estándares incluidos en WebRTC hacen posible que los usuarios creen teleconferencias y uso compartido de datos entre pares (Peer-to-Peer) sin instalar ningún complemento o software de terceros.
WebRTC no es la tecnología original de Google. En 2010, Google adquirió el desarrollador de software VoIP Global IP Solutions por aproximadamente $ 68,2 millones y, por lo tanto, adquirió la tecnología WebRTC propiedad de la empresa. Hoy en día, las tecnologías de servicios de comunicación de audio y video de Internet son generalmente tecnologías propietarias, como Skype , que necesitan instalar complementos o clientes de escritorio para realizar funciones de comunicación. Google espera que los desarrolladores web puedan crear aplicaciones de video o chat de voz directamente en el navegador.Global IP Solutions ha producido anteriormente clientes móviles basados en WebRTC para Android, Windows Mobile y iPhone. Google hizo WebRTC de código abierto esta vez, con la esperanza de que los fabricantes de navegadores puedan integrar directamente la tecnología en el navegador, para facilitar a los desarrolladores web.
Suplemento de concepto
Además de los conceptos mencionados anteriormente, permítanme agregar algunos conceptos relacionados
servicio de enlace interactivo
Establecimiento de conectividad interactiva (ICE): un marco de protocolo que permite que su navegador establezca una conexión con un navegador similar. En una red real, hay muchas razones por las que una simple conexión directa de A a B no se puede completar como se desea. Esto requiere eludir el firewall que impide que se establezca la conexión, asignar a su dispositivo una dirección visible única (por lo general, la mayoría de nuestros dispositivos no tienen una dirección de red pública fija), y si el enrutador no permite que el host se conecte directamente, usted tiene que pasar un El servidor reenvía los datos. Es posible que haya descubierto que este ICE es un resumen de nuestros métodos de conexión anteriores, como STUN y TURN. Formalmente, debido al marco ICE, nuestro trabajo de desarrollo se simplifica enormemente, e ICE seleccionará automáticamente el método de conexión de acuerdo con la prioridad;
servidor de señalización
Signal server (servidor de señales): intercambie las direcciones de comunicación entre pares, después de obtener sus propias direcciones de comunicación a través de STUN, regístrese en el servidor de señalización para intercambiar direcciones de comunicación entre dispositivos, completando así la conexión P2P;
Sesión Descripción Protocolo
Protocolo de descripción de sesión (Session Description Protocol, SDP): protocolo que describe el contenido de una conexión multimedia, como resolución, formato, codificación, algoritmo de cifrado, etc. Antes de iniciar una conexión P2P, es necesario negociar un protocolo de sesión soportado por ambas partes. Cuando un usuario inicia una llamada WebRTC a otro usuario, se crea una descripción específica denominada oferta . La descripción incluye toda la información sobre la configuración de la llamada propuesta por el llamante. Luego, el destinatario responde con una respuesta, que es su descripción del final de la llamada. De esta forma, dos dispositivos comparten entre sí la información necesaria para intercambiar datos multimedia; un SDP describe el contenido de esta manera ("="No puede haber espacios en ambos lados)
v=0
o=- 212360934117607227 2 IN IP4 127.0.0.1
s=-
t=0 0
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
a=rtpmap:111 opus/48000/2
......
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 121 127 120 125 107 108 109 35 36 124 119 123 118 114 115 116
a=rtpmap:96 VP8/90000
......
Una descripción de SDP consta de una sesión y varias descripciones de medios. La descripción de la sesión va desde v= hasta la primera descripción de medios (1-4 líneas) y la descripción de medios va desde m= hasta la siguiente descripción de medios (5-6 líneas— - audio, líneas 8-9 - vídeo).
descripción a nivel de sesión
Hay muchos campos de descripción de sesión, los más importantes son 4 campos
- v=: número de versión UDP, excluyendo la versión menor* o=: una descripción del iniciador de la sesión > o=*
<username>: nombre de usuario, cuando no le importa el nombre de usuario, puede usar "-" en su lugar; *<session id>: cadena de número, debe ser único en toda la sesión, y se recomienda usar la marca de tiempo NTP; *<version>: número de versión, el valor de la versión se incrementará cada vez que se modifiquen los datos de la sesión; *<network type>: tipo de red, generalmente "IN", que significa "internet"; *<address type>: tipo de dirección, normalmente IP4; *<address>: dirección IP - Nombre de sesión: indica una sesión * t=: descripción de la hora de inicio y hora de finalización
t=<start time> <stop time>, cuando ambos eventos son 0, significa una sesión persistente ##### SDP en WebRTC
Se han realizado algunas modificaciones a SDP bajo WebRTC, y se han agregado algunas otras descripciones sobre la base del original.
// 音频使用9端口收发;
// UDP / TLS / RTP / SAVPF 表示使用 dtls / srtp 协议对数据加密传输;
m = audio 9 UDP / TLS / RTP / SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
// 网络描述, webRTC不使用
c = IN IP4 0.0.0.0
// 设置rtcp地址和端口, webRTC不使用
a = rtcp: 9 IN IP4 0.0.0.0
// 安全验证信息
a=ice-ufrag:duP8
a=ice-pwd:/7pIrSvgESATKPZUVzHhLQ0E
a=ice-options:trickle
// 音频流媒体描述
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
descripción de los medios
- m=: indica una sesión,
m=<media> <port> <transport> <fmt list>*<media>: tipo de medio, como audio/video, etc.; *<port>: puerto; *<transport>: protocolo de transporte, hay dos tipos: RTP/AVP y UDP; *<fmt list>: formato de medio, es decir, el lista de tipos de carga útil de datos (Tipo de carga útil). - a=*:
a=<type>oa=<type>:<value>, el tipo tiene dos tipos rtpmap y fmap
Ahora mejoremos el diagrama esquemático de la puerta de enlace anterior y agreguemos algunos conceptos aquí
Recopilar direcciones de candidatos
La llamada recopilación de direcciones candidatas consiste en obtener su propia dirección comunicable a través del servidor STUN mencionado anteriormente.
| Tipos de | alias | Cómo enviar a pares | uso |
|---|---|---|---|
| Candidatos anfitriones | anfitrión | servidor de señalización | La dirección de transporte local obtenida de la tarjeta de red, si esta dirección está detrás de NAT, es la dirección de intranet |
| Candidatos de reflexión del servidor | srflx | servidor de señalización | La dirección de transporte obtenida de la verificación de enlace enviada al servidor de aturdimiento. Si esta dirección está detrás de NAT, es la dirección de red pública del NAT más externo. |
| Candidatos a la reflexión entre pares | prflx | Solicitud de vinculación de aturdimiento | La dirección de transporte obtenida de la solicitud Stun Binding enviada por el par. Este es un nuevo tipo de candidato que se produce durante las comprobaciones de conectividad. |
| Candidatos de relevo | relé | servidor de señalización | La dirección de transporte del servidor de retransmisión de medios. Adquirido mediante el uso de la solicitud de asignación de TURN |
intercambiar direcciones de candidatos
A envía la dirección candidata recopilada en el primer paso a B a través del servidor de señalización, y B también envía la dirección candidata recopilada a A. Después de recibir todas las direcciones candidatas de B, A comparará su propia dirección candidata con la dirección candidata del par Ejecutar un arreglo completo y almacenarlo en la tabla de estado. Por ejemplo, el host de A en este momento es 192.168.0.100:60000, srflx es 11.102.30.3:30110, el host de B es 192.168.0.15:10001, srflx es 1.10.108.25:30110, la tabla de estado es la siguiente
| dirección de la tarjeta de red local | dirección de pares | Expresar |
|---|---|---|
| 192.168.1.105:60001 | 192.168.0.204:40001 | Prueba de aturdimiento no realizada |
| 172.16.40.6:60003 | 192.168.0.204:40001 | Prueba de aturdimiento no realizada |
| 192.168.1.105:60001 | 11.92.14.8:50002 | Prueba de aturdimiento no realizada |
| 172.16.40.6:60003 | 11.92.14.8:50002 | Prueba de aturdimiento no realizada |
| 192.168.1.105:60001 | 192.168.0.181:40003 | Prueba de aturdimiento no realizada |
| 172.16.40.6:60003 | 192.168.0.181:40003 | Prueba de aturdimiento no realizada |
En este momento, todos los estados de registro no se verifican STUN, y la verificación STUN de cada registro se llevará a cabo en el siguiente paso.
control de ATURDIMIENTO
Hemos introducido el proceso de inspección STUN antes, si lo olvida, puede revisar la perforación de agujeros p2p
conectar, medios de arranque
Una vez que se completa la verificación de STUN, se prepara la conexión. En este momento, la tabla de estado en P2PTransportChannel ha registrado el costo de cada registro (que involucra muchos factores, como el tiempo transcurrido desde que se envía una solicitud de Stun hasta que se recibe una respuesta). .).
**Cuando hay datos Rtp de video para enviar, verifique el primer registro en la tabla de estado, si se considera que su estado está listo para enviar, utilizará esta conexión para enviar. De lo contrario, abandone la tarea de envío directamente. **Es decir, la tarea del módulo de medios no se verá afectada por el estado de la conexión, solo verifica el estado cuando está a punto de enviar y renuncia al envío si no está conectado.
Para garantizar que las reglas de mapeo y filtrado de NAT no superen el tiempo de espera durante una sesión de medios, ICE envía continuamente comprobaciones de conexión de aturdimiento contra los candidatos en uso. En términos sencillos, es "sondeo". Si la respuesta de STUN se agota, aumentará el costo, lo que se refleja en la tabla de estado a medida que se reduce la prioridad, es decir, la tabla de estado de P2PTransportChannel es en tiempo real.
Por fin
Organicé 75 preguntas de entrevistas de alta frecuencia de JS y brindé respuestas y análisis, lo que básicamente puede garantizar que pueda hacer frente a las preguntas del entrevistador sobre JS.
Amigos necesitados, puede hacer clic en la tarjeta a continuación para recibir y compartir gratis