В чем разница между MQTT и веб-сокетами, и когда я должен их использовать?

Каковы основные различия между MQTT и веб-сокетами?

При использовании IoT для домашней автоматизации - контроль и мониторинг доступа через разные устройства, какое из них следует использовать, когда требуется доступ через API на основе Rest и браузер.

Я использую Java (библиотека Pi4J) на Raspberry Pi 2 B +.

У меня есть несколько датчиков, таких как свет и темнота, влажность, PID и т. Д.

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

communication monitoring mqtt Shakti Phartiyal
источник

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

Ответы:

Задаваемый здесь вопрос немного вводит в заблуждение, поскольку на самом деле эти протоколы вообще нельзя сравнивать друг с другом. Они похожи на TCP и IP, слои друг над другом. [1]

Websockets - это низкоуровневый протокол, обеспечивающий то, чего не обеспечивает RESTful http своего «конкурента», который находится на том же уровне: всегда открытый канал без необходимости открывать и закрывать каждый запрос. [2]

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

В IoT, как и в любом дизайне, вы должны выбрать, нужен ли вам поток (WebSockets vs RESTful), а в отношении MQTT вам, возможно, придется подумать, хотите ли вы использовать механизм подписки и публикации в своем приложении.

В некоторых случаях вы можете рассмотреть MQTT через WebSockets, если есть что-то общее. [3]

Ответ на вопрос:

Вы говорите, что у вас есть установка Rasperry Pi и несколько датчиков по всему месту. Если датчики находятся далеко от Rasperry со своими собственными контроллерами, вы можете использовать MQTT для сбора данных. Чтобы сохранить данные в облаке, отправьте данные в HTTP. В облаке предоставляем данные через отдых. [4]

Для веб-сокетов это не нужно, но если вы найдете это полезным, используйте его.

Источники:

[1] https://www.quora.com/What-are-the-pros-and-cons-of-WebSockets-versus-MQTT-as-real-time-web-infrastructure-for-the-Internet-of -Вещи

[2] https://www.pubnub.com/blog/2015-01-05-websockets-vs-rest-api-understanding-the-difference/

[3] /programming/30624897/direct-mqtt-vs-mqtt-over-websocket

[4] http://www.theinternetofthings.eu/antonio-grasso-mqtt-vs-http-what-best-protocol-iot

Мико
источник

Также имеет отношение к вашему последнему замечанию: Этот ответ от Roger Light, разработчика брокера Mosquitto MQTT, сравнивает варианты использования необработанных сокетов с веб-сокетами с помощью MQTT.

Aurora0001

Спасибо, мико, это замечательное объяснение. но мне все еще не ясно, что использовать .. что бы вы порекомендовали для моего сценария?

Shakti Phartiyal

Хороший ответ, но: использование «открывать и закрывать» WRT WS: // против HTTP: // может вводить в заблуждение; во-первых, запросы HTTP 1.1 могут быть конвейерными, поэтому на уровне буквальных сокетов одно соединение может включать в себя неопределенное количество запросов без открытия и закрытия в этом смысле. Было бы лучше сказать, что преимущество веб-сокетов состоит в том, что нет обязательств по синхронному циклу «запрос и ответ» ; у вас есть открытый, двунаправленный канал с минимальным набором правил для обмена.

Златовласка

«Чтобы установить постоянное открытое соединение в MQTT, вам необходимо одновременно использовать Websockets AND MQTT». Вы уверены в этом? Пожалуйста, объясните, почему MQTT должен использовать webSockets для поддержания «постоянного открытого соединения», если клиент может просто продолжать публиковать пакеты PINGRESP обратно на сервер? Клиент, реализующий MQTT, отправит пакет PINGRESP, чтобы поддержать соединение, а клиент, реализующий webSockets, будет использовать keepAlive () для отправки пустого пакета webSocket.send ('') на сервер, чтобы поддерживать соединение живым.

Джон

Хм .. Вы можете поддерживать соединение с этим пакетом . Я обнаружил, что MQTT работает через TCP / IP (не HTTP). В этом случае вы можете оставить соединение открытым.

Мико

Они сравнимы в том, что оба позволяют вам иметь полнодуплексный обмен данными, так что сервер может немедленно передать данные клиенту без опроса клиента (как это может быть с HTTP).

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

MQTT обладает множеством других полезных функций, например сохраняемых сообщений, так что подписчики немедленно получают сообщение, и LWT (Последняя воля и Завет), который представляет собой сообщение, которое может отправляться автоматически, если клиент ненормально отключается. Таким образом, MQTT - это «выше по стеку», предлагающий функции и абстракции, которых нет у простого Websocket.

TheMagicCow
источник