Dezvoltarea tehnologiilor în domeniul software și hardware, apariția noilor protocoale de comunicare au dus la extinderea Internetului lucrurilor (IoT). Numărul de dispozitive crește pe zi ce trece și generează o cantitate imensă de date. Prin urmare, este nevoie de o arhitectură de sistem convenabilă, capabilă să prelucreze, să stocheze și să transmită aceste date.
Acum serviciile cloud sunt folosite în aceste scopuri. Cu toate acestea, paradigma din ce în ce mai populară de calcul pentru ceață (Fog) poate completa soluțiile cloud prin scalarea și optimizarea infrastructurii IoT.
Norii sunt capabili să acopere majoritatea solicitărilor IoT. De exemplu, pentru a asigura monitorizarea serviciilor, procesarea rapidă a oricărei cantități de date generate de dispozitive, precum și vizualizarea acestora. Calcularea ceață este mai eficientă atunci când se rezolvă probleme în timp real. Acestea oferă răspuns rapid la solicitări și o latență minimă în procesarea datelor. Adică, ceața completează „norii” și își extinde capacitățile.
Cu toate acestea, întrebarea principală este diferită: cum ar trebui să interacționeze toate acestea în contextul IoT? Ce protocoale de comunicare vor fi cele mai eficiente atunci când lucrați într-un sistem combinat IoT-Fog-Cloud?
În ciuda dominației aparente a HTTP, există un număr mare de alte soluții utilizate în sistemele IoT, Fog și Cloud. Acest lucru se datorează faptului că IoT trebuie să combine funcționalitatea unei varietăți de senzori de dispozitiv cu securitatea, compatibilitatea și alte cerințe ale utilizatorilor.
Dar pur și simplu nu există o idee unică despre arhitectura de referință și standardul de comunicare. Prin urmare, crearea unui nou protocol sau modificarea unuia existent pentru sarcini specifice IoT este una dintre cele mai importante sarcini cu care se confruntă comunitatea IT.
Ce protocoale sunt utilizate în prezent și ce pot oferi? Să ne dăm seama. Dar mai întâi, să discutăm despre principiile ecosistemului în care interacționează norii, ceața și Internetul lucrurilor.
Arhitectură IoT Fog-to-Cloud (F2C).
Probabil ați observat cât de mult efort se depune pentru a explora avantajele și beneficiile asociate cu gestionarea inteligentă și coordonată a IoT, cloud și ceață. Dacă nu, atunci iată trei inițiative de standardizare: , и .
Dacă anterior erau luate în considerare doar 2 niveluri, nori și dispozitive finale, atunci arhitectura propusă introduce un nou nivel - calculul de ceață. În acest caz, nivelul de ceață poate fi împărțit în mai multe subnivele, în funcție de specificul resurselor sau de un set de politici care determină utilizarea diferitelor dispozitive în aceste subnivele.
Cum ar putea arăta această abstracție? Iată un ecosistem tipic IoT-Ceață-Cloud. Dispozitivele IoT trimit date către servere și dispozitive de calcul mai rapide pentru a rezolva problemele care necesită o latență scăzută. În același sistem, norii sunt responsabili pentru rezolvarea problemelor care necesită o cantitate mare de resurse de calcul sau spațiu de stocare a datelor.
Smartphone-urile, ceasurile inteligente și alte gadget-uri pot face, de asemenea, parte din IoT. Dar astfel de dispozitive, de regulă, folosesc protocoale de comunicare proprietare de la dezvoltatori mari. Datele IoT generate sunt transferate în stratul de ceață prin protocolul REST HTTP, care oferă flexibilitate și interoperabilitate atunci când se creează servicii RESTful. Acest lucru este important în lumina necesității de a asigura compatibilitatea cu infrastructura de calcul existentă care rulează pe computere locale, servere sau un cluster de servere. Resursele locale, numite „noduri de ceață”, filtrează datele primite și le procesează local sau le trimit în cloud pentru calcule suplimentare.
Cloudurile suportă diferite protocoale de comunicare, cele mai comune fiind AMQP și REST HTTP. Deoarece HTTP este bine cunoscut și adaptat pentru Internet, poate apărea întrebarea: „Nu ar trebui să-l folosim pentru a lucra cu IoT și ceață?” Cu toate acestea, acest protocol are probleme de performanță. Mai multe despre asta mai târziu.
În general, există 2 modele de protocoale de comunicație potrivite pentru sistemul de care avem nevoie. Acestea sunt cerere-răspuns și publicare-abonare. Primul model este mai cunoscut, mai ales în arhitectura server-client. Clientul solicită informații de la server, iar serverul primește cererea, o procesează și returnează un mesaj de răspuns. Protocoalele REST HTTP și CoAP funcționează pe acest model.
Al doilea model a apărut din necesitatea de a asigura o cuplare asincronă, distribuită, liberă între sursele generatoare de date și destinatarii acestor date.
Modelul presupune trei participanți: un editor (sursa de date), un broker (dispecer) și un abonat (destinator). Aici, clientul care acționează ca abonat nu trebuie să solicite informații de la server. În loc să trimită cereri, se abonează la anumite evenimente din sistem printr-un broker, care este responsabil cu filtrarea tuturor mesajelor primite și direcționarea lor între editori și abonați. Iar editorul, atunci când are loc un eveniment cu privire la o anumită temă, îl publică brokerului, care trimite date despre subiectul solicitat abonatului.
În esență, această arhitectură este bazată pe evenimente. Și acest model de interacțiune este interesant pentru aplicații în IoT, cloud, ceață datorită capacității sale de a oferi scalabilitate și de a simplifica interconectarea dintre diferite dispozitive, de a suporta comunicarea dinamică multi-la-mulți și comunicarea asincronă. Unele dintre cele mai cunoscute protocoale de mesagerie standardizate care utilizează un model de publicare-abonare includ MQTT, AMQP și DDS.
Evident, modelul publish-subscribe are o mulțime de avantaje:
- Editorii și abonații nu trebuie să știe despre existența celuilalt;
- Un abonat poate primi informații de la mai multe publicații diferite, iar un editor poate trimite date către mai mulți abonați diferiți (principiul multi-la-mulți);
- Editorul și abonatul nu trebuie să fie activi în același timp pentru a comunica, deoarece brokerul (care lucrează ca sistem de așteptare) va putea stoca mesajul pentru clienții care nu sunt conectați în prezent la rețea.
Cu toate acestea, modelul cerere-răspuns are și punctele sale forte. În cazurile în care capacitatea serverului de a gestiona mai multe solicitări ale clienților nu este o problemă, este logic să folosiți soluții dovedite și de încredere.
Există și protocoale care acceptă ambele modele. De exemplu, XMPP și HTTP 2.0, care acceptă opțiunea „server push”. IETF a lansat, de asemenea, un CoAP. În încercarea de a rezolva problema de mesagerie, au fost create câteva alte soluții, precum protocolul WebSockets sau utilizarea protocolului HTTP prin QUIC (Quick UDP Internet Connections).
În cazul WebSockets, deși este folosit pentru a transfera date în timp real de la un server la un client web și oferă conexiuni persistente cu comunicare bidirecțională simultană, nu este destinat dispozitivelor cu resurse de calcul limitate. De asemenea, QUIC merită atenție, deoarece noul protocol de transport oferă o mulțime de noi oportunități. Dar, deoarece QUIC nu este încă standardizat, este prematur să se prezică posibila aplicare și impactul său asupra soluțiilor IoT. Așa că ținem cont de WebSockets și QUIC cu privirea către viitor, dar nu le vom studia mai detaliat deocamdată.
Cine este cel mai drăguț din lume: compararea protocoalelor
Acum să vorbim despre punctele forte și punctele slabe ale protocoalelor. Privind în viitor, să facem imediat o rezervă că nu există un lider clar. Fiecare protocol are unele avantaje/dezavantaje.
Timp 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. Dar, printre protocoalele existente, nu există un câștigător clar care să demonstreze nivelul minim de latență atunci când se lucrează în diferite condiții. Dar există o grămadă de cercetări și comparații ale capabilităților de protocol.
De exemplu, comparațiile între eficiența HTTP și MQTT atunci când lucrați cu IoT au arătat că timpul de răspuns pentru solicitările pentru MQTT este mai mic decât pentru HTTP. Și atunci când Timpul de călătorie dus-întors (RTT) al MQTT și CoAP a arătat că RTT mediu al CoAP este cu 20% mai mic decât cel al MQTT.
Alte cu RTT pentru protocoalele MQTT și CoAP a fost realizat în două scenarii: rețea locală și rețea IoT. S-a dovedit că RTT-ul mediu este de 2-3 ori mai mare într-o rețea IoT. MQTT cu QoS0 a arătat un rezultat mai scăzut în comparație cu CoAP, iar MQTT cu QoS1 a arătat un RTT mai mare datorită ACK-urilor la straturile de aplicare și transport. Pentru diferite niveluri QoS, latența rețelei fără congestie a fost de milisecunde pentru MQTT și de sute de microsecunde pentru CoAP. Cu toate acestea, merită să ne amintim că atunci când lucrați pe rețele mai puțin fiabile, MQTT care rulează peste TCP va afișa un rezultat complet diferit.
timpul de răspuns pentru protocoalele AMQP și MQTT prin creșterea sarcinii utile a arătat că, cu o sarcină ușoară, nivelul de latență este aproape același. Dar atunci când transferați cantități mari de date, MQTT demonstrează timpi de răspuns mai scurti. în încă unul CoAP a fost comparat cu HTTP într-un scenariu de comunicare între mașină, cu dispozitive instalate deasupra vehiculelor echipate cu senzori de gaz, senzori de vreme, senzori de locație (GPS) și o interfață de rețea mobilă (GPRS). Timpul necesar pentru a transmite un mesaj CoAP prin rețeaua mobilă a fost de aproape trei ori mai scurt decât timpul necesar pentru a utiliza mesajele HTTP.
Au fost efectuate studii care au comparat nu două, ci trei protocoale. De exemplu, performanța protocoalelor IoT MQTT, DDS și CoAP într-un scenariu de aplicație medicală folosind un emulator de rețea. DDS a depășit MQTT în ceea ce privește latența de telemetrie testată într-o varietate de condiții proaste de rețea. CoAP bazat pe UDP a funcționat bine pentru aplicațiile care necesitau timpi de răspuns rapid, cu toate acestea, datorită faptului că este bazat pe UDP, a existat o pierdere semnificativă de pachete imprevizibilă.
capacitate
MQTT și CoAP în ceea ce privește eficiența lățimii de bandă au fost efectuate ca un calcul al cantității totale de date transmise per mesaj. CoAP a arătat un randament mai mic decât MQTT atunci când transmite mesaje mici. Dar când se compară eficiența protocoalelor în ceea ce privește raportul dintre numărul de octeți de informații utili și numărul total de octeți transferați, CoAP s-a dovedit a fi mai eficient.
la folosind MQTT, DDS (cu TCP ca protocol de transport) și lățimea de bandă CoAP, s-a constatat că CoAP a arătat, în general, un consum de lățime de bandă comparativ mai mic, care nu a crescut odată cu pierderea de pachete de rețea crescută sau cu o latență crescută a rețelei, spre deosebire de MQTT și DDS, unde a existat o creștere a utilizării lățimii de bandă în scenariile menționate. Un alt scenariu a implicat un număr mare de dispozitive care transmit date simultan, ceea ce este tipic în mediile IoT. Rezultatele au arătat că pentru o utilizare mai mare este mai bine să utilizați CoAP.
În condiții de sarcină ușoară, CoAP a folosit cea mai mică lățime de bandă, urmată de MQTT și REST HTTP. Cu toate acestea, când dimensiunea încărcărilor utile a crescut, REST HTTP a avut cele mai bune rezultate.
Consumul de energie
Problema consumului de energie este întotdeauna de mare importanță, și mai ales într-un sistem IoT. Dacă În timp ce MQTT și HTTP consumă energie electrică, HTTP consumă mult mai mult. Și CoAP este mai mult comparativ cu MQTT, permițând gestionarea energiei. Cu toate acestea, în scenarii simple, MQTT este mai potrivit pentru schimbul de informații în rețelele Internet of Things, mai ales dacă nu există restricții de putere.
Un experiment care a comparat capacitățile AMQP și MQTT pe un banc de testare a rețelei fără fir mobil sau instabil a constatat că AMQP oferă mai multe capacități de securitate, în timp ce MQTT este mai eficient din punct de vedere energetic.
Безопасность
Securitatea este o altă problemă critică ridicată atunci când se studiază subiectul Internet of Things și ceață/cloud computing. Mecanismul de securitate se bazează de obicei pe TLS în HTTP, MQTT, AMQP și XMPP sau DTLS în CoAP și acceptă ambele variante DDS.
TLS și DTLS încep cu procesul de stabilire a comunicării între partea client și server pentru a face schimb de suite și chei de criptare acceptate. Ambele părți negociază seturi pentru a se asigura că comunicarea ulterioară are loc pe un canal securizat. Diferența dintre cele două constă în mici modificări care permit DTLS bazat pe UDP să funcționeze printr-o conexiune nesigură.
la Mai multe implementări diferite ale TLS și DTLS au descoperit că TLS a făcut o treabă mai bună. Atacurile asupra DTLS au avut mai mult succes datorită toleranței sale la erori.
Cu toate acestea, cea mai mare problemă cu aceste protocoale este că ele nu au fost concepute inițial pentru utilizare în IoT și nu au fost destinate să funcționeze în ceață sau nor. Prin acordarea de mână, ei adaugă trafic suplimentar cu fiecare stabilire de conexiune, ceea ce epuizează resursele de calcul. În medie, există o creștere de 6,5% pentru TLS și 11% pentru DTLS în cheltuielile generale, comparativ cu comunicațiile fără un nivel de securitate. În medii bogate în resurse, care sunt de obicei situate pe nivel, aceasta nu va fi o problemă, dar în legătura dintre IoT și nivelul de ceață, aceasta devine o limitare importantă.
Ce sa aleg? Nu există un răspuns clar. MQTT și HTTP par a fi protocoalele cele mai promițătoare, deoarece sunt considerate soluții IoT relativ mai mature și mai stabile în comparație cu alte protocoale.
Soluții bazate pe un protocol de comunicare unificat
Practicarea unei soluții cu un singur protocol are multe dezavantaje. De exemplu, un protocol care se potrivește unui mediu restrâns poate să nu funcționeze într-un domeniu care are cerințe stricte de securitate. Având în vedere acest lucru, suntem lăsați să renunțăm la aproape toate soluțiile posibile cu un singur protocol din ecosistemul Fog-to-Cloud din IoT, cu excepția MQTT și REST HTTP.
REST HTTP ca soluție cu un singur protocol
Există un exemplu bun despre modul în care solicitările și răspunsurile HTTP REST interacționează în spațiul IoT-to-Fog: . Animalele sunt echipate cu senzori purtabili (client IoT, C) și controlate prin cloud computing de un sistem de fermă inteligentă (server Fog, S).
Antetul metodei POST 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 urmează să o gestioneze (Dulcinea/vacă) . Răspunsul de la server indică faptul că solicitarea a avut succes prin trimiterea codului de stare HTTPS 201 (resursa creată). Metoda GET trebuie să specifice doar resursa solicitată în URI (de exemplu, /farm/animals/1), care returnează o reprezentare JSON a animalului cu acel ID de la server.
Metoda PUT este utilizată atunci când o anumită înregistrare de resurse trebuie actualizată. În acest caz, resursa specifică URI-ul parametrului care trebuie schimbat și valoarea curentă (de exemplu, indicând faptul că vaca merge în prezent, /farm/animals/1? state=walking). În cele din urmă, metoda DELETE este folosită la fel ca 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 folosim protocolul MQTT. Un server local cu biblioteca Mosquitto instalată acționează ca un broker. În acest exemplu, un computer simplu (denumit server fermă) Raspberry Pi servește ca client MQTT, implementat printr-o instalare a bibliotecii Paho MQTT, care este pe deplin compatibilă cu brokerul Mosquitto.
Acest client corespunde unui strat de abstractizare IoT reprezentând un dispozitiv cu capabilități de detectare și de calcul. Mediatorul, pe de altă parte, corespunde unui nivel superior de abstractizare, reprezentând un nod de calcul de ceață caracterizat printr-o capacitate mai mare de procesare și stocare.
În scenariul de fermă inteligentă propus, Raspberry Pi se conectează la accelerometru, GPS și senzori de temperatură și publică datele de la acești senzori într-un nod de ceață. După cum probabil știți, MQTT tratează subiectele ca pe o ierarhie. Un singur editor MQTT poate publica mesaje pentru un anumit set de subiecte. În cazul nostru sunt trei. Pentru un senzor care măsoară temperatura într-un hambar de animale, clientul selectează o temă (ferme de animale/șopată/temperatură). Pentru senzorii care măsoară locația GPS și mișcarea animalelor prin accelerometru, clientul va publica actualizări pentru (ferme de animale/animale/GPS) și (ferme de animale/animale/mișcare).
Aceste informații vor fi transmise brokerului, care le poate stoca 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 în ceață și căruia Raspberry Pis, acționând ca clienți MQTT, îi trimite date senzorilor, poate exista un alt broker MQTT la nivel de cloud. În acest caz, informațiile transmise brokerului local pot fi stocate temporar într-o bază de date locală și/sau trimise în cloud. Brokerul de ceață MQTT în această situație este folosit pentru a asocia toate datele cu brokerul MQTT cloud. Cu această arhitectură, un utilizator de aplicație mobilă poate fi abonat la ambii brokeri.
Dacă conexiunea la unul dintre brokeri (de exemplu, cloud) eșuează, utilizatorul final va primi informații de la celălalt (ceață). Aceasta este o trăsătură caracteristică a sistemelor combinate de ceață și cloud computing. În mod implicit, aplicația mobilă poate fi configurată să se conecteze mai întâi la brokerul MQTT din ceață și, dacă nu reușește, să se conecteze la brokerul MQTT din cloud. Această soluție este doar una dintre multele sisteme IoT-F2C.
Soluții multiprotocoale
Soluțiile cu un singur protocol sunt populare datorită implementării lor mai ușoare. Dar este clar că în sistemele IoT-F2C are sens să combinați diferite protocoale. Ideea este că diferite protocoale pot funcționa la diferite niveluri. Luați, de exemplu, trei abstractizări: straturile IoT, ceață și cloud computing. Dispozitivele la nivel IoT sunt, în general, considerate limitate. Pentru această prezentare generală, să considerăm nivelurile IoT ca fiind cele mai constrânse, cloud cel mai puțin constrâns și calculul de ceață ca „undeva la mijloc”. Se dovedește atunci că între abstracțiile IoT și ceață, soluțiile actuale de protocol includ MQTT, CoAP și XMPP. Între ceață și nor, pe de altă parte, AMQP este unul dintre principalele protocoale utilizate, alături de REST HTTP, care datorită flexibilității sale este folosit și între IoT și straturile de ceață.
Problema principală aici este interoperabilitatea protocoalelor și ușurința transferului mesajelor de la un protocol la altul. În mod ideal, în viitor, arhitectura unui sistem Internet of Things cu resurse cloud și ceață va fi independentă de protocolul de comunicație utilizat și va asigura o bună interoperabilitate între diferite protocoale.
Deoarece nu este cazul în prezent, este logic să combinați protocoale care nu au diferențe semnificative. În acest scop, o soluție potențială se bazează pe o combinație a două protocoale care urmează același stil arhitectural, REST HTTP și CoAP. O altă soluție propusă se bazează pe o combinație a două protocoale care oferă comunicare-publicare-abonare, MQTT și AMQP. Folosind concepte similare (atât MQTT, cât și AMQP folosesc brokeri, CoAP și HTTP folosesc REST) face aceste combinații mai ușor de implementat și necesită mai puțin efort de integrare.
Figura (a) prezintă două modele bazate pe cerere-răspuns, HTTP și CoAP, și posibila plasare a acestora într-o soluție IoT-F2C. Deoarece HTTP este unul dintre cele mai cunoscute și adoptate protocoale în rețelele moderne, este puțin probabil ca acesta să fie complet înlocuit de alte protocoale de mesagerie. Printre nodurile care reprezintă dispozitive puternice care stau între nor și ceață, REST HTTP este o soluție inteligentă.
Pe de altă parte, pentru dispozitivele cu resurse de calcul limitate care comunică între straturile Fog și IoT, este mai eficient să utilizați CoAP. Unul dintre marile avantaje ale CoAP este de fapt compatibilitatea sa cu HTTP, deoarece ambele protocoale se bazează pe principiile REST.
Figura (b) prezintă două modele de comunicare de publicare-abonare în același scenariu, inclusiv MQTT și AMQP. Deși ambele protocoale ar putea fi utilizate ipotetic pentru comunicarea între noduri la fiecare strat de abstractizare, poziția lor ar trebui determinată pe baza performanței. MQTT a fost conceput ca un protocol ușor pentru dispozitive cu resurse de calcul limitate, astfel încât să poată fi utilizat pentru comunicarea IoT-Fog. AMQP este mai potrivit pentru dispozitive mai puternice, care ar poziționa în mod ideal între nodurile de ceață și nor. În loc de MQTT, protocolul XMPP poate fi utilizat în IoT, deoarece este considerat ușor. Dar nu este atât de utilizat pe scară largă în astfel de scenarii.
Constatări
Este puțin probabil ca unul dintre protocoalele discutate să fie suficient pentru a acoperi toate comunicațiile dintr-un sistem, de la dispozitive cu resurse de calcul limitate până la servere cloud. Studiul a constatat că cele mai promițătoare două opțiuni pe care dezvoltatorii le folosesc cel mai mult sunt MQTT și RESTful HTTP. Aceste două protocoale nu sunt doar cele mai mature și mai stabile, dar includ și multe implementări și resurse online bine documentate și de succes.
Datorită stabilității și configurației sale simple, MQTT este un protocol care și-a dovedit performanța superioară în timp atunci când este utilizat la nivel IoT cu dispozitive limitate. În părțile sistemului în care comunicarea limitată și consumul de baterie nu reprezintă o problemă, cum ar fi unele domenii de ceață și majoritatea cloud computing, RESTful HTTP este o alegere ușoară. Ar trebui să se țină cont și de CoAP, deoarece evoluează rapid ca standard de mesagerie IoT și este probabil că va atinge un nivel de stabilitate și maturitate similar cu MQTT și HTTP în viitorul apropiat. Dar standardul evoluează în prezent, ceea ce vine cu probleme de compatibilitate pe termen scurt.
Ce mai poți citi pe blog?
→
→
→
→
→
Abonați-vă la -canal pentru a nu rata următorul articol! Scriem nu mai mult de două ori pe săptămână și numai pentru afaceri.
Sursa: www.habr.com