Подробное объяснение протокола MQTT: модель публикации/подписки, три уровня QoS и новые возможности 5.0

Общий доступ к ресурсам Туториалы & Документы
,
1

Если вы занимались проектами в сфере Интернета вещей, то почти наверняка сталкивались с одним термином: MQTT. От умных лампочек дома до датчиков влажности почвы в поле, от станков на производственной линии до прокатных велосипедов у дороги — миллиарды устройств общаются друг с другом благодаря этому протоколу, появившемуся в 1999 году. Почему он стал фактическим стандартом для IoT? Чем именно он лучше HTTP? В этой статье мы разберём модель публикации/подписки, три уровня QoS, сообщения Last Will, новые возможности MQTT 5.0, сравним протоколы и приведём пример кода на Python, который можно сразу запустить, чтобы вы наконец-то разобрались с MQTT раз и навсегда.

1. Начнём с умной теплицы: почему для Интернета вещей одного HTTP недостаточно

Представьте типичную умную сельскохозяйственную теплицу: сотни датчиков температуры, влажности, освещённости и влажности почвы разбросаны по полю, питаются от аккумуляторов и солнечных панелей, передают данные в облако через нестабильную сеть 4G; облако же на основе этих данных в реальном времени дистанционно управляет рольставнями, вентиляторами и поливочными клапанами.

На этапе обсуждения решения первая реакция команды разработчиков часто звучит так: «Давайте использовать HTTP, просто отправим POST-запрос». Логика в целом верная, но в реальных условиях — слабой сети, сотен и тысяч устройств и необходимости работать 24/7 — все недостатки HTTP сразу становятся очевидными:

  • Облако не может само отправлять команды. HTTP работает по модели запрос/ответ: если облако хочет отправить команду вроде «включить вентилятор для охлаждения», оно может сделать это только во время следующего опроса со стороны устройства. Если интервал опроса большой, команда приходит с заметной задержкой; если короткий, тысячи устройств одновременно начинают опрашивать сервер, и сеть с сервером забиваются бессмысленными запросами.
  • Слишком большие заголовки. Один HTTP-запрос сам по себе может занимать несколько сотен байт только на заголовки, тогда как реальные данные устройства — например, значение температуры «26.5» — могут быть всего десять-двадцать байт. Это как отправить записку в огромной курьерской коробке.
  • Энергопотребление не выдерживает. Каждый обмен требует полноценного рукопожатия TCP + TLS, а для датчиков с батарейным питанием каждая лишняя секунда работы радиомодуля — это прямые расходы энергии.

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

2. Что такое MQTT: протокол, созданный «для экономии»

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

Происхождение MQTT хорошо объясняет его суть. В 1999 году Энди Стэнфорд-Кларк из IBM и Арлен Ниппер из компании Arcom разработали этот протокол для конкретной задачи: мониторинга нефтепровода, проходящего через пустынную местность, через спутниковый канал связи. Спутниковая связь оплачивалась по трафику, пропускная способность была крайне низкой, задержка высокой, а устройства мониторинга вдоль трубопровода работали от аккумуляторов. Поэтому цели были предельно простыми: сообщения должны быть маленькими, протокол должен экономить энергию, а сеть должна выдерживать обрывы связи.

Эти три простые цели и сформировали ДНК MQTT, которая сохранилась до наших дней:

  • Крайне маленький размер сообщений: минимальный фиксированный заголовок занимает всего 2 байта, тогда как HTTP-заголовки часто занимают сотни байт текста.
  • Лёгкость: MQTT работает поверх TCP (по умолчанию порт 1883, для TLS-шифрования — 8883), и MQTT-клиент может работать на микроконтроллере с несколькими десятками килобайт памяти.
  • Создан для нестабильных сетей: внутри уже есть heartbeat, Last Will и многоуровневый QoS — целый набор механизмов «самозащиты при обрыве связи».

Примерно в 2013 году IBM передала MQTT в стандартную организацию OASIS, в 2014 году MQTT 3.1.1 стал официальным стандартом OASIS, а позже был принят как международный стандарт ISO (ISO/IEC 20922). Сейчас наиболее распространены версии MQTT 3.1.1 и MQTT 5.0 (выпущена в 2019 году). 5.0 — рекомендуемая версия на сегодня, и ниже мы отдельно поговорим о ней.

eeClub — сообщество инженеров-электронщиков: https://bbs.eeclub.top/

Группа QQ для обмена опытом по электронике и микроконтроллерам: 2169025065

3. Основная архитектура: не «звонок», а «подписка на газету»

Чтобы понять MQTT, важнее всего разобраться с его моделью коммуникации — моделью публикации/подписки (Publish/Subscribe).

Модель HTTP-запроса/ответа похожа на телефонный звонок: вы набираете номер собеседника и общаетесь напрямую; обе стороны должны быть онлайн одновременно и знать «номер» друг друга.

Модель публикации/подписки больше похожа на подписку на газету: издательство печатает газету и отправляет её на почту (Broker), вы заранее регистрируетесь на почте с подписью «я хочу технологический раздел», и каждый день, когда газета приходит, почта доставляет её по списку подписчиков. Издательство не знает, кто именно читатель, а читателю не нужен телефон издательства — стороны полностью развязаны, а почта является единственным центральным узлом.

В этой модели есть три ключевые роли:

  • Publisher (издатель) — устройство или программа, которая создаёт сообщения, например датчик температуры, отправляющий показания.
  • Broker (брокер) — «почта» всей системы: принимает сообщения, распределяет их по темам между всеми подписчиками, а также управляет соединениями, сессиями, retained-сообщениями и другими служебными вещами. Это единственный участник, которому нужна доступность из публичной сети.
  • Subscriber (подписчик) — устройство или программа, которому интересны определённые сообщения, например мобильное приложение или информационная панель.

Важно понимать: издатель и подписчик — это только логические роли. Одно и то же устройство вполне может выполнять обе функции — например, камера публикует в облако предупреждения и одновременно подписывается на управляющие команды из облака. Кроме того, поскольку устройству нужно только самостоятельно подключаться к брокеру, ему не требуется публичный IP-адрес и не нужно открывать какие-либо порты, что автоматически снимает проблемы с NAT и фаерволами. Именно поэтому MQTT гораздо популярнее схем вроде «устройство открывает порт и ждёт подключения».

Topic: «номер почтового ящика» на почте

Как именно распределяются сообщения? С помощью Topic (темы). Topic — это строка в кодировке UTF-8, разделённая символами / по уровням, похожая на путь к файлу:

home/livingroom/temperature
home/livingroom/humidity
home/bedroom/temperature

При подписке можно использовать два типа подстановочных символов:

  • + — одноуровневый подстановочный символ: соответствует ровно одному уровню. Например, home/+/temperature позволит получать температуру и из гостиной, и из спальни.
  • # — многоуровневый подстановочный символ: соответствует любому числу уровней после себя и может стоять только в конце. Например, home/# позволит получать все сообщения под home.

4. Разберём ключевые возможности по порядку

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

1. QoS: три вида «курьерской доставки» сообщений

MQTT делит качество доставки сообщений (Quality of Service) на три уровня, которые можно представить как три вида курьерской службы:

  • QoS 0 — максимум один раз (At most once): как обычная почта без уведомления. Отправили — и всё, подтверждения и повторной отправки нет. Сообщение может потеряться, но дублироваться не будет. Подходит для данных, которые часто обновляются и потеря одного значения не критична, например для показаний, которые отправляются раз в секунду: если один кадр потерялся, через секунду придёт новый.
  • QoS 1 — хотя бы один раз (At least once): как заказное письмо. Получатель обязан ответить PUBACK-подтверждением, а отправитель повторяет отправку, если подтверждения не получил. Сообщение гарантированно дойдёт, но может продублироваться — если пакет подтверждения потеряется в пути, отправитель отправит сообщение повторно. Подходит для предупреждений, изменений состояния и других сообщений, где «лучше дубликат, чем потеря», но получатель должен обеспечить идемпотентность.
  • QoS 2 — ровно один раз (Exactly once): как курьерская доставка с подписью с обеих сторон. За счёт четырёхэтапного рукопожатия PUBREC, PUBREL и PUBCOMP гарантируется отсутствие и потерь, и дублей, но цена — максимальные накладные расходы и самая низкая скорость. Подходит для сценариев вроде биллинга, где «лишний списанный юань — уже авария».

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

Есть ещё один важный нюанс, который легко упустить: QoS указывается отдельно со стороны издателя и со стороны подписчика, а брокер при фактической доставке берёт меньшее из двух значений. Если издатель отправил сообщение с QoS 2, а подписчик подписался только на QoS 0, итоговая доставка будет выполнена с QoS 0. Поэтому, когда разбираетесь, «почему моё сообщение с высоким QoS потерялось», проверяйте обе стороны.

2. Retained-сообщения: записка, приклеенная к почтовому ящику

Обычные сообщения действуют по принципу «прочитал — исчезло»: если подписчик не в сети, после отправки сообщение пропадает. Но если при публикации установить Retain-флаг, брокер сохранит для этой темы последнее retained-сообщение, и любой новый подписчик, подписавшись на эту тему, сразу его получит.

Типичное применение: после подключения устройство публикует своё состояние, например «online» или текущее положение переключателя, с Retain. Тогда приложение в любой момент сможет сразу увидеть актуальное состояние устройства, не дожидаясь следующего отчёта. Важно: для каждой темы хранится только одно retained-сообщение, новое заменяет старое. Чтобы очистить retained-сообщение для определённой темы, достаточно опубликовать в эту тему retained-сообщение с пустой полезной нагрузкой.

3. Last Will (LWT): «последнее слово» устройства

Last Will and Testament (сообщение Last Will) — одна из самых человечных функций MQTT. При подключении к брокеру клиент может заранее зарегистрировать правило: «Если я внезапно исчезну (аномально отключусь), отправьте вместо меня вот это сообщение».

Например, камера при подключении регистрирует Last Will camera/01/status = "offline" (Retained). Если устройство потеряет питание или сеть, и соединение будет разорвано ненормально, брокер опубликует это сообщение от его имени, и все подписчики сразу узнают, что «эта камера недоступна». В сочетании с Retained пользователь, открывший приложение позже, тоже увидит состояние offline.

4. Keep Alive: heartbeat, чтобы убедиться, что обе стороны ещё живы

TCP довольно медленно обнаруживает «зависание» удалённой стороны, поэтому MQTT добавляет heartbeat на прикладном уровне: при подключении клиент и брокер договариваются об интервале Keep Alive (например, 60 секунд), и в периоды простоя клиент отправляет крошечное сообщение PINGREQ, а брокер отвечает PINGRESP. Если брокер в течение 1,5-кратного интервала Keep Alive не получает от клиента ни одного сообщения, он считает его мёртвым, разрывает соединение и запускает отправку Last Will.

5. Clean Session: после переподключения брокер помнит меня?

С помощью флага Clean Session клиент сообщает брокеру, нужно ли сохранять сессию. Если установлено 0 (постоянная сессия), брокер запоминает подписки этого клиента и сообщения QoS 1/2, которые он пропустил в офлайне, а после переподключения досылает их; если 1 — после переподключения всё начинается с нуля.

В MQTT 5.0 этот механизм разделили на Clean Start (начинать ли с чистого состояния) и Session Expiry Interval (время жизни сессии), что позволяет описывать поведение точнее — например, хранить сессию 24 часа, а не выбирать только между «вечно» и «не хранить».

6. Структура сообщений: предельное сжатие от 2 байт

Сообщение MQTT состоит из трёх частей: фиксированного заголовка, изменяемого заголовка и полезной нагрузки. В первом байте фиксированного заголовка старшие 4 бита задают тип сообщения (CONNECT, PUBLISH, SUBSCRIBE, PINGREQ и т. д.; всего 14 типов), младшие 4 бита — флаги; далее идёт поле «оставшейся длины» с переменной кодировкой, которое может занимать минимум 1 байт. То есть heartbeat-пакет в сумме занимает всего 2 байта — именно в этом и заключается «лёгкость» MQTT.

5. MQTT 5.0: очень добротное обновление

MQTT 5.0, выпущенная в 2019 году, сохранила лёгкость протокола и при этом закрыла множество инженерных недостатков:

  • Reason Code (код причины): почти все ответные сообщения теперь содержат стандартизированный код причины, поэтому отказ соединения или ошибка подписки больше не выглядят как туманное «не удалось», а прямо объясняют, почему.
  • Properties (свойства): сообщения могут переносить гибкие пары «ключ—значение» с метаданными; на этой системе построено множество новых возможностей.
  • Shared Subscription (совместная подписка): несколько подписчиков могут объединяться в группу потребления (например, $share/group1/topic), и одно сообщение доставляется только одному участнику группы, что естественным образом даёт балансировку нагрузки — в эпоху 3.1.1 для этого приходилось сильно изворачиваться.
  • Message Expiry Interval (срок жизни сообщения): при публикации можно задать время действия сообщения; просроченные офлайн-сообщения больше не досылаются, чтобы устройство после подключения не получало лавину устаревших команд.
  • Другие улучшения: псевдонимы тем (короткие номера вместо длинных имён тем для экономии трафика), управление потоком через Receive Maximum, уведомления о принудительном разрыве со стороны сервера, поддержка модели запрос-ответ через Response Topic и т. д.

Если коротко: 3.1.1 достаточно, 5.0 удобнее, а для новых проектов лучше сразу выбирать 5.0.

6. Сравнение: MQTT против HTTP, CoAP и WebSocket

Сказать, что MQTT хорош, недостаточно. Если сравнить его с другими протоколами, его место становится гораздо понятнее:

Критерий MQTT HTTP CoAP WebSocket
Модель связи публикация/подписка запрос/ответ запрос/ответ (REST-подобный) двунаправленный поток данных
Транспортный уровень TCP TCP UDP TCP
Минимальные накладные расходы 2 байта сотни байт заголовков 4 байта от 2 байт заголовка кадра
Отправка команд из облака встроена не поддерживается (нужен polling) требуется Observe поддерживается
Механизмы надёжности встроенный трёхуровневый QoS зависит от TCP опциональное подтверждение/повтор нет, нужно строить самостоятельно
Адаптация к низкому энергопотреблению отличная слабая отличная (UDP экономичнее) средняя
Типичные сценарии подключение устройств к облаку, телеметрия, удалённое управление веб-страницы, открытые API, передача файлов сенсорные сети с крайне ограниченными ресурсами интерактив в реальном времени в браузере, чаты

Коротко: HTTP создан для людей, WebSocket — для браузера, CoAP — для предельно ограниченных устройств, а MQTT — для сценариев «огромное число устройств + слабая сеть + двунаправленная связь в реальном времени».

7. Типичные сценарии применения: возможно, вы используете это каждый день

  • Умный дом: MQTT — крупнейшая базовая площадка в этой области. В open-source-платформе Home Assistant множество устройств подключается через MQTT; ваши лампы, розетки и датчики температуры/влажности вполне могут прямо сейчас держать постоянное соединение с каким-нибудь брокером.
  • Промышленный Интернет вещей (IIoT): PLC, станки и приборы на производственной линии отправляют данные на фабричный брокер, а MES-система и мониторинговые панели подписываются на нужные данные. В облачных платформах вроде Alibaba Cloud IoT и AWS IoT Core основным протоколом на уровне подключения устройств также является MQTT.
  • Интернет транспорта: платформы управления автопарком через MQTT отправляют команды тысячам автомобилей и собирают данные об их состоянии; уровни QoS идеально соответствуют разным требованиям — например, данные о местоположении можно потерять, а команда на удалённую блокировку должна дойти обязательно.
  • Экологический и сельскохозяйственный мониторинг: датчики почвы в поле и станции контроля качества воды у водохранилищ работают от аккумуляторов и солнечных панелей, поэтому низкое энергопотребление MQTT и возможность буферизации при обрывах связи здесь критически важны.

8. Практика: за 10 минут отправьте своё первое MQTT-сообщение

Теория без практики мало что даёт, а порог входа здесь на самом деле очень низкий.

Выбор брокера

  • EMQX: отечественная open-source-платформа с высокой производительностью и дружелюбной китайской документацией; есть публичный тестовый брокер broker.emqx.io, идеальный вариант для первых шагов.
  • Mosquitto: проект Eclipse Foundation, написан на C, чрезвычайно лёгкий, работает даже на Raspberry Pi, хорошо подходит для локальной отладки.
  • HiveMQ: корпоративное решение на Java с качественной коммерческой поддержкой.

Выбор клиентского инструмента

  • MQTTX: кроссплатформенный десктопный клиент от EMQ (есть также CLI и веб-версия), интуитивный интерфейс, незаменим для работы с протоколом.
  • mqtt-cli / mosquitto_pub, mosquitto_sub: удобные инструменты для тех, кто предпочитает командную строку.

Пример на Python, который можно запустить

Установите зависимости: pip install paho-mqtt

Подписчик (subscriber.py):

import paho.mqtt.client as mqtt

def on_connect(client, userdata, flags, reason_code, properties):
    print("已连接:", reason_code)
    client.subscribe("home/livingroom/temperature", qos=1)

def on_message(client, userdata, msg):
    print(f"收到 [{msg.topic}] {msg.payload.decode()}")

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.emqx.io", 1883, 60)
client.loop_forever()

Издатель (publisher.py):

import paho.mqtt.client as mqtt

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)
client.connect("broker.emqx.io", 1883, 60)
client.publish("home/livingroom/temperature", "26.5", qos=1)
client.disconnect()
print("已发送")

Сначала запустите подписчика, затем издателя — и вы увидите в терминале подписчика то самое «26.5». Это и есть самый маленький «heartbeat» в мире Интернета вещей.

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

9. Итог

Успех MQTT не в том, что он самый продвинутый, а в том, что он предельно сдержан: маленькие сообщения, низкое энергопотребление и устойчивость к слабой сети, вынужденно рождённые в жёстких условиях «нефтепровода + спутникового канала», идеально попали в ключевые потребности огромного числа IoT-устройств. Развязанная модель публикации/подписки, гибкая надёжность трёх уровней QoS, Last Will и retained-сообщения — все эти практичные решения, построенные вокруг простой мысли «устройство может отключиться», сделали MQTT фактическим стандартным протоколом Интернета вещей сегодня.

Если вы занимаетесь умными устройствами или backend-разработкой, мой совет такой: сначала попробуйте публикацию и подписку через публичный брокер и MQTTX, а затем внимательно прочитайте про QoS и механизм сессий. Когда разберётесь с этими двумя вещами, примерно на 80% поймёте MQTT.

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

Дополнительные материалы для изучения

Рекомендуем почитать

English Version of the Article: https://blog.zeruns.top/archives/96.html