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 werden mit MQTT Sensordaten wie Temperaturen oder Füllstände übertragen. Aber auch klassische Nachrichten, wie Aktienkurse oder Kurzmitteilungen.
MQTT wurde ursprünglich von IBM und Eurotech konzipiert, um Telemetriedaten zwischen Sensoren und Servern über unzuverlässige Datenverbindungen zu übertragen. Hierfür existieren auch alte Namen wie SCADA, MQIsdp (MQ Integrator SCADA Device Protocol) oder WebSphere MQTT (WMQTT), die heute nicht mehr verwendet werden. 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. Also bei Verbindungen mit hoher Verlust- und Abbruchrate. 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.
MQTT hat mit der Version 5.0 neben den Grundfunktionen eine große Anzahl neuer Funktionen erhalten und ist nicht mehr abwärtskompatibel zu den Vorgängerversionen.
Besonderheiten von MQTT
- MQTT ist ein zustandshaltendes Protokoll. Die Verbindung bleibt in der Regel auch dann bestehen, wenn keine Daten übertragen werden.
- Es ist ein leichtgewichtiges Protokoll bei dem kaum Overhead entsteht.
- Abgebrochene Verbindungen können wieder aufgenommen und fortgesetzt werden.
- Es gibt unterschiedliche QoS-Level mit verschiedenen Zuverlässigkeitsstufen für die Nachrichten-Zustellung.
MQTT-Architektur
Die Funktionsweise und Kommunikation des MQTT-Protokolls entspricht dem Publish-Subscriber-Modell, -Prinzip oder auch der -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 zuständig ist.
Der Broker wird manchmal als Server bezeichnet, weil die Software auf einer typischen Server-Hardware betrieben wird. Publisher und Subscriber sind dann entsprechend die Clients, die beide Rollen zugleich annehmen können. Damit die MQTT-Clients auf ressourcenarmen Geräten laufen können, sind viele MQTT-Funktionen im Broker implementiert. Beispielsweise die Nachrichtenverteilung oder die Möglichkeit, Daten dauerhaft zu speichern.
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 vorgesehen. 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.
Das System, das über die Entscheidungskompetenz zur Steuerung von Geräten verfügt, muss in dieser Architektur ebenfalls mit MQTT als Publisher und Subscriber kommunizieren.
MQTT-Server: Message-Broker
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).
MQTT-Clients: Publisher und Subscriber
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.
Topics: Organisation der Informationen
Es geht um die Frage, wie Publisher und Subscriber mit MQTT zueinander finden? Dazu liegt dem Message-Broker 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 (POSIX) und bilden eine semantische Hierarchie ab. Die Hierarchielevel werden jeweils mit einem Slash („/“) voneinander getrennt.
Aber Achtung: Ein Topic ist keine Adresse von einem Gerät oder eine Gegenstelle und sollte auch nicht so genutzt werden. Vielmehr sollte man Topics als Kommunikationskanäle verstehen, zu denen Publisher Nachrichten beitragen und die von interessierten Subscribern abonniert werden können.
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 lässt.
- 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.
MQTT mit QoS-Level 0
BILD
Eine Nachricht mit dem QoS-Level 0 wird per PUBLISH gesendet. Ob der ankommt ist egal.
Im ersten Moment scheint der QoS-Level 0 unnütz zu sein, weil überhaupt nicht garantiert ist, dass eine Nachricht ankommt. Es gibt aber Anwendungsfälle, wo eine mehrmalige Zustellung oder der Aufwand für eine garantierte Zustellung wenig Sinn macht. Beispielsweise, wenn Nachrichten relativ schnell aufeinander folgen und die Informationen in alten Nachrichten wertlos werden. QoS 0 kann auch dann sinnvoll sein, wenn ein Subscriber überlastet werden kann und sowieso nicht auf alte Nachrichten reagieren soll.
MQTT mit QoS-Level 1
BILD
Eine Nachricht mit dem QoS-Level 1 wird per PUBLISH gesendet. Als Antwort auf einen PUBLISH sendet der Empfänger ein PUBACK (Empfangsbestätigung). Bleibt diese Bestätigung aus, sendet der Sender erneut bis der Empfang bestätigt wurde. Dabei kann es vorkommen, dass eine Nachricht mehrmals ankommt, weil die Bestätigung verloren gegangen ist.
Dieser QoS-Level ist mit Vorsicht zu genießen. Hier muss der Entwickler sicherstellen, dass durch mehrfach eingegangene Nachrichten kein Schaden angerichtet werden kann.
Ein Beispiel ist, wenn der binäre Zustand eines Geräts über eine eingehende Nachricht gewechselt wird. Dann kann das Gerät zum Beispiel durch eine Nachricht eingeschaltet und mit einer doppelten Nachricht unerwünschterweise wieder ausgeschaltet werden.
MQTT mit QoS-Level 2
BILD
Das Senden einer Nachricht ist mit dem QoS-Level 2 viel aufwendiger und dafür zuverlässiger. Hier sorgen beide Gesprächspartner dafür, dass eine Nachricht nur genau einmal beim Gegenüber ankommt. Der Sender sendet ein PUBLISH mit einer ID. Der Empfänger bestätigt den Empfang per PUBREC und speichert die Nachricht erst einmal zwischen. Wenn der Sender die Bestätigung erhalten hat, sendet er ein PUBREL zurück und kann dann die Nachricht bei sich löschen. Danach sendet der Empfänger als letztes ein PUBCOMP an den Sender. Erst dann beginnt der Empfänger, die Nachricht zu verarbeiten.
Der letzte Wille, wenn ein Gerät offline geht
Geht ein Gerät aus unterschiedlichen Gründen unkontrolliert offline, dann kann es sich nicht mehr bei allen verbundenen Endstellen abmelden. Zu diesem Zweck kann ein Client beim Verbindungsaufbau beim Broker einen letzten Willen hinterlegen. Der Broker verteilt diesen an die Subscriber eines Topics, sobald die Verbindung zu dem betreffenden Publisher getrennt wurde.
Übertragung und Sicherheit
MQTT unterscheidet zwischen TCP/IP- und Nicht-TCP/IP-Netzen mit verlustfreien und bidirektionalen Verbindungen.
In TCP/IP-Netzen verwendet MQTT den TCP- und UDP-Port 1883 für unsichere Verbindungen und den Port 8883 für MQTT over TLS. In der Praxis ist es ratsam für Verbindungen über das Internet MQTT over TLS zu verwenden, damit die Verbindungen nicht abgehört oder manipuliert werden können.
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.
Übersicht: MQTT mit Raspberry Pi
- Raspberry Pi: MQTT-Broker Mosquitto installieren und konfigurieren
- Raspberry Pi: MQTT-Dashboard mit Node-RED einrichten
Übersicht: MQTT mit Raspberry Pi Pico
- Raspberry Pi Pico W als MQTT-Publisher
- Raspberry Pi Pico W als MQTT-Subscriber
- Raspberry Pi Pico W als schnurloser Taster (mit MQTT)
- Raspberry Pi Pico W als fernsteuerbarer Schalter (mit MQTT)
- Raspberry Pi Pico W als schnurloses Thermometer (mit MQTT)
Weitere verwandte Themen:
- IoT-Protokolle
- Internet der Dinge / Internet of Things (IoT)
- IoT-Funksysteme
- IoT-Architektur
- HTTP - Hypertext Transfer Protocol
Frag Elektronik-Kompendium.de
Kommunikationstechnik-Fibel
Alles was Sie über Kommunikationstechnik wissen müssen.
Die Kommunikationstechnik-Fibel ist ein Buch über die Grundlagen der Kommunikationstechnik, Übertragungstechnik, Netze, Funktechnik, Mobilfunk, Breitbandtechnik und Voice over IP.
Artikel-Sammlungen zum Thema Kommunikationstechnik
Kommunikationstechnik-Fibel
Alles was Sie über Kommunikationstechnik wissen müssen.
Die Kommunikationstechnik-Fibel ist ein Buch über die Grundlagen der Kommunikationstechnik, Übertragungstechnik, Netze, Funktechnik, Mobilfunk, Breitbandtechnik und Voice over IP.