Programação · Web · Redes

O que é um WebSocket?

A maior parte da web funciona por pedido e resposta: o navegador pergunta, o servidor responde, a ligação fecha. Isso é ótimo para carregar uma página, mas desmorona quando se quer atualizações ao vivo — uma mensagem de chat, uma cotação de bolsa, uma jogada multijogador — que o servidor precisa de enviar no momento em que acontecem. Um WebSocket é a resposta padrão. Este guia explica o que é um WebSocket, em que difere do HTTP comum, e quando se precisa mesmo de um.

A ideia central: uma ligação, ambos os sentidos

Um WebSocket é uma ligação persistente e bidirecional (full-duplex) entre um cliente — normalmente um navegador — e um servidor. Uma vez aberta, qualquer dos lados pode enviar uma mensagem a qualquer momento, sem que o outro tenha de pedir primeiro. É essa a diferença fundamental em relação a uma API HTTP normal: HTTP é um pedido, uma resposta, e acabou; um WebSocket mantém-se aberto e transporta mensagens em ambos os sentidos durante o tempo que for preciso.

Como a ligação já está aberta, as mensagens chegam com muito pouca sobrecarga e quase nenhum atraso. Não há cabeçalhos repetidos, nem um novo handshake por mensagem — apenas uma pequena frame de dados em cada sentido. É isso que torna os WebSockets adequados a tudo o que tenha de parecer instantâneo.

Como arranca um WebSocket: o handshake HTTP

Um WebSocket não surge do nada — começa como um pedido HTTP comum. O navegador envia um pedido normal com um cabeçalho Upgrade: websocket, pedindo essencialmente ao servidor para trocar de protocolo. Se o servidor concordar, responde com o estado 101 Switching Protocols, e a partir daí a mesma ligação TCP deixa de falar HTTP e passa a falar o protocolo WebSocket. É por isso que os WebSockets viajam pelas mesmas portas da web (80 e 443) e atravessam a maioria das firewalls que já permitem o tráfego web.

Depois do handshake, os dados movem-se como frames leves. Cada mensagem pode ser texto — muitas vezes JSON — ou binária, e não há uma forma fixa de pedido/resposta: as mensagens simplesmente fluem quando há algo a enviar.

ws vs wss

Os URL de WebSocket usam o seu próprio esquema. ws:// é uma ligação não cifrada, e wss:// é a versão cifrada, protegida com TLS exatamente como o está https://. Na prática, deve usar sempre wss:// em produção — é cifrado e é muito menos provável que seja bloqueado por proxies e redes empresariais que desconfiam do tráfego ws:// em claro.

Quando usar um WebSocket (e quando não)

Os WebSockets brilham sempre que o servidor tem de enviar dados ao cliente assim que acontecem:

• Chat e mensagens — as mensagens aparecem no instante em que são enviadas.
• Painéis e cotações ao vivo — tickers de bolsa, métricas, resultados desportivos.
• Colaboração — documentos e quadros partilhados onde as edições sincronizam ao vivo.
• Jogos multijogador — atualizações de estado de baixa latência em ambos os sentidos.
• Notificações — tudo o que o utilizador deve ver sem recarregar.

Não são a ferramenta certa para tudo. Se o cliente apenas pergunta e o servidor apenas responde — carregar uma página, submeter um formulário, obter um registo — uma simples API HTTP é mais simples, cacheável e mais fácil de escalar. Recorra a um WebSocket quando for o servidor a ter de iniciar a conversa.

WebSockets vs polling vs SSE

Antes dos WebSockets, o truque habitual para dados «ao vivo» era o polling: o cliente pergunta ao servidor «há algo novo?» de poucos em poucos segundos. Funciona, mas é um desperdício — a maioria dos pedidos volta vazia, e as atualizações continuam atrasadas pelo intervalo de polling. Um WebSocket substitui tudo isso por uma ligação aberta e zero pedidos desperdiçados.

Há também os Server-Sent Events (SSE), que dão um fluxo de sentido único do servidor para o cliente sobre HTTP simples. SSE é mais simples quando só precisa que o servidor envie (um feed de notícias, uma barra de progresso). Escolha um WebSocket quando precisar que as mensagens fluam em ambos os sentidos, e SSE quando um sentido chega.

Uma nota sobre a infraestrutura

Como um WebSocket mantém uma ligação aberta, muda a forma como faz o deploy. As ligações de longa duração precisam de um servidor e de um proxy reverso configurados para as manter vivas em vez de as encerrar por timeout, e escalar muitas ligações simultâneas é um problema de design por si só. É esse o compromisso: um WebSocket dá-lhe comunicação instantânea e bidirecional em troca de manter um estado aberto no servidor.

Em resumo

Um WebSocket é uma ligação única, persistente e bidirecional que permite ao servidor e ao navegador trocar mensagens no momento em que acontecem — sem o ritmo de pedir-e-esperar do HTTP. Começa a vida como um pedido HTTP que é atualizado (upgrade) e depois transporta frames leves em ambos os sentidos. Use wss://, recorra a ele quando o servidor precisar de enviar dados ao vivo, e mantenha-se numa API HTTP normal quando bastar um simples pedido e resposta.