WebRTC vs Websockets: se o WebRTC pode gravar vídeo, áudio e dados, por que preciso de Websockets? [fechadas]

Então, estou procurando criar um aplicativo de bate-papo que permita vídeo, áudio e texto. Passei algum tempo pesquisando sobre Websockets e WebRTC para decidir qual usar. Como existem muitos aplicativos de vídeo e áudio com o WebRTC, isso parece uma escolha razoável, mas há outras coisas que devo considerar? Sinta-se livre para compartilhar seus pensamentos.

Coisas como:

• Por ser novo, o WebRTC está disponível apenas em alguns navegadores, enquanto o WebSockets parece estar em mais navegadores.

• Escalabilidade - Websockets usa um servidor para sessão e WebRTC parece ser p2p.

• Multiplexação / várias salas de chat - usadas no Hangouts do Google+, e ainda estou vendo aplicativos de demonstração sobre como implementar.

• Servidor - Websockets precisa de RedisSessionStore ou RabbitMQ para escalar em várias máquinas.

O WebRTC foi projetado para comunicação de alto desempenho e alta qualidade de vídeo, áudio e dados arbitrários. Em outras palavras, para aplicativos exatamente como o que você descreve.

Os aplicativos WebRTC precisam de um serviço pelo qual eles possam trocar metadados de rede e mídia, um processo conhecido como sinalização. No entanto, após a sinalização, o vídeo / áudio / dados são transmitidos diretamente entre os clientes, evitando o custo de desempenho do streaming por meio de um servidor intermediário.

O WebSocket, por outro lado, foi projetado para comunicação bidirecional entre cliente e servidor. É possível transmitir áudio e vídeo pelo WebSocket (veja aqui, por exemplo), mas a tecnologia e as APIs não são projetadas inerentemente para um fluxo eficiente e robusto da maneira que o WebRTC é.

Como outras respostas disseram, o WebSocket pode ser usado para sinalização.

Eu mantenho uma lista de recursos do WebRTC : recomendo vivamente que você analise a apresentação de E / S do Google de 2013 sobre o WebRTC.

WebSockets:

• Padrão IETF ratificado (6455) com suporte em todos os navegadores modernos e até navegadores herdados usando o polyfill web-socket-js.

• Utiliza handshake compatível com HTTP e portas padrão, facilitando o uso com a infraestrutura existente de firewall, proxy e servidor da web.

• API do navegador muito mais simples. Basicamente, um construtor com alguns retornos de chamada.

• Cliente / navegador apenas para servidor.

• Suporta apenas transporte confiável e em ordem porque é construído no TCP. Isso significa que a queda de pacotes pode atrasar todos os pacotes subsequentes.

WebRTC:

• Apenas começando a ser suportado pelo Chrome e Firefox. A MS propôs uma variante incompatível. O componente DataChannel ainda não é compatível entre o Firefox e o Chrome.

• O WebRTC é um navegador para outro em circunstâncias ideais, mas mesmo assim quase sempre requer um servidor de sinalização para configurar as conexões. As soluções mais comuns para servidor de sinalização agora usam WebSockets.

• A camada de transporte é configurável com o aplicativo capaz de escolher se a conexão está em ordem e / ou confiável.

• API do navegador complexa e de várias camadas. Existem bibliotecas JS para fornecer uma API mais simples, mas elas são jovens e mudam rapidamente (assim como o próprio WebRTC).

Os Websockets usam o protocolo TCP.

O WebRTC é principalmente UDP.

Portanto, o principal motivo do uso do WebRTC em vez do Websocket é a latência. Com o streaming via websocket, você terá alta latência ou reprodução instável com baixa latência. Com o WebRTC, você pode obter baixa latência e reprodução suave, o que é crucial para as comunicações VoIP.

Apenas tente testar essas tecnologias com uma perda de rede, ou seja, 2%. Você verá grandes atrasos no fluxo do Websocket.

webRTC ou websockets? Por que não usar ambos.

Ao criar um bate-papo por vídeo / áudio / texto, o webRTC é definitivamente uma boa opção, pois usa a tecnologia ponto a ponto e, quando a conexão está em funcionamento, você não precisa passar a comunicação por um servidor (a menos que esteja usando TURN).

Ao configurar a comunicação webRTC, você precisa envolver algum tipo de mecanismo de sinalização. Os Websockets podem ser uma boa opção aqui, mas o webRTC é o caminho a percorrer para as informações de vídeo / áudio / texto. As salas de bate-papo são realizadas na sinalização.

Mas, como você mencionou, nem todos os navegadores oferecem suporte ao webRTC, portanto, os websockets às vezes podem ser uma boa alternativa para esses navegadores.

Comparar websocket e webrtc é injusto.

O Websocket é baseado no TCP. O limite do pacote pode ser detectado a partir das informações do cabeçalho de um pacote websocket, diferente do tcp.

Normalmente, o webrtc utiliza o websocket. A sinalização para o webrtc não está definida, cabe ao provedor de serviços que tipo de sinalização ele deseja usar. Pode ser SIP, HTTP, JSON ou qualquer mensagem de texto / binária.

As mensagens de sinalização podem ser enviadas / recebidas usando o websocket.

A segurança é um aspecto que você perdeu.

Com os Websockets, os dados precisam passar por um servidor da web central que normalmente vê todo o tráfego e pode acessá-lo.

Com o WebRTC, os dados são criptografados de ponta a ponta e não passam por um servidor (exceto às vezes, são necessários servidores TURN, mas eles não têm acesso ao corpo das mensagens que encaminham).

Dependendo da sua aplicação, isso pode ou não ser importante.

Se você estiver enviando grandes quantidades de dados, também poderá valer a pena economizar em largura de banda da nuvem devido à arquitetura P2P do webRTC.

O Webrtc faz parte da conexão ponto a ponto. Todos sabemos que antes de criar uma conexão ponto a ponto, é necessário um processo de handshake para estabelecer uma conexão ponto a ponto. E os websockets desempenham o papel do processo de handshake.

O Websocket e o WebRTC podem ser usados ​​juntos, o Websocket como canal de sinal do WebRTC e o webrtc é um canal de vídeo / áudio / texto. O WebRTC também pode estar em UDP também no TURN relay, TURN relay TCP HTTP e HTTPS. Muitos projetos usam Websocket e WebRTC juntos.