# Fondamentaux de MQTT Le protocole Message Queuing Telemetry Transport (MQTT) est utilisé depuis de nombreuses années, mais il est désormais particulièrement pertinent en raison de la croissance explosive de l’IoT : les appareils grand public comme industriels mettent en œuvre des réseaux distribués et de l’edge computing, et les appareils à transmission de données continue font désormais partie du quotidien. Une telle croissance intensive oblige à rechercher des moyens de transférer les données efficacement. ## Qu’est-ce que MQTT Andy Stanford-Clark (IBM) et Arlen Nipper (alors employé chez Eurotech, Inc.) ont rédigé la première version du protocole en 1999. Il servait à surveiller les oléoducs dans le cadre SCADA. L’objectif était de disposer d’un protocole économe en bande passante, léger et consommant peu de batterie, car les appareils étaient connectés via un lien satellite qui, à l’époque, était extrêmement coûteux. À l’heure actuelle, la plupart des appareils utilisent la version 5.0. Le Message Queuing Telemetry Transport (MQTT) est un protocole réseau léger de type publication-abonnement qui transporte des messages entre appareils. Le protocole s’exécute 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 les connexions avec des emplacements distants où une « petite empreinte de code » est requise ou lorsque la bande passante du réseau est limitée. Le protocole est une norme ouverte de l’OASIS et une recommandation ISO (ISO/IEC 20922). Compte tenu des conditions de fonctionnement, le protocole est conçu pour être petit et léger. Il est idéal pour les appareils à faible consommation d’énergie et à autonomie de batterie limitée. Aujourd’hui, cela inclut les smartphones, ainsi qu’un nombre toujours croissant de capteurs et d’appareils connectés. Ainsi, MQTT est devenu un protocole permettant la transmission de données entre des appareils dotés d’une puissance CPU et/ou d’une autonomie de batterie limitées, ainsi que pour des réseaux coûteux ou à faible bande passante, à stabilité imprévisible ou à forte latence. C’est pourquoi MQTT est connu comme le protocole idéal pour l’IoT. Il repose sur le protocole TCP/IP, mais il existe une branche MQTT-SN pour fonctionner via Bluetooth, UDP, ZigBee, et d’autres réseaux IoT autres que TCP/IP. ## Fonctionnement ### Le modèle publication et abonnement Il existe 2 définitions principales dans MQTT : MQTT Broker et 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 recevoir une copie de ce message s’abonnera à ce topic. Plusieurs clients peuvent recevoir le message d’un seul broker (fonctionnalité un vers plusieurs). De même, plusieurs éditeurs peuvent publier des topics vers un seul abonné (plusieurs vers un). Un client MQTT est tout appareil (d’un microcontrôleur à un serveur pleinement développé) 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 message sur le 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. Comme les messages MQTT sont organisés par topics, le développeur de l’application dispose de la flexibilité nécessaire pour spécifier que certains clients ne peuvent interagir qu’avec certains messages. Par exemple, les capteurs publieront leurs relevés 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 back-end s’abonneront au topic « sensor\_data ». Une application de console d’administration pourrait recevoir les commandes de l’administrateur système afin d’ajuster les configurations des capteurs, telles que la sensibilité et la fréquence d’échantillonnage, et publier ces modifications dans le topic « config\_change ». ### Types de messages MQTT Une session MQTT se divise 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 s’il se voit fournir une identité client réutilisée. Les ports standard sont 1883 pour la communication non chiffrée et 8883 pour la communication chiffrée — à l’aide de Secure Sockets Layer (SSL)/Transport Layer Security (TLS). Lors de la poignée de main SSL/TLS, le client valide le certificat du serveur et authentifie le serveur. Le client peut également fournir un certificat client au broker pendant l’échange. Le broker peut s’en servir pour authentifier le client. Bien que cela ne fasse pas spécifiquement partie de la spécification MQTT, il est devenu habituel pour les brokers de prendre en charge l’authentification client à l’aide de certificats côté client SSL/TLS. Comme le protocole MQTT vise à être un protocole destiné aux appareils IoT et aux appareils à ressources limitées, SSL/TLS n’est pas toujours une option et, dans certains cas, peut ne pas être souhaité. Dans ces cas, l’authentification est présentée 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 la séquence de paquets CONNECT/CONNACK. En outre, certains brokers, en particulier les brokers ouverts publiés sur Internet, acceptent 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 petite empreinte de code. Le paquet se compose d’un en-tête fixe de 2 octets + un en-tête variable et une charge utile. Dans ces 2 premiers octets, l’en-tête fixe sera toujours présent dans tous les paquets, et les deux autres, en-tête variable et charge utile, ne sont pas toujours présents. ![Format des messages MQTT](/files/2b96ce0262b0ee77e239c2dd33f350ecdca2fbee) Parmi 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 premiers bits MSB constituent le champ du type de commande. Ce type détermine l’action qui sera exécutée : le client souhaite s’abonner au topic, un nouveau message est publié pour les abonnés, et autres. 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 leur valeur sera 0. Le deuxième octet de l’en-tête fixe contient la longueur restante, c’est-à-dire 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 ou des indicateurs supplémentaires, 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 facultative et varie selon le type de paquet. Ce champ contient généralement les données en cours d’envoi. Par exemple, pour les paquets CONNECT, la charge utile est l’ID client et le « nom d’utilisateur et mot de passe » s’ils sont présents. Et pour le paquet PUBLISH, il s’agit du message à publier. ### Qualité de service QoS désigne un accord entre l’expéditeur d’un message et le destinataire du message. Il constitue une fonctionnalité clé dans MQTT, donnant au client la possibilité de choisir entre trois niveaux de service. Les trois niveaux de QoS déterminent la manière dont le contenu est géré par le protocole MQTT. Bien que les niveaux de QoS supérieurs soient plus fiables, ils impliquent davantage d’exigences en matière de latence et de bande passante ; les clients abonnés peuvent donc spécifier le niveau de QoS le plus élevé qu’ils souhaitent recevoir. * Le niveau de QoS le plus simple est un service sans accusé de réception. Ce niveau de QoS utilise une séquence de paquets PUBLISH ; l’éditeur envoie un message au broker une fois, et le broker transmet le message aux abonnés une fois. Il n’existe aucun mécanisme garantissant que le message a été correctement reçu, et le broker n’enregistre pas le message. Ce niveau de QoS peut également être appelé at most once, QoS0 ou fire and forget. * Le deuxième niveau de QoS est le service avec accusé de réception. 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é de réception vérifie que le contenu a bien été reçu, et un mécanisme de nouvelle tentative renverra le contenu d’origine si aucun accusé de réception n’est reçu dans un délai suffisant. Cela peut entraîner la réception de plusieurs copies du même message par l’abonné. Ce niveau de QoS peut également être appelé at least once ou QoS1. * Le troisième niveau de QoS est le service garanti. Ce niveau de QoS délivre le message au moyen de deux paires de paquets. La première paire s’appelle PUBLISH/PUBREC, et la seconde paire s’appelle PUBREL/PUBCOMP. Les deux paires garantissent que, quel que soit le nombre de tentatives, le message ne sera délivré qu’une seule fois. Ce niveau de QoS peut également être appelé exactly once ou QoS2. ![QoS MQTT](/files/0f53159e656b419cb6493ef582adb74a88f9ea17) ## Avantages et inconvénients ### Avantages : * MQTT est agnostique au type de paquet. La charge utile du protocole MQTT peut transporter n’importe quel type de données, comme du binaire, du texte ASCII, etc. Le récepteur doit interpréter et décoder selon le format utilisé par l’émetteur. * Il utilise un paquet de petite taille et peut être utilisé pour des applications à faible bande passante. * Il offre une consommation d’énergie de la batterie plus faible. * C’est un protocole fiable, car il utilise des options QoS pour fournir une livraison garantie. * Grâce à son modèle publication/abonnement, il est évolutif. * Il offre une conception découplée, car il est facile de séparer l’appareil et le serveur. Idéal pour les communications distribuées un vers plusieurs et les applications séparées. * Un appareil émetteur peut envoyer des données au serveur à tout moment, quel 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 les messages selon les modèles « maximum une fois », « minimum 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 constituer un point de défaillance, car les connexions des clients avec les 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é Comme les applications IoT sont désormais mises en œuvre à grande échelle, MQTT s’est retrouvé sous les projecteurs en tant que moyen ouvert, simple et évolutif de déployer des fonctionnalités de calcul distribué et d’IoT auprès d’une base d’utilisateurs plus large — dans les marchés grand public comme industriels. * Gestion de flotte. Les organisations utilisent MQTT pour créer des systèmes de gestion de flotte plus intelligents qui améliorent l’optimisation de flotte, la sécurité des conducteurs et réduisent les coûts de carburant. De nouveaux modes de transport utilisant des drones changent également la manière 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 issues du véhicule et l’intégration dans les systèmes de planification et d’acheminement back-end fournit la visibilité nécessaire pour améliorer l’ensemble des opérations de flotte. * Données de capteurs environnementaux. MQTT prend en charge le modèle de livraison des messages « pas plus d’une fois ». Dans les réseaux présentant une couverture partielle du territoire ou une 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 à intervalles spécifiés, cela ne pose pas de problème, puisque de nouvelles mesures sont reçues régulièrement. Les capteurs dans des environnements distants sont généralement des appareils à faible consommation, ce qui fait de MQTT une solution idéale pour les capteurs IoT ayant une priorité de transfert de données relativement faible. * Données de santé des machines : pour répondre rapidement aux problèmes émergents et éviter les temps d’arrêt. Par exemple, pour une centrale éolienne, vous avez besoin d’une 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 à temps par les spécialistes nécessaires, même s’ils arrivent en double. Cela est important pour les communications machine à machine avec une priorité plus élevée. * Systèmes de facturation : il existe encore davantage de messages prioritaires et précis qui doivent être traités correctement. Dans les situations commerciales où la duplication des enregistrements est inacceptable, y compris dans les systèmes de facturation, le drapeau de QoS de transmission « exactement une fois » est utile. Cela élimine la duplication ou la perte de paquets dans la facturation ou les systèmes de facturation, réduit le nombre d’anomalies et de contradictions inutiles dans l’accord. * Applications de messagerie textuelle pour la communication en temps réel qui tirent parti de la faible consommation de données et d’énergie de MQTT. Par exemple, Facebook utilise MQTT pour son application Messenger, non seulement parce que le protocole préserve la batterie lors des échanges entre téléphones mobiles, mais aussi parce qu’il permet de livrer les messages efficacement en quelques 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 de l’appareil Xirgo & BCE MQTT Pour configurer l’appareil Xirgo & BCE pour fonctionner avec MQTT : * Dans FMSET : Choisissez connectivity → Telemetry server → MQTT broker address settings) spécifiez host : [mqtt.eu.navixy.com](http://mqtt.eu.navixy.com/) pour le serveur EU et [mqtt.us.navixy.com](http://mqtt.eu.navixy.com/) pour le serveur US, port 1883. * Et ajoutez l’utilisateur par défaut dans MQTT Security -> Authorization\ ![MQTT device configuration](/files/ba16e5e490dda3fdd849c91d19d43f61e980b29a) ### Configuration de l’appareil Globalmatix MQTT Pour configurer l’appareil Globalmatix pour fonctionner avec MQTT : * Spécifiez le serveur port 1883 pour l’UE et 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 port 8883 pour l’UE et port 8883 pour les États-Unis * Utilisateur/mot de passe - globalmatix/secretword * Topic globalmatix/in --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://navixy.com/docs/expert-center/fr/vehicle-telematics-technology/connectivity/mqtt-fundamentals.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.