WebSockets: comunicação em tempo real

Todo o modelo HTTP visto até aqui segue a mesma regra: o cliente pergunta, o servidor responde. Isso funciona perfeitamente pra carregar uma página, mas trava num chat ao vivo ou numa notificação instantânea — porque o servidor não pode iniciar o envio de nada. Se uma mensagem nova chega para você, o servidor não tem como simplesmente "empurrar" ela; ele só fala quando alguém pergunta.

A solução ruim: ficar perguntando (polling)

A cada 2 segundos:
  cliente → servidor: "tem mensagem nova?"
  servidor → cliente: "não" (ou "sim, aqui está")

// funciona, mas desperdiça requisição mesmo quando não tem nada novo,
// e o atraso máximo é o intervalo entre perguntas

WebSocket — a conexão HTTP vira outra coisa

Um WebSocket começa como uma requisição HTTP normal, mas pede pro servidor trocar de protocolo no meio do caminho, usando o header Upgrade. Se o servidor aceitar, a mesma conexão TCP que começou como HTTP passa a ser usada como um canal aberto dos dois lados — sem precisar abrir uma nova conexão a cada mensagem.

GET /chat HTTP/1.1
Host: howtodev.site
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade

// a partir daqui, não é mais request/response — é um canal aberto:
// qualquer um dos dois lados manda mensagem a qualquer momento

Depois do 101 Switching Protocols, a conexão deixa de seguir o ciclo pergunta-resposta do HTTP. O servidor consegue mandar uma mensagem pro cliente no instante em que ela existe — sem esperar o cliente perguntar antes. É por isso que ws:// (ou wss://, a versão sobre TLS) é a base de chat, notificação ao vivo, colaboração em tempo real e jogos multiplayer baseados em navegador.

Server-Sent Events (SSE) — quando só uma via já resolve

Nem todo caso precisa de comunicação nos dois sentidos. Um feed de notícias ao vivo ou um placar de jogo em tempo real só precisa que o servidor mande atualização pro cliente — o cliente nunca precisa responder nada pelo mesmo canal. Pra esse caso, Server-Sent Events é mais simples que WebSocket: continua sendo HTTP normal (sem upgrade de protocolo), só que a resposta nunca termina — o servidor vai escrevendo eventos novos nela conforme acontecem, e o navegador expõe isso via EventSource, já com reconexão automática embutida se a conexão cair.

HTTP/1.1 200 OK
Content-Type: text/event-stream

data: {"placar": "1-0"}

data: {"placar": "1-1"}

// a conexão HTTP fica aberta; cada "data:" novo é um evento entregue
// ao cliente sem que ele precise pedir de novo