WebRTC vs Websockets: si WebRTC puede hacer video, audio y datos, ¿por qué necesito Websockets?
(8)
Así que estoy buscando construir una aplicación de chat que permita video, audio y texto. Pasé algún tiempo investigando en Websockets y WebRTC para decidir cuál usar. Dado que hay muchas aplicaciones de audio y video con WebRTC, esto parece una opción razonable, pero ¿hay otras cosas que deba considerar? Siéntete libre de compartir tus pensamientos.
Cosas como:
Debido a que es nuevo, WebRTC solo está disponible en algunos navegadores, mientras que Websockets parece estar en más navegadores.
Escalabilidad: Websockets utiliza un servidor para la sesión y WebRTC parece ser p2p
Multiplexación / salas de chat múltiples: se usa en Hangouts de Google+, y sigo viendo aplicaciones de demostración sobre cómo implementar
Servidor: Websockets necesita RedisSessionStore o RabbitMQ para escalar en varias máquinas
Comparar websocket y webrtc es injusto.
Websocket se basa en la parte superior de TCP. El límite del paquete se puede detectar a partir de la información del encabezado de un paquete de websocket a diferencia de tcp.
Normalmente, webrtc hace uso de websocket. La señalización para webrtc no está definida, depende del proveedor de servicios qué tipo de señalización quiere usar. Puede ser SIP, HTTP, JSON o cualquier mensaje de texto / binario.
Los mensajes de señalización se pueden enviar / recibir usando websocket.
La seguridad es un aspecto que te perdiste.
Con Websockets, los datos tienen que pasar a través de un servidor web central que normalmente ve todo el tráfico y puede acceder a él.
Con WebRTC, los datos están cifrados de extremo a extremo y no pasan por un servidor (excepto que a veces se necesitan servidores TURN, pero no tienen acceso al cuerpo de los mensajes que reenvían).
Dependiendo de su aplicación, esto puede o no ser importante.
Si envía grandes cantidades de datos, vale la pena considerar el ahorro en los costos de ancho de banda de la nube debido a la arquitectura P2P de webRTC.
WebRTC está diseñado para la comunicación de alto rendimiento y alta calidad de video, audio y datos arbitrarios. En otras palabras, para las aplicaciones exactamente como lo que describes.
Las aplicaciones WebRTC necesitan un servicio a través del cual puedan intercambiar metadatos de redes y medios, un proceso conocido como señalización. Sin embargo, una vez que se ha producido la señalización, el video / audio / datos se transmite directamente entre los clientes, evitando el costo de rendimiento de la transmisión a través de un servidor intermediario.
WebSocket por otro lado está diseñado para la comunicación bidireccional entre el cliente y el servidor. Es posible transmitir audio y video a través de WebSocket (ver here por ejemplo), pero la tecnología y las API no están diseñadas inherentemente para una transmisión eficiente y robusta en la forma en que es WebRTC.
Como han dicho otras respuestas, WebSocket se puede usar para la señalización.
Mantengo una lista de los recursos de WebRTC : recomiendo encarecidamente que comience mirando la presentación de Google I / O 2013 sobre WebRTC.
WebSockets:
Ratificó el estándar IETF (6455) con soporte en todos los navegadores modernos e incluso navegadores heredados usando web-socket-js polyfill.
Utiliza el protocolo de enlace compatible con HTTP y los puertos predeterminados, lo que hace que sea mucho más fácil de usar con el servidor de seguridad, proxy y la infraestructura del servidor web existente.
API de navegador mucho más simple. Básicamente un constructor con un par de devoluciones de llamada.
Cliente / navegador al servidor solamente.
Solo admite transporte confiable y ordenado porque está integrado en TCP. Esto significa que las gotas de paquetes pueden retrasar todos los paquetes subsiguientes.
WebRTC:
Recién comenzó a ser compatible con Chrome y Firefox. MS ha propuesto una variante incompatible. El componente DataChannel aún no es compatible entre Firefox y Chrome.
WebRTC es navegador a navegador en circunstancias ideales, pero incluso entonces casi siempre se requiere un servidor de señalización para configurar las conexiones. Las soluciones de servidor de señalización más comunes ahora usan WebSockets.
La capa de transporte es configurable y la aplicación puede elegir si la conexión está en orden y / o es confiable.
API de navegador complejo y multicapa. Hay JS libs para proporcionar una API más simple, pero estos son jóvenes y cambian rápidamente (al igual que WebRTC).
Webrtc es una parte de la conexión punto a punto. Todos sabemos que antes de crear una conexión punto a punto, se requiere un proceso de establecimiento de lazos para establecer una conexión punto a punto. Y los websockets desempeñan el papel de proceso de apretón de manos.
Websocket y WebRTC se pueden usar juntos, Websocket como canal de señal de WebRTC, y webrtc es canal de video / audio / texto, también WebRTC puede estar en UDP también en Relé TURN, Relé de retransmisión compatible con TCP HTTP también HTTPS. Muchos proyectos usan Websocket y WebRTC juntos.
Websockets usa el protocolo TCP.
WebRTC es principalmente UDP.
Por lo tanto, la razón principal para usar WebRTC en lugar de Websocket es la latencia. Con la transmisión de websocket tendrá alta latencia o reproducción entrecortada con baja latencia. Con WebRTC puede lograr una baja latencia y una reproducción sin problemas, lo cual es crucial para las comunicaciones de VoIP.
Intente probar esta tecnología con una pérdida de red, es decir, 2%. Verás altas demoras en la transmisión de Websocket.
webRTC o websockets? ¿Por qué no usar ambos?
Al construir un chat de video / audio / texto, webRTC es definitivamente una buena opción, ya que utiliza la tecnología de igual a igual y una vez que la conexión está funcionando, no es necesario pasar la comunicación a través de un servidor (a menos que utilice TURN).
Al configurar la comunicación webRTC, debe involucrar algún tipo de mecanismo de señalización. Websockets podría ser una buena opción aquí, pero webRTC es el camino a seguir para la información de video / audio / texto. Salas de chat se logra en la señalización.
Pero, como usted menciona, no todos los navegadores son compatibles con webRTC, por lo que los websockets a veces pueden ser una buena alternativa para esos navegadores.