Uma das primeiras decisões técnicas num projeto IoT é escolher o protocolo de comunicação. MQTT e HTTP são os dois candidatos principais, mas têm filosofias completamente diferentes. Escolher mal pode significar baterias que se esgotam em semanas em vez de anos, dados que se perdem sem que ninguém saiba ou arquiteturas que não escalam.
MQTT: desenhado para IoT
MQTT foi criado em 1999 pela IBM para monitorizar oleodutos via satélite. Modelo Pub/Sub, overhead mínimo (2 bytes de header), três níveis de QoS, sessões persistentes e Last Will and Testament.
HTTP: o protocolo universal
Modelo Request/Response, overhead significativo (300-800 bytes), sem estado, mas ecossistema maduro e TLS padrão.
Comparação técnica
| Métrica | MQTT | HTTP |
|---|---|---|
| Header mínimo | 2 bytes | ~300 bytes |
| Conexão | Uma vez (persistente) | Cada request |
| Ratio payload/overhead | 50% | 3% |
Consumo de bateria
| Cenário | MQTT QoS 0 | HTTP POST |
|---|---|---|
| Envio cada 5 min | ~3 anos bateria | ~6 meses bateria |
| Envio cada hora | ~5 anos bateria | ~2 anos bateria |
Recomendações práticas
- Se tem dispositivos com bateria: MQTT, sem discussão
- Se precisa de bidirecionalidade: MQTT
- Se envia dados a cada poucos segundos: MQTT
- Se só envia dados 1x por dia com WiFi: HTTP está bem
- Se são ficheiros grandes: HTTP para os ficheiros, MQTT para a sinalização
- Se não sabe o que escolher: MQTT. É mais versátil.
Conclusão
A maioria dos projetos IoT industriais usa ambos os protocolos: MQTT para dispositivo-cloud e HTTP/REST para a API do backend. Se precisa de ajuda para desenhar a arquitetura, agende uma consultoria gratuita.