Обзор протокола MQTT

задняя часть

Обзор

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

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

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

1. Реализация протокола MQTT


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

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

Сообщение, передаваемое по MQTT, делится на две части: тему (Topic) и полезную нагрузку (payload): (1) Тема, которую можно понимать как тип сообщения, после подписки подписчика (Subscribe) он получит содержимое сообщения (полезную нагрузку) темы; (2) Полезная нагрузка, которую можно понимать как содержимое сообщения, относится к конкретному содержимому, которое будет использоваться подписчиком.

2. Терминология в протоколе MQTT


2.1 Подписка

Подписка включает тематический фильтр (Topic Filter) и максимальное качество обслуживания (QoS). Подписки связаны с сеансом. Сеанс может содержать несколько подписок. Каждая подписка в каждом сеансе имеет отдельный фильтр тем.

2.2 Сессия

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

2.3 Название темы

Подключитесь к тегу сообщения приложения, который соответствует подписке сервера. Сервер отправит сообщение каждому клиенту, подписавшемуся на соответствующий тег. Системная тема: определяя тему, начинающуюся с $SYS, вы можете просматривать некоторую системную информацию, такую ​​как количество клиентских подключений и т. д. Подробное введение:GitHub.com/Mother Tiantian/Мать Тяньтянь.…

2.4 Тематический фильтр

Фильтр с подстановочными знаками для имен тем, используемый в выражениях подписки, для представления нескольких тем, соответствующих подписке. Многоуровневый сопоставитель # одноуровневый сопоставитель + Для обсуждения дополнительных тем перейдите на вики github.GitHub.com/Mother Tiantian/Мать Тяньтянь.…

2.5 Полезная нагрузка

Контент, специально полученный подписчиком сообщения.

3. Сохраняйте сообщения и завещания


Сохраненные сообщения

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

Последняя воля и завещание

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

4. Качество службы сообщений


Существует три вида QOS качества службы публикации сообщений (Quality of Service):

4.1 «Не более одного раза»

至多一次

Публикация сообщений полностью зависит от базовой сети TCP/IP. Возможна потеря или дублирование сообщений. Этот уровень можно использовать в случае данных датчика окружающей среды, не имеет значения, если одна прочитанная запись потеряна, потому что скоро будет вторая передача.

4.2 «Хоть раз»

至少一次

Сообщение PUBACK является ответом на сообщение PUBLISH с уровнем QoS 1. Сообщение PUBACK отправляется сервером в ответ на сообщение PUBLISH от издателя, и подписчик также отвечает на сообщение PUBLISH от сервера. Когда издатель получает сообщение PUBACK, он отбрасывает исходное сообщение, поскольку оно также было получено (и зарегистрировано) сервером.

Если издатель или сервер не получит сообщение PUBACK в течение определенного периода времени, оно будет передано повторно. Такой подход гарантирует получение сообщений, но может произойти дублирование сообщений.

4.3 «Только один раз»

只有一次

Сообщение PUBREC является ответом на сообщение PUBLISH с уровнем QoS 2. Это второе сообщение потока протокола QoS уровня 2. На сообщение PUBREC сервер отвечает на сообщение PUBLISH от издателя, или подписчик отвечает на сообщение PUBLISH от сервера. Когда издатель или сервер получит сообщение PUBREC, он ответит на сообщение PUBREL.

Сообщение PUBREL — это ответ на PUBREC от издателя или ответ сервера на сообщение PUBREC от подписчика. Это третье сообщение в потоке протокола QoS 2. Когда сервер получает сообщение PUBREL от издателя, сервер отправляет сообщение PUBLISH подписчику и сообщение PUBCOMP издателю. Когда подписчик получает сообщение PUBREL с сервера, делает сообщение доступным для приложения и отправляет сообщение PUBCOMP на сервер.

Сообщение PUBCOMP — это ответ сервера на сообщение PUBREL от издателя или ответ подписчика на сообщение PUBREL от сервера. Это четвертое и последнее сообщение в потоке протокола QoS 2. Когда издатель получает сообщение PUBCOMP, он отбрасывает исходное сообщение, поскольку оно уже отправлено на сервер.

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


Приложение: Реализация клиента/сервера MQTT на различных языках программирования

Name Language Type Last release License
Adafruit IO Ruby on Rails, Node.js Client 2.0.0 ?
flespi C Broker ? Proprietary License
M2Mqtt C# Client 4.3.0.0 Eclipse Public License 1.0
Machine Head Clojure Client 1.0.0 Creative Commons Attribution 3.0 Unported License
moquette Java Broker 0.10 Apache License 2.0
Mosquitto C, Python Broker and client 1.4.15 Eclipse Public License 1.0, Eclipse Distribution License 1.0 (BSD)
Paho MQTT C, C++, Java, Javascript, Python, Go Client 1.3.0 Eclipse Public License 1.0, Eclipse Distribution License 1.0 (BSD)
SharkMQTT C Client 1.5 Proprietary License
VerneMQ Erlang/OTP Broker 1.4.1 Apache License 2.0
wolfMQTT C Client 0.14 GNU Public License, version 2
MQTTRoute C, Python Broker 1.0 Proprietary License
HiveMQ Java Broker 3.4.0 Proprietary License
SwiftMQ Java Broker 11.1.0 Proprietary License
JoramMQ Java Broker 11.1.0 Proprietary License