Qual è la differenza tra MQTT e Web Socket e quando dovrei usarli?

Quali sono le principali differenze tra MQTT e Web Socket?

Quando si utilizza l'IoT per l'automazione domestica, controllare e monitorare l'accesso su diversi dispositivi, quale di questi dovrebbe essere utilizzato quando è richiesta l'accessibilità basata su API Rest e basata su browser.

Sto usando Java (Libreria Pi4J) su un Raspberry Pi 2 B +.

Ho una configurazione di diversi sensori come luce e buio, umidità, PID ecc.

Ho anche un server cloud dove posso inviare i dati se necessario.

communication monitoring mqtt

— Shakti Phartiyal
fonte

Decidi tu quale utilizzare definendo chiaramente tutti i tuoi requisiti attuali e probabili futuri. Quindi si genera una matrice incrociata che mostra quale tecnologia soddisfa meglio le proprie esigenze. Scegli quindi di utilizzare una o più tecnologie per soddisfare le tue esigenze.

Risposte:

L'impostazione della domanda qui è un po 'fuorviante, perché in realtà questi protocolli non possono assolutamente essere confrontati insieme. Sono come TCP e IP, strati uno sopra l'altro. [1]

Websocket è un protocollo di basso livello per fornire cose che il suo http RESTful 'concorrente' allo stesso livello non fornisce: un canale sempre aperto senza necessità di aprire e chiudere ad ogni richiesta. [2]

MQTT offre un modo leggero per pubblicare o sottoscrivere dati. La confusione potrebbe essere che tali abbonamenti siano una sorta di canali, ma questo è un diverso tipo di canale. Per stabilire una connessione aperta costante in MQTT sono necessari Websocket E MQTT contemporaneamente.

In IoT, così come in qualsiasi progetto, devi selezionare se hai bisogno di un flusso o meno (WebSocket vs RESTful) e su MQTT potresti dover pensare se vuoi un abbonamento e un meccanismo di pubblicazione sulla tua app.

In alcune circostanze puoi considerare MQTT su WebSocket, se c'è qualcosa di comune in giro. [3]

Rispondi alla domanda:

Dici di avere una configurazione di un Rasperry Pi e diversi sensori in tutto il luogo. Se i sensori sono lontani da Rasperry con i propri controller, è possibile utilizzare MQTT per raccogliere i dati. Per archiviare i dati nel cloud, inviare i dati in HTTP. Nel cloud fornire dati attraverso il resto. [4]

Per i websocket non è necessario, ma se lo trovi utile, usalo.

fonti:

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

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

Rilevante anche per il tuo ultimo punto: questa risposta di Roger Light, sviluppatore del broker Mosquitto MQTT che confronta i casi d'uso di socket grezzi con socket Web con MQTT.

— Aurora0001

Grazie mico questa è una spiegazione meravigliosa. ma non sono ancora chiaro cosa usare .. cosa consiglieresti per il mio scenario?

— Shakti Phartiyal,

Ottima risposta, ma: l'utilizzo di "apri e chiudi" WRT WS: // vs. HTTP: // potrebbe essere fuorviante; in primo luogo, le richieste HTTP 1.1 possono essere pipeline, quindi a livello letterale socket una connessione può includere un numero indefinito di richieste senza aprirsi e chiudersi in quel senso. Sarebbe meglio dire che il vantaggio dei websocket è che non c'è impegno per un ciclo sincrono di "richiesta e risposta" ; hai un canale aperto e bidirezionale con un insieme minimo di regole per lo scambio.

— Riccioli d'oro,

"Per stabilire una connessione aperta costante in MQTT sono necessari Websocket E MQTT allo stesso tempo." Ne sei sicuro? Spiegare perché MQTT deve utilizzare webSocket per mantenere una "connessione aperta costante" se il client può semplicemente continuare a pubblicare i pacchetti PINGRESP sul server? Un client che implementa MQTT invierà un pacchetto PINGRESP per mantenere attiva la connessione e un client che impianta webSocket utilizzerà keepAlive () per inviare un pacchetto vuoto webSocket.send ('') al server per mantenere attiva la connessione.

— Giovanni

Hmm .. Puoi mantenere viva la connessione con quel pacchetto . Ho scoperto che MQTT funziona su TCP / IP (non HTTP). In tal caso è possibile lasciare aperta la connessione.

— mico,

Sono comparabili in quanto entrambi consentono di avere una comunicazione full duplex in modo tale che il server possa passare immediatamente i dati al client, senza che il client esegua il polling (come potrebbe essere con HTTP).

Tuttavia, Websocket è progettato per una semplice connessione punto-punto tra un client e un server. MQTT sovrappone ulteriori astrazioni oltre all'invio di messaggi di base, in modo che più parti interessate possano sottoscrivere messaggi che potrebbero interessarli. I messaggi possono quindi essere instradati per "argomento del messaggio" in modo che molti client possano condividere una coda nozionale, in cui un server può scegliere di ascoltare tutti i messaggi di tutti i client, ma può anche filtrare per argomento.

MQTT ha una varietà di altre utili funzioni, ad esempio messaggi conservati, in modo tale che gli abbonati ricevano immediatamente il messaggio e LWT (Last Will and Testament) che è un messaggio che può essere inviato automaticamente se il client si disconnette in modo anomalo. In sintesi, MQTT è "più in alto nello stack" offrendo funzionalità e astrazioni che un semplice WebSocket non offre.

— TheMagicCow
fonte