Erste Einführung in MQTT
Das Internet der Dinge ist, wie der Name schon sagt, ein Internet, in dem Dinge miteinander verbunden sind. Es kann Objekte über das Internet vernetzen, sodass diese Objekte miteinander interagieren können. MQTT ist ein TCP/IP-basiertes Protokoll für die Datenkommunikation zwischen diesen Objekten.
Jedes Endgerät ist mit einem Proxy/Server verbunden, der das MQTT-Protokoll implementiert.
Daten über ein Thema auf einem veröffentlichten MQTT-Proxy-Server senden.
Rufen Sie die Daten zu den Themen, die Sie abonniert haben, über das Abonnement vom MQTT-Proxy-Server ab.
Der Proxy-Server selbst erzeugt keine Daten; alle Daten werden von dem mit dem Proxy-Server verbundenen Endgerät erzeugt.
Das Endgerät sendet Daten an den Server. Das Endgerät, das das Thema auf dem Server abonniert hat, empfängt die von einem anderen Endgerät an den Server gesendeten Daten und leitet sie über den Server an sich selbst weiter.
Warum sollte man sich für das MQTT-Protokoll entscheiden?
Das MQTT-Protokoll ist ein schlankes und flexibles Netzwerkprotokoll. Es eignet sich sehr gut für IoT-Anwendungen.
Zunächst einmal ist das IoT-Protokoll sehr kompakt und nicht so ressourcenintensiv wie HTTP und HTTPS.
Im Allgemeinen sind die Netzwerkübertragungsbedingungen und die Rechenleistung von Geräten, die das Internet der Dinge (IoT) unterstützen, relativ gering, weshalb sie sich für MQTT eignen, ein schlankes Protokoll, das keine hohen Anforderungen an Netzwerk und Daten stellt.
Warum ist MQTT also so schlank und flexibel? Ein wesentliches Merkmal des MQTT-Protokolls ist das Publish/Subscribe-Modell. Es trennt den Absender und den Empfänger von Daten voneinander.
Ein Endgerät kann entweder als Datenanbieter oder als Datenabnehmer fungieren.
Wenn ein Gerät Daten veröffentlichen möchte, muss es lediglich den Dateninhalt im entsprechenden Thema auf dem Proxy-Server veröffentlichen.
Wenn ein Gerät Daten empfangen soll, muss es lediglich im Proxy-Server im Voraus die Themen abonnieren, auf die es achten muss.
Warum nicht ein anderes Netzwerkprotokoll wählen?
Die meisten Entwickler sind bereits mit dem HTTP-Webprotokoll vertraut. Warum also nicht die IoT-Konfiguration mit dem Webdienst verknüpfen?
Das Gerät kann Daten in Form von HTTP-Anfragen senden und Daten vom Server in Form von HTTP-Antworten abrufen, um Aktualisierungen zu übernehmen.
Denn bei IoT-Geräten weist dieses Datenübertragungsmodell – aktive Anfrage → passives Warten auf die Antwort – erhebliche Einschränkungen auf:
HTTP ist ein synchrones Protokoll. Der Client muss auf die Antwort des Servers warten. Webbrowser stellen diese Anforderung, was jedoch auf Kosten der Skalierbarkeit geht. In der Welt des IoT stellen die große Anzahl an Geräten und potenziell unzuverlässige oder durch hohe Latenzzeiten gekennzeichnete Netzwerke die synchrone Kommunikation vor ein Problem. Asynchrone Nachrichtenprotokolle eignen sich besser für IoT-Anwendungen. Der Sensor sendet einfach die Daten und überlässt es dem Netzwerk, den besten Weg und den besten Zeitpunkt für die Übermittlung an das Zielgerät und den Server zu bestimmen.
HTTP ist ein Einweg-Protokoll. Der Client muss die Anfrage aktiv auslösen. In IoT-Anwendungen fungiert das Gerät oder der Sensor in der Regel als Client, was bedeutet, dass es bzw. er keine Daten vom Server empfangen kann, es sei denn, der Benutzer oder die Anwendung fordert diese aktiv an.
HTTP ist ein 1:1-Protokoll. Der Client sendet eine Anfrage, und der Server antwortet. Es besteht eine Eins-zu-Eins-Beziehung. Es ist jedoch notwendig, die 1:1-Beziehung von HTTP auf die im IoT sehr verbreitete Eins-zu-Viele-Beziehung umzustellen. Die Umsetzung ist schwierig, und auch die Kosten sind hoch. Und die „Eins-zu-Viele“-Beziehung ist im IoT sehr verbreitet.
Im Vergleich zu MQTT ist HTTP ein relativ ressourcenintensives Protokoll. Es eignet sich nicht für die begrenzten Netzwerkressourcen und die geringe Rechenleistung von IoT-Endgeräten.
