Когда и зачем использовать протокол MQTT?

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

В каком случае и почему я должен перейти с HTTPS на MQTT?

MQTT - это «мессенджер» между устройствами:

• Ваше устройство измеряет в момент времени Т температуру X градусов
• он подключается (сам или через концентратор zwave) к брокеру MQTT
• это создать сообщение с темой /domotics/myplace/mydevice/temperature
• в сообщении, которое он просто помещает X(как «полезная нагрузка»)

В другом месте в вашем доме:

• ваш Raspberry Pi подключен к брокеру MQTT (это может быть сам экземпляр MQTT)
• он подписывается на тему, /domotics/+/+/temperatureчтобы получать ВСЕ сведения о температуре от всех устройств, использующих этот формат темы. См. Спецификацию MQTT для получения дополнительной информации о подстановочных знаках темы MQTT ( +и #).
• он получит сообщение с полезной нагрузкой Xи сделает все, что захочет!

В другом месте в вашем доме:

• ваш компьютер подключен к брокеру MQTT и подписывается на тему, /domotics/myplace/mydevice/#чтобы получить ВСЕ данные с вашего устройства и зарегистрировать их
• он получит сообщение с полезной нагрузкой Xи сделает все, что захочет!

MQTT очень полезен, чтобы избежать размещения веб-сервисов и сокетов вокруг ваших серверов. Node-RED использует MQTT, и Domoticz может быть настроен на получение inи настройку outсигналов.

Я лично использую MQTT у себя дома, чтобы выключить компьютеры: /house/computers/mycomputerpayload:0

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

HTTP / HTTPS разработан как протокол запроса-ответа для клиент-серверных вычислений, который никогда не беспокоится об энергопотреблении и имеет много служебных данных.

Используйте MQTT, если:

• Устройство, которое вы используете, работает от аккумуляторной батареи, и вы не хотите заменять его каждые x чисел дней (MQTT оптимизирован для использования батареи, а HTTP / S - нет).
• Нужен более быстрый ответ
• Нужно иметь механизм pub / sub (если вы хотите отправить сообщения многим клиентам)
• Нужно надежно отправлять данные с разными уровнями QoS

MQTT предлагает такую ​​же безопасность, как HTTPS?

MQTT использует TCP в качестве транспортного протокола, что означает, что по умолчанию соединение не использует зашифрованное соединение. Для шифрования всей связи MQTT большинство брокеров MQTT, таких как HiveMQ, позволяют использовать TLS вместо обычного TCP.

Ссылка: HiveMQ

MQTT (Telemetry Transport с очередью сообщений), кажется, хорошо подходит для предлагаемого применения.

Он облегчен как по пропускной способности (наименьший размер пакета с заголовком всего 2 байта), так и по размеру клиентского кода (что позволяет ему работать на тонких клиентах, таких как ESP8266, типичный клиент IoT). Сокращение передаваемых данных выгодно для увеличения срока службы батареи для клиентов, работающих от автономной батареи, например датчиков.

MQTT также предлагает простые методы ( глаголы ), которые хорошо подходят для задач IoT, такие как долговременные подписки, которые восстанавливают соединения после неожиданного отключения клиента. По сравнению с HTTP / HTTPS также проще извлекать данные из пакета (анализатор не требуется).

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

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

С точки зрения трафика, ЦП, памяти и энергопотребления MQTT и HTTP в основном совпадают.

Что касается вашей цитаты, MQTT - это «протокол Интернета вещей»:

Да, существует большое количество разработчиков, использующих этот протокол (см. IoT Developer Survey 2018), но CoAP (это HTTP с поправкой на IoT, основанный на UDP) предоставляет альтернативу для HTTP в случае, если вы хотите использовать легкие функции Запрос / Ответ в ваше приложение.

С другой стороны, MQTT предоставляет встроенную логику публикации / подписки, которая отлично подходит для масштабирования (вы можете использовать больше шлюзов для большего количества устройств). Существует также альтернатива UDP (например, CoAP-HTTP), которая называется MQTT-SN (MQTT для сенсорных сетей). Это обеспечивает даже меньшую нагрузку, чем CoAP, но не использует R / R.