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


219

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.

Respostas:


272

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.


2
Obrigado pela resposta detalhada ... alguma atualização quase dois anos depois?
Crashalot

2
Eu recomendo dar uma olhada nos recursos vinculados acima - consulte g.co/webrtc .
Sam Dutton

3
Também não é que (acredito) o WebRTC possa ser configurado para ser menos rigoroso quanto à ordem e outras coisas, por isso pode ser muito mais rápido se você não se importar com a perda de pacotes, etc. (por exemplo, ter os dados mais recentes é mais importante do que ter todos os data): stackoverflow.com/a/13051771/993683

1
Acho que as palavras-chave aqui estão no momento . O recurso de fallback de pesquisa do Socket.io agora é redundante, então você fica com uma biblioteca fina como wafer que possui recursos fáceis de implementar a um custo de desempenho horrível. Não me inicie: D.
21418 Luke

1
@ SamDutton, Certamente o servidor pode dobrar como um par e usar uma extremidade do próprio RTCDataChannel? Como tal, para a programação web moderna , não vejo nenhuma vantagem do websocket? desde RTCDataChannel é UDP / tempo real?
Pacerier

71

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).


4
O suporte ao navegador WebRTC é muito melhor agora. caniuse.com/#search=WebRTC
tuxayo 11/06

57

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.


2
Para os interessados, este material é explicado ainda mais aqui: stackoverflow.com/a/13051771/993683

39

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.


10

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.


10

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.


1
É um equívoco que o WebRTC seja estritamente um protocolo ponto a ponto. Está começando a ver o uso generalizado na indústria como uma alternativa VOIP baseada em servidor.
PhoticSphere

Além disso, quando implementamos o WebSocket como um fluxo de mídia do WebRTC, ele usa o SIP e o SIP é um protocolo de texto sem formatação usado para o VoIP.
M. Rostami

6

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.


3

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.