MQTT против HTTP для IoT: почему MQTT — лучший выбор

MQTT (Message Queuing Telemetry Transport) и HTTP (Hypertext Transfer Protocol) — это два разных протокола связи, каждый со своими сильными и слабыми сторонами. Выбор между MQTT и HTTP зависит от конкретных требований вашего приложения. Вот несколько причин, почему MQTT может быть лучшим выбором, чем HTTP, в определенных сценариях.

В мире, где устройствам и компьютерам необходимо общаться друг с другом, существуют разные способы взаимодействия. Два из них называются MQTT и HTTP. MQTT — это сверхэффективный, быстрый и тихий мессенджер. Он отлично подходит для отправки небольших обновлений между устройствами, например, для передачи данных с датчика температуры на ваш телефон в режиме реального времени. С другой стороны, HTTP — это как отправка электронных писем или совершение телефонных звонков. Он хорош, когда вы что-то запрашиваете, например, загрузку веб-страницы, и получаете ответ. Но для быстрых и постоянных обновлений MQTT часто является лучшим выбором. В этой статье мы объясним, почему.

Что такое MQTT?

MQTT, что расшифровывается как Message Queuing Telemetry Transport (система обмена сообщениями, очередями и телеметрией), — это легковесный и эффективный протокол обмена сообщениями, предназначенный для надежной связи между устройствами в сети. Он использует модель «публикация-подписка», при которой устройства (или клиенты) взаимодействуют через центральный сервер, называемый брокером.

Как это работает?

В протоколе MQTT устройства могут выступать в роли издателей, подписчиков или и тех, и других. Издатели отправляют сообщения (или «публикуют» их) в определенные темы брокера, а подписчики выражают свой интерес к определенным темам, подписываясь на них. Когда издатель отправляет сообщение в тему, брокер гарантирует, что все подписчики, заинтересованные в этой теме, получат сообщение. Такой децентрализованный подход обеспечивает асинхронную связь в реальном времени, что делает MQTT хорошо подходящим для приложений, где устройствам необходимо быстро обмениваться информацией, например, в Интернете вещей (IoT). Кроме того, MQTT предлагает различные уровни качества обслуживания (QoS), позволяя пользователям выбирать уровень надежности доставки сообщений, от «не более одного раза» (когда сообщения могут быть потеряны) до «ровно один раз» (гарантируя доставку сообщения, но с большими накладными расходами). Эта гибкость делает MQTT адаптируемым к различным сценариям связи, от передачи данных с датчиков с низкой задержкой до более надежных, критически важных для бизнеса приложений.

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

Краеугольным камнем этого процесса является концепция Темы. Темы служат основой для маршрутизации сообщений MQTT и напоминают пути URL, используя /для иерархической структуры, например sensor/1/temperature,. Подписчики подписываются на интересующие их темы, и когда издатель отправляет сообщение в эту тему, оно пересылается в соответствии со структурой темы.

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

Что такое HTTP?

HTTP (Hypertext Transfer Protocol), или протокол передачи гипертекста, — это основной протокол интернета, используемый для передачи и приема данных между веб-браузерами и веб-серверами. Он лежит в основе обмена информацией во Всемирной паутине. HTTP работает по модели «запрос-ответ»: когда вы вводите веб-адрес в свой браузер и нажимаете «Enter», ваш браузер отправляет HTTP-запрос на удаленный веб-сервер. Этот запрос обычно указывает желаемую веб-страницу или ресурс, и сервер отвечает HTTP-ответом, предоставляя запрошенный контент вместе с информацией о статусе запроса. Этот ответ может включать текст, изображения, видео или любые другие данные, составляющие веб-страницу.

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

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

В протоколе HTTP для обозначения местоположения ресурсов используются URL-адреса , аналогично тому, как в MQTT используются темы. Например, URL-адрес HTTP-запроса, такой как http://example.com/api/sensor, имеет схожий многоуровневый формат с темой MQTT, например , .sensor/1/temperature

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

Разница между MQTT и HTTP

Вот несколько причин, почему MQTT может быть лучшим выбором, чем HTTP, в определенных сценариях:

Низкие накладные расходы: MQTT разработан для связи с низкими накладными расходами. Он использует модель «публикация/подписка», которая более эффективна для отправки небольших пакетов данных. HTTP, с другой стороны, имеет большие накладные расходы из-за своей модели «запрос/ответ» и заголовков, что делает его менее эффективным для частых и небольших обновлений данных.

Режим реального времени и асинхронность: MQTT идеально подходит для связи в режиме реального времени и асинхронно. Он позволяет отправлять push-уведомления и мгновенно обновлять данные при их изменении, что делает его подходящим для таких приложений, как Интернет вещей (IoT), где данные с датчиков необходимо передавать в режиме реального времени. В отличие от этого, HTTP обычно работает на основе запросов, что может приводить к задержкам.

Модель «публикация/подписка»: данная модель протокола MQTT хорошо подходит для сценариев, когда нескольким клиентам необходимо получать одну и ту же информацию. Подписчики могут получать данные без необходимости запрашивать их, что делает передачу данных нескольким потребителям более эффективной.

Среды с низкой пропускной способностью и высокой задержкой: MQTT разработан для эффективной работы в условиях низкой пропускной способности и высокой задержки. Он использует легковесный бинарный протокол, который уменьшает объем обмениваемых данных. HTTP может быть менее эффективен в таких сценариях из-за своей текстовой природы и дополнительных заголовков.

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

Надежная передача сообщений: MQTT поддерживает уровни качества обслуживания (QoS), которые позволяют выбирать уровень надежности доставки сообщений — от «не более одного раза» до «точно один раз». Это может быть критически важно в приложениях, где необходима целостность данных.

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

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

MQTT против HTTP

Данные протоколы сравнены по нескольким критериям в следующей таблице

Аспект	MQTT	HTTP
Модель коммуникации	Публикация-Подписка	Запрос-Ответ
Эффективность	Низкие накладные расходы, подходит для Интернета вещей.	Более высокие накладные расходы, подходит для веб-сайтов.
Режим реального времени	Поддерживает режим реального времени и push-уведомления.	Как правило, обработка происходит по запросу, а не в режиме реального времени.
Асинхронность	Асинхронная передача сообщений	Синхронный запрос-ответ
Доставка сообщений	Поддерживает уровни качества обслуживания (QoS) для обеспечения надежности.	Встроенных уровней QoS нет.
Публикация-Подписка	Используется модель «публикация-подписка», позволяющая нескольким клиентам получать одни и те же данные.	Клиент-серверная модель, требующая явных запросов.
Масштабируемость	Хорошо масштабируется для большого количества клиентов.	Масштабируемость присутствует, но для аналогичных нагрузок может потребоваться больше ресурсов.
Типы данных	Подходит для передачи данных небольшого объема, например, данных с датчиков.	Обычно используется для передачи веб-контента, включая текст, изображения, видео и т. д.
Низкая пропускная способность	Эффективен в условиях низкой пропускной способности и высокой задержки.	В таких условиях может быть менее эффективным.
Безопасность	Может быть защищен с помощью аутентификации и шифрования.	Также может быть защищен с помощью аутентификации и шифрования.
Использование	Широко используется в Интернете вещей (IoT), межмашинном взаимодействии (M2M) и приложениях для обработки данных в реальном времени.	Необходим для просмотра веб-страниц, работы с веб-сервисами и взаимодействия пользователей с веб-сайтами.
Протокол	Бинарный протокол, облегченный	Текстовый протокол, больше накладных расходов
Тип подключения	Постоянные соединения — обычное явление.	Как правило, не сохраняющее состояние соединение, с отдельными соединениями для каждого запроса.

В итоге:

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

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

Также важно отметить, что MQTT и HTTP используются в разных сценариях, и выбор между ними зависит от конкретных требований вашего приложения. Во многих случаях их можно использовать совместно, дополняя друг друга: HTTP подходит для определенных типов взаимодействий (например, веб-интерфейсов), а MQTT — для обмена данными в реальном времени с низкой задержкой и высокой эффективностью, особенно в сценариях IoT и межмашинной связи (M2M).

Когда следует выбирать MQTT

MQTT — лучший выбор, если ваше IoT-приложение требует:

• Связь между устройствами в режиме реального времени;
• Частая передача данных с датчиков;
• Низкое потребление полосы пропускания;
• Связь по нестабильным сетям;
• Большое количество подключенных устройств;
• Двусторонняя передача сообщений между устройствами и приложениями.

К распространённым сценариям использования MQTT относятся:

• Мониторинг промышленного интернета вещей;
• Устройства для умного дома;
• Телеметрия транспортного средства;
• системы управления энергопотреблением;
• Дистанционное управление оборудованием;
• Панели мониторинга в реальном времени.

Когда следует выбирать HTTP

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

HTTP подходит в следующих случаях:

• Устройства обмениваются данными периодически, а не непрерывно.
• Для работы приложений требуется интеграция с REST API.
• Важна совместимость с браузерами.
• Разработчикам необходима простая связь типа «запрос-ответ».
• Системы уже полагаются на веб-инфраструктуру.

К типичным сценариям использования HTTP относятся:

• Конфигурация устройства;
• Обновления прошивки;
• Облачный API-интерфейс для связи;
• Приложения, ориентированные на пользователя;
• Услуги по извлечению данных.

Еще одна мысль: интеграция MQTT с HTTP

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

Например, в типичном приложении IoV протокол HTTP хорошо подходит для взаимодействия с пользователем. Представьте, что пользователь управляет автомобилем в гараже с помощью кнопки «открыть дверь» в приложении. Это действие не является двусторонним обменом данными между приложением и сервером, и использование HTTP позволяет осуществлять более сложные и гибкие проверки безопасности и разрешений. С другой стороны, для связи между сервером и транспортным средством необходима двусторонняя связь в реальном времени: транспортное средство должно оперативно реагировать на действия пользователя.

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

Ведущий в мире брокер MQTT, EMQX, обеспечивает этот процесс, легко и гибко интегрируя протокол MQTT с протоколом HTTP.

HTTP → MQTT:

Система приложений может преобразовывать HTTP-запросы в сообщения MQTT, отправляемые на определенные устройства, путем вызова API, предоставляемого EMQX. Это позволяет системе отправлять команды управления или уведомления на устройства.

MQTT → HTTP:

Когда устройство отправляет сообщение MQTT в EMQX, функция Webhook может перенаправить это сообщение на HTTP-сервер, мгновенно передавая данные устройства в систему приложения.

Интерфейс конфигурации выглядит следующим образом:

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

Часто задаваемые вопросы о сравнении MQTT и HTTP

MQTT лучше, чем HTTP, для интернета вещей? 

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

Может ли MQTT заменить HTTP?

MQTT не полностью заменяет HTTP. Многие системы IoT используют оба протокола вместе: MQTT отвечает за связь между устройствами, а HTTP — за интерфейсы приложений, API и взаимодействие с пользователем.

MQTT быстрее, чем HTTP?

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

Безопасен ли протокол MQTT?

MQTT поддерживает безопасную связь с помощью шифрования TLS, механизмов аутентификации и средств контроля авторизации, таких как разрешения доступа на основе тем.

Могут ли протоколы MQTT и HTTP работать вместе?

Да. Многие платформы IoT объединяют протоколы MQTT и HTTP. MQTT обычно используется для обмена сообщениями между устройствами и облаком, а HTTP — для API, панелей мониторинга и интеграции приложений.

Заключение

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