TechSchool

 
  MQTT-3.1.1-CN  1 
 
MQTT Protocole 3.1.1 Version chinoise 
OASIS Standard 
2014 année 10 mois 29 jour 
lien vers la spécification 
version actuelle： 
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.doc (faisant autorité) 
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 
versionprécédente: 
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/cos01/mqtt-v3.1.1-cos01.doc (Faisant autorité) 
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 
dernière version： 
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.doc (Afaisant autorité) 
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 
Comité techniqueComité : 
Normes d'information structuréeorganisation de promotion MQTT Comité technique 
Président： 
Raphael·J· Cohen (raphael.cohn@stormmq.com), Individuel 
Richard·J· Koppen (coppen@uk.ibm.com), IBM 
Édition： 
Andrew Banks (Andrew_Banks@uk.ibm.com), IBM 
Rahul Gupta (rahul.gupta@us.ibm.com), IBM 
Documentation connexe： 
Cette spécification est liée à ceci： 
  MQTT et NIST sécurité réseauCadre 1.0 Version. Les éditeurs sont Jeff Brown et Louis·Philip· Lamule. Dernière version
Ceci : http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-
v1.0.html. 
Résumé： 
MQTT est unservice clientLe développement de l'architecture de bouttissu/modèle d'abonnementle protocole de transport de messages.Sa philosophie de conception estléger,Ouvert、
Simple、Spécification，Par conséquentFacile à implémenter.Ces caractéristiques rendentIl est utile pour de nombreux scénariosest un très bon choix, y comprisenvironnements contraints tels que
Communication de machine à machineCroyez (M2M）et IoTenvironnement réseau (IoT），CesLe scénario nécessite très peu de codeencapsulation de code ou réseaubande passante réseau
Très coûteux. 
ce protocoleFonctionneDans TCP/IP, ouD'autres fournissent ordonné, fiable, bidirectionnelconnexion réseau connectéesur. Il a les suivantesles caractéristiques suivantes : 
  en utilisant le modèle publish/SubscriptionMessage, fournissantune distribution de messages un-à-plusieursetdécouplage entre applications. 
  La transmission de messages ne nécessite pasde connaître le contenu de la charge utile。 
  Fournit trois niveaux dequalité de service :. 

 
  MQTT-3.1.1-CN  2 
  “au plus une fois”, autant que l'environnement d'exploitation peutfournir un effort maximalpour livrer les messages.Les messages peuvent être perdus.Par exemple,Ceci
Ce niveau peut être utilisé pourdes données de capteurs environnementaux,une perte de données isoléela perte n'a pas d'importance,carvont bientôtEnvoyer à nouveau. 
   “au moins une fois”, garantissant que les messages peuvent arriverà destination,maispeuvent se répéter. 
   “une seule fois”，GarantieUn message n'est livré qu'une seule fois. Par exemple,CeciCe niveau peut être utilisé dansun système de facturationdans, si ici
La duplication ou la perte de messagesconduira à desfrais incorrects. 
  Très faible surdébit de transmissionet échange de données de protocoleéchange, minimiser au maximumle trafic réseau 
  Une déconnexion anormale de la connexion se produitLorsque cela se produit, peut notifieraux parties concernées. 
 
état : 
Ce document a été pour la dernière fois OASIS membres enLa date finale indiquée ci-dessusrévisé ou approuvé.le niveau d'approbation aussiListé ci-dessus.si
Pour consulter la version la plusrécente de ce document, veuillezVérifier ci-dessus 
dernière version
 Emplacement. Produit par le comité techniqueautres révisions etautres technologies
Tous les documents techniques sont listés iciÀ l'intérieur :https://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=mqtt#technical 。 
Membres du comité techniquecommentaires sur cette spécificationLes discussions doivent être envoyées au comité techniqueliste de diffusion du comitéTableau. Les autres doivent envoyercommentaires au comité technique
Les commentaires publics du comitéliste, méthodeest le pointCliquez sur le comité techniquedu site web de l'association envoyer des commentaires bouton,L'adresse web est 
https://www.oasis-open.org/committees/mqtt/ 。 
À propos de la mise en œuvre de cette spécificationtâches essentiellessi un brevet a été divulgué,et autres informations spécialiséesrelatives aux termes de la licencesouffle, veuillez vous référer à la tech
Site Web du comité techniqueSection propriété intellectuelle（(https://www.oasis-open.org/committees/mqtt/ipr.php）。 
format de référenceFormulaire : 
Lorsque vous citez cette spécification, vous devriezutiliser le format de citation suivantFormat de citation : 
[mqtt-v3.1.1] 
MQTT version 3.1.1. Édité par Andrew Banks et Rahul Gupta. 29 octobre 2014. OASIS 
Norme. http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html. Dernièreversion: 
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html. 
   

MQTT-3.1.1-CN 3

 liens du document

 MQTT Protocole 3.1.1 chinoisprojet de traduction

 MQTT Protocole 3.1.1 version chinoise PDF

 historique des révisions

édition livre

jour période

notes de version

1.0.0

2015-07-30

Traduire tout le texte,Terminer la relecture initiale, publié publiquement comme lapremière édition

1.0.1

2015-10-22

Corriger plusieurs fautes typographiques,compléter plusieurs éléments non traduitsdu texte traduit

 fermerpour le traducteur

 GitHub

 Blog

 E-mail

 
  MQTT-3.1.1-CN  4 
Répertoire 
Aperçu ...................................................................................................................................................... 8 
1 MQTT Structure organisationnelle du protocole ........................................................................................................................ 8 
2 Terme ..................................................................................................................................................... 8 
3 références normatives .............................................................................................................................................. 9 
4 références non normativesutilisation ........................................................................................................................................ 10 
5 représentation des données ............................................................................................................................................ 12 
5.1 binairebit .................................................................................................................................... 12 
5.2 Entiervaleur .................................................................................................................................... 12 
5.3 Chaîne encodée en UTF-8 Encoded string ..................................................................................................................... 12 
6 conventions de rédaction ............................................................................................................................................ 13 
MQTT paquet de contrôleformat de message ........................................................................................................................... 14 
1 MQTT Structure des messages de contrôle ...................................................................................................................... 14 
2 en-tête fixe ............................................................................................................................................ 14 
2.1 MQTT Types de messages de contrôle .............................................................................................................. 14 
2.2 Indicateurs ........................................................................................................................................... 15 
2.3 longueurrestante .................................................................................................................................... 16 
3 en-tête variable ............................................................................................................................................ 17 
3.1 Identifiantsde message ................................................................................................................................. 17 
4 payload ............................................................................................................................................ 19 
MQTT paquet de contrôletexte .................................................................................................................................. 20 
1 CONNECT – Se connecter au serveur .................................................................................................................. 20 
1.1 En-têtefixe .................................................................................................................................... 20 
1.2 En-têtevariable .................................................................................................................................... 20 
1.3 Charge utilevalide .................................................................................................................................... 26 
1.4 response ........................................................................................................................................... 27 
2 CONNACK – confirmerla demande de connexionTrouver .............................................................................................................. 28 
2.1 En-têtefixe .................................................................................................................................... 28 
2.2 En-têtevariable .................................................................................................................................... 28 
2.3 Charge utilevalide .................................................................................................................................... 30 
3 PUBLISH – publier un message ........................................................................................................................ 30 
3.1 En-têtefixe .................................................................................................................................... 30 
3.2 En-têtevariable .................................................................................................................................... 32 
3.3 Charge utilevalide .................................................................................................................................... 33 
3.4 response ........................................................................................................................................... 33 
3.5 action ........................................................................................................................................... 33 
4 PUBACK –accusé de réception de publication .......................................................................................................................... 33 
4.1 En-têtefixe .................................................................................................................................... 33 
4.2 En-têtevariable .................................................................................................................................... 34 
4.3 Charge utilevalide .................................................................................................................................... 34 

 
  MQTT-3.1.1-CN  5 
4.4 action ........................................................................................................................................... 34 
5 PUBREC – émettrepublication reçue (QoS 2, premièreétape) ........................................................................................ 34 
5.1 En-têtefixe .................................................................................................................................... 34 
5.2 En-têtevariable .................................................................................................................................... 34 
5.3 Charge utilevalide .................................................................................................................................... 35 
5.4 action ........................................................................................................................................... 35 
6 PUBREL – libérationde publication (QoS 2, deuxièmeétape) ......................................................................................... 35 
6.1 En-têtefixe .................................................................................................................................... 35 
6.2 En-têtevariable .................................................................................................................................... 35 
6.3 Charge utilevalide .................................................................................................................................... 36 
6.4 action ........................................................................................................................................... 36 
7 PUBCOMP – émettrepublication terminée (QoS 2, étape 3) ..................................................................................... 36 
7.1 En-têtefixe .................................................................................................................................... 36 
7.2 En-têtevariable .................................................................................................................................... 36 
7.3 Charge utilevalide .................................................................................................................................... 36 
7.4 action ........................................................................................................................................... 36 
8 SUBSCRIBE - sujet d'abonnement ................................................................................................................... 37 
8.1 En-têtefixe .................................................................................................................................... 37 
8.2 En-têtevariable .................................................................................................................................... 37 
8.3 Charge utilevalide .................................................................................................................................... 37 
8.4 response ........................................................................................................................................... 39 
9 SUBACK – accusé de réception d'abonnement ......................................................................................................................... 40 
9.1 En-têtefixe .................................................................................................................................... 40 
9.2 En-têtevariable .................................................................................................................................... 40 
9.3 Charge utilevalide .................................................................................................................................... 41 
10 UNSUBSCRIBE –Annulerl'abonnement ............................................................................................................ 41 
10.1 en-tête fixe .................................................................................................................................. 42 
10.2 en-tête variable .................................................................................................................................. 42 
10.3 payload .................................................................................................................................. 42 
10.4 response ......................................................................................................................................... 43 
11 UNSUBACK – Annulation d'abonnementaccusé de réception .......................................................................................................... 43 
11.1 en-tête fixe .................................................................................................................................. 44 
11.2 en-tête variable .................................................................................................................................. 44 
11.3 payload .................................................................................................................................. 44 
12 PINGREQ – requête de battement de cœur ..................................................................................................................... 44 
12.1 en-tête fixe .................................................................................................................................. 44 
12.2 en-tête variable .................................................................................................................................. 45 
12.3 payload .................................................................................................................................. 45 
12.4 response ......................................................................................................................................... 45 
13 PINGRESP – réponse de battement de cœur ................................................................................................................... 45 
13.1 en-tête fixe .................................................................................................................................. 45 

 
  MQTT-3.1.1-CN  6 
13.2 en-tête variable .................................................................................................................................. 45 
13.3 payload .................................................................................................................................. 45 
14 DISCONNECT –déconnexion............................................................................................................... 45 
14.1 en-tête fixe .................................................................................................................................. 46 
14.2 en-tête variable .................................................................................................................................. 46 
14.3 payload .................................................................................................................................. 46 
14.4 response ......................................................................................................................................... 46 
comportement opérationnel ............................................................................................................................................. 47 
1 stockage d'état ............................................................................................................................................ 47 
1.1 exemplenon normatif ................................................................................................................................. 47 
2 Connexion réseau ............................................................................................................................................ 47 
3 Qualité de serviceNiveaux et flux de protocole .................................................................................................................. 48 
3.1 QoS 0:au pluslivrer une fois .................................................................................................................. 48 
3.2 QoS 1 : au moinslivrer une fois ................................................................................................................. 48 
3.3 QoS 2 : seulement une partieenvoyer une fois .................................................................................................................... 49 
4 distribution des messagesRéessayer .................................................................................................................................... 51 
5 message reçu ............................................................................................................................................ 51 
6 ordre des messages ............................................................................................................................................ 51 
7 nom du topic etfiltre de topic ......................................................................................................................... 52 
7.1 topicjoker ................................................................................................................................. 52 
7.2 avec$ouverttopic de l'en-tête ........................................................................................................................... 53 
7.3 topicSémantique et utilisation ......................................................................................................................... 53 
8 Gestion des erreurs ............................................................................................................................................ 54 
sécurité .................................................................................................................................................... 55 
1 Aperçu ................................................................................................................................................... 55 
2 MQTT Solution : sécurisation etauthentification ........................................................................................................... 55 
3 légerChiffrement et appareils contraints .................................................................................................................. 55 
4 notes d'implémentationélément .................................................................................................................................... 55 
4.1 clientAuthentification du point de terminaison ......................................................................................................................... 56 
4.2 clientautorisation du client ................................................................................................................................. 56 
4.3 ServicesAuthentification du point de terminaison ......................................................................................................................... 56 
4.4 contrôlemessages et messages d'applicationIntégrité des messages .................................................................................................... 56 
4.5 contrôlemessages et messages d'applicationConfidentialité des messages .................................................................................................... 56 
4.6 Messagenon-répudiation de la transmissionauthenticité .............................................................................................................. 56 
4.7 détectionclient et serveurusurpation d'identité client ....................................................................................................... 57 
4.8 détectioncomportement anormal ............................................................................................................................. 57 
4.9 autreprécautions de sécuritéélément .................................................................................................................. 57 
4.10 Utilisation SOCKS courtier .................................................................................................................... 58 
4.11 configuration de sécuritéFichier ........................................................................................................................... 58 
Utilisation WebSocket dopour la couche réseau .............................................................................................................. 59 
1 IANA Noteélément .................................................................................................................................. 59 

 
  MQTT-3.1.1-CN  7 
7  cohérence ................................................................................................................................................. 60 
7.1 objectif de cohérencemarque ........................................................................................................................................ 60 
7.1.1 MQTT côté serveur ............................................................................................................................. 60 
7.1.2 MQTT client ............................................................................................................................. 60 
annexe B Déclaration normative obligatoire (non normativenormative) ............................................................................................................. 62 
 

MQTT-3.1.1-CN 8

1 Aperçu

1.1 MQTT coopératifstructure organisationnelle du protocole

Cette spécification est divisée en septchapitres :

 Chapitre 1 - Introduction

 Chapitre 2 – MQTT format des messages de contrôle

 Chapitre 3 – MQTT paquet de contrôle

 Chapitre 4 – OpérationComportement

 Chapitre 5 – sécurité

 Chapitre 6 – Utilisation WebSocket Comme couche de transport réseau t

 Chapitre 7 – cohérentsobjectifs de sécurité

1.2 Terme

Utilisé dans cette spécificationMots-clés Requis DOIT，ne peut pas NE DOIT PAS，Exigence REQUIS，doit DOIT，Ne doit pas DOIT

PAS，devrait DEVRAIT，ne devrait pas NE DEVRAIT PAST，Recommandé RECOMMANDÉ，Oui PEUT，Facultatif OFACULTATIF

tout selon IETF RFC 2119 [RFC2119] description dansexpliquer.

Connexion réseau（Connexion réseau）：

MQTT utiliséProtocole de transport sous-jacentInfrastructure de protocole。

 Le client l'utilise pour se connecter au serveur.

 Il fournit ordonné,fiablede,Transport de flux d'octets bidirectionnel.

voir les exemples 4.2 section.

message d'application（Message d'application）：

MQTT protocole de communicationTransmettre sur le réseauDonnées d'application.messages d'application via MQTT lorsqu'ils sont transmis, ilsService associéQualité de service (QoS) etsujet

（Sujet）。

client（Client）：

Utilisation MQTT d'un programme ou d'un appareil.les clients se connectent toujourssur le réseau pour se connecter àServeur. IlOui

 Publier des messages applicatifs vers d'autres clients associésle client..

 AbonnementavecrequêteAccepte les messages applicatifs pertinents

 Se désabonner pour supprimerrecevoir des messages applicatifsrequête.

 Se déconnecter du serveurse connecter.

Côté serveur（Serveur）：

un programme ou un appareil, en tant que message d'envoiclient du message etle client demandant l'abonnementintermédiaire entre. Le serveurserveur

 Accepter les connexions réseau des clients.

 Accepter la publication du clientmessage applicatif

MQTT-3.1.1-CN 9

 Traiter l'abonnement du client, demande d'abonnement et de désabonnement.

 transférerAppliquer les messages à l'abonnement duclient du composant conformeSubscription。

Abonnement（Abonnement）：

L'abonnement contient un sujetFiltre de sujet (TFiltre de sujet) etun serveur le plus grandQualité de Service (QoS) niveau. Abonnement avec une seulesession

（Session) liée àconnexion. Les sessions peuventcontenir plus d'un abonnement. SessionChaque abonnement a unsujets différents viafiltre.

nom du sujet (Nom du sujet）：

Attaché au message d'applicationune étiquette sur, connue du serveur et avec l'abonnementcorrespondant. Le serveur envoiecelui du message d'applicationune copie à chaque correspondance

de l'abonnement du client.

filtre de sujetfiltre (Filtre de sujet :）：

celui inclus dans l'abonnementexpression, utilisépour représenter lesun ou plusieurs maîtresSujet. Les filtres de sujets peuventutiliser des caractères génériques.

Session（Session）：

client et serveuréchange d'état entreinteraction. Certaines sessions durent lorsquelongueur et réseaucomme une connexion réseau,d'autres peuvent être dansclient et serveur multiples

une connexion réseau continueextension d'intervalle.

paquet de contrôle（Paquet de contrôle MQTT）：

envoyé sur la connexion réseaules données d'information transmisespaquet.MQTT La spécification définit quatorzetypes différents de messages de contrôletexte,oùun (PUBLISH rapport

message) utilisé pour transmettre l'applicationmessage d'utilisation.

1.3 SpécificationRéférence

[RFC2119]

Bradner, S., « Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence », BCP 14, RFC 2119, mars

1997.

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

[RFC3629]

Yergeau, F., « UTF-8, un format de transformation de l'ISO 10646 », STD 63, RFC 3629, novembre 2003

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

[RFC5246]

Dierks, T. et E. Rescorla, « Le protocole Transport Layer Security (TLS) version 1.2 », RFC 5246, août

2008.

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

[RFC6455]

Fette, I. et A. Melnikov, « Le protocole WebSocket », RFC 6455, décembre 2011.

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

[Unicode]

Le Consortium Unicode. La norme Unicode.

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

 
  MQTT-3.1.1-CN  10 
1.4 Référence non normative 
[RFC793] 
Postel, J. Protocole de contrôle de transmission . STD 7, IETF RFC 793, septembre 1981. 
http://www.ietf.org/rfc/rfc793.txt 
 
[AES] 
Norme de chiffrement avancé(AES) (FIPS PUB 197). 
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf 
 
[DES] 
Norme de chiffrement des données (DES). 
http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf 
 
[FIPS1402] 
Exigences de sécurité pour les modules cryptographiques (FIPS PUB 140-2) 
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf 
 
[IEEE 802.1AR] 
Norme IEEE pour réseau local et métropolitains - Identité de dispositif sécurisé 
http://standards.ieee.org/findstds/standard/802.1AR-2009.html 
 
[ISO29192] 
ISO/IEC 29192-1:2012 Technologiesde l'information — -- Techniques de sécurité — -- Cryptographielégère -- Partie 
1: Généralités 
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=56425 
 
[MQTT NIST] 
Publication supplémentaire MQTT, MQTT et le cadre NIST pour l'amélioration de lacybersécurité desinfrastructures critiquese 
Cybersécurité 
http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-v1.0.html 
 
[MQTTV31] 
Spécification du protocoleMQTT V3.1. 
http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html 
 
[NISTCSF] 
Amélioration de la cybersécurité desinfrastructurescritiques, décret exécutif 13636 
http://www.nist.gov/itl/upload/preliminary-cybersecurity-framework.pdf 
 
[NIST7628] 
NISTIR 7628 Lignesdirectrices pour la cybersécurité du Smart Grid 
http://www.nist.gov/smartgrid/upload/nistir-7628_total.pdf 
 
[NSAB] 
NSA Suite B Cryptographie 
http://www.nsa.gov/ia/programs/suiteb_cryptography/ 
 

 
  MQTT-3.1.1-CN  11 
[PCIDSS] 
PCI-DSS Norme de sécuritédes données de l'industrie des cartes de paiementard 
https://www.pcisecuritystandards.org/security_standards/ 
 
[RFC1928] 
Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., et L. Jones, "SOCKS Protocole Version 5", RFC 
1928, mars 1996.  
http://www.ietf.org/rfc/rfc1928.txt 
 
[RFC4511] 
Sermersheim, J., éd., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, juin 
2006. 
http://www.ietf.org/rfc/rfc4511.txt 
 
[RFC5077] 
Salowey, J., Zhou, H., Eronen, P., et H. Tschofenig, "Transport Layer Security (TLS) Session 
Resumption without Server-Side State", RFC 5077, 20 janvier08. 
http://www.ietf.org/rfc/rfc5077.txt 
 
[RFC5280] 
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., et W. Polk, "Internet X.509 Public Key 
Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, mai 2008. 
http://www.ietf.org/rfc/rfc5280.txt 
 
[RFC6066] 
Eastlake 3rd, D., "Extensions de sécuritéde la couchede transport (TLS) : définitionsd'extension", RFC 6066, janviery 
2011.  
http://www.ietf.org/rfc/rfc6066.txt  
 
[RFC6749] 
Hardt, D., éd., « The OAuth 2.0 Authorization Framework », RFC 6749, octobre 2012. 
http://www.ietf.org/rfc/rfc6749.txt 
 
[RFC6960] 
Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., et C. Adams, "X.509 Internet Public 
Infrastructure de clés Enligne Certificat Statut Protocole - OCSP", RFC 6960, juin 2013. 
http://www.ietf.org/rfc/rfc6960.txt 
 
[SARBANES] 
Loi Sarbanes-Oxley de 2002. 
http://www.gpo.gov/fdsys/pkg/PLAW-107publ204/html/PLAW-107publ204.htm 
 
[USEUSAFEHARB] 
Safe Harbor États-Unis-UE 
http://export.gov/safeharbor/eu/eg_main_018365.asp 

MQTT-3.1.1-CN 12

1.5 représentation des données

1.5.1 bit binaire

les bits dans l'octet de 0 à 7. Le bit n° 7 est le plus élevé.bit significatif, le 0 Le bit est le bit le moins significatif.

1.5.2 valeur entière

La valeur entière est 16 bits, en big-endian (big-endian，octetde poids fortavant l'octet de poids faibleavant). Cela signifieavec un 16 bitscaractère dans le réseau

sur le réseau représenté comme l'octet le plussignificatif (MSB), suivi dela section du mot le moins significatif(LSB）。

1.5.3 UTF-8 Chaîne encodée

le contrôle décrit plus lointexte dans le message de contrôlece champ est encodé comme UTF-8 caractères de formatchaîne.UTF-8 [RFC3629] est unefficace

Unicode encodage de caractèresformat, pour prendre en charge la basepour la communication textuelle, il est ASCII Caractèrel'encodage effectueoptimisé.

Chaque chaînea unchamp de longueur de deux octets commecomme préfixe, il donnecette chaîne UTF-8 octets encodésnombre,ilsDanslégende

1.1 UTF-8 modifierstructure d'une chaîne de code décrit dansdécrit. Par conséquent, ce qui peut être transmis UTF-8 encodagela taille de la chaîne a unelimite, ne peut pas dépasserpasser

65535 octet。

Sauf indication contraire,toutes UTF-8 modifierchaîne de codela longueur doit être 0 à 65535 octetdans cette plage。

légende 1.1 UTF-8 caractère encodéfin de la chaînestructure

bit binaire

octet 1

la longueur maximale de la chaîneoctet de poids fort (MSB）

octet 2

la longueur maximale de la chaîneoctet de poids faible (LSB）

octet 3 ….

si la longueur est supérieure à 0, voici UTF-8 le nombre de caractères encodésdonnées.

UTF-8 encodageles caractères de la chaînedonnées de caractèresRequisest conforme à Unicode Spécification [Unicode] définie et dans RFC3629 [RFC3629] Moyenne

réaffirmé valide UTF-8 format. Il est particulièrement nécessairede souligner que,CesDonnéesne peut pascontenir le code de caractère à U+D800 et U+DFFF entre

données.sile serveur ou le client reçoitun paquet contenantInvalide UTF-8 contrôle des caractèrespaquet, ilRequisfermer laconnexion réseau [MQTT-

1.5.3-1]。

UTF-8 encodagela chaînene peut pascontenir un caractère nul U+0000。sile client ou le serveur reçoitarrivé à un contenant U+0000 de contrôlepaquet de contrôle

texte,ilRequisfermer la connexion réseau [MQTT-1.5.3-2]。

dans les donnéesne doit pascontenir ce qui suit Unicode point de codel'encodage. Siun récepteur (serveur ou client) a reçu un paquetcontient ce qui suit

contrôle de caractères arbitrairespaquet, ilOuifermer la connexion réseauconnect:

U+0001 et U+001F entreCaractère de contrôle

U+007F et U+009F entreCaractère de contrôle

La spécification Unicode Specificationa défini un point de code non-caractère (par ex., U+0FFFF）

La spécification Unicode Specificationa défini une garantie pour les caractèresréservés (par ex. U+0FFFF）

MQTT-3.1.1-CN 13

UTF-8 encodageséquence 0XEF 0xBB 0xBF toujoursest interprétée comme U+FEFF(espace insécable de largeur nullecaractère),quel que soit l'endroit oùil apparaît dans le caractère

quelle que soit la position dans la chaîne,tous les récepteurs de messagesne peuvent ni l'ignorer nile supprimer [MQTT-1.5.3-3]。

1.5.3.1 non normatifExemple

Par exemple, chaîne A𪛔 Yesune lettrelatine A suivie d'unpoint de code U+2A6D4(Il représente unCJK unifiécaractère idéographique

Extensions B caractère dans)，Cetencodage de chaînecomme suit :

légende 1.2 UTF-8 caractère codéchaîne non normativeexemple

Bit

octet 1

longueur de chaîne MSB (0x00)

octet 2

longueur de chaîne LSB (0x05)

octet 3

‘A’ (0x41)

octet 4

(0xF0)

octet 5

(0xAA)

byte 6

(0x9B)

byte 7

(0x94)

1.6 conventions de rédaction

Cette spécification utilise un surlignage jauneidentifiant de texte vifdéclaration de conformité,chaque déclaration de conformitése voit attribuer un telRéférence du format :[MQTT-x.x.x-

y]。

MQTT-3.1.1-CN 14

2 MQTT paquet de contrôleFormatage

2.1 MQTT Structure des messages de contrôle

MQTT communication du protocolepar échange prédéterminésémantique MQTT paquet de contrôle àCommunication. Cette sectiondécrit ces paquetsformat.

MQTT paquet de contrôlele paquet se compose de trois partiescomposées, selon la légende 2.1 –MQTT contrôlestructure du paquet de contrôle ordre de description :

légende 2.1 –MQTT du paquet de contrôleStructure

En-tête fixe pleinen-tête fixe, tousles paquets de contrôle incluent touscontiennent

En-tête variable en-tête variable,certains paquets de contrôlecontiennent

Charge utile charge utile, certains paquets de contrôlecontient

2.2 en-tête fixe

chaque MQTT contrôletous les paquets de contrôle contiennentun en-tête fixe。légende 2.2 -pleinformat de l'en-tête fixe décrit l'en-tête fixeformat de l'en-tête.

légende 2.2 -Fixeformat d'en-têteformule

Bit

octet 1

MQTT paquet de contrôletype de message

utilisé pourdu type de message de contrôle spécifiébit de drapeau

octet 2…

longueurrestante

2.2.1 MQTT Types de messages de contrôle

position :N° 1 un octet, bits binaires 7-4。

représenté par 4 N° de bitvaleurs de symbole, ces valeursvoir définition Tableau 2.1 -Types de messages de contrôle

Tableau 2.1 -contrôletype de paquettype

name

Valeur

messagesens du flux

Description

Réservé

Refuser

conserver

CONNECT

client vers serveur

Le client demande une connexionCôté serveur

CONNACK

serveur vers client

paquet de connexionaccusé de réception

PUBLISH

les deux directions sont autorisées

message de publication

PUBACK

les deux directions sont autorisées

QoS 1 Messagepublicationreçuaccusé de réception

PUBREC

les deux directions sont autorisées

Publication reçue (livraisongarantie étape 1)

PUBREL

les deux directions sont autorisées

Publication libérée (livraisongarantie étape 2)

MQTT-3.1.1-CN 15

PUBCOMP

les deux directions sont autorisées

QoS 2 MessagePublication terminée (garantieinteraction garantie étape 3）

client vers serveur

Demande d'abonnement du client

SUBACK

serveur vers client

demande d'abonnementmessageaccusé de réception

UNSUBSCRIBE

client vers serveur

Demande de désabonnementdu client

UNSUBACK

serveur vers client

Annuler l'abonnementmessageaccusé de réception

PINGREQ

client vers serveur

demande de battement de cœur

PINGRESP

serveur vers client

réponse de battement de cœur

DISCONNECT

client vers serveur

Le client se déconnecte

Réservé

Refuser

conserver

2.2.2 Indicateurs

en-tête fixe, le 1 les octets restants 4 bits [3-0]contient chacun MQTT paquet de contrôledrapeaux spécifiques au type de message,voir Tableau 2.2 -bit de drapeau。

Tableau 2.2 tout marqué comme“retain”bits de drapeau, tous sont réservéspour une utilisation future,Requisdéfini comme dans le tableauvaleurs listées [MQTT-

2.2.2-1]。silors de la réception d'un drapeau invalide, le récepteurrécepteurRequisFermer la connexion réseau. Il y aliés à la gestion des erreursPour plus de détails, voir 4.8 section [MQTT-

2.2.2-2]。

Tableau 2.2 -bit de drapeau

paquet de contrôle

solidedrapeaux d'en-tête fixe

Bit 3

Bit 2

Bit 1

Bit 0

CONNECT

Réservé

CONNACK

Réservé

PUBLISH

Utilisé dans MQTT 3.1.1

DUP

QoS

RETAIN

PUBACK

Réservé

PUBREC

Réservé

PUBREL

Réservé

PUBCOMP

Réservé

SUBACK

Réservé

UNSUBSCRIBE

Réservé

UNSUBACK

Réservé

PINGREQ

Réservé

PINGRESP

Réservé

DISCONNECT

Réservé

MQTT-3.1.1-CN 16

DUP

=contrôleduplication de livraison des paquetsdrapeau d'envoi

QoS

= PUBLISH messagedeniveau de qualité de service

RETAIN

= PUBLISH du paquetretaindrapeaux

PUBLISH contrôledans le paquet DUP, QoS et RETAIN description du flagdécrite dans 3.3.1 section.

2.2.3 longueur restante

position :à partir du premier 2 commence par un octet.

restantelongdegré（Longueur restante）ReprésenteLorsquemessage précédenttexte restantresteDiviserdeoctetnuméro,y comprispeutmessage variableen-tête etnégatifchargedeDonnées。restantlongdegré

à l'exclusion des octets utilisés pour l'encodagechamp Longueur restanteson propre décompte。

longueur restantechamp de longueurutiliser unlongueur variableméthode d'encodagecas,Pour moins de 128 valeur deil faitUtiliser un seul caractèresectionencodage. plus grandevaleur comme ci-dessousfaçon deGérer.

Faible 7 Les bits significatifs sont utilisés pour encoder les données., le bit de poids fortutilisé pour indiquer s'il y en a d'autresoctets de. Par conséquent, chaque motsection peut encoder 128 nombreValeur

et un

bit de continuation (

bit de continuation

）

. Le champ Remaining Lengthmaximum 4 caractèressection.

non normatifcommentaire

ExemplePar exemple，dixentrersystèmenombre 64 vaParmodifiercodeestunélémentsCaractèresection, valeurOui 64，dixsixentrersystèmeTableauafficherest 0x40,。dixentrersystèmenombreCaractère

321(=65+2*128)est encodéest de deux octets,le bit de poids faible est àavant. Le premier motsection est 65+128=193. notez que le plusbit de poids fort est

1 Représentederrièreau moinsil y a un octet de plus. Les deuxièmesoctets sont 2。

pasSpécificationcommentaire

这autoriserpermettre devraitutiliserenvoyermaximum 256MB(268,435,455)grandpetit decontrôlesystème rapporttexte。这élémentsnombre ValeurDans rapporttexteMoyendeTableau afficherOui：

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

Tableau 2.4 du champ Longueur restanteTaillemontre le champ Longueur restantela valeur représentée varie aveccroissance en octets.

Tableau 2.4 longueur restantedu champTaille

nombre d'octets

valeur minimale

valeur maximale

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)

désignent respectivement (chaquebit de poids faible de l'octet 7 bitsutilisés pour encoder les données, le bit le plus significatif est un bit d'indicateur）：

1 lorsqu'il s'agit d'octets,de 0(0x00)à 127(0x7f)

2 lorsqu'il s'agit d'octets,de 128(0x80,0x01)à 16383(0Xff,0x7f)

3 lorsqu'il s'agit d'octets,de 16384(0x80,0x80,0x01)à 2097151(0xFF,0xFF,0x7F)

4 lorsqu'il s'agit d'octets,de 2097152(0x80,0x80,0x80,0x01)à 268435455(0xFF,0xFF,0xFF,0x7F)

MQTT-3.1.1-CN 17

non normatifcommentaire

entier non négatif X utilise un schéma d'encodage à longueur variablel'algorithme est le suivant :

encodedByte = X MOD 128

X = X DIV 128

// s'il y a plus de données à encoder, positionner le bit de poids fort de cet octet

if ( X > 0 )

encodedByte = encodedByte OR 128

endif

'output' encodedByte

while ( X > 0 )

MOD est une opérationmodulo,DIV est une division entière,OR est une opération bit à bit ou（C langagedans lequel sont respectivement%，/，|）

non normatifcommentaire

du champ Remaining Lengthl'algorithme de décodage est le suivant：

multiplier = 1

value = 0

encodedByte = 'next byte from stream'

value += (encodedByte AND 127) * multiplier

multiplier *= 128

if (multiplier > 128*128*128)

throw Error(Malformed Remaining Length)

while ((encodedByte AND 128) != 0)

AND est une opération bit à bitopération AND (C dans le langage&）

lorsque cet algorithme se termine，valeur Paquetce qui est inclus estla valeur de la Remaining Length.

2.3 en-tête variable

certains MQTT paquets de contrôlecontiennent une partie Variable Header.il est dans l'en-tête fixeet la charge utileentre. Le contenu de l'en-tête variableselonle type de paquet

varie. Peutl'identifiant de paquet de l'en-tête variable(Packet Identifier）champ) exister dansles messages de plusieurs types.

2.3.1 identifiant de paquet

légende 2.3 -messageclasse d'identifianttype

Bit

octet 1

identifiant de paquet MSB

octet 2

identifiant de paquet LSB

MQTT-3.1.1-CN 18

de nombreux paquets de contrôlepartie d'en-tête variablecontient un message de deux octetschamp d'identifiant de paquet. Cespaquet est PUBLISH（QoS>0 temps)，

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

UNSUBACK。

SUBSCRIBE，UNSUBSCRIBE et PUBLISH（QoS supérieur à 0) paquet de contrôleRequiscontient unun non nul 16 bit d'identifiant de paquet

caractère (Packet Identifier）[MQTT-2.3.1-1]. Le client chaque foisenvoyer un nouveaude ces types dechaque fois qu'un messageRequisattribuer unactuel

identifiant de paquet inutiliséidentifiant [MQTT-2.3.1-2]. SiUn client veut renvoyerce contrôle spécialmessage de contrôle, lors d'une retransmission ultérieurece message

quand,ilRequisutilise le même identifiant.Lorsque le client a fini de traiter ceun paquet correspondant àAprès confirmation, cetidentifiant de message seralibéré comme réutilisable.

QoS 1 de PUBLISH correspondantest PUBACK，QoS 2 de PUBLISH correspondantest PUBCOMP, et SUBSCRIBE ou

UNSUBSCRIBE correspondantséparémentOui SUBACK ou UNSUBACK [MQTT-2.3.1-3]。envoyer unéléments QoS 0 de PUBLISH

messageLorsque, les mêmes conditions s'appliquent également aucôté serveur [MQTT-2.3.1-4]。

QoS Défini sur 0 de PUBLISH messagene peut pascontenir un identifiant de paquet [MQTT-2.3.1-5]。

PUBACK, PUBREC, PUBREL messageRequiscontenant etinitialement envoyé PUBLISH rapportpaquet avec le mêmeidentifiant de message [MQTT-2.3.1-

6]. De même,SUBACK et UNSUBACK Requiscontenu dans le SUBSCRIBE et UNSUBSCRIBE rapport correspondantutilisé dans le textede

identifiant de paquet [MQTT-2.3.1-7]。

nécessiteLe paquet de contrôle de l'identifiant de message est dans Tableau 2.5 -contient un identifiant de paquetpaquet de contrôle de listé dans.

Tableau 2.5 -contientidentifiant de messagecontrôle du symbolepaquet de contrôle

paquet de contrôle

identifiant de paquetcaractère d'identifiantsegment

CONNECT

Non requis

CONNACK

Non requis

PUBLISH

requis (si QoS > 0）

PUBACK

nécessite

PUBREC

nécessite

PUBREL

nécessite

PUBCOMP

nécessite

SUBACK

nécessite

UNSUBSCRIBE

nécessite

UNSUBACK

nécessite

PINGREQ

Non requis

PINGRESP

Non requis

DISCONNECT

Non requis

MQTT-3.1.1-CN 19

client et serveurattribués indépendammentidentifiants de message. Par conséquent, le clientcombinaison côté serveurutilisant le même messageidentifiant de message peut être implémenté et

l'échange de messages envoyés.

non normatifcommentaire

Le client envoie un identifiantcaractère est 0x1234 de PUBLISH paquet,il peutpeut être lors de la réception de celad'un message PUBACK deavant, d'abord

reçoit envoyé par le serveurun autre différentmais l'identifiant du messagel'identifiant est aussi 0x1234 de PUBLISH paquet.

Client Serveur

PUBLISH Packet Identifier=0x1234---

--PUBLISH Packet Identifier=0x1234

PUBACK Packet Identifier=0x1234---

--PUBACK Packet Identifier=0x1234

2.4 payload

un certain MQTT paquet de contrôle dans le paquetla dernière partie du paquetcontient unecharge utile valide, ce sera dans lediscuté au chapitre 3.pour PUBLISH en parlantvalide

charge utileest le message d'application.Tableau 2.6 – contient unpaquet de contrôle valide avec une charge utile liste les exigencesPaquet de contrôle de la charge utile.

Tableau 2.6 – contient la charge utilemessage de contrôletexte

paquet de contrôle

payload

CONNECT

nécessite

CONNACK

Non requis

PUBLISH

Optional

PUBACK

Non requis

PUBREC

Non requis

PUBREL

Non requis

PUBCOMP

Non requis

nécessite

SUBACK

nécessite

UNSUBSCRIBE

nécessite

UNSUBACK

Non requis

PINGREQ

Non requis

PINGRESP

Non requis

DISCONNECT

Non requis

MQTT-3.1.1-CN 20

3 MQTT paquet de contrôle

3.1 CONNECT – connexioncôté serveur

client vers serveurétablissement de la connexion réseauaprès établissement, le client envoie aucôté serveurle premier message deObligatoireOui CONNECT message [MQTT-

3.1.0-1]。

sur une connexion réseau, le client peut uniquementenvoyer une fois CONNECT message. ServeurObligatoirele client envoiele second envoyé CONNECT

paquet comme une violation de protocolegérer normalement et déconnecterla connexion du client [MQTT-3.1.0-2]. Concernant les erreursPour les informations traitées, veuillez vous référer à 4.8 la section.

la charge utile contient unun ou plusieurs encodageschamps. Y comprisl'identifiant unique du client,Will sujet,Will message, utiliseznom d'utilisateur et mot de passe.diviser

l'identifiant du clienten dehors，autreLes champs sont tous facultatifs, en fonction des bits de drapeaupour déterminer le message variabledans l'en-têtesiCes champs doivent être inclus。

3.1.1 en-tête fixe

légende 3.1 –CONNECT la partie fixe du messageen-tête fixe

Bit

octet 1

MQTT type de paquettype (1)

Réservé retainbits

octet 2…

valeur de longueur restante

longueur restantechamp de longueur

la Longueur restante est égale à l'en-tête variablelongueur de l'en-tête variable（10 octet) plus la charge utilela longueur. Encodagevoir méthode 2.2.3 sectiondescription.

3.1.2 en-tête variable

CONNECT rapportEn-tête variable du messageL'en-tête contient dans l'ordre suivantquatre champs : protocolenom (Nom du protocole), protocoleNiveau（Protocole

Niveau），connexiondrapeau (Indicateurs de connexion) etKeep Alive (Keep Alive）。

3.1.2.1 Nom duprotocole

légende 3.2 -Nom duprotocolecomposé d'octets

Description

nom du protocole

octet 1

longueur MSB (0)

octet 2

longueur LSB (4)

octet 3

‘M’

octet 4

‘Q’

octet 5

‘T’

MQTT-3.1.1-CN 21

byte 6

‘T’

Le nom du protocole est une chaîne qui représente le protocolenom du protocole MQTT de UTF-8 la chaîne encodée.MQTT de la spécificationLes versions ultérieures nechangeront pas cedécalage de chaîneet

longueur.

si le nom du protocole est incorrectconfirmer le serveurOuidéconnecter le clientla connexion, aussiOuiselond'autres spécificationscontinuer le traitement CONNECT message. Pour

dans ce dernier cas,conformément à cette spécification,Côté serveurne peut pascontinuer le traitement CONNECT message [MQTT-3.1.2-1]。

pasSpécificationcommentaire

outil d'inspection de paquets, par exemple les pare-feu, peut utiliser le protocolenom du protocole pour identifier MQTT trafic.

3.1.2.2 niveau de protocoleautre

légende 3.3 - Protocol Level byte ProtocolLevelbyteconstituer

Description

niveau de protocole

byte 7

Level(4)

le client utilise 8 la valeur de symbole non signé du bitindiquela révision du protocole. Pourdans 3.1.1 éditionprotocole, niveau de protocolevaleur du champ identifiantOui 4(0x04). Si l'envoi

détecte un protocole non pris en chargeniveau, le serveurRequisenvoyer àenvoyer un code de retourest 0x01(nonniveau de protocole pris en chargedifférence) de CONNACK messageresponse

CONNECT message, puis déconnecterdéconnecter laconnexion du client [MQTT-3.1.2-2]。

3.1.2.3 identifiant de connexionsera

l'octet Connect Flags contientcontient certains éléments utilisés pour indiquerdécider MQTT connecterles paramètres de comportement de connexion. Il indique également qu'il y acaractères dans la charge utilesi le champ existe.

légende 3.4 -bits des drapeaux de connexion

Bit

Nom d'utilisateure

Option

Password

Option

WRétention du testament

WQoS du testament

WDrapeau du testament

Propre

Session

Réservé

octet 8

Côté serveurRequisvérifier CONNECT paquet de contrôlele drapeau retain du textebit (les 0 bits) s'il est 0，sin'est pas 0 doit déconnecterla connexion client

[MQTT-3.1.2-3]。

3.1.2.4 session proprediscours

position :Le bit de l’octet des drapeaux de connexion 1 bits

ce bit indiquedétermine l’état de sessionla méthode de traitement.

client et serveurpeuvent sauvegarder la sessionétat, pour prendre en chargeà travers une connexion réseautransmission fiable des messages. Ce bit d’indicateurutilisé pour contrôler l’état de session

durée de vie.

MQTT-3.1.1-CN 22

Si la session propre (CleanSession）l’indicateur est définidéfini à 0, le serveurRequisbasé sursession actuelle (faireIdentifiée par l’identifiant clientdifférence) de

restauration de l’état et le clientcommunication entre les extrémités. Sis’il n’existe pas avec ceidentifiant clientsession associée,Côté serveurRequiscréer uneune nouvelle session. Dans

après la fermeture de la connexion,après la déconnexion de la connexion, client et serveurserveurRequisconserver les informations de sessionsouffle [MQTT-3.1.2-4]. Lorsque le drapeau de session de nettoyage estsession flag is 0

La connexion de session est déconnectée.ensuite, le serveurRequisilaprès QoS 1 et QoS 2 niveaule message est enregistré commede l'état de sessionune partie, si这

Certains messages correspondent à la déconnexion.lors de la connexion, le clientdes abonnements [MQTT-3.1.2-5]。le serveur aussiOuiEnregistrersatisfait la même conditionde QoS 0 niveau

message.

sieffacergérerSession（CleanSession）marquevaParParamètresest 1，clientfinetServicesfinRequisrejeterdeavantdevoircomment peutsession etouvrirdémarreraNouveau

devaparole。vaparoleseulementconservercontinueretnetréseauconnecterJiemêmeexemplelongdequandentre。et这élémentsvontparolefermerunirdeétatconditionnombreselonne peut pasPardevoirquoideaprèsdevaparolelourdutilisation

[MQTT-3.1.2-6]。

L'état de session du client.L'état comprend :

 A été envoyé au serveur.fin,MaisPas encore acquitté QoS 1 et QoS 2 niveauautres messages

 A été reçu du serveur., mais n'a pas encorede l'accusé de réception de fin QoS 2 niveauautres messages.

L'état de session du serveur.L'état comprend :

 SessionS'il existe, même si l'état de sessiontoutes les autres partiesest vide.

 Les informations d'abonnement du client.message.

 A été envoyé au client.fin,MaisPas encore acquitté QoS 1 et QoS 2 niveauautres messages。

 sur le point deTransmis au client. QoS 1 et QoS 2 niveauautres messages。

 A été reçu du client., mais n'a pas encored'accusé de réception d'achèvement QoS 2 niveauautres messages.

 facultatif,préparerEnvoyé au client. QoS 0 messages du niveau。

Les messages conservés ne sont pas côté serveur.état de session du serveurune partie de, seralorsque la session se terminene peut passupprimer les messages conservéssouffle [MQTT-3.1.2.7]。

Concernant le stockage d'état.limitations et détails voirN° 4.1 section.

Lorsque l'indicateur de session propreest défini sur 1 lorsque,client et serveurla suppression de l'état côté serveur n'a pas besoinsi opération atomique。

non normatifcommentaire

Pour garantir qu'en cas deétat en cas de défaillancecohérence, le clientcôté doit utiliser sessionindicateur d'état de session 1 lourddemande de connexion répétée, jusqu'à ce que la connexion réussisse

succès.

non normatifcommentaire

D'une manière générale, les clientsà la fin, toujours lors de la connexion,vont nettoyer le drapeau de sessionle drapeau est défini sur 0 ou 1，Et n'utilisez pas alternativement les deuxtypes de valeur. Cechoix à faire

Cela dépend de l'application spécifique.. Le drapeau Clean Sessionle drapeau est défini sur 1 le client nerecevra pas les anciensmessage d'application,de plusà chaque connexionaprès succès

Tous doivent se réabonner.toutassociéSujet. Clean sessionle drapeau est défini sur 0 deLe client recevra touslorsqu'il se connectedéconnexionpendant l'envoi

publié QoS 1 et QoS 2 message au niveau. Par conséquent,doit garantirqu'il n'est pas perdu pendant que la connexion est déconnectéele message, il fautUtilisation QoS 1 ou

QoS 2 Niveau, simultanément nettoieraLe drapeau de session est défini sur 0。

non normatifcommentaire

MQTT-3.1.1-CN 23

drapeau Clean Session 0 Lorsque le client se connecteIl demande au serveur deaprès que la connexion est déconnectée, enregistrerconserver son MQTT état de session.si ouvert

Prévu à un moment ultérieurse reconnecter au moment de se connecter àce serveur,la connexion du client devraitutiliser uniquement l'indicateur de session propre 0. Lorsque le client décide

aprèsLorsqu'il n'utilise plus cette session, ildevrait nettoyer la sessionl'indicateur est défini à 0 enfin puisse connecter une fois,Puis se déconnecter.

3.1.2.5 indicateur Will

position :Le 2 bit des indicateurs de connexion.

indicateurWill (Will Flag) est définiest 1, indiquant siSi la demande de connexion estacceptée, le message Will（Will Message）MessageRequisest stocké dans

Le serveur et avec ceune connexion réseau associéeassociée. Après que le réseaulorsque la connexion est fermée,Côté serveurRequispublier ceWillmessage,sauf sile serveur reçoit

DISCONNECT lorsque le message est suppriméCeWillMessage [MQTT-3.1.2-8] 。

Le message Will publiéconditions, y compris maissans s'y limiter :

 Le serveur a détectéa I/O Erreur ou défaillance réseau。

 Le client maintient la connexionconnexion (Keep Alive）dans le délai imparti a échoué à lacommunication.

 Le client n'a pas envoyé en premierenvoyer DISCONNECT Le message a directement fermé la connexion réseau.

 En raison d'une erreur de protocole, le serveurle serveur a fermé le réseauconnexion réseau.

siL'indicateur Will est défini à 1, connexiondans l'indicateur de connexion Will QoS et Will Retain Champsseront utilisés par le serveurpour,en même tempsdans la charge utiledoit

doitcontenir Will Topic et Will Message Champs [MQTT-3.1.2-9]。

Une fois publié oule serveur a reçuenvoyé par le client DISCONNECT paquet,seramessage puisRequisSupprimé de l'état de session stocké.

diviser [MQTT-3.1.2-10]。

siL'indicateur Will est défini sur 0，connexiondans l'indicateur Will QoS et Will Retain ChampsRequisDéfini sur 0, etdans la charge utilene peut pas

contient WSujet à remplir et WMessage à remplir Champs [MQTT-3.1.2-11]。

siL'indicateur Will est défini sur 0, réseaulorsque la connexion réseau est déconnectée，ne peut pasenvoyer le message Will [MQTT-3.1.2-12]。

le serveur devraitrapidementémettretissuWillMessage。Dansfermermachineoudéfautdesentimentdans certaines circonstances，le serveur peutreportervaéliminerinformationémettretissudirectementàaprèsdelourddébut.

Si ce genre decas, au serveurdéfaillance du serveur et vaaprès la publication du messageil peut y avoir un délai entre。

3.1.2.6 va QoS

position:Les drapeaux de connexion 4 et le 3 bit.

Ces deux bits sont utilisés pour spécifierpublishWillLe service utilisé lors de l'envoi d'un messageniveau de qualité.

siLe drapeau Will est défini sur 0，Will QoS aussiRequisDéfini sur 0(0x00) [MQTT-3.1.2-13]。

siLe drapeau Will est défini sur 1，Will QoS la valeur depeut être égale à 0(0x00)，1(0x01)，2(0x02). Savaleur dene peut pasêtre égale à 3

[MQTT-3.1.2-14]。

3.1.2.7 Will Retain

position :Le 5 bit des indicateurs de connexion.

MQTT-3.1.1-CN 24

siLorsque le message Will est publié, il doit être conservéRetain, il faut spécifierla valeur de ce bit.

siLe drapeau Will est défini à 0, laisserWill Retain (Will Retain）drapeau aussiRequisDéfini à 0 [MQTT-3.1.2-15]。

siLe drapeau Will est défini à 1：

 siLe Will Retain est défini à 0, le serveurRequisTraiter le message Will comme une publication de message non-conservé [MQTT-3.1.2-16]。

 siLa conservation du testament est définie sur 1, le serveurObligatoiretraite le message testament commePublié en tant que message retenu [MQTT-3.1.2-17]。

3.1.2.8 Nom d'utilisateurIndicateurs

position :Le 7 bit des indicateurs de connexion.

si l'indicateur de nom d'utilisateur (Nom d'utilisateur) est défini sur 0, dans la charge utilene peut pascontenirchamp de nom d'utilisateur [MQTT-3.1.2-18]。

si l'indicateur de nom d'utilisateur (Nom d'utilisateur) est défini sur 1, dans la charge utileObligatoirecontientchamp de nom d'utilisateur [MQTT-3.1.2-19]。

3.1.2.9 indicateur de mot de passetestament

position :Le 6 bit des indicateurs de connexion.

si l'indicateur de mot de passe (Password)est défini à 0, dans la charge utilene peut pascontient un champ de mot de passe [MQTT-3.1.2-20]。

si l'indicateur de mot de passe (Password)est défini à 1, dans la charge utileObligatoirecontient un champ de mot de passe [MQTT-3.1.2-21]。

Si l'indicateur de nom d'utilisateurest défini sur 0, l'indicateur de mot de passe aussiRequisDéfini sur 0 [MQTT-3.1.2-22]。

3.1.2.10 maintien de connexion

légende 3.5 maintien de connexionbyte

Bit

octet 9

maintien de connexion Maintien deconnexion MSB

octet 10

maintien de connexion Maintien deconnexion LSB

Maintien de connexion (Keep Alive) est unune valeur en secondesl'intervalle de temps, exprimé ena 16 Le mot de bits, qui fait référence àle client termine la transmissionCheng

du moment d'un message de contrôle au moment de l'envoi du message suivant, les deuxentreautoriserpermettreVideinactifle plusgrandquandintervalleséparé。le client est responsableprotégerprouvercontrôler

messageémettreenvoyerdequandintervalleséparéNondépasserpasserLa valeur keepalive.sipasOuiun quelconquesesilde contrôlesystèmerapporttexte peutavecémettreenvoyer,clientrequisenvoyera

PINGREQ message [MQTT-3.1.2-23]。

indépendammentQuelle est la valeur de keep alive, clientclient à tout momentpeuvent tous être envoyés PINGREQ Packet, et utiliser PINGRESP message pour déterminer le réseau

Réseau et activité côté serveurétat actif.

si le keepalivevaleur denonzéro, etetfermeserveurDansunvirgule cinqfoisdeprotégermaintenir la connexionJiequandentredansaucuneréceptiondeclientfindecontrôlerapporttexte，ilrequisbreak

Ouvrir le réseau du clientconnexion, considérer le réseaula connexion réseau a été déconnectée [MQTT-3.1.2-24]。

le client a envoyé PINGREQ messageEnsuite, si dans un délai raisonnablen'a toujours pas reçu PINGRESP paquet, ildevraitfermer la connexion au serveur

La connexion réseau du point de terminaison.

MQTT-3.1.1-CN 25

La valeur du keep-alive estzéro indiqueafficherfermer keepmaintenirconnecterJieméritecapacité。cela signifie, servicefinNonBesoinvouloirparce queinvitéménagepoint de terminaison nonactifetrompreouvrirconnexionconnexion.Remarque：

Indépendamment de la valeur du keep-alive, à tout moment, tant quevêtementsaffairepoint de terminaison reconnaîtestLe client est inactif ou ne répond pas et peut être déconnecté.clientdu point de terminaisonconnexion

connexion.

non normatifcommentaire

La valeur réelle du keep-alivevaleur est spécifiée par l'applicationspécifiée, généralementquelques minutes. Autoriserla valeur maximale est 18 heures 12 Diviser 15 secondes.

3.1.2.11 en-tête variable non normatifportéeExemple

légende 3.6 -en-tête variablenon normatifExemple

Description

nom du protocole

octet 1

Longueur MSB (0)

octet 2

Longueur LSB (4)

octet 3

‘M’

octet 4

‘Q’

octet 5

‘T’

byte 6

‘T’

niveau de protocole

Description

byte 7

Niveau (4) Niveau

drapeau de connexion Drapeaux de connexion

octet 8

Indicateur de nom d'utilisateur (1) indicateur de nom d'utilisateurname flag

Indicateur de mot de passe (1) indicateur decode dense

WConserver le testament (0) WTestament indicateur de rétention

WQoS du testament (01) WTestament Qualité de service

WIndicateur de testament (1) WTestament Indicateurs

Session propre (1) nettoyageSession

Réservé (0) bit réservé

temps de keepalive

octet 9

délai de maintien MSB (0)

octet 10

délai de maintien LSB (10)

MQTT-3.1.1-CN 26

3.1.3 payload

CONNECT rapportela charge utile du messagecharge utile (chargeutile) contient un ouplusieurs champs codés en longueurun champ préfixé par, les indicateurs dans l'en-tête variabledéterminentsi

Contient ces champs.si inclus，RequisApparaissent dans cet ordre: identifiant clientidentifiant, le sujet du testamentproblème,testamentMessage, nom d'utilisateur, mot de passe

code [MQTT-3.1.3-1]。

3.1.3.1 clientIdentifiants

vêtementsaffairefinfaireutiliserinvitéménagefinmarqueconnaîtresymbole (ClientId) connaîtreautreinvitéménagefin。connecterJievêtementsaffairefindechaqueélémentsinvitéménagefintousOuiseulementundeinvitéménagefinmarqueconnaîtresymbole

（ClientId）。client et serveurles points de terminaison doivent utiliser ClientId connaîtredistinguer entre les deuxentre MQTT état lié à la sessioncondition [MQTT-3.1.3-

2]。

identifiant client (ClientId) RequisExistede plusRequisOui CONNECT messageLe premier de la charge utileun champ [MQTT-3.1.3-3]。

identifiant clientRequisOui 1.5.3 défini dans la section UTF-8 Chaîne encodée [MQTT-3.1.3-4]。

Côté serveurRequisAutorisé 1 à 23 octets de long UTF-8 client encodéIdentifiant client, le clientl'identifiant client ne peut contenir queces caractères :

“0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ”(lettres majuscules,Lettres minuscules

et chiffres)[MQTT-3.1.3-5]。

Côté serveurOuiautorise l'encodé ... à dépasserpasser 23 caractèresclient de la sectionIdentifiants (ClientId). ServeurOuiautoriser les paquetscontenant ceux non listés ci-dessusreprésentent un caractère

L'identifiant client (ClientId)。

Côté serveurOuipermet au client de fournirfournir un caractère zéroL'identifiant client de la section (ClientId) , siAprès avoir fait cela,Côté serveurRequisTraiter ceci comme un cas spécial

cas spéciaux et attribuer un identifiant uniqueidentifiant client uniqueidentifiant à ce clientclient. Ensuite, ilRequisSupposonsle client a fourniCe client uniqueidentifiant

caractère,traitement normalCe CONNECT message [MQTT-3.1.3-6]。

Si le client fournitun octet zérode l'identifiant clientsymbole, ilObligatoireeffacera égalementdrapeau de session définidéfini sur 1 [MQTT-3.1.3-7]。

Si le client fournitde ClientId est de zéro octetet le drapeau Clean Sessionmarqué comme 0, servicefinObligatoireenvoie un code de retour de 0x02(indiquant que l'identifiant n'est pas

valide) de CONNACK paquet de réponserépondre au clientde CONNECT message，puisfermer la connexion réseau [MQTT-3.1.3-8]。

Si le serveur rejettede ce ClientId，ilObligatoireenvoyerle code de retour est 0x02(tableauindique que l'identifiant est invalideformat) de CONNACK paquet de réponse

du client CONNECT paquet,puis ferme la connexionréseau [MQTT-3.1.3-9]。

non normatifcommentaire

L'implémentation client peutfournir une méthode pratiqueutilisée pour générer aléatoirede ClientId. Lorsque le Clean Sessiondrapeau est défini sur 0 devraitque

Abandonner proactivement l'utilisation de cetteméthode.

3.1.3.2 sujet Will

siL'indicateur Will est défini à 1, il y ale champ suivant de la charge utilele champ est le sujetWill (Will Topic). SujetWillRequisOui 1.5.3 la section spécifie

sémantique UTF-8 encodageString [MQTT-3.1.3-10]。

MQTT-3.1.1-CN 27

3.1.3.3 message Will

siL'indicateur Will est défini à 1, il y ale champ suivant de la charge utilele champ est le Willmessage. Le message Willle message définit ce qui serapublié sur le sujet Willla réponse du sujet

Utilisez le message, voir 3.1.2.5 la description de la section. Ce champ est constitué d'un deux-octetsla longueur et le message Willla charge utile du messagecomposé de, représenté commezéro octets ou

Plusieurs séquences d'octets.la longueur donne ce qui suitles données qui suiventnombre d'octets, pascontientlongueurLes deux octets occupés par le champ lui-mêmeoctets.

testamentLorsqu'un message est publié sur le sujet testament, sa charge utilela charge utile contient uniquement cesdonnées de champPartie, n'inclut pas l'ouvertureles deux champs de longueur de l'en-têteoctet.

3.1.3.4 Nom d'utilisateur

si l'indicateur du nom d'utilisateur (Nom d'utilisateur) est défini sur 1, la partie suivante de la charge utileles champs sont exactement cela.Nom d'utilisateurRequisOui 1.5.3 sectiondéfini

UTF-8 encodageChaîne [MQTT-3.1.3-11]. servicele serveur peutil est utilisé pour l'identitéauthentification et autorisation.

3.1.3.5 Password

si le mot de passe (Password) drapeauest défini sur 1, le champ suivant de la charge utile estcela. mot de passele champ code contient une longueurde deux octets de la section

Champs，longueurIndique le nombre d'octets de données binaires(sans compter le champ de longueur lui-mêmeles deux octets occupés par lui-mêmeoctets), puissuit 0 à 65535 l'octet

Les données binaires.

légende 3.7 - octets du mot de passe

Bit

octet 1

longueur des données MSB

octet 2

longueur des données LSB

octet 3 ….

si la longueur est supérieure à 0, voici la partie de données

3.1.4 response

Remarque : le serveur peutde sorte que dans le même TCP port ou saprise en charge sur d'autres points de terminaison réseauprend en charge plusieurs protocoles (y compris cetteversion antérieure du protocolececi).si le serveur

Le serveur détermine que le protocole est MQTT 3.1.1, puisil suit la méthode suivantede vérification de la connexionrequête.

1. Après que la connexion réseau est établie, si le serveurdans un délai raisonnablen'a pas reçu dans CONNECT signalerle paquet, le serveurdevraitfermercette connexion

connexion.

2. Côté serveurRequisconformément à 3.1 la vérification des exigences de la section CONNECT paquet,sile paquet n'est pas conforme àla spécification, le serveurn'envoie pas

CONNACK messagefermer directementConnexion réseau [MQTT-3.1.4-1]。

3. Côté serveurOuiVérifie CONNECT du paquetsi le contenu satisfaitsatisfait une quelconque autrerestriction,Ouieffectuer l'authentification d'identitéet l'autorisation

Vérifications. Si une vérification ne passe pascependant, selon 3.2 la description de la section, elledevraitenvoyer un code de retourapproprié,non nul

CONNACK réponse, etObligatoirefermer cette connexion réseau.

Si la vérification réussit,le serveur exécuterales étapes suivantes.

1. si ClientId indiqueLe client s'est connecté à ce serveurServeur, alors le serveurObligatoiredéconnecter le client existantconnexion client [MQTT-

3.1.4-2]。

2. Côté serveurObligatoireselon 3.1.2.4 la sectiondela descriptionExécuterLe processus de nettoyage de session [MQTT-3.1.4-3]。

3. Côté serveurObligatoireenvoie un code de retour dezéro CONNACK paquet comme CONNECT du paquetréponse d'accusé de réception [MQTT-3.1.4-4]。

4. Démarrer la distribution des messages etmaintenir lemoniteur d'état de connexion.

MQTT-3.1.1-CN 28

Autoriséle client envoie CONNECT messageenvoie immédiatement ensuiteAutres paquets de contrôle ;le client n'a pas besoind'attendre le CONNACK du serveur

paquet.sile serveur a rejeté CONNECT, ilne peut pastraiter le clientDans CONNECT après le paquet, envoyertoute donnée envoyée [MQTT-

3.1.4-5]。

non normatifcommentaire

Le client attend généralementattendre un CONNACK paquet. Cependant,le client a le droit dereçu CONNACK avant deenvoyer des paquets de contrôle，

Comme il n'est pas nécessaire de maintenirl'état de connexion, celapeut simplifier l'implémentation du clientapparaître.

3.2 CONNACK – accuser réception de la demande de connexionTrouver

le serveur envoie CONNACK messageréponse du clientreçu CONNECT rapportpaquet. Le serveurenvoyé au clientle premier message dedoit

besoinOui CONNACK [MQTT-3.2.0-1]。

Si le client est dansun délai raisonnable n'a pasreçu du serveurde CONNACK paquet,clientdoitFermer le réseauconnexion réseau.

raisonnable

le temps nécessaire

Dépend du type d'applicationet de l'infrastructure de communicationmise en œuvre.

3.2.1 en-tête fixe

Le format de l'en-tête fixevoir légende 3.8 – CONNACK rapporttexte fixeen-tête fixe la description de。

légende 3.8 – CONNACK en-tête fixe du paquet

Bit

octet 1

MQTT type de paquet de contrôle (2)

Réservé bit réservé

octet 2

longueur restante (2)

longueur restantechamp de longueur

ReprésenteLa longueur de l'en-tête variable. Pour CONNACK messagecette valeur vaut 2。

3.2.2 en-tête variable

Le format de l'en-tête variablevoir légende 3.9 –CONNACK Le message peuten-tête variable dedescription.

légende 3.9 –CONNACK en-tête variable du paquet

Description

drapeaux d'accusé de réception de connexion

Réservé bit réservé

octet 1

code de retour de connexion

octet 2

MQTT-3.1.1-CN 29

3.2.2.1 Accusé de réception de connexionDrapeau d'accusé de réception

N° 1 octets sont

drapeaux d'accusé de réception de connexion

, bit 7-1 sert à garantirbit réservé etRequisDéfini à 0。

N° 0 (SP)bits est actuelSession（Session présente）Indicateurs。

3.2.2.2 session actuellediscours

position :Le bit du drapeau d'accusé de réception de connexion 0 bit.

Si le serveur reçoitClean Session (CleanSession）Flagsest 1 deconnexion, saufserait CONNACK Le code de retour dans le paquetdéfini à 0

de plus, égalementRequisva CONNACK dans le paquetparamètre de session actuelle（Session Present）Flagsest 0 [MQTT-3.2.2-1]。

Si le serveur reçoita CleanSession est 0 deconnexion,drapeau de session actuellela valeur dépend de si le serveura déjà enregistré ClientId

L'état de session du client correspondantétat de session. Sile serveur a déjà sauvegardéstocké l'état de session, ilRequisdéfinira CONNACK Le drapeau de session actuelle dans le paquetdéfini

défini à 1 [MQTT-3.2.2-2]。Si le serveuril n'y a pas d'état sauvegardéétat de session, ilRequisva CONNACK signalerdans le messageparamètre de session actuelle

est 0. Il est également nécessaire de CONNACK signalerle code de retour dans le texte est défini à 0 [MQTT-3.2.2-3]。

Le drapeau de session actuelle est utilisépar le serveur et le clientpour savoir s'il existe déjàune conservation de l'état de session stockérestent cohérents.

une foisles paramètres d'initialisation de session terminés, la session déjà sauvegardéele client avec état de session attendraattend que le serveur maintienneil stockel'état de session.si le client

Le client reçoit du serveurreçuactuelLa valeur diffère de celle attendue, le client peutchoisir de poursuivre cecisession ou déconnexion.clientpeut abandonner

Abandonner le client et le serveursession entre les points de terminaisonétat, méthodeest,déconnecter, puisindicateur Clean Sessionl'indicateur est défini à 1, se reconnecter,puisde nouveau

Déconnexion.

Si le serveur envoiecontenait un non-avec un code de retour nul CONNACK paquet, ilRequisservira deindicateur de session précédenteDéfini à 0 [MQTT-

3.2.2-4]。

3.2.2.3 retour de connexioncode de réponse

position :de l'en-tête variable 2 un octet。

champ Connect Return Codeen utilisant une valeurnon signée d'un octet,Dans Tableau 3.1 – retour de connexionvaleur du code de retour Listée dans. Si le serveur reçoitun valide

de la méthode CONNECT paquet, mais semblepour une raison quelconque ne peut pasle gérer, le serveurle serveur devrait essayerenvoyer un contenant un retour non nulcode de retour (dans le tableaude

d'un particulier) CONNACK paquet. Sile serveur a envoyéun contenant un code de retour non nulde CONNACK paquet,alors ilObligatoirefermer

fermer la connexion réseau [MQTT-3.2.2-5].。

Tableau 3.1 –Valeur du code de retour de connexion

Valeur

code de retourréponse

Description

0x00 connexion acceptéeaccepter

La connexion a été acceptée par le serveurAccepter

0x01 connexion refuséerefusée, non prise en chargeversion de protocole

Le serveur ne prend pas en charge le clientdemandé par le client MQTT niveau de protocoleautre

0x02 connexion refuséerefusée, pasun identifiant client valide

L'identifiant client estcorrect UTF-8 encodage,MaisServices

le point de terminaison n'est pas autorisé à utiliser

0x03 connexion refuséerefusé, serveurserveur indisponible

La connexion réseau a été établie, mais MQTT service indisponible

0x04 connexion refuséerefusé, invalidele nom d'utilisateur ou le mot de passe

du nom d'utilisateur ou du mot de passeformat de données invalide

MQTT-3.1.1-CN 30

0x05 connexion refuséerefusé, nonautorisé

Le client n'est pas autoriséà se connecter à ce serviceappareil

6-255

conserver

Si vous pensez que dans le tableau ci-dessustoutes les connexions renvoientaucun des codes de retour n'est approprié，alorsCôté serveurRequisFermer la connexion réseau,pas besoin d'envoyer CONNACK rapport

texte [MQTT-3.2.2-6]。

3.2.3 payload

CONNACK messageaucunecharge utile valide.

3.3 PUBLISH – publier un message

PUBLISH contrôlepaquet fait référence à depuis le clientdu client au serveurou du serveur au clienttransmettre une applicationmessage.

3.3.1 en-tête fixe

légende 3.10 – PUBLISH rapporten-tête fixe du paquetdécrit l'en-tête fixeformat d'en-tête

légende 3.10 – PUBLISH en-tête fixe du paquet

Bit

octet 1

MQTT paquet de contrôletype de message (3)

DUP

QoS niveau

RETAIN

octet 2

longueur restante

3.3.1.1 drapeau de retransmissionwill

position :N° 1 octet, les 3 bits

si DUP drapeau est défini à 0, indiquant qu'il s'agit d'un client ou serveurpremière requête du serveurdemande d'envoyer ce PUBLISH paquet.si DUP drapeaux

est défini à 1, tableauindiquant qu'il peut s'agir d'uneune requête de paquet antérieureretransmission de la requête.

client ou serveurdemande de renvoyer un PUBLISH lorsque le message,Requiswill DUP marquedrapeau est défini à 1 [MQTT-3.3.1.-1].. Pour QoS

0 le message,DUP DrapeauxRequisDéfini à 0 [MQTT-3.3.1-2]。

le serveur envoie PUBLISH messageà l'abonnélorsque,reçude (entrant) PUBLISH du paquet DUP valeur du drapeaune sera pas propagé.émettre

envoyé (sortant) PUBLISH messageet reçude (entrant) PUBLISH dans le paquet DUP l'indicateur est indépendantdéfini indépendamment,sa valeurRequis

individuellement selon l'envoide (sortant) PUBLISH messages'il s'agit d'une retransmissionenvoyé pour déterminer [MQTT-3.3.1-3]。

non normatifcommentaire

le récepteur reçoit un DUP drapeau est 1 depaquet de contrôle,ne peut pas supposer qu'il voitcelui qui précède ce paquetun doublon de.

non normatifcommentaire

Ce qu'il faut souligner spécifiquement, c'estest,DUP marquele journal se concentre sur le contrôlele paquet de contrôle lui-même,avec le message applicatif qu'il contientnon pertinent. Lors de l'utilisation de QoS 1

lorsque,Un client pourrait recevoir un DUP drapeau est 0 de PUBLISH paquet,Cepaquet contient unUn qu'il avait précédemment reçu

une copie du message d'application, mais celui utilisé estun identifiant de paquet différentidentifiant. 2.3.1 la section fournit quelquesconcernant l'identifiant de paquetplus d'informations.

MQTT-3.1.1-CN 31

3.3.1.2 qualité de serviceniveau

position :n° 1 octet, le 2-1 bit.

Ce champ indique le message d'applicationpour la distribution des messagesgarantie du niveau de qualité de service.qualité de serviceniveau de qualité dans Tableau 3.2 -définition de la qualité de service répertoriée dansdehors.

Tableau 3.2 -Qualité de servicedéfinition

QoS Valeur

Bit 2

Bit 1

Description

au plus une fois

au moins une fois

livrer une seule fois

bit réservé

PUBLISH messagene peut passera QoS lieucertains bits sont définis à 1。siserveur ou clientclienta reçu QoS Tous les bits sont 1 de PUBLISH

paquet, ilest nécessaire defermer la connexion réseauJie [MQTT-3.3.1-4]。

3.3.1.3 drapeau retaintestament

position :n° 1 octet, le 0 bit.

Si le client envoie auserveur un PUBLISH du paquetretain (RETAIN）le drapeau est définiest 1, le serveurRequisstocker ce message applicatif

information etildeServicesqualitéattenteniveau（QoS）, afin deappropriéilOuiPardistribuerà ne pas encorevenirdeprincipaltitrecorrespondattribués'abonnerlecteur [MQTT-3.3.1-5]。a

NouveauAbonnementconstruireimmédiatement, pourchaquecorrespondancedesujetnom，sistockerDansrécentprotégerrestantéliminermessage,ilObligatoireest envoyéenvoyer àCes'abonnerlecteur [MQTT-

3.3.1-6]. Si le Serveurle client reçoit un message conservé（RETAIN) le drapeau est 1 de QoS 0 message,ilObligatoiresupprimerprécédemment pour ce sujetsujet Retain

d'un message quelconque. Ildevraitvaun nouveau QoS 0 message comme ce sujetun nouveau message conservé sur le sujet, maisà tout momentOuichoisit de le supprimer

— siLorsque cela se produit, cesujet n'aura pas de message conservémessage conservé [MQTT-3.3.1-7]。lié à l'état de stockagePour plus d'informations, voir 4.1 section.

côté serveurenvoyer PUBLISH message àlorsque le client, par ex.si le message est en tant que clientun nouveaule résultat d'abonnement est envoyéenvoyer, ilObligatoirele Retain du paquet

Drapeau Retain défini à 1 [MQTT-3.3.1-8]. Lorsqu'un PUBLISH rapporttexte envoyéenvoyé au client car il correspondattribuer un déjà établilorsque l'abonnement, le serveur

serveurRequisDéfinir le drapeau Retain à 0, indépendamment de celale message reçudans le messageretainQuelle est la valeur du drapeau [MQTT-3.3.1-9]。

retainle drapeau est 1 et validela charge utile est de zéro octetde PUBLISH rapportle message serale serveur le traite comme un message normaltraitement, il seraenvoyé vers le sujet souscrit

correspondantclientfin。en outre，mêmeaprincipalsujetBastoutprésentstockerderetainéliminersouffleRequisPardéplacerdiviser，Par conséquent这élémentssujetdeaprèsdetouts'abonnerliretout

ne recevra pasà unmessage retenu [MQTT-3.3.1-10]。

traité comme normal

Cela signifieexistantle Client reçoitdu messageMoyenl'indicateur Retain n'est pasest défini。

Côté serveurne peut passtocker un message de zéro octetretenu [MQTT-3.3.1-11]。

Si le client envoie auserveur PUBLISH du paquetbit d'indicateur Retain 0，Côté serveurne peut passtocker ce messagenon plusne peut passupprimer ou remplacer aucun

messages retenus existants [MQTT-3.3.1-12]。

non normatifcommentaire

non déterminé pour l'éditeurenvoyer périodiquement des messages d'étatmessage, dans ce scénario,les messages retenus sont trèsutiles. Les nouveaux abonnementsl'abonné recevra l'état le plus récentétat.

longueur restantechamp de longueur

est égal àLa longueur de l'en-tête variable plus la charge utilela longueur de la charge utile.

MQTT-3.1.1-CN 32

3.3.2 en-tête variable

En-tête variable dans l'ordrecontienttopicNom et identifiant de paquet.

3.3.2.1 nom du topic

nom du sujet (TNom du sujet) utilisé pouridentifier la charge utileoù les données doivent être publiéesun canal d'information。

nom du sujetObligatoireOui PUBLISH rapporten-tête variableLe premier champ de l'en-tête.ilObligatoireOui 1.5.3 sectiondéfinie UTF-8 encoded string

[MQTT-3.3.2-1]。

PUBLISH messageNom de rubrique dans lene peut pascontenir un caractère génériquecorrespondant [MQTT-3.3.2-2]。

Le serveur envoie à l'abonnédu Client abonné PUBLISH messagenom de rubriqueRequiscorrespondrele sujet de l'abonnementfiltre (selon 4.7 la correspondance définie dans la section

traiter）[MQTT-3.3.2-3]。

3.3.2.2 identifiant de paquetidentifiant

uniquement lorsque QoS waitniveau est 1 ou 2 lorsque, identifiant de paquet（Identifiant de paquet) champne peut apparaître que dans PUBLISH dans le paquet.2.3.1

La section fournit des informations sur le paquetmise à jour de l'identifiant de paquetplus d'informations.

3.3.2.3 en-tête variableen-tête non normatifExemple

légende 3.11 – PUBLISH rapportEn-tête variable du paquetExemple non normatif illustre Tableau 3.3 - PUBLISH rapportexemple non normatif décrit brièvement

décrit PUBLISH l'en-tête variable du paqueten-tête.

Tableau 3.3 - PUBLISH Exemple non normatif du message

Champ

Valeur

nom du topic

a/b

identifiant de paquet

légende 3.11 – PUBLISH en-tête variable du paquetExemple non normatif

Description

Nom du sujete nom du sujet

octet 1

Longueur MSB (0)

octet 2

Longueur LSB (3)

octet 3

‘a’ (0x61)

octet 4

‘/’ (0x2F)

octet 5

‘b’ (0x62)

identifiant de paquet

byte 6

identifiant de paquet MSB (0)

byte 7

identifiant de paquet LSB (10)

MQTT-3.1.1-CN 33

Le nom du sujet dans l'exempleest “a/b”，longueurest égale à 3, l'identifiant de paquet est “10”

3.3.3 payload

La charge utile contiendralemessage d'application publié. Lecontenu et le format des données sontspécifiques à l'application.la longueur de la charge utileest calculé comme suit :avec fixe

la longueur restante dans l'en-têtela valeur du champ Length moinssoustrayez la longueur de l'en-tête variable.contient zérolongueur de la charge utilede PUBLISH signalerque le paquet est valide.

3.3.4 response

PUBLISH messagele récepteurRequisselonSelon PUBLISH dans le paquet QoS niveau QoS pour envoyer une réponse, voir le tableau ci-dessousdescription du format [MQTT-

3.3.4-1]。

Tableau 3.4 – PUBLISH la réponse de paquetattendue

niveau de qualité de service

réponse attendue

QoS 0

aucune réponse

QoS 1

PUBACK message

QoS 2

PUBREC message

3.3.5 action

le Client utilise PUBLISH le paquet envoie un messaged'application au serveur, afin de distribuerà d'autres abonnements correspondantsclients correspondants.

le Serveur utilise PUBLISH le paquet envoie un messaged'application à chaqueabonnementcorrespondantle client.

Le client utilise unfiltre de sujet générique passe-bandelorsque le filtre demande un abonnement, le clientl'abonnement du client peutpeut être répété，Par conséquentles messages publiés peuvent correspondre à plusieurs

un filtre. PourDans ce cas, le serveurserveurRequisdélivre le message àtous les abonnements correspondantsattribué QoS attendrele client de plus haut niveau [MQTT-3.3.5-

1]. Du serveurpuis selon l'abonnementde QoS niveau, la distribution du messageune copie à chaqueabonné correspondant。

recevoir un PUBLISH rapportquand le message,l'action du récepteurdépend de 4.3 sectiondécrite QoS attenteniveau.

siL'implémentation du serveur n'autorise pas un clientle client publie PUBLISH paquet,il n'a aucun moyen de le notifierClient. IlRequisselon normalnormal

QoS règle d'envoienvoyer unaccusé de réception positif, oufermer la connexion réseau [MQTT-3.3.5-2]。

3.4 PUBACK –émettreaccusé de réception de publication

PUBACK messageest correct QoS 1 niveaude PUBLISH rapportréponse au paquet。

3.4.1 en-tête fixe

légende 3.12 - PUBACK rapporttexte fixemessage déterminéhead

Bit

octet 1

MQTT paquet de contrôletype de message (4)

bit réservé

MQTT-3.1.1-CN 34

octet 2

longueur restante(2)

longueur restantechamp de longueur

indiquant la longueurde l'en-tête variable. Pour PUBACK messagecette valeur est égale à 2.

3.4.2 en-tête variable

contient ceux en attente d'accusé de réception PUBLISH le paquet du messageIdentifiant de paquet.

légende 3.13 – PUBACK en-tête variable du paquet

Bit

octet 1

identifiant de paquet MSB

octet 2

identifiant de paquet LSB

3.4.3 payload

PUBACK messageaucune charge utile。

3.4.4 action

voir la description complète dans 4.3.2 section.

3.5 PUBREC – publicationreçue (QoS 2, étape 1)

PUBREC signale quele message est correct QoS niveau 2 de PUBLISH signalela réponse au message. Il s'agit de QoS 2 échange de protocole QoSle deuxième message de l'échangetexte.

3.5.1 en-tête fixe

légende 3.14 – PUBREC en-tête de messagefixe

Bit

octet 1

MQTT paquet de contrôletype de message e (5)

bit réservé

octet 2

longueur restante (2)

longueur restantechamp de longueur

indiquant la longueur de l'en-tête variable. Pour PUBREC signalela valeur du messageest égale 2。

3.5.2 en-tête variable

l'en-tête variable contient etc.accusé de réception en attente PUBLISH signalel'identifiant de paquet du paquetidentifiant.

MQTT-3.1.1-CN 35

légende 3.15 – PUBREC en-tête de messagevariable

Bit

octet 1

identifiant de paquet MSB

octet 2

identifiant de paquet LSB

3.5.3 payload

PUBREC signaleque le message n'a pas de charge utile。

3.5.4 action

voir la description complète dans 4.3.3 section.

3.6 PUBREL – publicationlibération (QoS 2, Étape 2)

PUBREL messageest correct PUBREC la réponse au message.C'est QoS 2 attentede l'échange au niveau du protocolele troisième message.

3.6.1 en-tête fixe

légende 3.16 – PUBREL en-tête fixe du paquet

Bit

octet 1

MQTT paquet de contrôletype de message (6)

bit réservé

octet 2

longueur restante (2)

PUBREL contrôleEn-tête fixe du paquetle premier 3,2,1,0 bit de l'en-tête est le bit Retain，Obligatoireest défini à 0,0,1,0. ServicefinObligatoiretoute autre valeur

sont tous traités comme illégauxet ferment laconnexion réseau [MQTT-3.6.1-1]。

longueur restantechamp de longueur

indiquant lalongueur de l'en-tête variable. Pour PUBREL rapportla valeur de Packet est égale àdans 2.

3.6.2 en-tête variable

l'en-tête variable contient eten attente d'accusé de réception PUBREC messagele même identifiant de messageidentifiant.

légende 3.17 – PUBREL en-tête variable du paquet

Bit

octet 1

identifiant de paquet MSB

octet 2

identifiant de paquet LSB

MQTT-3.1.1-CN 36

3.6.3 payload

PUBREL messagen'a pas de Payloadcharge utile.

3.6.4 action

voir la description complète dans 4.3.3 section.

3.7 PUBCOMP – Publication terminée (QoS 2, étape 3)

PUBCOMP signalele message est correct PUBREL signalela réponse au paquet. C'est le QoS 2 niveaude l'échange de protocolequatrième et dernierun paquet.

3.7.1 en-tête fixe

légende 3.18 – PUBCOMP message fixeen-tête fixe

Bit

octet 1

MQTT paquet de contrôletype de message (7)

bit réservé

octet 2

longueur restante (2)

longueur restantechamp de longueur

indiquant la longueur de l'en-tête variable. Pour PUBCOMP signalece texteune valeur égale 2。

3.7.2 en-tête variable

l'en-tête variable contient eten attente d'accusé de réception PUBREL messagele même paquetidentifiant.

légende 3.19 – PUBCOMP Le message peuten-tête variable

Bit

octet 1

identifiant de paquet MSB

octet 2

identifiant de paquet LSB

3.7.3 payload

PUBCOMP signalele message n'a pas decharge utile.

3.7.4 action

voir la description complète dans 4.3.3 section.

MQTT-3.1.1-CN 37

3.8 SUBSCRIBE - sujet d'abonnement

client vers serveurenvoyer SUBSCRIBE message utilisé pourcréer un ou plusieursabonnements. Chaquel'abonnement enregistre le clientun sujet qui intéresse le clientou plusieurs

sujet. Afin detransmettre le message àcorrespondant à ces abonnementssujet correspondant, le serveurle serveur envoie PUBLISH rapportPaquet vers le client。SUBSCRIBE

le message aussi (pour chaquel'abonnement) spécifiemaximum QoS attenteniveau, le Serveurenvoyer en fonction de celatransmettre le message d'application au client.

3.8.1 en-tête fixe

légende 3.20 – SUBSCRIBE message fixeen-tête fixe

Bit

octet 1

MQTT paquet de contrôletype de message (8)

bit réservé

octet 2

longueur restante

SUBSCRIBE contrôleen-tête fixe du paquet de contrôledes 3,2,1,0 bitsest conservébit,Requisrespectivement défini à 0,0,1,0. ServeurRequistout autre

toute valeur est traitée comme nonvalide et fermerConnexion réseau [MQTT-3.8.1-1]。

longueur restantechamp de longueur

est égal àLa longueur de l'en-tête variable (2 octet) plus la charge utilelongueur de la charge utile.

3.8.2 en-tête variable

l'en-tête variable contient le clientidentifiant client.2.3.1 Fournirsur le PaquetPlus d'informations sur les identifiants.。

3.8.2.1 en-tête variableen-tête non normatifExemple

légende 3.21 – identifiant de paquetest égal à 10 de l'en-tête variable, un exemple non normatifExemple montre le messagel'identifiant de message est défini à 10 En-tête variable quand

en-tête.

légende 3.21 – messageidentifiantidentifiant égal à 10 peut êtremessage variableen-tête, exemple non normatifExemple

Description

identifiant de paquet

octet 1

identifiant de paquet MSB (0)

octet 2

identifiant de paquet LSB (10)

3.8.3 payload

SUBSCRIBE du paquetcharge utilecontient un sujetliste de filtres de sujets,ils représentent le clientles sujets auxquels le client veut s'abonner。SUBSCRIBE

messageFiltre de sujets dans la charge utileListeObligatoireOui 1.5.3 sectiondéfini UTF-8 String [MQTT-3.8.3-1]. serviceserveurdevraitPris en charge

contient un caractère générique (4.7.1 la section spécifiela signification) dufiltre de sujets. Sisi le serveur choisit de ne pas prendre en chargecontenant des caractères génériquesfiltre de sujets,ObligatoireRejeter

tout filtre contenant des caractères génériquesl'abonnement du filtrerequête [MQTT-3.8.3-2]。Après chaque filtresuivi d'un octet, cet octet estappelé vêtements

exigence de qualité de service (QoS demandée）. Il indique au serveurServeur vers Clientle client envoie un message applicatifautorisé par le messagemaximum QoS niveau.

MQTT-3.1.1-CN 38

SUBSCRIBE du paquetcharge utileRequiscontientau moinsune pairefiltre de sujet et QoS niveaucombinaison de champs.aucune charge utilede

SUBSCRIBE signalerle message est une violation de protocolede [MQTT-3.8.3-3]。concernant la gestion des erreursveuillez consulter les informations sur la gestion 4.8 section.

le service maximum demandéchamp de niveau de qualité de serviceencodé comme un motoctet, après luisuit UTF-8 modifierle nom de sujet du code,ces filtres de sujet /et

QoS combinaison de niveauxsont regroupées consécutivement.

légende 3.22 – SUBSCRIBE messagecharge utileFormatage

Description

Filtre de sujet

octet 1

longueur MSB

octet 2

longueur LSB

octets 3..N

filtre de sujet（Filtre de sujet）

exigences de qualité de service (Requested QoS）

bit réservé

niveau de qualité de service

octet N+1

la version actuelle du protocolen'a pas utilisé le serviceexigence QoS (Requested QoS）les six bits de poids fort de l'octet. Si la charge utiletout dans la charge utilebit est non-

valeur zéro,ou QoS Différent de 0,1 ou 2, le serveurRequisconsidérer SUBSCRIBE le paquet estunion invalidefermer la connexion réseau [MQTT-

3-8.3-4]。

3.8.3.1 charge utilecharge utile non normativeExemple

légende 3.23 – mot de charge utileformat d'octets non standardexemple affichagedéjà Tableau 3.5 – Ouicharge utile non normativeExemple brièvement décrit dans

SUBSCRIBE signalerla charge utile du paquet。

Tableau 3.5 – charge utilela charge utile n'est pas unexemple normatif

nom du topic

“a/b”

Exigences de qualité de service

0x01

nom du topic

“c/d”

Exigences de qualité de service

0x02

légende 3.23 – validecharge utileformat d'octets non-la spécification montreExemple

Description

Topic Filter (Topic Filter）

octet 1

Longueur MSB (0)

octet 2

Longueur LSB (3)

octet 3

‘a’ (0x61)

MQTT-3.1.1-CN 39

octet 4

‘/’ (0x2F)

octet 5

‘b’ (0x62)

exigences de qualité de service (Requested QoS）

byte 6

QoS demandée(1)

Topic Filter (Topic Filter）

byte 7

Longueur MSB (0)

octet 8

Longueur LSB (3)

octet 9

‘c’ (0x63)

octet 10

‘/’ (0x2F)

octet 11

‘d’ (0x64)

exigences de qualité de service (Requested QoS）

QoS demandée(2)

le serveur reçoit le client

3.8.4 response

octet 12one sent by the endpoint SUBSCRIBE when the message,RequiredUsage SUBACK réponse de paquet [MQTT-3.8.4-1]。

SUBACK messageRequiset en attente d'accusé de réception SUBSCRIBE messageont le même identificateur de paquetsymbole [MQTT-3.8.4-2]。

permet au serveur d'envoyerenvoyer SUBACK rapportavant le messagepuis commencer à envoyer et à s'abonnercorrespondant PUBLISH paquet.

Si le serveur reçoita SUBSCRIBE paquet, paquetLe filtre de sujets d'un abonnement existantcorrespondant au filtre de sujetidentique,puisRequis

utiliser le nouvel abonnement pour complètementremplacer l'abonnement existant. Les sujets du nouvel abonnementle filtre et le précédentsont identiques à l'abonnement,mais illa valeur maximale QoS Valeurne peut pas

identique.Cela correspond à ce filtre de sujettout message conservé existantmessage conservéRequisest retransmis,mais le flux de publicationne peut pasMoyeninterrompre [MQTT-3.8.4-3]。

si le filtre de sujetdifférent de tout filtre d'abonnement stocké existant, le serveurle serveur créera unnouvel abonnement et enverra toutmessage conservé correspondant.

Si le serveur reçoitcontenant plusieurs sujetsdu filtre SUBSCRIBE paquet,ilRequiscomme s'il avait reçu une sériede multiples SUBSCRIBE

traiter le message de la même manière, puisun,saufdoivent combiner leurs réponsesfusionnées en un seulindépendant SUBACK messageenvoyer [MQTT-3.8.4-4]。

le serveur envoie au clientdu client SUBACK rapportpaire de textechaque paire de filtres de sujets et QoS attendretous les niveauxRequiscontient un code de retour.Ceretour

codeRequisindique que l'abonnement est accordé avec leniveau maximal accordé de QoS ,ouindique que cet abonnement a échoué [MQTT-3.8.4-5]. Le serveur peutaccorder que

inférieur à l'exigence de l'abonnéune partie de QoS niveau.envoyé en réponse à l'abonnementdu message envoyéde la charge utile QoS Requisest celle du message publié d'origine

QoS et le serviceaccordé par le point de terminaison QoS des deuxvaleur minimale. Si le message d'origineinformations QoS Oui 1 et le maximum accordé QoS Oui 0, autoriserautoriser le serveur

Le serveur renvoie unune copie du messageà l'abonné [MQTT-3.8.4-6]。

non normatifExemple

pour un sujet particulierfiltre de sujet,siactuellement abonnéle client se voit accorderle maximum QoS niveau d'attenteest 1, alorscorrespondant à ce filtre

du filtre QoS niveau 0 le message d'application sera selon QoS niveau 0 livré à ce client.cela signifie que le clientle client recevra au plus ce

MQTT-3.1.1-CN 40

une copie du message. En revanche,c'est-à-dire, publier sur le mêmed'un sujet QoS niveau 2 du messagesera rétrogradé par le serveur à QoS attente

niveau 1 redistribuer àclient, par conséquent le clientle client peut recevoirdes messages en doublecopie.

Si l'abonné actuelle client se voit accorderle maximum QoS niveau est 0, alorsà l'origine par QoS niveau 2 publié versapplication cliente

le message peut, en cas d'occupation,peut être perdu,Maisle serveur ne doit pasdoit envoyer une copie en doubledu message. Publier vers le mêmed'un sujet QoS niveau

1 message en transitlors de la livraison au client peutpeut être perdu ou dupliqué.

non normatifcommentaire

Utilisation QoS niveau 2 s'abonnerS'abonner à un filtre de sujet égal àc'est-à-dire :

Je veux publier en fonction de leurtemps

QoS

niveau accepte correspondant à ceséléments

le message du filtre

. Cela signifie,déterminerpossible lors de la livraison du messagemaximum QoS attenteniveau est la responsabilité de l'éditeur, etl'abonné peut

exige que le serveur réduise QoS à un niveau plus appropriécorrespondant à son niveau.

3.9 SUBACK – accusé de réception d'abonnement

le serveur envoie SUBACK paquet au client, utilisé pour accuser réception qu'ila reçu et esten cours de traitement SUBSCRIBE paquet.

SUBACK messagecontient une liste de codes de retour, ilsspécifient SUBSCRIBE veuillezde la requêtechaque abonnement estle maximum accordé QoS attenteniveau.

3.9.1 en-tête fixe

légende 3.24 – SUBACK en-tête fixe du paquet

Bit

octet 1

MQTT paquet de contrôletype de message (9)

bit réservé

octet 2

longueur restante

longueur restantechamp de longueur

égal à la longueur de l'en-tête variableplus la charge utilela longueur de la charge utile.

3.9.2 en-tête variable

l'en-tête variable contient etc.accusé de réception en attente SUBSCRIBE rapportdu texteidentifiant de paquet.légende 3.25 – SUBACK rapporten-tête variable du paquet décrit les possibles

le format de l'en-tête variable.

légende 3.25 – SUBACK en-tête variable du paquet

Bit

octet 1

identifiant de paquet MSB

octet 2

identifiant de paquet LSB

MQTT-3.1.1-CN 41

3.9.3 payload

la charge utile contient unune liste de codes de retour. Chaque code de retourcorrespond à un accusé de réception en attentede SUBSCRIBE l'un des paquetsun filtre de sujet. Retour

ordre des codesRequiset SUBSCRIBE messagedans l'ordre des filtres de sujetmême [MQTT-3.9.3-1]。

légende 3.26 – SUBACK rapportcharge utile du paquetFormatage décritdans la charge utile un seuloctetcodé pour lechamp de code de retour.

légende 3.26 – SUBACK format de la charge utile du paquet

Bit

code de retour

octet 1

Valeurs de code de retour autorisées：

0x00 - maximum QoS 0

0x01 - succès – maximum QoS 1

0x02 - succès – maximum QoS 2

0x80 - Échec échec

0x00, 0x01, 0x02, 0x80 en dehorsde SUBACK retourle code de retour est réservéde,ne peut pasUtilisation [MQTT-3.9.3-2]。

3.9.3.1 charge utilecharge utile non normativeExemple

légende 3.27 -charge utileexemple non normatif de format d'octets apparaît dans Tableau 3.6 -Ouiexemple non normatif de charge utile brièvement décrit

SUBACK messagede la charge utile.

Tableau 3.6 -charge utilenon normatifExemple

Succès - Maximum QoS 0

Succès - Maximum QoS 2

Failure

128

légende 3.27 -charge utileformat d'octetsExemple non normatif

Description

octet 1

Succès - Maximum QoS 0

octet 2

Succès - Maximum QoS 2

octet 3

Failure

3.10 UNSUBSCRIBE –Annuler l'abonnement

le client envoie UNSUBSCRIBE messageau serveur,utilisé pour se désabonnerdu sujet d'abonnement.

MQTT-3.1.1-CN 42

3.10.1 en-tête fixe

légende 3.28 – UNSUBSCRIBE en-tête fixe du paquet

Bit

octet 1

MQTT type de paquet de contrôle (10)

bit réservé

octet 2

longueur restante

UNSUBSCRIBE rapporttexte fixele bit de l'en-tête fixe 3,2,1,0 est à maintenirLe bit réservé etRequisdéfini séparémentest 0,0,1,0。côté serveurRequisconsidère toutses

ses valeurs sont toutes invalideslégales et ferme le réseauconnexion réseau [MQTT-3.10.1-1]。

longueur restantechamp de longueur

égal à la longueur de l'en-tête variableplus la charge utilela longueur de la charge utile.

3.10.2 en-tête variable

L'en-tête variable contient unun identifiant de paquet。2.3.1 sectionfournit des informations surplus d'informations sur les identifiants de paquetinformations.

légende 3.29 – UNSUBSCRIBE en-tête variable du paquet

Bit

octet 1

identifiant de paquet MSB

octet 2

identifiant de paquet LSB

3.10.3 payload

UNSUBSCRIBE du paquetvalidela charge utile contient, pour le client,les sujets dont le client veut se désabonnerliste de filtres de sujets。UNSUBSCRIBE dans le paquet

sujetFiltreRequisest compacté de manière contiguë,selon 1.5.3 ce que spécifie la sectionsémantique UTF-8 éditionchaîne de code [MQTT-3.10.3-1]。

UNSUBSCRIBE du paquetvalidecharge utileRequisau moinscontientun filtre de messages. Aucune charge utilede la charge utile UNSUBSCRIBE le paquet est

violant le protocole [MQTT-3.10.3-2]. Il y aPlus d'informations sur la gestion des erreursveuillez consulter 4.8 section.

3.10.3.1 charge utile non conformeportéeExemple

légende 3.30 -charge utileFormat d'octets non normatifExemple montre Tableau 3.7 -valideExemple de charge utile non normatif brièvement décrit

UNSUBSCRIBE du paquetvalidecharge utile.

Tableau 3.7 -charge utileexemple non normatifExemple

Filtre de sujet

“a/b”

Filtre de sujet

“c/d”

MQTT-3.1.1-CN 43

légende 3.30 -charge utileformat d'octetsnon normatifexemple

Description

Filtre de sujet

octet 1

Longueur MSB (0)

octet 2

Longueur LSB (3)

octet 3

‘a’ (0x61)

octet 4

‘/’ (0x2F)

octet 5

‘b’ (0x62)

Filtre de sujet

byte 6

Longueur MSB (0)

byte 7

Longueur LSB (3)

octet 8

‘c’ (0x63)

octet 9

‘/’ (0x2F)

octet 10

‘d’ (0x64)

3.10.4 response

UNSUBSCRIBE rapportmention textuellefiltre de sujet fourni (que celui-ci contienne ou noncaractère générique）Obligatoireavec ceci détenu par le serveuractuel du clientprincipal

filtre de sujet défini un par unune comparaison de caractères.si un filtre complètementcorrespondance exacte,alors il (le serveurserveur) son propreL'abonnement sera supprimé,Sinon

il n'y aura plus detraitement [MQTT-3.10.4-1]。

Si le serveur supprimeun abonnement :

 ilObligatoirecesser de distribuer tout nouveau messagemessage à ce clientclient [MQTT-3.10.4-2]。

 ilObligatoireachever la livraison de tout message déjàcommence à envoyer au clientenvoyé par le point de terminaison QoS 1 et QoS 2 du message [MQTT-3.10.4-3]。

 ilOuicontinuer d'envoyer tout message existanten préparation de distributionvers le tampon du clientstocker le message.

Côté serveurObligatoireenvoyer UNSUBACK paquet de réponsedu client UNSUBSCRIBE requête.UNSUBACK messageObligatoirecontient et

UNSUBSCRIBE rapportphase de textele même identifiant de paquet [MQTT-3.10.4-4]。même sin'a supprimé aucunaucun abonnement à un sujet,le serveur doit aussiobligatoirementémettre

envoyer une SUBACK réponse [MQTT-3.10.4-5]。

Si le serveur reçoitcontenant plusieurs sujetsdu filtre UNSUBSCRIBE paquet,ilObligatoirecomme s'il avait reçu une série demultiples

UNSUBSCRIBE rapportun textetraiter ce paquet de la même manière,en outrefusionner leurs réponses en une seuleun UNSUBACK séparé en dehors du message.

[MQTT-3.10.4-6]。

3.11 UNSUBACK – Annulation d'abonnementaccusé de réception

le serveur envoie UNSUBACK messageau client pour confirmer la réceptionà UNSUBSCRIBE paquet.

MQTT-3.1.1-CN 44

3.11.1 en-tête fixe

légende 3.31 – UNSUBACK message fixeen-tête fixe

Bit

octet 1

MQTT paquet de contrôletype de message (11)

bit réservé

octet 2

longueur restante (2)

longueur restantechamp de longueur

indiquant la longueur de l'en-tête variable, pour UNSUBACK ce messageune valeur égale 2。

3.11.2 en-tête variable

l'en-tête variable contient etc.accusé de réception en attente UNSUBSCRIBE messagel'identifiant de paquet.

légende 3.32 – UNSUBACK Le message peuten-tête variable

Bit

octet 1

identifiant de paquet MSB

octet 2

identifiant de paquet LSB

3.11.3 payload

UNSUBACK le message n'a pas decharge utile。

3.12 PINGREQ – requête de battement de cœur

le client envoie PINGREQ messageau serveur. Utilisezà :

1. en l'absence de tout autrepaquet de contrôle du clientlorsque le client envoie au serveur,informer le serveur que le clientle client est actif.

2. demander au serveur d'envoyer la réponse confirme qu'il est toujoursactif.

3. utiliser le réseau pour accuser réceptionla connexion réseau n'a pasde déconnexion.

Keep Alive (Keep Alive）traitementutilisé dansce paquet,détaillépour information, voir 3.1.2.10 la section.

3.12.1 en-tête fixe

légende 3.33 – PINGREQ en-tête fixe du paquet

Bit

octet 1

MQTT type de paquet de contrôle (12)

bit réservé

MQTT-3.1.1-CN 45

octet 2

longueur restante (0)

3.12.2 en-tête variable

PINGREQ rapportLe message n'a pas d'en-tête variable。

3.12.3 payload

PINGREQ rapportle message n'a pas de charge utile。

3.12.4 response

Côté serveurRequisenvoyer PINGRESP paquet de réponsedu client PINGREQ message [MQTT-3.12.4-1]。

3.13 PINGRESP – réponse de battement de cœur

le serveur envoie PINGRESP le paquet répond au clientdu client PINGREQ paquet.Représentele serveur est toujours en vie-ing.

Keep Alive (Keep Alive）traitementutilisé dansce paquet,détailsveuillez consulter 3.1.2.10 section.

3.13.1 en-tête fixe

légende 3.34 – PINGRESP message fixeen-tête fixe

Bit

octet 1

MQTT type de paquet de contrôle (13)

bit réservé

octet 2

longueur restante (0)

3.13.2 en-tête variable

PINGRESP messagepas d'en-tête variableen-tête.

3.13.3 payload

PINGRESP messagen'a pas de charge utilecharge utile.

3.14 DISCONNECT –déconnexion

DISCONNECT le paquet est envoyé du client au serveurdernier du serveurun paquet de contrôle.indique que le client s'est déconnecté normalementconnexion.

MQTT-3.1.1-CN 46

3.14.1 en-tête fixe

légende 3.35 – DISCONNECT messageen-tête fixe

Bit

octet 1

MQTT type de paquet de contrôle (14)

bit réservé

octet 2

longueur restante (0)

Côté serveurObligatoirevérifier tous les retenusles bits réservés sont tous définisdéfinis à 0, siils ne sont pas 0 Obligatoiredéconnecter [MQTT-3.14.1-1]。

3.14.2 en-tête variable

DISCONNECT Le paquet n'a pas d'en-tête variable.

3.14.3 payload

DISCONNECT le paquet n'a pas de charge utilecharge utile.

3.14.4 response

le client envoie DISCONNECT rapportaprès le message :

 Obligatoirefermer la connexion réseau [MQTT-3.14.4-1]。

 ne peut pasvia cette connexion réseau à nouveauenvoyer tout paquet de contrôlepaquet de contrôle [MQTT-3.14.4-2]。

le serveur à la réception de DISCONNECT lors de l'envoi d'un message :

 Obligatoiresupprimer tout élément associé à la connexion actuelleassocié non envoyépubliéseramessage, voir la description spécifique 3.1.2.5 section [MQTT-3.14.4-3]。

 devraitFermer la connexion réseau,si le client ne l'a pas encore fait.

MQTT-3.1.1-CN 47

4 comportement opérationnel

4.1 stockage d'état

Pour fournir une qualité de servicegarantie QoS, le clientle client et le serveur disposent dunécessaire pour stocker l'état de lasession. Tout au long de la sessionentre, le clientclient et serveurtousObligatoire

conserver l'état de session [MQTT-4.1.0-1]. SessionObligatoiredure au moins aussi longtemps que son réseau actifconnexion réseau d'égale duréedurée de [MQTT-4.1.0-2]。

le message retenu du serveurle message ne fait pas partie de l'état de sessionpartie de l'état. Le serveurdevraitconserver ce type de messagemessage jusqu'à ce que le client le supprime.

non normatifcommentaire

client et serveurstockage de l'implémentationCapaciténécessairement limitéede, peut également devoirêtre soumise à la politique de gestionrestrictions, telles qu'à traversla session de connexion réseau

le stockage maximal de l'état de sessiondurée de stockage. déjà conservéétat de session stockéLa perte peut être d'une certaine ampleurcausée par une opération de gestion,par exemple, pourun élément prédéfini

réponse automatique.les conséquences qu'elle entraîneest la terminaison de session. Ces opérations peuventêtre des contraintes de ressourcesou être causées par d'autres raisons opérationnellesde. Il faut

Il faut évaluer attentivement le clientclient et serveurde la capacité de stockage,pour garantir que l'espace de stockagele temps est suffisant.

non normatifcommentaire

client ou serveurde défaillances logicielles et matériellespeuvent toutes entraîner l'état de session versde perte ou corruption。

non normatifcommentaire

serveur et clientfonctionnement normal peutsignifier que l'état sauvegardéperte ou corruption d'étatest des opérations de gestion ou logiciel/matérielcausées par des défaillances.

les opérations administratives peuvent êtrepour une prédéfinieréponse automatique à des conditions. Cecertaines opérations peuvent êtredes limitations de ressources ou d'autres opérationsdéclenché par la raison.

par exemple, le serveur peutpeut être basé sur desconditions externes, décider de ne pasrenvoyer un certain messageou certains messages distribués à n'importe queltout actuel ouaprès le client

client.

non normatifcommentaire

MQTT l'utilisateur devraitdevrait évaluer MQTT les implémentations client et serveurde la capacité de stockage,s'assurer qu'il peut satisfaire le besoinrequête.

4.1.1 Exemple non normatif

par exemple, si vous voulez collecterl'utilisation des relevés de compteursl'utilisateur peut décider d'utiliser QoS 1 niveaule message, car ils ne peuvent pasréception de données sur le réseauchemin de transmission réseau

perdu dans ..., mais,Ils peuvent penserdonnées client et serveurles données peuvent être stockées dansmémoire (mémoire volatile), parce que (ils pensent

l'alimentation électrique esttrès fiable,ne présentera pas un trop grandrisque de perte de données.

en revanche, les applications de stationnementde facturation et de paiementle fournisseur peut décider que touteen aucun caspeut entraîner la perte de messages de livraison de donnéesperte,Par conséquentils exigent que

transmises sur le réseauavant, toutes les donnéesles données doivent être écrites surun stockage non volatildispositif (comme un disque dur）。

4.2 Connexion réseau

MQTT le protocole nécessiteexige que la couche de transport sous-jacentepuisse fournirordonné, fiablede,bidirectionneltransport (du client versle côté serveur et duserveur vers le client

flux d'octets du point de terminaison).

non normatifcommentaire

MQTT 3.1 utilisele protocole de couche de transport utiliséOui [RFC793] défini TCP/IP coopérerdiscussion.le protocole suivant prend égalementen charge :

MQTT-3.1.1-CN 48

 TLS Protocole [RFC5246]

 WebSocket Protocole [RFC6455]

non normatifcommentaire

TCP port 8883 et 1883 déjà dans IANA Remarqueenregistrement, respectivement utilisés pour MQTT de TLS et non- TLS communication.

transmission réseau sans connexionprotocole de transport tel que UDP Ouinon pris en charge,car ils peuventpeuvent perdre des donnéespaquet ou réordonner les paquets de données。

4.3 Niveau de qualité de service et flux de protocole

MQTT selon ceservice défini dansqualité de service (QoS) niveau de distribution d'applicationMessage. Distributionle protocole est symétrique, dans ce qui suitdans la description ci-dessus,client

et le serveur peuvent tous deuxl'expéditeur peut aussiIl est déjà le récepteur.Le protocole de distribution se concentre surest d'un seul expéditeur versun seul récepteurMessage d'application.vêtements

serveurDistribuer les messages d'application à plusieurs clientslorsqu'à la fin, chaque clientle client traite indépendamment. Livré au clientl'application sortante du clientmessages et messages d'application entrants

du QoS niveau peutpeut être différent.

le flux non normatif suivantLe diagramme montre desméthodes d'implémentation possibles.。

4.3.1 QoS 0 :au plus une fois

la livraison des messages dépend dedescapacités du réseau sous-jacent. Le récepteurn'enverra pas de réponse, l'émetteur neréessaiera pas non plus. Le messagepeut être livré une fois ou peut

n'a pas été livré du tout.

pour QoS 0 duprotocole de livraison, l'émetteurémetteur

 Requisenvoyer QoS égal à 0，DUP égal à 0 du PUBLISH message [MQTT-4.3.1-1]。

pour QoS 0 duprotocole de livraison, le récepteurrécepteur

 Accepter PUBLISH lorsqu'un message, recevoir simultanémentrecevoir tout le messagecorrect.

légende 4.1 – QoS 0 flux du protocolediagramme,non normatifExemple

expéditeuraction

paquet de contrôle

récepteuraction

PUBLISH message QoS 0, DUP=0

---------->

livrer les messages applicatifs àdestinataire ultérieur appropriérecevoir

celui/celle(s)

4.3.2 QoS 1: au moinsDiviserenvoyer une fois

vêtementsaffairequalitéquantitéconfirmerprotégeréliminersoufflePourpeuenvoyeratteindreunefois。QoS 1 de PUBLISH rapporttextedepeutchangerrapporten-têteMoyenPaquetcontientunélémentsrapporttextemarquesavoirsymbole，Besoinvouloir

PUBACK messageaccusé de réception.2.3.1 sectionfournit des informations sur les identifiants de paquetplus d'informations sur l'identifiant。

pour QoS 1 deprotocole de livraison, l'expéditeurexpéditeur

 chaque fois qu'un nouveau message d'application est envoyétous les messagesRequisAttribuer un non-l'identifiant de paquet utilisécaractère.

 envoyé PUBLISH messageRequiscontientidentifiant de message et QoS égal à 1，DUP égal à 0。

MQTT-3.1.1-CN 49

 Requisce PUBLISH rapportmessage considéré comme

non acquitté

，jusqu'à ce quereçoive celui correspondant de la part du récepteur PUBACK paquet.4.4 section

il y a une ... à propos des non acquittésdiscussion sur l'accusé de réception des messages。

[MQTT-4.3.2-1].

une fois que l'expéditeur reçoit PUBACK paquet,Cetidentifiant de paquetpeut être réutilisé.

Remarque :Autorisél'expéditeur attend un accusé de réceptionlors de l'utilisation de différentsidentifiant de paquet pour envoyer les suivantsde PUBLISH paquet.

pour QoS 1 duprotocole de livraison, le récepteurrécepteur

 réponse PUBACK messageRequiscontient unidentifiants de message,cet identifiant provient dedu reçu,a déjà accepté tousd'autorité

PUBLISH paquet.

 envoyé PUBACK rapportaprès le message,le récepteur doittout contenant le mêmeidentifiant de paquet entrant PUBLISH messagecomme un

un nouveau message, etignorer son DUP marquevaleur de drapeau.

[MQTT-4.3.2-2].

légende 4.2 – QoS 1 flux de protocolediagramme,non normatifExemple

expéditeuraction

paquet de contrôle

récepteuraction

stocker les messages

envoyer PUBLISH message QoS=1,

DUP=0, avec le messageIdentifiants

---------->

démarrer ...la distribution ultérieure du message d'application

<----------

envoyer PUBACK message, avec unemarque de message

identifiant

rejeter le message

ne nécessite pas que le récepteurenvoie PUBACK avant la distribution complèteenvoie des messages d'application. L'originall'expéditeur reçoit PUBACK messageaprès cela,

tous lesdroits du message d'application seront transférés àce récepteur.

4.3.3 QoS 2 : seulementlivrer une fois

c'est le plus haut niveau dequalité de service,Messageperte et duplicationtous sont inacceptablesde. En utilisant cette qualité de servicele niveau de qualité aura unesurcharge supplémentaire.

QoS 2 d'éliminationdans l'en-tête variable du messagea un identifiant de paquet.2.3.1 sectionfournit des informations surla mise à jour de l'identifiant de paquetplus d'informations.QoS 2 de PUBLISH

le récepteur du paquet utiliseen utilisant un accusé de réception en deux étapesprocessus d'accusé de réception pour confirmer la réception.

pour QoS 2 duprotocole de livraison, l'émetteurémetteur

 doit attribuer au ... à envoyernouvelle distribution de message d'applicationattribuer un identifiant de paquet inutiliséidentifiant.

 envoyerde PUBLISH messageRequiscontientidentifiant de paquet et le QoS du paquet est égal à 2,，DUP est égal à 0。

 Requisce PUBLISH rapportmessage considéré comme

non acquitté

，jusqu'à ce quereçoive le correspondant de la part du récepteur PUBREC paquet.4.4 section

il y a une ... à propos des non acquittésdiscussion sur l'accusé de réception des messages。

MQTT-3.1.1-CN 50

 reçu PUBREC après le messageRequisenvoyer un PUBREL paquet.PUBREL le message doitdoit contenir le mêmeoriginal PUBLISH message

mêmel'identifiant de paquet.

 Requisce PUBREL rapportmessage considéré comme

non acquitté

，jusqu'à ce quereçoive le correspondant de la part du récepteur PUBCOMP paquet.

 une fois que le ... correspondant a été envoyéde PUBREL message alorsne peut pasrenvoyer ce PUBLISH paquet.

[MQTT-4.3.3-1].

une fois que l'émetteur reçoit PUBCOMP message, cetl'identifiant de paquet peut alors être réutilisé。

Remarque :Autorisél'expéditeur attend un accusé de réceptionlors de l'utilisation de différentsidentifiant de paquet pour envoyer les suivantsde PUBLISH paquet.

pourQoS 2protocole de livraison, recevoirpersonne

 réponse PUBREC messageRequiscontientidentifiant de paquet, cet identifiantà partir du reçu, déjà accepté tous lesautorisés

PUBLISH paquet.

 Lors de la réception du PUBREL correspondant avant le message,récepteurRequisenvoyer PUBREC rapportconfirmationtout paquet ultérieur avec le mêmemême identifiant

de PUBLISH paquet. Dans ce cas,ilne peut paslivraison en double des messagesà toutdestinataire ultérieur.

 réponse PUBREL du paquet PUBCOMP messageRequiscontenant et PUBREL rapportmessage avec le même identifiantcaractère.

 envoyer PUBCOMP rapportdu texteaprès, le récepteurdoit inclure le mêmetout avec le même identifiant de messagesuivi PUBLISH rapporttexte devraiten faire un

une nouvelle publication.

[MQTT-4.3.3-2].

légende 4.3 – QoS 2 flux protocolairediagramme,non normatifExemple

expéditeuraction

paquet de contrôle

récepteuraction

stocker les messages

envoyer PUBLISH paquet,QoS=2,

DUP=0, avecidentifiant de paquet

---------->

Méthodes A: stocker les messages, ou méthodes B：

stocker l'identifiant de paquet, puis commencer àavant

remettre ce message d'applicationsouffle

。

envoyer PUBREC rapporttexte,avec identifiant de message

identifiant.

<----------

rejeter le message, stocker PUBREC dans

identifiant de paquet

envoyer PUBREL rapporttexte, avec messagemarque

identifiant

---------->

MQTT-3.1.1-CN 51

Méthodes A: commence à transférer le message d'applicationsouffle

puis rejeter le message ou méthode B：rejeter

identifiant de paquet

envoyer PUBCOMP paquet,avec message

Identificateurs

<----------

abandonner l'état sauvegardécondition

n'exige pas que le récepteurlors de l'envoi de PUBREC ou PUBCOMP avantla distribution complète devraitavec le message. L'envoi d'originele récepteur reçoit

PUBREC rapportaprès le paquet, le message d'applicationla propriété du message alorssera transférée à ce récepteur。

légende 4.3 – QoS 2 Protocoleorganigramme, non standardexemple affichagedu récepteur QoS 2 attendredeux types de messages de niveauméthode de traitement.ils

la différence est ce que le message ...quand peut commencercommencer la distribution. Implémentationl'implémenteur peut décider d'utiliserquelle méthode utiliser. Tant que l'implémentationl'implémenteur a seulement sélectionnéune méthode

méthode,n'affectera pas QoS fluxla fiabilité du processus.

4.4 réessai de livraison de message

le client définit l'indicateur Clean Startsession (CleanSession）Flagsest 0 se reconnecterlorsque, le clientet le serveurRequisutiliser l'originalrenvoyer l'identifiant du message initial

tout PUBLISH message non acquitté (si QoS>0) et PUBREL message [MQTT-4.4.0-1]. C'est la seuleuneExigenceclient ou

Le serveur renvoie les messagesla situation.

non normatifcommentaire

Retransmission des paquets de contrôlenécessaire pour surmontercertaines TCP données obsolètes sur le réseauproblème de perte de données.déployé dans ces environnements MQTT

3.1.1 réelleL'implémentation peut encore être nécessairese concentrer sur ce problèmesujet.

4.5 message reçu

Le serveur prend en charge l'entrantla propriété du message d'applicationlorsqu'il est autorisé, ilRequisle messageajouter à l'abonnementla session du client correspondantdans l'état.les règles de correspondance déterminent

vue sémantique 4.7 section [MQTT-4.5.0-1]。

Dans des circonstances normales, le clientle client reçoit envoyéà son abonnementmessage. Le clientpeut également recevoir des messages qui ne lui sont pas liésl'abonnement correspond exactementmessage correspondant. Par exemple

Si le serveur envoie automatiquementle client attribuéun abonnement,possiblecette situation se produitsituation. Actuellement en cours de traitement UBSUBSCRIBE demandepeut également recevoirà

message. ClientObligatoireselon la possiblequalité de service utiliséequantité (QoS) la règle confirme qu'il a reçutout PUBLISH paquet,indépendammentilSélectionners'il faut traiter

Traiter le message d'application contenu dans le paquetutiliser le message [MQTT-4.5.0-2]。

4.6 ordre des messages

Implémenter ce qui est défini dans ce chapitrependant le flux du protocole,clientObligatoiresuivre les règles suivantespuis :

 Renvoyer tout précédent PUBLISH rapportlorsque le message,Obligatoireselon l'original PUBLISH messagel'ordre d'envoirenvoyer dans l'ordre (applicableutilisé pour QoS 1 et

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

 Obligatoireselon le correspondant PUBLISH Envoyer les paquets dans l'ordre PUBACK rapporttexte (QoS 1 Message）[MQTT-4.6.0-2]。

 Obligatoireselon le correspondant PUBLISH Envoyer les paquets dans l'ordre PUBREC message (QoS 2 Message）[MQTT-4.6.0-3]。

 Requisselon le PUBREC correspondant Envoyer les paquets dans l'ordre PUBREL message (QoS 2 Message）[MQTT-4.6.0-4]。

Côté serveurRequisconsidère par défaut que chaqueles sujets ont tousun ordre. IlOuifournirune fonction de gestion oud'autres mécanismes, pourpermettre à un ouplusieurs maîtres

Traiter le sujet comme non ordonné [MQTT-4.6.0-5]。

MQTT-3.1.1-CN 52

Le serveur gère l'envoivers des sujets ordonnéslorsqu'un message,Requiscomme ci-dessusles règles s'appliqueront au messagemessage distribué à chaque abonné. De plus, ilRequisselon

Reçu du clientenvoyer dans l'ordre PUBLISH signalerle message au consommateur(pour le même sujetquestion et QoS）[MQTT-4.6.0-6]。

non normatifcommentaire

Les règles énumérées ci-dessusgarantissent, en utilisant QoS 1 publicationet le flux de messages d'abonnement,les abonnés selon le messagel'ordre lors de la publication du messagereçu dans l'ordrechaque

MessageLa copie finale, mais le message peutpeut être répété, celapeut l'amener àles messages suivantsaprès avoir déjà reçu un certainmessage déjà reçu

Version renvoyée. Par exemple, l'éditeur dans l'ordreséquence 1,2,3,4 envoie des messages, l'abonnél'ordre reçu par le récepteurpeut être 1,2,3,2,3,4。

Si le client et le serveurle serveur peut garantir n'importe quelà tout moment, au plus un messagel'information est dans

pendant la transmission (

encours

）

(dans un certain messageavant que le message soit acquitté

N’envoyez pas ce qui suitmessage), puisquoi,Ne ... pasOui QoS 1 du messagesera dans l’un de sesreçu après des messages ultérieurs。 Par exemple，

L’ordre dans lequel les abonnés reçoiventl’ordre peut être 1,2,3,3,4, plutôt que 1,2,3,2,3,4. La fenêtre de transmission （dans-ffenêtre légère) soitest 1

Signifie que, dans le mêmesur un sujet,même sil’éditeur envoieune série de différents QoS niveaux de messages,leur ordre doit aussiêtre protégé

conserver.

4.7 nom du sujet et filtre de sujet

4.7.1 joker de sujet

sujetniveau (niveau de sujet) séparéséparateur utilisé pour structurerLa normalisation introduit des noms de sujet.s'il y a une distributionséparateur, il sera le principalDiviser le nom du sujet en plusieurs

niveau de sujet

level

niveau de sujet 。

Filtre de sujet d'abonnementl'appareil peut contenir des caractères spéciauxjokers spéciaux, vous permettants'abonner à plusieurs à la foissujet.

Le filtre de sujet peututiliser des jokers, mais les noms de sujetne peuvent pasUtilisationjoker [MQTT-4.7.1-1]。

4.7.1.1 niveau de sujetDélimiteurs

barre oblique（‘/’ U+002F) utilisé pourChacun des niveaux de sujetNiveau, pour fournir une hiérarchie pour le nom du sujetstructure. Lorsque le clientle client s'abonne aufiltre de sujet spécifié

Le filtre contient deux jokerslorsque le séparateur, le niveau de sujetséparateur de niveau est trèsutile. Le sujetséparateur de hiérarchie peutpeut apparaître dans les filtres de sujetou celui du nom du sujet

N'importe quelle position. Un séparateur adjacentde la hiérarchie des sujetsreprésente unniveau de sujet de longueur nulle.

4.7.1.2 Jokermulti-niveau

indicateur numérique (‘#’ U+0023) est utilisépour la correspondance dans les sujetsN'importe quelniveaule caractère générique. Multi-niveaucaractère générique représente sonparent et n'importe quel nombre d'enfants de la quantité

Niveaux. Leséparateur du caractère générique multi-niveaux doit être situé à sonpropre niveau ou suivi duséparateur de niveau de sujetaprès le séparateur. Indépendammentquel type de situationsituation, il est toujoursRequisest le sujet

Le dernier descaractères du filtre [MQTT-4.7.1-2]。

non normatifcommentaire

Par exemple,siLe client s'abonne aux sujets “sport/tennis/player1/#”，Il recevra en utilisant ce qui suitle nom du sujet publiéMessage :

 “sport/tennis/player1”

 “sport/tennis/player1/ranking”

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

non normatifcommentaire

 “sport/#”correspond aussi à“sport” “séparé , car # incluantson parent.

 “#”est validede,recevra tous lesmessages d'application。

 “sport/tennis/#”est aussivalide.

 “sport/tennis#”est invalide.

MQTT-3.1.1-CN 53

 “sport/tennis/#/ranking”Ouiinvalide.

4.7.1.3 passe à une seule couchecaractère correspondant

Le signe plus (‘+’ U+002B) ne peut être utilisé quepour un seul niveau de sujet, commecaractère générique de correspondance de niveau.

Dans le filtre de sujetsn'importe quel niveau peutpeut utiliser un caractère générique à un seul niveau,y compris lespremier et dernier niveaux. CependantilRequisoccupe celui du filtre

le niveau entier [MQTT-4.7.1-3]。Peut être dans le filtre de sujetsplusieurs niveaux dans leniveau, en l'utilisant,peut également être utilisé avec plusieurs niveauxutiliser des caractères génériques ensembleutilisation.

non normatifcommentaire

Par exemple, “sport/tennis/+” correspond à “sport/tennis/player1” et “sport/tennis/player2” ，Maisne correspond pas

“sport/tennis/player1/ranking” . Pendant ce temps, commeun caractère générique à niveau uniquene peut correspondre qu’à un niveauniveau, “sport/+” ne correspond pas

“sport” mais il correspond àallocate “sport/”。

non normatifcommentaire

 “+” est valide.

 “+/tennis/#” est valide.

 “sport+” est invalide.

 “sport/+/player1” est également valide.

 “/finance” correspond à “+/+” et “/+” , mais pascorrespondance “+”。

4.7.2 avec$sujets commençant par

Côté serveurne peut pasva $ le caractère commencecorrespondance du nom de sujet en têtecorrespondre au caractère générique (#ou+) ouvrirFiltre de sujets commençant par [MQTT-4.7.2-1]Le serveur doitempêcher

Le client utilise ce type denoms de sujets et d'autresclients échangent des messagesmessage. L'implémentation du serveur peutva $ Les noms de sujets commençant parà d'autres fins.

non normatifcommentaire

 $SYS/ est largement"Utilisé pour contenir des informations spécifiques au serveurmessage ou interface de contrôlele préfixe du sujet。

 Les applications ne peuvent pas utiliser $ des noms de sujets commençant par le caractèresujet.

non normatifcommentaire

 Abonnement “#” Le client ne recevra pasÀ tout message publié sur “$” sujet commençantles messages du sujet.

 Abonnement “+/monitor/Clients” le client nerecevra aucun message envoyédistribuer à “$SYS/monitor/Clients” d'éliminationmessage.

 Abonnement “$SYS/#” le clientrecevra les messages publiés sur “$SYS/” commençantmessages sur le sujet.

 Abonnement “$SYS/monitor/+” deLe client recevra un Publishvers “$SYS/monitor/Clients” mainles messages du sujet.

 Si le client souhaitelors de l'acceptation “$SYS/” un sujet commençant parmessages et ne commençant pas par $ un sujet commençant parmessages, il doiten même temps

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

4.7.3 sujetsémantiqueet utilisation

nom du sujet et filtre de sujetsLes filtres doivent être conformes àles règles suivantes :

 tous les noms de sujets etFiltre de sujetsObligatoireinclure au moinscontient un caractère [MQTT-4.7.3-1]。

 nom du sujet et filtre de sujetsLes filtres sont sensibles à la casseminuscules.

 nom du sujet et filtre de sujetsLes filtres peuvent contenirdes espaces.

MQTT-3.1.1-CN 54

 nom du sujet ou filtre de sujetsLes filtres avec une barre oblique initiale ouune barre oblique finale “/” distinguent.

 contient uniquement des barres obliques “/” le nom du sujet ou le filtre de sujetsLe filtre est valide.

 nom de sujet et filtre de sujetfiltrene peut pascontenir un caractère nul (Unicode U+0000) [Unicode] [MQTT-4.7.3-2]。

 nom de sujet et filtre de sujetle filtre est UTF-8 chaîne encodée, ilsne peuvent pasDépassé 65535 octet [MQTT-4.7.3-3]. voir 1.5.3

section.

saufne peut pas dépasser UTF-caractère encodélimite de longueur de chaîneDe plus, le nom de sujet ou le sujetles niveaux du filtrele nombre n'a pas d'autres restrictions.

lors de la mise en correspondance des abonnements, le serveurserveurne peut paspour le nom de sujet ouLe filtre de sujets exécuteeffectuer aucune normalisation（normalisation) processus, nepeut pas modifier ou remplacer

tout caractère non reconnusymbole [MQTT-4.7.3-4]. SujetChaque non-joker dans le filtreles niveaux de joker doivent être mis en correspondance un par unles caractères correspondent au sujetniveau correspondant dans le nom

le niveau est considéré comme une correspondance réussie。

pasSpécificationcommentaire

Utilisation UTF-8 Les règles d'encodage impliquent, le filtre de sujetset la comparaison des noms de sujetsLa comparaison peut être effectuée en comparantpar rapport à l'encodé UTF-8 octetou solution

caractères Unicode encodés.

pasSpécificationcommentaire

 « ACCOUNTS » et « Accounts” sont des sujets différentsTitre.

 « Accounts payable » est cohérent avecle nom du sujet de

 « /finance » et « finance » sont différents.

siLe filtre de sujet abonné et le nom de sujet du messagecorrespondent, les messages d'application serontenvoyés à chaqueclient correspondantabonnement. Le sujetpeut être

Administrateur au niveau du serveurprédéfini, ou il peut être le serveurle serveur reçoit le premierun abonnement ou en utilisant ce sujetmessage applicatif avec le nom de sujetajouté dynamiquement lors de la réception du message

de. Le serveur peut aussipeut utiliser uncomposant de sécurité de manière sélectiveautoriser le client à utiliser une certaineressource de sujet.

4.8 Gestion des erreurs

Sauf indication contraire,Si le serveur ouLe client a rencontréun comportement qui viole le protocole,ilRequisdésactiver la transmission de ceune violation de protocolele réseau de messages de contrôle

connexion réseau [MQTT-4.8.0-1]。

client ou serveurl'implémentation peut rencontrerdes erreurs transitoires (Terreur transitoireou)(par ex., à l'intérieurle tampon est pleincas) conduisant àne peut pas réussir à

traitement MQTT paquet.

Si le client ou le serveurle côté serveur traite les paquets entrantsa rencontré un problème transitoire lors du traitement d'un paquet de contrôleerreur temporelle,ilRequisfermer le transport quiconnexion réseau pour les paquets de contrôleJie

[MQTT-4.8.0-2]。sile serveur a détectéune erreur transitoire, ilne devrait passe déconnecterse connecter ou exécutertoute opération vers d'autres clientsaffectant le pair

faire.

 
  MQTT-3.1.1-CN  55 
5  sécurité 
5.1 Aperçu 
Le contenu de ce chapitre est à titre deréférence, n'est pasnormalisé. Cependant, il est fortement recommandé defournir TLS de serviceimplémentation côté serveurdevraitUtilisation TCP port 8883
（IANA nom de service :secure-mqtt）。 
 
fournisseur de solutionsIl faut prendre en compte de nombreuxrisques. Par exemple : 
  Les appareils peuvent être volésutilisation 
  client et serveurles données statiques peuventpeuvent être accessibles (peuvent être fixéesmodifier) 
  Le comportement du protocole peut avoirdes effets secondaires (tels queles attaques temporelles) 
  attaques par déni de service 
  Les communications peuvent être interceptéesintercepter,modifierredirection ou divulgation 
  faux messages de contrôleinjection 
 
MQTT schéma viasouvent déployé dans unenvironnement de communication sécurisée. Dans cecas, le protocolela mise en œuvre nécessite généralementIl est nécessaire de fournir ces mécanismes : 
  Identité de l'utilisateur et de l'appareilauthentification 
  Accès aux ressources du serveurautorisation 
  MQTT paquet de contrôletexte et application embarquéel'intégrité des donnéesvérification de l'intégrité 
  MQTT paquet de contrôletexte et application embarquéela confidentialité des donnéescontrôle privé 
 
En tant que protocole de couche transport，MQTT se concentre uniquement sur la transmission des messages,fournit une sécurité appropriéela fonctionnalité complète relève de la responsabilité de l'implémenteurresponsabilité. Utiliser TLS [RFC5246] Oui
un choix relativement courant. Outre les aspects techniquesoutre les problèmes de sécurité,et les facteurs géographiquesfacteurs (par exemple, les États-UnisPrincipes de Safe Harbor de l'UE 
[USEUSAFEHARB]）, les normessectorielles (par exemple, les normes de l'industrie des paiements tiersen matière de sécurité des données [PCIDSS]), considérationsréglementaires (Exemple
tels que Sarbanes-profondOxley Act [SARBANES]) etc.problème. 
5.2 MQTT Solution : Sécurité et authentification 
Les implémentations de protocole peuvent vouloirdoivent se conformer à des normes spécifiquesde sécurité industrielle, telles que NIST netcadre de cybersécurité [NISTCSF] , tiersdonnées de l'industrie des paiementspaix
norme complète [PCIDSS] , normes fédérales américainesde traitement de l'information [FIPS1402] et NSA ajoutercombinaison de chiffrement B [NSAB] 。 
Dans MQTT du correctifpublication supplémentaire （MQTT et lecadre NIST pour l'amélioration des Infrastructures critiques 
Cybersécurité [MQTT NIST]） peut être trouvée dansDans NIST Mise en réseaucadre de sécurité [NISTCSF] MoyenUtilisation MQTT deconseils. Utiliser
Certification sectorielle, audit indépendantet technologie d'authentificationaide à satisfaire auxexigences de conformité. 
5.3 Chiffrement léger et dispositifs contraints 
chiffrement avancé largement adopténorme de chiffrement [AES] numérochiffrement des donnéesNorme [DES] 。 
recommandé pour une utilisation comme restreintefonctionnalités d'appareils bas de gammeléger spécialement optimiséniveau de chiffrement internationalNorme ISO 29192 [ISO29192] 。 
5.4 considérations de mise en œuvre 
la mise en œuvre et l'utilisation de MQTT nécessitent de prendre en compte de nombreuxproblèmes de sécurité.ci-dessousla partie ne doit pasdoit être traité comme deséléments d'une liste de contrôle 。 
Les implémentations du protocole peuvent implémenterdésormais la partie suivanteen partie ou en totalité : 

 
  MQTT-3.1.1-CN  56 
5.4.1 identité du clientà vérifier 
CONNECT rapportle texte contient les champs nomd'utilisateur et mot de passe.L'implémentationpeut décider comment utiliser ces caractèresLe contenu du paragraphe. Les implémenteurs peuvent fournirleur propre
Mécanisme d'authentification,ou utiliser un système externed'authentification tel que LDAP [RFC4511] ou OAuth [RFC6749] , peut aussiutiliser le système d'exploitation
mécanismes d'authentification. 
les implémentations peuvent transmettre en clairlivrer les données d'authentification,obscurcir ces données, ou ne pas exigerde données d'authentification,mais doivent être conscientescela augmentera l'utilisation de virtuel entre intermédiaireattaque de l'homme du milieu
attaques et attaques par rejeurisque.5.4.5 sectiona introduit les méthodes exactespour garantir la confidentialité des données. 
Sur lespoints de terminaison client et serveurun réseau privé virtuel (VPN) peutgarantir que les données ne sont queClients autorisésle client reçoit. 
Utilisation TLS [RFC5246] lorsque,Le serveur peut utiliserenvoyé par le client SSL certificatvérifierl'identité du client. 
L'implémentation peut permettre au clientclient via lemessage d'application envoyant les identifiants au serveurcertificat pour la vérification d'identitépreuve. 
5.4.2 autorisation du client 
D'après les informations fournies par le clienttelles que le nom d'utilisateur, l'identifiant clientidentifiant (ClientId）、clientle nom d'hôte ou IP adresse, ouauthentification
Le résultat, le serveurpeut restreindre l'accès à certainesressources serveuraccès. 
5.4.3 Servicesle point de terminaison lui-mêmevérification d'identité 
MQTT le protocole n'est pas une confiance mutuellede, il nefournit pas de vérification par le client de l'identité du serveurmécanisme. 
MaisUtilisation TLS [RFC5246] lorsque, le client peut utiliser le serviceenvoyé par le serveur SSL certificatvérifier le serveuridentité. À partir d'une seule IP plusieursnom de domaine
Fournir MQTT L'implémentation du service devraitenvisager RFC6066  [RFC6066] N° 3 sectiondéfinie TLS de SNI Extension.SNI permet aux clients determiner
Indiquer au serveur qu'il souhaite se connecter auserveur connecténom d'hôte. 
L'implémentation peut permettre au serveurserveur via l'applicationmessage envoyant des identifiants au clientcertificat pour vérification d'identitépreuve. 
Sur le client et le serveurpoints de terminaisonréseau privé virtuel (VPN) peutgarantir que le clientse connecte à l'attendudu serveur. 
 
5.4.4 contrôlemessageet message d'applicationintégrité du messageintégrité 
L'application peut être dans l'applicationle message séparément contient une valeur de hachage. Cefaisant ainsi peut PUBLISH contrôlela transmission réseau et les données statiquesfournissent le contenu
Contrôle d'intégrité. 
TLS [RFC5246] mentionprévu pour le réseaules données transmises sontalgorithme de hachage pour la vérification d'intégritéméthode. 
Sur le client et le serveurpoints de terminaisonréseau privé virtuel (VPN) connexionVous pouvez VPN couvertLe segment réseau fournit l'intégrité des donnéescontrôle d'intégrité. 
5.4.5 messages de contrôle etmessage d'applicationsouffleconfidentialité 
TLS [RFC5246] peutpour la transmission réseauchiffré.. Si la valide TLS suite de chiffrementla combinaison contient un chiffrementdont l'algorithme est NULL，alors il
Cela ne chiffre pas les données.doit garantir au clientet au serveur laconfidentialité, devrait éviterd'utiliser ces suites de chiffrementaccord. 
 
Les applications peuvent ajouter séparémentpour chiffrer les messages d'applicationcontenu. Cela peutFournir des messages d'application en transitneutre et statiqueconfidentialité des données statiquesConfidentialité. Mais ne peut pas fournir de messages d'application
Autres attributs du message, tels quele chiffrement du nom de sujet. 
 
client et serveurles implémentations peuvent chiffrerLe stockage de données statiques, par exemplepeuvent chiffrer les messages applicatifsmessage dans le cadre d'une sessionstockage. 
Sur le client et le serveurpoints de terminaisonréseau privé virtuel (VPN) connexionVous pouvez VPN couvertLe segment réseau garantit laconfidentialité des données。 
5.4.6 transmission de messagesnon-répudiationauthenticité 
Le concepteur d'application peutdevoir envisager desstratégies appropriées pour implémenter undéni de bout en bout (non-répudiation）。 

 
  MQTT-3.1.1-CN  57 
5.4.7 détectionclientclient et serveurcôté serveurvol 
Utilisation TLS [RFC5246] du clientLes implémentations client et serveur devraientpouvoir garantir,Initialiser TLS [RFC5246] lors de la connexion, fournirfourni SSL prouver
Le certificat est lié au nom d'hôte (les clients doivent se connecterou le serveur sera connectéà) relationassociée. 
 
Utilisation TLS [RFC5246] du clientLes implémentations client et serveur peuventchoisir de fournir une détectionVérifier la liste de révocation des certificats  (CRLs [RFC5280]) et en ligne
Protocole d'état de certificat  (OSCP) [RFC6960] defonction,Rejeter l'utilisation de certificats révoquéscertificat. 
 
Le déploiement physique peut utiliserdu matériel résistant à l'altération etdes données spéciales des messages d'applicationcombinaison de transmission.Par exemple,ales instruments peuventun GPS intégré pour garantir
Nonutilisé dans une région non autorisée.IEEE dispositif de sécuritéauthentification de dispositif [IEEE 802.1AR] consiste à utiliserpour implémenter ce mécanismeUne norme de contrôle,cela rend
Utiliser un identifiant de liaison chiffrépour vérifier l'identité de l'appareilcopier. 
 
5.4.8 détecter un comportement anormal 
L'implémentation serveur peutsurveiller lecomportement du client, détecter des risquesde sécurité potentiels. Par exemple : 
  Demandes de connexion répétées 
  Demande répétée d'authentificationrequest 
  Arrêt anormal de la connexion 
  Analyse des sujets (demanded’envoi ou d’abonnement à un grandnombre de sujets) 
  Envoyer des messages non distribuables(sujets sansabonnés) 
  Le client se connecte, maisn’envoie pas de données 
Découvrir les violations des règles de sécuritéle comportement, l’implémentation du serveurpeutdéconnecter la connexion clientconnecter. 
L’implémentation du serveur détecteun comportement indésirablepeut être basée sur l’adresse IP de baseou l’identifiant clientpour implémenter uneliste noire dynamique. 
Le déploiement de service peut se faireen utilisant le contrôle de la couche réseau(si disponible) mis en œuvre en fonction de l’adresse IP de baseadresse ou autrelimitation de débit de ses informationsou liste noire. 
5.4.9 autrede sécuritéprécautions de sécuritéélément 
Si le client ou le serveurcôté serveur SSL perte de certificat, ou siils considèrent le certificat voléutilisé ou révoqué(Utiliser CRLs [RFC5280] et 
OSCP [RFC6960])de lasituation. 
 
client ou serveurlors de la vérification des identifiants,s'il est constaté que lenom d'utilisateur et le mot de passe de l'utilisateur sont perdusou volés, devraitdevrait révoquer ou réémettre。 
 
Lors de l'utilisation de connexions de longue durée： 
  client et serveurUtilisation TLS [RFC5246] devrait permettrepermettre la renégociationnégocier une session pour confirmerde nouveaux paramètres de chiffrement (remplacerla clé de session
Clé, changer la suite de chiffrementidentité, changer lesinformations d'authentification). 
  Le serveur peut déconnecterla connexion du client,et exiger qu'ilutilise de nouveaux identifiants pour re-vérifier son identité. 
 
Sur un réseau restreint, le point de terminaison de confiancelimité aux appareils et clientspeut utiliser TLS la reprise de session [RFC5077] réduire TLS Sessionreconnexion [RFC5246] de coût
coût. 
 
Connecté au serveuret aux autres clientsles clients connectés au serveurextrémité Il existe une relation de confiance transitive entre, ils ont tous le droitsur le même sujet
pour publier des messages. 

 
  MQTT-3.1.1-CN  58 
5.4.10 Utilisation SOCKS courtier 
L'implémentation client devraitêtre consciente que certains environnementsenvironnement nécessite d'utiliser SOCKSv5 [RFC1928] générationla gestion crée une connexion réseau sortante.certains MQTT réel
La sécurité peut maintenant être utiliséetunnel (tel que SSH）À travers SOCKS courtier. onUne implémentation décide de prendre en charge SOCKS quand,Elles devraient simultanément prendre en chargemasquer
du nom et du mot de passe d'utilisateurvérification du code SOCKS proxy.pour ce derniercas, implémenterdevrait être conscient SOCKS peutpeut utiliserauthentification en clair,
Par conséquentDevrait éviter d'utiliser les mêmes identifiantsconnexion MQTT serveur. 
5.4.11 profil de sécurité 
Implémenteur et conception de solutionles concepteurs peuvent souhaiterTraiter la sécurité comme un fichier de configurationensemble devraitêtre appliqué à MQTT dans le protocole. Ce qui suit décritest une sécurité en couches
structure hiérarchique globale. 
5.4.11.1 Configuration de communicationouverte 
Utilisez la configuration de communication ouvertelors du paramétrage,MQTT Le protocole s'exécute sur un mécanisme intégré sans surcoût supplémentairedu mécanisme de communication sécurisée supplémentairemis en place sur le réseau. 
5.4.11.2 sécuritéconfiguration de communication réseau 
Utilisez une communication réseau sécuriséelors de la configuration de la communicationMQTT le fonctionnement du protocoles'exécute dans un environnement sécurisécontrôlé physique ou virtuelsur le réseau,Par exemple VPN ou objetréseau de sécurité physique. 
5.4.11.3 Configuration de transport sécurisé 
Utilisez une configuration de transmission sécuriséelors du paramétrage,MQTT le protocole s'exécute surUtilisation TLS [RFC5246] deréseau physique ou virtuelsur le réseau, il fournitFournit une authentification d'identité，
Intégrité et confidentialité。 
 
Utilisez l'utilisateur intégréChamps de nom d'utilisateur et de mot de passe，TLS [RFC5246] identité clientL'authentification d'identité peut être utiliséepour (ou à la place de）MQTT invitéauthentification client
preuve. 
5.4.11.4 Sécurité conforme aux normes de l'industrieconfiguration complète 
Comme on peut s'y attendre,MQTT Parconçu pour prendre en chargede nombreuses applications conformes aux normes de l'industrieconfiguration,Chacun définit unun modèle de menace et pour définirposition de menace
Le mécanisme de sécurité spécial. La sécurité spécialemécanisme recommande la méthode suivantechoisir dans le plan : 
 
[NISTCSF] NIST cadre de sécurité réseaucadre 
[NIST7628] NISTIR 7628 Guide de cybersécurité des réseaux électriques intelligents 
[FIPS1402] (FIPS PUB 140-2) module de chiffrementexigences de sécurité 
[PCIDSS] PCI-DSS Support tiersSécurité des données de l'industrie des paiementsnorme complète 
[NSAB] NSA chiffrementcombinaison B 

MQTT-3.1.1-CN 59

6 Utilisation WebSocket commecouche réseau

si MQTT dans WebSocket [RFC6455] connexionlors de la transmission,ObligatoiresatisfaireLes conditions suivantes :

 MQTT paquet de contrôletexteObligatoireUtilisation WebSocket nombre binaireTrame de données envoyée. Sireçu tout autre type detrame de données, recevoir

personneObligatoirefermer la connexion réseau [MQTT-6.0.0-1]。

 unique WebSocket nombreTrame de données peut contenir plusieursun ou partie MQTT Paquet. Le récepteurne peut pasSupposer MQTT paquet de contrôleappuyer

WebSocket alignement des limites de trame [MQTT-6.0.0-2]。

 clientObligatoireLa chaîne mqtt contenue dans celui-cifournie WebSocket sous-protocoledans la liste des protocoles [MQTT-6.0.0-3]。

 Le serveur sélectionne et renvoierenvoyé WebSocket sous-protocolenom du protocoleObligatoireOui mqtt [MQTT-6.0.0-4] 。

 Utilisé pour connecter les clientset le WebSocket URI du serveur Paire MQTT n'a aucun effet sur le protocole.

6.1 IANA Noteprécautions

cette spécification demande IANA In WebSocket sous-protocoleEnregistré sous l'entrée de nom de protocole WebSocket MQTT sous-protocole,Utilisez les données suivantes：

légende 6.1 - IANA WebSocket Identifiants

Identifiant de sous-protocole

mqtt

Nom générique du sous-protocole

mqtt

définition du sous-protocole

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

MQTT-3.1.1-CN 60

7 cohérence

MQTT spécification définitdéfini MQTT invitéimplémentation client et MQTT Implémenté par le serveurexigences de conformité

MQTT l'implémentation peutpeut simultanément être MQTT client et MQTT serveur.Accepter les connexions entranteset établir vers d'autresde la connexion sortante du serveurvêtements

Le serveur doit également se conformercombiner MQTT invitéclient et MQTT exigence côté serveurTrouver [MQTT-7.0.0-1]。

Afin de pouvoir, avec toute autreimplémentation conformeInteropérer, uneimplémentation conforme ne peut pasêtre tenue d'utiliser dans cette spécificationToute externe définieExtensions [MQTT-

7.0.0-2]。

7.1 objectifs de conformité

7.1.1 MQTT Côté serveur

a MQTT Le serveur ne satisfait queci-dessousTouspour être considéré conforme aux exigencesCette spécification :

1. le serveur envoiede tous les paquets de contrôlele format doit être conforme àChapitre 2 et leformat décrit au chapitre 3

2. se conformer à la 4.7 correspondance de sujet décrite dans la sectionrègles de correspondance.

3. satisfaire aux chapitres suivantstous dans cette sectionRequisexigences de niveaudemande,clairS'applique uniquement au clientsauf :

- Chapitre 1 – Introduction

- Chapitre 2 – MQTT format des messages de contrôleformule

- Chapitre 3 – MQTT paquet de contrôle

- Chapitre 4 – comportement opérationnel

- Chapitre 6 –(si MQTT la couche réseau est WebSocket）

- Chapitre 7 – objectifs de conformité

Satisfaire aux exigences de cohérencedu serveurRequisprise en charge à l'aide d'unun ou plusieurs transports sous-jacentsProtocole de transport, tant queIl fournit ordonné, fiable,bidirectionneloctet

flux (du client versServeur et du serviceServeur vers le client）[MQTT-7.1.1-1]. CependantLa cohérence ne dépend pas du fait qu'il prenne en chargePrend en charge n'importe quel

protocole de transport. ServeurfinOuiprend en charge la 4.2 sectiontout listéprotocole de transport, ouTout autre satisfaisant [MQTT-7.1.1-1] requistransmission

protocole.

7.1.2 MQTT client

a MQTT Un client ne satisfaità toutes les conditions suivantesCe n'est qu'alors qu'il est considéré comme conforme.à cette spécification :

1. le client envoiede tous les paquets de contrôlele format doit être conforme àchapitre 2 et leformat décrit au chapitre 3

2. satisfaire aux chapitres suivantstous dans cette sectionRequisexigences de niveaudemande,clairNe s'applique qu'au serveursauf :

- Chapitre 1 – Introduction

- Chapitre 2 – MQTT format des messages de contrôleformule

- Chapitre 3 – MQTT paquet de contrôle

- Chapitre 4 – comportement opérationnel

- Chapitre 6 – (si MQTT du réseaula couche réseau est WebSocket）

- Chapitre 7 – objectifs de conformité

Satisfaire aux exigences de cohérencele clientRequisprendre en charge en utilisant unun ou plusieurs transports sous-jacentsprotocole de transport, tant queIl fournit ordonné, fiable,bidirectionneloctet

flux (du client versServeur et du serviceServeur vers le client）[MQTT-7.1.2-1]. CependantLa cohérence ne dépend pas du fait qu'il prenne en chargePrend en charge n'importe quel

MQTT-3.1.1-CN 61

protocole de transport. ExtrémitéclientOuiprend en charge la 4.2 sectiontoute répertoriéeprotocole de transport, ouTout autre satisfaisant [MQTT-7.1.2-1] requistransmission

protocole.

MQTT-3.1.1-CN 62

annexe B Forcedéclaration de spécification de conformité(non standardportée）

Cette annexe est non normativeNormative, uniquement commeDans le corps de ce documentpeuvent être trouvéesune grande quantitéde déclarations de conformitéLe résumé est fourni.Exigences de conformitécolonne des limites

Tableau présenté au chapitre 7.

numéro de séquence déclaré

déclaration de spécification

[MQTT-1.5.3-1]

UTF-8 Caractères dans la chaîne encodéedonnées de caractèresRequisest selon Unicode Spécification [Unicode] définie et dans

RFC3629 [RFC3629] moyen-lourddéclaré valide UTF-8 format. SpécialIl convient de noter en particulier que,Cesnombre

selonne peut pascontient le code de caractère à U+D800 et U+DFFF entredonnées.Si le serveur oule Client reçoit

contient un paquet de contrôle de caractère UTF-8non valide,ilest requisfermer la connexion réseau。

[MQTT-1.5.3-2]

chaîne encodée en UTF-8 encoded stringne peut pascontenir un caractère nul U+0000。sile client ou le serveur reçoitun paquet est arrivé

contient U+0000 demessage de contrôle,ilRequisFermer la connexion réseau.

[MQTT-1.5.3-3]

UTF-8 séquence d'encodage 0XEF 0xBB 0xBF totaleest interprétée comme U+FEFF(espace insécable de largeur nulleCaractère

caractère),peu importeIl apparaît à la position de la chaînequelle qu'elle soit,messageLes destinataires ne peuvent pas l'ignorer ni le supprimerlaissez-le.

[MQTT-2.2.2-1]

Tableau 2.2 tout marqué comme“retain”bits de drapeau, tous sont réservésréservé pour un usage futur，Requisdéfini comme un tableau

Valeurs listées dans.

[MQTT-2.2.2-2]

siReçoit un indicateur non valide,récepteurRequisFermer la connexion réseau.

[MQTT-2.3.1-1]

SUBSCRIBE，UNSUBSCRIBE et PUBLISH（QoS supérieur à 0) paquet de contrôleRequiscontient un

un non nul 16 bitsIdentifiant de paquet (Packet Identifier。

[MQTT-2.3.1-2]

Chaque fois que le client envoieUn nouveau de ceux-citype de paquet quandRequisAttribuer un actuellementpaquet inutilisé.mark

identifiant。

[MQTT-2.3.1-3]

siUn client veut renvoyer ce particulierpaquet de contrôle spécial, lors d'une retransmission plus tardquand ce paquet,ilRequisfaire

Utiliser le même identifiant. Lorsque le client estaprès avoir traité le message correspondant àAprès confirmation, ceL'identifiant de paquet est libéré

rendre réutilisable.QoS 1 de PUBLISH Pairecorrespond à PUBACK，QoS 2 de PUBLISH correspondant

Oui PUBCOMP, et SUBSCRIBE ou UNSUBSCRIBE Pairecorrespondant respectivement sont SUBACK ou

UNSUBACK

[MQTT-2.3.1-4]

envoyer un QoS 0 de PUBLISH messagequand,mêmeLes conditions s'appliquent aussi au serveurextrémité.

[MQTT-2.3.1-5]

QoS Défini sur 0 de PUBLISH messagene peut pasContient un identifiant de paquet.

[MQTT-2.3.1-6]

PUBACK, PUBREC, PUBREL messageRequiscontenant etinitialement envoyé PUBLISH message avec le même

identifiant de paquet。

[MQTT-2.3.1-7]

et [MQTT-2.3.1-6] similaire,SUBACK et UNSUBACK Requiscontenu dans le correspondant

SUBSCRIBE et UNSUBSCRIBE messageL'identifiant de paquet utilisé danscaractère.

[MQTT-3.1.0-1]

client à serveurétablissement de connexion réseauaprès l'établissement, le client envoie aupremier du serveurun messageRequisOui

CONNECT message。

[MQTT-3.1.0-2]

sur une connexion réseau, le client ne peutenvoyer qu'une seule fois un CONNECT Message. ServeurserveurIl est requis quele client

le deuxième message CONNECT envoyé commetraitement d'une violation de protocoleet déconnecter la connexion du client。

[MQTT-3.1.2-1]

si le nom du protocole est incorrectconfirmer le serveurOuidéconnecter le clientla connexion, aussiOuiconformément àd'autres spécificationsReprendre

traitement du CONNECT message. Pourdans ce dernier cas,conformément à cette spécification,côté serveurne peut pascontinuer le traitement

CONNECT message。

MQTT-3.1.1-CN 63

[MQTT-3.1.2-2]

S'il s'avère quele niveau de protocole n'est pas pris en charge,côté serveuril est requisd'envoyer uncode de retour est 0x01(protocole non pris en charge

niveau de protocole)de CONNACK messageréponse CONNECT paquet,puisDéconnecter la connexion du client。

[MQTT-3.1.2-3]

côté serveuril est requis devérifier CONNECT les indicateurs réservés du paquet de contrôle(le 0 bit) est de savoir si 0，siNon

est 0 doitdoit déconnecter la connexion du client.

[MQTT-3.1.2-4]

Si la session propre (CleanSession）l’indicateur est définidéfini à 0, le serveurRequisen fonction desession actuelle (faire

Utiliser l'identifiant clientidentification) étatreprendre avec le clientcommunication. Sinon associé à cet identifiant clientsavoir

session associée à l'identifiant,côté serveurRequiscréer uneune nouvelle session. DansAprès la déconnexion de la connexion, lorsque la connexiondéconnexion de la connexion

Après,client et serveurRequisEnregistrerles informations de session.

[MQTT-3.1.2-5]

Lorsque l'indicateur de session propreest 0 connexion de sessionaprès la déconnexion de la connexion,côté serveurRequisensuite QoS 1 et QoS 2

persistance des messages au niveaucomme l'état de sessionune partie, sices messages correspondentlors de la déconnexion, le clientn'importe lequel du client

n'importe quel abonnement.

[MQTT-3.1.2-6]

Si la session propre (CleanSession）l'indicateur est définidéfini sur 1, clientet le serveurRequisavant de supprimer

de toute session et démarrerdémarrer une nouvelle sessionEn d'autres termes, la session ne dure que tant que le réseauconnexion réseau aussi longtempstemps.etCeci

état associé à la sessionDonnéesne peuvent pasaprès touteréutilisation de session.

[MQTT-3.1.2.7]

Les messages retenus ne sont pas côté serveur.état de session du serveurune partie de, la session se terminelorsquene peut passupprimer les messages retenusmessage.

[MQTT-3.1.2-8]

Drapeau Will (Will Flag) est définiest 1, indiquant siSi la demande de connexion estacceptée, le Will (Will

Message）MessageRequisest stocké dansle serveur et avec ce réseauassociation de connexion réseau.après la fermeture de la connexion réseau

lors de la fermeture, le serveurRequisPublier ce message Will, sauf si le serveura reçu DISCONNECT lors de la suppression d'un message

à l'exception de ce message Willmessage.

[MQTT-3.1.2-9]

Si l'indicateur Will estDéfini sur 1, connexiondans l'indicateur de connexion Will QoS et Will Retain Champsseront par le serveur

utilisé,en même tempsdans la charge utileRequiscontient Will Topic et Will Message Champs。

[MQTT-3.1.2-10]

Une fois publié oule serveur a reçuenvoyé par le client DISCONNECT paquet, le message WillJustedoit

besoindu stockageSupprimé de l'état de session stocké.

[MQTT-3.1.2-11]

Si le drapeau Will estDéfini à 0，connexiondans le drapeau Will QoS et Will Retain ChampsRequisDéfini à

0, etdans la charge utilene peut pascontient Will Topic et Will Message Champs。

[MQTT-3.1.2-12]

Si le drapeau Will estDéfini à 0, réseaulorsque la connexion réseau est déconnectée，ne peut pasenvoyer le message Will。.

[MQTT-3.1.2-13]

Si le drapeau Will estDéfini à 0, laisserindiquer QoS aussiRequisDéfini à 0(0x00)。

[MQTT-3.1.2-14]

Si l'indicateur Will estDéfini à 1, laissezindiquez QoS valeur depeut être égal à 0(0x00)，1(0x01)，2(0x02)。

sa valeurne peut pasêtre égale à 3。

[MQTT-3.1.2-15]

Si l'indicateur Will estDéfini à 0, laissezwill retain (Will Retain) l'indicateur aussiRequisDéfini à 0。

[MQTT-3.1.2-16]

siLe Will Retain est défini à 0, le serveurRequisTraiter le message Will comme une publication de message non-conservé。

[MQTT-3.1.2-17]

siLa conservation du testament est définie sur 1, le serveurObligatoiretraite le message testament commePublié en tant que message retenu。

[MQTT-3.1.2-18]

si l'indicateur de nom d'utilisateur (User Name) est défini à 0, dans la charge utilene peut pascontenirchamp de nom d'utilisateur.

[MQTT-3.1.2-19]

si l'indicateur de nom d'utilisateur (User Name) est défini à 1, dans la charge utileRequiscontientchamp de nom d'utilisateur.

[MQTT-3.1.2-20]

si l'indicateur de mot de passe (Password)est défini à 0, dans la charge utilene peut pascontient un champ de mot de passe。

[MQTT-3.1.2-21]

si l'indicateur de mot de passe (Password)est défini à 1, dans la charge utileObligatoirecontient un champ de mot de passe

MQTT-3.1.1-CN 64

[MQTT-3.1.2-22]

Si l'indicateur de nom d'utilisateurest défini à 0, l'indicateur de mot de passe aussiRequisDéfini à 0。

[MQTT-3.1.2-23]

Le client est responsable de s'assurer quela transmission des paquets de contrôlel'intervalle de temps ne dépasse pas le keep-alivevaleur keep-alive.S'il n'y a pas d'autre

son paquet de contrôle peutpeut envoyer, le clientfinRequisenvoyer un PINGREQ message。

[MQTT-3.1.2-24]

Si le keep alivevaleur est non nulle, etle serveur à une fois et demie ledélai keepaliveaucun client reçu dans

le paquet de contrôle du client,ilRequisdéconnecter laconnexion réseau du client,considérerconnexion réseau déjàdéconnectée.

[MQTT-3.1.3-1]

si inclus,RequisApparaître dans cet ordre: identifiant clientjoker, sujet will, willmessage,use

nom d'utilisateur，Mot de passe。

[MQTT-3.1.3-2]

Le serveur utilise leidentifiant client (ClientId) pour connaîtreIdentifier le client. Se connecter au serveur.chaque client du serveurtous les clients ont un identifiant unique

identifiant client uniquecaractère (ClientId). Le client etle serveur doivent tous les deuxUtilisation ClientId savoirdistinguer entre les deux

entre MQTT état lié à la session。

[MQTT-3.1.3-3]

identifiant client (ClientId) RequisExistede plusRequisOui CONNECT messageLe premier de la payloada

Fields。

[MQTT-3.1.3-4]

identifiant clientRequisOui 1.5.3 défini dans la section UTF-8 Chaîne encodée。

[MQTT-3.1.3-5]

Côté serveurRequisAutorisé 1 à 23 octets de long UTF-8 client encodéIdentifiant client, le clientidentifiant client

ne peut contenir que ces caractèrescaractère :

“0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXY

Z”(lettres majuscules, lettres minuscules et chiffrescaractère).

[MQTT-3.1.3-6]

Côté serveurOuiautoriser le clientle client fournit un zero-byteidentifiant client d'un byteidentifiant (ClientId) ，si cela est fait

terminé,Côté serveurObligatoiretraiter ceci comme un cas particulier etattribuer un client uniqueidentifiant client àce client.mais

après celaRequissupposer le clientLe point de terminaison fournit cet uniquede l'identifiant clientcaractère,normaltraiter ceci CONNECT

message。

[MQTT-3.1.3-7]

si le clientle point de terminaison fournit un zéro octetde l'identifiant du clientsymbole, ilObligatoireeffacera égalementindicateur de session définiplacé

est 1。

[MQTT-3.1.3-8]

Si le client fournitde ClientId est de zéro octetet le drapeau Clean Sessionmarqué comme 0, servicefinObligatoireenvoyer le code de retour

est 0x02（Indique que l'identifiant est invalide) de CONNACK réponse de paquetdu client CONNECT rapport

texte,Ensuite, fermez la connexion réseau。

[MQTT-3.1.3-9]

Si le serveur rejettede ce ClientId，ilObligatoireenvoyer le retourcode comme 0x02(tableauindique que l'identifiant est invalide

format) de CONNACK rapportréponse au messagedu client CONNECT paquet, puisfermez la connexion réseau。

[MQTT-3.1.3-10]

sujet WillObligatoireOui 1.5.3 défini dans la section UTF-8 chaîne encodée.

[MQTT-3.1.3-11]

Nom d'utilisateurObligatoireOui 1.5.3 défini dans la section UTF-8 chaîne encodée。

[MQTT-3.1.4-1]

Côté serveurObligatoireselon 3.1 la sectionvérification des exigences CONNECT paquet,sile paquet n'est pas conforme àla spécification, le service

n'envoie pas CONNACK rapporttexte directfermer la connexion réseau。

[MQTT-3.1.4-2]

si ClientId Tableindique que le clientdéjà connecté àce serveur,alors le serveurObligatoireraison de déconnexioncertains clients

connexion.

[MQTT-3.1.4-3]

Côté serveurObligatoireselon 3.1.2.4 du nœuddécrit l'exécution du nettoyagedu processus de session.

[MQTT-3.1.4-4]

Côté serveurObligatoirerenvoyercode de retour zéro CONNACK paquet comme CONNECT du paquetréponse d'accusé de réception.

[MQTT-3.1.4-5]

sile serveur a rejeté CONNECT, ilne peut pasgérer le client dans CONNECT rapportenvoyer après le messagede

toute donnée。

MQTT-3.1.1-CN 65

[MQTT-3.2.0-1]

le serveur envoie CONNACK messagela réponse reçue du client CONNECT rapportMessage. Le serveur envoie à

le premier du clientmessageRequisOui CONNACK。

[MQTT-3.2.2-1]

Si le serveur reçoitClean Session (CleanSession）Flagsest 1 deconnexion, saufserait CONNACK

Le code de retour dans le paquetDéfini à 0 extérieur, aussiRequisva CONNACK dans le paquetparamètre de session actuel

（Session Present）l'indicateur est 0。

[MQTT-3.2.2-2]

Si le serveur reçoita CleanSession est 0 deconnexion, la session actuelleLa valeur de l'indicateur de session prenddépend du serveur

s'il a déjà enregistré ClientId Pairrépondre au clientl'état de session.si le serveur a déjà stockél'état de session

état,ilRequisva CONNACK rapportle drapeau de session actuel dans le paquetDéfini à 1。

[MQTT-3.2.2-3]

siLe serveur n'a pas de session enregistréestatut,ilRequisva CONNACK dans le messagele paramètre de la session actuellemettre

est 0. Il est également nécessaire de CONNACK signalerle code de retour dans le texte est défini à 0。

[MQTT-3.2.2-4]

Si le serveur envoiecontenait un non-avec un code de retour zéro CONNACK paquet,ilRequismarquer la session actuelle comme

le drapeau est défini à 0。

[MQTT-3.2.2-5]

Si le serveur envoiecontenait un non-avec un code de retour zéro CONNACK paquet,alorsilRequisfermer le réseau

connexion。.

[MQTT-3.2.2-6]

S'il est considéré que le tableau ci-dessus 3.1 toutes les connexions dans le tableau ci-dessus retournentles codes de retour ne sont pas tout à fait appropriésapproprié,alorscôté serveurRequisfermer la connexion réseau

connexion, pas besoin d'envoyer CONNACK message。

[MQTT-3.3.1-1]

client ou serveurdemande de renvoyer un PUBLISH lorsque le message,Requiswill DUP marqueindicateur est défini à 1。

[MQTT-3.3.1-2]

pour QoS 0 le message,DUP indicateursrequisDéfini à 0

[MQTT-3.3.1-3]

le serveur envoie PUBLISH message à l'abonnélorsque,reçude (entrant) PUBLISH du paquet DUP

la valeur de l'indicateur ne sera pasPropagation. Envoyer(sortant) PUBLISH message et reçu(entrant)

PUBLISH rapportdans le message DUP marqueindicateur est indépendantdéfini, sa valeurRequisséparémentla base pour l'envoi (sortant

de la station) PUBLISH rapportsi le messageune retransmission pour déterminer。

[MQTT-3.3.1-4]

PUBLISH messagene peut passera QoS lieucertains bits sont définis à 1。sile serveur ou le client reçoit QoS lieu

tous les bits sont 1 de PUBLISH rapportmessage, ilRequisFermer le réseauconnexion réseau.

[MQTT-3.3.1-5]

Si le client envoie àdu serveur PUBLISH rapportdu texteretain (RETAIN) marquerl'indicateur est défini à 1, service

serveurRequisStocker ce message applicatif et son serviceniveau de qualité de service (QoS), afin queil peut être distribuéDonner

correspondance future du nom de rubriquel'abonné correspondant.

[MQTT-3.3.1-6]

un nouvel abonnement est établilorsqu'il est établi, pour chaquele nom de rubrique correspondant, siExisterécentmessage retenu, ilRequis

envoyé à cet abonnementlecteur.

[MQTT-3.3.1-7]

Si le serveur reçoitune marque retenue (RETAIN) marquemarquée comme 1 de QoS 0 message,ilRequisavant de supprimer

retenu pour ce sujettout message.ildevraitce nouveau QoS 0 éliminerle message comme cettenouvelle rétention d’un sujet

conserver un message, mais n'importe quià tout momentOuichoisit de le supprimer — siCette situation se produit,cesujet n'aura pas de

a un message retenu。

[MQTT-3.3.1-8]

le serveur envoie PUBLISH paquet au clientquand, si le messageest en tant que clientLe résultat d'un nouvel abonnement

envoyer, ilRequisrapportLe drapeau retain du message est défini à 1。

[MQTT-3.3.1-9]

quand un PUBLISH rapportmessage envoyé àle client est parce qu'il correspond à unun abonnement établilors de l'abonnement, le serveurRequis

Définir le drapeau retain à 0，indépendammentRetain dans le message qu'il a reçula valeur du drapeau estinférieure.

MQTT-3.1.1-CN 66

[MQTT-3.3.1-10]

le drapeau retained est 1 et une charge utile de zéro octet PUBLISH messageSera traité comme positif par le serveurtraitement des messages

traité, il sera envoyépour correspondre au sujet d'abonnementclients correspondants. De plus,sous le mêmetout existantstocké retenu

le message doit être supprimé, donc ce sujettout abonné après le sujetne recevra pas deun message retenu。

[MQTT-3.3.1-11]

Côté serveurne peut passtockage zérole message retenu d'octets。

[MQTT-3.3.1-12]

Si le client envoie auserveur PUBLISH rapportdu textebit de drapeau Retain 0, le servicefinalne peut passtocker ce message

informations aussine peut pasSupprimer ou remplacer toute réservation existantemessage.

[MQTT-3.3.2-1]

nom du sujetObligatoireOui PUBLISH rapporten-tête variableLe premier champ de l'en-tête.ilObligatoireOui 1.5.3 la section spécifiesémantique

UTF-8 la chaîne encodée.

[MQTT-3.3.2-2]

PUBLISH rapportle nom du sujet dans le messagene peut pascontenir de jokers.

[MQTT-3.3.2-3]

Le serveur envoie à l'abonnédu Client abonné PUBLISH messagenom de rubriqueObligatoirecorrespondreau sujet de l'abonnementFiltre

(conformément à 4.7 la correspondance définie dans la sectionprocessus).

[MQTT-3.3.4-1]

PUBLISH rapportdestinataire du messageObligatoireselonSelon PUBLISH dans le paquet QoS niveauenvoyer une réponse, voir

Tableau 3.4 description.

[MQTT-3.3.5-1]

Côté serveurObligatoirele messageDistribué à tous les abonnements correspondantsattribué QoS le client de plus haut niveaufin.

[MQTT-3.3.5-2]

si le serveur implémenten'autorise pas un certain clientle client publie PUBLISH message, il n'a pasmoyen de notifier celaclient

fin.il estrequisselon les règles QoS normalesEnvoyer un accusé de réception positifaccusé de réception, ouFermer la connexion réseau.

[MQTT-3.6.1-1]

PUBREL contrôleen-tête fixe du paquet de contrôlepremier de l'en-tête 3,2,1,0 bit estbit réservé,Obligatoireest défini à 0,0,1,0. service

serveurObligatoireTraiter toute autre valeur comme nonvalide et fermer laconnexion réseau.

[MQTT-3.8.1-1]

SUBSCRIBE contrôlemessage de contrôle fixele 3,2,1,0 bit de l'en-tête fixe est réservébit,Obligatoirerespectivement défini à 0,0,1,0。

Côté serveurObligatoirel'autreToute valeur est traitée commeinvalide et fermerfermer la connexion réseau.

[MQTT-3.8.3-1]

SUBSCRIBE rapportmessage validefiltre de sujet dans la charge utileListeObligatoireOui 1.5.3 sectiondéfini UTF-8 Caractère

string。

[MQTT-3.8.3-2]

si le serveur choisitne prend pas en charge les caractères génériquesfiltre de rubrique générique,Obligatoirerejeter toutfiltre contenant des caractères génériquesfilter

la demande d'abonnement du filtre。

[MQTT-3.8.3-3]

SUBSCRIBE rapportdu messagecharge utileObligatoirecontient au moins unpour le filtre de rubrique et QoS niveaugroupe de champs

correspond. Aucune charge utilede la charge utile SUBSCRIBE messageest une violation du protocole。

[MQTT-3-8.3-4]

si dans la charge utileun bit quelconque de ... est non-nulle, ou QoS Différent 0,1 ou 2，Côté serveurObligatoireconsidérer

SUBSCRIBE rapportle message n'est pasvalide et fermer la connexion réseauconnecter.

[MQTT-3.8.4-1]

octet 12one sent by the endpoint SUBSCRIBE when the message,RequiredUsage SUBACK réponse de paquet

réponse.

[MQTT-3.8.4-2]

SUBACK messageRequiset en attente d'accusé de réception SUBSCRIBE messageont le même messageIdentifiant de paquet.

[MQTT-3.8.4-3]

Si le serveur reçoita SUBSCRIBE paquet, paquetLe filtre de topic et le topic d'un abonnement existantsubscription's topic

le filtre de topic est le même,alorsObligatoireen utilisant le nouvel abonnementl'abonnement remplace complètement les existantsabonnements stockés. Le nouvel abonnementfiltre de topic

filtre et précédemment abonnéidentique, mais illes maximales QoS valeurs peuvent être différentes.avec ce filtre de topiccorrespondant au filtre

tout existant retenuMessageObligatoireest retransmis,Maisflux de publicationne peut pasinterruption.

[MQTT-3.8.4-4]

Si le serveur reçoitcontenant plusieurs sujetsdu filtre SUBSCRIBE paquet,ilObligatoirecomme s'il avait reçu un

une série de plusieurs SUBSCRIBE messagegérer de la même manière, sauf qu'il est nécessaire defusionner leurs réponses en uneitems

séparé SUBACK signalerl'envoi de message.

MQTT-3.1.1-CN 67

[MQTT-3.8.4-5]

le serveur envoie au clientdu client SUBACK paire de messageschaque paire de filtres de topicdispositif et QoS attendretous les niveauxObligatoirePaquet

contient un code de retour.ce code de retourRequisindique que l'abonnement est accordéle maximum QoS niveau,ou désigne

cet abonnement échoue。

[MQTT-3.8.4-6]

le serveur peut accorderun niveauQoS inférieur à celui exigé par l'abonné. En réponse à l'abonnement,le message envoyé en raison de l'abonnementinformation

de la charge utile QoS RequisOuimessage de publication d'origineinformation QoS etaccordée par le serveur QoS deuxle plus petit parmi

valeur. Si le message d'origineinformation QoS Oui 1 et est accordéle maximum QoS Oui 0, permettant au serveur de répéterenvoyer une

une copie du message àl'Abonné.

[MQTT-3.9.3-1]

l'ordre des codes de retourRequiset SUBSCRIBE messagedans le filtre de sujetsl'ordre du serveur est le même。

[MQTT-3.9.3-2]

0x00, 0x01, 0x02, 0x80 desexternes SUBACK codes de retour sont réservésde,ne peut pasutiliser.

[MQTT-3.10.1-1]

UNSUBSCRIBE rapporttexte fixele bit de l'en-tête fixe 3,2,1,0 est à maintenirLe bit réservé etObligatoiredéfini séparémentest

0,0,1,0. serviceserveurObligatoireconsidérer tout autreles valeurs sont toutes invalideset fermer le réseauconnexion.

[MQTT-3.10.3-1]

UNSUBSCRIBE rapportdans le textele filtre de sujetObligatoireest continuellement compacté, selon 1.5.3 sectiondéfini

UTF-8 chaîne encodée.

[MQTT-3.10.3-2]

UNSUBSCRIBE rapportdu textecharge utileObligatoireau moins inclurecontient un messagefiltre. Il n'y a pasde la charge utile

UNSUBSCRIBE rapportle texte esten violation du protocole。

[MQTT-3.10.4-1]

UNSUBSCRIBE rapportmention textuellefiltre de sujet fourni (que celui-ci contienne ou noncaractère générique）Obligatoiremaintenir avec le serveur

le client qui a cele sujet actuelcomparer l'ensemble de filtres caractère par caractèrecomparaison. Si unun filtre correspond entièrement

correspond,Ensuite, il (le serveur)son propre abonnement sera supprimé, sinon il n'y aura pas detraitement ultérieur。

[MQTT-3.10.4-2]

Si le serveur supprimeun abonnement,ildoitcesser de distribuer tout nouveaumessage à ceClient.

[MQTT-3.10.4-3]

Si le serveur supprimeun abonnement,ildoitterminer la distribution de tout déjàdéjà commencé au clientenvoyé au client QoS

1 et QoS 2 du message。

[MQTT-3.10.4-4]

Côté serveurObligatoireenvoyer UNSUBACK rapportmessage de réponsedu client UNSUBSCRIBE requête.

UNSUBACK messageObligatoirecontient et UNSUBSCRIBE messagele même Packetidentifiant.

[MQTT-3.10.4-5]

même siN'a supprimé aucun abonnement aux topics,Côté serveuraussiObligatoireenvoyer un SUBACK réponse。

[MQTT-3.10.4-6]

Si le serveur reçoitcontenant plusieurs sujetsdu filtre UNSUBSCRIBE paquet,ilObligatoirecomme s'il était reçu

une série de plusieurs UNSUBSCRIBE signaleridentique au messagetraiter ce paquet,sauf pour leurfusionner la réponse dans

un message UNSUBACK séparéen dehors.

[MQTT-3.12.4-1]

Côté serveurObligatoireenvoyer PINGRESP paquet réponsedu client PINGREQ message。

[MQTT-3.14.1-1]

Côté serveurObligatoirevérifier tousTous les bits réservés sont définisdéfinis à 0, siils ne le sont pas 0 Obligatoiredéconnecterla connexion.

[MQTT-3.14.4-1]

le client envoie DISCONNECT signaleraprès le message,Obligatoirefermer le réseauconnexion.

[MQTT-3.14.4-2]

le client envoie DISCONNECT signaleraprès le message,ne peut pasà travers celaconnexion réseau puisenvoyer n'importe quel paquet de contrôle

texte.

[MQTT-3.14.4-3]

le serveur reçoit DISCONNECT signalerlorsque le message,Obligatoirerejeter tout avecLes messages non acquittés associés à la connexion actuellele testament publié

message testament, décrivant spécifiquementdécrit dans la 3.1.2.5 section.

[MQTT-4.1.0-1]

pendant toute la session, le client et le serveurserveur tousRequisstocker l'état de sessionétat.

[MQTT-4.1.0-2]

SessionRequisDure au moins aussi longtemps que sa connexion réseau activeconnecter pendant la même duréeespace.

MQTT-3.1.1-CN 68

[MQTT-4.3.1-1]

pour QoS 0 deprotocole de livraison, l'émetteurémetteurRequisenvoyer QoS égal à 0，DUP égal à 0 sur PUBLISH

message。

[MQTT-4.3.2-1]

pour QoS 1 duprotocole de distribution,expéditeur

 chaque fois qu'un nouveau message d'application est envoyétous les messagesRequisAttribuer un non-l'identifiant de paquet utilisécaractère.

 DOIT envoyer un PUBLISH Packet contenant ce Packet Identifier avec

QoS=1, DUP=0.

 envoyé PUBLISH messageObligatoirecontient unidentifiant de paquet et QoS égal à 1，DUP égal à

0。

 Obligatoirece PUBLISH messageconsidéré comme

non acquitté

，jusqu'à ce quereçoive le paquet correspondant du récepteur

de PUBACK paquet.4.4 octet a unun à propos de non acquittédiscussion des messages.

[MQTT-4.3.2-2]

pour QoS 1 duprotocole de livraison, le récepteurrécepteur

 réponse PUBACK messageRequiscontient unidentifiants de message,cet identifiant provient deà la réception

de,Cela a accepté la propriété PUBLISH paquet.

 envoyé PUBACK rapportaprès le message,le récepteur doittout paquet contenant le même identifiant de paquetl'entrée de l'identifiant

station PUBLISH messagecomme un nouveaule message, et ignorer son DUP Flagsla valeur de.

[MQTT-4.3.3-1]

pour QoS 2 duprotocole de livraison, l'émetteurémetteur

 doit attribuer au ... à envoyernouvelle distribution de message d'applicationattribuer un identifiant de paquet inutiliséidentifiant.

 DOIT envoyer un PUBLISH packet contenant ce Packet Identifier avec

QoS=2, DUP=0.

 envoyé PUBLISH messageRequiscontient un paquetidentifiant et paquetde QoS est égal à 2,，DUP

equals 0。

 Obligatoirece PUBLISH messageconsidéré comme

non acquitté

，jusqu'à ce quereçoive le paquet correspondant du récepteur

de PUBREC paquet.4.4 sectionIl y a un message concernant un non acquittédiscussion des messages.

 reçu PUBREC après le messageRequisenvoyer un PUBREL paquet.PUBREL paquet doit

Contient le PUBLISH original le même message que le messageIdentifiant de paquet.

 DOIT traiter le PUBREL paquet comme « non acquitté » jusqu'à ce qu'il ait

reçu le correspondant PUBCOMP paquet de la part du récepteur.

 Requisce PUBREL rapportmessage considéré comme

non acquitté

，jusqu'à ce qu'ilreçoive celui correspondant du récepteur

PUBCOMP paquet.

 une fois que le ... correspondant a été envoyéde PUBREL message alorsne peut pasrenvoyer ce PUBLISH paquet.

[MQTT-4.3.3-2]

pourQoS 2protocole de livraison, recevoirpersonne

 réponse PUBREC messageRequisContient un identifiant de paquet, qui estl'identifiant du paquet reçu、

déjàacceptant la propriété du PUBLISH paquet.

 Lors de la réception du PUBREL correspondant avant le message,récepteurRequisenvoyer PUBREC rapportconfirmationobligation

tout suivant ayant le mêmeavec le même identifiant PUBLISH paquet. Dans ce casci-dessous, ilne peut pasrépéter

transmettre des messages à toutdestinataire suivant。

 réponse PUBREL du paquet PUBCOMP messageRequiscontenant et PUBREL rapportidentique au message

identifiant.

 envoyer PUBCOMP rapportdu texteaprès, le récepteurdoit inclure le mêmetout avec le même identifiant de messageaprès

continuer PUBLISH messagecomme une nouvelleLa publication.

MQTT-3.1.1-CN 69

[MQTT-4.4.0-1]

le client définit l'indicateur Clean Startsession (CleanSession) marquemarqué comme 0 se reconnecterquand, le clientet le serveurRequisfaire

en utilisant l'identifiant de paquet d'origineidentifiant renvoie toutnon acquitté PUBLISH message (si QoS>0) et

PUBREL message。

[MQTT-4.5.0-1]

Le serveur prend en charge l'entrantla propriété du message d'applicationlorsqu'il est autorisé, ilRequisle messageajouter à l'abonnementclient correspondantde

dans l'état de session.correspondanceVoir la définition de la règle 4.7 section.

[MQTT-4.5.0-2]

clientRequisselon le possiblela qualité de service utilisée (QoS) Confirmation de règletout ce qu'il reçoit PUBLISH paquet,

indépendammentIl choisit s'il faut traiter les paquets contenantun message d'application。

[MQTT-4.6.0-1]

Renvoyer tout précédent PUBLISH rapportlorsque le message,Obligatoireselon l'original PUBLISH messageretransmettre dans l'ordre d'envoi

(s'applique à QoS 1 et QoS 2 Message）。

[MQTT-4.6.0-2]

Obligatoireselon le correspondant PUBLISH Envoyer les paquets dans l'ordre PUBACK rapporttexte (QoS 1 Message）。

[MQTT-4.6.0-3]

Requisselon le correspondant PUBLISH Envoyer les paquets dans l'ordre PUBREC rapporttexte (QoS 2 Message）。

[MQTT-4.6.0-4]

Requisselon le correspondant PUBREC ordre des paquetsenvoi séquentiel PUBREL message (QoS 2 Message）。

[MQTT-4.6.0-5]

Côté serveurRequispar défautPour chaque sujet il y aordre. IlOuifournirune fonction de gestion ouune autre machine

mécanisme, pourAutoriséUn ou plusieurs sujetstraités commenon ordonnés。

[MQTT-4.6.0-6]

Le serveur gère l'envoivers des sujets ordonnéslorsqu'un message,Requiscomme ci-dessusles règles s'appliqueront au messagemessage distribué à chaquesubscribe

lecteur.en outre, ilRequisselon ce qui est reçu du clientenvoyer dans l'ordre de réception PUBLISH messageau consommateur (pour le correspondant

le même sujet et QoS）。

[MQTT-4.7.1-1]

Le filtre de sujet peututiliser des jokers, mais les noms de sujetsne peuvent pasUtilisationJoker.

[MQTT-4.7.1-2]

le caractère générique multi-niveau doitêtre situé à son propreniveau ou en suivant le niveau de sujetaprès le séparateur de niveau. Quelle que soit la situation

condition,toutObligatoireest le dernier niveau du filtre de sujetscaractères。

[MQTT-4.7.1-3]

Dans le filtre de sujetstout niveau peutpeut utiliser un caractère générique à un seul niveau,y compris lepremier et le dernierniveau.

cependantilRequisoccupe tout le niveau du filtre。

[MQTT-4.7.2-1]

Côté serveurne peut pastestament $ Correspondance du nom de sujet commençant par le caractèrecorrespond au caractère générique (#ou+) ouvrirfiltre de sujet au débutappareil.

[MQTT-4.7.3-1]

tous les noms de rubrique etfiltre de rubriqueObligatoireDoit contenir au moins un caractère.

[MQTT-4.7.3-2]

nom de rubrique et filtre de rubriquefiltrene peut pascontenir un caractère nul (Unicode U+0000) [Unicode] 。

[MQTT-4.7.3-3]

nom de sujet et filtre de sujetle filtre est UTF-8 chaîne encodée, ilsne peuvent pasDépassement 65535 octet。

[MQTT-4.7.3-4]

lors de la mise en correspondance des abonnements, le serveurserveurne peut paspour le nom de sujet ouLe filtre de sujets exécuteeffectuer aucune normalisation

（normalisation）traitement,Impossible de modifier ou remplacer touttout caractère non reconnucaractère.

[MQTT-4.8.0-1]

Sauf indication contraire,Si le serveur ouLe client a rencontréun comportement qui viole le protocole,ilRequisdésactiver la transmission de ce

une violation de protocole contrôlela connexion réseau du paquetconnecter.

[MQTT-4.8.0-2]

Réseau de messages de contrôleconnexion.

[MQTT-6.0.0-1]

MQTT paquet de contrôleRequisUtilisation WebSocket nombre binaireTrame de données envoyée. Sirecevoir tout autreType

Trame de données, réceptionpersonneRequisfermer la connexion réseau。

[MQTT-6.0.0-2]

unique WebSocket nombreTrame de données peut contenir plusieursun ou partie MQTT Paquet. Le récepteurne peut pasSupposer

MQTT Messages de contrôle selon WebSocket l'alignement des limites de trame。

MQTT-3.1.1-CN 70

[MQTT-6.0.0-3]

clientRequisla chaînede caractères mqtt qu'il contientfourni WebSocket sous-protocoledans la liste des protocoles.

[MQTT-6.0.0-4]

Le serveur sélectionne et renvoierenvoyé WebSocket sous-protocolenom du protocoleObligatoireOui mqtt

[MQTT-7.0.0-1]

MQTT L'implémentation peut être simultanément MQTT client et MQTT côté serveur. Accepter les connexions entrantesConnexion au site et établissement à son

Son sortant côté serveurserveur connectédoit simultanément satisfaire MQTT client et MQTT exigence côté serveur

requête.

[MQTT-7.0.0-2]

Afin de avec toute autreimplémentation conformeinteropérer, uneimplémentation conforme ne peut pasobligé d'utiliser dans ceen dehors de la spécification

Toute extension définie。

[MQTT-7.1.1-1]

Satisfaire aux exigences de cohérencedu serveurRequisprise en charge à l'aide d'unun ou plusieurs transports sous-jacentsProtocole de transport, tant queil fournit

ordonné, peutFlux d'octets bidirectionnel fiable (Du client au serveurCôté serveur et du serveur au clientclient)

[MQTT-7.1.2-1]

Satisfaire aux exigences de cohérencele clientRequisprendre en charge en utilisant unun ou plusieurs transports sous-jacentsprotocole de transport, tant queil fournit

ordonné, peutFlux d'octets bidirectionnel fiable (Du client au serveurCôté serveur et du serveur au clientclient)