Pangembangan teknologi ing bidang piranti lunak lan perangkat keras, munculé protokol komunikasi anyar wis nyebabake ekspansi Internet of Things (IoT). Jumlah piranti saya tambah saben dina lan ngasilake data sing akeh banget. Mulane, perlu kanggo arsitektur sistem sing trep sing bisa ngolah, nyimpen lan ngirim data kasebut.
Saiki layanan awan digunakake kanggo tujuan kasebut. Nanging, paradigma komputasi kabut (Fog) sing tambah populer bisa nglengkapi solusi awan kanthi skala lan ngoptimalake infrastruktur IoT.
Awan bisa nutupi paling akeh panjaluk IoT. Contone, kanggo nyedhiyakake pemantauan layanan, pangolahan cepet saka jumlah data sing digawe dening piranti, uga visualisasi. Komputasi kabut luwih efektif nalika ngrampungake masalah wektu nyata. Padha menehi respon cepet kanggo panjalukan lan latensi minimal ing pangolahan data. Yaiku, Kabut nglengkapi "awan" lan ngembangake kemampuane.
Nanging, pitakonan utama beda: kepiye kabeh iki kudu sesambungan ing konteks IoT? Apa protokol komunikasi sing paling efektif nalika nggarap sistem gabungan IoT-Fog-Cloud?
Sanajan dominasi HTTP sing katon, ana akeh solusi liyane sing digunakake ing sistem IoT, Fog lan Cloud. Iki amarga IoT kudu nggabungake fungsi macem-macem sensor piranti kanthi keamanan, kompatibilitas, lan syarat pangguna liyane.
Nanging ora ana gagasan siji-sijine babagan arsitektur referensi lan standar komunikasi. Mulane, nggawe protokol anyar utawa ngowahi sing wis ana kanggo tugas IoT tartamtu minangka salah sawijining tugas paling penting sing diadhepi komunitas IT.
Protokol apa sing saiki digunakake lan apa sing bisa ditawakake? Ayo dipikirake. Nanging pisanan, ayo ngrembug prinsip ekosistem ing endi awan, pedhut lan Internet samubarang sesambungan.
Arsitektur IoT Fog-to-Cloud (F2C).
Sampeyan bisa uga wis weruh carane akeh gaweyan sing ditindakake kanggo njelajah kaluwihan lan keuntungan sing ana gandhengane karo manajemen IoT, awan lan kabut sing cerdas lan koordinasi. Yen ora, ana telung inisiatif standarisasi: , и .
Yen sadurunge mung 2 tingkat sing dianggep, awan lan piranti pungkasan, mula arsitektur sing diusulake ngenalake level anyar - komputasi kabut. Ing kasus iki, tingkat kabut bisa dipérang dadi sawetara sublevel, gumantung saka spesifik sumber daya utawa sakumpulan kabijakan sing nemtokake panggunaan piranti beda ing sublevel kasebut.
Kaya apa abstraksi iki? Iki minangka ekosistem IoT-Fog-Cloud sing khas. Piranti IoT ngirim data menyang server lan piranti komputasi sing luwih cepet kanggo ngatasi masalah sing mbutuhake latensi sing sithik. Ing sistem sing padha, awan tanggung jawab kanggo ngrampungake masalah sing mbutuhake sumber daya komputasi utawa papan panyimpenan data sing akeh.
Smartphone, jam tangan pinter lan gadget liyane uga bisa dadi bagian saka IoT. Nanging piranti kasebut, minangka aturan, nggunakake protokol komunikasi proprietary saka pangembang gedhe. Data IoT sing digawe ditransfer menyang lapisan kabut liwat protokol HTTP REST, sing nyedhiyakake keluwesan lan interoperabilitas nalika nggawe layanan RESTful. Iki penting amarga kudu njamin kompatibilitas mundur karo infrastruktur komputasi sing ana ing komputer lokal, server utawa kluster server. Sumber daya lokal, sing diarani "kelenjar kabut", nyaring data sing ditampa lan diproses sacara lokal utawa dikirim menyang awan kanggo petungan luwih lanjut.
Awan ndhukung protokol komunikasi sing beda-beda, sing paling umum yaiku AMQP lan REST HTTP. Wiwit HTTP kondhang lan dicocogake kanggo Internet, bisa uga ana pitakonan: "Apa ora kudu digunakake kanggo nggarap IoT lan kabut?" Nanging, protokol iki duwe masalah kinerja. Liyane babagan iki mengko.
Umumé, ana 2 model protokol komunikasi sing cocog kanggo sistem sing kita butuhake. Iki minangka request-respons lan nerbitake-langganan. Model pisanan luwih dikenal, utamane ing arsitektur server-klien. Klien njaluk informasi saka server, lan server nampa panjaluk kasebut, ngolah lan ngasilake pesen respon. Protokol HTTP lan CoAP REST beroperasi ing model iki.
Model kapindho muncul saka perlu kanggo nyedhiyakake kopling sing ora sinkron, disebarake, longgar antarane sumber sing ngasilake data lan panampa data iki.
Model kasebut nganggep telung peserta: penerbit (sumber data), broker (dispatcher) lan pelanggan (penerima). Ing kene, klien sing dadi pelanggan ora kudu njaluk informasi saka server. Tinimbang ngirim panjalukan, langganan acara tartamtu ing sistem liwat broker, sing tanggung jawab kanggo nyaring kabeh pesen sing mlebu lan nuntun antarane penerbit lan pelanggan. Lan penerbit, nalika ana acara babagan topik tartamtu, nerbitake menyang broker, sing ngirim data babagan topik sing dijaluk menyang pelanggan.
Intine, arsitektur iki adhedhasar acara. Lan model interaksi iki menarik kanggo aplikasi ing IoT, awan, kabut amarga kemampuan kanggo nyedhiyakake skalabilitas lan nyederhanakake interkoneksi antarane piranti sing beda-beda, ndhukung komunikasi akeh-kanggo-akeh dinamis lan komunikasi asinkron. Sawetara protokol olahpesen standar sing paling misuwur sing nggunakake model langganan-publish kalebu MQTT, AMQP, lan DDS.
Temenan, model publish-subscribe duwe akeh kaluwihan:
- Penerbit lan pelanggan ora perlu ngerti babagan eksistensi saben liyane;
- Siji pelanggan bisa nampa informasi saka macem-macem publikasi, lan siji penerbit bisa ngirim data menyang akeh pelanggan sing beda (prinsip akeh-kanggo-akeh);
- Penerbit lan pelanggan ora kudu aktif ing wektu sing padha kanggo komunikasi, amarga broker (makarya minangka sistem antrian) bakal bisa nyimpen pesen kanggo klien sing saiki ora nyambung menyang jaringan.
Nanging, model request-respons uga nduweni kekiyatan. Ing kasus ngendi kemampuan sisih server kanggo nangani macem-macem panjalukan klien ora masalah, iku ndadekake pangertèn kanggo nggunakake bukti, solusi dipercaya.
Ana uga protokol sing ndhukung loro model. Contone, XMPP lan HTTP 2.0, sing ndhukung opsi "push server". IETF uga wis ngetokake CoAP. Ing upaya kanggo ngatasi masalah olahpesen, sawetara solusi liyane wis digawe, kayata protokol WebSockets utawa nggunakake protokol HTTP liwat QUIC (Sambungan Internet UDP Cepet).
Ing kasus WebSockets, sanajan digunakake kanggo nransfer data ing wektu nyata saka server menyang klien web lan nyedhiyakake sambungan sing terus-terusan kanthi komunikasi bidirectional bebarengan, ora dimaksudake kanggo piranti kanthi sumber daya komputasi sing winates. QUIC uga pantes diwenehi perhatian, amarga protokol transportasi anyar nyedhiyakake akeh kesempatan anyar. Nanging amarga QUIC durung standar, prediksi prediksi bisa ditrapake lan pengaruhe ing solusi IoT. Supaya kita tetep WebSockets lan QUIC ing atine karo mripat kanggo mangsa, nanging kita ora bakal sinau luwih rinci kanggo saiki.
Sapa sing paling lucu ing donya: mbandhingake protokol
Saiki ayo ngomong babagan kekiyatan lan kelemahane protokol. Ngadhepi ngarep, ayo padha enggal-enggal gawe leladen yen ora ana pimpinan sing jelas. Saben protokol duwe sawetara kaluwihan / cacat.
Wektu tanggepan
Salah sawijining ciri protokol komunikasi sing paling penting, utamane sing ana hubungane karo Internet of Things, yaiku wektu nanggepi. Nanging ing antarane protokol sing ana, ora ana pemenang sing jelas sing nuduhake tingkat latensi minimal nalika digunakake ing kahanan sing beda. Nanging ana akeh riset lan mbandhingake kemampuan protokol.
Contone, mbandhingake efektifitas HTTP lan MQTT nalika nggarap IoT nuduhake yen wektu respon kanggo panjalukan kanggo MQTT kurang saka HTTP. Lan nalika Wektu perjalanan bolak-balik (RTT) MQTT lan CoAP nuduhake yen rata-rata RTT CoAP 20% kurang saka MQTT.
Liyane karo RTT kanggo protokol MQTT lan CoAP ditindakake ing rong skenario: jaringan lokal lan jaringan IoT. Ternyata rata-rata RTT 2-3 kaping luwih dhuwur ing jaringan IoT. MQTT karo QoS0 nuduhake asil sing luwih murah dibandhingake karo CoAP, lan MQTT karo QoS1 nuduhake RTT sing luwih dhuwur amarga ACK ing lapisan aplikasi lan transportasi. Kanggo tingkat QoS sing beda, latensi jaringan tanpa kemacetan yaiku milidetik kanggo MQTT, lan atusan mikrodetik kanggo CoAP. Nanging, kudu eling yen nalika nggarap jaringan sing kurang dipercaya, MQTT sing mlaku ing ndhuwur TCP bakal nuduhake asil sing beda.
wektu nanggepi kanggo AMQP lan MQTT protokol dening nambah payload nuduhake yen karo mbukak cahya tingkat latensi meh padha. Nanging nalika nransfer jumlah gedhe saka data, MQTT nduduhake wektu respon luwih cendhek. ing siji maneh CoAP dibandhingake karo HTTP ing skenario komunikasi mesin-kanggo-mesin kanthi piranti sing dipasang ing ndhuwur kendaraan sing dilengkapi sensor gas, sensor cuaca, sensor lokasi (GPS) lan antarmuka jaringan seluler (GPRS). Wektu sing dibutuhake kanggo ngirim pesen CoAP liwat jaringan seluler meh kaping telu luwih cendhek tinimbang wektu sing dibutuhake kanggo nggunakake pesen HTTP.
Pasinaon wis ditindakake sing dibandhingake ora loro, nanging telung protokol. Tuladhane, kinerja protokol IoT MQTT, DDS lan CoAP ing skenario aplikasi medical nggunakake emulator jaringan. DDS ngluwihi MQTT babagan latensi telemetri sing diuji ing macem-macem kahanan jaringan sing ora apik. CoAP adhedhasar UDP bisa digunakake kanthi apik kanggo aplikasi sing mbutuhake wektu nanggepi cepet, nanging amarga adhedhasar UDP, ana mundhut paket sing ora bisa ditebak.
Bandwidth
MQTT lan CoAP babagan efisiensi bandwidth ditindakake minangka pitungan jumlah total data sing dikirim saben pesen. CoAP wis nuduhake throughput luwih murah tinimbang MQTT nalika ngirim pesen cilik. Nanging nalika mbandhingake efisiensi protokol babagan rasio jumlah bita informasi sing migunani kanggo jumlah total bita sing ditransfer, CoAP dadi luwih efektif.
ing nggunakake MQTT, DDS (karo TCP minangka protokol transportasi) lan bandwidth CoAP, ditemokake yen CoAP umume nuduhake konsumsi bandwidth sing relatif murah, sing ora mundhak kanthi mundhut paket jaringan utawa tambah latensi jaringan, ora kaya MQTT lan DDS, ing ngendi ana Tambah ing panggunaan bandwidth ing skenario kasebut. Skenario liyane kalebu akeh piranti sing ngirim data bebarengan, sing khas ing lingkungan IoT. Asil kasebut nuduhake yen kanggo panggunaan sing luwih dhuwur luwih becik nggunakake CoAP.
Ing beban entheng, CoAP nggunakake bandwidth paling sithik, diikuti MQTT lan REST HTTP. Nanging, nalika ukuran muatan tambah, REST HTTP entuk asil sing paling apik.
Konsumsi Daya
Masalah konsumsi energi mesthi penting banget, lan utamane ing sistem IoT. Yen Nalika MQTT lan HTTP nganggo listrik, HTTP nganggo luwih akeh. Lan CoAP luwih akeh dibandhingake karo MQTT, ngidini manajemen daya. Nanging, ing skenario sing prasaja, MQTT luwih cocok kanggo ijol-ijolan informasi ing jaringan Internet of Things, utamane yen ora ana watesan daya.
Eksperimen sing mbandhingake kemampuan AMQP lan MQTT ing testbed jaringan nirkabel seluler utawa ora stabil nemokake yen AMQP nawakake kemampuan keamanan luwih akeh nalika MQTT luwih efisien energi.
Keamanan
Keamanan minangka masalah kritis liyane nalika sinau topik Internet of Things lan komputasi kabut / awan. Mekanisme keamanan biasane adhedhasar TLS ing HTTP, MQTT, AMQP lan XMPP, utawa DTLS ing CoAP, lan ndhukung loro varian DDS.
TLS lan DTLS diwiwiti kanthi proses nggawe komunikasi antarane sisi klien lan server kanggo ngganti suite lan kunci cipher sing didhukung. Loro-lorone pihak rembugan mranata kanggo mesthekake yen komunikasi luwih ana ing saluran aman. Bentenipun antarane loro dumunung ing modifikasi cilik sing ngidini DTLS basis UDP bisa liwat sambungan ora dipercaya.
ing Sawetara implementasi beda saka TLS lan DTLS nemokake yen TLS nindakake tugas sing luwih apik. Serangan ing DTLS luwih sukses amarga toleransi kesalahane.
Nanging, masalah paling gedhe karo protokol iki yaiku asline ora dirancang kanggo digunakake ing IoT lan ora dimaksudake kanggo kerja ing kabut utawa awan. Liwat handshaking, padha nambah lalu lintas tambahan karo saben panyiapan sambungan, kang saluran sumber daya komputerisasi. Rata-rata, ana paningkatan 6,5% kanggo TLS lan 11% kanggo DTLS ing overhead dibandhingake komunikasi tanpa lapisan keamanan. Ing lingkungan sing sugih sumber daya, sing biasane ana ing tingkat, iki ora bakal dadi masalah, nanging ing sambungan antarane IoT lan tingkat kabut, iki dadi watesan penting.
Apa sing kudu dipilih? Ora ana jawaban sing jelas. MQTT lan HTTP katon minangka protokol sing paling njanjeni amarga dianggep minangka solusi IoT sing luwih diwasa lan luwih stabil dibandhingake karo protokol liyane.
Solusi adhedhasar protokol komunikasi terpadu
Praktek solusi siji-protokol nduweni akeh kekurangan. Contone, protokol sing cocog karo lingkungan sing diwatesi bisa uga ora bisa digunakake ing domain sing nduweni syarat keamanan sing ketat. Kanthi pikiran iki, kita kudu mbuwang meh kabeh solusi protokol siji sing bisa ditindakake ing ekosistem Fog-to-Cloud ing IoT, kajaba MQTT lan REST HTTP.
REST HTTP minangka solusi protokol siji
Ana conto sing apik babagan carane panjaluk lan respon HTTP REST berinteraksi ing ruang IoT-to-Fog: . Kéwan kasebut dilengkapi sensor sing bisa dipakai (klien IoT, C) lan dikontrol liwat komputasi awan kanthi sistem pertanian cerdas (Server kabut, S).
Header metode POST nemtokake sumber daya kanggo ngowahi (/ peternakan / kewan) uga versi HTTP lan jinis konten, sing ing kasus iki minangka obyek JSON sing makili peternakan kewan sing bakal dikelola sistem (Dulcinea / sapi) . Tanggepan saka server nuduhake yen panjaluk kasebut sukses kanthi ngirim kode status HTTPS 201 (sumber daya digawe). Cara GET kudu nemtokake mung sumber daya sing dijaluk ing URI (contone, / farm / kewan / 1), sing ngasilake perwakilan JSON saka kewan karo ID kasebut saka server.
Cara PUT digunakake nalika sawetara rekaman sumber daya tartamtu kudu dianyari. Ing kasus iki, sumber kasebut nemtokake URI kanggo parameter sing bakal diganti lan nilai saiki (contone, nuduhake yen sapi lagi mlaku, / farm / kewan / 1? negara = mlaku). Pungkasan, metode DELETE digunakake kanthi cara sing padha karo metode GET, nanging mung mbusak sumber daya minangka asil saka operasi.
MQTT minangka solusi protokol tunggal
Ayo padha njupuk farm pinter, nanging tinimbang REST HTTP kita nggunakake protokol MQTT. Server lokal karo perpustakaan Mosquitto diinstal tumindak minangka makelar. Ing conto iki, komputer prasaja (diarani minangka server farm) Raspberry Pi serves minangka klien MQTT, dipun ginakaken liwat instalasi saka perpustakaan Paho MQTT, kang kebak kompatibel karo broker Mosquitto.
Klien iki cocog karo lapisan abstraksi IoT sing makili piranti kanthi kemampuan sensing lan komputasi. Mediator, ing sisih liya, cocog karo tingkat abstraksi sing luwih dhuwur, sing nuduhake simpul komputasi kabut sing ditondoi kanthi kapasitas pangolahan lan panyimpenan sing luwih gedhe.
Ing skenario farm pinter sing diusulake, Raspberry Pi nyambung menyang accelerometer, GPS, lan sensor suhu lan nerbitake data saka sensor kasebut menyang simpul kabut. Kaya sing sampeyan ngerteni, MQTT nganggep topik minangka hirarki. Penerbit MQTT siji bisa nerbitake pesen menyang topik tartamtu. Ing kasus kita ana telu. Kanggo sensor sing ngukur suhu ing kandhang kewan, klien milih tema (animalfarm / gudang / suhu). Kanggo sensor sing ngukur lokasi GPS lan gerakan kewan liwat accelerometer, klien bakal nerbitaké nganyari kanggo (animalfarm/ animal/GPS) lan (animalfarm/ animal/movement).
Informasi iki bakal dikirim menyang makelar, sing bisa nyimpen sementara ing basis data lokal yen ana pelanggan liyane sing kasengsem teka mengko.
Saliyane server lokal, sing tumindak minangka broker MQTT ing kabut lan Raspberry Pis, tumindak minangka klien MQTT, ngirim data sensor, bisa uga ana broker MQTT liyane ing tingkat awan. Ing kasus iki, informasi sing dikirim menyang makelar lokal bisa disimpen sementara ing basis data lokal lan / utawa dikirim menyang awan. Broker MQTT kabut ing kahanan iki digunakake kanggo nggandhengake kabeh data karo broker MQTT awan. Kanthi arsitektur iki, pangguna aplikasi seluler bisa langganan loro makelar kasebut.
Yen sambungan menyang salah siji makelar (contone, awan) gagal, pangguna pungkasan bakal nampa informasi saka liyane (kabut). Iki minangka fitur karakteristik gabungan sistem komputasi awan lan kabut. Kanthi gawan, aplikasi seluler bisa dikonfigurasi kanggo nyambung menyang broker MQTT kabut dhisik, lan yen gagal, nyambung menyang broker MQTT awan. Solusi iki mung salah siji saka akeh sistem IoT-F2C.
Solusi multi-protokol
Solusi protokol tunggal populer amarga implementasine luwih gampang. Nanging cetha yen ing sistem IoT-F2C iku ndadekake pangertèn kanggo gabungke protokol beda. Ide iki yaiku protokol sing beda bisa digunakake ing tingkat sing beda. Contone, njupuk telung abstraksi: lapisan IoT, kabut lan komputasi awan. Piranti ing tingkat IoT umume dianggep winates. Kanggo ringkesan iki, ayo nimbang tingkatan IoT minangka sing paling kendala, awan sing paling sithik, lan komputasi kabut minangka "nang endi wae ing tengah." Ternyata ing antarane IoT lan abstraksi kabut, solusi protokol saiki kalebu MQTT, CoAP lan XMPP. Antarane kabut lan awan, ing sisih liya, AMQP minangka salah sawijining protokol utama sing digunakake, bebarengan karo REST HTTP, sing amarga keluwesane uga digunakake ing antarane lapisan IoT lan kabut.
Masalah utama ing kene yaiku interoperabilitas protokol lan gampang ngirim pesen saka siji protokol menyang protokol liyane. Saenipun, ing mangsa ngarep, arsitektur sistem Internet of Things kanthi sumber awan lan kabut bakal bebas saka protokol komunikasi sing digunakake lan bakal njamin interoperabilitas sing apik ing antarane protokol sing beda-beda.
Amarga saiki ora kedadeyan, mula kudu nggabungake protokol sing ora ana bedane sing signifikan. Kanggo tujuan iki, siji solusi potensial adhedhasar kombinasi rong protokol sing ngetutake gaya arsitektur sing padha, REST HTTP lan CoAP. Solusi liyane sing diusulake adhedhasar kombinasi rong protokol sing nawakake komunikasi nerbitake-langganan, MQTT lan AMQP. Nggunakake konsep sing padha (loro MQTT lan AMQP nggunakake makelar, CoAP lan HTTP nggunakake REST) nggawe kombinasi kasebut luwih gampang dileksanakake lan mbutuhake upaya integrasi sing kurang.
Gambar (a) nuduhake rong model adhedhasar panjalukan, HTTP lan CoAP, lan kemungkinan panggonane ing solusi IoT-F2C. Wiwit HTTP minangka salah sawijining protokol sing paling misuwur lan diadopsi ing jaringan modern, mesthine ora bakal diganti kanthi protokol olahpesen liyane. Antarane simpul sing makili piranti kuat sing ana ing antarane awan lan kabut, REST HTTP minangka solusi sing cerdas.
Ing sisih liya, kanggo piranti kanthi sumber daya komputasi winates sing komunikasi ing antarane lapisan Fog lan IoT, luwih efisien nggunakake CoAP. Salah sawijining kaluwihan gedhe saka CoAP yaiku kompatibilitas karo HTTP, amarga loro protokol kasebut adhedhasar prinsip REST.
Gambar (b) nuduhake rong model komunikasi nerbitake-langganan ing skenario sing padha, kalebu MQTT lan AMQP. Senajan loro protokol bisa hypothetically digunakake kanggo komunikasi antarane simpul ing saben lapisan abstraksi, posisi kudu ditemtokake adhedhasar kinerja. MQTT dirancang minangka protokol entheng kanggo piranti kanthi sumber daya komputasi winates, saengga bisa digunakake kanggo komunikasi IoT-Fog. AMQP luwih cocok kanggo piranti sing luwih kuat, sing saenipun nempatake ing antarane simpul kabut lan awan. Tinimbang MQTT, protokol XMPP bisa digunakake ing IoT amarga dianggep entheng. Nanging ora digunakake kanthi akeh ing skenario kasebut.
temonan
Ora mungkin salah sawijining protokol sing dibahas bakal cukup kanggo nutupi kabeh komunikasi ing sistem, saka piranti kanthi sumber daya komputasi winates nganti server maya. Panliten kasebut nemokake yen rong pilihan sing paling njanjeni sing paling akeh digunakake pangembang yaiku MQTT lan HTTP RESTful. Iki loro protokol ora mung paling diwasa lan stabil, nanging uga kalebu akeh implementasine uga-didokumentasikan lan sukses lan sumber daya online.
Amarga stabilitas lan konfigurasi sing prasaja, MQTT minangka protokol sing wis mbuktekake kinerja sing unggul sajrone wektu nalika digunakake ing level IoT kanthi piranti sing winates. Ing bagean sistem sing komunikasi lan konsumsi baterei sing winates ora dadi masalah, kayata sawetara domain kabut lan umume komputasi awan, RESTful HTTP minangka pilihan sing gampang. CoAP uga kudu digatekake amarga uga berkembang kanthi cepet minangka standar olahpesen IoT lan kemungkinan bakal tekan tingkat stabilitas lan kadewasan sing padha karo MQTT lan HTTP ing mangsa ngarep. Nanging standar kasebut saiki berkembang, sing ana masalah kompatibilitas jangka pendek.
Apa maneh sing bisa diwaca ing blog?
→
→
→
→
→
Langganan kita -saluran supaya sampeyan ora kantun artikel sabanjure! Kita nulis ora luwih saka kaping pindho saben minggu lan mung babagan bisnis.
Source: www.habr.com