WebSocket vs Server-Sent Events vs Long Polling vs WebRTC vs WebTransport
- Em aplicações web modernas em tempo real, a capacidade de transmitir eventos do servidor para o cliente é essencial.
- Essa necessidade levou ao desenvolvimento de vários métodos, cada um com suas vantagens e desvantagens.
- No início, o long polling era a única opção disponível, mas depois surgiu o WebSocket, uma solução mais robusta para comunicação bidirecional.
- Depois do WebSocket, surgiu uma forma mais simples de comunicação unidirecional do servidor para o cliente: os Server-Sent Events (SSE).
- O protocolo WebTransport oferece uma abordagem mais eficiente, flexível e escalável, e parece estar prestes a inovar ainda mais essa área.
- Para casos de uso específicos, o WebRTC também pode ser considerado para eventos entre servidor e cliente.
O que é long polling?
- O long polling é a primeira técnica de “hack” que tornou possível um método de mensagens entre servidor e cliente utilizável no navegador por meio de HTTP.
- Diferentemente do polling tradicional, em que o cliente solicita dados periodicamente ao servidor, o long polling estabelece uma conexão com o servidor que permanece aberta até que novos dados estejam disponíveis.
- Quando o servidor tem novas informações, ele envia uma resposta ao cliente e fecha a conexão.
- O cliente inicia uma nova requisição imediatamente após receber a resposta do servidor, e esse processo se repete.
- Esse método permite atualizações de dados mais imediatas e reduz tráfego de rede desnecessário e carga no servidor.
- No entanto, ainda pode causar latência de comunicação e é menos eficiente do que outras tecnologias em tempo real, como o WebSocket.
O que é WebSocket?
- O WebSocket fornece um canal de comunicação full-duplex por meio de uma única conexão persistente entre cliente e servidor.
- Essa tecnologia permite a troca de dados entre navegador e servidor sem a sobrecarga do ciclo de requisição-resposta do HTTP, o que a torna adequada para transmissão de dados em tempo real.
- O WebSocket representa um grande avanço em relação ao HTTP tradicional, pois, uma vez estabelecida a conexão, ambos os lados podem enviar dados de forma independente, sendo ideal para cenários que exigem baixa latência e atualizações em alta frequência.
O que são Server-Sent Events?
- Os Server-Sent Events (SSE) fornecem uma forma padronizada de enviar atualizações do servidor para o cliente por meio de HTTP.
- Diferentemente do WebSocket, o SSE foi projetado apenas para comunicação unidirecional do servidor para o cliente, sendo ideal para situações em que o cliente precisa receber atualizações em tempo real sem precisar enviar dados ao servidor.
O que é a API WebTransport?
- O WebTransport é uma API moderna projetada para comunicação eficiente e de baixa latência entre clientes web e servidores.
- Ela aproveita o protocolo HTTP/3 QUIC para possibilitar diversas capacidades de transmissão de dados.
- O WebTransport é uma ferramenta poderosa para aplicações que exigem rede de alto desempenho, como jogos em tempo real, streaming ao vivo e plataformas colaborativas.
- O WebTransport está atualmente em estágio de working draft e ainda não foi amplamente adotado.
O que é WebRTC?
- O WebRTC (Web Real-Time Communication) é um projeto open source e um padrão de API que permite funcionalidades de comunicação em tempo real (RTC) em navegadores web e aplicações móveis, sem a necessidade de infraestrutura de servidor complexa ou instalação de plugins adicionais.
- O WebRTC oferece suporte a conexões peer-to-peer para troca de áudio, vídeo e dados entre navegadores.
- O WebRTC foi projetado para funcionar através de NAT e firewalls, usando protocolos como ICE, STUN e TURN para estabelecer conexões entre pares.
Limitações das tecnologias
- Apenas o WebSocket e o WebTransport permitem enviar dados nos dois sentidos.
- O limite de 6 requisições por domínio restringe a usabilidade de todos os métodos persistentes de mensagens entre servidor e cliente.
- Em aplicativos móveis, o sistema operacional move automaticamente o app para segundo plano após um período de inatividade, fechando conexões abertas.
- Em ambientes corporativos, muitos proxies e firewalls bloqueiam conexões que não sejam HTTP, o que dificulta integrar servidores WebSocket à infraestrutura.
Comparação de desempenho
- Para comparar diretamente o desempenho de WebSocket, SSE, long polling e WebTransport, é preciso avaliar aspectos importantes como latência, throughput, carga no servidor e escalabilidade em diferentes condições.
Latência
- WebSocket: oferece a menor latência com comunicação full-duplex por meio de uma única conexão persistente.
- Server-Sent Events: oferece baixa latência para comunicação do servidor para o cliente, mas não permite enviar mensagens ao servidor sem requisições HTTP adicionais.
- Long polling: resulta em latência mais alta, pois depende de estabelecer uma nova conexão HTTP para cada transmissão de dados.
- WebTransport: espera-se que ofereça baixa latência semelhante à do WebSocket, aproveitando o protocolo HTTP/3 para multiplexação mais eficiente e melhor controle de congestionamento.
Throughput
- WebSocket: pode atingir alto throughput graças à conexão persistente, mas esse throughput pode cair quando o cliente não consegue processar os dados na mesma velocidade em que o servidor pode enviá-los.
- Server-Sent Events: pode alcançar maior throughput em comunicação unidirecional servidor-cliente, pois consegue transmitir mensagens para muitos clientes com menos sobrecarga do que o WebSocket.
- Long polling: em geral oferece throughput menor devido à sobrecarga de abrir e fechar conexões com frequência.
- WebTransport: espera-se que suporte alto throughput tanto para streams bidirecionais quanto unidirecionais dentro de uma única conexão, podendo superar o WebSocket em cenários que exigem múltiplos streams.
Escalabilidade e carga no servidor
- WebSocket: manter um grande número de conexões WebSocket pode aumentar significativamente a carga no servidor, o que pode afetar a escalabilidade de aplicações com muitos usuários.
- Server-Sent Events: é mais escalável que o WebSocket em cenários voltados principalmente a atualizações do servidor para o cliente, porque tem menos sobrecarga de conexão.
- Long polling: tem a pior escalabilidade devido à alta carga no servidor causada pelo estabelecimento frequente de conexões.
- WebTransport: foi projetado para tirar proveito da eficiência do HTTP/3 no tratamento de conexões e streams, oferecendo alta escalabilidade com menor carga no servidor em comparação com WebSocket e SSE.
Recomendações e adequação por caso de uso
- No cenário das tecnologias de comunicação entre servidor e cliente, cada uma tem vantagens próprias e melhor adequação a determinados casos de uso.
- Server-Sent Events (SSE) é a opção mais simples de implementar e pode evitar problemas técnicos ao contornar restrições de firewalls corporativos.
- WebSocket se destaca em cenários que exigem comunicação bidirecional persistente.
- WebTransport enfrenta dificuldades de adoção, não é amplamente suportado por frameworks de servidor, incluindo Node.js, e não é compatível com o Safari.
- Long polling é ineficiente e, devido à alta sobrecarga de estabelecer repetidamente novas conexões HTTP, não é recomendado para a maioria dos casos de uso.
Problemas conhecidos
- Todas as tecnologias de streaming em tempo real têm problemas conhecidos.
- O cliente pode perder eventos que ocorrerem no servidor enquanto estiver conectando, reconectando ou offline.
- Firewalls corporativos podem causar problemas no uso de tecnologias de streaming.
Opinião do GN⁺
- Este artigo compara diversas tecnologias de comunicação disponíveis para desenvolvedores ao criar aplicações web em tempo real, oferecendo informações úteis para a escolha da tecnologia.
- WebSocket e SSE já são amplamente usados e, em especial, o WebSocket é muito popular em aplicações que exigem comunicação bidirecional, como chat em tempo real ou jogos.
- O WebTransport ainda está em fase de rascunho e não conta com amplo suporte, o que pode torná-lo difícil de aplicar em projetos reais. Ainda assim, vale atenção pelo grande potencial futuro como tecnologia baseada em HTTP/3.
- O long polling é uma tecnologia antiga, mas ainda pode ser útil em certas situações, especialmente quando a compatibilidade com sistemas legados é importante.
- Ao escolher uma tecnologia de comunicação em tempo real, é preciso considerar os requisitos da aplicação, os navegadores e a infraestrutura de servidor suportados, além do nível de maturidade da tecnologia.
1 comentários
Comentários do Hacker News
Expressa apreço por Server Sent Events (SSE), ao mesmo tempo em que menciona a ausência de controle de fluxo (backpressure) e multiplexação no WebSockets, a impossibilidade de transmitir dados binários no SSE e possíveis problemas de adoção do WebTransport.
Aponta a dificuldade de implementar recursos em tempo real em ambientes corporativos e os limites para resolver problemas por causa da burocracia, sugerindo adicionar um botão de atualizar como solução simples.
Considerando HTTP/2 ou superior, há a opinião de que a combinação de EventSource e fetch() parece ser tão boa quanto outros protocolos que usam uma única conexão TCP, além de mencionar o uso de UDP no HTTP/3.
Diz não entender por que WebSockets e SSE não oferecem suporte ao envio de cabeçalhos na requisição inicial, apontando que isso acaba sendo deixado para quem implementa a autenticação de serviços em tempo real.
Menciona problemas de gerenciamento em larga escala com WebSockets e SSE, exigências especiais de observabilidade no backend, dificuldade de depuração em dispositivos móveis, custo das conexões de rede e dificuldade de manter estado.
Compartilha a experiência de ter lidado com atualizações em tempo real por meio de server push/HTTP streaming em um sistema de leilão online projetado nos anos 90.
Demonstra saudade da simplicidade do long polling e também faz uma avaliação positiva do WebRTC.
Como alguém que trabalha na Stream, recomenda o uso de websockets com pings keep-alive a cada 30 segundos na maioria dos casos, e menciona considerar o WebTransport pela baixa latência e para jogos em tempo real ou transmissão de voz.
Apresenta uma opinião crítica sobre o artigo não mencionar a vantagem da comunicação baseada em UDP no WebRTC.