Razvoj tehnologija u oblasti softvera i hardvera, pojava novih komunikacijskih protokola doveli su do ekspanzije Interneta stvari (IoT). Broj uređaja raste iz dana u dan i generiraju ogromnu količinu podataka. Zbog toga postoji potreba za prikladnom arhitekturom sistema sposobnom za obradu, pohranjivanje i prijenos ovih podataka.
Sada se za ove svrhe koriste usluge u oblaku. Međutim, sve popularnija paradigma računarstva u magli (Fog) može upotpuniti rješenja u oblaku skaliranjem i optimizacijom IoT infrastrukture.
Oblaci su sposobni pokriti većinu IoT zahtjeva. Na primjer, za pružanje nadzora usluga, brzu obradu bilo koje količine podataka koje generiraju uređaji, kao i njihovu vizualizaciju. Računanje magle je efikasnije kada se rešavaju problemi u realnom vremenu. Pružaju brz odgovor na zahtjeve i minimalno kašnjenje u obradi podataka. To jest, magla nadopunjuje "oblake" i proširuje svoje mogućnosti.
Međutim, glavno pitanje je drugačije: kako bi sve to trebalo biti u interakciji u kontekstu IoT-a? Koji će komunikacijski protokoli biti najefikasniji kada radite u kombinovanom IoT-Fog-Cloud sistemu?
Uprkos očiglednoj dominaciji HTTP-a, postoji veliki broj drugih rešenja koja se koriste u IoT, Fog i Cloud sistemima. To je zato što IoT mora kombinirati funkcionalnost raznih senzora uređaja sa sigurnosnim, kompatibilnim i drugim zahtjevima korisnika.
Ali jednostavno ne postoji jedinstvena ideja o referentnoj arhitekturi i komunikacijskom standardu. Stoga je kreiranje novog protokola ili modifikacija postojećeg za specifične IoT zadatke jedan od najvažnijih zadataka s kojima se suočava IT zajednica.
Koji se protokoli trenutno koriste i šta mogu ponuditi? Hajde da to shvatimo. Ali prvo, hajde da razgovaramo o principima ekosistema u kojem oblaci, magla i internet stvari komuniciraju.
IoT Fog-to-Cloud (F2C) arhitektura
Vjerovatno ste primijetili koliko se truda ulaže u istraživanje prednosti i prednosti povezanih s pametnim i koordinisanim upravljanjem internetom stvari, oblakom i maglom. Ako ne, evo tri inicijative za standardizaciju: , и .
Ako su se ranije razmatrala samo 2 nivoa, oblaci i krajnji uređaji, onda predložena arhitektura uvodi novi nivo - računanje magle. U ovom slučaju, nivo magle se može podijeliti na nekoliko podnivoa, ovisno o specifičnostima resursa ili skupu politika koje određuju korištenje različitih uređaja na ovim podnivoima.
Kako bi ova apstrakcija mogla izgledati? Evo tipičnog IoT-Fog-Cloud ekosistema. IoT uređaji šalju podatke bržim serverima i računarskim uređajima kako bi riješili probleme koji zahtijevaju nisko kašnjenje. U istom sistemu, oblaci su odgovorni za rešavanje problema koji zahtevaju veliku količinu računarskih resursa ili prostora za skladištenje podataka.
Pametni telefoni, pametni satovi i drugi uređaji također mogu biti dio IoT-a. Ali takvi uređaji, u pravilu, koriste vlasničke komunikacijske protokole velikih programera. Generirani IoT podaci se prenose u sloj magle putem REST HTTP protokola, koji pruža fleksibilnost i interoperabilnost prilikom kreiranja RESTful usluga. Ovo je važno u svjetlu potrebe da se osigura kompatibilnost unatrag sa postojećom računarskom infrastrukturom koja radi na lokalnim računarima, serverima ili serverskom klasteru. Lokalni resursi, zvani „čvorovi magle“, filtriraju primljene podatke i lokalno ih obrađuju ili šalju u oblak na daljnje prorač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 skrojen za internet, može se postaviti pitanje: „zar ne bismo trebali da ga koristimo za rad sa IoT-om i maglom?“ Međutim, ovaj protokol ima problema s performansama. Više o tome kasnije.
Generalno, postoje 2 modela komunikacionih protokola prikladnih za sistem koji nam je potreban. To su zahtjev-odgovor i objavljivanje-pretplata. Prvi model je šire poznat, posebno u arhitekturi server-klijent. Klijent traži informacije od servera, a server prima zahtjev, obrađuje ga i vraća poruku odgovora. REST HTTP i CoAP protokoli rade na ovom modelu.
Drugi model je proizašao iz potrebe da se obezbedi asinhrona, distribuirana, labava veza između izvora koji generišu podatke i primalaca ovih podataka.
Model pretpostavlja tri učesnika: izdavača (izvor podataka), brokera (dispečer) i pretplatnika (primaoca). Ovdje klijent koji djeluje kao pretplatnik ne mora tražiti informacije od servera. Umjesto slanja zahtjeva, on se pretplaćuje na određene događaje u sistemu preko brokera, koji je odgovoran za filtriranje svih dolaznih poruka i njihovo rutiranje između izdavača i pretplatnika. A izdavač, kada se dogodi događaj u vezi sa određenom temom, to objavljuje brokeru, koji pretplatniku šalje podatke o traženoj temi.
U suštini, ova arhitektura je zasnovana na događajima. A ovaj model interakcije je zanimljiv za aplikacije u IoT-u, oblaku, magli zbog svoje sposobnosti da pruži skalabilnost i pojednostavi međusobnu povezanost između različitih uređaja, podržava dinamičku komunikaciju više-prema-više i asinkronu komunikaciju. Neki od najpoznatijih standardiziranih protokola za razmjenu poruka koji koriste model objavljivanja i pretplate uključuju MQTT, AMQP i DDS.
Očigledno, model objave-pretplate ima mnogo prednosti:
- Izdavači i pretplatnici ne moraju znati o postojanju jedni drugih;
- Jedan pretplatnik može primati informacije iz više različitih publikacija, a jedan izdavač može slati podatke mnogim različitim pretplatnicima (princip mnogo-prema-mnogima);
- Izdavač i pretplatnik ne moraju biti istovremeno aktivni da bi komunicirali, jer će broker (koji radi kao sistem čekanja) moći pohraniti poruku za klijente koji trenutno nisu povezani na mrežu.
Međutim, model zahtjev-odgovor ima i svoje prednosti. U slučajevima kada sposobnost serverske strane da obrađuje više zahtjeva klijenata nije problem, ima smisla koristiti dokazana, pouzdana rješenja.
Postoje i protokoli koji podržavaju oba modela. Na primjer, XMPP i HTTP 2.0, koji podržavaju opciju „server push“. IETF je također objavio CoAP. U pokušaju da se riješi problem razmjene poruka, kreirano je nekoliko drugih rješenja, kao što je WebSockets protokol ili korištenje HTTP protokola preko QUIC-a (Brze UDP internetske veze).
U slučaju WebSockets-a, iako se koristi za prijenos podataka u realnom vremenu sa servera na web klijent i pruža trajne veze uz istovremenu dvosmjernu komunikaciju, nije namijenjen uređajima s ograničenim računskim resursima. QUIC također zaslužuje pažnju, jer novi transportni protokol pruža puno novih mogućnosti. Ali budući da QUIC još nije standardiziran, preuranjeno 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.
Ko je najslađi na svijetu: upoređivanje protokola
Hajde sada da razgovaramo o prednostima i slabostima protokola. Gledajući unapred, odmah rezervišemo da nema jednog jasnog lidera. Svaki protokol ima neke prednosti/nedostatke.
Vrijeme odziva
Jedna od najvažnijih karakteristika komunikacijskih protokola, posebno u odnosu na Internet stvari, je vrijeme odziva. Ali među postojećim protokolima, nema jasnog pobjednika koji pokazuje minimalni nivo latencije pri radu u različitim uvjetima. Ali postoji čitava gomila istraživanja i poređenja mogućnosti protokola.
Na primjer, poređenja efikasnosti HTTP-a i MQTT-a pri radu sa IoT-om pokazala su da je vrijeme odgovora za zahtjeve za MQTT manje nego za HTTP. I kada Vrijeme povratnog putovanja (RTT) za MQTT i CoAP otkrilo je da je prosječni RTT CoAP-a 20% manji od MQTT-a.
Ostalo sa RTT-om za MQTT i CoAP protokole izvedena je u dva scenarija: lokalna mreža i IoT mreža. Pokazalo se da je prosječan RTT 2-3 puta veći u IoT mreži. MQTT sa QoS0 je pokazao niži rezultat u odnosu na CoAP, a MQTT sa QoS1 je pokazao veći RTT zbog ACK-ova na aplikacijskom i transportnom sloju. Za različite QoS nivoe, kašnjenje mreže bez zagušenja je bilo milisekundi za MQTT, a stotine mikrosekundi za CoAP. Međutim, vrijedi zapamtiti da će kada radite na manje pouzdanim mrežama, MQTT koji radi na vrhu TCP-a pokazati potpuno drugačiji rezultat.
vrijeme odziva za AMQP i MQTT protokole povećanjem korisnog opterećenja pokazalo je da je sa malim opterećenjem nivo latencije skoro isti. Ali kada prenosi velike količine podataka, MQTT pokazuje kraće vrijeme odgovora. u još jednom CoAP je upoređen sa HTTP-om u komunikacijskom scenariju od mašine do mašine sa uređajima postavljenim na vozila opremljenim senzorima za gas, vremenskim senzorima, senzorima lokacije (GPS) i interfejsom mobilne mreže (GPRS). Vrijeme potrebno za prijenos CoAP poruke preko mobilne mreže bilo je skoro tri puta kraće od vremena potrebnog za korištenje HTTP poruka.
Provedene su studije koje su upoređivale ne dva, već tri protokola. Na primjer, performanse IoT protokola MQTT, DDS i CoAP u scenariju medicinske aplikacije koristeći mrežni emulator. DDS je nadmašio MQTT u smislu testirane latencije telemetrije u raznim lošim mrežnim uslovima. CoAP zasnovan na UDP-u je dobro funkcionisao za aplikacije koje su zahtevale brzo vreme odziva, međutim, zbog toga što je bio zasnovan na UDP-u, došlo je do značajnog nepredvidivog gubitka paketa.
Propusnost
MQTT i CoAP u smislu efikasnosti propusnog opsega izveden je kao proračun ukupne količine podataka prenetih po poruci. CoAP je pokazao nižu propusnost od MQTT-a pri prijenosu malih poruka. Ali kada se uporedi efikasnost protokola u smislu odnosa broja korisnih informacionih bajtova i ukupnog broja prenetih bajtova, CoAP se pokazao efikasnijim.
u koristeći MQTT, DDS (sa TCP kao transportnim protokolom) i CoAP propusni opseg, ustanovljeno je da je CoAP općenito pokazao relativno nižu potrošnju propusnog opsega, koja se nije povećavala s povećanim gubitkom mrežnih paketa ili povećanim kašnjenjem mreže, za razliku od MQTT i DDS, gdje je bilo povećanje iskorištenosti propusnog opsega u navedenim scenarijima. Drugi scenario je uključivao veliki broj uređaja koji istovremeno prenose podatke, što je tipično za IoT okruženja. Rezultati su pokazali da je za veću iskorišćenost bolje koristiti CoAP.
Pod malim opterećenjem, CoAP je koristio najmanji propusni opseg, a slijede MQTT i REST HTTP. Međutim, kada se povećala veličina korisnih podataka, REST HTTP je imao najbolje rezultate.
Potrošnja energije
Pitanje potrošnje energije je uvijek od velike važnosti, a posebno u IoT sistemu. Ako Dok MQTT i HTTP troše električnu energiju, HTTP troši mnogo više. A CoAP je više u poređenju sa MQTT, što omogućava upravljanje napajanjem. Međutim, u jednostavnim scenarijima, MQTT je pogodniji za razmjenu informacija u mrežama Interneta stvari, posebno ako nema ograničenja napajanja.
Eksperiment koji je upoređivao mogućnosti AMQP i MQTT na mobilnoj ili nestabilnoj bežičnoj mreži za testiranje otkrio je da AMQP nudi više sigurnosnih mogućnosti dok je MQTT energetski efikasniji.
Sigurnost
Sigurnost je još jedno kritično pitanje koje se postavlja prilikom proučavanja teme interneta stvari i magle/cloud computinga. Sigurnosni mehanizam se obično zasniva 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 počinju procesom uspostavljanja komunikacije između klijentske i serverske strane radi razmjene podržanih paketa šifriranja i ključeva. Obje strane dogovaraju skupove kako bi osigurali da se daljnja komunikacija odvija na sigurnom kanalu. Razlika između njih dvoje leži u malim modifikacijama koje omogućavaju DTLS-u zasnovanom na UDP-u da radi preko nepouzdane veze.
u Nekoliko različitih implementacija TLS-a i DTLS-a otkrilo je da je TLS učinio bolji posao. Napadi na DTLS su bili uspješniji zbog njegove tolerancije na greške.
Međutim, najveći problem s ovim protokolima je to što oni nisu izvorno dizajnirani za korištenje u IoT-u i nisu bili namijenjeni za rad u magli ili oblaku. Putem rukovanja, oni dodaju dodatni promet pri svakom uspostavljanju veze, što iscrpljuje računarske resurse. U prosjeku, postoji povećanje od 6,5% za TLS i 11% za DTLS u režiji u poređenju sa komunikacijama bez sigurnosnog sloja. U okruženjima bogatim resursima, koja se obično nalaze na nivou, to neće biti problem, ali u vezi između IoT-a i nivoa magle, ovo postaje važno ograničenje.
Šta odabrati? Nema jasnog odgovora. Čini se da su MQTT i HTTP protokoli koji najviše obećavaju jer se smatraju relativno zrelijim i stabilnijim IoT rješenjima u odnosu na druge protokole.
Rješenja zasnovana na objedinjenom komunikacijskom protokolu
Praksa rješenja sa jednim protokolom ima mnoge nedostatke. Na primjer, protokol koji odgovara ograničenom okruženju možda neće raditi u domeni koja ima stroge sigurnosne zahtjeve. Imajući ovo na umu, ostaje nam da odbacimo gotovo sva moguća rješenja sa jednim protokolom u ekosistemu Fog-to-Cloud u IoT-u, osim MQTT i REST HTTP-a.
REST HTTP kao jednoprotokolsko rješenje
Postoji dobar primjer kako REST HTTP zahtjevi i odgovori komuniciraju u IoT-to-Fog prostoru: . Životinje su opremljene nosivim senzorima (IoT klijent, C) i kontrolisane su putem računarstva u oblaku pomoću sistema pametne farme (Fog server, S).
Zaglavlje metode POST specificira resurs za modifikaciju (/farm/animals), kao i HTTP verziju i tip sadržaja, koji je u ovom slučaju JSON objekat koji predstavlja farmu životinja kojom sistem treba da upravlja (Dulcinea/krava) . Odgovor servera pokazuje da je zahtjev bio uspješan slanjem HTTPS statusnog koda 201 (resurs kreiran). Metoda GET mora specificirati samo traženi resurs u URI-ju (na primjer, /farm/animals/1), koji vraća JSON prikaz životinje sa tim ID-om sa servera.
Metoda PUT se koristi kada je potrebno ažurirati neki specifični zapis resursa. U ovom slučaju, resurs specificira URI za parametar koji treba promijeniti i trenutnu vrijednost (na primjer, označavajući da krava trenutno hoda, /farm/animals/1? state=walking). Konačno, metoda DELETE se koristi jednako kao i GET metoda, ali jednostavno briše resurs kao rezultat operacije.
MQTT kao jednoprotokolsko rješenje
Uzmimo istu pametnu farmu, ali umjesto REST HTTP-a koristimo MQTT protokol. Lokalni server s instaliranom bibliotekom Mosquitto djeluje kao posrednik. U ovom primjeru, jednostavan računar (koji se naziva farmski server) Raspberry Pi služi kao MQTT klijent, implementiran kroz instalaciju Paho MQTT biblioteke, koja je u potpunosti kompatibilna sa Mosquitto brokerom.
Ovaj klijent odgovara sloju IoT apstrakcije koji predstavlja uređaj sa senzorskim i računarskim sposobnostima. Posrednik, s druge strane, odgovara višem nivou apstrakcije, predstavljajući magloviti računarski čvor koji karakteriše veći kapacitet obrade i skladištenja.
U predloženom scenariju pametne farme, Raspberry Pi se povezuje sa akcelerometrom, GPS-om i senzorima temperature i objavljuje podatke sa ovih senzora u čvor za maglu. Kao što verovatno znate, MQTT tretira teme kao hijerarhiju. Jedan MQTT izdavač može objavljivati poruke na određeni skup tema. U našem slučaju ih ima tri. Za senzor koji mjeri temperaturu u štali za životinje, klijent bira temu (životinjska farma/šupa/temperatura). Za senzore koji mjere GPS lokaciju i kretanje životinja kroz akcelerometar, klijent će objaviti ažuriranja za (animalfarm/animal/GPS) i (animalfarm/animal/movement).
Ove informacije će biti proslijeđene brokeru, koji ih može privremeno pohraniti u lokalnu bazu podataka u slučaju da se kasnije pojavi neki drugi zainteresirani pretplatnik.
Pored lokalnog servera, koji u magli djeluje kao MQTT broker i kojem Raspberry Pis, koji djeluje kao MQTT klijent, šalje podatke senzora, može postojati još jedan MQTT broker na nivou oblaka. U tom slučaju, informacije koje se prenose lokalnom brokeru mogu se privremeno pohraniti u lokalnu bazu podataka i/ili poslati u oblak. Fog MQTT broker u ovoj situaciji se koristi za povezivanje svih podataka sa cloud MQTT brokerom. Sa ovom arhitekturom, korisnik mobilne aplikacije može biti pretplaćen na oba brokera.
Ako veza s jednim od brokera (na primjer, oblak) ne uspije, krajnji korisnik će dobiti informacije od drugog (magla). Ovo je karakteristična karakteristika kombinovanih sistema magle i računarstva u oblaku. Prema zadanim postavkama, mobilna aplikacija se može konfigurirati tako 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 je samo jedno od mnogih u IoT-F2C sistemima.
Višeprotokolna rješenja
Jednoprotokolna rješenja su popularna zbog lakše implementacije. Ali jasno je da u IoT-F2C sistemima ima smisla kombinovati različite protokole. Ideja je da različiti protokoli mogu raditi na različitim nivoima. Uzmimo, na primjer, tri apstrakcije: slojeve IoT-a, maglu i računalstvo u oblaku. Uređaji na nivou IoT općenito se smatraju ograničenim. Za ovaj pregled, uzmimo u obzir IoT nivoe kao najviše ograničene, oblake najmanje ograničene, a računanje magle kao "negdje u sredini". Ispostavilo se da između IoT-a i apstrakcija magle, trenutna rješenja protokola uključuju MQTT, CoAP i XMPP. Između magle i oblaka, s druge strane, AMQP je jedan od glavnih protokola koji se koristi, uz REST HTTP, koji se zbog svoje fleksibilnosti također koristi između slojeva IoT-a i magle.
Glavni problem ovdje je interoperabilnost protokola i lakoća prijenosa poruka s jednog protokola na drugi. U idealnom slučaju, u budućnosti, arhitektura sistema Interneta stvari sa resursima oblaka i magle biće nezavisna od korišćenog komunikacionog protokola i obezbediće dobru interoperabilnost između različitih protokola.
Pošto to trenutno nije slučaj, ima smisla kombinovati protokole koji nemaju bitne razlike. U tu svrhu, jedno potencijalno rješenje je bazirano na kombinaciji dva protokola koji prate isti arhitektonski stil, REST HTTP i CoAP. Drugo predloženo rješenje je bazirano na kombinaciji dva 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) čini ove kombinacije lakšima za implementaciju i zahtijeva manje napora za integraciju.
Slika (a) prikazuje dva modela zasnovana na zahtjevu i odgovoru, HTTP i CoAP, i njihovo moguće postavljanje u IoT-F2C rješenje. Budući da je HTTP jedan od najpoznatijih i najprihvaćenijih protokola na modernim mrežama, malo je vjerovatno 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 magle i IoT-a, efikasnije je koristiti CoAP. Jedna od velikih prednosti CoAP-a je zapravo njegova kompatibilnost sa HTTP-om, budući da su oba protokola zasnovana 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 hipotetički mogla koristiti za komunikaciju između čvorova na svakom sloju apstrakcije, njihov položaj treba odrediti na osnovu performansi. MQTT je dizajniran kao lagani protokol za uređaje s ograničenim računskim resursima, tako da se može koristiti za IoT-Fog komunikaciju. AMQP je pogodniji za moćnije uređaje, koji bi ga idealno pozicionirali između čvorova magle i oblaka. Umjesto MQTT, XMPP protokol se može koristiti u IoT-u jer se smatra laganim. Ali nije tako široko korišten u takvim scenarijima.
nalazi
Malo je vjerovatno da će jedan od razmatranih protokola biti dovoljan da pokrije sve komunikacije u sistemu, od uređaja sa ograničenim računarskim resursima do servera u oblaku. Studija je pokazala da su dvije najperspektivnije opcije koje programeri najviše koriste MQTT i RESTful HTTP. Ova dva protokola nisu samo najzreliji i najstabilniji, već uključuju i mnoge dobro dokumentovane i uspješne implementacije i online resurse.
Zbog svoje stabilnosti i jednostavne konfiguracije, MQTT je protokol koji je dokazao svoje superiorne performanse tokom vremena kada se koristi na nivou IoT-a sa ograničenim uređajima. U dijelovima sistema gdje ograničena komunikacija i potrošnja baterije nisu problem, kao što su neki domeni magle i većina računalstva u oblaku, RESTful HTTP je lak izbor. CoAP također treba uzeti u obzir jer se također brzo razvija kao IoT standard za razmjenu poruka i vjerovatno je da će dostići nivo stabilnosti i zrelosti sličan MQTT i HTTP u bliskoj budućnosti. Ali standard se trenutno razvija, što dolazi sa kratkoročnim problemima kompatibilnosti.
Šta još možete pročitati na blogu?
→
→
→
→
→
Pretplatite se na naše -kanal, da ne propustite sljedeći članak! Pišemo ne više od dva puta sedmično i samo poslovno.
izvor: www.habr.com