Wat zijn de voordelen van MQTT ten opzichte van het traditionele HTTP-protocol?

HTTP is het meest gebruikte en populaire protocol. Maar MQTT heeft de afgelopen jaren snel terrein gewonnen. Bij het bespreken van IoT-ontwikkeling moeten ontwikkelaars kiezen tussen deze twee.

MQTT richt zich op gegevens, terwijl HTTP zich richt op documenten. HTTP is een request-response-protocol voor client-server computing, dat niet altijd is geoptimaliseerd voor mobiele apparaten. In deze termen zijn de belangrijkste voordelen van MQTT: lichtgewicht (MQTT draagt gegevens over in de vorm van byte-arrays) en publish/subscribe-model, wat MQTT zeer geschikt maakt voor apparaten met beperkte bronnen en helpt de batterij te sparen. Bovendien stelt het publish/subscribe-model clients in staat om onafhankelijk van elkaar te zijn, waardoor de betrouwbaarheid van het algehele systeem wordt vergroot. In het geval van een clientstoring blijft het hele systeem normaal functioneren.

Er zijn nog steeds veel voordelen van MQTT, zoals volgt:

1. Lage protocoloverhead, MQTT is uniek omdat de header per bericht zo kort kan zijn als 2 bytes. Zowel MQ als HTTP hebben een veel hogere overhead per bericht. Met HTTP brengt het opnieuw tot stand brengen van de HTTP-verbinding voor elk nieuw verzoekbericht aanzienlijke overhead met zich mee. De persistente verbindingen die door MQ en MQTT worden gebruikt, verminderen deze overhead aanzienlijk.

2. Tolerantie voor onstabiele netwerken, MQTT en MQ kunnen herstellen van fouten zoals ontkoppeling en er zijn geen verdere codevereisten. HTTP kan dit echter niet native doen, waardoor clients de codering opnieuw moeten proberen, wat kan bijdragen aan idempotentieproblemen.

3. Laag stroomverbruik, MQTT is speciaal ontworpen voor laag stroomverbruik. HTTP is niet ontworpen om hier rekening mee te houden, waardoor het stroomverbruik toeneemt.

4. Clients met miljoenen verbindingen op de HTTP-stack, die miljoenen gelijktijdige verbindingen onderhouden, vereisen veel werk om ondersteuning te bieden. Hoewel deze ondersteuning mogelijk is, zijn de meeste commerciële producten geoptimaliseerd om persistente verbindingen van deze orde van grootte te verwerken. IBM biedt IBM MessageSight, een enkele rackmount-server die is getest om tot 1 miljoen gelijktijdig verbonden apparaten via MQTT te verwerken. Daarentegen is MQTT niet ontworpen voor een groot aantal gelijktijdige clients.

5. Pushmeldingen, u moet tijdig meldingen aan klanten kunnen leveren. Hiervoor moet een soort periodieke polling of push worden gebruikt; push is de beste oplossing vanuit het perspectief van batterij, systeembelasting en bandbreedte.

Ons bedrijf moet mogelijk gevoelige informatie verzenden zonder tussenkomst van een derde partij. Dit vermindert de waarde van OS-specifieke oplossingen (zoals Apple iOS, Google Play-meldingen) als primair tranSportmechanisme.

HTTP staat slechts één methode toe, COMET genaamd, waarbij persistente HTTP-verzoeken worden gebruikt om pushes uit te voeren. Deze aanpak is duur vanuit zowel het client- als het serverperspectief. Zowel MQ als MQTT ondersteunen push als een fundamenteel kenmerk ervan.

6. Verschillen tussen clientplatforms, zowel HTTP- als MQTT-clients zijn op een groot aantal platforms geïmplementeerd. De eenvoud van MQTT helpt om MQTT met weinig moeite op extra clients te implementeren.

7. Firewall-fouttolerantie, sommige bedrijfsfirewalls beperken uitgaande verbindingen tot bepaalde gedefinieerde poorten. Deze poorten zijn meestal beperkt tot HTTP (poort 80), HTTPS (poort 443), enz. HTTP kan in deze situaties uiteraard werken. MQTT kan worden verpakt in een WebSockets-verbinding die verschijnt als een HTTP-upgradeverzoek, waardoor de werking in deze gevallen mogelijk is. MQTT staat dit patroon niet toe.

Vergeleken met HTTP garandeert het MQTT-protocol een hoge overdrachtssnelheid. Er zijn drie niveaus van servicekwaliteit:

A. Maximaal één keer: probeer de levering te garanderen.

B. Minstens één keer: zorg ervoor dat de e-mail minstens één keer wordt verzonden, maar het bericht kan ook meer dan één keer worden afgeleverd.

C. Slechts één keer: zorg ervoor dat elk bericht slechts één keer door de andere partij wordt ontvangen.

In feite wordt MQTT veel gebruikt. U kunt MQTT vinden in bijna elk groot hardware- en internetbedrijf, zoals Facebook, BP, Alibaba, Baidu, enz.

Vanwege de verschillende technische voordelen van MQTT zelf, kiezen steeds meer bedrijven MQTT als het standaardprotocol voor IoT-productcommunicatie. Daarom hebben ingenieurs geleidelijk ontdekt dat het MQTT-protocol enkele functies heeft die verbeterd moeten worden als het op grote schaal gecommercialiseerd moet worden. bijvoorbeeld:

1. Er is geen complete SDK en verschillende heterogene terminals hebben overeenkomstige software SDK-pakketten nodig om te communiceren met de MQTT-server. Om bijvoorbeeld onderlinge verbinding tussen MCU, Linux, Android, IOS, WEB, enz. te bereiken, zijn verschillende SDK-pakketten vereist.

2. Bestand en AV worden niet ondersteund. In sommige toepassingsscenario's is de te verzenden informatie mogelijk niet beperkt tot instructies, zoals audiosignalen en videosignalen, die via Bestand en AV moeten communiceren.

3. Het ondersteunt de integratie met HTTP van derden niet. Hoewelh het MQTT-protocol superieur is aan het gewone HTTP-protocol, WEB-servers gebaseerd op het traditionele HTTP-protocol bezetten nog steeds de mainstream markt, dus deze servers moeten de onderlinge verbinding met het MQTT-protocol realiseren om upgrades te verminderen. Kosten zijn ook kritisch.

4. Het ondersteunt geen load balancing. Om hoge gelijktijdigheid en kwaadaardige aanvallen te voorkomen, is een load balancing-server ook essentieel.

5. Het ondersteunt de gebruikersbeheerinterface niet. Het is met name belangrijk voor gebruikers om apparaatgedragsgegevens te analyseren, wat een onvermijdelijke vereiste is van Industrie 4.0 en het tijdperk van big data.

6. Het ondersteunt geen offline berichten en compenseert het probleem dat de MQTT-server de besturingsinformatie van het apparaat verliest nadat het apparaat offline is.

7. Point-to-point-communicatie wordt niet ondersteund en het standaard MQTT-protocol wordt gebruikt. In theorie kan point-to-point-communicatie worden gerealiseerd via wederzijds abonnement, maar de logica is relatief ingewikkeld en er zijn zorgen over de beveiliging van het apparaat. Wanneer apparaat B en apparaat C hetzelfde onderwerp hebben, kan apparaat A niet weten of het apparaat B of apparaat C is dat het bericht heeft verzonden, en het is ook mogelijk dat het bericht wordt afgeluisterd door apparaat D.

8. Het ondersteunt geen groepscommunicatie en groepsbeheer, en realiseert het beheer van groepsleden, en groepsleden kunnen met elkaar communiceren. In het scenario waarin één apparaat door meerdere mensen wordt bestuurd, of meerdere apparaten door één persoon worden bestuurd, is dit vooral handig.