1. Kurze Einführung

MQTT (Message Queuing Telemetry Transport) ist ein „leichtgewichtiges“ Kommunikationsprotokoll, das auf dem Publish/Subscribe-Modell basiert. Dieses Protokoll baut auf dem TCP/IP-Protokoll auf und wurde 1999 von IBM veröffentlicht. Der größte Vorteil von MQTT besteht darin, dass es verbundenen entfernten Geräten mit minimalem Code und begrenzter Bandbreite Echtzeit- und zuverlässige Messaging-Dienste bieten kann. Als Instant-Messaging-Protokoll mit geringem Overhead und geringer Bandbreitennutzung wird es häufig im Internet der Dinge, bei kleinen Geräten, in mobilen Anwendungen und anderen Bereichen eingesetzt.

MQTT ist ein Client-Server-basiertes Nachrichten-Publish/Subscribe-Transportprotokoll. Das MQTT-Protokoll ist leichtgewichtig, einfach, offen und leicht zu implementieren, wodurch es in einer sehr breiten Palette von Szenarien anwendbar ist. In vielen Fällen, einschließlich eingeschränkter Umgebungen, wie Maschine-zu-Maschine-Kommunikation (M2M) und Internet der Dinge (IoT). Es wird häufig in Sensoren eingesetzt, die über Satellitenverbindungen kommunizieren, in medizinischen Geräten, die gelegentlich eine Einwahlverbindung herstellen, in Smart Homes und in einigen miniaturisierten Geräten.

2. Design-Spezifikationen

Da die IoT-Umgebung sehr speziell ist, folgt MQTT den folgenden Designprinzipien:

  • (1) Schlank, ohne nicht wesentliche Funktionen hinzuzufügen;
  • (2) Publish/Subscribe-Modus (Pub/Sub), der die Nachrichtenübertragung zwischen Sensoren erleichtert;
  • (3) Ermöglicht Benutzern, Topics dynamisch zu erstellen, mit null Betriebs- und Wartungskosten;
  • (4) Das Übertragungsvolumen minimieren, um die Übertragungseffizienz zu verbessern;
  • (5) Faktoren wie geringe Bandbreite, hohe Latenz und instabile Netzwerke berücksichtigen;
  • (6) Kontinuierliche Sitzungskontrolle unterstützen;
  • (7) Davon ausgehen, dass die Rechenleistung des Clients sehr gering sein kann;
  • (8) Servicequalitätsmanagement bereitstellen;
  • (9) Davon ausgehen, dass Daten unbekannt sind, Typ und Format der übertragenen Daten nicht vorschreiben und Flexibilität bewahren.

3. Hauptmerkmale

Das MQTT-Protokoll ist für die Kommunikation zwischen entfernten Sensoren und Steuergeräten über unzuverlässige Netzwerke mit geringer Bandbreite konzipiert. Es besitzt folgende Hauptmerkmale:

  • (1) Verwendet das Publish/Subscribe-Nachrichtenmuster, um eine Eins-zu-viele-Nachrichtenveröffentlichung zu ermöglichen und Anwendungen zu entkoppeln.

    Dies ist dem XMPP sehr ähnlich, aber MQTT hat weit weniger Informationsredundanz als XMPP, weil XMPP XML-formatierte Texte zur Datenübertragung verwendet.

  • (2) Nachrichtenübertragung, die gegenüber dem Inhalt der Nutzdaten transparent ist.

  • (3) Verwendet TCP/IP, um Netzwerkverbindungen bereitzustellen.

    Mainstream-MQTT verwendet TCP-Verbindungen für Daten-Push, aber es gibt auch UDP-basierte Versionen, genannt MQTT-SN. Da diese beiden Versionen auf unterschiedlichen Verbindungsmethoden basieren, unterscheiden sich ihre Vor- und Nachteile naturgemäß.

  • (4) Es gibt drei Dienstgütestufen für die Nachrichtenveröffentlichung:

    "At most once": Die Nachrichtenveröffentlichung hängt vollständig vom zugrunde liegenden TCP/IP-Netzwerk ab. Nachrichtenverlust oder -duplizierung kann auftreten. Diese Stufe kann in Situationen wie Umwelt-Sensordaten verwendet werden; der Verlust eines Messwerts spielt keine Rolle, da bald ein zweites Senden erfolgt. Diese Methode wird hauptsächlich für Push-Benachrichtigungen in gewöhnlichen Apps verwendet. Wenn Ihr Smart-Gerät nicht online ist, wenn eine Nachricht gepusht wird, wird der Push nicht empfangen, und er wird auch nicht empfangen, wenn es wieder online geht.

    "At least once": stellt die Zustellung der Nachricht sicher, aber es kann zu Nachrichtenduplizierung kommen.

    "Exactly once": stellt sicher, dass die Nachricht genau einmal ankommt. Diese Stufe kann in einigen Abrechnungssystemen mit strengen Anforderungen verwendet werden. In Abrechnungssystemen können doppelte oder verlorene Nachrichten zu fehlerhaften Ergebnissen führen. Dieser Nachrichtenveröffentlichungsdienst mit höchster Qualität kann auch für Push-Benachrichtigungen in Instant-Messaging-Apps verwendet werden, um sicherzustellen, dass Benutzer die Nachricht genau einmal erhalten.

  • (5) Kleine Übertragungen mit minimalem Overhead (der Header mit fester Länge ist 2 Bytes), wodurch der Protokollaustausch minimiert wird, um den Netzwerkverkehr zu reduzieren.

    Deshalb heißt es in der Einführung, dass es sehr gut für die „Kommunikation zwischen Sensoren und Servern und die Informationserfassung im IoT-Bereich“ geeignet ist. Sie sollten wissen, dass die Rechenleistung und Bandbreite eingebetteter Geräte relativ gering sind, daher ist die Verwendung dieses Protokolls zur Übertragung von Nachrichten bestens geeignet.

  • (6) Verwendet die Last-Will-and-Testament-Funktion, um relevante Parteien über eine abnormale Trennung des Clients zu benachrichtigen.

    Last Will: Das ist der Willensmechanismus, der verwendet wird, um andere Geräte unter demselben Topic zu benachrichtigen, dass das Gerät, das den Willen gesendet hat, die Verbindung getrennt hat.

    Testament: Der Testament-Mechanismus, dessen Funktion ähnlich wie Last Will ist.

4. Prinzipien des MQTT-Protokolls

4.1 Implementierungsmethode des MQTT-Protokolls

Die Implementierung des MQTT-Protokolls erfordert Kommunikation zwischen Client und Server. Während der Kommunikation gibt es drei Rollen im MQTT-Protokoll: Publisher, Broker (Server) und Subscriber. Dabei sind sowohl Publisher als auch Subscriber Clients, der Message Broker ist der Server, und ein Publisher kann gleichzeitig auch ein Subscriber sein.

Von MQTT übertragene Nachrichten werden in zwei Teile unterteilt: Topic und Payload.

  • (1) Topic kann als der Nachrichtentyp verstanden werden. Nachdem ein Subscriber abonniert hat, empfängt er den Nachrichteninhalt (Payload) dieses Topics.
  • (2) Payload kann als der Inhalt der Nachricht verstanden werden und bezieht sich auf den konkreten Inhalt, den der Subscriber verwenden wird.

4.2 Netzwerkübertragung und Anwendungsnachrichten

MQTT konstruiert die zugrunde liegende Netzwerkübertragung: Es baut eine Verbindung vom Client zum Server auf und bietet zwischen beiden eine geordnete, verlustfreie, auf Byte-Streams basierende bidirektionale Übertragung.

Wenn Anwendungsdaten über das MQTT-Netzwerk gesendet werden, ordnet MQTT ihnen die zugehörige Quality of Service (QoS) und den Topic-Namen zu.

4.3 MQTT-Client

Eine Anwendung oder ein Gerät, das das MQTT-Protokoll verwendet, baut immer eine Netzwerkverbindung zum Server auf. Ein Client kann:

  • (1) Informationen veröffentlichen, die andere Clients abonnieren können;
  • (2) Nachrichten abonnieren, die von anderen Clients veröffentlicht werden;
  • (3) Anwendungsnachrichten abbestellen oder löschen;
  • (4) Die Verbindung zum Server trennen.

4.4 MQTT-Server

Der MQTT-Server wird auch als „Message Broker“ (Broker) bezeichnet. Er kann eine Anwendung oder ein Gerät sein. Er befindet sich zwischen dem Nachrichtenpublisher und den Abonnenten und kann:

  • (1) Netzwerkverbindungen von Clients annehmen;
  • (2) Von Clients veröffentlichte Anwendungsinformationen annehmen;
  • (3) Abonnement- und Abbestellungsanfragen von Clients verarbeiten;
  • (4) Anwendungsnachrichten an abonnierte Clients weiterleiten.

4.5 Abonnements, Themen und Sitzungen im MQTT-Protokoll

1. Abonnement

Ein Abonnement enthält einen Themenfilter und eine maximale Dienstgüte (Quality of Service, QoS). Ein Abonnement ist einer Sitzung zugeordnet. Eine Sitzung kann mehrere Abonnements enthalten. Jedes Abonnement in jeder Sitzung hat einen anderen Themenfilter.

2. Session

Nachdem jeder Client eine Verbindung mit dem Server hergestellt hat, wird er zu einer Sitzung, mit Zustandsinteraktion zwischen Client und Server. Eine Sitzung existiert über ein Netzwerk hinweg und kann sich auch über mehrere aufeinanderfolgende Netzwerkverbindungen zwischen Client und Server erstrecken.

3. Themenname

Ein Label, das an eine Anwendungsnachricht angehängt wird und mit den Abonnements auf dem Server übereinstimmt. Der Server sendet die Nachricht an jeden Client, dessen Abonnement mit dem Label übereinstimmt.

4. Themenfilter

Ein Platzhalterfilter für Themennamen, der in Abonnementausdrücken verwendet wird und mehrere Themen repräsentiert, auf die das Abonnement passt.

5. Nutzlast

Der spezifische Inhalt, der vom Nachrichtenabonnenten empfangen wird.

4.6 Methoden im MQTT-Protokoll

Das MQTT-Protokoll definiert einige Methoden (auch Aktionen genannt), um Operationen auf bestimmten Ressourcen darzustellen. Diese Ressource kann bereits vorhandene Daten oder dynamisch generierte Daten repräsentieren, abhängig von der Serverimplementierung. Im Allgemeinen beziehen sich Ressourcen auf Dateien oder Ausgaben auf dem Server. Die wichtigsten Methoden sind:

  • (1) Connect. Warten, bis eine Verbindung mit dem Server hergestellt ist.
  • (2) Disconnect. Warten, bis der MQTT-Client seine Arbeit abgeschlossen hat und die TCP/IP-Sitzung mit dem Server trennt.
  • (3) Subscribe. Warten, bis das Abonnement abgeschlossen ist.
  • (4) UnSubscribe. Warten, bis der Server das Abonnement des Clients für ein oder mehrere Themen abbestellt.
  • (5) Publish. Der MQTT-Client sendet eine Nachrichtenanfrage und kehrt nach Abschluss des Sendens zum Anwendungsthread zurück.

5. Paketstruktur des MQTT-Protokolls

Im MQTT-Protokoll besteht ein MQTT-Paket aus drei Teilen: Fixed Header, Variable Header und Payload. Die Struktur des MQTT-Pakets ist wie folgt:

  • (1) Fixed Header. In allen MQTT-Paketen vorhanden, gibt den Pakettyp und die Gruppenklassenkennung des Pakets an.
  • (2) Variable Header. In einigen MQTT-Paketen vorhanden. Der Pakettyp bestimmt, ob der Variable Header vorhanden ist und welchen konkreten Inhalt er hat.
  • (3) Payload. In einigen MQTT-Paketen vorhanden, repräsentiert den konkreten Inhalt, den der Client empfängt.

5.1 MQTT Fixed Header

Der feste Header ist in allen MQTT-Paketen vorhanden, und sein Aufbau ist wie folgt:

5.1.1 MQTT-Pakettyp

Position: Bits 7-4 in Byte 1.

Es ist ein 4-Bit-Wert ohne Vorzeichen. Die Typen, Werte und Beschreibungen sind wie folgt:

5.1.2 Flags

Position: Bits 3-0 in Byte 1.

In Nachrichtentypen, die keine Flags verwenden, werden die Flags als reservierte Bits behandelt. Wenn ein ungültiges Flag empfangen wird, muss der Empfänger die Netzwerkverbindung schließen:

(1) DUP: Duplikat einer veröffentlichten Nachricht. Wird verwendet, um eine zuverlässige Übertragung von Nachrichten zu gewährleisten. Wenn auf 1 gesetzt, wird die MessageId im nachfolgenden variablen Header hinzugefügt, und eine Bestätigungsantwort ist erforderlich, um sicherzustellen, dass die Nachrichtenübertragung abgeschlossen wird, aber es kann nicht verwendet werden, um doppeltes Senden von Nachrichten zu erkennen.

(2) QoS: Quality of Service für veröffentlichte Nachrichten, d. h. die Anzahl, wie oft die Zustellung von Nachrichten garantiert wird.

Ø00：最多一次，即：<=1

Ø01：至少一次，即：>=1

Ø10：一次，即：=1

Ø11：预留

(3) RETAIN: Publish-Retain-Flag. Gibt an, dass der Server diese gepushten Informationen behalten soll. Wenn ein neuer Abonnent erscheint, sende diese Nachricht an ihn; wenn nicht gesetzt, gib sie frei, nachdem sie an den aktuellen Abonnenten gesendet wurde.

5.1.3 Verbleibende Länge

Position: Byte 2.

Das zweite Byte des festen Headers wird verwendet, um die Gesamtgröße des variablen Headers und der Payload zu speichern, aber es wird nicht direkt gespeichert. Dieses Byte ist erweiterbar. Sein Speichermechanismus: Die ersten 7 Bits werden verwendet, um die Länge zu speichern, und das letzte Bit wird als Kennung verwendet. Wenn das letzte Bit 1 ist, bedeutet das, dass die Länge nicht ausreicht, und ein zweites Byte ist erforderlich, um weiter zu speichern. Zum Beispiel: Wenn die berechnete folgende Größe 0 ist

5.2 Variabler MQTT-Header

Ein MQTT-Paket enthält einen variablen Header, der sich zwischen dem festen Header und der Payload befindet. Der Inhalt des variablen Headers variiert je nach Pakettyp. Eine häufigere Anwendung ist die als Paketkennung:

Viele Pakettypen enthalten ein 2-Byte-Paketkennungsfeld. Zu diesen Pakettypen gehören: PUBLISH (QoS > 0), PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK.

5.3 Payload-Nachrichtenkörper

Der Payload-Nachrichtenkörper ist der dritte Teil eines MQTT-Pakets und enthält Nachrichten von vier Typen: CONNECT, SUBSCRIBE, SUBACK, UNSUBSCRIBE:

  • (1) CONNECT: Der Nachrichtenkörper enthält hauptsächlich die ClientID des Clients, das abonnierte Topic, die Nachricht sowie Benutzername und Passwort.
  • (2) SUBSCRIBE: Der Nachrichtenkörper enthält eine Reihe zu abonnierender Topics und die QoS.
  • (3) SUBACK: Der Nachrichtenkörper ist die Bestätigung und Antwort des Servers auf die von SUBSCRIBE angeforderten Topics und QoS.
  • (4) UNSUBSCRIBE: Der Nachrichtenkörper enthält die zu abonnierenden Topics.

Mehr Inhalte

Original-Link: https://blog.csdn.net/qq_28877125/article/details/78325003