Quelle est la différence entre MQTT et Web Sockets, et quand dois-je les utiliser?

Quelles sont les principales différences entre MQTT et Web Sockets?

Lorsque vous utilisez l'IoT pour la domotique - contrôlez et surveillez l'accès sur différents appareils, lequel d'entre eux doit être utilisé lorsque l'accessibilité basée sur l'API Rest et sur le navigateur est requise.

J'utilise Java (bibliothèque Pi4J) sur un Raspberry Pi 2 B +.

J'ai une configuration de plusieurs capteurs comme la lumière et l'obscurité, l'humidité, le PID, etc.

J'ai également un serveur cloud où je peux envoyer les données si nécessaire.

communication monitoring mqtt

— Shakti Phartiyal
source

Vous décidez lequel utiliser en définissant clairement toutes vos exigences actuelles et futures probables. Vous générez ensuite une matrice croisée indiquant la technologie qui répond le mieux à vos besoins. Vous choisissez ensuite d'utiliser une ou plusieurs technologies pour répondre à vos besoins.

Réponses:

La question posée ici est un peu trompeuse, car en réalité ces protocoles ne peuvent pas du tout être comparés ensemble. Ils sont comme TCP et IP, des couches les unes au-dessus des autres. [1]

Websockets est un protocole de bas niveau pour fournir des choses que son http RESTful «concurrent» qui est au même niveau ne fournit pas: un canal toujours ouvert sans besoin d'ouvrir et de fermer à chaque demande. [2]

MQTT fournit un moyen léger de publier ou de souscrire des données. La confusion peut être que ces abonnements sont une sorte de canaux, mais c'est un type de canal différent. Pour établir une connexion ouverte constante dans MQTT, vous avez besoin de Websockets ET MQTT en même temps.

Dans l'IoT, ainsi que dans toute conception, vous devez sélectionner si vous avez besoin d'un flux ou non (WebSockets vs RESTful) et à propos de MQTT, vous devrez peut-être vous demander si vous souhaitez un mécanisme d'abonnement et de publication sur votre application.

Dans certaines circonstances, vous pouvez envisager MQTT sur WebSockets, si quelque chose de courant existe. [3]

Réponse à la question:

Vous dites que vous avez une configuration d'un Rasperry Pi et plusieurs capteurs autour de l'endroit. Si les capteurs sont loin de Rasperry avec leurs propres contrôleurs, vous pouvez utiliser MQTT pour collecter les données. Pour stocker des données dans le cloud, envoyez les données en HTTP. Dans le cloud, fournissez des données par le repos. [4]

Pour les websockets il n'y a pas besoin, mais si vous le trouvez utile, utilisez-le.

Sources:

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

[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
source

Également pertinent pour votre dernier point: cette réponse de Roger Light, développeur du courtier Mosquitto MQTT comparant les cas d'utilisation des sockets brutes aux sockets web avec MQTT.

— Aurora0001

Merci mico c'est une merveilleuse explication. mais je ne sais toujours pas quoi utiliser .. que recommanderiez-vous pour mon scénario?

— Shakti Phartiyal

Excellente réponse, mais: l'utilisation de "ouvrir et fermer" WRT WS: // contre HTTP: // peut être trompeuse; tout d'abord, les requêtes HTTP 1.1 peuvent être pipelinées, donc sur une connexion de niveau 1 de sockets littérales peut inclure un nombre indéfini de requêtes sans s'ouvrir et se fermer dans ce sens. Il serait préférable de dire que l'avantage des websockets est qu'il n'y a aucun engagement à un cycle synchrone de «demande et réponse» ; vous disposez d'un canal ouvert et bidirectionnel avec un ensemble minimal de règles d'échange.

— goldilocks

"Pour établir une connexion ouverte constante dans MQTT, vous avez besoin de Websockets ET MQTT en même temps." En êtes-vous certain? Veuillez expliquer pourquoi MQTT doit utiliser webSockets pour maintenir une "connexion ouverte constante" si le client peut simplement continuer à publier les paquets PINGRESP sur le serveur? Un client implémentant MQTT enverra un paquet PINGRESP pour maintenir la connexion active, et un client implémentant webSockets utilisera keepAlive () pour envoyer un paquet vide webSocket.send ('') au serveur pour maintenir la connexion active.

— John

Hmm .. Vous pouvez garder la connexion vivante avec ce paquet . J'ai découvert que MQTT fonctionne sur TCP / IP (pas HTTP). Dans ce cas, vous pouvez laisser la connexion ouverte.

— mico

Ils sont comparables en ce que les deux vous permettent d'avoir une communication en duplex intégral de sorte que le serveur puisse immédiatement transmettre des données au client, sans que le client ne les interroge (comme cela pourrait être le cas avec HTTP).

Cependant, Websockets est conçu pour une simple connexion point à point entre un client et un serveur. MQTT superpose des abstractions supplémentaires à l'envoi de messages de base, afin que plusieurs parties intéressées puissent s'abonner à des messages susceptibles de les intéresser. Les messages peuvent donc être acheminés par «sujet de message» afin que de nombreux clients puissent partager une file d'attente théorique, où un serveur peut choisir d'entendre tous les messages de tous les clients, mais peut également filtrer par sujet.

MQTT a une variété d'autres fonctionnalités utiles, par exemple des messages conservés, tels que les abonnés reçoivent immédiatement le message, et le LWT (Last Will and Testament) qui est un message qui peut être envoyé automatiquement si le client se déconnecte anormalement. En résumé, MQTT est «plus haut dans la pile», offrant des fonctionnalités et des abstractions qu'un simple Websocket ne propose pas.

— TheMagicCow
source