Как общаются машины — протокол MQTT


    В предыдущей статье мы разбирали протокол Modbus, являющийся стандартом де-факто в промышленности для M2M-взаимодействия. Разработанный в далеком 1979 году, он имеет ряд существенных недостатков, которые решает MQTT.

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

    Главные особенности протокола MQTT:

    • Компактный и легковесный — минимальные накладные расходы на пересылку данных, для экономии трафика.
    • Устойчивость к потерям — гарантированная доставка в условиях нестабильных сетевых подключений.
    • Асинхронный — позволяет обслуживать большое количество устройств, и не зависит от сетевых задержек.
    • Поддержка QoS — возможность управлять приоритетом сообщений и гарантировать доставку сообщения адресату.
    • Динамическая конфигурация — не требует предварительно согласования полей и форматов данных, может конфигурироваться «на лету».
    • Работает за NAT — клиенты могут находиться за NAT, только сервер (брокер) должен иметь реальный IP. Позволяет обойтись без VPN и пробрасывания портов.
    • Удобная адресация — поля данных имеют текстовые названия, понятные для человека. Не нужно запоминать цифровые адреса и битовые смещения.

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

    История протокола MQTT


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

    В ноябре 2011 IBM совместно с компанией Eurotech объявили об участии в рабочей группе Eclipse M2M и передаче кода MQTT в проект Eclipse Paho.

    В 2013 году консорциум OASIS (Organization for the Advancement of Structured Information Standards) начинает процесс стандартизации протокола MQTT. До этого момента спецификация протокола была опубликована под бесплатной лицензией, и такие компании, как Eurotech (ранее известный как Arcom), уже используют протокол в своих продуктах.

    В октябре 2014 г. OASIS публикует первый официальный стандарт протокола MQTT.

    В 2016 г. протокол был стандартизирован Международной организацией по стандартизации ISO и получил номер ISO/IEC 20922.

    С 2014 года интерес к протоколу начинает стремительно расти и, судя по графику Google Trends, на сегодняшний день превышает интерес к Modbus.


    Сравнительный график Google Trends

    Основные понятия


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

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


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

    На прикладном уровне протокол работает поверх TCP/IP и может легко связывать удаленные объекты напрямую по интернету, без необходимости использования VPN-тоннелей. Достаточно, чтобы брокер имел реальный IP-адрес и все клиенты могли к нему подключиться. При этом, клиенты могут находится за NAT. Так как в протоколе MQTT подключение инициируют клиенты, пробрасывать порты для установки соединения не требуется, в то время как в Modbus/TCP подключение инициирует сервер (master), что требует прямой сетевой доступности.

    Стандартный порт MQTT-брокера для входящих TCP-соединений — 1883. При использовании защищенного SSL-подключения используется порт 8883.

    Broker


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

    Publisher/Subscriber


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

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

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


    Publisher посылает данные брокеру, Subscriber подписывается на обновления этих данных

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

    Topic


    Для идентификации сущностей в MQTT используются топики, в русском переводе их еще называют каналами. Топики состоят из UTF8-символов, и имеют древовидную структуру, похожую на файловую систему в UNIX. Это удобный механизм, позволяющий называть сущности в человекопонятном виде.

    Пример топиков в MQTT

    # Датчик температуры на кухне
    home/kitchen/temperature
    
    # Датчик температуры в спальне
    home/sleeping-room/temperature
    
    # Датчик освещенности на улице 
    home/outdoor/light
    

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

    Топики также предусматривают wildcard-синтаксис, хорошо знакомый тем, кто работал с файловой системой UNIX. Wildcard может быть одноуровневым и многоуровневым.

    Одноуровневый wildcard обозначается символом "+".

    Например, чтобы получить данные с температурных датчиков во всех помещениях в доме, подписчику нужно подписаться на такой топик:

    home/+/temperature
    

    В результате он подпишется на получение данных с таких датчиков:

    home/kitchen/temperature
    home/sleeping-room/temperature
    home/living-room/temperature
    home/outdoor/temperature
    

    Многоуровневый wildcard обозначается символом "#".
    Пример получения данных со всех датчиков во всех комнатах в доме:

    home/#
    

    Подписка на такой топик позволит получать данные с таких датчиков:

    home/kitchen/temperature
    home/kitchen/humidity
    home/kitchen/light
    home/sleeping-room/temperature
    home/sleeping-room/humidity
    home/sleeping-room/light
    ....
    

    Идентификация клиентов


    Для контроля доступа в MQTT предусмотрена аутентификация клиентов, в отличие от протокола Modbus, который не имеет такой функции. Для контроля доступа используются такие поля:

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

    Username — (опциональное поле) логин для аутентификации, в формате UTF-8. Может быть не уникальным. Например, группа клиентов может авторизовываться с одним и тем же логином/паролем.

    Password — (опциональное поле) может посылаться только вместе с полем Username, при этом Username может передаваться без поля Password. Максимум 65535 байт. Важно знать, что имя и пароль передаются в открытом виде, поэтому, если данные передаются по публичным сетям, необходимо использовать SSL для шифрования подключения.

    Структура пакета


    Как уже говорилось выше, в протоколе MQTT подключение всегда инициируют клиенты, вне зависимости от того, являются ли они получателями (Subscriber) или поставщиками (Publisher) данных. Разберем пакет с установкой соединения, перехваченный с помощью программы Wireshark.


    Пакет с опцией MQTT, переданный по нешифрованному каналу

    В TCP заголовке видно, что пакет передан по порту 1883, то есть шифрование не используется, а значит в открытом виде доступны все данные, в том числе логин и пароль.

    Заголовок


    Тип сообщения — Connect (команда 0x0001), установка соединения с брокером. Основные команды: Connect, Disconnect, Publish, Subscribe, Unsubscribe. Есть также команды подтверждения получения, keep alive, и т.д.

    Флаг DUP — означает, что сообщение передается повторно, используется только в типах сообщений PUBLISH, SUBSCRIBE, UNSUBSCRIBE, PUBREL, для случаев, когда брокер не получил подтверждения получения предыдущего сообщения.
    Уровень QoS — флаг Quality of Service. Мы разберем эту тему подробнее дальше.
    Retain — данные, опубликованные с флагом retain, сохраняются на брокере. При последующей подписке на этот топик, брокер сразу отправит сообщение с этим флагом. Используется только в сообщениях с типом Publish.

    Использование на практике




    Теперь, ознакомившись с теорией, попробуем поработать с MQTT на практике. Для этого будем использовать открытую программу Mosquitto, которая может работать как в режиме клиента, так и в режиме сервера (брокера). Работает на Windows, macOS, Linux. Программа очень удобна для отладки и изучения протокола MQTT, при этом также широко используется в промышленной эксплуатации. Мы будем использовать ее как клиент для отправки и получения данных с удаленного облачного брокера.

    Множество облачных провайдеров предоставляют услуги MQTT-брокера, например Microsoft Azure IoT Hub, Amazon AWS IoT, и другие. В этом примере мы будем использовать сервис Cloudmqtt.com, так как у него самая простая регистрация, и бесплатного тарифа достаточно для обучения.

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


    Реквизиты доступа к MQTT-брокеру в личном кабинете облачного провайдера

    Гибкость протокола MQTT позволяет клиенту передавать данные, заранее не определенные на брокере. То есть нет необходимости предварительно создавать нужные топики, в которые сможет записать данные Publisher. Используя данные, полученные из личного кабинета, попробуем вручную составить запрос для публикации данных в топик habr/test/random и чтения из него.

    mosquitto_sub — утилита-клиент subscriber
    mosquitto_pub — утилита-клиент publisher

    Для начала подключимся к брокеру как subscriber, и подпишемся на получение данных из топика
    habr/test/random.

    mosquitto_sub -d --capath /etc/ssl/certs/ --url mqtts://hwjspxxt:7oYugN7Fa5Aa@postman.cloudmqtt.com:27529/habr/test/random
    Client mosq/zEPZz0glUiR4aEipZA sending CONNECT
    Client mosq/zEPZz0glUiR4aEipZA received CONNACK (0)
    Client mosq/zEPZz0glUiR4aEipZA sending SUBSCRIBE (Mid: 1, Topic: habr/test/random, QoS: 0, Options: 0x00)
    Client mosq/zEPZz0glUiR4aEipZA received SUBACK
    

    Видно, что подключение прошло успешно, и мы подписались на топик habr/test/random, и сейчас ожидаем данных в данном топике от брокера.
    Так как используется SSL-подключение, для проверки сертификата необходимо указать путь, по которому программа будет искать корневые сертификаты шифрования. Так как у сервиса в нашем примере используется сертификат, выданный доверенным удостоверяющим центром, то мы указываем путь к системному хранилищу корневых сертификатов: --capath /etc/ssl/certs/

    В случае с самоподписанным сертификатом, необходимо указывать путь к нужному CA. Также важно учитывать разницу в формате URI для подключения по SSL — mqtts://, и подключения без шифрования — mqtt://. В случае ошибки проверки сертификата программа завершается без сообщения об ошибке. Для более подробного вывода можно использовать ключ --debug
    Теперь попробуем опубликовать данные в топик, не прерывая первую программу.

    mosquitto_pub -d --capath /etc/ssl/certs/  --url mqtt://hwjspxxt:7oYugN7Fa5Aa@postman.cloudmqtt.com:27529/habr/test/random -m "Привет хабр!"
    Client mosq/sWjh9gf8DRASrRZjk6 sending CONNECT
    Client mosq/sWjh9gf8DRASrRZjk6 received CONNACK (0)
    Client mosq/sWjh9gf8DRASrRZjk6 sending PUBLISH (d0, q0, r0, m1, 'habr/test/random', ... (22 bytes))
    Client mosq/sWjh9gf8DRASrRZjk6 sending DISCONNECT
    

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

    Client mosq/zEPZz0glUiR4aEipZA received PUBLISH (d0, q0, r0, m0, 'habr/test/random', ... (22 bytes))
    Привет хабр!
    

    QoS и гарантия доставки


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

    По умолчанию для сообщений установлен флаг QoS в значение 0, что значит «Fire and forget»: Publisher публикует сообщение на брокере, но при этом не требует, чтобы сообщение было гарантированно доставлено подписчику. Это подходит для данных, потеря которых не критична, например, для регулярных измерений влажности или температуры.

    QoS 1: At least once – хотя бы один. Этот флаг означает, что пока Publisher не получит подтверждения доставки подписчику, данная публикация будет посылаться брокеру, и далее подписчику. Таким образом, подписчик должен получить данное сообщение как минимум один раз.

    QoS 2: Exactly once – гарантированно один. Флаг QoS, обеспечивающий высшую гарантию доставки сообщений за счет использования дополнительных процедур подтверждения и завершения публикации (PUBREC, PUBREL, PUBCOMP). Применим для ситуаций, когда нужно исключить любые потери и дублирование данных от датчиков. Например, когда от полученного сообщения срабатывает сигнализация, вызов экстренных служб.

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

    mosquitto_pub --retain --qos 2 -d --capath /etc/ssl/certs/  --url mqtt://hwjspxxt:7oYugN7Fa5Aa@postman.cloudmqtt.com:27529/habr/test/random -m "Очень важный привет!" 
    Client mosq/Xwhua3GAyyY9mMd05V sending CONNECT
    Client mosq/Xwhua3GAyyY9mMd05V received CONNACK (0)
    Client mosq/Xwhua3GAyyY9mMd05V sending PUBLISH (d0, q2, r1, m1, 'habr/test/random', ... (37 bytes))
    Client mosq/Xwhua3GAyyY9mMd05V received PUBREC (Mid: 1)
    Client mosq/Xwhua3GAyyY9mMd05V sending PUBREL (m1)
    Client mosq/Xwhua3GAyyY9mMd05V received PUBCOMP (Mid: 1, RC:0)
    Client mosq/Xwhua3GAyyY9mMd05V sending DISCONNECT
    

    Теперь, спустя время, наш получатель наконец смог установить соединение с интернетом и подключился к брокеру:

    mosquitto_sub  -d --capath /etc/ssl/certs/ -d --url mqtts://hwjspxxt:7oYugN7Fa5Aa@postman.cloudmqtt.com:27529/habr/test/random
    Client mosq/VAzcLVMB1MiWhYxoJS sending CONNECT
    Client mosq/VAzcLVMB1MiWhYxoJS received CONNACK (0)
    Client mosq/VAzcLVMB1MiWhYxoJS sending SUBSCRIBE (Mid: 1, Topic: habr/test/random, QoS: 0, Options: 0x00)
    Client mosq/VAzcLVMB1MiWhYxoJS received SUBACK
    Subscribed (mid: 1): 0
    Client mosq/r6UwPnDvx8aNInpPF6 received PUBLISH (d0, q0, r1, m0, 'habr/test/random', ... (37 bytes))
    Очень важный привет!
    

    Заключение


    MQTT — современный продвинутый протокол, лишенный множества недостатков предшественников. Его гибкость позволяет добавлять клиентские устройства без настройки на брокере, что существенно экономит время. Порог вхождения для понимания и настройки протокола достаточно низкий, а наличие библиотек под множество языков программирования позволяет выбрать любой стек технологий для разработки. Гарантия доставки сообщений существенно отличает MQTT от его предшественников, и позволяет не тратить время на лишнюю разработку собственных механизмов контроля целостности на сетевом уровне.
    Advantech IIoT
    76,94
    Наша миссия — создание умной планеты.
    Поделиться публикацией

    Комментарии 32

      0
      Поддержка QoS — возможность управлять приоритетом сообщений и гарантировать доставку сообщения адресату.

      Прошу не вводить в заблуждение:
      QoS — и гарантировать доставку сообщения адресату.
      — не гарантирует доставку сообщения. Он лишь расставляет приоритеты. Крайне полезная штука, при мало скоростном соединении.
      Линк почитать про QoS


      Согласен с автором QoS может делать выше указанное. Иной ресурс с описанием
        +1
        Термин QoS не описывает конкретный протокол. В данном случае может одновременно использоваться QoS на сетевом уровне в виде ToS маркера в IP пакетах и на прикладном уровне внутри протокола mqtt. Будет QoS внутри QoS.
          0

          Мне всегда было интересно, а как вообще пакет может быть не доставлен, если MQTT работает поверх TCP, который гарантирует доставку? Разве что если устройство-получатель вообще сдохлотполностью или отключилось, а при установлении связи с ним брокер будет пытаться отправить посылку ещё раз...

          0
          По поводу топиков: приведённые в примерах топики, а оторые начинаются со слэша — плохая практика. По стандарту первый слэш не нужен, в данном случае он приводит к созданию первого уровня с пустым именем.
          /home/something — в данном случае home находится на втором уровне.
          Правильнее писать
          Home/something
            0
            Да, Вы правы. Эта путаница возникла из-за синтаксиса mosquitto, который требует первый слеш для отделения топика от порта. Начальный слеш при этом игнорируется и не передается в топик.


            mqtt(s)://[username[:password]@]host[:port]/topic


            Спасибо за внимательность.
            0
            И ещё маленький комментарий — топики чувствительны к регистру. HOME не равно home
              +1
              Уже есть брокеры с 5 версией протокола и разными плюшками типа shared subscription и тп. Например flespi.com/mqtt-broker и mosquitto.org
                0
                Пароль от брокера действующий. Наверное его нужно поменять, чтобы вам мусора не наслали.
                  0
                  Так и задумано, что все команды из статьи можно повторить без изменения. Это тестовая учетная запись созданная специально для статьи.
                  0
                  Честно говоря не очень понятна ниша сего протокола, видимо нужно какое-то сравнение, с AMPQ например и т.п.
                    +1
                    Ниша — IoT, это по сути легковесная версия AMQP.
                    Поддерживается во всяких штуках за $1 типа ESP8266 (точнее в ОС для них).
                    • НЛО прилетело и опубликовало эту надпись здесь
                        0
                        <Делать QoS поверх TCP/IP — это излишне (в статье не указано, но вообще-то, MQTT может работать поверх UDP, RS-232/485, WebSocket — частично QoS оправдан)
                        Расчёт на ненадёжное TCP — то есть, то нет, то косячит.
                        А с учётом ещё одной «фишки» — will-сообщений (типа «завещание на случай нежданной смерти»), вообще очень надёжная и предсказуемая система может получиться.
                        Что касается ресурсоёмкости, то впринципе самое ресурсоёмкое — шифрование трафика. Остальное для простых устройств не так уж и сложно и ресурсоёмко.
                        Т.е., если «открытым текстом», то вполне под силу и совсем лёгким железкам.
                        • НЛО прилетело и опубликовало эту надпись здесь
                            0

                            Что TCP работает через пень-колоду? Редко бывает? По редиоканалу? GSM?
                            А серверу мало понимать. Понимать должны устройства и программы, работающие совместно с устройством с ненадёжноф связью. И "умершее" устройство должно уметь гарантированно сообщить о своей смерти. Протокол эту проблему решает.
                            На 8 битной железке с 16кБ ОЗУ и 32 ПЗУ даже интерпретатор бейсика когда-то неплохо работал.
                            И кто Вас заставляет Json пихать? Хоть в бинарном виде сообщения отдавайте. Протокол и это позволяет. А хочется с 8 битной железкой работать, так и работайте на соответствующем уровне.
                            Странно ставить в вину протоколу, что 8 битная железка не умеет h264 на лету кодировать. :)
                            И да. этот протокол не для того, чтобы "в жёстком реальном времени глолову с ногами соединять", а в основном для того, чтобы обеспечить обмен данными между функционально самостоятельными устройствами.

                            • НЛО прилетело и опубликовало эту надпись здесь
                                0
                                Вы это всё ещё про mqtt рассуждаете?
                                Кстати, какой там максимальный размер сообщения и сколько их может одновременно храниться?
                                • НЛО прилетело и опубликовало эту надпись здесь
                      0

                      Пример добавления данного протокола к программируемому промышленному реле https://youtu.be/Ogp0U0pHQqA

                        0

                        Все же у Mqtt и MODBUS разные ниши. Modbus rtu/ascii можно использовать в реальном времени, а mqtt, из-за завязки на tcp/ip уже нельзя.

                          0
                          Что такое реальное время? Profinet тоже TCP/IP. Modbus TCP?
                          MQTT ориентирован на децентрализованную систему независимых устройств, как по-моему. А Modbus для работы с одной главной управляющей машиной.
                            0

                            Ну, скажем, принимать и передавать данные каждые 20 мс без изменения порядка.

                              0
                              Profinet RT не использует TCP
                            +2
                            Самая простая, и довольно точная аналогия для описания MQTT — «чат для железок».
                            Впринципе, можно использовать и для обмена сообщениями между людьми. :)
                              0
                              А может кто-нибудь подсказать, как снифить траффик, проходящий от клиента к брокеру? Что-то вроде Charles или Fiddler, только для mqtt
                                0

                                Немного не то что Вы хотите, но как вариант можно использовать mqtt-spy. Подключиться к брокеру и подписаться на все топики (#).

                                0
                                Я не совсем понял — а если 2 подписчика qos 2 сообщения — каждый получит по 2? А если один подписался позднее? Хранит ли брокер сообщения так, чтобы при подписке новым subscriber я гарантирванно получал всю историю сообщений?
                                  0
                                  хранит, если Retain.
                                    0

                                    хранит только последнее сообщение помеченное retain

                                  0
                                  Самый большой недостаток в MQTT протоколе, на мой взгляд, это то что нельзя перебрать содержимое MQTT брокера, хотя бы получить список опубликованных топиков.
                                    0
                                    А что можете сказать про существующие брокеры? С полгода назад ресёрчил данный вопрос, из более-менее встречающихся в интернете пишут про emqtt и его наследник (как я понял) emqx, либо же VerneMQ, про другие — крайне мало информации. Приходилось ли кому-нибудь сталкиваться с указанными брокерами? Или если используете другой брокер — расскажите, плз, какой.
                                      0
                                      в то время как в Modbus/TCP подключение инициирует сервер (master)

                                      Позвольте уточнить. В Modbus/TCP действительно master инициирует соединение, но master это клиент. Сервер это slave. Если за NAT клиенты, то проброс портов не нужен.

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

                                      Самое читаемое