Что такое MQTT?

MQTT или Message Queue Telemetry Transport – это легкий открытый протокол обмена данными, работающий поверх TCP/IP, созданный для унификации обмена данных между устройствами M2M (Машинно-Машинное взаимодействие) и IIoT (Промышленный Интернет вещей).

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

Особенности протокола MQTT

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

  • Асинхронный протокол
  • Компактные сообщения
  • Работа в условиях нестабильной связи на линии передачи данных
  • Поддержка нескольких уровней качества обслуживания (QoS) 
  • Легкая интеграция новых устройств

 

Протокол MQTT работает на прикладном уровне поверх TCP/IP и использует по умолчанию 1883 порт (8883 при подключении через SSL). Также, возможна работа через Winsocket

Обмен сообщениями в протоколе MQTT осуществляется между клиентом (client), который может быть издателем или подписчиком (publisher/subscriber) сообщений, и брокером (broker) сообщений (например, открытое ПО  Mosquitto MQTT).

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

Устройства MQTT используют определенные типы сообщений для взаимодействия с брокером, ниже представлены основные:

  • Connect – установить соединение с брокером
  • Disconnect – разорвать соединение с брокером
  • Publish – опубликовать данные в топик на брокере
  • Subscribe – подписаться на топик на брокере
  • Unsubscribe – отписаться от топика

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

/myhome/kitchen/temperature

/myhome/kitchen/light

Все устройства, которые заинтересованы в получении обновлений информации по всему, например, что происходит на кухне, могут подписаться на топик /myhome/kitchen/#  (#-специальный символ, аналогичный "*" в файловых системах) 

Датчик температуры публикует свои измерения в топик /myhome/kitchen/temperature

Выключатель - в топик /myhome/kitchen/light

Преимущества использования MQTT для устройств  

  • Является стандартом де-факто для современных облачных систем IoT (см обзор). Данный протокол поддерживается всеми современными облачными системами
  • Развитая экосистема opensource решений автоматизации и диспетчеризации, в том числе: OpenHab, Wiren Board, Node Red - (см. Обзор) - это позволяет оконечным устройствам легко использовать уже имеющееся ПО без необходимости разрабатывать Web- интерфейсы, мобильные приложения, Rule-engines и пр.
  • ПО MQTT брокера, также, доступно в открытом исходном коде и портировано под основные ОС (https://mosquitto.org/)
  • Поддержка данного протокола устройством позволяет использовать его совместно с большим кол-вом уже существующего ПО и легко интегрировать новые устройства  
  • Библиотеки для реализации клиентской части данного протокола, также, доступны в исходном коде и могут быть легко интегрированы в ваш проект

Недостатки MQTT

Протокол хорошо специфицирует такие операции как подписка на информацию (топик)  и публикацию информации в топик, но сам формат данных оставляет на усмотрение приложений IoT

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

Например, системы IoT Manager и OpenHab, напрямую, не совместимы. IoT Manager использует формат Json, тогда как OpenHab передает в MQTT топики простые команды "ON", "OFF", цифровые значения датчиков, разделенные запятыми значения для управления устройствами. При этом, подразумевается, что устройства и система управления сконфигурированы одинаковым образом, что позволяет всем участникам обмена однозначно интерпретировать значения

Из общих соображений, использование структурированных данных (Json) более гибко и перспективно. Полагаю, в индустрии будет сформирован и стандартизован общеупотребимый и совместимый формат данных, на который, в перспективе, перейдет прикладное ПО

 

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

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

 

В статье использованы материалы из  Wikipedia и IPC2u 

 

Комментарии   

0 #1 Netwizard 23.11.2017 23:05
Здравствуйте,

на сколько я помню, на железках уровня atmega2560 SSL нет... как с безопасностью комуникаций? В контроллируемой среде (по кабелю) это плохо, но не кошмар, а вот wifi для таких железок автоматически закрывается от слова совсем.

mosquitto это легко и просто, но ненадежно. Не задумывались о варианте RabbitMQ в кластере с адаптером в mqtt протокол? Там вроде все "искаропки" поддерживается + без диких плясок с бубном можно подцепить авторизацию.
Цитировать
0 #2 Super User 25.11.2017 16:15
Цитирую Netwizard:
Здравствуйте,

на сколько я помню, на железках уровня atmega2560 SSL нет... как с безопасностью комуникаций? В контроллируемой среде (по кабелю) это плохо, но не кошмар, а вот wifi для таких железок автоматически закрывается от слова совсем.

mosquitto это легко и просто, но ненадежно. Не задумывались о варианте RabbitMQ в кластере с адаптером в mqtt протокол? Там вроде все "искаропки" поддерживается + без диких плясок с бубном можно подцепить авторизацию.

Да, на AVR затруднительно поднять SSL, но для локальной связи с брокером пока проблемы не вижу. Со временем, смигрирую все же код на AVR и ESP - там мощность позволяет. После этого можно будет смело и без паранойи подключаться к внешним облачным брокерам. Не очень, правда, понимаю какая проблема с WiFi? WiFi сам по себе закрыт шифрованием и прослушивая его не перехватишь взаимодействие контроллера с брокером. Контроллер во всех смыслах лучше подключать проводом. Но даже пачка WiFi сенсоров, которые у меня подключаются по WiFi к брокеру без SSL, по моему, дополнительно не компрометируют безопасность.

Относительно надежности mosquitto, также, не уловил мысль. За два года после его установки (2 минуты из репозитория Ubuntu), я о нем более не вспоминал. Ни в каких глюках я данный брокер не заметил просто ни разу. Rabbit хорошая штука, но какие преимущества принесет связка RabbitMQ+MQTT адаптер?
Цитировать
0 #3 Алексей 25.11.2017 16:47
Цитирую Super User:

Да, на AVR затруднительно поднять SSL, но для локальной связи с брокером пока проблемы не вижу. Со временем, смигрирую все же код на AVR и ESP - там мощность позволяет. После этого можно будет смело и без паранойи подключаться к внешним облачным брокерам.


Ну вариант подлючения к внешним системам я даже не рассматриваю - мой внутренний параноик говорит, что мои данние являются моими только пока они у меня. А насчет "бесплатных" облаков товарищ Бобук сказал оценна правильно: вы или покупатель или товар - другого не дано.
Цитировать
0 #4 Алексей 25.11.2017 16:49
Цитирую Super User:

Не очень, правда, понимаю какая проблема с WiFi? WiFi сам по себе закрыт шифрованием и прослушивая его не перехватишь взаимодействие контроллера с брокером.


Не давече чем месяц тому назад, wpa/2-psk "продемонстрировал" свою защишенность во всей красе. И никто не может гарантировать, что похожий facepalm не вылезет позже - так что защита коммуникации должна быть на каждом уровне - в случае какой-либо дыры велика вероятность что следующий слой не позволит нагадить в системе управления.
OFFTOP: мой личный опыт утверждает, что люди экономящие на безопастности на начальных стадиях разработки, на последних этапах платят со сторицей, на на проде - иногда и сворачиваются после первого-же инцидента безопасности.
Цитировать
0 #5 Алексей 25.11.2017 16:50
Цитирую Super User:

Контроллер во всех смыслах лучше подключать проводом. Но даже пачка WiFi сенсоров, которые у меня подключаются по WiFi к брокеру без SSL, по моему, дополнительно не компрометируют безопасность.


тот-же провод, выходящий за пределы контролируемой среды (напр. за физ. пределами дома, квартиры) автоматически перестает быть доверенной средой. WiFi по определению не может быть доверенной средой передачи: его можно снифить, делать инжекцию пакетов (MitM, принидительный разрыв соединения https://xakep.ru/2017/10/16/wpa2-krack/ ), да даже простое зашумление эфира с целью блокировки связи
Цитировать
0 #6 Алексей 25.11.2017 16:52
Цитирую Super User:

Относительно надежности mosquitto, также, не уловил мысль. За два года после его установки (2 минуты из репозитория Ubuntu), я о нем более не вспоминал. Ни в каких глюках я данный брокер не заметил просто ни разу. Rabbit хорошая штука, но какие преимущества принесет связка RabbitMQ+MQTT адаптер?

например, message persistance на случай рестарт брокера, гарантия доставки всем подписчикам. в отношении глюков такое я встречал: например, он не хотел пускать клиента с тем-же именем, если он уже был зареган в брокере (напр., timeout 120s для экономии батарейки при работе от акума по wifi)
С точки зрения HA - падение одного из брокеров не положит коммуникацию IoT, т.к. очереди кластерные, а VIP перекидывается на живую ноду тем-же heartbeat'ом
Цитировать
0 #7 Super User 25.11.2017 18:24
Цитирую Алексей:

например, message persistance на случай рестарт брокера, гарантия доставки всем подписчикам. в отношении глюков такое я встречал: например, он не хотел пускать клиента с тем-же именем, если он уже был зареган в брокере (напр., timeout 120s для экономии батарейки при работе от акума по wifi)
С точки зрения HA - падение одного из брокеров не положит коммуникацию IoT, т.к. очереди кластерные, а VIP перекидывается на живую ноду тем-же heartbeat'ом

Client-ID должен быть уникальный, это не бага а фича. В Вашем случае, перед засыпанием устройства, вероятно, помогло бы делать Disconnect от брокера.
По поводу кластеризации и персистентности - тут полностью соглашусь. Хотя, это, скорее, для "ответственных" или промышленных применений. Кластер MQTT брокера для дома ИМХО перебор.
Цитировать
0 #8 Super User 25.11.2017 18:27
Цитирую Алексей:

Не давече чем месяц тому назад, wpa/2-psk "продемонстрировал" свою защишенность во всей красе. И никто не может гарантировать, что похожий facepalm не вылезет позже - так что защита коммуникации должна быть на каждом уровне - в случае какой-либо дыры велика вероятность что следующий слой не позволит нагадить в системе управления.

Ну если покопаться поглубже в этой уязвимости, то становится понятно, что ZeroKey позволяет перекинуть непропатченного WiFi клиента Android или Linux на фальшивую точку доступа, а далее, при помощи SSLStrip, например, сниффить пароли. В нашем случае, эта уязвимость ничего не добавляет и не прибавляет. Мобильные приложения на Андроид - становятся более уязвимы, до установки обновлений. WiFi датчик CO2 внутри с ESP8266, про ее уязвимость тут ничего не говорится. Конечно, при возможности, надо использовать SSL или TLS шифрование при подключению к брокеру. В принципе, можно аксеслистами ограничить незашифрованное соединение с брокером только контроллеру, подключенному по проводной сети. Всех прочих - пускать только на порт с шифрованием.
Провод внутренней докальной сети за периметр, конечно, тоже не дело выпускать.
Цитировать
0 #9 Алексей 25.11.2017 18:34
Цитирую Super User:
Ну если покопаться поглубже в этой уязвимости, то становится понятно, что ZeroKey позволяет перекинуть непропатченного WiFi клиента Android или Linux на фальшивую точку доступа, а далее, при помощи SSLStrip, например, сниффить пароли. В нашем случае, эта уязвимость ничего не добавляет и не прибавляет.


Zerokey + heartbleed - 2 наиболее яркие и наглядные демострация того, что то, что все считают незыблемым - таковым не является и может показать средний палец в самый неподходящий момент. Именно исходя из этого системы автоматизации и телеметрии должны проектироваться с требованями максимальной безопасности. Утрируя: Вам же не хочется, чтобы ваш уютный дом в час Х превратился в неуютную запертую халупу из-за того, что школьнику из соседней квартиры не понравились ваши комментарии по поводу его громко демонстрируемых всему дому, музыкальных вкусов :)
Цитировать
0 #10 Super User 25.11.2017 18:48
Цитирую Алексей:

Zerokey + heartbleed - 2 наиболее яркие и наглядные демострация того, что то, что все считают незыблемым - таковым не является и может показать средний палец в самый неподходящий момент. Именно исходя из этого системы автоматизации и телеметрии должны проектироваться с требованями максимальной безопасности. Утрируя: Вам же не хочется, чтобы ваш уютный дом в час Х превратился в неуютную запертую халупу из-за того, что школьнику из соседней квартиры не понравились ваши комментарии по поводу его громко демонстрируемых всему дому, музыкальных вкусов :)

Ну для большинства домашних применений, даже гипотетический взлом WiFi и несанкционированое подключение к шине пока не могут привести к чему-то кроме мелкого неудобства. Но для более ответственных применений, там где есть угроза здоровью/жизни, конечно, решения должны быть другими. Доверить открывание дверей этой технологии, также рановато.
Все ПО тут опенсорсное, и будет очень хорошо, если в сообщество разработчиков добавится конструктивный параноик. Так, глядишь, оно станет пригодно и для другого класса применения. :-)
Цитировать

Добавить комментарий


Защитный код
Обновить

0
0
0
s2sdefault