MQTT

Architettura di MQTT

MQTT funziona su TCPS utilizzando una topologia PUSH/SUBSCRIBE. Nell'architettura MQTT, esistono due tipi di sistemi: i client e i broker. Il broker è il server con cui comunicano i client. Il broker riceve le comunicazioni dai client e le invia ad altri client. I client non comunicano direttamente tra loro, ma si collegano al broker. Ogni client può essere un publisher, un subscriber o entrambi.

MQTT è un protocollo guidato dagli eventi. Non vi è alcuna trasmissione di dati periodica o continua. In questo modo la trasmissione è ridotta al minimo. Un client pubblica solo quando ci sono informazioni da inviare e un broker invia informazioni ai sottoscrittori solo quando arrivano nuovi dati.

Architettura dei messaggi

Un altro modo in cui MQTT riduce al minimo le sue trasmissioni è la costruzione di messaggi piccoli e strettamente definiti. Ogni messaggio ha un'intestazione fissa di soli 2 byte. È possibile utilizzare un'intestazione opzionale, che però aumenta le dimensioni del messaggio. Il carico utile del messaggio è limitato a soli 256 MB. Tre diversi livelli di qualità del servizio (QoS) consentono ai progettisti di rete di scegliere tra la minimizzazione della trasmissione dei dati e la massimizzazione dell'affidabilità.

• QoS 0 - Offre la quantità minima di trasmissione di dati. Con questo livello, ogni messaggio viene consegnato all'abbonato una sola volta senza alcuna conferma. Non c'è modo di sapere se gli abbonati hanno ricevuto il messaggio. Questo metodo viene talvolta definito "fire and forget" o "at most once delivery" Poiché questo livello presuppone che la consegna sia completa, i messaggi non vengono memorizzati per essere consegnati a client disconnessi che successivamente si riconnettono.
• QoS 1 - Il broker tenta di consegnare il messaggio e poi attende una risposta di conferma dal sottoscrittore. Se non riceve una conferma entro un determinato periodo di tempo, il messaggio viene inviato di nuovo. Con questo metodo, l'abbonato può ricevere il messaggio più di una volta se il broker non riceve la conferma dell'abbonato in tempo. Questo metodo viene talvolta definito "consegna almeno una volta".
• QoS 2 - Il client e il broker utilizzano un handshake in quattro fasi per garantire che il messaggio venga ricevuto e che venga ricevuto una sola volta. Questa modalità viene talvolta definita "consegna esattamente una volta".
  
  

Per situazioni in cui le comunicazioni sono affidabili ma limitate, QoS 0 può essere l'opzione migliore. Per le situazioni in cui le comunicazioni sono inaffidabili, ma le connessioni non sono così limitate, la QoS 2 è l'opzione migliore. La QoS 1 offre una sorta di soluzione ottimale, ma richiede che l'applicazione che riceve i dati sappia come gestire i duplicati.

Sia per la QoS 1 che per la QoS 2, i messaggi vengono salvati o messi in coda per i client che sono offline e che hanno una sessione persistente stabilita. Questi messaggi vengono reinviati (secondo il livello di QoS appropriato) una volta che il client è di nuovo online.

Argomenti

I messaggi in MQTT sono pubblicati come argomenti. Gli argomenti sono strutture in una gerarchia che utilizza il carattere slash (/) come delimitatore. Questa struttura assomiglia all'albero delle directory di un file system. Una struttura come Sensori/OilandGas/Pressione/ consente a un sottoscrittore di specificare che gli vengano inviati solo i dati dei client che pubblicano sull'argomento Pressione o, per una visione più ampia, tutti i dati dei client che pubblicano su qualsiasi argomento Sensori/OilandGas. Gli argomenti non vengono creati esplicitamente in MQTT. Se un broker riceve dati pubblicati su un argomento che attualmente non esiste, l'argomento viene semplicemente creato e i client possono iscriversi al nuovo argomento.

Messaggi conservati

Per mantenere l'ingombro ridotto, i messaggi ricevuti non vengono memorizzati sul broker, a meno che non siano contrassegnati dal flag retained. Questo è chiamato messaggio conservato. Gli utenti che desiderano memorizzare i messaggi ricevuti dovranno memorizzarli altrove, al di fuori del protocollo MQTT. C'è un'eccezione.

Essendo un protocollo guidato dagli eventi, è possibile, anzi probabile, che un sottoscrittore riceva pochissimi messaggi per un determinato argomento, anche per un lungo periodo di tempo. Nella struttura di argomenti precedentemente menzionata, forse i messaggi all'argomento Pressione vengono inviati solo quando un sensore rileva che la pressione ha superato un certo valore. Supponendo che il sensore monitorato non si guasti spesso, potrebbero passare mesi o addirittura anni prima che un client pubblichi un messaggio su quell'argomento.

Per garantire che un nuovo abbonato riceva i messaggi di un argomento, i broker possono conservare l'ultimo messaggio inviato a ciascun argomento. Questo è chiamato messaggio conservato. Ogni volta che un nuovo cliente si iscrive a un argomento o quando un cliente esistente torna online, il messaggio conservato viene inviato agli abbonati, assicurando così che l'abbonamento sia attivo e che abbia le informazioni più recenti.

Ultime volontà e testamento

Quando le comunicazioni sono inaffidabili, è possibile che un editore si disconnetta dalla rete senza preavviso. Un editore può registrare un messaggio da inviare agli abbonati nel caso in cui l'editore si disconnetta inaspettatamente; si tratta delle cosiddette ultime volontà. Questo messaggio viene cachettato sul broker e inviato agli abbonati nel caso in cui l'editore si disconnetta in modo improprio. In genere, questo messaggio include informazioni che consentono di identificare l'editore disconnesso, in modo da poter intraprendere le azioni appropriate.

Messaggi MQTT

Per mantenere il protocollo piccolo, ci sono solo quattro azioni possibili per ogni comunicazione: pubblicare, sottoscrivere, annullare l'iscrizione o eseguire un ping.

• Pubblicare - Invia un blocco di dati contenente il messaggio da inviare. Questi dati sono specifici per ogni implementazione, ma potrebbero essere qualcosa di semplice come un'indicazione di accensione e spegnimento, o il valore di un determinato sensore, come la temperatura, la pressione, ecc. Nel caso in cui l'argomento da pubblicare non esista, l'argomento viene creato sul broker.
• Sottoscrivi - Trasforma un client in un sottoscrittore di un argomento. Gli argomenti possono essere sottoscritti in modo specifico o tramite caratteri jolly che consentono l'abbonamento a un intero ramo di argomento o a parte di esso. Per sottoscrivere, un client invia un pacchetto SUBSCRIBE e riceve in cambio un pacchetto SUBACK. Se esiste un messaggio di mantenimento per l'argomento, il nuovo sottoscrittore riceve anche quel messaggio.
• PING - Un client può inviare un ping al broker. Il sottoscrittore invia un pacchetto PINGREQ e riceve in risposta un pacchetto PINGRESP. I ping possono essere usati per assicurarsi che la connessione sia ancora funzionante e che la sessione TCP non sia stata chiusa inaspettatamente da altre apparecchiature di rete come un router o un gateway.
• DISCONNECT - Un subscriber o un publisher può inviare un messaggio DISCONNECT al broker. Questo messaggio informa il broker che non avrà più bisogno di inviare o accodare messaggi per un sottoscrittore e che non riceverà più dati da un editore. Questo tipo di disattivazione consente al client di riconnettersi utilizzando la stessa identità del client precedente. Quando un client si disconnette senza inviare un messaggio di disconnessione, le sue ultime volontà vengono inviate agli abbonati

Sicurezza

L'obiettivo originario del protocollo MQTT era quello di realizzare la trasmissione di dati più piccola e più efficiente possibile su linee di comunicazione costose e inaffidabili. Pertanto, la sicurezza non è stata una preoccupazione primaria durante la progettazione e l'implementazione di MQTT.

Tuttavia, sono disponibili alcune opzioni di sicurezza al costo di una maggiore trasmissione di dati e di un maggiore ingombro.

• Sicurezza della rete - Se la rete stessa può essere protetta, la trasmissione di dati MQTT non sicuri è irrilevante. In questo caso, i problemi di sicurezza dovrebbero provenire dall'interno della rete stessa, forse attraverso un cattivo attore o un'altra forma di penetrazione della rete.
• Nome utente e password - L'MQTT consente a un client di stabilire una connessione con un broker tramite nome utente e password. Sfortunatamente, per mantenere la luce della testa, i nomi utente e le password sono trasmessi in chiaro. Nel 1999, questo era più che sufficiente perché intercettare una comunicazione satellitare per quella che era essenzialmente una lettura di sensore senza importanza sarebbe stato proibitivo. Oggi, invece, l'intercettazione di molti tipi di comunicazioni di rete wireless è banale e rende questa autenticazione pressoché inutile.
  Molti casi d'uso richiedono un nome utente e una password non come protezione contro gli attori in malafede, ma come modo per evitare connessioni involontarie.
• SSL/TLS - In esecuzione su IPS, la soluzione più ovvia per proteggere le trasmissioni tra client e broker è l'implementazione di SSL/TLS. Sfortunatamente, questo aggiunge un overhead sostanziale alle comunicazioni, altrimenti leggere.