Hvad er fordelene ved MQTT sammenlignet med den traditionelle HTTP-protokol

HTTP er den mest udbredte og populære protokol. Men MQTT har hurtigt vundet indpas i løbet af de sidste par år. Når man diskuterer IoT-udvikling, skal udviklere vælge mellem disse to.

MQTT fokuserer på data, mens HTTP fokuserer på dokumenter. HTTP er en anmodning-svar-protokol til klient-server-beregning, som ikke altid er optimeret til mobile enheder. I disse termer er de vigtigste fordele ved MQTT: letvægts (MQTT overfører data i form af byte-arrays) og publish/subscribe model, hvilket gør MQTT meget velegnet til enheder med begrænsede ressourcer og hjælper med at spare batteri. Derudover gør public/subscribe-modellen kunderne i stand til at være uafhængige af hinanden, og derved øger pålideligheden af det samlede system. I tilfælde af en klientfejl fortsætter hele systemet med at fungere normalt.

Der er stadig mange fordele ved MQTT, som følger:

1. Lav protokoloverhead, MQTT er unik ved, at dens header pr. besked kan være så kort som 2 bytes. Både MQ og HTTP har en meget højere overhead pr. besked. Med HTTP vil genetablering af HTTP-forbindelsen for hver ny anmodningsmeddelelse medføre betydelige omkostninger. De vedvarende forbindelser, der bruges af MQ og MQTT, reducerer denne overhead betydeligt.

2. Tolerance over for ustabile netværk, MQTT og MQ kan komme sig efter fejl som f.eks. afbrydelse, og der er ingen yderligere kodekrav. HTTP kan dog ikke gøre dette indbygget, hvilket kræver, at klienter prøver kodningen igen, hvilket kan øge problemer med idempotens.

3. Lavt strømforbrug, MQTT er specielt designet til lavt strømforbrug. HTTP er ikke designet til at tage højde for dette, hvilket øger strømforbruget.

4. Klienter med millioner af forbindelser, på HTTP-stakken, kræver en masse arbejde at yde support. Selvom denne support er mulig, er de fleste kommercielle produkter optimeret til at håndtere vedvarende forbindelser af denne størrelsesorden. IBM tilbyder IBM MessageSight, en enkelt rackmonteret server, der er testet til at håndtere op til 1 million samtidigt tilsluttede enheder over MQTT. I modsætning hertil er MQTT ikke designet til et stort antal samtidige klienter.

5. Push-meddelelser, du skal være i stand til at levere meddelelser til kunderne rettidigt. Til dette skal der anvendes en form for periodisk afstemning eller push; push er den bedste løsning set ud fra et batteri-, systembelastnings- og båndbreddeperspektiv.

Vores virksomhed skal muligvis sende følsomme oplysninger uden mellemled fra en tredjepart. Dette reducerer værdien af OS-specifikke løsninger (såsom Apple iOS, Google Play-meddelelser) som den primære transportmekanisme.

HTTP tillader kun én metode kaldet COMET, der bruger vedvarende HTTP-anmodninger til at udføre push. Denne tilgang er dyr fra både klient- og serverperspektiv. Både MQ og MQTT understøtter push som et grundlæggende træk ved dem.

6. Klientplatformsforskelle, både HTTP- og MQTT-klienter er blevet implementeret på et stort antal platforme. Enkelheden af MQTT hjælper med at implementere MQTT på yderligere klienter med meget lidt indsats.

7. Firewall-fejltolerance, nogle virksomhedsfirewalls begrænser udgående forbindelser til nogle definerede porte. Disse porte er normalt begrænset til HTTP (port 80), HTTPS (port 443) osv. HTTP kan naturligvis fungere i disse situationer. MQTT kan pakkes ind i en WebSockets-forbindelse, der vises som en HTTP-opgraderingsanmodning, hvilket tillader drift i disse tilfælde. MQTT tillader ikke dette mønster.

Sammenlignet med HTTP garanterer MQTT-protokollen en høj overførselshastighed. Der er tre niveauer af servicekvalitet:

A. Højst én gang: Prøv at sikre levering.

B. Mindst én gang: Sørg for, at mailen sendes mindst én gang, men beskeden kan også leveres mere end én gang.

C. Bare én gang: Sørg for, at hver besked kun modtages én gang af den anden part.

MQTT er faktisk meget brugt. Du kan finde MQTT i næsten alle Store hardware- og internetvirksomheder, såsom Facebook, BP, alibaba, baidu osv.

På grund af de forskellige tekniske fordele ved selve MQTT, har flere og flere virksomheder en tendens til at vælge MQTT som standardprotokol for IoT-produktkommunikation. Derfor har ingeniører efterhånden opdaget, at MQTT-protokollen har nogle funktioner, der skal forbedres, hvis den skal kommercialiseres i stor skala. for eksempel:

1. Der er ingen komplet SDK, og forskellige heterogene terminaler har brug for tilsvarende software SDK-pakker for at kommunikere med MQTT-serveren. For at opnå sammenkobling mellem MCU, Linux, Android, IOS, WEB osv. skal der kræves forskellige SDK-pakker.

2. Fil og AV understøttes ikke. I nogle applikationsscenarier er informationen, der skal transmitteres, muligvis ikke begrænset til instruktioner, såsom lydsignaler og videosignaler, som skal kommunikere gennem Fil og AV.

3. Det understøtter ikke integration med tredjeparts HTTP. Selvomh MQTT-protokollen er overlegen i forhold til den almindelige HTTP-protokol, WEB-servere baseret på den traditionelle HTTP-protokol optager stadig det almindelige marked, så disse servere skal realisere sammenkoblingen med MQTT-protokollen for at reducere opgraderinger. Omkostningerne er også kritiske.
< br/>4. Den understøtter ikke belastningsbalancering. For at forhindre høj samtidighed og ondsindede angreb er en belastningsbalanceringsserver også vigtig.

5. Det understøtter ikke brugergrænsefladen. Det er især vigtigt for brugere at analysere data om enhedens adfærd, hvilket er et uundgåeligt krav i Industry 4.0 og big data-æraen.

6. Den understøtter ikke offline-meddelelser og kompenserer for problemet med, at MQTT-serveren mister kontroloplysningerne for enheden, efter at enheden er offline.

7. Punkt-til-punkt kommunikation understøttes ikke, og standard MQTT-protokollen er overtaget. I teorien kan punkt-til-punkt-kommunikation realiseres gennem gensidigt abonnement, men logikken er relativt kompliceret, og der er bekymringer omkring enhedens sikkerhed. Når enhed B og enhed C er om samme emne, kan enhed A ikke vide, om det er enhed B eller enhed C, der har sendt beskeden, og det er også muligt, at beskeden aflyttes af enhed D.

8. Det understøtter ikke gruppekommunikation og gruppeledelse, og realiserer ledelsen af gruppemedlemmer, og gruppemedlemmer kan kommunikere med hinanden. I det scenarie, hvor én enhed styres af flere personer, eller flere enheder styres af én person, er det særligt nyttigt.