Tempo real (WebSocket e SSE)
Formas de o servidor enviar dados ao cliente sem esperar um pedido, e o custo de manter conexões abertas.
As decisões de tempo real são cinco: qual forma usar, como levar o evento à instância certa, como não perder eventos, como proteger as conexões e como dimensionar a infraestrutura para conexões longas.
Comparação
| Consultas periódicas | SSE | WebSocket | |
|---|---|---|---|
| Direção | Cliente pergunta | Servidor envia | Os dois enviam |
| Protocolo | HTTP comum | HTTP comum, resposta longa | Protocolo próprio, depois de um pedido HTTP |
| Atraso | Até um intervalo inteiro | Imediato | Imediato |
| Reconexão e retomada | Não se aplica | Embutidas no navegador | Por conta da aplicação |
| Dados binários | Sim | Só texto | Sim |
| Proxies e balanceadores | Sem cuidados | Cuidado com buffer e tempo de ociosidade | Precisam suportar o protocolo; tempo de ociosidade |
| Autenticação | A de sempre | A de sempre (cookie; o EventSource não envia cabeçalhos próprios) | Na abertura, por cookie, token na primeira mensagem ou na URL |
| Complexidade | Mínima | Baixa | Média a alta |
Levar o evento à instância certa
| Abordagem | Como funciona | Quando usar |
|---|---|---|
| Publicação e assinatura do Redis | Toda instância assina um canal; quem gera o evento publica nele; cada instância repassa aos clientes conectados a ela | O padrão para a maioria dos sistemas |
| Fila ou log de eventos | As instâncias consomem um tópico do Kafka ou do RabbitMQ | Quando os eventos já trafegam por um intermediário |
| Afinidade de sessão | O balanceador manda cada cliente sempre para a mesma instância | Ajuda, mas não resolve: o evento pode nascer em outra instância |
| Serviço gerenciado | Pusher, Ably, AWS AppSync, Azure Web PubSub cuidam das conexões | Quando operar conexões longas não compensa |
A publicação e assinatura do Redis não guarda mensagens: quem não estiver assinando no momento perde o evento. Para a retomada funcionar depois de uma reconexão, os eventos recentes precisam ficar guardados em algum lugar.
Não perder eventos
| Técnica | Como funciona |
|---|---|
| Identificador em cada evento | O SSE envia id:; no WebSocket, um campo na mensagem |
| Retomada a partir do último recebido | No SSE, o navegador envia Last-Event-ID sozinho; no WebSocket, o cliente informa o último identificador ao reconectar |
| Eventos recentes guardados | Um Redis Stream, uma tabela de eventos ou um log, de onde o servidor reenvia o que o cliente perdeu |
| Estado completo ao conectar | Em vez de reenviar eventos, o servidor manda o estado atual (o status do pedido agora) e só depois os eventos novos |
A última técnica costuma ser a mais simples e a mais robusta: o cliente que reconecta recebe o estado atual, e não precisa de todos os eventos intermediários. Ela funciona bem para status e painéis; não serve quando cada evento importa, como as mensagens de um chat.
Proteger as conexões
| Risco | Defesa |
|---|---|
| Conexões abertas sem autenticação | Autenticar na abertura e encerrar quando a credencial vencer |
| Um cliente abrindo milhares de conexões | Limite de conexões por usuário e por IP |
| Um cliente inundando o WebSocket de mensagens | Limite de mensagens por segundo, e tamanho máximo de mensagem |
| Origem não confiável abrindo WebSocket com o cookie do usuário | Conferir o cabeçalho Origin na abertura: o WebSocket não segue as regras de CORS |
| Token na URL do WebSocket | Aparece em logs de proxies; prefira um token de vida curta, válido só para abrir a conexão |
A linha sobre Origin merece atenção: o navegador envia os cookies do usuário ao abrir um WebSocket para qualquer domínio, e o CORS não bloqueia. Sem conferir a origem, uma página maliciosa pode abrir uma conexão autenticada em nome do usuário.
Dimensionar para conexões longas
Uma conexão de tempo real fica aberta por minutos ou horas, ao contrário de um pedido comum, que dura milissegundos. Isso muda a conta de capacidade:
| Recurso | Efeito |
|---|---|
| Descritores de arquivo | Cada conexão ocupa um; o limite do processo precisa comportar todas, como mostra o tópico de Linux |
| Memória | Cada conexão tem buffers e estado; dezenas de milhares somam gigabytes |
| Threads | Modelos de uma thread por conexão não escalam; laços de eventos, goroutines e threads virtuais sim |
| Balanceador | Precisa de tempo de ociosidade maior que o intervalo dos pulsos |
| Deploys | Cada deploy derruba as conexões da instância substituída; os clientes reconectam todos de uma vez |
O último ponto pede cuidado: um deploy que derruba 50 mil conexões gera 50 mil reconexões em segundos. Uma variação aleatória no intervalo de reconexão dos clientes espalha essa onda. No SSE, o campo retry: define o intervalo; no WebSocket, a lógica de reconexão fica no cliente.
Resumo da decisão
- SSE para atualizações do servidor ao cliente; WebSocket quando o cliente também envia muito; consultas quando as atualizações são raras.
- Publicação e assinatura entre as instâncias, para o evento chegar a quem está conectado em outra.
- Retomada: identificador por evento e, de preferência, o estado atual na reconexão.
- Uma rota comum com o estado atual, como reserva.
- Pulsos abaixo do tempo de ociosidade do balanceador; nada de buffer ou compressão no caminho.
- Segurança na abertura: autenticação,
Originno WebSocket, limites de conexões e mensagens.
O próximo nível mostra um servidor SSE nas cinco linguagens, executado com e sem Last-Event-ID, e um servidor WebSocket com pulsos.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
Escolher a forma de tempo real
Preciso acrescentar atualizações em tempo real ao meu sistema e quero escolher a forma certa. Pergunte o que precisa ser atualizado, com que frequência, quantos clientes simultâneos são esperados, se o cliente também envia dados com frequência e qual é a infraestrutura (balanceador, proxy, CDN). Compare para o meu caso consultas periódicas, SSE e WebSocket, e recomende uma forma, explicando: 1. Como os eventos chegam à instância em que o cliente está conectado. 2. Como a reconexão e a retomada vão funcionar. 3. Como fica a autenticação. 4. O que muda na configuração da infraestrutura.
Tempo real com várias instâncias
Minha aplicação roda em várias instâncias e quero que os eventos de tempo real cheguem aos clientes certos. Pergunte qual linguagem eu uso e se já existe Redis, Kafka ou outro intermediário. Explique: 1. Por que um evento gerado numa instância não chega sozinho aos clientes de outra. 2. Como usar publicação e assinatura do Redis para repassar os eventos. 3. Por que a publicação e assinatura do Redis não guarda mensagens, e como guardar os eventos recentes para a retomada (Redis Streams, tabela de eventos). 4. A alternativa de mandar o estado atual na reconexão. 5. Quando um serviço gerenciado compensa mais que operar as conexões.
Segurança em conexões de tempo real
Quero proteger as conexões SSE ou WebSocket da minha aplicação. Explique: 1. Como autenticar na abertura, com cookie, token de vida curta ou primeira mensagem, e os riscos de cada um. 2. Como encerrar a conexão quando a credencial vence. 3. Por que o WebSocket não segue as regras de CORS e como conferir o cabeçalho Origin. 4. Limites de conexões por usuário e de mensagens por segundo. 5. Como validar as mensagens recebidas pelo WebSocket. Pergunte qual linguagem e biblioteca eu uso e mostre o código para o meu caso.