Welche Vorteile bietet MQTT im Vergleich zum herkömmlichen HTTP-Protokoll?

HTTP ist das am weitesten verbreitete und beliebteste Protokoll. Doch MQTT hat in den letzten Jahren rasant an Boden gewonnen. Bei der Diskussion der IoT-Entwicklung müssen Entwickler zwischen diesen beiden wählen.

MQTT konzentriert sich auf Daten, während HTTP sich auf Dokumente konzentriert. HTTP ist ein Request-Response-Protokoll für Client-Server-Computing, das nicht immer für mobile Geräte optimiert ist. In dieser Hinsicht sind die Hauptvorteile von MQTT: Leichtgewichtigkeit (MQTT überträgt Daten in Form von Byte-Arrays) und Publish/Subscribe-Modell, wodurch MQTT sehr gut für Geräte mit begrenzten Ressourcen geeignet ist und dabei hilft, Batterie zu sparen. Darüber hinaus ermöglicht das Publish/Subscribe-Modell die Unabhängigkeit der Clients voneinander und erhöht so die Zuverlässigkeit des Gesamtsystems. Im Falle eines Clientausfalls funktioniert das gesamte System normal weiter.

Es gibt weiterhin viele Vorteile von MQTT, wie folgt:

1. MQTT zeichnet sich durch einen geringen Protokollaufwand aus und zeichnet sich dadurch aus, dass der Header pro Nachricht nur 2 Byte lang sein kann. Sowohl MQ als auch HTTP haben einen viel höheren Overhead pro Nachricht. Bei HTTP verursacht die Wiederherstellung der HTTP-Verbindung für jede neue Anforderungsnachricht einen erheblichen Mehraufwand. Die von MQ und MQTT verwendeten dauerhaften Verbindungen reduzieren diesen Overhead erheblich.

2. Toleranz gegenüber instabilen Netzwerken, MQTT und MQ können sich nach Fehlern wie Verbindungsabbrüchen erholen, und es sind keine weiteren Codeanforderungen erforderlich. HTTP kann dies jedoch nicht nativ tun, sodass Clients die Kodierung erneut versuchen müssen, was zu Idempotenzproblemen führen kann.

3. Geringer Stromverbrauch, MQTT ist speziell für einen geringen Stromverbrauch konzipiert. HTTP wurde nicht darauf ausgelegt, dies zu berücksichtigen, wodurch der Stromverbrauch steigt.

4. Bei Clients mit Millionen von Verbindungen auf dem HTTP-Stack ist die Aufrechterhaltung von Millionen gleichzeitiger Verbindungen mit einem hohen Arbeitsaufwand verbunden. Obwohl diese Unterstützung möglich ist, sind die meisten kommerziellen Produkte für die Verarbeitung dauerhafter Verbindungen dieser Größenordnung optimiert. IBM bietet IBM MessageSight an, einen Single-Rack-Mount-Server, der für die Verarbeitung von bis zu 1 Million gleichzeitig verbundenen Geräten über MQTT getestet wurde. Im Gegensatz dazu ist MQTT nicht für eine große Anzahl gleichzeitiger Clients konzipiert.

5. Push-Benachrichtigungen: Sie müssen in der Lage sein, Benachrichtigungen zeitnah an Kunden zu übermitteln. Hierzu muss eine Art periodisches Polling oder Push eingesetzt werden; Push ist aus Sicht der Batterie, der Systemauslastung und der Bandbreite die beste Lösung.

Unser Unternehmen muss möglicherweise vertrauliche Informationen ohne die Vermittlung eines Dritten versenden. Dies verringert den Wert betriebssystemspezifischer Lösungen (z. B. Apple iOS, Google Play-Benachrichtigungen) als primären TranSportmechanismus.

HTTP erlaubt nur eine Methode namens COMET, die persistente HTTP-Anfragen zum Durchführen von Pushs verwendet. Dieser Ansatz ist sowohl aus Client- als auch aus Serversicht kostspielig. Sowohl MQ als auch MQTT unterstützen Push als grundlegende Funktion.

6. Unterschiede zwischen Client-Plattformen: Sowohl HTTP- als auch MQTT-Clients wurden auf einer großen Anzahl von Plattformen implementiert. Die Einfachheit von MQTT hilft, MQTT mit sehr geringem Aufwand auf weiteren Clients zu implementieren.

7. Firewall-Fehlertoleranz: Einige Unternehmensfirewalls beschränken ausgehende Verbindungen auf bestimmte definierte Ports. Diese Ports sind normalerweise auf HTTP (Port 80), HTTPS (Port 443) usw. beschränkt. HTTP kann in diesen Situationen offensichtlich funktionieren. MQTT kann in eine WebSockets-Verbindung eingebettet werden, die als HTTP-Upgrade-Anfrage erscheint, was in diesen Fällen den Betrieb ermöglicht. MQTT lässt dieses Muster nicht zu.

Im Vergleich zu HTTP garantiert das MQTT-Protokoll eine hohe Übertragungsrate. Es gibt drei Stufen der Servicequalität:

A. Höchstens einmal: Versuchen Sie, die Lieferung sicherzustellen.

B. Mindestens einmal: Stellen Sie sicher, dass die E-Mail mindestens einmal gesendet wird, die Nachricht kann aber auch mehrmals zugestellt werden.

C. Nur einmal: Stellen Sie sicher, dass jede Nachricht nur einmal von der anderen Partei empfangen wird.

Tatsächlich ist MQTT weit verbreitet. Sie finden MQTT in fast jedem großen Hardware- und Internetunternehmen wie Facebook, BP, Alibaba, Baidu usw.

Aufgrund der verschiedenen technischen Vorteile von MQTT selbst entscheiden sich immer mehr Unternehmen dafür MQTT als Standardprotokoll für die IoT-Produktkommunikation. Daher haben Ingenieure nach und nach herausgefunden, dass das MQTT-Protokoll einige Funktionen aufweist, die verbessert werden müssen, wenn es in großem Maßstab kommerzialisiert werden soll. zum Beispiel:

1. Es gibt kein vollständiges SDK und verschiedene heterogene Terminals benötigen entsprechende Software-SDK-Pakete, um mit dem MQTT-Server zu kommunizieren. Um beispielsweise eine Verbindung zwischen MCU, Linux, Android, IOS, WEB usw. zu erreichen, müssen unterschiedliche SDK-Pakete erforderlich sein.

2. Datei und AV werden nicht unterstützt. In einigen Anwendungsszenarien sind die zu übertragenden Informationen möglicherweise nicht auf Anweisungen wie Audiosignale und Videosignale beschränkt, die über Datei und AV kommunizieren müssen.

3. Die Integration mit HTTP von Drittanbietern wird nicht unterstützt. ObwohlDa das MQTT-Protokoll dem gewöhnlichen HTTP-Protokoll überlegen ist, besetzen WEB-Server, die auf dem traditionellen HTTP-Protokoll basieren, immer noch den Mainstream-Markt, daher müssen diese Server die Verbindung mit dem MQTT-Protokoll realisieren, um Upgrades zu reduzieren. Auch die Kosten sind von entscheidender Bedeutung.
< br/>4. Es unterstützt keinen Lastausgleich. Um hohe Parallelität und böswillige Angriffe zu verhindern, ist auch ein Lastausgleichsserver unerlässlich.

5. Die Benutzerverwaltungsschnittstelle wird nicht unterstützt. Für Benutzer ist es besonders wichtig, Geräteverhaltensdaten zu analysieren, was eine unvermeidliche Anforderung von Industrie 4.0 und dem Zeitalter von Big Data ist.

6. Es unterstützt keine Offline-Nachrichten und gleicht das Problem aus, dass der MQTT-Server die Steuerinformationen des Geräts verliert, nachdem das Gerät offline ist.

7. Punkt-zu-Punkt-Kommunikation wird nicht unterstützt und das Standard-MQTT-Protokoll wird übernommen. Theoretisch kann eine Punkt-zu-Punkt-Kommunikation durch gegenseitiges Abonnement realisiert werden, die Logik ist jedoch relativ kompliziert und es bestehen Bedenken hinsichtlich der Sicherheit des Geräts. Wenn sich Gerät B und Gerät C im selben Thema befinden, kann Gerät A nicht wissen, ob es Gerät B oder Gerät C ist, das die Nachricht gesendet hat, und es ist auch möglich, dass die Nachricht von Gerät D abgehört wird.

8. Es unterstützt keine Gruppenkommunikation und Gruppenverwaltung und realisiert die Verwaltung von Gruppenmitgliedern, und Gruppenmitglieder können miteinander kommunizieren. In dem Szenario, in dem ein Gerät von mehreren Personen gesteuert wird oder mehrere Geräte von einer Person gesteuert werden, ist dies besonders nützlich.