MQTT

Энди Стэнфорд-Кларк (IBM) и Арлен Ниппер (на тот момент работавший в Arcom, позже Eurotech, Inc.) разработали первую версию протокола в 1999 году. Изначально он создавался для решения задачи американской нефтяной компании ConocoPhillips по мониторингу состояния нефте- и газопроводов в реальном времени в составе промышленной системы управления SCADA^[4]. Целью было создание эффективного по использованию полосы пропускания, легковесного и экономящего заряд батареи протокола, поскольку устройства были подключены через дорогие и нестабильные спутниковые каналы связи^[4][5].

Исторически «MQ» в «MQTT» происходит от IBM MQ (тогда «MQSeries»), где означает «Message Queue». Однако сам протокол реализует обмен сообщениями по модели публикации-подписки (без очередей, несмотря на название)^[6]. В спецификации, открытой IBM как версия 3.1, протокол назывался «MQ Telemetry Transport»^[7][8]. В последующих версиях, выпускаемых OASIS, протокол официально называется просто «MQTT», хотя технический комитет носит название «OASIS Message Queuing Telemetry Transport Technical Committee». С 2013 года «MQTT» не расшифровывается как аббревиатура^[6][9].

В 2013 году компания IBM передала спецификацию MQTT v3.1 в организацию по стандартизации OASIS с уставом, допускающим только незначительные изменения. После этого версия 3.1.1 была выпущена 29 октября 2014 года^[10][11], а в 2016 году протокол был опубликован как международный стандарт ISO/IEC 20922^[12]. Более значительное обновление — версия MQTT 5 с рядом новых функций^[13] — было опубликовано 7 марта 2019 года.

Ключевую роль в стандартизации протокола в рамках OASIS сыграли редакторы спецификаций. Редакторами версии 3.1.1 выступили Эндрю Бэнкс (Andrew Banks) и Рахул Гупта (Rahul Gupta) из IBM. Над версией 5.0 работала расширенная группа редакторов: Эндрю Бэнкс, Кен Боргдейл (Ken Borgdale), Рахул Гупта (все из IBM) и Эд Бриггс (Ed Briggs) из Microsoft^[14].

MQTT-SN (MQTT for Sensor Networks) — версия протокола MQTT, адаптированная для сенсорных сетей и устройств с ограниченными ресурсами, которые работают в сетях без поддержки TCP/IP, таких как Zigbee или BLE^[15]. Протокол использует шлюзы для трансляции сообщений MQTT-SN в стандартный формат MQTT, обеспечивая интеграцию с существующей IoT-инфраструктурой^[16]. Ключевыми особенностями MQTT-SN являются оптимизация для беспроводных сред с низкой пропускной способностью и высокими потерями, а также поддержка спящего режима для устройств с низким энергопотреблением^[17].

Первые версии протокола (1.0 и 1.1) появились в 2007 и 2008 годах соответственно. 14 ноября 2013 года была выпущена спецификация версии 1.2, разработанная Энди Стэнфорд-Кларком и Хонг Линь Труонгом из IBM. В этой версии, в частности, была добавлена поддержка сообщений длиной более 255 байт^[18]. Эта версия оставалась последней официальной спецификацией на протяжении многих лет.

В 2017 году технический комитет OASIS MQTT отложил работу по стандартизации MQTT-SN, чтобы сосредоточиться на выпуске MQTT 5.0^[19]. После выхода MQTT 5.0 в 2019 году возникла необходимость в обновлении MQTT-SN для лучшей совместимости. В конце 2020 года в рамках OASIS началась работа над новой версией протокола, условно названной MQTT-SN 2.0^[20]. 6 апреля 2021 года устав технического комитета был официально обновлён, чтобы включить разработку MQTT-SN как стандарта OASIS^[21].

По состоянию на 2024 год, работа над стандартом MQTT-SN 2.0 всё ещё продолжается, а версия 1.2 остаётся последней опубликованной спецификацией^[21]. Целью обновления является приведение протокола в соответствие с возможностями MQTT 5.0, включая выравнивание кодов ошибок, улучшенную аутентификацию и добавление новых опций подписки^[20].

Протокол MQTT определяет два типа сетевых сущностей: брокер сообщений и множество клиентов. MQTT-брокер — это сервер, который принимает все сообщения от клиентов и перенаправляет их соответствующим клиентам-получателям^[22]. MQTT-клиент — любое устройство (от микроконтроллера до полноценного сервера), использующее библиотеку MQTT и подключающееся к брокеру по сети^[23].

Информация организована в иерархию тем (topics). Когда издатель (publisher) имеет новые данные для распространения, он отправляет управляющее сообщение с данными подключённому брокеру. Брокер затем рассылает информацию всем клиентам, подписанным на эту тему. Издателю не требуется знать количество или местоположение подписчиков; подписчики, в свою очередь, не должны быть настроены на конкретных издателей.

Если брокер получает сообщение по теме, на которую нет подписчиков, он отбрасывает сообщение, если только издатель не пометил его как сохраняемое (retained message). Сохраняемое сообщение — это обычное MQTT-сообщение с установленным флагом retained. Брокер хранит последнее сохраняемое сообщение и соответствующий уровень QoS для выбранной темы. Каждый клиент, подписывающийся на шаблон темы, совпадающий с темой сохраняемого сообщения, получает его сразу после подписки. Брокер хранит только одно сохраняемое сообщение на тему^[24]. Это позволяет новым подписчикам сразу получать актуальное значение, не дожидаясь следующего обновления от издателя.

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

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

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

MQTT использует протокол TCP для передачи данных. Вариант MQTT-SN применяется для других транспортов, таких как UDP или Bluetooth.

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

Стандартный нешифрованный порт MQTT — 1883. Для защищённого соединения используется порт 8883^[25].

Благодаря своей легковесности, эффективности и низкому потреблению ресурсов, протокол MQTT нашёл широкое применение в различных отраслях, став де-факто стандартом для Интернета вещей (IoT) и межмашинного взаимодействия (M2M). Ключевые области применения включают:

• Интернет вещей (IoT): Основная сфера применения MQTT. Протокол используется для связи между многочисленными устройствами, такими как интеллектуальные датчики, носимые устройства и другие IoT-гаджеты, с облачными сервисами и между собой. Его эффективность и низкое энергопотребление делают его идеальным для устройств с ограниченным временем автономной работы.
• Промышленный интернет вещей (IIoT) и автоматизация: В промышленности MQTT применяется для мониторинга и управления оборудованием в режиме реального времени^[26]. Датчики, установленные на станках, трансформаторах и другом оборудовании, передают данные, что позволяет оперативно реагировать на нештатные ситуации, сокращая простои и предотвращая поломки^[26].
• Умный дом: В системах «умного дома» протокол обеспечивает взаимодействие между различными устройствами, такими как лампочки, выключатели, датчики температуры и движения.
• Мониторинг окружающей среды: MQTT используется для сбора данных с удалённых и маломощных датчиков, которые отслеживают климатические показатели, сейсмическую активность и другие параметры окружающей среды^[26].
• Транспорт и логистика: Одним из первых применений протокола была передача данных с датчиков на нефтепроводах через спутниковую связь. Сегодня он также используется в различных транспортных системах^[27].
• Здравоохранение: Протокол находит применение в сфере здравоохранения для удалённого мониторинга состояния пациентов и сбора данных с медицинских устройств^[27].

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

Брокер действует как почтовое отделение. MQTT-клиенты не используют прямой адрес получателя, а применяют строку темы (topic). Любой подписчик получает копию всех сообщений по этой теме. Несколько клиентов могут подписываться на одну тему у одного брокера (модель «один ко многим»), а один клиент может подписываться на темы у нескольких брокеров («многие к одному»).

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

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

В случае сбоя программное обеспечение брокера и клиенты могут автоматически переключиться на резервный/автоматический брокер. Резервные брокеры также могут использоваться для распределения нагрузки между несколькими серверами — локально, в облаке или в гибридной конфигурации.

Брокер может поддерживать как стандартный MQTT, так и совместимые спецификации, например Sparkplug^[28]. Это возможно на одном сервере, одновременно и с одинаковым уровнем безопасности.

Брокер отслеживает всю информацию о сессии устройства в режиме «постоянных сессий» (persistent sessions). В этом состоянии брокер хранит как информацию о соединении каждого клиента, так и темы подписки, а также сообщения по темам с QoS 1 или 2^[29].

Основные преимущества MQTT-брокера:

1. Исключение уязвимых и небезопасных клиентских соединений (при правильной настройке).
2. Возможность масштабирования от одного устройства до тысяч.
3. Управление и отслеживание состояния клиентских соединений, включая учётные данные и сертификаты (при правильной настройке).
4. Снижение нагрузки на сотовые или спутниковые сети без ущерба для безопасности (при правильной настройке).

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

MQTT поверх QUIC Ключевой инновацией стала поддержка протокола QUIC в качестве транспортного уровня вместо традиционного TCP. Это обеспечивает значительные преимущества для мобильных и нестабильных сетей, характерных для IoT: ускоренное установление соединения, устойчивость к смене IP-адреса клиентом (например, при переключении с Wi-Fi на сотовую сеть) и уменьшение задержек^[30][31]. Пионерами в реализации этой возможности стали брокеры EMQX и NanoMQ^[31].

Расширенная интеграция данных Современные брокеры всё чаще выступают в роли центральных узлов для маршрутизации данных в корпоративные системы. Например, EMQX обеспечивает встроенную интеграцию с базами данных и хранилищами, такими как Snowflake и Amazon S3, а также шлюз для протокола NATS^[32]. HiveMQ предлагает корпоративные расширения для интеграции с Google Cloud Pub/Sub и Microsoft SQL Server^[33], а коммерческая версия Pro Mosquitto от Cedalo — мосты для интеграции с MongoDB и Kafka^[34].

Внедрение искусственного интеллекта (AI) В июне 2025 года с выходом версии EMQX Enterprise 5.10 в брокерах появились функции на базе искусственного интеллекта^[35]. Они включают интеграцию с большими языковыми моделями (например, GPT-4) для анализа и обобщения MQTT-сообщений непосредственно в брокере, а также генератор SQL-правил на естественном языке, позволяющий создавать логику обработки данных без написания кода^[32].

Улучшения в области безопасности и управления Ведущие брокеры усилили функции безопасности и управления. HiveMQ получил сертификацию SOC 2 и внедрил поддержку SSO и детализированный журнал аудита^[36]. EMQX расширил контроль доступа, добавив авторизацию на основе метаданных клиента (IP-адрес, Client ID), и представил функцию «Cluster Linking» для эффективного объединения кластеров в разных регионах^[37]. В промышленном интернете вещей (IIoT) брокеры стали центральным элементом архитектур Unified Namespace (UNS) и стандарта Sparkplug, унифицирующих обмен данными между производственным оборудованием и IT-системами^[38].

Ожидает установления соединения с сервером и создаёт связь между узлами.

Ожидает завершения работы MQTT-клиента и разрыва сессии TCP/IP.

Сразу возвращает управление приложению после передачи запроса MQTT-клиенту.

В 2019 году OASIS опубликовала официальный стандарт MQTT 5.0. Версия 5.0 включает следующие основные новые функции^[39]:

• Коды причин: подтверждения теперь поддерживают коды возврата, указывающие причину сбоя.
• Разделяемые подписки: позволяют распределять нагрузку между клиентами, снижая риск перегрузки.
• Время жизни сообщения: сообщения могут иметь срок действия и удаляются, если не доставлены за это время.
• Псевдонимы тем: имя темы может быть заменено одним числом.

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

Одним из ключевых направлений развития стала работа по использованию протокола QUIC в качестве транспортного уровня для MQTT вместо традиционного TCP^[40]. Это нововведение призвано улучшить скорость установки соединения, уменьшить задержки и, что особенно важно для мобильных IoT-устройств, обеспечить устойчивость к смене сети клиентом (например, при переключении с Wi-Fi на сотовую связь) без разрыва сессии.

В сообществе также обсуждаются усовершенствования, которые могут войти в будущую версию протокола, условно называемую MQTT 5.1. К ним относятся предложения по внедрению более гибких фильтров подписок и возможности пакетной отправки сообщений для снижения накладных расходов при передаче большого количества небольших пакетов^[40].

Другим направлением является разработка расширений для решения задач, для которых стандартный MQTT подходит не лучшим образом. Например, ведётся работа над механизмами для передачи больших файлов (таких как обновления прошивок), которые позволят передавать данные по частям с возможностью возобновления, используя существующую инфраструктуру MQTT^[40].

Каждое соединение с брокером может указывать уровень QoS^[41]. Уровни классифицируются по возрастанию накладных расходов:

• Не более одного раза (At most once) — сообщение отправляется только один раз, клиент и брокер не подтверждают доставку (fire and forget).
• Не менее одного раза (At least once) — отправитель повторяет отправку до получения подтверждения (acknowledged delivery).
• Ровно один раз (Exactly once) — отправитель и получатель используют двухуровневое подтверждение, чтобы гарантировать получение только одной копии сообщения (assured delivery).

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

Поскольку протокол MQTT не предписывает обязательное шифрование, безопасность передачи данных полностью зависит от правильной конфигурации и использования протоколов транспортного уровня, таких как TLS^[42]. При отсутствии TLS учётные данные и сообщения передаются в открытом виде, что делает систему уязвимой для атак типа «человек посередине»^[43]. Неправильно настроенные брокеры, доступные через интернет, могут раскрывать конфиденциальные данные неавторизованным подписчикам^[42].

Безопасность протокола и его реализаций неоднократно становилась предметом исследований. Например, в 2020 году итальянскими исследователями была продемонстрирована атака типа «медленный отказ в обслуживании» (slow DoS) на протокол (CVE-2020-13849)^[44]. В последующие годы было выявлено множество других уязвимостей.

В 2021 году, по данным «Лаборатории Касперского», было обнаружено 33 уязвимости в MQTT, 18 из которых были классифицированы как критические^[45]. Исследователи из Synopsys выявили DoS-уязвимости в трёх популярных брокерах с открытым исходным кодом^[46]:

• RabbitMQ (CVE-2021-22116): чрезмерное потребление памяти из-за специально созданных сообщений.
• EMQ X (CVE-2021-33175): отказ в обслуживании из-за вредоносных пакетов.
• VerneMQ (CVE-2021-33176): исчерпание памяти из-за некорректно сформированных пакетов.

Также были обнаружены уязвимости в Eclipse Mosquitto: CVE-2021-41039, при которой клиент MQTTv5 с большим количеством пользовательских свойств мог вызвать чрезмерную нагрузку на процессор^[47], и CVE-2021-28166, исправленная в версии 2.0.10^[48].

В феврале 2022 года «Лаборатория Касперского» опубликовала отчёт, в котором подчеркнула риски использования MQTT в носимых устройствах и телемедицине, отметив, что многие из ранее выявленных уязвимостей оставались неисправленными^[43]. В этом году были зарегистрированы следующие уязвимости:

• F5 BIG-IP (CVE-2022-35240): удалённый неаутентифицированный злоумышленник мог вызвать отказ в обслуживании в компоненте Message Routing MQTT^[49].
• Servisnet Tessa (CVE-2022-22832): уязвимость позволяла получить учётные данные MQTT без аутентификации^[50].
• Eclipse Mosquitto: в августе была исправлена проблема, приводившая к сбою брокера в версиях с 2.0.0 по 2.0.14^[48].

В 2023 году продолжилось выявление уязвимостей, в основном в брокере Eclipse Mosquitto:

• CVE-2023-0809: DoS-атака через чрезмерное выделение памяти на брокере^[48].
• CVE-2023-3592: утечка памяти при отправке клиентом MQTTv5 пакета CONNECT с некорректными свойствами в «завещании» (will message)^[48].
• CVE-2023-28366: утечка памяти, вызываемая отправкой множества сообщений с QoS 2 и дублирующимися идентификаторами^[51].

Кроме того, были обнаружены уязвимости, затрагивающие целые системы, например, CVE-2023-3028, которая позволяла получить доступ к телеметрии парка транспортных средств^[52], и CVE-2023-1083, позволявшая неаутентифицированному злоумышленнику отправлять команды на устройства, зная имя топика^[53].

В 2024 году были выявлены уязвимости как в серверных, так и в клиентских реализациях MQTT:

• Eclipse Mosquitto (CVE-2024-8376): утечка памяти или сбой, вызываемые определённой последовательностью пакетов^[54].
• libmosquitto (CVE-2024-10525): переполнение буфера в клиентской библиотеке, которое могло привести к сбою приложения или выполнению произвольного кода^[55].
• CVE-2024-6786: уязвимость обхода каталога (path traversal) в MQTT-сообщениях, позволяющая читать произвольные файлы в системе^[56].
• SiPass integrated AC5102 (CVE-2024-52285): обнаружены открытые URL-адреса MQTT без аутентификации, что позволяло получить доступ к конфиденциальным данным^[56].

В 2025 году уязвимости были обнаружены в ряде промышленных и потребительских продуктов:

• Rockwell Automation FactoryTalk Optix (CVE-2025-9161): отсутствие санитаризации URI позволяло загружать удалённые плагины Mosquitto, что могло привести к удалённому выполнению кода^[57].
• SunGrow iSolarCloud (CVE-2025-29756): недостаточные ограничения на подписку к топикам позволяли аутентифицированному пользователю перехватывать сообщения от всех устройств в системе^[58].
• Маршрутизаторы TOTOLINK: выявлен ряд критических уязвимостей в обработчике MQTT-пакетов (например, CVE-2025-8170, CVE-2025-7952)^[56].
• Устройства ABB RMC-100 (CVE-2025-6071): использование жёстко закодированного криптографического ключа позволяло расшифровывать данные, передаваемые по MQTT^[56].

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