Протокол mqtt что это
Протокол MQTT. Особенности, варианты применения, основные процедуры MQTT Protocol. Features, applications and basic procedures
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.
Введение
Протокол 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:
Принцип «издатель-подписчик»
Отличительной особенностью принципа «издатель-подписчик» от клиент-серверного подхода является то, что клиенты, посылающие сообщения (издатели, 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 изображена схема передачи информации по принципу «издатель-подписчик».
Формат сообщений протокола 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, в котором указываются:
Брокер в ответ посылает клиенту сообщение CONACK, состоящее из:
После того, как клиент MQTT подключен к брокеру, он может публиковать сообщения. Публикация происходит путем отправки брокеру от клиента сообщения PUBLISH, где указываются:
Таким образом, после получения сообщения PUBLISH брокер отправляет подтверждение приема публикации (если это задано QoS) и пересылает полученное сообщение всем клиентам, которые подписаны на данную тему.
Чтобы получать сообщения с необходимыми данными, MQTT-клиент должен сначала подписаться на их получение с помощью сообщения SUBSCRIBE. Данное сообщение состоит из двух частей:
Стоит отметить, что в протоколе MQTT принята иерархическая структура построения тем, поэтому для удобства применяются т.н. wildcard-символы, благодаря которым подписчик может подписаться на все подтемы данной темы (символ #) либо темы определенного уровня (символ +).
В ответ на сообщение SUBSCRIBE брокер отправляет клиенту подтверждение SUBACK, в котором сообщает о результате подписки (успешная или нет).
Также клиент может отписаться от темы, которая больше не представляет для него интереса, отправив брокеру сообщение UNSUBSCRIBE, в котором будет указана данная тема.
Брокер подтверждает отказ от информации по этой теме сообщением UNSUBACK.
Проиллюстрируем работу протокола. В качестве примера рассмотрим спортивные приложения, устанавливаемые на смартфон. Практически все эти приложения, помимо сбора статистических данных, также позволяют динамически отслеживать местоположение спортсмена. Эта функция особенно востребована на массовых спортивных мероприятиях, таких как марафон, дистанции триатлона или велосипедные соревнования.
Для реализации такой функции необходимы как минимум три типа клиентов и один брокер, обслуживающий этих клиентов с использованием протокола MQTT.
На рис. 8 изображена упрощенная схема обмена сообщениями протокола MQTT между участниками с указанием тем. На ней бегун (издатель) с установленным приложением навигации публикует на брокер информацию о своем текущем местоположении («марафон/спортсмены/имя/GPS»).
Аналитическое приложение, которое подписано на темы с местоположением конкретного бегуна и остальных участников с помощью рассмотренных выше wildcard-символов («марафон/спортсмены/+/GPS»), использует эти данные для анализа времени, скорости, пройденного расстояния, а проанализированные данные публикует в соответствующие темы на брокере («мара-фон/спортсмены/имя/дистанция_вре мя»). Болельщик может таким образом узнать точное местоположение бегуна и время прибытия в ту или иную точку с помощью приложения мониторинга, которое подписано на темы с местоположением, уже проанализированными данными («марафон/спортсмены/#») и в виде графического интерфейса представляет эту информацию пользователю.
Заключение
Минимальный объем служебной информации, наличие классов обслуживания и иерархическая структура тем являются неоспоримыми достоинствами протокола MQTT, что подтверждается большим разнообразием как клиентского, так и серверного ПО, в том числе открытого ПО. В то же время архитектура «издатель-подписчик» выдвигает требования к новому сетевому объекту – брокеру, который по сути своей обеспечивает маршрутизацию пользовательской информации. Таким образом, мы наблюдаем сдвиг парадигмы от маршрутизации на транспортном уровне к маршрутизации на прикладном.
В последнее время мне пришлось долго и муторно разбираться с протоколом MQTT (Mosquitto) и с тем, как его можно использовать с домашней автоматизацией. Поэтому пришлось разбираться с тем, как оно работает и зачем нужны все эти настройки.
Немного теории
Основные термины и понятия используемые в данном протоколе:
Разберем каждый термин по отдельности
Message
Сообщения (message) содержат в себе информацию, которую один участник сети на базе протокола MQTT хочет передать другим. Взаимодействие между участниками сети осуществляется через Брокера. То есть, если мне, как устройству, нужно передать сообщение о том что я что-то сделал или сообщить о том, как у меня дела, я передаю сообщение брокеру публикуя во всеуслышание что «я что-то сделал» или «как у меня дела».
Publish
Это процесс передачи сообщения брокеру.
То есть простым языком, я подошел к брокеру и сказал «мама я покакал». Брокер гипотетически должен услышать это сообщение и записать его к себе в блокнотик. Почему гипотетически? Потому что есть особенности протокола, которые мы разберем чуть ниже. Пока берем за данность, что я сказал что-то брокеру используя механизм Publish и он это услышал и записал.
Subscribe
Так как всеми сообщениями от всех устройств владеет исключительно брокер, то нам жеж нужно как то получить эти сообщения. Для этого мы подписываемся на рассылку от брокера для получения проходящих через него сообщений. Чтобы читать какие-то конкретные сообщения, нам необходимо определить на какую тему мы хотим получать эти сообщения, и для этого как раз используется механизм Topic
Topic
Это как раз таки Тема, по поводу которой мы хотим получать или как ни странно отправлять сообщения.
То есть формат общения между участниками выглядит примерно так.
Я как участник хочу сказать всем «мама я покакала»
для этого я создаю топик любого содержания, например: мое_тело/задница/
и сообщаю в этот топик сообщение «мама я покакала»
Брокер получит это сообщение, и передаст всем, кто подписался на тему (топик) мое_тело/задница/
То есть это такая вот упрощенная система смс рассылок с определенными темами.
Формат топика может быть разным и абсолютно любым. В принципе мы можем создать любой топик, и в него передавать сообщения любого содержания. Главное чтобы получатель был подписан на этот топик и знал что делать с информацией полученной из сообщений.
Что касается особенностей топиков, то их не так чтобы много.
Во первых они чувствительны к регистру. То есть топик «мое_тело/задница» и топик «Мое_Тело/Задница» это два разных топика.
Во вторых, топики не создаются не сервере администратором. Они создаются публикаторами и подписчиками которые на них подписаны. Брокер только занимается передачей сообщений и служебной информации.
Они позволяют выстраивать иерархию. Ну например:
У нас есть в гостиной и в спальне по два выключателя и один в гараже. Для этого мы формируем на выключателях в топики в виде:
Затем, что есть служебные топики, которые позволяют подписаться на группы топиков или сообщений.
Например если мы хотим читать вообще все сообщения мы подписываемся на топик #
Если мы хотим видеть то, что происходит в доме, то мы подписываемся на топик home/# и будем получать сообщения в топиках:
Но не будем видеть то что происходит в топике:
Если мы хотим видеть то, что происходит в гостиной, мы подписываемся на топик home/livingroom/# и будем получать сообщения только из топиков
В общем я думаю понятно что и как происходит с этими топиками.
Служебные сообщения
В качестве служебных сообщений используются в основном два типа сообщений
Last Will and Testament (LWT) которое сообщает что после этого сообщения считать меня мертвым.
Ну плюс еще используется Keep Alive сообщения, которые сообщают брокеру что «я все еще живой» и стандартно посылаются каждые 60 секунд. Если брокер не получил это сообщение от клиента, то он принудительно пингует его чтобы выяснить живой ли тот, и если выясняется что он неживой, то брокер публикует за клиента LWT сообщение, чтобы все узнали что тот скончался.
Соответственно получение брокером Birth Message от устройства, переводит устройство в понимании брокера в режим ONLINE, а после того как брокер получает от устройства LWT сообщение или когда сам принимает решения что тот скончался проверив устройство на доступность, то переводит статус устройства в режим OFFLINE.
QoS в принципе расшифровывается как Quality Of Service, то есть качество предоставляемой услуги. В разрезе MQTT оно имеет три значения 0,1 и 2
Если по простому, то эти варианты означают по факту определение того, надо ли нам как публикующему свое сообщение устройству, быть уверенным что оно получено.
QoS=0 означает что мы один раз публикуем сообщение «мама я покакала» и нам пофиг услышали нас или нет
QoS=1 означает что мы будем публиковать сообщение «мама я покакала» до посинения, до тех пор пока нам не скажут что нас услышали и можно заткнуться уже.
QoS=2 означает что мы один раз сказали «мама я покакала», получили от мамы подтверждение того что она нас услышала, сообщили маме что мы узнали о том что мама нас улышала, а мама подтвердила, что она поняла что мы узнали о том что она услышала :))))))
Я думаю первая буква М в протоколе, имеет отсылку в адрес Майкрософта, который по стопицот раз переспрашивает «действительно ли вы уверены что хотите закрыть это приложения?» :)))))))
Вот в общем то и все.
Retain
Этот параметр имеет всего два значения вкл и выкл. Означает он очень простой механизм.
Если у нас режим выключен, то когда я сообщаю всему миру «мама я покакала», то его слышат все кто подписан сейчас на топик в который я это сообщил. Но вновь подключившийся подписчик на наш веселый топик «мое_тело/задница» не узнает о том что все уже случилось и так и умрет в неведении наверное.
Если же мы включаем режим Retain, то брокер берет на себя обязательство, после того как мы сообщили миру об акте дефекации, сообщать каждому вновь подписавшемуся на этот топик сей удивительный и жизненно необходимый факт.
Роль протокола MQTT в развитии промышленного интернета вещей
У нас часто проходят мероприятия, на которые мы приглашаем экспертов промышленной автоматизации. В 2016 году к нам приезжал Арлен Ниппер, который является одним создателей протокола MQTT. Хотим поделиться его докладом в русском переводе.
И такие же системы SCADA, системы автоматизации производства, системы контроля и управления производством становятся элементом IIoT-инфраструктуры.
Для чего нужна IIoT-инфраструктура? Пользователи стремятся получать все больше возможностей, тратя меньше ресурсов. Этого невозможно добиться без получения и использования производственных данных нижнего уровня.
Сначала везде внедрялись информационные технологии. Потом появилось «облака» и у всех появился доступ к Интернету. Теперь осталось только использовать «облако» для систем SCADA.
Поэтому мы занялись переписыванием старых протоколов с закрытым исходным кодом. Так на рынке появились Modbus, Allen-Bradley, DNP 3.0. А потом случилось дерегулирование деятельности телекоммуникационных компаний, в том числе AT&T. До этого системы управления производственными процессами, системы SCADA и т. д. работали на отличных условиях: AT&T получала большие субсидии и была готова тянуть свои телефонные линии куда бы мы ни пожелали. После дерегулирования цены взлетели, а качество рухнуло.
Мы стали использовать системы VSAT, но они работали медленно, с большой задержкой сигнала, а постоянный опрос устройств обходился очень дорого.
В результате совместного проекта Phillips 66 и IBM, в котором я принял участие 19 лет назад, появился сетевой протокол MQTT (MQ telemetry transport), который используется уже почти 20 лет. В далеком 1999 г. мы понятия не имели об Интернете вещей или «облаке», а просто искали пути решения проблемы. Но нам удалось создать протокол для критически важных систем контроля состояния трубопроводов в режиме реального времени. Сегодня протокол MQTT — один из самых используемых прикладных протоколов.
Собственно Интернет вещей задумывался как обычный Интернет людей, объединяющий пользователей через веб-браузеры, HTTP и т. д., но который должен был объединять «вещи». Потом мы создали Промышленный Интернет вещей для систем управления производством, не имеющий ничего общего с возможностью корректировать температуру термостата через телефон.
Чтобы заставить Промышленный Интернет вещей работать, необходимо:
1. «Отвязать» устройства от приложений и связать с инфраструктурой.
Допустим, я установил прекрасный компьютер Advantech UNO, разработал для него отличное приложение, к которому привязал компьютер через протокол. Это означает, что я жестко увязал возможности компьютера с возможностями приложения.
И даже если я нашел для какой-либо проблемы решение, завтра оно может не сработать. Например, чтобы воспользоваться намного большим объемом данных, мне придется менять код.
Именно поэтому устройства нужно привязывать не к приложению, а к инфраструктуре, а затем встраивать в нее приложения. В таком случае нас не будут ограничивать возможности приложений.
2. Создать более совершенное решение на уровне операционных технологий (ОТ), чем существующее.
Девятнадцать лет в IBM я разрабатывал эту технологию, но все попытки внедрения были неудачными, потому что мы пытались спускать IIoT-технологию от ИТ до производства.
Но IIoT-решение должно обеспечивать получение данных от «вещей» и оптимизацию на операционном уровне вне зависимости от того, для какого предприятия создается IIoT, — завода, фармацевтической компании, системы водоснабжения и водоотведения или нефтегазовых компаний. И сейчас в B & B я пытаюсь создать эффективное ОТ-решение, потому что Интернет вещей можно создать только снизу вверх.
Согласно исследованию 2016 года, MQTT — самый используемый протокол в Интернете вещей (HTTP занимает первое место, но не обеспечивает контроль в режиме реального времени, и мы его не учитываем).
На рынке предлагается множество серверов, поддерживающих протокол MQTT. 
MQTT Servers
При этом количество клиентских MQTT-технологий ограничено. 
MQTT Clients
Но в IIoT-решениях нужно применять технологии, известные вчерашним студентам инженерных и ИТ-специальностей. Так, выпускники по компьютерным специальностям, например, 2016 года, скорее всего, пользуются одноплатным Raspberry Pi, поддерживающим протокол MQTT, чтобы включать и выключать свет в комнате. При этом они могут не знать, что такое OPC UA, протоколы Modbus, Allen-Bradley или DMP 3.0. Открытость и доступность таких технологий приведет к появлению большого количества SRP-решений.
Точной инструкции по применению MQTT в критически важных системах управления производством в режиме реального времени не существует. Но мы разработали спецификацию Sparkplug MQTT, определяющую некоторые базовые правила для создания систем управления производством в режиме реального времени с использованием протокола MQTT:
Итак, мы должны «отвязать» устройства от приложений и предложить более совершенное ОТ-решение.
Мы стремимся обеспечить взаимодействие продуктов Advantech с «вещами» в IoT:
Наша MQTT-инфраструктура включает устройства, отслеживающие физические события и публикующие данные о таких событиях на защищенных брокерах сообщений. Линейка продуктов Advantech позволяет не только создавать Интернет вещей, но и использовать маршрутизаторы SmartFlex и eWorks, которые публикуют данные и предоставляют интерфейс для их мониторинга.
После того, как мы «отвязали» устройства от приложений, можно встроить в инфраструктуру устройства и модули доступа в Интернет и подписать их на данные, публикуемые в режиме реального времени через протокол MQTT. На этом этапе необходимо продемонстрировать пользователю, руководителю производства или менеджеру SCADA, что наше ОТ-решение лучше, быстрее, безопаснее и легче масштабируется, чем обычные системы SCADA.
Раньше несколько систем SCADA нельзя было подписать на один и тот же топик. Но если системы не привязаны к приложению, нам даже не придется определять, какая система SCADA должна получать информацию в первую или вторую очередь — все системы, программы и устройства могут иметь доступ к одним и тем же производственным данным в режиме реального времени.
И на этом этапе можно выбирать другие интересные решения и встраивать их в инфраструктуру, например, приложения для управления активами, оптимизации проектно-технических работ и т. д. 
Advantech Unique Energy/Environment Solution Topology
Налаженный поток данных позволяет приступить к созданию собственно Промышленного Интернета вещей, с которым мы уже знакомы, включая большие данные, облачные вычисления и т. д. Можно использовать Microsoft Azure, IBM Bluemix или AWS IoT, а также всем известные Hadoop и Big Data, Storm и Spark и различные инструменты визуализации и аналитики. Но оказаться на этом уровне невозможно, если устройства связаны с приложениями и не встроены в необходимую инфраструктуру.