Principes fondamentaux de MQTT
Le protocole Message Queuing Telemetry Transport (MQTT) est utilisé depuis de nombreuses années, mais il est particulièrement pertinent aujourd’hui en raison de la croissance explosive de l’IoT : les appareils clients et industriels mettent en œuvre des réseaux distribués et du edge computing, et les appareils avec transmission de données permanente font désormais partie du quotidien. Cette croissance intensive oblige à rechercher des moyens de transférer les données de manière efficace.
Qu'est-ce que MQTT
Andy Stanford-Clark (IBM) et Arlen Nipper (alors employé par Eurotech, Inc.) ont rédigé la première version du protocole en 1999. Il était utilisé pour surveiller des oléoducs dans le cadre SCADA. L’objectif était d’avoir un protocole économe en bande passante, léger et peu consommateur d’énergie, car les appareils étaient connectés via un lien satellite qui, à l’époque, était extrêmement coûteux. À présent, la plupart des appareils utilisent la version 5.0.
Le Message Queuing Telemetry Transport (MQTT) est un protocole réseau léger en mode publication/abonnement qui transporte des messages entre appareils. Le protocole fonctionne généralement sur TCP/IP ; toutefois, tout protocole réseau offrant des connexions ordonnées, sans perte et bidirectionnelles peut prendre en charge MQTT. Il est conçu pour des connexions vers des emplacements distants où une « empreinte code réduite » est requise ou la bande passante réseau est limitée. Le protocole est une norme ouverte OASIS et une recommandation ISO (ISO/IEC 20922).
Compte tenu des conditions d’exploitation, le protocole est conçu pour être petit et léger. Il est idéal pour les appareils à faible consommation d’énergie et à autonomie limitée. Aujourd’hui, cela inclut les smartphones, ainsi qu’un nombre croissant de capteurs et d’appareils connectés.
Ainsi, MQTT est devenu un protocole pour le streaming de données entre appareils disposant d’une puissance CPU et/ou d’une autonomie limitées, ainsi que pour les réseaux à bande passante coûteuse ou faible, de stabilité imprévisible ou à forte latence. C’est pourquoi MQTT est reconnu comme le protocole idéal pour l’IoT. Il est construit sur le protocole TCP/IP, mais il existe une branche MQTT-SN pour fonctionner sur Bluetooth, UDP, ZigBee et d’autres réseaux IoT autres que TCP/IP.
Comment cela fonctionne
Le modèle publication/abonnement
Il y a 2 définitions principales dans MQTT : le Broker MQTT et le client MQTT.
Un broker MQTT est un serveur qui reçoit tous les messages des clients puis achemine les messages vers les clients destinataires appropriés. En termes simples, le broker agit comme un bureau de poste : MQTT n’utilise pas l’adresse du destinataire prévu mais utilise la ligne d’objet appelée « Topic », et toute personne souhaitant une copie de ce message s’abonnera à ce topic. Plusieurs clients peuvent recevoir le message d’un seul broker (capacité un vers plusieurs). De même, plusieurs éditeurs peuvent publier des topics pour un seul abonné (plusieurs vers un).
Un client MQTT est tout appareil (d’un microcontrôleur à un serveur complet) qui exécute une bibliothèque MQTT et se connecte à un broker MQTT via un réseau.
Le client se connecte au broker. Il peut s’abonner à n’importe quel « topic » de messages du broker. Cette connexion peut être une connexion TCP/IP simple ou une connexion TLS chiffrée pour les messages sensibles.
Le client publie des messages sous un topic en envoyant le message et le topic au broker.
Le broker transmet ensuite le message à tous les clients abonnés à ce topic.
Puisque les messages MQTT sont organisés par topics, le développeur d’application a la flexibilité de spécifier que certains clients ne peuvent interagir qu’avec certains messages. Par exemple, des capteurs publieront leurs mesures sous le topic « sensor_data » et s’abonneront au topic « config_change ». Les applications de traitement de données qui enregistrent les données des capteurs dans une base de données backend s’abonneront au topic « sensor_data ». Une application console d’administration pourrait recevoir les commandes de l’administrateur système pour ajuster la configuration des capteurs, comme la sensibilité et la fréquence d’échantillonnage, et publier ces modifications sur le topic « config_change ».
Types de messages MQTT
Une session MQTT est divisée en quatre étapes : connexion, authentification, communication et terminaison. Un client commence par créer une connexion Transmission Control Protocol/Internet Protocol (TCP/IP) au broker en utilisant soit un port standard soit un port personnalisé défini par les opérateurs du broker. Lors de la création de la connexion, il est important de reconnaître que le serveur peut poursuivre une ancienne session si on lui fournit une identité client réutilisée.
Les ports standard sont 1883 pour les communications non chiffrées et 8883 pour les communications chiffrées -- utilisant Secure Sockets Layer (SSL)/Transport Layer Security (TLS). Lors de la négociation SSL/TLS, le client valide le certificat du serveur et authentifie le serveur. Le client peut également fournir un certificat client au broker pendant la négociation. Le broker peut l’utiliser pour authentifier le client. Bien que cela ne fasse pas spécifiquement partie de la spécification MQTT, il est devenu d’usage que les brokers prennent en charge l’authentification des clients avec des certificats client SSL/TLS côté client.
Parce que le protocole MQTT vise les appareils contraints en ressources et les appareils IoT, SSL/TLS n’est pas toujours une option et, dans certains cas, peut ne pas être souhaité. Dans de telles occasions, l’authentification se présente sous la forme d’un nom d’utilisateur et d’un mot de passe en clair, envoyés par le client au serveur - ceci dans le cadre de la séquence de paquets CONNECT/CONNACK. De plus, certains brokers, en particulier les brokers ouverts publiés sur Internet, accepteront des clients anonymes. Dans ces cas, le nom d’utilisateur et le mot de passe sont simplement laissés vides.
Format des messages MQTT
MQTT est considéré comme un protocole léger car tous ses messages ont une empreinte code réduite. Le paquet consiste en un en-tête fixe de 2 octets + un en-tête variable et une charge utile. Dans ces premiers 2 octets, l’en-tête fixe sera toujours présent dans tous les paquets et les deux autres, l’en-tête variable et la charge utile, ne sont pas toujours présents.
Sur les deux octets de l’en-tête fixe, le premier octet est le champ de contrôle. Ce champ de contrôle de 8 bits est divisé en deux champs de 4 bits. Les 4 bits MSB (les plus significatifs) constituent le champ du type de commande. Ce type détermine l’action qui sera effectuée : le client souhaite s’abonner au topic, un nouveau message est publié pour les abonnés, etc.
Les 4 bits suivants sont les bits de drapeau de contrôle et ils sont utilisés par la commande PUBLISH ; pour le reste des commandes ils sont réservés et la valeur sera 0.
Le deuxième octet de l’en-tête fixe contient la longueur restante qui est la longueur de l’en-tête variable + la longueur de la charge utile.
Un en-tête variable n’est pas présent dans tous les paquets MQTT. Certaines commandes ou messages MQTT utilisent ce champ pour fournir des informations supplémentaires ou des drapeaux et ils varient selon le type de paquet. Un identifiant de paquet est courant dans la plupart des types de paquets.
Enfin, le paquet peut contenir une charge utile. Même la charge utile est optionnelle et varie selon le type de paquet. Ce champ contient généralement les données qui sont envoyées. Par exemple, pour les paquets CONNECT, la charge utile est l’identifiant client et le « username and password » s’ils sont présents. Et pour le paquet PUBLISH, il s’agit du message à publier.
Qualité de service
Le QoS se réfère à un accord entre l’émetteur d’un message et le destinataire du message. Il agit comme une caractéristique clé dans MQTT, donnant au client la possibilité de choisir entre trois niveaux de service.
Les trois niveaux de QoS déterminent comment le contenu est géré par le protocole MQTT. Bien que des niveaux de QoS supérieurs soient plus fiables, ils impliquent plus de latence et des exigences en bande passante plus élevées, donc les clients abonnés peuvent spécifier le niveau de QoS maximal qu’ils souhaitent recevoir.
Le niveau de QoS le plus simple est un service sans accusé. Ce niveau de QoS utilise une séquence de paquets PUBLISH ; l’éditeur envoie un message au broker une seule fois, et le broker transmet le message aux abonnés une seule fois. Il n’existe aucun mécanisme garantissant que le message a été correctement reçu, et le broker ne sauvegarde pas le message. Ce niveau de QoS peut également être appelé au plus une fois, QoS0 ou « fire and forget ».
Le deuxième niveau de QoS est le service avec accusé. Ce niveau de QoS utilise une séquence de paquets PUBLISH/PUBACK entre l’éditeur et son broker, ainsi qu’entre le broker et les abonnés. Un paquet d’accusé vérifie que le contenu a été reçu, et un mécanisme de nouvelle tentative renverra le contenu d’origine si un accusé n’est pas reçu en temps voulu. Cela peut entraîner la réception par l’abonné de copies multiples du même message. Ce niveau de QoS peut également être appelé au moins une fois ou QoS1.
Le troisième niveau de QoS est le service assuré. Ce niveau de QoS délivre le message avec deux paires de paquets. La première paire s’appelle PUBLISH/PUBREC, et la seconde s’appelle PUBREL/PUBCOMP. Les deux paires garantissent que, quel que soit le nombre de tentatives, le message ne sera livré qu’une seule fois. Ce niveau de QoS peut également être appelé exactement une fois ou QoS2.
Avantages et inconvénients
Avantages :
MQTT est agnostique au contenu des paquets. La charge utile du protocole MQTT peut transporter tout type de données telles que binaire, texte ASCII, etc. Le récepteur doit interpréter et décoder selon le format utilisé par l’émetteur.
Il utilise des paquets de petite taille et peut être utilisé pour des applications à faible bande passante.
Il offre une consommation d’énergie réduite.
C’est un protocole fiable car il utilise des options QoS pour fournir une livraison garantie.
En raison de son modèle publication/abonnement, il est évolutif.
Il offre une conception découplée car il est facile de découpler l’appareil et le serveur. Idéal pour les communications distribuées un-vers-plusieurs et les applications séparées.
Un appareil éditeur peut envoyer des données au serveur à tout moment quelle que soit son état.
Équipé de la fonction LWT (Last Will and Testament) pour informer les parties d’une déconnexion anormale du client.
S’appuie sur TCP/IP pour les tâches de communication de base.
Conçu pour livrer des messages selon les modèles « au plus une fois », « au moins une fois » et « exactement une fois ».
Inconvénients :
MQTT ne peut pas prendre en charge le streaming vidéo.
Problèmes de latence.
La sécurité n’est pas intégrée. MQTT n’est pas chiffré. À la place, il utilise TLS/SSL (Transport Layer Security/Secure Sockets Layer) pour le chiffrement de sécurité.
Un broker centralisé peut être un point de défaillance car les connexions des clients aux brokers sont ouvertes en permanence.
Il ne prend pas en charge des fonctionnalités avancées telles que le contrôle de flux.
Où MQTT peut être utilisé
Alors que les applications IoT sont désormais déployées à grande échelle, MQTT est devenu sous les projecteurs comme une manière ouverte, simple et évolutive de déployer l’informatique distribuée et les fonctionnalités IoT à un public plus large — tant sur les marchés grand public qu’industriels.
Gestion de flotte. Les organisations utilisent MQTT pour construire des systèmes de gestion de flotte plus intelligents qui améliorent l’optimisation des flottes, la sécurité des conducteurs et réduisent les coûts de carburant. De nouveaux modes de transport utilisant des drones changent également la façon dont nous déplaçons les marchandises. La connectivité entre un appareil mobile utilisé par l’opérateur, les informations de télémétrie directement depuis le véhicule et l’intégration dans les systèmes de planification et d’acheminement en back-end fournit la visibilité requise pour améliorer l’exploitation globale de la flotte.
Données des capteurs environnementaux. MQTT prend en charge le modèle de livraison de messages « pas plus d’une fois ». Dans les réseaux à couverture partielle du territoire ou à forte latence, cela signifie que l’information peut être perdue ou dupliquée. Dans les zones où des capteurs distants enregistrent et transmettent des données à des intervalles spécifiés, cela ne pose pas de problème, puisque de nouvelles mesures sont reçues régulièrement. Les capteurs en environnements éloignés sont généralement des appareils basse consommation, ce qui fait de MQTT une solution idéale pour les capteurs IoT avec une priorité de transfert de données relativement faible.
Données de santé des machines : pour répondre rapidement aux problèmes émergents et prévenir les temps d’arrêt. Par exemple, pour un parc éolien, il est nécessaire d’assurer la livraison garantie des indicateurs de performance actuels aux équipes locales avant même que ces informations n’atteignent le centre de traitement des données. Dans de telles situations, la livraison des messages « au moins une fois » garantit que les indicateurs appropriés seront remarqués par les spécialistes nécessaires en temps utile, même s’ils arrivent en double. Cela est important pour la communication machine-à-machine ayant une priorité plus élevée.
Systèmes de facturation : il existe des messages encore plus prioritaires et précis qui doivent être traités correctement. Dans des situations professionnelles où la duplication des enregistrements est inacceptable, notamment dans les systèmes de facturation, le flag QoS de transmission « exactly once » est utile. Cela élimine la duplication ou la perte de paquets dans les systèmes de facturation, réduisant le nombre d’anomalies et de contradictions inutiles dans l’accord.
Applications de messagerie textuelle pour la communication en temps réel tirant parti de la faible utilisation de données et d’énergie de MQTT. Par exemple, Facebook utilise MQTT pour son application Messenger, non seulement parce que le protocole économise la batterie lors d’échanges entre téléphones mobiles, mais aussi parce qu’il permet la livraison efficace des messages en millisecondes, malgré des connexions Internet inconstantes à travers le monde.
Appareils MQTT pris en charge par Navixy
Xirgo Global FMS500 Light MQTT (IOTM
Xirgo Global FMS500 Light+ MQTT (IOTM)
Xirgo Global FMS500 StCAN MQTT (IOTM)
BCE FMS500 Light MQTT (IOTM)
BCE FMS500 Light+ MQTT (IOTM)
BCE FMS500 StCAN MQTT (IOTM)
GlobalmatiX xTCU
Comment configurer les appareils MQTT pour fonctionner avec Navixy
Configuration des appareils Xirgo & BCE MQTT
Pour configurer l’appareil Xirgo & BCE pour fonctionner avec MQTT :
Dans FMSET : Choisir Connectivité → Telemetry server → MQTT broker address settings) spécifiez l’hôte : mqtt.eu.navixy.com pour le serveur EU et mqtt.us.navixy.com pour le serveur US, port 1883.
Et ajoutez l’utilisateur par défaut dans MQTT Security -> Authorization
Configuration de l’appareil Globalmatix MQTT
Pour configurer l’appareil Globalmatix pour fonctionner avec MQTT :
Spécifiez le serveur http://mqtt.navixy.com port 1883 pour l’Union européenne et http://mqtt.us.navixy.com port 1883 pour les États-Unis
Utilisateur/mot de passe - globalmatix/secretword
Topic globalmatix/in
Pour configurer l’appareil Globalmatix pour fonctionner avec MQTTS :
Spécifiez le serveur http://mqtt.navixy.com port 8883 pour l’Union européenne et http://mqtt.us.navixy.com port 8883 pour les États-Unis
Utilisateur/mot de passe - globalmatix/secretword
Topic globalmatix/in
Mis à jour
Ce contenu vous a-t-il été utile ?