Для чего нужен протокол 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 обладает следующими свойствами:

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

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

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

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

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

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

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

Где можно использовать 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 лёгкий и подходит для использования на всех устройствах: от маломощных одноплатных компьютеров до полноценных серверов.

MQTT.js

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

MQTTnet

MQTTnet — высокопроизводительная библиотека .NET, которая предоставляет и клиент, и сервер MQTT (брокер).

Установка клиента 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. Среди них:

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

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

MQTT и Ably

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

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

MQTT: The Standard for IoT Messaging

MQTT is an OASIS standard messaging protocol for the Internet of Things (IoT). It is designed as an extremely lightweight publish/subscribe messaging transport that is ideal for connecting remote devices with a small code footprint and minimal network bandwidth. MQTT today is used in a wide variety of industries, such as automotive, manufacturing, telecommunications, oil and gas, etc.

Why MQTT?

Lightweight and Efficient

MQTT clients are very small, require minimal resources so can be used on small microcontrollers. MQTT message headers are small to optimize network bandwidth.

Bi-directional Communications

MQTT allows for messaging between device to cloud and cloud to device. This makes for easy broadcasting messages to groups of things.

Scale to Millions of Things

MQTT can scale to connect with millions of IoT devices.

Reliable Message Delivery

Reliability of message delivery is important for many IoT use cases. This is why MQTT has 3 defined quality of service levels: 0 — at most once, 1- at least once, 2 — exactly once

Support for Unreliable Networks

Many IoT devices connect over unreliable cellular networks. MQTT’s support for persistent sessions reduces the time to reconnect the client with the broker.

Security Enabled

MQTT makes it easy to encrypt messages using TLS and authenticate clients using modern authentication protocols, such as OAuth.

MQTT: протокол передачи данных в интернете вещей

Укоренное развитие промышленности и информационных технологий привело к повышению количества устройств, контролирующих выполнение рабочих процессов, позволяющих получать данные об их эффективности. Чтобы решить проблему взаимодействия огромного количества аппаратного оборудования, была разработана концепция Интернета вещей – IoT. Технология предполагает объединение устройств, которые классифицируются по определенному признаку в одну сеть. Далее схожие сети укрупняются. И так до бесконечности, пока не получится одна масштабная структура с общим признаком.

Взаимодействие в ней осуществляется при помощи интерфейсов и протоколов передачи данных в сети. Но, Интернет вещей имеет свои особенности, которые могут учесть далеко не все протоколы. Как результат – снижается эффективность взаимодействия, возникают другие проблемы, требуется постоянный контроль. Чтобы минимизировать эти проблемы, обеспечить стабильность работы IoT был создан особый протокол – MQTT. И на сегодня это одно из наиболее востребованных решений в области Интернета вещей.

MQTT: для чего нужен протокол, в чем его особенности, преимущества и в каких областях он нашел наибольшее практическое применения?

MQTT: знакомимся с особенностями протокола

Начать описание протокола MQTT стоит с его основных моментов. Ему присуще:

• Функционирование в условиях нестабильной работы линии передачи данных (в случае отпадания сети). Обеспечивается оперированием небольшими сообщениями – пересылаются компактно, что позволяет экономить буквально каждый бит. А это очень актуально для бинарных протоколов, которым и является MQTT.
• Одновременная поддержка нескольких уровней качества обслуживания. MQTT работает на прикладном уровне, используя для организации соединения и передачи информации TCP/IP. По умолчанию применяется порт 1883. Если требуется дополнительно обеспечить защиту данных, используется SSL. В этом случае для подключения применяется порт 8883.
• Быстрота и простота подключения нового аппаратного обеспечения. MQTT адаптирован к особенностям как оборудования, так и каналов связи.

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

В процессе взаимодействия принимает участие три категории пользователей:

1. Издатели. Это те, кто отправляют сообщения. Они указывают topic – тему. Как пример – датчики, снимающие показания с термометров или других устройств, подключенных к Интернету вещей.
2. Подписчики. Конечные получатели информации. Они могут работать с разными издателями, в зависимости от того, на какие топики они подписаны. Как пример – аналитическая облачная система.
3. Брокер. Это основной узел MQTT, обеспечивающий стабильную передачу информации между клиентами: издателями и подписчиками. Он получает информацию от брокера, обрабатывает ее, передает подписчикам, контролирует доставку. Роль брокера зачастую возлагается на сервер или контролер.

Для взаимодействия с брокером предусмотрен набор стандартизированных сообщений:

• Connect: установка доступа/соединения;
• Disconnect: разрыв соединения;
• Publish: публикация информации в topic;
• Subscribe: подписка на topic;
• Unsubscribe: отписка от topic.

Все эти действия выполняются с брокером.

Основные преимущества

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

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

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

Область применения

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

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

Наиболее часто на практике протокол MQTT используется в:

1. Системах мониторинга оборудования. Большинство современных предприятий стали устанавливать на станках, кранах, трансформаторах и другом оборудовании дополнительные датчики. Они контролируют работу агрегатов в режиме реального времени: снимают показания и передают значения в центр обработки данных. Все это позволяет персоналу мгновенно реагировать на проблемы, минимизировать поломки оборудования и его простои.
2. Системах мониторинга окружающей среды. Позволяет с удобством контролировать климатические показатели, сейсмическую активность региона, устойчивость к ней зданий и сооружений. В удаленных регионах размещаются маломощные датчики, которые с заданным интервалом снимают информацию и передают ее на обработку через MQTT брокер.
3. Системы работы с важными данными. Речь идет о биллингах мобильный операторов и провайдеров. Позволяют передавать информацию о текущем состоянии клиентских счетов без риска ее потери. Информация передается «точно один раз», что исключает также и ее дублирование, снижает количество аномалий.

Подводим итоги

Подводя итог всему вышесказанному, стоит выделить следующие ключевые моменты протокола MQTT:

1. Создан он для Интернета вещей. Издатели передают информацию подписчикам через брокера. MQTT клиенты – это издатели и подписчики.
2. Протокол оказывает минимальную нагрузку на вычислительные мощности аппаратного обеспечения. Стабильно работает в условиях плохой связи.
3. В настройках протокола предусмотрены опции, позволяющие выставлять приоритеты при доставке сообщений.

Более подробно с особенностями протокола MQTT, его областью применения, нюансами внедрения вас познакомят специалисты компании «Xelent». Связаться с ними можно по телефону или через онлайн-форму.

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

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

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

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

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

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

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

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

Где можно использовать 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 лёгкий и подходит для использования на всех устройствах: от маломощных одноплатных компьютеров до полноценных серверов.

MQTT.js

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

MQTTnet

MQTTnet — высокопроизводительная библиотека .NET, которая предоставляет и клиент, и сервер MQTT (брокер).

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

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

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

Больше примеров см. в документации и вики MQTTnet.

Для поставщиков корпоративного уровня есть готовые 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. Среди них:

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

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

MQTT и Ably

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

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