1. Introducción básica
WebRTC (nombre completo: Web Real-Time Communication), que es comunicación instantánea de páginas web. Es una solución técnica que admite navegadores web para conversaciones de voz o video en tiempo real. Desde la perspectiva del desarrollo de tecnología front-end, es un conjunto de estándares API invocables.
Antes del lanzamiento de WebRTC, el costo de desarrollar aplicaciones interactivas de audio y video en tiempo real era muy costoso y había muchos problemas técnicos que debían considerarse, como problemas de codificación y decodificación de audio y video, problemas de transmisión de datos, retrasos, pérdida de paquetes, fluctuación, procesamiento y eliminación de eco, etc. Si desea ser compatible con la comunicación de audio y video en tiempo real en el lado del navegador, debe instalar complementos adicionales.
Mayo de 2010: Google adquirió el motor GIPS del desarrollador de software VoIP Global IP Solutions por 68,2 millones de dólares y cambió su nombre a "WebRTC" (consulte "Amazing WebRTC: El ecosistema está mejorando cada vez más, o la tecnología de audio y vídeo en tiempo real puede convertirse en un repollo"). Su objetivo es establecer una plataforma para la comunicación en tiempo real entre navegadores de Internet y hacer de la tecnología WebRTC uno de los estándares H5.
Significado
El surgimiento, el desarrollo y el reconocimiento general de WebRTC por parte de las organizaciones de estándares de la industria (como el W3C) son de gran importancia para el desarrollo actual y futuro de la gran tecnología front-end.
Reducir el umbral para el desarrollo interactivo de audio y vídeo en la web:
1) El desarrollo interactivo de audio y video previo tiene un cierto umbral técnico para los desarrolladores web;
2) Ahora, con la ayuda de WebRTC, los desarrolladores web pueden implementar rápidamente aplicaciones interactivas de audio y video llamando a interfaces JS.
Evite problemas secundarios causados por dependencias y complementos:
1) En el pasado, la construcción de aplicaciones interactivas de audio y vídeo dependía de varios complementos, software y servidores;
2) Ahora se puede establecer una interacción de audio y vídeo de un extremo a otro con la ayuda de los navegadores convencionales.
La unificación y estandarización evitan las diferencias en los entornos tradicionales de interacción de audio y vídeo:
1) En el pasado, la interacción de audio y video requería diferentes NAT y firewalls, lo que planteaba grandes desafíos para el establecimiento de medios P2P;
2) Ahora existe libjingle, un proyecto de código abierto para perforar P2P en WebRTC, que admite STUN, TURN y otros protocolos.
Algoritmos y tecnologías más eficientes y optimizados mejoran el rendimiento de la interacción de audio y vídeo:
1) WebRTC utiliza tecnologías NACK y FEC para evitar el enrutamiento a través del servidor, lo que reduce el retraso y el consumo de ancho de banda;
2) También existen tecnologías como TCC + SVC + PACER + JitterBuffer que optimizan la fluidez de audio y video.
3. Características técnicas
WebRTC es rico en contenido y sus principales características técnicas incluyen los siguientes puntos.
1) Comunicación en tiempo real:
WebRTC es una tecnología de comunicación en tiempo real que permite que aplicaciones o sitios de red establezcan conexiones punto a punto (Peer-to-Peer) entre navegadores sin el uso de intermediarios para lograr transmisión de video y/o transmisión de audio u otra transmisión de datos arbitraria. datos.
2) Sin dependencias/complementos:
Estos estándares incluidos en WebRTC hacen posible que los usuarios compartan datos y realicen conferencias telefónicas entre pares sin instalar ningún complemento ni software de terceros.
3) Hay muchas pilas de protocolos:
WebRTC no es un protocolo único. Incluye múltiples estándares de protocolo, incluidos medios, cifrado, capa de transporte, etc., así como un conjunto de API basadas en JavaScript. Incluye recopilación, codificación y decodificación de audio y video, transmisión de red, visualización y otras funciones. A través de la API JavaScript simple y fácil de usar, el navegador tiene la capacidad de compartir audio, video y datos P2P sin instalar ningún complemento.
WebRTC se basa en numerosos diagramas de pila de protocolos 
:
Al mismo tiempo, WebRTC no es un protocolo aislado: tiene señalización flexible y puede conectarse fácilmente a sistemas de redes telefónicas y SIP existentes.
4. Coberturas compatibles
Actualmente, la mayoría de los navegadores convencionales suelen ser compatibles con WebRTC:
Para obtener una compatibilidad más detallada con el navegador y la versión, mire la siguiente imagen:
Los navegadores convencionales admiten la API estándar WebRTC, lo que hace posible la interoperabilidad de audio y video sin complementos entre navegadores, lo que reduce en gran medida el umbral para el desarrollo de audio y video. Los desarrolladores solo necesitan llamar a la API WebRTC para crear rápidamente aplicaciones de audio y video.
5. Marco técnico
Como se muestra en la siguiente figura: el marco técnico describe el contenido principal de WebRTC y el diseño de API para diferentes desarrolladores.
Diagrama del marco de tecnología WebRTC 
:
Como puede verse en la figura, WebRTC se dirige principalmente a diseños de API para tres tipos de desarrolladores:
1) API para desarrolladores web: el marco incluye un conjunto de estándares API basados en JavaScript y certificados por W3C, lo que permite a los desarrolladores web desarrollar aplicaciones de mensajería instantánea basadas en WebRTC basadas en este conjunto de API;
2) Para las API de los fabricantes de navegadores: el marco también incluye la interfaz WebRTC subyacente basada en C++, que es muy amigable para el acceso subyacente de los fabricantes de navegadores;
3) Partes que los fabricantes de navegadores pueden personalizar: el marco también incluye extensiones como la interceptación de audio y video que los fabricantes de navegadores pueden personalizar.
6. Núcleo técnico
Como se puede ver en el marco de la sección anterior, WebRTC consta principalmente de tres partes: motor de audio, video y transmisión, que también contiene muchos protocolos y métodos.
1) Motor de voz:
a. Voice Engine incluye iSAC/iLBC Codec (códec de audio, el primero es para banda ancha y banda ultraancha, y el segundo es para banda estrecha);
b.NetEQ para voz (que maneja la fluctuación de la red y la pérdida de paquetes de voz);
C. Cancelador de eco/reducción de ruido.
2) Motor de vídeo:
a.Códec VP8 (códec de imágenes de vídeo);
B. Búfer de fluctuación de video (búfer de fluctuación de video, maneja la fluctuación de video y la pérdida de paquetes de video);
C. Mejoras de imagen (mejora de la calidad de la imagen).
3) Transporte.
7. Principios técnicos
7.1 Situación básica
Las principales características técnicas de WebRTC:
1) SRTP: Protocolo seguro de transmisión en tiempo real para streaming de audio y vídeo;
2) Multiplexación: multiplexación;
3) P2P: STUN+TURN+ICE, utilizado para atravesar la red NAT y el firewall;
4) DTLS: la transmisión segura también puede utilizar DTLS (Transmisión segura de datagramas) para transmisión cifrada y negociación de claves;
5) UDP: toda la comunicación WebRTC se basa en UDP.
Debido a limitaciones de espacio, los siguientes capítulos de este artículo no presentarán en detalle la recopilación, codificación y procesamiento de audio y video, sino que solo presentarán el contenido central de los principios del proceso de establecimiento de la comunicación en tiempo real.
7.2 Mapeo de IP de la red pública: aclarar la información de posicionamiento de la red
WebRTC se implementa en función de la conexión de un extremo a otro del navegador (P2P).
Dado que no se requiere transferencia del servidor, la forma de obtener la dirección de red del objeto de conexión es utilizar tecnología de penetración de red auxiliar (NAT), como ICE, STUN y TURN, para obtener la dirección de red pública y el puerto del host correspondiente y otros. información de posicionamiento de la red.
Un posicionamiento claro de la red es la base para establecer una comunicación directa de extremo a extremo.
Diagrama esquemático de penetración NAT :
7.3 Servidor de señalización: negociación de red e intercambio de información
La función del servidor de señalización es transmitir información basada en comunicación dúplex.
La información de tránsito incluye información de posicionamiento de la red después del mapeo de IP de la red pública, como la IP de la red pública, el puerto y el flujo de datos de medios.
Mapa conceptual :
7.4 Protocolo de descripción de sesión SDP: método de negociación de medios unificados
El papel del SDP:
1) Diferentes terminales/navegadores tienen diferentes formatos de codificación para datos de flujo de medios, como VP8, VP9, etc., las capacidades de cada miembro que participa en la sesión no son iguales y el entorno y la configuración del usuario son inconsistentes, etc. ;
2) La comunicación WebRTC también requiere determinar e intercambiar información de medios de audio y video locales y remotos, como la resolución y las capacidades de códec. La señalización para intercambiar información de configuración de medios se realiza intercambiando Oferta y Respuesta utilizando el Protocolo de descripción de sesión (SDP);
3) El intercambio de SDP debe preceder al intercambio de flujos de audio y vídeo. Su contenido incluye información básica de la sesión, descripción de la información de los medios, etc. //Estructura SDP Descripción de la sesión (descripción del nivel de sesión) v= (versión del protocolo)o= (originador e identificador de sesión)s= (nombre de la sesión)c=* (información de conexión; no es necesaria si se incluye en todos los medios)Una o más descripciones de tiempo ( "t="y "r="líneas; ver más abajo)a=* (cero o más líneas de atributos de sesión)Cero o másDescripciones de mediosDescripción de tiempot= (hora en que la sesión está activa)Descripción de medios (descripción de nivel de medios), si presentem= (nombre de medio y dirección de transporte)c=* (información de conexión - opcional si se incluye en el nivel de sesión)a=* (cero o más líneas de atributos de medios)
Un ejemplo de SDP es el siguiente:
v=0 //Representa la versión, actualmente suele ser v=0.o=- 3883943731 1 IN IP4 127.0.0.1s=t=0 0 //El tiempo que la sesión está activa a=group:BUNDLE audio video // : Descripción Calidad de servicio, información relacionada con la multiplexación de la capa de transporte m=audio 1 RTP/SAVPF103 104 0 8 106 105 13 126 //...a=ssrc:2223794119 label:H4fjnMzxy3dPIgQ7HxuCTLb4wLLLeRHnFxh81
7.5 Proceso de establecimiento de conexión uno a uno
Expliquemos brevemente el proceso de establecimiento de una conexión Web RTC uno a uno como ejemplo.
Diagrama de proceso uno a uno:
-
1) Intercambiar SDP y obtener la información de configuración de medios respectiva;
-
2) El servidor STUN intercambia información de red, como direcciones y puertos de red;
-
3) Gire para transferir datos de transmisión de medios de audio y video.
diagrama de flujo de trabajo:
1) Ambas partes, A y B, primero llaman a getUserMedia para abrir la cámara local como flujo de medios local que se emitirá;
2) Enviar una solicitud para unirse a la sala al servidor de señalización;
3) El par B recibe el objeto SDP de oferta enviado por el par A, guarda el objeto SDP de respuesta a través del método SetLocalDescription de PeerConnection y lo envía al par A a través del servidor de señalización;
4) En el proceso de oferta/respuesta de información SDP, el Peer A y el Peer B crearon el canal de audio y el canal de video correspondientes en función de la información SDP y comenzaron a recopilar los datos del candidato: datos del candidato (dirección IP local, dirección IP pública). , La dirección asignada por el servidor de retransmisión);
5) Cuando el par A recopila la información del candidato, la envía al par B a través del servidor de señalización. El par B enviará el mismo proceso al par A nuevamente.
7.6 Establecimiento de muchos a muchos
Diagrama conceptual de establecer una conexión punto a punto de muchos a muchos, tomando como ejemplo la conexión punto a punto de tres usuarios:
7.7 Principales interfaces JavaScript para WebRTC
getUserMedia(): accede a flujos de datos, como los de la cámara y el micrófono del usuario.
//Solicitar tipo de medio const constraints = {video: trueaudio:true}; const video = document.querySelector('video'); //Montar la transmisión en el dom correspondiente para mostrar la función de transmisión de medios local handleSuccess(stream) {video .srcObject = stream;}function handleError(error) {console.error('getUserMedia error: ', error);}//Utilice la cámara para capturar el flujo multimedia navigator.mediaDevices.getUserMedia(constraints).then(handleSuccess). atrapar(manejarError);
RTCPeerConnection: habilite llamadas de audio o video con herramientas de encriptación y administración de ancho de banda
// Permitir la configuración del servidor RTC. const server = {"iceServers":[{ "urls": "stun: http://stun.stunprotocol.org"}]};// Crear una conexión local const localPeerConnection = newRTCPeerConnection(servers);// Recopilar datos del candidato localPeerConnection .onicecandidate=function(event){...}// Supervisar la operación cuando se accede al flujo de medios localPeerConnection.ontack=function(event){...}
RTCDataChannel: admite la comunicación punto a punto de datos generales, a menudo utilizado para la transmisión de datos punto a punto
const pc = newRTCPeerConnection();const dc = pc.createDataChannel("mi canal");//Recibir datos dc.onmessage = function(event) {console.log("recibido: "+ event.data);};/ /Abrir transmisión dc.onopen = function() {console.log("canal de datos abierto");}; //Cerrar transmisión dc.onclose = function() {console.log("cerrar canal de datos");};
8. Casos de aplicación
Aquí hay una demostración aproximada utilizando el caso de video de varias personas de WebRTC como práctica.
8.1 Marco de diseño
Diagrama de cuadro básico de video de varias personas:
8.2 Código clave
8.2.1) Captura de medios:
Obtenga el permiso de video del navegador, capture la transmisión de medios de video local, adjunte la transmisión de medios al elemento Video y muestre los resultados del video local. El código se muestra a continuación.
// Procesamiento de compatibilidad de cámara navigator.getUserMedia = ( navigator.getUserMedia ||navigator.webkitGetUserMedia ||navigator.mozGetUserMedia ||navigator.msGetUserMedia); // Obtener transmisiones de audio y video locales navigator.mediaDevices.getUserMedia({"audio": false ,"video": true}).then( (stream)=> {//Muestre su propio flujo de salida y cuélguelo en el elemento Video de la página document.getElementById("myVido").srcObject=stream})
// aturdir y activar servidores const iceServer = {"iceServers": [{urls:"stun: http://stun.l.google.com:19302"}]};//Crear RTCPeerConnectionconst peerRTCConn para punto a punto conexiones =newRTCPeerConnection(iceServer);
8.2.2) Negociación de red:
Las tareas principales son: crear conexiones de igual a igual, recopilar candidatos de ICE y montarse en el dom mientras se espera que accedan los flujos de medios.
Interactive Connectivity Establishment (ICE) es un marco que permite a los pares en tiempo real descubrirse y conectarse entre sí. Esta técnica permite a los pares descubrir suficiente información sobre la topología de cada uno para encontrar potencialmente una o más rutas de comunicación entre ellos. El agente ICE es responsable de: recopilar IP local, candidatos de tupla de puertos, realizar comprobaciones de conexión entre pares y enviar mensajes de mantenimiento de conexión. (Para obtener una introducción a ICE, consulte "Explicación detallada de STUN, TURN e ICE en tecnología P2P")
//Enviar candidatos ICE a otros clientes peerRTCConn.onicecandidate = function(event){if(event.candidate) {//Reenviar los candidatos ICE recopilados al servidor de señalización socket.send(JSON.stringify({"event": "relayICECandidate ","data": {'iceCandidate': {'sdpMLineIndex': event.candidate.sdpMLineIndex,'candidate': event.candidate.candidate}},"fromID":signalMsg 'data'}));}} // Monte dom si está involucrado el flujo de medios peerRTCConn.ontrack=function(event){let v=document.createElement("video")v.autoplay=truev.style="width:200px"document.getElementById("peer" ).appendChild (v)v.srcObject=event.streams[0]}
8.2.3) Consulta a los medios:
La oferta se crea cuando se inicia. El par utiliza el método setLocalDescription para agregar información de sesión a RTCPeerConnection() y el servidor de señalización la retransmite. Otros compañeros devolverán las respuestas correspondientes. Proceso del SDP:
// El nodo recién agregado inicia una oferta if(canOffer){peerRTCConn.createOffer(function(localDescription) {peerRTCConn.setLocalDescription(localDescription,function() {//Enviar información de descripción al servidor de señalización socket.send(JSON.stringify( {" event":"relaySessionDescription","data":localDescription,"fromID":peerId}))},function() { alert("oferta fallida"); });},function(error) {console.log (" error al enviar oferta: ", error);})}
La respuesta se crea en respuesta. La descripción de la sesión incluye información de audio y video y otro contenido. Cuando el iniciador envía una descripción del tipo de oferta al respondedor, el respondedor devolverá una descripción del tipo de respuesta:
//Crear una sesión de respuesta peer.createAnswer(function( remoteDescription) {peer.setLocalDescription(remoteDescription,function() {//Enviar información de descripción al servidor de señalización socket.send(JSON.stringify({"event":"relaySessionDescription" , "data":_remoteDescription,"callerID":signalMsg['fromId'],"fromID":signalMsg['fromId']})) },function() { alert("respuesta fallida"); });}, function (error) {console.log("error al crear la respuesta: ", error);});
Cuando se recibe una parte candidata de ICE, el candidato de ICE se agrega a la descripción del par remoto:
//RTCPeerConnectionconst correspondiente peer = peers[signalMsg["fromID"]]; //Los candidatos ICE se agregan a la descripción del punto de peer remoto peer.addIceCandidate(newRTCIceCandidate(signalMsg["data"].iceCandidate));
8.2.4) Relé de señalización:
Código clave de pieza de servicio de señalización:
wss.on('conexión', función(ws) {ws.on('mensaje', función(mensaje) {let meeageObj=JSON.parse(message)//交换ICE候选 if (meeageObj['event'] == 'relayICECandidate') { wss.clients.forEach(function (cliente) {console.log("enviar iceCandidate")client.send(JSON.stringify({"event": "iceCandidate","data": meeageObj['data '],"fromID": meeageObj['fromID']}));});}//交换SDPif (meeageObj['event'] =='relaySessionDescription') {console.log(meeageObj["fromID"], meeageObj["data"].type)wss.clients.forEach(function(client) {if(client!=ws) {client.send(JSON.stringify({"event": "sessionDescription","fromId":meeageObj ["fromID"],"data": meeageObj["data"],}));}});}})})
9. Resumir
Las principales ventajas de WebRTC son:
1) Comodidad: antes de la aparición de WebRTC, los usuarios necesitaban instalar complementos y clientes si querían comunicarse en tiempo real, pero para muchos usuarios, descargar complementos, instalar y actualizar software es complicado y propenso a problemas Sí, ahora la tecnología WebRTC está integrada en el navegador y los usuarios pueden lograr comunicación en tiempo real a través del navegador sin utilizar ningún complemento o software. Para los desarrolladores, antes de que Google hiciera WebRTC de código abierto, la tecnología para la comunicación entre navegadores estaba en manos de grandes empresas. El desarrollo de esta tecnología era una tarea muy difícil. Ahora los desarrolladores utilizan etiquetas HTML simples y la API JavaScript puede realizar la función de la Web. comunicación audio/vídeo.
2) Gratis: aunque la tecnología WebRTC es relativamente madura e integra el mejor motor de audio/vídeo y un códec muy avanzado, Google no cobra ninguna tarifa por estas tecnologías.
3) Potente capacidad de perforación: la tecnología WebRTC incluye tecnologías clave de penetración de firewall y NAT que utilizan STUN, ICE, TURN, RTP sobre TCP y admite servidores proxy.
Las principales desventajas de WebRTC son:
1) Falta de diseño e implementación de soluciones de servidores.
2) La calidad de la transmisión es difícil de garantizar. El diseño de transmisión de WebRTC se basa en P2P, lo que dificulta garantizar la calidad de la transmisión y tiene métodos de optimización limitados: solo puede realizar una cierta optimización de extremo a extremo, lo que dificulta hacer frente al complejo entorno de Internet. Por ejemplo, la calidad de la transmisión en escenarios entre regiones, entre operadores, bajo ancho de banda, alta pérdida de paquetes y otros depende básicamente del clima, y este es exactamente el escenario típico de las aplicaciones de Internet domésticas.
3) WebRTC es más adecuado para chats individuales uno a uno. Aunque la función se puede ampliar para implementar chats grupales, no hay optimización para los chats grupales, especialmente los chats grupales muy grandes.
4) Adaptación del lado del dispositivo: problemas como el eco y fallos de grabación surgen uno tras otro. Esto es especialmente cierto en los dispositivos Android. Dado que hay muchos fabricantes de dispositivos Android, cada fabricante personalizará el marco estándar de Android, lo que provocará muchos problemas de usabilidad (fallas al acceder al micrófono) y problemas de calidad (como eco, aullidos).
5) Apoyo insuficiente al desarrollo nativo. Como sugiere el nombre, WebRTC es principalmente para aplicaciones Web, aunque también puede usarse para desarrollo Nativo, debido a la gran cantidad de conocimiento del dominio involucrado (recolección de audio y video, procesamiento, codificación y decodificación, transmisión en tiempo real, etc.). ), todo el diseño del marco es relativamente complejo y la granularidad de la API también es relativamente grande, tan detallada que incluso la compilación de proyectos de ingeniería no es una tarea fácil.