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

Развитието на технологиите в областта на софтуера и хардуера, появата на нови комуникационни протоколи доведоха до разрастването на Интернет на нещата (IoT). Броят на устройствата нараства с всеки изминал ден и те генерират огромно количество данни. Следователно има нужда от удобна системна архитектура, способна да обработва, съхранява и предава тези данни.

Сега за тези цели се използват облачни услуги. Въпреки това все по-популярната парадигма за изчисления в мъгла (Fog) може да допълни облачните решения чрез мащабиране и оптимизиране на IoT инфраструктура.

Облаците са в състояние да покрият повечето IoT заявки. Например, за осигуряване на мониторинг на услуги, бърза обработка на произволно количество данни, генерирани от устройствата, както и тяхната визуализация. Fog computing е по-ефективен при решаване на проблеми в реално време. Осигуряват бърз отговор на заявки и минимално забавяне при обработката на данните. Тоест, Fog допълва „облаците“ и разширява възможностите им.

Основният въпрос обаче е друг: как всичко това трябва да взаимодейства в контекста на IoT? Какви комуникационни протоколи ще бъдат най-ефективни при работа в комбинирана IoT-Fog-Cloud система?

Въпреки очевидното доминиране на HTTP, има голям брой други решения, използвани в IoT, Fog и Cloud системи. Това е така, защото IoT трябва да комбинира функционалността на различни сензори на устройства със сигурността, съвместимостта и други изисквания на потребителите.

Но просто няма единна идея за референтната архитектура и комуникационния стандарт. Следователно създаването на нов протокол или модифицирането на съществуващ за конкретни IoT задачи е една от най-важните задачи, пред които е изправена ИТ общността.

Какви протоколи се използват в момента и какво могат да предложат? Нека да го разберем. Но първо, нека обсъдим принципите на екосистемата, в която си взаимодействат облаците, мъглата и интернет на нещата.

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

Вероятно сте забелязали колко много усилия се влагат в изследване на предимствата и ползите, свързани с интелигентното и координирано управление на IoT, облак и мъгла. Ако не, тогава ето три инициативи за стандартизация: Консорциум OpenFog, Edge Computing Consortium и 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 по отношение на тестваното забавяне на телеметрията при различни лоши мрежови условия. Базираният на 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 е по-енергийно ефективен.

сигурност

Сигурността е друг критичен въпрос, повдигнат при изучаването на темата за интернет на нещата и изчисленията в мъгла/облак. Механизмът за защита обикновено се основава на TLS в HTTP, MQTT, AMQP и XMPP или DTLS в CoAP и поддържа и двата варианта на DDS.

TLS и DTLS започват с процеса на установяване на комуникация между клиентската и сървърната страна за обмен на поддържани комплекти за шифроване и ключове. И двете страни договарят комплекти, за да гарантират, че по-нататъшната комуникация се осъществява по защитен канал. Разликата между двете се крие в малки модификации, които позволяват на UDP-базиран DTLS да работи при ненадеждна връзка.

при тестови атаки Няколко различни реализации на 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) и се контролират чрез облачни изчисления от система за интелигентно земеделие (Fog сървър, S).

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

Методът PUT се използва, когато трябва да се актуализира някакъв конкретен ресурсен запис. В този случай ресурсът посочва URI за параметъра, който трябва да бъде променен, и текущата стойност (например, показвайки, че кравата в момента ходи, /farm/animals/1? state=walking). И накрая, методът 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 брокер на ниво облак. В този случай информацията, предадена на местния брокер, може да бъде временно съхранена в локална база данни и/или изпратена в облака. Брокерът на fog MQTT в тази ситуация се използва за свързване на всички данни с брокера MQTT на облака. С тази архитектура потребител на мобилно приложение може да бъде абониран и за двата брокера.

Ако връзката с един от брокерите (например облак) се провали, крайният потребител ще получи информация от другия (мъгла). Това е характерна черта на комбинираните изчислителни системи за мъгла и облак. По подразбиране мобилното приложение може да бъде конфигурирано да се свързва първо с fog MQTT брокера и ако това не успее, да се свързва с облачния MQTT брокер. Това решение е само едно от многото в системите IoT-F2C.

Многопротоколни решения

Решенията с един протокол са популярни поради по-лесната им реализация. Но е ясно, че в системите IoT-F2C има смисъл да се комбинират различни протоколи. Идеята е, че различните протоколи могат да работят на различни нива. Вземете например три абстракции: слоевете IoT, мъгла и облачни изчисления. Устройствата на ниво IoT обикновено се считат за ограничени. За този общ преглед нека разгледаме нивата на IoT като най-ограничените, облачните като най-малко ограничените, а изчисленията в мъгла като „някъде по средата“. Тогава се оказва, че между абстракциите на IoT и fog, текущите протоколни решения включват MQTT, CoAP и XMPP. Между мъглата и облака, от друга страна, AMQP е един от основните използвани протоколи, заедно с REST HTTP, който поради своята гъвкавост се използва и между IoT и слоевете за мъгла.

Основният проблем тук е оперативната съвместимост на протоколите и лекотата на прехвърляне на съобщения от един протокол към друг. В идеалния случай в бъдеще архитектурата на система за интернет на нещата с ресурси за облак и мъгла ще бъде независима от използвания комуникационен протокол и ще гарантира добра оперативна съвместимост между различни протоколи.

Тъй като в момента това не е така, има смисъл да се комбинират протоколи, които нямат съществени разлики. За тази цел едно потенциално решение се основава на комбинация от два протокола, които следват същия архитектурен стил, REST HTTP и CoAP. Друго предложено решение се основава на комбинация от два протокола, които предлагат комуникация публикуване-абониране, MQTT и AMQP. Използването на подобни концепции (както MQTT, така и AMQP използват брокери, CoAP и HTTP използват REST) ​​прави тези комбинации по-лесни за изпълнение и изисква по-малко усилия за интегриране.

Фигура (a) показва два модела, базирани на заявка-отговор, HTTP и CoAP, и възможното им поставяне в IoT-F2C решение. Тъй като HTTP е един от най-известните и приети протоколи в съвременните мрежи, малко вероятно е той да бъде напълно заменен от други протоколи за съобщения. Сред възлите, представляващи мощни устройства, които се намират между облака и мъглата, REST HTTP е интелигентно решение.

От друга страна, за устройства с ограничени изчислителни ресурси, които комуникират между слоевете Fog и 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. Но стандартът в момента се развива, което идва с краткосрочни проблеми със съвместимостта.

Какво друго можете да прочетете в блога? Cloud4Y

→ Компютърът ще ви направи вкусни
→ AI помага при изучаването на животни в Африка
→ Лятото почти свърши. Почти не са останали неизтекли данни
→ 4 начина да спестите от резервни копия в облак
→ На единен федерален информационен ресурс, съдържащ информация за населението

Абонирайте се за нашите Telegram-канал, за да не пропуснете следващата статия! Пишем не повече от два пъти седмично и само по работа.

Източник: www.habr.com