Définition et signification de MQTT (MQ Telemetry Transport)
MQTT (Message Queuing Telemetry Transport) est un protocole de messagerie efficace et léger conçu pour la communication à partir d’appareils dont les ressources ou la bande passante sont limitées comme l’Internet des objets (IdO). Il se fonde sur un protocole de transport qui active les connexions ordonnées et bidiréctionnelles, normallement en tant que TCP/IP, ainsi que dans QUIC (plus populaire dans le navigateur Chrome de Google), selon les standards de OASIS et les recommendations de ISO (ISO/IEC 20922).
Origine et but du protocole MQTT
Conçu par le Dr Andy Stanford-Clark et Arlen Nipper en 1999, MQTT a évolué pour devenir une norme fondamentale pour la transmission de données entre appareils connectés, tels que les capteurs de lumière, de mouvement, de température, de téléphones mobiles et d’ordinateurs. Sa standardisation par OASIS en 2013 a consolidé sa position en tant qu’outil clé dans le domaine de l’IoT. La simplicité, l’évolutivité et la capacité à fonctionner sur des réseaux de faible puissance ont contribué au succès continu de MQTT en facilitant une communication efficace dans divers environnements IoT.
Histoire et évolution de MQTT
Développement de MQTT jusqu’à la version actuelle, en tant que norme OASIS et ISO
À l’origine, MQTT a été inventé en 1999 pour l’industrie pétrolière et gazière, en raison de la nécessité d’un protocole avec une bande passante minimale et une perte de batterie minimale, afin de pouvoir superviser les oléoducs par satellite. À l’époque, le protocole s’appelait Transport de Télémétrie de Message Queue Server par le produit MQ Series d’IBM, qui fut le premier à l’accepter. Puis, en 2010, IBM a lancé MQTT 3.1 en tant que protocole gratuit et ouvert, afin que tout le monde puisse le mettre en œuvre. En 2013, l’Organisation pour l’avancement des normes d’information structurée (OASIS) a été envoyée à oasis pour normalisation.
En 2019, OASIS a lancé la version 5 de MQTT et a même converti l’acronyme en nom officiel du protocole IdO et reconnu comme norme ISO (ISO/IEC PRF 20922) du protocole de messagerie basé sur la publication/abonnement.
Fonctionnement de MQTT
Modèle de communication de publication/abonnement
Le protocole MQTT fonctionne selon les principes du modèle de publication ou d’abonnement. Dans la communication réseau traditionnelle, les clients et les serveurs communiquent directement entre eux, où les clients demandent des ressources ou des données au serveur, puis le serveur traite et envoie une réponse. Cependant, MQTT utilise un modèle de publication ou d’abonnement pour découpler l’expéditeur du message (éditeur), le destinataire du message (abonné), et un troisième composant, appelé agent de messagerie, contrôle la communication entre les éditeurs et les abonnés. Le travail de l’agent consiste à filtrer tous les messages entrants des éditeurs et à les distribuer correctement aux abonnés. L’agent découple les éditeurs et les abonnés de la manière suivante :
- Découplage spatial : L’éditeur et l’abonné ne connaissent pas l’emplacement du réseau de l’autre et n’échangent pas d’informations, telles que des adresses IP ou des numéros de port.
- Découplage temporel : Éditeur et abonné n’exécutent pas et n’ont pas de connectivité réseau en même temps.
- Découplage de synchronisation : Éditeurs et abonnés peuvent envoyer ou recevoir des messages sans s’interrompre mutuellement. En d’autres termes, l’abonné n’a pas à attendre que l’éditeur envoie un message.
Composants de MQTT : Client et agents
- Client MQTT : Tout appareil exécutant une bibliothèque MQTT. Si le client envoie des messages, c’est l’éditeur ; s’il reçoit des messages, c’est le destinataire.
- Agent MQTT : C’est le système back-end qui coordonne les messages entre les clients. Il est chargé de recevoir et de filtrer les messages, d’identifier les clients abonnés à chaque message et de leur envoyer les messages. Il est également responsable de l’autorisation et de l’authentification des clients MQTT, du transfert de messages vers d’autres systèmes pour l’analyse et le contrôle des messages perdus et des sessions client.
Processus de connexion et de communication entre les clients et les agents
Connexion MQTT : Les clients initient la connexion dans MQRR en envoyant un message de CONNEXION à l’agent. L’agent confirme la connexion établie avec un message CONNACK. Le client et l’agent ont besoin de TCP ou d’IP pour communiquer – ils ne se connectent pas les uns aux autres sans l’agent.
L’architecture de MQTT, contrôlée par des événements, se distingue par sa capacité à gérer des messages de petite taille et clairement définis. En outre, il introduit le concept de qualité de service (QoS) avec les niveaux 0, 1 et 2 (que nous expliquerons après dans la section des avantages), permettant d’adapter la livraison des messages aux besoins spécifiques de chaque application. Avec ces caractéristiques, MQTT se présente comme un protocole polyvalent et efficace pour la communication dans les environnements IdO, offrant une infrastructure robuste et évolutive.
Les sujets dans MQTT sont des chaînes hiérarchiques utilisées pour catégoriser les messages. Les abonnés peuvent filtrer les messages en s’abonnant à des sujets spécifiques, ce qui permet une distribution efficace des données. Ces thèmes sont organisés hiérarchiquement en utilisant le caractère “/” comme délimiteur, facilitant une structure ordonnée et compréhensible. Une caractéristique remarquable est la rétention des messages, en veillant à ce que les nouveaux abonnés reçoivent les dernières informations. De plus, MQTT intègre le concept de « dernière volonté et testament », fournissant une stratégie pour gérer les déconnexions inattendues en établissant un message prédéterminé à envoyer dans de telles situations. Ces éléments enrichissent la flexibilité et la fiabilité de MQTT, le consolidant comme un protocole polyvalent et robuste dans le contexte de l’Internet des objets (IdO).
Un autre aspect important est que MQTT se distingue par quatre actions principales qui constituent sa fonctionnalité centrale :
- Publier : Il permet aux clients d’envoyer des messages à un sujet spécifique, en partageant des informations pertinentes.
- S’abonner : Il permet aux clients de recevoir des messages d’un sujet donné, permettant une communication bidirectionnelle.
- Ping: Maintient la connexion entre les clients et les courtiers, assurant la validité et l’efficacité de l’échange d’informations.
- Déconnecter : Il permet aux clients de mettre fin à leur connexion de manière ordonnée.
Chacune de ces actions joue un rôle crucial dans le protocole MQTT, facilitant une communication agile et fiable dans l’environnement dynamique de l’Internet des objets (IdO).
Avantages et applications de MQTT
Avantages de l’utilisation de MQTT dans les environnements IdO et IdO industriel (IioT)
- Léger, avec un en-tête fixe de 2 à 5 octets, de sorte que son « poids » sur le réseau est léger. Non seulement la bande passante est optimisée lorsque de nombreux appareils sont connectés et envoient des messages simultanément, mais elle permet également d’être utilisée dans des zones où la connexion Internet est instable ou très limitée.
- Hautement compatible, étant une norme supportée par plusieurs appareils IoT utilisant ce protocole. Pour le mettre en œuvre, un code minimum est requis, ce qui est un avantage évident pour les appareils de différents fabricants ou à mémoire limitée.
- Fiable, avec trois niveaux de qualité de service (QoS, Quality of Service) :
- Niveau 0 (lancer et oublier). À ce niveau, chaque message est envoyé une fois à chaque abonné, sans attente de confirmation, ce qui réduit au maximum la bande passante. Le message n’est pas stocké. Si les clients sont déconnectés à ce moment-là, ils ne recevront pas le message, il est donc recommandé dans les cas où la perte du message n’est pas un problème.
- Niveau 1 (livré au moins une fois). Comme son nom l’indique, à ce niveau, le client doit confirmer le message reçu. L’avantage est que l’on s’assure que les messages sont tous délivrés au moins une fois. L’inconvénient est que plus de bande passante est utilisée et que le client peut recevoir des messages en double s’il tarde à confirmer sa réception.
- Niveau 2 (livrer une seule fois). C’est le niveau qui demande le plus de bande passante, bien que l’avantage soit qu’il est plus fiable car le client est attendu pour confirmer le message reçu et, avant de renvoyer un message, il pose la question si le message a été reçu. Ce niveau garantit que les clients n’ont reçu le message qu’une seule fois. En plus de ne pas consommer de bande passante, la certitude des messages reçus sans être dupliqués est donnée.
- Assure la sécurité,car il prend en charge des méthodes d’authentification telles que OAuth ou TLS 1.3, ce qui lui permet d’être utilisé sur des réseaux qui ne sont pas entièrement sécurisés.
- Informations pour l’analyse en temps réel, car il fournit des données en temps réel, ce qui est extrêmement utile pour la maintenance préventive et la supervision dans des environnements soit dans une maison intelligente, soit dans la logistique, la distribution et la fabrication.
- Ouvert, pris en charge par les principaux fabricants de cloud tels que AWS, Google Cloud, IBM Cloud, Oracle et Microsoft Azure.
Applications pratiques de MQTT dans diverses industries, telles que l’automobile, l’énergie et les télécommunications
Grâce à MQTT, IdO permet d’obtenir et de traiter des données pour gérer les données qui conduisent à prendre des décisions et des actions visant à la productivité et à l’optimisation des opérations dans divers secteurs de l’économie. Par exemple :
- Transport
Prise en charge des applications mobiles, en recommandant les véhicules disponibles les plus proches. - Fabrication
En interaction avec la robotique dans les cycles de fabrication ou la maintenance préventive. - Automobile
Avec les données de l’intelligence artificielle, il peut reconnaître et résoudre de manière autonome les lacunes de l’information humaine. - Energie
Contrôle à distance et automatisation de la distribution d’énergie. - Télécommunications
Fournir des services de connectivité mobile et réseau exceptionnels qui prennent en charge les applications mobiles de maison intelligente ou les systèmes de supervision en temps réel. - Santé
Supervision de l’état de bien-être grâce à une montre intelligente qui émet des données, permettant d’identifier les informations critiques du patient.
Inconvénients et défis de MQTT
Limites et défis de la sécurité, de l’interopérabilité et de l’authentification
L’un des inconvénients de MQTT est associé à des problèmes de sécurité potentiels, car le protocole ne dispose d’aucun mécanisme de sécurité tel que le cryptage ou l’authentification, ce qui expose les messages au risque d’être interceptés, modifiés ou usurpés par des pirates.
Un autre inconvénient provient du fait que le protocole peut être un point de défaillance unique, ce qui peut exposer le système IdO à des attaques ou à des perturbations.
Cela nous amène à recommander la mise en œuvre de mesures de sécurité supplémentaires, telles que le cryptage SSL/TLS, l’authentification des utilisateurs, les mots de passe ou les listes de contrôle d’accès. Il est de la plus haute importance de protéger les données et les appareils, qui sont les cibles privilégiées des cybercriminels.
Comparaison avec d’autres protocoles de transfert, tels que CoAP et AMQP
Il existe d’autres protocoles pour connecter des périphériques tels que CoaP (Constrained Application Protocol) et AMQP (Advanced Message Queuing Protocol, est le protocole de couche d’application standard ouvert pour les intergiciels orientés message). Par rapport à ceux-ci, MQTT présente quelques inconvénients :
MQTT contre CoAP :
- Cycles de transmission : MQTT a un cycle de transmission plus lent que CoAP.
- Prise en charge de RESTful (interface pour l’échange sécurisé d’informations sur Internet) : MQTT n’est pas RESTful (une API RESTful est une interface que deux systèmes informatiques utilisent pour échanger des informations en toute sécurité sur Internet), tandis que CoAP est RESTful.
- Découverte de ressources : MQTT fonctionne sur des abonnements de rubriques flexibles. CoAP dispose d’un mécanisme stable de découverte des ressources.
- Cryptage : MQTT n’est pas crypté, bien que vous puissiez utiliser TLS/SSL pour mettre en œuvre la sécurité et le cryptage. CoAP est alimenté par DTLS (Data Transport Layer Security).
MQTT contre AMQP :
- Modèles de message : Le protocole AMQP prend en charge un mécanisme de routage plus sophistiqué. Les messages sont d’abord acheminés vers un échangeur qui les achemine ensuite vers la bonne file d’attente, en utilisant des règles prédéfinies.
- Routage des messages : AMQP prend en charge plusieurs types d’échange avec des stratégies de routage uniques, ce qui permet à ce protocole de prendre en charge différents modèles de communication, tandis que MQTT est un mécanisme de routage de message simple.
- Polyvalence : AMQP offre plusieurs fonctionnalités en matière de persistance des messages et de transactionnalité. Cela le rend très polyvalent pour divers cas d’utilisation qui nécessitent plus de fonctionnalités.
Différences entre MQTT et REST en termes d’architecture et de modèle de communication
Pour comprendre la différence entre MQTT et REST, passons en revue ce qui suit :
La figure ci-dessus montre l’architecture MQTT, qui consiste en un intermédiaire centralisé où toutes les communications entre les périphériques (terminaux) passent par l’intermédiaire, et le broker peut être installé sur n’importe quel serveur public. Rappelons que MQTT est basé sur une architecture de publication/abonnement, où les périphériques peuvent publier des rubriques et s’abonner à n’importe quelle rubrique. Dans le protocole MQTT, un nom d’utilisateur et un mot de passe sont nécessaires pour établir la connexion.
REST (Representational State Transfer) est maintenant une interface permettant de connecter divers systèmes basés sur le protocole HTTP et utilisés pour obtenir et générer des données et des opérations, renvoyant des données dans des formats très spécifiques (e.g. XML et JSON).
Cette figure représente les protocoles REST. Voyez que REST est construit sur des couches HTTP/TCP. Le protocole REST utilise une architecture basée sur le bus, où aucun composant intermédiaire (broker) n’est nécessaire et où les périphériques (endpoints) peuvent communiquer directement. Dans ce cas, les messages de demande et de réponse sont utilisés entre les terminaux pour échanger les informations. Avec ceci, contrairement à MQTT, dans REST :
- Les messages sont GET, PUT, POST et DELETE.
- L’architecture est REQUEST/RESPONSE.
- Aucun courtier n’est requis, car la communication est directe.
- Le protocole de sécurité est HTTPS.
- L’interopérabilité est sémantique.
- Tolérance aux pannes du serveur dans SPoF (point de défaillance unique) : si une partie du système tombe en panne, le reste du système cesse de fonctionner.
Exploration de la façon dont la version 5 de MQTT introduit des fonctionnalités de type REST
La raison pour laquelle nous avons expliqué ce qui précède est que la version 5.0 de MQTT a maintenant des fonctionnalités similaires à REST, ce qui la rend plus robuste :
- Motifs de déconnexion : Vous pouvez désormais fournir un motif ou un code de motif pour chaque paquet d’accusé de réception, ce qui nous permet de mieux comprendre pourquoi une déconnexion ou une défaillance s’est produite.
- Avec MQTT 5.0, vous pouvez définir une période de temps spécifique pendant laquelle la session doit rester active après la déconnexion. Cela offre une plus grande flexibilité dans la gestion des durées de session et préserve les ressources sur le serveur.
- MQTT 5.0 introduit des alias de thème pour réduire les surcharges dans les en-têtes de message. Dans les versions précédentes, le nom du sujet devait être inclus dans chaque message, ce qui générait des paquets plus volumineux.
- Métadonnées personnalisées, qui permet aux utilisateurs d’inclure des métadonnées personnalisées dans les en-têtes des paquets MQTT. Cela peut être particulièrement utile pour les applications qui ont besoin d’envoyer des informations supplémentaires avec leurs messages MQTT, comme l’horodatage du message, l’emplacement de l’appareil ou une autre application.
- Options d’abonnement, pour spécifier comment recevoir des messages pour chaque thème abonné. Par exemple, les clients peuvent désormais spécifier s’ils souhaitent recevoir des messages en attente d’un abonnement particulier ou s’ils souhaitent recevoir des messages s’ils ont le même niveau de qualité de service (QoS) que l’abonnement.
- La fonction requête/réponse permet à un client de spécifier un sujet que le serveur peut utiliser pour envoyer une réponse directe. Cela rend la communication plus efficace et plus directe.
- Souscription commune ; en d’autres termes, lorsqu’un message est publié dans une rubrique partagée, le serveur distribue le message à l’un des clients de l’abonnement partagé, équilibrant ainsi la charge des messages.
Toujours dans cette version, les clients peuvent connecter des périphériques à l’aide de MQTT5 ou tirer parti d’une combinaison de périphériques connectés aux versions 3 et 5 de MQTT, interagissant les uns avec les autres pour prendre en charge des déploiements hétérogènes.
Sécurité MQTT
Implémentation de protocoles de sécurité tels que SSL/TLS pour protéger la communication dans MQTT
La sécurité dans MQTT est gérée à travers plusieurs couches pour assurer l’intégrité et la confidentialité de la communication dans l’Internet des objets (IdO). La première couche se concentre sur la sécurité du réseau, en mettant en œuvre des mesures pour protéger l’infrastructure sous-jacente. Bien que MQTT offre la possibilité d’utiliser des noms d’utilisateur et des mots de passe, il est crucial de noter que ces informations sont transmises en texte clair, ce qui présente un aspect à considérer en termes de confidentialité. De plus, il est possible de renforcer la sécurité grâce à l’utilisation de SSL/TLS, bien que cette option s’accompagne d’une surcharge supplémentaire. Prises ensemble, ces stratégies cherchent à trouver un équilibre entre l’accessibilité et la protection, en s’adaptant aux exigences spécifiques de chaque implémentation MQTT dans les environnements IdO.
Mises à jour dans MQTT v5.0
L’évolution de MQTT vers la version 5.0 a marqué une étape importante dans son développement. Publiée officiellement en 2019, cette norme a introduit des innovations significatives qui ont élargi sa polyvalence. Parmi les nouveautés les plus notables, on trouve les codes de motifs, qui offrent une plus grande clarté dans l’interprétation des événements. Les abonnements partagés constituent un moyen efficace de distribuer des messages à plusieurs abonnés, ce qui améliore l’évolutivité. L’expiration des messages permet un contrôle plus précis de la persistance des informations, en s’adaptant à divers scénarios d’application. De plus, l’ajout d’alias de rubrique simplifie la gestion et rationalise le partage des données. Ces mises à jour renforcent l’état de MQTT en tant que protocole dynamique et de pointe, capable de répondre aux exigences changeantes de l’Internet des objets (IdO) de manière efficace et efficiente.
Aspects liés à l’authentification, à l’autorisation et au chiffrement dans MQTT
Comme nous l’avons mentionné précédemment, l’utilisation de SSL/TLS nous aide à fournir l’authentification, le chiffrement et l’intégrité lors de l’utilisation du protocole MQTT. Autrement dit,
- Authentification : Celui qui envoie le message est celui qu’il prétend être.
- Chiffrement : Personne en chemin ne peut lire le message.
- Intégrité : Le message ne peut pas être modifié.
Cela se fait via une signature numérique (certificat) et des clés publiques et privées pour crypter et déchiffrer le message. Pour ajouter cela dans MQTT, les étapes suivantes sont :
- Créer un mot de passe public et un mot de passe privé pour autoriser la certification (CA).
- Créer un certificat pour la CA et signer avec le mot de passe privé précédemment généré.
- Générer un mot de passe public et un mot de passe privé pour le broker MQTT.
- Créer une exigence de signature de certificat pour les mots de passe de l’étape précédente.
- Utiliser le certificat de l’étape 2 pour signer l’exigence de l’étape précédente.
- Copier tous les certificats dans un répertoire du broker MQTT.
- Copier le certificat CA sur le client.
- Modifier la configuration du client pour qu’il utilise TLS et le certificat CA.
MQTT et WSS (MQTT sur WebSockets)
Description de MQTT sur WebSockets et sa mise en œuvre pour recevoir des données dans les navigateurs Web
Chaque navigateur peut être un périphérique MQTT avec MQTT sur Websockets, qui sont des protocoles qui permettent d’ouvrir une session de communication interactive entre le navigateur de l’utilisateur et un serveur. Ce protocole s’exécute sur Transport Layer Security (TLS) ou Secure Sockets Layer (SSL), fournissant un moyen sécurisé d’échanger des données. En utilisant WebSockets, directement dans un navigateur, vous pouvez atteindre l’efficacité de la communication, en envoyant des messages à un serveur et en recevant des réponses contrôlées par des événements sans avoir à consulter le serveur pour une réponse. C’est parce que le client et le serveur se connectent via l’URL WebSocket (il existe plusieurs paquets de contrôle MQTT dans une seule trame de données WebSocket).
Comparaison avec la communication standard de MQTT
À l’origine, WebSocket a été conçu pour les applications Web. Une caractéristique de WebSocket est qu’il maintient une connexion continue avec le serveur, ce qui permet une communication à faible latence par rapport aux autres architectures traditionnelles basées sur HTTP. Aussi, WebSocket révolutionne la communication en permettant la transmission de données en temps réel, au lieu de créer plusieurs connexions de courte durée pour chaque interaction. Face à la croissance rapide de l’utilisation des appareils IdO, la latence et l’évolutivité sont devenues plus critiques pour l’échange de données en temps réel.
Conclusions et considérations
Face à l’extension des infrastructures au-delà des datacenters dans les appareils et l’Internet des objets, MQTT offre les avantages d’être léger, fiable, compatible, ouvert et sécurisé. Maintenant que la version 5.0 est disponible, il est recommandé de faire une mise à jour. Pour effectuer ce processus de migration, il est recommandé ce qui suit :
1. Mettre à jour les courtiers MQTT, avec le plus grand soin afin de ne pas affecter tous les clients MQTT, de préférence dans un environnement autre que la production, avant de le mettre en œuvre.
2. Mettre à jour les librairies des clients, également d’abord dans un environnement non productif. Assurez-vous que le code de votre application est à jour pour gérer les nouvelles fonctionnalités de MQTT 5.0.
3. Aborder de nouvelles considérations de sécurité. Par exemple, avec la nouvelle fonction de propriété de l’utilisateur, les clients peuvent désormais envoyer des données personnalisées au courtier. Bien qu’il s’agisse d’une caractéristique puissante, elle peut être exploitée si elle n’est pas utilisée correctement. Il est donc important d’évaluer toutes les nouvelles fonctionnalités du point de vue de la sécurité.
4. Superviser après avoir effectué la migration. La supervision ne doit pas se limiter aux aspects techniques, tels que la livraison des messages ou les connexions des clients, mais l’utilisation des nouvelles fonctions MQTT 5.0 dans vos applications doit également être supervisée.
Et la recommandation que nous faisons toujours est de le combiner avec un expert en technologie et, de préférence, de comprendre les besoins particuliers du secteur auquel votre organisation appartient.
Un seul outil peut-il avoir une visibilité mondiale ?