Suche
Interview mit Christian Götz und Dominik Obermaier

„MQTT glänzt bei Push-basierter Kommunikation.“

Diana Kupfer
Christian Götz, Dominik Obermaier

Christian Götz und Dominik Obermaier sind Mitgründer der dc-square GmbH, einem Unternehmen, das sich auf die Entwicklung hochskalierbarer IoT-/M2M-Lösungen und die Beratung von Unternehmen in diesem Bereich spezialisiert hat. Sie halten außerdem Vorträge auf Konferenzen und schreiben Artikel im Bereich M2M. Auf der EclipseCon Europe sprachen wir mit ihnen über MQTT, ein leichtgewichtiges Protokoll für das Internet der Dinge, das ebenfalls zu ihren Schwerpunktthemen zählt.

JAXenter: Wie seid ihr auf MQTT gekommen?

Christian Götz: Wir haben uns bei der dc-square GmbH auf Anwendungen im Bereich Machine-to-Machine-Kommunikation und vor allem auch MQTT spezialisiert. Wir sind durch Kundenprojekte auf MQTT aufmerksam geworden und haben uns im selben Zug auch mit der Community über Twitter und  mqtt.org vernetzt.

So haben wir immer mehr die Vorzüge von MQTT kennengelernt und nutzen dieses Wissen gezielt in Projekten, die von Kunden an uns herangetragen werden.

JAXenter: Wie ist dieser Hype um MQTT zu erklären – was genau sind die Vorteile?

Götz: Das Protokoll wurde ursprünglich von Andy Stanford-Clark von IBM und Arlen Nipper, damals Arcom, entwickelt. Es ist erst seit 2010 offen und lizenzfrei. Damit wurde der Grundstein für die Verbreitung gelegt. Entscheidend zu dem Hype beigetragen hat meiner Meinung nach der Siegeszug von Smartphones und mobilen Geräten im Allgemeinen. Die Zahlen sind durchaus beeindruckend. Es werden zum Beispiel ca. 80 Geräte pro Sekunde mit dem Internet verbunden. Einen anderen großen Anteil haben offene Hardwareplattformen, wie zum Beispiel Rasberry Pi und Arduino, die wie Pilze aus dem Boden schießen.

Der einfachere Einstieg in die hardwarenahe Programmierung wird von vielen dankend angenommen. Damit wird der Bedarf an Lösungen für die Kommunikation über unzuverlässige Netze wie das Mobilfunknetz immer größer.

Die Anforderungen, die man 1999 für ein Protokoll zur Überwachung von Ölpipelines über Satelliten identifizierte, decken sich mit denen, die an die mobile Kommunikation im 21. Jahrhundert gestellt werden. MQTT hat eine leichtgewichtige und ressourcenschonende Datenübertragung. Es legt kein bestimmtes Datenformat fest und bietet die Sicherheit, dass alle Nachrichten übertragen werden, auch wenn die Verbindung kurz abreißt. Trotzdem wurde es relativ simpel gehalten, was für die Verwendung auf Geräten mit beschränkten Ressourcen wichtig ist. MQTT hat einen klaren Fokus auf dem mobilen Bereich, weil es für die Probleme, die durch die unzuverlässige Kommunikation aufkommen, Abhilfe schafft.

JAXenter: Fokus auf dem mobilen Bereich, das heißt, es ist nicht das Protokoll für alle Anwendungsfälle. Dominik, du bist in Deinem EclipseCon-Talk auch kurz auf HTTP und CoAP [Constrained Application Protocol] eingegangen und hast auch im dem Java-Magazin-Artikel gerade darüber geschrieben. Was sind die Vor- und Nachteile von CoAP und HTTP gegenüber MQTT?

Dominik Obermaier: HTTP ist so alt wie das World Wide Web an sich, das heißt es ist ein sehr stabiles Protokoll. Es gibt für jede Programmiersprache eine HTTP-Bibliothek, es ist Standard und auch von Menschen lesbar, das bedeutet, es ist kein binäres Protokoll wie zum Beispiel CoAP und MQTT. Wenn sehr viele verschiedene Systeme integriert werden müssen, spielt es seine Stärken aus. Es hat aber speziell im M2M-Bereich auch Nachteile. Einer davon ist, dass es nicht binär ist, daher ist der Bandbreitenverbrauch nicht optimiert. Davon abgesehen hat HTTP generell viel Overhead – den HTTP-Header beispielsweise –, der nicht unbedingt für die Applikation benötigt wird. Das Protokoll ist Request-Response-basiert, man fragt also beim Server nach Daten und wartet auf eine Antwort. Für echte Push-Kommunikation ist HTTP nicht geeignet. Trotzdem wird HTTP nicht von der Bildfläche verschwinden. Es wird bleiben und auch langfristig eine wichtige Rolle spielen. Es kann sich einfach niemand leisten, kein REST-API mit HTTP zu unterstützen.

CoAP ist ein vergleichsweise junges Protokoll. Es hat noch eine sehr kleine Community und es gibt sehr wenige Implementierungen. Generell ist CoAP, ähnlich wie HTTP, ein RESTful-Protokoll. Es ist auf Maschinen optimiert und in gewisser Weise auch kompatibel mit HTTP. Nachteile sind, wie bereits erwähnt, die kleine Community, die Tatsache, dass es schwieriger zu debuggen ist, weil es binär ist, und die fehlende Unterstützung durch Tools und Bibliotheken.

JAXenter:  Ist aber noch ausbaufähig, also die Community wächst, oder?

Obermaier: Genau. Ich denke, dass Internet-of-Things-Plattformen neben einer HTTP-Schnittstelle langfristig auch CoAP-Schnittstellen besitzen werden, wenn man Anwendungsfälle bedienen will, die z. B. eine effiziente Mobilfunkkommunikation benötigen.

JAXenter: Ihr habt vorhin auch über Quality of Service Level [QoS] gesprochen, die HTTP nicht hat, MQTT schon. Könnt Ihr ganz kurz erklären, welche es gibt?

Obermaier: Bei MQTT gibt es drei QoS Levels: 0, 1 und 2. QoS 0 ist prinzipiell fire and forget. Dadurch, dass MQTT auf TCP basiert, ist eine Verbindung über ein kabelgebundenes Netzwerk relativ stabil. Es reicht dabei meistens aus, sich auf die von TCP zur Verfügung gestellten Mechanismen zu verlassen, um eine Nachricht an alle Clients zu senden. In einem mobilen Szenario mit instabilen Mobilfunknetzen kann es aber passieren, dass trotz TCP Nachrichten verlorengehen. Bei QoS 0 bedeutet das, dass die Nachricht nicht ankommt. Der Sender wird auch nicht darüber informiert. Bei QoS Level 1 wird vom Protokoll selbst sichergestellt, dass die Nachricht mindestens einmal ankommt. Das hat zur Folge, dass es unter bestimmten Umständen Duplikate beim Empfänger geben kann – beispielsweise, wenn die Rückantwort verloren geht und der Client die Nachricht noch einmal schickt. Prinzipiell bedeutet das aber, dass die Nachricht angekommen ist. Die höchste Garantie gibt QoS Level 2. In einem erweiterten Protokoll-Flow wird sichergestellt, dass die Nachricht genau einmal beim Empfänger ankommt.

JAXenter: Wenn man jetzt diese drei Protokolle für verschiedene Anwendungsszenarien verwendet, bleiben dann noch größere Lücken? Gibt es wichtige Use Cases, die damit noch nicht abgedeckt sind und bei denen man andere Protokolle verwenden müsste, wie z. B. AMQP?

Obermaier: Das kommt auf den Anwendungsfall an. Wenn man speziell für mobile Kommunikation entwickelt, kann man damit schon sehr viel abdecken. Also die gängigen Internet-of-Things-Plattformen implementieren diese drei Protokolle, und es sind bisher noch keine größeren Lücken entdeckt worden. Dazu tragen auch die unterschiedlichen Paradigmen bei, auf denen die Protokolle basieren – Publish/Subscribe im Falle von MQTT und Request/Response bei HTTP und COAP.

JAXenter: Das ergänzt sich alles ganz gut oder?

Obermaier: MQTT glänzt, wenn man Push-basierte Kommunikation braucht. Bei Request-basierter Kommunikation sind HTTP oder CoAP sehr gut. Deswegen sehe ich im Moment keinen Bedarf an zusätzlichen Protokollen.

JAXenter: Du hast gerade von Push gesprochen – eine Bereicherung ist sicher WebSocket. Ihr habt ja eine ganz interessante Lösung entwickelt für HiveMQ: Dabei habt ihr WebSocket mit MQTT kombiniert. Wie funktioniert das?

Obermaier: Der von uns entwickelte MQTT-Broker HiveMQ kann nativ mit WebSocket umgehen. MQTT an sich basiert auf TCP, durch die native Unterstützung können MQTT Nachrichten auch über WebSocket an den Broker versendet werden. Jeder Browser kann also prinzipiell ein MQTT Client sein. Damit ist es möglich, Benutzer auf einer Webseite Push-Notifications zu schicken. JavaScript-Bibliotheken wie z. B. Eclipse Paho können verwendet werden, um eine WebSocket-Verbindung zu einem MQTT-Broker herzustellen. Für den MQTT-Broker bedeutet das: Es ist ihm generell egal, ob es eine TCP-basierte Verbindung oder eine Verbindung über WebSocket ist – es ist ein MQTT-Client. Das ermöglicht Push Notifications im Browser und zusätzlich noch Features wie QoS Levels, Queuing bei höheren QoS Levels und auch Last Will and Testament, was man benutzen kann, um auf das Schließen eines Browserfensters zu reagieren.

JAXenter: Was sind Anwendungsszenarien für diese Kombination?

Obermaier: Beispielsweise Online-Chats und generell alles, was Push benötigt. Nachrichtenticker sind ein anderes gutes Beispiel. Das Interesse ist hier sehr groß, vor allem in der Community. Aber auch sehr viele andere Leute entwickeln Lösungen für Probleme, an die man selbst noch nicht gedacht hat. Der Ansatz bietet die Möglichkeit, dass jeder Browser und auch jedes Smartphone über den Browser ein MQTT-Device sein kann. Man bekommt echte Push Notifications, ohne dass man eigene Lösungen entwickeln muss, die es ermöglichen, Nachrichten über WebSocket auszutauschen.

JAXenter: Punkt Sicherheit, das ist natürlich ein großes Feld, aber auch sehr wichtig im Bereich Embedded/M2M/IOT. Wie lässt sich MQTT sicher machen?

Götz: Generell gibt es da mehrere Möglichkeiten, besser gesagt, mehrere Ebenen, die man berücksichtigen muss. Das Protokoll sieht vor, dass beim Verbindungsaufbau des Clients ein Username und ein Passwort mitgeschickt werden können. Das ist im ersten Moment nicht sicher, da der Username und das Passwort im Klartext übertragen werden. Das wird umgangen durch den Aufbau einer SSL-Verbindung zwischen Client und Broker. Dadurch ist sichergestellt, dass der Nachrichteninhalt und der Username und das Passwort nicht von Dritten mitgelesen oder manipuliert werden können. Natürlich ist anzumerken, dass SSL ein Protokoll mit nicht wenig Overhead ist und eventuell die Verschlüsselung der eigentlichen Nachricht eine Alternative dazu darstellen kann.

In manchen Szenarien macht es beispielsweise auch Sinn, die Kommunikation über MQTT durch einen SSH-Tunnel oder VPN-Verbindungen abzusichern. In diesem Fall gewährleistet die SSH oder VPN Verbindung die Übertragungssicherheit.

Man muss natürlich nicht nur auf Protokollebene für das nötige Maß an Sicherheit sorgen, sondern auch auf Betriebssystemebene des Servers, auf dem der Broker läuft. Das fällt mehr in den Bereich Operations.

Auf Applikationsebene ist es je nach Anwendungsfall auch sinnvoll, Topics individuell abzusichern. Eine häufige Absicherung ist die Begrenzung der Berechtigungen der einzelnen Clients auf bestimmten Topics. Man erlaubt beispielsweise nur manchen Clients Nachrichten zu versenden [publish] oder Nachrichten zu empfangen [subscribe]. Das ist keine Funktionalität des Protokolls, sondern stützt sich auf die Implementierung des Brokers.

JAXenter: MQTT ist aber doch durch den Publish-Subscribe-Mechanismus insofern schon sicher, als sich die Clients untereinander nicht kennen?

Götz: Genau. Die Clients müssen sich untereinander nicht kennen, das ist ein zentraler Aspekt. Allerdings verhindert das nicht direkt eine Manipulation oder das Abhören der zu übertragenden Daten. Ein potentieller Angreifer könnte, vorausgesetzt er hat Username und Passwort eines Clients, Nachrichten abhören oder Nachrichten schicken, die Schaden verursachen. Auch die Annahme, dass sich Clients nicht kennen, geht nur so weit, dass man sie nicht direkt mit Identifiern anspricht. Es muss aber ein gewisses Level an Wissen da sein, weil MQTT auch data-agnostic ist, d. h. das Protokoll setzt nicht auf feste Strukturen, wie Daten übertragen werden, sondern überlässt dies dem Entwickler. Alle Clients müssen das auf die gleiche Art und Weise befolgen. Eine generelle Grundannahme ist, dass nur vertrauenswürdige Clients sich im MQTT-Netzwerk befinden.

Trotzdem sollte man nach dem Prinzip der geringsten Rechte den Clients nur erlauben, die nötigen Nachrichten auszutauschen und keinen Zugriff auf alles geben. Das ist vor allem für Geräte interessant, die öffentlich zugänglich sind. Man muss sicherstellen, dass ein potentieller Angreifer, der zum Beispiel physischen Zugriff zu einem Temperatursensor hat, nicht etwa Steuerbefehle senden kann und dadurch Einfluss auf  andere Geräte nehmen kann.

JAXenter: Das klingt jetzt so, als hätte man damit schon das wesentliche Rüstzeug für das Internet der Dinge. Woran liegt es eurer Beobachtung nach, dass noch so viele proprietäre Technologien im Einsatz sind?

Götz: Ich denke, das hat mehrere Gründe. Einer davon ist, dass die MQTT-Community zwar mit jedem Tag wächst, es allerdings Zeit braucht, bis MQTT auch in die Firmen hineingetragen wird. Da spielen die Entwickler eine wichtige Rolle. Über die Entwickler-Community und Konferenzen wie die EclipseCon oder die JAX werden Entwickler darauf aufmerksam und tragen das Wissen in die Firmen hinein. Das bekommt schließlich niemand per Push Notification auf sein Handy mitgeteilt [lacht].

Generell tragen die Offenheit des Protokolls, die Arbeit der Community und auch die offenen Tools und Bibliotheken dazu bei, ein stabiles Ökosystem aufzubauen, das auch in Firmen nachhaltig eingesetzt werden kann. Allerdings ist, abgesehen von einigen wenigen, bei vielen Firmen der Gedanke, alles selbst zu implementieren, immer noch höher angesiedelt als auf offene De-facto-Standards zu setzen.

JAXenter: Was kann man machen, um diese Firmenkultur zu unterwandern?

Götz: Das ist keine leichte Aufgabe. Aber wie schon gesagt, die Entwickler spielen dabei eine große Rolle, da sie offene Technologien in die Firmen hineintragen und bewirken, dass diese Sichtbarkeit bekommen. Es muss oft Überzeugungsarbeit geleistet werden, um beispielsweise Nutzen und Vergleich zu bereits etablierten Technologien klar darzulegen. Das braucht Zeit. Die Community ist auf einem guten Weg, und es ist viel Engagement zu sehen. Allerdings ändern sich diese Dinge nicht von heute auf morgen.

Obermaier: Es ist auch eine Kostenfrage: Wenn man für jedes Projekt sein eigenes proprietäres Protokoll entwickelt, hat man immer wieder einen hohen Entwicklungsaufwand. Wenn man dagegen etwas benutzt, was schon länger auf dem Markt ist, bereits produktiv eingesetzt wird und stabil funktioniert, ist das oft mit weniger Risiko und Kosten verbunden.

Götz: Die meisten proprietären Protokolle sind auf bestimmte Anwendungsfälle zugeschnitten. Das ist sicher nicht der richtige Weg. Wenn man offene Protokolle verwendet, profitiert man vom Ökosystem darum herum. Außerdem ist schneller ein höherer Reifegrad erreicht, da ein Protokoll oft in verschiedenen Anwendungsfällen und von unterschiedlichen Entwicklern benutzt wird.

JAXenter: Also höhere Produktivitätsanforderungen werden letztendlich den Wandel hervorbringen?

Obermaier: Ja, genau.

JAXenter: Irgendetwas, was euch noch auf den Nägeln brennt?

Götz: Generell wollen wir jeden ermutigen, MQTT auszuprobieren, sich nicht abschrecken zu lassen von der Umstellung auf ein anderes Paradigma und es in seinen Technologie-Stack aufzunehmen. Wir setzen es auch nicht zwangsweise in jedem Projekt ein. Aber die Anwendungsfälle werden immer mehr, und dann ist es von Vorteil, schon eine passende Lösung in petto zu haben.

JAXenter: Gibt es Treffen der Community oder sogar Konferenzen?

Götz: Ich weiß nichts von MQTT-spezifischen Konferenzen. Zumindest gibt es auf der JAX oder EclipseCon spezielle Tage, an denen das Thema M2M und MQTT tiefer behandelt wird. Das trägt natürlich auch zum Austausch in der Community und zur Vergrößerung bei.

 

Geschrieben von
Diana Kupfer
Diana Kupfer
Diana Kupfer war Redakteurin bei S&S Media für die Zeitschriften Java Magazin, Eclipse Magazin und das Portal JAXenter. 
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.