Définition MQ Telemetry Transport

Definition_MQ_Telemetry_Transport.png
Definition_MQ_Telemetry_Transport.png

Définition MQ Telemetry Transport

939 lecteurs
Sommaire de l'article

MQTT (MQ Telemetry Transport) 8 minutes

MQTT (MQ Telemetry Transport) est un protocole de messagerie léger qui permet aux clients des réseaux à ressources limitées de partager facilement des informations de télémétrie. Ce protocole, qui utilise le modèle de communication publier/abonner, est utilisé pour faciliter la communication de machine à machine (M2M) et joue un rôle clé dans l’Internet des objets (IoT).

Le protocole MQTT est une excellente option pour les réseaux sans fil présentant divers niveaux de latence en raison de limitations intermittentes de la bande passante ou de connexions instables.

Le protocole MQTT se compose de deux entités : un client et un courtier. Un courtier MQTT fait office de serveur et les clients sont les appareils auxquels il est connecté. Lorsqu’un dispositif – ou un client – doit transférer des données à un courtier ou à un intermédiaire, on parle de publication. Si le processus est inversé, il s’agit d’un abonnement.

Si la connexion entre le client abonné et le courtier est rompue, le courtier met les messages en mémoire tampon et les transmet à l’abonné dès qu’elle est rétablie. Si la connexion entre le client éditeur et le courtier est coupée sans préavis, le courtier peut mettre fin à la connexion et envoyer ensuite aux abonnés un message mis en cache avec les instructions de l’éditeur.

Le T de MQTT signifie Telemetry Transport, le MQ fait référence à un produit spécifique connu sous le nom de IBM MQ.

Comment fonctionne MQTT

Une session MQTT est divisée en quatre phases : la connexion au courtier, l’authentification, la communication et la phase finale. Un client commence par établir une connexion TCP/IP (Transmission Control Protocol/Internet Protocol) avec le courtier, en utilisant soit un port ordinaire, soit un port personnalisé défini par les administrateurs du courtier. Lors de la connexion, il est important de savoir que le serveur peut poursuivre une ancienne session, s’il possède une identité réutilisée par le client.

Les ports les plus courants sont 1883 pour les communications non cryptées et 8883 pour les communications cryptées à l’aide de Secure Sockets Layer (SSL)/Transport Layer Security (TLS). Lors de la poignée de main SSL/TLS, le client confirme le certificat du serveur et authentifie également le serveur. Le client est également en mesure de fournir un certificat du client au courtier au cours du processus de prise de contact. Les courtiers peuvent alors utiliser le certificat pour vérifier ce client. Bien que cela ne soit pas spécifiquement inclus dans la spécification MQTT, il est désormais habituel pour les courtiers de fournir une authentification du client en utilisant des certificats SSL/TLS côté client.

Comme MQTT est conçu pour les appareils IoT à ressources limitées, SSL/TLS n’est pas toujours une alternative viable et, dans certaines situations, n’est pas souhaitable. Dans ces cas, l’authentification est assurée par le nom d’utilisateur et le mot de passe en clair qui sont transmis du client au serveur dans le cadre de la séquence CONNECT/CONNACK. En outre, certains courtiers, y compris les courtiers ouverts disponibles sur Internet, acceptent les clients anonymes. Dans ce cas, le nom d’utilisateur et le mot de passe ne sont pas renseignés.

MQTT est connu comme un protocole léger, car tous les messages qu’il envoie ont une empreinte minimale dans le code. Chaque message est composé d’un en-tête initial (2 octets), d’un en-tête variable et d’une charge utile limitée à 256 mégaoctets (Mo) d’informations, ainsi que du niveau de qualité de service (QoS).

Pendant la phase de communication, le client peut effectuer des opérations de publication, d’abonnement, de désabonnement ou de ping. L’opération de publication transmet un bloc de données unicode qui est le contenu à un sujet spécifié par l’éditeur.

MQTT peut prendre en charge les grands objets binaires (BLOB) de messages jusqu’à 256 mégaoctets. Le format des données sera spécifique à l’application. Les abonnements aux sujets sont exécutés avec une combinaison SUBSCRIBE/SUBACK et le désabonnement se fait de la même manière avec une paire UNSUBSCRIBE/UNSUBACK.

Voir Aussi  EDULine Lille : connexion à l’intranet de l’académie sur eduline.ac-lille.fr

Les chaînes thématiques permettent de créer un arbre thématique organique en utilisant un caractère délimiteur particulier, une barre oblique. (/). Un utilisateur peut s’abonner et se désabonner de branches entières de l’arbre en utilisant un caractère particulier. Deux caractères génériques sont disponibles : un caractère générique à un niveau et le signe plus (+) ; et un caractère générique à plusieurs niveaux appelé le signe dièse. (#). Un caractère générique spécial, appelé symbole du dollar ($), permet d’exclure une personne des abonnements aux racines. Généralement, le symbole $ est utilisé pour transmettre des messages spécifiques à un serveur ou à un système.

Une autre option qu’un client peut exécuter pendant la communication est de se connecter au serveur du courtier avec la séquence de paquets PINGREQ/PINGRESP. Cette séquence de paquets se traduit grossièrement par ARE YOU ALIVE/ Oui, je suis vivant. Cette opération n’a d’autre but que de s’assurer qu’une connexion est active et de vérifier que la connexion TCP n’a pas été supprimée par une passerelle ou un routeur.

Si un abonné ou un éditeur souhaite couper une connexion MQTT et se déconnecter, il peut envoyer un signal DISCONNECT au broker et fermer la connexion. Cette fermeture est connue sous le nom de « fermeture gracieuse «  car elle permet au client de se reconnecter facilement en prouvant son nom et en identifiant l’endroit où il s’était arrêté.

Si la déconnexion se produit soudainement sans que l’éditeur ait le temps de communiquer un message de DISCONNECT aux abonnés, le courtier pourrait envoyer aux abonnés un message électronique de l’éditeur, que le courtier avait préalablement enregistré. Ce message, appelé testament, donne aux abonnés des indications sur ce qu’ils peuvent faire en cas de décès soudain de l’éditeur.

L’histoire du protocole MQTT

MQTT a été développé par le Dr Andy Stanford-Clark d’IBM ainsi que par Arlen Nipper d’Arcom qui est maintenant Eurotech en 1999. MQTT a été conçu comme une méthode abordable et fiable pour connecter les dispositifs de surveillance de l’industrie pétrolière et gazière aux serveurs d’entreprise situés dans des lieux éloignés. Lorsqu’ils ont eu besoin d’un moyen de transférer des informations depuis des capteurs de pipelines dans le désert vers des systèmes de contrôle et d’acquisition de données (SCADA) hors site, ils ont décidé d’utiliser la topologie de publication/abonnement basée sur TCP/IP qui est pilotée par les événements, ce qui permet de réduire le coût de la transmission par satellite.

Bien que MQTT soit toujours étroitement lié à IBM, il s’agit désormais d’une norme ouverte, gérée par l’Organization for the Advancement of Structured Information Standards (OASIS).

Bien que son nom l’indique, MQTT ne fait pas partie de la série MQ d’origine d’IBM, mais dans sa version 7.1, il est désormais inclus dans WebSphere MQ. MQTT était auparavant connu sous le nom de protocole SCADA, MQ Integrator SCADA Device Protocol (MQIsdp) et WebSphere MQTT (WMQTT), mais toutes ces versions ont été abandonnées.

Applications et cas d’utilisation du protocole MQTT

Facebook utilise actuellement le protocole MQTT pour exécuter son application Messenger, et pas seulement parce qu’il permet d’économiser la batterie lors de l’utilisation de la messagerie de téléphone à téléphone, mais aussi parce qu’il permet d’envoyer des messages en quelques millisecondes (ms), même en cas d’incohérence des connexions Internet à travers le monde.

Applications verticales MQTT

La majorité des grands fournisseurs de services en nuage, dont Amazon Web Services (AWS), Google Cloud, IBM Cloud et Microsoft Azure, prennent en charge MQTT.

MQTT est bien adapté aux applications qui utilisent des gadgets M2M et IoT pour servir d’analyse en temps réel, de maintenance préventive et de surveillance dans des environnements tels que les maisons intelligentes, les soins de santé, la fabrication, la logistique et l’industrie.

MQTT dans l’IoT

MQTT est l’un des protocoles les plus utilisés dans l’IoT. MQTT permet aux dispositifs IoT à ressources limitées de publier ou d’envoyer des informations sur un sujet spécifique à un serveur qui agit comme un courtier de messages MQTT. Le courtier relaie ensuite les informations aux utilisateurs qui ont déjà été abonnés à ce sujet. Pour les humains, le sujet semble être un chemin de fichier hiérarchique. Les clients peuvent s’abonner à une section particulière de la hiérarchie d’un sujet, ou l’utiliser comme substitut pour s’abonner à plusieurs niveaux.

Voir Aussi  Intelligence artificielle des choses (AIoT)

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

Protocoles concurrents

Les autres protocoles de transfert qui sont en concurrence avec MQTT comprennent .

  • Le protocole CoAP (Constrained Application Protocol ) est un autre protocole conçu pour l’IoT. CoAP utilise également un modèle de communication de type demande/réponse.
  • Advanced Message Queuing Protocol (AMQP), similaire à MQTT, utilise un modèle de communication par publication/abonnement.
  • Simple/Streaming Text Oriented Messaging Protocol (STOMP) est un protocole basé sur le texte. Cependant, STOMP ne traite pas de sujets ou de files d’attente. Il utilise la sémantique de l’envoi avec une chaîne d’adresses.
  • Mosquitto est un courtier MQTT à code source ouvert.
  • Simple Media Control Protocol (SMCP) est une pile CoAP qui est utilisée pour les systèmes embarqués. SMCP est également construit sur le langage C.
  • CSSI (Simple Sensor Interface) est un protocole utilisé pour l’échange de données entre un ensemble de capteurs et des ordinateurs.
  • Data Distribution Service (DDS) for Real-Time Systems est une norme d’intergiciel qui permet la publication ou l’abonnement direct à la communication en temps réel dans les systèmes embarqués.

Les avantages et les inconvénients de MQTT

MQTT présente des avantages et des inconvénients uniques par rapport aux autres protocoles. Les avantages de MQTT sont nombreux, notamment :

  • une transmission de données rapide et efficace, grâce à la légèreté du protocole.
  • Utilisation insuffisante du réseau en raison de la lenteur des paquets de données.
  • une distribution efficace des données ;
  • le déploiement réussi de la télésurveillance et de la télédétection ;
  • la transmission rapide et efficace des messages ;
  • l’utilisation de petites quantités d’électricité, ce qui peut être bénéfique pour les appareils connectés.
  • Réduction de la bande passante utilisée

Les inconvénients possibles de MQTT pourraient être les suivants :

  • MQTT a des temps de transmission plus faibles que CoAP.
  • La découverte des ressources de MQTT fonctionne sur la base d’un abonnement par sujet, alors que CoAP utilise un mécanisme de découverte des ressources établi.
  • MQTT n’est pas sécurisé. Au lieu de cela, il utilise TLS/SSL pour sécuriser le cryptage.
  • Il n’est pas facile d’établir un réseau MQTT mondial.

Sécurité, interopérabilité et authentification MQTT

Le protocole MQTT n’ayant pas été développé pour être sécurisé, il a généralement été employé pour sécuriser des réseaux dorsaux pour des raisons spécifiques. La structure thématique de MQTT est capable de former un énorme arbre et il n’existe pas de méthode claire pour diviser l’arbre en domaines plus petits pouvant être connectés. C’est pourquoi il est difficile de construire un réseau MQTT évolutif à l’échelle internationale, car lorsque la taille de l’arbre augmente, la complexité croît.

Un autre problème avec MQTT est le manque d’interopérabilité. Les messages étant binaires, sans aucune information sur la manière dont ils sont codés, des problèmes peuvent survenir, en particulier dans les architectures ouvertes, où les logiciels de différents fournisseurs sont censés coopérer de manière transparente les uns avec les autres.

Comme nous l’avons mentionné précédemment, MQTT dispose de fonctions d’authentification minimales qui sont intégrées au protocole. Les mots de passe et les noms d’utilisateur sont transmis en clair et toute utilisation de MQTT à des fins de sécurité nécessite SSL/TLS, qui n’est malheureusement pas un protocole léger.

Les certificats côté client pour l’authentification ne sont pas une procédure simple et MQTT ne peut pas être en mesure de s’assurer qui possède un sujet particulier et qui peut libérer des informations sur le sujet autrement que par des méthodes propriétaires, hors bande. Cela permet d’injecter facilement des messages dangereux sur le réseau, que ce soit intentionnellement ou accidentellement.

En outre, le récepteur du message n’est pas en mesure de déterminer qui a envoyé le message, à moins que l’information ne soit incluse dans le message. Les fonctions de sécurité qui doivent être ajoutées à MQTT d’une manière spécifique créent une plus grande empreinte pour le code et peuvent rendre la mise en œuvre plus difficile.

Voir Aussi  CGOS espace agent : comment se connecter à mon compte

Les niveaux de qualité de service

La qualité de service fait référence à un contrat entre la partie qui envoie un courriel et le destinataire du message. La QoS définit l’assurance de livraison en se référant à un message spécifique. La QoS est l’une des principales caractéristiques de MQTT qui permet à l’utilisateur de choisir trois types de service.

Trois niveaux de QoS différents affectent la manière dont le contenu est traité par le protocole MQTT. Si les niveaux de QoS les plus élevés sont plus sûrs, ils nécessitent davantage de bande passante et de latence. Les abonnés peuvent donc choisir le niveau de QoS le plus fiable qu’ils souhaitent recevoir.

Niveaux de qualité de service MQTT

La QoS la plus simple est un service qui ne fait pas l’objet d’un accusé de réception. Ce niveau de QoS utilise la séquence de paquets PUBLISH. L’éditeur envoie une fois un message au courtier et le courtier envoie ensuite une fois le message aux abonnés. Il n’y a aucun moyen de garantir que le message a été reçu de manière correcte et le courtier ne conserve pas le message. Ce type de qualité de service pourrait également être décrit comme étant, tout au plus, QoS0 ou « fire and forget ».

Le degré suivant de QoS est celui de l’accusé de réception. Ce niveau de QoS utilise la séquence PUBLISH/PUBACK entre l’éditeur et son courtier et également entre le courtier et les abonnés. Un paquet d’accusé de réception confirme que le contenu a été reçu et une fonction de réessai renvoie le contenu original au cas où un accusé de réception n’est pas reçu rapidement. L’abonné recevra plusieurs copies du message exact. Ce niveau de QoS pourrait être décrit comme « au moins une fois » ou  » QoS1″.

Le troisième niveau de QoS est le service assuré. Ce type de QoS permet de transmettre des messages à l’aide de deux paquets. La première paire est connue sous le nom de PUBLISH/PUBREC. La seconde paire est connue sous le nom de PUBREL/PUBCOMP. Ces deux paires garantissent que, quel que soit le nombre de fois, les messages ne seront délivrés qu’une seule fois. Cette qualité de service est également décrite comme  » one time only » ou  » QoS2″.

Spécifications

MQTT a des spécifications différentes en fonction de la version. La version 5.0 a remplacé la version 3.1.1. Voici les spécifications les plus récentes qui sont spécifiées par OASIS :

  • l’utilisation de messages modèles pour la publication et l’abonnement ;
  • Un mécanisme qui alerte les utilisateurs en cas de déconnexions anormales ;
  • les trois étapes de transmission des messages : au minimum une seule fois, et au moins une fois
  • la réduction des frais généraux dans le transport et les échanges de protocoles afin de diminuer la quantité de trafic sur les réseaux.
  • Transport de messagerie agnostique en termes de contenu qui fait référence au contenu de la charge utile.

Mises à jour MQTT

MQTT a été officiellement reconnu comme une norme OASIS le 28 octobre 2015. À la fin du mois de janvier 2016, il a été reconnu comme une norme de l’Organisation internationale de normalisation (ISO). Le protocole s’améliore continuellement et est maintenant compatible avec WebSockets qui est un protocole différent qui permet une communication bidirectionnelle entre les brokers et les clients en temps réel. Les versions les plus récentes comprennent la v3.1.1 et la v5.0, qui ont toutes deux été acceptées comme normes OASIS. Parmi les améliorations apportées, la v5.0 comprend un meilleur signalement des erreurs, ainsi que des métadonnées dans les en-têtes des messages, des abonnements partagés, des expirations de messages et de sessions, ainsi que des alias de sujets.

4.9/5 - (27 votes)
Marine
Marine

Passionnée par l'entreprenariat depuis plus de 10 ans, je suis à la tête d'une société française visant à favoriser la communication des entreprises. Également attiré par la finance, je partage mes conseils et expériences au travers mes articles de blog.

Retour en haut