Ang pag-unlad ng mga teknolohiya sa larangan ng software at hardware, ang paglitaw ng mga bagong protocol ng komunikasyon ay humantong sa pagpapalawak ng Internet of Things (IoT). Ang bilang ng mga aparato ay lumalaki araw-araw at sila ay bumubuo ng isang malaking halaga ng data. Samakatuwid, mayroong pangangailangan para sa isang maginhawang arkitektura ng system na may kakayahang pagproseso, pag-iimbak at pagpapadala ng data na ito.
Ngayon ang mga serbisyo ng ulap ay ginagamit para sa mga layuning ito. Gayunpaman, ang lalong sikat na fog computing paradigm (Fog) ay maaaring umakma sa mga solusyon sa ulap sa pamamagitan ng pag-scale at pag-optimize ng imprastraktura ng IoT.
Ang mga ulap ay may kakayahang saklawin ang karamihan sa mga kahilingan sa IoT. Halimbawa, upang magbigay ng pagsubaybay sa mga serbisyo, mabilis na pagproseso ng anumang dami ng data na nabuo ng mga device, pati na rin ang kanilang visualization. Ang fog computing ay mas epektibo kapag nilulutas ang mga real-time na problema. Nagbibigay ang mga ito ng mabilis na pagtugon sa mga kahilingan at kaunting latency sa pagproseso ng data. Iyon ay, ang Fog ay umaakma sa "ulap" at nagpapalawak ng mga kakayahan nito.
Gayunpaman, iba ang pangunahing tanong: paano dapat makipag-ugnayan ang lahat ng ito sa konteksto ng IoT? Anong mga protocol ng komunikasyon ang magiging pinakaepektibo kapag nagtatrabaho sa isang pinagsamang IoT-Fog-Cloud system?
Sa kabila ng maliwanag na pangingibabaw ng HTTP, mayroong isang malaking bilang ng iba pang mga solusyon na ginagamit sa IoT, Fog at Cloud system. Ito ay dahil dapat pagsamahin ng IoT ang functionality ng iba't ibang sensor ng device sa seguridad, compatibility, at iba pang mga kinakailangan ng mga user.
Ngunit walang iisang ideya tungkol sa arkitektura ng sanggunian at pamantayan ng komunikasyon. Samakatuwid, ang paggawa ng bagong protocol o pagbabago ng umiiral na para sa mga partikular na gawain ng IoT ay isa sa pinakamahalagang gawain na kinakaharap ng komunidad ng IT.
Anong mga protocol ang kasalukuyang ginagamit at ano ang maiaalok ng mga ito? Alamin natin ito. Ngunit una, talakayin natin ang mga prinsipyo ng ecosystem kung saan nakikipag-ugnayan ang mga ulap, fog at ang Internet ng mga bagay.
IoT Fog-to-Cloud (F2C) Architecture
Marahil ay napansin mo kung gaano karaming pagsisikap ang ginagawa sa pagtuklas sa mga pakinabang at benepisyong nauugnay sa matalino at magkakaugnay na pamamahala ng IoT, cloud at fog. Kung hindi, narito ang tatlong hakbangin sa standardisasyon: , ΠΈ .
Kung dati ay 2 level lang ang isinasaalang-alang, clouds at end device, ang iminungkahing arkitektura ay nagpapakilala ng bagong level - fog computing. Sa kasong ito, ang antas ng fog ay maaaring hatiin sa ilang mga sublevel, depende sa mga detalye ng mga mapagkukunan o isang hanay ng mga patakaran na tumutukoy sa paggamit ng iba't ibang mga device sa mga sublevel na ito.
Ano kaya ang hitsura ng abstraction na ito? Narito ang isang tipikal na IoT-Fog-Cloud ecosystem. Ang mga IoT device ay nagpapadala ng data sa mas mabilis na mga server at computing device upang malutas ang mga problema na nangangailangan ng mababang latency. Sa parehong sistema, ang mga ulap ay may pananagutan sa paglutas ng mga problema na nangangailangan ng malaking halaga ng mga mapagkukunan sa pag-compute o espasyo sa imbakan ng data.
Ang mga smartphone, matalinong relo at iba pang gadget ay maaari ding maging bahagi ng IoT. Ngunit ang mga naturang device, bilang panuntunan, ay gumagamit ng mga proprietary na protocol ng komunikasyon mula sa malalaking developer. Ang nabuong data ng IoT ay inililipat sa fog layer sa pamamagitan ng REST HTTP protocol, na nagbibigay ng flexibility at interoperability kapag gumagawa ng mga RESTful na serbisyo. Mahalaga ito dahil sa pangangailangang tiyakin ang pabalik na pagkakatugma sa umiiral na imprastraktura ng computing na tumatakbo sa mga lokal na computer, server o isang cluster ng server. Ang mga lokal na mapagkukunan, na tinatawag na "fog nodes," ay sinasala ang natanggap na data at iproseso ito nang lokal o ipadala ito sa cloud para sa karagdagang mga kalkulasyon.
Sinusuportahan ng mga ulap ang iba't ibang mga protocol ng komunikasyon, ang pinakakaraniwan ay ang AMQP at REST HTTP. Dahil ang HTTP ay kilala at iniakma para sa Internet, ang tanong ay maaaring lumitaw: "hindi ba natin ito dapat gamitin upang gumana sa IoT at fog?" Gayunpaman, ang protocol na ito ay may mga isyu sa pagganap. Higit pa tungkol dito mamaya.
Sa pangkalahatan, mayroong 2 modelo ng mga protocol ng komunikasyon na angkop para sa system na kailangan namin. Ito ay kahilingan-tugon at mag-publish-subscribe. Ang unang modelo ay mas kilala, lalo na sa arkitektura ng server-client. Ang kliyente ay humihiling ng impormasyon mula sa server, at natatanggap ng server ang kahilingan, pinoproseso ito at nagbabalik ng isang mensahe ng tugon. Gumagana ang REST HTTP at CoAP protocol sa modelong ito.
Ang pangalawang modelo ay nagmula sa pangangailangang magbigay ng asynchronous, distributed, loose coupling sa pagitan ng mga source na bumubuo ng data at ng mga tatanggap ng data na ito.
Ipinapalagay ng modelo ang tatlong kalahok: isang publisher (data source), isang broker (dispatcher) at isang subscriber (receiver). Dito, ang kliyente na kumikilos bilang isang subscriber ay hindi kailangang humiling ng impormasyon mula sa server. Sa halip na magpadala ng mga kahilingan, nagsu-subscribe ito sa ilang partikular na kaganapan sa system sa pamamagitan ng isang broker, na responsable sa pag-filter ng lahat ng papasok na mensahe at pagruruta sa mga ito sa pagitan ng mga publisher at subscriber. At ang publisher, kapag naganap ang isang kaganapan tungkol sa isang partikular na paksa, ini-publish ito sa broker, na nagpapadala ng data sa hiniling na paksa sa subscriber.
Sa pangkalahatan, ang arkitektura na ito ay batay sa kaganapan. At ang modelo ng pakikipag-ugnayan na ito ay kawili-wili para sa mga application sa IoT, cloud, fog dahil sa kakayahang magbigay ng scalability at pasimplehin ang interconnection sa pagitan ng iba't ibang device, suportahan ang dynamic na marami-sa-maraming komunikasyon at asynchronous na komunikasyon. Ang ilan sa mga pinakakilalang standardized messaging protocol na gumagamit ng publish-subscribe na modelo ay kinabibilangan ng MQTT, AMQP, at DDS.
Malinaw, ang modelo ng pag-publish-subscribe ay may maraming mga pakinabang:
- Hindi kailangang malaman ng mga publisher at subscriber ang tungkol sa pagkakaroon ng isa't isa;
- Ang isang subscriber ay maaaring makatanggap ng impormasyon mula sa maraming iba't ibang publikasyon, at ang isang publisher ay maaaring magpadala ng data sa maraming iba't ibang mga subscriber (many-to-many na prinsipyo);
- Ang publisher at subscriber ay hindi kailangang maging aktibo sa parehong oras upang makipag-usap, dahil ang broker (nagtatrabaho bilang isang queuing system) ay makakapag-imbak ng mensahe para sa mga kliyente na kasalukuyang hindi nakakonekta sa network.
Gayunpaman, ang modelo ng kahilingan-tugon ay mayroon ding mga lakas nito. Sa mga kaso kung saan ang kakayahan ng panig ng server na pangasiwaan ang maraming kahilingan ng kliyente ay hindi isang isyu, makatuwirang gumamit ng mga napatunayan, maaasahang solusyon.
Mayroon ding mga protocol na sumusuporta sa parehong mga modelo. Halimbawa, ang XMPP at HTTP 2.0, na sumusuporta sa opsyong "server push". Ang IETF ay naglabas din ng isang CoAP. Sa pagtatangkang lutasin ang problema sa pagmemensahe, maraming iba pang solusyon ang nagawa, gaya ng WebSockets protocol o ang paggamit ng HTTP protocol sa QUIC (Quick UDP Internet Connections).
Sa kaso ng WebSockets, bagama't ginagamit ito upang maglipat ng data sa real time mula sa isang server patungo sa isang web client at nagbibigay ng patuloy na mga koneksyon na may sabay-sabay na bidirectional na komunikasyon, hindi ito inilaan para sa mga device na may limitadong mga mapagkukunan ng computing. Ang QUIC ay nararapat ding pansinin, dahil ang bagong transport protocol ay nagbibigay ng maraming bagong pagkakataon. Ngunit dahil hindi pa na-standardize ang QUIC, napaaga pa upang mahulaan ang posibleng aplikasyon at epekto nito sa mga solusyon sa IoT. Kaya't isinasaisip namin ang WebSockets at QUIC nang may mata sa hinaharap, ngunit hindi namin ito pag-aaralan nang mas detalyado sa ngayon.
Sino ang pinaka-cute sa mundo: paghahambing ng mga protocol
Ngayon pag-usapan natin ang mga kalakasan at kahinaan ng mga protocol. Pagtingin sa unahan, gumawa tayo agad ng reserbasyon na walang malinaw na pinuno. Ang bawat protocol ay may ilang mga pakinabang / disadvantages.
Oras ng pagtugon
Ang isa sa pinakamahalagang katangian ng mga protocol ng komunikasyon, lalo na may kaugnayan sa Internet of Things, ay ang oras ng pagtugon. Ngunit kabilang sa mga umiiral na protocol, walang malinaw na nagwagi na nagpapakita ng pinakamababang antas ng latency kapag nagtatrabaho sa ilalim ng iba't ibang mga kondisyon. Ngunit mayroong isang buong bungkos ng pananaliksik at paghahambing ng mga kakayahan sa protocol.
Halimbawa, ang mga paghahambing ng pagiging epektibo ng HTTP at MQTT kapag nagtatrabaho sa IoT ay nagpakita na ang oras ng pagtugon para sa mga kahilingan para sa MQTT ay mas mababa kaysa sa HTTP. At kailan Ang round trip time (RTT) ng MQTT at CoAP ay nagsiwalat na ang average na RTT ng CoAP ay 20% mas mababa kaysa sa MQTT.
Iba kasama ang RTT para sa mga protocol ng MQTT at CoAP ay isinagawa sa dalawang senaryo: lokal na network at IoT network. Ito ay lumabas na ang average na RTT ay 2-3 beses na mas mataas sa isang IoT network. Ang MQTT na may QoS0 ay nagpakita ng mas mababang resulta kumpara sa CoAP, at ang MQTT na may QoS1 ay nagpakita ng mas mataas na RTT dahil sa mga ACK sa application at transport layer. Para sa iba't ibang antas ng QoS, ang latency ng network na walang congestion ay millisecond para sa MQTT, at daan-daang microsecond para sa CoAP. Gayunpaman, ito ay nagkakahalaga ng pag-alala na kapag nagtatrabaho sa hindi gaanong maaasahang mga network, ang MQTT na tumatakbo sa tuktok ng TCP ay magpapakita ng isang ganap na naiibang resulta.
Ang oras ng pagtugon para sa mga protocol ng AMQP at MQTT sa pamamagitan ng pagtaas ng payload ay nagpakita na sa isang magaan na pag-load ang antas ng latency ay halos pareho. Ngunit kapag naglilipat ng malaking halaga ng data, nagpapakita ang MQTT ng mas maiikling oras ng pagtugon. sa isa pa Ang CoAP ay inihambing sa HTTP sa isang machine-to-machine communication scenario na may mga device na naka-deploy sa ibabaw ng mga sasakyang nilagyan ng mga gas sensor, weather sensor, location sensor (GPS) at isang mobile network interface (GPRS). Ang oras na kinakailangan upang magpadala ng mensahe ng CoAP sa mobile network ay halos tatlong beses na mas maikli kaysa sa oras na kinakailangan upang gumamit ng mga HTTP na mensahe.
Ang mga pag-aaral ay isinagawa na inihambing hindi dalawa, ngunit tatlong mga protocol. Halimbawa, pagganap ng mga protocol ng IoT na MQTT, DDS at CoAP sa isang senaryo ng medikal na aplikasyon gamit ang isang network emulator. Naungusan ng DDS ang MQTT sa mga tuntunin ng nasubok na latency ng telemetry sa ilalim ng iba't ibang hindi magandang kundisyon ng network. Ang CoAP na nakabatay sa UDP ay gumana nang maayos para sa mga application na nangangailangan ng mabilis na mga oras ng pagtugon, gayunpaman, dahil ito ay nakabatay sa UDP, nagkaroon ng makabuluhang hindi nahuhulaang pagkawala ng packet.
Throughput
Ang MQTT at CoAP sa mga tuntunin ng kahusayan ng bandwidth ay isinagawa bilang isang pagkalkula ng kabuuang halaga ng data na ipinadala sa bawat mensahe. Ang CoAP ay nagpakita ng mas mababang throughput kaysa sa MQTT kapag nagpapadala ng maliliit na mensahe. Ngunit kapag inihambing ang kahusayan ng mga protocol sa mga tuntunin ng ratio ng bilang ng mga kapaki-pakinabang na byte ng impormasyon sa kabuuang bilang ng mga byte na inilipat, naging mas epektibo ang CoAP.
Sa gamit ang MQTT, DDS (na may TCP bilang transport protocol) at CoAP bandwidth, napag-alaman na ang CoAP sa pangkalahatan ay nagpapakita ng medyo mas mababang pagkonsumo ng bandwidth, na hindi tumaas nang may tumaas na pagkawala ng packet ng network o tumaas na latency ng network, hindi katulad ng MQTT at DDS, kung saan nagkaroon isang pagtaas sa paggamit ng bandwidth sa mga nabanggit na sitwasyon. Ang isa pang senaryo ay nagsasangkot ng malaking bilang ng mga device na nagpapadala ng data nang sabay-sabay, na karaniwan sa mga kapaligiran ng IoT. Ang mga resulta ay nagpakita na para sa mas mataas na paggamit mas mainam na gumamit ng CoAP.
Sa ilalim ng magaan na pag-load, ginamit ng CoAP ang pinakamababang bandwidth, na sinusundan ng MQTT at REST HTTP. Gayunpaman, nang tumaas ang laki ng mga payload, ang REST HTTP ay nagkaroon ng pinakamahusay na mga resulta.
Power Consumption
Ang isyu ng pagkonsumo ng enerhiya ay palaging napakahalaga, at lalo na sa isang IoT system. Kung Habang ang MQTT at HTTP ay kumonsumo ng kuryente, ang HTTP ay gumagamit ng higit pa. At higit pa ang CoAP kumpara sa MQTT, na nagpapahintulot sa pamamahala ng kuryente. Gayunpaman, sa mga simpleng senaryo, mas angkop ang MQTT para sa pagpapalitan ng impormasyon sa mga network ng Internet of Things, lalo na kung walang mga paghihigpit sa kapangyarihan.
Nalaman ng isang eksperimento na inihambing ang mga kakayahan ng AMQP at MQTT sa isang mobile o hindi matatag na wireless network na testbed na nag-aalok ang AMQP ng higit pang mga kakayahan sa seguridad habang ang MQTT ay mas mahusay sa enerhiya.
katiwasayan
Ang seguridad ay isa pang kritikal na isyu na ibinangon kapag pinag-aaralan ang paksa ng Internet of Things at fog/cloud computing. Ang mekanismo ng seguridad ay karaniwang nakabatay sa TLS sa HTTP, MQTT, AMQP at XMPP, o DTLS sa CoAP, at sumusuporta sa parehong mga variant ng DDS.
Nagsisimula ang TLS at DTLS sa proseso ng pagtatatag ng komunikasyon sa pagitan ng panig ng kliyente at server upang makipagpalitan ng mga sinusuportahang cipher suite at key. Ang parehong partido ay nakikipag-ayos sa mga hanay upang matiyak na ang karagdagang komunikasyon ay magaganap sa isang secure na channel. Ang pagkakaiba sa pagitan ng dalawa ay nasa maliliit na pagbabago na nagpapahintulot sa UDP-based na DTLS na gumana sa isang hindi mapagkakatiwalaang koneksyon.
Sa Nalaman ng ilang iba't ibang pagpapatupad ng TLS at DTLS na gumawa ng mas mahusay na trabaho ang TLS. Mas matagumpay ang mga pag-atake sa DTLS dahil sa pagpapahintulot nito sa error.
Gayunpaman, ang pinakamalaking problema sa mga protocol na ito ay hindi orihinal na idinisenyo ang mga ito para sa paggamit sa IoT at hindi nilayon na gumana sa fog o ulap. Sa pamamagitan ng pakikipagkamay, nagdaragdag sila ng karagdagang trapiko sa bawat pagtatatag ng koneksyon, na nakakaubos ng mga mapagkukunan ng computing. Sa karaniwan, mayroong pagtaas ng 6,5% para sa TLS at 11% para sa DTLS sa overhead kumpara sa mga komunikasyong walang layer ng seguridad. Sa mga kapaligirang mayaman sa mapagkukunan, na karaniwang matatagpuan sa antas, hindi ito magiging problema, ngunit sa koneksyon sa pagitan ng IoT at antas ng fog, ito ay nagiging isang mahalagang limitasyon.
Ano ang pipiliin? Walang malinaw na sagot. Ang MQTT at HTTP ay tila ang pinaka-promising na mga protocol dahil ang mga ito ay itinuturing na medyo mas mature at mas matatag na mga solusyon sa IoT kumpara sa iba pang mga protocol.
Mga solusyon batay sa isang pinag-isang protocol ng komunikasyon
Ang pagsasagawa ng isang solong-protocol na solusyon ay may maraming disadvantages. Halimbawa, ang isang protocol na nababagay sa isang pinaghihigpitang kapaligiran ay maaaring hindi gumana sa isang domain na may mahigpit na mga kinakailangan sa seguridad. Sa pag-iisip na ito, hinahayaan kaming itapon ang halos lahat ng posibleng single-protocol solution sa Fog-to-Cloud ecosystem sa IoT, maliban sa MQTT at REST HTTP.
REST HTTP bilang isang solong-protocol na solusyon
Mayroong magandang halimbawa kung paano nakikipag-ugnayan ang mga kahilingan at tugon ng REST HTTP sa espasyo ng IoT-to-Fog: . Ang mga hayop ay nilagyan ng mga naisusuot na sensor (IoT client, C) at kinokontrol sa pamamagitan ng cloud computing ng isang matalinong sistema ng pagsasaka (Fog server, S).
Tinutukoy ng header ng pamamaraang POST ang mapagkukunang babaguhin (/farm/animals) gayundin ang bersyon ng HTTP at uri ng content, na sa kasong ito ay JSON object na kumakatawan sa animal farm na pamamahalaan ng system (Dulcinea/cow) . Ang tugon mula sa server ay nagpapahiwatig na ang kahilingan ay matagumpay sa pamamagitan ng pagpapadala ng HTTPS status code 201 (ginawa ang mapagkukunan). Ang GET method ay dapat na tukuyin lamang ang hiniling na mapagkukunan sa URI (halimbawa, /farm/animals/1), na nagbabalik ng JSON na representasyon ng hayop na may ID na iyon mula sa server.
Ginagamit ang PUT method kapag kailangang i-update ang ilang partikular na resource record. Sa kasong ito, tinutukoy ng mapagkukunan ang URI para sa parameter na babaguhin at ang kasalukuyang halaga (halimbawa, nagsasaad na kasalukuyang naglalakad ang baka, /farm/animals/1? state=walking). Sa wakas, ang DELETE na paraan ay ginagamit nang pantay sa GET na paraan, ngunit tinatanggal lang ang mapagkukunan bilang resulta ng operasyon.
MQTT bilang isang solong-protocol na solusyon
Dalhin natin ang parehong matalinong bukid, ngunit sa halip na REST HTTP ginagamit namin ang protocol ng MQTT. Ang isang lokal na server na may naka-install na Mosquitto library ay kumikilos bilang isang broker. Sa halimbawang ito, ang isang simpleng computer (tinukoy bilang server ng sakahan) Raspberry Pi ay nagsisilbing MQTT client, na ipinatupad sa pamamagitan ng pag-install ng Paho MQTT library, na ganap na tugma sa Mosquitto broker.
Ang client na ito ay tumutugma sa isang IoT abstraction layer na kumakatawan sa isang device na may sensing at computing na kakayahan. Ang tagapamagitan, sa kabilang banda, ay tumutugma sa isang mas mataas na antas ng abstraction, na kumakatawan sa isang fog computing node na nailalarawan sa pamamagitan ng mas malaking kapasidad sa pagproseso at imbakan.
Sa iminungkahing smart farm scenario, ang Raspberry Pi ay kumokonekta sa accelerometer, GPS, at mga sensor ng temperatura at nag-publish ng data mula sa mga sensor na ito sa isang fog node. Tulad ng malamang na alam mo, tinatrato ng MQTT ang mga paksa bilang isang hierarchy. Ang isang publisher ng MQTT ay maaaring mag-publish ng mga mensahe sa isang partikular na hanay ng mga paksa. Sa aming kaso, tatlo sila. Para sa sensor na sumusukat sa temperatura sa isang kamalig ng hayop, pipili ang kliyente ng tema (animalfarm/shed/temperatura). Para sa mga sensor na sumusukat sa lokasyon ng GPS at paggalaw ng hayop sa pamamagitan ng accelerometer, mag-publish ang kliyente ng mga update sa (animalfarm/animal/GPS) at (animalfarm/animal/movement).
Ang impormasyong ito ay ipapasa sa broker, na maaaring pansamantalang mag-imbak nito sa isang lokal na database kung sakaling dumating ang isa pang interesadong subscriber sa ibang pagkakataon.
Bilang karagdagan sa lokal na server, na gumaganap bilang isang MQTT broker sa fog at kung saan ang Raspberry Pis, na kumikilos bilang mga kliyente ng MQTT, ay nagpapadala ng data ng sensor, maaaring mayroong isa pang MQTT broker sa antas ng ulap. Sa kasong ito, ang impormasyong ipinadala sa lokal na broker ay maaaring pansamantalang maimbak sa isang lokal na database at/o ipadala sa cloud. Ang fog MQTT broker sa sitwasyong ito ay ginagamit upang iugnay ang lahat ng data sa cloud MQTT broker. Sa ganitong arkitektura, ang isang gumagamit ng mobile application ay maaaring mag-subscribe sa parehong mga broker.
Kung mabigo ang koneksyon sa isa sa mga broker (halimbawa, cloud), ang end user ay makakatanggap ng impormasyon mula sa isa (fog). Isa itong katangian ng pinagsamang fog at cloud computing system. Bilang default, maaaring i-configure ang mobile app upang kumonekta sa MQTT broker muna, at kung mabigo iyon, upang kumonekta sa cloud MQTT broker. Ang solusyon na ito ay isa lamang sa marami sa IoT-F2C system.
Mga solusyon sa multi-protocol
Ang mga solong solusyon sa protocol ay sikat dahil sa kanilang mas madaling pagpapatupad. Ngunit malinaw na sa mga sistema ng IoT-F2C ay makatuwiran na pagsamahin ang iba't ibang mga protocol. Ang ideya ay ang iba't ibang mga protocol ay maaaring gumana sa iba't ibang antas. Kunin, halimbawa, ang tatlong abstraction: ang mga layer ng IoT, fog at cloud computing. Ang mga device sa antas ng IoT ay karaniwang itinuturing na limitado. Para sa pangkalahatang-ideya na ito, isaalang-alang natin ang mga tier ng IoT bilang ang pinaka-nalilimitahan, ang cloud ang pinakamaliit na napipigilan, at ang fog computing bilang "sa isang lugar sa gitna." Lumalabas na sa pagitan ng IoT at fog abstraction, ang mga kasalukuyang solusyon sa protocol ay kinabibilangan ng MQTT, CoAP at XMPP. Sa pagitan ng fog at cloud, sa kabilang banda, ang AMQP ay isa sa mga pangunahing protocol na ginagamit, kasama ang REST HTTP, na dahil sa flexibility nito ay ginagamit din sa pagitan ng IoT at fog layers.
Ang pangunahing problema dito ay ang interoperability ng mga protocol at ang kadalian ng paglilipat ng mga mensahe mula sa isang protocol patungo sa isa pa. Sa isip, sa hinaharap, ang arkitektura ng isang Internet of Things system na may cloud at fog resources ay magiging independyente sa protocol ng komunikasyon na ginamit at titiyakin ang mahusay na interoperability sa pagitan ng iba't ibang protocol.
Dahil hindi ito kasalukuyang nangyayari, makatuwirang pagsamahin ang mga protocol na walang makabuluhang pagkakaiba. Sa layuning ito, ang isang potensyal na solusyon ay batay sa isang kumbinasyon ng dalawang protocol na sumusunod sa parehong istilo ng arkitektura, REST HTTP at CoAP. Ang isa pang iminungkahing solusyon ay batay sa isang kumbinasyon ng dalawang protocol na nag-aalok ng komunikasyon sa pag-publish-subscribe, MQTT at AMQP. Ang paggamit ng mga katulad na konsepto (kapwa MQTT at AMQP ay gumagamit ng mga broker, ang CoAP at HTTP ay gumagamit ng REST) ββay ginagawang mas madaling ipatupad ang mga kumbinasyong ito at nangangailangan ng mas kaunting pagsisikap sa pagsasama.
Ang Figure (a) ay nagpapakita ng dalawang modelong batay sa kahilingan-tugon, HTTP at CoAP, at ang kanilang posibleng paglalagay sa isang IoT-F2C na solusyon. Dahil ang HTTP ay isa sa pinakakilala at pinagtibay na mga protocol sa mga modernong network, malamang na hindi ito ganap na mapapalitan ng iba pang mga protocol sa pagmemensahe. Kabilang sa mga node na kumakatawan sa mga makapangyarihang device na nasa pagitan ng ulap at fog, ang REST HTTP ay isang matalinong solusyon.
Sa kabilang banda, para sa mga device na may limitadong mapagkukunan ng computing na nakikipag-ugnayan sa pagitan ng mga layer ng Fog at IoT, mas mahusay na gumamit ng CoAP. Isa sa malaking bentahe ng CoAP ay ang pagiging tugma nito sa HTTP, dahil ang parehong mga protocol ay nakabatay sa mga prinsipyo ng REST.
Ipinapakita ng Figure (b) ang dalawang modelo ng komunikasyon sa pag-publish-subscribe sa parehong senaryo, kabilang ang MQTT at AMQP. Bagama't ang parehong mga protocol ay maaaring hypothetically gamitin para sa komunikasyon sa pagitan ng mga node sa bawat abstraction layer, ang kanilang posisyon ay dapat matukoy batay sa pagganap. Idinisenyo ang MQTT bilang isang magaan na protocol para sa mga device na may limitadong mapagkukunan ng computing, kaya magagamit ito para sa komunikasyon ng IoT-Fog. Ang AMQP ay mas angkop para sa mas makapangyarihang mga device, na perpektong iposisyon ito sa pagitan ng fog at cloud node. Sa halip na MQTT, ang XMPP protocol ay maaaring gamitin sa IoT dahil ito ay itinuturing na magaan. Ngunit hindi ito gaanong ginagamit sa mga ganitong sitwasyon.
Natuklasan
Malamang na ang isa sa mga protocol na tinalakay ay magiging sapat upang masakop ang lahat ng mga komunikasyon sa isang system, mula sa mga device na may limitadong mga mapagkukunan sa pag-compute hanggang sa mga cloud server. Nalaman ng pag-aaral na ang dalawang pinaka-maaasahan na opsyon na karamihang ginagamit ng mga developer ay ang MQTT at RESTful HTTP. Ang dalawang protocol na ito ay hindi lamang ang pinaka-mature at stable, ngunit kasama rin ang maraming mahusay na dokumentado at matagumpay na pagpapatupad at online na mapagkukunan.
Dahil sa katatagan at simpleng configuration nito, ang MQTT ay isang protocol na napatunayan ang mahusay na performance nito sa paglipas ng panahon kapag ginamit sa antas ng IoT na may limitadong mga device. Sa mga bahagi ng system kung saan ang limitadong komunikasyon at pagkonsumo ng baterya ay hindi isang isyu, tulad ng ilang fog domain at karamihan sa cloud computing, ang RESTful HTTP ay isang madaling pagpipilian. Dapat ding isaalang-alang ang CoAP dahil mabilis din itong umuunlad bilang pamantayan sa pagmemensahe ng IoT at malamang na maabot nito ang antas ng katatagan at maturity katulad ng MQTT at HTTP sa malapit na hinaharap. Ngunit ang pamantayan ay kasalukuyang umuunlad, na may mga panandaliang isyu sa compatibility.
Ano pa ang mababasa mo sa blog?
β
β
β
β
β
Mag-subscribe sa aming -channel, para hindi makaligtaan ang susunod na artikulo! Nagsusulat kami ng hindi hihigit sa dalawang beses sa isang linggo at sa negosyo lamang.
Pinagmulan: www.habr.com