> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/expert-center/fr/vehicle-telematics-technology/connectivity/mqtt-fundamentals.md). # Principes 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 et industriels mettent en œuvre des réseaux distribués et de l’informatique en périphérie, et les appareils transmettant des données en continu font désormais partie du quotidien. Une croissance aussi intense pousse les gens à chercher des moyens de transférer les données efficacement. ## Qu’est-ce que MQTT Andy Stanford-Clark (IBM) et Arlen Nipper (alors chez Eurotech, Inc.) ont rédigé la première version du protocole en 1999. Il a été utilisé pour surveiller des oléoducs dans le cadre du SCADA. L’objectif était d’avoir un protocole économe en bande passante, léger et peu gourmand en batterie, car les appareils étaient connectés via une liaison satellite qui, à l’époque, était extrêmement coûteuse. À 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 publication/abonnement qui transporte des messages entre des appareils. Le protocole fonctionne généralement au-dessus de TCP/IP ; toutefois, tout protocole réseau fournissant des connexions bidirectionnelles, ordonnées et sans perte peut prendre en charge MQTT. Il est conçu pour des connexions à distance où une « faible empreinte de code » est requise ou lorsque la bande passante du réseau est limitée. Le protocole est une norme ouverte OASIS et une recommandation ISO (ISO/IEC 20922). Compte tenu des conditions de fonctionnement, le protocole est conçu pour être compact et léger. Il est idéal pour les appareils à faible consommation énergétique et à autonomie de batterie limitée. Désormais, cela inclut les smartphones, ainsi qu’un nombre toujours croissant de capteurs et d’appareils connectés. Ainsi, MQTT est devenu un protocole de transmission continue de données entre des appareils dont la puissance CPU et/ou l’autonomie de batterie sont limitées, ainsi que pour les réseaux à bande passante coûteuse ou faible, à stabilité imprévisible ou à latence élevée. 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 sur Bluetooth, UDP, ZigBee et sur d’autres réseaux IoT autres que TCP/IP. ## Comment cela fonctionne ### Le modèle de publication et d’abonnement Il existe 2 notions principales dans le protocole 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 de destination 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 le sujet de message, et toute personne qui souhaite une copie de ce message s’abonnera à ce sujet. Plusieurs clients peuvent recevoir le message d’un seul broker (capacité un-à-plusieurs). De même, plusieurs éditeurs peuvent publier des sujets vers un seul abonné (plusieurs-à-un). Un client MQTT est n’importe quel appareil (d’un microcontrôleur à un serveur à part entière) 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 sujet de message dans le broker. Cette connexion peut être une simple connexion TCP/IP ou une connexion TLS chiffrée pour les messages sensibles. * Le client publie des messages sur un sujet en envoyant le message et le sujet au broker. * Le broker transmet alors le message à tous les clients qui s’abonnent à ce sujet. Comme les messages MQTT sont organisés par sujets, le développeur de l’application dispose de la flexibilité nécessaire pour préciser que certains clients ne peuvent interagir qu’avec certains messages. Par exemple, les capteurs publieront leurs mesures sous le sujet « sensor\_data » et s’abonneront au sujet « config\_change ». Les applications de traitement des données qui enregistrent les données des capteurs dans une base de données côté serveur s’abonneront au sujet « sensor\_data ». Une application de console d’administration pourrait recevoir les commandes de l’administrateur système pour ajuster les configurations des capteurs, telles que la sensibilité et la fréquence d’échantillonnage, et publier ces changements dans le sujet « 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 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 une identité client réutilisée lui est fournie. Les ports standard sont 1883 pour la communication non chiffrée et 8883 pour la communication chiffrée -- en utilisant Couche de sockets sécurisée (SSL)/Sécurité de la couche transport (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 s’en servir pour authentifier le client. Bien que cela ne fasse pas spécifiquement partie de la spécification MQTT, il est devenu courant que les brokers prennent en charge l’authentification du client avec des certificats client SSL/TLS. Parce que le protocole MQTT vise à être un protocole destiné aux appareils aux ressources limitées et aux appareils IoT, SSL/TLS n’est pas toujours une option et, dans certains cas, n’est pas souhaitable. Dans de telles situations, l’authentification prend la forme d’un nom d’utilisateur et d’un mot de passe en clair, envoyés par le client au serveur — dans le cadre de 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 ce 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 faible 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 est toujours présent dans tous les paquets, tandis que les deux autres, l’en-tête variable et la charge utile, ne sont pas toujours présents. ![Format des messages MQTT](/files/afd69b6d8a10b3e986a5b9179cd454d50b7b1a6c) Parmi ces deux octets d’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 de poids fort (MSB) constituent le champ du type de commande. Ce type détermine l’action à effectuer : le client souhaite s’abonner au sujet, un nouveau message est publié pour les abonnés, et ainsi de suite. Les 4 bits suivants sont les bits indicateurs de contrôle ; ils sont utilisés par la commande PUBLISH, et pour toutes les autres 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 + celle de la charge utile. Un en-tête variable n’est pas présent dans tous les paquets MQTT. Certaines commandes ou certains 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. Au final, 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 envoyées. Par exemple, pour les paquets CONNECT, la charge utile contient l’ID client et, s’ils sont présents, le nom d’utilisateur et le mot de passe. 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 son destinataire. Il s’agit d’une fonctionnalité clé de 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 plus élevés soient plus fiables, ils entraînent davantage de latence et des exigences de bande passante plus élevées ; 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 seule fois, et le broker transmet le message aux abonnés une seule fois. Il n’existe aucun mécanisme pour s’assurer que le message a été reçu correctement, et le broker ne stocke pas le message. Ce niveau de QoS peut également être appelé au plus une fois, QoS0 ou envoi sans accusé de réception. * Le deuxième niveau de QoS est un 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 é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 à temps. Cela peut amener l’abonné à recevoir plusieurs copies 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 un service garanti. Ce niveau de QoS transmet le message avec 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 nouvelles tentatives, le message ne sera transmis qu’une seule fois. Ce niveau de QoS peut également être appelé exactement une fois ou QoS2. ![QoS MQTT](/files/562b2264864dd5c7e2707d1779214e2b278ce961) ## Avantages et inconvénients ### Avantages : * MQTT est indépendant du type de paquet. La charge utile du protocole MQTT peut transporter tout type de données, comme du binaire, du texte ASCII, etc. Le destinataire doit l’interpréter et le 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 énergétique plus faible. * C’est un protocole fiable, car il utilise des options de QoS pour garantir la livraison. * Grâce à son modèle de 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-à-plusieurs et les applications distinctes. * Un appareil émetteur peut envoyer des données au serveur à tout moment, quel que soit son état. * Équipé de la fonction LWT (testament et dernières volontés) 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 transmettre les messages selon les modèles « au maximum une fois », « au minimum une fois » et « exactement une fois ». ### Inconvénients : * MQTT ne peut pas prendre en charge la diffusion vidéo en continu. * Problèmes de latence. * La sécurité n’est pas intégrée. MQTT n’est pas chiffré. À la place, il utilise TLS/SSL (Sécurité de la couche transport/Couche de sockets sécurisée) pour le chiffrement de sécurité. * Un broker centralisé peut être un point de défaillance, car les connexions des clients aux brokers sont toujours ouvertes. * Il ne prend pas en charge de fonctionnalités avancées telles que le contrôle de flux. ## Domaines d’utilisation de MQTT Alors que les applications IoT sont désormais mises en œuvre à grande échelle, MQTT s'est imposé comme un moyen ouvert, simple et évolutif de déployer l'informatique distribuée et les fonctionnalités IoT auprès d'une base d'utilisateurs plus large, tant sur les marchés grand public qu'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 la Flotte, la Sécurité du Conducteur et réduisent les coûts de Carburant. Les nouveaux modes de transport utilisant des drones changent également la manière dont nous transportons des 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 aux systèmes d’Ordonnancement et de routage back-end fournit la visibilité nécessaire pour améliorer le fonctionnement global de la Flotte. * Données du capteur environnementales. MQTT prend en charge le modèle de livraison des messages « au plus une fois ». Dans les réseaux à couverture partielle du territoire ou à forte latence, cela signifie que les informations peuvent être perdues ou dupliquées. Dans les zones où des capteurs distants enregistrent et transmettent des données à intervalles spécifiés, ce n’est pas un problème, puisque de nouvelles lectures sont reçues régulièrement. Les capteurs dans des environnements éloignés sont généralement des appareils à faible consommation, ce qui fait de MQTT une solution idéale pour les capteurs IoT dont la priorité de transfert de données est relativement faible. * Données de santé des machines : pour réagir 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 cette information n’arrive au centre de traitement des données. Dans de telles situations, la transmission des messages « au moins une fois » garantit que les drapeaux appropriés seront remarqués à temps par les spécialistes nécessaires, même s’ils arrivent en double. C’est important pour la communication de machine à machine avec une priorité plus élevée. * Systèmes de facturation : il existe même des messages plus prioritaires et plus précis qui doivent être traités correctement. Dans les situations d’entreprise où la duplication des enregistrements est inacceptable, y compris dans les systèmes de facturation, l’indicateur 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 économise la batterie lors de la messagerie entre téléphones mobiles, mais aussi parce qu’il permet de livrer efficacement les messages en quelques millisecondes, malgré des connexions Internet inégales à 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 qu’ils fonctionnent avec Navixy ### Configuration des appareils MQTT Xirgo et BCE Pour configurer l’appareil Xirgo et BCE afin qu’il fonctionne avec MQTT : * Dans FMSET : choisissez **Connectivité** → **Serveur de télémétrie** → **Paramètres d’adresse du broker MQTT** et indiquez l’hôte : [mqtt.eu.navixy.com](http://mqtt.eu.navixy.com/) pour le serveur UE et [mqtt.us.navixy.com](http://mqtt.us.navixy.com/) pour le serveur des États-Unis, port 1883. * Et ajoutez l’utilisateur par défaut dans **Sécurité MQTT** -> **Autorisation**\ ![MQTT device configuration](/files/5a4100349ca2201e7a70681486e48db4ead5adc2) ### Configuration de l’appareil MQTT Globalmatix Pour configurer l’appareil Globalmatix afin qu’il fonctionne avec MQTT : * Indiquez le serveur port 1883 pour l’UE et port 1883 pour les États-Unis * **Utilisateur/mot de passe**: globalmatix/secretword * **Sujet**: globalmatix/in Pour configurer l’appareil Globalmatix afin qu’il fonctionne avec MQTTS : * Indiquez **le serveur** port 8883 pour l’UE et port 8883 pour les États-Unis * **Utilisateur/mot de passe**: globalmatix/secretword * **Sujet**: globalmatix/in --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://navixy.com/docs/expert-center/fr/vehicle-telematics-technology/connectivity/mqtt-fundamentals.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.