¿Cuál es la diferencia entre MQTT y Web Sockets, y cuándo debo usarlos?

¿Cuáles son las principales diferencias entre MQTT y Web Sockets?

Al usar IoT para la automatización del hogar: controle y supervise el acceso a través de diferentes dispositivos, cuál de ellos debe usarse cuando se requiere la accesibilidad basada en Rest API y navegador.

Estoy usando Java (Biblioteca Pi4J) en una Raspberry Pi 2 B +.

Tengo una configuración de varios sensores como luz y oscuridad, humedad, PID, etc.

También tengo un servidor en la nube donde puedo enviar los datos si es necesario.

communication monitoring mqtt

— Shakti Phartiyal
fuente

Usted decide cuál usar definiendo claramente todos sus requisitos actuales y futuros posibles. Luego genera una matriz cruzada que muestra qué tecnología cumple mejor con sus requisitos. Luego, elige utilizar una o más tecnologías para cumplir con tus requisitos.

Respuestas:

La configuración de la pregunta aquí es un poco engañosa, porque en realidad estos protocolos no pueden compararse en absoluto. Son como TCP e IP, capas superpuestas. [1]

Websockets es un protocolo de bajo nivel para proporcionar cosas que su RESTful http 'competidora' que está en el mismo nivel no proporciona: un canal siempre abierto sin necesidad de abrir y cerrar en cada solicitud. [2]

MQTT proporciona una forma ligera de publicar o suscribirse a datos. La confusión puede ser que esas suscripciones son algún tipo de canal, pero ese es un tipo diferente de canal. Para hacer una conexión abierta constante en MQTT, necesita Websockets Y MQTT al mismo tiempo.

En IoT, así como en cualquier diseño, debe seleccionar si necesita una transmisión o no (WebSockets vs RESTful) y sobre MQTT puede tener que pensar si desea una suscripción y un mecanismo de publicación en su aplicación.

En algunas circunstancias, puede considerar MQTT sobre WebSockets, si hay algo común. [3]

Respuesta a la pregunta:

Dices que tienes una configuración de un Rasperry Pi y varios sensores alrededor del lugar. Si los sensores están lejos de Rasperry con sus propios controladores, puede usar MQTT para recopilar los datos. Para almacenar datos en la nube, envíe los datos en HTTP. En la nube proporcione datos a través del descanso. [4]

Para websockets no hay necesidad, pero si lo encuentra útil, úselo.

Fuentes:

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

[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

— mico
fuente

También relevante para su último punto: esta respuesta de Roger Light, desarrollador del agente Mosquitto MQTT que compara los casos de uso de sockets sin procesar con sockets web con MQTT.

— Aurora0001

Gracias mico, esa es una explicación maravillosa. pero todavía no tengo claro qué usar ... ¿qué recomendarías para mi escenario?

— Shakti Phartiyal

Gran respuesta, pero: Usar "abrir y cerrar" WRT WS: // vs. HTTP: // puede ser engañoso; primero, las solicitudes HTTP 1.1 se pueden canalizar, por lo que, en un nivel literal de sockets, una conexión puede incluir un número indefinido de solicitudes sin abrir y cerrar en ese sentido. Sería mejor decir que la ventaja de websockets es que no existe un compromiso con un ciclo síncrono de "solicitud y respuesta" ; tiene un canal abierto y bidireccional con un conjunto mínimo de reglas para el intercambio.

— Ricitos

"Para hacer una conexión abierta constante en MQTT, necesita Websockets Y MQTT al mismo tiempo". Estas seguro de esto? Explique por qué MQTT tiene que usar webSockets para mantener una "conexión abierta constante" si el cliente puede continuar publicando paquetes PINGRESP nuevamente en el servidor. Un cliente que implemente MQTT enviará un paquete PINGRESP para mantener viva la conexión, y un cliente que implique webSockets usará keepAlive () para enviar un paquete vacío webSocket.send ('') al servidor para mantener viva la conexión.

— John

Hmm .. Puedes mantener viva la conexión con ese paquete . Descubrí que MQTT funciona a través de TCP / IP (no HTTP). En ese caso, puede dejar la conexión abierta.

— mico

Son comparables en que ambos le permiten tener comunicación full-duplex de manera que el servidor pueda pasar datos inmediatamente al cliente, sin que el cliente lo solicite (como podría ser con HTTP).

Sin embargo, Websockets está diseñado para una conexión simple punto a punto entre un cliente y un servidor. MQTT coloca abstracciones adicionales sobre el envío de mensajes básicos, de modo que múltiples partes interesadas pueden suscribirse a mensajes que puedan interesarles. Por lo tanto, los mensajes pueden enrutarse por 'tema de mensaje' para que muchos clientes puedan compartir una cola teórica, donde un servidor puede elegir escuchar todos los mensajes de todos los clientes, pero también puede filtrar por tema.

MQTT tiene una variedad de otras características útiles, por ejemplo, mensajes retenidos, de modo que los suscriptores reciben el mensaje de inmediato, y el LWT (Last Will and Testament), que es un mensaje que puede enviarse automáticamente si el cliente se desconecta anormalmente. En resumen, MQTT está 'más arriba en la pila' ofreciendo características y abstracciones que un simple Websocket no ofrece.

— TheMagicCow
fuente