Che cos'è MQTT?

MQTT è il protocollo applicativo che la maggior parte dei dispositivi IoT usa per inviare dati a un back end e riceverne comandi. Fu progettato nel 1999 da ingegneri di IBM e Arcom per monitorare oleodotti tramite collegamenti satellitari, quindi doveva essere piccolo, tollerare collegamenti che cadono senza preavviso e usare meno byte possibile. Questi vincoli descrivono la maggior parte delle installazioni IoT, e dopo essere diventato uno standard aperto è diventato la lingua comune tra dispositivi e piattaforme IoT.

Il protocollo è semplice da imparare, ma usarlo bene comporta decisioni sulla struttura dei topic, sulle garanzie di consegna e sulla gestione delle sessioni che è facile sbagliare. Questa guida copre prima i meccanismi e poi le scelte pratiche.

Come funziona MQTT?

MQTT è un protocollo publish-subscribe. I client non parlano tra loro: si connettono tutti a un broker. Un client pubblica un messaggio su un topic identificato da un nome, e il broker lo consegna a ogni client che ha sottoscritto quel topic. Il publisher non sa chi sta ascoltando, e non gli interessa.

Questo disaccoppiamento è il punto. Un sensore pubblica le letture di temperatura su un topic; una dashboard, un servizio di allarme e un servizio di scrittura su database possono sottoscriverlo tutti senza che il firmware del sensore cambi.

Una connessione è una sessione TCP di lunga durata, normalmente incapsulata in TLS, sulla porta 1883 per MQTT in chiaro e 8883 per TLS, le due porte registrate presso IANA per il protocollo. MQTT può anche funzionare su WebSocket, così che le applicazioni browser possano sottoscrivere direttamente. Per i dispositivi che non possono permettersi TCP, MQTT-SN è una variante per UDP e per le reti non IP che un gateway raccorda a un broker normale.

Cosa sono i topic MQTT?

Un topic è una stringa UTF-8 organizzata in livelli separati da barre, come:

factory/line-3/press-7/temperature

I subscriber possono usare le wildcard. La wildcard a livello singolo + corrisponde a un solo livello (factory/line-3/+/temperature corrisponde a ogni macchina della linea 3), e la wildcard multilivello # corrisponde a tutto ciò che sta sotto (factory/line-3/#). I topic non si dichiarano in anticipo: esistono nel momento in cui qualcuno pubblica o sottoscrive.

La progettazione dei topic è la decisione con più conseguenze in un sistema MQTT. Una gerarchia che va dal generale allo specifico rende utili le sottoscrizioni con wildcard e gestibile il controllo degli accessi. Le convenzioni comuni separano la telemetria dai comandi e includono l’identità del dispositivo nel topic, così che il broker possa imporre che ogni dispositivo pubblichi solo nel proprio ramo. Sparkplug è una specifica che standardizza la struttura dei topic e il formato del payload per l’uso industriale.

Quali sono i livelli di QoS?

Ogni pubblicazione porta con sé un livello di Quality of Service che definisce la garanzia di consegna tra il client e il broker.

QoS 0, al massimo una volta. Il messaggio viene inviato una volta, senza conferma. Se la connessione cade nel momento sbagliato va perso. È il più economico, e va bene per letture frequenti dove comunque la prossima arriverà presto.

QoS 1, almeno una volta. Il mittente conserva il messaggio finché il broker non lo conferma, e lo reinvia se la conferma non arriva. Il messaggio può quindi arrivare più di una volta, e i consumatori devono tollerare i duplicati. È l’impostazione predefinita più comune per telemetria e comandi.

QoS 2, esattamente una volta. Un handshake in quattro passi garantisce la consegna singola. Costa più round trip e più stato da mantenere, ed è riservato a cose come gli eventi di fatturazione, dove un duplicato è grave quanto una perdita.

Il livello si applica a ogni tratta: il broker consegna a ciascun subscriber al più basso tra il livello del publisher e quello del subscriber.

Come funzionano sessioni, keep-alive e Last Will?

Quando un client si connette, dice al broker se conservare lo stato della sessione. Una sessione persistente memorizza le sottoscrizioni del client e i messaggi QoS 1 o 2 che arrivano mentre è offline, e li consegna alla riconnessione. È così che un dispositivo che dorme per un’ora riceve i comandi inviati mentre era assente. Il costo è la memoria del broker, quindi le piattaforme limitano quanto accodano e per quanto tempo.

I client inviano un keep-alive periodico perché il broker possa rilevare una connessione morta. Se un client sparisce senza una disconnessione regolare, il broker pubblica il suo messaggio Last Will and Testament, registrato al momento della connessione, in genere su un topic di stato.

Un messaggio retained è l’ultimo messaggio di un topic che il broker conserva e consegna immediatamente a ogni nuovo subscriber. Pubblicare lo stato dei dispositivi come retained significa che una dashboard appena avviata vede subito lo stato corrente di tutti i dispositivi.

Cosa ha aggiunto MQTT 5?

MQTT 3.1.1, standardizzato da OASIS nell’ottobre 2014, è ancora la versione più diffusa. MQTT 5, pubblicato come OASIS Standard nel marzo 2019, ha colmato le lacune emerse nelle grandi installazioni:

• Codici di motivazione (reason code) sulle conferme, così un client sa perché una pubblicazione o una sottoscrizione è stata rifiutata invece di essere disconnesso in silenzio.
• Proprietà utente, metadati chiave-valore arbitrari sui messaggi, utili per il tipo di contenuto, gli identificatori di tracciamento o i suggerimenti di instradamento.
• Scadenza dei messaggi, così che un comando ormai vecchio venga scartato invece di essere consegnato a un dispositivo che si riconnette un giorno dopo.
• Sottoscrizioni condivise, in cui un gruppo di consumatori si divide i messaggi di un topic per bilanciare il carico.
• Alias dei topic e un intervallo esplicito di scadenza della sessione, che sostituisce il flag clean session.

La maggior parte dei broker e delle piattaforme supporta entrambe le versioni. I nuovi progetti dovrebbero usare la 5, salvo nei casi in cui la libreria del dispositivo supporta solo la 3.1.1.

Come si mette in sicurezza MQTT?

MQTT ha campi di autenticazione propri: il pacchetto CONNECT ha un campo nome utente e un campo password sia nella 3.1.1 sia nella 5.0, e MQTT 5 aggiunge l’autenticazione avanzata tramite il pacchetto AUTH, che permette a client e broker di negoziare meccanismi challenge-response nello stile di SASL. Ciò per cui MQTT non prevede nulla è la cifratura: la riservatezza è delegata a TLS, per convenzione sulla porta 8883, e una password inviata senza TLS viaggia in chiaro. In pratica le installazioni più comuni usano TLS mutuo con il dispositivo che presenta un certificato X.509, oppure uno schema basato su token trasportato su TLS dove i certificati non sono praticabili. L’autorizzazione è applicata dal broker tramite liste di controllo degli accessi che legano ogni identità client ai topic che può usare. Un broker che lascia qualsiasi dispositivo sottoscrivere # ha reso ogni dispositivo un ascoltatore di tutti gli altri. La guida sull’identità dei dispositivi copre la parte dei certificati.

Quando usare MQTT?

MQTT è adatto ai dispositivi che hanno una connessione IP, possono tenere aperta una sessione TCP almeno a intermittenza e inviano molti piccoli messaggi a un back end che li smista a più consumatori. È la descrizione della maggior parte dei dispositivi IoT Wi-Fi, Ethernet e cellulari, e della maggior parte dei gateway.

Si adatta male quando il dispositivo non può sostenere TCP e TLS, il che orienta verso CoAP su DTLS o verso MQTT-SN. È anche lo strumento sbagliato per le interazioni richiesta-risposta in cui un client vuole una risposta immediata da un server specifico; MQTT 5 aggiunge allo scopo i response topic e i correlation data, ma una chiamata REST o CoAP è più naturale. Per un throughput molto alto tra servizi di back end, una coda di messaggi dedicata o una piattaforma di streaming è una scelta migliore del broker rivolto ai dispositivi. E per il controllo industriale in tempo reale, i protocolli di bus di campo e OPC UA restano gli standard, con MQTT usato per portare i loro dati verso i livelli superiori.

Com’è fatto uno scambio minimo?

Un dispositivo invia una lettura con QoS 1 e segnala la propria presenza con un messaggio di stato retained e un Last Will:

CONNECT   clientId=sensor-0042, will: devices/sensor-0042/status = "offline"
PUBLISH   devices/sensor-0042/status  "online"  (retained)
PUBLISH   devices/sensor-0042/telemetry  {"t":21.4,"h":48}  QoS 1
SUBSCRIBE devices/sensor-0042/cmd/#  QoS 1

Il back end sottoscrive devices/+/telemetry e devices/+/status, e pubblica i comandi su devices/sensor-0042/cmd/set-interval.

Per continuare

• CoAP spiegato copre la principale alternativa per i dispositivi a risorse limitate.
• Le piattaforme IoT spiegate descrive i broker gestiti usati dalla maggior parte delle installazioni.
• Panoramica della connettività IoT spiega il livello radio sottostante.
• Come funziona l’IoT: dal sensore al cloud e ritorno colloca MQTT nel percorso completo dei dati.

Argomenti: MQTT, protocolli, messaggistica, publish-subscribe