Technologijų tobulėjimas programinės ir techninės įrangos srityje, naujų komunikacijos protokolų atsiradimas paskatino daiktų interneto (IoT) plėtrą. Įrenginių skaičius kasdien auga ir jie generuoja didžiulį duomenų kiekį. Todėl reikia patogios sistemos architektūros, galinčios apdoroti, saugoti ir perduoti šiuos duomenis.
Dabar šiems tikslams naudojamos debesų paslaugos. Tačiau vis populiarėjanti rūko skaičiavimo paradigma (rūkas) gali papildyti debesų sprendimus, padidindama ir optimizuodama daiktų interneto infrastruktūrą.
Debesys gali padengti daugumą daiktų interneto užklausų. Pavyzdžiui, teikti paslaugų stebėjimą, greitą bet kokio kiekio įrenginių generuojamų duomenų apdorojimą, taip pat jų vizualizavimą. Rūko skaičiavimas yra efektyvesnis sprendžiant realaus laiko problemas. Jie užtikrina greitą atsakymą į užklausas ir minimalų duomenų apdorojimo delsą. Tai yra, Rūkas papildo „debesis“ ir išplečia savo galimybes.
Tačiau pagrindinis klausimas yra kitoks: kaip visa tai turėtų sąveikauti daiktų interneto kontekste? Kokie ryšio protokolai bus efektyviausi dirbant kombinuotoje IoT-Fog-Cloud sistemoje?
Nepaisant akivaizdaus HTTP dominavimo, daiktų interneto, rūko ir debesų sistemose naudojama daugybė kitų sprendimų. Taip yra todėl, kad daiktų internetas turi derinti įvairių įrenginių jutiklių funkcionalumą su saugumo, suderinamumo ir kitais vartotojų reikalavimais.
Tačiau tiesiog nėra vienos idėjos apie atskaitos architektūrą ir komunikacijos standartą. Todėl naujo protokolo kūrimas arba esamo modifikavimas konkrečioms IoT užduotims yra viena iš svarbiausių IT bendruomenės užduočių.
Kokie protokolai šiuo metu naudojami ir ką jie gali pasiūlyti? Išsiaiškinkime. Tačiau pirmiausia aptarkime ekosistemos, kurioje sąveikauja debesys, rūkas ir daiktų internetas, principus.
IoT „rūko į debesį“ (F2C) architektūra
Tikriausiai pastebėjote, kiek pastangų įdedama tyrinėjant privalumus ir privalumus, susijusius su protingu ir koordinuotu daiktų interneto, debesų ir rūko valdymu. Jei ne, tai trys standartizacijos iniciatyvos: , и .
Jei anksčiau buvo svarstomi tik 2 lygiai, debesys ir galutiniai įrenginiai, tai siūloma architektūra pristato naują lygmenį – rūko skaičiavimą. Šiuo atveju rūko lygis gali būti suskirstytas į kelis polygius, atsižvelgiant į išteklių specifiką arba strategijų rinkinį, kuris lemia skirtingų įrenginių naudojimą šiuose polygiuose.
Kaip gali atrodyti ši abstrakcija? Čia yra tipiška IoT-Fog-Cloud ekosistema. IoT įrenginiai siunčia duomenis į greitesnius serverius ir skaičiavimo įrenginius, kad išspręstų problemas, kurioms reikia mažo delsos. Toje pačioje sistemoje debesys yra atsakingi už problemų, kurioms reikia daug skaičiavimo resursų ar duomenų saugojimo vietos, sprendimą.
Išmanieji telefonai, išmanieji laikrodžiai ir kitos programėlės taip pat gali būti IoT dalis. Tačiau tokie įrenginiai, kaip taisyklė, naudoja patentuotus didelių kūrėjų ryšio protokolus. Sugeneruoti IoT duomenys į miglotąjį sluoksnį perduodami per REST HTTP protokolą, kuris suteikia lankstumo ir sąveikumo kuriant RESTful paslaugas. Tai svarbu, atsižvelgiant į poreikį užtikrinti atgalinį suderinamumą su esama skaičiavimo infrastruktūra, veikiančia vietiniuose kompiuteriuose, serveriuose arba serverių grupėje. Vietiniai ištekliai, vadinami „rūko mazgais“, filtruoja gautus duomenis ir apdoroja juos vietoje arba siunčia į debesį tolesniems skaičiavimams.
Debesys palaiko skirtingus ryšio protokolus, dažniausiai AMQP ir REST HTTP. Kadangi HTTP yra gerai žinomas ir pritaikytas internetui, gali kilti klausimas: „ar neturėtume jo naudoti dirbdami su IoT ir migla? Tačiau šis protokolas turi veikimo problemų. Daugiau apie tai vėliau.
Apskritai yra 2 ryšio protokolų modeliai, tinkami mums reikalingai sistemai. Tai yra užklausa-atsakymas ir paskelbimas-prenumerata. Pirmasis modelis yra plačiau žinomas, ypač serverio-kliento architektūroje. Klientas prašo informacijos iš serverio, o serveris gauna užklausą, ją apdoroja ir grąžina atsakymo pranešimą. Šiame modelyje veikia REST HTTP ir CoAP protokolai.
Antrasis modelis atsirado dėl poreikio užtikrinti asinchroninį, paskirstytą, laisvą ryšį tarp šaltinių, generuojančių duomenis, ir šių duomenų gavėjų.
Modelyje numatyti trys dalyviai: leidėjas (duomenų šaltinis), tarpininkas (dispečeris) ir abonentas (gavėjas). Čia klientas, veikiantis kaip abonentas, neprivalo prašyti informacijos iš serverio. Užuot siuntęs užklausas, jis užsiprenumeruoja tam tikrus įvykius sistemoje per tarpininką, kuris yra atsakingas už visų gaunamų pranešimų filtravimą ir nukreipimą tarp leidėjų ir prenumeratorių. O leidėjas, įvykus įvykiui tam tikra tema, jį paskelbia brokeriui, kuris siunčia prenumeratoriui duomenis apie prašomą temą.
Iš esmės ši architektūra yra pagrįsta įvykiais. Ir šis sąveikos modelis yra įdomus naudojant daiktų internetą, debesį, miglą, nes jis gali užtikrinti mastelį ir supaprastinti skirtingų įrenginių ryšį, palaikyti dinaminį ryšį tarp daugelio ir asinchroninį ryšį. Kai kurie iš labiausiai žinomų standartizuotų pranešimų protokolų, kuriuose naudojamas publikavimo ir prenumeratos modelis, yra MQTT, AMQP ir DDS.
Akivaizdu, kad publikavimo ir prenumeratos modelis turi daug privalumų:
- Leidėjai ir prenumeratoriai neturi žinoti vienas apie kito egzistavimą;
- Vienas prenumeratorius gali gauti informaciją iš daugybės skirtingų leidinių, o vienas leidėjas – siųsti duomenis daugeliui skirtingų prenumeratorių (principas „daug prie daugelio“);
- Leidėjas ir abonentas neturi būti aktyvūs tuo pačiu metu, kad galėtų bendrauti, nes brokeris (dirbantis kaip eilių sistema) galės išsaugoti pranešimą klientams, kurie šiuo metu nėra prisijungę prie tinklo.
Tačiau prašymo-atsakymo modelis taip pat turi savo privalumų. Tais atvejais, kai serverio pusės gebėjimas apdoroti kelias klientų užklausas nėra problema, prasminga naudoti patikrintus ir patikimus sprendimus.
Taip pat yra protokolų, kurie palaiko abu modelius. Pavyzdžiui, XMPP ir HTTP 2.0, kurie palaiko „serverio stūmimo“ parinktį. IETF taip pat išleido CoAP. Bandant išspręsti pranešimų problemą, buvo sukurti keli kiti sprendimai, pvz., WebSockets protokolas arba HTTP protokolo naudojimas per QUIC (Quick UDP Internet Connections).
„WebSockets“ atveju, nors jis naudojamas duomenims perduoti realiuoju laiku iš serverio į žiniatinklio klientą ir užtikrina nuolatinius ryšius tuo pačiu metu dvikrypčiu ryšiu, jis nėra skirtas įrenginiams su ribotais skaičiavimo ištekliais. QUIC taip pat nusipelno dėmesio, nes naujasis transporto protokolas suteikia daug naujų galimybių. Tačiau kadangi QUIC dar nėra standartizuotas, per anksti numatyti galimą jo taikymą ir poveikį daiktų interneto sprendimams. Taigi, atsižvelgdami į ateitį, turime omenyje „WebSockets“ ir „QUIC“, bet kol kas jų plačiau nenagrinėsime.
Kas yra mieliausias pasaulyje: protokolų palyginimas
Dabar pakalbėkime apie protokolų stipriąsias ir silpnąsias puses. Žvelgdami į ateitį, iš karto padarykime išlygą, kad nėra vieno aiškaus lyderio. Kiekvienas protokolas turi tam tikrų privalumų / trūkumų.
Atsakymo laikas
Viena iš svarbiausių komunikacijos protokolų savybių, ypač susijusių su daiktų internetu, yra atsako laikas. Tačiau tarp esamų protokolų nėra aiškaus laimėtojo, kuris parodytų minimalų delsos lygį dirbant skirtingomis sąlygomis. Tačiau yra daugybė tyrimų ir protokolų galimybių palyginimų.
Pavyzdžiui, HTTP ir MQTT efektyvumo palyginimas dirbant su daiktų internetu parodė, kad atsakymo laikas į MQTT užklausas yra trumpesnis nei HTTP. Ir kada MQTT ir CoAP kelionės pirmyn ir atgal laikas (RTT) parodė, kad vidutinis CoAP RTT yra 20% mažesnis nei MQTT.
Kitas su RTT MQTT ir CoAP protokolams buvo atlikta pagal du scenarijus: vietinį tinklą ir IoT tinklą. Paaiškėjo, kad vidutinis RTT yra 2–3 kartus didesnis daiktų interneto tinkle. MQTT su QoS0 parodė žemesnį rezultatą, palyginti su CoAP, o MQTT su QoS1 parodė didesnį RTT dėl ACK programos ir transportavimo sluoksniuose. Skirtingiems QoS lygiams tinklo delsa be perkrovos buvo milisekundės MQTT ir šimtai mikrosekundžių CoAP. Tačiau verta prisiminti, kad dirbant mažiau patikimuose tinkluose, MQTT, veikiantis TCP viršuje, parodys visiškai kitokį rezultatą.
AMQP ir MQTT protokolų atsako laikas padidinus naudingąją apkrovą parodė, kad esant nedideliam apkrovimui latentinis lygis yra beveik toks pat. Tačiau perduodant didelius duomenų kiekius, MQTT rodo trumpesnį atsako laiką. dar viename CoAP buvo lyginamas su HTTP naudojant mašinų tarpusavio ryšio scenarijų, kai įrenginiai buvo įrengti ant transporto priemonių su dujų jutikliais, oro jutikliais, vietos jutikliais (GPS) ir mobiliojo tinklo sąsaja (GPRS). CoAP pranešimo perdavimo mobiliuoju tinklu laikas buvo beveik tris kartus trumpesnis nei HTTP pranešimų naudojimo laikas.
Buvo atlikti tyrimai, kuriuose lyginami ne du, o trys protokolai. Pavyzdžiui, IoT protokolų MQTT, DDS ir CoAP veikimas medicinos programos scenarijuje naudojant tinklo emuliatorių. DDS pranoko MQTT pagal išbandytą telemetrijos delsą įvairiomis blogomis tinklo sąlygomis. UDP pagrįstas CoAP gerai veikė programoms, kurioms reikėjo greito atsako laiko, tačiau dėl to, kad jis pagrįstas UDP, buvo didelis nenuspėjamas paketų praradimas.
Bandwidth
MQTT ir CoAP pralaidumo efektyvumo požiūriu buvo atlikti apskaičiuojant bendrą per pranešimą perduodamų duomenų kiekį. CoAP parodė mažesnį pralaidumą nei MQTT, kai perduodami nedideli pranešimai. Tačiau lyginant protokolų efektyvumą pagal naudingos informacijos baitų skaičiaus santykį su visu perduotų baitų skaičiumi, CoAP pasirodė esąs efektyvesnis.
prie naudojant MQTT, DDS (su TCP kaip transportavimo protokolu) ir CoAP pralaidumą, buvo nustatyta, kad CoAP paprastai rodė palyginti mažesnį pralaidumą, kuris nepadidėjo didėjant tinklo paketų praradimui ar didėjant tinklo delsai, skirtingai nei MQTT ir DDS, kur buvo pralaidumo panaudojimo padidėjimas minėtais scenarijais. Kitas scenarijus susijęs su dideliu skaičiumi įrenginių, vienu metu perduodančių duomenis, o tai būdinga daiktų interneto aplinkoms. Rezultatai parodė, kad didesniam panaudojimui geriau naudoti CoAP.
Esant nedidelei apkrovai, CoAP naudojo mažiausią pralaidumą, po to sekė MQTT ir REST HTTP. Tačiau padidėjus naudingųjų apkrovų dydžiui, REST HTTP pasiekė geriausius rezultatus.
Energijos suvartojimas
Energijos vartojimo klausimas visada yra labai svarbus, ypač daiktų interneto sistemoje. Jeigu Nors MQTT ir HTTP sunaudoja elektros energiją, HTTP sunaudoja daug daugiau. Ir CoAP yra daugiau palyginti su MQTT, leidžiančiu valdyti energiją. Tačiau pagal paprastus scenarijus MQTT labiau tinka keistis informacija daiktų interneto tinkluose, ypač jei nėra galios apribojimų.
Eksperimentas, kuriame buvo palygintos AMQP ir MQTT galimybės mobiliajame arba nestabiliame belaidžiame tinkle, parodė, kad AMQP siūlo daugiau saugumo galimybių, o MQTT yra efektyvesnis.
saugumas
Saugumas yra dar viena svarbi problema, iškelta studijuojant daiktų interneto ir miglos / debesų kompiuterijos temą. Saugos mechanizmas paprastai yra pagrįstas TLS HTTP, MQTT, AMQP ir XMPP arba DTLS CoAP ir palaiko abu DDS variantus.
TLS ir DTLS prasideda ryšio tarp kliento ir serverio pusių užmezgimo procesu, kad būtų galima keistis palaikomais šifrų rinkiniais ir raktais. Abi šalys derasi dėl rinkinių, siekdamos užtikrinti, kad tolesnis ryšys vyktų saugiu kanalu. Skirtumas tarp šių dviejų yra nedidelių modifikacijų, leidžiančių UDP pagrindu veikiančiam DTLS veikti per nepatikimą ryšį.
prie Keletas skirtingų TLS ir DTLS diegimų nustatė, kad TLS atliko geresnį darbą. DTLS atakos buvo sėkmingesnės dėl klaidų tolerancijos.
Tačiau didžiausia šių protokolų problema yra ta, kad jie iš pradžių nebuvo skirti naudoti IoT ir nebuvo skirti dirbti rūke ar debesyje. Paspaudę rankas, jie prideda papildomo srauto su kiekvienu ryšiu, o tai eikvoja skaičiavimo išteklius. Vidutiniškai TLS pridėtinės išlaidos padidėja 6,5 %, o DTLS – 11 %, palyginti su ryšiais be saugos sluoksnio. Daug išteklių turinčiose aplinkose, kurios paprastai yra lygiu, tai nebus problema, tačiau ryšium tarp daiktų interneto ir rūko lygio tai tampa svarbiu apribojimu.
Ką rinktis? Nėra aiškaus atsakymo. Atrodo, kad MQTT ir HTTP yra perspektyviausi protokolai, nes jie laikomi palyginti brandesniais ir stabilesniais IoT sprendimais, palyginti su kitais protokolais.
Vieningu komunikacijos protokolu pagrįsti sprendimai
Vieno protokolo sprendimo praktika turi daug trūkumų. Pavyzdžiui, ribotai aplinkai tinkamas protokolas gali neveikti domene, kuriam taikomi griežti saugos reikalavimai. Turint tai omenyje, mums belieka atmesti beveik visus įmanomus vieno protokolo sprendimus rūko į debesį ekosistemoje IoT, išskyrus MQTT ir REST HTTP.
REST HTTP kaip vieno protokolo sprendimas
Yra geras pavyzdys, kaip REST HTTP užklausos ir atsakymai sąveikauja IoT-to-Fog erdvėje: . Gyvūnai aprūpinti nešiojamaisiais jutikliais (IoT klientas, C) ir valdomi per debesų kompiuteriją išmaniosios ūkininkavimo sistemos („Fog server“, S).
POST metodo antraštė nurodo šaltinį, kurį reikia keisti (/farm/animals), taip pat HTTP versiją ir turinio tipą, kuris šiuo atveju yra JSON objektas, reprezentuojantis gyvūnų fermą, kurią sistema turi valdyti (Dulcinea/cow). . Atsakymas iš serverio rodo, kad užklausa buvo sėkminga, siunčiant HTTPS būsenos kodą 201 (išteklius sukurtas). GET metodas URI turi nurodyti tik prašomus išteklius (pvz., /farm/animals/1), kuris iš serverio pateikia gyvūno JSON atvaizdą su tuo ID.
PUT metodas naudojamas, kai reikia atnaujinti tam tikrą išteklių įrašą. Tokiu atveju išteklius nurodo keičiamo parametro URI ir esamą reikšmę (pvz., nurodant, kad karvė šiuo metu vaikšto, /farm/animals/1? state=walking). Galiausiai, DELETE metodas naudojamas lygiai taip pat kaip ir GET metodas, tačiau dėl operacijos tiesiog ištrinami ištekliai.
MQTT kaip vieno protokolo sprendimas
Imkime tą pačią išmaniąją fermą, bet vietoj REST HTTP naudojame MQTT protokolą. Vietinis serveris su įdiegta Mosquitto biblioteka veikia kaip tarpininkas. Šiame pavyzdyje paprastas kompiuteris (vadinamas ūkio serveriu) Raspberry Pi naudojamas kaip MQTT klientas, įdiegtas įdiegus Paho MQTT biblioteką, kuri visiškai suderinama su Mosquitto brokeriu.
Šis klientas atitinka IoT abstrakcijos sluoksnį, vaizduojantį įrenginį su jutimo ir skaičiavimo galimybėmis. Kita vertus, tarpininkas atitinka aukštesnį abstrakcijos lygį, atstovaujantį rūko skaičiavimo mazgui, kuriam būdinga didesnė apdorojimo ir saugojimo talpa.
Siūlomame išmaniosios fermos scenarijuje Raspberry Pi prisijungia prie akselerometro, GPS ir temperatūros jutiklių ir skelbia duomenis iš šių jutiklių į rūko mazgą. Kaip tikriausiai žinote, MQTT temas traktuoja kaip hierarchiją. Vienas MQTT leidėjas gali skelbti pranešimus konkrečiam temų rinkiniui. Mūsų atveju jų yra trys. Jutikliui, kuris matuoja temperatūrą gyvulių tvarte, klientas pasirenka temą (gyvūnų ferma/tvartas/temperatūra). Jei jutikliai matuoja GPS vietą ir gyvūnų judėjimą per akselerometrą, klientas paskelbs (gyvūnų ferma/gyvūnų/GPS) ir (gyvūnų ferma/gyvūnų/judėjimas) atnaujinimus.
Ši informacija bus perduota brokeriui, kuris gali laikinai saugoti ją vietinėje duomenų bazėje, jei vėliau atsirastų kitas suinteresuotas abonentas.
Be vietinio serverio, kuris migloje veikia kaip MQTT brokeris ir kuriam Raspberry Pis, veikdamas kaip MQTT klientai, siunčia jutiklių duomenis, debesų lygiu gali būti dar vienas MQTT brokeris. Tokiu atveju vietiniam brokeriui perduota informacija gali būti laikinai saugoma vietinėje duomenų bazėje ir/arba siunčiama į debesį. Rūko MQTT brokeris šioje situacijoje naudojamas susieti visus duomenis su debesies MQTT brokeriu. Naudojant šią architektūrą, mobiliosios programos vartotojas gali būti prenumeruojamas abiejų brokerių paslaugomis.
Jei nepavyksta prisijungti prie vieno iš brokerių (pavyzdžiui, debesis), galutinis vartotojas gaus informaciją iš kito (rūkas). Tai būdinga kombinuotų rūko ir debesų kompiuterijos sistemų savybė. Pagal numatytuosius nustatymus mobiliąją programėlę galima sukonfigūruoti taip, kad pirmiausia jungtųsi prie miglos MQTT brokerio, o jei nepavyks – prie debesies MQTT brokerio. Šis sprendimas yra tik vienas iš daugelio IoT-F2C sistemų.
Kelių protokolų sprendimai
Vieno protokolo sprendimai yra populiarūs dėl lengvesnio jų įgyvendinimo. Tačiau akivaizdu, kad IoT-F2C sistemose prasminga derinti skirtingus protokolus. Idėja ta, kad skirtingi protokolai gali veikti skirtingais lygiais. Paimkite, pavyzdžiui, tris abstrakcijas: daiktų interneto, rūko ir debesų kompiuterijos sluoksnius. Įrenginiai daiktų interneto lygiu paprastai laikomi ribotais. Apžvelgdami šią apžvalgą, laikykime, kad daiktų interneto pakopos yra labiausiai suvaržytos, debesys – mažiausiai suvaržytos, o miglos skaičiavimas – kaip „kažkur per vidurį“. Tada paaiškėja, kad tarp daiktų interneto ir rūko abstrakcijų dabartiniai protokolo sprendimai apima MQTT, CoAP ir XMPP. Kita vertus, tarp rūko ir debesies AMQP yra vienas iš pagrindinių naudojamų protokolų, kartu su REST HTTP, kuris dėl savo lankstumo taip pat naudojamas tarp daiktų interneto ir rūko sluoksnių.
Pagrindinė problema čia yra protokolų sąveikumas ir pranešimų perdavimo iš vieno protokolo į kitą paprastumas. Idealiu atveju ateityje daiktų interneto sistemos architektūra su debesų ir miglos ištekliais bus nepriklausoma nuo naudojamo ryšio protokolo ir užtikrins gerą skirtingų protokolų sąveiką.
Kadangi šiuo metu taip nėra, prasminga derinti protokolus, kurie neturi reikšmingų skirtumų. Šiuo tikslu vienas galimas sprendimas yra pagrįstas dviejų protokolų, kurie atitinka tą patį architektūrinį stilių, – REST HTTP ir CoAP – deriniu. Kitas siūlomas sprendimas yra pagrįstas dviejų protokolų, siūlančių publikavimo ir prenumeratos ryšį, deriniu – MQTT ir AMQP. Naudojant panašias koncepcijas (ir MQTT, ir AMQP naudoja brokerius, CoAP ir HTTP naudoja REST), šiuos derinius lengviau įgyvendinti ir reikia mažiau pastangų integruojant.
(a) paveiksle pavaizduoti du užklausos ir atsako modeliai, HTTP ir CoAP, ir galimas jų išdėstymas IoT-F2C sprendime. Kadangi HTTP yra vienas iš labiausiai žinomų ir priimtų protokolų šiuolaikiniuose tinkluose, mažai tikėtina, kad jį visiškai pakeis kiti pranešimų siuntimo protokolai. Tarp mazgų, atstovaujančių galingus įrenginius, esančius tarp debesies ir rūko, REST HTTP yra protingas sprendimas.
Kita vertus, įrenginiams su ribotais skaičiavimo ištekliais, kurie palaiko ryšį tarp rūko ir daiktų interneto sluoksnių, efektyviau naudoti CoAP. Vienas iš didžiausių CoAP privalumų iš tikrųjų yra jo suderinamumas su HTTP, nes abu protokolai yra pagrįsti REST principais.
b paveiksle parodyti du publikavimo ir prenumeratos komunikacijos modeliai pagal tą patį scenarijų, įskaitant MQTT ir AMQP. Nors hipotetiškai abu protokolai gali būti naudojami ryšiui tarp mazgų kiekviename abstrakcijos sluoksnyje, jų padėtis turėtų būti nustatyta atsižvelgiant į našumą. MQTT buvo sukurtas kaip lengvas protokolas įrenginiams su ribotais skaičiavimo ištekliais, todėl jį galima naudoti IoT-Fog ryšiui palaikyti. AMQP labiau tinka galingesniems įrenginiams, kurie idealiai padėtų jį tarp rūko ir debesų mazgų. Vietoj MQTT, XMPP protokolas gali būti naudojamas IoT, nes jis laikomas lengvu. Tačiau tokiais atvejais jis nėra plačiai naudojamas.
išvados
Mažai tikėtina, kad vieno iš aptartų protokolų pakaks visam sistemos ryšiui aprėpti – nuo įrenginių su ribotais skaičiavimo ištekliais iki debesies serverių. Tyrimas parodė, kad dvi perspektyviausios parinktys, kurias dažniausiai naudoja kūrėjai, yra MQTT ir RESTful HTTP. Šie du protokolai yra ne tik patys brandžiausi ir stabiliausi, bet ir apima daug gerai dokumentuotų ir sėkmingų diegimų bei internetinių išteklių.
Dėl savo stabilumo ir paprastos konfigūracijos MQTT yra protokolas, kuris laikui bėgant įrodė savo puikų našumą, kai naudojamas daiktų interneto lygiu su ribotais įrenginiais. Tose sistemos dalyse, kuriose ribotas ryšys ir akumuliatoriaus suvartojimas nėra problema, pvz., kai kurie rūko domenai ir dauguma debesų kompiuterijos, RESTful HTTP yra lengvas pasirinkimas. Taip pat reikėtų atsižvelgti į CoAP, nes jis taip pat sparčiai vystosi kaip daiktų interneto pranešimų standartas ir tikėtina, kad artimiausiu metu jis pasieks stabilumo ir brandumo lygį, panašų į MQTT ir HTTP. Tačiau standartas šiuo metu tobulinamas, todėl kyla trumpalaikių suderinamumo problemų.
Ką dar galite perskaityti tinklaraštyje?
→
→
→
→
→
Užsiprenumeruokite mūsų -kanalas, kad nepraleistumėte kito straipsnio! Rašome ne dažniau kaip du kartus per savaitę ir tik darbo reikalais.
Šaltinis: www.habr.com