Startseite > Kommunikation > Zwei Protokolle zur Auswahl

Internet der Dinge

Zwei Protokolle zur Auswahl

17. Dezember 2015, 13:22 Uhr | Von James Stansberry

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Die Stärken und Schwächen von MQTT

Die Stärken von MQTT

MQTT nutzt ein „Verbreiten/Abonnieren“-Modell (Publish/Subscribe) und benötigt einen zentralen MQTT-Makler, der Nachrichten zwischen den MQTT-Netzwerkknoten verwaltet und weiterleitet. Eclipse beschreibt MQTT als ein „Mehrpunkt-zu-Mehrpunkt-Kommunikationsprotokoll zur Weiterleitung von Nachrichten zwischen mehreren Clients durch einen zentralen Makler“. MQTT nutzt TCP als Transportschicht, das als zuverlässig, geordnet und fehlerüberprüft gilt.

Verbreiten/Abonnieren-Modell

Das MQTT-„Pub/Sub“-Modell lässt sich gut skalieren und kann energiesparend sein. Makler und Knoten verbreiten Informationen und andere abonnieren diese entsprechend dem Nachrichten-Inhalt, Typ oder Thema. Der Makler abonniert generell alle Nachrichten und verwaltet dann den Informationsfluss zu seinen Knoten. Das Verbreiten/Abonnieren-Modell bietet verschiedene Vorteile:

Räumliche Entkopplung Knoten und Makler müssen jeweils über die IP-Adresse des anderen verfügen. Jedoch können Knoten Informationen verbreiten oder von anderen Knoten abonnieren, ohne voneinander zu wissen, da alles über den zentralen Makler läuft. Dies verringert den Protokollballast, der mit Sitzungen per TCP einhergeht, und die Endknoten können unabhängig voneinander arbeiten. Zeitliche Entkopplung Ein Knoten kann seine Informationen unabhängig vom Status anderer Knoten verbreiten. Andere Knoten können diese Informatione vom Makler empfangen, sobald sie aktiv sind. Damit können Knoten im Ruhezustand verweilen, selbst wenn andere Knoten Nachrichten verbreiten, die für sie relevant sind.

Synchronisations-Entkopplung Ein Knoten, der gerade eine Operation ausführt, wird nicht unterbrochen, um eine verbreitete Nachricht zu empfangen, die er abonniert hat. Die Nachricht wird vom Makler gespeichert, bis der Empfangsknoten seine Aufgabe beendet hat. Dies spart Energie und reduziert wiederholte Operationen, indem Unterbrechungen laufender Aktionen oder von Ruhezuständen vermieden werden. Sicherheit MQTT verwendet unverschlüsseltes TCP und ist nicht von Grund auf sicher. Da MQTT aber TCP nutzt, kann – und sollte – das Internet-Verschlüsselungsprotokoll TLS (Transport Layer Security, auch bekannt als Secure Sockets Layer, SSL) verwendet werden. TLS ist eine sehr sichere Methode zur Verschlüsselung des Datenverkehrs, aber auch eine ressourcenintensive für abgespeckte Clients, da ein Handshake erforderlich ist und ein höherer Protokollballast pro Paket auftritt. In Netzwerken, in denen hoher Wert auf den Energiebedarf und weniger auf die Sicherheit gelegt wird, kann es reichen, nur die Nutzdaten des Pakets zu verschlüsseln.

Dienstgüte

Der Begriff Dienstgüte (QoS, Quality of Service) bezieht sich auch auf andere Dinge außerhalb von MQTT. In MQTT beschreiben die QoS-Stufen 0, 1 und 2 eine zunehmende garantierte Nachrichten-Auslieferung.

Stufe 0 (höchstens einmal) Dies wird allgemein als „Fire and Forget“ bezeichnet: ein einzelner Sendevorgang ohne Garantie, dass die Nachricht angekommen ist. Stufe 0 kann bei oft wiederholten Nachrichtentypen oder nicht einsatzkritischen Nachrichten verwendet werden. Stufe 1 (mindestens einmal) Damit soll garantiert werden, dass eine Nachricht zumindest einmal beim beabsichtigten Empfänger ankommt. Wird die Nachricht vom beabsichtigten Empfänger empfangen und verstanden, wird diese mit einer Empfangsbestätigungs-Nachricht (PUBACK) bestätigt – adressiert an den die Nachricht verbreitenden Knoten. Bis die Nachricht mit der Empfangsbestätigung vom Sender empfangen wurde, speichert der sie ausgebende Knoten die Nachricht und sendet sie in regelmäßigen Abständen wiederholt aus. Dieser Nachrichtentyp kann für eine nicht kritische Abschaltung von Knoten eingesetzt werden. Stufe 2 (genau einmal) Stufe 2 versucht zu garantieren, dass die Nachricht vom vorgesehenen Empfänger erhalten und decodiert wurde. Dies ist die sicherste und zuverlässigste Dienstgüte bei MQTT. Der Sender verbreitet eine Nachricht zur Ankündigung, dass er eine Nachricht mit QoS Stufe 2 verbreiten muss. Der vorgesehene Empfänger nimmt die Ankündigung entgegen, decodiert sie und zeigt an, dass er für den Empfang der Nachricht bereit ist. Der Sender verbreitet dann die Nachricht. Versteht der Empfänger diese Nachricht, schließt er die Transaktion mit einer Bestätigung ab. Dieser Nachrichtentyp kann z.B. für das Ein-/Ausschalten von Licht oder Alarmanlagen im Haus angewendet werden.

Letzter Wille und Testament

MQTT bietet eine LWT-Nachricht (Last Will and Testament), die im MQTT-Makler gespeichert werden kann – für den Fall, dass ein Knoten unerwartet vom Netzwerk getrennt wird. Diese LWT-Nachricht speichert den Zustand und Zweck des Knotens, einschließlich der von ihm herausgegebenen Befehlstypen und seine Abonnements. Verschwindet der Knoten, benachrichtigt der Makler alle Abonnenten der LWT-Nachricht dieses Knotens. Kehrt der Knoten zurück, informiert der Makler den Knoten über seinen vorherigen Zustand. Diese Funktion sorgt für eine Anpassung an Veränderungen, z.B. bei verlustbehafteten Netzwerken, und unterstützt die Skalierbarkeit.

Flexible Abonnements von Schlagworten

Ein MQTT-Knoten kann alle Nachrichten mit einer bestimmten Funktion abonnieren. So kann ein Küchenherd-Knoten alle Nachrichten für „Küche/Herd/+“ mit „+“ als Platzhalter abonnieren – mit minimalen Anforderungen an Code, Speicher und Kosten. Ein Knoten in der Küche kann auch an sämtlichen Temperaturinformationen interessiert sein, unabhängig von der Funktion des Endknotens. In diesem Fall erfasst „Küche/+/Temp“ jede Nachricht in der Küche, die von jedem Knoten kommt, der „Temp“ meldet. Es gibt noch weitere nützliche MQTT-Platzhalter, um den Code-Umfang zu verringern und damit die Speichergröße und die Kosten zu reduzieren.

Die Schwächen von MQTT

Der zentrale Makler kann ein Nachteil in verteilten IoT-Systemen sein. Beispiel: Ein System kann anfangs klein ausgelegt werden, mit einer Fernsteuerung und einem Fensterrollo. Später, wenn das System erweitert wird, z.B. durch Sicherheitssensoren, Leuchten oder weitere Rollos, wächst das Netzwerk und kann nun einen zentralen Makler benötigen. Jedoch möchte keiner der einzelnen Knoten die Kosten und Verantwortung übernehmen, da hierfür Ressourcen, Software und Komplexität gefordert werden, die nicht Teil der zentralen Funktion des Endknoten sind.

In Systemen, die bereits mit einem zentralen Makler ausgestattet sind, kann dieser zur Schwachstelle für das gesamte Netzwerk werden. Ist der Makler z.B. ein netzgespeister Knoten ohne Puffer-Akku oder USV, können batteriebetriebene Knoten bei einem Stromausfall weiter arbeiten, während der Makler außer Betrieb ist. Das Netzwerk funktioniert dann aber nicht mehr.

Hoher Energiebedarf für TCP

TCP wurde ursprünglich für Geräte mit mehr Speicher und Rechenressourcen entwickelt, als in einem abgespeckten IoT-Netzwerk vorhanden sind. Das TCP-Protokoll verlangt zum Beispiel, dass Verbindungen in einem mehrstufigen Handshake-Prozess aufgebaut werden, bevor eine Nachricht ausgetauscht wird. Damit verlängern sich die Zeitspannen für das Wecken und die Kommunikation, was auf längere Sicht die Batterielebensdauer verkürzt.

In TCP ist es für zwei kommunizierende Knoten ideal, ihre TCP-Schnittstelle mit einer permanenten Sitzung für den anderen Knoten dauerhaft offen zu halten, was für energie- und ressourcenbeschränkte Geräte wiederum schwierig sein kann.

Verlängerte Weckzeit

Wird TCP ohne dauerhafte Sitzung verwendet, kann dies – aufgrund des Verbindungsaufbaus – zu einer höheren Übertragungszeit führen. Bei batteriebetriebenen Knoten mit periodischem, sich wiederholendem Datenverkehr kann dies zu einer kürzeren Nutzungsdauer führen.