IoT-протоколы (MQTT, CoAP)

IoT-протоколы (MQTT, CoAP) — это два специализированных прикладных протокола, предназначенных для обмена данными между узлами Интернета вещей (IoT) с ограниченными вычислительными ресурсами и пропускной способностью сети. Оба протокола относятся к лёгковесным, однако реализуют различную модель взаимодействия:

  • MQTT (Message Queuing Telemetry Transport) — брокер-ориентированный протокол «публикация-подписка», работающий поверх TCP[1].
  • CoAP (Constrained Application Protocol) — REST-подобный протокол «запрос-ответ», использующий UDP и оптимизированный для минимального энергопотребления.
Общие сведения
IoT-протоколы MQTT и CoAP
англ. IoT protocols MQTT and CoAP
Область использования Интернет вещей, Компьютерные сети

Определения

  • MQTT — бинарный, чрезвычайно лёгковесный протокол обмена сообщениями по модели «издатель-подписчик». Устройства публикуют сообщения в «темы», а брокер доставляет их всем подписчикам. Ключевые характеристики:
    1. минимальный заголовок (2 байта) и низкие накладные расходы[2];
    2. три уровня качества обслуживания (QoS 0-2) для гарантии доставки[3];
    3. поддержка двустороннего обмена устройству-облако и облако-устройству;
    4. транспорт поверх TCP с возможностью шифрования (TLS).
  • CoAP — облегчённый веб-протокол прикладного уровня, ориентированный на constrained-устройства и беспроводные сети с высокой задержкой. Основные особенности:
    1. HTTP-подобная семантика (методы GET, POST, PUT, DELETE);
    2. использование UDP, что снижает энергопотребление и задержку;
    3. четыре типа сообщений (Confirmable, Non-confirmable, Acknowledgement, Reset) для управления надёжностью;
    4. поддержка DTLS для защиты трафика.
  • QoS (Quality of Service — «качество обслуживания») — технология управления сетевым трафиком, которая приоритизирует критически важные данные (голос, видео, онлайн-игры) при ограниченной пропускной способности канала.
  • Last Will and Testament (LWT, «Последняя воля и завещание») — не самостоятельный IoT-протокол, а функция (механизм) в протоколе MQTT, предназначенная для обработки ситуаций неожиданного отключения клиентов (устройств).
  • Confirmable (подтверждаемые сообщения) — это тип сообщений в протоколе CoAP (Constrained Application Protocol), обеспечивающий гарантированную доставку (аналог QoS 1/2 в MQTT).
  • Piggybacked — способ передачи данных, используемый в протоколах интернета вещей (IoT), в частности, CoAP (Constrained Application Protocol), для оптимизации.
  • Back-off — механизм управления сетевым трафиком, который используется протоколами для предотвращения перегрузки сети, когда множество устройств пытаются отправить данные одновременно.

Структурные элементы IoT-протоколов (MQTT, CoAP)

MQTT

Пакет MQTT

  • Фиксированный заголовок — содержит тип контрольного пакета (4 старших бита) и флаги (DUP, QoS, RETAIN), а также поле «Remaining Length».
  • Переменный заголовок — присутствует выборочно и зависит от типа пакета.
  • Полезная нагрузка — данные сообщения или служебные параметры[4].

Контрольные пакеты (15 типов):

  • CONNECT
  • CONNACK
  • PUBLISH
  • PUBACK
  • PUBREC
  • PUBREL
  • PUBCOMP
  • SUBSCRIBE
  • SUBACK
  • UNSUBSCRIBE
  • UNSUBACK
  • PINGREQ
  • PINGRESP
  • DISCONNECT
  • AUTH[5].

CoAP

Структура сообщения

  • Заголовок (4 байта): Version (2 бита), Type (2 бита), TKL (4 бита), Code (8 бит), Message ID (16 бит).
  • Token (0-8 байт) — связывает запрос и ответ.
  • Опции — последовательность TLV-полей в порядке возрастания номеров.
  • Маркер 0xFF (при наличии полезной нагрузки).
  • Полезная нагрузка — представление ресурса.

Типы сообщений:

  • Confirmable (CON).
  • Non-confirmable (NON).
  • Acknowledgement (ACK).
  • Reset (RST).
undefined

Этапы работы

Взаимодействие по протоколам MQTT и CoAP строится поэтапно, с учётом их архитектурных особенностей.

1. Этапы работы по MQTT

1.1. Установление соединения

Обмен пакетами CONNECT/CONNACK между клиентом и брокером. На этом этапе передаются параметры Keep Alive и аутентификации[3].

1.2. Подписка на темы

Клиент отправляет пакет SUBSCRIBE, указывая интересующие темы и желаемый уровень QoS. Брокер подтверждает подписку пакетом SUBACK.

1.3. Публикация сообщений

Клиент или другое устройство публикует сообщения в выбранные темы с помощью пакета PUBLISH. В зависимости от уровня QoS осуществляется подтверждение доставки:

  • PUBACK (QoS 1)
  • цепочка PUBREC → PUBREL → PUBCOMP (QoS 2)

1.4. Поддержание сеанса

Для поддержания активности соединения периодически обмениваются пакетами PINGREQ/PINGRESP.

1.5. Завершение соединения

Сеанс завершается отправкой пакета DISCONNECT от клиента или по инициативе брокера.

2. Этапы работы по CoAP

2.1. Формирование запроса

Клиент формирует и отправляет сообщение типа CON (Confirmable) или NON (Non-confirmable) к ресурсу, определённому URI.

2.2. Подтверждение получения

Получатель отвечает сообщением ACK (Acknowledgement) для подтверждения приёма или RST (Reset), если обработка невозможна.

2.3. Повторная передача сообщений

Для сообщений типа CON применяется механизм повторной передачи с экспоненциальным увеличением интервала (back-off) до 4 попыток, если не получено подтверждение.

2.4. Получение ответа

Ответ может быть вложен в ACK (piggybacked) или отправлен отдельным сообщением, если требуется дополнительная обработка.

2.5. Обнаружение ресурсов

Для поиска доступных ресурсов и узлов используется GET-запрос к `/.well-known/core` и, при необходимости, мультикаст-запросы.

Преимущества и недостатки

MQTT

Преимущества:

  • Минимальные сетевые накладные расходы и малый размер клиента[2].
  • Три уровня QoS и функция «Last Will» для надёжности[6].
  • Масштабируемость до тысяч и миллионов соединений благодаря брокерной архитектуре[7].

Недостатки:

  • Зависимость от центрального брокера — потенциальная точка отказа.
  • TCP-соединение требует больше ресурсов, чем UDP.
  • Шифрование реализуется внешним TLS-слоем, увеличивая энергопотребление.

CoAP

Преимущества:

  • Чрезвычайно лёгкий стек на базе UDP и быстрая «просыпаемость» устройств.
  • REST-подобная модель упрощает интеграцию с веб-службами.
  • Поддержка мультикаста для управления группами устройств.

Недостатки:

  • Потенциальные потери пакетов и необходимость ручного контроля надёжности.
  • Проблемы прохождения NAT и отсутствие встроенного сквозного шифрования без DTLS.
  • Меньшая распространённость и экосистемная поддержка по сравнению с MQTT.

Сферы применения

MQTT

  • Промышленная автоматизация и телеметрия оборудования.
  • Системы «умного дома» (освещение, климат-контроль).
  • Умные города — мониторинг трафика и окружающей среды.
  • Телемедицина и удалённое наблюдение пациентов.
  • Сельское хозяйство — управление орошением и сбор данных с датчиков.

CoAP

  • Беспроводные сенсорные сети с жёсткими ограничениями по энергии.
  • Устройства управления освещением и бытовыми приборами в жилых зданиях.
  • Массовое обновление прошивок микроконтроллеров (Block-Wise Transfer).
  • Мультикаст-управление уличными светильниками и счётчиками ресурсов.

Инструменты для использования в IoT-протоколах

MQTT

  • Брокеры — Eclipse Mosquitto, HiveMQ (Community Edition), EMQX, VerneMQ, RabbitMQ (MQTT плагин).
  • Клиентские библиотеки — Eclipse Paho (C/C++, Java, Python, JavaScript), MQTT.js.
  • Облачные сервисы — HiveMQ Cloud, AWS IoT Core, WQTT.ru.

CoAP

  • Библиотеки — libcoap (C), Eclipse Californium (Java), CoAPthon3 (Python), aiocoap (Python async).
  • Платформы — Eclipse Leshan (LwM2M/CoAP сервер), EMQX Edge с CoAP-гейтвеем, Zephyr RTOS (встроенная реализация).

Ограничения

MQTT

  • Зависимость от TCP/IP: Требует постоянного или частого соединения. В сетях с высокой потерей пакетов (например, LoRaWAN) постоянная переотправка TCP-пакетов быстро расходует энергию батареи.
  • Накладные расходы TCP: TCP создает большие накладные расходы на установление соединения, что неэффективно для передачи коротких, редких сообщений.
  • Централизованная архитектура: Необходимость использования центрального брокера делает его «единой точкой отказа» и ограничивает масштабируемость в децентрализованных системах (сравнение с CoAP/UDP, где возможна прямая связь).
  • Сложность реализации на очень ограниченных устройствах: Хотя существуют реализации MQTT-SN (для сенсорных сетей), стандартный MQTT требует больше памяти и вычислительных ресурсов, чем CoAP.
  • Сравнение с AMQP: В отличие от AMQP, который предлагает мощные инструменты маршрутизации и надежности (queuing, acknowledgments), MQTT проще, но менее гибкий в сложных корпоративных системах.

CoAP

  • Ненадежность UDP: Поскольку CoAP работает поверх UDP, он не гарантирует доставку сообщений (без использования механизма подтверждения Confirmable Messages). В потерях пакетов CoAP уступает MQTT в надежности.
  • Отсутствие встроенного Pub/Sub: CoAP — это протокол RESTful (как HTTP), он отлично подходит для взаимодействия "устройство-сервер", но сложнее реализует модель "один-ко-многим", чем MQTT.
  • Ограниченная безопасность: Базовая безопасность реализуется через DTLS (Datagram TLS), что может быть накладно для простейших датчиков.
  • Сравнение с LwM2M: CoAP обеспечивает транспорт, но сам по себе не имеет стандартизированных моделей данных для управления устройствами. LwM2M (основанный на CoAP) предоставляет этот функционал, делая его лучше для удаленного конфигурирования, чем чистый CoAP.

Примечания

  1. MQTT — The Standard for IoT Messaging. MQTT.org. Дата обращения: 20 июня 2025.
  2. 1 2 Introduction of MQTT. GeeksforGeeks. Дата обращения: 20 июня 2025.
  3. 1 2 What is MQTT? AWS. Дата обращения: 20 июня 2025.
  4. Understanding MQTT packet format. Bevywise. Дата обращения: 20 июня 2025.
  5. MQTT control packets. EMQX. Дата обращения: 20 июня 2025.
  6. MQTT protocol in IoT. Nabto. Дата обращения: 20 июня 2025.
  7. CoAP vs MQTT. Cloud.Studio. Дата обращения: 20 июня 2025.

Категории

© Правообладателем данного материала является АНО «Интернет-энциклопедия «РУВИКИ».
Использование данного материала на других сайтах возможно только с согласия АНО «Интернет-энциклопедия «РУВИКИ».