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

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

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

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

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

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

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

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

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

Вероятно сте заб注意ли колко значителни усилия се полагат за проучване на предимствата и ползите, свързани с рационалното и координирано управление на IoT, облаците и тумана. Ако не, ето ви три инициативи за стандартизация: OpenFog Consortium, Edge Computing Consortium и mF2C H2020 EU project.

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

Как може да изглежда тази абстракция? Ето типична екосистема 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 и не предвиждат работа в облака или тумор. Чрез установена размяна (handshaking) те добавят допълнителен трафик с всяко установяване на връзка, което изтощава изчислителните ресурси. В средно наблюдава се увеличение от 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 обект, представляващ животновъдната ферма, която системата трябва да управлява (Дулсинея\/кравата). Отговорът от сървъра указва, че запитването е успешно, изпращайки код на състоянието HTTPS 201 (ресурс създаден). Методът GET трябва да указва само поисканото съдържание в URI (например, \/farm\/animals\/1), което връща JSON представяне на животното с този идентификатор от сървъра.

Методът PUT се използва, когато е необходимо да се обнови конкретна запис на ресурса. В този случай в ресурса се указва URI за параметъра, който трябва да се промени, и текущото значение (например, указващо, че кравата в момента се разхожда, \/farm\/animals\/1? статус=разходка). Накрая, методът DELETE се използва по същия начин като метода GET, но просто изтрива ресурса в резултат на операцията.

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

Да вземем същата умна ферма, но вместо REST HTTP ще използваме протокол MQTT. Локален сървър с инсталирана библиотека Mosquitto изпълнява ролята на брокер. В този пример обикновен компютър (означен като сървър на фермата) Raspberry Pi служи като клиент на MQTT, реализиран чрез инсталиране на библиотеката MQTT Paho, която е напълно съвместима с брокера Mosquitto.

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

В предложеното сценарий на "умната ферма" Raspberry Pi се свързва с акселерометър, GPS и температурни сензори и публикува данни от тези сензори в мъгловия възел. Както вероятно знаете, MQTT разглежда темите като йерархия. Един MQTT издател може да публикува съобщения в определен набор от теми. В нашия случай те са три. За сензора, който измерва температурата в животновъдния навес, клиентът избира тема (animalfarm/shed/temperature). За сензорите, които измерват местоположението на GPS и движението на животните чрез акселерометъра, клиентът публикува актуализации (animalfarm/animal/GPS) и (animalfarm/animal/movement).

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

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

На картинката (б) се показват два модела на взаимодействие „публикация-подписка“ в един сценарий, включващи MQTT и AMQP. Въпреки че хипотетично и двата протокола биха могли да се използват за комуникация между узли на всеки абстрактен слой, тяхното положение трябва да бъде определено на базата на производителността. MQTT е проектиран като опростен протокол за устройства с ограничени изчислителни ресурси, затова може да се използва за комуникация между IoT и мъглата. AMQP е по-подходящ за по-мощни устройства, които биха го позиционирали идеално между узлите на мъглата и облака. Вместо MQTT в IoT може да се използва протокол XMPP, тъй като той се счита за лек. Но не е толкова широко използван в подобни сценарии.

Изводи

Малко вероятно е един от разглежданите протоколи да е достатъчен за обхващане на цялата комуникация в системата, започвайки от устройства с ограничени изчислителни ресурси и завършвайки с облачните сървъри. Изследването показа, че двата най-проспериращи варианта, които по-често използват разработчиците, са MQTT и RESTful HTTP. Тези два протокола не само са най-зрелите и стабилни, но също така включват множество добре документирани и успешни реализации и онлайн ресурси.

Благодарение на своята стабилност и лесна конфигурация, MQTT е протокол, който с времето е доказал своето отлично представяне в IoT приложения с ограничени устройства. В системни части, където ограничената свързаност и консумацията на батерия не са проблем, като в някои области на облаците и повечето облачни изчисления, RESTful HTTP е прост избор. CoAP също трябва да бъде взет под внимание, тъй като бързо се развива като стандарт за обмен на съобщения в IoT и е вероятно в близко бъдеще да достигне ниво на стабилност и зрялост, сравнимо с MQTT и HTTP. Но стандартът в момента се развива, което носи краткосрочни проблеми с съвместимостта.

Какво още полезно може да прочетете в блога Cloud4Y

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

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

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