MQTT (MQ Telemetry Transport)

⌚: 8 minutes

MQTT (MQ Telemetry Transport) est un protocole de messagerie léger qui fournit aux clients de réseaux à ressources limitées un moyen simple de distribuer des informations télémétriques. Le protocole, qui utilise un modèle de communication par publication/abonnement, est utilisé pour la communication de machine à machine (M2M) et joue un rôle important dans l’internet des objets (IoT).

Le protocole MQTT est un bon choix pour les réseaux sans fil qui connaissent des niveaux de latence variables en raison de contraintes occasionnelles de largeur de bande ou de connexions peu fiables.

Le protocole MQTT concerne deux sujets : un client et un courtier. Un courtier MQTT est un serveur, tandis que les clients sont les appareils connectés. Lorsqu’un appareil – ou un client – veut envoyer des données à un serveur – ou un courtier – on parle de publication. Lorsque l’opération est inversée, on parle d’abonnement.

Si la connexion entre un client abonné et un courtier est interrompue, le courtier met en mémoire tampon les messages et les transmet à l’abonné lorsqu’il est de nouveau en ligne. Si la connexion entre le client éditeur et le courtier est coupée sans préavis, le courtier peut alors fermer la connexion et envoyer aux abonnés un message en cache avec les instructions de l’éditeur.

Alors que le TT dans MQTT signifie Telemetry Transport, le MQ fait référence à un produit appelé IBM MQ.

Comment fonctionne le MQTT

Une session MQTT est divisée en quatre étapes : connexion, authentification, communication et terminaison. Un client commence par créer une connexion TCP/IP (Transmission Control Protocol/Internet Protocol) avec le courtier en utilisant soit un port standard, soit un port personnalisé défini par les opérateurs du courtier. Lors de la création de la connexion, il est important de savoir que le serveur peut poursuivre une ancienne session s’il est doté d’une identité client réutilisée.

Les ports standard sont 1883 pour les communications non cryptées et 8883 pour les communications cryptées – en utilisant le protocole SSL (Secure Sockets Layer)/TLS (Transport Layer Security). 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 de client au courtier pendant la poignée de main. Le courtier peut utiliser ce certificat pour authentifier le client. Bien que cela ne fasse pas spécifiquement partie de la spécification MQTT, il est devenu habituel pour les courtiers de prendre en charge l’authentification du client avec des certificats SSL/TLS côté client.

Le protocole MQTT étant destiné aux dispositifs à ressources limitées et aux dispositifs IoT, le protocole SSL/TLS n’est pas toujours une option et, dans certains cas, n’est pas souhaité. Dans ces cas-là, l’authentification est présentée sous la forme d’un nom d’utilisateur et d’un mot de passe en clair, qui sont envoyés par le client au serveur — ceci, dans le cadre de la séquence de paquets CONNECT/CONNACK. En outre, certains courtiers, en particulier les courtiers ouverts publiés sur Internet, acceptent les clients anonymes. Dans ce cas, le nom d’utilisateur et le mot de passe sont simplement laissés en blanc.

Le MQTT est appelé un protocole léger parce que tous ses messages ont une petite empreinte de code. Chaque message se compose d’un en-tête fixe (2 octets), d’un en-tête variable facultatif, d’une charge utile limitée à 256 mégaoctets (Mo) d’informations et d’un niveau de qualité de service (QoS).

Pendant la phase de communication, un client peut effectuer des opérations de publication, d’abonnement, de désabonnement et de ping. L’opération de publication envoie un bloc binaire de données – le contenu – à un sujet défini par l’éditeur.

Le MQTT prend en charge les objets binaires de grande taille (BLOB) des messages jusqu’à 256 Mo. Le format du contenu sera spécifique à l’application. Les abonnements aux sujets sont effectués en utilisant une paire de paquets SUBSCRIBE/SUBACK, et le désabonnement est effectué de la même manière en utilisant une paire de paquets UNSUBSCRIBE/UNSUBACK.

Les chaînes thématiques forment un arbre thématique naturel grâce à l’utilisation d’un caractère de délimitation spécial, la barre oblique (/). Un client peut s’abonner – et se désabonner – de branches entières de l’arbre à thèmes en utilisant un caractère spécial. Il existe deux caractères génériques : un caractère générique à un niveau, le caractère plus (+) ; et un caractère générique à plusieurs niveaux, le caractère dièse (#). Un caractère de remplacement spécial, le caractère dollar ($), exclut un sujet de tout abonnement à la racine. Généralement, le caractère $ est utilisé pour transporter des messages spécifiques au serveur ou au système.

Une autre opération qu’un client peut effectuer pendant la phase de communication consiste à envoyer un ping au serveur du courtier en utilisant une séquence de paquets PINGREQ/PINGRESP. Cette séquence de paquets se traduit en gros par ÊTES-VOUS VIVANT / OUI JE SUIS VIVANT. Cette opération n’a d’autre fonction que de maintenir une connexion active et de s’assurer que la connexion TCP n’a pas été interrompue par une passerelle ou un routeur.

Lorsqu’un éditeur ou un abonné souhaite mettre fin à une session MQTT, il envoie un message DISCONNECT au courtier et ferme ensuite la connexion. Cette fermeture est appelée « fermeture gracieuse » car elle permet au client de se reconnecter facilement en fournissant son identité et en reprenant là où il s’était arrêté.

Si la déconnexion se produit soudainement sans qu’un éditeur ait le temps d’envoyer un message de DISCONNECT, le courtier peut envoyer aux abonnés un message de l’éditeur que le courtier a précédemment mis en cache. Ce message, appelé testament, donne aux abonnés des instructions sur ce qu’ils doivent faire en cas de décès inattendu de l’éditeur.

Historique du protocole MQTT

Le MQTT a été créé par le Dr Andy Stanford-Clark d’IBM et Arlen Nipper d’Arcom – aujourd’hui Eurotech – en 1999. MQTT a été créé comme un moyen économique et fiable de connecter les dispositifs de surveillance utilisés dans les industries pétrolière et gazière aux serveurs d’entreprise distants. Lorsqu’il leur a fallu trouver un moyen de transmettre les données des capteurs des pipelines dans le désert à des systèmes de contrôle et d’acquisition de données (SCADA) hors site, ils ont décidé d’adopter une topologie de publication/abonnement basée sur TCP/IP qui serait pilotée par les événements afin de maintenir les coûts de transmission des liaisons par satellite à un niveau peu élevé.

Bien que le MQTT soit toujours étroitement associé à IBM, il s’agit désormais d’un protocole ouvert qui est supervisé par l’Organisation pour l’avancement des normes d’information structurées (OASIS).

Bien que son nom l’indique, MQTT ne fait pas partie de la série MQSeries originale d’IBM ; cependant, à partir de la version 7.1, il est disponible dans WebSphere MQ. MQTT était auparavant connu sous les noms de protocole SCADA, MQ Integrator SCADA Device Protocol (MQIsdp) et WebSphere MQTT (WMQTT), bien que toutes ces variantes soient tombées en désuétude.

Applications et cas d’utilisation du protocole MQTT

Facebook utilise actuellement MQTT pour son application Messenger, non seulement parce que le protocole permet d’économiser la batterie lors de la messagerie de téléphone e à téléphone, mais aussi parce que le protocole permet de délivrer efficacement des messages en quelques millisecondes (ms), malgré des connexions internet incohérentes à travers le monde.

Applications verticales du MQTT

La plupart des grands fournisseurs de services Cloud, dont Amazon Web Services (AWS), Google Cloud, IBM Cloud et Microsoft Azure, soutiennent MQTT.

Le MQTT est bien adapté aux applications utilisant des dispositifs M2M et IoT à des fins telles que l’analyse en temps réel, la maintenance préventive et la surveillance dans des environnements tels que les maisons intelligentes, les soins de santé, la logistique, l’industrie et la fabrication.

MQTT dans l’IoT

Le MQTT est l’un des protocoles les plus couramment utilisés en ce qui concerne l’IoT. MQTT permet aux dispositifs IoT à ressources limitées d’envoyer ou de publier des informations sur un sujet donné à un serveur qui fonctionne comme un courtier de messages MQTT. Le courtier transmet ensuite les informations aux clients qui se sont précédemment abonnés au sujet. Pour un humain, un sujet ressemble à un chemin de fichier hiérarchique. Les clients peuvent s’abonner à un niveau spécifique de la hiérarchie d’un sujet ou utiliser un caractère de remplacement pour s’abonner à plusieurs niveaux.

Par exemple, les plateformes Carriots, Evrything et ThingWorx IoT prennent en charge le protocole MQTT.

Protocoles concurrents

Parmi les autres protocoles de transfert qui entrent en concurrence avec le MQTT, on peut citer les suivants

Le protocole d’application sous contrainte (CoAP) est un autre protocole bien adapté à l’IoT. Le CoAP utilise également un modèle de communication requête/réponse.
L’Advanced Message Queuing Protocol (AMQP), comme le MQTT, utilise un modèle de communication de publication/abonnement.
Simple/Streaming Text Oriented Messaging Protocol (STOMP) est un protocole basé sur le texte. Toutefois, STOMP ne traite pas les files d’attente et les sujets ; il utilise une sémantique d’envoi avec une chaîne de destination.
Mosquitto est un courtier MQTT open source.
Le protocole SMCP (Simple Media Control Protocol) est une pile CoAP utilisée dans les environnements embarqués. Le SMCP est également basé sur le langage C.
SSI (Simple Sensor Interface) est un protocole de communication pour le transfert de données entre une combinaison d’ordinateurs et de capteurs.
Le service de distribution de données (DDS) pour les systèmes en temps réel est une norme d’intergiciel qui permet de publier directement ou de souscrire des communications en temps réel dans les systèmes embarqués.

Avantages et inconvénients du MQTT

Le MQTT présente quelques avantages et inconvénients distincts par rapport aux protocoles concurrents. Les avantages sont notamment les suivants :

une transmission de données efficace et rapide à mettre en œuvre grâce à la légèreté du protocole ;
une faible utilisation du réseau, en raison de la minimisation des paquets de données ;
une distribution efficace des données ;
la mise en œuvre réussie de la télédétection et du contrôle ;
une transmission rapide et efficace des messages ;
l’utilisation de petites quantités d’énergie, ce qui est bon pour les appareils connectés
réduction de la la bande passante utilisée

Les inconvénients potentiels du MQTT sont notamment les suivants :

Le MQTT a des cycles de transmission plus lents que le CoAP.
La découverte de ressources du MQTT fonctionne sur la base d’un abonnement à un sujet flexible, tandis que le CoAP utilise un système de découverte de ressources stable.
MQTT n’est pas crypté. Il utilise plutôt le TLS/SSL pour le cryptage de sécurité.
Il est difficile de créer un réseau MQTT à l’échelle mondiale.

Les défis du MQTT : Sécurité, interopérabilité et authentification

Le protocole MQTT n’ayant pas été conçu dans un souci de sécurité, il a traditionnellement été utilisé dans des réseaux dorsaux sécurisés à des fins spécifiques. La structure thématique du MQTT peut facilement former un énorme arbre, et il n’y a pas de moyen clair de diviser un arbre en domaines logiques plus petits qui peuvent être fédérés. Il est donc difficile de créer un réseau MQTT globalement évolutif, car plus la taille de l’arbre thématique augmente, plus la complexité s’accroît.

Un autre aspect négatif du MQTT est son manque d’interopérabilité. Les charges utiles des messages étant binaires, sans information sur la façon dont elles sont codées, des problèmes peuvent survenir, en particulier dans les architectures ouvertes où différentes applications de différents fabricants sont censées fonctionner de façon transparente les unes avec les autres.

Comme nous l’avons déjà mentionné, le MQTT comporte des fonctions d’authentification minimales intégrées au protocole. Les noms d’utilisateur et les mots de passe sont envoyés en clair, et toute forme d’utilisation sécurisée du MQTT doit utiliser SSL/TLS, qui n’est malheureusement pas un protocole léger.

L’authentification des clients par des certificats côté client n’est pas un processus simple, et le MQTT n’a aucun moyen de contrôler qui est propriétaire d’un sujet et qui peut publier des informations sur ce sujet, sauf en utilisant des moyens exclusifs et hors bande. Il est donc facile d’injecter des messages nuisibles dans le réseau, que ce soit délibérément ou par erreur.

En outre, le destinataire du message ne peut pas savoir qui a envoyé le message original, à moins que cette information ne soit contenue dans le message lui-même. Les fonctions de sécurité qui doivent être mises en œuvre en plus du MQTT de manière propriétaire augmentent l’empreinte du code et rendent les mises en œuvre plus difficiles.

Qualité des niveaux de service

La qualité de service est un accord entre l’expéditeur d’un message et le destinataire de ce message. La QoS définit la garantie de livraison en se référant à un message spécifique. La qualité de service est une caractéristique essentielle du MQTT, qui permet au client de choisir entre trois niveaux de service.

Les trois différents niveaux de qualité de service déterminent la manière dont le contenu est géré par le protocole MQTT. Bien que les niveaux de qualité de service plus élevés soient plus fiables, ils nécessitent plus de latence et de bande passante, de sorte que les clients abonnés peuvent spécifier le niveau de qualité de service le plus élevé qu’ils souhaitent recevoir.

Niveaux de qualité de service MQTT

Le niveau de qualité de service le plus simple est le service non reconnu. Ce niveau de QoS utilise une séquence de paquets PUBLISH ; l’éditeur envoie un message au courtier une fois, et le courtier transmet le message aux abonnés une fois. Il n’y a pas de mécanisme en place pour s’assurer que le message a été reçu correctement et le courtier ne sauvegarde pas le message. Ce niveau de qualité de service peut également être appelé au plus une fois, QoS0 ou fire and forget.

Le deuxième niveau de qualité de service est le service reconnu. Ce niveau de qualité de service utilise une séquence de paquets PUBLISH/PUBACK entre l’éditeur et son courtier, ainsi qu’entre le courtier 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 réessai enverra à nouveau le contenu original si un accusé de réception n’est pas reçu en temps voulu. L’abonné peut alors recevoir plusieurs copies du même message. Ce niveau de qualité de service peut également être désigné par l’expression « au moins une fois » ou « QoS1″.

Le troisième niveau de qualité de service est le service assuré. Ce niveau de qualité de service permet de délivrer le message avec deux paires de paquets. La première paire est appelée PUBLISH/PUBREC, et la seconde paire est appelée PUBREL/PUBCOMP. Ces deux paires garantissent que, quel que soit le nombre de tentatives, le message ne sera livré qu’une seule fois. Ce niveau de qualité de service peut également être appelé « une seule fois » ou « QoS2″.

Spécifications

Le MQTT a des spécifications différentes selon la version spécifique. La version 5.0 a remplacé la la version 3.1.1. Voici quelques spécifications plus récentes, telles que définies par l’OASIS :

l’utilisation de modèles de messages de publication/abonnement ;
un mécanisme qui peut avertir les utilisateurs en cas de déconnexions anormales ;
les trois niveaux de transmission des messages : au plus une fois, au moins une fois et une seule fois ;
la minimisation des frais généraux de transport et des échanges de protocoles pour réduire le trafic sur le réseau
un transport de messagerie agnostique faisant référence au contenu de la charge utile.

Mises à jour de MQTT

Le MQTT a été officiellement approuvé comme norme OASIS le 28 octobre 2015. Fin janvier 2016, il a été accepté comme norme de l’Organisation internationale de normalisation (ISO). Le protocole s’améliore constamment et prend désormais en charge les WebSockets, un autre protocole qui permet une communication bidirectionnelle entre les clients et les courtiers en temps réel. Par la suite, des versions notables ont inclus la norme v3.1.1 et la norme v5.0, toutes deux ayant été approuvées en tant que normes OASIS. À titre d’exemple de certaines de ses mises à jour, la version 5.0 comprenait de meilleurs rapports d’erreurs, notamment des métadonnées dans les en-têtes de message, des abonnements partagés, des expirations de message et de session, et des alias de sujets.