WebSockets: comunicação bidirecional em tempo real

O que são WebSockets e como diferem do HTTP

Full-duplex sobre uma única conexão TCP

WebSockets é um protocolo de comunicação bidirecional e full-duplex que opera sobre uma única conexão TCP persistente. Diferente do HTTP, que é fundamentalmente requisicao-resposta (o servidor só envia dados quando o cliente solicita), WebSockets permitem que servidor e cliente enviem dados independentemente e simultaneamente, a qualquer momento, sem necessidade de nova requisicao. Essa característica é o que torna WebSockets obrigatórios para aplicações como chats em tempo real, dashboards de monitoramento ao vivo, feeds de cotacoes financeiras e jogos multiplayer, onde o servidor precisa empurrar dados para o cliente imediatamente quando eventos ocorrem, sem esperar uma requisicao iniciada pelo cliente.

O handshake WebSocket - upgrade de HTTP para WS

Como a conexão é estabelecida

Uma conexão WebSocket começa como uma requisicao HTTP GET comum com headers especiais: Upgrade: websocket e Connection: Upgrade. O servidor responde com HTTP 101 Switching Protocols, confirmando o upgrade do protocolo. A partir desse momento, a conexão TCP que estava sendo usada pelo HTTP é "promovida" para o protocolo WebSocket, e ambas as partes podem enviar frames a qualquer instante sem overhead de headers HTTP. O URL de conexão usa o schema ws:// para conexões não criptografadas ou wss:// para conexões sobre TLS, sendo wss:// obrigatório em produção por transitar pela internet aberta. O handshake inclui um mecanismo de Sec-WebSocket-Key e Sec-WebSocket-Accept para verificar que o servidor compreende o protocolo WebSocket.

Frames e mensagens - como dados são transmitidos

A estrutura de comunicação no protocolo WebSocket

Dados no protocolo WebSocket são transmitidos em frames, que podem carregar texto (UTF-8), dados binários ou frames de controle como ping, pong e close. Mensagens grandes são fragmentadas em múltiplos frames e remontadas pelo receptor. O mascaramento de payload é obrigatório para frames enviados pelo cliente (para prevenir ataques de cache poisoning em proxies intermediários) mas proibido para frames do servidor. Frames de controle ping/pong são usados para keepalive: o servidor envia pings periodicamente, e clientes que não respondem com pong dentro de um timeout são considerados desconectados. O overhead de um frame WebSocket é mínimo (2 a 14 bytes de header) comparado ao HTTP, tornando WebSockets muito mais eficientes para mensagens frequentes de pequeno tamanho.

Escalabilidade - WebSockets em múltiplos servidores

O desafio de estado de conexão em escala

O principal desafio de escalar WebSockets é que cada conexão é stateful: ela está estabelecida com um servidor específico e o estado da conexão (usuario autenticado, sala de chat, subscricoes) fica na memória desse servidor. Quando a aplicação tem múltiplas instâncias (horizontal scaling), um cliente conectado ao servidor A não recebe mensagens enviadas de uma sessao conectada ao servidor B. Soluitar isso requer um bus de mensagens compartilhado: quando o servidor A quer enviar a todos os clientes conectados em qualquer servidor, ele pública em Redis Pub/Sub ou Kafka, e todos os servidores consomem e repassam para suas conexões locais. Esse padrao permite escalar WebSockets horizontalmente sem limites de instâncias.

Sticky sessions e estado de conexão

Roteando clientes ao servidor correto

Sticky sessions (ou session affinity) configuram o load balancer para direcionar todas as requisicoes de um cliente ao mesmo servidor de backend, garantindo que a conexão WebSocket não seja interrompida por roteamento incorreto. No AWS Application Load Balancer, sticky sessions são habilitadas via target group stickiness com um cookie AWSALB. No Nginx, o módulo ip_hash ou cookie upstream garante que o mesmo cliente sempre alcance o mesmo backend. A limitacao das sticky sessions é que elas reduzem a eficiência do balanceamento de carga: se um servidor fica sobrecarregado, novos clientes são direcionados a outros, mas os existentes permanecem no servidor congestionado. Em arquiteturas de alta escala, o padrao Redis Pub/Sub é preferido às sticky sessions por não ter essa limitacao.

WebSockets com Redis Pub/Sub para múltiplas instâncias

Mensagens entre servidores via Redis

O padrao de escalabilidade mais adotado para WebSockets é usar Redis Pub/Sub como canal de comunicação entre instâncias do servidor. Quando um evento precisa ser transmitido para um cliente específico ou broadcast para todos, o servidor que originou o evento pública em um canal Redis; todas as instâncias são subscribers desse canal e repassam a mensagem para suas conexões locais relevantes. Socket.IO, um dos frameworks WebSocket mais populares, tem suporte nativo ao Redis Adapter que implementa esse padrao automaticamente. No .NET, SignalR oferece o Redis Backplane com a mesma finalidade. Esse padrao funciona eficientemente até dezenas de instâncias; para escalas maiores, considere substituir Redis Pub/Sub por Kafka como bus de mensagens.

Heartbeat e reconexao automática

Mantendo conexões estáveis em ambientes reais

Conexões WebSocket podem cair silenciosamente por diversas razoes: timeout de proxies intermediários (muitos proxies fecham conexões inativas após 60-120 segundos), queda de rede, reinicio do servidor ou garbage collection longa no cliente. Heartbeat implementa troca periódica de ping/pong entre cliente e servidor para manter a conexão ativa e detectar desconexoes rapidamente. No lado do cliente, reconexao automática com backoff exponencial (1s, 2s, 4s, 8s...) e jitter previne tempestade de reconexoes simultâneas após uma queda. Bibliotecas como Socket.IO, Reconnecting WebSocket e SignalR implementam reconexao automática com suporte a resubmissao de eventos perdidos durante a desconexao, criando uma experiência de conexão seamless para o usuário.

Seguranca em WebSockets - WSS e autenticação

Protegendo conexões persistentes

WebSockets não têm suporte nativo a headers de autenticação no protocolo de handshake: o único ponto para autenticação é o momento do upgrade HTTP, onde headers como Authorization podem ser incluídos. A abordagem mais comum é enviar um token JWT como query parameter no URL de conexão (wss://api.exemplo.com/ws?token=JWT) ou em um header customizado durante o handshake, validando o token no servidor antes de aceitar a conexão. Uma vez estabelecida, a conexão permanece autenticada com as permissões do momento do handshake; revogacao de token requer que o servidor feche conexões ativas manualmente. Todas as conexões em produção devem usar WSS (WebSocket Secure sobre TLS), assim como HTTPS, para prevenir interceptacao e man-in-the-middle em redes não confiáveis.

Alternativas - Server-Sent Events e Long Polling

Quando WebSocket é excessivo para o caso de uso

Server-Sent Events (SSE) é uma API nativa do browser para streams unidirecionais do servidor para o cliente sobre HTTP/1.1, sem necessidade de protocolo adicional. SSE é ideal para casos onde o cliente só precisa receber dados do servidor (notificações, feeds, atualizações de status), eliminando a complexidade bidirecional dos WebSockets. Long polling simula tempo real mantendo uma requisicao HTTP aberta até o servidor ter dados para enviar, sendo compatível com qualquer servidor HTTP sem configuração especial. A regra prática: use SSE para streams unidirecionais simples, Long Polling quando WebSocket ou SSE não são suportados pela infraestrutura, e WebSocket apenas quando comunicação bidirecional em baixa latência é genuinamente necessária.

Conclusao - WebSockets como base de experiências em tempo real

Quando adotar WebSockets em produção

WebSockets transformam aplicações passivas em experiências interativas e colaborativas, mas exigem cuidado com escalabilidade, reconexao e seguranca para funcionar de forma confiável em produção. Domine os padroes de Redis Pub/Sub, heartbeat e autenticação no handshake antes de colocar WebSockets em sistemas críticos. Continue em: Fundamentos obrigatórios antes de produção.

WebSockets - Vídeos Essenciais

WebSockets explicados em 100 segundos

Escalando WebSockets com Redis Pub/Sub

SignalR no .NET - WebSockets simplificados

WebSocket vs SSE vs Long Polling

Segurança em conexões WebSocket (WSS)

Socket.IO - tempo real escalável na prática