MQTT

MQTT-Architektur

MQTT läuft auf TCP/IP unter Verwendung einer PUSH/SUBSCRIBE-Topologie. In der MQTT-Architektur gibt es zwei Arten von Systemen: Clients und Makler. Ein Broker ist der Server, mit dem die Clients kommunizieren. Der Broker empfängt Mitteilungen von den Clients und sendet diese Mitteilungen an andere Clients weiter. Die Clients kommunizieren nicht direkt miteinander, sondern stellen eine Verbindung mit dem Broker her. Jeder Client kann entweder ein Publisher, ein Subscriber oder beides sein.

MQTT ist ein ereignisgesteuertes Protokoll. Es gibt keine periodische oder laufende Datenübertragung. Dadurch wird die Übertragung auf ein Minimum beschränkt. Ein Client veröffentlicht nur dann, wenn es Informationen zu senden gibt, und ein Broker sendet nur dann Informationen an Abonnenten, wenn neue Daten eintreffen.

Architektur der Nachrichten

Eine weitere Möglichkeit, wie MQTT seine Übertragungen minimiert, besteht in einer eng definierten, kleinen Nachrichtenstruktur. Jede Nachricht hat einen festen Header von nur 2 Byte. Ein optionaler Header kann verwendet werden, erhöht aber die Größe der Nachricht. Die Nutzlast der Nachricht ist auf 256 MB begrenzt. Drei verschiedene Quality of Service (QoS)-Stufen ermöglichen es Netzwerkdesignern, zwischen einer Minimierung der Datenübertragung und einer Maximierung der Zuverlässigkeit zu wählen.

• QoS 0 - Bietet die geringste Menge an Datenübertragung. Bei dieser Stufe wird jede Nachricht einmal ohne Bestätigung an einen Teilnehmer zugestellt. Es gibt keine Möglichkeit festzustellen, ob die Teilnehmer die Nachricht erhalten haben. Diese Methode wird manchmal als "fire and forget" oder als "at most once delivery" bezeichnet Da bei dieser Stufe davon ausgegangen wird, dass die Zustellung vollständig ist, werden Nachrichten nicht für die Zustellung an getrennte Clients gespeichert, die sich später wieder verbinden.
• QoS 1 - Der Broker versucht, die Nachricht zuzustellen und wartet dann auf eine Bestätigungsantwort des Abonnenten. Wird die Bestätigung nicht innerhalb eines bestimmten Zeitrahmens empfangen, wird die Nachricht erneut gesendet. Bei dieser Methode kann der Teilnehmer die Nachricht mehr als einmal erhalten, wenn der Broker die Bestätigung des Teilnehmers nicht rechtzeitig erhält. Dies wird manchmal auch als "mindestens einmalige Zustellung" bezeichnet.
• QoS 2 - Client und Broker verwenden ein vierstufiges Handshake-Verfahren, um sicherzustellen, dass die Nachricht empfangen wird und dass sie nur einmal empfangen wird. Dies wird manchmal als "genau einmalige Zustellung" bezeichnet.
  
  

In Situationen, in denen die Kommunikation zuverlässig, aber begrenzt ist, kann QoS 0 die beste Option sein. In Situationen, in denen die Kommunikation unzuverlässig ist, aber die Verbindungen nicht so ressourcenbeschränkt sind, wäre QoS 2 die beste Option. QoS 1 bietet eine Art Best-of-both-Worlds-Lösung, setzt aber voraus, dass die Anwendung, die die Daten empfängt, weiß, wie sie mit Duplikaten umgehen muss.

Sowohl bei QoS 1 als auch bei QoS 2 werden Nachrichten für Clients gespeichert oder in eine Warteschlange gestellt, die offline sind und eine dauerhafte Sitzung aufgebaut haben. Diese Nachrichten werden (gemäß der entsprechenden QoS-Stufe) erneut gesendet, sobald der Client wieder online ist.

Themen

Nachrichten innerhalb von MQTT werden als Topics veröffentlicht. Topics sind Strukturen in einer Hierarchie mit dem Schrägstrich (/) als Begrenzungszeichen. Diese Struktur ähnelt der eines Verzeichnisbaums in einem Dateisystem eines Computers. Mit einer Struktur wie sensors/OilandGas/Pressure/ kann ein Abonnent angeben, dass er nur Daten von Clients erhalten soll, die im Topic Pressure veröffentlichen, oder, für eine umfassendere Betrachtung, vielleicht alle Daten von Clients, die im Topic sensors/OilandGas veröffentlichen. Topics werden in MQTT nicht explizit erstellt. Wenn ein Broker Daten erhält, die in einem Topic veröffentlicht werden, das derzeit nicht existiert, wird das Topic einfach erstellt, und die Clients können das neue Topic abonnieren.

Zurückgehaltene Nachrichten

Um den Speicherplatzbedarf gering zu halten, werden empfangene Nachrichten nur dann im Broker gespeichert, wenn sie mit dem Flag "retained" gekennzeichnet sind. Dies wird als aufbewahrte Nachricht bezeichnet. Benutzer, die empfangene Nachrichten speichern möchten, müssen diese an anderer Stelle außerhalb des MQTT-Protokolls speichern. Es gibt eine Ausnahme.

Da es sich um ein ereignisgesteuertes Protokoll handelt, ist es möglich, ja sogar wahrscheinlich, dass ein Teilnehmer nur sehr wenige Nachrichten für ein bestimmtes Thema erhält, selbst über einen langen Zeitraum hinweg. In der oben erwähnten Themenstruktur werden vielleicht nur dann Nachrichten zum Thema Druck gesendet, wenn ein Sensor feststellt, dass der Druck einen bestimmten Wert überschritten hat. Unter der Annahme, dass der Sensor, den er überwacht, nicht häufig ausfällt, kann es Monate oder sogar Jahre dauern, bis ein Client eine Nachricht zu diesem Thema veröffentlicht.

Um sicherzustellen, dass ein neuer Abonnent die Nachrichten aus einem Thema erhält, können Broker die letzte an jedes Thema gesendete Nachricht aufbewahren. Dies wird als aufbewahrte Nachricht bezeichnet. Immer wenn ein neuer Kunde ein Thema abonniert oder wenn ein bestehender Kunde wieder online geht, wird die aufbewahrte Nachricht an die Abonnenten gesendet, wodurch sichergestellt wird, dass das Abonnement aktiv ist und die neuesten Informationen enthält.

Letzter Wille und Testament

Bei unzuverlässiger Kommunikation kann es vorkommen, dass ein Verlag ohne Warnung die Verbindung zum Netz unterbricht. Ein Verleger kann eine Nachricht registrieren, die an die Abonnenten gesendet wird, falls der Verleger die Verbindung unerwartet unterbricht. Dies ist ein so genannter letzter Wille und ein Testament. Diese Nachricht wird im Cache des Brokers gespeichert und an die Abonnenten verschickt, falls der Verlag die Verbindung vorschriftswidrig unterbricht. In der Regel enthält eine solche Nachricht Informationen, die es ermöglichen, den unterbrochenen Verlag zu identifizieren, so dass die entsprechenden Maßnahmen ergriffen werden können.

MQTT-Nachrichten

Um das Protokoll klein zu halten, gibt es bei jeder Kommunikation nur vier mögliche Aktionen: veröffentlichen, abonnieren, abbestellen oder pingen.

• Veröffentlichen - Sendet einen Datenblock, der die zu sendende Nachricht enthält. Diese Daten sind für jede Implementierung spezifisch, können aber etwas so Einfaches sein wie eine An/Aus-Anzeige oder ein Wert eines bestimmten Sensors, wie Temperatur, Druck usw. Falls das Thema, das veröffentlicht werden soll, noch nicht existiert, wird das Thema vom Broker erstellt.
• Abonnieren - Verwandelt einen Client in einen Abonnenten eines Themas. Themen können spezifisch abonniert werden oder über Wildcards, die Abonnements für einen ganzen Themenzweig oder einen Teil eines Themenzweigs ermöglichen. Um ein Thema zu abonnieren, sendet ein Client ein SUBSCRIBE-Paket und erhält im Gegenzug ein SUBACK-Paket. Wenn es eine zurückbehaltene Nachricht für das Thema gibt, erhält der neue Abonnent auch diese Nachricht.
• PING - Ein Client kann den Broker anpingen. Der Abonnent sendet ein PINGREQ-Paket und erhält als Antwort ein PINGRESP-Paket. Pings können verwendet werden, um sicherzustellen, dass die Verbindung noch funktioniert und dass die TCP-Sitzung nicht unerwartet von anderen Netzwerkgeräten wie einem Router oder Gateway geschlossen wurde.
• DISCONNECT - Ein Teilnehmer oder Herausgeber kann eine DISCONNECT-Nachricht an den Broker senden. Diese Nachricht teilt dem Broker mit, dass er keine Nachrichten mehr für einen Abonnenten senden oder in eine Warteschlange stellen muss und dass er keine Daten mehr von einem Herausgeber empfangen wird. Diese Art der Abschaltung ermöglicht es dem Client, sich mit der gleichen Client-Identität wie zuvor wieder zu verbinden. Wenn sich ein Client abmeldet, ohne eine Abmeldungsnachricht zu senden, wird sein letzter Wille an die Abonnenten gesendet

Sicherheit

Das ursprüngliche Ziel des MQTT-Protokolls war es, die kleinstmögliche und effizienteste Datenübertragung über teure, unzuverlässige Kommunikationsleitungen zu ermöglichen. Daher war die Sicherheit bei der Entwicklung und Implementierung von MQTT kein Hauptanliegen.

Es gibt jedoch einige Sicherheitsoptionen, die auf Kosten einer größeren Datenübertragung und eines größeren Platzbedarfs gehen.

• Netzwerksicherheit - Wenn das Netzwerk selbst gesichert werden kann, dann ist die Übertragung unsicherer MQTT-Daten irrelevant. In diesem Fall müssten Sicherheitsprobleme innerhalb des Netzes selbst auftreten, vielleicht durch einen bösartigen Akteur oder eine andere Form des Eindringens in das Netz.
• Benutzername und Passwort - MQTT erlaubt Benutzernamen und Passwörter für einen Client, um eine Verbindung mit einem Broker herzustellen. Leider werden die Benutzernamen und Passwörter im Klartext übertragen, um den Aufwand gering zu halten. Im Jahr 1999 war dies mehr als ausreichend, da das Abfangen einer Satellitenkommunikation für einen im Grunde genommen unwichtigen Sensormesswert untragbar schwierig gewesen wäre. Heutzutage ist es jedoch trivial, viele Arten der drahtlosen Netzwerkkommunikation abzufangen, was eine solche Authentifizierung nahezu nutzlos macht.
  Viele Anwendungsfälle erfordern einen Benutzernamen und ein Kennwort nicht zum Schutz vor böswilligen Akteuren, sondern um unbeabsichtigte Verbindungen zu vermeiden.
• SSL/TLS - Die offensichtliche Lösung für die Sicherung von Übertragungen zwischen Clients und Brokern ist die Implementierung von SSL/TLS, die auf TCP/IP aufbaut. Leider führt dies zu einem erheblichen Mehraufwand bei der ansonsten leichtgewichtigen Kommunikation.