MQTT vs HTTP para IoT: qual protocolo usar?

O HTTP move a web; o MQTT foi projetado para máquinas em redes instáveis. Os dois rodam sobre TCP, os dois podem ser protegidos com TLS e os dois podem transportar JSON. A diferença está no modelo de comunicação — e é esse modelo que decide qual deles se encaixa na sua carga de trabalho de IoT. Este artigo compara os dois de forma honesta, inclusive nos casos em que o HTTP é a melhor escolha.

Dois modelos de comunicação diferentes

O HTTP é request/response. Um cliente pede um recurso específico a um servidor específico e espera a resposta. O servidor não pode falar primeiro: se um dispositivo precisa saber de uma mudança, ele tem que fazer polling, manter uma requisição longa aberta ou usar um mecanismo extra, como server-sent events ou WebSockets.

O MQTT é publish/subscribe. Os clientes se conectam a um broker e mantêm a conexão aberta. Os publicadores enviam mensagens para tópicos; o broker as entrega a todos os assinantes daquele tópico. Remetentes e destinatários nunca precisam saber uns dos outros. Se o modelo é novo para você, leia primeiro o que é MQTT.

Comparação MQTT vs HTTP

Overhead e duração da bateria

Um pacote MQTT mínimo como o PINGREQ tem só 2 bytes, e uma publicação adiciona apenas o nome do tópico e o payload a um cabeçalho pequeno. Uma requisição HTTP carrega uma linha de método, um cabeçalho host e, muitas vezes, cabeçalhos de user-agent, content-type, authorization e cookies — em texto, a cada requisição. Quando um sensor envia uma leitura de 20 bytes a cada poucos segundos, esse enquadramento domina o tráfego.

O estabelecimento da conexão pesa ainda mais. Cada nova conexão HTTPS custa um handshake TCP e TLS, o que significa tempo de rádio e bateria em um dispositivo celular. O MQTT paga esse custo uma vez e depois reutiliza a conexão nas duas direções. O keep-alive do HTTP e o HTTP/2 diminuem a diferença, mas não dão ao servidor uma forma de enviar dados ao dispositivo por iniciativa própria.

Confiabilidade em redes ruins

O MQTT tem semântica de entrega no próprio protocolo. O QoS 1 e 2 confirma e retransmite mensagens, as sessões persistentes enfileiram mensagens para clientes que caem, as mensagens retidas (retained) entregam na hora a um novo assinante o último valor conhecido, e um Last Will avisa a todos quando um dispositivo desaparece sem se despedir. Com HTTP, você constrói cada uma dessas coisas por conta própria: retentativas, chaves de idempotência, um armazenamento de status e um endpoint de heartbeat.

Segurança

Os dois protocolos dependem do TLS para criptografia, então nenhum é intrinsecamente mais seguro. A diferença está em onde acontece a autorização. Uma API HTTP autentica cada requisição, normalmente com um token, e a autoriza por endpoint. Um broker MQTT autentica uma vez no CONNECT (usuário/senha, certificados de cliente ou, no MQTT 5, autenticação estendida) e depois autoriza cada publicação e assinatura com base em regras de acesso por tópico. Uma hierarquia de tópicos bem projetada faz, portanto, parte do seu modelo de segurança: uma regra como este dispositivo só pode publicar na sua própria subárvore é fácil de expressar quando os tópicos incluem o ID do dispositivo.

Escalabilidade

Serviços HTTP escalam horizontalmente atrás de um load balancer porque cada requisição é independente. Brokers MQTT guardam estado de cada cliente conectado — assinaturas, sessões, mensagens em trânsito —, então escalar para grandes frotas significa clusterizar o broker ou usar um provedor que faça isso. Do lado dos consumidores, as assinaturas compartilhadas do MQTT 5 distribuem as mensagens entre vários workers de backend. Nenhuma das abordagens é mais difícil no geral; elas apenas colocam a complexidade em lugares diferentes.

A mesma leitura, de duas formas

curl -X POST https://api.example.com/devices/sensor-17/readings \
  -H 'Content-Type: application/json' \
  -d '{"temp":21.4}'

mosquitto_pub -h broker.emqx.io -t 'testmqtt/sensor-17/temp' -q 1 -m '{"temp":21.4}'

Com HTTP, é a API que decide quem recebe a leitura em seguida. Com MQTT, um dashboard, um gravador em banco de dados e um serviço de alertas podem todos assinar testmqtt/+/temp sem que o dispositivo saiba que eles existem.

Assinar leituras ao vivo no navegador

Quando usar MQTT

• Telemetria frequente de muitos dispositivos.
• Envio de comandos a dispositivos atrás de NAT ou firewalls — eles se conectam para fora, e o broker envia para dentro.
• Dashboards e alertas em tempo real que precisam de push, não de polling.
• Hardware limitado, links tarifados ou dispositivos a bateria.
• Um mesmo evento consumido por vários serviços independentes.

Quando usar HTTP

• Consultar e gerenciar recursos (registro de dispositivos, configurações, contas de usuário) com uma API REST.
• Transferências de arquivos grandes, como imagens de firmware, logs ou snapshots de câmeras.
• Envios esporádicos e pontuais, em que não vale a pena manter uma conexão aberta.
• APIs públicas para terceiros que esperam ferramentas web, cache e autenticação padrão.

E os navegadores?

Os navegadores não conseguem abrir conexões MQTT puras, mas o MQTT funciona bem sobre WebSockets, que começam como uma requisição HTTP de upgrade. Isso dá aos dashboards web push ao vivo usando os mesmos tópicos dos seus dispositivos. Veja MQTT sobre WebSockets para portas e configuração.

Veredito

Escolha MQTT para comunicação orientada a eventos, bidirecional e com muitos dispositivos; escolha HTTP para APIs orientadas a recursos e transferências em massa. Se estiver em dúvida, prototipe o lado MQTT em poucos minutos com o cliente MQTT online e um broker público de teste antes de se comprometer.

Perguntas frequentes