MQTT - Message Queue Telemetry Transport

Message Queue Telemetry Transport, kurz MQTT, ist ein äußerst einfach aufgebautes binäres Publish-Subscribe-Protokoll. Es eignet sich für den Nachrichtenaustausch zwischen Geräten mit geringer Funktionalität und für die Übertragung über unzuverlässige Netze mit geringer Bandbreite und hoher Latenz. Mit diesen Eigenschaften spielt MQTT eine wichtige Rolle für das Internet der Dinge (IoT) und in der M2M-Kommunikation.

Typischerweise lassen sich mit MQTT Sensordaten, wie Temperatur oder Füllstände, übertragen. Aber auch klassische Nachrichten, wie Aktienkurse oder Kurzmitteilungen. Facebook nutzt MQTT für seine Mobile-Apps.

MQTT wurde ursprünglich von IBM und Eurotech um die Jahrtausendwende konzipiert, um Telemetriedaten zwischen Sensoren und Servern über unzuverlässige Datenverbindungen zu übertragen. Alte Namen wie SCADA, MQIsdp (MQ Integrator SCADA Device Protocol) oder WebSphere MQTT (WMQTT) sind heute nicht mehr in Gebrauch. Seit 2013 wird die Standardisierung des MQTT-Protokolls von der OASIS (Organization for the Advancement of Structured Information Standards) weitergeführt.

MQTT kann besonders bei der Nachrichtenübertragung in unzuverlässigen Netzwerken seine Stärken entfalten. Auf Protokollebene existiert eine Funktion zum Wiederverbinden und erneutes Ausliefern von Nachrichten. Somit wird bei der Datenübermittlung eine hohe Zuverlässigkeit erreicht.
Der Bedarf an Netzwerk-Bandbreite ist beim MQTT-Protokoll minimal und gleichzeitig stellt es nur geringe Anforderungen an die Geräte. Somit braucht es vergleichsweise wenig Energie, was wichtig ist, wenn die Energieversorgung über eine Batterie erfolgt.

Zusammenfassung

  • Leichtgewichtiges Protokoll bei dem kaum Overhead entsteht.
  • Abgebrochene Verbindungen können wieder aufgenommen und fortgesetzt werden.
  • Unterschiedliche QoS-Level mit verschiedenen Zuverlässigkeitsstufen für die Nachrichten-Zustellung.

Somit eignet sich MQTT für den Einsatz in instabilen Netzwerken und für den Einsatz in der M2M-Kommunikation und im Internet der Dinge.

  • Internet der Dinge
  • M2M-Kommunikation

MQTT-Architektur

MQTT-Architektur

Die Struktur bzw. der Aufbau in dem das MQTT-Protokoll arbeitet entspricht dem Publish-Subscriber-Modell, -Prinzip oder auch -Architektur.
Das Publish-Subscriber-Modell besteht aus einer Datenquelle, die als Publisher bezeichnet wird, und einer Datensenke, die als Subscriber bezeichnet wird. Dazwischen befindet sich ein Message-Broker, der für die Kommunikationssteuerung sorgt.

Diese Konstruktion hat den Vorteil, dass Sender und Empfänger einer Nachricht voneinander entkoppelt und unabhängig sind. Eine direkte Kommunikation zwischen Sender und Empfänger ist nicht möglich. Die Idee dabei ist, dass der Broker eine Nachricht an alle weiterleitet, die eine Nachricht von einer bestimmten Quelle bekommen wollen.

Geht ein Empfänger offline oder die Verbindung bricht ab, dann speichert der Broker alle Nachrichten für diesen Empfänger und stellt sie dann zu, sobald die Verbindung wieder hergestellt ist.

Message-Broker (MQTT-Server)

Der Message-Broker ist ein zentraler Server, der Nachrichten von einem oder mehreren Publishern entgegennimmt und an einen oder mehrere Subscriber weiterleitet. Jeder Broker kann dabei die Gegenstelle von tausenden oder gar hunderttausenden Publishern sein und Daten übermitteln bzw. entgegennehmen.
Für den Betrieb eines Brokers stehen zahlreiche Produkte zur Auswahl. Die verfügbaren Produkte unterscheiden sich dabei teilweise deutlich in der Unterstützung der Protokollfähigkeiten (verschiedene MQTT-Versionen).

Publisher und Subscriber (Sensoren und Aktoren)

Typischerweise wäre ein Publisher ein Sensor, der etwas detektiert und das an einen Subscriber, also Aktor, zum Schalten übermitteln soll. Der Publisher sendet seine Nachricht aber nicht an den Subscriber direkt, sondern an den Message-Broker.
Der Publisher muss aber kein Sensor sein. Es kann sich dabei auch um eine Schaltfläche handeln, die in einem Webbrowser dargestellt wird. Das ist nichts anderes als ein Sensor, der von einem Anwender ausgelöst wird. Das heißt, das Rollenverständnis von Publisher und Subscriber muss man etwas weiter fassen.
Der Subscriber könnte ein Aktor sein, der Aufgrund einer Nachricht von einem Publisher und dem darin enthaltenen Wert etwas auslöst oder schaltet. Damit der Subscriber die Nachrichten von einem Publisher erhält, muss er diese bei einem Message-Broker abonnieren.

Wie finden Publisher und Subscriber mit MQTT zueinander?

Dem Message-Broker liegt eine Liste mit Subscribern vor, die eine bestimmte Nachricht bekommen sollen. Diese Nachrichten sind in sogenannten Topics organisiert, die von den Subscribern abonniert werden. Dem Absender einer Nachricht (Publisher) obliegt die Aufgabe, Inhalt und Topic beim Versand der Nachricht festzulegen. Der Broker kümmert sich dann darum, dass die Subscriber die Nachrichten von den abonnierten Topics bekommen.

Die Topics folgen einem definierten Schema. Sie ähneln einem Verzeichnispfad und bilden eine semantische Hierarchie ab.

QoS - Quality of Service

MQTT verfügt über unterschiedliche QoS-Level mit verschiedenen Zuverlässigkeitsstufen für die Zustellung. Hierzu definiert MQTT drei Stufen der Verlässlichkeit, die sich für jede Nachricht individuell einstellen lassen.

  • QoS-Level 0: "at most once, unreliable oder fire and forget": Das bedeutet, dass MQTT die Zustellung nicht garantiert. Praktisch gar keine Zuverlässigkeit.
  • QoS-Level 1: "at least once": Das bedeutet, die Nachricht kommt garantiert mindestens einmal oder auch mehrfach beim Broker an.
  • QoS-Level 2: "exactly once": Das bedeutet, die Nachricht kommt garantiert nur einmal beim Broker an.

Der QoS-Level 2 ist die verlässlichste Variante. Allerdings ist das in Bezug auf Performance und Netzlast mit Abstand die aufwendigste, langsamste und teuerste Variante. Für batteriebetriebene Geräte bedeutet das eine höhere CPU-Belastung und damit eben auch eine niedrigere Batterie-Laufzeit.

Wie sicher ist MQTT?

Grundsätzlich ist die Kommunikation über MQTT genauso unsicher wie beispielsweise bei HTTP. Publisher und Subscriber kommunizieren über MQTT mit dem Broker ohne Verschlüsselung und Authentifizierung. Ein Angreifer kann nicht nur mitlesen, sondern auch die Daten manipulieren.

Das Problem dabei ist aber nicht, dass MQTT unsicher ist, sondern die MQTT-Broker von ihren Betreibern nicht ordentlich konfiguriert und öffentlich im Internet erreichbar sind. Das bedeutet, dass jeder ohne Benutzername und Passwort an den Broker Nachrichten schicken und von ihm empfangen kann. Die Betreiber verzichten also auf Authentifizierung, was in gewisser Weise nur mit Unwissenheit oder Bequemlichkeit der Betrieber zu erklären ist.

Zu finden sind die MQTT-Broker über die Suchmaschine für das Internet der Dinge "Shodan.io" oder mit dem NMAP-Scanner (Port 1883/tcp oder 8883/tcp). Hier lassen sich unter Umständen Publisher finden, die sich in kritischen Infrastrukturen befinden und ungeschützt über das Netz kommunizieren. Um sich mit einem der öffentlichen MQTT-Broker zu verbinden, genügt ein eigener Client wie MQTT.fx, der per Hashtag (#) alle vom Broker organisierten Topics abonniert.

Das Problem dabei ist nicht, dass sich die Nachrichten lesen lassen, sondern, dass Message-Broker beliebige Nachrichten von Publishern entgegennehmen und an beliebige Subscriber weiterleiten. Auf diese Weisen lassen sich Subscriber durch falsche Nachrichten manipulieren. Das heißt, ein Angreifer schickt als Publisher eine Nachricht mit Topic und Inhalt an den Broker, der diese Nachricht ungeprüft an die Subscriber weiterleitet.

Abhilfe schafft nur die Kommunikation mit SSL/TLS zu verschlüsseln und die Authentifizierung von Publishern und Subscribern mit Benutzername und Passwort. Außerdem sollten die Broker nicht frei zugänglich sein. Ein zusätzlicher Schutz kann sein, nur Verbindungen von bestimmten Publishern zuzulassen.

Weitere verwandte Themen:

Teilen:

Netzwerktechnik-Fibel

Netzwerktechnik-Fibel

Das will ich haben!