Что такое mqtt брокер

Что такое MQTT

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

Я написал этот текст специально для людей кто никогда раньше не сталкивались с MQTT.

История возникновения MQTT

MQTT — это такой специальный протокол по которому умеют общаться программы и устройства. Есть русский язык и люди которые умеют разговаривать на этом языке могут понять друг друга. Точно так же есть «язык» MQTT — программы и устройства которые умеют разговаривать на этом языке могут общаться друг с другом.

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

Протокол MQTT смог успешно решить эта задачу и стал применяться и в других отраслях. Постепенно компьютеры и микропроцессоры становились все дешевле и это привело к тому что стала появляться куча разных устройств в которые добавили «ума» (для этого придумали красивый термин IoT — Internet of Things — Интернет Вещей). Умный чайник, умный обогреватель — эти устройства могут отправлять данные про себя (какая сейчас температура, сколько устройство работает), а так же удаленно получать команды на управление.

Есть множество устройств разных производителей — как им общаться друг с другом и с серверами умного дома? Можно взять и придумать новый язык (протокол) и многие производители так и делают. Но есть протокол MQTT которые отлично подходит для общения разных устройств и программ. Некоторые производители используют MQTT в своих устройствах. MQTT популярен в мире бесплатных и открытых программ (Open Source).

Программа MQTT Explorer

Если вы работаете с MQTT, то вам нужно обязательно скачать и поставить программу MQTT Explorer.

Программа бесплатная. Программа работает на Windows, на macOS и на Linux.

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

MQTT брокер

MQTT — это протокол который работает по модели клиент-сервер.

Центральная часть — это MQTT сервер. Обычно сервер MQTT называют MQTT брокер.

Есть очень популярная программа Mosquitto — если запустить эту программу, то у вас появится работающий MQTT сервер.

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

Клиенты

К серверу MQTT подключаются клиенты. Клиенты могут отправлять сообщения и читать сообщения. Некоторые клиенты только отправляют, некоторые только читают, но достаточно часто клиент делает и то и другое: и отправляет сообщения и слушает другие сообщения.

Чтобы клиент мог подключиться к MQTT серверу нужно указать:

Топики и отправка сообщений

Итак, есть MQTT брокер — центр системы. Есть клиенты которые подключаются к этому центру.

Давайте разберем задачу. Есть датчик температуры и есть система умного дома. Как с помощью MQTT датчик может передать температуру в систему умного дома?

Датчик температуры подключается к серверу MQTT. Раз в 5 минут датчик производит замер температуры и отправляет результат замера в сервер MQTT. Например, температура 23.8 °C

Для того чтобы отправить температуру в MQTT датчик должен знать две вещи. Во-первых, саму температуру, она есть — 23.8. А во-вторых датчик должен указать адрес топика в который будет отправлено это значение. Что же такое топик? Чуть-чуть отойдем в сторону. Представим что нужно сохранить число 23.8 на компьютер. Можно сохранить в файл. Для этого нужно знать полный путь к файлу. Например, c:\temperature\sensor.txt — в этом файл мы можем записать число 23.8

Топик очень похож на файл — это расположение какого-то кусочка информации в MQTT сервере. Датчик температуру может отправить сообщение 23.8 в топик temperature/sensor — теперь MQTT сервер знает про это число.

Половину задачи решели — датчик температуру отправил значение температуру в MQTT сервер.

Как же система умного дома узнает о том что датчик прислал новую температуру? При подключении к серверу MQTT система умного дома говорит — я хочу получить все данные которые приходят в топик temperature/sensor MQTT сервер запоминает это желание клиента и как только в топик temperature/sensor приходит какое-то значение сервер пересылает это сообщение всем клиентам кто выразил желание получать сообщение из этого топика (это называется кто «подписался» на эти топики»)

Символ решетка

Клиент при подключении к MQTT серверу может указать список топиков которые он хочет «слушать» (т.е. получать все сообщения которые поступают в эти топики)

При подписке можно указать символ решетка. Например, если клиент говорит что он хочет подписать на temperature/# то этот клиент получит все сообщения которые будут отправлены вот в такие топики:

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

Retain Флаг

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

Пример. Есть датчик температуры и есть система умного дома. Штатный режим работы. Система умного дома подключилась к MQTT серверу и слушает все сообщения. Датчик температуры подключился к MQTT серверу и каждые 5 минут отправляет данные про температуру. Все работает прекрасно — датчик отправл температуру, MQTT сервер переслал эту температуру в систему умного дома и умный дом отобразил эту температуру в интерфейсе.

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

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

Last will

Одна из интересных фишек протокола MQTT — это штука под названием Last will — завещание. Еще используют аббревиатуру «LWT» — Last Will and Testament.

Стандартная работа — клиент подключается к MQTT серверу и все время остается подключенным к серверу (сервер «видит» момент подключения и может понять когда клиент отключился).

Задача. Есть клиент — компьютер — он должен быть всегда подключен к MQTT серверу. Если этот компьютер не подключен к MQTT серверу — это авария, что-то случилось либо с этим компьютером, либо с каналом связи. Как об этой аварии могут узнать другие клиенты?

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

Например, клиент может попросить сервер отправить сообщение «offline» в топик «computers/my-desktop/status». И когда этот клиент отвалится MQTT сервер отправит сообщение «offline» в нужный топик. Клиент подключился, сказал MQTT серверу что при отключении нужно отправить в топик значение «offline» и тут же отправляет в этот же топик значение «online». Тогда все другие клиенты которым интересен статус этого клиента могут следить за этим топиком — если там «online» значит с компьютером все нормально, если «offline», то есть проблема.

Источник

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

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

Главные особенности протокола 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

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

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

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

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

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

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

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

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

Для контроля доступа в 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.

Видно, что подключение прошло успешно, и мы подписались на топик habr/test/random, и сейчас ожидаем данных в данном топике от брокера.

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

Теперь попробуем опубликовать данные в топик, не прерывая первую программу.

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

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, чтобы отправленное сообщение сохранилось на брокере.

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

Источник

Протокол MQTT: концептуальное погружение

Протокол Message Queuing Telemetry Transport (MQTT) используется в течение многих лет, но сейчас он особенно актуален благодаря взрывному росту IoT: и потребительские, и промышленные устройства внедряют распределённые сети и граничные вычисления (edge computing), а устройства с постоянной трансляцией данных становятся частью повседневной жизни.

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

Небольшое вступление

MQTT — это протокол обмена сообщениями по шаблону издатель-подписчик (pub/sub). Первоначальную версию в 1999 году опубликовали Энди Стэнфорд-Кларк из IBM и Арлен Ниппер из Cirrus Link. Они рассматривали MQTT как способ поддержания связи между машинами в сетях с ограниченной пропускной способностью или непредсказуемой связью. Одним из первых вариантов его использования было обеспечение контакта фрагментов нефтепровода друг с другом и с центральными звеньями через спутники.

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

Таким образом, MQTT стал протоколом для потоковой передачи данных между устройствами с ограниченной мощностью CPU и/или временем автономной работы, а также для сетей с дорогой или низкой пропускной способностью, непредсказуемой стабильностью или высокой задержкой. Именно поэтому MQTT известен как идеальный транспорт для IoT. Он построен на протоколе TCP/IP, но есть ответвление MQTT-SN для работы по Bluetooth, UDP, ZigBee и в других сетях IoT, отличных от TCP/IP.

MQTT — не единственный в своём роде протокол обмена сообщениями pub/sub в реальном времени, но он уже получил широкое распространение в различных средах, которые зависят от межмашинной связи. Среди его сверстников — Web Application Messaging Protocol, Streaming Text-Oriented Messaging Protocol и Alternative Message Queueing Protocol.

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

Как работает MQTT: основы

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

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

Пример того, как можно настроить клиент для подключения через брокера MQTT:

Любые данные, опубликованные или полученные брокером MQTT, будут закодированы в двоичном формате, поскольку MQTT является бинарным протоколом. Это означает, что для получения исходного содержимого нужно интерпретировать сообщение. Вот как это выглядит с помощью Ably и JavaScript:

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

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

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

Функциональность MQTT: более глубокое погружение

Согласно IBM, MQTT обладает следующими свойствами:

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

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

Формат сообщений MQTT

Посмотрите на два компонента, из которых состоит каждое сообщение по протоколу MQTT:

Где можно использовать MQTT?

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

Как указано выше, MQTT — легковесный протокол обмена сообщениями, построенный для ненадёжных сетей и устройств с ограничениями на источник питания и CPU. Однако это не означает, что связь с потенциальной потерей пакетов — его единственное приложение. MQTT предоставляет различные уровни обслуживания для различных типов инфраструктуры IoT, от повторяющейся выборки данных до управления промышленными машинами:

Когда не нужно использовать MQTT?

У разработчиков есть богатый выбор протоколов для проектирования и развёртывания двунаправленных каналов связи IoT, включая MQTT, HTTP, CoAP, WebSockets (если позволяет CPU/батарея) и другие. Является ли MQTT лучшим выбором, зависит от оборудования и задачи приложения.

Разработанный для сред с чрезвычайно низкой пропускной способностью, протокол MQTT может быть довольно негибким в своём стремлении сохранить каждый байт. Например, спецификация определяет всего пять сообщений об ошибке, с помощью которых сервер может отклонить соединение (например, неверное имя пользователя/пароль или неприемлемая версия протокола). Если сервер хочет указать на какую-то иную ошибку, ему не повезло. Хуже того, если ошибка возникает после запуска соединения, нет никакого механизма для сообщения об ошибке вообще. Сервер может только пожать плечами и резко прервать TCP-соединение, оставив клиента без понятия, почему его сбросили (и без какого-либо способа отличить преднамеренное отключение от временной сетевой проблемы). Для людей, привыкших к более гибким и простым в отладке (хотя и менее экономичным по пропускной способности) протоколам pub/sub, такой спартанский подход может показаться немного примитивным.

MQTT часто упоминается вместе с HTTP, поэтому компания Google провела исследование, сравнив их по времени отклика, объёму трафика и другим важным для разработчиков атрибутам. MQTT занял первое место в тестах Google, но только в условиях, когда соединение можно повторно использовать для отправки нескольких полезных нагрузок.

HTTP и MQTT являются хорошим выбором для приложений IoT из-за достаточно малого объёма трафика, низких требований к батарее и памяти.

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

В тех случаях, когда клиенты должны только получать данные, Server-Sent Events — тоже подходящий вариант.

Как быстро настроить MQTT

Eclipse Mosquitto — open source брокер MQTT

Eclipse Mosquitto — брокер сообщений с открытым исходным кодом (лицензии EPL/EDL), который реализует протоколы MQTT версий 5.0, 3.1.1 и 3.1. Mosquitto лёгкий и подходит для использования на всех устройствах: от маломощных одноплатных компьютеров до полноценных серверов.

MQTT.js

MQTT.js — это клиентская библиотека для протокола MQTT, написанная на JavaScript для Node.js и браузера. Вот пример отправки сообщения с помощью MQTT.js:

MQTTnet

Установка клиента MQTT:

После настройки параметров клиента MQTT можно установить соединение. В следующем коде показано, как подключиться к серверу:

Приём входящих сообщений:

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

Что насчёт масштабирования?

Когда речь идёт о масштабировании MQTT, следует учесть два соображения: 1) правильный ли это протокол; 2) независимо от выбора протокола, какие инфраструктура и сетевые возможности необходимы для обработки возросшего трафика между устройствами по MQTT.

Lightweight Machine-to-Machine (LWM2M) — ещё один протокол, который можно использовать вместе с MQTT на уровне предприятия. По сравнению с MQTT, он иногда лучше подходит для долговременных систем IoT. MQTT идеально подходит для пробного запуска IoT без особых усилий, в то время как LWM2M предоставляет функции для долгосрочной универсальной инфраструктуры. LWM2M также предоставляет превосходные инструменты управления устройствами, такие как мониторинг подключения, обновление прошивок и удалённые действия на устройствах. Для предприятий с большим количеством неуправляемых устройств, отправляющих большие объёмы данных на центральную платформу, LWM2M является лучшим выбором. Тем не менее, мы говорим о масштабных развёртываниях IoT, поэтому обычно MQTT более чем адекватный вариант. Кроме того, MQTT более распространён и у него более широкая поддержка.

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

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

Какова нынешняя ситуация с MQTT?

В апреле 2019 года OASIS выпустила MQTT v5.0 в качестве официального стандарта. OASIS — это некоммерческий консорциум, состоящий из 600 организаций-членов и 5000 индивидуальных участников.

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

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

MQTT и Ably

MQTT — популярный, широко поддерживаемый и относительно зрелый протокол. Он отлично подходит для множества применений в реальном времени, а не только для развёртывания IoT. Тем не менее, поскольку производство и потребление данных в реальном времени продолжают расти экспоненциально, MQTT не всегда будет правильным выбором протокола для удовлетворения ваших потребностей в потоковой передаче. Следите за нашим разделом Realtime Concepts для получения информации о других протоколах и о том, как они подходят вашей ситуации.

Ably предоставляет брокер и адаптер протокола MQTT с трансляцией на собственный протокол Ably в обе стороны, что позволяет интегрироваться с любыми существующими системами и соединениями. Поддерживаются WebSockets, HTTP, SSE, gRPC (в разработке), STOMP, AMQP и другие протоколы для организации распределённой инфраструктуры обмена сообщениями в реальном времени. Есть более 40 клиентских библиотекам SDK и поддержка проприетарных протоколов реального времени.

Источник