Развитието на технологиите в областта на софтуера и хардуера, появата на нови комуникационни протоколи, доведе до разширяване на интернет на нещата (IoT). Броят на устройствата нараства всеки ден и те генерират огромно количество данни. Затова възниква нуждата от удобна архитектура на системата, способна да обработва, съхранява и предава тези данни.
В момента за тези цели се използват облачни услуги. Въпреки това, нарастващата популярност на парадигмата за мъглени изчисления (Fog) може да допълни облачните решения, мащабирайки и оптимизирайки инфраструктурата на IoT.
Облакът може да покрие повечето от нуждите на IoT. Например, той осигурява мониторинг на услуги, бърза обработка на всякакви обеми данни, генерирани от устройства, както и тяхната визуализация. Мъглените изчисления обаче са по-ефективни при решаване на задачи в реално време. Те осигуряват бързо реагиране на заявки и минимално забавяне при обработката на данни. Следователно, Fog точно допълва „облаците“, разширявайки техните възможности.
Въпреки това, основният въпрос е друг: как всичко това трябва да взаимодейства в контекста на IoT? Кои комуникационни протоколи ще бъдат най-ефективни при работа в обединена система IoT-Fog-Cloud?
Въпреки видимото доминиране на HTTP, в системите IoT, Fog и Cloud се използва голямо количество други решения. Това се дължи на факта, че IoT трябва да съчетава функционалните възможности на разнообразни сензори от устройства с безопасността, съвместимостта и другите изисквания, поставяни от потребителите.
Обаче, няма единно разбиране за еталонната архитектура и стандартите за комуникация. Затова създаването на нов протокол или подобряване на съществуващия за конкретни задачи IoT е една от най-важните задачи пред ИТ-общността.
Какви протоколи се използват в момента и какво могат да предложат? Нека разберем. Но за начало, нека обсъдим принципите на екосистемата, в която взаимодействат облаците, мъглата и интернет на нещата.
Архитектурата IoT Fog-to-Cloud (F2C)
Вероятно сте забелязали колко значителни усилия се полагат за изучаване на предимствата и ползите, свързани с рационалното и координирано управление на IoT, облаците и мъглата. Ако не, то ето ви три инициативи за стандартизация: , и .
Ако до сега са били разглеждани само 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 като еднопротоколнo решение
Има добър пример за взаимодействие на заявки и отговори 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?state=гледа). Накрая методът 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 брокер в мъглата, на който Raspberry Pi, действащи като MQTT клиенти, изпращат данни от сенzorите, на облачното ниво може да има още един 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. Но стандартът все още се развива, което е свързано с краткосрочни проблеми със съвместимостта.
Какво още полезно може да се прочете в блога
→
→
→
→
→
Абонирайте се за нашия -канал, за да не пропуснете следващата статия! Пишем не по-често от два пъти в седмицата и само по същество.
Източник: habr.com
