Что такое mqtt и с чем его едят

MQTT или Message Queue Telemetry Transport – это легкий, компактный и открытый протокол обмена данными созданный для передачи данных на удалённых локациях, где требуется небольшой размер кода и есть ограничения по пропускной способности канала.

Брокер 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 обладает следующими свойствами:

 

• Нейтрален к содержимому сообщения
   
• Идеально подходит для распределённых коммуникаций «один ко многим» и разъединённых приложений
   
• Оснащён функцией LWT (Last Will and Testament, «последняя воля и завещание») для уведомления сторон об аномальном отключении клиента
   
• Полагается на TCP/IP для базовых задач связи
   
• Разработан для доставки сообщений по шаблонам «максимум один раз», «минимум один раз» и «ровно один раз»

Участник системы MQTT может взять на себя роль издателя, потребителя или обе роли сразу.

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

 

channel = "user/path/channel"

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

 

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

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

 

• Байт 1: содержит тип сообщения (запрос клиента на подключение, подтверждение подписки, запрос ping и т. д.), флаг дублирования, инструкции для сохранения сообщений и информацию об уровне качества обслуживания (QoS).
   
• Байт 2: содержит информацию об оставшейся длине сообщения, включая полезную нагрузку и любые данные в заголовке необязательной переменной.

Флаг QoS в байте 1 заслуживает особого внимания, так как он лежит в основе переменной функциональности, которую поддерживает MQTT. Флаги QoS содержат следующие значения, основанные на намерении и срочности сообщения:

 

• 0 = не более одного раза: сервер срабатывает и забывает. Сообщения могут быть потеряны или продублированы
   
• 1 = по крайней мере один раз: получатель подтверждает доставку. Сообщения могут дублироваться, но доставка гарантирована
   
• 2 = ровно один раз: сервер обеспечивает доставку. Сообщения поступают точно один раз без потери или дублирования

Давайте рассмотрим, как использовать различные уровни QoS в устройствах IoT и других приложениях.

 

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

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

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

• Данные датчиков окружающей среды: как уже упоминалось, MQTT поддерживает модель доставки сообщений «не более одного раза». В сетях с частичным покрытием территории или высокой задержкой это означает, что информация может быть потеряна или дублироваться. В областях, где удалённые датчики записывают и передают данные с заданными интервалами, это не является проблемой, так как новые показания поступают на регулярной основе. Датчики в удалённых средах — обычно маломощные устройства, что делает MQTT идеальным решением для сенсоров IoT с относительно низким приоритетом передачи данных.
   
• Данные о работоспособности машин: для быстрого реагирования на возникающие проблемы и предотвращения простоев. Например, для ветроэлектрической установки нужна гарантированная доставка текущих показателей о работоспособности местным командам ещё до того, как эта информация попадёт в центр обработки данных. В таких ситуациях доставка сообщений «по крайней мере один раз» гарантирует, что соответствующие флаги своевременно заметят нужные специалисты, даже если они поступают как дубликаты. Это важно для межмашинной связи с более высоким приоритетом.
   
• Биллинговые системы: есть ещё более приоритетные и точные сообщения, которые требуется правильно обрабатывать. В бизнес-ситуациях, где дублирование записей неприемлемо, в том числе в биллинговых системах, пригодится флаг QoS передачи «точно один раз». Это устраняет дублирование или потерю пакетов в системах выставления счетов или биллинга, сокращает количество аномалий и ненужных противоречий по согласованию.

 

Когда не нужно использовать 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

В репозиторий MQTT на GitHub обширный список open source библиотек MQTT на разных языках. Ниже приведены два примера настройки с помощью open source брокера MQTT, библиотеки JavaScript и библиотеки .NET.

 

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

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

В следующей статье реализуем схему указанную ниже на базе устройства esp32, брокера Mosquitto и Arduino IDE