1. CE ESTE MQTT?

MQTT înseamnă Message Queuing Telemetry Transport. Este un protocol ușor de mesagerie pentru utilizare, în cazurile în care clienții au nevoie de o mică amprentă de cod și sunt conectați la rețele sau rețele nesigure cu resurse de lățime de bandă limitate. Este utilizat în principal pentru comunicarea de la mașină la mașină (M2M) sau tipurile de conexiuni Internet of Things.

2. ISTORIE

MQTT a fost inițial creat de Dr. Andy Stanford-Clark și Arlen Nipper în 1999. Scopul inițial al metodei de comunicare a fost acela de a permite dispozitivelor de monitorizare utilizate în industria petrolului și a gazelor să își trimită datele către serverele la distanță. În multe cazuri, astfel de dispozitive de monitorizare au fost utilizate în locații îndepărtate, unde orice fel de linie fixă, conexiune cu fir sau conexiune de transmisie radio ar fi dificilă sau imposibil de stabilit. La acea vreme, singura opțiune pentru astfel de cazuri era comunicațiile prin satelit, care erau foarte scumpe și facturate în funcție de cantitatea de date folosite. Cu mii de senzori în domeniu, industria a avut nevoie de o formă de comunicare care să poată oferi date suficient de fiabile pentru utilizare, folosind în același timp o lățime de bandă minimă.
MQTT a fost standardizat ca sursă deschisă în cadrul Organizației pentru Îmbunătățirea Standardelor Informaționale Structurate (OASIS) în 2013. OASIS gestionează în continuare standardul MQTT.

3. ARHITECTURA MQTT

MQTT rulează pe TCP / IP folosind o tipologie PUSH / SUBSCRIBE. În arhitectura MQTT, există două tipuri de sisteme: clienți și brokeri. Un broker este serverul cu care clienții comunică. Brokerul primește comunicări de la clienți și trimite aceste comunicări către alți clienți. Clienții nu comunică direct între ei, ci mai degrabă se conectează la broker. Fiecare client poate fi fie editor, abonat sau ambii.
MQTT este un protocol bazat pe evenimente. Nu există transmisie periodică sau continuă a datelor. Aceasta menține transmisia la minimum. Un client publică numai atunci când există informații care trebuie trimise, iar un broker trimite informații doar abonaților atunci când sosesc date noi.

4. ARHITECTURA MESAJELOR

Un alt mod prin care MQTT reduce la minimum transmisiile sale este cu o construcție de mesaj mică, bine definită. Fiecare mesaj are un antet fix de doar 2 octeți. Se poate folosi un antet opțional, dar crește dimensiunea mesajului. Sarcina utilă a mesajului este limitată la doar 256 MB. Trei niveluri diferite ale calității serviciilor (QoS) permit proiectanților de rețea să aleagă între minimizarea transmiterii datelor și maximizarea fiabilității.

• QoS 0 – Oferă cantitatea minimă de transmisie a datelor. Cu acest nivel, fiecare mesaj este livrat unui abonat o dată fără confirmare. Nu există nicio modalitate de a ști dacă abonații au primit mesajul. Această metodă este uneori denumită „fire and forget” sau „at most once delivery”. Deoarece acest nivel presupune că livrarea este completă, mesajele nu sunt stocate pentru livrare către clienții deconectați care ulterior se reconectează.
• QoS 1 – Brokerul încearcă să transmită mesajul și apoi așteaptă un răspuns de confirmare din partea abonatului. Dacă nu se primește o confirmare într-un interval de timp specificat, mesajul este trimis din nou. Folosind această metodă, abonatul poate primi mesajul de mai multe ori dacă brokerul nu primește la timp confirmarea abonatului. Aceasta este uneori denumită „at least once delivery”.
• QoS 2 – Clientul și brokerul utilizează o strângere de mână în patru pași pentru a se asigura că mesajul este primit și că acesta este primit o singură dată. Aceasta este uneori denumită „exactly once delivery”.

Pentru situațiile în care comunicațiile sunt fiabile, dar limitate, QoS 0 poate fi cea mai bună opțiune. Pentru situațiile în care comunicațiile nu sunt de încredere, dar în care conexiunile nu sunt la fel de limitate de resurse, atunci QoS 2 ar fi cea mai bună opțiune. QoS 1 oferă un fel de cea mai bună soluție din ambele lumi, dar necesită ca aplicația care primește datele să știe să gestioneze duplicatele.
Atât pentru QoS 1 cât și pentru QoS 2, mesajele sunt salvate sau puse în coadă pentru clienții care nu sunt conectati și care au o sesiune persistentă stabilită. Aceste mesaje sunt trimise din nou (în funcție de nivelul QoS corespunzător) odată ce clientul este din nou online.

5. SUBIECTE

Mesajele din cadrul MQTT sunt publicate ca subiecte. Subiectele sunt structuri dintr-o ierarhie folosind caracterul slash (/) ca delimitator. Această structură seamănă cu cea a unui arbore de directoare pe un sistem de fișiere computer. O structură precum senzori / OilandGas / Pressure / permite unui abonat să precizeze că ar trebui să fie trimise doar date de la clienții care publică subiectul Pressure, sau pentru o vizualizare mai largă, probabil toate datele de la clienți care publică pe orice senzori / OilandGas subiect . Subiectele nu sunt create în mod explicit în MQTT. Dacă un broker primește date publicate pe un subiect care nu există în prezent, subiectul este creat simplu, iar clienții se pot abona la noul subiect.

6. MESAJE RETINUTE

Pentru a menține amprenta mică, mesajele primite nu sunt stocate pe broker decât dacă sunt marcate cu steagul reținut. Aceasta se numește un mesaj reținut. Utilizatorii care doresc să stocheze mesajele primite vor trebui să le stocheze în altă parte în afara protocolului MQTT. Există o excepție.
Ca un protocol bazat pe evenimente, este posibil, chiar probabil, ca un abonat să primească foarte puține mesaje pentru un anumit subiect, chiar și pe o perioadă lungă de timp. În structura subiectului menționată anterior, poate mesajele către subiectul Pressure sunt trimise doar atunci când un senzor detectează că presiunea a depășit o anumită cantitate. Presupunând că orice monitorizare a acestui senzor nu reușește, adesea ar putea trece luni sau chiar ani înainte ca un client să publice un mesaj la subiectul respectiv.
Pentru a vă asigura că un nou abonat primește mesajele de la un subiect, brokerii pot păstra ultimul mesaj trimis fiecărui subiect. Aceasta se numește un mesaj reținut. Ori de câte ori un nou client se abonează la un subiect sau când un client existent revine online, mesajul reținut este trimis abonaților, asigurând astfel că abonamentul este activ și că are cele mai recente informații.

7. ULTIMA DORINTA SI TESTAMENT

În cazul în care comunicațiile sunt fiabile, este posibil ca un editor să se deconecteze de la rețea fără avertisment. Un editor poate înregistra un mesaj care să fie trimis abonaților în cazul în care editorul se deconectează în mod neașteptat, aceasta este o așa-numită ultimă dorinta și testament. Acest mesaj este cache pe broker și este trimis abonaților în cazul în care editorul se deconectează în mod necorespunzător. De obicei, un astfel de mesaj include informații care să permită identificarea editorului deconectat, astfel încât să poată fi luate măsurile adecvate.

8. MESAJELE MQTT

Pentru a menține protocolul mic, există doar patru acțiuni posibile cu orice comunicare: publicare, abonare, dezabonare sau ping.

• Publicare – Trimite un bloc de date care conține mesajul care urmează să fie trimis. Aceste date sunt specifice fiecărei implementări, dar pot fi ceva la fel de simplu ca o indicație de pornire / oprire sau o valoare a unui anumit senzor, cum ar fi temperatura, presiunea, etc. În cazul în care subiectul publicat nu există, subiectul este creat pe broker.
• Abonare – Transformă un client în abonat al unui subiect. Subiectele pot fi abonate în mod specific sau prin intermediul wildcard-urilor care permit abonamente la o întreagă ramură de subiect sau o parte a unei sucursale tematice. Pentru a vă abona, un client trimite un pachet SUBSCRIBE și primește un pachet SUBACK în schimb. Dacă există un mesaj reținut pentru subiect, noul abonat primește și mesajul respectiv.
• PING – Un client poate face ping brokerului. Abonatul trimite un pachet PINGREQ și un pachet PINGRESP este trimis ca răspuns. Ping-urile pot fi utilizate pentru a vă asigura că conexiunea încă funcționează și că sesiunea TCP nu a fost închisă în mod neașteptat de alte echipamente de rețea, cum ar fi un router sau o poartă de acces.
• DISCONNECT – Abonatul sau editorul poate trimite un mesaj DISCONNECT către broker. Acest mesaj informează brokerul că nu va mai avea nevoie să trimită sau să dea mesaje pentru un abonat și că nu va mai primi date de la un editor. Acest tip de oprire permite clientului să se reconecteze folosind aceeași identitate a clientului ca înainte. Când un client se deconectează fără a trimite un mesaj de deconectare, ultima dorinta și testament este trimis abonaților

9. SECURITATE

Scopul inițial al protocolului MQTT a fost acela de a face cea mai mică și mai eficientă transmisie de date pe linii de comunicare scumpe și nesigure. Ca atare, securitatea nu a fost o preocupare primordială în timpul proiectării și implementării MQTT.
Cu toate acestea, există câteva opțiuni de securitate disponibile cu costul unei transmisii de date mai mari și a unei amprente mai mari.

• Securitatea rețelei – Dacă rețeaua în sine poate fi securizată, atunci transmiterea datelor MQTT nesigure este irelevantă. În acest caz, problemele de securitate ar trebui să apară chiar din interiorul rețelei, poate printr-un actor rău sau o altă formă de penetrare a rețelei.
• Nume utilizator și parolă – MQTT permite numele de utilizator și parolele pentru un client să stabilească o conexiune cu un broker. Din păcate, pentru a păstra lumina superioară, numele de utilizator și parolele sunt transmise în text clar. În 1999, acest lucru a fost mai mult decât suficient, deoarece interceptarea unei comunicări prin satelit pentru ceea ce era esențial o citire a senzorului fără importanță ar fi fost dificil de prohibitiv. Cu toate acestea, astăzi, interceptarea multor tipuri de comunicații de rețea fără fir este banală, ceea ce face ca această autentificare să fie totală, dar inutilă.
  Multe cazuri de utilizare necesită un nume de utilizator și o parolă nu ca protecție împotriva actorilor de rea-credință, ci ca o modalitate de a evita conexiunile neintenționate.
• SSL / TLS – Ruland deasupra TCP / IP, soluția evidentă pentru asigurarea transmisiilor între clienți și brokeri este implementarea SSL / TLS. Din păcate, acest lucru adaugă cheltuielile substanțiale la comunicațiile altfel ușoare.

10. Actualizări standard MQTT v5.0

Pe 3 aprilie 2019, OASIS a publicat standardul oficial MQTT v5.0

Caracteristici majore noi MQTT v5.0

• Reason codes – Inițial, MQTT pur și simplu nu a luat nicio măsură în cazul în care a fost un eșec. Eșecul în sine a fost singurul cod de eroare. În versiunea 5.0, confirmarile acceptă acum utilizarea codurilor de retur, care pot oferi un motiv ușor de utilizat pentru un eșec. Desigur, utilizarea codurilor de retur crește ușor amprenta.
• Shared subscriptions – Prea mulți abonați la un anumit subiect de la un broker pot crea probleme de încărcare. Abonamentele partajate permit echilibrarea încărcării între clienți.
• Message expiry – Mesajele pot fi setate pentru a fi șterse dacă nu sunt livrate într-o perioadă determinată. Acest lucru împiedică trimiterea de mesaje vechi către abonați care au fost deconectați pentru o perioadă de timp.
• Topic alias – Numele subiectelor în sine pot deveni atât de lungi încât să afecteze mica amprentă a protocolului. Șirurile de subiecte pot fi acum înlocuite cu un singur număr atunci când se utilizează în mod repetat aceleași subiecte.

Sursa: https://www.paessler.com/it-explained/mqtt