Razvoj tehnologij na področju programske in strojne opreme, pojav novih komunikacijskih protokolov so privedli do širitve interneta stvari (IoT). Število naprav narašča iz dneva v dan in generirajo ogromno podatkov. Zato obstaja potreba po priročni sistemski arhitekturi, ki je sposobna obdelave, shranjevanja in prenosa teh podatkov.
Zdaj se za te namene uporabljajo storitve v oblaku. Vse bolj priljubljena paradigma računalništva v megli (Fog) pa lahko dopolni rešitve v oblaku s skaliranjem in optimizacijo infrastrukture IoT.
Oblaki so sposobni pokriti večino IoT zahtev. Na primer zagotoviti spremljanje storitev, hitro obdelavo poljubne količine podatkov, ki jih ustvarijo naprave, kot tudi njihovo vizualizacijo. Računalništvo v megli je učinkovitejše pri reševanju problemov v realnem času. Zagotavljajo hiter odziv na zahteve in minimalno zakasnitev pri obdelavi podatkov. To pomeni, da Fog dopolnjuje "oblake" in širi njihove zmogljivosti.
Vendar je glavno vprašanje drugačno: kako naj bi vse to delovalo v kontekstu IoT? Kateri komunikacijski protokoli bodo najučinkovitejši pri delu v kombiniranem sistemu IoT-Fog-Cloud?
Kljub navidezni prevladi HTTP obstaja veliko drugih rešitev, ki se uporabljajo v sistemih IoT, Fog in Cloud. To je zato, ker mora internet stvari združevati funkcionalnost različnih senzorjev naprav z varnostjo, združljivostjo in drugimi zahtevami uporabnikov.
Enotne ideje o referenčni arhitekturi in komunikacijskem standardu preprosto ni. Zato je ustvarjanje novega protokola ali spreminjanje obstoječega za posebne naloge interneta stvari ena najpomembnejših nalog, s katerimi se sooča skupnost IT.
Kateri protokoli so trenutno v uporabi in kaj lahko ponudijo? Ugotovimo. Toda najprej se pogovorimo o načelih ekosistema, v katerem oblaki, megla in internet stvari sodelujejo.
Arhitektura IoT Fog-to-Cloud (F2C).
Verjetno ste opazili, koliko truda je vloženega v raziskovanje prednosti in koristi, povezanih s pametnim in usklajenim upravljanjem IoT, oblaka in megle. Če ne, so tukaj tri pobude za standardizacijo: , и .
Če sta bili prej upoštevani samo 2 ravni, oblaki in končne naprave, potem predlagana arhitektura uvaja novo raven - računalništvo v megli. V tem primeru lahko stopnjo megle razdelimo na več podravni, odvisno od posebnosti virov ali nabora politik, ki določajo uporabo različnih naprav v teh podnivojih.
Kako bi lahko izgledala ta abstrakcija? Tukaj je tipičen ekosistem IoT-Fog-Cloud. Naprave IoT pošiljajo podatke hitrejšim strežnikom in računalniškim napravam za reševanje težav, ki zahtevajo nizko zakasnitev. V istem sistemu so oblaki odgovorni za reševanje problemov, ki zahtevajo veliko količino računalniških virov ali prostora za shranjevanje podatkov.
Pametni telefoni, pametne ure in drugi pripomočki so prav tako lahko del interneta stvari. Toda takšne naprave praviloma uporabljajo lastniške komunikacijske protokole velikih razvijalcev. Ustvarjeni IoT podatki se prenesejo v sloj megle prek protokola REST HTTP, ki zagotavlja prilagodljivost in interoperabilnost pri ustvarjanju storitev RESTful. To je pomembno zaradi potrebe po zagotavljanju združljivosti za nazaj z obstoječo računalniško infrastrukturo, ki se izvaja na lokalnih računalnikih, strežnikih ali gruči strežnikov. Lokalni viri, imenovani »vozlišča megle«, filtrirajo prejete podatke in jih lokalno obdelajo ali pošljejo v oblak za nadaljnje izračune.
Oblaki podpirajo različne komunikacijske protokole, najpogostejša sta AMQP in REST HTTP. Ker je HTTP dobro znan in prilagojen za internet, se lahko pojavi vprašanje: "ali ga ne bi morali uporabiti za delo z IoT in meglo?" Vendar ima ta protokol težave z zmogljivostjo. Več o tem pozneje.
Na splošno obstajata 2 modela komunikacijskih protokolov, primernih za sistem, ki ga potrebujemo. To sta zahteva-odziv in objava-naročnina. Prvi model je širše poznan predvsem v arhitekturi strežnik-odjemalec. Odjemalec zahteva informacije od strežnika, strežnik pa zahtevo prejme, obdela in vrne odgovor. Protokola REST HTTP in CoAP delujeta na tem modelu.
Drugi model je nastal zaradi potrebe po zagotavljanju asinhrone, porazdeljene, ohlapne povezave med viri, ki generirajo podatke, in prejemniki teh podatkov.
Model predvideva tri udeležence: založnika (vir podatkov), posrednika (dispečerja) in naročnika (prejemnika). Tukaj odjemalcu, ki deluje kot naročnik, ni treba zahtevati informacij od strežnika. Namesto pošiljanja zahtev se na določene dogodke v sistemu naroči prek posrednika, ki je odgovoren za filtriranje vseh dohodnih sporočil in njihovo usmerjanje med založniki in naročniki. In založnik, ko pride do dogodka v zvezi z določeno temo, to objavi posredniku, ki podatke o zahtevani temi pošlje naročniku.
V bistvu ta arhitektura temelji na dogodkih. In ta interakcijski model je zanimiv za aplikacije v IoT, oblaku, megli zaradi svoje zmožnosti zagotavljanja razširljivosti in poenostavljanja medsebojnega povezovanja med različnimi napravami, podpira dinamično komunikacijo mnogo proti mnogo in asinhrono komunikacijo. Nekateri najbolj znani standardizirani protokoli za sporočanje, ki uporabljajo model objave in naročnine, vključujejo MQTT, AMQP in DDS.
Očitno ima model objave in naročnine veliko prednosti:
- Založnikom in naročnikom ni treba vedeti za obstoj drug drugega;
- En naročnik lahko prejema informacije iz več različnih publikacij, en založnik pa lahko pošilja podatke več različnim naročnikom (načelo mnogo proti mnogo);
- Založniku in naročniku ni treba biti aktiven hkrati za komunikacijo, saj bo posrednik (deluje kot čakalni sistem) lahko shranil sporočilo za odjemalce, ki trenutno niso povezani v omrežje.
Vendar ima model zahteva-odgovor tudi svoje prednosti. V primerih, ko zmožnost strežniške strani, da obravnava več zahtev odjemalcev, ni problem, je smiselno uporabiti preverjene, zanesljive rešitve.
Obstajajo tudi protokoli, ki podpirajo oba modela. Na primer XMPP in HTTP 2.0, ki podpirata možnost »server push«. IETF je izdal tudi CoAP. V poskusu rešitve problema sporočanja je bilo ustvarjenih več drugih rešitev, kot je protokol WebSockets ali uporaba protokola HTTP prek QUIC (Hitre internetne povezave UDP).
V primeru WebSockets, čeprav se uporablja za prenos podatkov v realnem času s strežnika na spletni odjemalec in zagotavlja trajne povezave s hkratno dvosmerno komunikacijo, ni namenjen napravam z omejenimi računalniškimi viri. Pozornost si zasluži tudi QUIC, saj novi transportni protokol ponuja veliko novih priložnosti. A ker QUIC še ni standardiziran, je prezgodaj napovedovati njegovo možno uporabo in vpliv na rešitve IoT. Zato imamo v mislih WebSockets in QUIC s pogledom na prihodnost, vendar je za zdaj ne bomo podrobneje preučevali.
Kdo je najbolj srčkan na svetu: primerjava protokolov
Zdaj pa se pogovorimo o prednostih in slabostih protokolov. Če pogledamo naprej, takoj rezervirajmo, da ni nobenega jasnega vodje. Vsak protokol ima nekaj prednosti/slabosti.
Odzivni čas
Ena najpomembnejših lastnosti komunikacijskih protokolov, zlasti v zvezi z internetom stvari, je odzivni čas. Toda med obstoječimi protokoli ni jasnega zmagovalca, ki bi pokazal minimalno stopnjo zakasnitve pri delu v različnih pogojih. Je pa cel kup raziskav in primerjav zmožnosti protokola.
Na primer, Primerjave učinkovitosti HTTP in MQTT pri delu z IoT so pokazale, da je odzivni čas za zahteve za MQTT krajši kot za HTTP. In kdaj Čas povratnega potovanja (RTT) MQTT in CoAP je razkril, da je povprečni RTT CoAP 20 % manjši od tistega MQTT.
Drugo z RTT za protokola MQTT in CoAP je potekalo v dveh scenarijih: lokalno omrežje in omrežje IoT. Izkazalo se je, da je povprečni RTT 2-3-krat višji v omrežju IoT. MQTT s QoS0 je pokazal nižji rezultat v primerjavi s CoAP, MQTT s QoS1 pa je pokazal višji RTT zaradi ACK-ov na aplikacijski in transportni plasti. Za različne ravni QoS je bila omrežna zakasnitev brez zastojev milisekunde za MQTT in stotine mikrosekund za CoAP. Vendar si velja zapomniti, da bo pri delu v manj zanesljivih omrežjih MQTT, ki deluje na vrhu TCP, pokazal popolnoma drugačen rezultat.
odzivni čas za protokola AMQP in MQTT s povečanjem obremenitve je pokazal, da je pri majhni obremenitvi raven zakasnitve skoraj enaka. Toda pri prenosu velikih količin podatkov MQTT izkazuje krajše odzivne čase. še v enem CoAP so primerjali s HTTP v komunikacijskem scenariju stroj-stroj z napravami, nameščenimi na vrhu vozil, opremljenih s senzorji za plin, vremenskimi senzorji, lokacijskimi senzorji (GPS) in mobilnim omrežnim vmesnikom (GPRS). Čas, potreben za prenos sporočila CoAP prek mobilnega omrežja, je bil skoraj trikrat krajši od časa, potrebnega za uporabo sporočil HTTP.
Izvedene so bile študije, ki niso primerjale dveh, ampak tri protokole. na primer delovanje IoT protokolov MQTT, DDS in CoAP v scenariju medicinske aplikacije z uporabo omrežnega emulatorja. DDS je presegel MQTT v smislu preizkušene zakasnitve telemetrije v različnih slabih omrežnih pogojih. CoAP, ki temelji na UDP, je dobro deloval za aplikacije, ki so zahtevale hitre odzivne čase, vendar je zaradi tega, ker je temeljil na UDP, prišlo do velike nepredvidljive izgube paketov.
Prepustnost
MQTT in CoAP v smislu učinkovitosti pasovne širine je bil izveden kot izračun skupne količine prenesenih podatkov na sporočilo. CoAP je pokazal nižjo prepustnost kot MQTT pri prenosu majhnih sporočil. Toda pri primerjavi učinkovitosti protokolov glede na razmerje med številom bajtov uporabnih informacij in skupnim številom prenesenih bajtov se je CoAP izkazal za učinkovitejšega.
Ob z uporabo MQTT, DDS (s TCP kot transportnim protokolom) in pasovne širine CoAP je bilo ugotovljeno, da je CoAP na splošno pokazal razmeroma nižjo porabo pasovne širine, ki se ni povečala s povečano izgubo paketov v omrežju ali povečano zakasnitvijo omrežja, za razliko od MQTT in DDS, kjer je bilo povečanje izkoriščenosti pasovne širine v omenjenih scenarijih. Drugi scenarij je vključeval veliko število naprav, ki hkrati prenašajo podatke, kar je značilno za okolja IoT. Rezultati so pokazali, da je za večjo izkoriščenost bolje uporabiti CoAP.
Pri majhni obremenitvi je CoAP uporabil najmanjšo pasovno širino, sledita mu MQTT in REST HTTP. Ko pa se je velikost uporabnih obremenitev povečala, je imel REST HTTP najboljše rezultate.
Poraba energije
Vprašanje porabe energije je vedno zelo pomembno, še posebej v sistemu IoT. če Medtem ko MQTT in HTTP porabita elektriko, HTTP porabi veliko več. In CoAP je več v primerjavi z MQTT omogoča upravljanje porabe energije. Vendar pa je v preprostih scenarijih MQTT primernejši za izmenjavo informacij v omrežjih interneta stvari, zlasti če ni omejitev moči.
Eksperiment, ki je primerjal zmogljivosti AMQP in MQTT na preskusni napravi mobilnega ali nestabilnega brezžičnega omrežja, je pokazal, da AMQP ponuja več varnostnih zmogljivosti, medtem ko je MQTT energijsko učinkovitejši.
varnost
Varnost je še eno kritično vprašanje, ki se pojavi pri preučevanju teme interneta stvari in računalništva v megli/oblaku. Varnostni mehanizem običajno temelji na TLS v HTTP, MQTT, AMQP in XMPP ali DTLS v CoAP in podpira obe različici DDS.
TLS in DTLS se začneta s postopkom vzpostavljanja komunikacije med stranjo odjemalca in strežnika za izmenjavo podprtih šifer in ključev. Obe strani se pogajata o nizih, da zagotovita nadaljnjo komunikacijo po varnem kanalu. Razlika med obema je v majhnih spremembah, ki omogočajo DTLS, ki temelji na UDP, da deluje prek nezanesljive povezave.
Ob Več različnih izvedb TLS in DTLS je pokazalo, da je TLS opravil boljše delo. Napadi na DTLS so bili uspešnejši zaradi njegove tolerance na napake.
Vendar je največja težava teh protokolov ta, da prvotno niso bili zasnovani za uporabo v IoT in niso bili namenjeni delovanju v megli ali oblaku. Z rokovanjem z vsako vzpostavitvijo povezave dodajo dodaten promet, kar izčrpa računalniške vire. V povprečju je povečanje za 6,5 % za TLS in 11 % za DTLS v režijskih stroških v primerjavi s komunikacijo brez varnostne plasti. V okoljih, bogatih z viri, ki se običajno nahajajo na ravni, to ne bo problem, vendar v povezavi med internetom stvari in stopnjo megle to postane pomembna omejitev.
Kaj izbrati? Jasnega odgovora ni. Zdi se, da sta MQTT in HTTP najbolj obetavna protokola, saj veljata za sorazmerno zrelejši in stabilnejši rešitvi IoT v primerjavi z drugimi protokoli.
Rešitve, ki temeljijo na poenotenem komunikacijskem protokolu
Praksa rešitve z enim protokolom ima številne pomanjkljivosti. Na primer, protokol, ki ustreza omejenemu okolju, morda ne bo deloval v domeni, ki ima stroge varnostne zahteve. S tem v mislih moramo zavrniti skoraj vse možne enoprotokolne rešitve v ekosistemu Fog-to-Cloud v IoT, razen MQTT in REST HTTP.
REST HTTP kot rešitev z enim protokolom
Obstaja dober primer, kako zahteve in odgovori REST HTTP medsebojno delujejo v prostoru IoT-to-Fog: . Živali so opremljene z nosljivimi senzorji (odjemalec IoT, C) in nadzorovane prek računalništva v oblaku s sistemom pametnega kmetovanja (strežnik Fog, S).
Glava metode POST določa vir za spreminjanje (/farm/animals) ter različico HTTP in vrsto vsebine, ki je v tem primeru predmet JSON, ki predstavlja živalsko farmo, ki naj bi jo sistem upravljal (Dulcinea/krava) . Odgovor strežnika nakazuje, da je bila zahteva uspešna s pošiljanjem statusne kode HTTPS 201 (vir ustvarjen). Metoda GET mora podati samo zahtevani vir v URI (na primer /farm/animals/1), ki s strežnika vrne predstavitev živali v JSON s tem ID-jem.
Metoda PUT se uporablja, ko je treba posodobiti določen zapis vira. V tem primeru vir podaja URI za parameter, ki ga je treba spremeniti, in trenutno vrednost (na primer, ki označuje, da krava trenutno hodi, /farm/animals/1? state=walking). Končno se metoda DELETE uporablja enako kot metoda GET, vendar preprosto izbriše vir kot rezultat operacije.
MQTT kot rešitev z enim protokolom
Vzemimo isto pametno farmo, vendar namesto REST HTTP uporabljamo protokol MQTT. Lokalni strežnik z nameščeno knjižnico Mosquitto deluje kot posrednik. V tem primeru preprost računalnik (imenovan kmetijski strežnik) Raspberry Pi služi kot odjemalec MQTT, implementiran z namestitvijo knjižnice Paho MQTT, ki je popolnoma združljiva s posrednikom Mosquitto.
Ta odjemalec ustreza sloju abstrakcije IoT, ki predstavlja napravo z zaznavanjem in računalniškimi zmogljivostmi. Po drugi strani pa posrednik ustreza višji ravni abstrakcije, ki predstavlja računalniško vozlišče megle, za katero je značilna večja zmogljivost obdelave in shranjevanja.
V predlaganem scenariju pametne kmetije se Raspberry Pi poveže z merilnikom pospeška, GPS in temperaturnimi senzorji ter objavi podatke iz teh senzorjev v vozlišču za meglo. Kot verjetno veste, MQTT obravnava teme kot hierarhijo. Posamezen založnik MQTT lahko objavi sporočila za določen nabor tem. V našem primeru so trije. Za senzor, ki meri temperaturo v hlevu za živali, naročnik izbere temo (živalska farma/lopa/temperatura). Za senzorje, ki merijo lokacijo GPS in gibanje živali prek merilnika pospeška, bo stranka objavila posodobitve za (živalska farma/žival/GPS) in (živalska farma/žival/gibanje).
Ti podatki bodo posredovani posredniku, ki jih lahko začasno shrani v lokalno bazo podatkov, če se kasneje pojavi še kakšen zainteresirani naročnik.
Poleg lokalnega strežnika, ki deluje kot posrednik MQTT v megli in na katerega Raspberry Pis, ki deluje kot odjemalec MQTT, pošilja senzorske podatke, je lahko na ravni oblaka še kakšen posrednik MQTT. V tem primeru se lahko informacije, posredovane lokalnemu posredniku, začasno shranijo v lokalno bazo podatkov in/ali pošljejo v oblak. Posrednik MQTT za meglo se v tej situaciji uporablja za povezovanje vseh podatkov s posrednikom MQTT v oblaku. S to arhitekturo je lahko uporabnik mobilne aplikacije naročen na oba posrednika.
Če povezava z enim od posrednikov (na primer oblak) ne uspe, bo končni uporabnik prejel informacije od drugega (megla). To je značilna lastnost kombiniranih računalniških sistemov megle in oblaka. Privzeto je mogoče mobilno aplikacijo konfigurirati tako, da se najprej poveže s posrednikom MQTT za meglo, in če to ne uspe, da se poveže s posrednikom MQTT v oblaku. Ta rešitev je le ena od mnogih v sistemih IoT-F2C.
Večprotokolne rešitve
Enoprotokolne rešitve so priljubljene zaradi lažje implementacije. Jasno pa je, da je v sistemih IoT-F2C smiselno kombinirati različne protokole. Ideja je, da lahko različni protokoli delujejo na različnih ravneh. Vzemimo za primer tri abstrakcije: plasti interneta stvari, meglo in računalništvo v oblaku. Naprave na ravni IoT na splošno veljajo za omejene. Za ta pregled upoštevajmo stopnje IoT kot najbolj omejene, oblak najmanj omejene in računalništvo v megli kot "nekje na sredini". Izkazalo se je, da med IoT in abstrakcijami megle trenutne rešitve protokolov vključujejo MQTT, CoAP in XMPP. Med meglo in oblakom je na drugi strani AMQP eden glavnih uporabljenih protokolov, skupaj z REST HTTP, ki se zaradi svoje prilagodljivosti uporablja tudi med IoT in sloji megle.
Glavna težava pri tem je interoperabilnost protokolov in enostavnost prenosa sporočil iz enega protokola v drugega. V idealnem primeru bo v prihodnosti arhitektura sistema interneta stvari z viri v oblaku in megli neodvisna od uporabljenega komunikacijskega protokola in bo zagotavljala dobro interoperabilnost med različnimi protokoli.
Ker trenutno ni tako, je smiselno kombinirati protokole, ki nimajo bistvenih razlik. V ta namen ena možna rešitev temelji na kombinaciji dveh protokolov, ki sledita istemu arhitekturnemu slogu, REST HTTP in CoAP. Druga predlagana rešitev temelji na kombinaciji dveh protokolov, ki ponujata komunikacijo objava-naročnina, MQTT in AMQP. Uporaba podobnih konceptov (MQTT in AMQP uporabljata posrednike, CoAP in HTTP uporabljata REST) olajša implementacijo teh kombinacij in zahteva manj truda pri integraciji.
Slika (a) prikazuje dva modela, ki temeljita na zahtevi in odgovoru, HTTP in CoAP, ter njuno možno umestitev v rešitev IoT-F2C. Ker je HTTP eden najbolj znanih in sprejetih protokolov v sodobnih omrežjih, je malo verjetno, da ga bodo v celoti nadomestili drugi protokoli za sporočanje. Med vozlišči, ki predstavljajo zmogljive naprave, ki ležijo med oblakom in meglo, je REST HTTP pametna rešitev.
Po drugi strani pa je za naprave z omejenimi računalniškimi viri, ki komunicirajo med slojema Fog in IoT, bolj učinkovito uporabljati CoAP. Ena od velikih prednosti CoAP je pravzaprav njegova združljivost s HTTP, saj oba protokola temeljita na principih REST.
Slika (b) prikazuje dva komunikacijska modela objave in naročnine v istem scenariju, vključno z MQTT in AMQP. Čeprav bi lahko oba protokola hipotetično uporabili za komunikacijo med vozlišči na vsaki abstraktni plasti, je treba njun položaj določiti na podlagi zmogljivosti. MQTT je bil zasnovan kot lahek protokol za naprave z omejenimi računalniškimi viri, zato ga je mogoče uporabiti za komunikacijo IoT-Fog. AMQP je bolj primeren za zmogljivejše naprave, ki bi ga idealno postavile med vozlišča megle in oblaka. Namesto MQTT se lahko v IoT uporablja protokol XMPP, saj velja za lahkega. Vendar se v takšnih scenarijih ne uporablja tako pogosto.
Ugotovitve
Malo verjetno je, da bo eden od obravnavanih protokolov zadostoval za pokrivanje vseh komunikacij v sistemu, od naprav z omejenimi računalniškimi viri do strežnikov v oblaku. Študija je pokazala, da sta dve najbolj obetavni možnosti, ki ju razvijalci največ uporabljajo, MQTT in RESTful HTTP. Ta dva protokola nista samo najbolj zrela in stabilna, ampak vključujeta tudi številne dobro dokumentirane in uspešne izvedbe ter spletne vire.
Zaradi svoje stabilnosti in enostavne konfiguracije je MQTT protokol, ki je s časom dokazal svojo vrhunsko zmogljivost pri uporabi na ravni IoT z omejenimi napravami. V delih sistema, kjer omejena komunikacija in poraba baterije nista problem, kot so nekatere domene megle in večina računalništva v oblaku, je RESTful HTTP preprosta izbira. Upoštevati je treba tudi CoAP, saj se hitro razvija tudi kot standard sporočanja IoT in je verjetno, da bo v bližnji prihodnosti dosegel raven stabilnosti in zrelosti, podobno MQTT in HTTP. Toda standard se trenutno razvija, kar prinaša kratkoročne težave z združljivostjo.
Kaj še lahko preberete na blogu?
→
→
→
→
→
Naročite se na našo -kanal, da ne zamudite naslednjega članka! Pišemo največ dvakrat na teden in samo poslovno.
Vir: www.habr.com