Kommunikation ist alles

MQTT 5 – Das sind die Neuerungen für das IoT-Standardprotokoll
Keine Kommentare

MQTT hat sich zum Kommunikationsstandard für die Vernetzung von Geräten, Applikationen und Enterprise Systemen über das Internet etabliert. Seit Kurzem ist die Version 5 des IoT Protokolls verfügbar. Grund genug, die Verbesserungen und Neuerungen im Detail zu betrachten.

MQTT ist das Standardprotokoll für Messaging über das Internet zwischen mobilen Endgeräten, Backend-Systemen und IoT-Geräten aller Art (von einzelnen Sensoren bis zu Connected Cars). Eine der Besonderheiten des Nachrichtenprotokolls ist die bandbreitenschonende Push-Kommunikation aller Teilnehmer und die Einfachheit in der Implementierung und Nutzung von Clients. So sind für alle gängigen Programmiersprachen produktionsreife Implementierungen verfügbar. Bisher wird in den meisten Fällen die im Jahr 2014 veröffentlichte Version MQTT 3.1.1 umgesetzt. Mit MQTT 5 ist nun nach vier Jahren Spezifikationsarbeit der Nachfolger verfügbar.

Funktionsweise

Die Architektur von MQTT basiert auf dem Publish/Subscribe-Muster. Die Produzenten von Nachrichten (Publisher) und die Empfänger der Nachrichten (Subscriber) sind mittels einem MQTT Broker entkoppelt. Der MQTT Broker ist verantwortlich, eine Nachricht den richtigen Empfängern sofort oder nach einer Neuverbindung des Clients zuzustellen, und er verwaltet die Sessions der verbundenen und nicht verbundenen Clients. Der Broker ist in der Lage, eine einzelne, von einem Publisher versendete Nachricht, an eine Vielzahl von Subscribern gleichzeitig zu versenden. Sowohl sendende als auch empfangende Clients bleiben ständig mittels einer stehenden TCP-Verbindung mit dem MQTT Broker verbunden, weshalb der MQTT Broker eine Nachricht im Push-Verfahren ohne Verzögerung an Clients ausliefern kann. Abbildung 1 zeigt die prinzipielle Funktionsweise des Publish-/Subscribe-Mechanismus. Mehrere Geräte können eine Subscription am MQTT Broker erstellen und signalisieren über sogenannte Topics, an welchen Nachrichten sie jeweils interessiert sind. Der Broker verwaltet die Subscriptions der einzelnen Clients und ist in der Lage, neu ankommende Nachrichten direkt weiterzuleiten. Neben Open Source MQTT Brokern wie mosquitto gibt es hochskalierbare und erweiterbare Broker für den professionellen Projekteinsatz wie HiveMQ.

MQTT 5

Abb. 1: Der Publish-/Subscribe-Mechanismus

Anwendungsfälle und Neuerungen

Seit 1999, dem Jahr in dem die erste MQTT-Version entwickelt wurde, hat sich in der Welt der Softwareentwicklung und der Vernetzung von Systemen einiges getan. Interessanterweise sind die Grundprinzipien von MQTT im Zeitalter des Internet of Things aktueller denn je. Typische Anwendungsfälle von MQTT sind:

  • Push-basierte Messaging-Kommunikation
  • Leichtgewichtige Vernetzung von Backend-Systemen und IoT-Geräten
  • Kommunikation über unzuverlässige Kanäle wie etwa Mobilfunknetzwerke
  • Entkoppelte Kommunikation aller Teilnehmer über Publish/Subscribe
  • Bandbreitenschonende Übertragung von Daten

Dennoch haben sich in den letzten Jahren vermehrt Anforderungen in Projekteinsätzen herauskristallisiert, welche nun mit MQTT 5 leichter abgedeckt werden können. Das Spezifikationskommittee für die neue MQTT-Version hat sich daher die folgenden Ziele für Verbesserungen gesteckt:

  • Vereinfachungen des Protokolls für hochskalierbare Systeme
  • Verbesserte Fehlerbehandlung
  • Erweiterbarkeit des Protokolls
  • Vereinfachungen für die Implementierung von eigenen Client-Bibliotheken
  • Identifikation und Formalisierung von gängigen Kommunikationsmustern
  • Verbesserte Authentifizierungs- und Autorisierungsmechanismen

Grundlegende Änderungen im Protokoll

Die neue Version des IoT-Protokolls ist eine logische Weiterentwicklung zum Vorgänger. Die bekannten Charakteristiken von MQTT – einfach, skalierbar, bandbreitenschonend und sicher – bleiben erhalten und ein Update bestehender Geräte und Applikation von Version 3.1.1 auf Version 5 sollte sehr einfach sein, da Broker wie HiveMQ eine Kompatibilitätsschicht der verschiedenen Protokollversionen anbietet.

Eine der lang erwarteten und großen Änderungen im Protokoll ist die Möglichkeit, Key-Value Header für MQTT-Pakete zu verwenden. Ähnlich wie mit HTTP lässt sich so das Nachrichtenprotokoll auf eigene Bedürfnisse erweitern. Viele der neu spezifizierten Funktionalitäten werden mit standardisierten Header-Feldern umgesetzt.

Ein Kritikpunkt an den älteren Versionen von MQTT war, dass Fehlerfälle meist zu einem Verbindungsabbruch führten, sodass sich Clients neu zum Broker verbinden mussten. Das war etwa der Fall, falls eine Applikation Nachrichten an Topics versendete, für die sie keine Berechtigungen hatte. Mit MQTT 5 wurden sogenannte Negative Acknowledgements eingeführt, welche nun für fast alle Antwortpakete vorhanden sind. So ist es z.B. möglich, einen Client sowohl beim Verbindungsaufbau als auch beim subscriben oder publishen von Nachrichten genau mitzuteilen, warum eine Aktion abgelehnt wurde oder welcher Fehler aufgetreten ist. So kann dann auf Applikations-Seite darauf reagiert werden.

Besonders nützlich ist hierbei auch das neu eingeführte serverseitige Paket MQTT DISCONNECT. In älteren Versionen war es Clients vorbehalten, bei einem ordnungsgemäßen Herunterfahren ein solches DISCONNECT-Paket an den Server zu senden, um mitzuteilen, dass der Verbindungsabbau gewollt war. Falls der Broker mit MQTT 5 die Verbindung zu einem Client trennen möchte (z.B. weil der Administrator eine Neuverbindung erzwingen möchte), so sendet der Server nun ein DISCONNECT-Paket mit dem entsprechendem Fehlercode, welches der Client interpretieren kann, bevor die TCP-Verbindung vom Server getrennt wird.

API Summit 2018

From Bad to Good – OpenID Connect/OAuth

mit Daniel Wagner (VERBUND) und Anton Kalcik (business.software.engineering)

Neue Features

Neben den grundlegenden Protokolländerungen gibt es eine Reihe an neuen Funktionalitäten, die die Verwendung von MQTT in typischen IoT-Anwendungsfällen erleichtert. Die Feature-Highlights von MQTT 5 sind:

Shared Subscriptions

Prinzipiell empfängt ein MQTT Client alle Nachrichten für jedes subskribierte Topic. Speziell bei Anwendungsfällen, in denen eine hohe Anzahl an Nachrichten empfangen werden soll (z.B. für Backend Applikationen oder Big Data Applikationen), kann es sein, dass ein einzelner Konsument mit der Menge an Nachrichten überfordert ist. Um die Last auf mehrere Subscriber aufzuteilen, wurden hierfür Shared Subscriptions spezifiziert. Damit ist es möglich, dass mehrere MQTT Clients sich den Nachrichten-Strom aufteilen und so nur einen Teil der Gesamtmenge einer Subscription erhalten. Anders gesagt handelt es sich bei dem Feature um ein Client Loadbalancing. Zur Laufzeit können neue MQTT Clients sich einer Shared Subscription anschließen oder diese verlassen, was ein dynamisches hoch- und herunterskalieren der Konsumenten erlaubt. Für MQTT 3.1.1 ist dieses Feature bereits seit längerer Zeit als proprietäre Erweiterung mit dem Enterprise Broker HiveMQ verfügbar, mit MQTT 5 wurde diese Funktionalität nun standardisiert.

Session Expiry

Ein großer Vorteil bei der Verwendung von MQTT ist, dass der MQTT Broker eine Session für einen Client vorhalten kann, wenn die Funktionalität beim Verbindungsaufbau angefordert wird. Wenn also ein MQTT Client für eine bestimmte Zeit nicht mit dem Broker verbunden sein sollte, hält der Broker Sessioninformationen über den Client vor, wie etwa die Subscriptions und alle verpassten Nachrichten. Sobald die Client-seitige MQTT-Applikation sich wieder mit dem Broker verbindet, werden alle verpassten Nachrichten direkt ausgeliefert, als ob der Verbindungsabbruch nie passiert wäre.

Problematisch wird dieses Verhalten, wenn eine Session niemals fortgesetzt wird und so die Informationen und Nachrichten auf ewig vom Broker vorgehalten werden. Mit MQTT 5 wurde eine standardisierte Möglichkeit geschaffen, die Session nach einem bestimmtem Zeitintervall ablaufen zu lassen, so dass der Broker die Ressourcen dieser nicht mehr benötigten Sessions wieder freigegeben kann.

Message Expiry

Neben der Session Expiry wurde auch eine sogenannte Message Expiry neu in den Protokollstandard eingeführt. Es gibt häufig Anwendungsfälle, in denen eine Nachricht nur eine begrenzte Gültigkeit hat. Man stelle sich eine Staumeldung vor, die an mehrere Fahrzeuge mittels MQTT versendet werden soll. Wenn ein Fahrzeug länger offline war und sich nun nach einiger Zeit neu am Broker anmeldet, so ist die Staunachricht unter Umständen schon veraltet und es wäre verschwendete Bandbreite, diese Nachricht noch an den MQTT Client auszuliefern. Der Publisher einer Nachricht kann daher eine maximale Gültigkeitsdauer beim Versenden angeben, sodass der Broker diese nicht mehr an Clients ausliefert, sobald diese Nachricht an Gültigkeit verloren hat.

Erweiterte Mechanismen zur Authentifizierung

Sicherheit ist eine der wichtigsten Herausforderungen im Internet of Things. Dazu gehören neben einer Transportverschlüsselung mittels TLS auch geeignete Authentifizierungs- und Autorisierungsmaßnahmen. Neben X509-Client-Zertifikaten oder OAuth 2.0 sind auch häufig klassische User Credentials mit MQTT im Einsatz. Mit dem in MQTT 5 neu eingeführtem AUTH-Paket wird nun auch das SASL (Simple Authentication and Security Layer) Framework mit Challenge/Response-Authentifizerungsmechanismen wie SCRAM unterstützt. MQTT bietet jedoch nur die Mechanismen zur Implementierung dieser Mechanismen an. Die konkrete Client-Bibliothek und der Broker müssen die entsprechenden Authentifizierungsprotokolle unterstützen bzw. Erweiterungsmöglichkeiten dafür anbieten. Für Java-basierte Applikationen lässt sich z.B. die Bibliothek MQTT Bee erweitern.

Weitere Features

Neben den genannten Funktionalitäten bietet MQTT 5 eine Reihe an weiteren Verbesserungen an, unter anderem:

  • Request/Response-Funktionalität, um Ende-zu-Ende-Acknowledgements auf Applikationsebene umzusetzen.
  • Flow-Control-Mechanismen, um die Anzahl an gleichzeitigen Nachrichten für einzelne Clients zu beschränken, z.B. zum Zwecke des Schutzes langsamer konsumierenden Clients vor einer Flut an Nachrichten.
  • Client- und serverseitige Indikation einer maximal unterstützten Nachrichtengröße, womit sichergestellt werden kann, dass keine Nachrichten ausgeliefert werden, die eine bestimmte Größe überschreiten.
  • Funktionalität zum serverseitigen Überschreiben von Client-Parametern, wie etwa des Client Identifiers oder dem Keep-Alive-Wert für Heartbeats.
  • Einer Topic-Alias-Funktionalität, bei der ein langer Topic-Name nur einmal an den Broker gesendet werden muss und in zukünftigen Nachrichten ein kurzer Alias verwendet werden kann, um Bandbreite zu sparen.

Eine detaillierte Übersicht aller neuen Protokoll-Features ist auf der Homepage von MQTT 5 zu finden.

Erweiterbarkeit des Protokolls

MQTT 5 ist mit der Spezifizierung der User Properties, also applikationsspezifischen Headern, nun deutlich erweiterbarer als ältere Versionen. Jede Art von Metadaten kann nun neben den reinen Nutzdaten an ein MQTT-Paket angehängt werden. Diese Erweiterungen bieten in der Praxis, ähnlich wie mit HTTP, viele Möglichkeiten der Integration mit externen Systemen, beispielsweise die Anreicherung von Metadaten direkt am Load Balancer. Vor allem lässt sich jedoch ein eigenes, applikationsspezifisches Protokoll auf Basis von MQTT für eigene Projekte umsetzen, indem das MQTT-Protokoll um benötigte Header erweitert wird. Mittels eines Plug-in-Systems erweiterbare MQTT Broker wie HiveMQ wären mit eigenen Erweiterungen in der Lage, die projektspezifischen Protokoll-Header (wenn nötig) auszuwerten und entsprechende Logik auszuführen.

Fazit

MQTT 5 ist der lang erwartete Nachfolger von MQTT 3.1.1 und ist sich dabei seiner Grundphilosophie treu geblieben, indem es weiterhin leichtgewichtig, skalierbar, einfach und sicher bleibt, jedoch auch mit vielen nützlichen Erweiterungen punktet. Damit der Umstieg von MQTT 3.1.1 auf MQTT 5 leicht vonstattengehen kann, bieten manche Broker eine Kompatibilitätsschicht an, um gleichzeitig MQTT 3.1.1 und MQTT 5 Clients betreiben zu können. Bisher hat sich MQTT als Standardprotokoll für das IoT etabliert. Mit Version 5 sind nun alle Kritikpunkte der vorherigen Versionen beseitigt und es bietet neue Funktionalitäten, welche typische IoT-Anwendungsfälle noch leichter umsetzen lässt.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -