Razvoj tehnologija u području softvera i hardvera, pojava novih komunikacijskih protokola doveli su do ekspanzije Interneta stvari (IoT). Broj uređaja raste iz dana u dan i oni generiraju golemu količinu podataka. Stoga postoji potreba za prikladnom arhitekturom sustava koja može obraditi, pohraniti i prenijeti te podatke.
Sada se u te svrhe koriste usluge u oblaku. Međutim, sve popularnija paradigma maglenog računalstva (Fog) može nadopuniti rješenja u oblaku skaliranjem i optimiziranjem IoT infrastrukture.
Oblaci su sposobni pokriti većinu IoT zahtjeva. Na primjer, omogućiti praćenje usluga, brzu obradu bilo koje količine podataka koje generiraju uređaji, kao i njihovu vizualizaciju. Fog computing je učinkovitiji pri rješavanju problema u stvarnom vremenu. Omogućuju brz odgovor na zahtjeve i minimalnu latenciju u obradi podataka. Odnosno, Fog nadopunjuje "oblake" i proširuje njegove mogućnosti.
Međutim, glavno pitanje je drugačije: kako bi sve to trebalo djelovati u kontekstu IoT-a? Koji će komunikacijski protokoli biti najučinkovitiji pri radu u kombiniranom IoT-Fog-Cloud sustavu?
Unatoč očitoj dominaciji HTTP-a, postoji veliki broj drugih rješenja koja se koriste u IoT, Fog i Cloud sustavima. To je zato što IoT mora kombinirati funkcionalnost raznih senzora uređaja sa sigurnošću, kompatibilnošću i drugim zahtjevima korisnika.
Ali jednostavno ne postoji jedinstvena ideja o referentnoj arhitekturi i komunikacijskom standardu. Stoga je stvaranje novog protokola ili modificiranje postojećeg za specifične IoT zadatke jedan od najvažnijih zadataka s kojima se IT zajednica suočava.
Koji se protokoli trenutno koriste i što mogu ponuditi? Hajdemo shvatiti. Ali prvo, raspravimo o principima ekosustava u kojem su oblaci, magla i internet stvari u interakciji.
IoT Fog-to-Cloud (F2C) arhitektura
Vjerojatno ste primijetili koliko se truda ulaže u istraživanje prednosti i koristi povezanih s pametnim i koordiniranim upravljanjem IoT-a, oblaka i magle. Ako ne, onda su tri inicijative za standardizaciju: , и .
Ako su se prije razmatrale samo 2 razine, oblaci i krajnji uređaji, tada predložena arhitektura uvodi novu razinu - fog computing. U ovom slučaju, razina magle može se podijeliti u nekoliko podrazina, ovisno o specifičnostima resursa ili skupu pravila koja određuju korištenje različitih uređaja u tim podrazinama.
Kako bi ova apstrakcija mogla izgledati? Ovdje je tipičan ekosustav IoT-Fog-Cloud. IoT uređaji šalju podatke bržim poslužiteljima i računalnim uređajima kako bi riješili probleme koji zahtijevaju nisku latenciju. U istom sustavu, oblaci su odgovorni za rješavanje problema koji zahtijevaju veliku količinu računalnih resursa ili prostora za pohranu podataka.
Pametni telefoni, pametni satovi i drugi gadgeti također mogu biti dio IoT-a. Ali takvi uređaji u pravilu koriste vlasničke komunikacijske protokole velikih programera. Generirani IoT podaci prenose se u fog sloj putem REST HTTP protokola, koji pruža fleksibilnost i interoperabilnost prilikom kreiranja RESTful usluga. Ovo je važno u svjetlu potrebe da se osigura povratna kompatibilnost s postojećom računalnom infrastrukturom koja radi na lokalnim računalima, poslužiteljima ili klasteru poslužitelja. Lokalni resursi, nazvani "čvorovi magle", filtriraju primljene podatke i obrađuju ih lokalno ili ih šalju u oblak za daljnje izračune.
Oblaci podržavaju različite komunikacijske protokole, a najčešći su AMQP i REST HTTP. Budući da je HTTP dobro poznat i prilagođen za Internet, može se postaviti pitanje: "ne bismo li ga trebali koristiti za rad s IoT-om i maglom?" Međutim, ovaj protokol ima problema s performansama. Više o ovome kasnije.
Općenito, postoje 2 modela komunikacijskih protokola prikladnih za sustav koji nam je potreban. To su zahtjev-odgovor i objavljivanje-pretplata. Prvi model je šire poznat, posebice u arhitekturi server-klijent. Klijent traži informacije od poslužitelja, a poslužitelj prima zahtjev, obrađuje ga i vraća poruku odgovora. REST HTTP i CoAP protokoli rade na ovom modelu.
Drugi model nastao je iz potrebe da se osigura asinkrona, distribuirana, labava veza između izvora koji generiraju podatke i primatelja tih podataka.
Model pretpostavlja tri sudionika: izdavača (izvor podataka), posrednika (dispečera) i pretplatnika (primatelja). Ovdje klijent koji djeluje kao pretplatnik ne mora tražiti informacije od poslužitelja. Umjesto slanja zahtjeva, pretplaćuje se na određene događaje u sustavu preko brokera, koji je odgovoran za filtriranje svih dolaznih poruka i njihovo usmjeravanje između izdavača i pretplatnika. A izdavač, kada se dogodi događaj u vezi s određenom temom, to objavi brokeru, koji podatke o traženoj temi šalje pretplatniku.
U osnovi, ova se arhitektura temelji na događajima. A ovaj model interakcije zanimljiv je za aplikacije u IoT, oblaku, magli zbog svoje sposobnosti pružanja skalabilnosti i pojednostavljenja međusobnog povezivanja između različitih uređaja, podrške dinamičkoj komunikaciji više-prema-više i asinkronoj komunikaciji. Neki od najpoznatijih standardiziranih protokola za slanje poruka koji koriste model objavljivanja i pretplate uključuju MQTT, AMQP i DDS.
Očito, model objavljivanja i pretplate ima puno prednosti:
- Izdavači i pretplatnici ne moraju znati za postojanje jedni drugih;
- Jedan pretplatnik može primati informacije iz više različitih publikacija, a jedan izdavač može slati podatke više različitih pretplatnika (načelo više prema više);
- Izdavač i pretplatnik ne moraju biti istovremeno aktivni da bi komunicirali, jer će broker (koji radi kao sustav čekanja) moći pohraniti poruku za klijente koji trenutno nisu spojeni na mrežu.
Međutim, model zahtjev-odgovor također ima svoje prednosti. U slučajevima kada sposobnost serverske strane da obradi više zahtjeva klijenata nije problem, ima smisla koristiti provjerena, pouzdana rješenja.
Postoje i protokoli koji podržavaju oba modela. Na primjer, XMPP i HTTP 2.0, koji podržavaju opciju "poslužiteljski pritisak". IETF je također objavio CoAP. U pokušaju da se riješi problem slanja poruka, stvoreno je nekoliko drugih rješenja, poput protokola WebSockets ili korištenja HTTP protokola preko QUIC (Quick UDP Internet Connections).
U slučaju WebSockets, iako se koristi za prijenos podataka u stvarnom vremenu od poslužitelja do web klijenta i pruža postojane veze uz istovremenu dvosmjernu komunikaciju, nije namijenjen uređajima s ograničenim računalnim resursima. QUIC također zaslužuje pozornost, budući da novi transportni protokol pruža puno novih mogućnosti. Ali budući da QUIC još nije standardiziran, prerano je predviđati njegovu moguću primjenu i utjecaj na IoT rješenja. Stoga imamo na umu WebSockets i QUIC s pogledom na budućnost, ali za sada to nećemo detaljnije proučavati.
Tko je najslađi na svijetu: usporedba protokola
Razgovarajmo sada o prednostima i slabostima protokola. Gledajući unaprijed, odmah napomenimo da nema jednog jasnog vođe. Svaki protokol ima neke prednosti/nedostatke.
Vrijeme odgovora
Jedna od najvažnijih karakteristika komunikacijskih protokola, posebice u odnosu na Internet stvari, je vrijeme odziva. Ali među postojećim protokolima nema jasnog pobjednika koji pokazuje minimalnu razinu latencije pri radu u različitim uvjetima. Ali postoji cijela hrpa istraživanja i usporedbi mogućnosti protokola.
Na primjer, usporedbe učinkovitosti HTTP-a i MQTT-a pri radu s IoT-om pokazale su da je vrijeme odgovora za zahtjeve za MQTT kraće nego za HTTP. I kada Vrijeme povratnog putovanja (RTT) MQTT-a i CoAP-a otkrilo je da je prosječni RTT CoAP-a 20% manji od MQTT-a.
drugo s RTT-om za MQTT i CoAP protokole provedeno je u dva scenarija: lokalna mreža i IoT mreža. Ispostavilo se da je prosječni RTT 2-3 puta veći u IoT mreži. MQTT s QoS0 pokazao je niži rezultat u usporedbi s CoAP-om, a MQTT s QoS1 pokazao je veći RTT zbog ACK-ova na aplikacijskom i transportnom sloju. Za različite razine QoS-a, latencija mreže bez zagušenja iznosila je milisekunde za MQTT i stotine mikrosekundi za CoAP. Međutim, vrijedi upamtiti da će pri radu na manje pouzdanim mrežama MQTT koji radi na TCP-u pokazati potpuno drugačiji rezultat.
vrijeme odziva za protokole AMQP i MQTT povećanjem korisnog opterećenja pokazalo je da je s malim opterećenjem razina latencije gotovo ista. Ali pri prijenosu velikih količina podataka, MQTT pokazuje kraće vrijeme odziva. u još jednom CoAP je uspoređen s HTTP-om u komunikacijskom scenariju stroj-stroj s uređajima postavljenim na vrhu vozila opremljenim senzorima plina, vremenskim senzorima, senzorima lokacije (GPS) i sučeljem mobilne mreže (GPRS). Vrijeme potrebno za prijenos CoAP poruke preko mobilne mreže bilo je gotovo tri puta kraće od vremena potrebnog za korištenje HTTP poruka.
Provedene su studije koje su uspoređivale ne dva, već tri protokola. Na primjer, performanse IoT protokola MQTT, DDS i CoAP u scenariju medicinske primjene pomoću mrežnog emulatora. DDS je nadmašio MQTT u smislu testirane latencije telemetrije pod raznim lošim mrežnim uvjetima. CoAP temeljen na UDP-u dobro je funkcionirao za aplikacije koje su zahtijevale brzo vrijeme odziva, međutim, budući da se temeljio na UDP-u, došlo je do značajnog nepredvidivog gubitka paketa.
kapacitet
MQTT i CoAP u smislu učinkovitosti propusnosti provedena je kao izračun ukupne količine podataka prenesenih po poruci. CoAP je pokazao manju propusnost od MQTT-a pri prijenosu malih poruka. Ali kada se uspoređuje učinkovitost protokola u smislu omjera broja bajtova korisnih informacija i ukupnog broja prenesenih bajtova, CoAP se pokazao učinkovitijim.
u koristeći MQTT, DDS (s TCP kao transportnim protokolom) i CoAP propusnost, utvrđeno je da CoAP općenito pokazuje relativno nižu potrošnju propusnosti, koja se nije povećala s povećanim gubitkom mrežnih paketa ili povećanom latencijom mreže, za razliku od MQTT i DDS, gdje je bilo povećanje iskorištenosti propusnosti u spomenutim scenarijima. Drugi scenarij uključuje veliki broj uređaja koji prenose podatke istovremeno, što je tipično za IoT okruženja. Rezultati su pokazali da je za veću iskoristivost bolje koristiti CoAP.
Pod malim opterećenjem, CoAP je koristio najmanju propusnost, a slijede ga MQTT i REST HTTP. Međutim, kada se veličina nosivosti povećala, REST HTTP je imao najbolje rezultate.
Potrošnja energije
Pitanje potrošnje energije uvijek je od velike važnosti, a posebno u IoT sustavu. Ako Dok MQTT i HTTP troše električnu energiju, HTTP troši puno više. A CoAP je više u usporedbi s MQTT-om, omogućujući upravljanje napajanjem. Međutim, u jednostavnim scenarijima, MQTT je prikladniji za razmjenu informacija u mrežama Interneta stvari, osobito ako nema ograničenja napajanja.
Eksperiment koji je uspoređivao mogućnosti AMQP-a i MQTT-a na testiranoj mobilnoj ili nestabilnoj bežičnoj mreži otkrio je da AMQP nudi više sigurnosnih mogućnosti dok je MQTT energetski učinkovitiji.
sigurnosti
Sigurnost je još jedno kritično pitanje koje se postavlja prilikom proučavanja teme Interneta stvari i računarstva u magli/oblaku. Sigurnosni mehanizam obično se temelji na TLS-u u HTTP-u, MQTT-u, AMQP-u i XMPP-u ili DTLS-u u CoAP-u i podržava obje DDS varijante.
TLS i DTLS započinju procesom uspostavljanja komunikacije između strane klijenta i poslužitelja radi razmjene podržanih paketa šifri i ključeva. Obje strane dogovaraju setove kako bi osigurale da se daljnja komunikacija odvija na sigurnom kanalu. Razlika između to dvoje leži u malim izmjenama koje omogućuju DTLS-u temeljenom na UDP-u da radi preko nepouzdane veze.
u Nekoliko različitih implementacija TLS-a i DTLS-a pokazalo je da je TLS obavio bolji posao. Napadi na DTLS bili su uspješniji zbog njegove tolerancije na pogreške.
Međutim, najveći problem s ovim protokolima je taj što nisu izvorno dizajnirani za korištenje u IoT-u i nisu bili namijenjeni za rad u magli ili oblaku. Putem rukovanja dodaju dodatni promet sa svakom uspostavom veze, što troši računalne resurse. U prosjeku postoji povećanje od 6,5% za TLS i 11% za DTLS u režijskim troškovima u usporedbi s komunikacijama bez sigurnosnog sloja. U okruženjima bogatim resursima, koja se obično nalaze na razini, to neće biti problem, ali u vezi između IoT-a i razine magle, to postaje važno ograničenje.
Što izabrati? Ne postoji jasan odgovor. Čini se da su MQTT i HTTP protokoli koji najviše obećavaju jer se smatraju relativno zrelijim i stabilnijim IoT rješenjima u usporedbi s drugim protokolima.
Rješenja temeljena na jedinstvenom komunikacijskom protokolu
Praksa rješenja s jednim protokolom ima mnogo nedostataka. Na primjer, protokol koji odgovara ograničenom okruženju možda neće raditi u domeni koja ima stroge sigurnosne zahtjeve. Imajući to na umu, preostaje nam odbaciti gotovo sva moguća rješenja s jednim protokolom u ekosustavu Fog-to-Cloud u IoT-u, osim MQTT-a i REST HTTP-a.
REST HTTP kao rješenje s jednim protokolom
Postoji dobar primjer kako REST HTTP zahtjevi i odgovori međusobno djeluju u prostoru IoT-to-Fog: . Životinje su opremljene nosivim senzorima (IoT klijent, C) i kontrolirane su putem računalstva u oblaku putem pametnog sustava uzgoja (Fog server, S).
Zaglavlje metode POST specificira resurs za izmjenu (/farm/animals), kao i HTTP verziju i vrstu sadržaja, što je u ovom slučaju JSON objekt koji predstavlja životinjsku farmu kojom sustav treba upravljati (Dulcinea/krava) . Odgovor poslužitelja pokazuje da je zahtjev bio uspješan slanjem HTTPS statusnog koda 201 (izrađen resurs). Metoda GET mora navesti samo traženi resurs u URI-ju (na primjer, /farm/animals/1), koji s poslužitelja vraća JSON prikaz životinje s tim ID-om.
Metoda PUT koristi se kada treba ažurirati neki određeni zapis resursa. U ovom slučaju, resurs specificira URI za parametar koji treba promijeniti i trenutnu vrijednost (na primjer, označava da krava trenutno hoda, /farm/animals/1? state=walking). Konačno, metoda DELETE koristi se jednako kao i metoda GET, ali jednostavno briše resurs kao rezultat operacije.
MQTT kao rješenje s jednim protokolom
Uzmimo istu pametnu farmu, ali umjesto REST HTTP koristimo MQTT protokol. Lokalni poslužitelj s instaliranom bibliotekom Mosquitto djeluje kao posrednik. U ovom primjeru, jednostavno računalo (koji se naziva poslužitelj farme) Raspberry Pi služi kao MQTT klijent, implementiran kroz instalaciju Paho MQTT biblioteke, koja je u potpunosti kompatibilna s Mosquitto brokerom.
Ovaj klijent odgovara IoT sloju apstrakcije koji predstavlja uređaj sa senzorskim i računalnim sposobnostima. Medijator, s druge strane, odgovara višoj razini apstrakcije, predstavljajući magloviti računalni čvor karakteriziran većim kapacitetom obrade i pohrane.
U predloženom scenariju pametne farme, Raspberry Pi povezuje se s akcelerometrom, GPS-om i temperaturnim senzorima te objavljuje podatke s tih senzora čvoru za maglu. Kao što vjerojatno znate, MQTT tretira teme kao hijerarhiju. Jedan MQTT izdavač može objaviti poruke za određeni skup tema. U našem slučaju ih je tri. Za senzor koji mjeri temperaturu u staji za životinje, klijent odabire temu (farma životinja/šupa/temperatura). Za senzore koji mjere GPS lokaciju i kretanje životinja putem akcelerometra, klijent će objaviti ažuriranja za (farma životinja/životinja/GPS) i (farma životinja/kretanje životinja).
Ti će se podaci proslijediti brokeru koji ih može privremeno pohraniti u lokalnu bazu podataka u slučaju da se kasnije pojavi neki drugi zainteresirani pretplatnik.
Osim lokalnog poslužitelja, koji djeluje kao MQTT broker u magli i na koji Raspberry Pis, djelujući kao MQTT klijenti, šalje podatke senzora, možda postoji još jedan MQTT broker na razini oblaka. U tom slučaju, informacije prenesene lokalnom posredniku mogu se privremeno pohraniti u lokalnu bazu podataka i/ili poslati u oblak. Fog MQTT broker u ovoj se situaciji koristi za povezivanje svih podataka s MQTT brokerom u oblaku. Uz ovu arhitekturu, korisnik mobilne aplikacije može biti pretplaćen na oba brokera.
Ako veza s jednim od brokera (primjerice oblak) ne uspije, krajnji korisnik će dobiti informacije od drugog (magla). Ovo je karakteristična značajka kombiniranih sustava magle i oblaka. Prema zadanim postavkama, mobilna aplikacija može se konfigurirati da se prvo poveže s fog MQTT brokerom, a ako to ne uspije, da se poveže s MQTT brokerom u oblaku. Ovo rješenje samo je jedno od mnogih u IoT-F2C sustavima.
Rješenja s više protokola
Rješenja s jednim protokolom popularna su zbog lakše implementacije. Ali jasno je da u IoT-F2C sustavima ima smisla kombinirati različite protokole. Ideja je da različiti protokoli mogu raditi na različitim razinama. Uzmimo, na primjer, tri apstrakcije: slojeve IoT-a, magle i računalstva u oblaku. Uređaji na razini IoT općenito se smatraju ograničenima. Za ovaj pregled, razmotrimo razine IoT-a kao najograničenije, oblake kao najmanje ograničene, a računalstvo u magli kao "negdje u sredini". Ispostavilo se da između IoT i fog apstrakcija trenutna rješenja protokola uključuju MQTT, CoAP i XMPP. S druge strane, između magle i oblaka, AMQP je jedan od glavnih korištenih protokola, uz REST HTTP, koji se zbog svoje fleksibilnosti također koristi između IoT i fog slojeva.
Glavni problem ovdje je interoperabilnost protokola i jednostavnost prijenosa poruka s jednog protokola na drugi. U idealnom slučaju, u budućnosti će arhitektura sustava Interneta stvari s resursima oblaka i magle biti neovisna o korištenom komunikacijskom protokolu i osiguravati dobru interoperabilnost između različitih protokola.
Budući da to trenutno nije slučaj, ima smisla kombinirati protokole koji nemaju bitnih razlika. U tu svrhu, jedno potencijalno rješenje temelji se na kombinaciji dvaju protokola koji slijede isti arhitektonski stil, REST HTTP i CoAP. Drugo predloženo rješenje temelji se na kombinaciji dvaju protokola koji nude komunikaciju objavljivanja i pretplate, MQTT i AMQP. Korištenje sličnih koncepata (i MQTT i AMQP koriste brokere, CoAP i HTTP koriste REST) olakšavaju implementaciju ovih kombinacija i zahtijevaju manje napora pri integraciji.
Slika (a) prikazuje dva modela temeljena na zahtjevu i odgovoru, HTTP i CoAP, i njihov mogući smještaj u IoT-F2C rješenju. Budući da je HTTP jedan od najpoznatijih i najprihvaćenijih protokola na modernim mrežama, malo je vjerojatno da će ga u potpunosti zamijeniti drugi protokoli za razmjenu poruka. Među čvorovima koji predstavljaju moćne uređaje koji se nalaze između oblaka i magle, REST HTTP je pametno rješenje.
S druge strane, za uređaje s ograničenim računalnim resursima koji komuniciraju između slojeva Fog i IoT, učinkovitije je koristiti CoAP. Jedna od velikih prednosti CoAP-a zapravo je njegova kompatibilnost s HTTP-om, budući da se oba protokola temelje na REST principima.
Slika (b) prikazuje dva komunikacijska modela objavljivanja i pretplate u istom scenariju, uključujući MQTT i AMQP. Iako bi se oba protokola hipotetski mogla koristiti za komunikaciju između čvorova na svakom sloju apstrakcije, njihov bi se položaj trebao odrediti na temelju izvedbe. MQTT je dizajniran kao lagani protokol za uređaje s ograničenim računalnim resursima, tako da se može koristiti za komunikaciju IoT-Fog. AMQP je prikladniji za jače uređaje, koji bi ga idealno pozicionirali između čvorova magle i oblaka. Umjesto MQTT-a, XMPP protokol se može koristiti u IoT-u jer se smatra laganim. Ali nije tako široko korišten u takvim scenarijima.
Zaključci
Malo je vjerojatno da će jedan od opisanih protokola biti dovoljan da pokrije sve komunikacije u sustavu, od uređaja s ograničenim računalnim resursima do poslužitelja u oblaku. Studija je otkrila da su dvije opcije koje najviše obećavaju i koje programeri najviše koriste MQTT i RESTful HTTP. Ova dva protokola nisu samo najzreliji i najstabilniji, već također uključuju mnoge dobro dokumentirane i uspješne implementacije i mrežne resurse.
Zbog svoje stabilnosti i jednostavne konfiguracije, MQTT je protokol koji je dokazao svoje vrhunske performanse tijekom vremena kada se koristi na IoT razini s ograničenim uređajima. U dijelovima sustava gdje ograničena komunikacija i potrošnja baterije nisu problem, poput nekih maglovitih domena i većine računalstva u oblaku, RESTful HTTP je jednostavan izbor. CoAP također treba uzeti u obzir jer se također brzo razvija kao IoT standard za razmjenu poruka te je vjerojatno da će u bliskoj budućnosti dostići razinu stabilnosti i zrelosti sličnu MQTT-u i HTTP-u. No standard se trenutno razvija, što dolazi s kratkoročnim problemima kompatibilnosti.
Što još možete pročitati na blogu?
→
→
→
→
→
Pretplatite se na naš -kanal, kako ne biste propustili sljedeći članak! Pišemo ne više od dva puta tjedno i samo poslovno.
Izvor: www.habr.com