TechSchool

 
  MQTT-3.1.1-CN  1 
 
MQTT Protokoll 3.1.1 chinesische Version 
OASIS Standard 
2014 Jahr 10 Monat 29 Tag 
Link zur Spezifikation 
aktuelle Version： 
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.doc (Autoritative) 
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html 
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf 
vorherigeVersion: 
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/cos01/mqtt-v3.1.1-cos01.doc (Verbindlich) 
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/cos01/mqtt-v3.1.1-cos01.html 
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/cos01/mqtt-v3.1.1-cos01.pdf 
neueste Version： 
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.doc (Amaßgeblich) 
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html 
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.pdf 
Technisches KomiteeKomitee: 
Standards für strukturierte Informationenfördernde Organisation MQTT Technisches Komitee 
Vorsitzender： 
Raphael·J· Cohen (raphael.cohn@stormmq.com), Einzelperson 
Richard·J· Koppen (coppen@uk.ibm.com), IBM 
Bearbeiten： 
Andrew Banks (Andrew_Banks@uk.ibm.com), IBM 
Rahul Gupta (rahul.gupta@us.ibm.com), IBM 
Verwandte Dokumentation： 
Diese Spezifikation steht in Zusammenhang mit diesem： 
  MQTT und NIST Netzwerksicherheits-Framework 1.0 Version. Herausgeber sind Jeff Brown und Louis·Philip· Lamule. Neueste Version
Dies: http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-
v1.0.html. 
Zusammenfassung： 
MQTT ist einClient-DienstDie Entwicklung der EndarchitekturStoff/Abonnementmodelldas Nachrichtentransportprotokoll.Seine Designphilosophie istleichtgewichtig,offen、
Einfache、Spezifikation，DaherEinfach zu implementieren.Diese Eigenschaften machenEs ist für viele Szenarien nützlichist eine sehr gute Wahl, einschließlicheingeschränkter Umgebungen wie
Maschine-zu-Maschine-KommunikationGlauben (M2M）und IoTNetzwerkumgebung (IoT），DieseDas Szenario erfordert sehr wenig CodeCode-Kapselung oder NetzwerkNetzwerkbandbreite
Sehr teuer. 
dieses ProtokollLäuftin TCP/IP, oderAndere bieten geordnete, zuverlässige, bidirektionaleverbundene Netzwerkverbindungan. Es hat die folgendendie folgenden Funktionen: 
  unter Verwendung des Publish/-Subscription-Nachrichtenmusters, daseine Ein-zu-viele-Nachrichtenverteilungund eine Entkopplung zwischen Anwendungenbietet. 
  Die Nachrichtenübertragung erfordert nichtdie Kenntnis des Nutzlastinhalts。 
  Bietet drei Stufen derDienstgüte:. 

 
  MQTT-3.1.1-CN  2 
  “höchstens einmal”, so viel wie die Betriebsumgebung leisten kann, wobei maximaler Aufwand betrieben wird, um Nachrichten zuzustellen.Nachrichten können verloren gehen.Zum Beispiel,Dies
Die Stufe kann verwendet werden fürUmweltsensordaten,Einzelner DatenverlustVerlust spielt keine Rolle,weilbaldErneut senden. 
   “mindestens einmal”, wodurch sichergestellt wird, dass Nachrichten ankommen könnenErreichen,Aberkönnen sich wiederholen. 
   “nur einmal”，GarantieEine Nachricht wird nur einmal zugestellt. Zum Beispiel,DiesDie Stufe kann verwendet werden ineinem Abrechnungssystemin, wenn hier
Nachrichtenduplizierung oder -verlustführt zu einer falschenGebühr. 
  Sehr geringer Übertragungsaufwandund Protokolldatenaustausch, minimieren denNetzwerkverkehr weitestgehend. 
  Eine abnormale Verbindungstrennung tritt aufWenn sie auftritt, kann eine Benachrichtigung erfolgenan relevante Parteien. 
 
Status: 
Dieses Dokument wurde zuletzt OASIS Mitglieder inDas oben angegebene endgültige Datumüberarbeitet oder genehmigt.die Genehmigungsstufe ebenfallsOben aufgeführt.wenn
Um die aktuellste Version dieses Dokuments zu sehendie neue Revision, bitteprüfen Sie die oben genannte 
neueste Version
 Ort. Erstellt vom technischen Komiteeandere Revisionen undandere Technologien
Technische Dokumente sind alle hier aufgelistetUnter:https://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=mqtt#technical 。 
Mitglieder des technischen KomiteesKommentare zu dieser SpezifikationDiskussionen sollten an das technische Komitee gesendet werdenMailingliste des KomiteesTabelle. Andere sollten sendenKommentare an das technische Komitee
Die öffentlichen Kommentare des KomiteesListe, Methodeist PunktKlicken Sie auf das technische Komiteeder Website des Verbands Kommentare senden Schaltfläche,Die Webadresse ist 
https://www.oasis-open.org/committees/mqtt/ 。 
Zur Implementierung dieser Spezifikationwesentliche Aufgabenob ein Patent offenbart wurde,und andere spezialisierteInformationen bezüglich der LizenzbedingungenAtem, bitte beziehen Sie sich auf die technische
Website des technischen KomiteesAbschnitt zu geistigem Eigentum（(https://www.oasis-open.org/committees/mqtt/ipr.php）。 
ReferenzformatFormular: 
Beim Zitieren dieser Spezifikation solltesollten Sie das folgendeZitierformat verwenden: 
[mqtt-v3.1.1] 
MQTT Version 3.1.1. Bearbeitet von Andrew Banks und Rahul Gupta. 29. Oktoberer 2014. OASIS 
Standard. http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html. Neueste Version: 
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html. 
   

MQTT-3.1.1-CN 3

 Dokumentlinks

 MQTT Protokoll 3.1.1 chinesischesÜbersetzungsprojekt

 MQTT Protokoll 3.1.1 chinesische Version PDF

 Revisionsverlauf

Ausgabe Buch

Tag Zeitraum

Versionshinweise

1.0.0

2015-07-30

Alle Texte übersetzen,die erste Überprüfung abschließen, öffentlich veröffentlicht alserste Ausgabe

1.0.1

2015-10-22

Mehrere typografische Fehler korrigieren,mehrere unübersetzteübersetzte Texte ergänzen

 schließenfür den Übersetzer

 GitHub

 Blog

 E-Mail

 
  MQTT-3.1.1-CN  4 
Verzeichnis 
Übersicht ...................................................................................................................................................... 8 
1 MQTT Organisatorische Struktur des Protokolls ........................................................................................................................ 8 
2 Begriff ..................................................................................................................................................... 8 
3 normative Referenzen .............................................................................................................................................. 9 
4 nicht-normative ReferenzenVerwendung ........................................................................................................................................ 10 
5 Datendarstellung ............................................................................................................................................ 12 
5.1 BinärBit .................................................................................................................................... 12 
5.2 IntegerWert .................................................................................................................................... 12 
5.3 UTF-8 codierte Zeichenkette ..................................................................................................................... 12 
6 Redaktionelle Konventionen ............................................................................................................................................ 13 
MQTT SteuerpaketNachrichtenformat ........................................................................................................................... 14 
1 MQTT Struktur von Steuernachrichten ...................................................................................................................... 14 
2 Fester Header ............................................................................................................................................ 14 
2.1 MQTT Typen von Steuernachrichten .............................................................................................................. 14 
2.2 Flags ........................................................................................................................................... 15 
2.3 VerbleibendeLänge .................................................................................................................................... 16 
3 Variabler Header ............................................................................................................................................ 17 
3.1 NachrichtenIdentifikatoren ................................................................................................................................. 17 
4 payload ............................................................................................................................................ 19 
MQTT SteuerpaketText .................................................................................................................................. 20 
1 CONNECT – Mit dem Server verbinden .................................................................................................................. 20 
1.1 FesterHeader .................................................................................................................................... 20 
1.2 VariablerHeader .................................................................................................................................... 20 
1.3 GültigeNutzlast .................................................................................................................................... 26 
1.4 response ........................................................................................................................................... 27 
2 CONNACK – bestätigenVerbindungsanfrageFinden .............................................................................................................. 28 
2.1 FesterHeader .................................................................................................................................... 28 
2.2 VariablerHeader .................................................................................................................................... 28 
2.3 GültigeNutzlast .................................................................................................................................... 30 
3 PUBLISH – Nachricht veröffentlichen ........................................................................................................................ 30 
3.1 FesterHeader .................................................................................................................................... 30 
3.2 VariablerHeader .................................................................................................................................... 32 
3.3 GültigeNutzlast .................................................................................................................................... 33 
3.4 response ........................................................................................................................................... 33 
3.5 action ........................................................................................................................................... 33 
4 PUBACK –Veröffentlichungsbestätigung .......................................................................................................................... 33 
4.1 FesterHeader .................................................................................................................................... 33 
4.2 VariablerHeader .................................................................................................................................... 34 
4.3 GültigeNutzlast .................................................................................................................................... 34 

 
  MQTT-3.1.1-CN  5 
4.4 action ........................................................................................................................................... 34 
5 PUBREC – sendenVeröffentlichung empfangen (QoS 2, ersterSchritt) ........................................................................................ 34 
5.1 FesterHeader .................................................................................................................................... 34 
5.2 VariablerHeader .................................................................................................................................... 34 
5.3 GültigeNutzlast .................................................................................................................................... 35 
5.4 action ........................................................................................................................................... 35 
6 PUBREL – Veröffentlichungfreigeben (QoS 2, zweiterSchritt) ......................................................................................... 35 
6.1 FesterHeader .................................................................................................................................... 35 
6.2 VariablerHeader .................................................................................................................................... 35 
6.3 GültigeNutzlast .................................................................................................................................... 36 
6.4 action ........................................................................................................................................... 36 
7 PUBCOMP – sendenVeröffentlichung abgeschlossen (QoS 2, Schritt 3) ..................................................................................... 36 
7.1 FesterHeader .................................................................................................................................... 36 
7.2 VariablerHeader .................................................................................................................................... 36 
7.3 GültigeNutzlast .................................................................................................................................... 36 
7.4 action ........................................................................................................................................... 36 
8 SUBSCRIBE - Abonnement-Thema ................................................................................................................... 37 
8.1 FesterHeader .................................................................................................................................... 37 
8.2 VariablerHeader .................................................................................................................................... 37 
8.3 GültigeNutzlast .................................................................................................................................... 37 
8.4 response ........................................................................................................................................... 39 
9 SUBACK – Abonnementbestätigung ......................................................................................................................... 40 
9.1 FesterHeader .................................................................................................................................... 40 
9.2 VariablerHeader .................................................................................................................................... 40 
9.3 GültigeNutzlast .................................................................................................................................... 41 
10 UNSUBSCRIBE –Kündigung desAbonnements ............................................................................................................ 41 
10.1 Fester Header .................................................................................................................................. 42 
10.2 Variabler Header .................................................................................................................................. 42 
10.3 payload .................................................................................................................................. 42 
10.4 response ......................................................................................................................................... 43 
11 UNSUBACK – Kündigung des AbonnementsBestätigung .......................................................................................................... 43 
11.1 Fester Header .................................................................................................................................. 44 
11.2 Variabler Header .................................................................................................................................. 44 
11.3 payload .................................................................................................................................. 44 
12 PINGREQ – Heartbeat-Anfrage ..................................................................................................................... 44 
12.1 Fester Header .................................................................................................................................. 44 
12.2 Variabler Header .................................................................................................................................. 45 
12.3 payload .................................................................................................................................. 45 
12.4 response ......................................................................................................................................... 45 
13 PINGRESP – Heartbeat-Antwort ................................................................................................................... 45 
13.1 Fester Header .................................................................................................................................. 45 

 
  MQTT-3.1.1-CN  6 
13.2 Variabler Header .................................................................................................................................. 45 
13.3 payload .................................................................................................................................. 45 
14 DISCONNECT –Verbindung trennen............................................................................................................... 45 
14.1 Fester Header .................................................................................................................................. 46 
14.2 Variabler Header .................................................................................................................................. 46 
14.3 payload .................................................................................................................................. 46 
14.4 response ......................................................................................................................................... 46 
Betriebsverhalten ............................................................................................................................................. 47 
1 Zustandsspeicherung ............................................................................................................................................ 47 
1.1 nicht-normativBeispiel ................................................................................................................................. 47 
2 Netzwerkverbindung ............................................................................................................................................ 47 
3 DienstgüteStufen und Protokollabläufe .................................................................................................................. 48 
3.1 QoS 0:höchstenseinmal zustellen .................................................................................................................. 48 
3.2 QoS 1: mindestenseinmal zustellen ................................................................................................................. 48 
3.3 QoS 2: nur teilweiseeinmal senden .................................................................................................................... 49 
4 NachrichtenverteilungWiederholen .................................................................................................................................... 51 
5 Nachricht empfangen ............................................................................................................................................ 51 
6 Nachrichtenreihenfolge ............................................................................................................................................ 51 
7 Topic-Name undTopic-Filter ......................................................................................................................... 52 
7.1 TopicPlatzhalter ................................................................................................................................. 52 
7.2 mit$offenemTopic des Headers ........................................................................................................................... 53 
7.3 TopicSemantik und Verwendung ......................................................................................................................... 53 
8 Fehlerbehandlung ............................................................................................................................................ 54 
Sicherheit .................................................................................................................................................... 55 
1 Übersicht ................................................................................................................................................... 55 
2 MQTT Lösung: sicher undAuthentifizierung ........................................................................................................... 55 
3 leichtgewichtigeVerschlüsselung und eingeschränkte Geräte .................................................................................................................. 55 
4 ImplementierungshinweiseEintrag .................................................................................................................................... 55 
4.1 ClientEndpunkt-Authentifizierung ......................................................................................................................... 56 
4.2 ClientClient-Autorisierung ................................................................................................................................. 56 
4.3 DiensteEndpunkt-Authentifizierung ......................................................................................................................... 56 
4.4 SteuerungNachrichten und AnwendungsnachrichtenNachrichtenintegrität .................................................................................................... 56 
4.5 SteuerungNachrichten und AnwendungsnachrichtenNachrichtenvertraulichkeit .................................................................................................... 56 
4.6 NachrichtNichtabstreitbarkeit der ÜbertragungAuthentizität .............................................................................................................. 56 
4.7 ErkennungClient und ServerClient-Spoofing ....................................................................................................... 57 
4.8 Erkennungabnormales Verhalten ............................................................................................................................. 57 
4.9 sonstigeSicherheitsvorkehrungenElement .................................................................................................................. 57 
4.10 Verwendung SOCKS Broker .................................................................................................................... 58 
4.11 SicherheitskonfigurationDatei ........................................................................................................................... 58 
Verwendung WebSocket dofür die Netzwerkschicht .............................................................................................................. 59 
1 IANA HinweisElement .................................................................................................................................. 59 

 
  MQTT-3.1.1-CN  7 
7  Konsistenz ................................................................................................................................................. 60 
7.1 KonsistenzzielMarkierung ........................................................................................................................................ 60 
7.1.1 MQTT Serverseitig ............................................................................................................................. 60 
7.1.2 MQTT Client ............................................................................................................................. 60 
Anhang B Verbindliche normative Aussage (nicht-normativnormativ) ............................................................................................................. 62 
 

MQTT-3.1.1-CN 8

1 Übersicht

1.1 MQTT kooperierenProtokoll-Organisationsstruktur

Diese Spezifikation ist in siebenKapitel unterteilt:

 Kapitel 1 - Einführung

 Kapitel 2 – MQTT Steuernachrichtenformat

 Kapitel 3 – MQTT Steuerpaket

 Kapitel 4 – BetriebVerhalten

 Kapitel 5 – Sicherheit

 Kapitel 6 – Verwendung WebSocket Als Netzwerktransportschicht t

 Kapitel 7 – konsistenteSicherheitsziele

1.2 Begriff

In dieser Spezifikation verwendetSchlüsselwörter Erforderlich MUSS，kann nicht DARF NICHT，Anforderung ERFORDERLICH，wird SOLL，Wird nicht SOLL

NICHT，sollte SOLLTE，sollte nicht SOLLTE NICHTT，Empfohlen EMPFOHLEN，Ja KANN，Optional OPTIONAL

alles gemäß IETF RFC 2119 [RFC2119] Beschreibung inerklären.

Netzwerkverbindung（Netzwerkverbindung）：

MQTT verwendetZugrunde liegendes TransportprotokollProtokollinfrastruktur。

 Der Client verwendet es, um sich mit dem Server zu verbinden.

 Es bietet geordneten,zuverlässigenvon,bidirektionalen Bytestrom-Transport.

siehe Beispiele 4.2 Abschnitt.

Anwendungsnachricht（Anwendungsnachricht）：

MQTT ProtokollkommunikationÜber das Netzwerk übertragenAnwendungsdaten.Anwendungsnachrichten über MQTT wenn sie übertragen werden,Zugehöriger DienstQuality of Service (QoS) undTopic

（Thema）。

Client（Client）：

Verwendung MQTT durch ein Programm oder Gerät.Clients verbinden sich immerüber das Netzwerk, um eine Verbindung zuServer herzustellen. EsJa

 Anwendungsnachrichten an andere zugehörigeden Client veröffentlichen..

 AbonnementmitAnfrageAkzeptiert die relevanten Anwendungsnachrichten

 Abbestellen zum EntfernenEmpfangen von AnwendungsnachrichtenAnfrage.

 Verbindung zum Server trennenverbinden.

Serverseitig（Server）：

ein Programm oder Gerät, als der Client der sendenden Nachrichtundder Client, der das Abonnement anfordertVermittler dazwischen. Der ServerServer

 Netzwerkverbindungen von Clients annehmen.

 Client-Publish annehmenAnwendungsnachricht

MQTT-3.1.1-CN 9

 Client-Abonnement verarbeitenSubscribe- und UnsubscribeAnfrage.

 WeiterleitenNachrichten auf übereinstimmendesClient-KomponenteAbonnement anwenden。

Abonnement（Abonnement）：

Abonnement enthält ein TopicTopic-Filter (Topic-Filter) undeinen größten ServerQuality of Service (QoS)-Level. Abonnement mit einer einzelnenSession

（Session) zugehörigeVerbindung. Sessions könnenEnthält mehr als ein Abonnement. SessionJedes Abonnement hat eineverschiedene Topics durchFilter.

Topic-Name (Topic Name）：

An die Anwendungsnachricht angehängtein Label auf, dem Server bekannt und mit dem AbonnementAbonnement-Abgleich. Der Server sendeteine der Anwendungsnachrichteine Kopie an jede passende

des Client-Abonnements.

Topic-FilterFilter (Topic-Filter:）：

eine im Abonnement enthalteneAusdruck, verwendetzur Darstellung zugehörigereines oder mehrerer MasterTopic. Topic-Filter könnenWildcards verwenden.

Session（Session）：

Client und ServerZustandsaustausch zwischenInteraktion. Einige Sitzungen dauern, wennLänge und Netzwerkwie eine Netzwerkverbindung,andere können inmehrere Client und Server

eine kontinuierliche NetzwerkverbindungIntervallverlängerung.

Steuerpaket（MQTT-Steuerpaket）：

über die Netzwerkverbindung gesendetdas übertragene Informationsdatenpaket.MQTT Die Spezifikation definiert vierzehnverschiedene Arten von SteuernachrichtenText,wobeieine (PUBLISH Meldung

Nachricht), die zum Übertragen von Anwendungsnutzungsnachricht verwendet wird.

1.3 SpezifikationReferenz

[RFC2119]

Bradner, S., „Schlüsselwörter zur Verwendung in RFCs zur Angabe von Anforderungsstufen“, BCP 14, RFC 2119, März

1997.

http://www.ietf.org/rfc/rfc2119.txt

[RFC3629]

Yergeau, F., „UTF-8, ein Transformationsformat von ISO 10646“, STD 63, RFC 3629, November 2003

http://www.ietf.org/rfc/rfc3629.txt

[RFC5246]

Dierks, T. und E. Rescorla, „Das Transport Layer Security (TLS) Protokoll Version 1.2“, RFC 5246, August

2008.

http://www.ietf.org/rfc/rfc5246.txt

[RFC6455]

Fette, I. und A. Melnikov, „Das WebSocket-Protokoll“, RFC 6455, Dezember 2011.

http://www.ietf.org/rfc/rfc6455.txt

[Unicode]

Das Unicode-Konsortium. Der Unicode-Standard.

http://www.unicode.org/versions/latest/

 
  MQTT-3.1.1-CN  10 
1.4 Nicht-normative Referenz 
[RFC793] 
Postel, J. Transmission Control Protocol. STD 7, IETF RFC 793, September 1981. 
http://www.ietf.org/rfc/rfc793.txt 
 
[AES] 
Advanced Encryption Standard (AES) (FIPS PUB 197). 
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf 
 
[DES] 
Datenverschlüsselungsstandard (DES). 
http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf 
 
[FIPS1402] 
Sicherheitsanforderungen für kryptografische Module (FIPS PUB 140-2) 
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf 
 
[IEEE 802.1AR] 
IEEE-Standard für lokale und metropolitane Netzwerkes - Sichere Geräteidentität 
http://standards.ieee.org/findstds/standard/802.1AR-2009.html 
 
[ISO29192] 
ISO/IEC 29192-1:2012 Informationstechnik -- Sicherheitstechniken -- Leichtgewichtige Kryptographie -- Teil 
1: Allgemeines 
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=56425 
 
[MQTT NIST] 
MQTT-Zusatzveröffentlichung, MQTT und das NIST-Rahmenwerk zur Verbesserung kritischer Infrastrukture 
Cybersicherheit 
http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-v1.0.html 
 
[MQTTV31] 
MQTT V3.1 Protokollspezifikation. 
http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html 
 
[NISTCSF] 
Verbesserung der kritischen Infrastruktur-Cybersicherheit Executive Order 13636 
http://www.nist.gov/itl/upload/preliminary-cybersecurity-framework.pdf 
 
[NIST7628] 
NISTIR 7628 Leitlinien für Cybersicherheit im SmartGridid Cyber Security 
http://www.nist.gov/smartgrid/upload/nistir-7628_total.pdf 
 
[NSAB] 
NSA Suite B Kryptographie 
http://www.nsa.gov/ia/programs/suiteb_cryptography/ 
 

 
  MQTT-3.1.1-CN  11 
[PCIDSS] 
PCI-DSS Zahlungskarten-Industrie -Datensicherheitsstandard 
https://www.pcisecuritystandards.org/security_standards/ 
 
[RFC1928] 
Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., und L. Jones, "SOCKS-Protokoll Version 5", RFC 
1928, März 1996.  
http://www.ietf.org/rfc/rfc1928.txt 
 
[RFC4511] 
Sermersheim, J., Hrsg., "Lightweight Directory Access Protocol (LDAP): Das Protokoll", RFC 4511, Juni 
2006. 
http://www.ietf.org/rfc/rfc4511.txt 
 
[RFC5077] 
Salowey, J., Zhou, H., Eronen, P., und H. Tschofenig, "Transport Layer Security (TLS)-Sitzung 
Wiederaufnahme ohne Server-seitigen Zustand", RFC 5077, Januar 2008. 
http://www.ietf.org/rfc/rfc5077.txt 
 
[RFC5280] 
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., und W. Polk, "Internet X.509 Public Key 
Infrastruktur-Zertifikat und Zertifikatssperrlisten-(CRL)-Profil", RFC 5280, Mai 2008. 
http://www.ietf.org/rfc/rfc5280.txt 
 
[RFC6066] 
Eastlake 3rd, D., "Transport Layer Security (TLS)-Erweiterungen: Erweiterungsdefinitionen", RFC 6066, January 
2011.  
http://www.ietf.org/rfc/rfc6066.txt  
 
[RFC6749] 
Hardt, D., Hrsg., "Das OAuth 2.0 Autorisierungsrahmenwerk", RFC 6749, Oktober 2012. 
http://www.ietf.org/rfc/rfc6749.txt 
 
[RFC6960] 
Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S. und C. Adams, "X.509 Internet Public 
Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, Juni 2013. 
http://www.ietf.org/rfc/rfc6960.txt 
 
[SARBANES] 
Sarbanes-Oxley-Gesetz von 2002. 
http://www.gpo.gov/fdsys/pkg/PLAW-107publ204/html/PLAW-107publ204.htm 
 
[USEUSAFEHARB] 
U.S.-EU-Safe-Harbor-Abkommen 
http://export.gov/safeharbor/eu/eg_main_018365.asp 

MQTT-3.1.1-CN 12

1.5 Datendarstellung

1.5.1 Binärbit

die Bits im Byte von 0 bis 7. Nr. 7 Bit ist das höchstesignifikantes Bit, das 0 Das Bit ist das niedrigstwertige Bit.

1.5.2 Ganzzahlwert

Der Ganzzahlwert ist 16 Bits, unter Verwendung von Big-Endian (Big-Endian，höherwertigesBytevor dem niederwertigen Bytevorne). Dies bedeutetmit einem 16 BitsZeichen im Netzwerk

im Netzwerk dargestellt als das höchstesignifikante Byte (MSB), gefolgt vondem niederwertigsten Wortabschnitt (LSB）。

1.5.3 UTF-8 codierte Zeichenkette

die später beschriebene SteuerungText in der Steuernachrichtdieses Feld ist kodiert als UTF-8 FormatzeichenZeichenkette.UTF-8 [RFC3629] ist eineeffiziente

Unicode ZeichenkodierungFormat, um Radix zu unterstützenfür textuelle Kommunikation, es ist ASCII Zeichendie Kodierung führtoptimiert durch.

Jede Zeichenkettehat ein Zwei-Byte-Längenfeld alsals Präfix, es gibtdiese Zeichenkette aus UTF-8 kodierte BytesAnzahl,sieinLegende

1.1 UTF-8 BearbeitungStruktur einer Codezeichenkette beschrieben inbeschrieben. Daher, was übertragen werden kann UTF-8 Kodierungdie Zeichenkettenlänge hat eineGrenze, darf nicht überschreitenübergeben

65535 Byte。

Sofern nicht anders angegeben,alle UTF-8 BearbeitungCodezeichenkettedie Länge muss sein 0 bis 65535 Byteinnerhalb dieses Bereichs。

Legende 1.1 UTF-8 kodiertes ZeichenEnde der ZeichenketteStruktur

Binärbit

Byte 1

die maximale Länge der Zeichenkettehöherwertiges Byte (MSB）

Byte 2

die maximale Länge der Zeichenketteniederwertiges Byte (LSB）

Byte 3 ….

wenn die Länge größer als 0ist, steht hier UTF-8 die Anzahl der kodierten ZeichenDaten.

UTF-8 Kodierungder Zeichen in der ZeichenketteZeichendatenErforderlichist gemäß Unicode Spezifikation [Unicode] definiert und in RFC3629 [RFC3629] Mittel

erneut bestätigtes gültiges UTF-8 Format. Es ist besonders notwendigdarauf hinzuweisen, dassDieseDatendarf nichtden Zeichencode bei U+D800 und U+DFFF zwischen enthalten

Daten.WennServer oder Client empfängtauf ein enthaltendes gestoßen istUngültiges UTF-8 SteuerzeichenPaket, esmussdie Netzwerkverbindung schließen [MQTT-

1.5.3-1]。

UTF-8 Kodierungdie Zeichenfolgedarf keinNullzeichen enthalten U+0000。wennClient oder Server empfängtan einem angekommenen, das enthält U+0000 der SteuerungSteuerpaket

Text,esist erforderlich,die Netzwerkverbindung zu schließen [MQTT-1.5.3-2]。

in den Datensollte nichtFolgendes enthalten Unicode Codepunktdie Kodierung. Wennein Empfänger (Server oder Client) hat ein Paket empfangen, das Folgendes enthält

Kontrolle über beliebige ZeichenPaket, esJaNetzwerkverbindung schließenverbinden:

U+0001 und U+001F zwischenSteuerzeichen

U+007F und U+009F zwischenSteuerzeichen

Unicode- Spezifikationdefinierter Nicht-Zeichen-Codepunkt (z. B., U+0FFFF）

Unicode- Spezifikationdefinierte garantiertereservierte Zeichen (z. B. U+0FFFF）

MQTT-3.1.1-CN 13

UTF-8 KodierungSequenz 0XEF 0xBB 0xBF wird immerinterpretiert als U+FEFF(Zero-Width-Non-Breaking-Space-Zeichen),egales im Zeichen vorkommt

welche Position in der Zeichenkette,alle Nachrichtenempfängerkönnen nicht überspringen oderes entfernen [MQTT-1.5.3-3]。

1.5.3.1 nicht normativBeispiel

Zum Beispiel, Zeichenkette A𪛔 Yesein lateinischerBuchstabe A gefolgt von einemCodepunkt U+2A6D4(Es repräsentiert einCJK Unifiedideographisches Zeichen

Erweiterungs B zeichen in)，DieserStringkodierungwie folgt:

Legende 1.2 UTF-8 kodiertes Zeichennicht normativer StringBeispiel

Bit

Byte 1

Stringlänge MSB (0x00)

Byte 2

Stringlänge LSB (0x05)

Byte 3

‘A’ (0x41)

Byte 4

(0xF0)

Byte 5

(0xAA)

byte 6

(0x9B)

byte 7

(0x94)

1.6 Redaktionelle Konventionen

Diese Spezifikation verwendet gelbe Hervorhebungheller TextbezeichnerKonformitätsaussage,jeder Konformitätsaussagewird jeweils eine solche zugewiesenFormatreferenz:[MQTT-x.x.x-

y]。

MQTT-3.1.1-CN 14

2 MQTT SteuerpaketFormatierung

2.1 MQTT Struktur von Steuernachrichten

MQTT Protokollkommunikationdurch Austausch vorbestimmtersemantischer MQTT Steuerpakete zuKommunikation. Dieser Abschnittbeschreibt dieser PaketeFormat.

MQTT SteuerpaketPaket besteht aus drei Teilenzusammengesetzt, gemäß Legende 2.1 –MQTT SteuerungStruktur des Steuerpakets Reihenfolge der Beschreibung:

Legende 2.1 –MQTT des SteuerpaketsStruktur

Fester Header festfester Header, alleSteuerpakete alle enthaltenenthalten

Variabler Header variabler Header,einige Steuerpaketeenthalten

Nutzlast Nutzlast, einige Steuerpaketeenthalten

2.2 Fester Header

jedes MQTT SteuerSteuerpakete enthalten alleeinen festen Header。Legende 2.2 -durchgezogenFormat des festen Headers beschreibt den festen HeaderFormat des Headers.

Legende 2.2 -FestesHeader-FormatFormel

Bit

Byte 1

MQTT SteuerpaketNachrichtentyp

verwendet fürdes angegebenen SteuernachrichtentypsFlag-Bit

Byte 2…

VerbleibendeLänge

2.2.1 MQTT Typen von Steuernachrichten

Position:Nr. 1 ein Byte, binäre Bits 7-4。

dargestellt als 4 kein BitSymbolwerte, diese Wertesiehe Definition Tabelle 2.1 -Typen von Steuernachrichten

Tabelle 2.1 -SteuerPakettypTyp

name

Wert

NachrichtFlussrichtung

Beschreibung

Reserviert

Verweigern

beibehalten

CONNECT

Client zu Server

Client fordert Verbindung anServerseitig

CONNACK

Server zu Client

VerbindungspaketBestätigung

PUBLISH

beide Richtungen sind erlaubt

Veröffentlichungsnachricht

PUBACK

beide Richtungen sind erlaubt

QoS 1 NachrichtveröffentlichenempfangenBestätigung

PUBREC

beide Richtungen sind erlaubt

Publish empfangen (garantierteZustellung Schritt 1)

PUBREL

beide Richtungen sind erlaubt

Publish-Freigabe (garantierteZustellung Schritt 2)

MQTT-3.1.1-CN 15

PUBCOMP

beide Richtungen sind erlaubt

QoS 2 NachrichtPublish abgeschlossen (Garantiegarantierte Interaktion Schritt 3）

Client zu Server

Client-Abonnementanfrage

SUBACK

Server zu Client

AbonnementanfrageNachrichtBestätigung

UNSUBSCRIBE

Client zu Server

Client-AbmeldungAnfrage

UNSUBACK

Server zu Client

Abonnement kündigenNachrichtBestätigung

PINGREQ

Client zu Server

Heartbeat-Anfrage

PINGRESP

Server zu Client

Heartbeat-Antwort

DISCONNECT

Client zu Server

Client trennt die Verbindung

Reserviert

Verweigern

beibehalten

2.2.2 Flags

Fixed Header, die 1 die verbleibenden Bytes 4 Bits [3-0]enthält jeweils MQTT Steuerpaketnachrichtentypspezifische Flags,siehe Tabelle 2.2 -Flag-Bit。

Tabelle 2.2 alle als“retain”markierten Flag-Bits, alle sind reserviertfür zukünftige Verwendung,Erforderlichwie in der Tabelle festgelegtaufgeführten Werte [MQTT-

2.2.2-1]。wennbeim Empfang eines ungültigen Flags der EmpfängerEmpfängerErforderlichdie Netzwerkverbindung schließen. Es gibtim Zusammenhang mit der FehlerbehandlungFür Details siehe 4.8 Abschnitt [MQTT-

2.2.2-2]。

Tabelle 2.2 -Flag-Bit

Steuerpaket

festFixed-Header-Flags

Bit 3

Bit 2

Bit 1

Bit 0

CONNECT

Reserviert

CONNACK

Reserviert

PUBLISH

Verwendet in MQTT 3.1.1

DUP

QoS

RETAIN

PUBACK

Reserviert

PUBREC

Reserviert

PUBREL

Reserviert

PUBCOMP

Reserviert

SUBACK

Reserviert

UNSUBSCRIBE

Reserviert

UNSUBACK

Reserviert

PINGREQ

Reserviert

PINGRESP

Reserviert

DISCONNECT

Reserviert

MQTT-3.1.1-CN 16

DUP

=steuertdie doppelte Zustellung von PaketenSende-Flag

QoS

= PUBLISH NachrichtderQuality-of-Service-Stufe

RETAIN

= PUBLISH des PaketsretainFlags

PUBLISH Steuerungim Paket DUP, QoS und RETAIN Flag-Beschreibungbeschrieben in 3.3.1 Abschnitt.

2.2.3 verbleibende Länge

Position:von der ersten 2 beginnt mit einem Byte.

verbleibendelangGrad（Remaining Length）RepräsentiertWennvorherige Nachrichtverbleibender TextRestTeilenvonByteAnzahl,einschließlichkannvariable NachrichtHeader undnegativLastvonDaten。verbleibendelangGrad

ohne die für die Kodierung verwendeten BytesRemaining-Length-Feldseine eigene Byte-Anzahl。

verbleibende LängeLängenfeldverwenden einevariable LängeKodierungsmethodeFall,Für weniger als 128 Wert vones machtEinzelzeichen verwendenAbschnittKodierung. größererWert wie untenArt und WeiseBehandeln.

Niedrig 7 Die signifikanten Bits werden zum Kodieren von Daten verwendet., das höchstwertige Bitwird verwendet, um anzugeben, ob weitere vorhanden sindBytes von. Daher kann jeder WortAbschnitt 128 ZahlWert kodieren

und ein

Fortsetzungsbit (

Fortsetzungsbit

）

. Das Remaining-Length-Feldmaximal 4 ZeichenAbschnitt.

nicht-normativerKommentar

BeispielZum Beispiel，zehneingebenSystemNummer 64 wirdDurchBearbeitenCodeisteinsElementeZeichenAbschnitt, WertJa 64，zehnsechseingebenSystemTabelleanzeigenist 0x40,。zehneingebenSystemNummerZeichen

321(=65+2*128)wird codiertist zwei Bytes,das niederwertigste Bit ist beidavor. Das erste WortAbschnitt ist 65+128=193. Beachten Sie, dass das höchstwertigehöchstwertiges Bit ist

1 Repräsentiertdahintermindestenses gibt ein weiteres Byte. Die zweitenBytes sind 2。

nichtSpezifikationKommentar

这erlaubenzulassen sollteverwendensendenmaximal 256MB(268,435,455)großklein vonSteuerungSystem BerichtText。这ElementeNummer WertIn BerichtTextMediumvonTabelle anzeigenJa：

0xFF,0xFF,0xFF,0x7F。

Tabelle 2.4 des Remaining-Length-FeldesGrößezeigt das Remaining-Length-Feldder dargestellte Wert variiert mitByte-Wachstum.

Tabelle 2.4 verbleibende Längedes FeldesGröße

Byte-Anzahl

Mindestwert

Höchstwert

0 (0x00)

127 (0x7F)

128 (0x80, 0x01)

16 383 (0xFF, 0x7F)

16 384 (0x80, 0x80, 0x01)

2 097 151 (0xFF, 0xFF, 0x7F)

2 097 152 (0x80, 0x80, 0x80, 0x01)

268 435 455 (0xFF, 0xFF, 0xFF, 0x7F)

bezeichnen jeweils (jeweilsdie niedrigstwertigen Bits des Bytes 7 , diezur Kodierung von Daten verwendet werden, das höchstwertige Bit ist ein Flag-Bit）：

1 wenn Bytes,von 0(0x00)bis 127(0x7f)

2 wenn Bytes,von 128(0x80,0x01)bis 16383(0Xff,0x7f)

3 wenn Bytes,von 16384(0x80,0x80,0x01)bis 2097151(0xFF,0xFF,0x7F)

4 wenn Bytes,von 2097152(0x80,0x80,0x80,0x01)bis 268435455(0xFF,0xFF,0xFF,0x7F)

MQTT-3.1.1-CN 17

nicht-normativerKommentar

nichtnegative Ganzzahl X verwendet ein Kodierungsschema mit variabler Längeder Algorithmus lautet wie folgt:

encodedByte = X MOD 128

X = X DIV 128

// wenn es weitere Datenzu kodieren gibt, setzen Sie das obersteBit dieses Bytes

if ( X > 0 )

encodedByte = encodedByte OR 128

endif

'output' encodedyte

while ( X > 0 )

MOD ist eine ModuloOperation,DIV ist ganzzahlige Division,OR ist eine bitweise Operation oder（C Sprachein der jeweils ... sind%，/，|）

nicht-normativerKommentar

des Feldes Remaining LengthDer Dekodierungsalgorithmus lautet wie folgt：

multiplier = 1

value = 0

encodedByte = 'next byte from stream'

value += (encodedByte AND 127) * multiplier

multiplier *= 128

if (multiplier > 128*128*128)

throw Error(Fehlerhafte verbleibende Länge)

while ((encodedByte AND 128) != 0)

AND ist eine BitoperationOperation AND (C in der Sprache&）

wenn dieser Algorithmus terminiert，Wert Paketwas enthalten ist, istder Wert der Remaining Length.

2.3 Variabler Header

manches MQTT -Steuerpaketenthält einen Variable Header-Teil.es befindet sich im Fixed Headerund Payloaddazwischen. Der Inhalt des Variable Headersje nachPakettyp

variiert. KannVariable-Header-Paketkennung (Packet Identifier）Feld existiert inin Nachrichten mehrerer Typen.

2.3.1 Paketkennung

Legende 2.3 -NachrichtKennungsklasseTyp

Bit

Byte 1

Paketkennung MSB

Byte 2

Paketkennung LSB

MQTT-3.1.1-CN 18

von vielen Steuerpaketenvariabler Header-Teilenthält ein Zwei-Byte-NachrichtenPaket-Identifikator-Feld. DiesesPaket ist PUBLISH（QoS>0 Zeit)，

PUBACK，PUBREC，PUBREL，PUBCOMP，SUBSCRIBE, SUBACK，UNSUBSCIBE，

UNSUBACK。

SUBSCRIBE，UNSUBSCRIBE und PUBLISH（QoS größer als 0) SteuerpaketErforderlichenthält einein Nicht-Null 16 Paket-Identifikator-Bit

Zeichen (Packet Identifier）[MQTT-2.3.1-1]. Der Client jedes Malsendet eine neuedieser Arten vonwann immer eine NachrichtErforderlichweist eineaktuelle zu

unbenutzter Paket-IdentifikatorIdentifikator [MQTT-2.3.1-2]. WennEin Client möchte erneut sendendiese spezielle SteuerSteuernachricht, bei späterer Neuübertragungdiese Nachricht

wenn,esErforderlichverwendet denselben Identifikator.Wenn der Client die Verarbeitung dieses abgeschlossen hatein Paket entsprechendNach der Bestätigung,Nachrichten-Identifikator wirdals wiederverwendbar freigegeben.

QoS 1 von PUBLISH entsprechendist PUBACK，QoS 2 von PUBLISH entsprechendist PUBCOMP, und SUBSCRIBE oder

UNSUBSCRIBE entsprechendseparatJa SUBACK oder UNSUBACK [MQTT-2.3.1-3]。sende einElemente QoS 0 von PUBLISH

NachrichtWenn, gelten dieselben Bedingungen auch fürserverseitig [MQTT-2.3.1-4]。

QoS Gesetzt auf 0 von PUBLISH Nachrichtkann nichtenthält einen Paketbezeichner [MQTT-2.3.1-5]。

PUBACK, PUBREC, PUBREL NachrichtErforderlichenthaltend undursprünglich gesendet PUBLISH BerichtPaket mit derselbenNachrichtenkennung [MQTT-2.3.1-

6]. Ähnlich,SUBACK und UNSUBACK Erforderlichenthalten im entsprechenden SUBSCRIBE und UNSUBSCRIBE Berichtverwendet im Textvon

Paketkennung [MQTT-2.3.1-7]。

erfordertDas Steuerpaket der Nachrichtenkennung ist in Tabelle 2.5 -enthält eine PaketkennungSteuerpaket von aufgeführt in.

Tabelle 2.5 -enthältNachrichtenkennungSteuerung des SymbolsSteuerpaket

Steuerpaket

PaketkennungKennungszeichenSegment

CONNECT

Nicht erforderlich

CONNACK

Nicht erforderlich

PUBLISH

erforderlich (wenn QoS > 0）

PUBACK

erfordert

PUBREC

erfordert

PUBREL

erfordert

PUBCOMP

erfordert

SUBACK

erfordert

UNSUBSCRIBE

erfordert

UNSUBACK

erfordert

PINGREQ

Nicht erforderlich

PINGRESP

Nicht erforderlich

DISCONNECT

Nicht erforderlich

MQTT-3.1.1-CN 19

Client und Serverunabhängig zugewieseneNachrichtenkennungen. Daher die Clientserverseitige Kombinationunter Verwendung derselben NachrichtNachrichtenkennung kann implementiert werden und

der Austausch gesendeter Nachrichten.

nicht-normativerKommentar

Der Client sendet eine KennungZeichen ist 0x1234 von PUBLISH Paket,es kannkann sein, wenn empfangen wird, dassvon einer Nachricht PUBACK vonvorher, zuerst

empfängt vom Server gesendeteine andere, unterschiedlicheaber der NachrichtenbezeichnerBezeichner ist auch 0x1234 von PUBLISH Paket.

Client Server

PUBLISH Packet Identifier=0x1234---

--PUBLISH Packet Identifier=0x1234

PUBACK Packet Identifier=0x1234---

--PUBACK Packet Identifier=0x1234

2.4 payload

irgendein MQTT Steuerpaket im Paketder letzte Teil des Paketsenthält eine gültigeNutzlast, dies wird in derdiskutiert in Kapitel 3.für PUBLISH sprechendgültig

Nutzlastist die Anwendungsnachricht.Tabelle 2.6 – enthält gültigesSteuerpaket mit einer Nutzlast listet die Anforderungen aufSteuerpaket der Nutzlast.

Tabelle 2.6 – enthält die NutzlastSteuernachrichtText

Steuerpaket

payload

CONNECT

erfordert

CONNACK

Nicht erforderlich

PUBLISH

Optional

PUBACK

Nicht erforderlich

PUBREC

Nicht erforderlich

PUBREL

Nicht erforderlich

PUBCOMP

Nicht erforderlich

erfordert

SUBACK

erfordert

UNSUBSCRIBE

erfordert

UNSUBACK

Nicht erforderlich

PINGREQ

Nicht erforderlich

PINGRESP

Nicht erforderlich

DISCONNECT

Nicht erforderlich

MQTT-3.1.1-CN 20

3 MQTT Steuerpaket

3.1 CONNECT – VerbindungServerseite

Client zu ServerNetzwerkverbindungsaufbaunach dem Aufbau sendet der Client anServerseitedie erste Nachricht vonErforderlichJa CONNECT Nachricht [MQTT-

3.1.0-1]。

auf einer Netzwerkverbindungkann der Client nureinmal gesendet werden CONNECT Nachricht. ServerErforderlichder Client sendetdie zweite gesendete CONNECT

Paket als Protokollverletzungnormal behandeln und trennenClient-Verbindung [MQTT-3.1.0-2]. Bezüglich FehlerFür die verarbeiteten Informationen siehe 4.8 Abschnitt.

die Nutzlast enthält einoder mehrere KodierungsFelder. Einschließlichdes eindeutigen ClientBezeichners,Will Topic,Will Nachricht, verwendenBenutzername und Passwort.aufteilen

der Client-Bezeichneraußer，anderenAlle Felder sind optional, basierend auf den Flag-Bitsum die variable Nachricht zu bestimmenim Headerobdiese Felder eingeschlossen werden müssen。

3.1.1 Fester Header

Legende 3.1 –CONNECT der feste Header der Nachrichtfester Header

Bit

Byte 1

MQTT PakettypTyp (1)

Reserviert retainBits

Byte 2…

Wert der verbleibenden Länge

verbleibende LängeLängenfeld

Die Remaining Length entspricht der Variable-Header-Länge des Variable Headers（10 Byte) plus der Payload-Länge. Kodierungsiehe Methode 2.2.3 AbschnittBeschreibung.

3.1.2 Variabler Header

CONNECT BerichtVariable Header der NachrichtDer Header enthält in der folgenden Reihenfolgevier Felder: Protokollname (Protokollname), ProtokollLevel（Protokoll

Level），Verbindungs-Flag (Connect Flags) undKeep Alive (Keep Alive）。

3.1.2.1 Protokollname

Legende 3.2 -Protokollnameaus Bytes zusammengesetzt

Beschreibung

Protokollname

Byte 1

Länge MSB (0)

Byte 2

Länge LSB (4)

Byte 3

‘M’

Byte 4

‘Q’

Byte 5

‘T’

MQTT-3.1.1-CN 21

byte 6

‘T’

Der Protokollname ist eine Zeichenkette, die das Protokoll darstelltProtokollname MQTT von UTF-8 die kodierte Zeichenkette.MQTT der SpezifikationSpätere Versionen werden nichtdiesenString-Offset ändernund

Länge.

wenn der Protokollname falsch istder Server bestätigtJaden Client trennendie Verbindung, auchJagemäßeinigen anderen Spezifikationenweiterverarbeiten CONNECT Nachricht. Für

im letzteren Fall,gemäß dieser Spezifikation,serverseitigkann nichtweiterverarbeiten CONNECT Nachricht [MQTT-3.1.2-1]。

nichtSpezifikationKommentar

Paketinspektionswerkzeug, zum Beispiel Firewalls, kann das ProtokollProtokollnamen verwenden, um MQTT Datenverkehr zu identifizieren.

3.1.2.2 ProtokollebeneSonstiges

Legende 3.3 - Protokoll Ebene byte ProtokollEbenebytebilden

Beschreibung

Protokollebene

byte 7

Ebene(4)

Client verwendet 8 vorzeichenloses BitSymbolwert gibt anProtokollrevision. Fürin 3.1.1 EditionProtokoll, ProtokollebeneWert des BezeichnerfeldsJa 4(0x04). Wenn Senden

ein nicht unterstütztes Protokoll erkennenEbene, der ServerErforderlichsenden aneinen Rückgabecode sendenist 0x01(nichtunterstützte ProtokollebeneDifferenz) von CONNACK Nachrichtresponse

CONNECT Nachricht, dann trennentrennen Sie dieVerbindung des Clients [MQTT-3.1.2-2]。

3.1.2.3 Verbindungskennungwird

Das Connect-Flags-Byte enthältenthält einige, die verwendet werden, um anzugebenentscheiden MQTT verbindenParameter für das Verbindungsverhalten. Es zeigt auch an, dass esZeichen in der Payload gibtob das Feld existiert.

Legende 3.4 -Connect-Flag-Bits

Bit

Benutzernamee

Flag

Password

Flag

WWill Retain

WWill QoS

WWill Flag

Clean

Sitzung

Reserviert

Byte 8

ServerseitigErforderlichüberprüfen CONNECT Steuerpaketdas Retain-Flag des TextesBit (die 0 Bits) ob es 0，wennist nicht 0 muss trennenClient-Verbindung

[MQTT-3.1.2-3]。

3.1.2.4 saubere SitzungSprache

Position:das Bit des Connect-Flags-Bytes 1 Bits

Dieses Bit gibt anbestimmt den Sitzungszustanddie Verarbeitung.

Client und Serverkönnen den Sitzungszustandspeichern, umüber eine Netzwerkverbindungzuverlässige Nachrichtenübertragung zu unterstützen. Dieses Flag-Bitzur Steuerung des Sitzungszustands verwendet

Time to Live.

MQTT-3.1.1-CN 22

Wenn das Clean-Session- (CleanSession）Flag gesetzt istauf 0gesetzt wird, der ServerErforderlichbasierend aufaktueller Sitzung (machendurch den Client-Bezeichner identifiziertUnterschied) von

Zustandswiederherstellung und der ClientKommunikation zwischen den Enden. Wennwenn es keine mit diesemClient-Bezeichnerverknüpfte Sitzung gibt,serverseitigErforderlicheine erstelleneine neue Sitzung. In

nachdem die Verbindung geschlossen ist,nachdem die Verbindung getrennt wurde, Client und ServerServerErforderlichSitzungsinformationen beibehaltenAtem [MQTT-3.1.2-4]. Wenn das Bereinigen desSitzungsflags ist 0

Die Sitzungsverbindung ist getrennt.danach, der ServerErforderlichesnach QoS 1 und QoS 2 Ebenedie Nachricht wird gespeichert alsdes Sitzungszustandsein Teil, wenn这

Einige Nachrichten entsprechen der Trennung.beim Verbinden, der Clientbeliebige Abonnements [MQTT-3.1.2-5]。der Server ebenfallsJaSpeichernerfüllt die gleiche Bedingungvon QoS 0 Ebene

Nachricht.

wennlöschenverwaltenSitzung（CleanSession）MarkierungwirdDurchEinstellungenist 1，ClientEndeundDiensteEndeErforderlichverwerfenvonvorPflichtwie kannSitzung undöffnenstartenaNeu

vonwirdSprache。wirdSprachenurhaltenfortfahrenundNetzNetzwerkverbindenJiegleichBeispiellangvonwennzwischen。und这ElementewirdSpracheschließenvereinenvonZustandBedingungNummergemäßkann nichtDurchPflichtwasvonnachvonwirdSpracheschwerverwenden

[MQTT-3.1.2-6]。

Der Sitzungszustand des Clients.Zustand umfasst:

 Wurde an den Server gesendet.Ende,AberNoch nicht bestätigt QoS 1 und QoS 2 Ebeneandere Nachrichten

 Wurde vom Server empfangen., aber wurde noch nichtder Abschlussbestätigung QoS 2 Ebeneandere Nachrichten.

Der Sitzungszustand des Servers.Zustand umfasst:

 SitzungOb sie existiert, selbst wenn der Sitzungszustandalle anderen Teileleer ist.

 Die Abonnementinformationen des Clients.Nachricht.

 Wurde an den Client gesendet.Ende,AberNoch nicht bestätigt QoS 1 und QoS 2 Ebeneandere Nachrichten。

 kurz davorAn den Client übertragen. QoS 1 und QoS 2 Ebeneandere Nachrichten。

 Wurde vom Client empfangen., aber hat noch nichtder Abschlussbestätigung QoS 2 Ebeneandere Nachrichten.

 optional,vorbereitenAn den Client gesendet. QoS 0 Nachrichten der Ebene。

Retained Messages sind nicht serverseitig.Server-Session-Statusein Teil von, wirdwenn die Sitzung endetkönnen nichtRetained Messages löschenAtemzug [MQTT-3.1.2.7]。

Bezüglich der Zustandsspeicherung.Einschränkungen und Details sieheNr. 4.1 Abschnitt.

Wenn das Clean-Session-Flaggesetzt wird auf 1 wenn,Client und Serverserverseitige Statuslöschung nicht benötigtwenn atomare Operation。

nicht-normativerKommentar

Um sicherzustellen, dass im Falle vonZustand bei FehlerKonsistenz, der ClientEnde sollte Session verwendenSession-Status-Flag 1 schwerwiederholte Verbindungsanfrage, bis die Verbindung erfolgreich ist

Erfolg.

nicht-normativerKommentar

Im Allgemeinen werden Clientsam Ende immer beim Verbindendas Clean-Session-Flag setzenFlag ist gesetzt auf 0 oder 1，Und verwenden Sie nicht abwechselnd die beidenArten von Werten. DieseAuswahl treffen

Hängt von der jeweiligen Anwendung ab.. Clean-Session-FlagFlag ist gesetzt auf 1 der Client nichtwird alte empfangenAnwendungsnachricht,außerdembei jeder Verbindungnach Erfolg

Alle müssen erneut abonnieren.jedeszugehörigeTopic. Clean-SessionFlag ist gesetzt auf 0 vonDer Client wird alle empfangenwenn er sich verbindettrennenwährend des Sendens

veröffentlichte QoS 1 und QoS 2 Nachricht auf der Stufe. Daher,muss sicherstellen, dassnicht verloren geht, während die Verbindung getrennt istdie Nachricht, mussVerwendung QoS 1 oder

QoS 2 Stufe, gleichzeitig wird bereinigtDas Session-Flag ist gesetzt auf 0。

nicht-normativerKommentar

MQTT-3.1.1-CN 23

Clean-Session-Flag 0 Wenn der Client sich verbindetEr fordert den Server aufnach dem Trennen der Verbindung zu speichernbehält seinen MQTT Sitzungszustand.wenn geöffnet

Später geplantzum Zeitpunkt erneut verbinden mitdiesem Server,die Client-Verbindung solltesollte nur sauberesSitzungsflag verwenden 0. Wenn der Client entscheidet

danachWenn diese Sitzung nicht mehr verwendet wird, solltesollte die Sitzung bereinigenFlag ist gesetzt auf 0 schließlich danneinmal verbinden,Dann trennen.

3.1.2.5 Will-Flag

Position:Das Connect-Flags- 2 Bit.

Will-Flag (Will Flag) ist gesetztist 1, was anzeigt, obWenn die Verbindungsanfrageakzeptiert wird, wird die Will-（Will Message）NachrichtErforderlichgespeichert in

Der Server und damiteine Netzwerkverbindung verbundenverbunden. Nachdem das Netzwerkwenn die Verbindung geschlossen wird,ServerseitigErforderlichveröffentlichen dieseWill-Nachricht,es sei denn,Server empfängt

DISCONNECT wenn die Nachricht gelöscht wirdDieseWill-Nachricht [MQTT-3.1.2-8] 。

Die Will-Nachricht veröffentlichtBedingungen, einschließlich, abernicht beschränkt auf:

 Der Server hat erkannta I/O Fehler oder Netzwerkausfall。

 Der Client hält die Verbindung aufrechtVerbindung (Keep Alive）innerhalb des Zeitraums nicht geschafft hat zukommunizieren.

 Der Client hat nicht zuerst gesendetsenden DISCONNECT Die Nachricht hat direkt die Netzwerkverbindung geschlossen.

 Aufgrund eines Protokollfehlers hat der Serverder Server hat die NetzwerkNetzwerkverbindung geschlossen.

wennDas Will-Flag ist gesetzt auf 1, Verbindungim Verbindungsflag Will QoS und Will Retain Felderwerden vom Server verwendetzu,gleichzeitigin der Payloadmuss

mussenthält Will Topic und Will Message Felder [MQTT-3.1.2-9]。

Sobald veröffentlicht oderder Server empfangen hatvom Client gesendet DISCONNECT Paket,wirdNachricht dannErforderlichAus dem gespeicherten Sitzungszustand entfernt.

teilen [MQTT-3.1.2-10]。

wennDas Will-Flag ist gesetzt auf 0，Verbindungim Flag WWill-QoS und Will Retain FelderErforderlichGesetzt auf 0, undim Payloadkann nicht

enthält Will Topic und Will Message Felder [MQTT-3.1.2-11]。

wennDas Will-Flag ist gesetzt auf 0, Netzwerkwenn die Netzwerkverbindung getrennt wird，kann nichtdie Will-Nachricht senden [MQTT-3.1.2-12]。

der Server sollteschnellaussendenclothWillNachricht。Inder Näheder MaschineoderFehlervonGefühlunter Umständen，der Server kannaufschiebenwirdeliminierenInformationausgebenStoffgeradezunachvonschweremStart.

Wenn diese Art vonFall, am ServerServerausfall und wirdnachdem die Nachricht veröffentlicht wurdees kann eine Verzögerung dazwischen geben。

3.1.2.6 wird QoS

Position:Die Connect-Flags' 4 und das 3 Bit.

Diese zwei Bits werden verwendet, um anzugebenpublishwillDer Dienst, der beim Senden einer Nachricht verwendet wirdQualitätsstufe.

wennDas Will-Flag ist auf 0，will QoS aucherforderlichGesetzt auf 0(0x00) [MQTT-3.1.2-13]。

wennDas Will-Flag ist gesetzt auf 1，Will QoS Wert vonkann gleich sein 0(0x00)，1(0x01)，2(0x02). EsWert vonkann nichtgleich sein 3

[MQTT-3.1.2-14]。

3.1.2.7 Will Retain

Position:Das Connect-Flags- 5 Bit.

MQTT-3.1.1-CN 24

wennWenn die Will-Nachricht veröffentlicht wird, muss sie beibehalten werdenRetain, muss angegeben werdender Wert dieses Bits.

wennDas Will-Flag ist gesetzt auf 0, belassenWill Retain (Will Retain）Flag ebenfallsErforderlichGesetzt auf 0 [MQTT-3.1.2-15]。

wennDas Will-Flag ist gesetzt auf 1：

 wennDas Will Retain ist gesetzt auf 0, der ServerErforderlichBehandeln Sie die Will-Nachricht als nicht-beibehaltene Nachrichtenveröffentlichung [MQTT-3.1.2-16]。

 Wenndas Will-Retain auf 1gesetzt ist, muss der ServerErforderlichdie Will-Nachricht so behandeln, als wäre sieals zurückbehaltene Nachricht veröffentlicht [MQTT-3.1.2-17]。

3.1.2.8 BenutzernameFlags

Position:Das Connect-Flags- 7 Bit.

Wenn das Benutzername-Flag (Benutzername) auf 0gesetzt ist, darf im Payloadnichtenthalten seinBenutzername-Feld [MQTT-3.1.2-18]。

Wenn das Benutzername-Flag (Benutzername) auf 1gesetzt ist, muss im PayloadErforderlichenthalten seinBenutzername-Feld [MQTT-3.1.2-19]。

3.1.2.9 Passwort-FlagWill

Position:Das Connect-Flags- 6 Bit.

Wenn das Passwort-Flag (Passwort)auf 0gesetzt ist, darf im Payloadnichtenthält ein Passwortfeld [MQTT-3.1.2-20]。

Wenn das Passwort-Flag (Passwort)auf 1gesetzt ist, muss im PayloadErforderlichenthält ein Passwortfeld [MQTT-3.1.2-21]。

Wenn das Benutzername-Flagauf 0gesetzt ist, muss das Passwort-Flag ebenfallsErforderlichauf 0 [MQTT-3.1.2-22]。

3.1.2.10 Keep Alive

Legende 3.5 Keep AliveByte

Bit

Byte 9

Keep Alive Keep Alive MSB

Byte 10

Keep Alive Keep Alive LSB

Keep Alive (Keep Alive) ist einein Wert in Sekundendas Zeitintervall, ausgedrückt alsa 16 Das Wort aus Bits, das sich bezieht aufder Client beendet die ÜbertragungCheng

vom Moment einer Steuernachricht bis zum Moment des Sendens der nächsten Nachricht, beidezwischenerlaubenzulassenLeerLeerlaufam meistengroßwennIntervallgetrennt。Client ist verantwortlichschützenbeweisensteuern

NachrichtaussendensendenvonwennIntervallgetrenntNeinüberschreitenübersteigenDer Keepalive-Wert.wennnichtJabeliebigseinesder SteuerungSystemBerichtText kannmitausgebensenden,Clienterforderlichsendena

PINGREQ Nachricht [MQTT-3.1.2-23]。

unabhängigWas der Keep-Alive-Wert ist, ClientClient jederzeitkönnen alle gesendet werden PINGREQ Paket, und verwenden PINGRESP Nachricht zur Bestimmung des Netzwerks

Netzwerk- und serverseitige Aktivitätaktiver Zustand.

wenn der KeepaliveWert vonnichtnull, undundKleidungServerIneinsKomma fünfMalvonschützenVerbindung aufrechterhaltenJiewennzwischeninnerhalbnichtempfangenanClientEndevonSteuerungBerichtText，eserforderlichbreak

Öffnen Sie das Netzwerk des ClientsVerbindung, betrachten Sie das NetzwerkNetzwerkverbindung wurde getrennt [MQTT-3.1.2-24]。

Der Client hat eine PINGREQ- Nachricht gesendetWenn er danach innerhalb einer angemessenen Zeitspannenoch immer kein PINGRESP empfangen hat Paket, essolltedie Verbindung zum Server schließen

Die Netzwerkverbindung des Endpunkts.

MQTT-3.1.1-CN 25

Der Wert des Keep-Alive istNull zeigt ananzeigenschließen behaltenhaltenverbindenJieVerdienstFähigkeit。das bedeutet, ServiceEndeNeinBrauchenwollenweilGastHaushaltEndpunkt nichtaktivundbreakopenconnectconnect.Hinweis：

Unabhängig vom Wert des keep-alive, zu jeder Zeit, solangeKleidungAngelegenheitEndpunkt erkenntistDer Client ist inaktiv oder reagiert nicht und kann getrennt werden.ClientEndpunktsconnect

connect.

nicht-normativerKommentar

Der tatsächliche Keep-Alive-WertWert wird von der Anwendungangegeben, normalerweiseein paar Minuten. Erlaubender maximale Wert ist 18 Stunden 12 Teilen 15 Sekunden.

3.1.2.11 Variabler Header nicht normativGeltungsbereichBeispiel

Legende 3.6 -Variabler Headernicht normativBeispiel

Beschreibung

Protokollname

Byte 1

Länge MSB (0)

Byte 2

Länge LSB (4)

Byte 3

‘M’

Byte 4

‘Q’

Byte 5

‘T’

byte 6

‘T’

Protokollebene

Beschreibung

byte 7

Pegel (4) Pegel

Verbindungs-Flag Verbindungs-Flags

Byte 8

Benutzername-Flag (1) Benutzername-Flag

Passwort-Flag (1) Dense-Code-Flag

Will Retain (0) Will Retain-Flag

Will QoS (01) Will Dienstgüte

Will Flag (1) Will Flags

Clean Session (1) BereinigungSitzung

Reserviert (0) reserviertes Bit

Keepalive-Zeit

Byte 9

Keep Alive MSB (0)

Byte 10

Keep Alive LSB (10)

MQTT-3.1.1-CN 26

3.1.3 payload

CONNECT Berichtdie Payload der NachrichtPayload (payload) enthält ein odermehrere längenkodierteein Feld mit Präfix, die Flags im variablen Headerbestimmenob

Enthält diese Felder.falls enthalten，ErforderlichErscheinen in dieser Reihenfolge: Client-IdentifierIdentifier, das Will-TopicProblem,WillMessage, Benutzername, Passwort

Code [MQTT-3.1.3-1]。

3.1.3.1 ClientIdentifikatoren

KleidungAngelegenheitEndemachenverwendenGastHaushaltEndeMarkierungkennenSymbol (ClientId) kennenandereGastHaushaltEnde。verbindenJieKleidungAngelegenheitEndevonjedeElementeGastHaushaltEndealleJanureinevonGastHaushaltEndeMarkierungkennenSymbol

（ClientId）。Client und Serverdie Endpunkte müssen verwenden ClientId wissenzwischen den beiden unterscheidenzwischen MQTT sitzungsbezogener ZustandBedingung [MQTT-3.1.3-

2]。

Client-Bezeichner (ClientId) ErforderlichExistiertaußerdemErforderlichJa CONNECT NachrichtDas erste der Nutzlastein Feld [MQTT-3.1.3-3]。

Client-BezeichnerErforderlichJa 1.5.3 definiert im Abschnitt UTF-8 codierte Zeichenkette [MQTT-3.1.3-4]。

ServerseitigErforderlichZulässig 1 bis 23 Bytes lang UTF-8 kodierter ClientClient-Bezeichner, der Clientder Client-Bezeichner darf nurdiese Zeichen enthalten:

“0123456789abcdefghijklmnopqrstuvwxyzABCDEFIJKLMNOPQRSTUVWXYZ”(Großbuchstaben,Kleinbuchstaben

und Zahlen)[MQTT-3.1.3-5]。

ServerseitigJaerlaubt, dass die kodierte ... überschreitetpass 23 ZeichenClient des AbschnittsBezeichner (ClientId). ServerJaerlauben Paketedie die oben nicht aufgeführten enthaltenZeichen darstellen

Der Client-Bezeichner (ClientId)。

ServerseitigJaerlaubt dem Client die Angabeein Nullzeichen bereitstellenDer Client-Bezeichner des Abschnitts (ClientId) , wennNachdem dies geschehen ist,ServerseitigErforderlichBehandeln Sie dies als speziell

Sonderfälle und weisen Sie einen eindeutigeneindeutigen Client-BezeichnerBezeichner diesem Client zuClient. Dann ist esErforderlichAngenommender Client bereitgestellt hatDieser eindeutige ClientBezeichner

Zeichen,normale VerarbeitungDiese CONNECT Nachricht [MQTT-3.1.3-6]。

Wenn der Client angibtein Null-Bytedes Client-BezeichnersSymbol, eserforderlichwird ebenfalls gelöschtSession-Flag gesetztgesetzt auf 1 [MQTT-3.1.3-7]。

Wenn der Client angibtvon ClientId null Bytes istund das Clean-Session-Flagmarkiert als 0, DienstEndeerforderlichsendet einen Rückgabecode von 0x02(was anzeigt, dass die Kennung nicht

gültig) von CONNACK Paketantwortdem Client antwortenvon CONNECT Nachricht，danndie Netzwerkverbindung schließen [MQTT-3.1.3-8]。

Wenn der Serverdiese ClientId，ablehnt, ist eserforderlich zusendenRückgabecode ist 0x02(Tabellegibt an, dass der Bezeichner ein ungültigesFormat hat) der CONNACK Paketantwort

des Clients CONNECT Paket,dann schließt die Netzwerkverbindung [MQTT-3.1.3-9]。

nicht-normativerKommentar

Die Client-Implementierung kanneine praktischeMethode bereitstellen, die verwendet wird, um zufälligevon ClientId zu generieren. Wenn die Clean SessionFlag auf 0 gesetzt ist, solltedass

Verzichten Sie proaktiv auf die Verwendung dieserMethode.

3.1.3.2 Will-Thema

wenndas Will-Flag auf 1gesetzt ist, gibt esdas nächste Feld der NutzlastFeld ist das WillThema (WWill Topic). WillTopicErforderlichJa 1.5.3 Abschnitt spezifiziert

semantische UTF-8 KodierungString [MQTT-3.1.3-10]。

MQTT-3.1.1-CN 27

3.1.3.3 Will-Nachricht

wennDas Will-Flag ist gesetzt auf 1, gibt esdas nächste Feld der NutzlastFeld ist die WillNachricht. Die Will-NachrichtNachricht definiert, waszum Will-Topic veröffentlicht wirdAntwort des Topics

Verwenden Sie die Nachricht, siehe 3.1.2.5 Beschreibung des Abschnitts. Dieses Feld besteht auseiner Zwei-Byte-Länge und die Will-Nachrichtdie Nutzlast der Nachrichtbestehend aus, dargestellt alsNull-Bytes oder

Mehrere Byte-Sequenzen.Länge gibt die folgendenDaten, die folgenAnzahl von Bytes, nichtenthältLängeDie zwei Bytes, die vom Feld selbst belegt werdenBytes.

WillWenn eine Nachricht zum Will-Topic veröffentlicht wird, enthält ihre PayloadPayload enthält nur dieseFelddatenTeil, enthält nicht das öffnendedie beiden Längenfelder des HeadersByte.

3.1.3.4 Benutzername

wenn das Flag für den Benutzernamen (Benutzername) auf 1gesetzt ist, sind die nächsten Teile der PayloadFelder genau das.BenutzernameErforderlichJa 1.5.3 Abschnittdefiniert

UTF-8 KodierungString [MQTT-3.1.3-11]. DienstServer kannes wird zur Identitäts-Authentifizierung und Autorisierung verwendet.

3.1.3.5 Password

Wenn das Passwort-(Password-)Flagauf 1gesetzt ist, ist das nächste Feld der Nutzlastes. PasswortDas Code-Feld enthält eine Zwei-Byte-Länge des Abschnitts

Felder，LängeGibt die Anzahl der Bytes binärer Daten an(ohne das Längenfeld selbstdie zwei Bytes, die es selbst belegtBytes), dannfolgt 0 bis 65535 Byte

Die Binärdaten.

Legende 3.7 - Passwort-Bytes

Bit

Byte 1

Datenlänge MSB

Byte 2

Datenlänge LSB

Byte 3 ….

Wenn die Länge größer als 0ist, folgt hier der Datenteil

3.1.4 response

Hinweis: Der Server kannsodass im selben TCP Port oder dessenUnterstützung an anderen Netzwerkendpunktenunterstützt mehrere Protokolle (einschließlich dieserfrühen Version des Protokollsdies).wenn der Server

Der Server stellt fest, dass das Protokoll MQTT 3.1.1ist, dannfolgt er der folgendenMethode zum Verifizieren der Verbindungsanfrage.

1. Nachdem die Netzwerkverbindung hergestellt ist, wenn der Serverinnerhalb einer angemessenen Zeitnicht innerhalb CONNECT empfangen hat meldenPaket, der Serversollteschließendiese Verbindung

connect.

2. ServerseitigErforderlichgemäß 3.1 Abschnittsanforderung Verifizierung CONNECT Paket,wennPaket nicht mitSpezifikation übereinstimmt, der Serversendet nicht

CONNACK Nachrichtdirekt schließenNetzwerkverbindung [MQTT-3.1.4-1]。

3. ServerseitigJaPrüft CONNECT des Paketsob der Inhalt erfülltjede weitereEinschränkung erfüllt,JaIdentitätAuthentifizierung und Autorisierung durchführen

Prüfungen. Wenn eine Prüfung nicht bestanden wirdjedoch, gemäß 3.2 der Beschreibung des Abschnitts, essolltesende einen geeignetengeeigneten,Rückgabecode ungleich null

CONNACK Antwort, undErforderlichdiese Netzwerkverbindung schließen.

Wenn die Verifizierung erfolgreich ist,der Server wirddie folgenden Schritte ausführen.

1. falls ClientId angibtDer Client hat sich mit diesem Server verbundenServer, dann der ServerErforderlichden bestehenden Client trennenClient-Verbindung [MQTT-

3.1.4-2]。

2. ServerseitigErforderlichgemäß 3.1.2.4 AbschnittvonBeschreibungAusführenden Sitzungsbereinigungsprozess [MQTT-3.1.4-3]。

3. ServerseitigErforderlichsendet einen Rückgabecode vonNull CONNACK Paket als CONNECT des PaketsBestätigungsantwort [MQTT-3.1.4-4]。

4. Nachrichtenverteilung starten undden Verbindungszustand beibehaltenüberwachen.

MQTT-3.1.1-CN 28

Erlaubtder Client sendet CONNECT Nachrichtsendet unmittelbar danachAndere Steuerpakete;Client nichtMuss auf den des Servers warten CONNACK

Paket.wennder Server abgelehnt hat CONNECT, eskann nichtden Client verarbeitenIn CONNECT nach dem Paket sendenalle gesendeten Daten [MQTT-

3.1.4-5]。

nicht-normativerKommentar

Der Client wartet normalerweisewartet auf ein CONNACK Paket. Allerdingshat der Client das Recht zuempfangen CONNACK bevorSteuerpakete senden，

Da keine Notwendigkeit besteht,Verbindungszustand zu verwalten, kann diesdie Implementierung des Clients vereinfachenerscheinen.

3.2 CONNACK – Verbindungsanforderung bestätigenFinden

der Server sendet CONNACK NachrichtAntwort vom Clientempfangen CONNECT meldenPaket. Der Serveran den Client gesendetdie erste Nachricht vonmuss

benötigtJa CONNACK [MQTT-3.2.0-1]。

Wenn der Client ininnerhalb einer angemessenen Zeit nichtvom Server empfangen hatvon CONNACK Paket,ClientsollteNetzwerk schließenNetzwerkverbindung.

angemessen

die benötigte Zeit

Hängt von der Art der Anwendung abund Kommunikationsinfrastrukturimplementieren.

3.2.1 Fester Header

Das Format des Fixed Headerssiehe Legende 3.8 – CONNACK BerichtText festFixed Header die Beschreibung von。

Legende 3.8 – CONNACK Paket-Fixed-Header

Bit

Byte 1

MQTT Steuerpakettyp (2)

Reserviert reserviertes Bit

Byte 2

verbleibende Länge (2)

verbleibende LängeLängenfeld

RepräsentiertDie Länge des Variable Headers. Für CONNACK Nachrichtdieser Wert entspricht 2。

3.2.2 Variabler Header

Das Format des Variable Headerssiehe Legende 3.9 –CONNACK Nachricht kannVariable Header vonBeschreibung.

Legende 3.9 –CONNACK Paket-Variable-Header

Beschreibung

Verbindungsbestätigungs-Flags

Reserviert reserviertes Bit

Byte 1

Verbindungs-Rückgabecode

Byte 2

MQTT-3.1.1-CN 29

3.2.2.1 VerbindungsbestätigungBestätigungsflag

Anz. 1 Bytes sind

Verbindungsbestätigungs-Flags

, Bit 7-1 soll sicherstellenReserviertes Bit undErforderlichGesetzt auf 0。

Anz. 0 (SP)Bits ist aktuelleSession（Session Present）Flags。

3.2.2.2 aktuelle SitzungSprache

Position:Das Bit des Verbindungsbestätigungs-Flags 0 Bit.

Wenn der Server empfängtClean Session (CleanSession）Flagsist 1 vonVerbindung, außerwürde CONNACK Der Rückgabecode im PaketGesetzt auf 0

zusätzlich, auchErforderlichwird CONNACK im Paketaktuelle Sitzungseinstellung（Session Present）Flagsist 0 [MQTT-3.2.2-1]。

Wenn der Server empfängta CleanSession ist 0 vonVerbindung,aktuelles Sitzungsflagder Wert hängt davon ab, ob der Serverob er bereits gespeichert hat ClientId

Die Sitzung des entsprechenden ClientsSitzungszustand. Wennder Server bereits gespeichert hatden Sitzungszustand gespeichert hat, esErforderlichwird CONNACK Die aktuelle Sitzung im PaketSitzungsflag gesetzt

gesetzt auf 1 [MQTT-3.2.2-2]。Wenn der Serveres gibt kein gespeichertesSitzungszustand, esErforderlichwird CONNACK meldenin der Nachrichtaktuelle Sitzungseinstellung

ist 0. Es ist auch notwendig, CONNACK meldender Rückgabecode im Text ist gesetzt auf 0 [MQTT-3.2.2-3]。

Das aktuelle Sitzungsflag wird verwendetServer und Clientob es bereitsden gespeicherten Sitzungszustand beibehaltenkonsistent bleiben.

Sobalddie Sitzungsinitialisierungseinstellungen abgeschlossen sind, bereits die Sitzung gespeichert hatder Client mit Sitzungszustand wird erwartenerwartet, dass der Server beibehältes speichertden Sitzungszustand.wenn Client

Der Client empfängt vom ServerempfangenenaktuellenDer Wert weicht von dem erwarteten ab, der Client kannwählen, dies fortzusetzenSitzung oder trennen.Clientkann verwerfen

Verwerfen Sie die Client- und ServerSitzung zwischen EndpunktenZustand, Methodeist,trennen, dannClean-Session-FlagFlag ist gesetzt auf 1, erneut verbinden,dannwieder

Trennen.

Wenn der Server sendetenthielt ein Nicht-mit einem Null-Rückgabecode CONNACK Paket, esErforderlichdient alsFlag für vorherige SitzungGesetzt auf 0 [MQTT-

3.2.2-4]。

3.2.2.3 VerbindungsrückgabeAntwortcode

Position:des Variable Headers 2 ein Byte。

Feld für Connect-Rückgabecodeunter Verwendung eines Ein-Byte-vorzeichenlosen Werts,In Tabelle 3.1 – VerbindungsrückgabeWert des Rückgabecodes Aufgeführt in. Wenn der Server empfängtein gültiges

Methode CONNECT Paket, aber scheinbaraus irgendeinem Grund nichtverarbeiten kann, der ServerServer sollte versuchensenden Sie eines, das eine Rückgabe ungleich null enthältRückgabecode (in der Tabellevon

eines bestimmten) CONNACK Paket. Wennder Servereines mit einem Rückgabecode ungleich Null gesendet hatvon CONNACK Paket,dann ist eserforderlich,zu schließen

Netzwerkverbindung schließen [MQTT-3.2.2-5].。

Tabelle 3.1 –Wert des Connect Return Code

Wert

RückgabecodeAntwort

Beschreibung

0x00 Verbindung akzeptiertakzeptieren

Die Verbindung wurde vom Server akzeptiertAkzeptieren

0x01 Verbindung abgelehntabgelehnt, nicht unterstütztProtokollversion

Der Server unterstützt den Client nichtvom Client angefordert MQTT Protokollebeneandere

0x02 Verbindung abgelehntabgelehnt, nichteine gültige Client-ID

Die Client-ID istkorrekt UTF-8 Kodierung,AberDienste

Der Endpunkt darf nicht verwendet werden

0x03 Verbindung abgelehntabgelehnt, ServerServer nicht verfügbar

Die Netzwerkverbindung wurde hergestellt, aber MQTT Dienst nicht verfügbar

0x04 Verbindung abgelehntabgelehnt, ungültigerBenutzername oder Passwort

des Benutzernamens oder Passwortsungültiges Datenformat

MQTT-3.1.1-CN 30

0x05 Verbindung abgelehntabgelehnt, nichtautorisiert

Der Client ist nicht autorisierteine Verbindung zu diesem Dienst herzustellenGerät

6-255

beibehalten

Wenn Sie der Meinung sind, dass in der obigen Tabellealle Verbindungen liefernkeiner der Rückgabecodes geeignet ist，dannserverseitigerforderlichSchließen Sie die Netzwerkverbindung,es muss nicht gesendet werden CONNACK Meldung

Text [MQTT-3.2.2-6]。

3.2.3 payload

CONNACK Nachrichtkeine gültigeNutzlast.

3.3 PUBLISH – Nachricht veröffentlichen

PUBLISH Steuerpaket bezieht sich auf vom ClientClient zu Serveroder Server zum Clienteine Anwendung übertragenNachricht.

3.3.1 Fester Header

Legende 3.10 – PUBLISH MeldungPaket-Fixed-Headerbeschreibt den Fixed HeaderHeader-Format

Legende 3.10 – PUBLISH Paket-Fixed-Header

Bit

Byte 1

MQTT SteuerpaketNachrichtentyp (3)

DUP

QoS -Stufe

RETAIN

Byte 2

verbleibende Länge

3.3.1.1 Retransmissions-Flagwird

Position:Nr. 1 Byte, die 3 Bits

wenn DUP -Flag auf 0gesetzt ist, was anzeigt, dass dies eine Client- oder ServerServer-Erstanfrage istAnfrage, dieses PUBLISH Paket zu senden.wenn DUP Flags

ist auf 1gesetzt, Tabellezeigt an, dass dies einefrühere PaketanforderungNeuübertragung der Anfrage sein kann.

Client oder ServerAnfrage, ein PUBLISH erneut zu senden, wenn die Nachricht,Erforderlichwird DUP MarkierungFlag ist auf 1 [MQT gesetztT-3.3.1.-1].. Für QoS

0 die Nachricht,DUP FlagsErforderlichGesetzt auf 0 [MQTT-3.3.1-2]。

der Server sendet PUBLISH Nachrichtan den Abonnentenwenn,empfangenvon (eingehend) PUBLISH des Pakets DUP Wert des Flagswird nicht weitergegeben.aussenden

gesendet (ausgehend) PUBLISH Nachrichtund empfangenvon (eingehend) PUBLISH im Paket DUP das Flag ist unabhängigunabhängig gesetzt,sein WertErforderlich

individuell je nach dem Sendenvon (ausgehend) PUBLISH Nachrichtob es eine erneute Übertragung istgesendet, um zu bestimmen [MQTT-3.3.1-3]。

nicht-normativerKommentar

der Empfänger empfängt ein DUP Flag ist 1 vonControl Packet,kann nicht annehmen, dass er es siehteines vor diesem Paketein Duplikat von.

nicht-normativerKommentar

Was speziell hervorgehoben werden muss, istist,DUP MarkierungProtokoll konzentriert sich auf die SteuerungControl Packet selbst,mit der Anwendungsnachricht, die es enthältirrelevant. Bei Verwendung von QoS 1

wenn,Ein Client könnte ein DUP Flag ist 0 von PUBLISH Paket,DiesesPaket enthält einEines, das es zuvor empfangen hatte

eine Kopie der Anwendungsnachricht, aber die verwendete hateine andere PaketkennungKennung. 2.3.1 Abschnitt bietet einigebezüglich der Paketkennungweitere Informationen.

MQTT-3.1.1-CN 31

3.3.1.2 Dienstgütestufe

Position:Nr. 1 Byte, das 2-1 Bit.

Dieses Feld gibt die Anwendungsnachrichtfür die NachrichtenverteilungDienstgütestufen-Garantie an.DienstgüteQualitätsstufe in Tabelle 3.2 -Dienstgüte-Definition inaufgeführt.

Tabelle 3.2 -DienstgüteDefinition

QoS Wert

Bit 2

Bit 1

Beschreibung

höchstens einmal

mindestens einmal

nur einmal zustellen

reserviertes Bit

PUBLISH Nachrichtkann nichtWill QoS Platzeinige Bits sind gesetzt auf 1。wennServer oder ClientClientempfangen QoS Alle Bits sind 1 von PUBLISH

Paket, esErforderlichNetzwerkverbindung schließenJie [MQTT-3.3.1-4]。

3.3.1.3 Retain-FlagWill

Position:Nr. 1 Byte, das 0 Bit.

Wenn der Client sendet andes Servers PUBLISH des Paketsretain (RETAIN）Flag ist gesetztist 1, der ServerErforderlichdiese Anwendungsnachricht speichern

Informationen undesvonDienstenQualitätwartenStufe（QoS）, umbequemesJaDurchverteilenzu noch nichtkommenvonHauptTitelübereinstimmenzugewiesenabonnierenLeser [MQTT-3.3.1-5]。a

NeuesAbonnementaufbauensofort, fürjedenÜbereinstimmungvonTopicName，wennspeichernInaktuellschützenverbleibendeliminierenNachricht,esErforderlichwird gesendetsenden anDiesabonnierenLeser [MQTT-

3.3.1-6]. Wenn der Serverder Client eine beibehaltene Nachricht empfängt（RETAIN) Flag ist 1 von QoS 0 Nachricht,esErforderlichverwerfenzuvor für dieses TopicTopic beibehalten

einer beliebigen Nachricht. Essolltewirdeine neue QoS 0 Nachricht wie dieses Topiceine neue beibehaltene Nachricht zum Topic, aberjederzeitJawählt, sie zu verwerfen

— wennWenn dies auftritt, diesesTopic wird keine beibehaltenebeibehaltene Nachricht [MQTT-3.3.1-7]。bezogen auf SpeicherzustandFür weitere Informationen siehe 4.1 Abschnitt.

Serverseitigsenden PUBLISH Nachricht anwenn der Client, z. B.wenn die Nachricht als Clienteine neuedas Abonnementergebnis wird gesendetsenden, esErforderlichdas Retain des Pakets

Retain-Flag gesetzt auf 1 [MQTT-3.3.1-8]. Wenn ein PUBLISH BerichtText gesendetan den Client gesendet, weil er übereinstimmteiner bereits bestehenden zuweisenwenn das Abonnement, der Server

ServerErforderlichRetain-Flag setzen auf 0, unabhängig davondie empfangene Nachrichtin der NachrichtRetainWelchen Wert hat das Flag [MQTT-3.3.1-9]。

RetainFlag ist 1 und gültigdie Payload null Bytes beträgtvon PUBLISH BerichtNachricht wirdder Server behandelt sie als normale Nachrichtbei der Verarbeitung wird siean das abonnierte Topic gesendet

passendClientEnde。zusätzlich，gleichaHauptTopicUntenbeliebigvorhandenspeichernvonRetaineliminierenAtemErforderlichdurchverschiebenaufteilen，Daher这ElementeTopicvonnachvonbeliebigabonnierenlesenalle

wird nicht empfangenan einebeibehaltene Nachricht [MQTT-3.3.1-10]。

als normal behandelt

Es bedeutetvorhandeneder Client empfängtder NachrichtMediumdas Retain-Flag ist nichtist gesetzt。

Serverseitigkann nichteine Zero-ByteRetained Message speichern [MQTT-3.3.1-11]。

Wenn der Client anden Server ein PUBLISH des Pakets sendet,Retain-Flag-Bit 0，Serverseitigkann nichtdiese Nachricht speichernauchkann nichtkeine entfernen oder ersetzen

vorhandene Retained Messages [MQTT-3.3.1-12]。

nicht-normativerKommentar

nicht für den Publisher festgelegtregelmäßig Statusnachrichten sendenNachricht, in diesem Szenario,Retained Messages sind sehrnützlich. Neue Abonnementsder Abonnent empfängt den neuesten StatusStatus.

verbleibende LängeLängenfeld

entsprichtdie Länge des Variable Headers plus der Payloadder Länge des Payloads.

MQTT-3.1.1-CN 32

3.3.2 Variabler Header

Variable Header in der ReihenfolgeenthältTopicName und Paketbezeichner.

3.3.2.1 Topic-Name

Topic-Name (Topic Name) verwendet, umdie Payload zu identifizierenwo die Daten veröffentlicht werden solleneinen Informationskanal。

Topic-NameErforderlichJa PUBLISH Berichtvariabler HeaderDas erste Feld des Headers.esErforderlichJa 1.5.3 Abschnittdefiniert UTF-8 codierte Zeichenkette

[MQTT-3.3.2-1]。

PUBLISH NachrichtTopic-Name in derdarf nichtWildcardÜbereinstimmungszeichen enthalten [MQTT-3.3.2-2]。

Der Server sendet an den Subscriberdes abonnierenden Clients PUBLISH NachrichtTopic-NameErforderlichentsprechendem Topic des SubscriptionFilters (gemäß 4.7 Übereinstimmung, die im Abschnitt definiert ist

Prozess）[MQTT-3.3.2-3]。

3.3.2.2 PaketbezeichnerBezeichner

nur wenn QoS waitLevel ist 1 oder 2 wenn, Paketbezeichner（Packet Identifier) Feldkann nur in PUB auftretenLISH im Paket.2.3.1

Der Abschnitt enthält Informationen über das PaketAktualisierung der Paketkennungweitere Informationen.

3.3.2.3 variabler Headernicht-normativer HeaderBeispiel

Legende 3.11 – PUBLISH BerichtVariabler Header des PaketsNicht-normatives Beispiel veranschaulicht Tabelle 3.3 - PUBLISH Berichtnicht-normatives Beispiel kurz beschreiben

beschrieben PUBLISH den variablen Header des PaketsHeader.

Tabelle 3.3 - PUBLISH Nicht-normatives Beispiel der Nachricht

Feld

Wert

Topic-Name

a/b

Paketkennung

Legende 3.11 – PUBLISH variabler Header des PaketsNicht-normatives Beispiel

Beschreibung

Themennamee Themenname

Byte 1

Länge MSB (0)

Byte 2

Länge LSB (3)

Byte 3

‘a’ (0x61)

Byte 4

‘/’ (0x2F)

Byte 5

‘b’ (0x62)

Paketkennung

byte 6

Paketkennung MSB (0)

byte 7

Paketkennung LSB (10)

MQTT-3.1.1-CN 33

Der Themenname im Beispielist “a/b”，Längegleich 3, die Paketkennung ist “10”

3.3.3 payload

Die Nutzlast wird enthaltendie veröffentlichte Anwendungsnachricht. Der Dateninhalt und das Format sindanwendungsspezifisch.die Länge der Nutzlastwird wie folgt berechnet:mit festem

die verbleibende Länge im Headerder Wert des Length-Feldes minussubtrahiere die Länge des variablen Headers.enthält nullNutzlastlängevon PUBLISH Berichtdas Paket ist gültig.

3.3.4 response

PUBLISH Nachrichtder EmpfängerErforderlichgemäßGemäß PUBLISH im Paket QoS QoS-Stufe, um eine Antwort zu senden, siehe die Tabelle untenFormatbeschreibung [MQTT-

3.3.4-1]。

Tabelle 3.4 – PUBLISH die erwartete Paketantwort

Quality of Service-Stufe

erwartete Antwort

QoS 0

keine Antwort

QoS 1

PUBACK Nachricht

QoS 2

PUBREC Nachricht

3.3.5 action

der Client verwendet PUBLISH; das Paket sendet eine AnwendungsNachricht an den Server, um zu verteilenan andere passende Abonnementspassende Clients.

der Server verwendet PUBLISH; das Paket sendet eine AnwendungsNachricht an jedeAbonnementÜbereinstimmungder Client.

Der Client verwendet BandpassWildcard-Topic-Filterwenn der Filter ein Abonnement anfordert, der Clientdas Abonnement des Clients kannwiederholt werden，Daherveröffentlichte Nachrichten können mehreren entsprechen

einen Filter. DennIn diesem Fall, der ServerServerErforderlichliefert die Nachricht analle passenden Abonnementszugewiesen QoS wartender Client mit der höchsten Ebene [MQTT-3.3.5-

1]. Des Serversdann entsprechend dem Abonnementvon QoS Stufe, die Verteilung der Nachrichteine Kopie an jedenpassenden Abonnenten。

erhalten einen PUBLISH Berichtwenn die Nachricht,die Aktion des Empfängershängt ab von 4.3 Abschnittbeschriebene QoS WarteStufe.

wennDie Serverimplementierung einen Client nicht autorisiertClient veröffentlicht PUBLISH Paket,hat sie keine Möglichkeit, das mitzuteilenClient. Eserforderlichgemäß normalnormal

QoS Regel senden: Senden Sieeine positiveBestätigung, oderschließen Sie die Netzwerkverbindung [MQTT-3.3.5-2]。

3.4 PUBACK –gibtVeröffentlichungsbestätigung aus

PUBACK Nachrichtist korrekt QoS 1 Ebenevon PUBLISH BerichtAntwort auf das Paket。

3.4.1 Fester Header

Legende 3.12 - PUBACK BerichtText festgelegtbestimmte Nachrichthead

Bit

Byte 1

MQTT SteuerpaketNachrichtentyp (4)

reserviertes Bit

MQTT-3.1.1-CN 34

Byte 2

verbleibende Länge(2)

verbleibende LängeLängenfeld

die Länge des Variable Headers angebend. Für PUBACK Nachrichtentspricht dieser Wert 2.

3.4.2 Variabler Header

enthält diejenigen, die auf Bestätigung warten PUBLISH das Paket der NachrichtPacket Identifier.

Legende 3.13 – PUBACK variabler Header des Pakets

Bit

Byte 1

Paketkennung MSB

Byte 2

Paketkennung LSB

3.4.3 payload

PUBACK Nachrichtkeine Nutzlast。

3.4.4 action

siehe die vollständige Beschreibung im 4.3.2 Abschnitt.

3.5 PUBREC – Veröffentlichungempfangen (QoS 2, Schritt 1)

PUBREC BerichtNachricht ist korrekt QoS Ebene 2 von PUBLISH meldetdie Antwort auf die Nachricht. Es ist QoS 2 QoS-Protokollaustauschdie zweite Nachricht des AustauschsText.

3.5.1 Fester Header

Legende 3.14 – PUBREC fester Nachrichten-Header

Bit

Byte 1

MQTT SteuerpaketNachrichtentyp e (5)

reserviertes Bit

Byte 2

verbleibende Länge (2)

verbleibende LängeLängenfeld

was dieLänge des variablen Headers angibt. Für den PUBREC -Bericht ist derNachrichtenwert gleich. 2。

3.5.2 Variabler Header

Der variable Header enthält usw.ausstehende Bestätigung PUB MeldungPaketkennung des PaketsKennung.

MQTT-3.1.1-CN 35

Legende 3.15 – PUBREC variable NachrichtHeader

Bit

Byte 1

Paketkennung MSB

Byte 2

Paketkennung LSB

3.5.3 payload

PUBREC MeldungDie Nachricht hat keine Nutzlast.。

3.5.4 action

siehe die vollständige Beschreibung im 4.3.3 Abschnitt.

3.6 PUBREL – veröffentlichenfreigeben (QoS 2, Schritt 2)

PUBREL Nachrichtist korrekt PUBREC die Antwort auf die Nachricht.Es ist QoS 2 wartetdes Protokoll-Austauschs auf Protokollebeneauf die dritte Nachricht.

3.6.1 Fester Header

Legende 3.16 – PUBREL Paket-Fixed-Header

Bit

Byte 1

MQTT SteuerpaketNachrichtentyp (6)

reserviertes Bit

Byte 2

verbleibende Länge (2)

PUBREL SteuerungPaket-Fixed-HeaderDas erste Bit des Headers 3,2,1,0 ist das Retain-Bit，Erforderlichist gesetzt auf 0,0,1,0. DienstendeErforderlichjeder andere Wert

gelten alle als unzulässigund schließen die Netzwerkverbindung [MQTT-3.6.1-1]。

verbleibende LängeLängenfeld

was die Länge des variablen Headers angibt. Für PUBREL melden Sie:Der Wert des Pakets entsprichtin 2.

3.6.2 Variabler Header

der variable Header enthält undwartet auf Bestätigung PUBREC Nachrichtdieselbe NachrichtenkennungBezeichner.

Legende 3.17 – PUBREL variabler Header des Pakets

Bit

Byte 1

Paketkennung MSB

Byte 2

Paketkennung LSB

MQTT-3.1.1-CN 36

3.6.3 payload

PUBREL Nachrichthat keine PayloadNutzlast.

3.6.4 action

siehe die vollständige Beschreibung im 4.3.3 Abschnitt.

3.7 PUBCOMP – Veröffentlichung abgeschlossen (QoS 2, Schritt 3)

PUBCOMP meldetNachricht ist korrekt PUBREL meldetAntwort auf das Paket. Es ist QoS 2 Ebenedes Protokollaustauschsvierte und letzteein Paket.

3.7.1 Fester Header

Legende 3.18 – PUBCOMP Nachricht festfester Header

Bit

Byte 1

MQTT SteuerpaketNachrichtentyp (7)

reserviertes Bit

Byte 2

verbleibende Länge (2)

verbleibende LängeLängenfeld

was die Länge des variablen Headers angibtLänge. Für PUBCOMP meldetdieser Textein Wert gleich 2。

3.7.2 Variabler Header

der variable Header enthält undwartet auf Bestätigung PUBREL Nachrichtdasselbe PaketBezeichner.

Legende 3.19 – PUBCOMP Nachricht kannvariablen Header

Bit

Byte 1

Paketkennung MSB

Byte 2

Paketkennung LSB

3.7.3 payload

PUBCOMP meldetNachricht hat keinenPayload.

3.7.4 action

siehe die vollständige Beschreibung im 4.3.3 Abschnitt.

MQTT-3.1.1-CN 37

3.8 SUBSCRIBE - Abonnement-Topic

Client-zu-Servergesendete SUBSCRIBE Nachricht, verwendet zumErstellen eines oder mehrererAbonnements. JedesDas Abonnement registriert den Clientfür ein Topic, das den Client interessiertoder mehrere

Topic. Umdie Nachricht weiterzuleiten anden diesen Abonnements entsprechendenpassenden Topic, der ServerServer sendet PUBLISH meldenPacket an den Client。SUBSCRIBE

die Nachricht spezifiziert außerdem (für jedesdas Abonnement)maximales QoS WarteLevel, der Serverauf dieser Grundlage sendendie Anwendungsnachricht an den Client zustellen.

3.8.1 Fester Header

Legende 3.20 – SUBSCRIBE Nachricht festfester Header

Bit

Byte 1

MQTT SteuerpaketNachrichtentyp (8)

reserviertes Bit

Byte 2

verbleibende Länge

SUBSCRIBE SteuerSteuerpaket Fixed Headerder 3,2,1,0 Bitsist beibehaltenesBit,Erforderlichjeweils gesetzt auf 0,0,1,0. ServerErforderlichjeder andere

jeder Wert wird als nichtgültig behandelt und schließt dieNetzwerkverbindung [MQTT-3.8.1-1]。

verbleibende LängeLängenfeld

entsprichtDie Länge des variablen Headers (2 Byte) plus die NutzlastLänge der Nutzlast.

3.8.2 Variabler Header

der Variable Header enthält den ClientClient-Identifier.2.3.1 Angabenüber das PacketWeitere Informationen über Identifier.。

3.8.2.1 variabler Headernicht-normativer HeaderBeispiel

Legende 3.21 – Paketkennungentspricht 10 des Variable Headers, ein nicht normatives BeispielBeispiel zeigt die Nachrichtdie Nachrichtenkennung ist gesetzt auf 10 Variable Header, wenn

Header.

Legende 3.21 – NachrichtBezeichnerBezeichner gleich 10 kann seinvariable NachrichtHeader, nicht normatives BeispielBeispiel

Beschreibung

Paketkennung

Byte 1

Paketkennung MSB (0)

Byte 2

Paketkennung LSB (10)

3.8.3 payload

SUBSCRIBE des PaketsNutzlastenthält ein ThemaThemenfilterliste,sie repräsentieren den Clientdie Themen, die der Client abonnieren möchte。SUBSCRIBE

NachrichtThemenfilter in der NutzlastListeErforderlichJa 1.5.3 Abschnittdefiniert UTF-8 String [MQTT-3.8.3-1]. DienstServersollteUnterstützt

enthält ein Wildcard (4.7.1 Abschnitt gibt anBedeutung) desThemenfilters. Fallswenn der Server sich entscheidet, nicht zu unterstützenWildcards enthaltendThemenfilter,ErforderlichAblehnen

beliebige Wildcards enthaltendedas Abonnement des FiltersAnfrage [MQTT-3.8.3-2]。Nach jedem Filtergefolgt von einem Byte, dieses Byte wirdgenannt Kleidung

Quality-of-Service-Anforderung (angeforderte QoS）. Sie gibt dem ServerServer zu Clientder Client sendet Anwendungsnachrichtdurch die Nachricht erlaubtesmaximales QoS Level.

MQTT-3.1.1-CN 38

SUBSCRIBE des PaketsPayloadErforderlichenthältmindestensein Paar ausTopic-Filter und QoS LevelFeldkombination.keine Nutzlastvon

SUBSCRIBE Bericht:Die Nachricht ist ein Protokollverstoßvon [MQTT-3.8.3-3]。zur Fehlerbehandlungbitte siehe die Informationen zur Behandlung 4.8 Abschnitt.

der maximal angeforderte ServiceQuality-of-Service-Level-Feldals ein WortByte kodiert, danachfolgt UTF-8 bearbeitenden Topic-Namen des Codes,diese Topic-Filter /und

QoS Level-Kombinationsind aufeinanderfolgend gepackt.

Legende 3.22 – SUBSCRIBE NachrichtPayloadFormatierung

Beschreibung

Topic-Filter

Byte 1

Länge MSB

Byte 2

Länge LSB

Bytes 3..N

Topic-Filter（Topic-Filter）

QoS-Anforderungen (Angeforderte QoS）

reserviertes Bit

Quality of Service-Stufe

Byte N+1

die aktuelle Version des Protokollsverwendete den Dienst nichtQoS-Anforderung (Angeforderte QoS）die oberen sechs Bits des Bytes. Wenn die Payloadbeliebige in der PayloadBit ist nicht-

Nullwert,oder QoS Nicht gleich 0,1 oder 2, der ServerErforderlichbetrachten SUBSCRIBE Paket istungültige Uniondie Netzwerkverbindung schließen [MQTT-

3-8.3-4]。

3.8.3.1 PayloadPayload nicht normativBeispiel

Legende 3.23 – Payload-WortByte-Format nicht standardisiertBeispiel Anzeigebereits Tabelle 3.5 – Janicht-normative PayloadBeispiel kurz beschrieben in

SUBSCRIBE meldetdie Payload des Pakets。

Tabelle 3.5 – PayloadPayload ist nichtnormatives Beispiel

Topic-Name

“a/b”

Quality-of-Service-Anforderungen

0x01

Topic-Name

“c/d”

Quality-of-Service-Anforderungen

0x02

Legende 3.23 – gültigPayloadByte-Format nicht-Spezifikation zeigtBeispiel

Beschreibung

Topic Filter (Topic Filter）

Byte 1

Länge MSB (0)

Byte 2

Länge LSB (3)

Byte 3

‘a’ (0x61)

MQTT-3.1.1-CN 39

Byte 4

‘/’ (0x2F)

Byte 5

‘b’ (0x62)

QoS-Anforderungen (Angeforderte QoS）

byte 6

Requested QoS(1)

Topic Filter (Topic Filter）

byte 7

Länge MSB (0)

Byte 8

Länge LSB (3)

Byte 9

‘c’ (0x63)

Byte 10

‘/’ (0x2F)

Byte 11

‘d’ (0x64)

QoS-Anforderungen (Angeforderte QoS）

Byte 12

Requested QoS(2)

3.8.4 response

der Server empfängt den Clienteines, das vom Endpunkt gesendet wurde SUBSCRIBE wenn die Nachricht,ErforderlichVerwendung SUBACK Paketantwort [MQTT-3.8.4-1]。

SUBACK NachrichtErforderlichund wartet auf Bestätigung SUBSCRIBE Nachrichthaben dieselbe PaketkennungSymbol [MQTT-3.8.4-2]。

erlaubt es dem Server zu sendensenden SUBACK Berichtvor der Nachrichtdann mit dem Senden und Abonnieren beginnenpassendes PUBLISH Paket.

Wenn der Server empfängta SUBSCRIBE Paket, PaketDer Themenfilter eines bestehenden Abonnementsmit dem Themenfilter übereinstimmendgleich,dannErforderlich

das neue Abonnement verwenden, um vollständigersetzt das bestehendeAbonnement. Die Themen des neuen Abonnementsder Filter und der vorherigedieselben wie das Abonnement,aber esder maximale QoS Wertkann nicht

gleich.Das passt zu diesem Themenfilteralle vorhandenen zurückbehaltenenzurückbehaltene NachrichtErforderlichwird erneut übertragen,aber der Veröffentlichungsablaufkann nichtMediumunterbrechen [MQTT-3.8.4-3]。

wenn der Themenfiltervon allen bestehenden verschieden istgespeicherte Abonnementfilter, der Serverder Server erstellt einein neues Abonnement und sendet allepassende zurückbehalteneNachricht.

Wenn der Servermit mehreren Themendes Filters ein SUBSCRIBE Paket empfängt,erErforderlichals ob er eine Reihevon mehreren SUBSCRIBE

die Nachricht genauso behandeln, danneine,außermüssen ihre Antworten kombinierenzusammengeführt zu einer einzigenunabhängigen SUBACK Nachrichtsenden [MQTT-3.8.4-4]。

der Server sendet an den Clientdes Clients SUBACK BerichtTextpaarjedes Paar von Themenfiltern und QoS wartenalle StufenErforderlichenthält einen Rückgabecode.DieserRückgabe-

CodeErforderlichgibt an, dass dem Abonnementdie maximal gewährte QoS Stufe gewährt wird,oderzeigt an, dass dieses Abonnement fehlgeschlagen ist [MQTT-3.8.4-5]. Der Server kannzu gewähren als

niedriger als die Anforderung des Abonnenteneinige von QoS Ebene.als Antwort auf das Abonnement gesendetder gesendeten Nachrichtder Nutzlast QoS Erforderlichist die der ursprünglich veröffentlichten Nachricht

QoS und Dienstvom Endpunkt gewährt QoS der beidenMindestwert. Wenn die ursprüngliche NachrichtInformationen QoS Ja 1 und die maximal gewährte QoS Ja 0, erlaubenServer erlauben

Der Server sendet erneut eineeine Kopie der Nachrichtan den Abonnenten [MQTT-3.8.4-6]。

nicht normativBeispiel

für ein bestimmtes ThemaThemenfilter,wennderzeit abonniert,wird dem Clientdas Maximum gewährt QoS warteStufe ist 1, dannpassend zu diesem Filter

des Filters QoS Stufe 0 die Anwendungsnachricht wird gemäß QoS Stufe 0 an diesen Client zugestellt.das bedeutet, der Clientder Client wird höchstens dies empfangen

MQTT-3.1.1-CN 40

eine Kopie der Nachricht. Andererseits,das heißt, Veröffentlichen an dasselbeeines Themas QoS Stufe 2 der Nachrichtwird vom Server herabgestuft auf QoS warte

Stufe 1 an Client weiterverteilenClient, daher der Clientder Client kann empfangendoppelte NachrichtenKopie.

Wenn der aktuell abonniertedem Client gewährt wirddas maximale QoS -Level ist 0, dannursprünglich von QoS -Level 2 anClient-Anwendung veröffentlicht

Nachricht kann, wenn ausgelastet,verloren gehen,Aberder Server sollte nichteine doppelteNachrichtenkopie senden. An dieselbe veröffentlicheneines Themas QoS -Level

1 Nachricht auf dem Transportwegkann bei der Zustellung an den Clientverloren gehen oder dupliziert werden.

nicht-normativerKommentar

Verwendung QoS -Level 2 abonnierenEinen Themenfilter abonnieren, der gleich ist zudas heißt:

Ich möchte entsprechend ihrerZeit veröffentlichen

QoS

Level akzeptiert passend zu diesenElementen

die Nachricht des Filters

. Das bedeutet,bestimmenwährend der Nachrichtenzustellung möglichmaximale QoS WartezeitLevel ist die Verantwortung des Publishers, undder Abonnent kann

erfordert, dass der Server QoS auf ein geeigneteres Niveau reduziert, dasseinem Level entspricht.

3.9 SUBACK – Abonnement-Bestätigung

der Server sendet SUBACK Paket an den Client, um zu bestätigen, dass erempfangen hat undin Verarbeitung ist SUBSCRIBE Paket.

SUBACK Nachrichtenthält eine Rückgabecode-Liste, sie habenangegeben SUBSCRIBE bitteder Anfragejedes Abonnement istdie maximal gewährte QoS wartenEbene.

3.9.1 Fester Header

Legende 3.24 – SUBACK Paket fester Header

Bit

Byte 1

MQTT SteuerpaketNachrichtentyp (9)

reserviertes Bit

Byte 2

verbleibende Länge

verbleibende LängeLängenfeld

gleich derLänge des variablen Headers plus Payloaddie Länge des Payloads.

3.9.2 Variabler Header

der variable Header enthält usw.ausstehende Bestätigung SUBSCRIBE BerichtTextesPaketkennung.Legende 3.25 – SUBACK BerichtPaket-Variable-Header beschreibt mögliche

das Format des variablen Headers.

Legende: Variabler Header des 3.25 – SUBACK -Pakets

Bit

Byte 1

Paketkennung MSB

Byte 2

Paketkennung LSB

MQTT-3.1.1-CN 41

3.9.3 payload

die Nutzlast enthält eineeine Liste von Rückgabecodes. Jeder Rückgabecodeentspricht einer ausstehenden Bestätigungvon SUBSCRIBE eines der Paketeeinen Topic-Filter. Rückgabe

Reihenfolge der CodesErforderlichund SUBSCRIBE Nachrichtin der Reihenfolge der Topic-Filtergleich [MQTT-3.9.3-1]。

Legende 3.26 – SUBACK BerichtPaketnutzlastFormatierung beschreibtin der Nutzlast ein einzelnesByte-kodiertes Rückgabecode-Feld.

Legende 3.26 – SUBACK Format der Paketnutzlast

Bit

Rückgabecode

Byte 1

Zulässige Rückgabecode-Werte：

0x00 - maximale QoS 0

0x01 - Erfolg – maximale QQoS 1

0x02 - Erfolg – maximale QoS 2

0x80 - Fehler Fehler

0x00, 0x01, 0x02, 0x80 außerhalbvon SUBACK returnRückgabecode ist reserviertvon,kann nichtVerwendung [MQTT-3.9.3-2]。

3.9.3.1 PayloadPayload nicht normativBeispiel

Legende 3.27 -Nutzlastnicht normatives Byteformat-Beispiel zeigt in Tabelle 3.6 -Janicht normatives Nutzlast-Beispiel kurz beschrieben

SUBACK Nachrichtder Nutzlast.

Tabelle 3.6 -Nutzlastnicht normativBeispiel

Erfolg - Maximum QoS 0

Erfolg - Maximum QoS 2

Fehler

128

Legende 3.27 -NutzlastByteformatNicht normatives Beispiel

Beschreibung

Byte 1

Erfolg - Maximum QoS 0

Byte 2

Erfolg - Maximum QoS 2

Byte 3

Fehler

3.10 UNSUBSCRIBE –Abonnement kündigen

Client sendet UNSUBSCRIBE Nachrichtan den Server,verwendet, umabonniertes Thema abzubestellen.

MQTT-3.1.1-CN 42

3.10.1 Fester Header

Legende 3.28 – UNSUBSCRIBE Fixed Header des Pakets

Bit

Byte 1

MQTT Steuerpakettyp (10)

reserviertes Bit

Byte 2

verbleibende Länge

UNSUBSCRIBE MeldungText festgelegtdes Fixed Headers 3,2,1,0 Bit ist beizubehaltenReserviertes Bit undErforderlichseparat gesetztist 0,0,1,0。serverseitigerforderlichbetrachtet jeglicheseine

seine Werte sind alle ungültigzulässig und schließt die NetzwerkNetzwerkverbindung [MQTT-3.10.1-1]。

verbleibende LängeLängenfeld

gleich derLänge des variablen Headers plus Payloaddie Länge des Payloads.

3.10.2 Variabler Header

Der variable Header enthält eineneinen Paketbezeichner。2.3.1 Abschnittliefert Informationen übermehr über PaketbezeichnerInformationen.

Legende 3.29 – UNSUBSCRIBE variabler Header des Pakets

Bit

Byte 1

Paketkennung MSB

Byte 2

Paketkennung LSB

3.10.3 payload

UNSUBSCRIBE des PaketsgültigPayload enthält Clientdie Topics, von denen der Client das Abonnement beenden möchteTopic-Filter-Liste。UNSUBSCRIBE im Paket

TopicFilterErforderlichwird zusammenhängend gepackt,gemäß 1.5.3 Abschnitt spezifiziertsemantisch UTF-8 BearbeitenCode-String [MQTT-3.10.3-1]。

UNSUBSCRIBE des PaketsgültigPayloadErforderlichmindestensenthälteinen Nachrichtenfilter. Kein Payloaddes Payloads UNSUBSCRIBE Paket ist

Verstoß gegen das Protokoll [MQTT-3.10.3-2]. Es gibtWeitere Informationen zur Fehlerbehandlungbitte siehe 4.8 Abschnitt.

3.10.3.1 nicht konformer PayloadGeltungsbereichBeispiel

Legende 3.30 -PayloadNicht normatives Byte-FormatBeispiel zeigt Tabelle 3.7 -gültigNicht normatives Payload-Beispiel kurz beschrieben

UNSUBSCRIBE des PaketsgültigPayload.

Tabelle 3.7 -Payloadnicht normatives BeispielBeispiel

Topic-Filter

“a/b”

Topic-Filter

“c/d”

MQTT-3.1.1-CN 43

Legende 3.30 -PayloadByte-Formatnicht normativBeispiel

Beschreibung

Topic-Filter

Byte 1

Länge MSB (0)

Byte 2

Länge LSB (3)

Byte 3

‘a’ (0x61)

Byte 4

‘/’ (0x2F)

Byte 5

‘b’ (0x62)

Topic-Filter

byte 6

Länge MSB (0)

byte 7

Länge LSB (3)

Byte 8

‘c’ (0x63)

Byte 9

‘/’ (0x2F)

Byte 10

‘d’ (0x64)

3.10.4 response

UNSUBSCRIBE BerichtText erwähntangegebenen Topic-Filter (unabhängig davon, ob er enthältWildcard）Erforderlichwobei dies vom Server gehalten wirdaktuelle des ClientsHaupt

Topic-Filter-Set einzelnein Zeichenvergleich.wenn ein Filter vollständigexakte Übereinstimmung,dann es (der ServerServer) seine eigeneDas Abonnement wird gelöscht,Andernfalls

es wird keine weitereVerarbeitung [MQTT-3.10.4-1]。

Wenn der Server löschtein Abonnement:

 esErforderlichkeine neuen Nachrichten mehr zuzustellenNachricht an diesen ClientClient [MQTT-3.10.4-2]。

 esErforderlichvollständige Zustellung aller bereitsbeginnt, an den Client zu sendenvom Endpunkt gesendet QoS 1 und QoS 2 der Nachricht [MQTT-3.10.4-3]。

 esJamit dem Senden aller vorhandenen fortfahrenVorbereitung zur Verteilungan den Puffer des ClientsNachricht speichern.

ServerseitigErforderlichsenden UNSUBACK Paketantwortdes Clients UNSUBSCRIBE Anfrage.UNSUBACK NachrichtErforderlichenthält und

UNSUBSCRIBE BerichtTextphasedieselbe Paketkennung [MQTT-3.10.4-4]。selbst wennhat keinThemenabonnement gelöscht,der Server ebenfallsErforderlichausgeben

eine SUBACK Antwort senden [MQTT-3.10.4-5]。

Wenn der Server empfängtenthaltend mehrere Themendes Filters UNSUBSCRIBE Paket,erErforderlich,als ob es eine Reihe vonmehreren empfangen hätte

UNSUBSCRIBE, meldeeinen Text,behandle dieses Paket auf die gleiche Weise,außerdemfasse ihre Antworten zu einer zusammenein separates UNSUBACK außerhalb der Nachricht.

[MQTT-3.10.4-6]。

3.11 UNSUBACK – Abonnement kündigenBestätigung

der Server sendet UNSUBACK Nachrichtan den Client, um den Empfang zu bestätigenzu UNSUBSCRIBE Paket.

MQTT-3.1.1-CN 44

3.11.1 Fester Header

Legende 3.31 – UNSUBACK Nachricht festgelegtfester Header

Bit

Byte 1

MQTT SteuerpaketNachrichtentyp (11)

reserviertes Bit

Byte 2

verbleibende Länge (2)

verbleibende LängeLängenfeld

die Länge des variablen Headersangebend, für UNSUBACK diese Nachrichteinem Wert entspricht 2。

3.11.2 Variabler Header

der variable Header enthält usw.ausstehende Bestätigung UNSUBSCRIBE Nachrichtdie Paketkennung.

Legende 3.32 – UNSUBACK Nachricht kannvariable Header

Bit

Byte 1

Paketkennung MSB

Byte 2

Paketkennung LSB

3.11.3 payload

UNSUBACK Nachricht hat keineNutzlast。

3.12 PINGREQ – Heartbeat-Anfrage

Client sendet PINGREQ Nachrichtan den Server. Verwenden Siebei:

1. bei Fehlen eines anderenSteuerpakets vom Clientwenn der Client an den Server sendet,informiert den Server, dass der ClientClient am Leben ist.

2. fordert den Server auf zu senden Antwort bestätigt, dass er nocham Leben ist.

3. das Netzwerk nutzen, um zu bestätigenNetzwerkverbindung hat keineTrennung.

Keep Alive (Keep Alive）Verarbeitungverwendet indiesem Paket,detailliertfür Informationen siehe 3.1.2.10 Abschnitt.

3.12.1 Fester Header

Legende 3.33 – PINGREQ Fixed Header des Pakets

Bit

Byte 1

MQTT Steuerpakettyp (12)

reserviertes Bit

MQTT-3.1.1-CN 45

Byte 2

verbleibende Länge (0)

3.12.2 Variabler Header

PINGREQ BerichtDie Nachricht hat keinen variablen Header。

3.12.3 payload

PINGREQ Berichtdie Nachricht hat keine Nutzlast。

3.12.4 response

ServerseitigErforderlichsenden PINGRESP Paketantwortdes Clients PINGREQ Nachricht [MQTT-3.12.4-1]。

3.13 PINGRESP – Heartbeat-Antwort

der Server sendet PINGRESP Paket antwortet dem Clientdes Clients PINGREQ Paket.Steht fürServer ist noch aktiv-ing.

Keep Alive (Keep Alive）Verarbeitungverwendet indiesem Paket,Detailsbitte siehe 3.1.2.10 Abschnitt.

3.13.1 Fester Header

Legende 3.34 – PINGRESP Nachricht festerfester Header

Bit

Byte 1

MQTT Steuerpakettyp (13)

reserviertes Bit

Byte 2

verbleibende Länge (0)

3.13.2 Variabler Header

PINGRESP Nachrichtkein variabler HeaderHeader.

3.13.3 payload

PINGRESP Nachrichthat keine PayloadPayload.

3.14 DISCONNECT –Verbindung trennen

DISCONNECT Das Paket wird vom Client an den Server gesendetletztes des Serversein Steuerpaket.gibt an, dass der Client normal getrennt wurdeVerbindung.

MQTT-3.1.1-CN 46

3.14.1 Fester Header

Legende 3.35 – DISCONNECT Nachrichtfester Header

Bit

Byte 1

MQTT Steuerpakettyp (14)

reserviertes Bit

Byte 2

verbleibende Länge (0)

ServerseitigErforderlichüberprüfen, dass alle beibehaltenenreservierten Bits alle gesetzt sindgesetzt auf 0, wennsie nicht sind 0 Erforderlichtrennen [MQTT-3.14.1-1]。

3.14.2 Variabler Header

DISCONNECT Das Paket hat keinen variablen Header.

3.14.3 payload

DISCONNECT Paket hat keine NutzlastNutzlast.

3.14.4 response

Client sendet DISCONNECT Meldungnach der Nachricht:

 Erforderlichdie Netzwerkverbindung schließen [MQTT-3.14.4-1]。

 kann nichtüber diese Netzwerkverbindung erneutein beliebiges Steuerungs-Steuerungspaket senden [MQTT-3.14.4-2]。

Server beim Empfang DISCONNECT beim Senden einer Nachricht:

 Erforderlichalle mit der aktuellen Verbindung verbundenen verwerfenzugehörige ungesendeteveröffentlichteWillNachricht, siehe die spezifische Beschreibung 3.1.2.5 Abschnitt [MQTT-3.14.4-3]。

 solltedie Netzwerkverbindung schließen,wenn der Client dies noch nicht getan hat.

MQTT-3.1.1-CN 47

4 Betriebsverhalten

4.1 Zustandsspeicherung

Um Quality of ServiceQoS-Garantie zu gewährleisten, ClientClient und Server habendie Notwendigkeit, den Sitzungszustand zu speichern. Während der Sitzungzwischen, der ClientClient und ServerAlleErforderlich

Sitzungszustand speichern [MQTT-4.1.0-1]. SitzungErforderlichbesteht mindestens so lange wie ihr aktives NetzwerkNetzwerkverbindung gleich langZeit von [MQTT-4.1.0-2]。

die zurückbehaltene Nachricht des ServersNachricht ist kein SitzungszustandTeil des Zustands. Serversolltediese Art von Nachricht zurückbehaltenNachricht, bis der Client sie löscht.

nicht-normativerKommentar

Client und ServerSpeicher der ImplementierungKapazitätnotwendigerweise begrenztvon, muss möglicherweise auchder Verwaltungsrichtlinie unterliegenEinschränkungen, wie z. B. überdie Sitzung der Netzwerkverbindung hinweg

die maximale Speicherung des SitzungsstatusSpeicherzeit. bereits beibehaltenergespeicherter SitzungsstatusDer Verlust kann ein bestimmter,durch einen Verwaltungsvorgang verursachter sein,zum Beispiel fürein vordefiniertes Element

automatische Antwort.die Folgen, die es verursacht,sind die Sitzungsbeendigung. Diese Vorgänge könnenRessourcenbeschränkungen seinoder durch andere betriebliche Gründe verursacht werdenvon. Muss

Muss die Client- und ServerSpeicherkapazität sorgfältig bewerten,um sicherzustellen, dass die SpeicherplatzZeit ausreicht.

nicht-normativerKommentar

Client oder Servervon Software- und Hardwarefehlernkönnen alle dazu führen, dass der Sitzungszustandvon Verlust oder Beschädigung。

nicht-normativerKommentar

Server und ClientNormalbetrieb kannbedeuten, dass der gespeicherte ZustandZustandsverlust oder -beschädigungist Verwaltungsvorgänge oder Software/Hardwaredurch Fehler verursacht.

administrative Vorgänge könnenfür eine vordefinierteautomatische Reaktion auf Bedingungen sein. Dieseinige Vorgänge könnenRessourcenbeschränkungen oder andere Vorgängedurch den Grund ausgelöst.

zum Beispiel kann der Serverkann auf externenBedingungen basieren, entscheiden, nichteine bestimmte Nachricht erneut zu sendenoder einige Nachrichten an beliebige verteiltjeden aktuellen odernach dem Client

Client.

nicht-normativerKommentar

MQTT Benutzer solltesollte bewerten MQTT Client- und Serverimplementierungender Speicherkapazität,sicherstellen, dass es den Bedarf erfüllen kannAnfrage.

4.1.1 Nicht normatives Beispiel

zum Beispiel, wenn Sie sammeln möchtendie Verwendung von Zählerständenkann der Benutzer entscheiden, QoS 1 Stufedie Nachricht zu verwenden, weil sie nicht könnenEmpfangen von Daten im NetzwerkNetzwerkübertragungspfad

verloren in ..., aber,Sie könnten denkenClient- und ServerdatenDaten können gespeichert werden inSpeicher (flüchtiger Speicher), because (they think

the power supply isvery reliable,will not have too greatrisk of data loss.

in contrast, parkingbilling and payment applicationsthe provider may decide anyunder no circumstancescan cause data delivery messages to be lostloss,Thereforethey require that

transmitted over the networkbefore, all datadata must be written tonon-volatile storagedevice (such as a hard disk）。

4.2 Netzwerkverbindung

MQTT protocol needsrequire the underlying transportlayer can provideordered, reliableof,bidirectionaltransport (from the client toServer-side and fromserver to client

byte stream of the endpoint).

nicht-normativerKommentar

MQTT 3.1 makethe transport layer protocol usedYes [RFC793] defined TCP/IP cooperatediscussion.the following protocol alsosupports:

MQTT-3.1.1-CN 48

 TLS Protocol [RFC5246]

 WebSocket Protocol [RFC6455]

nicht-normativerKommentar

TCP Port 8883 und 1883 bereits in IANA HinweisRegistrierung, jeweils verwendet für MQTT von TLS und Nicht- TLS Kommunikation.

verbindungslose NetzwerkübertragungTransportprotokoll wie UDP Janicht unterstützt,weil sie möglicherweisekönnen Datenpaket verlieren oder Datenpakete umsortieren。

4.3 Dienstgüteebene und Protokollfluss

MQTT gemäß diesemDienst definiert inDienstgüte (QoS) Stufe VerteilungsanwendungNachricht. Verteilungdas Protokoll ist symmetrisch, im Folgendenin der obigen Beschreibung,Client

und der Server können beideder Sender kann auchEr ist bereits der Empfänger.Das Zustellprotokoll konzentriert sich aufgeht von einem einzelnen Sender aneines einzelnen EmpfängersAnwendungsnachricht.Kleidung

ServerAnwendungsnachrichten an mehrere Clients verteilenwenn am Ende, jeder ClientClient verarbeitet unabhängig. An den Client zugestelltdie ausgehende Anwendung des ClientsNachrichten und eingehende Anwendungsnachrichten

von QoS Ebene kannkann unterschiedlich sein.

der folgende nicht normative AblaufDas Diagramm zeigt möglicheImplementierungsmethoden.。

4.3.1 QoS 0:höchstens einmal

Nachrichtenzustellung hängt ab vonden Fähigkeiten des zugrunde liegenden Netzwerks. Der Empfängerwird keine Antwort senden, der Sender wird ebenfalls nichterneut versuchen. Die Nachrichtkann einmal zugestellt werden oder kann

wurde überhaupt nicht zugestellt.

für QoS 0 desZustellprotokolls, der SenderSender

 Erforderlichsenden QoS gleich 0，DUP gleich 0 von PUBLISH Nachricht [MQTT-4.3.1-1]。

für QoS 0 desZustellprotokolls, der EmpfängerEmpfänger

 Akzeptieren PUBLISH , wenn eine Nachricht, gleichzeitig empfangendie gesamte Nachricht empfangenrichtig.

Legende 4.1 – QoS 0 Protokollablaufdiagramm,nicht normativBeispiel

AbsenderAktion

Steuerpaket

EmpfängerAktion

PUBLISH Nachricht QoS 0, DUP=0

---------->

Anwendungsnachrichten zustellen angeeigneten nachfolgenden Empfängerempfangen

der/die/das

4.3.2 QoS 1: mindestensTeileneinmal senden

KleidungAngelegenheitQualitätQuantitätbestätigenschützeneliminierenAtemzuwenigesendenerreicheneinmal。QoS 1 von PUBLISH BerichtTextvonkannändernBerichtKopfMediumPaketenthalteneinElementeBerichtTextmarkierenwissenSymbol，Bedarfwollen

PUBACK NachrichtBestätigung.2.3.1 Abschnittbietet Informationen über Paketbezeichnerweitere Informationen über den Bezeichner。

für QoS 1 desZustellprotokolls, der SenderSender

 jedes Mal, wenn eine neue Anwendungsnachricht gesendet wirdalle NachrichtenErforderlichWeisen Sie ein un-den verwendeten PaketbezeichnerZeichen zu.

 gesendet PUBLISH NachrichtErforderlichenthältNachrichtenbezeichner und QoS gleich 1，DUP gleich 0。

MQTT-3.1.1-CN 49

 Erforderlichdiese PUBLISH BerichtNachricht wird betrachtet als

unbestätigt

，bisdas entsprechende vom Empfänger empfangen wird PUBACK Paket.4.4 Abschnitt

es gibt eine ... über unbestätigteDiskussion der Nachrichtenbestätigung。

[MQTT-4.3.2-1].

sobald der Sender ein PUBACK Paket empfängt,DieserPaketbezeichnerkann wiederverwendet werden.

Hinweis:Erlaubtder Sender wartet auf eine Bestätigungbei Verwendung unterschiedlicherPaketbezeichner zum Senden nachfolgendervon PUBLISH Paket.

für QoS 1 desZustellprotokolls, der EmpfängerEmpfänger

 Antwort PUBACK NachrichtErforderlichenthält eineNachrichtenkennung,diese Kennung stammt vonvon der empfangenen,bereits akzeptiert alleder Autorität

PUBLISH Paket.

 gesendet PUBACK Berichtnach der Nachricht,der Empfänger mussjede, die dieselbe enthälteingehende Paketkennung PUBLISH Nachrichtals eine

eine neue Nachricht, undignoriere ihren DUP MarkierungsFlag-Wert.

[MQTT-4.3.2-2].

Legende 4.2 – QoS 1 ProtokollablaufDiagramm,nicht-normativBeispiel

AbsenderAktion

Steuerpaket

EmpfängerAktion

Nachrichten speichern

senden PUBLISH Nachricht QoS=1,

DUP=0, mit der NachrichtKennungen

---------->

starte die ... der Anwendungsnachrichtanschließende Verteilung

<----------

senden PUBACK Nachricht, mit einer NachrichtMarkierung

Kennung

Nachricht verwerfen

erfordert nicht, dass der Empfängersendet PUBACK vor der vollständigen Verteilungsendet Anwendungsnachrichten. Das OriginalSender empfängt PUBACK Nachrichtdanach,

alle Rechte an der Anwendungsnachrichtwerden aufdiesen Empfänger übertragen.

4.3.3 QoS 2: nureinmal zustellen

dies ist die höchste Stufe derQuality of Service,NachrichtVerlust und Duplizierungalle sind inakzeptabelvon. Bei Verwendung dieser Quality of Servicedie Qualitätsstufe wird extrazusätzlichen Overhead haben.

QoS 2 der Eliminierungim variablen Nachrichtenheaderhat eine Paketkennung.2.3.1 Abschnittbietet Informationen überAktualisierung der Paketkennungweitere Informationen.QoS 2 von PUBLISH

der Empfänger des Pakets verwendetunter Verwendung eines zweistufigen BestätigungsBestätigungsprozesses, um den Empfang zu bestätigen.

für QoS 2 desZustellprotokolls, der SenderSender

 muss dem zu sendenden ...Verteilung neuer Anwendungsnachrichteneine unbenutzte Paketkennung zuweisen.

 sendenvon PUBLISH NachrichtErforderlichenthältPaketkennung und die Paket- QoS ist gleich 2,，DUP ist gleich 0。

 Erforderlichdiese PUBLISH BerichtNachricht wird betrachtet als

unbestätigt

，bisdas entsprechende vom Empfänger empfängt PUBREC- Paket.4.4 Abschnitt

es gibt eine ... über unbestätigteDiskussion der Nachrichtenbestätigung。

MQTT-3.1.1-CN 50

 empfangen PUBREC nach der NachrichtErforderlichsende ein PUBREL Paket.PUBREL Nachricht mussmuss dieselbeursprüngliche PUBLISH enthalten message

gleichedie Paketkennung.

 Erforderlichdiese PUBREL BerichtNachricht betrachtet als

unbestätigt

，bisdas entsprechende PUBCOMP Paket vom Empfänger empfängt.

 Sobald die entsprechende ... gesendet wurdevon PUBREL Nachricht dannkanndies nicht erneut senden PUBLISH Paket.

[MQTT-4.3.3-1].

Sobald der Sender eine PUBCOMP Nachricht empfängt, diesePaketkennung kann dann wiederverwendet werden。

Hinweis:Erlaubtder Sender wartet auf eine Bestätigungbei Verwendung unterschiedlicherPaketbezeichner zum Senden nachfolgendervon PUBLISH Paket.

fürQoS 2Zustellprotokoll, empfangendePerson

 Antwort PUBREC NachrichtErforderlichenthältPaketkennung, diese Kennungvon der empfangenen, bereits akzeptiert alleautorisierten

PUBLISH Paket.

 Beim Empfang der entsprechenden PUBREL vor der Nachricht,EmpfängerErforderlichsenden PUBREC MeldungBestätigungjedes nachfolgende Paket mit derselbengleichen Kennung

des PUBLISH Pakets. In diesem Fall,eskann nichtdoppelte Zustellung von Nachrichtenan jeden nachfolgendenEmpfänger.

 Antwort PUBREL des Pakets PUBCOMP NachrichtErforderlichenthaltend und PUBREL BerichtNachricht mit demselben BezeichnerZeichen.

 senden PUBCOMP Berichtdes Textesdanach, der Empfängermuss denselben enthaltenjede mit derselben NachrichtenkennungFolge PUBLISH BerichtText sollteeine erstellen

eine neue Veröffentlichung.

[MQTT-4.3.3-2].

Legende 4.3 – QoS 2 Protokollablaufdiagramm,nicht normativesBeispiel

AbsenderAktion

Steuerpaket

EmpfängerAktion

Nachrichten speichern

senden PUBLISH Paket,QoS=2,

DUP=0, mitPaketkennung

---------->

Methoden A: Nachrichten oder Methoden speichern B：

die Paketkennung speichern, dann beginnen zubevor

diese Anwendungsnachricht zustellenAtem

。

senden PUBREC Berichttext,mit Nachrichtenkennung

Bezeichner.

<----------

die Nachricht verwerfen, speichern PUBREC in

Paketkennung

senden PUBREL Berichttext, mit Nachrichtmarkierung

Kennung

---------->

MQTT-3.1.1-CN 51

Methoden A: beginnt, die Anwendungsnachricht weiterzuleitenAtem

dann die Nachricht verwerfen oder Methode B：verwerfen

Paketkennung

senden PUBCOMP Paket,mit Nachricht

Bezeichner

<----------

den gespeicherten Zustand verwerfenBedingung

erfordert den Empfänger nichtbeim Senden von PUBREC oder PUBCOMP bevorvollständige Verteilung solltemit der Nachricht. Der ursprüngliche sendendeEmpfänger empfängt

PUBREC Berichtnach dem Paket, die Anwendungsnachrichtder Besitz der Nachricht dannwird an diesen Empfänger übertragen。

Legende 4.3 – QoS 2 ProtokollFlussdiagramm, nicht standardmäßigBeispiel Anzeigedes Empfängers QoS 2 wartenzwei Arten von Level-NachrichtenBehandlungsmethode.sie

der Unterschied ist, was die Nachricht ...wann beginnen kannmit der Verteilung beginnen. Implementierungder Implementierer kann entscheiden, zu verwendenwelche Methode verwendet wird. Solange die Implementierungder Implementierer nur ausgewählt hateine Methode

Methode,wirkt sich nicht auf QoS FlussProzesszuverlässigkeit aus.

4.4 Wiederholung der Nachrichtenzustellung

der Client setzt das Clean-Start-FlagSitzung (CleanSession）Flagsist 0 erneut verbindenwenn, der Clientund der ServerErforderlichdas ursprüngliche verwendendie anfängliche Nachrichtenkennung erneut senden

jede unbestätigte PUBLISH Nachricht (falls QoS>0) und PUBREL Nachricht [MQTT-4.4.0-1]. Dies ist die einzigeeineAnforderungClient oder

Server sendet Nachrichten erneutdie Situation.

nicht-normativerKommentar

Neuübertragung von Steuerpaketenerforderlich, umeinige veraltete TCP Daten im Netzwerk zu überwindenDatenverlustproblem.in diesen Umgebungen eingesetzt MQTT

3.1.1 echteImplementierung kann weiterhin erforderlich seinFokus auf dieses ProblemThema.

4.5 Nachricht empfangen

Der Server übernimmt eingehendeEigentümerschaft an der Anwendungsnachrichtwenn autorisiert, esErforderlichdie Nachrichtzum Abonnement hinzufügendie Sitzung des passenden Clientsim Zustand.Abgleichsregeln bestimmen

semantische Sicht 4.7 Abschnitt [MQTT-4.5.0-1]。

Unter normalen Umständen empfängt der ClientClient gesendetean sein AbonnementNachricht. Clientkann auch Nachrichten empfangen, die nicht damit zusammenhängendas Abonnement genau übereinstimmtpassende Nachricht. Zum Beispiel

Wenn der Server automatisch sendetdem Client zugewiesenein Abonnement,möglichdiese Situation auftrittSituation. Derzeit in Bearbeitung UBSUBSCRIBE Anfragekann auch empfangenan

Nachricht. Clientmussentsprechend der möglichenverwendeten DienstqualitätMenge (QoS) Regel bestätigt, dass sie empfangen hatjedes PUBLISH Paket,unabhängig davon, obesAuswählenob verarbeitet werden soll

Verarbeiten Sie die im Paket enthaltene AnwendungsnachrichtNachricht verwenden [MQTT-4.5.0-2]。

4.6 Nachrichtenreihenfolge

Implementieren Sie, was in diesem Kapitel definiert istwährend des Protokollablaufs,Clientmussdie folgenden Regeln befolgendann:

 Senden Sie jeden vorherigen PUBLISH Bericht erneutwenn die Nachricht,mussentsprechend dem Original PUBLISH Nachrichtdie Sendereihenfolgein der Reihenfolge erneut senden (anwendbarverwendet für QoS 1 und

QoS 2 Nachricht）[MQTT-4.6.0-1]。

 Mussgemäß der entsprechenden PUBLISH Pakete in der Reihenfolge senden PUBACK BerichtText (QoS 1 Nachricht）[MQTT-4.6.0-2]。

 Mussgemäß der entsprechenden PUBLISH Pakete in der Reihenfolge senden PUBREC Nachricht (QoS 2 Nachricht）[MQTT-4.6.0-3]。

 Erforderlichgemäß der entsprechenden PUBREC Pakete in Reihenfolge senden PUBREL Nachricht (QoS 2 Nachricht）[MQTT-4.6.0-4]。

ServerseitigErforderlichstandardmäßig wird angenommen, dass alleThemen eineReihenfolge haben. EsJabietet eineeine Verwaltungsfunktion oderandere Mechanismen, umeinem odermehreren Mastern zu ermöglichen

Behandle das Thema als ungeordnet [MQTT-4.6.0-5]。

MQTT-3.1.1-CN 52

Der Server übernimmt das Sendenan geordnete Themenwenn eine Nachricht,Erforderlichwie obendie Regeln werden NachrichtNachricht an jeden Abonnenten verteilt. Darüber hinaus, esErforderlichgemäß

Vom Client empfangenin Reihenfolge senden PUBLISH meldenNachricht an Konsumenten(für dasselbe ThemaFrage und QoS）[MQTT-4.6.0-6]。

nicht-normativerKommentar

Die oben aufgeführten Regelnstellen sicher, unter Verwendung von QoS 1 Veröffentlichungs-und Abonnement-Nachrichtenfluss,Abonnenten gemäß der Nachrichtdie Reihenfolge bei der Nachrichtenveröffentlichungin Reihenfolge empfangenjeweils

NachrichtDie endgültige Kopie, aber die Nachricht kannwiederholt werden, dieskann dazu führen, dass siedie nachfolgenden Nachrichtennach dem Empfang einer bestimmten bereitsbereits empfangene Nachricht

Erneut gesendete Version. Zum Beispiel, sendet der Publisher in ReihenfolgeSequenz 1,2,3,4 Nachrichten, abonnierendie vom Empfänger empfangene Reihenfolgekann sein 1,2,3,2,3,4。

Wenn der Client und Server, kann der Server jedejederzeit garantieren, dass höchstens eine NachrichtInformation ist in

während der Übertragung (

in-flight

）

(bei einer bestimmten Nachrichtbevor die Nachricht bestätigt wird

Senden Sie nicht die folgendeNachricht), dannwas,Wird nichtJa QoS 1 der Nachrichtwird in einer beliebigen ihrernach nachfolgenden Nachrichten empfangen。 Zum Beispiel，

Die Reihenfolge, in der Abonnenten empfangenReihenfolge kann sein 1,2,3,3,4, anstatt 1,2,3,2,3,4. Das Übertragungsfenster （in-fLichtfenster) lassenist 1

Bedeutet, dass in derselbenzu einem Thema,selbst wennPublisher sendeteine Reihe verschiedener QoS Stufen von Nachrichten,ihre Reihenfolge ist ebenfallsgeschützt werden

behalten.

4.7 Themenname und Themenfilter

4.7.1 Themen-Wildcard

ThemaEbene (Themenebene) getrenntTrennzeichen, das zur Strukturierung verwendet wirdNormalisierung führt Themennamen ein.wenn es eine Verteilung gibtTrennzeichen, wird es das HauptTeile den Themennamen in mehrere auf

Themenebene

level

Themenebene 。

Abonnierter Themenfilterdas Gerät kann spezielle enthaltenspezielle Wildcards, die es Ihnen ermöglichenmehrere gleichzeitig zu abonnierenThema.

Der Themenfilter darfWildcards verwenden, aber Themennamendürfen nichtVerwendungWildcard [MQTT-4.7.1-1]。

4.7.1.1 ThemenebeneTrennzeichen

Schrägstrich（‘/’ U+002F) verwendet fürJede der ThemenebenenStufe, um eine Hierarchie für den Themennamen bereitzustellenStruktur. Wenn der ClientClient abonniert den angegebenenThemenfilter

Der Filter enthält zwei Wildcardswenn das Trennzeichen, die ThemenebeneEbene-Trennzeichen ist sehrnützlich. Das ThemaHierarchie-Trennzeichen kannkann in Themenfiltern erscheinenoder der Name des Topics

Jede Position. Angrenzend an dasTopic-Hierarchie-Trennzeichen stellt eineTopic-Ebene der Länge nulldar.

4.7.1.2 Mehrschicht-Wildcard

Numerisches Flag (‘#’ U+0023) wird verwendetzum Abgleich in ThemenBeliebigEbeneder Platzhalter. MehrstufigPlatzhalter repräsentiert seinübergeordnetes Element und eine beliebige Anzahluntergeordneter Elemente dieser Menge

Ebenen. Multi-Level-WildcardTrennzeichen muss sich auf seinereigenen Ebene befinden oder von einemThemenebenen-Trennzeichennach dem Trennzeichen gefolgt werden. Unabhängig davonwelche Art von SituationSituation, es immerErforderlichist das Subjekt

Das letzte der Filterzeichen [MQTT-4.7.1-2]。

nicht-normativerKommentar

Zum Beispiel,wennDer Client Themen abonniert “sport/tennis/player1/#”，Er wird Folgendes empfangender Themenname der veröffentlichtenNachricht:

 “sport/tennis/player1”

 “sport/tennis/player1/ranking”

 “sport/tennis/player1/score/wimbledon”

nicht-normativerKommentar

 “sport/#”passt auch zuseparatem “sport” , denn # einschließlichseines übergeordneten Themas.

 “#”ist gültigvon,empfängt alleAnwendungsnachrichten。

 “sport/tennis/#”ist ebenfallsgültig.

 “sport/tennis#”ist ungültig.

MQTT-3.1.1-CN 53

 “sport/tennis/#/ranking”Jaungültig.

4.7.1.3 Single-Layer-Passübereinstimmendes Zeichen

Pluszeichen (‘+’ U+002B) kann nur verwendet werdenfür eine einzelne Topic-EbeneEbenen-übereinstimmendes Wildcard-Zeichen

Im Topic-Filterkann jede Ebeneeine Single-Level-Wildcard verwenden,einschließlich derersten und letzten Ebenen. AllerdingsesErforderlichbelegt die des Filters

die gesamte Ebene [MQTT-4.7.1-3]。Kann im Topic-Filter vorkommenmehrere Ebenen imEbene, indem man es verwendet,kann auch mit Multi-Level verwendet werdenWildcards zusammen verwendenverwenden.

nicht-normativerKommentar

Zum Beispiel, “sport/tennis/+” passt “sport/tennis/player1” und “sport/tennis/player2” ，Aberpasst nicht

“sport/tennis/player1/ranking” . Währenddessen, danur Single-Level-Wildcardeine Ebene abgleichen kannEbene, “sport/+” passt nicht

“sport” aber es passtallocate “sport/”。

nicht-normativerKommentar

 “+” ist gültig.

 “+/tennis/#” ist gültig.

 “sport+” ist ungültig.

 “sport/+/player1” ist ebenfalls gültig.

 “/finance” passt “+/+” und “/+” , aber nichtpasst “+”。

4.7.2 mit$Themen, die beginnen mit

Serverseitigkann nichtwird $ Zeichen beginntführender Topic-Name stimmt übereinWildcard abgleichen (#oder+) offenTopic-Filter beginnend mit [MQTT-4.7.2-1]Der Server sollteverhindern

Der Client verwendet diese Art vonTopic-Namen und andereClients tauschen Nachrichten ausNachricht. Die Server-Implementierung kannwird $ Topic-Namen, die beginnen mitfür andere Zwecke.

nicht-normativerKommentar

 $SYS/ wird häufig„Wird verwendet, um serverspezifische Informationen zu enthaltenNachrichten- oder Steuerungsschnittstelledas Präfix des Topics。

 Anwendungen können $ Topic-Namen, die mit dem Zeichen beginnen, nicht verwendenTopic.

nicht-normativerKommentar

 Abonnement “#” Der Client wird nicht empfangenAn alle veröffentlicht an “$” beginnendes Themadie Nachrichten des Topics.

 Abonnement “+/monitor/Clients” der Client nichtwird alle gesendeten Nachrichten empfangenverteilen an “$SYS/monitor/Clients” der EliminierungNachricht.

 Abonnement “$SYS/#” der Clientwird Nachrichten empfangen, die veröffentlicht wurden an “$SYS/” beginnendNachrichten zum Topic.

 Abonnement “$SYS/monitor/+” vonDer Client empfängt eine Publish-Nachrichtan “$SYS/monitor/Clients” Hauptdie Nachrichten des Topics.

 Wenn der Client möchtebeim Annehmen “$SYS/” Topic beginnend mitNachrichten und nicht beginnend mit $ Topic beginnend mitNachrichten, muss ergleichzeitig

Abonnement “#” und ““$SYS/#”。

4.7.3 TopicSemantikund Verwendung

Topic-Name und Topic-FilterFilter müssendie folgenden Regeln erfüllen:

 alle Topic-Namen undTopic-FilterErforderlichmindestens enthaltenenthält ein Zeichen [MQTT-4.7.3-1]。

 Topic-Name und Topic-FilterFilter sind case-sensitiveKleinbuchstaben.

 Topic-Name und Topic-FilterFilter könnenLeerzeichen enthalten.

MQTT-3.1.1-CN 54

 Topic-Name oder Topic-FilterFilter mit führendem oderabschließendem Schrägstrich “/” unterscheiden.

 enthält nur Schrägstriche “/” der Topic-Name oder Topic-FilterDer Filter ist gültig.

 Themenname und ThemenfilterFilterdarf nichtein Nullzeichen enthalten (Unicode U+0000) [Unicode] [MQTT-4.7.3-2]。

 Themenname und ThemenfilterFilter ist UTF-8 codierte Zeichenfolge, siekönnen nichtÜberschritten 65535 Byte [MQTT-4.7.3-3]. siehe 1.5.3

-Abschnitt weggelassen werden.

außerdarf nicht überschreiten UTF-codiertes ZeichenZeichenfolgenlängengrenzeDarüber hinaus der Themenname oder das Themadie Ebenen des FiltersAnzahl hat keineanderen Einschränkungen.

beim Abgleich von Abonnements der ServerServerdarf nichtfür Themenname oderDer Themenfilter führteine Normalisierung durchführen（Normalisierung) Prozess, darf nichtändern oder ersetzen

jedes nicht erkannte ZeichenSymbol [MQTT-4.7.3-4]. ThemaJede Nicht-Wildcard im FilterWildcard-Ebenen müssen einzeln abgeglichen werdenZeichen stimmen mit dem Thema übereinentsprechenden Ebene im Namen

Ebene gilt als erfolgreiche Übereinstimmung。

nichtSpezifikationKommentar

Verwendung UTF-8 Die Kodierungsregeln bedeuten, der Themenfilterund der Vergleich von ThemennamenDer Vergleich kann durch Vergleichen erfolgenim Vergleich zum codierten UTF-8 Byteoder zur Lösung

codierte Unicode Zeichen.

nichtSpezifikationKommentar

 “ACCOUNTS” und “Accounts” sind unterschiedliche SubjekteTitel.

 “Accounts payable” ist konsistent mitdem Subjektnamen des/der

 “/finance” und “finance” sind unterschiedlich.

wennder abonnierte Themenfilter und der Nachrichten-Themenname übereinstimmen, werden Anwendungsnachrichtenan jedenpassenden Client gesendetAbonnement. Topickann sein

Administrator am Servervordefiniert, oder es kann der Server seinServer empfängt die ersteein Abonnement oder unter Verwendung dieses TopicsAnwendungsnachricht mit dem Topic-Namendynamisch hinzugefügt, wenn die Nachricht empfangen wird

von. Der Server kann aucheine SicherheitsSicherheitskomponente selektiv einsetzen, umden Client zu autorisieren, eine bestimmteTopic-Ressource zu verwenden.

4.8 Fehlerbehandlung

Sofern nicht anders angegeben,Wenn der Server oderder Client aufVerhalten gestoßen ist, das gegen das Protokoll verstößt,esErforderlichdie Übertragung dieser deaktiviereneine Protokollverletzungdas Netzwerk von Steuernachrichten

Netzwerkverbindung [MQTT-4.8.0-1]。

Client- oder Server-Implementierung kann auftemporäre Fehler stoßen (Transient Erroder)(z. B. innerhalbder Puffer ist voll-Fall) was dazu führt, dassnicht erfolgreich

Verarbeitung von MQTT Paket.

Wenn der Client oder Serverserverseitige Verarbeitung eingehenderauf einen vorübergehenden Fehler beim Verarbeiten eines Steuerpakets gestoßenZeitfehler,esErforderlichden Transport schließen, derNetzwerkverbindung für SteuerpaketeJie

[MQTT-4.8.0-2]。wennder Server einenvorübergehenden Fehler erkannt hat, sollte ernichtdie Verbindung trennenverbinden oder ausführenbeliebigeOperationen, die den Peer betreffen, an andere Clients

tun.

 
  MQTT-3.1.1-CN  55 
5  Sicherheit 
5.1 Übersicht 
Der Inhalt dieses Kapitels dient zurReferenz, ist nichtstandardisiert. Es wird jedochdringend empfohlen,TLS bereitzustellen des Dienstesserverseitige ImplementierungsollteVerwendung TCP Port 8883
（IANA Dienstname:secure-mqtt）。 
 
Lösungsanbietermuss vieleRisiken berücksichtigen. Zum Beispiel: 
  Geräte können gestohlen werdenVerwendung 
  Client und Serverdie statischen Daten könnenzugänglich sein (können festgelegtmodifiziert werden) 
  Protokollverhalten kannNebenwirkungen haben (wie z. B.Timing-Angriffe) 
  Denial-of-Service-Angriffe 
  Kommunikation kann abgefangen werdenAbfangen,ModifizierenUmleitung oder Offenlegung 
  gefälschte SteuernachrichtenEinschleusung 
 
MQTT Schema durchoft eingesetzt insicherer KommunikationUmgebung. In diesemFall, das ProtokollImplementierung muss normalerweiseEs ist notwendig, diese Mechanismen bereitzustellen: 
  Benutzer- und GeräteidentitätAuthentifizierung 
  Zugriff auf ServerressourcenAutorisierung 
  MQTT SteuerpaketText und eingebettete Anwendungdie Integrität der DatenIntegritätsprüfung 
  MQTT KontrollpaketText und eingebettete Anwendungdie Privatsphäre der Datenprivate Kontrolle 
 
Als Transportschichtprotokoll，MQTT konzentriert sich nur auf die Nachrichtenübertragung,angemessene Sicherheit bereitstellendie volle Funktionalität liegt in der Verantwortung des ImplementierersVerantwortung. Verwenden Sie TLS [RFC5246] Ja
eine relativ verbreitete Wahl. Zusätzlich zu technischenabgesehen von den Sicherheitsfragen,und geografischen FaktorenFaktoren (z. B. die Vereinigten StaatenEU-Safe-Harbor-Prinzipien 
[USEUSAFEHARB]）, Branchenstandards (z. B. dieDrittzahlungsbranchen-Datensicherheitsstandards [PCIDSS]), regulatorischeÜberlegungen (Beispiel
wie z. B. Sarbanes-tiefgreifendeOxley Act [SARBANES]) usw.Problem. 
5.2 MQTT Lösung: Sicherheit und Authentifizierung 
Protokollimplementierungen möchten möglicherweisemüssen bestimmteindustrielle Sicherheitsstandards einhalten, wie z. B. NIST NetzCybersicherheitsrahmenwerk [NISTCSF] , Drittanbieter-ZahlungsbranchendatenFrieden
vollständiger Standard [PCIDSS] , US-Bundes-Informationsverarbeitungsstandards [FIPS1402] und NSA HinzufügenVerschlüsselungskombination B [NSAB] 。 
In MQTT des Patchesergänzende Veröffentlichung （MQTT und das NIST-Framework zur Verbesserung kritischer Infrastruktur 
Cybersicherheit [MQTT NIST]） kann inIn NIST gefunden werden NetzwerkSicherheitsframework [NISTCSF] MediumNutzung MQTT derAnleitung. Verwenden
Industriezertifizierung, unabhängigeAuditierung und Authentifizierungstechnologiehilft,Compliance-Anforderungen zu erfüllen. 
5.3 Leichtgewichtige Verschlüsselung und ressourcenbeschränkte Geräte 
weit verbreitete fortgeschrittene VerschlüsselungVerschlüsselungsstandard [AES] NummerDatenverschlüsselungStandard [DES] 。 
empfohlen zur Verwendung als eingeschränkteLow-End-Gerätefunktionenspeziell optimierte leichtgewichtigeStufen-Verschlüsselung internationalerStandard ISO 29192 [ISO29192] 。 
5.4 Implementierungsüberlegungen 
Implementierung und Nutzung von MQTT müssen vieleSicherheitsaspekte berücksichtigt werden.Im Folgendensollte der Teil nichtsollte alsPunkte Checkliste behandelt werden 。 
Protokollimplementierungen könnennun den folgenden Teilganz oder teilweise implementieren: 

 
  MQTT-3.1.1-CN  56 
5.4.1 Client-Identitätüberprüfen 
CONNECT BerichtText enthält Benutzername- und Passwortfelder.Implementierungkann entscheiden, wie diese Zeichen verwendet werdenDer Inhalt des Absatzes. Implementierer könneneigene bereitstellen
Authentifizierungsmechanismus,oder ein externesAuthentifizierungssystem wie LDAP [RFC4511] oder OAuth [RFC6749] , auchkann das Betriebssystem nutzen
Authentifizierungsmechanismen. 
Implementierungen können Klartext übertragenAuthentifizierungsdaten liefern,diese Daten verschleiern, oder keineAuthentifizierungsdaten erfordern,sollten sich jedoch bewusst seindies erhöht die Nutzung von virtuellen zwischengeschaltetenMan-in-the-Middle-Angriff
Angriffe und Replay-AngriffeRisiko.5.4.5 Abschnittführte die genauenMethoden ein, um den Datenschutz zu gewährleisten. 
Auf Client- und Serverendpunktenkann ein virtuelles privates Netzwerk (VPN)sicherstellen, dass Daten nurAutorisierte Clientsdie der Client empfängt. 
Verwendung TLS [RFC5246] wenn,Der Server kann verwendenvom Client gesendet SSL Zertifikatdie Clientidentität überprüfen. 
Die Implementierung kann dem Client ermöglichenClient über die AnwendungNachricht, die Anmeldeinformationen an den Server sendetZertifikat zur IdentitätsprüfungNachweis. 
5.4.2 Client-Autorisierung 
Basierend auf den vom Client bereitgestelltenInformationen wie Benutzername, Client-BezeichnerBezeichner (ClientId）、Clientder Hostname oder IP Adresse, oderAuthentifizierung
Das Ergebnis: Der Serverkann den Zugriff auf bestimmteServerressourcenZugriff beschränken. 
5.4.3 DiensteEndpunkt selbstIdentitätsprüfung 
MQTT Protokoll bietet nichtist gegenseitiges Vertrauenvon, es bietet nichtClient-Verifizierung der ServeridentitätMechanismus. 
AberVerwendung TLS [RFC5246] wenn, kann der Client den Dienst nutzenvom Server gesendet SSL Zertifikatdie ServerIdentität überprüfen. Von einer einzigen IP vieleDomänennamen
Bereitstellen MQTT Die Dienstimplementierung sollteberücksichtigen RFC6066  [RFC6066] Nr. 3 Abschnittdefiniert TLS von SNI Erweiterung.SNI ermöglicht Clientszu beenden
Sagen Sie dem Server, dass er eine Verbindung herstellen möchte zumverbundenen ServerHostnamen. 
Die Implementierung kann es dem Server ermöglichenServer durch die AnwendungNachricht Senden von Anmeldeinformationen an den ClientZertifikat zur IdentitätsüberprüfungNachweis. 
Auf den Client- und ServerEndpunktenkann ein virtuelles privates Netzwerk (VPN)sicherstellen, dass der Clientverbindet sich mit der erwartetendes Servers. 
 
5.4.4 Steuernachrichtund AnwendungsnachrichtNachrichtenintegritätIntegrität 
Die Anwendung kann in der Anwendungdie Nachricht separat enthält einen Hashwert. Diesauf diese Weise kann PUBLISH Steuerungdie Netzwerkübertragung und statische DatenInhalt bereitstellen
Integritätsprüfung. 
TLS [RFC5246] erwähntfür das Netzwerk bereitgestelltdie übertragenen Daten sindHash-Algorithmus zur IntegritätsprüfungMethode. 
An Client- und Serverendpunktenvirtuelles privates Netzwerk (VPN) VerbindungSie können VPN abgedecktDas Netzwerksegment bietet DatenintegritätIntegritätsprüfung. 
5.4.5 Steuernachrichten undAnwendungsnachrichtenverletzenVertraulichkeit 
TLS [RFC5246] kannfür die Netzwerkübertragungverschlüsselt.. Wenn die gültige TLS Cipher-SuiteKombination enthält VerschlüsselungAlgorithmus ist NULL，dann ist sie
Es verschlüsselt keine Daten.muss die Vertraulichkeit des Clientsund des Serverssicherstellen, sollte die Verwendung vonvermeiden, die diese Cipher-Suites verwendetVereinbarung. 
 
Anwendungen können separat hinzufügenum Anwendungsnachrichten zu verschlüsselnInhalt. Dies kannAnwendungsnachrichten während der Übertragung bereitstellenneutral und statischVertraulichkeit statischer DatenVertraulichkeit. Kann aber keine Anwendungsnachrichten bereitstellen
Andere Attribute der Nachricht, wie z. B.Verschlüsselung des Themennamens. 
 
Client- und ServerImplementierungen können verschlüsselnSpeichern statischer Daten, zum Beispielkönnen Anwendungsnachrichten verschlüsselnNachricht als Teil einer SitzungSpeicherung. 
An Client- und Serverendpunktenvirtuelles privates Netzwerk (VPN) VerbindungSie können VPN abgedecktDas Netzsegment gewährleistet dieVertraulichkeit der Daten。 
5.4.6 NachrichtenübertragungNichtabstreitbarkeitAuthentizität 
Der Anwendungsdesigner muss möglicherweisegeeigneteStrategien zur Implementierung von End-to-End-Abstreitbarkeit (Nicht-Abstreitbarkeit）。 

 
  MQTT-3.1.1-CN  57 
5.4.7 ErkennungClientClient und ServerserverseitigDiebstahl 
Verwendung TLS [RFC5246] des ClientsClient- und Serverimplementierungen solltensicherstellen können,Initialisieren TLS [RFC5246] beim Verbinden, bereitstellenbereitgestellt SSL nachweisen
Das Zertifikat ist an den Hostnamen gebunden (Clients müssen eine Verbindung herstellenoder der Server wird verbundenvon) Beziehungzugeordnet. 
 
Verwendung TLS [RFC5246] des ClientsClient- und Serverimplementierungen könnenwählen, Erkennung bereitzustellenÜberprüfen Sie die Zertifikatssperrliste  (CRLs [RFC5280]) und online
Zertifikatsstatusprotokoll  (OSCP) [RFC6960] derFunktion,Ablehnung der Verwendung eines widerrufenenZertifikats. 
 
Physische Bereitstellung kannmanipulationssichere Hardware undspezielle Daten von AnwendungsnachrichtenÜbertragungskombination.Zum BeispielaInstrumente könnenein eingebautes GPS um sicherzustellen
Nicht in unbefugtemBereich verwendet.IEEE SicherheitsgerätGeräteauthentifizierung [IEEE 802.1AR] ist zu verwenden, um diesen Mechanismus zu implementierenEin Standard zur Steuerung,er macht
Verwenden Sie eine verschlüsselte Bindungs-IDzur Überprüfung der GeräteidentitätKopie. 
 
5.4.8 abnormales Verhalten erkennen 
Die Serverimplementierung kanndas Verhalten des Clients überwachen,potenzielleSicherheitsrisiken erkennen. Zum Beispiel: 
  Wiederholte Verbindungsanfragen 
  Wiederholte Authentifizierungsanfrage 
  Abnormale Beendigung der Verbindung 
  Topic-Scan (Anfragezum Senden oder Abonnieren einer großenMenge von Topics) 
  UnzustellbareNachrichten senden (Topics ohneAbonnenten) 
  Der Client verbindet sich, abersendet keine Daten 
Sicherheitsregelverstöße entdeckendas Verhalten, die Serverimplementierung kanndie Client-Verbindung trennenverbinden. 
Die Serverimplementierung erkenntunerwünschtes Verhaltenkann auf IP BasisAdresse oder Client-ID basierenum einedynamische Blacklist zu implementieren. 
Service-Deployment kannunter Verwendung von NetzwerkschichtSteuerung (falls verfügbar) basierend auf IP Basis implementiert werdenAdresse oder sonstigesRate-Limit seiner Informationenoder Blacklist. 
5.4.9 weitereSicherheitsSicherheitsvorkehrungenPunkt 
Wenn der Client oder Serverserverseitig SSL Zertifikatsverlust, oder ichsie betrachten das Zertifikat als gestohlenverwendet oder widerrufen(Verwenden Sie CRLs [RFC5280] und 
OSCP [RFC6960])derSituation. 
 
Client oder Serverbei der Überprüfung von Anmeldeinformationen,wenn festgestellt wird, dass der Benutzerseinen Benutzernamen und sein Passwort verlorenoder gestohlen wurden, solltesollte widerrufen oder neu ausstellen。 
 
Bei der Verwendung langlebiger Verbindungen： 
  Client und ServerVerwendung TLS [RFC5246] sollten erlaubeneine Neuverhandlung erlaubeneine Sitzung aushandeln, um zu bestätigenneue Verschlüsselungsparameter (ersetzenSitzungsschlüssel
Schlüssel, ändern Sie die Cipher-SuiteIdentität, ändern Sie die AuthentifizierungAnmeldeinformationen). 
  服务器可以断开客户端连接，并要求它们使用凭据重新验证身份。 
 
在受限网络中，受信任的受限设备和客户端端点可以使用 TLS 会话恢复 [RFC5077] 减少 TLS 会话重连 [RFC5246] 的开销
开销。 
 
连接到服务器和其他客户端连接到服务器的客户端端 之间存在信任传递关系, sie alle haben die Berechtigungzum gleichen Thema
zum Veröffentlichen von Nachrichten. 

 
  MQTT-3.1.1-CN  58 
5.4.10 Verwendung SOCKS Broker 
Die Client-Implementierung solltesich bewusst sein, dass einige UmgebungenUmgebung die Verwendung von SOCKSv5 [RFC1928] Generation erfordertManagement erstellt ausgehendeNetzwerkverbindung.einige MQTT reale
Sicherheit kann nun genutzt werdenTunnel (wie z. B. SSH）Durch SOCKS Broker. eineEine Implementierung entscheidet sich, SOCKS zu unterstützen, wenn,sollten sie gleichzeitig unterstützenverbergen
des Namens und Benutzername PasswortCode-Verifizierung SOCKS Proxy.für den letzterenFall, implementierensollte sich bewusst sein SOCKS kannkann verwendenKlartext-Authentifizierung,
Dahersollte die Verwendung derselben Anmeldeinformationen vermieden werdenVerbindung MQTT Server. 
5.4.11 Sicherheitsprofil 
Implementierer und LösungsdesignDesigner möchten vielleichtSicherheit als Konfigurationsdatei behandelnSatz sollteangewendet werden auf MQTT im Protokoll. Das Folgende beschreibtist eine mehrschichtige Sicherheit
Gesamte hierarchische Struktur. 
5.4.11.1 OffeneKommunikationskonfiguration 
Verwenden Sie eine offene Kommunikationskonfigurationbeim Einstellen,MQTT Das Protokoll läuft auf einer integrierten, ohne zusätzlichenOverhead des zusätzlichen sicheren Kommunikationsmechanismusim Netzwerk. 
5.4.11.2 SicherheitsNetzwerkkommunikationskonfiguration 
Sichere Netzwerkkommunikation verwendenbei der Konfiguration der KommunikationMQTT Protokollbetriebläuft in einer sicherenkontrolliertes physisches oder virtuellesim Netzwerk,zum Beispiel VPN oder Objektphysisches Sicherheitsnetzwerk. 
5.4.11.3 Sichere Transportkonfiguration 
Sichere Übertragungskonfiguration verwendenbeim Einstellen,MQTT Protokoll läuft aufVerwendung TLS [RFC5246] vonphysischem oder virtuellem Netzwerkim Netzwerk, bietet esbietet Identitätsauthentifizierung，
Integrität und Vertraulichkeit。 
 
Verwenden Sie integrierten BenutzerBenutzername- und Passwortfelder，TLS [RFC5246] Client-IdentitätIdentitätsauthentifizierung kann verwendet werdenfür (oder anstelle von）MQTT GastClient-Authentifizierung
Nachweis. 
5.4.11.4 Sicherheit nach Branchenstandardvollständige Konfiguration 
Wie zu erwarten,MQTT Durchentwickelt, um zu unterstützenviele branchenübliche AnwendungenKonfiguration,Jedes definiert einein Bedrohungsmodell und zum DefinierenPosition der Bedrohung
Der spezielle Sicherheitsmechanismus. Spezielle SicherheitMechanismus empfiehlt die folgende Methodeim Plan wählen: 
 
[NISTCSF] NIST Netzwerksicherheits-FrameworkRahmen 
[NIST7628] NISTIR 7628 Smart-Grid-Cybersicherheitsleitfaden 
[FIPS1402] (FIPS PUB 140-2) VerschlüsselungsmodulSicherheitsanforderungen 
[PCIDSS] PCI-DSS Unterstützung durch DritteDatensicherheit der Zahlungsbranchevollständiger Standard 
[NSAB] NSA VerschlüsselungKombination B 

MQTT-3.1.1-CN 59

6 Verwendung WebSocket alsNetzwerkschicht

wenn MQTT In WebSocket [RFC6455] Verbindungbei Übertragung,ErforderlicherfüllenDie folgenden Bedingungen:

 MQTT SteuerpaketTextErforderlichVerwendung WebSocket BinärzahlDatenframe gesendet. Wennirgendein anderer Typ vonDatenframe empfangen wird, empfangen

PersonErforderlichdie Netzwerkverbindung schließen [MQTT-6.0.0-1]。

 einzelner WebSocket AnzahlDatenframe kann mehrere enthaltenein oder Teil MQTT Paket. Der Empfängerkann nichtannehmen MQTT Kontrollpaketdrücken

WebSocket Ausrichtung der Frame-Grenzen [MQTT-6.0.0-2]。

 ClientErforderlichDie Zeichenfolge mqtt darin enthaltenbereitgestellt WebSocket Subprotokollin der Protokoll-Liste [MQTT-6.0.0-3]。

 Server wählt aus und gibt zurückzurückgegeben WebSocket SubprotokollProtokollnameErforderlichJa mqtt [MQTT-6.0.0-4] 。

 Wird verwendet, um Clientsund die WebSocket URI des Servers zu verbinden Paar MQTT hat keine Auswirkung auf das Protokoll.

6.1 IANA HinweisVorsichtsmaßnahmen

diese Spezifikation ersucht IANA In WebSocket SubprotokollRegistriert unter dem Protokollnameneintrag WebSocket MQTT Subprotokoll,Verwenden Sie die folgenden Daten：

Legende 6.1 - IANA WebSocket Bezeichner

Subprotokoll-Bezeichner

mqtt

Generischer Name des Subprotokolls

mqtt

Subprotokoll-Definition

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html

MQTT-3.1.1-CN 60

7 Konsistenz

MQTT Spezifikation definiertdefinierte MQTT GastClient-Implementierung und MQTT Vom Server implementiertKonformitätsanforderungen

MQTT Implementierung kannkann gleichzeitig sein MQTT Client und MQTT Server.Eingehende Verbindungen akzeptierenund zu anderen aufbauender ausgehenden Verbindung des ServersKleidung

Server muss ebenfalls konform seinkombinieren MQTT GastClient und MQTT serverseitige AnforderungFinden [MQTT-7.0.0-1]。

Um mit jeder anderenkonformen Implementierunginteroperieren zu können, einekonforme Implementierung kann nichterforderlich sein, in dieser Spezifikation zu verwendenJede extern definierteErweiterungen [MQTT-

7.0.0-2]。

7.1 Konformitätsziele

7.1.1 MQTT Serverseitig

a MQTT Server erfüllt nuruntenAlleum als konform mit den Anforderungen betrachtet zu werdenDiese Spezifikation:

1. der Server sendetaller SteuerpaketeFormat muss übereinstimmen mitKapitel 2 und demFormat, das in Kapitel 3 beschrieben wird

2. entsprechen den 4.7 Topic-Übereinstimmung beschrieben in AbschnittÜbereinstimmungsregeln.

3. die folgenden Kapitel erfüllenalle in diesem AbschnittErforderlichStufenanforderungenAnfrage,klarGilt nur für den Clientaußer:

- Kapitel 1 – Einführung

- Kapitel 2 – MQTT SteuernachrichtenformatFormel

- Kapitel 3 – MQTT Steuerpaket

- Kapitel 4 – Betriebsverhalten

- Kapitel 6 –(falls MQTT die Netzwerkschicht ist WebSocket）

- Kapitel 7 – Konformitätsziele

Konsistenzanforderungen erfüllendes ServerserforderlicheUnterstützung unter Verwendung eineseines oder mehrerer zugrunde liegender TransportTransportprotokoll, solangeEs bietet geordnetes, zuverlässiges,bidirektionalesByte

Datenstrom (vom Client zumServer und vom DienstServer zum Client）[MQTT-7.1.1-1]. AllerdingsKonsistenz hängt nicht davon ab, dass es unterstütztUnterstützen Sie ein beliebiges bestimmtes

Transportprotokoll. ServerendeJaunterstützt den 4.2 Abschnittjedes aufgeführteTransportprotokoll, oderJedes andere, das erfüllt [MQTT-7.1.1-1] erforderlicheÜbertragung

Protokoll.

7.1.2 MQTT Client

a MQTT Client erfüllt nuralle der folgendenNur dann gilt er als konform.Diese Spezifikation:

1. Client sendetaller SteuerpaketeFormat muss übereinstimmen mitKapitel 2 und demin Kapitel 3 beschriebenen Format

2. die folgenden Kapitel erfüllenalle in diesem AbschnittErforderlichStufenanforderungenAnfrage,klarGilt nur für den Serveraußer:

- Kapitel 1 – Einführung

- Kapitel 2 – MQTT SteuernachrichtenformatFormel

- Kapitel 3 – MQTT Steuerpaket

- Kapitel 4 – Betriebsverhalten

- Kapitel 6 – (wenn MQTT NetzwerksNetzwerkschicht ist WebSocket）

- Kapitel 7 – Konformitätsziele

Konsistenzanforderungen erfüllender ClientErforderlichUnterstützung bei Verwendung eineseines oder mehrerer zugrunde liegender TransportTransportprotokolls, solangeEs bietet geordnetes, zuverlässiges,bidirektionalesByte

Datenstrom (vom Client zumServer und vom DienstServer zum Client）[MQTT-7.1.2-1]. AllerdingsKonsistenz hängt nicht davon ab, dass es unterstütztUnterstützen Sie ein beliebiges bestimmtes

MQTT-3.1.1-CN 61

Transportprotokoll. ClientEndeJaunterstützt die 4.2 Abschnittbeliebige aufgeführteTransportprotokoll, oderJedes andere, das erfüllt [MQTT-7.1.2-1] erforderlicheÜbertragung

Protokoll.

MQTT-3.1.1-CN 62

Anhang B ForceKonformitätsspezifikationserklärung(nicht standardmäßigerGeltungsbereich）

Dieser Anhang ist nicht normativNormativ, nur alsIm Hauptteil dieses Dokumentsfinden sicheine große AnzahlKonformitätserklärungDie Zusammenfassung wird bereitgestellt.KonformitätsanforderungenGrenzwertspalte

Tabelle in Kapitel 7 dargestellt.

deklarierte Sequenznummer

Spezifikationserklärung

[MQTT-1.5.3-1]

UTF-8 Zeichen in der kodierten ZeichenketteZeichendatenErforderlichist gemäß Unicode Spezifikation [Unicode] definiert und in

RFC3629 [RFC3629] mittelschwerals gültig erklärt UTF-8 Format. BesondersEs sollte besonders beachtet werden, dassDieseAnzahl

gemäßdarf nichtden Zeichencode enthalten bei U+D800 und U+DFFF zwischenDaten.Wenn der Server oderder Client empfängt

enthält ungültige UTF-8 ZeichenSteuerpaket,esErforderlichdie Netzwerkverbindung schließen。

[MQTT-1.5.3-2]

UTF-8 kodierte Zeichenkettedarf nichtein Nullzeichen enthalten U+0000。wennClient oder Server empfängtein Paket angekommen

enthalten U+0000 vonSteuernachricht,esErforderlichSchließen Sie die Netzwerkverbindung.

[MQTT-1.5.3-3]

UTF-8 Kodierungssequenz 0XEF 0xBB 0xBF insgesamtwird interpretiert als U+FEFF(geschütztes Leerzeichen mit NullbreiteZeichen

Zeichen),egalEs erscheint an der Zeichenkettewelcher Position,NachrichtEmpfänger können sie nicht überspringen oder entfernenes belassen.

[MQTT-2.2.2-1]

Tabelle 2.2 alle als“retain”markierten Flag-Bits, alle sind reserviertfür zukünftige Verwendung reserviert，Erforderlichals Tabelle festgelegt

Werte aufgeführt in.

[MQTT-2.2.2-2]

wennEmpfängt ein ungültiges Flag,EmpfängerErforderlichNetzwerkverbindung schließen.

[MQTT-2.3.1-1]

SUBSCRIBE，UNSUBSCRIBE und PUBLISH（QoS größer als 0) SteuerpaketErforderlichenthält eine

eine nicht-null 16 BitsPaketkennung (Paketkennung。

[MQTT-2.3.1-2]

Jedes Mal, wenn der Client sendetEine neue von diesenPakettyp, wennErforderlichWeisen Sie ein aktuellunbenutztes Paket zu.mark

Kennung。

[MQTT-2.3.1-3]

wennEin Client dieses bestimmtespezielle Steuerpaket erneut senden möchte, wenn es später erneut übertragen wirdwenn dieses Paket,esErforderlichmachen

Denselben Bezeichner verwenden. Wenn der Clientnach Verarbeitung der Nachricht, die entsprichtNach Bestätigung wird dieseDie Paketkennung wird freigegeben

wiederverwendbar setzen.QoS 1 von PUBLISH Paarentspricht PUBACK，QoS 2 von PUBLISH entsprechend

Ja PUBCOMP, und SUBSCRIBE oder UNSUBSCRIBE Paarentsprechen jeweils SUBACK oder

UNSUBACK

[MQTT-2.3.1-4]

sende eine QoS 0 von PUBLISH Nachrichtwenn,dasselbeDie Bedingungen gelten auch für den Serverende.

[MQTT-2.3.1-5]

QoS Gesetzt auf 0 von PUBLISH Nachrichtkann nichtEnthält eine Paketkennung.

[MQTT-2.3.1-6]

PUBACK, PUBREC, PUBREL NachrichtErforderlichenthaltend undursprünglich gesendet PUBLISH Nachricht mit derselben

Paketkennung。

[MQTT-2.3.1-7]

und [MQTT-2.3.1-6] ähnlich,SUBACK und UNSUBACK Erforderlichenthalten in der entsprechenden

SUBSCRIBE und UNSUBSCRIBE NachrichtDie verwendete Paketkennung inZeichen.

[MQTT-3.1.0-1]

Client zu ServerNetzwerkverbindungsaufbauNach dem Aufbau sendet der Client anden Server als Ersteseine NachrichtErforderlichJa

CONNECT Nachricht。

[MQTT-3.1.0-2]

Bei einer Netzwerkverbindungan, der Client nurkann einmal gesendet werden CONNECT Nachricht. ServerServerErforderlichder Client

die zweite gesendete CONNECT Nachricht alsProtokollverstoß behandelnund die Verbindung des Clients trennen。

[MQTT-3.1.2-1]

wenn der Protokollname falsch istder Server bestätigtJaden Client trennendie Verbindung, auchJagemäßeinigen anderen SpezifikationenFortsetzen

Verarbeitung der CONNECT Nachricht. Dennim letzteren Fall,gemäß dieser Spezifikation,serverseitigkann nichtmit der Verarbeitung fortfahren

CONNECT Nachricht。

MQTT-3.1.1-CN 63

[MQTT-3.1.2-2]

Wenn festgestellt wird, dassdie Protokollebene nicht unterstützt wird,serverseitigerforderlich ist,einenRückgabecode zu senden 0x01(nicht unterstütztes Protokoll

Protokollstufe)der CONNACK Nachricht alsAntwort auf CONNECT Paket,danndie Verbindung des Clients trennen。

[MQTT-3.1.2-3]

ServerseitigErforderlichÜberprüfen Sie beim CONNECT die reserviertenFlags des Steuerpakets (die 0 Bit) gibt an, ob 0，wennNein

ist 0 mussmuss die Client-Verbindung trennen.

[MQTT-3.1.2-4]

Wenn das Clean-Session- (CleanSession）Flag gesetzt istauf 0gesetzt wird, der ServerErforderlichbasierend aufaktueller Sitzung (erstellen

Verwenden Sie die Client-KennungIdentifikation) Zustandmit dem Client fortsetzenKommunikation. Wennnicht mit dieser Client-Kennung verknüpftwissen

Sitzung, die mit der Kennung verknüpft ist,ServerseitigErforderlicheine erstelleneine neue Sitzung. InNachdem die Verbindung getrennt wurde, wenn die VerbindungVerbindungstrennung

Danach,Client und ServerErforderlichSpeichernSitzungsinformationen.

[MQTT-3.1.2-5]

Wenn das Clean-Session-Flagist 0 Sitzungsverbindungnachdem die Verbindung getrennt wurde,ServerseitigErforderlichdanach QoS 1 und QoS 2

Nachrichtenpersistenz auf der Ebeneals Sitzungszustandein Teil, wenndiese Nachrichten übereinstimmenbeim Trennen der Verbindung, der Clientbeliebige des Clients

beliebiges Abonnement.

[MQTT-3.1.2-6]

Wenn die Clean Session (CleanSession）Flag gesetzt istgesetzt auf 1, Clientund der ServerErforderlichvor dem Verwerfen

einer beliebigen Sitzung und beginneeine neue Sitzung startenMit anderen Worten, die Sitzung dauert nur so lange wie das NetzwerkNetzwerkverbindung genauso langeZeit.undDies

Mit der Sitzung verknüpfter ZustandDatenkann nichtnach jederSitzungswiederverwendung.

[MQTT-3.1.2.7]

Beibehaltene Nachrichten sind nicht serverseitig.Server-Sitzungszustandein Teil davon, die Sitzung endetwennkann nichtbeibehaltene Nachrichten löschenNachricht.

[MQTT-3.1.2-8]

Will-Flag (Will Flag) ist gesetztist 1, was anzeigt, obWenn die Verbindungsanfrage istakzeptiert, der Wille (Wkrank

Nachricht）NachrichtErforderlichwird gespeichert indem Server und mit diesem NetzwerkNetzwerkverbindungszuordnung.nach dem Schließen der Netzwerkverbindung

beim Schließen, der ServerErforderlichDiese Will-Nachricht veröffentlichen, es sei denn, der Serverhat DISCONNECT empfangen beim Löschen einer Nachricht

außer für diese Will-NachrichtNachricht.

[MQTT-3.1.2-9]

Wenn das Will-Flagauf 1gesetzt ist, Verbindungim Verbindungsflag WWill-QoS und Will-Retain Felderwerden vom Server

verwendet,gleichzeitigim PayloadErforderlichenthält WWill Topic und WWill Message Felder。

[MQTT-3.1.2-10]

Sobald veröffentlicht oderder Server einvom Client gesendetes DISCONNECT Paket empfangen hat, wird die Will Messagenurmuss

mussaus dem Speicheraus dem gespeicherten Sitzungszustand entfernt werden.

[MQTT-3.1.2-11]

Wenn das Will-Flag istgesetzt auf 0，Verbindungim Flag Will QoS und Will Retain FelderErforderlichFestgelegt auf

0, undin der Payloaddarf nichtenthalten Will Topic und WWill-Nachricht Felder。

[MQTT-3.1.2-12]

Wenn das Will-Flagauf 0gesetzt ist, kann das Netzwerk,wenn die Netzwerkverbindung getrennt ist,，nichtdie Will-Nachricht senden。.

[MQTT-3.1.2-13]

Wenn das Will-Flagauf 0gesetzt ist, belassenanweisen QoS auchRequiredSet to 0(0x00)。

[MQTT-3.1.2-14]

If the Will flag isSet to 1, leaveinstruct QoS value ofcan equal 0(0x00)，1(0x01)，2(0x02)。

its valuecannotequals 3。

[MQTT-3.1.2-15]

If the Will flag isSet to 0, leavewill retain (Will Retain) flag alsoRequiredSet to 0。

[MQTT-3.1.2-16]

wennDas Will Retain ist gesetzt auf 0, der ServerErforderlichBehandeln Sie die Will-Nachricht als nicht-beibehaltene Nachrichtenveröffentlichung。

[MQTT-3.1.2-17]

Wenndas Will-Retain auf 1gesetzt ist, muss der ServerErforderlichdie Will-Nachricht so behandeln, als wäre sieals zurückbehaltene Nachricht veröffentlicht。

[MQTT-3.1.2-18]

if the username (User Name) flag is set to 0, in the payloadcannotcontainsusername field.

[MQTT-3.1.2-19]

if the username (User Name) flag is set to 1, in the payloadRequiredcontainsusername field.

[MQTT-3.1.2-20]

Wenn das Passwort-Flag (Passwort)auf 0gesetzt ist, darf im Payloadnichtcontains a password field。

[MQTT-3.1.2-21]

Wenn das Passwort-Flag (Passwort)auf 1gesetzt ist, muss im PayloadErforderlichcontains a password field

MQTT-3.1.1-CN 64

[MQTT-3.1.2-22]

If the username flagis set to 0, the password flag alsoRequiredSet to 0。

[MQTT-3.1.2-23]

The client is responsible for ensuringcontrol packet transmissionthe time interval does not exceed the keep-alivekeep-alive value.If there is no other

its control packet cancan send, the clientendRequiredsend a PINGREQ message。

[MQTT-3.1.2-24]

Wenn der Keep-AliveWert ungleich null ist undder Server innerhalb der eineinhalbfachenKeepalive-Zeitkeinen Client empfangen hat

das Steuerpaket des Clients,esErforderlichdieNetzwerkverbindung des Clients trennen,berücksichtigenNetzwerkverbindung bereitsgetrennt.

[MQTT-3.1.3-1]

falls enthalten,Erforderlichin dieser Reihenfolge erscheinen: Client-IdentifikatorWildcard, Will-Thema, Will-Nachricht,Verwenden Sie

Benutzername，Passwort。

[MQTT-3.1.3-2]

Der Server verwendet den ClientClient-Identifikator (ClientId) kennenDen Client identifizieren. Mit dem Server verbinden.jeden Client des Serversalle Clients haben eindeutige

eindeutiges Client-Identifikator-Zeichen (ClientId). Der Client undder Server müssen beideVerwendung ClientId kennenzwischen den beiden unterscheiden

zwischen MQTT sitzungsbezogenem Zustand。

[MQTT-3.1.3-3]

Client-Bezeichner (ClientId) ErforderlichExistiertaußerdemErforderlichJa CONNECT NachrichtDas erste der Nutzlasta

Fields。

[MQTT-3.1.3-4]

Client-IdentifikatorErforderlichJa 1.5.3 im Abschnitt definiert UTF-8 Kodierte Zeichenkette。

[MQTT-3.1.3-5]

ServerseitigErforderlichZulässig 1 bis 23 Bytes lang UTF-8 kodierter ClientClient-Bezeichner, der ClientClient-Bezeichner

darf nur diese Zeichen enthaltenZeichen:

“0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXY

Z”(Großbuchstaben, Kleinbuchstaben und ZahlenZeichen).

[MQTT-3.1.3-6]

ServerseitigJaClient zulassenClient liefert ein Null-ByteByte-Client-BezeichnerBezeichner (ClientId) ，wenn dies erfolgt ist

abgeschlossen,ServerseitigErforderlichdies als Sonderfall behandeln undeinen eindeutigen Client zuweisenClient-Bezeichner zudiesem Client.aber

danachErforderlichden Client annehmenDer Endpunkt stellt diesen eindeutigen bereitdes Client-BezeichnersZeichen,normaldies verarbeiten CONNECT

message。

[MQTT-3.1.3-7]

wenn der Clientder Endpunkt liefert ein Null-Byteder Client-KennungSymbol, esErforderlichwird ebenfalls löschenSitzungsflag gesetztsetzen

ist 1。

[MQTT-3.1.3-8]

Wenn der Client angibtvon ClientId null Bytes istund das Clean-Session-Flagmarkiert als 0, DienstEndeErforderlichRückgabecode senden

ist 0x02（Gibt an, dass die Kennung ungültig ist) von CONNACK Paketantwortdes Clients CONNECT Meldung

Text,Dann die Netzwerkverbindung schließen。

[MQTT-3.1.3-9]

Wenn der Server ablehntvon dieser ClientId，esErforderlichRückgabe sendenCode als 0x02(Tabellegibt an, dass die Kennung ungültig ist

Format) von CONNACK MeldungNachrichtenantwortdes Clients CONNECT Paket, danndie Netzwerkverbindung schließen。

[MQTT-3.1.3-10]

Will-TopicErforderlichJa 1.5.3 definiert im Abschnitt UTF-8 kodierte Zeichenkette.

[MQTT-3.1.3-11]

BenutzernameErforderlichJa 1.5.3 definiert im Abschnitt UTF-8 codierte Zeichenfolge。

[MQTT-3.1.4-1]

ServerseitigErforderlichgemäß 3.1 AbschnittAnforderungsüberprüfung CONNECT Paket,wennPaket nicht derSpezifikation entspricht, Dienst

sendet nicht CONNACK Berichtdirekter Textdie Netzwerkverbindung schließen。

[MQTT-3.1.4-2]

wenn ClientId Tabelleanzeigt, dass der Clientbereits verbunden ist mitdiesem Server,dann der ServerErforderlichTrennungsgrundeinige Clients

Verbindung.

[MQTT-3.1.4-3]

ServerseitigErforderlichgemäß 3.1.2.4 des Knotensbeschreibt das Durchführen der Bereinigungdes Sitzungsprozesses.

[MQTT-3.1.4-4]

ServerseitigErforderlichzurücksendenRückgabecode von Null CONNACK Paket als CONNECT des PaketsBestätigungsantwort.

[MQTT-3.1.4-5]

wennder Server abgelehnt hat CONNECT, eskann nichtden Client behandeln in CONNECT Berichtsenden nach der Nachrichtvon

beliebige Daten。

MQTT-3.1.1-CN 65

[MQTT-3.2.0-1]

Der Server sendet CONNACK Nachrichtdie vom Client empfangene Antwort CONNECT BerichtNachricht. Der Server sendet an

die erste des ClientsNachrichtErforderlichJa CONNACK。

[MQTT-3.2.2-1]

Wenn der Server empfängtClean Session (CleanSession）Flagsist 1 derVerbindung, außerwürde CONNACK

Der Rückgabecode im PaketGesetzt auf 0 außerhalb, auchErforderlichwird CONNACK im Paketaktuelle Sitzungseinstellung

（Session Present）Flag ist 0。

[MQTT-3.2.2-2]

Wenn der Server empfängta CleanSession ist 0 vonVerbindung, die aktuelle SitzungDer Wert des Sitzungs-Flags nimmthängt vom Server ab

ob er bereits gespeichert hat ClientId Pairdem Client antwortenden Sitzungszustand.wenn der Server bereits gespeichert hatSitzungszustand

Zustand,esErforderlichwird CONNACK meldendas Flag der aktuellen Sitzung im Paketsetzen auf 1。

[MQTT-3.2.2-3]

wennder Server keinen gespeicherten Sitzungsstatus hat,eserforderlichwird CONNACK in der Nachrichtdie Einstellung der aktuellen Sitzungsetzen

ist 0. Es ist auch notwendig, CONNACK zu meldender Rückgabecode im Text ist gesetzt auf 0。

[MQTT-3.2.2-4]

Wenn der Server sendetenthielt ein Nicht-mit einem Null-Rückgabecode CONNACK Paket,esErforderlichdie aktuelle Sitzung markieren als

Flag ist gesetzt auf 0。

[MQTT-3.2.2-5]

Wenn der Server sendetenthielt ein Nicht-mit einem Null-Rückgabecode CONNACK Paket,dannesErforderlichNetzwerk schließen

Verbindung。.

[MQTT-3.2.2-6]

Wenn man bedenkt, dass die obige Tabelle 3.1 alle Verbindungen in der obigen Tabelle zurückgebendie Rückgabecodes sind nicht ganz geeignetgeeignet,dannserverseitigErforderlichNetzwerkverbindung schließen

Verbindung, muss nicht gesendet werden CONNACK Nachricht。

[MQTT-3.3.1-1]

Client oder ServerAnfrage, ein PUBLISH erneut zu senden, wenn die Nachricht,Erforderlichwird DUP MarkierungFlag ist gesetzt auf 1。

[MQTT-3.3.1-2]

für QoS 0 die Nachricht,DUP FlagsErforderlichSetzen auf 0

[MQTT-3.3.1-3]

der Server sendet PUBLISH Nachricht an den Abonnentenwenn,empfangenvon (eingehend) PUBLISH des Pakets DUP

der Wert des Flags wird nichtWeiterleitung. Senden(ausgehend) PUBLISH Nachricht und empfangen(eingehend)

PUBLISH Meldungin der Nachricht DUP MarkierungFlag ist unabhängiggesetzt, sein WertErforderlichseparatdie Grundlage für das Senden (aus

Station)'s PUBLISH Meldungob die Nachrichteine Neuübertragung zu bestimmen。

[MQTT-3.3.1-4]

PUBLISH Nachrichtkann nichtWill QoS Platzeinige Bits sind gesetzt auf 1。wennder Server oder der Client empfängt QoS Platz

alle Bits sind 1 von PUBLISH MeldungNachricht, esErforderlichNetzwerk schließenNetzwerkverbindung.

[MQTT-3.3.1-5]

Wenn der Client andes Servers PUBLISH Meldungdes TextesRetain (RETAIN) Markierungs-Flag ist auf 1gesetzt, Dienst

ServerErforderlichSpeichern Sie diese Anwendungsnachricht und ihre Dienstgütestufe (QoS), damites kann verteilt werdenGeben

zukünftiges Topic-Name-Matchingdem passenden Abonnenten.

[MQTT-3.3.1-6]

ein neues Abonnement wird eingerichtetwenn eingerichtet, für jedenden passenden Topic-Namen, fallsExistiertaktuellezurückbehaltene Nachricht, esErforderlich

an diesen Abonnement-Leser gesendet.

[MQTT-3.3.1-7]

Wenn der Server empfängteine beibehaltene (RETAIN) Markierungmarkiert als 1 von QoS 0 Nachricht,esErforderlichvor dem Verwerfen

für dieses Thema beibehaltenjede Nachricht.essolltediese neue QoS 0 eliminierenNachricht als dieseneue Beibehaltung eines Themas

eine Nachricht beibehalten, aber jedejederzeitJaentscheidet sich, sie zu verwerfen — wenndiese Situation auftritt,diesesTopic wird keine haben

hat eine Retained Message。

[MQTT-3.3.1-8]

der Server sendet PUBLISH Paket an den Clientwenn, falls die Nachrichtals Client istDas Ergebnis eines neuen Abonnements

senden, esErforderlichwird meldenDas Retain-Flag der Nachricht ist gesetzt auf 1。

[MQTT-3.3.1-9]

wenn ein PUBLISH BerichtNachricht anden Client gesendet wird, weil sie miteiner bestehenden Subscription übereinstimmtbeim Abonnieren, der ServerErforderlich

Setzen Sie das Retain-Flag auf 0，unabhängigRetain in der empfangenen Nachrichtder Wert des Flags istgeringer.

MQTT-3.1.1-CN 66

[MQTT-3.3.1-10]

Retain-Flag ist 1 und eine Nutzlast mit null Bytes PUBLISH NachrichtWird vom Server als positiv behandeltnormale Nachrichtenverarbeitung

behandelt, wird sie gesendetum dem Abonnement-Topic zu entsprechenpassende Clients. Darüber hinausunter demselben Topicalle vorhandenengespeicherten Retained

die Nachricht muss entfernt werden, damit dieses TopicAbonnenten nach dem Topicwerden nichteine Retained Message empfangen。

[MQTT-3.3.1-11]

Serverseitigkann nichtNull-Bytes speicherndie Retained Message。

[MQTT-3.3.1-12]

Wenn der Client andes Servers PUBLISH Meldungdes TextesRetain-Flag-Bit 0, Dienstendekanndiese Nachricht nicht speichern

Informationen können außerdemnichtalle vorhandenen Reservierungen entfernen oder ersetzenNachricht.

[MQTT-3.3.2-1]

Topic-NameErforderlichJa PUBLISH Berichtvariabler HeaderDas erste Feld des Headers.esErforderlichJa 1.5.3 Abschnitt gibtSemantik an

UTF-8 die kodierte Zeichenkette.

[MQTT-3.3.2-2]

PUBLISH Meldungder Themenname in der Nachrichtkannkeine Wildcards enthalten.

[MQTT-3.3.2-3]

Der Server sendet an den Subscriberdes abonnierenden Clients PUBLISH NachrichtTopic-NameErforderlichübereinstimmen mitdem Topic des AbonnementsFilter

(gemäß 4.7 Abgleich, definiert im AbschnittProzess).

[MQTT-3.3.4-1]

PUBLISH MeldungEmpfänger der NachrichtErforderlichgemäßGemäß PUBLISH im Paket QoS Stufeeine Antwort senden, siehe

Tabelle 3.4 Beschreibung.

[MQTT-3.3.5-1]

ServerseitigErforderlichdie NachrichtAn alle passenden Abonnements verteiltzugewiesen QoS das höchstrangige ClientEnde.

[MQTT-3.3.5-2]

wenn der Server implementierteinen bestimmten Client nicht autorisiertClient veröffentlicht PUBLISH Nachricht, hat er keineMöglichkeit, das mitzuteilenClient

Ende.esErforderlichgemäß normalen QoS RegelnSende eine positive BestätigungBestätigung, oderSchließe die Netzwerkverbindung.

[MQTT-3.6.1-1]

PUBREL SteuerungSteuerpaket-Fixed-Headerdes Headers erstes 3,2,1,0 Bit istreserviertes Bit,Erforderlichist auf 0,0,1,0gesetzt. Dienst

ServerErforderlichBehandeln Sie alle anderen Werte als nichtgültig und schließen Sie dieNetzwerkverbindung.

[MQTT-3.8.1-1]

SUBSCRIBE Steuerungfeste Steuernachrichtdes festen Headers 3,2,1,0 Bit ist reserviertBit,Erforderlichjeweils gesetzt auf 0,0,1,0。

ServerseitigErforderlichder andereJeder Wert wird alsungültig behandelt und schließtdie Netzwerkverbindung.

[MQTT-3.8.3-1]

SUBSCRIBE BerichtNachricht gültigTopic-Filter in der NutzlastListeErforderlichJa 1.5.3 Abschnittdefiniert UTF-8 Zeichen

string。

[MQTT-3.8.3-2]

wenn der Server wähltunterstützt keine Wildcards enthaltendenWildcard-Themenfilter,Erforderlichjeden ablehnenWildcard-enthaltenden Filterfilter

die Abonnementanfrage des Filters。

[MQTT-3.8.3-3]

SUBSCRIBE Berichtder NachrichtPayloadErforderlichenthält mindestens einesfür den Themenfilter und QoS StufeFeldgruppe

stimmt überein. Kein Payloaddes Payloads SUBSCRIBE Nachrichtist eine Verletzung des Protokolls。

[MQTT-3-8.3-4]

wenn im Payloadirgendein Bit von ... ist nicht-Nullwert, oder QoS Nicht gleich 0,1 oder 2，ServerseitigErforderlichberücksichtigen

SUBSCRIBE BerichtNachricht ist nichtgültig und schließe die Netzwerkverbindungverbinden.

[MQTT-3.8.4-1]

der Server empfängt den Clienteines, das vom Endpunkt gesendet wurde SUBSCRIBE wenn die Nachricht,ErforderlichVerwendung SUBACK Paketantwort

Antwort.

[MQTT-3.8.4-2]

SUBACK NachrichtErforderlichund wartet auf Bestätigung SUBSCRIBE Nachrichthaben dieselbe NachrichtPaketbezeichner.

[MQTT-3.8.4-3]

Wenn der Server eina SUBSCRIBE Paket empfängt, PaketDer Topic-Filter und ein vorhandenesTopic eines Abonnements

der Topic-Filter derselbe ist,dannMUSSunter Verwendung des neuen AbonnementsAbonnement vollständig die vorhandenengespeicherten Abonnements ersetzt. Des neuen AbonnementsTopic-Filter

Filter und zuvor abonniertderselbe, aber esdie maximalen QoS Werte können unterschiedlich sein.mit diesem Topic-Filterdurch den Filter abgeglichen

jede vorhandene zurückbehalteneNachrichtMUSSerneut übertragen werden,AberPublish-Flowkann nichtUnterbrechung.

[MQTT-3.8.4-4]

Wenn der Servermit mehreren Themendes Filters ein SUBSCRIBE Paket empfängt,erMUSSals ob ein ... empfangen wurde

eine Reihe von mehreren SUBSCRIBE Nachrichtenbehandelt diese auf dieselbe Weise, außer dass es notwendig ist,ihre Antworten in einer zusammenzuführenitems

separate SUBACK BerichtNachrichtenversand.

MQTT-3.1.1-CN 67

[MQTT-3.8.4-5]

der Server sendet an den Clientdes Clients SUBACK Nachrichtenpaarjedes Paar von Topic-FilternGerät und QoS wartenalle StufenMUSSPaket

enthält einen Rückgabecode.dieser RückgabecodeErforderlichgibt an, dass das Abonnement gewährt wirddie maximale QoS Stufe,oder bezeichnet

dieses Abonnement schlägt fehl。

[MQTT-3.8.4-6]

der Server darf gewährenals der Abonnent verlangtniedrigere QoS Stufe. Als Reaktion auf das Abonnementdie aufgrund des Abonnements gesendete NachrichtInformation

der Nutzlast QoS ErforderlichJaursprüngliche Publish-NachrichtInformation QoS undvom Server gewährt QoS zweider kleinste unter

Wert. Wenn die ursprüngliche NachrichtInformation QoS Ja 1 und gewährt wirddie maximale QoS Ja 0, sodass der Server wiederholteine senden kann

eine Kopie der Nachricht anAbonnent.

[MQTT-3.9.3-1]

die Reihenfolge der RückgabecodesErforderlichund SUBSCRIBE Nachrichtim Topic-Filterdie Reihenfolge des Servers ist dieselbe。

[MQTT-3.9.3-2]

0x00, 0x01, 0x02, 0x80 vonexternen SUBACK Rückgabecodes sind reserviertvon,kann nichtverwenden.

[MQTT-3.10.1-1]

UNSUBSCRIBE MeldungText festgelegtdes Fixed Headers 3,2,1,0 Bit ist beizubehaltenReserviertes Bit undErforderlichseparat gesetztist

0,0,1,0. DienstServerErforderlichjeden anderen berücksichtigendie Werte sind alle ungültigund das Netzwerk schließenVerbindung.

[MQTT-3.10.3-1]

UNSUBSCRIBE Meldungim Textder Topic-FilterErforderlichist fortlaufend gepackt, gemäß 1.5.3 Abschnittdefiniert

UTF-8 codierte Zeichenkette.

[MQTT-3.10.3-2]

UNSUBSCRIBE Meldungdes TextesPayloadErforderlichmindestens enthaltenenthält eine NachrichtFilter. Es gibt keindes Payloads

UNSUBSCRIBE MeldungText istdas Protokoll verletzend。

[MQTT-3.10.4-1]

UNSUBSCRIBE BerichtText erwähntangegebenen Topic-Filter (unabhängig davon, ob er enthältWildcard）Erforderlichmit dem Server aufrechterhalten

der Client, der dies hatdas aktuelle Topicdas Filterset Zeichen für Zeichen vergleichenVergleich. Wenn irgendeinFilter vollständig übereinstimmt

match,Then it (the server)its own subscription will be deleted, otherwise there will be nofurther processing。

[MQTT-3.10.4-2]

If the server deletesa subscription,itRequiredstop delivering any newmessage to thisClient.

[MQTT-3.10.4-3]

If the server deletesa subscription,itRequiredfinish delivering any alreadyalready started to clientsent to the client QoS

1 and QoS 2 of the message。

[MQTT-3.10.4-4]

Server-sideRequiredsend UNSUBACK reportmessage responseclient's UNSUBSCRIBE request.

UNSUBACK messageRequiredcontains and UNSUBSCRIBE messagethe same Packetidentifier.

[MQTT-3.10.4-5]

even ifDid not delete any topic subscriptions,Server-sidealsoRequiredsend a SUBACK response。

[MQTT-3.10.4-6]

Wenn der Server empfängtenthaltend mehrere Themendes Filters UNSUBSCRIBE Paket,erErforderlichals ob empfangen

eine Reihe von mehreren UNSUBSCRIBE Meldungwie die Nachrichtverarbeite dieses Paket,außer ihrenAntwort zusammenführen in

eine separate UNSUBACK Nachrichtaußerhalb.

[MQTT-3.12.4-1]

ServerseitigErforderlichsenden PINGRESP Paketantwortdes Clients PINGREQ Nachricht。

[MQTT-3.14.1-1]

ServerseitigErforderlichalle überprüfenAlle reservierten Bits sind gesetztgesetzt auf 0, wennsie sind nicht 0 ErforderlichtrennenVerbindung.

[MQTT-3.14.4-1]

Client sendet DISCONNECT Meldungnach der Nachricht,ErforderlichNetzwerk schließenVerbindung.

[MQTT-3.14.4-2]

Client sendet DISCONNECT Meldungnach der Nachricht,kann nichtdurch dasNetzwerkverbindung dannsende ein beliebiges Steuerpaket

Text.

[MQTT-3.14.4-3]

Server empfängt DISCONNECT Meldungwenn die Nachricht,Erforderlichverwerfe alle mitDie unbestätigten Nachrichten, die mit der aktuellen Verbindung verknüpft sinddie veröffentlichte Will-Nachricht

Will-Nachricht, die speziell beschreibtbeschrieben in 3.1.2.5 Abschnitt.

[MQTT-4.1.0-1]

während der gesamten Sitzung, Client und ServerServer alleErforderlichSitzungszustand speichernZustand.

[MQTT-4.1.0-2]

SitzungErforderlichBesteht mindestens so lange wie ihre aktive Netzwerkverbindungfür dieselbe Dauer verbindenBereich.

MQTT-3.1.1-CN 68

[MQTT-4.3.1-1]

für QoS 0 desÜbermittlungsprotokolls, der SenderSenderErforderlichsenden QoS gleich 0，DUP gleich 0 von PUBLISH

message。

[MQTT-4.3.2-1]

für QoS 1 desVerteilungsprotokolls,Sender

 jedes Mal, wenn eine neue Anwendungsnachricht gesendet wirdalle NachrichtenErforderlichWeisen Sie ein un-den verwendeten PaketbezeichnerZeichen zu.

 MUSS ein PUBLISH-Paket senden, das diesen Paket-Identifier enthält, mit

QoS=1, DUP=0.

 gesendet PUBLISH NachrichtErforderlichenthält einen Paketidentifier und QoS gleich 1，DUP gleich

0。

 Erforderlichdiese PUBLISH Nachrichtbetrachtet als

unbestätigt

，bisdas entsprechende Paket vom Empfänger empfängt

von PUBACK Paket.4.4 Byte hat eineEins über unbestätigtDiskussion von Nachrichten.

[MQTT-4.3.2-2]

für QoS 1 desZustellprotokolls, der EmpfängerEmpfänger

 Antwort PUBACK NachrichtErforderlichenthält eineNachrichtenkennung,dieser Bezeichner stammt vonbeim Empfang

von,Das hat die Eigentümerschaft akzeptiert PUBLISH Paket.

 gesendet PUBACK Berichtnach der Nachricht,muss der Empfängerjede, die denselben Paketbezeichner enthältder Eintrag des Bezeichners

Station PUBLISH Nachrichtals neuedie Nachricht, und ignorieren ihr DUP Flagsder Wert von.

[MQTT-4.3.3-1]

für QoS 2 desZustellprotokolls, der SenderSender

 muss dem zu sendenden ...Verteilung neuer Anwendungsnachrichteneine unbenutzte Paketkennung zuweisen.

 MUSS ein PUBLISH packet senden, das diesen Packet Identifier enthält mit

QoS=2, DUP=0.

 gesendet PUBLISH NachrichtErforderlichenthält einen Paketbezeichner und Paketvon QoS entspricht 2,，DUP

equals 0。

 Erforderlichdiese PUBLISH Nachrichtbetrachtet als

unbestätigt

，bisdas entsprechende Paket vom Empfänger empfängt

von PUBREC Paket.4.4 AbschnittEs gibt eine Nachricht über unbestätigteDiskussion von Nachrichten.

 empfangen PUBREC nach der NachrichtErforderlichsende ein PUBREL Paket.PUBREL Paket muss

Enthält das ursprüngliche PUBLISH dieselbe Nachricht wie die NachrichtPaketkennung.

 MUSS das PUBREL-Paket als „unbestätigt“ behandeln, bis es

das entsprechende PUBCOMP-Paket von dem Empfänger empfangen hat.

 Erforderlichdiese PUBREL BerichtNachricht betrachtet als

unbestätigt

，bises das entsprechende vom Empfänger empfängt

PUBCOMP Paket.

 Sobald die entsprechende ... gesendet wurdevon PUBREL Nachricht dannkanndies nicht erneut senden PUBLISH Paket.

[MQTT-4.3.3-2]

fürQoS 2Zustellprotokoll, empfangendePerson

 Antwort PUBREC NachrichtErforderlichEnthält eine Paketkennung, welchedie Kennung aus dem empfangenen Paket ist、

bereitsdie Übernahme des PUBLISH Pakets akzeptiert

 Beim Empfang der entsprechenden PUBREL vor der Nachricht,EmpfängerErforderlichsenden PUBREC MeldungBestätigungPflicht

jedes nachfolgende mit derselbenmit derselben Kennung PUBLISH Paket. In diesem Fallunten, eskann nichtwiederholen

Nachrichten an beliebigenachfolgende Empfänger zustellen。

 Antwort PUBREL des Pakets PUBCOMP NachrichtErforderlichenthaltend und PUBREL meldetdasselbe wie die Nachricht

Bezeichner.

 senden PUBCOMP Berichtdes Textesdanach, der Empfängermuss denselben enthaltenjede mit derselben Nachrichtenkennungdanach

fortsetzen PUBLISH Nachrichtals neueDie Veröffentlichung.

MQTT-3.1.1-CN 69

[MQTT-4.4.0-1]

der Client setzt das Clean-Start-FlagSitzung (CleanSession) Markierungmarkiert als 0 erneut verbindenwenn, der Clientund der Servererforderlichmachen

unter Verwendung der ursprünglichen PaketkennungKennung sendet jedeunbestätigte PUBLISH Nachricht erneut (wenn QoS>0) und

PUBREL Nachricht。

[MQTT-4.5.0-1]

Der Server übernimmt eingehendeEigentümerschaft an der Anwendungsnachrichtwenn autorisiert, esErforderlichdie Nachrichtzum Abonnement hinzufügenpassender Clientvon

im Sitzungszustand.übereinstimmenSiehe die Regeldefinition 4.7 Abschnitt.

[MQTT-4.5.0-2]

ClientErforderlichentsprechend der möglichender verwendeten Dienstgüte (QoS) Regelbestätigungjedes von ihm empfangene PUBLISH Paket,

Unabhängig davon,entscheidet er, ob Pakete verarbeitet werden, die eineAnwendungsnachricht enthalten。

[MQTT-4.6.0-1]

Senden Sie jeden vorherigen PUBLISH Bericht erneutwenn die Nachricht,mussentsprechend dem Original PUBLISH Nachrichtin der Reihenfolge des Sendens erneut übertragen

(gilt für QoS 1 und QoS 2 Nachricht）。

[MQTT-4.6.0-2]

Mussgemäß der entsprechenden PUBLISH Pakete in der Reihenfolge senden PUBACK BerichtText (QoS 1 Nachricht）。

[MQTT-4.6.0-3]

Erforderlichgemäß dem entsprechenden PUBLISH Die Pakete in der Reihenfolge senden PUBREC BerichtText (QoS 2 Nachricht）。

[MQTT-4.6.0-4]

Erforderlichgemäß dem entsprechenden PUBREC Reihenfolge der Paketesequenzielles Senden PUBREL Nachricht (QoS 2 Nachricht）。

[MQTT-4.6.0-5]

ServerseitigErforderlichStandardFür jedes Thema gibt es eineReihenfolge. EsJabereitstellen eineeine Verwaltungsfunktion oderandere Maschine

Mechanismus, umErlaubtEin oder mehrere Topicsbehandelt alsungeordnet。

[MQTT-4.6.0-6]

Der Server übernimmt das Sendenan geordnete Themenwenn eine Nachricht,Erforderlichwie obendie Regeln werden NachrichtNachricht an jeden verteiltabonnieren

Leser.zusätzlich, esErforderlichentsprechend dem, was vom Client empfangen wirdin der Reihenfolge des Empfangs senden PUBLISH Nachrichtan den Consumer (für die entsprechende

dasselbe Topic und QoS）。

[MQTT-4.7.1-1]

Der Topic-Filter darfWildcards verwenden, aber Topic-Namendürfen nichtVerwendungWildcard.

[MQTT-4.7.1-2]

Multi-Level-Wildcard musssich in ihrer eigenenEbene befinden oder der Topic-Ebene folgennach dem Ebenentrennzeichen. Unabhängig von der Situation

Bedingung,es allesErforderlichist die letzte Ebene des Topic-FiltersZeichen。

[MQTT-4.7.1-3]

Im Topic-Filterjede Ebene kannkann einen Single-Level-Wildcard verwenden,einschließlich derersten und letzteneiner Ebene.

jedochesErforderlichnimmt die gesamte Ebene des Filters ein。

[MQTT-4.7.2-1]

Serverseitigkann nichtwird $ Topic-Namensübereinstimmung, die mit Zeichen beginntWildcard-Übereinstimmung (#oder+) öffnenTopic-Filter am AnfangGerät.

[MQTT-4.7.3-1]

alle Topic-Namen undTopic-FilterErforderlichMuss mindestens ein Zeichen enthalten.

[MQTT-4.7.3-2]

Topic-Name und Topic-FilterFilterdarf nichtein Nullzeichen enthalten (Unicode U+0000) [Unicode] 。

[MQTT-4.7.3-3]

Themenname und ThemenfilterFilter ist UTF-8 codierte Zeichenfolge, siekönnen nichtÜberschritten 65535 Byte。

[MQTT-4.7.3-4]

beim Abgleich von Abonnements der ServerServerdarf nichtfür Themenname oderDer Themenfilter führteine Normalisierung durchführen

（Normalisierung）Verarbeitung,Kann keinbeliebiges nicht erkanntesZeichen ändern oder ersetzen.

[MQTT-4.8.0-1]

Sofern nicht anders angegeben,Wenn der Server oderder Client aufVerhalten gestoßen ist, das gegen das Protokoll verstößt,esErforderlichÜbertragung hiervon deaktivieren

eine Protokollverletzung steuertdie Netzwerkverbindung des Paketsverbinden.

[MQTT-4.8.0-2]

Wenn der Client oder Serverserverseitige Verarbeitung eingehenderauf einen vorübergehenden Fehler beim Verarbeiten eines Steuerpakets gestoßenZeitfehler,esErforderlichden Transport schließen, der

Netzwerk von SteuernachrichtenVerbindung.

[MQTT-6.0.0-1]

MQTT SteuerpaketErforderlichVerwendung WebSocket BinärzahlDatenframe gesendet. Wennein andererTyp empfangen wird

Datenframe, empfangenPersonErforderlichdie Netzwerkverbindung schließen。

[MQTT-6.0.0-2]

einzelner WebSocket AnzahlDatenframe kann mehrere enthaltenein oder Teil MQTT Paket. Der Empfängerkann nichtannehmen

MQTT Steuernachrichten gemäß WebSocket Frame-Grenzausrichtung。

MQTT-3.1.1-CN 70

[MQTT-6.0.0-3]

ClientErforderlichdie Zeichenkette mqtt darin enthaltenbereitgestelltes WebSocket Subprotokollin der Protokollliste.

[MQTT-6.0.0-4]

Server wählt aus und gibt zurückzurückgegeben WebSocket SubprotokollProtokollnameErforderlichJa mqtt

[MQTT-7.0.0-1]

MQTT Implementierung kann gleichzeitig MQTT Client und MQTT Serverseite sein. Eingehende akzeptierenSite-Verbindung und Aufbau zu ihrer

Sein serverseitig ausgehenderverbundener Servermuss gleichzeitig erfüllen MQTT Client und MQTT serverseitige Anforderung

Anfrage.

[MQTT-7.0.0-2]

Um mit jeder anderenkonformen Implementierunginteroperieren zu können, darf einekonforme Implementierung nichtverpflichtet sein, in dieseraußerhalb der Spezifikation

Jede definierte Erweiterung。

[MQTT-7.1.1-1]

Konsistenzanforderungen erfüllendes ServerserforderlicheUnterstützung unter Verwendung eineseines oder mehrerer zugrunde liegender TransportTransportprotokoll, solangees bietet

geordnet, kannZuverlässiger, bidirektionaler Bytestrom (Vom Client zum ServerServerseite und vom Server zum ClientClient)

[MQTT-7.1.2-1]

Konsistenzanforderungen erfüllender ClientErforderlichUnterstützung bei Verwendung eineseines oder mehrerer zugrunde liegender TransportTransportprotokolls, solangees bietet

geordnet, kannZuverlässiger, bidirektionaler Bytestrom (Vom Client zum ServerServerseite und vom Server zum ClientClient)