Quali sono i vantaggi di MQTT rispetto al protocollo HTTP tradizionale?

HTTP è il protocollo più ampiamente utilizzato e popolare. Ma MQTT ha rapidamente guadagnato terreno negli ultimi anni. Quando si discute di sviluppo IoT, gli sviluppatori devono scegliere tra questi due.

MQTT si concentra sui dati mentre HTTP si concentra sui documenti. HTTP è un protocollo richiesta-risposta per l'elaborazione client-server, che non è sempre ottimizzato per i dispositivi mobili. In questi termini, i principali vantaggi di MQTT sono: leggerezza (MQTT trasferisce i dati sotto forma di array di byte) e modello publish/subscribe, che rende MQTT molto adatto per dispositivi con risorse limitate e aiuta a risparmiare la batteria. Inoltre, il modello publish/subscribe consente ai client di essere indipendenti l'uno dall'altro, aumentando così l'affidabilità del sistema complessivo. In caso di guasto del client, l'intero sistema continua a funzionare normalmente.

Ci sono ancora molti vantaggi di MQTT, come segue:

1. Basso overhead del protocollo, MQTT è unico in quanto la sua intestazione per messaggio può essere breve quanto 2 byte. Sia MQ che HTTP hanno un overhead per messaggio molto più elevato. Con HTTP, ristabilire la connessione HTTP per ogni nuovo messaggio di richiesta comporta un overhead significativo. Le connessioni persistenti utilizzate da MQ e MQTT riducono significativamente questo overhead.

2. Tolleranza alle reti instabili, MQTT e MQ possono recuperare da guasti come la disconnessione e non vi è alcun ulteriore requisito di codice. Tuttavia, HTTP non può farlo in modo nativo, richiedendo ai client di riprovare la codifica, il che può aumentare i problemi di idempotenza.

3. Basso consumo energetico, MQTT è appositamente progettato per un basso consumo energetico. HTTP non è stato progettato per tenerne conto, aumentando così il consumo energetico.

4. I client con milioni di connessioni, sullo stack HTTP, che mantengono milioni di connessioni simultanee richiedono molto lavoro per fornire supporto. Sebbene questo supporto sia possibile, la maggior parte dei prodotti commerciali è ottimizzata per gestire connessioni persistenti di questo ordine di grandezza. IBM offre IBM MessageSight, un singolo server rack mount testato per gestire fino a 1 milione di dispositivi connessi contemporaneamente tramite MQTT. Al contrario, MQTT non è progettato per un gran numero di client simultanei.

5. Notifiche push, devi essere in grado di inviare notifiche ai clienti in modo tempestivo. Per questo, deve essere impiegato un qualche tipo di polling periodico o push; push è la soluzione migliore dal punto di vista della batteria, del carico di sistema e della larghezza di banda.

La nostra azienda potrebbe dover inviare informazioni sensibili senza l'intermediazione di una terza parte. Ciò riduce il valore delle soluzioni specifiche del sistema operativo (come Apple iOS, notifiche di Google Play) come meccanismo di trasporto primario.

HTTP consente solo un metodo chiamato COMET, utilizzando richieste HTTP persistenti per eseguire push. Questo approccio è costoso sia dal punto di vista del client che del server. Sia MQ che MQTT supportano push come caratteristica fondamentale.

6. Differenze di piattaforma client, sia i client HTTP che MQTT sono stati implementati su un gran numero di piattaforme. La semplicità di MQTT aiuta a implementare MQTT su client aggiuntivi con il minimo sforzo.

7. Tolleranza ai guasti del firewall, alcuni firewall aziendali limitano le connessioni in uscita ad alcune porte definite. Queste porte sono solitamente limitate a HTTP (porta 80), HTTPS (porta 443), ecc. HTTP può ovviamente funzionare in queste situazioni. MQTT può essere racchiuso in una connessione WebSockets che appare come una richiesta di aggiornamento HTTP, consentendo l'operazione in questi casi. MQTT non consente questo schema.

Rispetto a HTTP, il protocollo MQTT garantisce un'elevata velocità di trasferimento. Esistono tre livelli di qualità del servizio:

A. Al massimo una volta: cerca di garantire la consegna.

B. Almeno una volta: assicurati che l'e-mail venga inviata almeno una volta, ma il messaggio può anche essere consegnato più di una volta.

C. Solo una volta: assicurati che ogni messaggio venga ricevuto solo una volta dall'altra parte.

In effetti, MQTT è ampiamente utilizzato. Puoi trovare MQTT in quasi tutte le grandi aziende hardware e Internet, come Facebook, BP, Alibaba, Baidu, ecc.

A causa dei vari vantaggi tecnici di MQTT stesso, sempre più aziende tendono a scegliere MQTT come protocollo standard per la comunicazione dei prodotti IoT. Pertanto, gli ingegneri hanno gradualmente scoperto che il protocollo MQTT ha alcune funzioni che devono essere migliorate se deve essere commercializzato su larga scala. Ad esempio:

1. Non esiste un SDK completo e diversi terminali eterogenei necessitano dei corrispondenti pacchetti software SDK per comunicare con il server MQTT. Ad esempio, per ottenere l'interconnessione tra MCU, Linux, Android, IOS, WEB, ecc., devono essere richiesti diversi pacchetti SDK.

2. File e AV non sono supportati. In alcuni scenari applicativi, le informazioni da trasmettere potrebbero non essere limitate alle istruzioni, come segnali audio e segnali video, che devono comunicare tramite File e AV.

3. Non supporta l'integrazione con HTTP di terze parti. Sebbeneh il protocollo MQTT è superiore al protocollo HTTP ordinario, i server WEB basati sul protocollo HTTP tradizionale occupano ancora il mercato mainstream, quindi questi server devono realizzare l'interconnessione con il protocollo MQTT per ridurre gli aggiornamenti. Anche i costi sono critici.

4. Non supporta il bilanciamento del carico. Per prevenire un'elevata concorrenza e attacchi dannosi, è essenziale anche un server di bilanciamento del carico.

5. Non supporta l'interfaccia di gestione degli utenti. È particolarmente importante per gli utenti analizzare i dati sul comportamento del dispositivo, che è un requisito inevitabile dell'Industria 4.0 e dell'era dei big data.

6. Non supporta i messaggi offline e compensa il problema che il server MQTT perde le informazioni di controllo del dispositivo dopo che il dispositivo è offline.

7. La comunicazione punto a punto non è supportata e viene adottato il protocollo MQTT standard. In teoria, la comunicazione punto a punto può essere realizzata tramite sottoscrizione reciproca, ma la logica è relativamente complicata e ci sono preoccupazioni sulla sicurezza del dispositivo. Quando il dispositivo B e il dispositivo C sono sullo stesso argomento, il dispositivo A non può sapere se è il dispositivo B o il dispositivo C ad aver inviato il messaggio, ed è anche possibile che il messaggio venga intercettato dal dispositivo D.

8. Non supporta la comunicazione di gruppo e la gestione di gruppo, e realizza la gestione dei membri del gruppo, e i membri del gruppo possono comunicare tra loro. Nello scenario in cui un dispositivo è controllato da più persone, o più dispositivi sono controllati da una persona, particolarmente utile.