Зміст
MQTT (MQ Telemetry Transport) — це негроміздкий обміну повідомленнями, що працює за моделлю «видавець—підписник». Його призначено для телеметрії між машинами (M2M) у середовищах із низькою пропускною здатністю. Це найпоширеніший протокол передачі повідомлень для Інтернету речей (IoT).
MQTT — це набір правил, що визначає, в який спосіб пристрої IoT публікують дані та підписуються на них через Інтернет. Цей протокол використовується для обміну повідомленнями й даними для IoT та промислового IoT (IIoT), наприклад, вбудованими пристроями, датчиками, промисловими програмованими логічними контролерами та іншими пристроями.
Відправник (видавець) та одержувач (підписник) зв’язуються один з одним із використанням тем (топіків) і працюють окремо один від одного. Зв’язком між ними керує MQTT. Брокер MQTT фільтрує всі вхідні повідомлення та розповсюджує їх між відповідними підписниками.
Протокол MQTT створили Енді Стенфорд-Клерк (IBM) та Арлен Ніппер у 1999 році для підключення телеметрії систем нафтопроводу через супутник. Цей протокол мав забезпечувати мінімальне споживання заряду акумулятора та мінімальну пропускну здатність. Винахідники сформулювали такі вимоги до протоколу:
Ці цілі й досі є основою MQTT. Проте головний фокус протоколу перейшов від пропрієтарних вбудованих систем до відкритих прикладів застосуванні для Інтернету речей (IoT). MQTT більше не вважають абревіатурою. Тепер MQTT є назвою протоколу.
Незважаючи на те, що MQTT спочатку був закритим, у 2010 році версію 3.1 було видано з ліцензією royalty-free. 2014 року MQTT став офіційно затвердженим стандартом OASIS.
Є два варіанти й декілька версій MQTT:
Наразі дуже поширена версія 3.1.1. Найновішу версію (5-а) затверджено в 2019 році, і вона підтримується обмежено. Клієнт mosquitto підтримує її з випуску 1.6, а клієнт Paho (Python) — з версії 1.5.1. Специфікація MQTT-SN з’явилася в 2013 році. Її призначено для роботи з UDP, ZigBee й іншими транспортами.
Нижче наведено головні особливості MQTT.
На відміну від парадигми «запит-відповідь» протоколу HTTP, MQTT керує подіями й дозволяє клієнтам надсилати push-повідомлення. Ця архітектура відокремлює клієнтів один від одного, що дає можливість створювати високомасштабовані рішення без залежностей між пристроями, що генерують дані, і пристроями, що їх отримують.
З’єднання MQTT завжди встановлюється між клієнтом і брокером. MQTT відокремлює видавця від абонента, і клієнти ніколи не підключаються один до одного безпосередньо. Зв’язки між клієнтами завжди обслуговуються брокерами. Для підключення клієнт надсилає брокеру повідомлення CONNECT. Брокер відповідає повідомленням CONNACK із кодом стану. Коли з’єднання встановлено, брокер залишає його відкритим, поки клієнт не надішле повідомлення про відключення або з’єднання не буде розірвано.
Розглянемо клієнти й брокери докладніше.
Клієнтами MQTT є і видавці, і передплатники. Їх називають видавцями й передплатниками залежно від того, що робить клієнт у певний момент: публікує повідомлення чи підписується на їх отримання. В одному й тому самому клієнті MQTT можна реалізувати функціонал і видавця, і підписника. Клієнтом MQTT є будь-який пристрій, від мікроконтролера до повнофункціонального сервера, що запускає бібліотеку MQTT й підключається до брокера MQTT по мережі. Наприклад, клієнт MQTT може бути дуже маленьким пристроєм із обмеженими ресурсами й мінімальною бібліотекою, який підключено через бездротову мережу. Клієнтом MQTT може бути також типовий комп’ютер, що використовує графічний клієнт MQTT для тестування. Реалізація протоколу MQTT для клієнта дуже проста, тому він ідеально підходить для невеликих пристроїв. Клієнтські бібліотеки MQTT доступні для різних мов програмування й платформ, зокрема таких:
Брокер є центром будь-якого протоколу, який працює за моделлю «видавець—підписник». Деякі реалізації брокера дають їм змогу обслуговувати мільйони одночасно підключених клієнтів MQTT.
Брокер відповідає за прийом усіх повідомлень, їх фільтрацію, ідентифікацію передплатників для кожного повідомлення й надсилання відповідним клієнтам. Він також зберігає дані для всіх клієнтів із постійними сеансами, зокрема підписки й пропущені повідомлення. До того ж, брокер здійснює аутентифікацію й авторизацію клієнтів. Зазвичай брокер є розширюваним, що спрощує аутентифікацію користувачів, авторизацію та інтеграцію в серверні системи. Інтеграція особливо важлива, оскільки брокер часто є тим компонентом, який підключений до Інтернету безпосередньо, обслуговує багатьох клієнтів і має надсилати повідомлення в системи аналізу та обробки. Оскільки всі повідомлення проходять через брокера, він має бути масштабованим, інтегрованим у серверні системи, легким для відстеження та стійким до збоїв.
У MQTT слово «суб’єкт» означає рядок у кодуванні UTF-8, що використовується брокером з метою фільтрації повідомлень для кожного підключеного клієнта. Тема містить один або кілька рівнів. Рівні відокремлено один від одного косою рискою (роздільником рівня теми):
Порівняно з чергою повідомлень, теми MQTT не такі громіздкі. Замовнику не потрібно створювати необхідну тему перед публікацією або підпискою. Брокер приймає тему без будь-якої попередньої ініціалізації.
Кожна тема має складатися хоча б з одного символу. У рядку теми допускаються пробіли. Теми чутливі до регістру. Наприклад, office/temperature та Office/Temperature – це дві різні теми. Темою може бути навіть символ косої риски.
Коли клієнт підписується на тему, він може підписатися на певну тему опублікованого повідомлення або використати символи узагальнення, щоб підписатися на кілька тем одночасно. Символ узагальнення можна використовувати лише для підписки на теми й не можна використовувати для публікації. Є два символи узагальнення: однорівневий і багаторівневий.
Однорівневий символ узагальнення замінює один рівень теми. Для цього використовується символ плюсу (+).
Тема відповідає темі символом узагальнення, якщо містить довільний рядок на місці цього символу. Наприклад, підписка на тему office/+/humidity може дати такі результати:
+ office/room1/humidity
+ office/conference-room/humidity
Але вона не відповідатиме зазначеним нижче результатам:
– home/room1/humidity
– office/room1/temperature
Багаторівневий символ узагальнення охоплює кілька рівнів теми. Для цього використовується символ діезу (#). Щоб брокер визначив, які теми необхідно зіставити, цей символ узагальнення має бути останнім у темі, а перед ним має бути пряма коса риска.
Цей запис відповідатиме таким темам:
+ office/room1/humidity
+ office/room1/temperature
Йому не відповідатимуть такі теми:
– home/room1/temperature
– office/conference-room/humidity
Коли клієнт підписується на тему з багаторівневим символом узагальнення, він отримує всі тематичні повідомлення, що починаються з шаблону узагальнення, незалежно від кількості рівнів у темі. Якщо тему складає лише цей символ узагальнення (#), будуть отримані всі повідомлення, що надіслано брокером MQTT. Якщо ви очікуєте високої пропускної здатності, використовувати лише багаторівневий символ узагальнення як тему не рекомендовано.
Загалом, ви можете називати теми MQTT як завгодно. Проте є і виняток. Теми, що починаються з символу $, мають інше призначення. Їх не буде включено в підписку з використанням багаторівневого символу узагальнення (#). Ці теми зарезервовано для внутрішньої статистики брокера MQTT. Клієнти не можуть публікувати повідомлення в цих темах. Наразі офіційного стандарту подібних тем немає.
MQTT є двійковим протоколом, у якому елементи керування представлено двійковими байтами, а не рядками тексту. MQTT використовує формат команд і підтвердження. Кожна команда має відповідне підтвердження.
Назви тем, ідентифікатори клієнтів, імена користувачів і паролі представлено у вигляді рядків у кодуванні UTF-8. Корисне навантаження, за винятком інформації протоколу MQTT, тобто ідентифікатора клієнта і т. і., представлено у вигляді двійкових даних, а вміст є специфічним для програми.
Пакет MQTT складається з двобайтового фіксованого заголовка (завжди присутній), змінного заголовка (не завжди присутній) і корисного навантаження (не завжди присутнє).
Можливі формати пакетів:
Фіксоване поле заголовка складається з поля керування й поля довжини пакета (поле змінної довжини).
Мінімальний розмір поля довжини пакета становить 1 байт і підходить для повідомлень із загальною довжиною менше за 127 байт (за винятком поля керування й довжини). Максимальний розмір пакета — 256 МБ. Пакети довжиною понад 127 і менше за 16383 байт матимуть розмір поля 2 байти і так далі. Примітка. Використовується 7 бітів, а 8-й є бітом продовження.
Мінімальний розмір пакета становить 2 байти: однобайтове поле керування й поле довжини пакета в один байт. Наприклад, повідомлення DISCONNECT містить лише два байти.
8-бітне поле керування є першим байтом двобайтового фіксованого заголовка. Його поділено на два 4-бітних поля, що містять усі команди й відповіді протоколу.
Перші 4 найбільш значущих біта — поле типу команди або повідомлення, а другі використовуються як прапорці керування. Наприклад, команда CONNECT має двійковий код 0001 (десятковий = 1), CONNACK — 0010 (2), PUBLISH — 0100 (3), DISCONNECT — 1110 (14). Оскільки це старші біти, фактичні коди будуть бітами від п’ятого до восьмого біта, наприклад, CONNECT — 00010000 (16), CONNACK — 00100000 (32) і так далі.
Хоча 16 прапорців керування можуть бути представлені чотирма бітами, лише деякі використовуються часто. У повідомленні PUBLISH використовуються всі біти, як показано нижче:
| Біт 3 | Біт 2 | Біт 1 | Біт 0 |
| DUP | QoS | QoS | RETAIN |
Прапорець DUP використовується для повторної публікації повідомлення з QoS 1 або 2.
Прапорці QoS використовуються для публікації з зазначенням рівня QoS (0 — один раз, не гарантовано, 1 — щонайменше один раз, гарантовано, 2 — лише один раз, гарантовано).
Прапорець RETAIN також використовується під час публікації.
Кожен із байтів поля довжини використовує 7 бітів для позначення довжини, а MSB використовується як прапорець продовження.
Як було зазначено вище, цей заголовок не завжди присутній у повідомленні MQTT. Він є необхідним у деяких типах повідомлень MQTT для передачі додаткової керуючої інформації. Цей заголовок схожий, але не однаковий для різних типів повідомлень.
Врешті решт пакет може містити корисне навантаження. Це необов’язкове поле, що містить різну інформацію для різних типів пакетів. Зазвичай це поле містить дані, що надсилаються. Наприклад, для пакета CONNECT робочим навантаженням є ідентифікатор клієнта, а також ім’я користувача й пароль, якщо їх зазначено. Для пакета PUBLISH це опубліковане повідомлення.
Першим байтом пакета CONNECT буде 00010000. Команда CONNECT має код 1, тому для старших чотирьох бітів буде встановлено значення 0001, а оскільки прапорців немає, то і молодші чотири біти дорівнюватимуть нулю.
Другим байтом буде довжина решти пакета. Він складається з довжини заголовка змінної довжини й довжини корисного навантаження. Нижче наведено формат заголовка змінної довжини та корисного навантаження пакета CONNECT.
Коли йдеться про безпеку мережі IoT, потрібно враховувати три основні поняття: ідентифікатор користувача, аутентифікацію та авторизацію.
У кожному сценарії MQTT беруть участь клієнт і брокер. Як вже говорилося раніше, клієнтом може бути будь-який пристрій: від мікроконтролера до сервера. Будь-який пристрій, що підключається до брокера, вважається клієнтом.
Брокер отримує всі повідомлення й координує їх публікацію для підписаних клієнтів. Брокер відповідає за підтримку стійких підключень, а також ідентифікацію та авторизацію для передачі даних клієнтам MQTT. З’єднання MQTT встановлюється лише між одним клієнтом і одним брокером.
Для підключення до брокера клієнт має передати йому ідентифікатор клієнта в повідомленні CONNECT. В ідеалі кожен клієнт має унікальний ідентифікатор. Більшість пристроїв мають універсальний унікальний ідентифікатор (UUID) або MAC-адресу мережевого пристрою для підключення клієнта.
Після отримання повідомлення CONNECT брокер перевіряє ідентифікатор, ім’я користувача й пароль, щоб визначити, чи має клієнт право підключитися до брокера, .
Крім аутентифікації з використанням імені користувача й пароля, протокол MQTT дає змогу здійснювати аутентифікацію за допомогою сертифіката X.509. Для цього виберіть TLS (Transport Layer Security) як метод шифрування.
Коли клієнт підключається до брокера, він може виконати дві дії: публікувати й підписуватися на теми. Теми є основним ресурсом, доступним для клієнтів, і вони вимагають авторизації для безпеки системи. Без неї будь-який клієнт зможе підключитися до будь-якої теми, доступної в брокері.
Найпоширенішими типами авторизації є контроль доступу на основі ролей (RBAC) та список контролю доступу (ACL).
За використання RBAC роль надає шар абстракції між клієнтом і основним ресурсом, тобто в даному випадку темами. З певними ролями пов’язані певні дозволи, що дозволяє брокеру авторизувати клієнта для публікації чи підписки на певну тему.
ACL пов’язує конкретних клієнтів зі списком дозволів. Ці дозволи містять політики, що визначають теми, на які клієнт може підписатися або в яких може опублікувати.
Також можлива авторизація за допомогою токенів доступу. Вони дають змогу обмежити дозволи клієнтів певною сферою, дозволяючи запобігти несанкціонованому доступу до читання або запису даних, який може мати небажаний вплив на інші клієнтські пристрої, підключені до вашої інфраструктури IoT.
MQTT використовується в багатьох прикладах застосування та галузях промисловості. На сайті MQTT наведені зазначені нижче приклади впровадження.
HiveMQ: Програма для спільного використання автомобілів BMW покладається на надійність підключення, яку забезпечує HiveMQ.
EMQ, допомагає SAIC Volkswagen створити платформу IoV (Інтернет транспортних засобів).
Надійне підключення IoT забезпечує моніторинг автономних дронів Matternet у режимі реального часу.
MQTT використовується для моніторингу електростанцій турецької компанії Çelikler Holding.
Приклад застосування телеметрії IBM: моніторинг і контроль електроенергії в домі.
Приклад застосування телеметрії IBM: домашній моніторинг пацієнтів.
Система безпеки для розумного будинку eFon Technology довіряє рішенню MQTT компанії Bevywise.
EMQ допомагає стимулювати інновації IoT у нафтохімічній промисловості.
CASO Design створює пристрої для розумної кухні.
IoT розгорнуто в німецькій залізничній системі Deutsche Bahn AG.
32-річний розробник безпеки інформаційних систем Агентства національної безпеки Джарех Себастьян Далке отримав 22 роки в'язниці…
Українська компанія Flytech представила розвідувальний безпілотний літальний апарат ARES. Основні його переваги — недорога ціна…
MC.today разом з Асоціацією IT Ukraine і сервісом моніторингу та аналітики згадок у ЗМІ та…
Україна не буде примусово повертати чоловіків призовного віку з-за кордону. Про це повідомила у Брюсселі…
В Збройних Силах України з'явився жіночий підрозділ з БПЛА. І вже проводиться конкурсний відбір до…
GitHub анонсував Copilot Workspace, середовище розробки з використанням «агентів на базі Copilot». За задумкою, вони…