Was ist MQTT? Eine praxisnahe Einführung

MQTT (ursprünglich MQ Telemetry Transport) ist ein schlankes Messaging-Protokoll, das auf dem Publish/Subscribe-Muster basiert. Clients sprechen nie direkt miteinander – sie schicken Nachrichten an einen zentralen Broker, versehen mit einem Topic, und der Broker leitet jede Nachricht an alle Clients weiter, die ein passendes Topic abonniert haben. Genau dieses einfache Modell ist der Grund, warum MQTT heute alles antreibt – von Sensornetzwerken und Smart Homes bis zu Fahrzeugtelemetrie und Live-Dashboards.

Diese Einführung erklärt, wie MQTT funktioniert, welche Features wichtig sind und wann es das richtige Werkzeug ist (und wann nicht). Wenn du direkt mitmachen willst, öffne den Online-MQTT-Client in einem zweiten Tab.

Eine kurze Geschichte

MQTT wurde 1999 von Andy Stanford-Clark (IBM) und Arlen Nipper entwickelt, um Ölpipelines über teure, unzuverlässige Satellitenverbindungen zu überwachen. Die Designziele – winzige Pakete, minimaler Client-Code, Toleranz gegenüber wackeligen Netzen – passten perfekt zum Internet der Dinge. MQTT 3.1.1 wurde 2014 ein OASIS-Standard (später auch ISO/IEC 20922), und 2019 folgte MQTT 5.0 mit Reason Codes, User Properties, Message Expiry und mehr. Beide Versionen sind heute weit verbreitet; die Unterschiede findest du unter MQTT 5 vs. 3.1.1.

So funktioniert MQTT: Publish/Subscribe

In MQTT gibt es nur zwei Rollen:

• Clients – jedes Programm oder Gerät, das sich mit dem Broker verbindet. Ein Client kann publishen, subscriben oder beides. Ein Temperatursensor, eine Mobile-App und ein Backend-Service sind allesamt einfach Clients.
• Der Broker – der Server, der Verbindungen annimmt, Clients authentifiziert, Topics abgleicht und Nachrichten zustellt. Bekannte Broker sind Mosquitto, EMQX und HiveMQ.

Publisher und Subscriber sind entkoppelt: Ein Publisher weiß nicht, wer (falls überhaupt jemand) seine Nachricht empfängt, und Subscriber wissen nicht, wer sie gesendet hat. Sie teilen sich nur einen Topic-Namen. Dadurch kannst du ganz einfach einen neuen Consumer hinzufügen – ein Dashboard, einen Datenbank-Writer, einen Alerting-Service –, ohne die Geräte anzufassen, die die Daten erzeugen.

sensor-17  --PUBLISH home/kitchen/temperature "21.5"-->  broker
broker     --PUBLISH home/kitchen/temperature "21.5"-->  dashboard   (subscribed to home/+/temperature)
broker     --PUBLISH home/kitchen/temperature "21.5"-->  logger      (subscribed to home/#)

Topics: die Adresse einer Nachricht

Ein Topic ist ein UTF-8-String mit Ebenen, die durch Schrägstriche getrennt sind, etwa factory/line-2/press-4/pressure. Topics werden nicht vorab angelegt – sie existieren, sobald jemand darauf publisht. Subscriber können zwei Wildcards nutzen: + passt auf genau eine Ebene und # auf beliebig viele Ebenen am Ende. Gutes Topic-Design ist für Berechtigungen und Skalierung enorm wichtig; unser Leitfaden zu MQTT-Topics und Wildcards geht ausführlich darauf ein.

Die Verbindung und ihre Pakete

MQTT läuft über eine langlebige Verbindung – meist TCP, optional in TLS verpackt, oder WebSockets im Browser. Die Session beginnt mit einem CONNECT-Paket (Client-ID, optional Benutzername und Passwort, Keep-Alive, Last Will), und der Broker antwortet mit CONNACK. Danach sind die häufigsten Pakete:

Der Fixed Header eines MQTT-Pakets ist nur zwei Bytes groß, und die Payload ist opakes Binärformat – JSON, Klartext, Protobuf oder rohe Bytes funktionieren gleichermaßen. Dieser geringe Overhead macht MQTT so attraktiv für ressourcenarme Geräte und volumenbasierte Netze.

Die wichtigsten MQTT-Features

Quality of Service

Jeder Publish und jede Subscription hat eine QoS-Stufe: 0 (höchstens einmal), 1 (mindestens einmal) oder 2 (genau einmal). Höhere Stufen fügen Bestätigungspakete hinzu und liefern dafür stärkere Zustellgarantien. Details und Paketabläufe findest du unter MQTT-QoS-Stufen erklärt.

Retained Messages

Eine mit dem Retain-Flag gepublishte Nachricht speichert der Broker als letzten bekannten Wert dieses Topics und stellt sie jedem neuen Subscriber sofort zu. Ideal für Zustände wie online/offline oder den aktuellen Sollwert. Siehe Retained Messages.

Last Will and Testament

Ein Client kann eine Nachricht hinterlegen, die der Broker in seinem Namen publisht, wenn der Client ohne sauberes Disconnect verschwindet – der Standardweg, um Offline-Geräte zu erkennen. Siehe Last Will and Testament.

Persistente Sessions

Mit einer persistenten Session (cleanSession=false in 3.1.1, cleanStart=false plus Session Expiry Interval in MQTT 5) merkt sich der Broker die Subscriptions eines Clients und puffert QoS-1- und QoS-2-Nachrichten, solange er offline ist. Beim erneuten Verbinden werden sie zugestellt.

MQTT in zwei Minuten ausprobieren

Am schnellsten verstehst du MQTT, wenn du einer Nachricht beim Round Trip zuschaust. Verbinde dich mit einem öffentlichen Broker, abonniere ein eindeutiges Topic und publishe darauf:

1. Öffne den Online-Client und verbinde dich mit einem Broker aus der Liste öffentlicher Broker.
2. Abonniere testmqtt/your-name/#.
3. Publishe hello an testmqtt/your-name/greeting und sieh zu, wie die Nachricht ankommt.

Im Online-MQTT-Client ausprobieren

Oder im Terminal, wenn die Mosquitto-Clients installiert sind:

# terminal 1
mosquitto_sub -h test.mosquitto.org -t 'testmqtt/intro/#' -v

# terminal 2
mosquitto_pub -h test.mosquitto.org -t 'testmqtt/intro/greeting' -m 'hello'

Wann du MQTT einsetzen solltest (und wann nicht)

MQTT passt gut, wenn:

• viele Geräte kleine, häufige Nachrichten senden (Telemetrie, Sensorwerte, Status).
• Netze unzuverlässig sind oder die Bandbreite begrenzt ist und du automatische Reconnects und Offline-Pufferung brauchst.
• Daten in Echtzeit an Clients gepusht statt abgefragt werden sollen.
• du One-to-Many-Fan-out willst, ohne Producer und Consumer direkt zu verdrahten.

Weniger gut passt es, wenn:

• du Request/Response mit umfangreicher Semantik brauchst – einfache HTTP-APIs sind dafür simpler (MQTT 5 bietet zwar Response Topics, bleibt aber Messaging).
• du eine Langzeitspeicherung oder ein Replay der kompletten Event-Historie brauchst – das ist Aufgabe eines Logs wie Kafka oder einer Datenbank, die aus MQTT gespeist wird.
• du große Dateien überträgst; MQTT kann das zwar, ist aber nicht dafür gemacht.

Einen direkten Vergleich findest du unter MQTT vs. HTTP.

Nächste Schritte

Jetzt, wo du weißt, was MQTT ist, lerne, wie du QoS-Stufen wählst, eine Topic-Hierarchie entwirfst und einen MQTT-Broker durchgängig testest. Alle Anleitungen findest du im MQTT-Lernzentrum.

Häufig gestellte Fragen