Tehnoloogiate areng tarkvara ja riistvara vallas, uute sideprotokollide tekkimine on viinud asjade interneti (IoT) laienemiseni. Seadmete arv kasvab iga päevaga ja need genereerivad tohutul hulgal andmeid. Seetõttu on vajadus mugava süsteemiarhitektuuri järele, mis oleks võimeline neid andmeid töötlema, salvestama ja edastama.
Nüüd kasutatakse nendel eesmärkidel pilveteenuseid. Üha populaarsemaks muutuv uduarvutusparadigma (udu) võib aga pilvelahendusi täiendada asjade interneti infrastruktuuri skaleerimise ja optimeerimisega.
Pilved on võimelised katma enamiku asjade Interneti päringuid. Näiteks teenuste jälgimise, seadmete poolt genereeritud igasuguse andmemahu kiire töötlemise, aga ka nende visualiseerimise pakkumiseks. Uduarvutus on efektiivsem reaalajas probleemide lahendamisel. Need tagavad kiire reageerimise päringutele ja minimaalse andmetöötluse latentsuse. See tähendab, et udu täiendab "pilvi" ja laiendab selle võimalusi.
Põhiküsimus on aga teistsugune: kuidas see kõik peaks asjade Interneti kontekstis suhtlema? Millised sideprotokollid on kombineeritud IoT-Fog-Cloud süsteemis töötamisel kõige tõhusamad?
Vaatamata HTTP näilisele domineerimisele, kasutatakse asjade Interneti-, udu- ja pilvesüsteemides palju muid lahendusi. Seda seetõttu, et asjade internet peab ühendama erinevate seadmeandurite funktsionaalsuse kasutajate turvalisuse, ühilduvuse ja muude nõuetega.
Kuid võrdlusarhitektuuri ja kommunikatsioonistandardi kohta pole lihtsalt ühtset ideed. Seetõttu on konkreetsete asjade Interneti-ülesannete jaoks uue protokolli loomine või olemasoleva muutmine IT-kogukonna üks olulisemaid ülesandeid.
Millised protokollid on praegu kasutusel ja mida need pakuvad? Selgitame välja. Kuid kõigepealt arutleme selle ökosüsteemi põhimõtete üle, milles pilved, udu ja asjade internet suhtlevad.
IoT udust pilveni (F2C) arhitektuur
Tõenäoliselt olete märganud, kui palju vaeva nähakse asjade Interneti, pilve ja udu nutika ja koordineeritud haldamisega seotud eeliste ja eeliste uurimisel. Kui ei, siis siin on kolm standardimisalgatust: , и .
Kui varem arvestati ainult 2 taset, pilved ja lõppseadmed, siis pakutud arhitektuur tutvustab uut taset - uduarvutus. Sel juhul saab udutaseme jagada mitmeks alamtasemeks, olenevalt ressursside spetsiifikast või poliitikate komplektist, mis määravad erinevate seadmete kasutamise nendel alamtasanditel.
Kuidas see abstraktsioon välja näha võiks? Siin on tüüpiline IoT-Fog-Cloud ökosüsteem. IoT-seadmed saadavad andmeid kiirematesse serveritesse ja arvutusseadmetesse, et lahendada probleeme, mis nõuavad madalat latentsust. Samas süsteemis vastutavad pilved selliste probleemide lahendamise eest, mis nõuavad suurt hulka arvutusressursse või andmesalvestusruumi.
Nutitelefonid, nutikellad ja muud vidinad võivad samuti olla osa asjade Internetist. Kuid sellised seadmed kasutavad reeglina suurte arendajate patenteeritud sideprotokolle. Loodud IoT-andmed kantakse udukihti REST HTTP protokolli kaudu, mis pakub paindlikkust ja koostalitlusvõimet RESTfuli teenuste loomisel. See on oluline, pidades silmas vajadust tagada tagasiühilduvus olemasoleva arvutitaristuga, mis töötab kohalikes arvutites, serverites või serveriklastris. Kohalikud ressursid, mida nimetatakse udusõlmedeks, filtreerivad saadud andmeid ja töötlevad neid kohapeal või saadavad pilve edasiste arvutuste tegemiseks.
Pilved toetavad erinevaid sideprotokolle, millest levinumad on AMQP ja REST HTTP. Kuna HTTP on hästi tuntud ja Interneti jaoks kohandatud, võib tekkida küsimus: "Kas me ei peaks seda kasutama asjade Interneti ja uduga töötamiseks?" Sellel protokollil on aga jõudlusprobleeme. Sellest lähemalt hiljem.
Üldiselt on meile vajaliku süsteemi jaoks sobivad 2 sideprotokolli mudelit. Need on päring-vastus ja avaldamine-tellimine. Esimene mudel on laiemalt tuntud, eriti server-klient arhitektuuris. Klient küsib serverilt teavet ja server võtab päringu vastu, töötleb selle ja tagastab vastuse. Sellel mudelil töötavad protokollid REST HTTP ja CoAP.
Teine mudel tekkis vajadusest tagada asünkroonne, hajutatud, lahtine side andmeid genereerivate allikate ja nende andmete saajate vahel.
Mudel eeldab kolme osalejat: väljaandja (andmeallikas), maakler (dispetšer) ja tellija (vastuvõtja). Siin ei pea tellijana tegutsev klient serverilt teavet küsima. Päringute saatmise asemel tellib see teatud sündmuste süsteemis maakleri kaudu, kes vastutab kõigi sissetulevate sõnumite filtreerimise ja nende väljaandjate ja tellijate vahel marsruutimise eest. Ja väljaandja, kui teatud teemaga seotud sündmus toimub, avaldab selle maaklerile, kes saadab tellijale andmed soovitud teema kohta.
Põhimõtteliselt on see arhitektuur sündmustepõhine. Ja see interaktsioonimudel on huvitav asjade Interneti-, pilve- ja udurakenduste jaoks, kuna see suudab pakkuda skaleeritavust ja lihtsustada erinevate seadmete vahelist ühendust, toetada dünaamilist palju-mitmele suhtlust ja asünkroonset suhtlust. Mõned kõige tuntumad standardiseeritud sõnumsideprotokollid, mis kasutavad avaldamise ja tellimise mudelit, on MQTT, AMQP ja DDS.
Ilmselt on avaldamise-tellimise mudelil palju eeliseid:
- Kirjastajad ja tellijad ei pea üksteise olemasolust teadma;
- Üks tellija võib saada teavet paljudest erinevatest väljaannetest ja üks väljaandja võib saata andmeid paljudele erinevatele tellijatele (printsiip mitu-mitmele);
- Väljaandja ja tellija ei pea suhtlemiseks samal ajal aktiivsed olema, sest maakler (töötab järjekorrasüsteemina) saab sõnumi salvestada klientidele, kes pole hetkel võrguga ühendatud.
Päringu-vastuse mudelil on aga ka oma tugevad küljed. Juhtudel, kui serveripoolne suutlikkus käsitleda mitut kliendipäringut ei ole probleem, on mõttekas kasutada tõestatud ja usaldusväärseid lahendusi.
Samuti on mõlemat mudelit toetavad protokollid. Näiteks XMPP ja HTTP 2.0, mis toetavad suvandit "server push". IETF on välja andnud ka CoAP-i. Sõnumiprobleemi lahendamiseks on loodud mitmeid muid lahendusi, näiteks WebSocketsi protokoll või HTTP-protokolli kasutamine QUIC-i kaudu (Quick UDP Internet Connections).
WebSocketsi puhul, kuigi seda kasutatakse andmete reaalajas edastamiseks serverist veebikliendile ja see tagab püsivad ühendused samaaegse kahesuunalise suhtlusega, ei ole see mõeldud piiratud arvutusressurssidega seadmetele. Tähelepanu väärib ka QUIC, kuna uus transpordiprotokoll pakub palju uusi võimalusi. Kuid kuna QUIC pole veel standarditud, on ennatlik ennustada selle võimalikku rakendamist ja mõju asjade interneti lahendustele. Seega hoiame WebSocketsi ja QUIC-i tulevikku silmas pidades silmas, kuid me ei uuri seda praegu üksikasjalikumalt.
Kes on maailma kõige armsam: protokollide võrdlemine
Nüüd räägime protokollide tugevatest ja nõrkadest külgedest. Tulevikku vaadates tehkem kohe reservatsioon, et üht kindlat juhti pole. Igal protokollil on mõned eelised/miinused.
Reageerimise aeg
Sideprotokollide üks olulisemaid omadusi, eriti seoses asjade internetiga, on reageerimisaeg. Kuid olemasolevate protokollide hulgas pole selget võitjat, mis näitaks erinevatel tingimustel töötades minimaalset latentsusaega. Kuid protokollivõimaluste kohta on tehtud terve hulk uuringuid ja võrdlusi.
Näiteks HTTP ja MQTT tõhususe võrdlus IoT-ga töötamisel näitas, et MQTT taotluste reageerimisaeg on lühem kui HTTP puhul. Ja millal MQTT ja CoAP edasi-tagasi reisi aeg (RTT) näitas, et CoAP keskmine RTT on 20% väiksem kui MQTT.
Muu RTT-ga MQTT ja CoAP protokollide jaoks viidi läbi kahe stsenaariumi järgi: kohalik võrk ja IoT võrk. Selgus, et IoT võrgus on keskmine RTT 2-3 korda kõrgem. QoS0-ga MQTT näitas madalamat tulemust võrreldes CoAP-ga ja QoS1-ga MQTT näitas kõrgemat RTT-d, mis oli tingitud rakendus- ja transpordikihtide ACK-dest. Erinevate QoS-tasemete puhul oli võrgu latentsus ilma ülekoormuseta MQTT puhul millisekundeid ja CoAP-i puhul sadu mikrosekundeid. Siiski tasub meeles pidada, et vähem töökindlates võrkudes töötades näitab TCP peal töötav MQTT hoopis teistsugust tulemust.
AMQP ja MQTT protokollide reageerimisaeg kasuliku koormuse suurendamisega näitas, et väikese koormuse korral on latentsusaeg peaaegu sama. Kuid suurte andmemahtude edastamisel näitab MQTT lühemat reageerimisaega. veel ühes CoAP-i võrreldi HTTP-ga masinatevahelises sidestsenaariumis, kus seadmed olid paigaldatud sõidukite peale, mis on varustatud gaasiandurite, ilmaandurite, asukohaandurite (GPS) ja mobiilsidevõrgu liidesega (GPRS). CoAP-teate edastamiseks mobiilsidevõrgus kulus ligi kolm korda vähem aega kui HTTP-sõnumite kasutamiseks.
On tehtud uuringuid, milles võrreldi mitte kahte, vaid kolme protokolli. Näiteks, IoT-protokollide MQTT, DDS ja CoAP toimivus meditsiinilise rakenduse stsenaariumis, kasutades võrguemulaatorit. DDS ületas MQTT-d testitud telemeetria latentsusaja osas erinevates halbades võrgutingimustes. UDP-põhine CoAP toimis hästi kiiret reageerimisaega nõudvate rakenduste puhul, kuid kuna see oli UDP-põhine, tekkis märkimisväärne ettearvamatu paketikadu.
Läbilaskevõime
MQTT ja CoAP ribalaiuse tõhususe osas viidi läbi sõnumi kohta edastatud andmete kogumahu arvutamiseks. CoAP on väikeste sõnumite edastamisel näidanud väiksemat läbilaskevõimet kui MQTT. Kuid kui võrrelda protokollide tõhusust kasuliku teabe baitide arvu ja edastatud baitide koguarvu suhte osas, osutus CoAP tõhusamaks.
juures kasutades MQTT-d, DDS-i (transpordiprotokollina TCP-d) ja CoAP-i ribalaiust, leiti, et CoAP-l oli üldiselt suhteliselt väiksem ribalaiuse tarbimine, mis erinevalt MQTT-st ja DDS-ist ei suurenenud võrgupakettide kaotuse või võrgu latentsuse suurenemise korral. ribalaiuse kasutamise suurenemine nimetatud stsenaariumide korral. Teine stsenaarium hõlmas suurt hulka andmeid samaaegselt edastavaid seadmeid, mis on tüüpiline asjade Interneti keskkondades. Tulemused näitasid, et suuremaks kasutuseks on parem kasutada CoAP-i.
Kerge koormuse korral kasutas CoAP kõige vähem ribalaiust, millele järgnesid MQTT ja REST HTTP. Kui aga kasulike koormuste suurus suurenes, oli REST HTTP-l parimad tulemused.
Energiatarve
Energiatarbimise küsimus on alati väga oluline ja seda eriti asjade interneti süsteemis. Kui Kui MQTT ja HTTP tarbivad elektrit, siis HTTP tarbib palju rohkem. Ja CoAP on rohkem võrreldes MQTT-ga, võimaldades toitehaldust. Lihtsate stsenaariumide korral sobib aga MQTT pigem asjade interneti võrkudes info vahetamiseks, eriti kui toitepiiranguid pole.
Katse, milles võrreldi AMQP ja MQTT võimalusi mobiilses või ebastabiilses traadita võrgus, näitas, et AMQP pakub rohkem turvavõimalusi, samas kui MQTT on energiatõhusam.
turvalisus
Turvalisus on veel üks kriitiline probleem, mis tõstatub asjade Interneti ja udu-/pilvandmetöötluse teema uurimisel. Turvamehhanism põhineb tavaliselt HTTP-s, MQTT-l, AMQP-l ja XMPP-s TLS-il või CoAP-is DTLS-il ning toetab mõlemat DDS-i varianti.
TLS ja DTLS algavad side loomise protsessiga kliendi ja serveri poole vahel, et vahetada toetatud šifrikomplekte ja võtmeid. Mõlemad pooled peavad komplektide üle läbirääkimisi tagamaks, et edasine suhtlus toimub turvalisel kanalil. Nende kahe erinevus seisneb väikestes muudatustes, mis võimaldavad UDP-põhisel DTLS-il töötada ebausaldusväärse ühenduse kaudu.
juures Mitmed erinevad TLS-i ja DTLS-i rakendused leidsid, et TLS sai paremini hakkama. DTLS-i rünnakud olid selle veataluvuse tõttu edukamad.
Nende protokollide suurim probleem on aga see, et need ei olnud algselt mõeldud IoT-s kasutamiseks ega olnud mõeldud udus ega pilves töötamiseks. Kätlemise kaudu lisavad nad iga ühenduse loomisega täiendavat liiklust, mis kulutab arvutusressursse. Võrreldes ilma turvakihita sidega on TLS-i puhul üldkulud keskmiselt 6,5% ja DTLS-i puhul 11%. Ressursirikastes keskkondades, mis tavaliselt asuvad tasemel, ei ole see probleem, kuid asjade Interneti ja udutaseme vahelises seoses muutub see oluliseks piiranguks.
Mida valida? Selget vastust pole. MQTT ja HTTP tunduvad olevat kõige lootustandvamad protokollid, kuna neid peetakse teiste protokollidega võrreldes suhteliselt küpsemaks ja stabiilsemaks IoT-lahenduseks.
Ühtsel sideprotokollil põhinevad lahendused
Ühe protokolliga lahenduse praktikal on palju puudusi. Näiteks ei pruugi piiratud keskkonda sobiv protokoll töötada rangete turvanõuetega domeenis. Seda silmas pidades jääb meil loobuda peaaegu kõigist võimalikest üheprotokollilistest lahendustest IoT-i Fog-to-Cloud ökosüsteemis, välja arvatud MQTT ja REST HTTP.
REST HTTP ühe protokolli lahendusena
Siin on hea näide sellest, kuidas REST HTTP päringud ja vastused IoT-to-Fog ruumis suhtlevad: . Loomad on varustatud kantavate anduritega (IoT klient, C) ja neid juhitakse pilvandmetöötluse kaudu nutika põllumajandussüsteemi (Fog server, S) abil.
POST-meetodi päis määrab muudetava ressursi (/farm/animals) ning HTTP versiooni ja sisutüübi, mis antud juhul on JSON-objekt, mis esindab loomafarmi, mida süsteem haldab (Dulcinea/lehm) . Serveri vastus näitab, et taotlus oli edukas, saates HTTPS-i olekukoodi 201 (ressurss loodud). Meetod GET peab määrama URI-s ainult taotletud ressursi (nt /farm/animals/1), mis tagastab serverist selle ID-ga looma JSON-i esituse.
PUT-meetodit kasutatakse siis, kui mõnda konkreetset ressursikirjet on vaja värskendada. Sellisel juhul määrab ressurss muudetava parameetri URI ja hetkeväärtuse (näiteks näitab, et lehm parasjagu kõnnib, /farm/loomad/1? olek=kõndimine). Lõpuks kasutatakse meetodit DELETE samaväärselt GET-meetodiga, kuid see lihtsalt kustutab toimingu tulemusel ressursi.
MQTT ühe protokolli lahendusena
Võtame sama nutika farmi, aga REST HTTP asemel kasutame MQTT protokolli. Kohalik server, kuhu on installitud Mosquitto raamatukogu, toimib vahendajana. Selles näites toimib lihtne arvuti (mida nimetatakse taluserveriks) Raspberry Pi MQTT-kliendina, mida rakendatakse Paho MQTT teegi installimise kaudu, mis ühildub täielikult Mosquitto maakleriga.
See klient vastab IoT abstraktsioonikihile, mis esindab tuvastus- ja arvutusvõimalustega seadet. Vahendaja seevastu vastab kõrgemale abstraktsioonitasemele, esindades uduarvutussõlme, mida iseloomustab suurem töötlemis- ja salvestusmaht.
Kavandatava nutika farmi stsenaariumi kohaselt loob Raspberry Pi ühenduse kiirendusmõõturi, GPS-i ja temperatuurianduritega ning avaldab nende andurite andmed udusõlme. Nagu te ilmselt teate, käsitleb MQTT teemasid hierarhiana. Üks MQTT väljaandja saab avaldada sõnumeid teatud teemade jaoks. Meie puhul on neid kolm. Andurile, mis mõõdab temperatuuri loomalaudas, valib klient teema (loomafarm/kuur/temperatuur). Andurite puhul, mis mõõdavad GPS-i asukohta ja loomade liikumist läbi kiirendusmõõturi, avaldab klient uuendused (loomafarm/loom/GPS) ja (loomafarm/loom/liikumine).
See info edastatakse maaklerile, kes saab selle ajutiselt kohalikku andmebaasi salvestada juhuks, kui hiljem tuleb mõni muu huviline tellija.
Lisaks kohalikule serverile, mis toimib udus MQTT maaklerina ja kuhu MQTT klientidena tegutsev Raspberry Pis saadab andurite andmeid, võib pilvetasandil olla veel üks MQTT maakler. Sellisel juhul saab kohalikule maaklerile edastatud info ajutiselt lokaalsesse andmebaasi salvestada ja/või pilve saata. Selles olukorras kasutatakse udu MQTT maaklerit kõigi andmete seostamiseks pilve MQTT maakleriga. Selle arhitektuuriga saab mobiilirakenduse kasutaja liituda mõlema maakleriga.
Kui ühenduse loomine ühe maakleriga (näiteks pilv) ebaõnnestub, saab lõppkasutaja teavet teiselt (udu). See on kombineeritud udu- ja pilvandmetöötlussüsteemide iseloomulik tunnus. Vaikimisi saab mobiilirakenduse seadistada nii, et see loob kõigepealt ühenduse udu MQTT maakleriga ja kui see ebaõnnestub, loob ühenduse pilve MQTT maakleriga. See lahendus on vaid üks paljudest IoT-F2C süsteemides.
Mitme protokolli lahendused
Ühe protokolli lahendused on populaarsed nende lihtsama rakendamise tõttu. Kuid on selge, et IoT-F2C süsteemides on mõttekas kombineerida erinevaid protokolle. Idee seisneb selles, et erinevad protokollid võivad töötada erinevatel tasanditel. Võtke näiteks kolm abstraktsiooni: asjade Interneti kihid, udu ja pilvandmetöötlus. IoT tasemel seadmeid peetakse üldiselt piiratuks. Selle ülevaate jaoks vaatleme asjade Interneti tasemeid kui kõige piiratumaid, pilvandmetöötlust kõige vähem piiravana ja uduandmetöötlust kui "kusagil keskel". Selgub, et asjade Interneti ja udu abstraktsioonide vahel on praegused protokollilahendused MQTT, CoAP ja XMPP. Udu ja pilve vahel seevastu on AMQP üks peamisi kasutatavaid protokolle koos REST HTTP-ga, mida oma paindlikkuse tõttu kasutatakse ka IoT ja udukihtide vahel.
Peamiseks probleemiks on siin protokollide koostalitlusvõime ja sõnumite ühest protokollist teise ülekandmise lihtsus. Ideaalis on tulevikus pilve- ja uduressurssidega asjade interneti süsteemi arhitektuur kasutatavast sideprotokollist sõltumatu ning tagab erinevate protokollide hea koostalitlusvõime.
Kuna see praegu nii ei ole, on mõttekas kombineerida protokolle, millel pole olulisi erinevusi. Selleks põhineb üks potentsiaalne lahendus kahe sama arhitektuuristiili järgiva protokolli, REST HTTP ja CoAP kombinatsioonil. Teine pakutud lahendus põhineb kahe protokolli kombinatsioonil, mis pakuvad avaldamise ja tellimise sidet, MQTT ja AMQP. Sarnaste kontseptsioonide kasutamine (nii MQTT kui ka AMQP kasutavad maaklereid, CoAP ja HTTP kasutavad REST-i) muudab nende kombinatsioonide rakendamise lihtsamaks ja nõuab vähem integreerimistööd.
Joonisel (a) on näidatud kaks päringu-vastusepõhist mudelit, HTTP ja CoAP, ning nende võimalik paigutus IoT-F2C lahenduses. Kuna HTTP on tänapäevastes võrkudes üks tuntumaid ja omaksvõetud protokolle, on ebatõenäoline, et see asendatakse täielikult muude sõnumsideprotokollidega. Pilve ja udu vahel asuvate võimsaid seadmeid esindavate sõlmede hulgas on REST HTTP nutikas lahendus.
Teisest küljest on piiratud arvutusressurssidega seadmete puhul, mis suhtlevad udu ja IoT kihtide vahel, tõhusam kasutada CoAP-i. CoAP-i üks suuri eeliseid on tegelikult selle ühilduvus HTTP-ga, kuna mõlemad protokollid põhinevad REST-põhimõtetel.
Joonisel (b) on sama stsenaariumi korral kaks avaldamise ja tellimise suhtlusmudelit, sealhulgas MQTT ja AMQP. Kuigi mõlemat protokolli saab hüpoteetiliselt kasutada iga abstraktsioonikihi sõlmede vaheliseks suhtluseks, tuleks nende asukoht kindlaks määrata jõudluse põhjal. MQTT loodi kerge protokollina piiratud arvutusressurssidega seadmetele, nii et seda saab kasutada IoT-Fog suhtluseks. AMQP sobib rohkem võimsamatele seadmetele, mis ideaalis positsioneeriksid selle udu- ja pilvesõlmede vahele. MQTT asemel saab asjade Internetis kasutada XMPP-protokolli, kuna seda peetakse kergeks. Kuid seda ei kasutata sellistes olukordades nii laialdaselt.
Järeldused
On ebatõenäoline, et ühest käsitletud protokollidest piisab süsteemis kogu suhtluse katmiseks alates piiratud arvutusressurssidega seadmetest kuni pilveserveriteni. Uuringust selgus, et kaks kõige lootustandvamat võimalust, mida arendajad enim kasutavad, on MQTT ja RESTful HTTP. Need kaks protokolli pole mitte ainult kõige küpsemad ja stabiilsemad, vaid sisaldavad ka palju hästi dokumenteeritud ja edukaid rakendusi ning veebiressursse.
Tänu oma stabiilsusele ja lihtsale konfiguratsioonile on MQTT protokoll, mis on aja jooksul tõestanud oma paremat jõudlust, kui seda kasutatakse IoT tasemel piiratud seadmetega. Süsteemi osades, kus piiratud side ja akutarbimine pole probleemiks, näiteks mõned ududomeenid ja enamik pilvandmetöötlust, on RESTful HTTP lihtne valik. Arvestada tuleks ka CoAP-iga, kuna see areneb kiiresti ka IoT sõnumsidestandardina ning on tõenäoline, et see saavutab lähitulevikus MQTT ja HTTP-ga sarnase stabiilsuse ja küpsustaseme. Kuid standard areneb praegu, millega kaasnevad lühiajalised ühilduvusprobleemid.
Mida veel blogist lugeda saab?
→
→
→
→
→
Telli meie -kanal, et mitte järgmisest artiklist ilma jääda! Kirjutame mitte rohkem kui kaks korda nädalas ja ainult tööasjades.
Allikas: www.habr.com