Che cos'è MQTT: il protocollo, le sue versioni e dove si usa

# In breve

MQTT (Message Queuing Telemetry Transport) è un protocollo di messaggistica leggero, basato su pubblicazione e sottoscrizione, creato per dispositivi con collegamento scadente, poca memoria e una batteria che deve durare.

Fu creato nel 1999 da Andy Stanford-Clark di IBM e Arlen Nipper di Arcom, per portare via satellite la telemetria degli oleodotti. Le condizioni erano spietate: la banda costava cara e scarseggiava, il collegamento cadeva di continuo e i dispositivi erano gracili. Quei vincoli hanno plasmato tutto il protocollo: un'intestazione minuscola, un'unica connessione di lunga durata e la capacità di sopravvivere a una caduta senza perdere messaggi.

Oggi MQTT è uno standard OASIS, e la versione 3.1.1 è stata inoltre adottata come norma internazionale ISO/IEC 20922. Ha superato da tempo l'industria petrolifera: case intelligenti, contatori, macchine utensili, automobili e apparecchi medicali ci girano sopra.

Il costo aggiuntivo minimo per messaggio è di due byte. Una singola richiesta HTTP, per confronto, spende centinaia di byte in intestazioni prima di qualsiasi contenuto. Quando un dispositivo riporta una temperatura ogni secondo tramite un modem cellulare in mezzo alla campagna, quella differenza decide il progetto.

# Come funziona: pubblicare, sottoscrivere e il broker

In HTTP il client chiede e il server risponde. In MQTT nessuno chiede nulla a nessuno: un dispositivo pubblica un messaggio in un topic, e tutti coloro che hanno sottoscritto quel topic lo ricevono. Il mittente non sa chi legge, né se qualcuno legge; il destinatario non sa chi ha inviato. L'unica cosa che li lega è il nome del topic.

Al centro c'è sempre un broker — un server che tiene le connessioni, custodisce l'albero delle sottoscrizioni e distribuisce i messaggi. Senza di lui il modello non funziona: è il broker a trasformare «inviato nel vuoto» in «consegnato a tutti quelli a cui serve».

Che cosa fa il broker

• Accetta e mantiene le connessioni: migliaia insieme, per anni senza interruzione.
• Verifica chi si collega: nome utente e password, un certificato o un token.
• Decide che cosa può fare ogni client: i permessi di pubblicare e sottoscrivere si concedono per topic.
• Confronta ogni messaggio pubblicato con l'albero delle sottoscrizioni e ne distribuisce le copie.
• Conserva lo stato: ultimi valori noti (retain), code per i client assenti e conferme rimaste in sospeso.
• Tiene d'occhio chi è vivo e pubblica il testamento di chi sparisce.

Disaccoppiare mittente e destinatario non è un dettaglio tecnico, ma il senso stesso del modello. Puoi sostituire un sensore, aggiungere un secondo consumatore o agganciare un'analisi di lato senza riscrivere nulla: tutti parlano con un topic, non tra loro.

# Topic e caratteri jolly

Un topic è una stringa di livelli separati da barre. Nulla va registrato in anticipo: pubblicare in un topic nuovo lo crea sul momento.

ufficio/piano2/stanza14/temperatura
ufficio/piano2/stanza14/umidita
ufficio/piano2/stanza15/temperatura

Una sottoscrizione può abbracciare interi rami grazie a due caratteri jolly:

Il jolly # vale solo come ultimo livello: ufficio/#/temperatura non è un filtro valido. I topic distinguono maiuscole e minuscole, e ufficio/piano2 e ufficio/piano2/ sono due topic diversi.

# Qualità del servizio: QoS 0, 1 e 2

MQTT lascia scegliere quanta fatica spendere per consegnare ogni messaggio. Il livello si imposta separatamente in pubblicazione e in sottoscrizione; vale il minore dei due.

Il costo sale con la garanzia: QoS 2 sono quattro pacchetti invece di uno, più stato a entrambe le estremità. Resisti alla tentazione di «usare 2 dappertutto per sicurezza»: diecimila sensori che pubblicano ogni secondo in QoS 2 caricano un broker di un ordine di grandezza in più, senza alcun vantaggio.

# Retain, Last Will, sessioni e keep-alive

Retain — l'ultimo valore noto

Un messaggio ordinario raggiunge solo chi è iscritto in quel momento. Un messaggio con il flag retain viene inoltre ricordato dal broker e consegnato a ogni nuovo iscritto nell'istante in cui si iscrive. È la risposta standard all'eterno problema del pannello che si apre vuoto e tale resta finché un sensore non si degna di inviare la lettura successiva.

Un topic conserva esattamente un messaggio ritenuto: l'ultimo. Per cancellarlo, pubblica un payload vuoto nello stesso topic con il flag retain.

Last Will — un messaggio per quando cade la linea

Nel collegarsi, un client può consegnare al broker un testamento: un topic, un payload e le sue opzioni. Se la connessione muore in malo modo — senza pacchetto DISCONNECT —, il broker pubblica quel messaggio al posto suo. Lo schema classico è un topic ritenuto device/42/status che riceve online alla connessione e porta offline come testamento. Il sistema sa sempre chi è presente, senza alcun sondaggio.

Sessioni: pulite e persistenti

Una sessione pulita dura esattamente quanto la connessione: alla disconnessione le sottoscrizioni sono dimenticate. Una persistente sopravvive alla caduta: il broker ricorda le sottoscrizioni e accoda i messaggi QoS 1 e 2 mentre il client è assente, per consegnargli l'arretrato al ritorno. Per un dispositivo che si sveglia una volta all'ora, è l'unico modo di non perdere nulla.

Keep-alive — accorgersi che la linea è morta

Una connessione TCP interrotta può sembrare perfettamente viva a entrambe le estremità per parecchio tempo. Perciò il client dichiara un intervallo di keep-alive e, non avendo altro da dire, invia un ping. Non sentendo nulla per un intervallo e mezzo, il broker dà il client per scomparso, chiude la connessione e pubblica il suo testamento.

# Le versioni: 3.1, 3.1.1 e 5.0

Nella pratica se ne incontrano tre, e le differenze non sono cosmetiche.

A parte sta MQTT-SN, un protocollo fratello per reti senza TCP: ZigBee, collegamenti radio, UDP. Non è «una versione di MQTT» ma una specifica a sé; a quelle reti si dà un gateway che traduce il traffico in MQTT ordinario.

Che cosa porta davvero MQTT 5.0

La versione 5 è nata da fastidi accumulati sul campo. Le cose che pesano di più:

• Codici di motivo. In 3.1.1 un rifiuto sembrava un socket chiuso in silenzio, e restava da indovinare. In 5.0 il server dice di che si tratta: password errata, nessun permesso su quel topic, pacchetto troppo grande.
• Proprietà dei pacchetti. Un messaggio può portare metadati: Content Type, Correlation Data, coppie chiave-valore a piacere. Prima tutto questo veniva infilato nel payload o nel nome del topic.
• Richiesta e risposta. I campi Response Topic e Correlation Data rendono il normale RPC uno schema di prima classe invece di una convenzione arrangiata.
• Sottoscrizioni condivise tramite $share/gruppo/filtro: più istanze di un consumatore si dividono il flusso. È bilanciamento del carico e tolleranza ai guasti a livello di protocollo.
• Durate di sessioni e messaggi. Session Expiry e Message Expiry permettono di dire «tienilo un giorno, poi dimenticalo» invece della scelta secca tra pulita e non pulita.
• Controllo di flusso. Receive Maximum limita quanti messaggi non confermati viaggiano insieme, e Maximum Packet Size protegge un dispositivo piccolo da un pacchetto che non riesce a digerire.
• Alias dei topic. Un nome lungo viene inviato una volta e poi sostituito da un numero di due byte: un risparmio vero sulle gerarchie profonde.
• Identificatori di sottoscrizione, No Local, Retain As Published, Retain Handling. Piccolezze che eliminano vecchie trappole: sentire l'eco dei propri messaggi, una valanga di ritenuti a ogni riconnessione, non sapere da quale sottoscrizione sia arrivato un messaggio.
• Testamento differito. Il Will Delay Interval evita che un'oscillazione momentanea faccia scattare un allarme: il testamento viene pubblicato solo se il client non torna in tempo.

La conclusione pratica: comincia i progetti nuovi in 5.0. Sottoscrizioni condivise e codici di errore comprensibili risparmiano settimane di debug, e la compatibilità con i dispositivi vecchi non si perde.

# MQTT contro HTTP e le alternative

«Perché MQTT se esiste REST?» è una domanda legittima. La differenza non è di moda, ma di direzione e di costo di una conversazione.

L'interrogazione periodica lo rende evidente. Per sapere di un evento entro un secondo via HTTP, mille dispositivi devono chiedere mille volte al secondo, e quasi ogni risposta sarà «niente di nuovo». In MQTT l'evento arriva da solo nell'istante in cui accade, e nel frattempo non costa traffico.

E CoAP, AMQP e WebSocket

• CoAP è REST su UDP per nodi molto piccoli. Più leggero di MQTT, ma non offre né code né consegna affidabile senza fatica.
• AMQP è più pesante e più ricco: instradamento elaborato, transazioni, code di livello aziendale. Sensato tra server, eccessivo per un sensore.
• WebSocket è un trasporto, non un'alternativa: MQTT stesso viaggia su WebSocket per funzionare dentro un browser.
• Sparkplug B non è un rivale ma uno strato sopra MQTT: detta come nominare i topic e codificare i payload nei sistemi industriali, perché software SCADA di fornitori diversi capiscano gli stessi dati.

# Trasporto, porte e payload

MQTT viaggia su TCP e chiede soltanto una consegna affidabile e ordinata. Le porte consuete:

Per il protocollo un payload è solo una sequenza di byte. MQTT non sa nulla del contenuto e non impone nulla: JSON, CBOR, protobuf, un semplice numero o un'immagine vanno bene allo stesso modo. Il limite formale è di 256 MB, ma in pratica tutto ciò che supera qualche centinaio di kilobyte spetta a HTTP, mentre su MQTT viaggia soltanto un collegamento.

Nella pratica domina JSON: una persona lo legge, ogni linguaggio lo analizza ed è abbastanza compatto. Su un collegamento stretto un formato binario si guadagna il posto — ed è esattamente lì che aiuta la proprietà Content Type di MQTT 5.0, dichiarando con onestà che cosa c'è dentro.

# Sicurezza

MQTT non cifra nulla da solo: sulla porta 1883 nome utente e password viaggiano in chiaro. La sicurezza nasce da tre strati indipendenti, e nessuno di essi è facoltativo.

Cifrare il canale

TLS sulla porta 8883. Per i dispositivi troppo deboli per TLS, l'unica scelta decorosa è tenerli su una rete isolata e non lasciar uscire nulla se non attraverso un gateway.

Autenticazione

Il classico è nome utente e password nel pacchetto CONNECT. Più rigoroso: i certificati client, con il dispositivo che presenta il proprio e il broker che ne verifica la firma. Più flessibile: JWT, con il dispositivo che porta un token firmato e a tempo, e la revoca che non richiede modifiche sul broker. I broker migliori sanno anche leggere gli account da un database esterno, da un file CSV o da un servizio HTTP, così l'elenco dei dispositivi non deve esistere in doppia copia.

Permessi sui topic

L'autenticazione risponde a «chi sei»; l'autorizzazione a «che cosa puoi fare». Le liste di controllo degli accessi dicono quali topic un client può leggere e quali può scrivere. L'impostazione giusta è negare tutto tranne ciò che è esplicitamente consentito.

A questo si aggiungono limiti di cadenza in pubblicazione (perché un solo dispositivo impazzito non seppellisca il broker), una dimensione massima dei pacchetti e la solita igiene di rete: il pannello del broker non ha nulla da fare affacciato su internet.

# Dove si usa davvero MQTT

Casa intelligente e automazione degli edifici

Il campo più vasto per numeri. Home Assistant, Zigbee2MQTT, ESPHome e openHAB dialogano tutti attraverso un broker MQTT, che fa anche da collante tra apparecchi di produttori diversi: una presa, un sensore di perdite e un termoregolatore di tre marche collaborano alla perfezione, perché ciascuno si limita a scrivere nel proprio topic.

Industria e SCADA

Letture di macchina, stato della linea, contatori delle ore. La disposizione classica è un gateway che legge Modbus od OPC UA dagli impianti e ripubblica via MQTT, dopo di che SCADA, uno storico e un sistema di manutenzione predittiva consumano tutto insieme senza darsi fastidio. È qui che Sparkplug B e le sottoscrizioni condivise di MQTT 5.0 si guadagnano il posto.

Contatori e servizi pubblici

Contatori d'acqua, gas, elettricità e calore: dispositivi a batteria che si svegliano una volta all'ora, comunicano una lettura e tornano a dormire. Qui sessioni persistenti e retain fanno il grosso del lavoro: il server vede sempre l'ultimo valore anche se un contatore si farà vivo solo di sera.

Trasporti e telematica

Coordinate, consumo di carburante, stato del vano refrigerato, comportamento del conducente. Il collegamento è una rete cellulare che sparisce nei tunnel e fuori città. Code e riconsegna dopo la riconnessione trasformano una connessione a brandelli in un flusso continuo di dati.

Energia, agricoltura, sanità

Impianti solari e cabine elettriche, sistemi di irrigazione e stazioni meteo, monitor per pazienti e frigoriferi per vaccini. Ciò che hanno in comune: molti punti, un collegamento debole, eventi che non si possono perdere e la necessità di sapere subito di un guasto.

Città intelligenti e logistica

Illuminazione pubblica, parcheggi, cassonetti che segnalano quanto sono pieni, tracciamento delle merci e temperatura della catena del freddo. Decine di migliaia di dispositivi che inviano messaggi brevi e radi: esattamente il profilo di carico per cui MQTT è stato progettato.

# Progettare i topic: decisioni che conviene prendere presto

Lo schema dei topic è l'API del tuo sistema. Cambiarlo dopo fa male, perché firmware e server vanno aggiornati insieme. Qualche regola che fa risparmiare tempo.

• Dal generale al particolare. stabilimento/capannone3/linea2/macchina7/temperatura permette di sottoscrivere a qualsiasi livello. L'ordine inverso rende inutili i caratteri jolly.
• Dai all'identificatore del dispositivo un livello suo. È questo che consente a una sola regola ACL di confinare un dispositivo al proprio ramo.
• Nessuna barra iniziale. /ufficio/temp crea un primo livello vuoto: lecito, ma fonte duratura di confusione.
• Solo lettere latine, cifre, trattino e trattino basso. Gli spazi e i caratteri +, # e $ nei nomi provocano guasti che nessuno si aspetta.
• Non codificare mai dati variabili nel topic. sensor/42/temp/21.5 è un errore: il valore va nel payload, altrimenti il broker si ritrova con un albero di topic senza limiti e retain diventa inutile.
• Separa lo stato dai comandi. Per esempio device/42/state per ciò che il dispositivo comunica e device/42/cmd per ciò che gli si ordina. Altrimenti l'eco dei propri comandi finirà per mandare in circolo la logica.
• Retain per lo stato, non per la telemetria. Retain serve per l'«ultimo stato noto» e non ha senso per un flusso di letture.

# Scegliere un broker

I broker sono molti, e la scelta di solito si riduce a una manciata di domande.

• MQTT 5.0 è supportato per intero? Il supporto parziale è frequente, e lo si scopre quasi sempre nel momento peggiore.
• Si vede che cosa succede? Poter osservare chi è connesso, quali topic sono vivi e che cosa passa in questo momento fa risparmiare ore di debug. Un broker senza pannello trasforma ogni problema in archeologia dei log.
• Come si creano i dispositivi? Con migliaia di essi, farlo a mano è escluso: serve un'API o account in un database esterno.
• Sopravvive a un riavvio? Messaggi ritenuti, sessioni persistenti e code devono arrivare al disco, altrimenti un riavvio pianificato significa perdere dati.
• Quali limiti offre? Un dispositivo impazzito non deve mettere in ginocchio il sistema: i limiti di cadenza e di volume contano.
• Quanto costa e dove gira? Un servizio in cloud è comodo finché non comincia a farsi pagare a messaggio; un server proprio va amministrato, ma i dati restano tuoi.

Per un'installazione piccola o media — da una casa intelligente a uno stabilimento con qualche migliaio di punti — di norma basta un solo broker su una macchina modesta. Il clustering serve molto meno spesso di quanto sembri in fase di progetto; più spesso conviene collegare due broker indipendenti con un bridge che inoltri solo i topic che contano.

# Partire in cinque minuti

Il modo più rapido per capire tutto questo è avviare un broker e guardare i messaggi di persona. Su Debian o Ubuntu sono tre comandi:

sudo wget -qO /usr/share/keyrings/elx-repo.gpg https://repo.um-d.ru/elx-repo.gpg
echo "deb [signed-by=/usr/share/keyrings/elx-repo.gpg] https://repo.um-d.ru stable main" | sudo tee /etc/apt/sources.list.d/elx-repo.list
sudo apt-get update && sudo apt-get install elxmqttbroker

Il pannello si apre su http://tuo-server:8567. Crea un utente e prova lo scambio con un client qualsiasi — gli strumenti da console di mosquitto, per esempio:

# in una finestra — sottoscrivere tutto ciò che il dispositivo invia
mosquitto_sub -h localhost -u sensor-42 -P password -t 'sensor-42/#' -v

# in un'altra — pubblicare una lettura
mosquitto_pub -h localhost -u sensor-42 -P password -t 'sensor-42/temp' -m '21.5'

# lo stesso, ma ricordato per i futuri iscritti
mosquitto_pub -h localhost -u sensor-42 -P password -t 'sensor-42/temp' -m '21.5' -r

Poi gioca con il flag retain, scollega un iscritto e guarda che cosa si accumula in una sessione persistente, imposta un testamento e stacca il cavo. Mezz'ora così insegna più di qualsiasi articolo, questo compreso.

# Risposte rapide