Was ist MQTT: das Protokoll, seine Versionen und wo es eingesetzt wird

# Die Kurzfassung

MQTT (Message Queuing Telemetry Transport) ist ein leichtgewichtiges Nachrichtenprotokoll nach dem Publish-and-Subscribe-Prinzip, gebaut für Geräte mit schlechter Verbindung, wenig Speicher und einer Batterie, die halten soll.

Entstanden ist es 1999 durch Andy Stanford-Clark von IBM und Arlen Nipper von Arcom, um Telemetrie aus Ölpipelines über Satellit zu übertragen. Die Bedingungen waren unbarmherzig: Bandbreite war teuer und knapp, die Verbindung brach ständig ab, und die Geräte waren schwach. Diese Zwänge haben alles am Protokoll geprägt — ein winziger Header, eine einzige langlebige Verbindung und die Fähigkeit, einen Abbruch ohne Nachrichtenverlust zu überstehen.

Heute ist MQTT ein OASIS-Standard, und Version 3.1.1 wurde zusätzlich als internationaler Standard ISO/IEC 20922 übernommen. Die Ölindustrie hat es längst hinter sich gelassen: Smart Homes, Verbrauchszähler, Werkzeugmaschinen, Autos und Medizingeräte laufen damit.

Der minimale Mehraufwand je Nachricht beträgt zwei Byte. Eine einzelne HTTP-Anfrage verbraucht dagegen Hunderte Byte allein für Header, noch vor jeglichem Inhalt. Wenn ein Gerät im Feld über ein Mobilfunkmodem einmal pro Sekunde eine Temperatur meldet, entscheidet dieser Unterschied über den Entwurf.

# So funktioniert es: Publish, Subscribe und der Broker

Bei HTTP fragt der Client und der Server antwortet. Bei MQTT fragt niemand irgendjemanden: Ein Gerät veröffentlicht eine Nachricht in einem Topic, und alle, die dieses Topic abonniert haben, erhalten sie. Der Sender weiß nicht, wer mitliest — und ob überhaupt jemand; der Empfänger weiß nicht, wer gesendet hat. Das Einzige, was beide verbindet, ist der Name des Topics.

In der Mitte steht immer ein Broker — ein Server, der die Verbindungen hält, den Abonnementbaum verwaltet und die Nachrichten verteilt. Ohne ihn funktioniert das Modell nicht: Der Broker macht aus „ins Leere gesendet“ ein „an alle zugestellt, die es brauchen“.

Was der Broker tut

• Nimmt Verbindungen an und hält sie — Tausende gleichzeitig, jahrelang ohne Unterbrechung.
• Prüft, wer sich verbindet: Anmeldename und Passwort, ein Zertifikat oder ein Token.
• Entscheidet, was jeder Client darf: Rechte zum Veröffentlichen und Abonnieren werden je Topic vergeben.
• Gleicht jede veröffentlichte Nachricht mit dem Abonnementbaum ab und verteilt die Kopien.
• Hält Zustand vor: zuletzt bekannte Werte (Retain), Warteschlangen für abwesende Clients, offene Bestätigungen.
• Verfolgt, wer noch lebt, und veröffentlicht den letzten Willen derer, die verschwinden.

Sender und Empfänger zu entkoppeln ist kein technisches Detail, sondern der ganze Sinn des Modells. Sie können einen Sensor austauschen, einen zweiten Verbraucher ergänzen oder eine Auswertung danebenhängen, ohne irgendetwas umzuschreiben: Alle sprechen mit einem Topic, nicht miteinander.

# Topics und Platzhalter

Ein Topic ist eine Zeichenkette aus Ebenen, getrennt durch Schrägstriche. Nichts muss vorher angemeldet werden: Wer in ein neues Topic veröffentlicht, erzeugt es damit auf der Stelle.

buero/etage2/raum14/temperatur
buero/etage2/raum14/feuchte
buero/etage2/raum15/temperatur

Ein Abonnement kann mit zwei Platzhaltern ganze Zweige erfassen:

Der Platzhalter # ist nur als letzte Ebene zulässig: buero/#/temperatur ist kein gültiger Filter. Topics unterscheiden Groß- und Kleinschreibung, und buero/etage2 und buero/etage2/ sind zwei verschiedene Topics.

# Dienstgüte: QoS 0, 1 und 2

MQTT lässt Sie wählen, wie viel Aufwand jede Nachricht wert ist. Die Stufe wird beim Veröffentlichen und beim Abonnieren getrennt gesetzt; wirksam ist die niedrigere von beiden.

Der Preis steigt mit der Zusicherung: QoS 2 bedeutet vier Pakete statt einem, dazu Zustand auf beiden Seiten. Widerstehen Sie dem Drang, „sicherheitshalber überall 2“ zu nehmen: Zehntausend Sensoren, die jede Sekunde mit QoS 2 veröffentlichen, belasten einen Broker um eine Größenordnung stärker — ohne Nutzen.

# Retain, Last Will, Sitzungen und Keep-alive

Retain — der zuletzt bekannte Wert

Eine gewöhnliche Nachricht erreicht nur, wer in genau diesem Moment abonniert hat. Eine Nachricht mit dem Flag Retain merkt sich der Broker zusätzlich und übergibt sie jedem neuen Abonnenten im Augenblick des Abonnierens. Das ist die Standardantwort auf das ewige Problem eines Dashboards, das leer aufgeht und leer bleibt, bis ein Sensor geruht, den nächsten Wert zu senden.

Ein Topic hält genau eine Retained Message — die letzte. Zum Löschen veröffentlichen Sie einen leeren Payload im selben Topic mit gesetztem Retain-Flag.

Last Will — eine Nachricht für den Fall, dass die Leitung stirbt

Beim Verbinden kann ein Client dem Broker einen letzten Willen übergeben: ein Topic, einen Payload und dessen Optionen. Stirbt die Verbindung unhöflich — ohne DISCONNECT-Paket —, veröffentlicht der Broker diese Nachricht stellvertretend. Das klassische Muster ist ein Retained-Topic device/42/status, das beim Verbinden online erhält und als Willen offline trägt. Das System weiß immer, wer da ist, ganz ohne Abfragen.

Sitzungen: clean und persistent

Eine Clean Session währt genau so lange wie die Verbindung: Trennen bedeutet, die Abonnements sind vergessen. Eine persistente übersteht den Abbruch: Der Broker merkt sich die Abonnements und legt Nachrichten mit QoS 1 und 2 in eine Warteschlange, solange der Client fehlt, um sie bei der Rückkehr nachzuliefern. Für ein Gerät, das einmal pro Stunde aufwacht, ist das die einzige Art, nichts zu verpassen.

Keep-alive — merken, dass die Leitung tot ist

Eine abgerissene TCP-Verbindung kann beiden Seiten lange völlig lebendig erscheinen. Deshalb nennt der Client ein Keep-alive-Intervall und sendet, wenn er sonst nichts zu sagen hat, ein Ping. Hört der Broker anderthalb Intervalle lang nichts, erklärt er den Client für verschwunden, schließt die Verbindung und veröffentlicht dessen letzten Willen.

# Die Versionen: 3.1, 3.1.1 und 5.0

In der Praxis begegnen einem drei Versionen, und die Unterschiede sind nicht kosmetisch.

Davon getrennt steht MQTT-SN, ein Schwesterprotokoll für Netze ohne TCP: ZigBee, Funkstrecken, UDP. Es ist keine „Version von MQTT“, sondern eine eigene Spezifikation; solche Netze bekommen ein Gateway, das den Verkehr in gewöhnliches MQTT übersetzt.

Was MQTT 5.0 tatsächlich bringt

Version 5 ist aus angesammeltem Ärger der Praxis entstanden. Das Wichtigste:

• Reason Codes. In 3.1.1 sah eine Ablehnung wie ein still geschlossener Socket aus, und Sie durften raten. In 5.0 sagt der Server, was los war: falsches Passwort, kein Recht für dieses Topic, Paket zu groß.
• Paket-Properties. Eine Nachricht kann Metadaten tragen: Content Type, Correlation Data, beliebige eigene Schlüssel-Wert-Paare. Früher wurde all das in den Payload oder den Topic-Namen gestopft.
• Anfrage und Antwort. Die Felder Response Topic und Correlation Data machen gewöhnliches RPC zu einem vollwertigen Muster statt einer selbstgebauten Konvention.
• Shared Subscriptions über $share/group/filter: Mehrere Instanzen eines Verbrauchers teilen sich den Strom. Das ist Lastverteilung und Ausfallsicherung auf Protokollebene.
• Lebensdauern von Sitzungen und Nachrichten. Session Expiry und Message Expiry erlauben „einen Tag aufheben, dann vergessen“ statt der Entweder-oder-Wahl zwischen clean und nicht clean.
• Flusskontrolle. Receive Maximum begrenzt die Zahl unbestätigter Nachrichten unterwegs, und Maximum Packet Size schützt ein kleines Gerät vor einem Paket, das es nicht verdauen kann.
• Topic-Aliase. Ein langer Name wird einmal gesendet und danach durch eine Zwei-Byte-Zahl ersetzt — bei tiefen Hierarchien eine echte Ersparnis.
• Subscription Identifier, No Local, Retain As Published, Retain Handling. Kleinigkeiten, die alte Fallen beseitigen: das Echo eigener Nachrichten zu hören, eine Lawine von Retained Messages bei jedem Reconnect, nicht zu wissen, über welches Abonnement eine Nachricht kam.
• Verzögerter Wille. Will Delay Interval verhindert, dass ein kurzer Aussetzer Alarm auslöst: Der Wille wird nur veröffentlicht, wenn der Client nicht rechtzeitig zurückkehrt.

Die praktische Folgerung: Beginnen Sie neue Projekte mit 5.0. Shared Subscriptions und verständliche Fehlercodes sparen Wochen an Fehlersuche, und die Verträglichkeit mit älteren Geräten geht nicht verloren.

# MQTT gegen HTTP und die Alternativen

„Wozu MQTT, wenn es REST gibt?“ ist eine berechtigte Frage. Der Unterschied liegt nicht in der Mode, sondern in der Richtung und den Kosten eines Gesprächs.

Das Nachfragen macht es deutlich. Um über HTTP binnen einer Sekunde von einem Ereignis zu erfahren, müssen tausend Geräte tausendmal pro Sekunde fragen, und fast jede Antwort lautet „nichts Neues“. Bei MQTT kommt das Ereignis von selbst, sobald es eintritt, und kostet in der Zwischenzeit keinen Datenverkehr.

Was ist mit CoAP, AMQP und WebSocket

• CoAP ist REST über UDP für sehr kleine Knoten. Leichter als MQTT, bietet aber ohne Zusatzaufwand weder Warteschlangen noch zuverlässige Zustellung.
• AMQP ist schwerer und reicher: aufwendiges Routing, Transaktionen, Warteschlangen für Unternehmen. Zwischen Servern sinnvoll, für einen Sensor übertrieben.
• WebSocket ist ein Transport, keine Alternative: MQTT läuft selbst über WebSocket, damit es im Browser funktioniert.
• Sparkplug B ist kein Konkurrent, sondern eine Schicht auf MQTT: Es schreibt vor, wie Topics benannt und Payloads kodiert werden, damit SCADA-Software verschiedener Hersteller dieselben Daten versteht.

# Transport, Ports und Payloads

MQTT läuft über TCP und verlangt nur zuverlässige, geordnete Zustellung. Die üblichen Ports:

Für das Protokoll ist ein Payload nur eine Folge von Bytes. MQTT weiß nichts über den Inhalt und schreibt nichts vor: JSON, CBOR, Protobuf, eine einzelne Zahl oder ein Bild sind gleichermaßen zulässig. Die formale Grenze liegt bei 256 MB, doch in der Praxis gehört alles jenseits einiger hundert Kilobyte zu HTTP, während über MQTT nur ein Verweis reist.

In der Praxis dominiert JSON: Ein Mensch kann es lesen, jede Sprache kann es parsen, und kompakt genug ist es auch. Auf einer schmalen Leitung verdient ein Binärformat seinen Platz — und genau dort hilft die Property Content Type aus MQTT 5.0, indem sie ehrlich sagt, was drinsteckt.

# Sicherheit

MQTT verschlüsselt von sich aus nichts: Auf Port 1883 reisen Benutzername und Passwort im Klartext. Sicherheit entsteht aus drei unabhängigen Schichten, und keine davon ist optional.

Den Kanal verschlüsseln

TLS auf Port 8883. Für Geräte, die zu schwach für TLS sind, bleibt nur eine anständige Möglichkeit: sie in einem abgeschotteten Netz zu halten und nichts nach außen zu lassen außer über ein Gateway.

Authentifizierung

Der Klassiker sind Benutzername und Passwort im CONNECT-Paket. Strenger sind Client-Zertifikate: Das Gerät weist sein eigenes vor, und der Broker prüft die Signatur. Flexibler ist JWT: Das Gerät bringt ein signiertes, zeitlich begrenztes Token mit, und ein Entzug erfordert keine Änderung am Broker. Gute Broker können Konten außerdem aus einer externen Datenbank, einer CSV-Datei oder einem HTTP-Dienst lesen, damit die Geräteliste nicht doppelt existieren muss.

Topic-Rechte

Authentifizierung beantwortet „wer sind Sie“, Autorisierung „was dürfen Sie“. Zugriffslisten legen fest, welche Topics ein Client lesen und welche er schreiben darf. Die richtige Einstellung lautet: alles verbieten außer dem ausdrücklich Erlaubten.

Dazu kommen Ratenbegrenzungen beim Veröffentlichen (damit ein einzelnes durchgedrehtes Gerät den Broker nicht begräbt), eine maximale Paketgröße und gewöhnliche Netzhygiene: Das Dashboard des Brokers hat im offenen Internet nichts verloren.

# Wo MQTT tatsächlich eingesetzt wird

Smart Home und Gebäudeautomation

Das größte Feld nach Stückzahl. Home Assistant, Zigbee2MQTT, ESPHome und openHAB sprechen alle über einen MQTT-Broker, der zugleich der Klebstoff zwischen Hardware verschiedener Hersteller ist: Eine Steckdose, ein Leckagesensor und ein Heizungsregler dreier Anbieter arbeiten bestens zusammen, weil jeder einfach in sein eigenes Topic schreibt.

Industrie und SCADA

Maschinenwerte, Linienstatus, Betriebsstundenzähler. Die klassische Anordnung ist ein Gateway, das Modbus oder OPC UA von der Anlage liest und über MQTT weiterveröffentlicht, woraufhin SCADA, ein Historian und eine vorausschauende Wartung es gleichzeitig und störungsfrei verbrauchen. Hier verdienen sich Sparkplug B und die Shared Subscriptions aus MQTT 5.0 ihren Platz.

Zählerwesen und Versorger

Wasser-, Gas-, Strom- und Wärmezähler: Batteriegeräte, die einmal pro Stunde aufwachen, einen Wert melden und weiterschlafen. Persistente Sitzungen und Retain leisten hier die Hauptarbeit — der Server sieht immer den letzten Wert, selbst wenn sich ein Zähler erst am Abend meldet.

Verkehr und Telematik

Koordinaten, Kraftstoffverbrauch, Zustand des Kühlaufbaus, Fahrverhalten. Die Verbindung ist ein Mobilfunknetz, das in Tunneln und außerhalb der Stadt verschwindet. Warteschlangen und erneute Zustellung nach dem Reconnect machen aus einer zerrissenen Verbindung einen durchgehenden Datenstrom.

Energie, Landwirtschaft, Gesundheitswesen

Solarparks und Umspannwerke, Bewässerungsanlagen und Wetterstationen, Patientenmonitore und Impfstoffkühlschränke. Gemeinsam ist ihnen: viele Endpunkte, eine schwache Verbindung, Ereignisse, die nicht verloren gehen dürfen, und die Notwendigkeit, sofort von einer Störung zu erfahren.

Smart Cities und Logistik

Straßenbeleuchtung, Parkraum, Abfallbehälter, die ihren Füllstand melden, Sendungsverfolgung und Temperatur in der Kühlkette. Zehntausende Geräte mit kurzen, seltenen Nachrichten — genau das Lastprofil, für das MQTT entworfen wurde.

# Topics entwerfen: Entscheidungen, die früh lohnen

Ihr Topic-Schema ist die API Ihres Systems. Es später zu ändern schmerzt, weil Firmware und Server im Gleichschritt aktualisiert werden müssen. Ein paar Regeln, die Zeit sparen.

• Vom Allgemeinen zum Speziellen. werk/halle3/linie2/maschine7/temperatur erlaubt ein Abonnement auf jeder Ebene. Die umgekehrte Reihenfolge macht Platzhalter nutzlos.
• Geben Sie der Geräte-ID eine eigene Ebene. Genau das erlaubt es, ein Gerät mit einer einzigen ACL-Regel auf seinen Zweig zu beschränken.
• Kein führender Schrägstrich. /buero/temp erzeugt eine leere erste Ebene — zulässig, aber eine dauerhafte Quelle der Verwirrung.
• Nur lateinische Buchstaben, Ziffern, Bindestrich und Unterstrich. Leerzeichen und die Zeichen +, # und $ in Namen führen zu Fehlern, mit denen niemand rechnet.
• Niemals veränderliche Daten im Topic kodieren. sensor/42/temp/21.5 ist ein Fehler: Der Wert gehört in den Payload, sonst bekommt der Broker einen unbegrenzten Topic-Baum und Retain wird nutzlos.
• Trennen Sie Zustand von Befehlen. Etwa device/42/state für das, was das Gerät meldet, und device/42/cmd für das, was ihm gesagt wird. Sonst dreht das Echo der eigenen Befehle irgendwann die Logik im Kreis.
• Retain für Status, nicht für Telemetrie. Retain passt zum „zuletzt bekannten Zustand“ und ist für einen Strom von Messwerten sinnlos.

# Einen Broker auswählen

Es gibt viele Broker, und die Wahl läuft meist auf eine Handvoll Fragen hinaus.

• Wird MQTT 5.0 vollständig unterstützt? Teilweise Unterstützung ist verbreitet, und man erfährt davon meist im denkbar ungünstigsten Moment.
• Können Sie sehen, was passiert? Zu sehen, wer verbunden ist, welche Topics leben und was gerade vorbeifliegt, spart Stunden an Fehlersuche. Ein Broker ohne Dashboard macht aus jedem Problem eine Grabung im Log.
• Wie werden Geräte angelegt? Bei Tausenden ist Handarbeit ausgeschlossen — Sie brauchen eine API oder Konten in einer externen Datenbank.
• Übersteht er einen Neustart? Retained Messages, persistente Sitzungen und Warteschlangen müssen auf die Platte, sonst bedeutet ein geplanter Neustart Datenverlust.
• Welche Limits gibt es? Ein durchgedrehtes Gerät darf das System nicht lahmlegen: Raten- und Mengenbegrenzungen zählen.
• Was kostet er und wo läuft er? Ein Cloud-Dienst ist bequem, bis er je Nachricht abrechnet; ein eigener Server will verwaltet werden, behält die Daten aber bei Ihnen.

Für eine kleine oder mittlere Installation — vom Smart Home bis zu einem Werk mit einigen tausend Endpunkten — genügt normalerweise ein einzelner Broker auf bescheidener Hardware. Clustering wird weit seltener gebraucht, als es beim Entwurf scheint; öfter lohnt es, zwei unabhängige Broker mit einer Bridge zu verbinden, die nur die wichtigen Topics weiterleitet.

# In fünf Minuten loslegen

Am schnellsten versteht man all das, indem man einen Broker startet und den Nachrichten selbst zusieht. Unter Debian oder Ubuntu sind das drei Befehle:

sudo wget -qO /usr/share/keyrings/elx-repo.gpg https://repo.um-d.ru/elx-repo.gpg
echo "deb [signed-by=/usr/share/keyrings/elx-repo.gpg] https://repo.um-d.ru stable main" | sudo tee /etc/apt/sources.list.d/elx-repo.list
sudo apt-get update && sudo apt-get install elxmqttbroker

Das Dashboard öffnet sich unter http://ihr-server:8567. Legen Sie einen Benutzer an und probieren Sie den Austausch mit einem beliebigen Client — etwa den Konsolenwerkzeugen von mosquitto:

# in einem Fenster — alles abonnieren, was das Gerät sendet
mosquitto_sub -h localhost -u sensor-42 -P passwort -t 'sensor-42/#' -v

# in einem anderen — einen Messwert veröffentlichen
mosquitto_pub -h localhost -u sensor-42 -P passwort -t 'sensor-42/temp' -m '21.5'

# dasselbe, aber für künftige Abonnenten gemerkt
mosquitto_pub -h localhost -u sensor-42 -P passwort -t 'sensor-42/temp' -m '21.5' -r

Spielen Sie danach mit dem Retain-Flag, trennen Sie einen Abonnenten und sehen Sie, was sich in einer persistenten Sitzung ansammelt, setzen Sie einen letzten Willen und ziehen Sie das Kabel. Eine halbe Stunde davon lehrt mehr als jeder Artikel, dieser eingeschlossen.

# Kurze Antworten