MQTT steht für „Message Queuing Telemetry Transport“. Es ist ein offenes Nachrichtenprotokoll für Fälle, bei denen Clients einen kleinen Code-Footprint brauchen und mit unzuverlässigen Netzwerken oder Netzwerken mit eingeschränkten Bandbreitenressourcen verbunden sind. Hauptsächlich wird es für Maschine-zu-Maschine-Kommunikation (M2M) oder Verbindungsarten wie beim Internet der Dinge eingesetzt.
MQTT wurde ursprünglich 1999 von Dr. Andy Stanford-Clark und Arlen Nipper entwickelt. Anfangs sollte die Kommunikationsmethode Monitoring-Geräten in der Öl- und Gasindustrie ermöglichen, ihre Daten an Remote-Server zu senden. Oftmals wurden solche Monitoring-Geräte an Remote-Standorten verwendet, wo jede Art von Festnetz-, Kabel- oder Funkverbindung schwierig oder unmöglich herzustellen war. Zu dieser Zeit war Satellitenkommunikation in solchen Fällen die einzige Möglichkeit, die sehr teuer war und aufgrund der verbrauchten Datenmenge berechnet wurde. Mit Tausenden von Sensoren im Einsatz wurde eine Kommunikationsform benötigt, die Daten zuverlässig bereitstellte und gleichzeitig minimale Bandbreite beanspruchte.
MQTT wurde 2013 als Open Source unter der „Organization for the Advancement of Structured Information Standards“ (OASIS) standardisiert. OASIS verwaltet den MQTT-Standard bis heute.
MQTT läuft auf TCP/IP mit einer PUSH/SUBSCRIBE-Topologie. In der MQTT-Architektur gibt es zwei Arten von Systemen: Clients und Broker. Ein Broker ist ein Server, mit dem die Clients kommunizieren. Der Broker empfängt die Kommunikation der Clients und sendet sie weiter zu anderen Clients. Clients kommunizieren nicht direkt miteinander, sondern verbinden sich mit dem Broker. Jeder Client kann entweder ein Veröffentlicher, ein Abonnent oder beides sein.
MQTT ist ein ereignisgesteuertes Protokoll. Dabei findet keine periodische oder dauernde Datenübertragung statt, wodurch die Übertragungen auf einem Minimum gehalten werden. Ein Client veröffentlicht nur, wenn Informationen zum Versenden vorhanden sind, und ein Broker sendet Informationen nur zu Abonnenten, wenn neue Daten eintreffen.
Eine weitere Maßnahme, um die Übertragungen bei MQTT minimal zu halten, besteht in einem eng definierten, kleinen Nachrichtenaufbau. Jede Nachricht hat einen festen Header von nur 2 Bytes. Es kann ein optionaler Header verwendet werden, durch den die Nachricht aber größer wird. Die Nachrichtennutzlast ist auf nur 256 MB beschränkt. Drei unterschiedliche „Quality of Service“-Stufen (QoS) geben Netzwerkdesignern die Möglichkeit, zwischen minimaler Datenübertragung und maximaler Zuverlässigkeit zu wählen.
- QoS 0: für minimale Datenübertragung. Bei dieser Stufe wird jede Nachricht einmal ohne Bestätigung an einen Abonnenten gesendet. Es besteht keine Möglichkeit zu wissen, ob Abonnenten die Nachricht erhalten haben. Diese Methode wird manchmal als “fire and forget” („abschicken und vergessen“) oder als “at most once delivery” („maximal einmalige Zustellung“) bezeichnet. Da bei dieser Stufe angenommen wird, dass die Zustellung erfolgt ist, werden Nachrichten zur Zustellung an nicht verbundene Clients, die sich später wieder verbinden, nicht gespeichert.
- QoS 1: Der Broker versucht, die Nachricht zuzustellen und wartet dann auf eine Bestätigung vom Abonnenten. Wenn innerhalb eines bestimmten Zeitraums keine Bestätigung empfangen wird, wird die Nachricht erneut gesendet. Mit dieser Methode kann der Abonnent die Nachricht mehr als einmal erhalten, wenn der Broker die Bestätigung des Abonnenten nicht rechtzeitig empfängt. Das wird manchmal als „mindestens einmalige Zustellung“ beschrieben.
- QoS 2: Client und Broker verwenden einen vierstufigen Handshake, um sicherzustellen, dass die Nachricht genau einmal empfangen wird. Das wird manchmal als „genau einmalige Zustellung“ beschrieben.
In Situationen, bei denen die Kommunikation zuverlässig, aber eingeschränkt ist, kann QoS 0 die beste Option sein. In Situationen, bei denen die Kommunikation unzuverlässig ist, jedoch weniger begrenzte Verbindungsressourcen vorhanden sind, wäre QoS 2 die beste Option. QoS 1 bietet in gewisser Weise das Beste aus beiden Welten, jedoch muss dafür die Anwendung, die die Daten empfängt, mit Duplikaten umgehen können.
Bei QoS 1 und QoS 2 werden Nachrichten für Clients, die offline sind und eine dauerhafte Sitzung eingerichtet haben, gespeichert oder in eine Warteschlange gestellt. Diese Nachrichten werden erneut gesendet (entsprechend der jeweiligen QoS-Stufe), sobald der Client wieder online ist.
Nachrichten innerhalb von MQTT werden als Themen veröffentlicht. Themen werden in einer Hierarchie strukturiert, in der der Schrägstrich (/) als Trennzeichen verwendet wird. Diese Struktur ähnelt der Verzeichnisstruktur eines Computerdateisystems. Mit einer Struktur wie Sensoren/ÖlundGas/Druck/ kann ein Abonnent spezifizieren, dass nur Daten dorthin geschickt werden sollen, die von Kunden kommen, die Nachrichten zum Thema Druck veröffentlichen, oder im weiteren Sinne vielleicht alle Daten von Kunden, die Nachrichten zu jedem Thema innerhalb des Bereichs Sensoren/ÖlundGas veröffentlichen. Themen werden nicht explizit in MQTT erstellt. Wenn ein Broker Daten empfängt, die zu einem gegenwärtig nicht existierenden Thema veröffentlicht werden, wird das Thema einfach erstellt, und Clients können das neue Thema abonnieren.
Um den Speicherbedarf niedrig zu halten, werden empfangene Nachrichten nicht im Broker gespeichert, soweit sie nicht mit dem Flag „zurückgehalten“ gekennzeichnet werden. Dies wird als zurückgehaltene Nachricht bezeichnet. Benutzer, die empfangene Nachrichten speichern möchten, müssen dies an anderer Stelle außerhalb des MQTT-Protokolls tun. Dazu gibt es eine Ausnahme.
Da es sich um ereignisgesteuertes Protokoll handelt, ist es möglich – sogar wahrscheinlich – dass ein Abonnent sehr wenig Nachrichten zu einem bestimmten Thema erhält – sogar über einen längeren Zeitraum. In der zuvor erwähnten Themenstruktur werden Nachrichten zum Thema Druck vielleicht nur gesendet, wenn ein Sensor feststellt, dass der Druck einen bestimmten Wert überschritten hat. Angenommen, dass das vom Sensor überwachte Objekt nicht oft ausfällt, könnte es Monate oder sogar Jahre dauern, bevor ein Client eine Nachricht zu diesem Thema veröffentlicht.
Um sicherzustellen, dass ein neuer Abonnent die Nachrichten zu einem Thema erhält, können Broker die letzte zu jedem Thema gesendete Nachricht beibehalten. Dies wird als zurückgehaltene Nachricht bezeichnet. Jedes Mal, wenn ein neuer Client ein Thema abonniert oder ein bestehender Client wieder online geht, wird die zurückgehaltene Nachricht an die Abonnenten gesendet. Dadurch wird sichergestellt, dass das Abonnement aktiv ist und die neuesten Informationen hat.
Bei unzuverlässiger Kommunikation ist es möglich, dass ein Veröffentlicher ohne Warnung vom Netzwerk getrennt wird. Ein Veröffentlicher kann eine Nachricht aufzeichnen, die an Abonnenten gesendet wird, falls der Veröffentlicher unerwartet getrennt wird. Dabei handelt es sich um einen so genannten letzten Willen und Testament. Diese Nachricht wird beim Broker zwischengespeichert und an Abonnenten gesendet, falls der Veröffentlicher unsachgemäß getrennt wird. Gewöhnlich enthält eine solche Nachricht Informationen, anhand derer der getrennte Veröffentlicher identifiziert werden kann, damit entsprechende Maßnahmen ergriffen werden können.
Um das Protokoll klein zu halten, gibt es bei jeder Kommunikation nur vier mögliche Aktionen: veröffentlichen, abonnieren, abbestellen oder pingen.
- Veröffentlichen: Hierbei wird ein Datenblock gesendet, der die zu sendende Nachricht enthält. Diese Daten sind für jede Implementierung spezifisch, könnten aber etwas so Einfaches wie eine Ein/Aus-Angabe oder ein Wert eines bestimmtes Sensors wie z. B. Temperatur, Druck usw. sein. Für den Fall, dass das Thema, zu dem die Veröffentlichung erfolgen soll, nicht existiert, wird es im Broker erstellt.
- Abonnieren: Ein Client wird zu einem Abonnenten eines Themas. Themen können spezifisch oder über Platzhalter abonniert werden, wodurch Abonnements zu einem ganzen Themenbereich oder einem Teil eines Themenbereichs möglich sind. Um sich zu abonnieren, sendet ein Client ein SUBSCRIBE-Paket und empfängt im Gegenzug ein SUBACK-Paket. Wenn für das Thema eine zurückgehaltene Nachricht vorliegt, erhält der neue Abonnent diese Nachricht ebenfalls.
- PINGEN: Ein Client kann den Broker anpingen. Vom Abonnenten wird ein PINGREQ-Paket und als Antwort ein PINGRESP-Paket gesendet. Mit Pings kann sichergestellt werden, dass die Verbindung noch besteht und dass die TCP-Sitzung nicht durch andere Netzwerkgeräte wie einen Router oder Gateway unerwartet geschlossen wurde.
- TRENNEN: Ein Abonnement oder Veröffentlicher kann eine DISCONNECT-Nachricht an den Broker senden. Diese Nachricht informiert den Broker, dass er für einen Abonnenten keine Nachrichten mehr senden oder in eine Warteschlange stellen muss und dass er keine Daten mehr von einem Veröffentlicher empfangen wird. Dank dieser Art Schließung kann der Client sich mit derselben Client-Identität wie zuvor neu verbinden. Wenn ein Client die Verbindung trennt, ohne eine Trennungs-Nachricht zu senden, wird sein letzter Wille und Testament an die Abonnenten gesendet.
Ursprünglich verfolgte das MQTT-Protokoll das Ziel, die kleinste und effizienteste Datenübertragung über teure, unzuverlässige Kommunikationsleitungen zu ermöglichen. Daher war die Sicherheit bei der Entwicklung und Implementierung von MQTT kein Hauptanliegen.
Es sind jedoch einige Sicherheitsoptionen verfügbar, die auf Kosten von mehr Datenübertragung und einem größeren Speicherbedarf gehen.
- Netzwerksicherheit: Wenn das Netzwerk selbst gesichert werden kann, ist die Übertragung unsicherer MQTT-Daten irrelevant. In diesem Fall müssten Sicherheitsprobleme im Netzwerk selbst auftreten – vielleicht durch einen böswilligen Akteur oder eine andere Form des Eindringens in das Netzwerk.
- Benutzername und Passwort: MQTT lässt Benutzernamen und Passwörter für einen Client zu, um eine Verbindung mit einem Broker herzustellen. Um den Overhead leicht zu halten, werden Benutzernamen und Passwörter leider als Klartext übertragen. 1999 war dies mehr als ausreichend, denn es wäre ungeheuer schwierig gewesen, eine Satellitenkommunikation wegen eines im Grunde unwichtigen Sensorwerts abzufangen. Heute ist es jedoch einfach, viele Arten von drahtloser Netzwerkkommunikation abzufangen, und daher ist eine derartige Authentifizierung alles andere als nutzlos.
Für viele Anwendungsfälle sind Benutzername und Passwort nicht als Schutz vor böswilligen Akteuren erforderlich, sondern um unbeabsichtigte Verbindungen zu vermeiden. - SSL/TLS: Die offensichtliche Lösung zur Sicherung von Übertragungen zwischen Clients und Brokern ist die Implementierung von SSL/TLS, das auf TCP/IP läuft. Leider wird der ansonsten leichten Kommunikation dadurch ein beträchtlicher Overhead auferlegt.
Am 3. April 2019 hat OASIS den offiziellen MQTT-Standard 5.0 veröffentlicht.
Wichtige neue Merkmale von MQTT 5.0
- Ursachencodes: Ursprünglich ergriff MQTT einfach keine Maßnahme, wenn ein Fehler vorlag. Der Fehler selbst war der einzige Fehlercode. Bei Version 5.0 unterstützen Bestätigungen jetzt Rückgabecodes, die eine benutzerfreundliche Ursache für einen Fehler angeben können. Natürlich wird der Speicherbedarf durch Rückgabecodes etwas erhöht.
- Gemeinsam genutzte Abonnements: Wenn zu viele Abonnenten zu einem bestimmten Thema auf einem Broker vorhanden sind, können Belastungsprobleme verursacht werden. Durch gemeinsam genutzte Abonnements kann die Belastung über mehrere Clients hinweg ausgeglichen werden.
- Nachrichtenverfall: Nachrichten können so eingerichtet werden, dass sie gelöscht werden, wenn sie innerhalb einer bestimmten Frist nicht zugestellt werden. Dadurch wird verhindert, dass alte, nicht mehr aktuelle Nachrichten an Abonnenten gesendet werden, die während eines bestimmten Zeitraums getrennt waren.
- Themenalias: Die Namen der Themen selbst können so lang werden, dass sie den geringen Speicherbedarf des Protokolls beeinträchtigen. Themenstrings können jetzt durch eine einzige Zahl ersetzt werden, wenn dasselbe Thema wiederholt verwendet wird.
Zwei kostenlose Whitepaper für Sie
Whitepaper I
In der modernen industriellen IT brauchen die richtigen Teams die richtigen Daten. Unser Whitepaper zeigt, wie Sie ein ganzheitliches Monitoring aufsetzen und Elemente aus IT, OT und IIoT in Ihr Dashboard bringen.
Whitepaper II
Unser zweites Whitepaper bietet Inspirationen und Ideen für Dashboards, die IT-, OT- und IIoT-Daten enthalten – übersichtlich an einem Ort. Wir zeigen, wie konvergente industrielle Dashboards aussehen!