Mae datblygiad technolegau ym maes meddalwedd a chaledwedd, ymddangosiad protocolau cyfathrebu newydd wedi arwain at ehangu Rhyngrwyd Pethau (IoT). Mae nifer y dyfeisiau'n cynyddu o ddydd i ddydd ac maent yn cynhyrchu llawer iawn o ddata. Felly, mae angen pensaernïaeth system gyfleus sy'n gallu prosesu, storio a throsglwyddo'r data hwn.
Nawr mae gwasanaethau cwmwl yn cael eu defnyddio at y dibenion hyn. Fodd bynnag, gall y patrwm cyfrifiadurol niwl cynyddol boblogaidd (Niwl) ategu atebion cwmwl trwy raddio ac optimeiddio seilwaith IoT.
Mae cymylau yn gallu cwmpasu'r rhan fwyaf o geisiadau IoT. Er enghraifft, i ddarparu monitro gwasanaethau, prosesu cyflym o unrhyw swm o ddata a gynhyrchir gan ddyfeisiau, yn ogystal â'u delweddu. Mae cyfrifiadura niwl yn fwy effeithiol wrth ddatrys problemau amser real. Maent yn darparu ymateb cyflym i geisiadau a chyn lleied â phosibl o hwyrni wrth brosesu data. Hynny yw, mae Niwl yn ategu'r “cymylau” ac yn ehangu ei alluoedd.
Fodd bynnag, mae'r prif gwestiwn yn wahanol: sut y dylai hyn i gyd ryngweithio yng nghyd-destun IoT? Pa brotocolau cyfathrebu fydd fwyaf effeithiol wrth weithio mewn system gyfun IoT-Fog-Cloud?
Er gwaethaf goruchafiaeth ymddangosiadol HTTP, mae nifer fawr o atebion eraill yn cael eu defnyddio mewn systemau IoT, Niwl a Chwmwl. Mae hyn oherwydd bod yn rhaid i IoT gyfuno ymarferoldeb amrywiaeth o synwyryddion dyfais â diogelwch, cydnawsedd a gofynion eraill defnyddwyr.
Ond yn syml, nid oes un syniad am bensaernïaeth gyfeirio a safon cyfathrebu. Felly, creu protocol newydd neu addasu un presennol ar gyfer tasgau IoT penodol yw un o'r tasgau pwysicaf sy'n wynebu'r gymuned TG.
Pa brotocolau sy'n cael eu defnyddio ar hyn o bryd a beth allant ei gynnig? Gadewch i ni chyfrif i maes. Ond yn gyntaf, gadewch i ni drafod egwyddorion yr ecosystem lle mae cymylau, niwl a Rhyngrwyd pethau'n rhyngweithio.
Pensaernïaeth Niwl-i-Cwmwl IoT (F2C).
Mae'n debyg eich bod wedi sylwi faint o ymdrech sy'n cael ei rhoi i archwilio'r manteision a'r buddion sy'n gysylltiedig â rheolaeth glyfar a chydgysylltiedig o IoT, cwmwl a niwl. Os na, yna dyma dair menter safoni: , и .
Os mai dim ond 2 lefel a ystyriwyd yn flaenorol, cymylau a dyfeisiau diwedd, yna mae'r bensaernïaeth arfaethedig yn cyflwyno lefel newydd - cyfrifiadura niwl. Yn yr achos hwn, gellir rhannu'r lefel niwl yn sawl is-lefel, yn dibynnu ar fanylion yr adnoddau neu set o bolisïau sy'n pennu'r defnydd o wahanol ddyfeisiau yn yr is-lefelau hyn.
Sut olwg allai fod ar y tyniad hwn? Dyma ecosystem IoT-Fog-Cloud nodweddiadol. Mae dyfeisiau IoT yn anfon data i weinyddion cyflymach a dyfeisiau cyfrifiadurol i ddatrys problemau sy'n gofyn am hwyrni isel. Yn yr un system, mae cymylau yn gyfrifol am ddatrys problemau sy'n gofyn am lawer iawn o adnoddau cyfrifiadurol neu ofod storio data.
Gall ffonau clyfar, oriorau clyfar a theclynnau eraill fod yn rhan o'r IoT hefyd. Ond mae dyfeisiau o'r fath, fel rheol, yn defnyddio protocolau cyfathrebu perchnogol gan ddatblygwyr mawr. Mae'r data IoT a gynhyrchir yn cael ei drosglwyddo i'r haen niwl trwy brotocol REST HTTP, sy'n darparu hyblygrwydd a rhyngweithrededd wrth greu gwasanaethau RESTful. Mae hyn yn bwysig yng ngoleuni'r angen i sicrhau cydweddoldeb yn ôl â'r seilwaith cyfrifiadurol presennol sy'n rhedeg ar gyfrifiaduron lleol, gweinyddwyr neu glwstwr o weinyddion. Mae adnoddau lleol, a elwir yn “nodau niwl,” yn hidlo'r data a dderbyniwyd a'i brosesu'n lleol neu ei anfon i'r cwmwl i gael cyfrifiadau pellach.
Mae cymylau yn cefnogi gwahanol brotocolau cyfathrebu, y mwyaf cyffredin yw AMQP a REST HTTP. Gan fod HTTP yn adnabyddus ac wedi'i deilwra ar gyfer y Rhyngrwyd, gall y cwestiwn godi: “Oni ddylem ei ddefnyddio i weithio gydag IoT a niwl?” Fodd bynnag, mae gan y protocol hwn broblemau perfformiad. Mwy am hyn yn nes ymlaen.
Yn gyffredinol, mae 2 fodel o brotocolau cyfathrebu sy'n addas ar gyfer y system sydd ei hangen arnom. Y rhain yw cais-ymateb a chyhoeddi-tanysgrifio. Mae'r model cyntaf yn fwy adnabyddus, yn enwedig mewn pensaernïaeth gweinydd-cleient. Mae'r cleient yn gofyn am wybodaeth gan y gweinydd, ac mae'r gweinydd yn derbyn y cais, yn ei brosesu ac yn dychwelyd neges ymateb. Mae protocolau REST HTTP a CoAP yn gweithredu ar y model hwn.
Deilliodd yr ail fodel o'r angen i ddarparu cyplydd asyncronaidd, gwasgaredig, rhydd rhwng y ffynonellau sy'n cynhyrchu data a derbynwyr y data hwn.
Mae'r model yn rhagdybio tri chyfranogwr: cyhoeddwr (ffynhonnell ddata), brocer (dosbarthwr) a thanysgrifiwr (derbynnydd). Yma, nid oes rhaid i'r cleient sy'n gweithredu fel tanysgrifiwr ofyn am wybodaeth gan y gweinydd. Yn lle anfon ceisiadau, mae'n tanysgrifio i rai digwyddiadau yn y system trwy frocer, sy'n gyfrifol am hidlo'r holl negeseuon sy'n dod i mewn a'u llwybro rhwng cyhoeddwyr a thanysgrifwyr. Ac mae'r cyhoeddwr, pan fydd digwyddiad yn digwydd ynghylch pwnc penodol, yn ei gyhoeddi i'r brocer, sy'n anfon data ar y pwnc y gofynnwyd amdano i'r tanysgrifiwr.
Yn y bôn, mae'r bensaernïaeth hon yn seiliedig ar ddigwyddiadau. Ac mae'r model rhyngweithio hwn yn ddiddorol ar gyfer cymwysiadau yn IoT, cwmwl, niwl oherwydd ei allu i ddarparu scalability a symleiddio'r rhyng-gysylltiad rhwng gwahanol ddyfeisiau, cefnogi cyfathrebu deinamig llawer-i-lawer a chyfathrebu asyncronig. Mae rhai o'r protocolau negeseuon safonol mwyaf adnabyddus sy'n defnyddio model tanysgrifio cyhoeddi yn cynnwys MQTT, AMQP, a DDS.
Yn amlwg, mae gan y model cyhoeddi-danysgrifio lawer o fanteision:
- Nid oes angen i gyhoeddwyr a thanysgrifwyr wybod am fodolaeth ei gilydd;
- Gall un tanysgrifiwr dderbyn gwybodaeth o lawer o wahanol gyhoeddiadau, a gall un cyhoeddwr anfon data at lawer o wahanol danysgrifwyr (egwyddor llawer-i-lawer);
- Nid oes rhaid i'r cyhoeddwr a'r tanysgrifiwr fod yn weithredol ar yr un pryd i gyfathrebu, oherwydd bydd y brocer (yn gweithio fel system giwio) yn gallu storio'r neges ar gyfer cleientiaid nad ydynt wedi'u cysylltu â'r rhwydwaith ar hyn o bryd.
Fodd bynnag, mae gan y model ymateb i gais ei gryfderau hefyd. Mewn achosion lle nad yw gallu ochr y gweinydd i ymdrin â cheisiadau cleient lluosog yn broblem, mae'n gwneud synnwyr i ddefnyddio atebion profedig, dibynadwy.
Mae yna hefyd brotocolau sy'n cefnogi'r ddau fodel. Er enghraifft, XMPP a HTTP 2.0, sy'n cefnogi'r opsiwn "gwthio gweinydd". Mae'r IETF hefyd wedi rhyddhau CoAP. Mewn ymgais i ddatrys y broblem negeseuon, mae nifer o atebion eraill wedi'u creu, megis y protocol WebSockets neu'r defnydd o'r protocol HTTP dros QUIC (Cysylltiadau Rhyngrwyd Cyflym CDU).
Yn achos WebSockets, er ei fod yn cael ei ddefnyddio i drosglwyddo data mewn amser real o weinydd i gleient gwe ac yn darparu cysylltiadau parhaus â chyfathrebu deugyfeiriadol ar yr un pryd, nid yw wedi'i fwriadu ar gyfer dyfeisiau ag adnoddau cyfrifiadurol cyfyngedig. Mae QUIC hefyd yn haeddu sylw, gan fod y protocol trafnidiaeth newydd yn darparu llawer o gyfleoedd newydd. Ond gan nad yw QUIC wedi'i safoni eto, mae'n gynamserol rhagweld ei gymhwysiad posibl a'i effaith ar atebion IoT. Felly rydyn ni'n cadw WebSockets a QUIC mewn cof gyda golwg ar y dyfodol, ond ni fyddwn yn ei astudio'n fanylach am y tro.
Pwy yw'r mwyaf ciwt yn y byd: cymharu protocolau
Nawr, gadewch i ni siarad am gryfderau a gwendidau protocolau. Wrth edrych ymlaen, gadewch inni ar unwaith amau nad oes un arweinydd clir. Mae gan bob protocol rai manteision/anfanteision.
Amser ymateb
Un o nodweddion pwysicaf protocolau cyfathrebu, yn enwedig mewn perthynas â Rhyngrwyd Pethau, yw amser ymateb. Ond ymhlith y protocolau presennol, nid oes enillydd clir sy'n dangos y lefel leiaf o hwyrni wrth weithio o dan amodau gwahanol. Ond mae yna griw cyfan o ymchwil a chymariaethau o alluoedd protocol.
Er enghraifft, dangosodd cymariaethau o effeithiolrwydd HTTP a MQTT wrth weithio gydag IoT fod yr amser ymateb ar gyfer ceisiadau am MQTT yn llai nag ar gyfer HTTP. A phryd Datgelodd amser taith gron (RTT) MQTT a CoAP fod RTT cyfartalog CoAP 20% yn llai na MQTT.
Arall gyda RTT ar gyfer y protocolau MQTT a CoAP ei gynnal mewn dwy senario: rhwydwaith lleol a rhwydwaith IoT. Daeth i'r amlwg bod yr RTT cyfartalog 2-3 gwaith yn uwch mewn rhwydwaith IoT. Dangosodd MQTT gyda QoS0 ganlyniad is o'i gymharu â CoAP, a dangosodd MQTT gyda QoS1 RTT uwch oherwydd ACKs yn yr haenau cais a thrafnidiaeth. Ar gyfer gwahanol lefelau QoS, roedd hwyrni rhwydwaith heb dagfeydd yn filieiliadau ar gyfer MQTT, a channoedd o ficroeiliadau ar gyfer CoAP. Fodd bynnag, mae'n werth cofio, wrth weithio ar rwydweithiau llai dibynadwy, y bydd MQTT sy'n rhedeg ar ben TCP yn dangos canlyniad hollol wahanol.
roedd amser ymateb ar gyfer protocolau AMQP a MQTT trwy gynyddu'r llwyth tâl yn dangos bod y lefel hwyrni bron yr un fath gyda llwyth ysgafn. Ond wrth drosglwyddo llawer iawn o ddata, mae MQTT yn dangos amseroedd ymateb byrrach. mewn un arall Cymharwyd CoAP â HTTP mewn senario cyfathrebu peiriant-i-beiriant gyda dyfeisiau wedi'u gosod ar ben cerbydau â synwyryddion nwy, synwyryddion tywydd, synwyryddion lleoliad (GPS) a rhyngwyneb rhwydwaith symudol (GPRS). Roedd yr amser sydd ei angen i drosglwyddo neges CoAP dros y rhwydwaith symudol bron deirgwaith yn fyrrach na'r amser sydd ei angen i ddefnyddio negeseuon HTTP.
Mae astudiaethau wedi'u cynnal a oedd yn cymharu nid dau, ond tri phrotocol. Er enghraifft, perfformiad protocolau IoT MQTT, DDS a CoAP mewn senario cais meddygol gan ddefnyddio efelychydd rhwydwaith. Perfformiodd DDS yn well na MQTT o ran hwyrni telemetreg a brofwyd o dan amrywiaeth o amodau rhwydwaith gwael. Gweithiodd CoAP ar sail CDU yn dda ar gyfer ceisiadau a oedd angen amseroedd ymateb cyflym, fodd bynnag, oherwydd ei fod yn seiliedig ar y CDU, roedd colled pecynnau anrhagweladwy sylweddol.
Lled band
Cynhaliwyd MQTT a CoAP o ran effeithlonrwydd lled band fel cyfrifiad o gyfanswm y data a drosglwyddir fesul neges. Mae CoAP wedi dangos trwybwn is na MQTT wrth drosglwyddo negeseuon bach. Ond wrth gymharu effeithlonrwydd protocolau o ran cymhareb nifer y bytes gwybodaeth ddefnyddiol i gyfanswm nifer y beitau a drosglwyddwyd, daeth CoAP yn fwy effeithiol.
Ar gan ddefnyddio MQTT, DDS (gyda TCP fel y protocol trafnidiaeth) a lled band CoAP, canfuwyd bod CoAP yn gyffredinol yn dangos defnydd lled band cymharol is, nad oedd yn cynyddu gyda mwy o golled pecynnau rhwydwaith na mwy o hwyrni rhwydwaith, yn wahanol i MQTT a DDS, lle'r oedd cynnydd yn y defnydd o led band yn y senarios a grybwyllwyd. Roedd senario arall yn cynnwys nifer fawr o ddyfeisiau'n trosglwyddo data ar yr un pryd, sy'n nodweddiadol mewn amgylcheddau IoT. Dangosodd y canlyniadau ei bod yn well defnyddio CoAP ar gyfer defnydd uwch.
O dan lwyth ysgafn, defnyddiodd CoAP y lled band lleiaf, ac yna MQTT a REST HTTP. Fodd bynnag, pan gynyddodd maint y llwythi tâl, cafodd REST HTTP y canlyniadau gorau.
Defnyddio Pŵer
Mae mater y defnydd o ynni bob amser yn bwysig iawn, ac yn enwedig mewn system IoT. Os Tra bod MQTT a HTTP yn defnyddio trydan, mae HTTP yn defnyddio llawer mwy. Ac mae CoAP yn fwy o'i gymharu â MQTT, gan ganiatáu rheoli pŵer. Fodd bynnag, mewn senarios syml, mae MQTT yn fwy addas ar gyfer cyfnewid gwybodaeth mewn rhwydweithiau Rhyngrwyd Pethau, yn enwedig os nad oes unrhyw gyfyngiadau pŵer.
Canfu arbrawf a oedd yn cymharu galluoedd AMQP a MQTT ar wely prawf rhwydwaith diwifr symudol neu ansefydlog fod AMQP yn cynnig mwy o alluoedd diogelwch tra bod MQTT yn fwy ynni-effeithlon.
diogelwch
Mae diogelwch yn fater hollbwysig arall a godwyd wrth astudio pwnc Rhyngrwyd Pethau a chyfrifiadura niwl/cwmwl. Mae'r mecanwaith diogelwch fel arfer yn seiliedig ar TLS yn HTTP, MQTT, AMQP a XMPP, neu DTLS yn CoAP, ac mae'n cefnogi'r ddau amrywiad DDS.
Mae TLS a DTLS yn dechrau gyda'r broses o sefydlu cyfathrebu rhwng ochrau'r cleient a'r gweinydd i gyfnewid switiau seiffrau ac allweddi â chymorth. Mae'r ddwy ochr yn negodi setiau i sicrhau bod cyfathrebu pellach yn digwydd ar sianel ddiogel. Mae'r gwahaniaeth rhwng y ddau yn gorwedd mewn mân addasiadau sy'n caniatáu i DTLS seiliedig ar CDU weithio dros gysylltiad annibynadwy.
Ar Canfu sawl gweithrediad gwahanol o TLS a DTLS fod TLS yn gwneud gwaith gwell. Roedd ymosodiadau ar DTLS yn fwy llwyddiannus oherwydd ei oddefgarwch gwallau.
Fodd bynnag, y broblem fwyaf gyda'r protocolau hyn yw nad oeddent wedi'u cynllunio'n wreiddiol i'w defnyddio yn IoT ac nad oeddent wedi'u bwriadu i weithio yn y niwl neu'r cwmwl. Trwy ysgwyd llaw, maent yn ychwanegu traffig ychwanegol gyda phob sefydliad cysylltu, sy'n draenio adnoddau cyfrifiadurol. Ar gyfartaledd, mae cynnydd o 6,5% ar gyfer TLS ac 11% ar gyfer DTLS mewn gorbenion o gymharu â chyfathrebu heb haen ddiogelwch. Mewn amgylcheddau llawn adnoddau, sydd fel arfer wedi'u lleoli ar lefel, ni fydd hyn yn broblem, ond yn y cysylltiad rhwng IoT a lefel niwl, mae hyn yn dod yn gyfyngiad pwysig.
Beth i'w ddewis? Nid oes ateb clir. Ymddengys mai MQTT a HTTP yw'r protocolau mwyaf addawol gan eu bod yn cael eu hystyried yn atebion IoT mwy aeddfed a mwy sefydlog o gymharu â phrotocolau eraill.
Atebion yn seiliedig ar brotocol cyfathrebu unedig
Mae gan yr arfer o ddatrysiad un-protocol lawer o anfanteision. Er enghraifft, efallai na fydd protocol sy'n addas ar gyfer amgylchedd cyfyngedig yn gweithio mewn parth sydd â gofynion diogelwch llym. Gyda hyn mewn golwg, rydym yn cael ein gadael i daflu bron pob datrysiad un-protocol posibl yn yr ecosystem Niwl-i-Cloud yn IoT, ac eithrio MQTT a REST HTTP.
REST HTTP fel ateb un-protocol
Mae yna enghraifft dda o sut mae ceisiadau ac ymatebion REST HTTP yn rhyngweithio yn y gofod IoT-to-Fog: . Mae gan yr anifeiliaid synwyryddion gwisgadwy (cleient IoT, C) a chânt eu rheoli trwy gyfrifiadura cwmwl gan system ffermio glyfar (Gweinydd Niwl, S).
Mae pennawd y dull POST yn nodi'r adnodd i'w addasu (/fferm/anifeiliaid) yn ogystal â'r fersiwn HTTP a'r math o gynnwys, sydd yn yr achos hwn yn wrthrych JSON sy'n cynrychioli'r fferm anifeiliaid y mae'r system i'w rheoli (Dulcinea/buwch) . Mae'r ymateb gan y gweinydd yn nodi bod y cais wedi bod yn llwyddiannus trwy anfon cod statws HTTPS 201 (adnodd wedi'i greu). Rhaid i'r dull GET nodi'r adnodd y gofynnwyd amdano yn yr URI yn unig (er enghraifft, /farm/animals/1), sy'n dychwelyd cynrychiolaeth JSON o'r anifail gyda'r ID hwnnw o'r gweinydd.
Defnyddir y dull PUT pan fydd angen diweddaru rhywfaint o gofnod adnoddau penodol. Yn yr achos hwn, mae'r adnodd yn nodi'r URI ar gyfer newid y paramedr a'r gwerth presennol (er enghraifft, yn nodi bod y fuwch yn cerdded ar hyn o bryd, /farm/animals/1?state=walking). Yn olaf, mae'r dull DELETE yn cael ei ddefnyddio'n gyfartal â'r dull GET, ond yn syml mae'n dileu'r adnodd o ganlyniad i'r llawdriniaeth.
MQTT fel ateb un-protocol
Gadewch i ni gymryd yr un fferm smart, ond yn lle REST HTTP rydym yn defnyddio'r protocol MQTT. Mae gweinydd lleol gyda llyfrgell Mosquitto wedi'i gosod yn gweithredu fel brocer. Yn yr enghraifft hon, mae cyfrifiadur syml (y cyfeirir ato fel gweinydd y fferm) Raspberry Pi yn gwasanaethu fel cleient MQTT, a weithredir trwy osodiad llyfrgell Paho MQTT, sy'n gwbl gydnaws â brocer Mosquitto.
Mae'r cleient hwn yn cyfateb i haen tynnu IoT sy'n cynrychioli dyfais gyda galluoedd synhwyro a chyfrifiadura. Mae'r cyfryngwr, ar y llaw arall, yn cyfateb i lefel uwch o dynnu, sy'n cynrychioli nod cyfrifiadurol niwl a nodweddir gan fwy o allu prosesu a storio.
Yn y senario fferm glyfar arfaethedig, mae'r Raspberry Pi yn cysylltu â'r cyflymromedr, GPS, a synwyryddion tymheredd ac yn cyhoeddi data o'r synwyryddion hyn i nod niwl. Fel y gwyddoch fwy na thebyg, mae MQTT yn trin pynciau fel hierarchaeth. Gall un cyhoeddwr MQTT gyhoeddi negeseuon i set benodol o bynciau. Yn ein hachos ni mae tri ohonyn nhw. Ar gyfer synhwyrydd sy'n mesur y tymheredd mewn ysgubor anifeiliaid, mae'r cleient yn dewis thema (fferm anifeiliaid / sied / tymheredd). Ar gyfer synwyryddion sy'n mesur lleoliad GPS a symudiad anifeiliaid trwy'r cyflymromedr, bydd y cleient yn cyhoeddi diweddariadau i (fferm anifeiliaid/anifail/GPS) a (fferm/anifeiliaid/symudiad).
Bydd y wybodaeth hon yn cael ei throsglwyddo i'r brocer, a all ei storio dros dro mewn cronfa ddata leol rhag ofn y bydd tanysgrifiwr arall â diddordeb yn dod ymlaen yn ddiweddarach.
Yn ogystal â'r gweinydd lleol, sy'n gweithredu fel brocer MQTT yn y niwl ac y mae Raspberry Pis, sy'n gweithredu fel cleientiaid MQTT, yn anfon data synhwyrydd, efallai y bydd brocer MQTT arall ar lefel y cwmwl. Yn yr achos hwn, gellir storio'r wybodaeth a drosglwyddir i'r brocer lleol dros dro mewn cronfa ddata leol a / neu ei hanfon i'r cwmwl. Defnyddir y brocer MQTT niwl yn y sefyllfa hon i gysylltu'r holl ddata â brocer cwmwl MQTT. Gyda'r bensaernïaeth hon, gellir tanysgrifio i ddefnyddiwr cais symudol i'r ddau frocer.
Os bydd y cysylltiad ag un o'r broceriaid (er enghraifft, cwmwl) yn methu, bydd y defnyddiwr terfynol yn derbyn gwybodaeth gan y llall (niwl). Mae hyn yn nodwedd nodweddiadol o systemau cyfrifiadurol niwl a cwmwl cyfun. Yn ddiofyn, gellir ffurfweddu'r app symudol i gysylltu â'r brocer MQTT niwl yn gyntaf, ac os bydd hynny'n methu, i gysylltu â brocer MQTT cwmwl. Mae'r datrysiad hwn yn un yn unig o lawer mewn systemau IoT-F2C.
Datrysiadau aml-brotocol
Mae datrysiadau protocol sengl yn boblogaidd oherwydd eu bod yn haws eu gweithredu. Ond mae'n amlwg ei bod yn gwneud synnwyr mewn systemau IoT-F2C i gyfuno gwahanol brotocolau. Y syniad yw y gall protocolau gwahanol weithredu ar wahanol lefelau. Cymerwch, er enghraifft, dri thyniad: haenau IoT, niwl a chyfrifiadura cwmwl. Yn gyffredinol, ystyrir bod dyfeisiau ar lefel IoT yn gyfyngedig. Ar gyfer y trosolwg hwn, gadewch i ni ystyried haenau IoT fel yr haenau mwyaf cyfyngedig, y cymylu lleiaf cyfyngedig, a chyfrifiadura niwl fel "rhywle yn y canol." Mae'n ymddangos felly, rhwng tyniadau IoT a niwl, mae datrysiadau protocol cyfredol yn cynnwys MQTT, CoAP a XMPP. Rhwng niwl a chwmwl, ar y llaw arall, AMQP yw un o'r prif brotocolau a ddefnyddir, ynghyd â REST HTTP, sydd oherwydd ei hyblygrwydd hefyd yn cael ei ddefnyddio rhwng haenau IoT a niwl.
Y brif broblem yma yw rhyngweithrededd protocolau a rhwyddineb trosglwyddo negeseuon o un protocol i'r llall. Yn ddelfrydol, yn y dyfodol, bydd pensaernïaeth system Rhyngrwyd Pethau gydag adnoddau cwmwl a niwl yn annibynnol ar y protocol cyfathrebu a ddefnyddir a bydd yn sicrhau rhyngweithrededd da rhwng gwahanol brotocolau.
Gan nad yw hyn yn wir ar hyn o bryd, mae'n gwneud synnwyr i gyfuno protocolau nad oes ganddynt wahaniaethau sylweddol. I'r perwyl hwn, mae un ateb posibl yn seiliedig ar gyfuniad o ddau brotocol sy'n dilyn yr un arddull bensaernïol, REST HTTP a CoAP. Mae datrysiad arfaethedig arall yn seiliedig ar gyfuniad o ddau brotocol sy'n cynnig cyfathrebu cyhoeddi-tanysgrifio, MQTT ac AMQP. Mae defnyddio cysyniadau tebyg (mae broceriaid defnydd MQTT ac AMQP, CoAP a HTTP yn defnyddio REST) yn gwneud y cyfuniadau hyn yn haws i'w gweithredu ac yn gofyn am lai o ymdrech integreiddio.
Mae Ffigur (a) yn dangos dau fodel sy’n seiliedig ar gais-ymateb, HTTP a CoAP, a’u lleoliad posibl mewn datrysiad IoT-F2C. Gan fod HTTP yn un o'r protocolau mwyaf adnabyddus a mabwysiedig ar rwydweithiau modern, mae'n annhebygol y caiff ei ddisodli'n llwyr gan brotocolau negeseuon eraill. Ymhlith y nodau sy'n cynrychioli dyfeisiau pwerus sy'n eistedd rhwng y cwmwl a'r niwl, mae REST HTTP yn ddatrysiad craff.
Ar y llaw arall, ar gyfer dyfeisiau ag adnoddau cyfrifiadurol cyfyngedig sy'n cyfathrebu rhwng yr haenau Niwl ac IoT, mae'n fwy effeithlon defnyddio CoAP. Un o fanteision mawr CoAP mewn gwirionedd yw ei gydnawsedd â HTTP, gan fod y ddau brotocol yn seiliedig ar egwyddorion REST.
Mae Ffigur (b) yn dangos dau fodel cyfathrebu cyhoeddi-danysgrifio yn yr un senario, gan gynnwys MQTT ac AMQP. Er y gellid defnyddio'r ddau brotocol yn ddamcaniaethol ar gyfer cyfathrebu rhwng nodau ar bob haen tynnu, dylid pennu eu safle yn seiliedig ar berfformiad. Dyluniwyd MQTT fel protocol ysgafn ar gyfer dyfeisiau ag adnoddau cyfrifiadurol cyfyngedig, felly gellir ei ddefnyddio ar gyfer cyfathrebu IoT-Fog. Mae AMQP yn fwy addas ar gyfer dyfeisiau mwy pwerus, a fyddai'n ddelfrydol yn ei leoli rhwng nodau niwl a chymylau. Yn lle MQTT, gellir defnyddio'r protocol XMPP yn IoT gan ei fod yn cael ei ystyried yn ysgafn. Ond nid yw'n cael ei ddefnyddio mor eang mewn senarios o'r fath.
Canfyddiadau
Mae'n annhebygol y bydd un o'r protocolau a drafodir yn ddigonol i gwmpasu'r holl gyfathrebiadau mewn system, o ddyfeisiau ag adnoddau cyfrifiadurol cyfyngedig i weinyddion cwmwl. Canfu'r astudiaeth mai'r ddau opsiwn mwyaf addawol y mae datblygwyr yn eu defnyddio fwyaf yw MQTT a RESTful HTTP. Nid yn unig y ddau brotocol hyn yw'r rhai mwyaf aeddfed a sefydlog, ond maent hefyd yn cynnwys llawer o weithrediadau ac adnoddau ar-lein llwyddiannus sydd wedi'u dogfennu'n dda.
Oherwydd ei sefydlogrwydd a'i ffurfweddiad syml, mae MQTT yn brotocol sydd wedi profi ei berfformiad uwch dros amser pan gaiff ei ddefnyddio ar lefel IoT gyda dyfeisiau cyfyngedig. Mewn rhannau o'r system lle nad yw cyfathrebu cyfyngedig a defnydd batri yn broblem, megis rhai parthau niwl a'r rhan fwyaf o gyfrifiadura cwmwl, mae RESTful HTTP yn ddewis hawdd. Dylid ystyried CoAP hefyd gan ei fod hefyd yn datblygu'n gyflym fel safon negeseuon IoT ac mae'n debygol y bydd yn cyrraedd lefel o sefydlogrwydd ac aeddfedrwydd tebyg i MQTT a HTTP yn y dyfodol agos. Ond mae'r safon yn esblygu ar hyn o bryd, sy'n dod â materion cydnawsedd tymor byr.
Beth arall allwch chi ei ddarllen ar y blog?
→
→
→
→
→
Tanysgrifiwch i'n -sianel, er mwyn peidio â cholli'r erthygl nesaf! Nid ydym yn ysgrifennu mwy na dwywaith yr wythnos a dim ond ar fusnes.
Ffynhonnell: hab.com