HTTP és el protocol més utilitzat i popular. Però MQTT ha guanyat terreny ràpidament durant els últims anys. Quan parlem del desenvolupament d'IoT, els desenvolupadors han de triar entre aquests dos.
MQTT se centra en les dades mentre que HTTP se centra en els documents. HTTP és un protocol de sol·licitud-resposta per a la informàtica client-servidor, que no sempre està optimitzat per a dispositius mòbils. En aquests termes, els principals avantatges de MQTT són: lleuger (MQTT transfereix dades en forma de matrius de bytes) i model de publicació/subscripció, que fa que MQTT sigui molt adequat per a dispositius amb recursos limitats i ajuda a estalviar bateria. A més, el model de publicació/subscripció permet que els clients siguin independents els uns dels altres, augmentant així la fiabilitat del sistema global. En cas d'error del client, tot el sistema continua funcionant amb normalitat.
MQTT encara té molts avantatges, com ara:
1. Baixa sobrecàrrega de protocol, MQTT és únic perquè la seva capçalera per missatge pot ser tan curta com 2 bytes. Tant MQ com HTTP tenen una sobrecàrrega per missatge molt més alta. Amb HTTP, restablir la connexió HTTP per a cada missatge de sol·licitud nou comporta una sobrecàrrega important. Les connexions persistents utilitzades per MQ i MQTT redueixen significativament aquesta sobrecàrrega.
2. Tolerància a xarxes inestables, MQTT i MQ es poden recuperar d'errors com ara la desconnexió, i no hi ha cap requisit de codi addicional. Tanmateix, HTTP no pot fer-ho de manera nativa i requereix que els clients tornin a provar la codificació, cosa que pot afegir problemes d'idempotència.
3. Baix consum d'energia, MQTT està especialment dissenyat per a un baix consum d'energia. HTTP no es va dissenyar per tenir-ho en compte, augmentant així el consum d'energia.
4. Els clients amb milions de connexions, a la pila HTTP, mantenir milions de connexions simultànies requereixen molta fEina per oferir suport. Tot i que aquest suport és possible, la majoria de productes comercials estan optimitzats per gestionar connexions persistents d'aquest ordre de magnitud. IBM ofereix IBM MessageSight, un servidor de muntatge en bastidor únic provat per gestionar fins a 1 milió de dispositius connectats simultàniament mitjançant MQTT. En canvi, MQTT no està dissenyat per a un gran nombre de clients concurrents.
5. Notificacions push, heu de poder enviar notificacions als clients de manera oportuna. Per a això, s'ha de fer servir algun tipus de votació periòdica o empenta; push és la millor solució des del punt de vista de la bateria, la càrrega del sistema i l'ample de banda.
És possible que la nostra empresa hagi d'enviar informació sensible sense l'intermediari d'un tercer. Això redueix el valor de les solucions específiques del sistema operatiu (com ara Apple iOS, notificacions de Google Play) com a mecanisme de transport principal.
HTTP només permet un mètode anomenat COMET, que utilitza sol·licituds HTTP persistents per realitzar pushs. Aquest enfocament és car tant des del punt de vista del client com del servidor. Tant MQ com MQTT admeten push com a característica fonamental d'ells.
6. Les diferències entre les plataformes dels clients, tant els clients HTTP com els MQTT s'han implementat en un gran nombre de plataformes. La senzillesa de MQTT ajuda a implementar MQTT en clients addicionals amb molt poc esforç.
7. Tolerància a errors del tallafoc, alguns tallafocs corporatius restringeixen les connexions de sortida a alguns ports definits. Aquests ports solen estar restringits a HTTP (port 80), HTTPS (port 443), etc. Òbviament, HTTP pot funcionar en aquestes situacions. MQTT es pot embolicar en una connexió WebSockets que apareix com una sol·licitud d'actualització HTTP, permetent el funcionament en aquests casos. MQTT no permet aquest patró.
En comparació amb HTTP, el protocol MQTT garanteix una velocitat de transferència elevada. Hi ha tres nivells de qualitat del servei:
A. Com a màxim una vegada: intenteu garantir el lliurament.
B. Almenys una vegada: assegureu-vos que el correu electrònic s'enviï almenys una vegada, però el missatge també es pot lliurar més d'una vegada.
C. Només una vegada: assegureu-vos que l'altra part només rep cada missatge una vegada.
De fet, MQTT s'utilitza àmpliament. Podeu trobar MQTT a gairebé qualsevol gran empresa de maquinari i Internet, com ara Facebook, BP, alibaba, baidu, etc.
A causa dels diversos avantatges tècnics del mateix MQTT, cada cop més empreses tendeixen a triar MQTT com a protocol estàndard per a la comunicació de productes IoT. Per tant, els enginyers han anat descobrint a poc a poc que el protocol MQTT té algunes funcions que cal millorar si es vol comercialitzar a gran escala. per exemple:
1. No hi ha un SDK complet, i diferents terminals heterogenis necessiten els paquets SDK de programari corresponents per comunicar-se amb el servidor MQTT. Per exemple, per aconseguir la interconnexió entre MCU, Linux, Android, IOS, WEB, etc., s'han de requerir diferents paquets SDK.
2. No s'admeten Fitxers ni AV. En alguns escenaris d'aplicació, és possible que la informació que s'ha de transmetre no es limiti a instruccions, com ara senyals d'àudio i senyals de vídeo, que s'han de comunicar mitjançant File i AV.
3. No admet la integració amb HTTP de tercers. Tot i aixòh el protocol MQTT és superior al protocol HTTP ordinari, els servidors WEB basats en el protocol HTTP tradicional encara ocupen el mercat principal, de manera que aquests servidors han de realitzar la interconnexió amb el protocol MQTT per reduir les actualitzacions. El cost també és crític.
< br/>4. No admet l'equilibri de càrrega. Per evitar atacs de concurrència alta i maliciosos, també és essencial un servidor d'equilibri de càrrega.
5. No admet la interfície de gestió d'usuaris. És especialment important que els usuaris analitzin les dades del comportament del dispositiu, que és un requisit inevitable de la indústria 4.0 i de l'era del big data.
6. No admet missatges fora de línia i compensa el problema que el servidor MQTT perd la informació de control del dispositiu després que el dispositiu estigui fora de línia.
7. La comunicació punt a punt no és compatible i s'adopta el protocol MQTT estàndard. En teoria, la comunicació punt a punt es pot realitzar mitjançant la subscripció mútua, però la lògica és relativament complicada i hi ha preocupacions sobre la seguretat del dispositiu. Quan el dispositiu B i el dispositiu C estan sobre el mateix tema, el dispositiu A no pot saber si és el dispositiu B o el dispositiu C qui ha enviat el missatge, i també és possible que el dispositiu D escolti el missatge.
8. No admet la comunicació i la gestió del grup, i s'adona de la gestió dels membres del grup i els membres del grup poden comunicar-se entre ells. En l'escenari en què un dispositiu està controlat per diverses persones, o diversos dispositius són controlats per una persona, és especialment útil.
Contact: Adam
Phone: +86 18205991243
E-mail: sale1@rfid-life.com
Add: No.987,High-Tech Park,Huli District,Xiamen,China