Dasturiy ta'minot va texnik vositalar sohasidagi texnologiyalarning rivojlanishi, yangi aloqa protokollarining paydo bo'lishi narsalar Interneti (IoT) ning kengayishiga olib keldi. Qurilmalar soni kundan-kunga ortib bormoqda va ular juda katta hajmdagi ma'lumotlarni ishlab chiqarmoqda. Shu sababli, ushbu ma'lumotlarni qayta ishlash, saqlash va uzatishga qodir bo'lgan qulay tizim arxitekturasiga ehtiyoj bor.
Endi bu maqsadlar uchun bulutli xizmatlardan foydalaniladi. Biroq, tobora ommalashib borayotgan tumanli hisoblash paradigmasi (Tuman) IoT infratuzilmasini masshtablash va optimallashtirish orqali bulutli echimlarni to'ldirishi mumkin.
Bulutlar ko'pgina IoT so'rovlarini qoplashga qodir. Masalan, xizmatlar monitoringini ta'minlash, qurilmalar tomonidan yaratilgan istalgan hajmdagi ma'lumotlarni tezkor qayta ishlash, shuningdek ularni vizualizatsiya qilish. Tumanli hisoblash real vaqtda muammolarni hal qilishda samaraliroq. Ular so'rovlarga tezkor javob berish va ma'lumotlarni qayta ishlashda minimal kechikishni ta'minlaydi. Ya'ni, Tuman "bulutlar" ni to'ldiradi va uning imkoniyatlarini kengaytiradi.
Biroq, asosiy savol boshqacha: bularning barchasi IoT kontekstida qanday o'zaro ta'sir qilishi kerak? Birlashtirilgan IoT-Fog-Cloud tizimida ishlashda qanday aloqa protokollari eng samarali bo'ladi?
HTTP ning yaqqol ustunligiga qaramay, IoT, Fog va Cloud tizimlarida qo'llaniladigan ko'plab boshqa echimlar mavjud. Buning sababi shundaki, IoT turli xil qurilmalar sensorlarining funksionalligini xavfsizlik, muvofiqlik va foydalanuvchilarning boshqa talablari bilan birlashtirishi kerak.
Ammo mos yozuvlar arxitekturasi va aloqa standarti haqida yagona fikr yo'q. Shu sababli, IoT-ning muayyan vazifalari uchun yangi protokol yaratish yoki mavjudni o'zgartirish IT hamjamiyatining oldida turgan eng muhim vazifalardan biridir.
Hozirda qanday protokollar qo'llanilmoqda va ular nimani taklif qilishi mumkin? Keling, buni aniqlaylik. Avvalo, bulutlar, tumanlar va narsalar Interneti o'zaro ta'sir qiladigan ekotizim tamoyillarini muhokama qilaylik.
IoT tumandan bulutga (F2C) arxitekturasi
IoT, bulut va tumanni aqlli va muvofiqlashtirilgan boshqarish bilan bog‘liq afzallik va imtiyozlarni o‘rganishga qanchalar kuch sarflanayotganini payqagandirsiz. Agar yo'q bo'lsa, unda uchta standartlashtirish tashabbusi mavjud: , и .
Agar ilgari faqat 2 daraja, bulutlar va oxirgi qurilmalar ko'rib chiqilgan bo'lsa, unda tavsiya etilgan arxitektura yangi darajani - tumanli hisoblashni joriy qiladi. Bunday holda, tuman darajasi resurslarning o'ziga xos xususiyatlariga yoki ushbu kichik darajalarda turli xil qurilmalardan foydalanishni belgilaydigan siyosatlar to'plamiga qarab bir nechta pastki darajalarga bo'linishi mumkin.
Ushbu mavhumlik qanday ko'rinishi mumkin? Bu erda odatiy IoT-Fog-Cloud ekotizimidir. IoT qurilmalari past kechikishni talab qiladigan muammolarni hal qilish uchun maʼlumotlarni tezroq serverlar va hisoblash qurilmalariga yuboradi. Xuddi shu tizimda bulutlar katta hajmdagi hisoblash resurslari yoki ma'lumotlarni saqlash joyini talab qiladigan muammolarni hal qilish uchun javobgardir.
Smartfonlar, aqlli soatlar va boshqa gadjetlar ham IoTning bir qismi bo'lishi mumkin. Ammo bunday qurilmalar, qoida tariqasida, yirik ishlab chiquvchilarning xususiy aloqa protokollaridan foydalanadi. Yaratilgan IoT ma'lumotlari REST HTTP protokoli orqali tuman qatlamiga uzatiladi, bu RESTful xizmatlarini yaratishda moslashuvchanlik va o'zaro muvofiqlikni ta'minlaydi. Bu mahalliy kompyuterlar, serverlar yoki server klasterida ishlaydigan mavjud hisoblash infratuzilmasi bilan orqaga qarab muvofiqlikni ta'minlash zarurati nuqtai nazaridan muhimdir. "Tuman tugunlari" deb nomlangan mahalliy manbalar olingan ma'lumotlarni filtrlaydi va ularni mahalliy ravishda qayta ishlaydi yoki keyingi hisob-kitoblar uchun bulutga yuboradi.
Bulutlar turli xil aloqa protokollarini qo'llab-quvvatlaydi, eng keng tarqalgani AMQP va REST HTTP. HTTP yaxshi ma'lum va Internet uchun moslashtirilganligi sababli, savol tug'ilishi mumkin: "biz uni IoT va tuman bilan ishlash uchun ishlatishimiz kerak emasmi?" Biroq, ushbu protokolda ishlash bilan bog'liq muammolar mavjud. Bu haqda keyinroq.
Umuman olganda, bizga kerak bo'lgan tizimga mos keladigan aloqa protokollarining 2 ta modeli mavjud. Bular so'rov-javob va nashr etish-obuna. Birinchi model, ayniqsa server-mijoz arxitekturasida kengroq ma'lum. Mijoz serverdan ma'lumot so'raydi va server so'rovni qabul qiladi, uni qayta ishlaydi va javob xabarini qaytaradi. REST HTTP va CoAP protokollari ushbu modelda ishlaydi.
Ikkinchi model ma'lumotlarni ishlab chiqaruvchi manbalar va ushbu ma'lumotlarni qabul qiluvchilar o'rtasida asinxron, taqsimlangan, bo'sh ulanishni ta'minlash zaruratidan kelib chiqdi.
Model uchta ishtirokchini nazarda tutadi: noshir (ma'lumotlar manbai), broker (dispetcher) va abonent (qabul qiluvchi). Bu erda abonent vazifasini bajaruvchi mijoz serverdan ma'lumot so'rashi shart emas. So'rovlarni yuborish o'rniga, u barcha kiruvchi xabarlarni filtrlash va ularni nashriyotlar va obunachilar o'rtasida yo'naltirish uchun mas'ul bo'lgan broker orqali tizimdagi muayyan hodisalarga obuna bo'ladi. Va nashriyot, ma'lum bir mavzu bo'yicha voqea sodir bo'lganda, uni brokerga e'lon qiladi, u obunachiga so'ralgan mavzu bo'yicha ma'lumotlarni yuboradi.
Aslida, bu arxitektura voqealarga asoslangan. Va bu o'zaro ta'sir modeli IoT, bulut, tuman ilovalari uchun qiziqarli, chunki uning miqyoslanishini ta'minlash va turli qurilmalar o'rtasidagi o'zaro bog'lanishni soddalashtirish, dinamik ko'p-ko'p aloqa va asinxron aloqani qo'llab-quvvatlash qobiliyati. Nashr qilish-obuna modelidan foydalanadigan eng mashhur standartlashtirilgan xabar almashish protokollaridan ba'zilari MQTT, AMQP va DDS ni o'z ichiga oladi.
Shubhasiz, nashr etish-obuna bo'lish modeli juda ko'p afzalliklarga ega:
- Nashriyotchilar va obunachilar bir-birining mavjudligi haqida bilishlari shart emas;
- Bitta obunachi ko'plab turli nashrlardan ma'lumot olishi mumkin, bir nashriyot esa ko'plab turli obunachilarga ma'lumot yuborishi mumkin (ko'pdan ko'pga printsipi);
- Muloqot qilish uchun nashriyot va abonent bir vaqtning o'zida faol bo'lishlari shart emas, chunki broker (navbat tizimi sifatida ishlaydi) hozirda tarmoqqa ulanmagan mijozlar uchun xabarni saqlashi mumkin bo'ladi.
Biroq, so'rov-javob modeli ham o'zining kuchli tomonlariga ega. Server tomonining bir nechta mijoz so'rovlarini bajarish qobiliyati muammo bo'lmagan hollarda, tasdiqlangan, ishonchli echimlardan foydalanish mantiqan to'g'ri keladi.
Ikkala modelni qo'llab-quvvatlaydigan protokollar ham mavjud. Masalan, "serverni surish" opsiyasini qo'llab-quvvatlaydigan XMPP va HTTP 2.0. IETF ham CoAP e'lon qildi. Xabar almashish muammosini hal qilish uchun WebSockets protokoli yoki QUIC (Quick UDP Internet Connections) orqali HTTP protokolidan foydalanish kabi bir qancha boshqa yechimlar yaratilgan.
WebSockets misolida, u real vaqt rejimida serverdan veb-mijozga ma'lumotlarni uzatish uchun ishlatilsa va bir vaqtning o'zida ikki tomonlama aloqa bilan doimiy ulanishlarni ta'minlasa ham, u cheklangan hisoblash resurslariga ega qurilmalar uchun mo'ljallanmagan. QUIC ham e'tiborga loyiqdir, chunki yangi transport protokoli ko'plab yangi imkoniyatlarni taqdim etadi. Ammo QUIC hali standartlashtirilmaganligi sababli, uning qo'llanilishi va IoT yechimlariga ta'sirini oldindan aytish hali erta. Shunday qilib, biz kelajakni ko'zlagan holda WebSockets va QUIC-ni yodda tutamiz, ammo hozircha uni batafsil o'rganmaymiz.
Dunyodagi eng yoqimli kim: protokollarni taqqoslash
Endi protokollarning kuchli va zaif tomonlari haqida gapiraylik. Oldinga qarab, darhol aniq bir rahbar yo'qligini ta'kidlaymiz. Har bir protokolning afzalliklari/kamchiliklari mavjud.
Javob vaqti
Aloqa protokollarining eng muhim xususiyatlaridan biri, ayniqsa narsalar Internetiga nisbatan, javob vaqtidir. Ammo mavjud protokollar orasida turli xil sharoitlarda ishlashda kechikishning minimal darajasini ko'rsatadigan aniq g'olib yo'q. Ammo protokol imkoniyatlarini ko'plab tadqiqotlar va taqqoslashlar mavjud.
Misol uchun, IoT bilan ishlashda HTTP va MQTT samaradorligini taqqoslash shuni ko'rsatdiki, MQTT so'rovlariga javob berish vaqti HTTPga qaraganda kamroq. Va qachon MQTT va CoAP ning aylanish vaqti (RTT) shuni ko'rsatdiki, CoAP ning o'rtacha RTT MQTTnikidan 20% kamroq.
Boshqa MQTT va CoAP protokollari uchun RTT bilan ikki stsenariyda amalga oshirildi: mahalliy tarmoq va IoT tarmog'i. Ma'lum bo'lishicha, o'rtacha RTT IoT tarmog'ida 2-3 baravar yuqori. QoS0 bilan MQTT CoAP bilan solishtirganda pastroq natijani ko'rsatdi va QoS1 bilan MQTT dastur va transport qatlamlarida ACKlar tufayli yuqori RTT ko'rsatdi. Turli QoS darajalari uchun tarmoqning tirbandligisiz kechikishi MQTT uchun millisekundlar va CoAP uchun yuzlab mikrosekundlar edi. Ammo shuni yodda tutish kerakki, kamroq ishonchli tarmoqlarda ishlaganda, TCP ustida ishlaydigan MQTT butunlay boshqacha natijani ko'rsatadi.
AMQP va MQTT protokollari uchun foydali yukni oshirish orqali javob vaqti engil yuk bilan kechikish darajasi deyarli bir xil ekanligini ko'rsatdi. Ammo katta hajmdagi ma'lumotlarni uzatishda MQTT qisqaroq javob vaqtini namoyish etadi. yana birida Gaz sensorlari, ob-havo sensorlari, joylashuv sensorlari (GPS) va mobil tarmoq interfeysi (GPRS) bilan jihozlangan transport vositalarining ustiga o'rnatilgan qurilmalar bilan mashinadan mashinaga aloqa stsenariysida CoAP HTTP bilan taqqoslandi. Mobil tarmoq orqali CoAP xabarini uzatish uchun talab qilinadigan vaqt HTTP xabarlarini ishlatish uchun zarur bo'lgan vaqtdan deyarli uch baravar qisqa edi.
Ikki emas, balki uchta protokolni taqqoslaydigan tadqiqotlar o'tkazildi. Masalan, tarmoq emulyatori yordamida tibbiy dastur stsenariysida IoT protokollarining MQTT, DDS va CoAP ishlashi. DDS turli xil yomon tarmoq sharoitlarida sinovdan o'tgan telemetriya kechikishi bo'yicha MQTT dan ustun keldi. UDP-ga asoslangan CoAP tez javob berish vaqtini talab qiladigan ilovalar uchun yaxshi ishladi, biroq u UDP-ga asoslanganligi sababli sezilarli darajada oldindan aytib bo'lmaydigan paket yo'qotildi.
Bandwidth
MQTT va CoAP tarmoqli kengligi samaradorligi bo'yicha har bir xabar uchun uzatiladigan ma'lumotlarning umumiy miqdorini hisoblash sifatida amalga oshirildi. Kichkina xabarlarni uzatishda CoAP MQTT ga qaraganda past o'tkazish qobiliyatini ko'rsatdi. Ammo foydali ma'lumotlar baytlari sonining uzatilgan baytlarning umumiy soniga nisbati bo'yicha protokollarning samaradorligini taqqoslaganda, CoAP samaraliroq bo'ldi.
da MQTT, DDS (transport protokoli sifatida TCP bilan) va CoAP tarmoqli kengligidan foydalangan holda, CoAP odatda nisbatan past tarmoqli kengligi iste'molini ko'rsatganligi aniqlandi, bu MQTT va DDS dan farqli o'laroq, tarmoq paketining yo'qolishi yoki tarmoq kechikishining oshishi bilan oshmaydi. qayd etilgan stsenariylarda tarmoqli kengligidan foydalanishning oshishi. Yana bir stsenariy bir vaqtning o'zida ma'lumotlarni uzatuvchi ko'p sonli qurilmalarni o'z ichiga oladi, bu IoT muhitida odatiy holdir. Natijalar shuni ko'rsatdiki, yuqoriroq foydalanish uchun CoAP dan foydalanish yaxshiroq.
Engil yuk ostida CoAP eng kam tarmoqli kengligidan foydalangan, keyin MQTT va REST HTTP. Biroq, foydali yuklarning hajmi oshganda, REST HTTP eng yaxshi natijalarga erishdi.
Quvvat iste'moli
Energiya iste'moli masalasi har doim katta ahamiyatga ega va ayniqsa IoT tizimida. Agar MQTT va HTTP elektr energiyasini iste'mol qilsa-da, HTTP ko'proq iste'mol qiladi. Va CoAP ko'proq MQTT bilan solishtirganda, quvvatni boshqarish imkonini beradi. Biroq, oddiy stsenariylarda MQTT Internet of Things tarmoqlarida ma'lumot almashish uchun ko'proq mos keladi, ayniqsa quvvat cheklovlari bo'lmasa.
Mobil yoki beqaror simsiz tarmoq sinov maydonchasida AMQP va MQTT imkoniyatlarini taqqoslagan tajriba shuni ko'rsatdiki, AMQP ko'proq xavfsizlik imkoniyatlarini taqdim etadi, MQTT esa energiya tejamkorroq.
Xavfsizlik
Xavfsizlik - bu narsalar Interneti va tuman / bulutli hisoblash mavzusini o'rganishda ko'tarilgan yana bir muhim masala. Xavfsizlik mexanizmi odatda HTTP, MQTT, AMQP va XMPPʼdagi TLSʼga yoki CoAPʼdagi DTLSʼga asoslanadi va har ikkala DDS variantini ham qoʻllab-quvvatlaydi.
TLS va DTLS qo'llab-quvvatlanadigan shifr to'plamlari va kalitlarni almashish uchun mijoz va server tomonlari o'rtasida aloqa o'rnatish jarayonidan boshlanadi. Har ikki tomon keyingi aloqa xavfsiz kanalda amalga oshirilishini ta'minlash uchun to'plamlarni muzokara qiladi. Ikkala o'rtasidagi farq UDP-ga asoslangan DTLS-ning ishonchsiz ulanish orqali ishlashiga imkon beruvchi kichik modifikatsiyalarda yotadi.
da TLS va DTLS ning bir nechta turli xil ilovalari TLS yaxshiroq ish qilganligini aniqladi. DTLSga qilingan hujumlar xatolarga chidamliligi tufayli muvaffaqiyatliroq bo'ldi.
Biroq, ushbu protokollar bilan bog'liq eng katta muammo shundaki, ular dastlab IoT-da foydalanish uchun mo'ljallanmagan va tuman yoki bulutda ishlash uchun mo'ljallanmagan. Qo'l berib ko'rishish orqali ular har bir ulanish muassasasiga qo'shimcha trafikni qo'shadilar, bu esa hisoblash resurslarini sarflaydi. Xavfsizlik qatlami bo'lmagan aloqa bilan solishtirganda, o'rtacha hisobda TLS uchun 6,5% va DTLS uchun 11% ga o'sish kuzatilmoqda. Odatda joylashgan resurslarga boy muhitlarda darajada, bu muammo bo'lmaydi, lekin IoT va tuman darajasi o'rtasidagi aloqada bu muhim cheklovga aylanadi.
Nima tanlash kerak? Hech qanday aniq javob yo'q. MQTT va HTTP eng istiqbolli protokollar bo'lib ko'rinadi, chunki ular boshqa protokollarga nisbatan nisbatan etukroq va barqaror IoT yechimlari hisoblanadi.
Yagona aloqa protokoliga asoslangan yechimlar
Bitta protokolli yechim amaliyoti ko'plab kamchiliklarga ega. Misol uchun, cheklangan muhitga mos keladigan protokol qat'iy xavfsizlik talablariga ega bo'lgan domenda ishlamasligi mumkin. Shuni yodda tutgan holda, biz MQTT va REST HTTP-dan tashqari, IoT-dagi Tumandan bulutga ekotizimidagi deyarli barcha mumkin bo'lgan yagona protokolli echimlardan voz kechishimiz kerak.
REST HTTP yagona protokolli yechim sifatida
REST HTTP so'rovlari va javoblari IoT-to-Fog maydonida qanday o'zaro ta'sir qilishiga yaxshi misol bor: . Hayvonlar taqiladigan sensorlar bilan jihozlangan (IoT mijozi, C) va bulutli hisoblash orqali aqlli fermerlik tizimi (Fog server, S) tomonidan boshqariladi.
POST usulining sarlavhasi o'zgartirish uchun resursni (/ferma/hayvonlar), shuningdek HTTP versiyasini va kontent turini belgilaydi, bu holda tizim boshqaradigan hayvon fermasini ifodalovchi JSON ob'ekti (Dulcinea/cow) . Serverdan olingan javob HTTPS holat kodi 201 (resurs yaratilgan) yuborilishi orqali soʻrov muvaffaqiyatli boʻlganligini koʻrsatadi. GET usuli URIda faqat so‘ralgan resursni ko‘rsatishi kerak (masalan, /farm/animals/1), u serverdan ushbu identifikatorga ega hayvonning JSON tasvirini qaytaradi.
PUT usuli ma'lum bir manba yozuvini yangilash kerak bo'lganda qo'llaniladi. Bunday holda, resurs o'zgartirilishi kerak bo'lgan parametr uchun URI va joriy qiymatni belgilaydi (masalan, sigir hozirda yurganligini ko'rsatadi, /ferma/hayvonlar/1? holat=yurish). Nihoyat, DELETE usuli GET usuliga teng ravishda qo'llaniladi, lekin operatsiya natijasida resursni o'chiradi.
MQTT yagona protokolli yechim sifatida
Keling, xuddi shu aqlli fermani olaylik, lekin REST HTTP o'rniga biz MQTT protokolidan foydalanamiz. Mosquitto kutubxonasi oʻrnatilgan mahalliy server broker vazifasini bajaradi. Ushbu misolda oddiy kompyuter (fermer serveri deb ataladi) Raspberry Pi MQTT mijozi bo'lib xizmat qiladi, u Mosquitto brokeriga to'liq mos keladigan Paho MQTT kutubxonasini o'rnatish orqali amalga oshiriladi.
Bu mijoz sezgi va hisoblash qobiliyatiga ega qurilmani ifodalovchi IoT abstraksiya qatlamiga mos keladi. Boshqa tomondan, vositachi yuqoriroq mavhumlik darajasiga to'g'ri keladi, bu ko'proq ishlov berish va saqlash imkoniyatlari bilan tavsiflangan tumanli hisoblash tugunini ifodalaydi.
Taklif etilayotgan aqlli ferma stsenariysida Raspberry Pi akselerometr, GPS va harorat sensorlariga ulanadi va ushbu sensorlardan olingan ma'lumotlarni tuman tuguniga e'lon qiladi. Siz bilganingizdek, MQTT mavzularni ierarxiya sifatida ko'rib chiqadi. Bitta MQTT noshiri ma'lum bir mavzular to'plamiga xabarlarni nashr etishi mumkin. Bizning holatlarimizda ulardan uchtasi bor. Hayvonlar omboridagi haroratni o'lchaydigan sensor uchun mijoz mavzuni (hayvon fermasi / shiypon / harorat) tanlaydi. GPS joylashuvi va hayvonlarning harakatini akselerometr orqali o'lchaydigan sensorlar uchun mijoz (hayvon fermasi/hayvon/GPS) va (hayvon fermasi/hayvon/harakat) yangilanishlarini e'lon qiladi.
Ushbu ma'lumot brokerga uzatiladi, agar keyinchalik boshqa manfaatdor obunachi kelsa, uni vaqtincha mahalliy ma'lumotlar bazasida saqlashi mumkin.
Tumanda MQTT brokeri vazifasini bajaradigan va MQTT mijozlari sifatida ishlaydigan Raspberry Pis sensor ma'lumotlarini yuboradigan mahalliy serverdan tashqari, bulut darajasida boshqa MQTT brokeri bo'lishi mumkin. Bunday holda, mahalliy brokerga uzatiladigan ma'lumotlar vaqtinchalik mahalliy ma'lumotlar bazasida saqlanishi va/yoki bulutga yuborilishi mumkin. Ushbu vaziyatda tuman MQTT brokeri barcha ma'lumotlarni bulutli MQTT brokeri bilan bog'lash uchun ishlatiladi. Ushbu arxitektura bilan mobil ilova foydalanuvchisi ikkala brokerga ham obuna bo'lishi mumkin.
Agar brokerlardan biriga ulanish (masalan, bulut) bajarilmasa, oxirgi foydalanuvchi ikkinchisidan ma'lumot oladi (tuman). Bu tuman va bulutli hisoblash tizimlarining o'ziga xos xususiyati. Odatiy bo'lib, mobil ilova birinchi navbatda tuman MQTT brokeriga ulanishi va agar bu muvaffaqiyatsiz bo'lsa, bulutli MQTT brokeriga ulanishi uchun sozlanishi mumkin. Ushbu yechim IoT-F2C tizimlaridagi ko'p narsalardan biridir.
Ko'p protokolli echimlar
Yagona protokolli yechimlar oson amalga oshirilishi tufayli mashhurdir. Ammo IoT-F2C tizimlarida turli xil protokollarni birlashtirish mantiqiy ekanligi aniq. G'oya shundaki, turli xil protokollar turli darajalarda ishlashi mumkin. Masalan, uchta abstraksiyani olaylik: IoT qatlamlari, tuman va bulutli hisoblash. IoT darajasidagi qurilmalar odatda cheklangan deb hisoblanadi. Ushbu umumiy nuqtai nazar uchun, keling, IoT darajalarini eng cheklangan, bulutli eng kam cheklangan va tumanli hisoblashni "o'rtada" deb ko'rib chiqaylik. Ma'lum bo'lishicha, IoT va tuman abstraktsiyalari o'rtasida joriy protokol echimlari MQTT, CoAP va XMPP ni o'z ichiga oladi. Boshqa tomondan, tuman va bulut o'rtasida AMQP REST HTTP bilan bir qatorda ishlatiladigan asosiy protokollardan biri bo'lib, u moslashuvchanligi tufayli IoT va tuman qatlamlari orasida ham qo'llaniladi.
Bu erda asosiy muammo - protokollarning o'zaro muvofiqligi va xabarlarni bir protokoldan boshqasiga o'tkazish qulayligi. Ideal holda, kelajakda bulut va tuman resurslariga ega narsalar Interneti tizimining arxitekturasi foydalaniladigan aloqa protokolidan mustaqil bo'ladi va turli protokollar o'rtasida yaxshi o'zaro muvofiqlikni ta'minlaydi.
Hozirda bunday bo'lmaganligi sababli, muhim farqlarga ega bo'lmagan protokollarni birlashtirish mantiqan. Shu maqsadda bitta potentsial yechim bir xil arxitektura uslubiga, REST HTTP va CoAPga amal qiladigan ikkita protokol kombinatsiyasiga asoslanadi. Yana bir taklif qilingan yechim nashr-obuna aloqasini taklif qiluvchi MQTT va AMQP ikkita protokol kombinatsiyasiga asoslangan. Shunga o'xshash kontseptsiyalardan foydalanish (har ikkala MQTT va AMQP brokerlardan foydalanadi, CoAP va HTTP REST dan foydalanadi) bu kombinatsiyalarni amalga oshirishni osonlashtiradi va kamroq integratsiya harakatlarini talab qiladi.
Shakl (a) so'rovga asoslangan ikkita model, HTTP va CoAP va ularni IoT-F2C yechimida joylashtirish mumkinligini ko'rsatadi. HTTP zamonaviy tarmoqlarda eng mashhur va qabul qilingan protokollardan biri bo'lganligi sababli, uni boshqa xabar almashish protokollari bilan to'liq almashtirishi dargumon. Bulut va tuman o'rtasida joylashgan kuchli qurilmalarni ifodalovchi tugunlar orasida REST HTTP aqlli yechim hisoblanadi.
Boshqa tomondan, Fog va IoT qatlamlari o'rtasida aloqa o'rnatadigan cheklangan hisoblash resurslariga ega qurilmalar uchun CoAP-dan foydalanish samaraliroq. CoAP ning katta afzalliklaridan biri uning HTTP bilan mosligidir, chunki ikkala protokol ham REST tamoyillariga asoslangan.
Shakl (b) MQTT va AMQPni o'z ichiga olgan bir xil stsenariyda ikkita nashr qilish va obuna bo'lish aloqa modellarini ko'rsatadi. Ikkala protokol ham har bir abstraksiya qatlamidagi tugunlar o'rtasidagi aloqa uchun faraz sifatida ishlatilishi mumkin bo'lsa-da, ularning pozitsiyasi ishlashga qarab aniqlanishi kerak. MQTT cheklangan hisoblash resurslariga ega qurilmalar uchun engil protokol sifatida ishlab chiqilgan, shuning uchun u IoT-Fog aloqasi uchun ishlatilishi mumkin. AMQP kuchliroq qurilmalar uchun ko'proq mos keladi, ular uni tuman va bulut tugunlari o'rtasida ideal joylashtiradi. MQTT o'rniga XMPP protokoli IoT-da ishlatilishi mumkin, chunki u engil hisoblanadi. Ammo bunday stsenariylarda u unchalik keng qo'llanilmaydi.
topilmalar
Muhokama qilingan protokollardan biri cheklangan hisoblash resurslariga ega qurilmalardan tortib bulutli serverlargacha bo'lgan tizimdagi barcha aloqalarni qamrab olish uchun etarli bo'lishi dargumon. Tadqiqot shuni ko'rsatdiki, ishlab chiquvchilar eng ko'p foydalanadigan ikkita eng istiqbolli variant MQTT va RESTful HTTP. Ushbu ikkita protokol nafaqat eng etuk va barqaror, balki ko'plab yaxshi hujjatlashtirilgan va muvaffaqiyatli dasturlarni va onlayn resurslarni ham o'z ichiga oladi.
Barqarorligi va oddiy konfiguratsiyasi tufayli MQTT cheklangan qurilmalar bilan IoT darajasida foydalanilganda vaqt o'tishi bilan o'zining yuqori ishlashini isbotlagan protokoldir. Ba'zi tumanli domenlar va ko'pgina bulutli hisoblash kabi cheklangan aloqa va batareya iste'moli muammo bo'lmagan tizim qismlarida RESTful HTTP oson tanlovdir. CoAP ham e'tiborga olinishi kerak, chunki u IoT xabar almashish standarti sifatida ham tez rivojlanmoqda va yaqin kelajakda u MQTT va HTTPga o'xshash barqarorlik va etuklik darajasiga yetishi mumkin. Ammo standart hozirda rivojlanmoqda, bu qisqa muddatli muvofiqlik muammolari bilan birga keladi.
Blogda yana nimani o'qishingiz mumkin?
→
→
→
→
→
Bizning kanalimizga obuna bo'ling Keyingi maqolani o'tkazib yubormaslik uchun kanal! Biz haftasiga ikki martadan ko'p bo'lmagan va faqat ish haqida yozamiz.
Manba: www.habr.com