Содержание
MQTT (MQ Telemetry Transport) — это легковесный протокол обмена сообщениями, работающий по модели «издатель—подписчик». Он предназначен для телеметрии между машинами (M2M) в средах с низкой пропускной способностью. Это самый распространенный протокол передачи сообщений для Интернета вещей (IoT).
MQTT представляет собой набор правил, который определяет, как устройства IoT публикуют данные и подписываются на них через Интернет. Этот протокол используется для обмена сообщениями и данными для IoT и промышленного IoT (IIoT), например встроенными устройствами, датчиками, промышленными программируемыми логическими контроллерами и другими устройствами.
Отправитель (издатель) и получатель (подписчик) связываются с использованием тем (топиков) и разделены между собой. Связью между ними управляет брокер MQTT. Брокер MQTT фильтрует все входящие сообщения и распределяет их между соответствующими подписчиками.
Протокол MQTT создан Энди Стэнфордом-Кларком (IBM) и Арленом Ниппером (Cirrus Link) в 1999 году для подключения систем телеметрии нефтяного трубопровода через спутник. Этот протокол должен был отличаться минимальным потреблением заряда аккумулятора и минимальной полосой пропускания. Изобретатели сформулировали следующие требования к протоколу:
Эти цели до сих пор лежат в основе MQTT. Однако основной фокус протокола сместился с проприетарных встроенных систем на открытые примеры внедрения для Интернета вещей (IoT). MQTT больше не считается аббревиатурой. Теперь MQTT — это название протокола.
Несмотря на то, что MQTT изначально был закрытым, в 2010 году версия 3.1 вышла по лицензии royalty-free. В 2014 году MQTT стал официально утвержденным стандартом OASIS.
Существует два варианта и несколько версий MQTT:
Сейчас широко используется версия 3.1.1. Новейшая версия (5-я) утверждена в 2019 году имеет ограниченную поддержку. Клиент mosquitto поддерживает ее с выпуска 1.6, а клиент Paho (Python) — с версии 1.5.1. Спецификация MQTT-SN появилась в 2013 году. Она предназначена для работы с UDP, ZigBee и другими транспортами.
Ниже перечислены основные особенности MQTT.
В отличие от парадигмы «запрос-ответ» протокола HTTP, протоколом MQTT управляют события и он позволяет отправлять клиентам push-сообщения. Такая архитектура отделяет клиенты друг от друга, позволяя создать решение с высокой масштабируемостью без зависимостей между устройствами, генерирующими данные, и устройствами, принимающими их.
Подключение MQTT всегда устанавливается между клиентом и брокером. MQTT отделяет издателя от подписчика, и клиенты никогда не подключаются друг к другу напрямую. Подключения клиентов всегда обслуживаются брокерами. Для подключения клиент отправляет брокеру сообщение CONNECT. Брокер отвечает сообщением CONNACK с кодом состояния. После установки подключения брокер оставляет его открытым, пока клиент не отправит сообщение об отключении или подключение не будет разорвано.
Рассмотрим клиенты и брокеры подробнее.
Клиентами MQTT являются как издатели, так и подписчики. Они называются издателями и подписчиками в зависимости от того, что делает клиент в определенный момент: публикует сообщения или подписан на их получение. В одном и том же клиенте MQTT может быть реализована функциональность издателя и подписчика. Клиентом MQTT является любое устройство, от микроконтроллера до полнофункционального сервера, на котором выполняется библиотека MQTT и которое подключается к брокеру MQTT по сети. Например, клиентом MQTT может быть очень маленькое устройство с ограниченными ресурсами и минимальной библиотекой, подключенное по беспроводной сети. Также клиентом MQTT может быть типичный компьютер, на котором используется графический клиент MQTT для тестирования. Реализация протокола MQTT для клиента очень проста, поэтому он идеально подходит для маленьких устройств. Клиентские библиотеки MQTT доступны для множества языков программирования, в том числе следующих:
Брокер находится в центре любого протокола, работающего по модели «издатель—подписчик». Некоторые реализации брокеров позволяют им обслуживать миллионы одновременно подключенных клиентов MQTT.
Брокер отвечает за получение всех сообщений, их фильтрацию, определение подписчиков для каждого сообщения и его отправку соответствующим клиентам. Также он хранит данные для всех клиентов с постоянными сеансами, в том числе подписки и пропущенные сообщения. Кроме того, брокер выполняет аутентификацию и авторизацию клиентов. Обычно брокер является расширяемым, что упрощает пользовательскую аутентификацию, авторизацию и интеграцию в серверные системы. Интеграция особо важна, потому что брокер часто является тем компонентом, который напрямую связан с Интернетом, обслуживает множество клиентов и должен отправлять срообщения анализироующим и обрабатывающим системам. Поскольку через брокер проходят все сообщения, он должен быть масштабируемым, интегрируемым в серверные системы, простым в отслеживании и устойчивым к сбоям.
В MQTT слово «тема» означает строку в кодировке UTF-8, которую брокер использует для фильтрации сообщений для каждого подключенного клиента. Тема включает в себя один или несколько уровней. Уровни отделяются друг от друга косой чертой (разделитель уровней темы):
По сравнению с очередью сообщений темы MQTT очень легковесны. Клиенту не нужно создавать требуемую тему перед публикацией или подпиской. Брокер принимает тему без какой-либо предварительной инициализации.
Каждая тема должна содержать по крайней мере один символ. В строке темы допускаются пробелы. Темы чувствительны к регистру. Например, office/temperature и Office/Temperature — это две разных темы. Даже символ косой черты является допустимой темой.
Когда клиент подписывается на тему, он может подписаться на конкретную тему опубликованного сообщения или использовать подстановочные символы для подписки на несколько тем одновременно. Подстановочный символ может использоваться только для подписки на темы и не может использоваться для публикации. Существует два подстановочных символа: одноуровневый и многоуровневый.
Одноуровневый подстановочный символ заменяет один уровень темы. Для этого используется символ плюса (+).
+ office/room1/humidity
+ office/conference-room/humidity
Но она не будет соответствовать указанным ниже результатам:
– home/room1/humidity
– office/room1/temperature
Многоуровневый подстановочный символ охватывает несколько уровней темы. Для этого используется символ диеза (#). Чтобы брокер мог определить, какие темы сопоставлять, этот подстановочный символ должен быть последним в теме, а перед ним должна быть косая черта.
+ office/room1/humidity
+ office/room1/temperature
Ей не будут соответствовать такие темы:
– home/room1/temperature
– office/conference-room/humidity
Когда клиент подписывается на тему с многоуровневым подстановочным символом, он получает все сообщения темы, начинающиеся с шаблона передж подстановочны символом, независимо от количества уровней в теме. Если в качестве темы указан только этот подстановочный символ (#), то будут получены все сообщения, отправляемые брокером MQTT. Если вы ожидаете высокой пропускной способности, подписываться с указанием только многоуровневого подстановочного символа не рекомендуется.
В принципе, вы можете называть темы MQTT, как захотите. Однако есть исключение. Темы, начинающиеся с символа $, имеют другое предназначение. Они не включатся в подписку с использованием многоуровневого подстановочного символа (#). Эти темы зарезервированы для внутренней статистики брокера MQTT. Клиенты не могут публиковать сообщения в этих темах. На данный момент официального стандарта для таких тем нет.
MQTT — это двоичный протокол, в котором управляющие элементы представлены двоичными байтами, а не строками текста. MQTT использует формат команды и подтверждения команды. То есть, с каждой командой связано соответствующиее подтверждение.
Пакет MQTT состоит из двухбайтового фиксированного заголовка (присутствует всегда), переменного заголовка (присутствует не всегдя) и полезной нагрузки (присутствует не всегда).
Поле фиксированного заголовка состоит из управляющего поля и поля длины пакета (поле переменной длины).
Минимальный размер поля длины пакета составляет 1 байт и подходит для сообщений общей длиной менее 127 байт (не включая поля управления и длины). Максимальный размер пакета — 256 МБ. Пакеты длиннее 127 и короче 16383 байт будут иметь размер поля длины 2 байта и так далее. Примечание. Используется 7 бит, а 8-й является битом продолжения.
Минимальный размер пакета — 2 байта: однобайтовое управляющее поле и однобайтовое поле длины пакета. Например, сообщение DISCONNECT состоит всего из двух байтов.
8-битовое управляющее поле — это первый байт двухбайтового фиксированного заголовка. Оно разделено на два 4-битовых поля и содержит все команды и ответы протокола.
Первые 4 наиболее значимых бита являются полем команды или типа сообщения, а вторые используются как управляющие флаги. Например, команда CONNECT имеет двоичный код 0001 (десятичный = 1), CONNACK — 0010 (2), PUBLISH — 0100 (3), DISCONNECT — 1110 (14). Поскольку это старшие биты, фактические коды будут отсчитываться от пятого до восьмого бита, например CONNECT — 00010000 (16), CONNACK — 00100000 (32) и так далее.
Хотя четырьмя битами можно представить 16 управляющих флагов, лишь некоторые используются часто. Сообщение PUBLISH использует все биты, как показано ниже:
| Бит 3 | Бит 2 | Бит 1 | Бит 0 |
| DUP | QoS | QoS | RETAIN |
Флаг DUP используется при повторной публикации сообщения с QoS 1 или 2.
Флаги QoS используются при публикации с указанием уровня QoS (0 — один раз, не гарантированно, 1 — как минимум один раз, гарантированно, 2 — только один раз, гарантированно).
Флаг RETAIN также используется при публикации.
Каждый из байтов поля длины использует 7 битов для указания длины, а MSB используется как флаг продолжения.
Как отмечено выше, этот заголовок не всегда присутствует в сообщении MQTT. Он необходим в некоторых типах сообщений MQTT для передачи дополнительной управляющей информации. Этот заголовок похож, но не одинаков для разных типов сообщений.
В конце концов, пакет может содержать полезную нагрузку. Она является необязательным полем и содержит разную информацию для разных типов пакетов. Обычно это поле содержит отправляемые данные. Например, для пакета CONNECT рабочей нагрузкой является идентификатор клиента, а также имя пользователя и пароль, если они есть. Для пакета PUBLISH это публикумое сообщение.
Первым байтом пакета CONNECT будет 00010000. Команда CONNECT имеет код 1, поэтому старшая четверка битов будет иметь значение 0001, а поскольку флаги отсутствуют, младшие 4 бита будут нулевыми.
Вторым байтом будет длина остальной части пакета. Она складывается из длины заголовка переменной длины и длины полезной нагрузки. Ниже приведен формат заголовка переменной длины и полезной нагрузки пакета CONNECT.
Когда речь идет о безопасности сети IoT, необходимо принять во внимание три базовых концепции: идентификатор пользователя, аутентификацию и авторизацию.
В каждом сценарии MQTT участвуют клиент и брокер. Как уже говорилось ранее, клиентом может быть устройство от микроконтроллера до сервера. Любое устройство, которое подключается к брокеру, считается клиентом.
Брокер получает все сообщения и координирует их публикацию для подписанных клиентов. Брокер несет ответственность за поддержание постоянных подключений, а также идентификацию и авторизацию для передачи данных клиентам MQTT. Подключение MQTT устанавливается только между одним клиентом и брокером.
Для подключения к брокеру клиент должен передать ему идентификатор клиента в сообщении CONNECT. В идеале каждый клиент имеет уникальный идентификатор клиента. Большинство устройств снабжены универсальным уникальным идентификатором (UUID) или MAC-адресом сетевого устройства для подключения клиента.
Получив сообщение CONNECT, брокер устанавливает, имеет ли право клиент подключиться к брокеру, проверяя идентификатор, имя пользователя и пароль.
Кроме аутентификации с использованием имени пользователя и пароля протокол MQTT позволяет проводить аутентификацию с использованием сертификата X.509. Для этого методом шифрования следует выбрать TLS (Transport Layer Security) .
Когда клиент подключается к брокеру, он может выполнять два действия: публиковать и подписываться на темы. Темы — это основной ресурс, доступный клиентам, и для безопасности системы они требуют авторизации. Без нее любой клиент смог бы подключиться на любую тему, доступную в брокере.
Самыми распространенными типами авторизации являются контроль доступа на основе ролей (Role Based Access Controls, RBAC) и список контроля доступа (Access Control List, ACL).
При использовании RBAC роль предоставляет уровень абстракции между клиентом и основным ресурсом, то есть, в данном случае темами. С определенными ролями связаны определенные разрешения, что позволяет брокеру авторизовать клиента для публикации или подписки на определенную тему.
ACL связывает определенные клиенты со списаом разрешений. Эти разрешения предоставляют политики, определяющие темы, на которые клиент может подписаться или в которых он может публиковать.
Также возможна авторизация с использованием токенов доступа. Они позволяют ограничить разрешения клиента определенной областью, давая возможность предотвратить несанкционированный доступ для чтения или записи данных, который мог бы оказать нежелательное влияние на другие клиентские устройства, подключенные к вашей инфраструктуре IoT.
MQTT используется во многих примерах внедрения и отраслях промышленности. На сайте MQTT приведены следующие примеры внедрения.
HiveMQ: Приложение BMW для совместного использования автомобилей полагается на надежность подключения, которую обеспечивает HiveMQ.
EMQ помогает SAIC Volkswagen в создании платформы IoV (Интернет транспортных средств).
Надежное подключение IoT обеспечивает мониторинг автономных дронов Matternet в режиме реального времени.
MQTT используется для мониторинга электростанций турецкой компании Çelikler Holding.
Пример внедрения телеметрии IBM: мониторинг и контроль электроэнергии в доме.
Пример внедрения телеметрии IBM: домашний мониторинг пациентов.
Система безопасности для интеллектуального дома eFon Technology доверяет решению MQTT компании Bevywise.
EMQ помогает внедрять инновации сферы IoT в нефтехимической промышленности.
CASO Design создает устройства для интеллектуальной кухни.
IoT развернут в железнодорожной системе Германии Deutsche Bahn AG.
Прокси (proxy), или прокси-сервер — это программа-посредник, которая обеспечивает соединение между пользователем и интернет-ресурсом. Принцип…
Согласитесь, было бы неплохо соединить в одно сайт и приложение для смартфона. Если вы еще…
Повсеместное распространение смартфонов привело к огромному спросу на мобильные игры и приложения. Миллиарды пользователей гаджетов…
В перечне популярных чат-ботов с искусственным интеллектом Google Bard (Gemini) еще не пользуется такой популярностью…
Скрипт (англ. — сценарий), — это небольшая программа, как правило, для веб-интерфейса, выполняющая определенную задачу.…
Дедлайн (от англ. deadline — «крайний срок») — это конечная дата стачи проекта или задачи…