WORK THE DATA @ WHAT THE DATA Teil 2: Warum MQTT?

WORK THE DATA @ WHAT THE DATA Teil 2: Warum MQTT?

Daten sind zum Spielen da! Wir haben euch für den WHAT THE DATA!? Hackathon wie immer eine bunte Spielwiese vorbereitet. Damit ihr eure wertvolle Zeit am Wochenende nicht mit den Grundlagen verschwenden müsst, machen wir es euch so leicht wie möglich, an Daten zu kommen. Einen vollständigen Datenkatalog veröffentlichen wir in den nächsten Tagen. In einer kleinen Blog-Post Serie erklären wir euch die einfachsten Tools zum Durchstarten.

Im letzten Teil haben wir euch einen kleinen Warm-Up gegeben. Heute erklären wir euch, warum wir dem MQTT Protokoll den Vorzug geben.

Warum wir MQTT gegenüber REST bevorzugen

Wer in sich in den letzten Jahren mit Software-Entwicklung vor allem rund um Webservices beschäftigt hat, kennt den Begriff REST API in der Regel sehr gut. REST bezeichnet eine HTTP Schnittstelle, die Funktionen für das Anlegen, Auslesen, Verändern und Löschen von Datensätzen anbietet (CREATE, READ, UPDATE, DELETE -> CRUD). Das HTTP Protokoll ist ein so genanntes Request/Response Protokoll, das heißt, um mit der Schnittstelle zu interagieren, sendet ein Client stets eine Anfrage (Request) an einen Server und erhält dann eine Antwort (Response), die Status Codes, die eigentlichen Daten (Payload oder Body) und einige Metadaten enthält.

In IoT-Systemen wollen Anwendungen (Clients) oft kontinuierlich Messwerte, die in einem festen Interval von Datenquellen (z.B. Sensoren) aufgenommen werden, erhalten und verarbeiten. Mit einer reinen REST API würde der Sensor seine Daten per HTTP POST an einen Server schicken, jeder Client kann per GET den letzten Wert abholen (Polling). Daraus entstehen allerdings eine Handvoll Nachteile:

  • die Anfragen sind meist redundant, da kontinuierlich immer wieder die gleiche Anfrage gestellt wird. Das verursacht unnötigen Datenverkehr
  • das Timing der Anfragen ist schwer zu treffen. Um keinen Wert zu verpassen muss das Polling-Intervall höher gewählt werden, als das Publish-Interval des Sensors
Abbildung 1: IoT Live-Daten mit HTTP Request/Response. Client A fragt in zu hohem Interval
und erhält doppelte Werte, Client B in zu niedrigem und verpasst Werte

 

MQTT ist ein so genanntes Publish/Subscribe Protokoll und ist für Fälle konzipiert worden, in denen über längere Zeiträume immer gleiche Datenpunkte von Datenquellen erzeugt und an andere Clients verteilt werden müssen. Dafür bauen alle Clients eine dauerhaft bestehende Netzwerk-Verbindung zum so genannten MQTT-Broker auf. Eine Authentifizierung mit Benutzername und Passwort bzw. Zertifikaten ist nur einmalig erforderlich. Auf dieser bestehenden Netzwerk-Verbindung können Datenquellen unter so genannten Topics senden (Publish). Andere Clients können Topics abbonnieren (Subscribe) und erhalten fortan sämtliche Daten unmittelbar per Push. Das ist elegant und effizient.

 

Abbildung 2: IoT Live-Daten mit MQTT Pub/Sub. Alle Clients erhalten jeden neuen Wert unmittelbar per Push.

Aber: Websockets?

Ein beliebter Irrtum ist, dass Websockets eine Alternative zu MQTT sind. Websockets ermöglicht es, Streaming-Protokolle durch HTTP zu tunneln. Dieser Datenkanal kann aber zunächst nichts anderes, als eine normale TCP Verbindung und stellt damit im OSI Modell nur den Transport-Layer zur Verfügung! Auf diesem Transport-Layer können dann wieder beliebige Application-Layer Protokolle angewendet werden, auch z.B. MQTT.

Der Hauptgrund für die Existenz von Websockets ist, dass aus einem Web-Browser heraus der Javascript Code aus Sicherheitsgründen keine direkten Netzwerk-Socket Verbindungen aufbauen kann, vielmehr kann er ausschließlich HTTP Anfragen an Web-Server stellen. Nur wenn dieser Web-Server auch Websockets unterstützt und seinerseits einen solchen Tunnel zur Verfügung stellt, kann diese Technologie genutzt werden.

Die meisten MQTT Broker haben einen eingebauten Webserver, der Websocket Verbindungen entgegen nehmen kann. Daher ist eine direkte MQTT Kommunikation aus einer Website heraus sehr einfach möglich!

Ein anderer Anwendungsfall für MQTT over Websockets sind übrigens restriktive Firewalls, die nur HTTP/HTTPS Traffic erlauben.

Zusammengefasst: Websockets sind keine Alternative zu MQTT, aber in manchen Fällen muss man MQTT over Websockets betreiben.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.