Контакты
Подписка
МЕНЮ
Контакты
Подписка

В рубрику "Решения корпоративного класса" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Протокол MQTT. Особенности, варианты применения, основные процедуры MQTT Protocol.Features, applications and basic procedures

Встатье рассматривается протокол MQTT (Message Queue Telemetry Transport) Интернета вещей , его особенности, варианты применения, характерные процедуры. Рассматривается принцип "издатель-подписчик". Проводится анализ информационных элементов и сообщений. Актуальность темы обусловлена стремительным развитием архитектуры "издатель-подписчик", для которой наиболее характерным является данный протокол.

This article discusses the MQTT (Message Queue Telemetry Transport) protocol of the Internet of things, overview protocol peculiar properties, possible applications. Messaging pattern which is called publish-subscriber are described. Contains an analysis of the information elements and messages. Actuality of the subject is due to the variety of existing protocols, Internet of Things standards and the lack of established terminology, describes the concept as a whole. Relevance of the topic is due to the rapid development of publish-subscriber architecture for which the most characteristic is the MQTT protocol.

Вадим
Гойхман
Доцент кафедры инфокоммуникационных систем, СПбГУТ им. проф. М.А. Бонч-Бруевича, к.т.н.
Vadim
GoikhmanSenior lecturer, The Bonch-Bruevich Saint-Petersburg State University of Telecommunication,s Ph.D.
Анастасия
Лаврова
Бакалавр кафедры инфокоммуникационных систем СПбГУТ им. проф. М.А. Бонч-Бруевича
Anastasiia
LavrovaBachelor the Bonch-Bruevich Saint-Petersburg State University of Telecommunications
Ключевые слова:
Интернет вещей, IoT, MQTT, издатель-подписчик, брокер
Keywords:
IoT, MQTT subscriber-publisher, broker

Введение

Протокол MQTT – Message Queuing Telemetry Transport – протокол для передачи последовательности сообщений с телеметрическими данными, то есть информации от датчиков температуры, влажности, освещенности и др.

MQTT был предложен в 1999 г. Энди Стандфордом-Кларком в качестве протокола, который бы служил для передачи данных о состоянии нефтепровода и газопровода в реальном времени. Разработка велась компанией IBM для нового трубопровода крупнейшей американской нефтяной компании ConocoPhillips. В рамках создания диспетчерской системы управления и сбора данных (SCADA) необходимо было обеспечить гарантированный сбор самой различной информации: состояние насосов, температура подшипников, скорость потоков, состояние клапанов, уровни в баках и т.д. При этом необходимо было учесть дороговизну каналов связи и узкую полосу пропускания. Ни один из существующих протоколов не подходил под эти задачи, таким образом, сформировались требования к новому протоколу: качество обслуживания, двусторонняя связь, эффективное использование полосы пропускания [2].

Впервые протокол MQTT был опубликован консорциумом OASIS (Organization for the Advancement of Structured Information Standards) в октябре 2014 г. Данный стандарт находится в открытом доступе [3].

В июне 2016 г. стандарт был признан Международной организацией по стандартизации (ISO). MQTT Version 3.1.1 был зарегистрирован техническим комитетом по информационным технологиям ISO (JTC1) под номером ISO/IEC 20922 [4].

Основные черты протокола MQTT:

  • обмен сообщениями происходит по принципу "издатель-подписчик" (Pub-Sub);
  • размер заголовка сообщения составляет 2 байта, а полезная нагрузка может варьироваться от 1 байта до 260 Мбайт;
  • в протоколе заложена возможность выбора одного из трех уровней обслуживания.

Принцип "издатель-подписчик"

Отличительной особенностью принципа "издатель-подписчик" от клиент-серверного подхода является то, что клиенты, посылающие сообщения (издатели, Publisher), и клиенты, принимающие сообщения (подписчики, Subscriber), как правило, разделены. Разделение может быть организовано в трех плоскостях:

  • пространство – издатель и подписчик не обязаны знать друг друга;
  • время – издатель и подписчик не должны быть включены в одно и то же время;
  • синхронизация – операции на обеих сторонах не должны приостанавливаться в течение публикации или получения информации.

Издатель и подписчик не передают друг другу сообщения напрямую, не устанавливают прямой контакт, могут не знать о существовании друг друга. Координирует и управляет передачей сообщений от издателя к подписчику и от подписчика к издателю брокер (Broker). Распараллеливание операций на брокере является второй важной особенностью принципа взаимодействия "издатель-подписчик".

MQTT-клиент – это устройство, оснащенное микроконтроллером, поддерживающим стек TCP/IP. Клиентские библиотеки MQTT доступны для большого числа языков программирования, например Android, Arduino, C, C++, C#, Go, iOS, Java, JavaScript, NET [5].

Брокер является основным элементом системы "издатель-подписчик". Он отвечает за прием всех сообщений, их фильтрацию, принятие решения о том, кому интересны эти сообщения, и, в конечном итоге, за пересылку сообщений всем клиентам-подписчикам.

Среди серверных реализаций брокера можно выделить IBM WebSphere MQ [6]; открытое ПО Mosquitto[7]; решение, основанное на облачном сервисе Eurotech Everywhere Device Cloud [8]; легко масштабируемый и высокопроизводительный открытый сервер emqttd, последняя версия (0,17) позволяет обслуживать 1,3 миллиона соединений [9]; брокер HiveMQ [10], обеспечивающий корпоративную безопасность и максимальную масштабируемость.

Упрощенный процесс обмена информацией можно описать следующим образом:

  1. Издатель передает сообщение с данными (например, информация с датчиков температуры) на брокер, указывая при этом тему (Topic), к которой эти данные относятся (например, "Temp").
  2. Брокер анализирует, какие из подписчиков имеют подписку на определенные темы, в данном случае – на тему "Temp".
  3. Подписчикам, которые подписаны на тему "Temp", брокером будет отправлено сообщение с информацией от датчиков температуры.


Таким образом, множество подписчиков может быть подписано на разнообразные темы и в зависимости от этих подписок получать необходимую им информацию, не общаясь с издателем напрямую. На рис. 1 изображена схема передачи информации по принципу "издатель-подписчик".

Формат сообщений протокола MQTT

На рис. 2 представлен общий формат сообщений прокола MQTT. Сообщение состоит из двух заголовков:

  • заголовок фиксированной длины;
  • заголовок переменной длины (в зависимости от типа сообщения);
  • поля полезной нагрузки переменной длины.


В данной статье приведено подробное описание заголовка фиксированной длины, так как ключевые особенности протокола MQTT реализуются именно с помощью полей этого заголовка. Первый байт заголовка включает четыре поля, три из которых являются специальными флагами (DUP, QoS Level, RETAIN), четвертое указывает тип сообщения. Второй байт служит для указания оставшейся длины сообщения, которая складывается из размера заголовка переменной длины (если он есть) и размера полезной нагрузки.

Тип сообщения. Значение этого поля определяет тип сообщения. В табл. 1 приведены типы сообщений, их числовые значения, направления передачи и краткое описание.


Специальный флаг DUP. DUPlicate – дублирование сообщения. Этот флаг указывает получателю, что полученное им сообщение передается повторно и, возможно, уже было получено им ранее. Этот флаг играет важную роль при передаче информации по ненадежным каналам, где возможна потеря сигнала.

Специальный флаг QoS. Как отмечалось выше, основной отличительной чертой протокола MQTT является возможность использования различных уровней обслуживания, которые задаются значением данного флага. Это делает протокол MQTT более гибким, в отличие от протокола CoAP (Constrained Application Protocol), сообщения которого могут подтверждаться или обрабатываться без подтверждения.

QoS 0: At most once – не более одного. Издатель публикует сообщение (PUBLISH) на брокере, а брокер публикует его для подписчика. Однако издатель не требует, чтобы это сообщение было гарантированно передано подписчику. Иными словами, подписчик может и не получить это сообщение, но это не отслеживается издателем. Описанный сценарий (см. рис. 3) используется для тех случаев, когда потери данных не критичны. Например, при постоянном мониторинге температуры, когда потеря единичного измерения не играет существенной роли в общей картине.


QoS 1: At least once – хотя бы один. Издатель публикует сообщение на брокере (PUBLISH). Брокер сохраняет это сообщение и публикует его для подписчика. Только после того, как сообщение будет опубликовано для подписчика, брокер отсылает подтверждение публикации издателю (PUBACK). Сценарий такого взаимодействия приведен на рис. 4. То есть до тех пор, пока издатель не получит подтверждение публикации подписчику, данная публикация будет посылаться брокеру и далее подписчику. Таким образом, подписчик должен получить данное сообщение как минимум один раз.


QoS 2: Exactly one – гарантированно один. Уровень QoS обеспечивает высшую гарантию доставки сообщений за счет использования дополнительных процедур подтверждения и завершения публикации (PUBREC, PUBREL, PUBCOMP). Сценарий представлен на рис. 5 и применим для ситуаций, когда нужно исключить любые потери и дублирование данных от датчиков. Например, когда от полученного сообщения срабатывает сигнализация, вызов экстренных служб.


Специальный флаг RETAIN. Данный флаг служит для индикации сохранения последнего принятого брокером сообщения. То есть флаг RETAIN=1 в сообщении PUBLISH от издателя сообщает брокеру о том, что сообщение по этой теме нужно сохранить и, когда новый подписчик присоединится к теме, отправить ему это сообщение.


На рис. 6 приведен сценарий, описанный выше.

Принцип работы

Рассмотрим более детально процесс установления соединения, посылки и приема сообщений (см. рис. 7).


Установление соединения начинается с передачи от клиента брокеру сообщения CONNECT, в котором указываются:

  • ClientId – уникальный идентификатор для каждого клиента, подключающегося к брокеру;
  • CleanSession – флаг удаления сохраненных сообщений из предыдущих сессий для данного клиента;
  • Username/Password – имя пользователя и пароль для идентификации и авторизации клиента;
  • KeepAlive – временной интервал, регулирующий передачу ping-запро-сов и ping-ответов для контроля отключения одной из сторон.

Брокер в ответ посылает клиенту сообщение CONACK, состоящее из:

  • Session Present Flag – указывает существуют ли для данного клиента действующие сессии от предыдущих подключений;
  • Connect Аcknowledge Flag – сообщает клиенту об успешном подключении или о каких-либо ошибках.

После того, как клиент MQTT подключен к брокеру, он может публиковать сообщения. Публикация происходит путем отправки брокеру от клиента сообщения PUBLISH, где указываются:

  • Topic Name – название темы, к которой относится данное сообщение. Данное поле является обязательным, так как MQTT-брокер принимает решение о пересылке того или иного сообщения клиенту, исходя из тем, на которые клиент подписан;
  • специальные флаги – QoS, DUP и RETAIN;
  • полезная нагрузка, где передаются сами данные.

Таким образом, после получения сообщения PUBLISH брокер отправляет подтверждение приема публикации (если это задано QoS) и пересылает полученное сообщение всем клиентам, которые подписаны на данную тему.

Чтобы получать сообщения с необходимыми данными, MQTT-клиент должен сначала подписаться на их получение с помощью сообщения SUBSCRIBE. Данное сообщение состоит из двух частей:

  • Packet Identifier – необходимо для QoS 1 и QoS 2;
  • List of Subscriptions – названия тем, на которые клиент хочет подписаться, и необходимое значение QoS.

Стоит отметить, что в протоколе MQTT принята иерархическая структура построения тем, поэтому для удобства применяются т.н. wildcard-символы, благодаря которым подписчик может подписаться на все подтемы данной темы (символ #) либо темы определенного уровня (символ +).

В ответ на сообщение SUBSCRIBE брокер отправляет клиенту подтверждение SUBACK, в котором сообщает о результате подписки (успешная или нет).

Также клиент может отписаться от темы, которая больше не представляет для него интереса, отправив брокеру сообщение UNSUBSCRIBE, в котором будет указана данная тема.

Брокер подтверждает отказ от информации по этой теме сообщением UNSUBACK.

Проиллюстрируем работу протокола. В качестве примера рассмотрим спортивные приложения, устанавливаемые на смартфон. Практически все эти приложения, помимо сбора статистических данных, также позволяют динамически отслеживать местоположение спортсмена. Эта функция особенно востребована на массовых спортивных мероприятиях, таких как марафон, дистанции триатлона или велосипедные соревнования.

Для реализации такой функции необходимы как минимум три типа клиентов и один брокер, обслуживающий этих клиентов с использованием протокола MQTT.

Клиенты:

  • Устройство с GPS/ГЛОНАСС. В его роли может выступать смартфон с установленным приложением, публикующим на брокер в определенную тему информацию о местоположении бегуна;
  • Приложение для анализа данных (Analytics App). Подписавшись на спортсменов (соответствующие им темы), получая информацию об их местоположении, приложение анализирует эту информацию и публикует в различные темы сообщения о текущих данных (сколько километров пробежал спортсмен и за какое время, направление движения);
  • Приложение мониторинга. Данное приложение будет взаимодействовать с картами, брокером и в режиме реального времени отображать на экране компьютера (Web-интерфейс) или смартфона местоположение спортсменов, а также информацию о текущих результатах забега.

На рис. 8 изображена упрощенная схема обмена сообщениями протокола MQTT между участниками с указанием тем. На ней бегун (издатель) с установленным приложением навигации публикует на брокер информацию о своем текущем местоположении ("марафон/спортсмены/имя/GPS").


Аналитическое приложение, которое подписано на темы с местоположением конкретного бегуна и остальных участников с помощью рассмотренных выше wildcard-символов ("марафон/спортсмены/+/GPS"), использует эти данные для анализа времени, скорости, пройденного расстояния, а проанализированные данные публикует в соответствующие темы на брокере ("мара-фон/спортсмены/имя/дистанция_вре мя"). Болельщик может таким образом узнать точное местоположение бегуна и время прибытия в ту или иную точку с помощью приложения мониторинга, которое подписано на темы с местоположением, уже проанализированными данными ("марафон/спортсмены/#") и в виде графического интерфейса представляет эту информацию пользователю.

Заключение

Минимальный объем служебной информации, наличие классов обслуживания и иерархическая структура тем являются неоспоримыми достоинствами протокола MQTT, что подтверждается большим разнообразием как клиентского, так и серверного ПО, в том числе открытого ПО. В то же время архитектура "издатель-подписчик" выдвигает требования к новому сетевому объекту – брокеру, который по сути своей обеспечивает маршрутизацию пользовательской информации. Таким образом, мы наблюдаем сдвиг парадигмы от маршрутизации на транспортном уровне к маршрутизации на прикладном.

Литература

  1. В. Гойхман. А. Савельева. Аналитический обзор протоколов Интернета вещей // Технологии и средства связи. – 2016. – № 4. С. 32–37.
  2. IBM Podcast: Piper, Diaz, Nipper – MQTT. [online]. Доступ через: http://www.ibm.com/podcasts/software/ websphere/connectivity/piper_diaz_nipper_mq_tt_1118201 1.pdf.
  3. OASIS Standard – MQTT Version 3.1.1.
  4. ISO/IEC 20922:2016 Information technology – Message Queuing Telemetry Transport (MQTT) v3.1.1.
  5. Web-хостинг GitHub, раздел MQTT – libraries. [online]. Доступ через: https://github.com/mqtt/mqtt.github.io/wiki/libraries.
  6. IBM WebSphere MQ. [online]. Доступ через: http://www-03.ibm.com/software/products/ru/websphere-mq.
  7. An Open Source MQTT v3.1/v3.1.1 Broker. [online]. Доступ через: https://mosquitto.org.
  8. Everywhere Device Cloud [online]. Доступ через: http://www.eurotech.com/en/products/software+services/everyware+device+cloud.
  9. EMQ – The Massively Scalable MQTT Broker for IoT and Mobile Applications. [online]. Доступ через: http://emqtt.io.
  10. HiveMQ – Enterprise MQTT Broker. [online]. Доступ через: http://www.hivemq.com.

Опубликовано: Журнал "Технологии и средства связи" #5, 2016
Посещений: 47857

  Автор

Вадим Гойхман

Вадим Гойхман

К.т.н., доцент кафедры инфокоммуникационных систем, СПбГУТ им. проф. М.А. Бонч-Бруевича

Всего статей:  3

  Автор

Анастасия Лаврова

Анастасия Лаврова

Бакалавр кафедры инфокоммуникационных систем СПбГУТ им. проф. М.А. Бонч-Бруевича

Всего статей:  1

В рубрику "Решения корпоративного класса" | К списку рубрик  |  К списку авторов  |  К списку публикаций