MQTT

MQTT (Message Queuing Telemetry Transport) — это сетевой протокол прикладного уровня, работающий поверх стека TCP/IP и реализующий модель обмена сообщениями по схеме «издатель — подписчик» (publish-subscribe). Протокол разработан для передачи данных в условиях ограниченной пропускной способности каналов связи, высокой задержки и нестабильного соединения, что делает его одним из стандартов в индустрии Интернета вещей (IoT), промышленной автоматизации и системах телеметрии. Основными характеристиками MQTT являются минимальный размер заголовка (от 2 байт), поддержка трёх уровней качества обслуживания (QoS) и встроенный механизм сессий для сохранения состояния клиента.

История

Протокол MQTT был разработан в 1999 году Энди Стэнфорд-Кларком (IBM) и Арленом Ниппером (Arcom, ныне Eurotech). Первоначальная цель заключалась в создании лёгкого протокола для мониторинга нефтепроводов через спутниковые каналы связи — типичная задача телеметрии, где каждый байт трафика стоил дорого, а соединение могло прерываться. Название изначально расшифровывалось как «MQ Telemetry Transport» (MQ — от «message queue», хотя сам протокол не использует очереди в классическом понимании).

В 2010 году IBM передала спецификацию MQTT версии 3.1 в организацию OASIS (Organization for the Advancement of Structured Information Standards) для стандартизации. В 2014 году OASIS выпустила версию 3.1.1, а в 2016 году — версию 5.0, которая добавила расширенные возможности, такие как метаданные, улучшенное управление сессиями и поддержку запрос-ответ. В 2022 году MQTT был утверждён как международный стандарт ISO/IEC 20922.

Архитектура и принцип работы

Модель «издатель — подписчик»

В отличие от клиент-серверных протоколов (например, HTTP), MQTT использует асинхронную модель обмена. Ключевым элементом является брокер (сервер MQTT), который принимает сообщения от клиентов-издателей и распределяет их среди клиентов-подписчиков. Клиенты не общаются напрямую друг с другом — вся коммуникация проходит через брокера.

• Издатель (publisher) отправляет сообщение на определённую тему (topic), не зная, кто и сколько подписчиков её слушает.
• Подписчик (subscriber) подписывается на интересующие его темы и получает все сообщения, опубликованные на них.
• Брокер (broker) фильтрует и маршрутизирует сообщения. Он хранит информацию о подписках и может временно сохранять сообщения для отключённых клиентов.

Темы (Topics)

Тема — это иерархическая строка, по которой маршрутизируются сообщения. Темы имеют структуру каталогов, разделённую слешем (/). Например:

• home/kitchen/temperature
• factory/machine1/status

Поддерживаются два wildcard-символа:

• + — заменяет один уровень иерархии (например, подписка home/+/temperature получит сообщения с home/kitchen/temperature и home/bedroom/temperature).
• # — заменяет все последующие уровни (например, home/# подпишет на все темы, начинающиеся с home/).

Уровни качества обслуживания (QoS)

MQTT определяет три уровня надёжности доставки сообщений:

Сессии и сохранение сообщений

Клиент может установить постоянную сессию (clean session = false), что позволяет брокеру хранить все подписки и неотправленные сообщения (с QoS > 0) для клиента, даже если он временно отключён. При повторном подключении клиент получит все накопленные сообщения. Временная сессия (clean session = true) удаляет все данные при отключении.

Последнее заветное сообщение (Last Will and Testament, LWT) — это сообщение, которое брокер публикует от имени клиента, если тот неожиданно отключается (например, из-за обрыва связи). LWT позволяет другим подписчикам узнать о сбое устройства.

Структура пакета

Заголовок фиксированного размера (Fixed Header) состоит из 2 байт:

• Первый байт: тип пакета (CONNECT, PUBLISH, SUBSCRIBE и т.д.) и флаги.
• Второй байт: длина оставшейся части сообщения (Remaining Length), закодированная с использованием переменного количества байт (до 4 байт, максимальная длина 256 МБ).

Переменный заголовок (Variable Header) и полезная нагрузка (Payload) зависят от типа пакета. Например, для PUBLISH переменный заголовок содержит имя темы и идентификатор пакета (только для QoS > 0).

Версии протокола

MQTT 3.1.1 (OASIS Standard, 2014)

Наиболее распространённая версия. Включает базовые функции: три уровня QoS, LWT, постоянные сессии, аутентификацию по логину/паролю.

MQTT 5.0 (OASIS Standard, 2016)

Расширенная версия, обратно совместимая с 3.1.1 по базовому синтаксису. Добавлены:

• Метаданные (User Properties) — произвольные пары ключ-значение в заголовке.
• Код причины (Reason Codes) — вместо простого ACK/NACK брокер может вернуть код причины (например, «недостаточно прав», «тема не существует»).
• Общие подписки (Shared Subscriptions) — балансировка нагрузки между несколькими подписчиками на одну тему.
• Время жизни сообщения (Message Expiry Interval) — автоматическое удаление устаревших сообщений.
• Подписка на тему с указанием опций (Subscription Options) — можно задать QoS, флаги «не получать собственные сообщения» (No Local) и «сохранять порядок» (Retain As Published).
• Поддержка запрос-ответ (Request-Response) — клиент может указать тему ответа, на которую брокер отправит результат.

MQTT-SN (MQTT for Sensor Networks)

Вариант протокола для сетей с очень малыми пакетами (например, ZigBee, LoRaWAN). Не требует TCP — работает поверх UDP или других транспортных протоколов. Использует сокращённые идентификаторы тем (Topic ID) вместо строк.

Брокеры MQTT

Для работы MQTT необходим брокер. Наиболее известные реализации:

• Mosquitto (Eclipse Foundation) — открытый, лёгкий, поддерживает MQTT 3.1.1 и 5.0. Широко используется в тестовых и промышленных средах.
• EMQX (EMQ) — масштабируемый брокер на Erlang/OTP, поддерживает кластеризацию, до миллионов одновременных подключений. Есть коммерческая и открытая версии.
• HiveMQ — коммерческий брокер с акцентом на корпоративную безопасность и мониторинг.
• VerneMQ — открытый брокер на Erlang, ориентированный на высокую доступность и горизонтальное масштабирование.
• RabbitMQ — универсальный брокер сообщений, который поддерживает MQTT через плагин, но не оптимизирован для сценариев IoT.
• AWS IoT Core — облачный сервис Amazon, поддерживающий MQTT (включая MQTT 5.0) и Device Shadow.
• Azure IoT Hub — облачный сервис Microsoft для управления IoT-устройствами, поддерживает MQTT как один из протоколов.

Применение

Интернет вещей (IoT)

MQTT является де-факто стандартом для передачи данных с датчиков, контроллеров и исполнительных устройств. Примеры:

• Умный дом: датчики температуры, влажности, света публикуют показания; контроллеры подписываются на команды включения/выключения.
• Промышленная автоматизация (Industry 4.0): сбор данных с PLC (программируемых логических контроллеров), мониторинг состояния станков.
• Сельское хозяйство: датчики влажности почвы, метеостанции передают данные на серверы.

Мобильные приложения и push-уведомления

Некоторые сервисы используют MQTT для доставки уведомлений на мобильные устройства, так как протокол позволяет поддерживать постоянное соединение с минимальным расходом батареи (в отличие от HTTP-опросов).

Автомобильная телематика

Системы мониторинга транспорта (GPS-трекеры, датчики топлива, CAN-шина) передают данные через MQTT на диспетчерские серверы.

Системы управления зданиями (BMS)

Контроллеры HVAC (отопление, вентиляция, кондиционирование), освещения, доступа обмениваются данными через MQTT.

Безопасность

Базовый MQTT не шифрует данные и передаёт логин/пароль в открытом виде. Для обеспечения безопасности используются следующие методы:

• TLS/SSL — шифрование трафика между клиентом и брокером (аналогично HTTPS). Рекомендуется для любых внешних сетей.
• Аутентификация — по логину/паролю, по сертификатам X.509, по токенам (JWT).
• Авторизация — брокер может ограничивать доступ к темам на основе идентификатора клиента (ACL — Access Control Lists).
• MQTT 5.0 — ввёл коды причин для отказа в доступе и поддержку аутентификации на уровне прикладного протокола (AUTH).

Критика и ограничения

• Отсутствие встроенного шифрования — требует обязательного использования TLS, что увеличивает накладные расходы.
• Централизованная архитектура — брокер является единой точкой отказа. Для отказоустойчивости необходима кластеризация брокеров, что усложняет настройку.
• Сложность QoS 2 — четырёхстороннее рукопожатие может создавать задержки и требует хранения состояния на брокере.
• Отсутствие гарантии порядка — при использовании нескольких брокеров или переподключениях порядок сообщений может нарушаться.
• Не подходит для потоковой передачи больших объёмов данных (аудио, видео) — из-за накладных расходов на метаданные и отсутствия поддержки фрагментации.
• Стандарт не определяет формат полезной нагрузки — разработчики вынуждены самостоятельно договариваться о сериализации (JSON, CBOR, Protocol Buffers, MessagePack).

Интересные факты

• Аббревиатура MQTT изначально не имела расшифровки. Позднее сообщество закрепило за ней «Message Queuing Telemetry Transport», хотя протокол не использует очереди (queues) — он использует темы.
• MQTT 3.1.1 был опубликован как стандарт OASIS в 2014 году и одновременно принят как стандарт ISO (ISO/IEC 20922:2016).
• Протокол используется в Facebook (продукт Meta, признанной экстремистской и запрещённой в РФ) Messenger (организация Meta признана экстремистской и запрещена в РФ) для доставки push-уведомлений, хотя компания модифицировала его под свои нужды.
• В 2020 году MQTT был признан одним из ключевых протоколов для Industrial IoT (IIoT) по версии консорциума Industrial Internet Consortium.

Источники

• OASIS Standard MQTT Version 3.1.1, 2014.
• OASIS Standard MQTT Version 5.0, 2016.
• ISO/IEC 20922:2016 — Information technology — Message Queuing Telemetry Transport (MQTT) v3.1.1.
• Andrew Banks, Rahul Gupta. «MQTT Version 3.1.1 Plus Errata 01». OASIS, 2015.
• Eclipse Mosquitto — официальная документация.
• EMQX — официальная документация.
• Industrial Internet Consortium. «The Industrial Internet of Things Volume G5: Connectivity Framework», 2020.