Zhvillimi i teknologjive në fushën e softit dhe harduerit, shfaqja e protokolleve të reja të komunikimit ka çuar në zgjerimin e internetit të gjërave (IoT). Numri i pajisjeve rritet nga dita në ditë, dhe ato gjenerojnë një volum të madh të të dhënave. Prandaj, ka një nevojë për një arkitekturë të përshtatshme sistemi, e cila është në gjendje të rregullojë, ruajë dhe transferojë këto të dhëna.
Aktualisht, për këto qëllime përdoren shërbimet cloud. Megjithatë, paradigma gjithnjë e më e popullarizuar e llogaritjeve të mjegullës (Fog) është në gjendje të plotësojë zgjidhjet cloud, duke zgjeruar dhe optimizuar infrastrukturën IoT.
«Reket» mund të përmbushin shumicën e kërkesave të IoT. Për shembull, të sigurojnë monitorimin e shërbimeve, përpunimin e shpejtë të çdo vëllimi të të dhënave që gjenerohen nga pajisjet, si dhe vizualizimin e tyre. Llogaritjet e mjegullës janë më efektive për zgjidhjen e detyrave në kohë reale. Ato ofrojnë një përgjigje të shpejtë ndaj kërkesave dhe një vonesë minimale gjatë përpunimit të të dhënave. Pra, Fog e plotëson pikërisht «Reket», duke zgjeruar mundësitë e saj.
Megjithatë, pyetja kryesore është: si duhet të ndërveprojnë të gjitha këto në kontekstin e IoT? Cilat protokolle komunikimi do të ishin më efektive gjatë punës në një sistem të integruar IoT-Fog-Cloud?
Pavarësisht dukshmërisë së HTTP, në sistemet IoT, Fog dhe Cloud përdoren një numër i madh zgjidhjesh të tjera. Kjo shpjegohet me faktin se IoT duhet të kombinojë funksionalitetet e ndryshme të sensorëve të pajisjeve me sigurinë, pajtueshmërinë dhe kërkesat e tjera që kërkohen nga përdoruesit.
Megjithatë, nuk ka një paraqitje të vetme për arkitekturën standarde dhe protokollin e lidhjes. Prandaj, krijimi i një protokolli të ri ose përmirësimi i atij ekzistues për detyrat specifike të IoT është një nga detyrat më të rëndësishme që i qëndrojnë komunitetit IT.
Cilat protokolle përdoren aktualisht dhe çfarë mund të ofrojnë ato? Le të kuptojmë. Por përpara se të fillojmë, le të diskutojmë parimet e ekosistemit ku ndërveprojnë reket, mjegulla dhe interneti i gjërave.
Arkitektura IoT Fog-to-Cloud (F2C)
Ju sigurisht keni vënë re se sa shumë përpjekje po bëhen për të studiuar përfitimet dhe fitimet që lidhen me menaxhimin efikas dhe të koordinuar të IoT, rekrutave dhe mjegullës. Nëse jo, atëherë ja tre iniciativa për standardizim: , dhe .
Nëse më parë shqyrtonim vetëm 2 nivele, rejnë dhe pajisjet fundore, arkitektura e propozuar fut një nivel të ri - llogaritë e mjegullës. Ky nivel mjegulle mund të ndahet në disa nën-nivele, në varësi të specifikave të burimeve ose grupit të politikave që përcaktojnë përdorimin e pajisjeve të ndryshme në këto nën-nivele.
Si mund të duket kjo abstraksion? Këtu është një ekosistem tipik IoT-Fog-Cloud. Pajisjet IoT dërgojnë të dhëna në servera dhe pajisje llogaritëse më të fuqishme për të zgjidhur detyra që kërkojnë një nivel të ulët vonese. Në këtë sistem, reja është përgjegjëse për zgjidhjen e detyrave që kërkojnë një volum të madh burimesh llogarituese ose hapësirë për ruajtjen e të dhënave.
Smartphone, orë inteligjente dhe paisje të tjera gjithashtu mund të jenë pjesë e IoT. Por këto pajisje zakonisht përdorin protokolle komunikimi pronësore nga zhvillues të mëdhenj. Të dhënat e gjeneruara nga interneti i gjërave dërgohen në nivelin e mjegullës nëpërmjet protokollit REST HTTP, i cili ofron fleksibilitet dhe ndërlidhshmëri funksionale në krijimin e shërbimeve RESTful. Kjo është e rëndësishme në dritën e nevojës për të siguruar përputhshmëri të prapaveprueshme me infrastrukturën aktuale llogarituese që funksionon në kompjuterë lokalë, servera ose grupe serverash. Burimet lokale, të cilat quhen "nyjet e mjegullës", filtrojnë të dhënat e pranuara dhe i përpunojnë lokal ose i dërgojnë në re për llogaritje të mëtejshme.
Rejtë mbështesin protokolle të ndryshme komunikimi, midis të cilave më të zakonshmet janë AMQP dhe REST HTTP. Duke qenë se HTTP është shumë i njohur dhe i dizajnuar për internetin, mund të lindë pyetja: "Pse të mos e përdorim atë për të punuar me IoT dhe mjegullën?". Megjithatë, ky protokoll ka probleme me performancën. Më vonë.
Në përgjithësi, ekzistojnë 2 modele protokollesh komunikimi, të përshtatshme për sistemin tonë. Këto janë kërkesë-përgjigje dhe publikim-nënshkrim. Modeli i parë njihet më gjerësisht, sidomos në arkitekturën server-klient. Klienti kërkon informacion nga serveri, dhe ai merr kërkesën, e përpunon atë dhe kthehet me një mesazh përgjigjeje. Sipas këtij modeli funksionojnë protokollet REST HTTP dhe CoAP.
Modeli i dytë u krijua nga nevoja për të siguruar një lidhje asinkrone, të shpërndarë dhe të dobët midis burimeve që gjenerojnë të dhëna dhe marrësve të këtyre të dhënave.
Modeli parashikon tre pjesëmarrës: botuesi (burimi i të dhënave), brokeri (dispeçeri) dhe abonenët (marrësit). Këtu, klienti që vepron si abonent nuk duhet të kërkojë informacion nga serveri. Në vend të dërgimit të kërkesave, ai abonon në ngjarje të caktuara në sistem përmes brokerit, i cili është përgjegjës për filtrimin e të gjitha mesazheve të ardhshme dhe rrethinimin e tyre midis botuesve dhe abonentëve. Kur ndodh një ngjarje që lidhet me një temë të caktuar, botuesi e publikon atë tek brokeri, i cili i dërgon abonentit të dhënat mbi temën e kërkuar.
Në thelb, kjo arkitekturë është e bazuar në ngjarje. Dhe një model i tillë interaksioni është i rëndësishëm për aplikacionet në IoT, në re, në mjegull për shkak të aftësive të saj për të siguruar shkallëzueshmëri dhe për të thjeshtuar ndërveprimin midis pajisjeve të ndryshme, për të mbështetur lidhjen dinamike "marrës shumë - shumë" dhe lidhjen asinkrone. Disa nga protokollet më të njohura të standardizuara për shkëmbimin e mesazheve që përdorin modelin "botim-abonim" janë MQTT, AMQP dhe DDS.
Evidentisht, modeli "botim-abonim" ka shumë avantazhe:
- Botuesit dhe abonentët nuk kanë nevojë të dinë për egzistencën e njëri-tjetrit;
- Një abonent mund të marrë informacion nga shumë botues të ndryshëm, ndërsa një botues mund të dërgojë të dhëna në shumë abonentë të ndryshëm (parimi "shumë në shumë");
- Botuesi dhe abonenti nuk janë të detyruar të jenë aktivë në të njëjtën kohë për shkëmbimin e të dhënave, sepse brokeri (që funksionon si një sistem radhitjeje) mund të ruajë mesazhin për klientët që aktualisht nuk janë të lidhur me rrjetin.
Megjithatë, edhe modeli "kërkesë-përgjigje" ka pikë të forta. Në raste kur kapacitetet e anës server për të përpunuar kërkesat e shumë klientëve nuk përbëjnë një problem, ka kuptim të përdoren tashmë zgjidhje të provuara dhe të besueshme.
Ka there edhe protokolle që mbështesin të dyja modelet. Për shembull, XMPP dhe HTTP 2.0, që mbështesin opsionin "server push". IETF gjithashtu lëshoi CoAP. Në përpjekje për të zgjidhur problemin e shkëmbimit të mesazheve janë krijuar disa zgjidhje të tjera, si protokolli WebSockets ose përdorimi i protokollit HTTP përmes QUIC (Quick UDP Internet Connections).
Në rastin e WebSockets, megjithëse ai përdoret për të transferuar të dhëna në kohë reale nga serveri në klientin web dhe ofron lidhje të vazhdueshme me komunikim të dyanshëm, ai nuk është i destinuar për pajisje me burime të kufizuara llogarike. QUIC gjithashtu meriton vëmendje, pasi protokolli i ri i transportit ofron një sërë mundësish të reja. Por, pasi që QUIC ende nuk është standardizuar, është herët të parashikohet përdorimi dhe ndikimi i tij në zgjidhjet për IoT. Pra, WebSockets dhe QUIC i mbajmë në mendje për të ardhmen, por nuk do t'i studiojmë më në thellësi për tani.
Kush është më i dashur në botë: krahasojmë protokollet
Tani le të flasim rreth pikave të forta dhe të dobëta të protokolleve. Duke kaluar përpara, menjëherë saktësojmë se nuk ka një lider të qartë. Çdo protokoll ka disa përparësi dhe disavantazhe.
Koha e përgjigjes
Një nga karakteristikat më të rëndësishme të protokolleve të komunikimit, veçanërisht në lidhje me Internetin e Gjërave, është koha e përgjigjes. Por ndër protokollet ekzistuese nuk ka një fitues të padiskutueshëm që tregon nivelin minimal të vonesës në kushte të ndryshme. Përkundrazi, ekziston një sasi e madhe studimesh dhe krahasimesh të mundësive të protokolleve.
Për shembull, krahasimet e efikasitetit të HTTP dhe MQTT në punën me IoT treguan se koha e përgjigjes për kërkesat në MQTT është më e vogël se në HTTP. Ndërsa, i kohës së transmetimit (RTT) MQTT dhe CoAP tregoi se RTT mesatar i CoAP është 20% më i vogël se ai i MQTT.
Tjetër Me RTT për protokollet MQTT dhe CoAP është zhvilluar në dy skenarë: rrjet lokal dhe rrjet IoT. Doli se RTT mesatar është 2-3 herë më i lartë në rrjetin IoT. MQTT me QoS0 tregoi rezultate më të ulta në krahasim me CoAP, ndërsa MQTT me QoS1 demonstroi një RTT më të lartë për shkak të ACK në nivelin aplikativ dhe transportit. Për nivele të ndryshme QoS, vonesat në rrjet pa ngarkesë për MQTT ishin milisekonda, ndërsa për CoAP ishin qindra mikrosekonda. Megjithatë, është e rëndësishme të mbani mend se në rrjetet më pak të besueshme, MQTT, i cili funksionon mbi TCP, do të tregojë një rezultat krejtësisht tjetër.
Koha e përgjigjes së protokolleve AMQP dhe MQTT përmes rritjes së ngarkesës ka treguar se me ngarkesë të vogël, niveli i vonesës është thuajse i njëjtë. Por kur transmetohen sasi të mëdha të dhënash, MQTT tregon një kohë përgjigjeje më të ulët. Një tjetër CoAP u krahasua me HTTP në një skenar ndërmjet makinash me pajisje të vendosura mbi mjete dhe të pajisura me sensorë gazi, sensorë moti, pozicion (GPS) dhe ndërfaqe të rrjetit celular (GPRS). Koha e nevojshme për të dërguar një mesazh CoAP përmes rrjetit celular ishte pothuajse tre herë më e shkurtër se koha e nevojshme për përdorimin e mesazheve HTTP.
U zhvilluan studime ku u krahasuan jo dy, por tre protokolle. Për shembull, rendimentin e protokolleve IoT MQTT, DDS dhe CoAP në një skenar të aplikacioneve mjekësore duke përdorur një emulator rrjeti. DDS tejkaloi MQTT në aspektin e vonesës së provuar të telemetrisë në kushte të ndryshme të dobëta të rrjetit. CoAP, bazuar në UDP, funksionoi mirë për aplikacione që kërkonin përgjigje të shpejtë, megjithatë për shkak se është i bazuar në UDP, kishte një humbje të konsiderueshme të papritur të paketave.
Kapaciteti
MQTT dhe CoAP në aspektin e efikasitetit të përdorimit të kanalit u zhvillua si një llogaritje e sasisë totale të të dhënave të transmetuara me një mesazh. CoAP tregoi kapacitete më të ulëta se MQTT në transmetimin e mesazheve të vogla. Por kur u krahasuan efikasitetin e protokolleve në aspektin e raportit të numrit të byteve të informacionit të dobishëm me sasinë totale të byteve të transmetuara, CoAP doli më efikas.
Kur Në studimin e përdorimit të kapacitetit të kanalit MQTT, DDS (me TCP si protokoll transporti) dhe CoAP, u zbulua se CoAP, në përgjithësi, kishte një konsum më të ulët të bandwidth-it, i cili nuk rritej me rritjen e humbjeve të paketave të rrjetit ose të vonesave të rrezikut në rrjet, ndryshe nga MQTT dhe DDS, ku në skenarët e përmendur vërehej rritja e përdorimit të kapacitetit të kanalit. Në një skenar tjetër, u angazhuan një numër i madh pajisjesh që dërgonin të dhëna në të njëjtën kohë, që është një rast tipik në ambientet IoT. Rezultatet treguan se për një ngarkesë më të lartë ishte më mirë të përdorej CoAP.
Me ngarkesë të vogël, CoAP përdorte kapacitetin më të ulët, pasuar nga MQTT dhe REST HTTP. Megjithatë, kur madhësia e ngarkesave u rrit, rezultatet më të mira i patën REST HTTP.
Konsum i energjisë
Çështja e konsumit të energjisë gjithmonë ka rëndësi të madhe, dhe në një sistem IoT - sidomos. Nëse konsumimi i energjisë midis MQTT dhe HTTP, atëherë HTTP 'han' shumë më tepër. Ndërsa CoAP është më në krahasim me MQTT, duke lejuar menaxhimin e energjisë. Në të njëjtën kohë, në skenarët e thjeshtë, MQTT është më i përshtatshëm për shkëmbimin e informacionit në rrjetet e internetit të gjërave, veçanërisht nëse nuk ka kufizime të energjisë.
Eksperimenti, në të cilin u krahasuan mundësitë e AMQP dhe MQTT në një stend provash në një rrjet celular ose të paqëndrueshëm pa tel, tregoi se AMQP ofron më shumë mundësi në aspektin e sigurisë, ndërsa MQTT është më efikas në energji.
Siguria
Siguria është një çështje tjetër shumë e rëndësishme që ngrihet gjatë studimit të temës së internetit të gjërave dhe kompjuterave në re/rrjet. Mekanizmi i sigurisë zakonisht bazohet në TLS në HTTP, MQTT, AMQP dhe XMPP, ose DTLS në CoAP, si dhe mbështet të dyja variantet DDS.
TLS dhe DTLS fillojnë me procesin e vendosjes së lidhjes midis anës kliente dhe anës server për shkëmbimin e grupeve të përkrahura të çelësve dhe kriptograve. Të dy palët bien dakord për grupet, për të garantuar që komunikimi i mëtejshëm të ndodhë në një kanal të sigurt. Diferenca midis tyre qëndron në modifikime të vogla që lejojnë që DTLS të funksionojë mbi një lidhje të pasigurt.
Kur Në disa implementime të ndryshme të TLS dhe DTLS, doli se TLS ishte më i suksesshëm. Sulmet ndaj DTLS ishin më të suksesshme për shkak të toleranceve të tij ndaj gabimeve.
Megjithatë, problemi më i madh me këto protokolle është se ato nuk ishin fillimisht të dizajnuara për përdorim në IoT dhe nuk parashikonin funksionimin në mjegull ose në re. Me shkëmbimin e dakorduar (handshaking), ato shtojnë trafik të panevojshëm me çdo vendosje lidhjeje, duke shteruar burimet kompjuterike. Mesatarisht, ka një rritje prej 6.5% për TLS dhe 11% për DTLS në ngarkesën e shërbimit në krahasim me lidhjen pa nivel sigurie. Në mjediset e pasura me burime, të cilat zakonisht janë të vendosura në , kjo nuk do të jetë një problem, por në lidhjen ndërmjet IoT dhe nivelit të mjegullës, kjo bëhet një kufizim i rëndësishëm.
Çfarë të zgjedhim? Nuk ka një përgjigje të qartë. MQTT dhe HTTP duken si protokollet më premtuese, pasi konsiderohen si zgjidhje më të plota dhe më stabile për IoT krahasuar me protokollet e tjera.
Zgjidhjet e bazuara në një protokoll komunikimi
Praktika e zgjidhjeve një-protokoll ka shumë disavantazhe. Për shembull, një protokoll që përshtatet në një mjedis të kufizuar, mund të mos funksionojë në një fushë që ka kërkesa të rrepta sigurie. Duke pasur parasysh këtë, ne duhet të heqim dorë nga pothuajse të gjitha zgjidhjet e mundshme të bazuara në një protokoll në ekosistemin Fog-to-Cloud në IoT, përveç MQTT dhe REST HTTP.
REST HTTP si një zgjidhje një-protokoll
Ka një shembull të mirë të ndërveprimit të kërkesave dhe përgjigjeve REST HTTP në fushën e IoT-to-Fog: . Kafshët furnizohen me sensorë të veshur (klienti IoT, C) dhe menaxhohen përmes llogaritjeve në re nga sistemi i fermerisë inteligjente (serveri Fog, S).
Në titullin e metodës POST shënohet burimi për t'u ndryshuar (\/farm\/animals), si dhe versioni i HTTP dhe lloji i përmbajtjes, që në këtë rast është një objekt JSON, që përfaqëson fermën e bagëtive që duhet të menaxhohet nga sistemi (Dulcinëa\/vaca). Përgjigjja nga serveri tregon se kërkesa ishte e suksesshme, duke dërguar kodin e statusit HTTPS 201 (burimi është krijuar). Metoda GET duhet të shënojë vetëm burimin e kërkuar në URI (p.sh., \/farm\/animals\/1), që kthen një përfaqësim JSON të kafshës me këtë identifikues nga serveri.
Metoda PUT përdoret kur është e nevojshme të përditësohet një regjistrim i veçantë i burimit. Në këtë rast, burimi tregon URI-në për parametrin që do të ndryshohet dhe vlerës aktuale (p.sh., duke treguar se krava aktualisht është duke ecur, /farm/animals/1?state=walking). Së fundmi, metoda DELETE përdoret njësoj si metoda GET, por thjesht eliminon burimin si rezultat i operacionit.
MQTT si një zgjidhje me një protokoll
Le të marrim të njëjtën fermë inteligjente, por në vend të REST HTTP të përdorim protokollin MQTT. Një server lokal me bibliotekën Mosquitto të instaluar shërben si broker. Në këtë shembull, një kompjuter i thjeshtë (i përfaqësuar si serveri i fermës) Raspberry Pi shërben si klient MQTT, i realizuar përmes instalimit të bibliotekës MQTT Paho, e cila është plotësisht e përputhshme me brokerin Mosquitto.
Ky klient i përket nivelit të abtraksionit IoT që përfaqëson një pajisje me mundësi zbulimi dhe llogaritjesh. Ndërmjetësi, nga ana tjetër, përfaqëson një nivel më të lartë abstraksioni, që përfaqëson një nyjë llogaritëse të mjegullës, e cila karakterizohet nga kapacitetet më të mëdha për përpunim dhe ruajtje të të dhënave.
Në skenarin e propozuar të "fermës inteligjente," Raspberry Pi lidhet me një accelerometër, GPS dhe sensorë temperature dhe publikon të dhënat nga këta sensorë në një nyjë të mjegullës. Siç e dini, MQTT i konsideron temat si një hierarki. Një botues MQTT mund të publikojë mesazhe në një grup të caktuar temash. Në rastin tonë, ato janë tre. Për sensorin që mason temperaturën në stallën e kafshëve, klienti zgjat temën (animalfarm/shed/temperature). Për sensorët që masin pozicionin GPS dhe lëvizjen e kafshëve përmes accelerometrit, klienti publikojnë përditësime (animalfarm/animal/GPS) dhe (animalfarm/animal/movement).
Këto informacione do të dërgohen te brokeri, i cili mund ta ruajë atë përkohësisht në një bazë të dhënash lokale për rast se më vonë shfaqet një abonent tjetër i interesuar.
Përveç një serveri lokal që vepron si broker MQTT në mjegull dhe të cilit Raspberry Pi, që shërbejnë si klientë MQTT, i dërgojnë të dhënat nga sensorët, në nivelin e cloud-it mund të ketë edhe një broker tjetër MQTT. Në këtë rast, informacioni që dërgohet në brokerin lokal mund të ruhet përkohësisht në një bazë të dhënash lokale dhe/ose të dërgohet në cloud. Brokeri MQTT i mjegullës në këtë situatë përdoret për të lidhur të gjitha të dhënat me brokerin MQTT të cloud-it. Me një arkitekturë të tillë, përdoruesi i aplikacionit mobil mund të jetë i regjistruar në të dy brokerët.
Në rast të dështimit të lidhjes me një nga brokerët (p.sh., cloud-it), përdoruesi i fundit do të marrë informacion nga tjetri (mjegu). Kjo është një karakteristikë tipike e sistemeve të kombinuara të mjegullës dhe llogarive në cloud. Sipas parazgjedhjes, aplikacioni mobil mund të konfigurohet për t'u lidhur fillimisht me brokerin MQTT të mjegullës, dhe në rast dështimi - me brokerin MQTT në cloud. Ky zgjidhje është vetëm një nga shumë në sistemet IoT-F2C.
Zgjidhjet shumëprotokollore
Zgjidhjet me një protokoll janë të njohura për shkak të implementimit më të lehtë. Por, është e qartë se në sistemet IoT-F2C ka kuptim të kombinoni protokolle të ndryshme. Ideja është që në nivele të ndryshme mund të funksionojnë protokolle të ndryshme. Le të marrim, për shembull, tre abstraksione: nivelet IoT, mjegullë dhe llogari në cloud. Pajisjet në nivelin IoT zakonisht konsiderohen se janë të kufizuara. Për këtë përmbledhje, le të konsiderojmë nivelet IoT si më të kufizuara, mbështetje në cloud si më pak të kufizuara dhe llogaritë e mjegullës si "diku në mes". Kështu, midis IoT dhe abstraksioneve të mjegullës, zgjidhjet aktuale të protokolleve përfshijnë MQTT, CoAP dhe XMPP. Ndërsa midis mjegullës dhe cloud-it, AMQP është një nga protokollet kryesore që përdoren së bashku me REST HTTP, i cili për shkak të fleksibilitetit të tij gjithashtu përdoret midis IoT dhe niveleve të mjegullës.
Problemi kryesor këtu është përputhshmëria funksionale e protokolleve dhe thjeshtësia e përkthimit të mesazheve nga një protokoll në një tjetër. Në mënyrë ideale, në të ardhmen, arkitektura e sistemit të Internetit të Gjërave me burime në cloud dhe mjegullë do të jetë e pavarur nga protokolli i komunikimit të përdorur dhe do të sigurojë një bashkëpunim të mirë midis protokolleve të ndryshme.
Tani është arsyeja pse ka kuptim të bashkohen protokollet që nuk kanë dallime të rëndësishme. Me këtë qëllim, një përmirësim potencial është e bazuar në kombinimin e dy protokolleve që ndajnë të njëjtin stil arkitektonik, REST HTTP dhe CoAP. Një zgjidhje tjetër e propozuar është e bazuar në kombinimin e dy protokolleve që ofrojnë ndërveprim sipas modelit 'publikim-abonim', MQTT dhe AMQP. Përdorimi i koncepteve të ngjashme (edhe MQTT dhe AMQP përdorin brokerë, CoAP dhe HTTP përdorin REST) e thjeshton zbatimin e këtyre kombinimeve dhe kërkon më pak përpjekje për integrim.
Në figurën (a) janë paraqitur dy modele të bazuara në kërkesa-përgjigje, HTTP dhe CoAP, dhe vendosja e mundshme e tyre në zgjidhjen IoT-F2C. Meqenëse HTTP është një nga protokollet më të njohura dhe të adaptuara në rrjetet moderne, ka shumë pak mundësi që ai të zëvendësohet plotësisht nga protokolle të tjera komunikimi. Midis nyjave që përfaqësojnë pajisje të fuqishme që ndodhen midis retës dhe mjegullës, REST HTTP është një zgjidhje e arsyeshme.
Nga ana tjetër, për pajisjet me burime të kufizuara të llogaritjes, të cilat lidhen mes niveleve të mjegullës dhe IoT, është më efikase të përdoret CoAP. Një nga avantazhet e mëdha të CoAP është në fakt përputhshmëria e tij me HTTP, pasi të dy protokollet janë të bazuara në parimet e REST.
Në figurën (b) paraqiten dy modele ndërveprimi 'publikim-abonim' në një skenar, duke përfshirë MQTT dhe AMQP. Megjithëse hipotetikisht të dy protokollet mund të përdoren për komunikim mes nyjave në çdo nivel abstraksioni, pozita e tyre duhet të përcaktohet duke u bazuar në performancën. MQTT është zhvilluar si një protokoll i thjeshtuar për pajisje me burime të kufizuara të llogaritjes, ndaj ai mund të përdoret për komunikim mes IoT dhe mjegullës. AMQP është më i përshtatshëm për pajisje më të fuqishme, të cilat do ta vendosnin atë në mënyrë ideale midis nyjave të mjegullës dhe re. Në vend të MQTT, në IoT mund të përdoret protokolli XMPP, pasi ai konsiderohet i lehtë. Por ai nuk është aq i përdorur gjerësisht në skenarë të tillë.
Përfundimet
Është e pamundur që një prej protokolleve të shqyrtuara të jetë e mjaftueshme për të përfshirë të gjitha komunikimet në sistem, duke filluar nga pajisjet me burime të kufizuara llogarish dhe duke përfunduar me serverët në re. Studimi tregoi se dy opsionet më premtuese, që shpesh përdoren nga zhvilluesit, janë MQTT dhe RESTful HTTP. Këto dy protokolle jo vetëm që janë më të avancuar dhe stabile, por gjithashtu përfshijnë shumë realizime të dokumentuara mirë dhe burime në internet.
Falë stabilitetit dhe konfigurimit të thjeshtë, MQTT është një protokoll që me kalimin e kohës ka dëshmuar performancën e tij të shkëlqyer kur përdoret në nivelin e IoT me pajisje të kufizuara. Në pjesët e sistemit ku lidhja e kufizuar dhe konsumimi i baterisë nuk janë problem, siç janë disa fusha të mjegullës dhe shumicën e llogaritjeve në re, RESTful HTTP është një zgjedhje e thjeshtë. CoAP gjithashtu duhet të merret parasysh, sepse gjithashtu po zhvillohet shpejt si një standard për shkëmbimin e mesazheve në IoT, dhe është shumë e mundur që në të ardhmen e afërt të arrijë një nivel stabiliteti dhe pjekurie të ngjashëm me MQTT dhe HTTP. Por standardi tani është në zhvillim, që vjen me probleme të përputhshmërisë në shkallë afatshkurtër.
Çfarë tjetër mund të lexoni në blog
→
→
→
→
→
Abonohuni në -kanali, për të mos humbur artikullin tjetër! Ne shkruajmë jo më shpesh se dy herë në javë dhe vetëm për çështje të rëndësishme.
Burimi: habr.com
