Dezvoltarea tehnologiilor în domeniul software-ului și hardware-ului, apariția unor noi protocoale de comunicare a dus la extinderea internetului lucrurilor (IoT). Numărul dispozitivelor crește zi de zi, generând un volum uriaș de date. Prin urmare, există o nevoie de o arhitectură sistemică convenabilă, capabilă să proceseze, să stocheze și să transmită aceste date.
În prezent, pentru aceste scopuri se folosesc servicii cloud. Totuși, paradigma de calcul pe nori (Fog) care devine din ce în ce mai populară poate completa soluțiile cloud, scalând și optimizând infrastructura IoT.
«Nori» pot răspunde majorității cerințelor IoT. De exemplu, pot asigura monitorizarea serviciilor, procesarea rapidă a oricăror volume de date generate de dispozitive, precum și vizualizarea acestora. Calculul pe nori este însă mai eficient în rezolvarea unor sarcini în timp real. Acesta asigură un răspuns rapid la solicitări și o întârziere minimă în procesarea datelor. Cu alte cuvinte, Fog completează exact «nori», extinzându-le capacitățile.
Cu toate acestea, întrebarea principală este alta: cum ar trebui să interacționeze toate acestea în contextul IoT? Ce protocoale de comunicare vor fi cele mai eficiente în cadrul sistemului integrat IoT-Fog-Cloud?
În ciuda aparentei dominări a HTTP, în sistemele IoT, Fog și Cloud sunt utilizate o multitudine de alte soluții. Aceasta se datorează faptului că IoT trebuie să combine capacitățile funcționale ale diverselor senzori de dispozitive cu cerințele de securitate, compatibilitate și alte cerințe impuse de utilizatori.
Numai că nu există o viziune unitară asupra arhitecturii de referință și standardului de comunicare. Prin urmare, crearea unui nou protocol sau adaptarea celui existent pentru sarcini specifice IoT reprezintă una dintre cele mai importante provocări cu care se confruntă comunitatea IT.
Ce protocoale sunt utilizate în prezent și ce pot oferi acestea? Să vedem. Dar mai întâi să discutăm principiile ecosistemului în care interacționează nori, ceață și internetul lucrurilor.
Arhitectura IoT Fog-to-Cloud (F2C)
Cu siguranță ați observat cât de multe eforturi sunt depuse pentru a studia avantajele și beneficiile asociate cu managementul rațional și coordonat al IoT, norilor și ceții. Dacă nu, iată trei inițiative de standardizare: , și .
Dacă anterior erau considerate doar 2 niveluri, cloud și dispozitive finale, arhitectura propusă introduce un nou nivel — calculul fog. În acest context, nivelul fog poate fi împărțit în mai multe subniveluri, în funcție de specificul resurselor sau de setul de politici care definesc utilizarea diferitelor dispozitive în aceste subniveluri.
Cum poate arăta această abstracție? Iată un ecosistem tipic IoT-Fog-Cloud. Dispozitivele IoT trimit date către servere și dispozitive de calcul mai performante, pentru a rezolva sarcini care necesită un nivel scăzut de latență. În aceleași sisteme, cloud-ul este responsabil pentru rezolvarea sarcinilor care necesită un volum mare de resurse de calcul sau spațiu pentru stocarea datelor.
Smartphone-urile, ceasurile inteligente și alte gadgeturi pot fi, de asemenea, parte a IoT. Dar astfel de dispozitive, de obicei, folosesc protocoale de comunicare proprietare de la mari dezvoltatori. Datele generate de internetul obiectelor sunt transmise la nivelul fog prin protocolul REST HTTP, care asigură flexibilitate și compatibilitate funcțională în crearea serviciilor RESTful. Acest aspect este important având în vedere nevoia de a asigura compatibilitatea inversă cu infrastructura de calcul existentă, care funcționează pe computere locale, servere sau clustere de servere. Resursele locale, denumite „nodi fog”, filtrează datele primite și le procesează local sau le trimit în cloud pentru calcule suplimentare.
Cloud-urile suportă diferite protocoale de comunicare, dintre care cele mai întâlnite sunt AMQP și REST HTTP. Deoarece HTTP este bine cunoscut și este optimizat pentru internet, s-ar putea pune întrebarea: „de ce să nu-l folosim pentru a lucra cu IoT și fog?”. Totuși, acest protocol are probleme de performanță. Despre această problemă vom discuta mai în detaliu ulterior.
În general, există 2 modele de protocoale de comunicare adecvate pentru sistemul nostru. Acestea sunt cerere-răspuns și publicare-abonare. Primul model este mai cunoscut, în special în arhitectura client-server. Clientul solicită informații de la server, iar serverul primește solicitarea, o procesează și returnează un mesaj de răspuns. Protocoalele REST HTTP și CoAP funcționează după acest model.
A doua model a apărut din necesitatea de a asigura o comunicare asincronă, distribuită, cu conexiune slabă între sursele care generează date și destinatarii acestor date.
Modelul presupune trei participanți: editorul (sursa de date), brokerul (dispecerul) și abonatul (destinatarul). Aici clientul, care acționează ca abonat, nu trebuie să solicite informații de la server. În loc să trimită solicitări, el se abonează la anumite evenimente din sistem prin intermediul brokerului, responsabil cu filtrarea tuturor mesajelor primite și cu rutarea acestora între editori și abonați. Iar editorul, atunci când are loc un eveniment referitor la un anumit subiect, îl publică brokerului, care trimite abonatului datele referitoare la subiectul solicitat.
În esență, această arhitectură se bazează pe evenimente. Și un astfel de model de interacțiune este interesant pentru aplicațiile din IoT, cloud, fog datorită capacității sale de a oferi scalabilitate și de a simplifica interacțiunea dintre diferite dispozitive, susținând o conectivitate dinamică „mulți la mulți” și o comunicare asincronă. Printre cele mai cunoscute protocoale de schimb de mesaje standardizate, care utilizează modelul „publicare-abonare”, se numără MQTT, AMQP și DDS.
Este evident că modelul „publicare-abonare” are multe avantaje:
- Editorii și abonații nu trebuie să știe de existența celuilalt;
- Un abonat poate primi informații de la multe publicații diferite, iar un editor poate trimite date către mulți abonați diferiți (principiul „mulți la mulți”);
- Editorul și abonatul nu trebuie să fie activi simultan pentru a schimba date, deoarece brokerul (care funcționează ca un sistem de cozi) va putea stoca mesajul pentru clienții care nu sunt conectați la rețea în acel moment.
Cu toate acestea, modelul „solicitare-răspuns” are și el propriile sale avantaje. În cazurile în care capacitățile părții serverului pentru a gestiona solicitările mai multor clienți nu reprezintă o problemă, are sens să se utilizeze soluții fiabile deja verificate.
Există, de asemenea, protocoale care susțin ambele modele. De exemplu, XMPP și HTTP 2.0, care suportă opțiunea „server push”. IETF a lansat și CoAP. În încercarea de a rezolva problema schimbului de mesaje, au fost create câteva alte soluții, cum ar fi protocolul WebSockets sau utilizarea protocolului HTTP prin QUIC (Quick UDP Internet Connections).
În cazul WebSockets, deși este folosit pentru transmiterea datelor în timp real de la server la clientul web și asigură conexiuni permanente cu comunicare bidirecțională simultană, nu este destinat dispozitivelor cu resurse computaționale limitate. QUIC merită, de asemenea, menționat, deoarece acest nou protocol de transport oferă o mulțime de noi oportunități. Dar, deoarece QUIC nu este încă standardizat, este prematur să prezicem aplicarea sa posibilă și impactul asupra soluțiilor în domeniul IoT. Așadar, WebSockets și QUIC rămân în memorie cu perspectiva asupra viitorului, dar nu le vom studia mai în detaliu pentru moment.
Cine este cel mai drăguț din lume: comparăm protocoalele
Acum să discutăm despre punctele forte și slabe ale protocoalelor. Înaintând, trebuie să spunem că nu există un lider evident. Fiecare protocol are propriile sale avantaje și dezavantaje.
Timpul de răspuns
Una dintre cele mai importante caracteristici ale protocoalelor de comunicare, în special în ceea ce privește internetul obiectelor, este timpul de răspuns. Însă, printre protocoalele existente, nu există un câștigător indiscutabil care să demonstreze cel mai scăzut nivel de întârziere în diverse condiții. Totuși, există o mulțime de cercetări și comparații ale capacităților protocoalelor.
De exemplu, Comparațiile eficienței HTTP și MQTT în contextul IoT au arătat că timpul de răspuns pentru cereri este mai mic la MQTT decât la HTTP. Iar la timpului de transmisie (RTT) pentru MQTT și CoAP s-a descoperit că RTT-ul mediu pentru CoAP este cu 20% mai mic decât cel pentru MQTT.
Altele Analiza RTT-ului pentru protocoalele MQTT și CoAP s-a desfășurat în două scenarii: rețea locală și rețea IoT. S-a constatat că RTT-ul mediu este de 2-3 ori mai mare în rețeaua IoT. MQTT cu QoS0 a avut rezultate mai slabe comparativ cu CoAP, iar MQTT cu QoS1 a arătat un RTT mai mare datorită ACK-urilor la nivelurile aplicației și transportului. Pentru diferite niveluri de QoS, întârzierile în rețea fără suprasarcină pentru MQTT au fost de câteva milisecunde, iar pentru CoAP — sute de microsecunde. Totuși, trebuie să ne amintim că în rețele mai puțin fiabile, MQTT, care funcționează pe TCP, va arăta rezultate complet diferite.
Timpul de răspuns al protocoalelor AMQP și MQTT a arătat că, sub o sarcină mică, nivelul de întârziere este aproape identical. Însă, atunci când se transmit volume mari de date, MQTT demonstrează un timp de răspuns mai scurt. Există și un alt CoAP a fost comparat cu HTTP într-un scenariu de comunicare între mașini, utilizând dispozitive desfășurate pe vehicule dotate cu senzori de gaz, senzori de vreme, localizare (GPS) și interfață de rețea mobilă (GPRS). Timpul necesar pentru transmiterea mesajului CoAP prin rețeaua mobilă a fost de aproape trei ori mai scurt decât timpul necesar pentru utilizarea mesajelor HTTP.
S-au realizat studii în care au fost comparate nu două, ci trei protocoale. De exemplu, performanței protocoalelor IoT MQTT, DDS și CoAP într-un scenariu medical utilizând un emulator de rețea. DDS a depășit MQTT în ceea ce privește întârzierea testată a telemetriei în diverse condiții proaste de rețea. CoAP bazat pe UDP a funcționat bine pentru aplicațiile care necesitau un răspuns rapid, totuși, din cauza bazei sale pe UDP, a existat o pierdere semnificativă și imprevizibilă de pachete.
Lățimea de bandă
MQTT și CoAP în ceea ce privește eficiența utilizării lățimii de bandă s-a făcut prin numărarea totalului de date transmise într-un mesaj. CoAP a arătat o lățime de bandă mai mică decât MQTT la transmiterea mesajelor mici. Cu toate acestea, când s-a comparat eficiența protocoalelor în ceea ce privește raportul dintre datele utile și totalul de biți transmiși, CoAP s-a dovedit a fi mai eficient.
Upon utilizării lățimii de bandă MQTT, DDS (cu TCP ca protocol de transport) și CoAP s-a constatat că, în general, CoAP a arătat un consum de lățime de bandă relativ mai scăzut, care nu a crescut odată cu creșterea pierderilor de pachete de rețea sau a întârzierii rețelei, spre deosebire de MQTT și DDS, unde în scenariile menționate s-a observat o creștere a utilizării lățimii de bandă. În alt scenariu, a fost implicat un număr mare de dispozitive care transmit date simultan, ceea ce este un caz tipic în medii IoT. Rezultatele au arătat că pentru o încărcare mai mare, este mai bine să se folosească CoAP.
În condiții de încărcare redusă, CoAP a utilizat cea mai mică capacitate de bandă, urmat de MQTT și REST HTTP. Cu toate acestea, atunci când dimensiunea sarcinilor utile a crescut, cele mai bune rezultate au fost obținute de REST HTTP.
Consumul de energie
Problema consumului de energie este întotdeauna importantă, iar în sistemul IoT - în mod special. Dacă consumul de energie între MQTT și HTTP, atunci HTTP "consumă" mult mai mult. Iar CoAP este mai comparativ cu MQTT, permițând gestionarea alimentării. În acest context, în scenarii simple, MQTT este mai potrivit pentru schimbul de informații în rețelele Internetului Lucrurilor, mai ales atunci când nu există constrângeri de putere.
experimentul în cadrul căruia s-au comparat capacitățile AMQP și MQTT pe un stand de testare a unei rețele mobile sau instabile fără fir a arătat că AMQP oferă mai multe posibilități în privința securității, în timp ce MQTT este mai eficient din punct de vedere energetic.
Securitate
Securitatea este o altă problemă esențială, ridicată când se studiază subiectul Internetului Lucrurilor și al calculului de tip fog/cloud. Mecanismul de securitate se bazează de obicei pe TLS în HTTP, MQTT, AMQP și XMPP, sau DTLS în CoAP, susținând ambele opțiuni DDS.
TLS și DTLS încep cu un proces de stabilire a conexiunii între partea client și partea server pentru a schimba seturile de criptare și cheile acceptate. Ambele părți convin asupra seturilor pentru a asigura că comunicarea ulterioară se desfășoară într-un canal sigur. Diferența dintre ele constă în modificările minore care permit DTLS, bazat pe UDP, să funcționeze într-o conexiune nesigură.
Upon împotriva mai multor implementări diferite ale TLS și DTLS a arătat că TLS a făcut față mai bine provocării. Atacurile asupra DTLS au fost mai reușite datorită toleranței sale la erori.
Cu toate acestea, cea mai mare problemă a acestor protocoale este că nu au fost concepute inițial pentru utilizarea în IoT și nu au anticipat funcționarea în fog sau cloud. Printr-un schimb convenit (handshaking) ele adaugă trafic suplimentar cu fiecare stabilire a conexiunii, ceea ce epuizează resursele computaționale. În medie, se observă o creștere de 6,5% pentru TLS și 11% pentru DTLS în încărcătura de control comparativ cu comunicația fără nivel de securitate. În medii bogate în resurse, care se află de obicei în la nivel, nu va fi o problemă, dar în legătura dintre IoT și nivelul de ceață, aceasta devine o limitare importantă.
Ce să alegem? Nu există un răspuns clar. MQTT și HTTP par a fi cele mai promițătoare protocoale, deoarece sunt considerate soluții relativ mature și mai stabile pentru IoT în comparație cu alte protocoale.
Soluții bazate pe un singur protocol de comunicație
Practicile soluțiilor cu un singur protocol au multe dezavantaje. De exemplu, un protocol care se dovedește eficient într-un mediu restricționat poate să nu funcționeze într-un domeniu cu cerințe stricte de securitate. Având în vedere acest lucru, trebuie să eliminăm aproape toate soluțiile posibile bazate pe un singur protocol în ecosistemul Fog-to-Cloud în IoT, cu excepția MQTT și REST HTTP.
REST HTTP ca soluție cu un singur protocol
Există un exemplu bun de interacțiune între cereri și răspunsuri REST HTTP în domeniul IoT-to-Fog: . Animalele sunt echipate cu senzori purtabili (client IoT, C) și sunt gestionate de către un sistem de fermă inteligentă prin cloud computing (server Fog, S).
În antetul metodei POST se specifică resursa de modificat (\/farm\/animals), precum și versiunea HTTP și tipul de conținut, care în acest caz este un obiect JSON reprezentând ferma de animale pe care sistemul ar trebui să o gestioneze (Dulcineea\/vacă). Răspunsul de la server indică faptul că cererea a fost succes, trimițând codul de stare HTTPS 201 (resource created). Metoda GET ar trebui să indice doar resursa solicitată în URI (de exemplu, \/farm\/animals\/1), care returnează o reprezentare JSON a animalului cu acest identificator de pe server.
Metoda PUT este utilizată atunci când este necesar să se actualizeze o anumită înregistrare a resursei. În acest caz, resursa indică URI-ul pentru parametrul care urmează să fie modificat și valoarea curentă (de exemplu, indicând că vaca este în prezent la păscut, \/farm\/animals\/1?stare=plimbare). În cele din urmă, metoda DELETE este utilizată în mod similar cu metoda GET, dar pur și simplu șterge resursa ca rezultat al operației.
MQTT ca soluție cu un singur protocol
Să luăm aceeași fermă inteligentă, dar în loc de REST HTTP, vom folosi protocolul MQTT. Un server local cu biblioteca Mosquitto instalată acționează ca broker. În acest exemplu, un computer simplu (denumit serverul fermei) Raspberry Pi servește ca client MQTT, implementat prin instalarea bibliotecii MQTT Paho, complet compatibilă cu brokerul Mosquitto.
Acest client corespunde nivelului de abstractizare IoT, reprezentând un dispozitiv cu capacități de detectare și calcul. Pe de altă parte, mediatorul corespunde unui nivel mai înalt de abstractizare, reprezentând un nod de calcul la margine, caracterizat prin resurse mai mari în ceea ce privește procesarea și stocarea datelor.
În scenariul propus al „fermă inteligente”, Raspberry Pi se conectează la un accelerometru, GPS și senzori de temperatură, publicând date de la acești senzori într-un nod de margine. Așa cum știți, MQTT consideră subiectele ca o ierarhie. Un editor MQTT poate publica mesaje într-un anumit set de subiecte. În cazul nostru, sunt trei. Pentru senzorul care măsoară temperatura din adăpostul animalelor, clientul alege subiectul (animalfarm/shed/temperature). Pentru senzorii care măsoară locația GPS și mișcarea animalelor prin accelerometru, clientul publică actualizări (animalfarm/animal/GPS) și (animalfarm/animal/movement).
Această informație va fi transmisă brokerului, care poate să o stocheze temporar într-o bază de date locală în cazul în care mai târziu apare un alt abonat interesat.
Pe lângă serverul local care acționează ca broker MQTT la margine și căruia Raspberry Pi, acționând ca clienți MQTT, îi trimite datele de la senzori, la nivelul cloud poate exista un alt broker MQTT. În acest caz, informațiile transmise brokerului local pot fi stocate temporar într-o bază de date locală și/sau trimise în cloud. Brokerul MQTT de margine în această situație este utilizat pentru a lega toate datele cu brokerul MQTT din cloud. Cu o astfel de arhitectură, utilizatorul aplicației mobile poate fi abonat la ambele brokere.
În cazul în care conexiunea cu unul dintre brokeri (de exemplu, cloud) eșuează, utilizatorul final va primi informații de la un alt broker (de tip fog). Aceasta este o caracteristică tipică a sistemelor combinate de fog și cloud computing. Implicit, aplicația mobilă poate fi configurată să se conecteze mai întâi la un broker MQTT de tip fog, și, în cazul unui eșec, să se conecteze la brokerul MQTT din cloud. Aceasta este doar una dintre numeroasele soluții în sistemele IoT-F2C.
Soluții multi-protocol
Soluțiile cu un singur protocol sunt populare datorită implementării lor mai simple. Dar este evident că în sistemele IoT-F2C are sens să combinăm diferite protocoale. Ideea este că la diferite niveluri pot funcționa protocoale diferite. Să luăm, de exemplu, trei abstracții: nivelurile IoT, fog și cloud computing. Dispozitivele de la nivelul IoT sunt de obicei considerate limitate. În această revizuire, să considerăm nivelurile IoT ca fiind cele mai limitate, cele de cloud cele mai puțin limitate și calculele de fog ca fiind „undeva la mijloc”. Astfel, între IoT și abstracțiile de fog, soluțiile protocolare actuale includ MQTT, CoAP și XMPP. Între fog și cloud, pe de altă parte, AMQP este unul dintre protocoalele principale utilizate împreună cu REST HTTP, care, datorită flexibilității sale, este de asemenea utilizat între IoT și straturile de fog.
Principala problemă aici constă în compatibilitatea funcțională a protocolilor și în ușurința conversiei mesajelor dintr-un protocol în altul. În mod ideal, în viitor, arhitectura sistemului de internet al lucrurilor cu resurse cloud și fog va fi independentă de protocolul de comunicare utilizat și va asigura o bună interacțiune între diferitele protocoale.
Deoarece, în prezent, acest lucru nu se întâmplă, are sens să combinăm protocoalele care nu au diferențe semnificative. În acest sens, o soluție potențială se bazează pe combinarea a două protocoale care respectă același stil arhitectural, REST HTTP și CoAP. O altă soluție propusă se bazează pe combinarea a două protocoale care oferă interacțiune prin modelul „publicare-abonare”, MQTT și AMQP. Utilizarea conceptelor apropiate (și MQTT, și AMQP folosesc brokeri, CoAP și HTTP folosesc REST), simplifică implementarea acestor combinații și necesită mai puțin efort pentru integrare.
În figura (a) sunt reprezentate două modele bazate pe cereri-răspunsuri, HTTP și CoAP, și posibilitatea lor de integrare în soluția IoT-F2C. Deoarece HTTP este unul dintre cele mai cunoscute și adaptabile protocoale din rețelele moderne, este puțin probabil să fie complet înlocuit de alte protocoale de mesagerie. Dintre nodurile care reprezintă dispozitive puternice, ce se află între cloud și fog, REST HTTP reprezintă o soluție rezonabilă.
Pe de altă parte, pentru dispozitive cu resurse computaționale limitate, care se conectează între nivelurile de fog și IoT, este mai eficient să se utilizeze CoAP. Unul dintre principalele avantaje ale CoAP este, de fapt, compatibilitatea sa cu HTTP, deoarece ambele protocoale se bazează pe principiile REST.
În figura (b) sunt prezentate două modele de interacțiune „publicare-abonare” într-un scenariu, incluzând MQTT și AMQP. Deși, pe hârtie, ambele protocoale ar putea fi utilizate pentru comunicarea între noduri la fiecare nivel de abstractizare, amplasarea lor ar trebui să fie determinată pe baza performanței. MQTT a fost dezvoltat ca un protocol simplificat pentru dispozitive cu resurse computaționale limitate, astfel că poate fi folosit pentru comunicarea între IoT și fog. AMQP este mai bine adaptat pentru dispozitive mai puternice, care ar plasa perfect între nodurile de fog și cloud. În loc de MQTT, în IoT poate fi utilizat protocolul XMPP, deoarece acesta este considerat ușor. Totuși, acesta nu este la fel de utilizat în astfel de scenarii.
Conclusions
Este puțin probabil ca unul dintre protocoalele discutate să fie suficient pentru a acoperi toată comunicarea din sistem, începând cu dispozitivele cu resurse computaționale limitate și terminând cu serverele cloud. Studiul a arătat că cele două opțiuni cele mai promițătoare, utilizate frecvent de dezvoltatori, sunt MQTT și RESTful HTTP. Aceste două protocoale sunt nu doar cele mai mature și stabile, ci includ, de asemenea, numeroase implementări bine documentate și resurse online de succes.
Datorită stabilității și configurației sale simple, MQTT este un protocol care, în timp, și-a dovedit performanța superioară la nivelul IoT cu dispozitivele limitate. În părțile sistemului unde comunicația limitată și consumul de energie nu sunt o problemă, cum ar fi în unele domenii de fog și majoritatea calculilor în cloud, RESTful HTTP este o alegere simplă. CoAP ar trebui, de asemenea, luat în considerare, deoarece se dezvoltă rapid ca standard de comunicare IoT, iar este foarte posibil ca în viitorul apropiat să atingă un nivel de stabilitate și maturitate similar cu MQTT și HTTP. Însă standardul este în prezent în dezvoltare, ceea ce aduce probleme de compatibilitate pe termen scurt.
Ce altceva util se poate citi în blog
→
→
→
→
→
Abonați-vă la canalul nostru -canal pentru a nu rata următorul articol! Scriem nu mai des de două ori pe săptămână și doar lucruri importante.
Sursa: habr.com
