Fondamentaux de MQTT
Protocole publish/subscribe qui alimente la communication légère des appareils IoT. Couvre la configuration du broker MQTT, les formats de message, les niveaux de QoS et les cas d’usage en télématique.
Le protocole Transport de télémétrie par file d’attente des messages (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 l’informatique en périphérie, et Rapport des capteurs d'information font désormais partie de la vie quotidienne. Une croissance aussi intensive pousse à chercher des moyens de transférer les données efficacement.
Qu’est-ce que MQTT
Andy Stanford-Clark (IBM) et Arlen Nipper (qui travaillait alors pour 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 peu gourmand en batterie, car les appareils étaient connectés par liaison satellite, qui, à l’époque, était extrêmement coûteuse. À l’heure actuelle, la plupart des appareils utilisent la version 5.0.
Le Transport de télémétrie par file d’attente des messages (MQTT) est un protocole réseau léger de publication-abonnement qui transporte des messages entre des 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 vers des sites distants où une « petite empreinte logicielle » 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 compact et léger. Il est idéal pour les appareils à faible consommation électrique et à autonomie de batterie limitée. Désormais, cela inclut les smartphones, ainsi qu’un nombre toujours croissant de capteurs et Rapport des capteurs d'information.
Ainsi, MQTT est devenu un protocole de diffusion de données entre des appareils à puissance CPU et/ou autonomie de batterie limitées, ainsi que pour les réseaux à bande passante coûteuse ou faible, à 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 sur Bluetooth, UDP, ZigBee et sur d’autres réseaux IoT autres que TCP/IP.
Comment ça marche
Le modèle de publication et d’abonnement
Il existe 2 définitions principales dans MQTT : broker MQTT 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 « sujet », 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és un-à-plusieurs). De même, plusieurs éditeurs peuvent publier des sujets vers un seul abonné (plusieurs-à-un).
Un client MQTT est tout 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 connexion TCP/IP simple ou une connexion TLS chiffrée pour les messages sensibles.
Le client publie des messages sous un sujet en envoyant le message et le sujet au broker.
Le broker transmet ensuite le message à tous les clients abonnés à ce sujet.
Étant donné que les messages MQTT sont organisés par sujets, le développeur de l’application peut spécifier que certains clients ne peuvent interagir qu’avec certains messages. Par exemple, les capteurs publieront leurs relevés sous le sujet « sensor_data » et s’abonneront au sujet « config_change ». Les applications de traitement des données qui enregistrent les Données du capteur dans une base de données backend s’abonneront au sujet « 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 sur le sujet « config_change ».
Types de messages MQTT
Une session MQTT est divisée en quatre étapes : connexion, authentification, communication et terminaison. Un client commence par établir 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 reçoit une identité de 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)/Sécurité de la couche transport (TLS). Lors de l’établissement de liaison 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’établissement de liaison. 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 courant que les brokers prennent en charge l’authentification des clients à l’aide de certificats SSL/TLS côté client.
Comme 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, peut ne pas être souhaité. Dans de telles circonstances, l’authentification se présente sous la forme d’un nom d’utilisateur et d’un mot de passe en texte clair, envoyés par le client au serveur - ceci dans le cadre de la séquence de paquets CONNECT/CONNACK. En outre, certains brokers, en particulier les brokers ouverts publiés sur Internet, accepteront 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 empreinte logicielle réduite. Le paquet se compose d'un en-tête fixe de 2 octets + d'un en-tête variable et d'une charge utile. Dans ces 2 premiers octets, l'en-tête fixe sera 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.
Dans l'en-tête fixe de 2 octets, 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 qui sera effectuée : le client souhaite s'abonner au sujet, 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 de publication ; 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 + la longueur 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 supplémentaires ou des indicateurs, et ils varient selon le type de paquet. Un identifiant de paquet est présent dans la plupart des types de paquets.
Enfin, le paquet peut contenir une charge utile. La charge utile est elle aussi facultative 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 « 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 son destinataire. 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 de latence et des besoins en bande passante plus élevés ; 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'émetteur envoie un message au broker MQTT une fois, et le broker MQTT transmet le message aux abonnés une fois. Aucun mécanisme n'est prévu pour s'assurer que le message a été reçu correctement, et le broker MQTT n'enregistre pas le message. Ce niveau de QoS peut également être appelé au plus une fois, QoS0 ou envoyer et oublier.
Le deuxième niveau de QoS est un service acquitté. 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'acquittement vérifie que le contenu a été reçu, et un mécanisme de réessai renverra le contenu d'origine si un acquittement n'est pas 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 délivre le message avec deux paires de paquets. La première paire s'appelle PUBLISH/PUBREC, et la deuxième paire s'appelle PUBREL/PUBCOMP. Les deux paires garantissent que, quel que soit le nombre de réessais, le message ne sera dé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 type de paquet. La charge utile du protocole MQTT peut transporter tout type de données, comme des données binaires, du texte ASCII, etc. Le récepteur 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 de batterie plus faible.
C'est un protocole fiable, car il utilise des options de QoS pour garantir une remise assurée.
Grâce à 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 des communications distribuées un-à-plusieurs et des applications distinctes.
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 missions de communication de base.
Conçu pour délivrer 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 le streaming vidéo.
Problèmes de latence.
Sécurité n’est pas intégrée. MQTT est non chiffré. Au lieu de cela, il utilise TLS/SSL (Transport Layer Security/Secure Sockets Layer) pour le chiffrement de la Sécurité.
Un broker centralisé peut constituer un point de défaillance, car les connexions clientes avec les brokers restent 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 s’est imposé comme une solution ouverte, simple et évolutive pour 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. De nouveaux modes de transport utilisant des drones transforment également notre manière de déplacer les marchandises. La connectivité entre un appareil mobile utilisé par l’opérateur, les informations de télémétrie directement provenant du véhicule et l’intégration dans les systèmes d’Ordonnancement et de routage en back-end fournit la visibilité nécessaire pour améliorer l’exploitation globale de la Flotte.
Données du capteur environnemental. MQTT prend en charge le modèle de livraison des messages « pas plus d’une fois ». Dans les réseaux avec une couverture partielle du territoire ou une latence élevée, 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 définis, cela ne pose pas de problème, car 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 avec une priorité de transfert de données relativement faible.
Données d’état des machines : pour réagir rapidement aux problèmes émergents et prévenir 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’arrivent au 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 en temps voulu par les spécialistes nécessaires, même s’ils arrivent en double. Cela est important pour la communication de machine à machine avec une priorité plus élevée.
Systèmes de facturation : il existe des messages encore plus prioritaires et plus précis qui doivent être traités correctement. Dans les situations professionnelles où la duplication des enregistrements est inacceptable, y compris dans les systèmes de facturation, le drapeau QoS de transmission « exactement une fois » est utile. Cela élimine la duplication ou la perte des 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 l’autonomie de la batterie lors des échanges de téléphone à téléphone, 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 des appareils MQTT pour fonctionner avec Navixy
Configuration des appareils MQTT Xirgo et BCE
Pour configurer l’appareil Xirgo et BCE pour fonctionner avec MQTT :
Dans FMSET : Choisissez Connectivité → Serveur de télémétrie → Paramètres de l'adresse du broker MQTT et spécifiez l’hôte : mqtt.eu.navixy.com pour le serveur UE et mqtt.us.navixy.com pour le serveur US, port 1883.
Et ajoutez l’utilisateur par défaut dans Sécurité MQTT -> Autorisation
Configuration de l’appareil MQTT Globalmatix
Pour configurer l’appareil Globalmatix pour fonctionner avec MQTT :
Indiquez le serveur http://mqtt.navixy.com port 1883 pour l’UE et http://mqtt.us.navixy.com port 1883 pour les États-Unis
Utilisateur/mot de passe: globalmatix/secretword
Sujet: globalmatix/in
Pour configurer l’appareil Globalmatix pour fonctionner avec MQTTS :
Indiquez le serveur http://mqtt.navixy.com port 8883 pour l’UE et http://mqtt.us.navixy.com port 8883 pour les États-Unis
Utilisateur/mot de passe: globalmatix/secretword
Sujet: globalmatix/in
Mis à jour
Ce contenu vous a-t-il été utile ?