MQTT – Нервная Система IoT

Источник: http://blog.catchpoint.com/2017/05/30/protocol-for-internet-of-things/

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

Message Queueing Telemetry Transport Protocol (MQTT)

MQTT – это облегченный протокол обмена сообщениями на основе модели публикации-подписки для обмена данными между компьютерами (M2M) поверх протокола TCP / IP. Протокол обеспечивает технологию телеметрии, и разработчики MQTT работают над тем, чтобы соединить развивающийся мир интернета, который, как ожидается, будет производить еще больше разнообразных интеллектуальных устройств. Первая версия протокола MQTT была разработана Стэнфорд-Кларком, IBM и Арленом Ниппером.

Почему MQTT?

MQTT используется Facebook для приложения Messenger, которому требуется постоянное подключение к своим серверам без потери заряда батареи. Он так же требует стабильной работы при низкой пропускной способности сети и имеет небольшой объем кода. Подобные функции являются преимуществами для устройств с небольшим объемом памяти и вычислительной мощности.

Другие примечательные особенности MQTT:

• Открытый исходный код, отсутствие лицензионных платежей и, следовательно, легкость введения в использование и адаптации
• Следует модели публикации-подписки и «один-ко-многим»
• Имеет небольшие заголовки сообщений
• Имеет несколько уровней качества обслуживания
• Имеет простые командные сообщения
• Не зависит от типа данных
• Возможность отложенного получения сообщений для новых клиентов
• Механизм поддержания продолжительных клиентских сессий
• Механизм уведомления клиентов при потере соединения (LWT)

MQTT vs. HTTP

Пример топологии MQTT:

Уровни качества обслуживания

Значение QoS определяет способ доставки каждого сообщения, и является обязательным значением для каждого отправляемого сообщения.

QoS 0 (не более одной попытки доставки сообщения)

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

QoS 1 (минимум одна доставка сообщения)

Клиент или сервер MQTT попытается доставить сообщение хотя бы один раз, при этом появляется возможность дублирования сообщений. Когда брокер получает сообщение, отправляется подтверждение PUBACK. Если PUBACK не получен, отправитель снова отправляет сообщение с установленным битом DUP (дубликата). Получив сообщение с установленным битом DUP, посредник повторно публикует сообщение всем своим подписчикам и отправляет другое сообщение PUBACK. Таким образом может быть достигается устойчивость соединения MQTT. Когда происходит PUBLISH, сообщение сохраняется на постоянном уровне, таком как диск, и удаляется при получении PUBACK. Сообщение с QoS 1 имеет идентификатор сообщения в заголовке сообщения.

QoS 2 (доставка только одного сообщения)

Дополнительные потоки к QoS 1 гарантируют, что сообщение доставляется ровно один раз. Сообщение отправляется в потоке PUBLISH, и сообщение сохраняется клиентом. Сообщение PUBREC отправляется как ответ на PUBLISH. Между тем сообщение заблокировано на сервере. При получении PUBREC PUBREL отправляется на сервер. Получив PUBREL, брокер отправляет сообщения, отправляет PUBCOMP и сбрасывает сохраненное состояние. Сообщение с QoS 2 будет иметь идентификатор сообщения в заголовке сообщения.

Безопасность в MQTT

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

Безопасность в MQTT подразделяется на несколько уровней.

Сетевой уровень: обеспечение безопасного соединения за счет использования физически защищенной сети или VPN.

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

Уровень приложения: протокол имеет идентификатор клиента, имя пользователя / пароль, используемые для аутентификации устройства. Другим способом является шифрование полезной нагрузки без использования расширенного транспортного шифрования.

MQTT в действии

Решение для домашнего мониторинга

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

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

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

В следующем посте мы рассмотрим протокол MQTT с помощью Wireshark. Это поможет нам понять связь между клиентом MQTT и брокером MQTT.

Изучение MQTT с использованием Wireshark

Перевод: @N3M351DA

Источник: http://blog.catchpoint.com/2017/07/06/dissecting-mqtt-using-wireshark/

Ранее мы рассмотрели протокол MQTT, как он работает и его роль в цифровом мире. Чтобы лучше понять содержание этой статьи, ознакомьтесь с основами межмашинного взаимодействия (M2M) в предыдущей статье «MQTT – Нервная Система IoT». Мы будем использовать монитор MQTT для отправления сообщений подписки/публикации от брокера MQTT. Изображение ниже иллюстрирует тест, настроенный с использованием Catchpoint.

Метрики мониторинга MQTT Catchpoint включают в себя время публикации, размер публикации, время подписки, размер подписки, DNS и время соединения.

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

Анализ с использованием Wireshark

Протокол MQTT основан на TCP / IP, и клиент и брокер должны поддерживать стек TCP / IP.

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

Примечание. На изображении выше IP 192.168.0.11 – это IP-адрес брокера MQTT, а 192.168.0.12 – действует как клиент публикации и клиент подписки.

1. Connect Message

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

Порт 1883 является портом по умолчанию для реализации протокола MQTT с помощью TCP.

Порт 8883 предназначен для реализации протокола MQTT с использованием TLS.

Рассмотрим детали сообщения подключения:

• Флаги заголовка: содержат информацию о типе пакета управления MQTT.

• Флаги соединения: байты флага соединения содержат параметры, определяющие поведение соединения MQTT. Он обозначает наличие или отсутствие полей в полезной нагрузке.

• Clean session: первый бит флагов соединения. Этот флаг указывает посреднику, хочет ли клиент установить постоянное соединение или нет. Если установлено значение «истина», результатом является сеанс, при котором подписки удаляются при отключении, а при значении «ложь» может быть достигнуто надежное соединение, когда сообщения с высоким QoS доставляются при повторном подключении.

• Will flag: второй бит флагов соединения. Часть механизма уведомления клиентов при потере соединения. При установке этот флаг означает, что, если запрос на соединение принят, на сервере должно быть сохранено сообщение Will. Сообщение Will – это сообщение MQTT с темой Will и сообщением Will. Оно используется при уведомлении других клиентов об отключении. Когда клиент отключается, брокер отправляет это сообщение от его имени. Когда флаг Will установлен в 1, серверы будут использовать поля Will QoS и Will Retain в флагах Connect.

• Will QoS: биты 4 и 3 флагов подключения. Обозначают уровень QoS, который будет использоваться при публикации сообщения Will.

• Will retain: Пятый бит флагов подключения. Если для параметра Will Retain установлено значение 0, сервер должен опубликовать сообщение Will без сохранения, а когда оно установлено в 1, сообщение Will публикуется как сообщение с сохранением.

• User Name and Password: биты 7 и 6 флагов подключения. Когда эти поля установлены, сервер будет ожидать учетные данные в полезной нагрузке. MQTT позволяет отправлять имя пользователя и пароль для аутентификации клиента и авторизации. Пароль отправляется в виде открытого текста, если он не зашифрован.

• Keep alive: Таймер поддержания активности используется для определения того, находится ли клиент MQTT в сети, для этого клиент отправляет брокеру регулярные сообщения запроса PING, а брокер отвечает PING-ответом.

• Client ID: идентификатор клиента MQTT, подключающегося к брокеру MQTT. Он должен быть уникальным для каждого брокера.

• Payload: полезная нагрузка содержит поля «Идентификатор клиента», «Тема», «Сообщение», «Имя пользователя» и «Пароль», наличие которых определяется флагами.

2. Connect Acknowledgment Message

Получив сообщение CONNECT, брокер отвечает сообщением CONNACK.

• Header Flags: содержит информацию о типе пакета управления MQTT.

• Session Present: бит 0 байта Connection Ack, является флагом присутствия сеанса. Этот флаг указывает, имеет ли брокер открытый сеанс клиента из предыдущих взаимодействий.

• Return Code: значения кода ответа и ответ в таблице ниже

• Payload: пакет CONNACK не имеет полезной нагрузки.

3. Subscribe Message

Клиент отправляет сообщение SUBSCRIBE брокеру MQTT для получения соответствующих ему сообщений.

• Header Flags: содержат информацию о типе пакета управления MQTT.

• Message Identifier: идентификатор между клиентом и брокером, служит для идентификации сообщения в потоке сообщений. Актуально для QoS выше нуля.

• Topic and QoS Level: Каждая подписка и тема представляет собой пару для фильтра тем и уровня QoS. Тема является предметом интереса клиента, который хотел бы получать сообщения о ней.

• Payload: полезная нагрузка содержит список подписок. Список подписок должен быть обязательно перечислен в пакете SUBSCRIBE.

4. Subscribe Acknowledgement Message

Брокер MQTT подтверждает подписку, отправляя подтверждение обратно клиенту в сообщении SUBACK.

• Header Flags: содержат информацию о типе пакета управления MQTT.

• Message Identifier: актуально для сообщения с QoS больше нуля, аналогичным указанному в сообщении SUBSCRIBE.

• Return Code: MQTT-брокер отправляет код ответа для каждой пары Тема / QoS, полученной в сообщении SUBSCRIBE. Код ответа соответствует уровню QoS в случае успеха. Значения кода ответа приведены в таблице ниже.

• Payload: полезная нагрузка содержит список кодов ответа.

5. Publish Message

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

• Header Flags: Содержат информацию о типе пакета управления MQTT.

• DUP flag: Если флаг DUP равен 0, это означает, что это первая попытка отправки пакета PUBLISH. Если флаг равен 1, это указывает на повторную попытку отправки сообщения.

• QoS: Уровень QoS определяет уровень достоверности сообщения.

• Retain Flag: Если данный флаг установлен в 1, сервер должен сохранить сообщение и его QoS, чтобы в дальнейшем обслуживать будущие подписки, соответствующие теме. Когда пакет PUBLISH отправляется подписывающемуся клиенту, сервер устанавливает Retain Flag в 1. Сервер устанавливает флаг сохранения в 0 при отправке пакета, если он соответствует установленной подписке, независимо от того, был ли установлен флаг при получении сообщения.

• Topic Name: Строка UTF-8, которая также может содержать косую черту, если она иерархически структурирована. Публикуемое сообщение должно содержать тему, которая используется брокером для фильтрации по темам. Таким образом, брокер будет отправлять сообщения клиентам, которые подписались на указанную тему.

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

• Payload: Содержит публикуемое сообщение.

6. Disconnect Request Message:

Сообщение об отключении – это окончательный контрольный пакет, отправленный клиентом брокеру, оно означает отключение клиентом от брокера.

• Header Flags: содержат информацию о типе пакета управления MQTT.

• Payload: пакет отключения не имеет полезной нагрузки.

7. MQTT Keep Alive

Функция поддержания активности (Keep Alive) гарантирует, что соединение открыто, а клиент и брокер связаны друг с другом. Когда соединение установлено, интервал поддержания активности (в секундах) передается брокеру клиентом.

В спецификации MQTT говорится:

«Клиент отвечает за то, чтобы интервал между отправляемыми контрольными пакетами не превышал значения Keep Alive. При отсутствии отправки каких-либо других управляющих пакетов клиент должен отправить пакет PINGREQ».

Поток Keep Alive поддерживается сообщениями PINGREQ и PINGRESP.

Типичный поток поддержания активности показан на рисунке ниже.

PINGREQ

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

• Header Flags: содержат информацию о типе пакета управления MQTT.

• Payload: пакет PINGREQ не имеет полезной нагрузки.

PINGRESP

PINGRESP – это ответ, который брокер отправляет в ответ на полученный пакет PINGREQ. Это указывает на доступность брокера для клиента.

• Header Flags: содержат информацию о типе пакета управления MQTT.

• Payload: пакет PINGRESP не имеет полезной нагрузки.

Заключение

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