MQTT ist ein schlankes Messaging-Protokoll, das für eine effiziente Kommunikation zwischen Geräten, Anwendungen, Sensoren, Gateways, Cloud-Plattformen und Steuerungssystemen entwickelt wurde. Es wird häufig in IoT-Netzen, Telemetriesystemen, Smart Buildings, industrieller Überwachung, Fahrzeugplattformen, Energiesystemen, Gebäude- und Heimautomation, Fernverwaltung von Geräten und mobilen Anwendungen eingesetzt, bei denen Bandbreite, Energie oder Netzstabilität begrenzt sein können.
Das Protokoll basiert auf einem Publish/Subscribe-Modell. Statt dass ein Gerät Daten direkt an ein anderes Gerät sendet, werden Nachrichten an einen Broker gesendet. Der Broker verteilt diese Nachrichten anschließend an Clients, die passende Topics abonniert haben. Diese Struktur macht die Kommunikation flexibel, skalierbar und geeignet für Systeme mit vielen Geräten, die die Netzwerkadresse der jeweils anderen Geräte nicht kennen müssen.
Eine andere Sicht auf Gerätemessaging
Klassische Client-Server-Kommunikation funktioniert häufig als direkte Anfrage und Antwort. Ein Client fragt einen Server nach Informationen, und der Server antwortet. MQTT folgt einem anderen Konzept. Ein Gerät kann eine Nachricht veröffentlichen, ohne zu wissen, wer sie empfängt, während ein anderes Gerät ein Topic abonnieren kann, ohne zu wissen, wer darin veröffentlicht.
Diese Trennung ist in großen verteilten Systemen nützlich. Ein Temperatursensor muss nicht wissen, welches Dashboard, welche Datenbank, welche mobile App oder welche Automatisierungsregel seine Daten nutzt. Er muss nur in ein definiertes Topic veröffentlichen. Die Verteilung übernimmt der Broker.
Das Ergebnis ist ein Kommunikationsmuster, das die enge Kopplung zwischen Geräten reduziert. Systeme können neue Abonnenten hinzufügen, ohne den Sensor zu ändern. Sie können auch neue Publisher hinzufügen, ohne jede Anwendung umzuschreiben. Dies ist ein Grund, warum das Protokoll im IoT- und Telemetriedesign so verbreitet ist.
Der Broker als Nachrichtenhub
Der Broker ist die zentrale Komponente der Architektur. Er nimmt Client-Verbindungen an, authentifiziert Clients bei Bedarf, empfängt veröffentlichte Nachrichten, gleicht Topics mit Abonnements ab und leitet Nachrichten an die richtigen Abonnenten weiter.
Ein Broker kann auf einer Cloud-Plattform, einem privaten Server, einem Edge-Gateway, einem Industriecomputer, einem eingebetteten Gerät oder einem verwalteten Messaging-Dienst laufen. In kleinen Installationen kann ein Broker den gesamten Verkehr verarbeiten. In größeren Installationen können mehrere Broker geclustert, gebrückt, lastverteilt oder über Regionen verteilt werden.
Der Broker steuert außerdem viele Betriebsverhalten, darunter Sitzungsstatus, retained Messages, Zugriffskontrolle, QoS-Zustellung, Keepalive-Timeout, Verbindungslimits, Topic-Autorisierung und Nachrichtenpersistenz. Daher wirkt sich das Brokerdesign direkt auf Zuverlässigkeit, Skalierbarkeit und Sicherheit aus.
Lebenszyklus der Verbindung
Der Client erstellt eine Sitzung
Ein Client öffnet zunächst eine Netzwerkverbindung zum Broker. MQTT läuft üblicherweise über TCP, und sichere Bereitstellungen verwenden häufig TLS-Verschlüsselung. Nachdem die Transportverbindung hergestellt ist, sendet der Client ein CONNECT-Paket mit Informationen wie Client-ID, Authentifizierungsdaten, Keepalive-Wert, Sitzungsverhalten und optionalen Einstellungen für die Will-Nachricht.
Der Broker prüft die Verbindungsanforderung und antwortet mit einem CONNACK-Paket. Wenn die Verbindung akzeptiert wird, kann der Client mit dem Veröffentlichen, Abonnieren, Abbestellen und Empfangen von Nachrichten beginnen. Wird die Verbindung abgelehnt, liefert der Broker je nach Protokollversion und Konfiguration einen Grund.
Heartbeat hält die Verbindung aktiv
Der Keepalive-Mechanismus hilft beiden Seiten, unterbrochene Verbindungen zu erkennen. Wenn innerhalb der vereinbarten Zeit keine Daten ausgetauscht wurden, sendet der Client ein PINGREQ-Paket und der Broker antwortet mit PINGRESP.
Das ist wichtig, weil IoT-Geräte über instabile Netze, mobile Verbindungen, Wi-Fi, Mobilfunk, Satellitenstrecken oder entfernte WAN-Pfade arbeiten können. Ein Netzwerk kann still ausfallen, ohne die Verbindung sauber zu schließen. Keepalive hilft, diesen Zustand zu erkennen.
Trennung und erneute Verbindung
Ein Client kann sich normal durch Senden eines DISCONNECT-Pakets trennen. Er kann aber auch unerwartet verschwinden, etwa durch Stromausfall, Netzwerkfehler, Firmware-Absturz oder Signalverlust. Der Broker wendet dann die für diesen Client konfigurierten Sitzungs- und Will-Regeln an.
Das Wiederverbindungsverhalten ist in realen Bereitstellungen wichtig. Geräte sollten Netzunterbrechungen sauber behandeln, übermäßige Reconnect-Stürme vermeiden und die Kommunikation gemäß der erforderlichen Sitzungspolitik wieder aufnehmen.
Topic-Namen und Nachrichtenrouting
Topics sind textbasierte Pfade zur Klassifizierung von Nachrichten. Ein Topic kann wie eine Hierarchie aussehen, zum Beispiel building/floor1/room102/temperature oder factory/line3/motor7/status. Publisher senden Nachrichten an Topics, und Abonnenten empfangen Nachrichten aus den Topics, die sie abonniert haben.
Ein gutes Topic-Design ist einer der wichtigsten Bestandteile einer erfolgreichen Bereitstellung. Topic-Namen sollten vorhersehbar, lesbar und an der tatsächlichen Systemstruktur ausgerichtet sein. Ein schlechtes Topic-Design erschwert Filterung, Berechtigungen, Überwachung und langfristige Wartung.
Abonnenten können exakte Topics oder Wildcard-Abonnements verwenden. Ein einstufiges Wildcard kann eine Topic-Ebene abdecken, während ein mehrstufiges Wildcard viele Ebenen abdecken kann. Wildcards sind nützlich für Dashboards, Analyseplattformen, Überwachungstools und Verwaltungsanwendungen, die Nachrichten von vielen Geräten empfangen müssen.
Publish- und Subscribe-Ablauf
Daten veröffentlichen
Wenn ein Client Daten veröffentlicht, sendet er ein PUBLISH-Paket an den Broker. Das Paket enthält den Topic-Namen, die Nutzlast, die Quality-of-Service-Stufe, das Retain-Flag und die Paketkennung, wenn die ausgewählte QoS-Stufe sie erfordert.
Die Nutzlast kann viele Datenformate enthalten. Sie kann Klartext, JSON, Binärdaten, Sensorwerte, Statusmeldungen, Befehle, Alarme, Telemetriedatensätze oder codierte Anwendungsdaten sein. MQTT selbst definiert die Bedeutung der Nutzlast nicht. Die Anwendung entscheidet, wie sie strukturiert und interpretiert wird.
Abonnements empfangen
Ein Client abonniert, indem er ein SUBSCRIBE-Paket mit einem oder mehreren Topic-Filtern sendet. Der Broker antwortet mit SUBACK und beginnt, passende Nachrichten entsprechend der angeforderten und gewährten QoS-Stufe an diesen Client zu liefern.
Abonnenten können Dashboards, Datenbanken, Automatisierungs-Engines, Cloud-Dienste, mobile Apps, Gerätesteuerungen oder andere Feldgeräte sein. Eine veröffentlichte Nachricht kann gleichzeitig an viele Abonnenten geliefert werden.
Interesse entfernen
Wenn ein Client bestimmte Nachrichten nicht mehr möchte, sendet er ein UNSUBSCRIBE-Paket. Der Broker stoppt nach Bestätigung der Anforderung die Weiterleitung passender Topic-Nachrichten.
So können Anwendungen ihr Dateninteresse dynamisch ändern. Ein Dashboard kann beispielsweise ein Gebäude abonnieren, während ein Nutzer es betrachtet, und das Abonnement beenden, wenn der Nutzer zu einem anderen Standort wechselt.
Das Publish/Subscribe-Modell ermöglicht es Datenproduzenten und Datenkonsumenten, sich unabhängig zu entwickeln, während der Broker Routing, Sitzungsverhalten und Zustellkontrolle verwaltet.
Quality-of-Service-Stufen
QoS 0: höchstens einmal
QoS 0 ist die einfachste Zustellstufe. Die Nachricht wird einmal gesendet, und auf MQTT-Ebene gibt es keine Bestätigung vom Empfänger. Geht die Nachricht verloren, wird sie vom Protokoll nicht erneut übertragen.
Diese Stufe eignet sich für häufige Telemetrie, bei der ein gelegentliches verlorenes Update akzeptabel ist. Ein Temperatursensor, der alle paar Sekunden Daten sendet, muss beispielsweise nicht zwingend jede einzelne Messung erfolgreich zustellen.
QoS 1: mindestens einmal
QoS 1 erfordert eine Bestätigung. Der Sender überträgt die Nachricht erneut, wenn keine Bestätigung eingeht. Das verbessert die Zustellzuverlässigkeit, aber der Empfänger kann doppelte Nachrichten erhalten.
Anwendungen mit QoS 1 sollten auf Duplikate vorbereitet sein. Das ist typisch für Alarme, Statusänderungen, Befehle und wichtige Telemetrie, bei denen die Zustellung wichtiger ist als die vollständige Vermeidung von Wiederholungen.
QoS 2: genau einmal
QoS 2 verwendet einen komplexeren Handshake, um sicherzustellen, dass eine Nachricht auf Protokollebene genau einmal zugestellt wird. Es bietet die stärkste Zustellgarantie, verursacht aber mehr Overhead und Latenz.
Diese Stufe kann eingesetzt werden, wenn doppelte Verarbeitung schädlich wäre. Viele reale Bereitstellungen verwenden jedoch QoS 0 oder QoS 1, weil sie ein besseres Gleichgewicht zwischen Leistung und Zuverlässigkeit bieten.
Retained Messages und letzter bekannter Zustand
Eine retained Message wird vom Broker als neueste Nachricht für ein Topic gespeichert. Wenn ein neuer Abonnent dieses Topic abonniert, sendet der Broker sofort die retained Message, damit der Abonnent den zuletzt bekannten Zustand sieht.
Das ist nützlich für Zustandsinformationen wie Online-Status eines Geräts, Schalterstellung, Sensorwert, Konfigurationsversion, Alarmzustand oder aktuellen Betriebsmodus. Ohne retained Messages müsste ein neuer Abonnent möglicherweise bis zum nächsten Update warten, bevor er den aktuellen Zustand kennt.
Retained Messages sollten sorgfältig eingesetzt werden. Sie sind hilfreich für Zustände, aber nicht immer für Ereignisströme geeignet. Ein beibehaltenes Ereignis „Tür geöffnet“ kann einen neuen Abonnenten verwirren, wenn es nicht mehr zutrifft. Zustands-Topics und Ereignis-Topics sollten getrennt entworfen werden.
Sitzungsverhalten und Offline-Zustellung
MQTT unterstützt ein Sitzungsverhalten, das festlegt, was passiert, wenn ein Client getrennt wird und sich später erneut verbindet. Je nach Protokollversion und Konfiguration kann der Broker Abonnements, wartende Nachrichten und Sitzungsstatus für einen Client speichern.
Das ist nützlich für Geräte, die schlafen, zwischen Netzen wechseln oder vorübergehend die Verbindung verlieren. Wenn sich das Gerät erneut verbindet, kann es Nachrichten weiter empfangen, die während seiner Offline-Zeit in der Warteschlange lagen, sofern Sitzungsrichtlinie und QoS-Regeln dies erlauben.
Sitzungspersistenz sollte zur Gerätefunktion passen. Ein batteriebetriebener Sensor muss möglicherweise nicht jeden Befehl dauerhaft in der Warteschlange behalten. Ein Remote-Controller kann hingegen wartende Konfigurationsupdates benötigen. Zu viele Offline-Warteschlangen verbrauchen Brokerressourcen, zu wenige können Befehle verpassen.
Will-Nachrichten bei unerwartetem Ausfall
Eine Letzter-Wille-Nachricht erlaubt einem Client, eine Nachricht zu definieren, die der Broker veröffentlichen soll, wenn der Client unerwartet getrennt wird. So können andere Systeme Geräteausfälle, Netzverlust oder abnormales Herunterfahren erkennen.
Ein Gerät kann beispielsweise eine Will-Nachricht in einem Status-Topic wie device/123/status setzen. Wenn das Gerät die Stromversorgung verliert, ohne eine normale Trennung zu senden, veröffentlicht der Broker die konfigurierte Offline-Nachricht.
Diese Funktion wird häufig in Überwachungsdashboards, Gerätezustandssystemen, industrieller Telemetrie, Gateway-Überwachung und Fernverwaltung von Assets verwendet. Sie bietet eine einfache Möglichkeit, eine abnormale Trennung anderen Systemteilen sichtbar zu machen.
Sicherheit und Zugriffskontrolle
Authentifizierung
Der Broker sollte die Identität des Clients prüfen, bevor er Zugriff erlaubt. Die Authentifizierung kann Benutzername und Passwort, Client-Zertifikate, Tokens, API-Zugangsdaten oder die Integration mit einem externen Identitätssystem verwenden.
Schwache Authentifizierung kann es unbefugten Geräten ermöglichen, falsche Daten zu veröffentlichen, sensible Topics zu abonnieren oder die Messaging-Umgebung zu stören.
Autorisierung
Nachdem die Identität geprüft wurde, sollte der Broker entscheiden, in welche Topics der Client veröffentlichen und welche Topics er abonnieren darf. Ein Sensor sollte keine Befehle an fremde Geräte veröffentlichen können. Eine Mandantenanwendung sollte keine Daten eines anderen Mandanten empfangen.
Topic-basierte Berechtigungen sind in Multi-Geräte-, Multi-Standort- und Multi-Mandanten-Bereitstellungen unverzichtbar.
Verschlüsselung
TLS-Verschlüsselung schützt Daten während der Übertragung zwischen Clients und Broker. Das ist wichtig, wenn Nachrichten über öffentliche Netze, Mobilfunknetze, Cloud-Verbindungen oder nicht vertrauenswürdige Infrastruktur laufen.
Verschlüsselung sollte mit Zertifikatsverwaltung, sicherer Schlüsselspeicherung und sorgfältiger Client-Bereitstellung kombiniert werden. Eine sichere Transportschicht hilft nicht, wenn Zugangsdaten in Firmware oder Konfigurationsdateien offengelegt werden.
Bereitstellungsmuster
Gerät zur Cloud
In vielen IoT-Systemen veröffentlichen Sensoren und Gateways Daten an einen Cloud-Broker. Cloud-Anwendungen speichern, visualisieren, analysieren und verarbeiten diese Daten anschließend. Dieses Modell ist typisch für Smart Buildings, Energiemanagement, Flottenüberwachung und Plattformen für Remote-Geräte.
Die wichtigsten Designaspekte sind Sicherheit, Netzwerkresilienz, Geräteidentität, Nachrichtenvolumen und Skalierung auf Cloud-Seite.
Aggregation über Edge-Gateway
Ein Edge-Gateway kann Daten lokaler Geräte sammeln und zusammengefasste oder gefilterte Daten an einen zentralen Broker veröffentlichen. Es kann auch Command-Topics abonnieren und Anweisungen an lokale Geräte weitergeben.
Das reduziert Bandbreite, verbessert die lokale Steuerung und ermöglicht einem Standort, bestimmte Funktionen auch dann fortzuführen, wenn die Cloud-Verbindung nicht verfügbar ist.
Lokaler Broker für Standortsysteme
Einige Bereitstellungen nutzen einen lokalen Broker in einer Fabrik, einem Gebäude, Labor, Campus oder Kontrollraum. Geräte und Anwendungen tauschen Daten lokal mit geringer Latenz und weniger Abhängigkeit von externen Netzen aus.
Ein lokaler Broker kann später ausgewählte Daten zu einer Cloud- oder Unternehmensplattform brücken. Dadurch erhalten Systemdesigner mehr Kontrolle über Datenfluss und Netzwerkabhängigkeit.
Anwendungen in vernetzten Systemen
Industrielle Überwachung
Fabriken und Versorgungsstandorte nutzen MQTT, um Gerätestatus, Sensordaten, Alarmmeldungen, Energiewerte, Temperaturmessungen, Vibrationsdaten und Produktionskennzahlen zu erfassen. Das Protokoll passt zu Umgebungen, in denen viele Geräte kleine Nachrichten an übergeordnete Plattformen senden.
Industrielle Bereitstellungen sollten Netzwerksegmentierung, Brokerredundanz, QoS-Auswahl, retained State und sichere Gerätebereitstellung berücksichtigen.
Smart Buildings
Gebäudesysteme können das Protokoll nutzen, um Beleuchtung, HLK, Zutrittskontrolle, Präsenzsensoren, Zähler, Aufzüge, Raumpanels und Dashboards zu verbinden. Die Topic-Struktur kann Gebäude-, Etagen-, Raum- und Gerätehierarchie abbilden.
Dadurch lassen sich Daten einfacher organisieren, und Automatisierungsregeln abonnieren nur relevante Ereignisse oder Zustände.
Energie und Messwesen
Energieplattformen können MQTT nutzen, um Zählerstände, Wechselrichterdaten, Batteriestatus, Lastinformationen und netzbezogene Telemetrie zu erfassen. Schlankes Messaging ist nützlich, wenn viele Geräte regelmäßig kleine Werte melden.
Da Energiesysteme Abrechnung, Steuerung oder Sicherheit beeinflussen können, sollten Authentifizierung und Nachrichtenintegrität sorgfältig behandelt werden.
Vernetzte Fahrzeuge und Mobilität
Fahrzeugplattformen, Ladestationen, Flottensysteme und Mobilitätsdienste können das Protokoll für Telemetrie, Standortupdates, Diagnose, Alarme und Remote-Control-Funktionen nutzen.
Mobile Netze können instabil sein, daher sind Sitzungsbehandlung, Reconnect-Logik und effizientes Nutzlastdesign wichtig.
Verbraucher- und Heimautomation
Heimautomationssysteme nutzen MQTT, um Sensoren, Schalter, Leuchten, Thermostate, Kameras, Hubs und Automatisierungsregeln zu verbinden. Das Publish/Subscribe-Modell macht es leicht, dass ein Sensorereignis mehrere Aktionen auslöst.
Für Heimbereitstellungen sind einfache Topic-Namen und eine sichere lokale Brokerkonfiguration wichtig, um Verwirrung und unbefugten Zugriff zu vermeiden.
Leistungs- und Skalierbarkeitsaspekte
Die Nachrichtengröße sollte angemessen bleiben. MQTT ist für kleine Nachrichten effizient, aber nicht ideal für sehr große Dateien oder schwere Medienströme. Große Nutzlasten können Brokerspeicher, Netzwerküberlastung und Verarbeitungsverzögerung erhöhen.
Das Topic-Design beeinflusst die Leistung. Zu viele breite Wildcard-Abonnements können die Brokerlast erhöhen, weil viele Nachrichten mit vielen Clients abgeglichen und an sie geliefert werden müssen. Eine klare Topic-Hierarchie hilft Systemen, berechenbarer zu skalieren.
Auch die Anzahl der Verbindungen ist ein Faktor. Ein Broker, der Tausende oder Millionen von Clients bedient, muss Keepalive-Verkehr, Authentifizierung, Sitzungsstatus, retained Messages, Warteschlangen und Netzwerkgrenzen verarbeiten. Skalierung kann Clustering, Load Balancing, Edge-Aggregation oder Topic-Partitionierung erfordern.
Die QoS-Stufe beeinflusst ebenfalls die Leistung. QoS 2 bietet stärkere Zustellsemantik, erzeugt aber mehr Paketaustausch. Für hochvolumige Telemetrie ist QoS 0 oder QoS 1 mit Logik auf Anwendungsebene oft praktischer.
Häufige Designfehler
Unklare Topic-Namen
Zufällige oder inkonsistente Topic-Namen erschweren die Verwaltung von Berechtigungen, Dashboards, Alarmen und Analysen. Vor einer groß angelegten Bereitstellung sollte ein Topic-Plan erstellt werden.
Retained Messages für Ereignisse verwenden
Retained Messages eignen sich am besten für den aktuellen Zustand. Werden sie für einmalige Ereignisse verwendet, können neue Abonnenten irregeführt werden, weil sie ein altes Ereignis erhalten, als wäre es gerade passiert.
Keine Duplikatbehandlung
QoS 1 kann Duplikate liefern. Anwendungen sollten Zeitstempel, Nachrichten-IDs, Sequenznummern oder idempotente Verarbeitung verwenden, wenn doppelte Nachrichten Probleme verursachen könnten.
Schwaches Credential-Management
Fest codierte gemeinsame Passwörter, wiederverwendete Client-IDs und ungeschützte Zertifikate können ernsthafte Sicherheitsrisiken verursachen. Jedes Gerät sollte eine verwaltbare Identität und einen Widerrufspfad haben.
Broker-Ausfall ignorieren
Der Broker ist zentral für die Architektur. Fällt er aus und gibt es keine Redundanz oder keinen Wiederherstellungsplan, kann die Kommunikation stoppen. Kritische Bereitstellungen sollten Clustering, Backup-Broker, Bridge-Design oder lokales Fallback-Verhalten berücksichtigen.
MQTT funktioniert gut, wenn Topics, Sitzungen, QoS, retained State, Sicherheit und Brokerkapazität gemeinsam geplant werden, statt als isolierte Einstellungen konfiguriert zu werden.
Wartung und Überwachung
Betriebsteams sollten Broker-CPU, Arbeitsspeicher, Verbindungszahl, Nachrichtenrate, Anzahl retained Messages, Abonnementzahl, wartende Nachrichten, Authentifizierungsfehler, getrennte Verbindungen und Netzwerklatenz überwachen.
Auch der Clientzustand sollte sichtbar sein. Wiederholte Reconnects, abgelaufene Sitzungen, doppelte Client-IDs, ungewöhnliche Veröffentlichungsraten und unerwarteter Topic-Zugriff können auf Gerätefehler oder Sicherheitsprobleme hinweisen.
Konfigurationssicherungen sind wichtig. Broker-Einstellungen, Zugriffskontrolllisten, Zertifikate, Topic-Richtlinien, Bridge-Einstellungen und retained-State-Verhalten sollten dokumentiert und wiederherstellbar sein.
Häufig gestellte Fragen
Kann MQTT über WebSocket funktionieren?
Ja. Viele Broker unterstützen MQTT über WebSocket, sodass browserbasierte Anwendungen und Web-Dashboards über webfreundliche Transportwege kommunizieren können.
Eignet es sich für große Video- oder Dateiinhalte?
In der Regel nicht als primäre Methode. Es eignet sich besser für kleine Nachrichten, Telemetrie, Ereignisse, Befehle und Statusupdates. Große Dateien werden oft über andere Protokolle übertragen, während eine Nachricht die Dateireferenz enthält.
Was passiert, wenn zwei Clients dieselbe Client-ID verwenden?
Viele Broker trennen den vorhandenen Client, wenn sich ein neuer Client mit derselben ID verbindet. Eindeutige Client-IDs sind wichtig für stabiles Sitzungsverhalten.
Kann ein Broker eine Verbindung zu einem anderen Broker herstellen?
Ja. Broker-Bridging oder Clustering kann verwendet werden, um ausgewählte Topics zwischen Standorten, Regionen, Edge-Gateways und Cloud-Plattformen auszutauschen, abhängig von den Fähigkeiten des Brokers.
Wie sollten Topic-Namen geplant werden?
Verwenden Sie eine konsistente Hierarchie nach Standort, System, Gerät, Datentyp und Funktion. Vermeiden Sie zufällige Namen, sensible Informationen in Topic-Pfaden und eine zu starke Abhängigkeit von breiten Wildcards.
