IoT, магла и облаци: ајде да зборуваме за технологија?

Развојот на технологии во областа на софтверот и хардверот, појавата на нови комуникациски протоколи доведоа до проширување на Интернет на нештата (IoT). Бројот на уреди расте од ден на ден и тие генерираат огромна количина на податоци. Затоа, постои потреба од удобна системска архитектура способна да ги обработува, складира и пренесува овие податоци.

Сега за овие цели се користат облак услугите. Сепак, сè попопуларната парадигма за пресметување на магла (Магла) може да ги надополни решенијата во облак со скалирање и оптимизирање на инфраструктурата на IoT.

Облаците се способни да ги покријат повеќето барања за IoT. На пример, да се обезбеди мониторинг на услугите, брза обработка на која било количина на податоци генерирани од уредите, како и нивна визуелизација. Пресметувањето со магла е поефикасно кога се решаваат проблеми во реално време. Тие обезбедуваат брз одговор на барањата и минимална латентност во обработката на податоците. Односно, Маглата ги надополнува „облаците“ и ги проширува своите способности.

Сепак, главното прашање е различно: како сето ова треба да комуницира во контекст на IoT? Кои протоколи за комуникација ќе бидат најефективни кога работите во комбиниран систем IoT-Fog-Cloud?

И покрај очигледната доминација на HTTP, има голем број други решенија кои се користат во системите IoT, Fog и Cloud. Тоа е затоа што IoT мора да ја комбинира функционалноста на различни сензори на уреди со безбедноста, компатибилноста и другите барања на корисниците.

Но, едноставно не постои единствена идеја за референтната архитектура и комуникацискиот стандард. Затоа, креирањето на нов протокол или менувањето на постоечки за специфични задачи на IoT е една од најважните задачи со кои се соочува ИТ заедницата.

Кои протоколи моментално се користат и што можат да понудат? Ајде да го сфатиме. Но, прво, да разговараме за принципите на екосистемот во кој облаците, маглата и Интернетот на нештата комуницираат.

Архитектура на IoT Fog-to-Cloud (F2C).

Веројатно сте забележале колку напори се вложуваат во истражување на предностите и придобивките поврзани со паметното и координирано управување со IoT, облакот и маглата. Ако не, тогаш еве три иницијативи за стандардизација: Конзорциум OpenFog, Edge Computing Конзорциум и mF2C H2020 ЕУ проект.

Ако претходно се разгледуваа само 2 нивоа, облаци и крајни уреди, тогаш предложената архитектура воведува ново ниво - пресметување магла. Во овој случај, нивото на магла може да се подели на неколку поднивоа, во зависност од спецификите на ресурсите или збир на политики што ја одредуваат употребата на различни уреди во овие поднивоа.

Како може да изгледа оваа апстракција? Еве типичен екосистем IoT-Fog-Cloud. IoT уредите испраќаат податоци до побрзи сервери и компјутерски уреди за да ги решат проблемите кои бараат мала латентност. Во истиот систем, облаците се одговорни за решавање на проблемите кои бараат голема количина на компјутерски ресурси или простор за складирање податоци.

Паметните телефони, паметните часовници и други гаџети исто така можат да бидат дел од IoT. Но, таквите уреди, како по правило, користат сопственички комуникациски протоколи од големи програмери. Генерираните IoT податоци се пренесуваат во слојот за магла преку протоколот REST HTTP, кој обезбедува флексибилност и интероперабилност при креирањето на RESTful услуги. Ова е важно со оглед на потребата да се обезбеди компатибилност наназад со постоечката компјутерска инфраструктура што работи на локални компјутери, сервери или кластер на сервери. Локалните ресурси, наречени „јазли за магла“, ги филтрираат примените податоци и ги обработуваат локално или ги испраќаат во облакот за понатамошни пресметки.

Облаците поддржуваат различни протоколи за комуникација, а најчести се AMQP и REST HTTP. Бидејќи HTTP е добро познат и прилагоден за Интернет, може да се појави прашањето: „да не треба да го користиме за да работиме со IoT и магла? Сепак, овој протокол има проблеми со перформансите. Повеќе за ова подоцна.

Општо земено, постојат 2 модели на протоколи за комуникација погодни за системот што ни треба. Тоа се барање-одговор и објавување-претплата. Првиот модел е пошироко познат, особено во архитектурата на сервер-клиент. Клиентот бара информации од серверот, а серверот го прима барањето, го обработува и враќа порака за одговор. Протоколите REST HTTP и CoAP работат на овој модел.

Вториот модел произлезе од потребата да се обезбеди асинхроно, дистрибуирано, лабаво спојување помеѓу изворите што генерираат податоци и примателите на овие податоци.

Моделот претпоставува три учесници: издавач (извор на податоци), брокер (диспечер) и претплатник (приемник). Овде, клиентот кој дејствува како претплатник не мора да бара информации од серверот. Наместо да испраќа барања, тој се претплати на одредени настани во системот преку брокер, кој е одговорен за филтрирање на сите дојдовни пораки и нивно рутирање помеѓу издавачите и претплатниците. И издавачот, кога ќе се случи настан во врска со одредена тема, го објавува на брокерот, кој испраќа податоци за бараната тема до претплатникот.

Во суштина, оваа архитектура е базирана на настани. И овој модел на интеракција е интересен за апликации во IoT, облак, магла поради неговата способност да обезбеди приспособливост и да ја поедностави меѓусебната врска помеѓу различни уреди, да поддржува динамична комуникација од многу до многу и асинхрона комуникација. Некои од најпознатите стандардизирани протоколи за пораки кои користат модел за објавување-претплата вклучуваат MQTT, AMQP и DDS.

Очигледно, моделот објавување-претплати има многу предности:

• Издавачите и претплатниците не треба да знаат за постоењето на едни со други;
• Еден претплатник може да прима информации од многу различни публикации, а еден издавач може да испраќа податоци до многу различни претплатници (принцип многу-на-многу);
• Издавачот и претплатникот не мора да бидат активни истовремено за да комуницираат, бидејќи брокерот (работи како систем за редици) ќе може да ја складира пораката за клиенти кои моментално не се поврзани на мрежата.

Сепак, моделот барање-одговор има и свои силни страни. Во случаи кога способноста на серверот да се справи со повеќе барања на клиентите не е проблем, има смисла да се користат докажани, сигурни решенија.

Исто така, постојат протоколи кои ги поддржуваат двата модели. На пример, XMPP и HTTP 2.0, кои ја поддржуваат опцијата „server push“. IETF, исто така, објави CoAP. Во обид да се реши проблемот со пораките, создадени се неколку други решенија, како што е протоколот WebSockets или употребата на протоколот HTTP преку QUIC (Quick UDP Internet Connections).

Во случајот на WebSockets, иако се користи за пренос на податоци во реално време од сервер на веб-клиент и обезбедува постојани врски со истовремена двонасочна комуникација, тој не е наменет за уреди со ограничени компјутерски ресурси. QUIC, исто така, заслужува внимание, бидејќи новиот протокол за транспорт дава многу нови можности. Но, бидејќи QUIC сè уште не е стандардизиран, прерано е да се предвиди неговата можна примена и влијание врз решенијата за IoT. Затоа, ги имаме на ум WebSockets и QUIC со поглед кон иднината, но засега нема да ги проучуваме подетално.

Кој е најслаткиот на светот: споредување протоколи

Сега да зборуваме за силните и слабите страни на протоколите. Гледајќи напред, веднаш да направиме резерва дека нема еден јасен лидер. Секој протокол има некои предности/недостатоци.

Време на одговор

Една од најважните карактеристики на протоколите за комуникација, особено во однос на Интернет на нештата, е времето на одговор. Но, меѓу постојните протоколи, не постои јасен победник што го покажува минималното ниво на латентност при работа под различни услови. Но, има цел куп истражувања и споредби на можностите на протоколот.

На пример, Наодите споредбите на ефективноста на HTTP и MQTT при работа со IoT покажаа дека времето на одговор за барањата за MQTT е помало отколку за HTTP. И кога учи Времето на кружно патување (RTT) на MQTT и CoAP откри дека просечниот RTT на CoAP е за 20% помал од оној на MQTT.

Останати експеримент со RTT за протоколите MQTT и CoAP беше спроведено во две сценарија: локална мрежа и IoT мрежа. Се покажа дека просечниот RTT е 2-3 пати поголем во IoT мрежата. MQTT со QoS0 покажа понизок резултат во споредба со CoAP, а MQTT со QoS1 покажа повисок RTT поради ACK на апликативните и транспортните слоеви. За различни QoS нивоа, доцнењето на мрежата без застој беше милисекунди за MQTT и стотици микросекунди за CoAP. Сепак, вреди да се запамети дека кога работите на помалку сигурни мрежи, MQTT што работи на врвот на TCP ќе покаже сосема поинаков резултат.

Споредба времето на одговор за протоколите AMQP и MQTT со зголемување на носивоста покажа дека со мало оптоварување нивото на латентност е речиси исто. Но, кога се пренесуваат големи количини на податоци, MQTT демонстрира пократко време на одговор. во уште една истражување CoAP беше спореден со HTTP во сценарио за комуникација од машина до машина со уреди распоредени над возила опремени со сензори за гас, временски сензори, сензори за локација (GPS) и мобилна мрежна интерфејс (GPRS). Времето потребно за пренос на CoAP порака преку мобилната мрежа беше речиси три пати пократко од времето потребно за користење на HTTP пораки.

Спроведени се студии кои споредуваат не два, туку три протоколи. На пример, споредба изведба на IoT протоколите MQTT, DDS и CoAP во сценарио за медицинска апликација користејќи мрежен емулатор. DDS го надмина MQTT во однос на латентноста на тестираната телеметрија под различни лоши мрежни услови. CoAP базиран на UDP работеше добро за апликации кои бараат брзо време на одговор, меѓутоа, поради тоа што беше базиран на 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 е енергетски поефикасен.

безбедност

Безбедноста е уште едно критично прашање покренато при проучување на темата Интернет на нештата и магла/облак компјутери. Безбедносниот механизам обично се базира на TLS во HTTP, MQTT, AMQP и XMPP или DTLS во CoAP и ги поддржува двете DDS варијанти.

TLS и DTLS започнуваат со процесот на воспоставување комуникација помеѓу клиентот и серверот за размена на поддржани пакети и клучеви за шифри. Двете страни преговараат за сетови за да се осигураат дека понатамошната комуникација ќе се случи на безбеден канал. Разликата помеѓу двете лежи во малите модификации кои овозможуваат DTLS базирана на UDP да работи преку несигурна врска.

на тест напади Неколку различни имплементации на TLS и DTLS открија дека TLS направи подобра работа. Нападите на DTLS беа поуспешни поради неговата толеранција на грешки.

Сепак, најголемиот проблем со овие протоколи е што тие не беа првично дизајнирани за употреба во IoT и не беа наменети да работат во магла или облак. Преку ракување, тие додаваат дополнителен сообраќај со секое воспоставување врска, што ги троши компјутерските ресурси. Во просек, има зголемување од 6,5% за TLS и 11% за DTLS во горните трошоци во споредба со комуникациите без безбедносен слој. Во средини богати со ресурси, кои обично се наоѓаат на облачно ниво, ова нема да биде проблем, но во врската помеѓу IoT и нивото на магла, ова станува важно ограничување.

Што да се избере? Нема јасен одговор. MQTT и HTTP се чини дека се најперспективните протоколи бидејќи се сметаат за релативно позрели и постабилни решенија за IoT во споредба со другите протоколи.

Решенија базирани на унифициран протокол за комуникација

Практиката на еднопротоколно решение има многу недостатоци. На пример, протокол кој одговара на ограничена средина може да не работи во домен кој има строги безбедносни барања. Имајќи го ова на ум, ни останува да ги отфрлиме скоро сите можни решенија со еден протокол во екосистемот Fog-to-Cloud во IoT, освен MQTT и REST HTTP.

REST HTTP како решение со еден протокол

Има добар пример за тоа како REST HTTP барањата и одговорите комуницираат во просторот IoT-to-Fog: паметна фарма. Животните се опремени со сензори за носење (IoT клиент, C) и контролирани преку cloud computing со паметен систем за земјоделство (Fog Server, S).

Заглавието на методот POST го одредува ресурсот за менување (/фарма/животни), како и HTTP верзијата и типот на содржина, што во овој случај е JSON објект што ја претставува животинската фарма со која системот треба да управува (Dulcinea/крава) . Одговорот од серверот покажува дека барањето било успешно со испраќање на статусен код на HTTPS 201 (создаден ресурс). Методот GET мора да го специфицира само бараниот ресурс во URI (на пример, /farm/animals/1), кој враќа JSON претстава на животното со тој ID од серверот.

Методот PUT се користи кога треба да се ажурира одреден запис за ресурси. Во овој случај, ресурсот го одредува URI за параметарот што треба да се смени и моменталната вредност (на пример, покажувајќи дека кравата моментално оди, /фарма/животни/1? состојба=одење). Конечно, методот DELETE се користи подеднакво како и методот GET, но едноставно го брише ресурсот како резултат на операцијата.

MQTT како еднопротоколно решение

Да ја земеме истата паметна фарма, но наместо REST HTTP го користиме протоколот MQTT. Локален сервер со инсталирана библиотека Mosquitto делува како посредник. Во овој пример, едноставен компјутер (наведен како сервер за фарма) Raspberry Pi служи како клиент MQTT, имплементиран преку инсталација на библиотеката Paho MQTT, која е целосно компатибилна со брокерот Mosquitto.

Овој клиент одговара на слој за апстракција на IoT што претставува уред со способности за сензори и пресметување. Медијаторот, од друга страна, одговара на повисоко ниво на апстракција, што претставува компјутерски јазол за магла што се карактеризира со поголем капацитет за обработка и складирање.

Во предложеното сценарио за паметна фарма, Raspberry Pi се поврзува со акцелерометарот, GPS и сензорите за температура и објавува податоци од овие сензори во јазол за магла. Како што веројатно знаете, MQTT ги третира темите како хиерархија. Еден издавач на MQTT може да објавува пораки за одреден сет на теми. Во нашиот случај има три од нив. За сензор кој ја мери температурата во штала за животни, клиентот избира тема (животинска фарма/барака/температура). За сензорите што ја мерат локацијата на GPS и движењето на животните преку акцелерометарот, клиентот ќе објави ажурирања за (животинска фарма/животно/GPS) и (животинска фарма/животно/движење).

Оваа информација ќе биде предадена на брокерот, кој може привремено да ги складира во локална база на податоци во случај подоцна да дојде друг заинтересиран претплатник.

Покрај локалниот сервер, кој делува како MQTT посредник во магла и на кој Raspberry Pis, делувајќи како MQTT клиенти, испраќа податоци од сензорот, може да има уште еден MQTT брокер на ниво на облак. Во овој случај, информациите пренесени до локалниот брокер може привремено да се складираат во локална база на податоци и/или да се испратат до облакот. Брокерот за магла MQTT во оваа ситуација се користи за поврзување на сите податоци со брокерот на облак MQTT. Со оваа архитектура, корисник на мобилна апликација може да се претплати на двата брокери.

Ако врската со еден од брокерите (на пример, облак) не успее, крајниот корисник ќе добие информации од другиот (магла). Ова е карактеристична карактеристика на комбинираните системи за компјутерска магла и облак. Стандардно, мобилната апликација може да се конфигурира прво да се поврзе со брокерот за магла MQTT, а ако тоа не успее, да се поврзе со брокерот за облак MQTT. Ова решение е само едно од многуте во системите IoT-F2C.

Мулти-протоколни решенија

Решенијата со еден протокол се популарни поради нивната полесна имплементација. Но, јасно е дека во системите IoT-F2C има смисла да се комбинираат различни протоколи. Идејата е дека различни протоколи можат да работат на различни нивоа. Земете, на пример, три апстракции: слоевите на IoT, маглата и cloud computing. Уредите на ниво на 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 е паметно решение.

Од друга страна, за уредите со ограничени компјутерски ресурси кои комуницираат помеѓу слоевите Fog и IoT, поефикасно е да се користи CoAP. Една од големите предности на CoAP е всушност неговата компатибилност со HTTP, бидејќи и двата протоколи се базирани на принципите REST.

Слика (б) покажува два модели на комуникација за објавување-претплата во истото сценарио, вклучувајќи ги MQTT и AMQP. Иако и двата протоколи хипотетички би можеле да се користат за комуникација помеѓу јазлите на секој слој на апстракција, нивната позиција треба да се одреди врз основа на перформансите. MQTT беше дизајниран како лесен протокол за уреди со ограничени компјутерски ресурси, така што може да се користи за комуникација IoT-Fog. AMQP е посоодветен за помоќни уреди, кои идеално би го поставиле помеѓу јазлите за магла и облак. Наместо MQTT, протоколот XMPP може да се користи во IoT бидејќи се смета за лесен. Но, тоа не е толку широко користено во такви сценарија.

Наоди

Малку е веројатно дека еден од дискутираните протоколи ќе биде доволен за да ги покрие сите комуникации во системот, од уреди со ограничени компјутерски ресурси до облак сервери. Студијата покажа дека двете најперспективни опции кои програмерите најмногу ги користат се MQTT и RESTful HTTP. Овие два протоколи не само што се најзрели и најстабилни, туку вклучуваат и многу добро документирани и успешни имплементации и онлајн ресурси.

Поради својата стабилност и едноставна конфигурација, MQTT е протокол кој ги докажал своите супериорни перформанси со текот на времето кога се користи на ниво на IoT со ограничени уреди. Во делови од системот каде што ограничената комуникација и потрошувачката на батеријата не се проблем, како што се некои домени за магла и повеќето облак компјутери, RESTful HTTP е лесен избор. CoAP, исто така, треба да се земе предвид бидејќи исто така брзо се развива како стандард за IoT пораки и веројатно е дека ќе достигне ниво на стабилност и зрелост слично на MQTT и HTTP во блиска иднина. Но, стандардот во моментов се развива, што доаѓа со краткорочни проблеми со компатибилноста.

Што друго можете да прочитате на блогот? Cloud4y

→ Компјутерот ќе ве направи вкусни
→ ВИ помага во проучувањето на животните во Африка
→ Летото е речиси завршено. Скоро и да нема непротечени податоци
→ 4 начини да заштедите на бекап во облак
→ На унифициран федерален информативен ресурс кој содржи информации за населението

Претплатете се на нашата Телеграма-канал за да не ја пропуштите следната статија! Ние пишуваме не повеќе од двапати неделно и само на деловен план.

Извор: www.habr.com