WebRTC vs WebSocket: mídia e data channels peer to peer vs um socket cliente-servidor, por que o WebRTC ainda precisa de sinalização, além de webhook vs WebSocket e HTTP vs WebSocket.
O WebSocket mantém uma conexão bidirecional entre o navegador e o seu servidor, e toda mensagem passa por esse servidor. O WebRTC conecta navegadores diretamente entre si para áudio, vídeo e dados arbitrários, com criptografia DTLS e SRTP. Os dois costumam ser usados juntos: um WebSocket transporta as mensagens de sinalização que configuram a chamada WebRTC.
WebRTC e WebSocket comparados
Pergunta
WebRTC
WebSocket
Quem fala com quem
Navegador com navegador (peer to peer)
Navegador com servidor
Feito para
Áudio, vídeo, compartilhamento de tela, dados entre peers
Mensagens entre o app e o servidor
Configuração
Offer, answer e candidatos ICE pela sua própria sinalização
Um único handshake HTTP Upgrade
Opções de entrega
Data channels podem ser ordenados ou não, confiáveis ou não
Ordenada e confiável
Criptografia
Sempre ativa (DTLS, SRTP)
Só com wss://
Precisa de servidor
Para sinalização, e relays TURN quando os peers não conseguem se conectar diretamente
Sim, ele é a outra ponta
Escolha o que você está construindo no assistente abaixo e ele indica a tecnologia adequada, com o motivo. Ele também cobre as duas dúvidas que as pessoas misturam com esta: webhooks, que vão de servidor para servidor, e requisições HTTP comuns.
Escolha o recurso mais parecido com o seu.
Veja qual tecnologia se encaixa e por quê.
Role até as seções de código para ver um esboço de sinalização e um exemplo de data channel.
Use as duas tabelas perto do final para as comparações com webhook e HTTP.
Não use WebRTC para enviar atualizações do seu servidor. Ali o servidor não é um peer, e um WebSocket ou um event stream é muito mais simples.
Reserve orçamento para um relay TURN antes de lançar chamadas. Algumas redes bloqueiam conexões diretas entre peers, e aí toda a mídia passa pelo relay que você paga.
Mantenha o servidor de sinalização burro: ele só repassa offers, answers e candidatos. A MDN descreve o conteúdo como uma caixa-preta que o servidor não precisa entender.
Para um jogo ou um feed de cursores ao vivo entre peers, abra o data channel com ordered como false e maxRetransmits como 0, para que um pacote atrasado nunca bloqueie os mais novos.
Perguntas frequentes
O WebRTC substitui os WebSockets?
Não. O WebRTC não tem um jeito embutido de dois navegadores se encontrarem, então você ainda precisa de um canal para trocar as mensagens de configuração. Um WebSocket é a escolha mais comum, embora a MDN observe que qualquer transporte funciona.
O WebRTC envia dados simples, e não só vídeo?
Sim. RTCPeerConnection.createDataChannel() abre um canal para texto ou dados binários entre peers, e a API dele é propositalmente parecida com a do WebSocket, com send() e um evento message.
Qual é a diferença entre um webhook e um WebSocket?
Um webhook é uma requisição HTTP que um servidor envia para uma URL em outro servidor quando um evento acontece, e depois a conexão termina. Um WebSocket é uma conexão que fica aberta para que navegador e servidor continuem conversando.
O WebSocket é mais rápido que o HTTP?
Para muitas mensagens pequenas, geralmente sim, já que o handshake acontece uma vez e cada mensagem seguinte dispensa os cabeçalhos de requisição. Para carregar uma página ou um arquivo, o HTTP comum é a ferramenta certa e aproveita o cache.
O WebRTC é peer to peer mesmo com muita gente na chamada?
Cada conexão é entre dois peers, então uma malha completa cresce rápido conforme as pessoas entram. Muitos produtos de chamada maiores encaminham a mídia por um servidor que repassa os streams, algo que fica fora da própria API WebRTC do navegador.
Por que o WebRTC ainda precisa de um servidor
Antes que dois navegadores possam se conectar, cada um precisa conhecer a descrição de sessão do outro, uma offer e uma answer SDP, e uma lista de endereços de rede possíveis chamados candidatos ICE. O WebRTC deixa a entrega dessas mensagens por sua conta.
Depois da troca, o ICE testa os candidatos, com o STUN ajudando cada lado a descobrir seu endereço público. Se nenhuma rota direta funcionar, o tráfego recorre a um servidor TURN que o retransmite. A partir daí a mídia flui entre os peers, e não pelo seu servidor de sinalização.
Webhook vs WebSocket
Eles resolvem problemas diferentes. Um webhook permite que um serviço, como um provedor de pagamentos ou uma plataforma de código, avise o seu backend de que algo aconteceu, enviando uma requisição HTTP para uma URL que você cadastrou. Nada fica aberto e nenhum navegador participa.
Um WebSocket mantém uma linha ativa com o navegador do usuário. Um padrão comum usa os dois: um webhook avisa o seu servidor de que um pedido foi pago, e o servidor então envia essa notícia para a página aberta do cliente por um WebSocket.
HTTP vs WebSocket
O HTTP comum é requisição e resposta: o cliente pede, o servidor responde, e respostas GET podem ficar em cache nos navegadores e CDNs. É o padrão certo para páginas, arquivos e a maioria das chamadas de API.
Um WebSocket começa como uma requisição HTTP, troca de protocolo com uma resposta 101 e fica aberto. Use-o só quando o servidor precisa enviar dados que o cliente não pediu, ou quando as mensagens são tão frequentes que o custo por requisição faz diferença.
Configuração do WebRTC por um WebSocket
Quem liga: crie uma offer e um data channel
O WebSocket só repassa as mensagens de configuração. A URL do STUN é um exemplo para o servidor que você escolher.
Quem recebe: responda e receba o canal
O outro lado recebe o canal pelo evento datachannel em vez de criá-lo.
Um canal sem ordem e sem reenvio para o estado do jogo
maxRetransmits e maxPacketLifeTime não podem ser definidos juntos; escolha um.
Webhook vs WebSocket em resumo
Webhook vs WebSocket
Pergunta
Webhook
WebSocket
Quem se conecta
Um servidor chama outro servidor
Um cliente mantém uma linha aberta com um servidor
Duração
Uma requisição HTTP por evento
Aberta até um dos lados fechar
Direção
Do remetente para o destinatário
Nos dois sentidos
Uso típico
Eventos de pagamento, repositório ou formulário
Chat ao vivo, dashboards, presença
HTTP vs WebSocket em resumo
HTTP vs WebSocket
Pergunta
Requisição HTTP
WebSocket
Quem inicia uma mensagem
Sempre o cliente
Qualquer um dos lados
Conexão
Requisição, depois resposta
Atualizada com 101, depois fica aberta
Cache
Respostas GET e HEAD podem ir para o cache
Nenhum
Esquemas de URL
ws:// (porta 80), wss:// (porta 443)
Chamada de vídeo entre duas pessoas
WebRTC, com um WebSocket para a sinalização
Áudio e vídeo devem ir direto entre os participantes, com pouco atraso. Um pequeno servidor WebSocket só repassa a offer, a answer e os candidatos durante a configuração.
Sala de chat em grupo em um web app
WebSocket
As mensagens precisam ser armazenadas, moderadas e enviadas a todos na sala, então já pertencem ao seu servidor. Um socket por usuário é a solução simples.
Enviar um arquivo grande para o navegador de um amigo
WebRTC data channel
Um data channel confiável e ordenado move os bytes de peer para peer, então o seu servidor nunca armazena nem retransmite o arquivo, a menos que o TURN seja necessário.
Jogadas rápidas de um jogo para dois
WebRTC data channel, sem ordem
Com a ordenação desligada e sem reenvios, uma atualização de posição perdida é ignorada em vez de travar as mais novas. Se você precisa de um servidor árbitro, use um WebSocket até ele.
Provedor de pagamentos confirma um pedido
Webhook
O servidor do provedor chama uma URL no seu servidor quando o pagamento é aprovado. Nenhum navegador participa e nada precisa ficar aberto.
Carregar uma página de produto e seus dados
HTTP comum
Requisição e resposta é tudo de que você precisa, e respostas GET podem ir para o cache. Uma conexão persistente só traria custo, sem benefício.