MQTT: Das meistgenutzte Messaging-Protokoll im IoT

• Was ist das MQTT-Protokoll?
• Wer hat MQTT entwickelt?
• Wem gehört MQTT?
• Was ist die neueste Version von MQTT?
• Was sind die Vorteile von MQTT?
• Wo wird MQTT eingesetzt?
• Wie funktioniert MQTT?
• Was sind die Unterschiede zwischen MQTT und MQTT-SN?
• Wie gewährleistet MQTT die Dienstgüte (QoS)?
• Wie wird bei MQTT die Sicherheit umgesetzt?
• Fazit

Das Internet der Dinge (IoT) ist in den letzten Jahren explosionsartig gewachsen. Das hat zu einer einzigartigen Konstellation in unserer Geschichte geführt: Wir sind von einer steigenden Zahl vernetzter, teils unsichtbarer Geräte umgeben, die ständig daran arbeiten, unsere Umwelt sicherer und komfortabler zu machen – und unseren Alltag effizienter zu gestalten.

Allein können diese Geräte jedoch nur wenig ausrichten. Denn ihr Potenzial wird nur dann voll ausgeschöpft, wenn sie miteinander kommunizieren. Aus diesem Grund ist ein leichtes, skalierbares Kommunikationsprotokoll vonnöten, das in kostengünstigen Geräten implementiert werden kann, die nicht immer über zuverlässige Verbindungen arbeiten.

Ein solches Protokoll existiert bereits seit Mitte der 1990er Jahre und wartet nur auf seinen Einsatz: MQTT wurde entwickelt, um den Anforderungen der Ölindustrie gerecht zu werden. Es wurde schnell zu einem De-facto-Standard für die Nachrichtenübermittlung im Internet der Dinge, der für ganz unterschiedliche Anwendungen verwendet wird, zum Beispiel die Steuerung einer Fahrzeugflotte oder das Chatten mit Freunden.

In diesem Artikel erklären wir, was MQTT ist, wie es funktioniert, wo es eingesetzt wird und warum es für das IoT-Segment so attraktiv ist.

Was ist das MQTT-Protokoll?

MQTT ist ein Protokoll die Übermittlung von Nachrichten von einer Maschine zur anderen (M2M, Machine to Machine), dessen Hauptmerkmale Leichtigkeit und Einfachheit sind. Es wurde für den Einsatz in Geräten mit begrenzten Ressourcen und eingeschränkter Bandbreite entwickelt, die über unzuverlässige Verbindungen oder mit hoher Latenzzeit kommunizieren.

Diese Eigenschaften sind es, die es für Anwendungen im Internet der Dinge ideal machen: z. B. die Fernüberwachung von Instrumenten oder den Nachrichtenaustausch zwischen mobilen Geräten, bei denen die Bandbreite oder die Stromversorgung begrenzt bzw. kostspielig sind.

Wer hat MQTT entwickelt?

MQTT wurde 1999 von Andy Stanford-Clark (von IBM) und Arlen Nipper (von Eurotech, Inc.) entwickelt. Bei einem Auftritt in einem IBM-Podcast im Jahr 2011 erinnerte sich Nipper an einige der Umstände, die zur Entstehung des Protokolls führten.

„Wie Sie sich bestimmt vorstellen können, hatten wir Anfang oder Mitte der 1990er Jahre noch nicht die Netzanbindung, die wir heute haben. Eines der Projekte, an denen ich gearbeitet habe, war ein SCADA-System (Supervisory Control and Data Acquisition) für eine neue Philips Conoco Pipeline. Dafür benötigten wir Echtzeitdaten. Damals haben wir in dieser Branche aber noch über 1.200-Baud- oder 300-Baud-Wählleitungen und Satellitenterminals (VSAT) mit sehr begrenzter Bandbreite kommuniziert.“

„Für MQTT hatten wir fünf Ziele: Einerseits sollte es einfach zu implementieren sein und Daten mit Quality of Service (QoS) liefern. Außerdem musste es leicht und bandbreiteneffizient sein, da der Datentransfer damals teuer war. Darüber hinaus sollte es datenunabhängig sein und über Sitzungspersistenz verfügen“, sagte er.

Mit dem Aufkommen des Internets der Dinge (IOT) entstand der Bedarf für ein Protokoll mit genau den Eigenschaften von MQTT. Angel Diaz, Vizepräsident für Software-Standards bei IBM, sagt:

„Als Planet sind wir stärker vernetzt. Ein Internet der Dinge hat sich herausgebildet. Und das Netz von Geräten, die miteinander kommunizieren und zusammenarbeiten können, hat sich explosionsartig vergrößert.“

„Es geschah also […], dass ein echter Bedarf für eine Protokoll-Art mit Publisher-Assigner-Architektur aufkam, um die bidirektionale Zustellung von Nachrichten auf eine besser vorhersehbare Weise zu ermöglichen.“

„Damit konnten wir von einer einfachen Punkt-zu-Punkt-Interaktion zu einer komplexeren Wechselbeziehung über das Netz übergehen. MQTT ist also ein Protokoll, das genau das ermöglicht: Das Veröffentlichen und Signieren von Nachrichten und eine vorhersehbare, wechselseitige Übermittlung dieser Nachrichten.“

Ursprünglich war MQTT ein Akronym für „MQ Telemetry Transport“. „MQ“ war dabei ein Verweis auf eine IBM-Middleware-Produktlinie namens MQSeries und stand dort für „Message Queue“. Seit 2013 ist der Begriff jedoch der Name des Protokolls.

Wem gehört MQTT?

Obwohl MQTT ursprünglich von IBM entwickelt wurde, ist es seit 2013 ein offenes Protokoll. Es wird vom OASIS-Konsortium (Organization for the Advancement of Structured Information Standards) mit Sitz in Massachusetts, USA gepflegt.

Die erste Version des Protokolls, die unter der Verantwortung der OASIS veröffentlicht wurde, war 3.1.1 im Oktober 2014. Diese Version ist auch eine Empfehlung der ISO (International Standards Organization) und der IEC (International Electrotechnical Commission) und trägt die Bezeichnung ISO/IEC 20922:2016.

Was ist die neueste Version von MQTT?

Die neueste Version von MQTT ist die Version 5, die im März 2019 von OASIS veröffentlicht wurde. Bei der Festlegung der Ziele stand das zuständige Komitee bei OASIS (OASIS Message Queuing Telemetry Transport Technical Committee) vor der Herausforderung, aufgrund des lang gehegten Wunsches der User neue Funktionen hinzuzufügen – ohne dabei die Belastung zu erhöhen oder die Benutzerfreundlichkeit zu verringern. Zudem sollten die Leistung und Skalierbarkeit verbessert werden.

Um diesen Anforderungen nachzukommen, wurden für die Version 5 folgende Ziele festgelegt:

• Verbesserungen bei der Skalierbarkeit und bei großen Systemen
• verbesserte Fehlerberichterstattung
• Formalisierung gemeinsamer Muster, einschließlich der Aufdeckung von Fähigkeiten und der Beantwortung von Anfragen
• Erweiterungsmechanismen einschließlich der Benutzereigenschaften
• verbesserte Leistung und Unterstützung für kleine Kunden

Was sind die Vorteile von MQTT?

Neben der Leichtigkeit und Einfachheit ist einer der Hauptvorteile von MQTT seine Flexibilität: Denn es konzentriert sich auf den Transport von Nachrichten zwischen zwei Punkten, ohne zu reflektieren, wer die Daten erzeugt oder wie sie genutzt werden sollen.

„Wenn ich ein eingebettetes Gerät erfinde, brauche ich auch ein Protokoll. Und dann muss ich zur IT-Abteilung laufen und eine Anwendung entwickeln, die mit meinem Gerät kommuniziert. Das Ergebnis ist eine Lösung […], die in der Zeit erstarrt ist“, so Niper.

„Aus der Zusammenarbeit mit IBM habe ich bei diesem Projekt gelernt: Durch die Einführung einer Publisher-Assigner-Architektur […] lässt sich die Implementierung von den Datenkonsumenten und den -produzenten auf der Geschäfts- oder Geräteseite trennen.“

„So können die Verbraucher sehr interessante Anwendungen auf einem End-to-End-Gerät schreiben, die Daten veröffentlichen – ohne dabei zu wissen, wer die Daten konsumiert. Und auf der anderen Seite gibt es Menschen, die die Daten nutzen.“

Darüber hinaus erleichtert das Publisher-Subscriber-Modell auch die Skalierbarkeit. Denn unabhängig davon, ob es 10, 100 oder 1.000 Abonnenten zu einem bestimmten Thema gibt. Der Aufwand, den ein Herausgeber betreiben muss, um eine Nachricht an alle zu senden, bleibt derselbe – eine einzige Verbindung zum Vermittler und eine einzige Nachricht.

Da MQTT ein offener Standard ist, gibt es eine Vielzahl von Implementierungen – entweder kommerziell oder als Open Source. Das bedeutet, dass es unabhängig von der Hardwareplattform, dem Betriebssystem oder der Programmiersprache, die Sie zur Entwicklung Ihrer Anwendung verwenden, mit Sicherheit eine oder mehrere Implementierungsmöglichkeiten gibt, die Ihren Anforderungen entsprechen.

Wo wird MQTT eingesetzt?

Das MQTT-Protokoll wird in unzähligen Situationen genutzt – von industriellen Umgebungen bis hin zur Steuerung von Geräten im Smart Home. Im Grunde genommen ist MQTT überall dort im Einsatz, wo ein Nachrichtenaustausch zwischen Geräten erforderlich ist.

Das deutsche Unternehmen CASO Design stellt intelligente Geräte für die Küche her, wie z. B. klimatisierte Weinkeller und Sous-Vide-Umwälzgeräte. Bei der Entwicklung der Produkte verfolgte das Unternehmen unter anderem das Ziel, dass diese von Nutzern von praktisch von überall gesteuert werden können. Außerdem sollten mehrere Nutzer ein einziges Gerät bedienen können und die Daten für verschiedene Anwendungen nutzbar sein.

Das ist auch der Grund, aus dem Lösungen wie eine Bluetooth-Verbindung über das UDP-Protokoll, die die physische Nähe zwischen dem Benutzer und dem Gerät erfordern, verworfen wurden. So entschied sich das Unternehmen letztendlich für MQTT: Denn über Wi-Fi-Verbindungen oder Mobilfunknetze kann ein Gerät mit einem Benutzer überall auf der Welt kommunizieren.

Dabei lassen sich mehrere Geräte über eine einzige App steuern. Sie sendet Befehle und benachrichtigt den Benutzer, wenn sich die Temperatur ändert oder der Kochvorgang beendet ist.

BMW nutzt MQTT wiederum in den BMW Mobility Services, einem Vehicle-Sharing-System für Flottenbetreiber. Denn eine herkömmliche Methode zur Fernsteuerung eines Fahrzeugs wäre das Senden einer SMS: Diese „weckt“ den Bordcomputer, der wiederum eine HTTP-Sitzung mit einem in der Cloud laufenden Back-End-Dienst initiiert.

Jeder, der schon einmal einen Authentifizierungscode erhalten hat, weiß jedoch, dass SMS nicht immer planbar sind. Eine Nachricht kann sofort oder erst nach einigen Minuten ankommen – oder sie kann unterwegs einfach verschwinden. Außerdem ist HTTP langsam. Und auch die Größe sowie die Anzahl der Nachrichten, die für den Aufbau einer Verbindung benötigt werden, erhöhen die Netzbetriebskosten.

MQTT war aufgrund seiner Leichtigkeit, einfachen Implementierung und garantierten Dienstqualität die perfekte Lösung. Denn an einem typischen Tag verarbeitet der BMW-Dienst 90.000 Transaktionen pro Minute, wobei mehr als 80.000 Kunden angeschlossen sind. Und dies in einem Umfeld, in dem die Netzzuverlässigkeit aufgrund der sehr mobilen und verstreuten Natur der Anwendung gering ist.

Laut Stanford-Clark, dem Mitbegründer von MQTT, wird das Protokoll jedoch nicht nur in Automatisierungssystemen eingesetzt. So übernahm Facebook es im Jahr 2011 als Transportschicht für seine beliebte Instant-Messaging-App Messenger. „Dadurch wurde MGTT buchstäblich über Nacht von 800 Millionen Menschen genutzt“, sagte er.

Und so funktioniert das Ganze: In Messenger wird bei jeder Unterhaltung ein Thread erstellt, den die Chatteilnehmer abonnieren und in den sie Beiträge schreiben. Anstelle eines einzigen gibt es jedoch mehrere Vermittler – und ein „Topic Director“ leitet die Datenpakete an den für einen bestimmten Chat zuständigen Vermittler weiter.

Darüber hinaus wird MQTT in Cloud-Plattformen wie Amazons AWS, Microsofts Azure, IBMs Watson und Googles IoT-Plattformen verwendet. Damit ist MQTT im Jahr 2018 das meistgenutzte Protokoll für den Nachrichtentransport im Internet der Dinge geworden.

Wie funktioniert MQTT?

MQTT arbeitet mit einer Publisher-Subscriber-Architektur. Clients können Nachrichten senden (als Herausgeber) oder empfangen (als Abonnenten). Es gibt aber keine direkte Verbindung zwischen ihnen: Denn die gesamte Kommunikation wird von einem Vermittler (Broker) gesteuert, der die veröffentlichten Nachrichten in einer Hierarchie von Themen organisiert und an interessierte Parteien verteilt.

Eine Analogie dazu ist eine traditionelle Zeitungsredaktion. Die Publisher wären hier die Reporter, die die Nachrichten sammeln und an die Redaktion weiterleiten. Diese wiederum fungiert als Vermittler und gliedert die Informationen in Abschnitte oder Themen. Die Abonnenten konsultieren hingegen die Zeitung, um Informationen zu den Themen zu erhalten, die sie interessieren.

Ein praktischeres Beispiel: Stellen Sie sich vor, dass ein Client ein Sensor ist, der die Temperatur eines Motors überwacht. Wenn der Sensor über neue Informationen verfügt (z. B. einen Temperaturanstieg), sendet er eine Nachricht zu diesem Thema (z. B. „Temperatur“) und die Information (z. B. „+10 °C“) an den Vermittler. Dieser wiederum leitet die Auskunft dann an alle Abonnenten des Themas „Temperatur“ weiter.

Allerdings schließen sich die Rollen von Publisher und Abonnent nicht aus – und das bedeutet Folgendes: Derselbe Kunde, der Informationen über die Motortemperatur sendet, kann einen Thread über den Füllstand der Kühlflüssigkeit abonnieren. So kann er diesen unter Kontrolle halten und die Informationen nutzen, um entsprechend zu handeln.

Der Vermittler kann wiederum eine dedizierte Appliance, ein PC mit Open-Source-Software im lokalen Netzwerk, ein Server in einem Unternehmensrechenzentrum oder sogar eine virtualisierte Instanz in der Cloud sein. Und auch der Standort und die Art des Vermittlers spielen keine Rolle, solange er über TCP/IP mit Herausgebern und Abonnenten „sprechen“ kann.

So wie eine Nachbarschaftszeitung keine Informationen über eine neue Entdeckung in der Quantenphysik veröffentlicht, verwirft ein Vermittler eine Nachricht über Themen, für die es keine Abonnenten gibt. Optional kann der Herausgeber jedoch angeben, dass diese Mitteilung zurückgehalten werden soll, bis ein Abonnent sein Interesse an dem Thema bekundet.

In diesem Fall erhält der Subscriber die Nachricht, sobald er das entsprechende Thema abonniert hat. Auf diese Weise bekommt er sofort die neuesten verfügbaren Informationen, ohne dass er auf eine Aktualisierung durch einen Publisher warten muss.

Darüber hinaus können die Publisher auch eine als „Letzter Wille und Testament“ bekannte Nachricht definieren. Diese wird dann an alle Abonnenten eines Themas gesendet, wenn die Verbindung zwischen dem Vermittler und dem Publisher plötzlich unterbrochen wird.

Apropos Verbindungen: MQTT verfügt über eine Funktion namens „Persistent Sessions“, die den Overhead beim erneuten Verbinden eines Clients mit einem Vermittler reduziert – insbesondere in instabilen Netzen, in denen dies häufig vorkommen kann.

Normalerweise muss ein Client, wenn er sich erneut mit einem Vermittler in Verbindung setzt, alle Themen, die ihn interessieren, noch einmal abonnieren. Wenn jedoch eine dauerhafte Sitzung angefordert wird, speichert der Vermittler verschiedene Informationen über den Kunden, die zum Zeitpunkt der erneuten Verbindung sofort verfügbar sind.

So kann der Client die Kommunikation dort fortsetzen, wo er sie unterbrochen hat – ohne Zeit (und Ressourcen) für die Neusignierung von Threads, die Neudefinition von QoS-Stufen usw. zu verschwenden.

Die MQTT-Datenübertragung erfolgt in der Regel über das TCP/IP-Protokoll (unter Verwendung des Standardports 1883). Allerdings kann stattdessen auch jedes andere Protokoll verwendet werden, das ordnungsgemäße, bidirektionale und verlustfreie Paketverbindungen bietet. Zudem ist die Größe der Nachrichten unterschiedlich und kann je nach Bedarf zwischen 2 Byte und 256 Megabyte liegen.

Was sind die Unterschiede zwischen MQTT und MQTT-SN?

MQTT für Sensornetzwerke (MQTT-SN) ist eine Erweiterung des MQTT-Protokolls für den Einsatz in drahtlosen Sensornetzwerken (WSN).

Solche Netze bestehen in der Regel aus einer großen Anzahl von Sensoren und Aktoren (SA) mit begrenzter Verarbeitungs- und Speicherkapazität. Diese kommunizieren über drahtlose Verbindungen mit niedriger Bandbreite sowie kurzer Reichweite und sind außerdem nicht besonders zuverlässig, da sie anfällig für Unterbrechungen durch Hindernisse oder Störungen sind.

Das MQTT-Protokoll scheint für diese Situation ideal zu sein – es erfordert jedoch eine TCP/IP-Implementierung, die für so einfache Geräte und Verbindungen wie die in den SAs verwendeten zu kostspielig sein könnte.

Für MQTT-SN wird so etwas nicht benötigt. Denn MQTT-SN kann über jede Art von Netz betrieben werden, das eine bidirektionale Datenübertragung zwischen einem Gerät und einem Gateway ermöglicht.

MQTT-SN wurde 2007 ebenfalls von IBM entwickelt und sollte ursprünglich in Netzwerken eingesetzt werden, die auf dem Zigbee-Protokoll basieren. Dieses beruht wiederum auf dem IEEE-Standard 802.15.4 für Wireless Personal Area Networks (WPANs).

Wie MQTT ist auch MQTT-SN ein Standard, der von OASIS gepflegt wird. Die aktuellste Version der Spezifikation ist 1.2.

Wie gewährleistet MQTT die Dienstgüte (QoS)?

Beim Aufbau einer Verbindung mit einem Vermittler kann ein Kunde (entweder Herausgeber oder Teilnehmer) je nach den Anforderungen der Anwendung drei Stufen der Dienstqualität festlegen.

Beim Aufbau einer Verbindung mit einem Vermittler kann ein Kunde (entweder Herausgeber oder Teilnehmer) je nach den Anforderungen der Anwendung drei Stufen der Dienstqualität festlegen.

Eine Analogie für diese Ebene wäre ein Supermarkt, der ein Unternehmen damit beauftragt, Flugblätter mit Angeboten für seine Kunden an die Haushalte einer Stadt zu verteilen. Er bittet nicht um eine Bestätigung, dass jedes Flugblatt zugestellt wurde. Und auch die Kunden machen sich nicht die Mühe, im Supermarkt anzurufen, um zu bestätigen, dass sie ein Exemplar erhalten haben.

Stufe 1 wird als „at least once“ bezeichnet. Wenn auf dieser Ebene nach einem bestimmten Zeitintervall keine Empfangsbestätigung für die Nachricht vorliegt, wird sie erneut gesendet, bis diese Zeitspanne verstrichen ist. Außerdem ist es möglich, dass eine Nachricht mehr als einmal empfangen oder zugestellt wird, z. B. wenn die Empfangsbestätigung unterwegs aufgrund eines Verbindungsfehlers verloren geht.

In diesem Fall könnten wir, um die vorherige Analogie aufzugreifen, die Flugblätter durch einen Rechnungsbrief ersetzen. Wenn keine Empfangsbestätigung (durch die Bezahlung der Rechnung) vorliegt, wird diese erneut versandt, bis die Zahlung eintrifft.

Die Stufe 2 wird „exactly once“ genannt. Hier führen sowohl der Kunde als auch der Vermittler einen zweistufigen Handshake durch, um sicherzustellen, dass nur eine Kopie der Nachricht zugestellt wird.

Analog zur Post lässt sich dies mit einem Einschreiben mit Rückschein vergleichen. Dieser geht im Anschluss an den Absender zurück und garantiert, dass der Brief zugestellt wurde.

Zudem ist es wichtig, sich daran zu erinnern, dass in MQTT immer ein Vermittler zwischen dem Herausgeber und dem Teilnehmer steht. Das bedeutet, dass es in jeder „Unterhaltung“ zwei Verbindungen gibt: eine zwischen dem Herausgeber und dem Vermittler und eine weitere zwischen dem Vermittler und dem Teilnehmer.

Diese Verbindungen können unterschiedliche QoS-Stufen haben. Ist das der Fall, stellt ein Vermittler dem Subscriber die Nachrichten immer mit der vom Abonnenten definierten QoS-Stufe zu – unabhängig von der, die der Herausgeber festgelegt hat.

Stellen Sie sich nun einmal vor, ein Herausgeber sendet Nachrichten zu einem Thema wie „Kraftstofffüllstand“ mit QoS 1. Sie werden dem Vermittler unter Einhaltung dieses Niveaus zugestellt, d. h. mit wiederholtem Versand, bis eine Zustellbestätigung vorliegt. Wenn der Abonnent dieses Themas jedoch QoS 0 angegeben hat, wird er die Nachricht nur einmal erhalten und der Vermittler erhält keine Bestätigung.

Wie wird bei MQTT die Sicherheit umgesetzt?

In der Version 3.1 des Protokolls ist es möglich, einen Benutzernamen und ein Passwort einzugeben, um eine Verbindung zu kontrollieren. Allerdings werden diese Daten „offen“ (im Klartext) übertragen und es gibt keine Verschlüsselung.

Darüber hinaus kann auch mitimplementiert SSL werden – unabhängig vom MQTT-Protokoll selbst. Es gibt aber einen inhärenten Nachteil beim Netzwerk- und Verarbeitungs-Overhead, da SSL kein leichtgewichtiges Protokoll ist. Denn verschlüsselte Verbindungen verwenden standardmäßig Port 8883.

Außerdem können Anwendungen die gesendeten und empfangenen Informationen auch verschlüsseln. Um das Protokoll einfach und leicht zu halten, ist dies jedoch nicht standardmäßig integriert.

Fazit

Obwohl es nicht für das Internet der Dinge entwickelt wurde, ist der Erfolg von MQTT direkt mit seiner Verbreitung verbunden, die sich in absehbarer Zeit nicht verlangsamen wird. Das Protokoll ist leichtgewichtig, flexibel und mit zahlreichen Implementierungen verfügbar. Deshalb ist es sicherlich eine Überlegung wert, wenn Sie das nächste Mal ein IoT-Gerät oder eine Anwendung entwickeln.