WebSocket vs HTTP: o guia para comunicação em tempo real

Bora codar!

HTTP: o protocolo que conhecemos

O modelo request-response.

1. O cliente faz uma requisição: seu navegador pede algo ao servidor (ex: "me envie a página inicial").

2. O servidor processa: o servidor recebe o pedido e encontra o recurso solicitado.

3. O servidor retorna uma resposta: o servidor envia os dados de volta (ex: "aqui está o HTML da página inicial").

4. A conexão fecha: tradicionalmente, após a resposta ser enviada, a conexão entre o cliente e o servidor é encerrada.

Características principais do HTTP.

• Stateless (sem estado): o HTTP não se lembra das requisições anteriores. Cada requisição é tratada como se fosse a primeira vez que o cliente interage com o servidor. (Usamos cookies e sessions para contornar isso, mas o protocolo em si é stateless).

• Unidirecional: a comunicação é sempre iniciada pelo cliente. O servidor só responde quando perguntado.

• Orientado a conexão (mas temporária): embora versões modernas do HTTP (como HTTP/1.1 e HTTP/2) usem técnicas como keep-alive para reutilizar a mesma conexão para múltiplas requisições, o modelo mental ainda é de interações curtas.

Quando o HTTP brilha?

• Carregar páginas web tradicionais (blogs, portfólios).

• Construir APIs REST para operações CRUD (criar, ler, atualizar, deletar dados).

• Enviar formulários.

• Buscar dados que não mudam com frequência.

async function buscarDadosDoUsuario(userId) {
  // Isso é uma requisição HTTP GET
  const resposta = await fetch(`https://api.exemplo.com/users/${userId}`);
  const dados = await resposta.json();
  return dados;
}

WebSocket: comunicação em tempo real

Conexão persistente e bidirecional.

Como o WebSocket funciona na prática?

1. Handshake inicial: o cliente envia uma requisição HTTP especial para o servidor, pedindo para "atualizar" o protocolo de HTTP para WebSocket (chamado de handshake).

2. Conexão estabelecida: se o servidor aceitar, a conexão é atualizada e permanece aberta.

3. Comunicação bidirecional: agora, tanto o cliente quanto o servidor podem enviar mensagens a qualquer momento, sem a necessidade de uma nova requisição.

Características principais do WebSocket.

• Full-duplex: a comunicação acontece simultaneamente nos dois sentidos.

• Baixa latência: como a conexão já está aberta, os dados são transmitidos imediatamente.

• Conexão persistente: a conexão dura enquanto a aplicação estiver em uso.

• Overhead mínimo: após o handshake inicial, as mensagens trocadas são muito leves, pois não precisam carregar todos os headers HTTP repetidamente.

Quando o WebSocket brilha?

• Aplicações de chat.

• Notificações instantâneas (push notifications).

• Jogos online multiplayer.

• Dashboards com dados ao vivo (ex: monitoramento de ações financeiras).

• Ferramentas de colaboração em tempo real (como editar um documento simultaneamente com outras pessoas).

// Estabelece a conexão WebSocket (wss:// significa WebSocket seguro, como https://)
const socket = new WebSocket("wss://api.exemplo.com/chat");

// Ouve por mensagens vindas do servidor
socket.onmessage = (event) => {
  console.log("Mensagem recebida:", event.data);
};

// Envia uma mensagem para o servidor
function enviarMensagem(texto) {
  socket.send(texto);
}

WebSocket vs HTTP:

Modelo de comunicação.

• HTTP: modelo de pergunta e resposta. O cliente pergunta, o servidor responde.

• WebSocket: modelo de conversa contínua. Ambos os lados podem iniciar a comunicação a qualquer momento.

Estabelecimento de conexão.

• HTTP: requer o estabelecimento de uma conexão (ou o reuso de uma existente via keep-alive) para cada interação. Isso adiciona tempo ao processo.

• WebSocket: estabelece uma única conexão que dura toda a sessão do usuário.

Overhead e performance.

• HTTP: cada requisição carrega consigo headers HTTP (cookies, user-agent, etc.). Em aplicações que fazem muitas requisições pequenas, o peso desses headers pode ser maior que os dados em si.

• WebSocket: após o handshake inicial, as mensagens trocadas têm um overhead mínimo. Apenas os dados necessários são transmitidos.

Escalabilidade.

• HTTP: por ser stateless, é mais fácil de escalar horizontalmente. Você pode adicionar mais servidores e distribuir as requisições entre eles sem se preocupar com qual servidor atendeu o cliente antes.

• WebSocket: escalar aplicações WebSocket é mais complexo. Como as conexões são persistentes e stateful (mantêm estado), você precisa garantir que um cliente específico continue se comunicando com o mesmo servidor, ou usar soluções mais avançadas para sincronizar o estado entre múltiplos servidores (como Redis pub/sub).

Comparativo:

Exemplos:

• Cenário 1: Mayk está construindo uma API para um blog. Os usuários vão ler posts, deixar comentários e buscar artigos.
• Solução: HTTP (API REST). A interação é baseada em ações do usuário (clicar em um link, enviar um comentário) e não exige atualizações instantâneas do servidor.

• Cenário 2: Isabela precisa desenvolver um sistema de leilão online, onde os lances precisam ser atualizados instantaneamente para todos os participantes.
• Solução: WebSocket. A baixa latência é crítica, e o servidor precisa notificar todos os clientes imediatamente quando um novo lance é feito.

• Cenário 3: Rodrigo está criando um feed de notícias que se atualiza automaticamente, mas as notícias vêm apenas do servidor para o cliente.
• Solução: WebSocket poderia funcionar, mas talvez seja exagero. Uma alternativa como Server-Sent Events (SSE), que veremos a seguir, pode ser mais simples.

Como escolher entre HTTP e WebSocket?

Use HTTP quando:

• Você precisa apenas buscar ou enviar dados ocasionalmente.

• A interação é iniciada pelo usuário (cliques, submissão de formulários).

• Você está construindo uma API REST tradicional.

• Simplicidade de implementação e escalabilidade são prioridades.

• Você não precisa de atualizações em tempo real com latência ultra baixa.

Use WebSocket quando:

• Você precisa de atualizações instantâneas vindas do servidor.

• A latência baixa é um requisito crítico para a experiência do usuário.

• Há uma troca constante e frequente de mensagens pequenas.

• Você está construindo interações complexas em tempo real.

• O overhead de múltiplas requisições HTTP (polling) se torna um problema de performance.

Considere alternativas!

• Server-Sent Events (SSE): uma ótima alternativa quando você precisa de atualizações em tempo real, mas a comunicação é unidirecional (apenas do servidor para o cliente). É mais simples de implementar que WebSocket e funciona sobre HTTP tradicional. Ideal para feeds de notícias ou atualizações de status.

• HTTP/2 e HTTP/3: as versões mais novas do HTTP trouxeram melhorias significativas de performance, como multiplexação (várias requisições na mesma conexão). O server push foi introduzido no HTTP/2, porém foi descontinuado/depredado nos navegadores e não está disponível no HTTP/3.

• Long Polling: uma técnica mais antiga onde o cliente faz uma requisição HTTP e o servidor segura a resposta até ter novos dados. Embora funcione, geralmente é menos performático que WebSocket ou SSE.

Checklist para decisão.

1. Preciso de comunicação bidirecional (cliente e servidor enviando dados livremente)?

2. A aplicação exige atualizações instantâneas (latência muito baixa)?

3. A operação é ocasional e iniciada pelo usuário?