Что такое протокол MQTT? Эта статья расскажет вам!

задняя часть внешний интерфейс
Что такое протокол MQTT? Эта статья расскажет вам!

Статья была впервые опубликована в моем паблике "Programmer cxuan", прошу внимания всех~

сделай как обещал!

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

Тогда требования читателя должны быть выполнены, так что теперь @ эта юная леди, приходите и слушайте класс!

Что такое протокол MQTT

Полное название протокола MQTT:Message Queuing Telemetry Transport, переводится как Message Queuing Transmission Probe, который является стандартом ISO, основанным наОпубликовать-подписатьсяПротокол сообщений режима, основанный на наборе протоколов TCP/IP, предназначен для повышения производительности оборудования сетевого оборудования и производительности сети. MQTT обычно используется в IoT, который представляет собой Интернет вещей, и широко используется в сценариях приложений промышленного уровня, таких как автомобили, производство, нефть и природный газ.

img

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

Основы MQTT

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

Вы можете быть немного скрытными в отношении этих понятий, почему он имеет характеристики xxx? Это нужно начать с проектирования MQTT.

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

  • Этот протокол должен быть прост в реализации;
  • Данные в этом протоколе должны легко передаваться, а стоимость потребления невелика;
  • Это соглашение должно обеспечивать управление качеством обслуживания;
  • Протокол ДОЛЖЕН поддерживать непрерывный контроль сеанса.
  • Предполагая, что данные являются независимыми, тип и формат передаваемых данных не применяются принудительно, и поддерживается гибкость.

Эти конструкции также являются сущностью MQTT.После непрерывной разработки MQTT стал необходимым протоколом обнаружения сообщений для Интернета вещей (IoT).Официально настоятельно рекомендуется версия MQTT 5.

Опубликовать - подписаться шаблон

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

Но модель публикации-подпискиpub/subДругое дело, модель публикации-подписки отправит издателю сообщениеpublisherс подписчиками, которые получают сообщенияsubscribersДля разделения издатели и подписчики не общаются напрямую, они даже не знают, существует ли другая сторона, а связь между ними контролируется сторонними компонентами.brokerиграет роль.

Наиболее важным аспектом pub/sub является разделение издателя и подписчика, которое имеет следующие три аспекта:

  • Пространственная развязка: издатель и подписчик не знают о существовании друг друга, например, не будет взаимодействия между IP-адресами и портами, не будет взаимодействия сообщений.
  • Разделение по времени: издатель и подписчик не обязательно должны работать одновременно.
  • СинхронизироватьSynchronizationРазделение: операции двух компонентов, таких как публикация и подписка, не будут прерываться во время процесса публикации или получения.

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

Масштабируемость

pub/sub масштабируется лучше, чем традиционная модель клиент-сервер из-за высоты брокера并行化, и основан на事件驱动режим. Масштабируемость также отражается в кэшировании сообщений и интеллектуальной маршрутизации сообщений.Также можно достичь миллионов подключений через агенты кластера и использовать балансировщики нагрузки для распределения нагрузки на большее количество отдельных серверов.Это всестороннее применение МКТТ. .

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

событийно-ориентированный编程范式, парадигма программирования — это концепция разработки программного обеспечения,Это относится к методу программирования или способу программированияНапример, объектно-ориентированное программирование и процедурное программирование представляют собой парадигму программирования, в которой поток программы в событийно-управляемом режиме определяется такими событиями, как действия пользователя (щелчки мыши, щелчки клавиатуры), выходные данные датчиков или сообщения из других программ или переданные. Программирование, управляемое событиями, является доминирующей парадигмой, используемой в графических пользовательских интерфейсах и других приложениях, таких как Интернет, которые сосредоточены на способности выполнять определенные действия в ответ на ввод пользователя, и это также относится к программированию драйверов.

фильтрация сообщений

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

У брокера есть несколько опций, которые можно фильтровать

  • Тематическая фильтрация

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

  • Контентная фильтрация

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

  • фильтрация по типам

При использовании объектно-ориентированных языков фильтрация типов на основе сообщений (событий) является относительно распространенным методом фильтрации.

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

Разница между MQTT и очередью сообщений

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

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

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

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

Hivemq теперь имеет открытый исходный код, а Hivemq Community Edition реализует спецификацию MQTT Broker и совместим с MQTT 3.1, 3.1.1 и MQTT 5. Клиент Hivemq MQTT — это реализация клиента MQTT на основе Java, совместимая с MQTT 3.1.1 и MQTT 5. Оба проекта могут быть в Hivemq GitHubgithub.com/hivemqнайти на.

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

Важные концепции MQTT

MQTT client

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

Клиент MQTT — это любое устройство, которое запускает библиотеку MQTT и подключается к брокеру MQTT по сети, который может варьироваться от микроконтроллеров до полноценных серверов. По сути, любое устройство, использующее MQTT с использованием протокола TCP/IP, можно назвать клиентом MQTT. Клиентская реализация протокола MQTT очень проста и понятна. Простота реализации — одна из причин, почему MQTT идеально подходит для небольших устройств. Клиентские библиотеки MQTT доступны для многих языков программирования. Например, Android, Arduino, C, C++, C#, Go, iOS, Java, JavaScript и .NET.

MQTT broker

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

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

MQTT Connection

MQTT основан на протоколе TCP/IP, поэтому и клиент MQTT, и брокер нуждаются в поддержке протокола TCP/IP.

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

сообщение сообщение

Пакеты сообщений MQTT в основном делятся на сообщения CONNECT и CONNACK.

CONNECT

Выше мы упоминали, что для инициализации соединения клиент должен отправить брокеру сообщение CONNECT.Если сообщение CONNECT имеет неправильный формат или сокет открыт (т.к. стек протоколов), это занимает слишком много времени или отправляется сообщение о соединении. Если время слишком велико, брокер закроет соединение.

Клиент MQTT отправляет соединение CONNECT, которое может содержать следующую информацию:

Позвольте мне объяснить, что такое концепция этой информации здесь

  • ClientId: Очевидно, это ID каждого клиента, то есть каждого клиента, подключенного к MQTT-брокеру. Этот идентификатор должен быть уникальным для каждого клиента и брокера.Если вам не нужно, чтобы брокер хранил состояние, вы можете отправить пустой ClientId, а пустой ClientId не будет иметь состояния. при этих обстоятельствах,ClientSessionНеобходимо установить значение true, иначе в соединении будет отказано.

Что такое clientSession мы поговорим ниже.

  • CleanSessionФлаг сеанса :CleanSession сообщает клиенту брокера, необходимо ли установить постоянный сеанс. В постоянном сеансе (CleanSession = false) брокер сохраняет все подписки клиента иКачество обслуживания (QoS)все потерянные сообщения для 1 или 2 подписанных клиентов. Если сессия не является постоянной (CleanSession = true), то брокер ничего не сохраняет для клиента и очищает всю информацию от предыдущих постоянных сессий.
  • Username/Password: MQTT отправит имя пользователя и пароль для аутентификации и авторизации клиента. Если эта информация не зашифрована и не хеширована, пароль будет отправлен в виде обычного текста. Поэтому, как правило, настоятельно рекомендуется шифровать и безопасно передавать имя пользователя и пароль. Брокеры, такие как HiveMQ, могут аутентифицироваться с помощью SSL-сертификатов, поэтому имя пользователя и пароль не требуются.
  • LastWillxxx: LastWillxxx представляет собой последнее желание. Клиент установит последнее желание при подключении к брокеру. Это последнее желание будет сохранено в брокере.аномальная причинаПри отключении от брокера брокер отправит последнее желание клиенту, подписавшемуся на эту тему (подписка на тему последнего желания).
  • keepAlive:keepAlive — это интервал взаимодействия клиента с брокером после установления соединения, обычно в секундах. Это время относится к максимальному времени, которое клиент и брокер могут выдержать без отправки сообщений.

После обсуждения сообщения CONNECT, отправляемого между клиентом и брокером для установления соединения, давайте поговорим о сообщении CONNACK, которое необходимо брокеру для подтверждения CONNECT.

CONNACK

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

  • SessionPresent: текущий идентификатор сеанса. Этот флаг сообщает клиенту, есть ли у текущего брокера постоянный сеанс для взаимодействия с клиентом. Флаг SessionPresent связан с флагом CleanSession: когда клиент подключается с CleanSession, для которого установлено значение true, SessionPresent всегда имеет значение false, поскольку нельзя использовать постоянный сеанс. Если для параметра CleanSession установлено значение false, возможны две возможности: если информация о сеансе для ClientId доступна и брокер сохранил информацию о сеансе, тогда SessionPresent имеет значение true, в противном случае, если информация о сеансе для ClientId отсутствует, тогда SessionPresent имеет значение false.

  • ReturnCode: Второй флаг в сообщении CONNACK — это флаг подтверждения соединения. Этот флаг содержит код возврата, сообщающий клиенту, была ли попытка подключения успешной. Флаг подтверждения подключения имеет следующие параметры.

Для получения подробной информации о каждом соединении ссылка может бытьdocs.oasis-open.org/Мать Тяньтянь/Мать Тяньтянь/V…

тип сообщения

выпуск

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

MQTT не зависит от данных, что означает, что данные определяются издателем — издатель решает, отправлять ли XML, JSON, двоичные данные или текстовые данные.

Структура сообщения PUBLISH в MQTT выглядит следующим образом.

  • Packet Identifier: Этот PacketId идентифицирует уникальный идентификатор сообщения между клиентом и брокером. packageId имеет значение только для уровней QoS выше нуля.
  • TopicName: Название темы представляет собой простую строку,/представляет собой иерархическую структуру.
  • Qos: Это число представляет уровень качества обслуживания.Существует три уровня уровня качества обслуживания: 0, 1 и 2. Уровень обслуживания определяет тип гарантии того, что сообщение будет доставлено клиенту или брокеру, а также определяет, будет ли сообщение потеряно.
  • RetainFlag: этот флаг указывает, что брокер установит флаг RETAIN, полученный недавно, какtrueСообщения хранятся на стороне сервера (в памяти или в файле).

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

  • Payload: это фактическое содержание каждого сообщения. MQTT не зависит от данных. Любой текст, изображения, зашифрованные данные и двоичные данные могут быть отправлены.
  • Dupflag: этот флаг указывает, что сообщение было продублировано и отправлено повторно из-за отсутствия подтверждения от ожидаемого клиента или брокера. Этот флаг актуален только для Qos больше 0.

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

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

подписка

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

  • Packet Identifier: этот PacketId такой же, как указанный выше PacketId, и оба представляют собой уникальный идентификатор сообщения.
  • ListOfSubscriptions: сообщение SUBSCRIBE может содержать несколько подписок клиента, и каждая подписка будет состоять из темы и QoS. Темы в сообщениях подписки могут содержать подстановочные знаки.

сообщение подтверждения

После того, как клиент отправит брокеру сообщение SUBSCRIBE, для подтверждения каждой подписки брокер отправит клиенту подтверждающее сообщение SUBACK. Этот SUBACK содержит packageId исходного сообщения SUBSCRIBE и список кодов возврата.

в

  • Packet Identifier: этот идентификатор пакета такой же, как у подписки.
  • ReturnCode: Брокер отправляет код возврата для каждой пары тема/Qos полученных сообщений SUBSCRIBE. Например, если сообщение SUBSCRIBE содержит пять сообщений о подписке, сообщение SUBACK содержит в ответ пять кодов возврата.

До сих пор мы обсуждали три типа сообщений, сообщения публикации-подписки-подтверждения, схемы этих трех сообщений следующие.

отписаться

Сообщение SUBSCRIBE соответствуетUNSUBSCRIBEПосле отправки этого сообщения брокер удалит подписку о клиенте. Таким образом, сообщение UNSUBSCRIBE похоже на сообщение SUBSCRIBE, у обоих есть packageId и список тем.

Подтвердить отписку

Отписаться также требует подтверждения от брокера. В это время брокер отправит сообщение клиенту.UNSUBACKсообщение, это сообщение UNSUBACK очень простое, просто идентификатор данных packageId.

Порядок отписки и подтверждения отписки следующий.

Когда клиент получает сообщение UNSUBACK от брокера, он может считать, что подписка в сообщении UNSUBSCRIBE была удалена.

Тема чата

Мы так много говорили о MQTT, но у нас не было хорошего разговора о Topic. В MQTT Topic относится к тому, как брокер фильтрует сообщения для каждого подключенного клиента.UTF-8нить. Тема — это иерархическая структура, которая может состоять из одной или нескольких тем. Каждая тема представлена/Сегментация.

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

подстановочный знак

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

одноуровневый подстановочный знак

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

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

myhome/groundfloor/+/temperatureСуществуют следующие методы согласования.

Многоуровневый подстановочный знак

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

Нижеmyhome/groundfloor/#Несколько примеров

Когда клиент подписывается на тему с многоуровневым подстановочным знаком, он будет получать все сообщения темы до подстановочного знака, независимо от того, насколько длинна или глубока тема. Если вы определите тему только как #, вы будете получать все сообщения.

У меня самого было шесть PDF-файлов, и вся сеть распространилась более чем на 10w +. После поиска «programmer cxuan» в WeChat и после официального аккаунта я ответил cxuan в фоновом режиме и получил все PDF-файлы.Эти PDF-файлы следующие

Шесть ссылок в формате PDF

Категории