O que é um WebSocket e quando você realmente precisa de um
Publicado em 2026-09-12 por frfrand
Una conexión que queda abierta en las dos direcciones. Cómo empieza siendo HTTP y deja de serlo, qué cuesta mantenerla, y por qué muchas veces alcanza con algo más simple.
HTTP tem uma propriedade que define quase todo o desenvolvimento web: o cliente pergunta e o servidor responde. O servidor nunca fala primeiro.
Para um site de conteúdo isso está perfeito. Para um chat, um painel ao vivo ou uma edição colaborativa, é um problema: o servidor sabe algo novo e não tem como avisar você.
Os WebSockets resolvem exatamente isso.
Como começa
O interessante é que começa como uma requisição HTTP normal, com um cabeçalho especial:
GET /ws HTTP/1.1 Upgrade: websocket Connection: Upgrade
Se o servidor aceitar, responde com um código pouco comum:
HTTP/1.1 101 Switching Protocols
A partir desse momento essa conexão TCP deixa de falar HTTP. Fica aberta, e os dois lados podem enviar mensagens quando quiserem, sem pedir permissão.
Esse design (começar como HTTP e depois mudar) não é capricho: é o que permite que funcione através de proxies e firewalls que só esperam tráfego web. Usa as mesmas portas 80 e 443.
O que custa
Uma conexão aberta por cliente. Mil usuários conectados são mil conexões vivas, cada uma ocupando memória e um descritor de arquivo. É manejável, mas precisa ser dimensionado com propósito: os limites padrão de descritores abertos são alcançados antes do que se espera.
O estado deixa de ser trivial. Com HTTP você pode colocar dez servidores atrás de um balanceador e cada requisição vai para qualquer um. Com WebSockets, o cliente fica vinculado a um servidor específico. Se você quiser que uma mensagem chegue a um usuário conectado a outro servidor, precisa de algo no meio que distribua (tipicamente Redis).
A reconexão é por sua conta. As conexões caem: muda de Wi-Fi para dados, o telefone dorme, um proxy fecha por inatividade. O navegador não reconecta sozinho. É preciso implementar tentativas com espera crescente e, acima de tudo, recuperar o que aconteceu enquanto você esteve desconectado. Esse segundo ponto é o mais esquecido e o que gera bugs difíceis.
Os intermediários cortam. Muitos proxies fecham conexões inativas após um minuto ou cinco. Por isso se envia um ping periódico, não pelo protocolo, mas para que ninguém acredite que a conexão está morta.
Quando vale a pena e quando não
Vale a pena quando o servidor precisa falar primeiro, seguido: chat, notificações instantâneas, cotações ao vivo, edição colaborativa, jogos, painéis que se atualizam sozinhos.
Não vale a pena quando o evento é pouco frequente ou quando o cliente pode perguntar sem custo. Manter mil conexões abertas para avisar de algo que acontece três vezes por dia é um desperdício com manutenção incluída.
As alternativas que se esquecem
Consultar cada tanto. Suena primitivo y muchas veces es la respuesta correcta. Si el dato cambia cada pocos minutos y la aplicación no necesita reaccionar en el instante, una consulta periódica é infinitamente mais simples de operar.
Server-Sent Events. Uma conexão aberta onde apenas o servidor envia, sobre HTTP normal. O navegador se reconecta sozinho, o que elimina a parte mais incômoda. Se você só precisa receber (notificações, progresso de uma tarefa, um painel que se atualiza), isso geralmente é melhor que um WebSocket e quase ninguém o considera.
A pergunta que ordena a decisão: você precisa enviar dados do cliente para o servidor por esse mesmo canal, e muito frequentemente? Se a resposta for não, provavelmente você não precisa de um WebSocket.
Uma nota sobre o proxy
Se você colocar o nginx na frente, é necessário configurá-lo para não quebrar a atualização de protocolo:
location /ws { proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 3600s; }
Sem essas linhas, a conexão é estabelecida e cai no minuto, que é um dos erros mais frustrantes de diagnosticar porque "funciona localmente".