Teil 2 – Die Architektur von MQTT

Im ersten Teil hast du gelernt, dass MQTT ein leichtgewichtiges Protokoll ist, das auf dem Publish/Subscribe-Modell basiert. Jetzt steigen wir tiefer ein: Wie sieht die Architektur von MQTT aus, welche Komponenten spielen zusammen, und wie sorgt das Protokoll dafür, dass Nachrichten zuverlässig übermittelt werden – auch bei instabilen Verbindungen?

Die drei zentralen Bausteine

1. Der Broker – das Herzstück

Der Broker ist die Schaltzentrale in MQTT.

• Er nimmt Nachrichten von Publishern entgegen.
• Er verteilt diese Nachrichten an die passenden Subscriber.
• Er verwaltet, wer welches Topic abonniert hat.

Wichtig: Publisher und Subscriber kennen sich nicht direkt. Sie kommunizieren immer über den Broker.

Beispiel:

• Sensor publiziert „22,5 °C“ auf haus/wohnzimmer/temperatur.
• Broker empfängt die Nachricht.
• Alle Subscriber mit Interesse an diesem Topic bekommen sie zugestellt.

2. Publisher – der Sender

Publisher sind die Geräte oder Anwendungen, die Daten veröffentlichen.

• Beispiele: Temperatursensor, Bewegungssensor, Solaranlage.
• Sie senden Nachrichten an definierte Topics.
• Nachrichten bestehen aus Topic + Payload.

Beispiel:

Topic: haus/keller/luftfeuchtigkeit
Payload: 63%

3. Subscriber – der Empfänger

Subscriber sind die Abnehmer von Nachrichten.

• Sie „abonnieren“ bestimmte Topics.
• Sie bekommen automatisch alle Nachrichten, die unter diesem Topic veröffentlicht werden.
• Es können beliebig viele Subscriber existieren.

Beispiel:

• App auf dem Smartphone zeigt „Wohnzimmer 22,5 °C“.
• Heizungssteuerung reagiert auf Wert und passt Temperatur an.

Topics – die Adressen im MQTT-Universum

Topics sind hierarchische Strings, die Nachrichten organisieren. Sie funktionieren ähnlich wie Ordnerpfade.

Beispiel-Topic-Struktur:

haus/wohnzimmer/temperatur
haus/wohnzimmer/luftfeuchtigkeit
haus/keller/temperatur

Wildcards in Topics

Subscriber können mit Platzhaltern flexibel arbeiten:

• + (Single Level):
  • haus/+/temperatur → abonniert alle Temperaturen aus allen Räumen.
• # (Multi Level):
  • haus/# → abonniert alle Nachrichten im Haus.

Das macht MQTT besonders praktisch für dynamische Strukturen.

Quality of Service (QoS) – Zuverlässigkeit steuern

Nicht jede Nachricht muss mit maximaler Zuverlässigkeit übertragen werden. Ein Temperatursensor, der jede Sekunde sendet, darf auch mal eine Nachricht verlieren. Aber ein Alarm darf niemals untergehen. Dafür gibt es QoS-Level.

QoS 0 – At most once

• Nachricht wird „best effort“ gesendet.
• Keine Bestätigung, keine Wiederholung.
• Schnell und effizient, aber unsicher.

Beispiel: Sensor sendet alle 5 Sekunden Temperatur. Wenn eine Nachricht verloren geht, macht das nichts.

QoS 1 – At least once

• Nachricht wird mindestens einmal zugestellt.
• Broker bestätigt den Empfang.
• Kann zu Duplikaten führen (Subscriber muss mit Mehrfachnachrichten umgehen).

Beispiel: Smart-Home-App erhält Temperaturwerte zuverlässig, auch wenn die Verbindung wackelt.

QoS 2 – Exactly once

• Nachricht wird garantiert genau einmal zugestellt.
• Komplexer Handshake zwischen Publisher und Broker.
• Höchste Zuverlässigkeit, aber langsamer und ressourcenintensiver.

Beispiel: Banktransaktionen oder kritische Steuerbefehle.

Retained Messages – letzter bekannter Wert

Standardmäßig erhalten Subscriber nur Nachrichten, die nach ihrem Abo veröffentlicht werden. Aber was, wenn jemand später dazukommt?

Retained Messages lösen dieses Problem:

• Publisher markiert eine Nachricht als „retained“.
• Broker speichert sie.
• Jeder neue Subscriber bekommt sofort den letzten Wert.

Beispiel:

• Sensor sendet 22,5 °C als retained.
• Neuer Subscriber abonniert haus/wohnzimmer/temperatur.
• Er erhält sofort den letzten Wert – ohne warten zu müssen.

Last Will and Testament (LWT)

MQTT bietet eine eingebaute Möglichkeit, Ausfälle zu erkennen.

Prinzip:

• Beim Verbindungsaufbau kann ein Client eine „Letzte Nachricht“ (Last Will) hinterlegen.
• Wenn der Client unerwartet die Verbindung verliert, sendet der Broker diese Nachricht automatisch an ein definiertes Topic.

Beispiel:

• Ein Sensor meldet sich mit LWT: „Sensor offline“.
• Wenn er unerwartet verschwindet, veröffentlicht der Broker automatisch diese Nachricht.
• Alle Subscriber wissen sofort, dass der Sensor nicht mehr aktiv ist.

MQTT-Session-Handling

• Persistent Session: Broker merkt sich, welche Topics ein Client abonniert hat. Wenn der Client wieder online kommt, bekommt er alle verpassten Nachrichten (sofern QoS > 0).
• Clean Session: Alles wird bei jedem Verbindungsaufbau neu gestartet.

Beispiel:

• Handy-App abonniert ein Topic.
• Verbindung bricht ab.
• Bei Persistent Session bekommt sie beim Wiederverbinden alle Nachrichten nachgeliefert.

Skalierung und Performance

Skalierbarkeit

• Ein einzelner Broker kann Tausende Verbindungen verarbeiten.
• Für sehr große Systeme: Cluster-Broker oder verteilte Architekturen.

Performance

• MQTT arbeitet über TCP, optional auch über WebSockets.
• Sehr geringer Overhead (oft < 2 Bytes pro Nachricht).
• Ideal für Mobilfunk und schwache Hardware (ESP32, Arduino, Raspberry Pi).

Sicherheitsaspekte in der Architektur

Von Haus aus ist MQTT unverschlüsselt. Sicherheit muss aktiv hinzugefügt werden:

• Authentifizierung: Benutzername/Passwort oder Zertifikate.
• Verschlüsselung: TLS, um Daten vor Abhören zu schützen.
• Zugangskontrolle: Rechtevergabe pro Topic (wer darf was publizieren/abonnieren).

Praxisbeispiel – Zusammenspiel der Komponenten

1. Publisher: Temperatur-Sensor im Wohnzimmer → publiziert Wert an haus/wohnzimmer/temperatur.
2. Broker: Empfängt Nachricht, prüft Abo-Liste.
3. Subscriber A: Smartphone-App → zeigt Temperatur an.
4. Subscriber B: Heizungssystem → regelt Wärme nach.
5. Retained Message: Wert wird gespeichert, neue Subscriber sehen ihn sofort.
6. QoS 1: Broker bestätigt Empfang, keine Nachricht geht verloren.
7. LWT: Sensor meldet „offline“, falls er abstürzt.

So ergibt sich ein robustes System mit minimalem Aufwand.