MQTT: ecco cos'è e come funziona il protocollo di comunicazione IoT

Articolo aggiornato il 14 aprile 2022

1 – MQTT: cos’è?

MQTT è un termine che alla maggior parte di noi probabilmente non dice nulla. Ma se anziché parlare di MQTT, dicessimo HTTP, diverse lampadine si accenderebbero. Per dirla semplice semplice, MQTT è per l’IoT ciò che HTTP è per il web.

MQTT è l’acronimo di Message Queuing Telemetry Transport e indica un protocollo di trasmissione dati TCP/IP basato su un modello di pubblicazione e sottoscrizione che opera attraverso un apposito message broker. In sostanza, i mittenti inviano messaggi relativi ad argomenti specifici, i destinatari si iscrivono ai temi che trovano interessanti e i broker provvedono alla trasmissione dei messaggi tra le due parti.

Tanto i mittenti quanto i destinatari sono client MQTT che possono comunicare esclusivamente attraverso il message broker.

Qualsiasi device o applicazione può essere un client MQTT che si appoggia a un’apposita libreria MQTT a sua volta connessa in rete a un broker MQTT. I broker MQTT gestiscono la ricezione dei messaggi e il successivo invio ai sottoscrittori e fanno anche un’altra cosa interessante: gestiscono le autorizzazioni. Ciò significa che i mittenti e i destinatari possono accreditarsi presso il broker così che questi li riconosca nel momento in cui inviano un messaggio o si iscrivono a uno o più argomenti. In questo modo il broker comprende elementi importanti, per esempio sa che un determinato client può ascoltare un argomento, ma non può scrivere nulla in merito allo stesso argomento. Addirittura, il broker potrebbe gestire in autonomia tutti gli argomenti possibili, bloccando la creazione degli stessi ai client, ma si tratta di una configurazione particolare che non rappresenta lo standard.

Il protocollo MQTT è un protocollo ISO standard. La porta TCP/IP 1883 è riservata dallo IANA (la Internet Assigned Numbers Authority che assegna gli Ip pubblici e le porte standard) all’esclusivo scambio di comunicazioni con MQTT. Lo stesso vale per la porta 8883 per SSL.

Anche una chat di gruppo potrebbe basarsi sul protocollo MQTT.

2 – MQTT, perché sì: i vantaggi

MQTT è un protocollo di rete leggero e flessibile che garantisce il corretto equilibrio agli sviluppatori IoT: 

• La leggerezza del protocollo ne consente l’implementazione sia su dispositivi hardware fortemente vincolati, sia su reti ad elevata latenza o a larghezza di banda limitata in quanto risulta particolarmente resiliente in fase di comunicazione dei dati;
• La flessibilità del protocollo fa sì che possa supportare diversi scenari applicativi per dispositivi e servizi IoT;
• MQTT è un protocollo robusto, con una sua storia e una sua affidabilità. Insomma, non è un azzardo.

Vuoi avere maggiori informazioni su come sviluppiamo App IoT in DuckMa?

Fissa in piena autonomia la consulenza gratuita scegliendo giorno e orario in base alla tua disponibilità.

3 – HTTP, perché no: gli svantaggi

La maggior parte degli sviluppatori ha già una certa familiarità con i servizi web HTTP. Di conseguenza, perché non connettere i dispositivi IoT agli stessi servizi web? Così facendo, il dispositivo potrebbe inviare i suoi dati su richiesta del client e ricevere aggiornamenti dal sistema non appena ottiene una risposta HTTP. Tuttavia, tale percorso di richiesta e risposta incontra limiti piuttosto severi:

• HTTP si basa su richieste auto-conclusive, in cui il client si connette al server per soddisfare una singola richiesta. Una volta che il server risponde con le informazioni richieste dal client, la connessione si chiude. Questa modalità di interazione è però poco scalabile e non si adatta bene al mondo dell’Internet of Things, in cui molti dispositivi devono comunicare tra loro in tempo reale. L’MQTT si slega dalla logica richiesta-risposta e crea invece una connessione persistente tra il client e il broker, sulla quale poi vengono inoltrati, in tempo reale, tutti i messaggi originati dai vari client connessi.
• HTTP è unidirezionale. Le richieste di informazioni partono sempre dal client che esegue la richiesta al server. Questo implica che ciascun client debba continuare a richiedere attivamente le informazioni, interrogando periodicamente il server su eventuali aggiornamenti. In ambito IoT, in cui gli aggiornamenti dovrebbero essere in tempo reale e le logiche embeddate il più semplici possibile, questo meccanismo di continuo “polling” degli aggiornamenti è poco adatto. Invece l’MQTT, creando una connessione persistente, rende possibile ricevere gli aggiornamenti senza che vi sia una richiesta esplicita. In questo modo gli aggiornamenti arrivano nello stesso momento in cui gli altri attori coinvolti li inviano.

• HTTP è un protocollo 1-1. Gli unici attori coinvolti nella comunicazione HTTP sono il client che esegue la richiesta e il server che riceve la richiesta e risponde con le informazioni necessarie. Nell’IoT questo aumenterebbe di molto il carico di lavoro del server, che si troverebbe a gestire continue richieste da parte di moltissimi client, ciascuno con la sua connessione dedicata e ciascuno con il suo flusso logico per recuperare le informazioni richieste. L’MQTT risolve questo problema lasciando che siano i client a scambiarsi direttamente le informazioni, senza che il broker (server) debba fare nulla.
• HTTP è un protocollo pesante. HTTP richiede l’apertura di una nuova connessione per ogni singola richiesta, e ciascuna richiesta deve essere associata a specifiche informazioni di contesto (come ad esempio la sessione di autenticazione per identificare chi sta eseguendo la chiamata). Come detto, inoltre, nell’IoT tutti gli attori connessi devono eseguire molte chiamate in continuazione per rimanere sempre aggiornati sullo stato del sistema, appesantendo ulteriormente il sistema stesso. Con MQTT la connessione è unica, così come sono uniche le informazioni di contesto e i vari attori non devono continuare a richiedere aggiornamenti: è sufficiente che rimangano in ascolto delle informazioni che interessano loro lasciando che siano altri elementi del sistema a generarli. Per esempio, un’applicazione mobile che vuole mostrare in tempo reale lo stato di apertura di un cancello non deve fare altro che ascoltare gli eventi “stato di apertura” generati dal cancello di interesse, mentre il device connesso al cancello in apertura, ogni volta che vede un cambiamento nello stato del cancello, emette un nuovo aggiornamento che l’app mobile riceve in tempo reale.

Una caratteristica chiave del protocollo MQTT sta nel suo modello di pubblicazione e sottoscrizione. Come accade in tutti i protocolli di trasmissione dati, disaccoppia mittente e destinatario dei dati. Per dirla con il linguaggio di tutti i giorni, il protocollo MQTT non è indirizzato a una singola persona, ma è più simile a un vasto contenitore di oggetti (nel caso specifico di argomenti) in cui ciascuno va a pescare ciò che più gli interessa.

4 – Modello PubSub

Il protocollo MQTT definisce due tipologie di entità nella rete: un message broker e un certo numero di client. Il broker altro non è che un server che riceve tutti i messaggi da tutti i client per poi indirizzare tali messaggi ai client di destinazione pertinenti. Per client si intende qualsiasi cosa in grado di interagire con il broker per l’invio e la ricezione di messaggi. Un client, dunque, può essere un sensore IoT oppure un’applicazione in un data center che processa dati IoT.

1. Il client si connette al broker e può effettuare la sottoscrizione a ogni argomento di riferimento dei messaggi del broker. Questa connessione può essere una semplice TCP/IP o una TLS crittografata per i messaggi sensibili;
2. Il client pubblica messaggi relativi a un argomento inviandoli al broker.

I messaggi MQTT sono organizzati per argomento e i client possono richiedere di leggere e scrivere su qualsiasi argomento, senza limitazioni di sorta. Quindi chi controlla il controllore? In altre parole, chi decide se un cliente possa o meno leggere o scrivere su un argomento? Il broker, Il quale, tuttavia, non andrà necessariamente a limitare la lettura e/o la scrittura, perché saranno i client ad “auto-limitarsi” scrivendo e ascoltando solo ciò che compete loro. 

MQTT ha il vantaggio della leggerezza. Consta semplicemente di un’intestazione che definisce la tipologia di messaggio, un argomento testuale e infine un payload.

L’applicazione può utilizzare ogni formato di dati per il carico, come JSON, XML, binario crittografato o Base64, fintanto che i client destinatari possono analizzare il payload.

5 – Il Protocollo MQTT

Ogni messaggio MQTT ha un comando e un payload. Il comando definisce il tipo di messaggio (per esempio, un messaggio CONNECT, SUBSCRIBE o PUBLISH). Tutte le librerie MQTT forniscono modalità semplici per gestire direttamente tali messaggi e possono popolare automaticamente alcuni campi richiesti, come per esempio “messaggio” e “client Id”.

Per ulteriori informazioni circa le tipologie di messaggio disponibili, puoi consultare la documentazione ufficiale.

6 – Le librerie MQTT che usiamo in DuckMa

In DuckMa utilizziamo le seguenti librerie per la comunicazione via MQTT:

• Server: Mosca
• Android: Eclipse Paho
• iOS: MQTT-Client-Framework

Fonti

• https://mqtt.org/
• https://developer.ibm.com/blogs/open-source-ibm-mqtt-the-messaging-protocol-for-iot/
• https://developer.ibm.com/articles/iot-mqtt-why-good-for-iot/
• https://en.wikipedia.org/wiki/MQTT

Vuoi parlare con un Esperto IoT per avere maggiori informazioni?

Fissa in piena autonomia la consulenza gratuita scegliendo giorno e orario in base alla tua disponibilità.