WebSockets: comunicação bidirecional em tempo real

O que são WebSockets e como diferem do HTTP

Full-duplex sobre uma única conexao TCP

WebSockets é um protocolo de comunicacao bidirecional e full-duplex que opera sobre uma única conexao 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 aplicacoes 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 conexao é estabelecida

Uma conexao 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 conexao 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 conexao usa o schema ws:// para conexoes nao criptografadas ou wss:// para conexoes sobre TLS, sendo wss:// obrigatório em producao 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 sao transmitidos

A estrutura de comunicacao no protocolo WebSocket

Dados no protocolo WebSocket sao transmitidos em frames, que podem carregar texto (UTF-8), dados binários ou frames de controle como ping, pong e close. Mensagens grandes sao 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 sao usados para keepalive: o servidor envia pings periodicamente, e clientes que nao respondem com pong dentro de um timeout sao 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 conexao em escala

O principal desafio de escalar WebSockets é que cada conexao é stateful: ela está estabelecida com um servidor específico e o estado da conexao (usuario autenticado, sala de chat, subscricoes) fica na memória desse servidor. Quando a aplicacao tem múltiplas instancias (horizontal scaling), um cliente conectado ao servidor A nao 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 publica em Redis Pub/Sub ou Kafka, e todos os servidores consomem e repassam para suas conexoes locais. Esse padrao permite escalar WebSockets horizontalmente sem limites de instancias.

Sticky sessions e estado de conexao

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 conexao WebSocket nao seja interrompida por roteamento incorreto. No AWS Application Load Balancer, sticky sessions sao habilitadas via target group stickiness com um cookie AWSALB. No Nginx, o modulo 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 sao 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 nao ter essa limitacao.

WebSockets com Redis Pub/Sub para múltiplas instancias

Mensagens entre servidores via Redis

O padrao de escalabilidade mais adotado para WebSockets é usar Redis Pub/Sub como canal de comunicacao entre instancias do servidor. Quando um evento precisa ser transmitido para um cliente específico ou broadcast para todos, o servidor que originou o evento publica em um canal Redis; todas as instancias sao subscribers desse canal e repassam a mensagem para suas conexoes 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 instancias; para escalas maiores, considere substituir Redis Pub/Sub por Kafka como bus de mensagens.

Heartbeat e reconexao automática

Mantendo conexoes estáveis em ambientes reais

Conexoes WebSocket podem cair silenciosamente por diversas razoes: timeout de proxies intermediários (muitos proxies fecham conexoes 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 conexao 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 conexao seamless para o usuário.

Seguranca em WebSockets — WSS e autenticacao

Protegendo conexoes persistentes

WebSockets nao têm suporte nativo a headers de autenticacao no protocolo de handshake: o único ponto para autenticacao é 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 conexao (wss://api.exemplo.com/ws?token=JWT) ou em um header customizado durante o handshake, validando o token no servidor antes de aceitar a conexao. Uma vez estabelecida, a conexao permanece autenticada com as permissoes do momento do handshake; revogacao de token requer que o servidor feche conexoes ativas manualmente. Todas as conexoes em producao devem usar WSS (WebSocket Secure sobre TLS), assim como HTTPS, para prevenir interceptacao e man-in-the-middle em redes nao 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 (notificacoes, feeds, atualizacoes 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 configuracao especial. A regra prática: use SSE para streams unidirecionais simples, Long Polling quando WebSocket ou SSE nao sao suportados pela infraestrutura, e WebSocket apenas quando comunicacao bidirecional em baixa latência é genuinamente necessária.

Conclusao — WebSockets como base de experiencias em tempo real

Quando adotar WebSockets em producao

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