La disvolviĝo de teknologioj en la kampo de programaro kaj aparataro, la apero de novaj komunikaj protokoloj kaŭzis la ekspansion de la Interreto de Aĵoj (IoT). La nombro da aparatoj kreskas tagon post tago kaj ili generas grandegan kvanton da datumoj. Tial necesas oportuna sistema arkitekturo kapabla prilabori, stoki kaj transdoni ĉi tiujn datumojn.
Nun nubaj servoj estas uzataj por ĉi tiuj celoj. Tamen, la ĉiam pli populara nebulkomputila paradigmo (Nebulo) povas kompletigi nubajn solvojn per skalado kaj optimumigado de IoT-infrastrukturo.
Nuboj kapablas kovri la plej multajn IoT-petojn. Ekzemple, provizi monitoradon de servoj, rapida prilaborado de ajna kvanto de datumoj generitaj de aparatoj, same kiel ilia bildigo. Nebulkomputado estas pli efika dum solvado de realtempaj problemoj. Ili provizas rapidan respondon al petoj kaj minimuma latenteco en datumtraktado. Tio estas, Nebulo kompletigas la "nubojn" kaj vastigas siajn kapablojn.
Tamen, la ĉefa demando estas malsama: kiel ĉio ĉi devus interagi en la kunteksto de IoT? Kiuj komunikaj protokoloj estos plej efikaj kiam vi laboras en kombinita sistemo IoT-Nebulo-Nubo?
Malgraŭ la ŝajna regado de HTTP, ekzistas granda nombro da aliaj solvoj uzataj en sistemoj IoT, Nebulo kaj Nubo. Ĉi tio estas ĉar IoT devas kombini la funkciecon de diversaj aparataj sensiloj kun la sekureco, kongruo kaj aliaj postuloj de uzantoj.
Sed simple ne ekzistas ununura ideo pri la referenca arkitekturo kaj komunika normo. Tial, krei novan protokolon aŭ modifi ekzistantan por specifaj IoT-taskoj estas unu el la plej gravaj taskoj alfrontantaj la IT-komunumon.
Kiuj protokoloj estas nuntempe uzataj kaj kion ili povas oferti? Ni eltrovu ĝin. Sed unue, ni diskutu la principojn de la ekosistemo en kiu interagas nuboj, nebulo kaj la Interreto de aferoj.
IoT Nebul-al-Nubo (F2C) Arkitekturo
Vi verŝajne rimarkis kiom multe da penado estas farita por esplori la avantaĝojn kaj avantaĝojn asociitajn kun inteligenta kaj kunordigita administrado de IoT, nubo kaj nebulo. Se ne, jen tri normigaj iniciatoj: , и .
Se antaŭe nur 2 niveloj estis pripensitaj, nuboj kaj finaj aparatoj, tiam la proponita arkitekturo enkondukas novan nivelon - nebulkomputiko. En ĉi tiu kazo, la nebulnivelo povas esti dividita en plurajn subnivelojn, depende de la specifaĵoj de rimedoj aŭ aro de politikoj kiuj determinas la uzon de malsamaj aparatoj en ĉi tiuj subniveloj.
Kiel povus aspekti ĉi tiu abstraktaĵo? Jen tipa ekosistemo de IoT-Nebulo-Nubo. IoT-aparatoj sendas datumojn al pli rapidaj serviloj kaj komputikaj aparatoj por solvi problemojn, kiuj postulas malaltan latentecon. En la sama sistemo, nuboj respondecas pri solvi problemojn, kiuj postulas grandan kvanton da komputikaj rimedoj aŭ datumstokado.
Smartphones, inteligentaj horloĝoj kaj aliaj aparatoj ankaŭ povas esti parto de la IoT. Sed tiaj aparatoj, kiel regulo, uzas proprietajn komunikajn protokolojn de grandaj programistoj. La generitaj IoT-datenoj estas transdonitaj al la nebultavolo per la REST HTTP-protokolo, kiu disponigas flekseblecon kaj kunfunkcieblecon dum kreado de RESTfulaj servoj. Ĉi tio gravas pro la bezono certigi malantaŭan kongruon kun ekzistanta komputika infrastrukturo funkcianta sur lokaj komputiloj, serviloj aŭ servila areto. Lokaj rimedoj, nomataj "nebulnodoj", filtras la ricevitajn datumojn kaj prilaboras ĝin loke aŭ sendas ĝin al la nubo por pliaj kalkuloj.
Nuboj subtenas malsamajn komunikajn protokolojn, la plej oftaj estas AMQP kaj REST HTTP. Ĉar HTTP estas bone konata kaj adaptita por la Interreto, la demando povas ekesti: "ĉu ni ne uzu ĝin por labori kun IoT kaj nebulo?" Tamen, ĉi tiu protokolo havas rendimentajn problemojn. Pli pri tio poste.
Ĝenerale, ekzistas 2 modeloj de komunikaj protokoloj taŭgaj por la sistemo, kiun ni bezonas. Ĉi tiuj estas peto-respondo kaj publikigi-aboni. La unua modelo estas pli vaste konata, precipe en arkitekturo de servil-kliento. La kliento petas informojn de la servilo, kaj la servilo ricevas la peton, prilaboras ĝin kaj resendas respondmesaĝon. La REST HTTP kaj CoAP-protokoloj funkcias sur ĉi tiu modelo.
La dua modelo ekestis de la bezono disponigi nesinkronan, distribuitan, lozan kupladon inter la fontoj generantaj datenojn kaj la ricevantoj de ĉi tiuj datumoj.
La modelo supozas tri partoprenantojn: eldonisto (datumfonto), makleristo (sendisto) kaj abonanto (ricevilo). Ĉi tie, la kliento aganta kiel abonanto ne devas peti informojn de la servilo. Anstataŭ sendi petojn, ĝi abonas certajn eventojn en la sistemo per makleristo, kiu respondecas pri filtri ĉiujn envenantajn mesaĝojn kaj direkti ilin inter eldonistoj kaj abonantoj. Kaj la eldonisto, kiam okazas evento pri certa temo, publikigas ĝin al la makleristo, kiu sendas datumojn pri la petita temo al la abonanto.
Esence, ĉi tiu arkitekturo estas okazaĵbazita. Kaj ĉi tiu interaga modelo estas interesa por aplikoj en IoT, nubo, nebulo pro sia kapablo provizi skaleblon kaj simpligi la interkonekton inter malsamaj aparatoj, subteni dinamikan mult-al-multan komunikadon kaj nesinkronan komunikadon. Iuj el la plej konataj normigitaj mesaĝaj protokoloj, kiuj uzas publikig-abonan modelon, inkluzivas MQTT, AMQP kaj DDS.
Evidente, la eldon-abono-modelo havas multajn avantaĝojn:
- Eldonejoj kaj abonantoj ne bezonas scii pri la ekzisto de unu la alian;
- Unu abonanto povas ricevi informojn de multaj diversaj eldonaĵoj, kaj unu eldonejo povas sendi datumojn al multaj diversaj abonantoj (principo mult-al-multaj);
- La eldonisto kaj abonanto ne devas esti aktivaj samtempe por komuniki, ĉar la makleristo (laboranta kiel vicsistemo) povos konservi la mesaĝon por klientoj kiuj ne estas nuntempe konektitaj al la reto.
Tamen, la peto-responda modelo ankaŭ havas siajn fortojn. En kazoj kie la kapablo de la servilflanko trakti plurajn klientajn petojn ne estas problemo, estas senco uzi pruvitajn, fidindajn solvojn.
Ekzistas ankaŭ protokoloj kiuj subtenas ambaŭ modelojn. Ekzemple, XMPP kaj HTTP 2.0, kiuj subtenas la opcion "servilo-puŝo". La IETF ankaŭ publikigis CoAP. Provante solvi la mesaĝproblemon, pluraj aliaj solvoj estis kreitaj, kiel la WebSockets-protokolo aŭ la uzado de la HTTP-protokolo super QUIC (Quick UDP Interretaj Konektoj).
En la kazo de WebSockets, kvankam ĝi estas uzata por transdoni datumojn en reala tempo de servilo al retkliento kaj provizas konstantajn konektojn kun samtempa dudirekta komunikado, ĝi ne estas destinita por aparatoj kun limigitaj komputikaj rimedoj. QUIC ankaŭ meritas atenton, ĉar la nova transportprotokolo donas multajn novajn ŝancojn. Sed ĉar QUIC ankoraŭ ne estas normigita, estas tro frue antaŭdiri ĝian eblan aplikon kaj efikon al IoT-solvoj. Do ni memoras WebSockets kaj QUIC kun okulo al la estonteco, sed ni ne studos ĝin pli detale nuntempe.
Kiu estas la plej bela en la mondo: komparante protokolojn
Nun ni parolu pri la fortoj kaj malfortoj de protokoloj. Rigardante antaŭen, ni tuj faru rezervon, ke ekzistas neniu klara gvidanto. Ĉiu protokolo havas kelkajn avantaĝojn/malavantaĝojn.
Respondotempo
Unu el la plej gravaj karakterizaĵoj de komunikadprotokoloj, precipe rilate al la Interreto de Aĵoj, estas respondtempo. Sed inter la ekzistantaj protokoloj, ne ekzistas klara gajnanto, kiu pruvas la minimuman nivelon de latenteco kiam laboras sub malsamaj kondiĉoj. Sed ekzistas multe da esplorado kaj komparoj de protokolaj kapabloj.
Ekzemple, komparoj de la efikeco de HTTP kaj MQTT dum laborado kun IoT montris, ke la respondtempo por petoj por MQTT estas malpli ol por HTTP. Kaj kiam La rondvetura tempo (RTT) de MQTT kaj CoAP rivelis ke la meza RTT de CoAP estas 20% malpli ol tiu de MQTT.
Aliaj kun RTT por la protokoloj MQTT kaj CoAP estis efektivigita en du scenaroj: loka reto kaj IoT-reto. Montriĝis, ke la averaĝa RTT estas 2-3 fojojn pli alta en reto IoT. MQTT kun QoS0 montris pli malaltan rezulton kompare kun CoAP, kaj MQTT kun QoS1 montris pli altan RTT pro ACKs ĉe la aplikaĵo kaj transportaj tavoloj. Por malsamaj QoS-niveloj, retlatenteco sen obstrukciĝo estis milisekundoj por MQTT, kaj centoj da mikrosekundoj por CoAP. Tamen indas memori, ke kiam oni laboras sur malpli fidindaj retoj, MQTT funkcianta super TCP montros tute alian rezulton.
responda tempo por la protokoloj AMQP kaj MQTT pliigante la utilan ŝarĝon montris, ke kun malpeza ŝarĝo la latencia nivelo estas preskaŭ la sama. Sed dum transdono de grandaj kvantoj da datumoj, MQTT montras pli mallongajn respondajn tempojn. en unu pli CoAP estis komparita kun HTTP en maŝin-al-maŝina komunika scenaro kun aparatoj deplojitaj aldone al veturiloj ekipitaj per gassensiloj, vetersensiloj, loksensiloj (GPS) kaj mobilretinterfaco (GPRS). La tempo bezonata por elsendi CoAP-mesaĝon tra la movebla reto estis preskaŭ trioble pli mallonga ol la tempo bezonata por uzi HTTP-mesaĝojn.
Oni faris studojn, kiuj komparis ne du, sed tri protokolojn. Ekzemple, agado de IoT-protokoloj MQTT, DDS kaj CoAP en medicina aplikaĵoscenaro uzante retan emulilon. DDS superis MQTT laŭ testita telemetria latenteco sub diversaj malbonaj retaj kondiĉoj. UDP-bazita CoAP funkciis bone por aplikoj kiuj postulis rapidajn respondtempojn, aliflanke, pro ĝi estante UDP-bazita, ekzistis signifa neantaŭvidebla pakaĵetperdo.
Larĝa de bando
MQTT kaj CoAP laŭ bendolarĝa efikeco estis efektivigitaj kiel kalkulo de la totala kvanto de datumoj transdonitaj per mesaĝo. CoAP montris pli malaltan trairon ol MQTT dum elsendado de malgrandaj mesaĝoj. Sed kiam oni komparas la efikecon de protokoloj laŭ la rilatumo de la nombro da utilaj informaj bajtoj al la totala nombro da transigitaj bajtoj, CoAP montriĝis pli efika.
ĉe uzante MQTT, DDS (kun TCP kiel la transportprotokolo) kaj CoAP-bendolarĝon, estis trovite ke CoAP ĝenerale montris relative pli malaltan bendolarĝkonsumon, kiu ne pliiĝis kun pliigita retpakaĵperdo aŭ pliigita retlatenteco, male al MQTT kaj DDS, kie ekzistis. pliiĝo en bendolarĝa utiligo en la menciitaj scenaroj. Alia scenaro implikis grandan nombron da aparatoj elsendantaj datumojn samtempe, kio estas tipa en IoT-medioj. La rezultoj montris, ke por pli alta utiligo estas pli bone uzi CoAP.
Sub malpeza ŝarĝo, CoAP uzis la malplej bendolarĝon, sekvitan de MQTT kaj REST HTTP. Tamen, kiam la grandeco de la utilaj ŝarĝoj pliiĝis, REST HTTP havis la plej bonajn rezultojn.
РнергопотреР± Р »РµРЅРёРµ
La afero de energikonsumo ĉiam tre gravas, kaj precipe en IoT-sistemo. Se Dum MQTT kaj HTTP konsumas elektron, HTTP konsumas multe pli. Kaj CoAP estas pli komparite kun MQTT, permesante potencoadministradon. Tamen, en simplaj scenaroj, MQTT pli taŭgas por interŝanĝi informojn en retoj de Interreto de Aĵoj, precipe se ne ekzistas potencaj limigoj.
Eksperimento kiu komparis la kapablojn de AMQP kaj MQTT sur movebla aŭ malstabila sendrata testlito trovis ke AMQP ofertas pli da sekureckapabloj dum MQTT estas pli energiefika.
Sekureco
Sekureco estas alia kritika afero levita dum studado de la temo de la Interreto de Aĵoj kaj nebulo/nuba komputado. La sekurecmekanismo estas tipe bazita sur TLS en HTTP, MQTT, AMQP kaj XMPP, aŭ DTLS en CoAP, kaj apogas ambaŭ DDS-variaĵojn.
TLS kaj DTLS komenciĝas kun la procezo de establado de komunikado inter la kliento- kaj servilflankoj por interŝanĝi apogitajn ĉifroseriojn kaj ŝlosilojn. Ambaŭ partioj negocas arojn por certigi ke plia komunikado okazas sur sekura kanalo. La diferenco inter la du kuŝas en malgrandaj modifoj kiuj permesas al UDP-bazita DTLS funkcii per nefidinda konekto.
ĉe Pluraj malsamaj efektivigoj de TLS kaj DTLS trovis ke TLS faris pli bonan laboron. Atakoj sur DTLS estis pli sukcesaj pro ĝia erartoleremo.
Tamen, la plej granda problemo kun ĉi tiuj protokoloj estas, ke ili ne estis origine dizajnitaj por uzo en IoT kaj ne estis intencitaj por funkcii en la nebulo aŭ nubo. Per manpremado, ili aldonas plian trafikon kun ĉiu koneksa establaĵo, kiu malplenigas komputigajn rimedojn. Averaĝe, estas pliiĝo de 6,5% por TLS kaj 11% por DTLS en supra kosto kompare kun komunikadoj sen sekureca tavolo. En rimedoj riĉaj medioj, kiuj kutime troviĝas sur nivelo, ĉi tio ne estos problemo, sed en la rilato inter IoT kaj nebulnivelo, ĉi tio fariĝas grava limigo.
Kion elekti? Ne estas klara respondo. MQTT kaj HTTP ŝajnas esti la plej esperigaj protokoloj ĉar ili estas konsiderataj kompare pli maturaj kaj pli stabilaj IoT-solvoj kompare kun aliaj protokoloj.
Solvoj bazitaj sur unuigita komunika protokolo
La praktiko de unu-protokola solvo havas multajn malavantaĝojn. Ekzemple, protokolo kiu konvenas al limigita medio eble ne funkcias en domajno kiu havas striktajn sekurecpostulojn. Konsiderante ĉi tion, ni restas forĵeti preskaŭ ĉiujn eblajn unu-protokolajn solvojn en la Nebulo-al-nuba ekosistemo en IoT, krom MQTT kaj REST HTTP.
REST HTTP kiel unu-protokola solvo
Estas bona ekzemplo pri kiel REST HTTP-petoj kaj respondoj interagas en la spaco IoT-al-Nebulo: . La bestoj estas ekipitaj per porteblaj sensiloj (IoT-kliento, C) kaj kontrolitaj per nuba komputado per inteligenta agrikultura sistemo (Nebulo-servilo, S).
La kaplinio de la POST-metodo specifas la rimedon por modifi (/farm/bestoj) same kiel la HTTP-version kaj enhavspecon, kiu ĉi-kaze estas JSON-objekto reprezentanta la bestan bienon, kiun la sistemo devas administri (Dulcinea/bovino) . La respondo de la servilo indikas, ke la peto sukcesis sendante HTTPS-statuskodon 201 (rimedo kreita). La GET-metodo devas specifi nur la petitan rimedon en la URI (ekzemple, /farm/animals/1), kiu resendas JSON-reprezenton de la besto kun tiu identigilo de la servilo.
La metodo PUT estas uzata kiam iu specifa rimedrekordo devas esti ĝisdatigita. En ĉi tiu kazo, la rimedo specifas la URI por la ŝanĝenda parametro kaj la aktuala valoro (ekzemple, indikante ke la bovino nuntempe marŝas, /farm/animals/1? state=marŝas). Fine, la metodo DELETE estas uzata same kiel la metodo GET, sed simple forigas la rimedon kiel rezulto de la operacio.
MQTT kiel unu-protokola solvo
Ni prenu la saman inteligentan bienon, sed anstataŭ REST HTTP ni uzas la MQTT-protokolon. Loka servilo kun la Mosquitto-biblioteko instalita funkcias kiel makleristo. En ĉi tiu ekzemplo, simpla komputilo (referita kiel la farmservilo) Raspberry Pi funkcias kiel MQTT-kliento, efektivigita per instalado de la Biblioteko Paho MQTT, kiu estas plene kongrua kun la makleristo Mosquitto.
Ĉi tiu kliento respondas al IoT-abstrakta tavolo reprezentanta aparaton kun sentado kaj komputikkapabloj. La mediaciisto, aliflanke, egalrilatas al pli alta nivelo de abstraktado, reprezentante nebulkomputiknodon karakterizitan per pli granda pretigo kaj stoka kapacito.
En la proponita saĝa farmscenaro, la Raspberry Pi konektas al la akcelometro, GPS kaj temperatursensiloj kaj publikigas datumojn de ĉi tiuj sensiloj al nebulnodo. Kiel vi verŝajne scias, MQTT traktas temojn kiel hierarkion. Ununura MQTT-eldonisto povas publikigi mesaĝojn al specifa aro de temoj. En nia kazo estas tri el ili. Por sensilo kiu mezuras la temperaturon en besta garbejo, la kliento elektas temon (bestofarmo/ŝedo/temperaturo). Por sensiloj kiuj mezuras GPS-lokon kaj bestan movadon per la akcelometro, la kliento publikigos ĝisdatigojn al (bestofarmo/besto/GPS) kaj (bestofarmo/besto/movado).
Ĉi tiu informo estos transdonita al la makleristo, kiu povas provizore konservi ĝin en loka datumbazo, se alia interesata abonanto venos poste.
Krom la loka servilo, kiu funkcias kiel MQTT-broker en la nebulo kaj al kiu Raspberry Pis, agante kiel MQTT-klientoj, sendas sensilajn datumojn, povas esti alia MQTT-broker ĉe la nuba nivelo. En ĉi tiu kazo, la informoj transdonitaj al la loka makleristo povas esti provizore konservita en loka datumbazo kaj/aŭ sendita al la nubo. La nebulo MQTT-broker en ĉi tiu situacio estas uzata por asocii ĉiujn datumojn kun la nuba MQTT-broker. Kun ĉi tiu arkitekturo, uzanto de poŝtelefona aplikaĵo povas esti abonita al ambaŭ makleristoj.
Se la konekto al unu el la makleristoj (ekzemple, nubo) malsukcesas, la fina uzanto ricevos informojn de la alia (nebulo). Ĉi tio estas karakteriza trajto de kombinitaj nebulaj kaj nubaj komputiksistemoj. Defaŭlte, la movebla aplikaĵo povas esti agordita por unue konektiĝi al la nebula MQTT-broker, kaj se tio malsukcesas, por konekti al la nuba MQTT-broker. Ĉi tiu solvo estas nur unu el multaj en sistemoj IoT-F2C.
Multi-protokolaj solvoj
Ununuraj protokolsolvoj estas popularaj pro sia pli facila efektivigo. Sed estas klare, ke en sistemoj IoT-F2C havas sencon kombini malsamajn protokolojn. La ideo estas, ke malsamaj protokoloj povas funkcii je malsamaj niveloj. Prenu, ekzemple, tri abstraktaĵojn: la tavoloj de IoT, nebulo kaj nuba komputado. Aparatoj ĉe la IoT-nivelo estas ĝenerale konsiderataj limigitaj. Por ĉi tiu superrigardo, ni konsideru IoT-nivelojn kiel la plej limigitajn, nubojn la malplej limigitajn, kaj nebulkomputadon kiel "ie en la mezo". Rezultas tiam, ke inter IoT kaj nebulaj abstraktaĵoj, nunaj protokolaj solvoj inkluzivas MQTT, CoAP kaj XMPP. Inter nebulo kaj nubo, aliflanke, AMQP estas unu el la ĉefaj protokoloj uzataj, kune kun REST HTTP, kiu pro sia fleksebleco ankaŭ estas uzata inter IoT kaj nebultavoloj.
La ĉefa problemo ĉi tie estas la kunfunkciebleco de protokoloj kaj la facileco transdoni mesaĝojn de unu protokolo al alia. Ideale, en la estonteco, la arkitekturo de Interreto de Aĵoj-sistemo kun nubo kaj nebulresursoj estos sendependa de la komunika protokolo uzata kaj certigos bonan kunfunkcieblecon inter malsamaj protokoloj.
Ĉar ĉi tio ne estas nuntempe la kazo, estas senco kombini protokolojn, kiuj ne havas signifajn diferencojn. Tiucele, unu ebla solvo baziĝas sur kombinaĵo de du protokoloj, kiuj sekvas la saman arkitekturan stilon, REST HTTP kaj CoAP. Alia proponita solvo baziĝas sur kombinaĵo de du protokoloj kiuj ofertas publikigi-aboni komunikadon, MQTT kaj AMQP. Uzante similajn konceptojn (kaj MQTT kaj AMQP uzas makleristojn, CoAP kaj HTTP uzas REST) faciligas ĉi tiujn kombinaĵojn pli facile efektivigi kaj postulas malpli da integriga penado.
Figuro (a) montras du modelojn bazitajn sur peto-respondo, HTTP kaj CoAP, kaj ilian eblan lokigon en solvo IoT-F2C. Ĉar HTTP estas unu el la plej konataj kaj adoptitaj protokoloj en modernaj retoj, estas neverŝajne ke ĝi estos tute anstataŭigita per aliaj mesaĝaj protokoloj. Inter la nodoj reprezentantaj potencajn aparatojn, kiuj sidas inter la nubo kaj la nebulo, REST HTTP estas inteligenta solvo.
Aliflanke, por aparatoj kun limigitaj komputikresursoj kiuj komunikas inter la Nebulo kaj IoT tavoloj, estas pli efika uzi CoAP. Unu el la grandaj avantaĝoj de CoAP estas fakte ĝia kongruo kun HTTP, ĉar ambaŭ protokoloj baziĝas sur REST-principoj.
Figuro (b) montras du publikigi-aboni komunikadmodelojn en la sama scenaro, inkluzive de MQTT kaj AMQP. Kvankam ambaŭ protokoloj povus hipoteze esti uzitaj por komunikado inter nodoj ĉe ĉiu abstrakta tavolo, ilia pozicio devus esti determinita surbaze de efikeco. MQTT estis desegnita kiel malpeza protokolo por aparatoj kun limigitaj komputikaj rimedoj, do ĝi povas esti uzata por komunikado IoT-Fog. AMQP estas pli taŭga por pli potencaj aparatoj, kiuj ideale poziciigus ĝin inter nebulo kaj nubaj nodoj. Anstataŭ MQTT, la protokolo XMPP povas esti uzata en IoT ĉar ĝi estas konsiderata malpeza. Sed ĝi ne estas tiel vaste uzata en tiaj scenaroj.
trovoj
Estas neverŝajne, ke unu el la diskutitaj protokoloj sufiĉos por kovri ĉiujn komunikadojn en sistemo, de aparatoj kun limigitaj komputikaj rimedoj ĝis nubaj serviloj. La studo trovis, ke la du plej promesplenaj opcioj, kiujn programistoj plej uzas, estas MQTT kaj RESTful HTTP. Ĉi tiuj du protokoloj ne nur estas la plej maturaj kaj stabilaj, sed ankaŭ inkluzivas multajn bone dokumentitajn kaj sukcesajn efektivigojn kaj retajn rimedojn.
Pro ĝia stabileco kaj simpla agordo, MQTT estas protokolo, kiu pruvis sian superan agadon laŭlonge de la tempo kiam uzata ĉe la IoT-nivelo kun limigitaj aparatoj. En partoj de la sistemo kie limigita komunikado kaj bateriokonsumo ne estas problemo, kiel kelkaj nebuldomajnoj kaj plej multe de la nuba komputado, RESTful HTTP estas facila elekto. CoAP ankaŭ devus esti konsiderata ĉar ĝi ankaŭ rapide evoluas kiel IoT mesaĝa normo kaj verŝajne ĝi atingos nivelon de stabileco kaj matureco simila al MQTT kaj HTTP en proksima estonteco. Sed la normo nuntempe evoluas, kiu venas kun mallongperspektivaj kongruaj problemoj.
Kion alian vi povas legi en la blogo?
→
→
→
→
→
Abonu nian -kanalo, por ne maltrafi la sekvan artikolon! Ni skribas ne pli ol dufoje semajne kaj nur pri komerco.
fonto: www.habr.com