Бағдарламалық-техникалық қамтамасыз ету саласындағы технологиялардың дамуы, жаңа коммуникациялық хаттамалардың пайда болуы заттар интернетінің (IoT) кеңеюіне әкелді. Құрылғылар саны күн санап артып келеді және олар деректердің үлкен көлемін жасайды. Сондықтан осы деректерді өңдеуге, сақтауға және беруге қабілетті ыңғайлы жүйе архитектурасы қажет.
Қазір бұл мақсаттар үшін бұлттық қызметтер қолданылады. Дегенмен, барған сайын танымал тұманды есептеу парадигмасы (Тұман) IoT инфрақұрылымын масштабтау және оңтайландыру арқылы бұлттық шешімдерді толықтыра алады.
Бұлттар IoT сұрауларының көпшілігін жабуға қабілетті. Мысалы, қызметтер мониторингін қамтамасыз ету, құрылғылармен жасалған деректердің кез келген көлемін жылдам өңдеу, сондай-ақ олардың визуализациясы. Нақты уақыттағы есептерді шешу кезінде тұманды есептеу тиімдірек. Олар сұрауларға жылдам жауап береді және деректерді өңдеудегі ең аз кідірісті қамтамасыз етеді. Яғни, Тұман «бұлттарды» толықтырады және оның мүмкіндіктерін кеңейтеді.
Дегенмен, басты сұрақ басқа: мұның бәрі IoT контекстінде қалай әрекеттесуі керек? Біріктірілген IoT-Fog-Cloud жүйесінде жұмыс істегенде қандай байланыс протоколдары тиімдірек болады?
HTTP-тің айқын басымдығына қарамастан, IoT, Fog және Cloud жүйелерінде қолданылатын көптеген басқа шешімдер бар. Себебі IoT әртүрлі құрылғы сенсорларының функционалдығын қауіпсіздік, үйлесімділік және пайдаланушылардың басқа талаптарымен біріктіруі керек.
Бірақ анықтамалық архитектура мен байланыс стандарты туралы бірде-бір идея жоқ. Сондықтан жаңа хаттаманы жасау немесе IoT нақты тапсырмалары үшін барын өзгерту АТ қауымдастығы алдында тұрған маңызды міндеттердің бірі болып табылады.
Қазіргі уақытта қандай хаттамалар қолданылуда және олар не ұсына алады? Оны анықтап көрейік. Бірақ алдымен бұлттар, тұман және заттардың интернеті өзара әрекеттесетін экожүйенің принциптерін талқылайық.
IoT тұманнан бұлтқа (F2C) архитектурасы
IoT, бұлтты және тұманды ақылды және үйлестірілген басқарумен байланысты артықшылықтар мен артықшылықтарды зерттеуге қанша күш жұмсалып жатқанын байқаған боларсыз. Олай болмаса, стандарттау бойынша үш бастама бар: , и .
Егер бұрын тек 2 деңгей, бұлттар және соңғы құрылғылар қарастырылған болса, онда ұсынылған архитектура жаңа деңгейді - тұманды есептеуді енгізеді. Бұл жағдайда тұман деңгейін ресурстардың ерекшеліктеріне немесе осы ішкі деңгейлерде әртүрлі құрылғыларды пайдалануды анықтайтын саясаттар жиынтығына байланысты бірнеше ішкі деңгейлерге бөлуге болады.
Бұл абстракция қандай болуы мүмкін? Мұнда типтік IoT-Fog-Cloud экожүйесі берілген. IoT құрылғылары аз кідірісті қажет ететін мәселелерді шешу үшін деректерді жылдамырақ серверлерге және есептеу құрылғыларына жібереді. Бір жүйеде бұлттар үлкен көлемдегі есептеу ресурстарын немесе деректерді сақтау кеңістігін қажет ететін мәселелерді шешуге жауап береді.
Смартфондар, смарт сағаттар және басқа гаджеттер де IoT бөлігі болуы мүмкін. Бірақ мұндай құрылғылар, әдетте, ірі әзірлеушілердің меншікті байланыс протоколдарын пайдаланады. Жасалған IoT деректері RESTful қызметтерін жасау кезінде икемділік пен өзара әрекеттесуді қамтамасыз ететін REST HTTP протоколы арқылы тұман қабатына тасымалданады. Бұл жергілікті компьютерлерде, серверлерде немесе сервер кластерінде жұмыс істейтін бар есептеу инфрақұрылымымен кері үйлесімділікті қамтамасыз ету қажеттілігі тұрғысынан маңызды. «Тұман түйіндері» деп аталатын жергілікті ресурстар алынған деректерді сүзеді және оны жергілікті түрде өңдейді немесе одан әрі есептеулер үшін бұлтқа жібереді.
Бұлттар әртүрлі байланыс протоколдарын қолдайды, олардың ең көп тарағаны AMQP және REST HTTP болып табылады. HTTP жақсы белгілі және Интернетке бейімделгендіктен, сұрақ туындауы мүмкін: «біз оны IoT және тұманмен жұмыс істеу үшін пайдалануымыз керек емес пе?» Дегенмен, бұл протоколда өнімділік мәселелері бар. Бұл туралы кейінірек.
Жалпы, бізге қажет жүйеге сәйкес келетін байланыс хаттамаларының 2 моделі бар. Бұл сұрау-жауап және жариялау-жазылу. Бірінші модель кеңірек белгілі, әсіресе сервер-клиент архитектурасында. Клиент серверден ақпаратты сұрайды, ал сервер сұрауды қабылдайды, оны өңдейді және жауап хабарламасын қайтарады. REST HTTP және CoAP протоколдары осы үлгіде жұмыс істейді.
Екінші модель деректерді генерациялайтын көздер мен осы деректерді алушылардың арасындағы асинхронды, бөлінген, бос байланыстарды қамтамасыз ету қажеттілігінен туындады.
Модель үш қатысушыны болжайды: баспагер (деректер көзі), брокер (диспетчер) және жазылушы (алушы). Мұнда абонент ретінде әрекет ететін клиент серверден ақпаратты сұрауға міндетті емес. Сұраныстарды жіберудің орнына ол жүйедегі белгілі бір оқиғаларға брокер арқылы жазылады, ол барлық кіріс хабарламаларды сүзуге және оларды баспагерлер мен жазылушылар арасында бағыттауға жауап береді. Ал баспагер белгілі бір тақырыпқа қатысты оқиға болған кезде оны брокерге жариялайды, ол жазылушыға сұралған тақырып бойынша деректерді жібереді.
Негізінде бұл архитектура оқиғаға негізделген. Және бұл өзара әрекеттесу моделі IoT, бұлттық, тұмандағы қолданбалар үшін қызықты, өйткені оның ауқымдылығын қамтамасыз ету және әртүрлі құрылғылар арасындағы өзара байланысты жеңілдету, динамикалық көптен көпке байланыс пен асинхронды байланысты қолдау мүмкіндігі. Жариялау-жазылу үлгісін пайдаланатын ең танымал стандартталған хабар алмасу протоколдарының кейбіріне MQTT, AMQP және DDS жатады.
Әлбетте, жариялау-жазылу үлгісінің көптеген артықшылықтары бар:
- Баспагерлер мен жазылушылар бір-бірінің бар екендігі туралы білудің қажеті жоқ;
- Бір жазылушы көптеген әртүрлі басылымдардан ақпаратты ала алады, ал бір баспагер көптеген әртүрлі жазылушыларға деректерді жібере алады (көптен көпке принципі);
- Байланыс жасау үшін баспагер мен жазылушының бір уақытта белсенді болуы міндетті емес, себебі брокер (кезекте тұру жүйесі ретінде жұмыс істейтін) желіге қазіргі уақытта қосылмаған клиенттер үшін хабарламаны сақтай алады.
Дегенмен, сұрау-жауап үлгісінің де күшті жақтары бар. Сервер тарапының бірнеше клиенттік сұрауларды өңдеу мүмкіндігі мәселе болмаса, дәлелденген, сенімді шешімдерді пайдалану мағынасы бар.
Екі үлгіні де қолдайтын протоколдар бар. Мысалы, «server push» опциясын қолдайтын XMPP және HTTP 2.0. IETF сонымен қатар CoAP шығарды. Хабар алмасу мәселесін шешу мақсатында WebSockets протоколы немесе QUIC (Quick UDP Интернет қосылымдары) арқылы HTTP протоколын пайдалану сияқты бірнеше басқа шешімдер жасалды.
WebSockets жағдайында, ол деректерді серверден веб-клиентке нақты уақыт режимінде тасымалдау үшін пайдаланылғанымен және бір уақытта екі жақты байланыспен тұрақты қосылымдарды қамтамасыз етеді, бірақ ол шектеулі есептеу ресурстары бар құрылғыларға арналмаған. QUIC де назар аударуды қажет етеді, өйткені жаңа көлік протоколы көптеген жаңа мүмкіндіктер береді. Бірақ QUIC әлі стандартталмағандықтан, оның ықтимал қолданылуы мен IoT шешімдеріне әсерін болжау әлі ерте. Сондықтан біз болашаққа көз жүгірте отырып, WebSockets және QUIC-ті есте ұстаймыз, бірақ біз оны әзірше егжей-тегжейлі зерттемейміз.
Әлемдегі ең сүйкімді кім: хаттамаларды салыстыру
Енді хаттамалардың күшті және әлсіз жақтарына тоқталайық. Алға қарай отырып, бірден бір нақты көшбасшы жоқ деп ескертейік. Әрбір хаттаманың кейбір артықшылықтары/кемшіліктері бар.
Жауап уақыты
Байланыс хаттамаларының ең маңызды сипаттамаларының бірі, әсіресе Интернет заттарына қатысты, жауап беру уақыты. Бірақ қолданыстағы хаттамалар арасында әртүрлі жағдайларда жұмыс істегенде кідірістің ең төменгі деңгейін көрсететін нақты жеңімпаз жоқ. Бірақ хаттаманың мүмкіндіктерін зерттеу мен салыстырудың тұтас тобы бар.
Мысалы, IoT-мен жұмыс істеу кезінде HTTP және MQTT тиімділігін салыстыру MQTT сұрауларына жауап беру уақыты HTTP-ге қарағанда аз екенін көрсетті. Және қашан MQTT және CoAP айналым уақыты (RTT) CoAP орташа RTT MQTT қарағанда 20% аз екенін көрсетті.
Басқа MQTT және CoAP хаттамалары үшін RTT көмегімен екі сценарийде орындалды: жергілікті желі және IoT желісі. IoT желісінде орташа RTT 2-3 есе жоғары екені белгілі болды. QoS0 бар MQTT CoAP-пен салыстырғанда төмен нәтиже көрсетті, ал QoS1 бар MQTT қолданбалы және тасымалдау деңгейлеріндегі ACK әсерінен жоғары RTT көрсетті. Әртүрлі QoS деңгейлері үшін кептеліссіз желі кідірісі MQTT үшін миллисекундтар, ал CoAP үшін жүздеген микросекундтар болды. Дегенмен, сенімді емес желілерде жұмыс істегенде, TCP үстінде жұмыс істейтін MQTT мүлдем басқа нәтиже көрсететінін есте ұстаған жөн.
Пайдалы жүктемені ұлғайту арқылы AMQP және MQTT хаттамаларына жауап беру уақыты жеңіл жүктеме кезінде кідіріс деңгейі дерлік бірдей екенін көрсетті. Бірақ үлкен көлемдегі деректерді тасымалдау кезінде MQTT қысқа жауап беру уақытын көрсетеді. тағы бірінде Газ сенсорларымен, ауа райы сенсорларымен, орналасу сенсорларымен (GPS) және мобильді желі интерфейсімен (GPRS) жабдықталған көліктердің үстіне орнатылған құрылғылары бар машинадан машинаға байланыс сценарийінде CoAP HTTP-мен салыстырылды. Мобильді желі арқылы CoAP хабарламасын жіберуге қажетті уақыт HTTP хабарламаларын пайдалану уақытынан үш есе дерлік қысқа болды.
Екі емес, үш хаттаманы салыстыратын зерттеулер жүргізілді. Мысалы, желі эмуляторы арқылы медициналық қолданбалы сценарийде IoT протоколдарының MQTT, DDS және CoAP өнімділігі. DDS әртүрлі нашар желі жағдайларында сыналған телеметриялық кідіріс бойынша MQTT-тен асып түсті. UDP негізіндегі CoAP жылдам жауап беру уақытын қажет ететін қолданбалар үшін жақсы жұмыс істеді, дегенмен, ол UDP негізіндегі болғандықтан, айтарлықтай күтпеген пакет жоғалуы болды.
Өткізу қабілеті
Өткізу қабілетінің тиімділігі бойынша MQTT және CoAP бір хабарламаға жіберілетін деректердің жалпы көлемін есептеу ретінде жүзеге асырылды. CoAP шағын хабарламаларды жіберу кезінде MQTT қарағанда төмен өткізу қабілеттілігін көрсетті. Бірақ пайдалы ақпарат байттарының санының тасымалданатын байттардың жалпы санына қатынасы тұрғысынан хаттамалардың тиімділігін салыстыру кезінде CoAP тиімдірек болды.
жанында MQTT, DDS (тасымалдау протоколы ретінде TCP) және CoAP өткізу қабілеттілігін пайдалана отырып, CoAP әдетте салыстырмалы түрде төмен өткізу қабілеттілігін тұтынуды көрсететіні анықталды, бұл желі пакетінің жоғалуының жоғарылауымен немесе желілік кідірістің жоғарылауымен өспейді, MQTT және DDS сияқты. аталған сценарийлерде өткізу қабілеттілігін пайдаланудың артуы. Тағы бір сценарий IoT орталарына тән деректерді бір уақытта жіберетін көптеген құрылғыларды қамтыды. Нәтижелер жоғары пайдалану үшін CoAP пайдалану жақсы екенін көрсетті.
Жеңіл жүктеме кезінде CoAP ең аз өткізу қабілеттілігін пайдаланды, одан кейін MQTT және REST HTTP. Дегенмен, пайдалы жүктемелердің өлшемі ұлғайған кезде, REST HTTP ең жақсы нәтижелерге ие болды.
Қуат тұтыну
Энергияны тұтыну мәселесі әрқашан үлкен маңызға ие, әсіресе IoT жүйесінде. Егер MQTT және HTTP электр қуатын тұтынса, HTTP әлдеқайда көп тұтынады. Және CoAP одан да көп қуатты басқаруға мүмкіндік беретін MQTT-мен салыстырғанда. Дегенмен, қарапайым сценарийлерде MQTT Интернет желісінде ақпарат алмасу үшін қолайлырақ, әсіресе қуат шектеулері болмаса.
Мобильді немесе тұрақсыз сымсыз желі сынақ алаңында AMQP және MQTT мүмкіндіктерін салыстырған эксперимент AMQP қауіпсіздік мүмкіндіктерін көбірек ұсынатынын, ал MQTT энергияны үнемдейтінін анықтады.
Қауіпсіздік
Қауіпсіздік - заттар интернеті және тұман/бұлтты есептеулер тақырыбын зерттеу кезінде көтерілетін тағы бір маңызды мәселе. Қауіпсіздік механизмі әдетте HTTP, MQTT, AMQP және XMPP жүйесіндегі TLS немесе CoAP ішіндегі DTLS негізінде жасалады және DDS нұсқасының екеуін де қолдайды.
TLS және DTLS қолдау көрсетілетін шифрлық жиынтықтар мен кілттермен алмасу үшін клиент пен сервер тараптары арасындағы байланысты орнату процесінен басталады. Қауіпсіз арнада әрі қарай байланыстың болуын қамтамасыз ету үшін екі тарап келіссөздер жүргізеді. Олардың арасындағы айырмашылық UDP негізіндегі DTLS сенімсіз қосылым арқылы жұмыс істеуге мүмкіндік беретін шағын модификацияларда жатыр.
жанында TLS және DTLS бірнеше түрлі енгізулері TLS жақсы жұмыс істегенін анықтады. DTLS-ке жасалған шабуылдар оның қателерге төзімділігіне байланысты сәтті болды.
Дегенмен, бұл хаттамалардың ең үлкен проблемасы олар бастапқыда IoT-де пайдалануға арналмаған және тұманда немесе бұлтта жұмыс істеуге арналмаған. Қол алысу арқылы олар есептеу ресурстарын төгетін әрбір қосылым мекемесіне қосымша трафик қосады. Қауіпсіздік қабаты жоқ байланыстармен салыстырғанда орташа есеппен TLS үшін 6,5%-ға және DTLS үшін 11%-ға өсу байқалады. Әдетте орналасқан ресурстарға бай орталарда деңгейде, бұл проблема болмайды, бірақ IoT және тұман деңгейі арасындағы байланыста бұл маңызды шектеуге айналады.
Не таңдау керек? Нақты жауап жоқ. MQTT және HTTP ең перспективалы хаттамалар болып көрінеді, өйткені олар басқа хаттамалармен салыстырғанда салыстырмалы түрде жетілген және тұрақты IoT шешімдері болып саналады.
Бірыңғай байланыс хаттамасына негізделген шешімдер
Бір хаттамалық шешім тәжірибесінің көптеген кемшіліктері бар. Мысалы, шектеулі ортаға сәйкес келетін протокол қатаң қауіпсіздік талаптары бар доменде жұмыс істемеуі мүмкін. Осыны ескере отырып, біз MQTT және REST HTTP қоспағанда, IoT жүйесіндегі «Fog-to-Cloud» экожүйесіндегі барлық дерлік мүмкін болатын бір хаттамалық шешімдерден бас тартамыз.
REST HTTP жалғыз протоколдық шешім ретінде
REST HTTP сұраулары мен жауаптарының IoT-to-Fog кеңістігінде қалай әрекеттесетінінің жақсы мысалы бар: . Жануарлар киілетін сенсорлармен жабдықталған (IoT клиенті, C) және ақылды ауыл шаруашылығы жүйесі (Fog server, S) арқылы бұлттық есептеулер арқылы басқарылады.
POST әдісінің тақырыбы өзгертілетін ресурсты (/ферма/жануарлар), сондай-ақ HTTP нұсқасын және мазмұн түрін көрсетеді, бұл жағдайда жүйе басқаратын жануарлар фермасын көрсететін JSON нысаны болып табылады (Dulcinea/cow) . Серверден келген жауап HTTPS күй кодын 201 (ресурс жасалған) жіберу арқылы сұраудың сәтті болғанын көрсетеді. GET әдісі серверден сол идентификаторы бар жануардың JSON көрінісін қайтаратын URI ішіндегі сұралған ресурсты ғана көрсетуі керек (мысалы, /farm/animals/1).
PUT әдісі белгілі бір ресурс жазбасын жаңарту қажет болғанда қолданылады. Бұл жағдайда ресурс өзгертілетін параметр үшін URI және ағымдағы мәнді көрсетеді (мысалы, сиырдың қазіргі уақытта серуендеп жатқанын көрсету, /ферма/жануарлар/1? күй=жүру). Соңында, DELETE әдісі GET әдісімен бірдей пайдаланылады, бірақ операция нәтижесінде ресурсты жояды.
MQTT бір хаттамалық шешім ретінде
Сол смарт ферманы алайық, бірақ REST HTTP орнына MQTT протоколын қолданамыз. Mosquitto кітапханасы орнатылған жергілікті сервер брокер ретінде әрекет етеді. Бұл мысалда қарапайым компьютер (ферма сервері деп аталады) Raspberry Pi Mosquitto брокерімен толық үйлесімді Paho MQTT кітапханасын орнату арқылы жүзеге асырылатын MQTT клиенті ретінде қызмет етеді.
Бұл клиент сезу және есептеу мүмкіндіктері бар құрылғыны білдіретін IoT абстракция деңгейіне сәйкес келеді. Медиатор, керісінше, үлкен өңдеу және сақтау сыйымдылығымен сипатталатын тұманды есептеу түйінін білдіретін абстракцияның жоғары деңгейіне сәйкес келеді.
Ұсынылған смарт ферма сценарийінде Raspberry Pi акселерометрге, GPS және температура сенсорларына қосылып, осы сенсорлардан алынған деректерді тұман түйініне жариялайды. Өздеріңіз білетіндей, MQTT тақырыптарды иерархия ретінде қарастырады. Жалғыз MQTT жариялаушысы хабарларды белгілі бір тақырыптар жинағына жариялай алады. Біздің жағдайда олардың үшеуі бар. Жануарлар қорасындағы температураны өлшейтін сенсор үшін клиент тақырыпты таңдайды (мал фермасы/сарай/температура). Акселерометр арқылы GPS орнын және жануарлардың қозғалысын өлшейтін сенсорлар үшін клиент (жануарлар фермасы/жануарлар/GPS) және (жануарлар фермасы/жануарлар/қозғалыс) жаңартуларын жариялайды.
Бұл ақпарат брокерге беріледі, ол кейінірек басқа мүдделі жазылушы келген жағдайда оны жергілікті дерекқорда уақытша сақтай алады.
Тұманда MQTT брокері ретінде әрекет ететін және MQTT клиенттері ретінде әрекет ететін Raspberry Pis сенсор деректерін жіберетін жергілікті серверден басқа, бұлт деңгейінде басқа MQTT брокері болуы мүмкін. Бұл жағдайда жергілікті брокерге жіберілген ақпарат уақытша жергілікті дерекқорда сақталуы мүмкін және/немесе бұлтқа жіберіледі. Бұл жағдайда тұман MQTT брокері барлық деректерді бұлттық MQTT брокерімен байланыстыру үшін пайдаланылады. Бұл архитектураның көмегімен мобильді қолданба пайдаланушысы екі брокерге де жазыла алады.
Егер брокерлердің біріне қосылу (мысалы, бұлт) сәтсіз болса, соңғы пайдаланушы екіншісінен ақпаратты алады (тұман). Бұл тұманды және бұлтты есептеулердің біріктірілген жүйелеріне тән қасиет. Әдепкі бойынша, мобильді қолданбаны алдымен тұман MQTT брокеріне қосылу үшін конфигурациялауға болады, ал егер бұл сәтсіз болса, бұлттық MQTT брокеріне қосылу үшін. Бұл шешім IoT-F2C жүйелеріндегі көптеген шешімдердің бірі ғана.
Көп протоколды шешімдер
Бір хаттамалық шешімдер олардың оңай іске асуына байланысты танымал. Бірақ IoT-F2C жүйелерінде әртүрлі хаттамаларды біріктіру мағынасы бар екені анық. Бұл идея әртүрлі протоколдар әртүрлі деңгейлерде жұмыс істей алады. Мысалы, үш абстракцияны алайық: IoT қабаттары, тұман және бұлтты есептеулер. IoT деңгейіндегі құрылғылар әдетте шектеулі деп саналады. Осы шолу үшін IoT деңгейлерін ең шектелген, бұлтты ең аз шектелген және тұманды есептеулерді «ортаңғы жерде» деп қарастырайық. IoT және тұман абстракциялары арасында ағымдағы протокол шешімдеріне MQTT, CoAP және XMPP кіреді. Тұман мен бұлт арасында, екінші жағынан, AMQP REST HTTP-мен бірге қолданылатын негізгі хаттамалардың бірі болып табылады, ол өзінің икемділігіне байланысты IoT және тұман қабаттары арасында да қолданылады.
Мұндағы негізгі мәселе хаттамалардың өзара әрекеттестікте болуы және хабарламаларды бір протоколдан екіншісіне тасымалдаудың қарапайымдылығы болып табылады. Ең дұрысы, болашақта бұлтты және тұман ресурстары бар заттар Интернет жүйесінің архитектурасы қолданылатын байланыс протоколынан тәуелсіз болады және әртүрлі протоколдар арасындағы жақсы өзара әрекеттесуді қамтамасыз етеді.
Қазіргі уақытта бұлай болмағандықтан, айтарлықтай айырмашылықтары жоқ хаттамаларды біріктіру мағынасы бар. Осы мақсатта бір әлеуетті шешім REST HTTP және CoAP бірдей архитектуралық стильге сәйкес келетін екі хаттаманың тіркесіміне негізделген. Басқа ұсынылған шешім MQTT және AMQP жариялау-жазылу байланысын ұсынатын екі хаттаманың тіркесіміне негізделген. Ұқсас тұжырымдамаларды пайдалану (MQTT және AMQP екеуі де брокерлерді пайдаланады, CoAP және HTTP REST пайдаланады) бұл комбинацияларды іске асыруды жеңілдетеді және интеграциялық күш-жігерді аз талап етеді.
(а) суретте сұрауға жауапқа негізделген екі үлгі, HTTP және CoAP және олардың IoT-F2C шешімінде ықтимал орналасуы көрсетілген. HTTP қазіргі заманғы желілердегі ең танымал және қабылданған протоколдардың бірі болғандықтан, оның басқа хабар алмасу протоколдарымен толығымен ауыстырылуы екіталай. Бұлт пен тұман арасында орналасқан қуатты құрылғыларды білдіретін түйіндердің арасында REST HTTP ақылды шешім болып табылады.
Екінші жағынан, Тұман және IoT қабаттары арасында байланысатын шектеулі есептеу ресурстары бар құрылғылар үшін CoAP пайдалану тиімдірек. CoAP-тың үлкен артықшылықтарының бірі оның HTTP-мен үйлесімділігі болып табылады, өйткені екі протокол да REST принциптеріне негізделген.
(b) суретте MQTT және AMQP қоса алғанда бір сценарийде екі жариялау-жазылу байланыс үлгісі көрсетілген. Әрбір абстракциялық қабаттағы түйіндер арасындағы байланыс үшін екі хаттаманы да гипотетикалық түрде пайдалануға болатынына қарамастан, олардың орны өнімділік негізінде анықталуы керек. MQTT шектеулі есептеу ресурстары бар құрылғыларға арналған жеңіл протокол ретінде жасалған, сондықтан оны IoT-Fog байланысы үшін пайдалануға болады. AMQP оны тұман мен бұлт түйіндерінің арасында орналастыратын қуаттырақ құрылғылар үшін қолайлы. MQTT орнына XMPP протоколын IoT-де қолдануға болады, өйткені ол жеңіл деп саналады. Бірақ мұндай сценарийлерде ол соншалықты кең қолданылмайды.
қорытындылар
Талқыланатын хаттамалардың бірі жүйедегі шектеулі есептеу ресурстары бар құрылғылардан бастап бұлттық серверлерге дейінгі барлық коммуникацияларды қамту үшін жеткілікті болуы екіталай. Зерттеу көрсеткендей, әзірлеушілер ең көп қолданатын екі перспективалы опция MQTT және RESTful HTTP болып табылады. Бұл екі хаттама ең жетілген және тұрақты ғана емес, сонымен қатар көптеген жақсы құжатталған және сәтті іске асырулар мен онлайн ресурстарды қамтиды.
Тұрақтылығы мен қарапайым конфигурациясының арқасында MQTT шектеулі құрылғылармен IoT деңгейінде пайдаланылған кезде уақыт өте келе өзінің жоғары өнімділігін дәлелдеген хаттама болып табылады. Кейбір тұман домендері және көптеген бұлттық есептеулер сияқты шектеулі байланыс және батареяны тұтыну мәселе болып табылмайтын жүйе бөліктерінде RESTful HTTP оңай таңдау болып табылады. CoAP-ті де ескеру қажет, өйткені ол IoT хабар алмасу стандарты ретінде тез дамып келеді және жақын арада ол MQTT және HTTP сияқты тұрақтылық пен жетілгендік деңгейіне жетуі мүмкін. Бірақ стандарт қазіргі уақытта дамып келеді, бұл қысқа мерзімді үйлесімділік мәселелерімен бірге келеді.
Блогта тағы не оқуға болады?
→
→
→
→
→
Біздің жазылым Келесі мақаланы жіберіп алмау үшін арна! Біз аптасына екі реттен көп емес және тек бизнес бойынша жазамыз.
Ақпарат көзі: www.habr.com