Ngembangkeun téknologi dina widang software jeung hardware, mecenghulna protokol komunikasi anyar geus ngarah ka perluasan Internet of Things (IoT). Jumlah alat naék unggal dinten sareng aranjeunna ngahasilkeun jumlah data anu ageung. Ku alatan éta, aya anu peryogi pikeun arsitéktur sistem merenah sanggup ngolah, nyimpen jeung ngirimkeun data ieu.
Ayeuna jasa awan dianggo pikeun tujuan ieu. Nanging, paradigma komputasi kabut (Fog) anu beuki populer tiasa ngalengkepan solusi awan ku cara skala sareng ngaoptimalkeun infrastruktur IoT.
Awan sanggup nutupan seueur paménta IoT. Contona, pikeun nyadiakeun monitoring jasa, ngolah gancang tina sagala jumlah data dihasilkeun ku alat, kitu ogé visualisasi maranéhanana. Komputasi kabut langkung efektif nalika ngarengsekeun masalah sacara real-time. Aranjeunna nyayogikeun réspon gancang kana pamundut sareng latén minimal dina ngolah data. Hartina, Kabut ngalengkepan "awan" sareng ngalegaan kamampuanana.
Nanging, patarosan utami béda: kumaha sadayana ieu kedah berinteraksi dina kontéks IoT? Protokol komunikasi naon anu paling efektif nalika damel dina sistem gabungan IoT-Fog-Cloud?
Sanajan dominasi katempo tina HTTP, aya angka nu gede ngarupakeun solusi séjén dipaké dina IoT, Halimun jeung Awan sistem. Ieu kusabab IoT kedah ngagabungkeun pungsionalitas rupa-rupa sensor alat sareng kaamanan, kasaluyuan, sareng syarat pangguna anu sanés.
Tapi ngan saukur teu aya ide tunggal ngeunaan arsitéktur rujukan sareng standar komunikasi. Ku alatan éta, nyieun hiji protokol anyar atawa ngaropéa nu geus aya pikeun tugas IoT husus mangrupa salah sahiji tugas pangpentingna nyanghareupan komunitas IT.
Protokol naon anu ayeuna dianggo sareng naon anu tiasa aranjeunna nawiskeun? Hayu urang angka eta kaluar. Tapi ke heula, hayu urang bahas prinsip ékosistem dimana awan, kabut sareng Internét mahluk berinteraksi.
IoT Halimun-to-Awan (F2C) Arsitéktur
Anjeun panginten tiasa perhatoskeun sabaraha usaha anu dilaksanakeun pikeun ngajalajah kauntungan sareng kauntungan anu aya hubunganana sareng manajemén pinter sareng koordinasi IoT, awan sareng kabut. Upami henteu, ieu mangrupikeun tilu inisiatif standarisasi: , и .
Upami sateuacana ngan ukur 2 tingkat anu dianggap, awan sareng alat tungtung, maka arsitéktur anu diusulkeun ngenalkeun tingkat anyar - komputasi kabut. Dina hal ieu, tingkat kabut bisa dibagi kana sababaraha sublevels, gumantung kana spésifik sumberdaya atawa sakumpulan kawijakan anu nangtukeun pamakéan alat béda dina sublevels ieu.
Kumaha sigana abstraksi ieu? Ieu ékosistem IoT-Fog-Cloud has. Alat IoT ngirim data ka server anu langkung gancang sareng alat komputasi pikeun ngarengsekeun masalah anu peryogi latency rendah. Dina sistem anu sami, awan tanggung jawab pikeun ngarengsekeun masalah anu peryogi seueur sumber komputasi atanapi rohangan panyimpen data.
Smartphone, jam tangan pinter sareng gadget sanésna ogé tiasa janten bagian tina IoT. Tapi alat sapertos kitu, sakumaha aturan, nganggo protokol komunikasi proprietary ti pamekar badag. Data IoT anu dihasilkeun ditransferkeun ka lapisan kabut liwat protokol HTTP REST, anu nyayogikeun kalenturan sareng interoperabilitas nalika nyiptakeun jasa RESTful. Ieu penting dina lampu tina kabutuhan pikeun mastikeun kasaluyuan mundur kalawan infrastruktur komputasi aya jalan dina komputer lokal, server atawa klaster server. Sumberdaya lokal, anu disebut "titik kabut," nyaring data anu ditampi sareng ngolahna sacara lokal atanapi kirimkeun ka awan pikeun itungan salajengna.
Awan ngadukung protokol komunikasi anu béda, anu paling umum nyaéta AMQP sareng REST HTTP. Kusabab HTTP dipikanyaho sareng disaluyukeun pikeun Internét, patarosan tiasa timbul: "Naha urang kedah dianggo pikeun damel sareng IoT sareng kabut?" Nanging, protokol ieu ngagaduhan masalah kinerja. Langkung lengkep ihwal ieu engké.
Sacara umum, aya 2 modél protokol komunikasi anu cocog pikeun sistem anu urang butuhkeun. Ieu mangrupikeun pamundut-réspon sareng nyebarkeun-ngalanggan. Modél munggaran leuwih dipikawanoh lega, utamana dina arsitektur server-klien. Klién naroskeun inpormasi ti server, sareng server nampi pamundut éta, prosésna sareng uih deui pesen réspon. Protokol REST HTTP sareng CoAP beroperasi dina modél ieu.
Modél kadua timbul tina kabutuhan nyadiakeun Asynchronous, disebarkeun, gandeng leupas antara sumber generating data jeung panarima data ieu.
Model nganggap tilu pamilon: penerbit (sumber data), calo (dispatcher) jeung palanggan (panarima). Di dieu, klien nu bertindak salaku palanggan teu kudu menta informasi ti server. Gantina ngirim requests, éta ngalanggan kana acara nu tangtu dina sistem ngaliwatan calo a, nu tanggung jawab nyaring sagala pesen asup tur routing aranjeunna antara penerbit jeung palanggan. Sareng penerbit, nalika aya kajadian ngeunaan topik anu tangtu, nyebarkeun éta ka calo, anu ngirim data ngeunaan topik anu dipénta ka palanggan.
Intina, arsitéktur ieu dumasar kana acara. Sareng modél interaksi ieu pikaresepeun pikeun aplikasi dina IoT, awan, kabut kusabab kamampuan pikeun nyayogikeun skalabilitas sareng nyederhanakeun interkonéksi antara alat anu béda, ngadukung komunikasi seueur-ka-loba-loba sareng komunikasi anu teu sinkron. Sababaraha protokol olahtalatah standar anu paling terkenal anu ngagunakeun modél publish-subscribe kalebet MQTT, AMQP, sareng DDS.
Jelas, modél publish-subscribe ngagaduhan seueur kaunggulan:
- Penerbit sareng palanggan henteu kedah terang ngeunaan ayana masing-masing;
- Hiji palanggan tiasa nampi inpormasi tina seueur publikasi anu béda, sareng hiji penerbit tiasa ngirim data ka seueur palanggan anu béda (prinsip seueur-ka-loba);
- Penerbit sareng palanggan henteu kedah aktip dina waktos anu sami pikeun komunikasi, sabab calo (damel salaku sistem antrian) bakal tiasa nyimpen pesen pikeun klien anu ayeuna henteu nyambung ka jaringan.
Sanajan kitu, model pamundut-réspon ogé boga kaunggulan na. Dina kasus dimana kamampuan sisi server pikeun nanganan sababaraha pamundut klien henteu janten masalah, masuk akal ngagunakeun solusi anu kabuktian sareng dipercaya.
Aya ogé protokol anu ngadukung duanana modél. Salaku conto, XMPP sareng HTTP 2.0, anu ngadukung pilihan "push server". IETF ogé parantos ngaluarkeun CoAP. Dina usaha pikeun ngajawab masalah olahtalatah, sababaraha solusi séjén geus dijieun, kayaning protokol WebSockets atawa pamakéan protokol HTTP leuwih QUIC (Gancangan UDP Internet Connections).
Dina kasus WebSockets, sanajan dipaké pikeun mindahkeun data sacara real waktos ti server ka klien web tur nyadiakeun sambungan pengkuh kalayan komunikasi bidirectional simultaneous, teu dimaksudkeun pikeun alat kalawan sumberdaya komputasi kawates. QUIC ogé pantes perhatian, saprak protokol angkutan anyar nyadiakeun loba kasempetan anyar. Tapi saprak QUIC henteu acan standarisasi, éta prématur pikeun ngaduga aplikasi na mungkin sarta dampak dina solusi IoT. Ku kituna urang tetep WebSockets na QUIC dina pikiran kalawan panon ka hareup, tapi urang moal diajar deui di leuwih jéntré pikeun ayeuna.
Saha anu paling lucu di dunya: ngabandingkeun protokol
Ayeuna hayu urang ngobrol ngeunaan kaunggulan sareng kalemahan protokol. Ningali payun, hayu urang geura-giru nyieun cadangan yen euweuh hiji pamingpin jelas. Unggal protokol boga sababaraha kaunggulan / kalemahan.
Waktos tanggepan
Salah sahiji ciri anu paling penting dina protokol komunikasi, khususna dina hubungan sareng Internet of Things, nyaéta waktos réspon. Tapi diantara protokol anu aya, teu aya juara anu jelas anu nunjukkeun tingkat laten minimum nalika damel dina kaayaan anu béda. Tapi aya seueur panalungtikan sareng ngabandingkeun kamampuan protokol.
Contona, ngabandingkeun efektivitas HTTP na MQTT nalika gawé bareng IoT némbongkeun yén waktu respon pikeun requests pikeun MQTT kirang ti HTTP. Jeung iraha Waktu perjalanan buleud (RTT) MQTT sareng CoAP ngungkabkeun yén rata-rata RTT CoAP 20% langkung handap tina MQTT.
nu lain kalayan RTT pikeun protokol MQTT sareng CoAP dilaksanakeun dina dua skenario: jaringan lokal sareng jaringan IoT. Tétéla yén rata-rata RTT 2-3 kali langkung luhur dina jaringan IoT. MQTT sareng QoS0 nunjukkeun hasil anu langkung handap dibandingkeun CoAP, sareng MQTT sareng QoS1 nunjukkeun RTT anu langkung luhur kusabab ACKs dina lapisan aplikasi sareng angkutan. Pikeun tingkat QoS béda, latency jaringan tanpa kamacetan éta milliseconds pikeun MQTT, sarta ratusan microseconds pikeun CoAP. Nanging, émut yén nalika damel dina jaringan anu kirang dipercaya, MQTT anu dijalankeun di luhur TCP bakal nunjukkeun hasil anu béda.
waktos respon pikeun AMQP na MQTT protokol ku cara ningkatkeun payload némbongkeun yén kalawan beban lampu tingkat latency ampir sarua. Tapi nalika nransferkeun data anu ageung, MQTT nunjukkeun waktos réspon anu langkung pondok. dina hiji deui CoAP dibandingkeun sareng HTTP dina skenario komunikasi mesin-ka-mesin sareng alat anu dipasang di luhur kendaraan anu dilengkepan sensor gas, sensor cuaca, sensor lokasi (GPS) sareng antarmuka jaringan seluler (GPRS). Waktu anu diperyogikeun pikeun ngirimkeun pesen CoAP dina jaringan sélulér ampir tilu kali langkung pondok tibatan waktos anu diperyogikeun pikeun nganggo seratan HTTP.
Studi parantos dilakukeun yén dibandingkeun henteu dua, tapi tilu protokol. Salaku conto, kinerja protokol IoT MQTT, DDS na CoAP dina skenario aplikasi médis ngagunakeun émulator jaringan. DDS outperformed MQTT dina watesan latency telemétri diuji dina rupa-rupa kaayaan jaringan goréng. CoAP basis UDP damel saé pikeun aplikasi anu peryogi waktos réspon anu gancang, tapi kusabab éta dumasar kana UDP, aya leungitna pakét anu teu diprediksi signifikan.
Bandwidth
MQTT sareng CoAP dina hal efisiensi bandwidth dilaksanakeun salaku itungan jumlah total data anu dikirimkeun per pesen. CoAP geus nembongkeun throughput leuwih handap MQTT nalika ngirimkeun pesen leutik. Tapi nalika ngabandingkeun efisiensi protokol dina hal rasio jumlah bait inpormasi anu kapaké sareng jumlah total bait anu ditransfer, CoAP tétéla langkung efektif.
di ngagunakeun MQTT, DDS (kalayan TCP salaku protokol angkutan) jeung rubakpita CoAP, kapanggih yén CoAP umumna némbongkeun konsumsi rubakpita comparatively handap, nu teu naek kalawan ngaronjat leungitna pakét jaringan atawa ngaronjat latency jaringan, teu kawas MQTT na DDS, dimana aya paningkatan dina utilization rubakpita dina skenario disebutkeun. Skenario anu sanés kalebet sajumlah ageung alat anu ngirimkeun data sakaligus, anu khas dina lingkungan IoT. Hasilna nunjukkeun yén pikeun panggunaan anu langkung luhur langkung saé ngagunakeun CoAP.
Dina beban hampang, CoAP nganggo bandwidth pangsaeutikna, dituturkeun ku MQTT sareng REST HTTP. Nanging, nalika ukuran muatan ningkat, REST HTTP ngagaduhan hasil anu pangsaéna.
pamakéan énérgi
Isu konsumsi énergi sok penting pisan, sareng khususna dina sistem IoT. Lamun Sedengkeun MQTT jeung HTTP meakeun listrik, HTTP meakeun leuwih. Sareng CoAP langkung seueur dibandingkeun MQTT, ngamungkinkeun manajemén kakuatan. Tapi, dina skenario basajan, MQTT leuwih cocog pikeun nukeur informasi dina jaringan Internet of Things, utamana lamun euweuh larangan kakuatan.
Eksperimen anu ngabandingkeun kamampuan AMQP sareng MQTT dina jaringan nirkabel sélulér atanapi teu stabil mendakan yén AMQP nawiskeun kamampuan kaamanan langkung seueur bari MQTT langkung éfisién énergi.
kasalametan
Kaamanan mangrupikeun masalah kritis sanés anu diangkat nalika ngulik topik Internet of Things sareng komputasi kabut / awan. Mékanisme kaamanan biasana dumasar kana TLS dina HTTP, MQTT, AMQP sareng XMPP, atanapi DTLS di CoAP, sareng ngadukung duanana varian DDS.
TLS sareng DTLS dimimitian ku prosés ngadegkeun komunikasi antara sisi klien sareng server pikeun tukeur suite sareng konci cipher anu didukung. Duanana pihak negotiate susunan pikeun mastikeun yén komunikasi salajengna lumangsung dina saluran aman. Beda antara dua perenahna di modifikasi leutik nu ngidinan DTLS basis UDP pikeun digawé ngaliwatan sambungan dipercaya.
di Sababaraha palaksanaan anu béda tina TLS sareng DTLS mendakan yén TLS ngalaksanakeun padamelan anu langkung saé. Serangan kana DTLS langkung suksés kusabab kasabaran kasalahanna.
Nanging, masalah anu paling ageung sareng protokol ieu nyaéta yén aranjeunna henteu dirancang pikeun dianggo dina IoT sareng henteu dimaksudkeun pikeun dianggo dina kabut atanapi awan. Ngaliwatan handshaking, aranjeunna nambahkeun lalulintas tambahan kalayan unggal ngadegna sambungan, nu drains sumberdaya komputasi. Rata-rata, aya paningkatan 6,5% pikeun TLS sareng 11% pikeun DTLS dina overhead dibandingkeun sareng komunikasi tanpa lapisan kaamanan. Dina lingkungan-euyeub sumberdaya, nu ilaharna lokasina di tingkat, ieu moal jadi masalah, tapi dina sambungan antara IoT jeung tingkat kabut, ieu janten watesan penting.
Naon anu kudu dipilih? Teu aya jawaban anu jelas. MQTT sareng HTTP sigana mangrupikeun protokol anu paling ngajangjikeun sabab dianggap solusi IoT anu langkung dewasa sareng langkung stabil dibandingkeun sareng protokol anu sanés.
Solusi dumasar kana protokol komunikasi ngahiji
Praktek solusi tunggal-protokol ngagaduhan seueur kalemahan. Salaku conto, protokol anu cocog sareng lingkungan anu diwatesan tiasa henteu tiasa dianggo dina domain anu ngagaduhan syarat kaamanan anu ketat. Kalayan ieu dina pikiran, urang ditinggalkeun pikeun miceun ampir kabéh mungkin solusi single-protocol dina ékosistem Fog-to-Cloud di IoT, iwal MQTT na REST HTTP.
REST HTTP salaku solusi protokol tunggal
Aya conto anu saé ngeunaan kumaha REST HTTP requests sareng réspon berinteraksi dina rohangan IoT-to-Fog: . Sato anu dilengkepan sensor wearable (IoT klien, C) jeung dikawasa via komputasi awan ku sistem pertanian pinter (Server kabut, S).
The lulugu sahiji metodeu POST nangtukeun sumberdaya pikeun ngaropea (/ peternakan / sato) kitu ogé versi HTTP na tipe eusi, nu dina hal ieu mangrupa objek JSON ngalambangkeun peternakan sato nu sistem pikeun ngatur (Dulcinea / sapi) . Tanggapan ti server nunjukkeun yén pamundut éta suksés ku ngirim kode status HTTPS 201 (sumberdaya dijieun). Metoda GET kudu nangtukeun ngan sumberdaya dipénta dina URI (contona, / tegalan / sato / 1), nu mulih JSON ngagambarkeun sato jeung ID nu ti server.
Metodeu PUT dianggo nalika sababaraha catetan sumber daya khusus kedah diropéa. Dina hal ieu, sumberdaya nu nangtukeun URI pikeun parameter dirobah sarta nilai ayeuna (contona, nunjukkeun yén sapi ayeuna leumpang, / tegalan / sato / 1? kaayaan = leumpang). Tungtungna, metode DELETE dianggo sami sareng metode GET, tapi ngan saukur ngahapus sumberdaya salaku hasil tina operasi.
MQTT salaku solusi tunggal-protokol
Hayu urang nyandak tegalan pinter sarua, tapi tinimbang REST HTTP kami nganggo protokol MQTT. A server lokal kalawan perpustakaan Mosquitto dipasang meta salaku calo a. Dina conto ieu, komputer basajan (disebut salaku server tegalan) buah prambus Pi fungsi salaku klien MQTT, dilaksanakeun ngaliwatan pamasangan perpustakaan Paho MQTT, nu sapinuhna cocog sareng calo Mosquitto.
Klién ieu pakait sareng lapisan abstraksi IoT anu ngagambarkeun alat anu gaduh kamampuan sensing sareng komputasi. Mediator, di sisi séjén, pakait jeung tingkat luhur abstraksi, ngagambarkeun titik komputasi kabut dicirikeun ku kapasitas processing jeung neundeun gede.
Dina skenario tegalan pinter anu diusulkeun, Raspberry Pi nyambung ka accelerometer, GPS, sareng sensor suhu sareng nyebarkeun data tina sensor ieu ka titik kabut. Sakumaha anjeun terang, MQTT ngarawat topik salaku hirarki. Hiji penerbit MQTT tunggal bisa nyebarkeun pesen ka set husus tina jejer. Dina hal urang aya tilu di antarana. Pikeun sénsor anu ngukur suhu dina kandang sato, klien milih téma (ternak sato / gudang / suhu). Pikeun sensor nu ngukur lokasi GPS jeung gerakan sato ngaliwatan accelerometer nu, klien bakal nyebarkeun apdet pikeun (sato / sato / GPS) jeung (sato / sato / gerakan).
Inpormasi ieu bakal dikirimkeun ka calo, anu tiasa nyimpen samentawis dina pangkalan data lokal upami palanggan anu kabetot sumping engké.
Salian server lokal, nu tindakan minangka hiji calo MQTT dina halimun jeung nu Raspberry Pis, akting salaku klien MQTT, ngirim data sensor, meureun aya calo MQTT sejen di tingkat awan. Dina hal ieu, informasi dikirimkeun ka calo lokal bisa disimpen samentara dina database lokal jeung / atawa dikirim ka awan. Calo MQTT kabut dina kaayaan ieu dianggo pikeun ngahubungkeun sadaya data sareng calo MQTT awan. Kalayan arsitéktur ieu, pangguna aplikasi sélulér tiasa ngalanggan duanana calo.
Upami sambungan ka salah sahiji calo (contona, awan) gagal, pangguna akhir bakal nampi inpormasi ti anu sanés (kabut). Ieu mangrupikeun ciri khas tina gabungan kabut sareng sistem komputasi awan. Sacara standar, aplikasi mobile tiasa dikonpigurasikeun pikeun nyambung ka calo MQTT kabut heula, sareng upami éta gagal, nyambung ka calo MQTT awan. Solusi ieu ngan ukur salah sahiji seueur dina sistem IoT-F2C.
Solusi multi-protokol
Solusi protokol tunggal populer kusabab palaksanaan anu langkung gampang. Tapi jelas yén dina sistem IoT-F2C asup akal pikeun ngagabungkeun protokol anu béda. Idena nyaéta yén protokol anu béda tiasa beroperasi dina tingkat anu béda. Candak, contona, tilu abstraksi: lapisan IoT, kabut sareng komputasi awan. Alat dina tingkat IoT umumna dianggap kawates. Pikeun tinjauan ieu, hayu urang anggap tingkatan IoT salaku anu paling kaampeuh, awan anu pangsaeutikna, sareng komputasi kabut salaku "tempat di tengah". Tétéla éta antara IoT sareng abstraksi kabut, solusi protokol ayeuna kalebet MQTT, CoAP sareng XMPP. Antara kabut sareng awan, sabalikna, AMQP mangrupikeun salah sahiji protokol utama anu dianggo, sareng REST HTTP, anu kusabab kalenturanna ogé dianggo antara IoT sareng lapisan kabut.
Masalah utama di dieu nyaéta interoperabilitas protokol sareng betah mindahkeun pesen tina hiji protokol ka protokol anu sanés. Ideally, dina mangsa nu bakal datang, arsitéktur hiji sistem Internet of Things kalawan sumberdaya awan jeung kabut bakal bebas tina protokol komunikasi dipaké sarta bakal mastikeun interoperability alus antara protokol béda.
Kusabab ieu henteu ayeuna, éta masuk akal pikeun ngagabungkeun protokol anu henteu aya bédana anu signifikan. Pikeun tujuan ieu, hiji solusi poténsial dumasar kana kombinasi dua protokol anu nuturkeun gaya arsitéktur anu sami, REST HTTP sareng CoAP. Solusi anu sanésna diusulkeun dumasar kana kombinasi dua protokol anu nawiskeun komunikasi nyebarkeun-langganan, MQTT sareng AMQP. Nganggo konsép anu sami (duanana MQTT sareng AMQP nganggo calo, CoAP sareng HTTP nganggo REST) ngajantenkeun kombinasi ieu langkung gampang dilaksanakeun sareng peryogi usaha integrasi anu kirang.
Gambar (a) nembongkeun dua model dumasar pamundut-réspon, HTTP na CoAP, sarta mungkin panempatan maranéhanana dina solusi IoT-F2C. Kusabab HTTP mangrupikeun salah sahiji protokol anu paling terkenal sareng diadopsi dina jaringan modéren, teu mungkin yén éta bakal lengkep diganti ku protokol olahtalatah anu sanés. Di antara titik-titik anu ngalambangkeun alat anu kuat anu aya di antara awan sareng kabut, REST HTTP mangrupikeun solusi anu pinter.
Di sisi anu sanés, pikeun alat anu gaduh sumber komputasi kawates anu komunikasi antara lapisan Kabut sareng IoT, langkung éfisién ngagunakeun CoAP. Salah sahiji kaunggulan badag CoAP sabenerna kasaluyuan na HTTP, saprak duanana protokol dumasar kana prinsip REST.
Gambar (b) nunjukkeun dua model komunikasi nyebarkeun-langganan dina skenario anu sami, kalebet MQTT sareng AMQP. Sanajan duanana protokol bisa hypothetically dipaké pikeun komunikasi antara titik dina unggal lapisan abstraksi, posisi maranéhanana kudu ditangtukeun dumasar kana kinerja. MQTT dirarancang salaku protokol anu hampang pikeun alat-alat anu sumber daya komputasi terbatas, ku kituna tiasa dianggo pikeun komunikasi IoT-Fog. AMQP leuwih cocog pikeun alat nu leuwih kuat, nu ideally bakal posisi eta antara titik kabut jeung awan. Gantina MQTT, protokol XMPP tiasa dianggo dina IoT sabab dianggap hampang. Tapi teu jadi loba dipaké dina skenario kitu.
papanggihan
Teu mungkin yén salah sahiji protokol anu dibahas bakal cekap pikeun nutupan sadaya komunikasi dina sistem, tina alat anu sumber daya komputasi terbatas dugi ka server awan. Panaliti mendakan yén dua pilihan anu paling ngajangjikeun anu paling dianggo ku pamekar nyaéta MQTT sareng HTTP RESTful. Dua protokol ieu henteu ngan ukur anu paling dewasa sareng stabil, tapi ogé kalebet seueur palaksanaan anu didokumentasikeun sareng suksés sareng sumber online.
Kusabab stabilitas sareng konfigurasi saderhana, MQTT mangrupikeun protokol anu parantos ngabuktikeun kinerja anu unggul dina waktosna nalika dianggo dina tingkat IoT sareng alat anu terbatas. Dina bagian sistem dimana komunikasi kawates sareng konsumsi batré henteu janten masalah, sapertos sababaraha domain kabut sareng kalolobaan komputasi awan, RESTful HTTP mangrupikeun pilihan anu gampang. CoAP ogé kedah dipertimbangkeun sabab éta ogé ngembang pesat salaku standar olahtalatah IoT sareng kamungkinan éta bakal ngahontal tingkat stabilitas sareng kematangan anu sami sareng MQTT sareng HTTP dina waktos anu caket. Tapi standar ayeuna ngembang, anu hadir sareng masalah kasaluyuan jangka pondok.
Naon deui anu anjeun tiasa baca dina blog?
→
→
→
→
→
Ngalanggan kami -kanal supados anjeun henteu sono kana tulisan salajengna! Kami nyerat henteu langkung ti dua kali saminggu sareng ngan ukur dina bisnis.
sumber: www.habr.com