Для чего используется символ в протоколе 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: концептуальное погружение

Протокол Message Queuing Telemetry Transport (MQTT) используется в течение многих лет, но сейчас он особенно актуален благодаря взрывному росту IoT: и потребительские, и промышленные устройства внедряют распределённые сети и граничные вычисления (edge computing), а устройства с постоянной трансляцией данных становятся частью повседневной жизни.

Это означает, что лёгкие, открытые и доступные протоколы со временем станут ещё важнее. В этой статье приводится концептуальное погружение в MQTT: как он работает, как используется сейчас и как будет использоваться в будущем.

Небольшое вступление

MQTT — это протокол обмена сообщениями по шаблону издатель-подписчик (pub/sub). Первоначальную версию в 1999 году опубликовали Энди Стэнфорд-Кларк из IBM и Арлен Ниппер из Cirrus Link. Они рассматривали MQTT как способ поддержания связи между машинами в сетях с ограниченной пропускной способностью или непредсказуемой связью. Одним из первых вариантов его использования было обеспечение контакта фрагментов нефтепровода друг с другом и с центральными звеньями через спутники.

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

Таким образом, MQTT стал протоколом для потоковой передачи данных между устройствами с ограниченной мощностью CPU и/или временем автономной работы, а также для сетей с дорогой или низкой пропускной способностью, непредсказуемой стабильностью или высокой задержкой. Именно поэтому MQTT известен как идеальный транспорт для IoT. Он построен на протоколе TCP/IP, но есть ответвление MQTT-SN для работы по Bluetooth, UDP, ZigBee и в других сетях IoT, отличных от TCP/IP.

MQTT — не единственный в своём роде протокол обмена сообщениями pub/sub в реальном времени, но он уже получил широкое распространение в различных средах, которые зависят от межмашинной связи. Среди его сверстников — Web Application Messaging Protocol, Streaming Text-Oriented Messaging Protocol и Alternative Message Queueing Protocol.

MQTT — логичный выбор для разработчиков, которые хотят создавать приложения с надёжной функциональностью и широкой совместимостью с подключёнными к интернету устройствами и приложениями, включая браузеры, смартфоны и устройства IoT.

Как работает MQTT: основы

Система связи, построенная на MQTT, состоит из сервера-издателя, сервера-брокера и одного или нескольких клиентов. Издатель не требует каких-либо настроек по количеству или расположению подписчиков, получающих сообщения. Кроме того, подписчикам не требуется настройка на конкретного издателя. В системе может быть несколько брокеров, распространяющих сообщения.

MQTT предоставляет способ создания иерархии каналов связи — своего рода ветвь с листьями. Всякий раз, когда у издателя есть новые данные для распространения среди клиентов, сообщение сопровождается примечанием контроля доставки. Клиенты более высокого уровня могут получать каждое сообщение, в то время как клиенты более низкого уровня могут получать сообщения, относящиеся только к одному или двум базовым каналам, «ответвляющимся» в нижней части иерархии. Это облегчает обмен информацией размером от двух байт до 256 мегабайт.

Пример того, как можно настроить клиент для подключения через брокера MQTT:

Любые данные, опубликованные или полученные брокером MQTT, будут закодированы в двоичном формате, поскольку MQTT является бинарным протоколом. Это означает, что для получения исходного содержимого нужно интерпретировать сообщение. Вот как это выглядит с помощью Ably и JavaScript:

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

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

Кроме того, в MQTT можно использовать аутентификацию Ably на токенах, если вы вообще не хотите раскрывать свой ключ API фактическому клиенту MQTT (в случае MQTT без SSL токены обязательны, чтобы предотвратить передачу ключей API открытым текстом). Пример аутентификации через токены:

Функциональность MQTT: более глубокое погружение

Согласно IBM, MQTT обладает следующими свойствами:

Одной из отличительных характеристик MQTT является уникальное понимание каналов: каждый из них обрабатывается как путь к файлу, например:

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

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

Посмотрите на два компонента, из которых состоит каждое сообщение по протоколу MQTT:

Где можно использовать MQTT?

Поскольку приложения IoT ныне внедряются в огромных масштабах, MQTT попал в центр внимания как открытый, простой и масштабируемый способ развёртывания распределённых вычислений и функциональности IoT для более широкой пользовательской базы — как на потребительском, так и на промышленном рынках.

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

Когда не нужно использовать MQTT?

У разработчиков есть богатый выбор протоколов для проектирования и развёртывания двунаправленных каналов связи IoT, включая MQTT, HTTP, CoAP, WebSockets (если позволяет CPU/батарея) и другие. Является ли MQTT лучшим выбором, зависит от оборудования и задачи приложения.

Разработанный для сред с чрезвычайно низкой пропускной способностью, протокол MQTT может быть довольно негибким в своём стремлении сохранить каждый байт. Например, спецификация определяет всего пять сообщений об ошибке, с помощью которых сервер может отклонить соединение (например, неверное имя пользователя/пароль или неприемлемая версия протокола). Если сервер хочет указать на какую-то иную ошибку, ему не повезло. Хуже того, если ошибка возникает после запуска соединения, нет никакого механизма для сообщения об ошибке вообще. Сервер может только пожать плечами и резко прервать TCP-соединение, оставив клиента без понятия, почему его сбросили (и без какого-либо способа отличить преднамеренное отключение от временной сетевой проблемы). Для людей, привыкших к более гибким и простым в отладке (хотя и менее экономичным по пропускной способности) протоколам pub/sub, такой спартанский подход может показаться немного примитивным.

MQTT часто упоминается вместе с HTTP, поэтому компания Google провела исследование, сравнив их по времени отклика, объёму трафика и другим важным для разработчиков атрибутам. MQTT занял первое место в тестах Google, но только в условиях, когда соединение можно повторно использовать для отправки нескольких полезных нагрузок.

HTTP и MQTT являются хорошим выбором для приложений IoT из-за достаточно малого объёма трафика, низких требований к батарее и памяти.

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

В тех случаях, когда клиенты должны только получать данные, Server-Sent Events — тоже подходящий вариант.

Как быстро настроить MQTT

Eclipse Mosquitto — open source брокер MQTT

Eclipse Mosquitto — брокер сообщений с открытым исходным кодом (лицензии EPL/EDL), который реализует протоколы MQTT версий 5.0, 3.1.1 и 3.1. Mosquitto лёгкий и подходит для использования на всех устройствах: от маломощных одноплатных компьютеров до полноценных серверов.

MQTT.js

MQTT.js — это клиентская библиотека для протокола MQTT, написанная на JavaScript для Node.js и браузера. Вот пример отправки сообщения с помощью MQTT.js:

MQTTnet

Установка клиента MQTT:

После настройки параметров клиента MQTT можно установить соединение. В следующем коде показано, как подключиться к серверу:

Приём входящих сообщений:

Для поставщиков корпоративного уровня есть готовые MQTT-серверы для масштабируемого обмена сообщениями между мобильными приложениями, промышленными машинами и широким спектром других вариантов использования IoT. В этом руководстве говорится, как использовать MQTT через брокера корпоративного уровня.

Что насчёт масштабирования?

Когда речь идёт о масштабировании MQTT, следует учесть два соображения: 1) правильный ли это протокол; 2) независимо от выбора протокола, какие инфраструктура и сетевые возможности необходимы для обработки возросшего трафика между устройствами по MQTT.

Lightweight Machine-to-Machine (LWM2M) — ещё один протокол, который можно использовать вместе с MQTT на уровне предприятия. По сравнению с MQTT, он иногда лучше подходит для долговременных систем IoT. MQTT идеально подходит для пробного запуска IoT без особых усилий, в то время как LWM2M предоставляет функции для долгосрочной универсальной инфраструктуры. LWM2M также предоставляет превосходные инструменты управления устройствами, такие как мониторинг подключения, обновление прошивок и удалённые действия на устройствах. Для предприятий с большим количеством неуправляемых устройств, отправляющих большие объёмы данных на центральную платформу, LWM2M является лучшим выбором. Тем не менее, мы говорим о масштабных развёртываниях IoT, поэтому обычно MQTT более чем адекватный вариант. Кроме того, MQTT более распространён и у него более широкая поддержка.

Теперь о возможностях инфраструктуры. Когда речь заходит о загрузке сервера, то редко узким местом является количество одновременных подключений. Большинство хороших серверов/брокеров MQTT поддерживают тысячи одновременных подключений, но какова рабочая нагрузка, необходимая для обработки и ответа на сообщения после того, как сервер MQTT получил фактические данные? Как правило, есть всевозможные потенциальные проблемы, такие как чтение и запись в базу данных и из неё, интеграция с сервером, распределение и управление ресурсами для каждого клиента и т. д. Как только одна машина перестаёт справляться с нагрузкой, нужно добавлять дополнительные серверы, то есть думать о балансировке нагрузки, синхронизации сообщений между клиентами, подключёнными к разным серверам, обобщённом доступе к состоянию клиента независимо от срока соединения или конкретного сервера, к которому подключён клиент — список продолжается и продолжается.

Такие проблемы заслуживают отдельной статьи, и много информации можно найти в разделе Engineering нашего блога. В частности, см. статью о некоторых сложностях обслуживания масштабной инфраструктуры обмена сообщениями в реальном времени.

Какова нынешняя ситуация с MQTT?

В апреле 2019 года OASIS выпустила MQTT v5.0 в качестве официального стандарта. OASIS — это некоммерческий консорциум, состоящий из 600 организаций-членов и 5000 индивидуальных участников.

Версия 5.0 вводит ряд новых функций, которые должны представлять интерес для разработчиков систем реального времени. Эти новые функции обратно совместимы с текущими версиями MQTT. Среди них:

В дополнение к множеству потребительских устройств и сервисов на рынке, MQTT нашёл использование в корпоративной инфраструктуре всех форм и размеров. Это смартфоны и планшеты, системы мониторинга энергии, медицинские устройства, нефтяные вышки и буровые установки, автомобильная и аэрокосмическая промышленность, а также датчики и системы машинного зрения, используемые в погрузочно-разгрузочных работах, строительстве, цепочке поставок, розничной торговле и многое другое.

MQTT и Ably

MQTT — популярный, широко поддерживаемый и относительно зрелый протокол. Он отлично подходит для множества применений в реальном времени, а не только для развёртывания IoT. Тем не менее, поскольку производство и потребление данных в реальном времени продолжают расти экспоненциально, MQTT не всегда будет правильным выбором протокола для удовлетворения ваших потребностей в потоковой передаче. Следите за нашим разделом Realtime Concepts для получения информации о других протоколах и о том, как они подходят вашей ситуации.

Ably предоставляет брокер и адаптер протокола MQTT с трансляцией на собственный протокол Ably в обе стороны, что позволяет интегрироваться с любыми существующими системами и соединениями. Поддерживаются WebSockets, HTTP, SSE, gRPC (в разработке), STOMP, AMQP и другие протоколы для организации распределённой инфраструктуры обмена сообщениями в реальном времени. Есть более 40 клиентских библиотекам SDK и поддержка проприетарных протоколов реального времени.

Источник