Una delle prime decisioni tecniche in un progetto IoT è scegliere il protocollo di comunicazione. MQTT e HTTP sono i due candidati principali, ma hanno filosofie completamente diverse. Scegliere male può significare batterie che si scaricano in settimane invece che in anni, dati che si perdono senza che nessuno se ne accorga o architetture che non scalano.
Questa guida ti aiuta a prendere la decisione corretta basandoti su criteri tecnici oggettivi e sull’esperienza reale di implementazione di entrambi i protocolli in produzione.
MQTT: progettato per IoT
MQTT (Message Queuing Telemetry Transport) è stato creato nel 1999 da IBM per monitorare oleodotti via satellite. Il contesto originale dice tutto: larghezza di banda limitata, alta latenza, connessioni instabili e dispositivi con risorse molto limitate.
Caratteristiche chiave di MQTT
Modello Pub/Sub: I dispositivi pubblicano messaggi su topic. I consumatori si iscrivono ai topic che li interessano. Non c’è connessione diretta tra produttore e consumatore: il broker gestisce tutta la distribuzione.
Overhead minimo: L’header fisso di MQTT occupa solo 2 byte. Un messaggio tipico con topic e payload occupa 10-50 byte. Confronta con i 300-800 byte di una richiesta HTTP equivalente.
Tre livelli di QoS:
- QoS 0: Fire and forget (massima efficienza, nessuna garanzia)
- QoS 1: At least once (garanzia di consegna, possibili duplicati)
- QoS 2: Exactly once (massima affidabilità, maggiore overhead)
Sessioni persistenti: Il broker memorizza i messaggi per dispositivi disconnessi e li consegna quando si riconnettono.
Last Will and Testament (LWT): Il broker pubblica un messaggio predefinito se rileva che un dispositivo si è disconnesso inaspettatamente. Perfetto per il rilevamento dei guasti.
Keep-alive efficiente: Ping periodici di pochi byte per mantenere attiva la connessione attraverso NAT e firewall.
Quando usare MQTT
- Dispositivi alimentati a batteria (ogni byte conta)
- Connettività mobile/LoRaWAN/NB-IoT con latenza variabile
- Dati che devono arrivare in tempo reale (monitoraggio, alert)
- Comunicazione bidirezionale (inviare comandi al dispositivo)
- Migliaia di dispositivi che pubblicano dati sullo stesso broker
- Dispositivi che si connettono e disconnettono frequentemente
HTTP: il protocollo universale
HTTP è il protocollo del web. Tutti gli sviluppatori lo conoscono, tutti gli strumenti lo supportano, tutti i firewall lo lasciano passare. Ma non è stato progettato per IoT.
Caratteristiche chiave di HTTP per IoT
Modello Request/Response: Il client inizia sempre la comunicazione. Il server non può inviare dati al dispositivo in modo proattivo (senza WebSocket o SSE).
Overhead significativo: Gli header HTTP tipici occupano 300-800 byte. Per un sensore che invia 10 byte di dati, questo è il 98% di overhead.
Senza stato: Ogni request è indipendente. Non c’è concetto di sessione persistente né di messaggi in sospeso. Se il server vuole inviare qualcosa al dispositivo, deve aspettare che il dispositivo faccia polling.
Ecosistema maturo: API REST ben documentate, autenticazione OAuth2, strumenti di debugging, SDK in tutti i linguaggi, integrazione banale con qualsiasi sistema.
TLS standard: HTTPS funziona ovunque. Certificati Let’s Encrypt gratuiti. Non richiede configurazione speciale.
Quando usare HTTP
- Dispositivi con alimentazione costante e WiFi/Ethernet
- Invio di dati poco frequente (una volta al giorno, ogni ora)
- Payload grandi (immagini, log, file di configurazione)
- Integrazione con API REST esistenti
- Aggiornamenti firmware OTA
- Gateway e dispositivi edge con risorse abbondanti
Confronto tecnico dettagliato
Overhead di rete
| Metrica | MQTT | HTTP |
|---|---|---|
| Header minimo | 2 byte | ~300 byte |
| Connessione | Una volta (persistente) | Ad ogni request (o keep-alive) |
| Handshake TLS | Una volta | Ad ogni connessione (senza keep-alive) |
| Messaggio tipico (10 byte payload) | ~20 byte totali | ~350 byte totali |
| Rapporto payload/overhead | 50% | 3% |
Per un sensore che invia una lettura ogni 5 minuti per un mese:
- MQTT: ~20 byte * 8.640 messaggi = 173 KB
- HTTP: ~350 byte * 8.640 request = 3 MB
Questo è 17x più dati con HTTP. In reti con costo per MB (NB-IoT, LTE-M), la differenza si riflette sulla bolletta.
Consumo batteria
Il consumo radio è il principale fattore di scaricamento delle batterie nei dispositivi IoT. Meno byte = meno tempo di radio attiva = maggiore durata della batteria.
| Scenario | MQTT QoS 0 | HTTP POST |
|---|---|---|
| Invio ogni 5 min | ~3 anni batteria | ~6 mesi batteria |
| Invio ogni ora | ~5 anni batteria | ~2 anni batteria |
| Invio 1x giorno | ~7 anni batteria | ~5 anni batteria |
Questi sono valori approssimativi per un dispositivo tipico con batteria da 3.600 mAh e radio LoRaWAN/NB-IoT.
Latenza
| Scenario | MQTT | HTTP |
|---|---|---|
| Dispositivo al broker/server | 10-50 ms | 100-500 ms |
| Broker al subscriber | <10 ms | N/A (polling) |
| Comando al dispositivo | <100 ms | Aspettare il prossimo poll |
| Notifica disconnessione | Immediata (LWT) | Solo per timeout |
MQTT vince chiaramente negli scenari bidirezionali. Se hai bisogno di inviare un comando a un dispositivo e ricevere conferma in meno di un secondo, HTTP con polling non è praticabile.
Affidabilità
| Caratteristica | MQTT | HTTP |
|---|---|---|
| Consegna garantita | QoS 1/2 | Retry manuale |
| Messaggi in sospeso | Sessione persistente | Non nativo |
| Rilevamento disconnessione | LWT (secondi) | Timeout (minuti) |
| Duplicati | QoS 2 li elimina | Idempotenza manuale |
| Ordine dei messaggi | Garantito da QoS | Non garantito |
Scalabilità
| Metrica | MQTT (AWS IoT Core) | HTTP (API Gateway) |
|---|---|---|
| Connessioni simultanee | Milioni | N/A (stateless) |
| Messaggi/secondo | Milioni | Migliaia-Milioni (con auto-scaling) |
| Fan-out (1 messaggio a N subscriber) | Nativo | Richiede implementazione |
| Costo per messaggio | $1 per milione | ~$3.50 per milione (API Gateway) |
Architettura ibrida: il meglio di entrambi i mondi
In pratica, la maggior parte dei progetti IoT industriali usa entrambi i protocolli:
Dispositivi → MQTT → Broker → Elaborazione
↓
API REST (HTTP)
↓
Dashboard / App / Integrazioni- MQTT per la comunicazione dispositivo-cloud: efficiente, bidirezionale, tollerante alle disconnessioni
- HTTP/REST per l’API del backend: dashboard, app mobili, integrazioni con sistemi di terze parti
Questa è esattamente l’architettura che abbiamo implementato in Spherag: i dispositivi pubblicano via MQTT su AWS IoT Core, l’elaborazione avviene in Lambda/Kinesis, e i dati sono esposti via API REST + WebSocket per il dashboard.
Casi dove MQTT è chiaramente migliore
1. Telemetria ad alta frequenza
Un sensore industriale che invia vibrazione a 100 Hz (100 messaggi/secondo). Con HTTP, ogni messaggio richiederebbe un round-trip completo. Con MQTT, i messaggi fluiscono attraverso la connessione persistente con overhead minimo.
2. Reti di sensori a batteria
Dispositivi LoRaWAN o NB-IoT che devono funzionare anni con una batteria. Ogni byte extra riduce la durata. MQTT con QoS 0 minimizza il consumo.
3. Comandi remoti ai dispositivi
Hai bisogno di aprire una valvola, cambiare la configurazione di un sensore o aggiornare un parametro. Con MQTT, il dispositivo è iscritto a un topic di comandi e riceve l’istruzione immediatamente. Con HTTP, dovresti aspettare che il dispositivo faccia polling.
4. Rilevamento delle disconnessioni
Nel monitoraggio di infrastrutture critiche, hai bisogno di sapere in secondi se un dispositivo si è disconnesso. Il LWT di MQTT lo fa automaticamente. Con HTTP, te ne accorgeresti solo quando il successivo poll non arriva (il che può avvenire minuti o ore dopo).
Casi dove HTTP è meglio o equivalente
1. Dispositivi con connettività WiFi stabile
Un gateway con WiFi/Ethernet e alimentazione costante può usare HTTP senza penalizzazioni significative. Se invia dati solo ogni minuto, l’overhead extra è irrilevante.
2. Invio di file grandi
Aggiornamenti firmware, log compressi, immagini da telecamere. HTTP con chunked transfer o multipart è più adatto di MQTT per payload da KB o MB.
3. Integrazione con sistemi legacy
Se il tuo sistema di destinazione accetta solo HTTP/REST, un gateway che traduce MQTT in HTTP è la soluzione più pragmatica.
4. Prototipazione rapida
Per un MVP rapido con pochi dispositivi, HTTP può essere più semplice da implementare se il team ha già esperienza con le API REST.
MQTT su WebSocket: il bridge perfetto
Un caso speciale: MQTT su WebSocket consente ai browser web di iscriversi direttamente ai topic MQTT. Questo è ideale per dashboard in tempo reale che devono ricevere dati dal broker senza un backend intermedio.
Dispositivo → MQTT → Broker
↓
Browser → MQTT over WebSocket → BrokerAWS IoT Core supporta MQTT su WebSocket nativamente, il che consente a un dashboard React di iscriversi agli stessi topic del backend senza codice aggiuntivo nel server.
Raccomandazioni pratiche
- Se hai dispositivi a batteria: MQTT, senza discussioni
- Se hai bisogno di bidirezionalità: MQTT
- Se invii dati ogni pochi secondi: MQTT
- Se invii dati 1x al giorno con WiFi: HTTP va bene
- Se sono file grandi: HTTP per i file, MQTT per la segnalazione
- Se non sai cosa scegliere: MQTT. È più versatile e non dovrai migrare quando i requisiti crescono
Implementazione con Soamee
In Soamee implementiamo architetture MQTT e AWS IoT per progetti di IoT industriale. Se hai bisogno di aiuto per scegliere e progettare l’architettura di comunicazione del tuo progetto IoT, prenota una consulenza gratuita.