POR QUE OUTRO PROTOCOLO?
HTTP responde muito bem a pedidos; eventos frequentes pedem outro ritmo.
No HTTP clássico, o cliente inicia uma requisição e o servidor produz uma resposta. Para uma notícia, um formulário ou uma API, isso é excelente. Em chat, telemetria, jogos e colaboração simultânea, o servidor precisa entregar novidades assim que elas surgem.
Perguntar periodicamente
O cliente consulta “há algo novo?” em intervalos. É simples, mas o intervalo cria atraso e requisições vazias.
Esperar uma resposta
O servidor segura a resposta até surgir evento ou expirar. Depois, o cliente abre outra requisição.
Eventos do servidor
Server-Sent Events mantém um fluxo textual servidor → cliente, com reconexão prevista pela API do navegador.
Duas direções
Cliente e servidor enviam frames de texto, binários e controle por um canal estabelecido após o handshake.
Laboratório visual · Polling × WebSocket
Compare perguntas HTTP repetidas com um canal aberto.
Polling: o cliente pergunta repetidamente se existe novidade. É simples e útil em atualizações pouco frequentes, mas cria trocas mesmo quando nada mudou.
WEBSOCKET POR DENTRO
Começa com HTTP; depois passa a transportar frames WebSocket.
No caminho tradicional sobre HTTP/1.1, o navegador pede uma mudança de protocolo. Se o servidor aceitar, responde com 101 Switching Protocols. A conexão TCP permanece aberta, mas as mensagens seguintes já usam frames WebSocket.
GET /chat HTTP/1.1
Host: exemplo.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: valor-aleatório
Sec-WebSocket-Version: 13
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: prova-calculada| Conceito | O que significa | Decisão prática |
|---|---|---|
| Texto e binário | Frames de dados podem carregar strings UTF-8 ou bytes. | JSON é legível; formatos binários podem ser menores, mas exigem schema. |
| Ping e pong | Frames de controle ajudam a verificar se a outra ponta responde. | Não confundir com a mensagem “ping” criada pela aplicação. |
| Fechamento | Existe um handshake de encerramento com código e motivo. | A aplicação deve limpar estado e decidir quando reconectar. |
wss:// | WebSocket protegido por TLS. | Em produção, protege o canal e atravessa melhor infraestruturas na porta 443. |
| Backpressure | Produzir mais rápido que a rede consome acumula dados. | Limitar filas, descartar eventos obsoletos ou reduzir a taxa. |
MQTT · PUBLISH/SUBSCRIBE
Publicadores não precisam conhecer seus consumidores.
No MQTT, todos os clientes conversam com um broker. Os consumidores registram os assuntos que desejam receber; depois, o publicador envia uma mensagem identificada por um tópico. O broker compara esse tópico com as assinaturas e cria uma entrega separada para cada consumidor compatível.
Laboratório visual · O caminho completo de uma mensagem MQTT
Avance pelas etapas para acompanhar SUBSCRIBE, PUBLISH, comparação, distribuição e confirmação.
1 · SUBSCRIBE: cada consumidor envia seu filtro ao broker. O broker guarda essas assinaturas; o sensor não participa dessa etapa e não recebe a lista de consumidores.
Registrar interesse
O consumidor pede ao broker eventos que combinem com um filtro, como casa/+/temperatura.
Enviar um evento
O sensor envia ao broker um tópico, um payload e opções de entrega. Não informa nomes ou endereços de consumidores.
Comparar os filtros
O broker confronta o tópico publicado com sua tabela de assinaturas, permissões e sessões ativas.
Criar as entregas
Uma publicação de entrada pode originar zero, uma ou várias entregas de saída, somente para quem combinar.
Confirmar por enlace
Com QoS 1, por exemplo, cada ligação cliente–broker confirma sua própria entrega com PUBACK.
casa/sala/temperaturaTópico específico: localização e grandeza aparecem como níveis separados.casa/+/temperatura+ substitui exatamente um nível: qualquer cômodo, apenas temperatura.casa/## cobre todos os níveis restantes: tudo que estiver abaixo de casa/.QoS descreve a entrega entre cada cliente e o broker
| QoS | Promessa | Custo e cuidado |
|---|---|---|
| 0 · no máximo uma vez | Envia sem confirmação. Pode perder. | Menor tráfego; útil quando a próxima medição substitui a anterior. |
| 1 · pelo menos uma vez | Reenvia até confirmar. Pode duplicar. | Consumidor precisa tolerar e deduplicar efeitos. |
| 2 · exatamente uma vez | Usa uma troca adicional para evitar duplicidade naquela ligação MQTT. | Maior custo; não transforma sozinho todo o processo de negócio em “exactly once”. |
Retained message guarda no broker a última mensagem marcada para o tópico e a oferece a novos assinantes. Will message permite ao broker publicar um aviso se o cliente desconectar de forma anormal. Session expiry controla por quanto tempo assinaturas e mensagens pendentes podem sobreviver à desconexão.
NÃO SÃO CONCORRENTES DIRETOS
WebSocket é um canal; MQTT é um protocolo de mensageria.
| Pergunta | WebSocket | MQTT |
|---|---|---|
| Modelo | Conversa bidirecional entre duas pontas. | Publicação e assinatura mediadas por broker. |
| Roteamento | A aplicação implementa salas, destinos e distribuição. | Tópicos e filtros fazem parte do protocolo. |
| Entrega | O transporte é confiável, mas confirmação de negócio é da aplicação. | Possui QoS por enlace cliente ↔ broker. |
| Navegador | API nativa amplamente disponível. | Pode rodar sobre WebSocket com biblioteca; MQTT direto sobre TCP não é exposto à página. |
| Exemplos | Chat, edição colaborativa, painel, jogo. | IoT, telemetria, automação, dispositivos intermitentes. |
PARE E PENSE
Um sensor publica temperatura a cada segundo. O painel desconecta por cinco minutos. Ao voltar, ele precisa de todas as 300 medições ou apenas da mais recente?
A resposta muda a escolha entre retained message, sessão persistente, QoS e um banco histórico.
CONTINUE EXPLORANDO
Referências e itens adicionais de estudo
Referências técnicas
Especificações oficiais usadas nesta aula.
- RFC 6455 · The WebSocket Protocol — handshake, frames e fechamento.
- RFC 8441 · Bootstrapping WebSockets with HTTP/2 — CONNECT estendido.
- OASIS · MQTT Version 5.0 — especificação normativa.
- MQTT.org — visão geral e ecossistema.
- MDN · Server-Sent Events — alternativa unidirecional.
Itens adicionais de estudo
Exercícios para consolidar o modelo.
- No DevTools, filtre por WS, abra uma conexão e observe frames em Messages.
- Modele tópicos para uma escola: prédio, sala, dispositivo e grandeza. Teste
+e#. - Use o broker público do Mosquitto somente com dados descartáveis e não sensíveis.
- Compare WebSocket, SSE e polling por direção, reconexão, cache, proxy e complexidade.
- Desenhe uma política de backpressure para um painel que fica lento.