1. Das Prinzip des MQTT-Protokolls

Das MQTT-Protokoll ist ein IoT-Kommunikationsprotokoll, das auf Publish | Subscribe basiert

Höhepunkte:

1. Einfach und leicht umzusetzen

2. Unterstützen Sie die QoS-Servicequalität

3. Kleine Nachrichtengröße (MQTT-Protokoll basiert auf dem TCP/IP-Protokoll)

Abonnentenmuster veröffentlichen:

Der Client muss dieses Thema nur abonnieren. Wenn andere Clients eine Nachricht an den Server senden möchten, kann der Client die Nachricht empfangen und eine Echtzeitkommunikation realisieren.

Anforderungsantwortmodus:

Anforderungsantwortmodus: Der Client sendet eine Anforderung an den Server und der Server gibt nach Erhalt der Anforderung eine Antwort an den Client zurück

2. Einführung in das MQTT-Protokoll

(Message Queuing Telemetry Transport, Nachrichtenwarteschlange, Telemetrieübertragungsprotokoll) ist ein „leichtgewichtiges“ Kommunikationsprotokoll, das auf dem Publish/Subscribe-Modell (Publish/Subscribe) basiert und auf dem 1999 von IBM entwickelten TCP/IP-Protokoll aufbaut freigegeben. Der größte Vorteil von MQTT besteht darin, dass es mit sehr wenig Code und begrenzter Bandbreite zuverlässige Echtzeit-Nachrichtendienste für entfernte verbundene Geräte bereitstellen kann.
MQTT ist ein Client-Server-basiertes Transportprotokoll zum Veröffentlichen/Abonnieren von Nachrichten Das MQTT-Protokoll ist leichtgewichtig, einfach, offen und leicht zu implementieren. Diese Eigenschaften machen es weit verbreitet. In vielen Fällen auch in eingeschränkten Umgebungen wie der Maschine-zu-Maschine-Kommunikation (M2M) und dem Internet der Dinge (loT). Es wird häufig in Kommunikationssensoren über Satellitenverbindungen, medizinischen Geräten mit gelegentlicher Einwahl, Smart Homes und einigen miniaturisierten Geräten (weit verbreitet im Knotenserver-Internet der Dinge) verwendet.

3. Spezifikation des MQTT-Protokolldesigns

Optimiert, ohne das Hinzufügen überflüssiger Funktionen;
Der Publish/Subscribe-Modus (Pub/Sub) erleichtert die Nachrichtenübertragung zwischen Sensoren und entkoppelt den Client/Server-Modus. Der Vorteil besteht darin, dass er die Existenz der anderen Partei (IP/Port) nicht im Voraus kennen muss und muss gleichzeitig laufen
Ermöglichen Sie Benutzern die dynamische Erstellung von Themen (keine Notwendigkeit, Themen vorab zu erstellen), ohne Betriebs- und Wartungskosten.
Minimieren Sie das Transfervolumen, um die Transfereffizienz zu verbessern
Berücksichtigen Sie Faktoren wie geringe Bandbreite, hohe Latenz und instabile Netzwerke.
Unterstützt die kontinuierliche Sitzungsaufbewahrung und -kontrolle (Heartbeat-Protokoll)
Beachten Sie, dass die Rechenleistung des Clients möglicherweise gering ist
Bereitstellung von Servicequalitätsmanagement (Quality of Service Level: QoS):
Die Art und das Format der übermittelten Daten sind zur Wahrung der Flexibilität nicht erforderlich (bezogen auf die Geschäftsdaten der Anwendungsschicht).

4. Hauptmerkmale des MQTT-Protokolls

Offenes Nachrichtenprotokoll, einfach und leicht zu implementieren.
Verwenden Sie den Publish/Subscribe-Nachrichtenmodus, um eine Eins-zu-Viele-Nachrichtenveröffentlichung bereitzustellen und Anwendungsprogramme zu entkoppeln.
Nachrichtenübertragung, die den Inhalt der Nutzlast (vom Protokoll übertragene Anwendungsdaten) maskiert.
Basierend auf einer TCP/IP-Netzwerkverbindung bietet es eine geordnete, verlustfreie, bidirektionale Verbindung .
Das Mainstream-MQTT basiert auf der TCP-Verbindung für den Daten-Push, es gibt jedoch auch eine UDP-basierte Version namens MQTT-SN. Da diese beiden Varianten auf unterschiedlichen Verbindungsmethoden basieren, sind ihre Vor- und Nachteile natürlich unterschiedlich.
Aufgrund der unterschiedlichen Verbindungsmethoden sind die Vor- und Nachteile natürlich unterschiedlich.
Unterstützung der Nachrichtenqualität des Dienstes (QoS), zuverlässige Übertragungsgarantie; es gibt drei Dienstqualitäten für die Nachrichtenfreigabe:
QoSO : „Höchstens einmal“, die Nachrichtenfreigabe hängt vollständig vom zugrunde liegenden TCP/IP-Netzwerk ab. Es kann zu Nachrichtenverlust oder Duplikaten kommen. Diese Ebene kann in den folgenden Situationen verwendet werden: Umgebungssensordaten. Es spielt keine Rolle, ob ein Lesedatensatz verloren geht, da in naher Zukunft ein zweiter Versand erfolgen wird. Diese Methode dient hauptsächlich zum Pushen gewöhnlicher APPs. Wenn Ihr Smart-Gerät zum Zeitpunkt des Pushens der Nachricht nicht mit dem Internet verbunden ist, wurde der Push in der Vergangenheit nicht empfangen und wird auch nicht empfangen, wenn es mit dem Internet verbunden ist wieder.
QoS1 : „Mindestens einmal“, um sicherzustellen, dass die Nachricht ankommt, es kann jedoch zu Nachrichtenduplikaten kommen.
QoS2 : „Nur einmal“, um sicherzustellen, dass die Nachricht einmal ankommt. Diese Stufe kann in einigen Abrechnungssystemen mit strengen Anforderungen verwendet werden. In Abrechnungssystemen können doppelte oder fehlende Nachrichten zu falschen Ergebnissen führen. Dieser Nachrichtenveröffentlichungsdienst höchster Qualität kann auch für Instant Messaging APP Push verwendet werden, um sicherzustellen, dass Benutzer nur einmal empfangen.
1 Byte fester Header, 2 Byte Heartbeat-Nachricht, minimiert den Übertragungsaufwand und den Protokollaustausch und reduziert effektiv den Netzwerkverkehr.
Deshalb heißt es in der Einleitung, dass es sich sehr gut für „im Bereich des Internets der Dinge, der Kommunikation zwischen Sensoren und Servern und der Sammlung von Informationen“ eignet. Es ist wichtig zu wissen, dass die Rechenleistung und Bandbreite eingebetteter Geräte sind relativ schwach. Die Verwendung dieses Protokolls zur Übertragung von Nachrichten ist perfekt.
Online-Statusanzeige: Nutzen Sie die Funktionen „Letzter Wille“ und „Testament“, um relevante Parteien über den Mechanismus einer ungewöhnlichen Kundenunterbrechung zu informieren.
Letzter Wille: Hierbei handelt es sich um den Mechanismus des letzten Willens, der verwendet wird, um andere Geräte unter demselben Thema darüber zu informieren, dass das Gerät, das den letzten Willen gesendet hat, getrennt wurde.
Testament: Willensmechanismus, in seiner Funktion dem letzten Testament ähnlich.

Fünftens MQTT-Anwendungsfeld

IoT-M2M-Kommunikation, IoT-Big-Data-Erfassung
Android-Nachrichten-Push, WEB-Nachrichten-Push
Mobiles Instant Messaging, z. B. Facebook Messenger
Intelligente Hardware, intelligente Möbel, intelligente Geräte
Fahrzeugvernetzungskommunikation, Sammlung von Stromtankstellen
Smart City, Telemedizin, Fernunterricht
Märkte der Energie-, Öl- und Energieindustrie

6. Implementierung des MQTT-Protokolls

Die Implementierung des MQTT-Protokolls erfordert den Abschluss der Kommunikation zwischen Client und Server. Während des Kommunikationsprozesses gibt es im MQTT-Protokoll drei Identitäten: Herausgeber, Broker (Server) und Abonnent. Unter diesen sind der Herausgeber und der Abonnent der Nachricht Clients, der Nachrichtenagent ist der Server und der Herausgeber der Nachricht kann gleichzeitig der Abonnent sein.

Die von MQTT übertragene Nachricht ist in zwei Teile unterteilt: Thema (Topic) und Nutzlast (Payload):
(1) Thema: Es kann als Nachrichtentyp verstanden werden. Nachdem der Abonnent abonniert (Abonnieren) hat, erhält er den Nachrichteninhalt (Nutzlast) des Themas)
(2) Nutzlast: Kann als Inhalt der Nachricht verstanden werden, der sich auf den spezifischen Inhalt bezieht, der vom Abonnenten verwendet werden soll

Netzwerktransport- und Anwendungsnachrichten

MQTT baut die zugrunde liegende Netzwerkübertragung auf: Es stellt eine Client-zu-Server-Verbindung her und sorgt so für eine geordnete, verlustfreie, Bytestream-basierte bidirektionale Übertragung zwischen beiden.
Wenn Anwendungsdaten über das MQTT-Netzwerk gesendet werden, ordnet MQTT die zugehörige Servicequalität (QoS) dem Themennamen (Topic) zu.

MQTT-Client

Eine Anwendung oder ein Gerät, das das MQTT-Protokoll verwendet und immer eine Netzwerkverbindung zu einem Server herstellt. Kunden können:

(1) Veröffentlichen Sie Informationen, die andere Kunden abonnieren können
(2) Abonnieren Sie Nachrichten, die von anderen Kunden veröffentlicht wurden
(3) Nachrichten zum Abbestellen oder Löschen der App
(4) Trennen Sie die Verbindung zum Server

MQTT-Serverseite

Der MQTT-Server wird „Nachrichtenbroker“ (Broker) genannt und kann eine Anwendung oder ein Gerät sein. Er befindet sich zwischen dem Herausgeber der Nachricht und dem Abonnenten. Er kann:

(1) Akzeptieren Sie Netzwerkverbindungen von Kunden;
(2) Akzeptieren Sie von Kunden freigegebene Anwendungsinformationen
(3) Bearbeitung von An- und Abmeldeanfragen von Kunden
(4) Leiten Sie Anwendungsnachrichten an abonnierte Clients weiter

Pub/Sub, Themen, Sitzungen

MQTT basiert auf dem Publish/Subscribe- Modus für Kommunikation und Datenaustausch, der sich grundlegend vom HTTP- Request .Modus Response-
/ zum Abonnieren eines Themas (Topic) . Nach erfolgreicher Anmeldung leitet der Nachrichtenserver die Nachrichten unter dem Thema an die Themenfilter aller Abonnenten diejenigen ohne Platzhalter werden zu Themennamen

Herausgeber können Nachrichten nur zu Themennamen veröffentlichen und Abonnenten können mehrere Themennamen mit Platzhaltern versehen, indem sie Themenfilter abonnieren

Sitzung (Sitzung)
Nachdem jeder Client eine Verbindung mit dem Server hergestellt hat, handelt es sich um eine Sitzung, und es findet eine zustandsbehaftete Interaktion zwischen dem Client und dem Server statt. Sitzungen bestehen über ein Netzwerk und können sich auch über mehrere aufeinanderfolgende Netzwerkverbindungen zwischen einem Client und einem Server erstrecken.

Methoden im MQTT-Protokoll

Einige Methoden (auch Aktionen genannt) sind im MQTT-Protokoll definiert, um Vorgänge auf bestimmten Ressourcen darzustellen. Diese Ressource kann je nach Serverimplementierung bereits vorhandene Daten oder dynamisch generierte Daten darstellen. Normalerweise bezieht sich eine Ressource auf eine Datei oder Ausgabe auf einem Server. Die wichtigsten Methoden sind:

(1) VERBINDEN: Der Client stellt eine Verbindung zum Server her
(2) CONNACK: Verbindungsbestätigung
(3) VERÖFFENTLICHEN: Eine Nachricht veröffentlichen
(4) PUBACK: Nachrichtenbestätigung veröffentlichen
(5) PUBREC: Die veröffentlichte Nachricht wurde empfangen
(6) PUBREL: Die veröffentlichte Nachricht wurde veröffentlicht
(7) PUBCOMP: Veröffentlichung abgeschlossen
(8) ABONNIEREN: Abonnementanfrage
(9) SUBACK: Abonnementbestätigung
(10) ABMELDUNG: Abmelden
(11) UNSUBACK: Abmeldebestätigung
(12) PINGREQ: Der Client sendet einen Heartbeat
(13) PINGRESP: Server-Heartbeat-Antwort
(14) TRENNEN: Trennen
(15) AUTH: Authentifizierung

Paketstruktur des MQTT-Protokolls

Im MQTT-Protokoll besteht ein MQTT-Paket aus drei Teilen: festem Header (fester Header), variablem Header (variabler Header) und Nachrichtentext (Nutzlast).
Die MQTT-Paketstruktur ist wie folgt:

(1) Fester Header. Es ist in allen MQTT-Datenpaketen vorhanden und gibt den Datenpakettyp und die Gruppierungsklassenkennung des Datenpakets an, z. B. Verbindung, Veröffentlichung, Abonnement, Heartbeat usw. Darunter ist ein fester Header erforderlich, und alle Arten von MQTT-Protokollen müssen feste Header enthalten.
(2) Variablenkopf (Variablenkopf). Es ist in einigen MQTT-Datenpaketen vorhanden und der Datenpakettyp bestimmt, ob der variable Header vorhanden ist und welchen spezifischen Inhalt er hat. Der Variablenheader bedeutet nicht optional, sondern bedeutet, dass dieser Teil in einigen Protokolltypen vorhanden ist und in einigen Protokollen nicht vorhanden ist.
(3) Nachrichtentext (Payload). Es ist in einigen MQTT-Paketen vorhanden und gibt den spezifischen Inhalt an, den der Client empfangen hat. Wie bei variablen Headern gibt es bei einigen Protokolltypen Nachrichteninhalte und bei einigen Protokolltypen keinen Nachrichteninhalt.

Fester Header

Der feste Header ist in allen MQTT-Paketen vorhanden.
Der feste Header besteht aus zwei Teilen:
dem ersten Byte (Byte 1),
der Länge der verbleibenden Nachricht (ab dem zweiten Byte beträgt die Länge 1-4 Byte) und dem
Rest Länge ist die Anzahl der Bytes der Inhaltslänge, die im aktuellen Paket verbleiben, einschließlich variabler Header und Daten in der Nutzlast. Die verbleibende Länge umfasst nicht die Bytes, die zum Codieren der verbleibenden Länge verwendet werden.
Die verbleibende Länge wird mithilfe einer Struktur variabler Länge codiert, die ein einzelnes Byte zur Darstellung der Werte 0-127 verwendet. Werte größer als 127 werden wie folgt behandelt. Die unteren 7 Bits jedes Bytes werden zum Codieren von Daten verwendet, und das höchste Bit wird verwendet, um anzuzeigen, ob nachfolgende Bytes vorhanden sind. Somit kann jedes Byte 128 Werte plus ein Identifikationsbit kodieren. Die verbleibende Länge kann durch bis zu vier Bytes repräsentiert werden.

Position des Datenpakettyps
: 7-4 Bits im ersten Byte (Byte 1) sind (Bit[7-4]) und identifizieren den 4-Bit-Wert ohne Vorzeichen

Der Typ der Nachricht wird durch die oberen 4 Bits des ersten Bytes bestimmt. Die 4 Bits können 16 Typen bestimmen, von denen 0000 und 1111 reservierte Felder sind. Die MQTT-Nachrichtentypen sind wie folgt:

Flag-
Position: 0-3 Bits (Bit[3-0]) im ersten Byte. Dies bedeutet, dass das Byte-Bit Bit[3-0] als Identifikation der Nachricht verwendet wird.
Die unteren 4 Bits (Bit3-Bit0) des ersten Bytes werden verwendet, um das Steuerfeld bestimmter Nachrichtentypen anzuzeigen. Tatsächlich verfügen nur wenige Nachrichtentypen über Steuerbits, wie in der folgenden Abbildung dargestellt:

(1): Unter diesen ist Bit[3] das Dup-Feld. Wenn der Wert 1 ist, bedeutet dies, dass es sich bei dem Datenpaket um eine wiederholte Nachricht handelt. Andernfalls handelt es sich bei dem Datenpaket um die erste veröffentlichte Nachricht (2): Bit[2 -1
] Für das QoS-Feld:
Wenn sowohl Bit 1 als auch Bit 2 0 sind, bedeutet dies QoS 0: höchstens einmal;
wenn Bit 1 1 ist, bedeutet es QoS 1: mindestens einmal;
wenn Bit 2 1 ist, bedeutet dies QoS 2: nur einmal
; Wenn sowohl Bit 1 als auch Bit 2 auf 1 gesetzt sind, betrachtet der Client oder Server dies als illegale Nachricht und schließt die aktuelle Verbindung.
MQTT-Nachrichten-QoS
Die Servicequalität (QoS) von MQTT-Nachrichtenveröffentlichungen erfolgt nicht Ende-zu-Ende, sondern zwischen dem Client und dem Server. Die QoS-Stufe des Abonnenten, der die MQTT-Nachricht empfängt, hängt letztendlich von der QoS der veröffentlichten Nachricht und der QoS des Themenabonnements QoS ab
: QoS bezieht sich auf die Dienstqualität zwischen dem Client und dem Server

Variabler Header

Mit variablen Headern sind variable Nachrichtenheader gemeint. Einige Nachrichtentypen enthalten variable Header, andere nicht. Der variable Header liegt zwischen dem festen Header und dem Nachrichteninhalt und sein Inhalt variiert je nach Nachrichtentyp

Protokollversion
Ein 1-Bit-Wert ohne Vorzeichen, der die Versionsebene des Clients darstellt. Version 3.1.1
MQTT-Sitzung
Wenn der MQTT-Client eine CONNECT-Anfrage an den Server initiiert, kann die Sitzung über das Flag „Clean Session“ gesetzt werden.
„Clean Session“ ist auf 0 gesetzt, was bedeutet, dass eine dauerhafte Sitzung erstellt wird. Wenn der Client die Verbindung trennt, behält und speichert die Sitzung weiterhin Offline-Nachrichten, bis die Sitzung abläuft und sich abmeldet.
„Clean Session“ ist auf 1 gesetzt, was bedeutet, dass eine neue temporäre Sitzung erstellt wird. Wenn der Client die Verbindung trennt, wird die Sitzung automatisch zerstört.
Will Flag /Will QoS/Will Retain Will Flag: Will QoS: Nachrichtenqualität der letzten Wörter
Will Retain: Letzte Worte zum Beibehalten des Zustands Keep Alive-Timer (Heartbeat-Dauer)

Heartbeat-Protokoll:

Maximales Zeitintervall des Keep Alive-Timers

Nachrichtentext (Payload)

Einige Nachrichtentypen enthalten Payload, und Payload bedeutet Nachrichtenträger.
Beispielsweise bezieht sich Payload in PUBLISH auf den Nachrichteninhalt (von einer Anwendung veröffentlichter Nachrichteninhalt). Die Nutzlast von CONNECT enthält Informationen wie Client-ID, Will-Thema, Will-Nachricht, Benutzername, Passwort usw.
Die Arten von Nachrichten, die die Nutzlast enthalten, sind wie folgt:

Nutzlast ist der Inhalt der Nachricht und erscheint nur in bestimmten Nachrichtentypen. Inhalt und Format variieren auch je nach Nachrichtentyp. Insbesondere
enthalten verschiedene Nachrichtentypen unterschiedliche Nutzlasten. Bitte überprüfen Sie die offizielle Dokumentation.

Beschreiben Sie kurz das Konzept des MQTT-Protokolls