Розвиток технологій у галузі софту та заліза, поява нових протоколів зв'язку призвели до розширення інтернету речей (IoT). Кількість пристроїв зростає з кожним днем, і вони генерують величезний обсяг даних. Тому виникає потреба у зручній архітектурі системи, здатної обробляти, зберігати та передавати ці дані.
Зараз для цього використовують хмарні послуги. Однак парадигма туманних обчислень (Fog), що стає все більш популярною, здатна доповнити хмарні рішення, масштабувавши і оптимізувавши інфраструктуру IoT.
"Хмари" здатні закрити більшість запитів IoT. Наприклад, забезпечити моніторинг служб, швидку обробку будь-яких обсягів даних, що генеруються пристроями, а також їхню візуалізацію. Туманні ж обчислення ефективніше під час вирішення real-time завдань. Вони забезпечують швидкий відгук на запити та мінімальну затримку при обробці даних. Тобто Fog саме доповнює хмари, розширює його можливості.
Втім, головне питання в іншому: як все це має взаємодіяти у контексті IoT? Які протоколи зв'язку будуть найефективнішими під час роботи в об'єднаній системі IoT-Fog-Cloud?
Незважаючи на уявне домінування HTTP, в системах IoT, Fog і Cloud використовується велика кількість інших рішень. Це пояснюється тим, що IoT повинен поєднувати функціональні можливості різноманітних датчиків пристроїв з безпекою, сумісністю та іншими вимогами користувачів.
Ось тільки єдиного уявлення про еталонну архітектуру та стандарт зв'язку просто немає. Тому створення нового протоколу або доопрацювання існуючого під конкретні завдання IoT є одним із найважливіших завдань, які стоять перед ІТ-спільнотою.
Які протоколи використовують зараз і що вони можуть запропонувати? Давайте розумітися. Але для початку обговоримо принципи екосистеми, в якій взаємодіють хмари, туман та інтернет речей.
Архітектура IoT Fog-to-Cloud (F2C)
Ви, напевно, помічали, наскільки значні зусилля докладаються для вивчення переваг та вигод, пов'язаних з раціональним та скоординованим управлінням IoT, хмарами та туманом. Якщо ж ні, то ось вам аж три ініціативи зі стандартизації: , и .
Якщо раніше розглядали лише 2 рівні, хмари та кінцеві пристрої, то пропонована архітектура вводить новий рівень — туманні обчислення. При цьому рівень туману може бути поділений на кілька підрівнів, залежно від специфіки ресурсів або набору політик, які визначають використання різних пристроїв у цих підрівнях.
Як може виглядати ця абстракція? Ось типова екосистема IoT-Fog-Cloud. IoT-пристрою надсилають дані на більш продуктивні сервери та обчислювальні пристрої, щоб вирішувати завдання, що вимагають низького рівня затримки. У цій же системі хмари відповідають за вирішення завдань, що вимагають великого обсягу обчислювальних ресурсів або місця зберігання даних.
Смартфони, розумний годинник та інші гаджети також можуть бути частиною IoT. Але такі пристрої зазвичай використовують пропрієтарні протоколи зв'язку від великих розробників. Згенеровані дані інтернету речей передаються на рівень туману через протокол REST HTTP, який забезпечує гнучкість та функціональну сумісність під час створення RESTful-сервісів. Це важливо у світлі необхідності забезпечення зворотної сумісності з існуючою обчислювальною інфраструктурою, що працює на локальних комп'ютерах, серверах чи кластері серверів. Локальні ресурси, які називають «вузлами туману», фільтрують отримані дані та обробляють їх локально або пересилають у хмару для подальших обчислень.
Хмари підтримують різні протоколи зв'язку, серед яких найчастіше зустрічаються AMQP та REST HTTP. Так як HTTP загальновідомий і заточений під інтернет, може виникнути питання: «Чи не використовувати його для роботи з IoT та туманом?». Однак цей протокол має проблеми з продуктивністю. Про це згодом.
Загалом, існує дві моделі протоколів зв'язку, які підходять під потрібну нам систему. Це запит-відповідь та публікація-підписка. Перша модель відома ширше, особливо в архітектурі сервер-клієнт. Клієнт запитує інформацію з сервера, а той отримує запит, обробляє його і повертає повідомлення у відповідь. За цією моделлю працюють протоколи 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 (resource created). Метод 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 у тумані і якому Raspberry Pi, що виступають у ролі клієнтів 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. Але стандарт зараз розвивається, що пов'язане із короткостроковими проблемами сумісності.
Що ще корисного можна почитати у блозі
→
→
→
→
→
Підписуйтесь на наш -Канал, щоб не пропустити чергову статтю! Пишемо не частіше двох разів на тиждень і лише у справі.
Джерело: habr.com