MQTT Basics

Das Message Queue Telemetry Transport (kurz MQTT) Protokoll wird für den Großteil der Kommunikation zwischen den verschiedenen Geräten genutzt. Der sowohl ISO- (ISO/IEC PRF 20922), als auch OASIS-Standard MQTT gilt mittlerweile als der de facto Standard des IoT und findet auch zunehmend Anwendung in industriellen Umgebungen. Das offene Nachrichtenprotokoll ist für die Machine-to-Machine-Kommunikation (M2M) konzipiert und hat einen kleinen Overhead, wodurch die Menge der transferierten Daten gering gehalten und das jeweilige Netzwerk nur wenig belastet wird. Diese ressourcenschonende Art der Kommunikation eignet sich bestens für die Kommunikation zwischen vielen Akteuren und ist daher prädestiniert für IoT-Szenarien, zu welchen auch der vorliegende Anwendungsfall – das vernetzte Testbed – zählt.

Die Übermittlung der Daten erfolgt ereignisgesteuert über einen zentralen Broker. Eine MQTT-Nachricht besteht immer aus mindestens dem Topic und der Payload, dem eigentlichen Inhalt der Nachricht. Der Inhalt der Payload ist für den Broker irrelevant, denn alle Daten werden BASE64-codiert übertragen. Topics hingegen werden genutzt um die Kommunikation zwischen den unterschiedlichen Teilnehmern (Clients) zu organisieren und haben eine hierarchische Struktur.

Diese Struktur orientiert sich häufig an der räumlichen Einordnung eines Kommunikationsteilnehmers. Die einzelnen Hierarchieebenen werden dabei durch Schrägstriche getrennt. Beispiele für mögliche Topics sind:

• haus14/R233/sensoren/temperatur
• deutschland/berlin/fahrzeuge/79b229f8-8cee-11e9-bc42-526af7764f64/geschwindigkeit
• labore/elektronik/2/netzteile/3/spannung

Der Name eines Topics ist prinzipiell frei wählbar. Andere Teilnehmer (Clients) können diese Topics abonnieren (subscribe) und empfangen jede Nachricht, die auf dem entsprechenden Topic veröffentlicht wird (publish), irrelevant von welchem Client diese stammt. Die Existenz eines Topics muss dem Broker nicht explizit mitgeteilt werden, sondern es können theoretisch auf jedem beliebigen Topic Nachrichten veröffentlicht werden. Eine Zugriffsverwaltung, die regelt, wer Nachrichten auf welchen Hierarchieebenen veröffentlichen oder abonnieren darf, kann und sollte brokerseitig implementiert werden, ist jedoch prinzipiell nicht Teil des MQTT-Protokolls (siehe Abschnitt „Sicherheit“ weiter unten im Text).

Ein Client kann entweder ein (oder mehrere) spezifische Topics abonnieren oder mit Hilfe von Wildcards ganze Teile der Hierarchie auf einmal abonnieren. Das Zeichen „+“ gilt dabei als Wildcard für eine einzelne Hierarchieebene und das Zeichen „#“, welches immer am Ende eines Topics stehen muss, gilt für alle folgenden Hierarchieebenen inkl. aller Unterebenen. Folgende Beispiele veranschaulichen die Funktionsweise der Wildcards in Topics des MQTT-Protokolls:

• haus12/+/jalousie 
• labore/logistik/#

Mehr Beispiele und weiterführende Informationen zur Verwendung von Topics und Wildcards finden Sie im entsprechenden Blogatrtikel von HiveMQ.

Optionale Eigenschaften eines MQTT-Clients

Persistent Session

Wenn ein Client die Verbindung zum Server verliert, gewollt oder ungewollt, sind normalerweise alle abonnierten Topics verschwunden und müssen neu hinzugefügt werden. Dieses Verhalten wird „Clean Session“ bezeichnet. In bestimmten Anwendungsfällen kann es allerdings sehr mühsam sein, zuvor abonnierte Topics wieder hinzuzufügen, wenn es sich z.B. um eine Vielzahl von Sensoren an unterschiedlichen Standorten handelt. Für diese Fälle gibt es die Möglichkeit einer „Persistent Session“. Hier werden nicht nur die Topics eines Clients vom Server vorgehalten, sondern auch alle Nachrichten mit dem QoS Level 1 und 2, die den Client seit dem letzten Verbindungsabbruch nicht erreicht haben.

Last Will & Testament

MQTT-Clients ist es möglich, dem Broker beim Verbinden eine „Last Will & Testament“ (LWT) -Nachricht bekannt zu geben. Diese Nachricht wird gesendet, falls der Client die Verbindung zum Server ungewollt verliert. Dadurch lässt sich z. B. eine Übersicht über den Verbindungsstatus eines Clients realisieren

Optionale Eigenschaften einer MQTT Nachricht

Quality of Service

MQTT bietet für die Spezifizierung der Semantik des Nachrichtentransfers drei Level von Quality of Service (QoS) an. Dafür sind im Header der Nachricht zwei Bit reserviert, die bei jeder Nachricht das Level angeben. Die Bedeutung der unterschiedlichen Level ist wie folgt:

• Level 0: Die Nachricht wird einmalig gesendet und anschließend verworfen. Damit ist nicht sichergestellt, dass diese ankommt.
• Level 1: Es wird sichergestellt, dass die Nachricht mindestens einmal beim jedem Subscriber ankommt. Es kann aber vorkommen, dass die Nachricht mehrfach von einem Subscriber empfangen wird.
• Level 2: Im höchsten Level der QoS wird sichergestellt, dass die Nachricht genau einmal von den Subscribern empfangen wird.

Je höher das Level der QoS, desto höher ist die benötigte Servicezeit des Brokers für die Nachrichtenverteilung. Die Verwendung des jeweiligen QoS-Levels hängt vom Einsatzfall ab und sollte nicht pauschal als Restriktion für alle vorgegeben werden.

Retained Messages

Nachrichten können vom sendenden Client als „Retained Message“ (aufbewahrte Nachrichten) markiert werden. Diese werden vom Broker zwischengespeichert und jeder Client, der das Topic mit der Retained Message abonniert, bekommt automatisch die letzte Nachricht mit einer Retained Kennzeichnung. Bei Temperaturdaten kann es beispielsweise sinnvoll sein Retained Messages zu aktivieren, damit ein neuer Subscriber nicht auf die nächste Änderung warten muss bis er den aktuellen Status empfängt, sondern sofort die letzte Meldung erhält.

Sicherheit

Da das MQTT Protokoll auf dem TCP/IP Stack basiert, besteht die Möglichkeit einer standardisierten Verschlüsselung auf Transportebene mit Hilfe von TLS/SSL. Um diese Art der Verschlüsselung zu nutzen, benötigt der MQTT Broker ein X509 Zertifikat, bevorzugt von einer offiziellen Zertifizierungsstelle signiert, um die spätere Verifizierung des Servers durch den Client zu erleichtern. Des Weiteren wird für die verschlüsselte Kommunikation ein separater Listener auf einem extra Port erstellt, standardmäßig ist dieser Port 8883. Nun können Clients, die die Möglichkeit der verschlüsselten Kommunikation via TLS/SSL unterstützen, über diesen Port verschlüsselt mit dem MQTT Broker Nachrichten austauschen.

Eine weitere Möglichkeit die Kommunikation mit dem MQTT Broker abzusichern besteht darin, durch einen Authentifizierungsmechanismus die Nutzer zu begrenzen. Das Protokoll verfügt dafür über Nutzernamen und Passwort Felder in der „CONNECT“ Nachricht. Der Abgleich des Nutzernamens mit dem Passwort erfolgt brokerseitig, eine Methodik dafür ist nicht standardisiert und muss vom Administrator händisch eingerichtet werden. Hierbei empfiehlt es sich ausdrücklich auf standardisierte, öffentlich zugängliche Sicherheitsmechanismen zurückzugreifen und keine eigenen Mechanismen zu programmieren!

Eine weitere Möglichkeit der brokerseitigen Absicherung der MQTT Kommunikation besteht in der Erstellung von Autorisierungskonzepten. Diese Autorisierung kann jede erdenkliche Form annehmen, z. B. nutzerspezifisch, nutzergruppenspezifisch oder zertifikatsbasierend. Die Implementierung der Logik liegt erneut vollkommen frei in der Hand der Administratoren.

Abschließend besteht noch die Möglichkeit der Nachrichtenverschlüsselung auf Applikationsebene. Diese ist abhängig von den jeweiligen Clients und kann unabhängig vom Broker von jedem Client eingesetzt werden.

Es ist hierbei, wie bei allen übrigen Sicherheitsmechanismen, zu beachten, dass jegliche Erhöhung der Sicherheit immer zu Performanceeinbußen führt. Es kann daher Sinn machen, bei besonders zeitkritischen Anwendungsfällen komplett auf Sicherheitsmechanismen zu verzichten um die Leistung des Gesamtsystems zu optimieren. Es empfiehlt sich in jedem Fall die Besonderheiten des jeweiligen Anwendungsfalles zu betrachten und die Sicherheitsanforderungen individuell zu bestimmen.