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

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

Другой взгляд на обмен сообщениями между устройствами

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

Такое разделение полезно в крупных распределенных системах. Датчику температуры не нужно знать, какая панель, база данных, мобильное приложение или правило автоматизации будет использовать его данные. Ему нужно только опубликовать данные в определенную тему. Распределением занимается брокер.

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

Брокер как центр сообщений

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

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

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

Жизненный цикл подключения

Клиент создает сессию

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

Брокер проверяет запрос на подключение и отвечает пакетом CONNACK. Если подключение принято, клиент может публиковать, подписываться, отменять подписки и получать сообщения. Если подключение отклонено, брокер указывает причину в соответствии с версией протокола и конфигурацией.

Пульс поддерживает связь активной

Механизм keepalive помогает обеим сторонам обнаруживать разорванные соединения. Если в течение согласованного времени не было обмена данными, клиент отправляет пакет PINGREQ, а брокер отвечает PINGRESP.

Это важно, потому что устройства IoT могут работать в нестабильных сетях, мобильных каналах, Wi-Fi, сотовых сетях, спутниковых линиях или удаленных WAN-маршрутах. Сеть может тихо отказать, не закрыв соединение корректно. Keepalive помогает выявить такое состояние.

Отключение и повторное подключение

Клиент может штатно отключиться, отправив пакет DISCONNECT. Он также может исчезнуть неожиданно из-за потери питания, сбоя сети, ошибки прошивки или потери сигнала. Затем брокер применяет правила сессии и последнего сообщения, настроенные для этого клиента.

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

Имена тем и маршрутизация сообщений

Темы — это текстовые пути, используемые для классификации сообщений. Тема может выглядеть как иерархия, например building/floor1/room102/temperature или factory/line3/motor7/status. Издатели отправляют сообщения в темы, а подписчики получают сообщения из тем, на которые они подписаны.

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

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

Поток публикации и подписки

Публикация данных

Когда клиент публикует данные, он отправляет брокеру пакет PUBLISH. Пакет содержит имя темы, полезную нагрузку, уровень качества обслуживания, флаг сохранения и идентификатор пакета, если он требуется выбранным уровнем QoS.

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

Получение подписок

Клиент подписывается, отправляя пакет SUBSCRIBE с одним или несколькими фильтрами тем. Брокер отвечает SUBACK и начинает доставлять этому клиенту совпадающие сообщения согласно запрошенному и предоставленному уровню QoS.

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

Удаление интереса

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

Это позволяет приложениям динамически менять интерес к данным. Например, панель может подписаться на одно здание, пока пользователь его просматривает, а затем отменить подписку при переходе к другому объекту.

Модель публикации/подписки позволяет производителям и потребителям данных развиваться независимо, а брокер управляет маршрутизацией, поведением сессий и контролем доставки.

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

QoS 0: не более одного раза

QoS 0 — самый простой уровень доставки. Сообщение отправляется один раз, и на уровне MQTT получатель не подтверждает его получение. Если сообщение потеряно, протокол не передает его повторно.

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

QoS 1: как минимум один раз

QoS 1 требует подтверждения. Отправитель повторно передает сообщение, если не получает подтверждение. Это повышает надежность доставки, но получатель может получить дубликаты.

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

QoS 2: ровно один раз

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

Этот уровень можно использовать, когда повторная обработка вредна. Однако многие реальные развертывания используют QoS 0 или QoS 1, потому что они дают лучший баланс между производительностью и надежностью.

Сохраненные сообщения и последнее известное состояние

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

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

Сохраненные сообщения следует использовать осторожно. Они полезны для состояния, но не всегда подходят для потоков событий. Сохраненное событие «дверь открыта» может ввести нового подписчика в заблуждение, если оно уже не актуально. Темы состояния и темы событий следует проектировать отдельно.

Поведение сессии и офлайн-доставка

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

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

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

Последние сообщения при неожиданном отказе

Сообщение последней воли позволяет клиенту определить сообщение, которое брокер должен опубликовать, если клиент неожиданно отключится. Это помогает другим системам обнаружить отказ устройства, потерю сети или аварийное завершение.

Например, устройство может настроить сообщение завещания в теме состояния, такой как device/123/status. Если устройство потеряет питание без штатного отключения, брокер опубликует настроенное сообщение offline.

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

Безопасность и контроль доступа

Аутентификация

Брокер должен проверить личность клиента перед предоставлением доступа. Аутентификация может использовать имя пользователя и пароль, клиентские сертификаты, токены, учетные данные API или интеграцию с внешней системой идентификации.

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

Авторизация

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

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

Шифрование

Шифрование TLS защищает данные при передаче между клиентами и брокером. Это важно, когда сообщения проходят через публичные сети, сотовые сети, облачные соединения или недоверенную инфраструктуру.

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

Модели развертывания

От устройства в облако

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

Основные вопросы проектирования — безопасность, устойчивость сети, идентичность устройств, объем сообщений и масштабирование на стороне облака.

Агрегация через пограничный шлюз

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

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

Локальный брокер для систем площадки

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

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

Применение в подключенных системах

Промышленный мониторинг

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

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

Умные здания

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

Это упрощает организацию данных и помогает правилам автоматизации подписываться только на нужные события или состояния.

Энергия и учет

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

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

Подключенные автомобили и мобильность

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

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

Потребительская и домашняя автоматизация

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

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

Производительность и масштабируемость

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

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

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

Уровень QoS также влияет на производительность. QoS 2 дает более строгую семантику доставки, но создает больше обменов пакетами. Для высокообъемной телеметрии практичнее использовать QoS 0 или QoS 1 с логикой на уровне приложения.

Распространенные ошибки проектирования

Неясные имена тем

Случайные или несогласованные имена тем усложняют управление разрешениями, панелями, тревогами и аналитикой. План тем следует создать до крупномасштабного развертывания.

Использование сохраненных сообщений для событий

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

Нет обработки дубликатов

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

Слабое управление учетными данными

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

Игнорирование отказа брокера

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

MQTT работает хорошо, когда темы, сессии, QoS, сохраненное состояние, безопасность и емкость брокера проектируются совместно, а не настраиваются как отдельные параметры.

Обслуживание и мониторинг

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

Состояние клиентов также должно быть видимым. Повторные переподключения, истекшие сессии, дублирующиеся ID клиентов, аномальные скорости публикации и неожиданный доступ к темам могут указывать на неисправности устройств или проблемы безопасности.

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

Часто задаваемые вопросы

Может ли MQTT работать поверх WebSocket?

Да. Многие брокеры поддерживают MQTT через WebSocket, позволяя браузерным приложениям и веб-панелям обмениваться данными через удобные для веба транспортные пути.

Подходит ли он для передачи больших видео или файлов?

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

Что происходит, если два клиента используют один и тот же идентификатор клиента?

Многие брокеры отключают существующего клиента, когда новый клиент подключается с тем же идентификатором. Уникальные идентификаторы клиентов важны для стабильного поведения сессий.

Может ли один брокер подключаться к другому брокеру?

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

Как планировать имена тем?

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