Le protocole Message Queuing Telemetry Transport (MQTT) est utilisé depuis de nombreuses années, mais il est maintenant 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 l'informatique de pointe, et les appareils avec transmission de données continue font partie du quotidien de la vie.
Cela signifie que les protocoles légers, ouverts et abordables deviendront encore plus importants au fil du temps. Cet article propose une immersion conceptuelle dans MQTT: comment cela fonctionne, comment il est utilisé maintenant et comment il sera utilisé à l'avenir.
Petite introduction
MQTT est un protocole de messagerie basé sur un éditeur-abonné (pub / sub). La version initiale en 1999 a été
publiée par Andy Stanford-Clark d'IBM et Arlene Nipper de Cirrus Link. Ils ont considéré MQTT comme un moyen de maintenir la communication entre les machines dans des réseaux à bande passante limitée ou des communications imprévisibles. L'une des premières options pour son utilisation était de s'assurer que les fragments du pipeline étaient en contact les uns avec les autres et avec les liaisons centrales via des satellites.
Compte tenu des conditions de fonctionnement difficiles, le protocole est rendu petit et léger. Il est idéal pour les appareils à faible consommation et avec une autonomie limitée. Ceux-ci incluent désormais les smartphones omniprésents et le nombre toujours croissant de capteurs et d'appareils connectés.
Ainsi, MQTT est devenu un protocole pour diffuser des données entre des appareils avec une puissance CPU et / ou une autonomie de batterie limitées, ainsi que pour des réseaux à bande passante coûteuse ou faible, à stabilité imprévisible ou à latence élevée. C'est pourquoi MQTT est connu comme le véhicule idéal pour l'IoT. Il est construit sur le protocole TCP / IP, mais il existe une branche MQTT-SN pour travailler via Bluetooth, UDP, ZigBee et d'autres réseaux IoT autres que TCP / IP.
MQTT n'est pas le seul protocole de messagerie pub / sub en temps réel de ce type, mais il a déjà été largement accepté dans divers environnements qui dépendent des communications de machine à machine. Parmi ses pairs figurent
le protocole de messagerie des applications Web, le protocole de messagerie orientée texte et le protocole alternatif de Message Queuing .
MQTT est le choix logique pour les développeurs qui souhaitent créer des applications avec des fonctionnalités fiables et une large compatibilité avec les appareils et applications connectés à Internet, y compris les navigateurs, les smartphones et les appareils IoT.
Comment fonctionne MQTT: les bases
Le système de communication construit sur MQTT se compose d'un serveur éditeur, d'un serveur courtier et d'un ou plusieurs clients. L'éditeur ne requiert aucun paramètre pour le nombre ou l'emplacement des abonnés qui reçoivent des messages. De plus, les abonnés n'ont pas besoin de syntoniser un éditeur spécifique. Il peut y avoir plusieurs courtiers de messages dans le système.
MQTT fournit un moyen de créer une hiérarchie de canaux de communication - une sorte de branche avec des feuilles. Chaque fois que l'éditeur a de nouvelles données à distribuer aux clients, le message est accompagné d'un bon de livraison. Les clients de niveau supérieur peuvent recevoir chaque message, tandis que les clients de niveau inférieur peuvent recevoir des messages liés à un ou deux canaux de base seulement, des «branches» au bas de la hiérarchie. Cela facilite l'échange d'informations dont la taille varie de deux octets
à 256 mégaoctets .
Un exemple de la façon dont vous pouvez configurer le client pour se connecter via le
courtier MQTT :
var options = { keepalive: 60, username: 'FIRST_HALF_OF_API_KEY', password: 'SECOND_HALF_OF_API_KEY', port: 8883 }; var client = mqtt.connect('mqtts:mqtt.ably.io', options);
Toutes les données publiées ou reçues par le courtier MQTT seront encodées au format binaire, car MQTT est un protocole binaire. Cela signifie que pour obtenir le contenu original, vous devez interpréter le message. Voici à quoi cela ressemble avec Ably et JavaScript:
var ably = new Ably.Realtime('REPLACE_WITH_YOUR_API_KEY'); var decoder = new TextDecoder(); var channel = ably.channels.get('input'); channel.subscribe(function(message) { var command = decoder.decode(message.data); });
Les courtiers MQTT peuvent parfois accumuler des messages liés à des canaux qui n'ont pas d'abonnés actuels. Dans ce cas, les messages seront rejetés ou enregistrés, selon les instructions du message de contrôle. Cela est utile dans les cas où les nouveaux abonnés peuvent avoir besoin du dernier point de données enregistré, plutôt que d'attendre le prochain envoi.
Il est à noter que MQTT transmet les informations d'identification de sécurité en texte clair, sinon les fonctions d'authentification ou de sécurité ne sont pas prises en charge.
C'est là que le cadre SSL entre en jeu , aidant à protéger les informations transmises contre toute interception ou falsification.
De plus, dans MQTT, vous pouvez utiliser l'authentification Ably sur les jetons si vous ne souhaitez pas divulguer votre clé API au client MQTT réel (dans le cas de MQTT sans SSL, les jetons sont requis pour empêcher le transfert des clés API en texte clair). Exemple d'authentification par jeton:
var options = { keepalive: 60, username: INSERT_TOKEN_HERE, password: '', port: 8883 }; var client = mqtt.connect('mqtts:mqtt.ably.io', options); client.subscribe("[mqtt]tokenevents", { client.end(); options.username = NEW_TOKEN; client = mqtt.connect('mqtts:mqtt.ably.io', options); });
Fonctionnalité MQTT: une immersion plus profonde
Selon IBM , MQTT a les propriétés suivantes:
- Neutre au contenu du message
- Idéal pour les communications un à plusieurs distribuées et les applications déconnectées
- Equipé de la fonction LWT (Last Will and Testament, «last will and testament») pour signaler aux parties une déconnexion anormale du client
- S'appuie sur TCP / IP pour les tâches de communication de base
- Conçu pour délivrer des messages en utilisant les modèles "au plus une fois", "au moins une fois" et "exactement une fois"
Un membre du système MQTT peut jouer le rôle d'éditeur, de consommateur ou les deux à la fois.
L'une des caractéristiques distinctives de MQTT est sa compréhension unique des canaux: chacun d'eux est traité comme un chemin de fichier, par exemple:
channel = "user/path/channel"
Les canaux garantissent que chaque client reçoit les messages qui lui sont destinés. En traitant les canaux comme des chemins de fichier, MQTT exécute toutes sortes de fonctions de communication utiles, y compris le filtrage des messages en fonction de l'endroit - à quel niveau ou dans quelle branche - les clients s'abonnent au chemin de fichier.
Format de message MQTT
Regardez les deux composants qui composent chaque message MQTT:
- Octet 1 : contient le type de message (demande de connexion client, confirmation d'abonnement, demande ping, etc.), un indicateur de duplication, des instructions pour l'enregistrement des messages et des informations sur la qualité de service (QoS).
- Octet 2 : contient des informations sur la longueur de message restante, y compris la charge utile et toutes les données dans l'en-tête d'une variable facultative.
L'indicateur QoS dans l'octet 1 mérite une attention particulière, car il sous-tend la fonctionnalité variable prise en charge par MQTT. Les indicateurs QoS contiennent les valeurs suivantes en fonction de l'intention et de l'urgence du message:
- 0 = pas plus d'une fois: le serveur est déclenché et oublie. Les messages peuvent être perdus ou dupliqués.
- 1 = au moins une fois: le destinataire confirme la livraison. Les messages peuvent être dupliqués, mais la livraison est garantie
- 2 = exactement une fois: le serveur assure la livraison. Les messages arrivent exactement une fois sans perte ni duplication
Voyons comment utiliser les différents niveaux de QoS dans les appareils IoT et d'autres applications.
Où puis-je utiliser MQTT?
Alors que les applications IoT sont désormais mises en œuvre à grande échelle, MQTT est devenu un moyen ouvert, simple et évolutif de déployer l'informatique distribuée et les fonctionnalités IoT pour une base d'utilisateurs plus large - à la fois sur les marchés grand public et industriel.
Comme indiqué ci-dessus, MQTT est un protocole de messagerie léger conçu pour les réseaux et les périphériques non approuvés avec des restrictions sur l'alimentation et le processeur. Cependant, cela ne signifie pas que la connexion avec une perte potentielle de paquets est sa seule application. MQTT fournit différents niveaux de service pour différents types d'infrastructure IoT, de l'échantillonnage répétitif des données à la gestion des machines industrielles:
- Données de capteur environnemental : Comme déjà mentionné, MQTT prend en charge le modèle de livraison de message «pas plus d'une fois». Dans les réseaux à couverture partielle ou à latence élevée, cela signifie que les informations peuvent être perdues ou dupliquées . Dans les zones où les capteurs à distance enregistrent et transmettent des données à des intervalles spécifiés, ce n'est pas un problème, car de nouvelles lectures sont reçues régulièrement. Les capteurs dans des environnements distants sont généralement des appareils à faible consommation d'énergie, ce qui fait de MQTT la solution idéale pour les capteurs IoT avec une priorité de transfert de données relativement faible.
- Données de performances de la machine : pour répondre rapidement aux problèmes et éviter les temps d'arrêt. Par exemple, une installation éolienne doit garantir la livraison des indicateurs de performance actuels aux équipes locales avant même que ces informations n'atteignent le centre de données. Dans de telles situations, la livraison de messages «au moins une fois» garantit que les spécialistes appropriés sont rapidement remarqués par les spécialistes nécessaires, même s'ils arrivent en double. Ceci est important pour les communications machine de priorité plus élevée.
- Systèmes de facturation : il y a encore plus de messages prioritaires et précis qui doivent être traités correctement. Dans les situations commerciales où la duplication des enregistrements est inacceptable, y compris dans les systèmes de facturation, l'indicateur de qualité de service «une seule fois» est utile. Cela élimine la duplication ou la perte de packages dans la facturation ou les systèmes de facturation, réduit le nombre d'anomalies et de contradictions inutiles, comme convenu.
Quand ne pas utiliser MQTT?
Les développeurs disposent d'une large sélection de protocoles pour la conception et le déploiement de canaux de communication IoT bidirectionnels, y compris MQTT, HTTP,
CoAP ,
WebSockets (si le CPU / la batterie le permet) et autres. Que MQTT soit le meilleur choix dépend du matériel et de la tâche de l'application.
Conçu pour les environnements à bande passante extrêmement faible, le protocole MQTT peut être assez rigide dans sa quête pour enregistrer chaque octet. Par exemple, la spécification ne définit que cinq messages d'erreur avec lesquels le serveur peut rejeter la connexion (par exemple, un nom d'utilisateur / mot de passe non valide ou une version inacceptable du protocole). Si le serveur veut signaler une autre erreur, ce n'est pas par chance. Pire encore, si une erreur se produit après le démarrage de la connexion, il n'existe aucun mécanisme pour signaler une erreur. Le serveur ne peut que hausser les épaules et interrompre brusquement la connexion TCP, laissant le client sans aucun indice pourquoi il l'a abandonnée (et sans aucun moyen de distinguer une déconnexion délibérée d'un problème de réseau temporaire). Pour les personnes habituées aux protocoles pub / sous plus flexibles et faciles à déboguer (bien que moins économiques en termes de bande passante), une telle approche Spartan peut sembler un peu primitive.
MQTT est souvent mentionné avec HTTP, donc Google a mené une étude en les comparant en temps de réponse, volume de trafic et autres attributs importants pour les développeurs. MQTT a pris la première place dans les tests Google, mais
uniquement dans des conditions où la connexion peut être réutilisée pour envoyer plusieurs charges utiles.
HTTP et MQTT sont un bon choix pour les applications IoT en raison de la quantité relativement faible de trafic, de la batterie faible et des besoins en mémoire.
CoAP est un autre protocole souvent comparé à MQTT pour le développement de systèmes IoT. Ils sont similaires, mais il existe des différences notables. MQTT est un protocole plusieurs-à-plusieurs, tandis que CoAP est essentiellement un protocole un-à-un pour la communication entre un serveur et un client. Dans le même temps, CoAP fournit des fonctionnalités de métadonnées, de découverte et de négociation de contenu
que MQTT ne possède pas .
Dans les cas où les clients ne devraient recevoir que des données, les
événements envoyés par le serveur sont également une option appropriée.
Comment configurer rapidement MQTT
Le référentiel MQTT sur GitHub possède
une liste complète de bibliothèques MQTT open source dans différentes langues. Voici deux exemples de personnalisation utilisant le courtier MQTT open source, la bibliothèque JavaScript et la bibliothèque .NET.
Eclipse Mosquitto - courtier MQTT open source
Eclipse Mosquitto est un courtier de messages open source (EPL / EDL) qui implémente les protocoles MQTT version 5.0, 3.1.1 et 3.1. Mosquitto est léger et adapté à une utilisation sur tous les appareils: des ordinateurs monocarte basse consommation aux serveurs à part entière.
MQTT.js
MQTT.js est une bibliothèque cliente pour le protocole MQTT, écrite en JavaScript pour Node.js et un navigateur. Voici un exemple d'envoi d'un message à l'aide de MQTT.js:
var mqtt = require('mqtt') var client = mqtt.connect('mqtt://test.mosquitto.org') client.on('connect', function () { client.subscribe('presence', function (err) { if (!err) { client.publish('presence', 'Hello mqtt') } }) }) client.on('message', function (topic, message) {
MQTTnet
MQTTnet est une bibliothèque .NET hautes performances qui fournit à la fois le client et le serveur MQTT (courtier).
Installation du client MQTT:
Après avoir configuré les paramètres du client MQTT, vous pouvez établir une connexion. Le code suivant montre comment se connecter au serveur:
Recevoir les messages entrants:
client.UseApplicationMessageReceivedHandler(e => { Console.WriteLine("### RECEIVED APPLICATION MESSAGE ###"); Console.WriteLine($"+ Topic = {e.ApplicationMessage.Topic}"); Console.WriteLine($"+ Payload = {Encoding.UTF8.GetString(e.ApplicationMessage.Payload)}"); Console.WriteLine($"+ QoS = {e.ApplicationMessage.QualityOfServiceLevel}"); Console.WriteLine($"+ Retain = {e.ApplicationMessage.Retain}"); Console.WriteLine(); Task.Run(() => client.PublishAsync("hello/world")); });
Post-publication:
var message = new MqttApplicationMessageBuilder() .WithTopic("MyTopic") .WithPayload("Hello World") .WithExactlyOnceQoS() .WithRetainFlag() .Build(); await client.PublishAsync(message);
Voir la
documentation et le wiki MQTTnet pour plus d'exemples .
Les fournisseurs de niveau entreprise disposent
de serveurs MQTT standard pour une messagerie évolutive entre les applications mobiles, les machines industrielles et une large gamme d'autres utilisations de l'IoT. Ce
guide vous explique comment utiliser MQTT via un courtier de niveau entreprise.
Qu'en est-il de la mise à l'échelle?
En ce qui concerne la mise à l'échelle de MQTT, il y a deux considérations à considérer: 1) est-ce le bon protocole; 2) quel que soit le choix du protocole, quelles infrastructures et capacités réseau sont nécessaires pour gérer l'augmentation du trafic entre les appareils utilisant MQTT.
Light-to-Machine-to-Machine (LWM2M) est un autre protocole qui peut être utilisé avec MQTT au niveau de l'entreprise. Comparé au MQTT, il est parfois
mieux adapté aux systèmes IoT à long terme . MQTT est idéalement adapté pour un essai de l'IoT sans effort tandis que le LWM2M fournit des fonctionnalités pour une infrastructure polyvalente à long terme. LWM2M fournit également des outils de gestion de périphériques supérieurs tels que la surveillance des connexions, les mises à jour du micrologiciel et les actions des périphériques distants. Pour les entreprises disposant d'un grand nombre d'appareils non gérés qui envoient de grandes quantités de données à une plate-forme centrale, LWM2M est le meilleur choix. Néanmoins, nous parlons de déploiements à grande échelle de l'IoT, donc généralement MQTT est plus qu'une option adéquate. De plus, MQTT est plus courant et a un support plus large.
Maintenant sur les possibilités d'infrastructure. En ce qui concerne le chargement du serveur, le nombre de connexions simultanées est rarement un goulot d'étranglement. La plupart des bons serveurs / courtiers MQTT prennent en charge des milliers de connexions simultanées, mais quelle est la charge de travail requise pour traiter et répondre aux messages une fois que le serveur MQTT a reçu les données réelles? En règle générale, il existe toutes sortes de problèmes potentiels, tels que la lecture et l'écriture vers et depuis la base de données, l'intégration avec le serveur, la distribution et la gestion des ressources pour chaque client, etc. Dès qu'une machine cesse de faire face à la charge, vous devez ajouter des serveurs supplémentaires, c'est-à-dire, pensez à l'équilibrage de charge, à la synchronisation des messages entre les clients connectés à différents serveurs, à l'accès généralisé à l'état du client, quel que soit le temps de connexion ou le serveur spécifique auquel le client est connecté - la liste des produits zhaetsya et continue.
De tels problèmes méritent un article séparé, et de nombreuses informations peuvent être trouvées dans la section Ingénierie de
notre blog . En particulier, consultez l'article sur
certaines des complexités de la maintenance d'une infrastructure de messagerie en temps réel à grande échelle .
Quelle est la situation actuelle du MQTT?
En avril 2019, OASIS a publié MQTT v5.0 en tant que norme officielle. OASIS est un consortium à but non lucratif de 600 organisations membres et
5 000 membres individuels .
La version 5.0 introduit un certain nombre de
nouvelles fonctionnalités qui devraient intéresser les développeurs de systèmes en temps réel. Ces nouvelles fonctionnalités sont rétrocompatibles avec les versions actuelles de MQTT. Parmi eux:
- Rapport d'erreur amélioré : les codes retour peuvent désormais informer que les données ne sont pas transmises pour une raison quelconque. Les chaînes facultatives sont prises en charge pour indiquer la raison. Ils aident à améliorer les diagnostics de dépannage.
- Partage des abonnements : pour aider à équilibrer la charge, les abonnements peuvent être partagés entre plusieurs clients côté réception.
- Propriétés du message : la version 5.0 introduit des métadonnées dans le cadre de l'en-tête du message. Il peut transmettre des informations supplémentaires à l'utilisateur final ou faciliter certaines des autres fonctions énumérées ci-dessous.
- Alias de canal : les éditeurs peuvent remplacer les canaux par des identificateurs numériques pour réduire le nombre d'octets à transmettre.
- Date d' expiration du message : les messages peuvent être marqués pour suppression automatique si le système n'est pas en mesure de les livrer dans un délai spécifié.
Pour une liste complète des nouvelles fonctionnalités MQTT 5.0, voir l'
annexe C de la norme officielle.
En plus des nombreux appareils et services grand public sur le marché, MQTT a trouvé une utilisation dans l'infrastructure d'entreprise de
toutes formes et tailles . Il s'agit des smartphones et tablettes, des systèmes de surveillance de l'énergie, des dispositifs médicaux, des plates-formes pétrolières et des plates-formes pétrolières, des industries automobile et aérospatiale, ainsi que des capteurs et des systèmes de vision industrielle utilisés dans la manutention, la construction, la chaîne d'approvisionnement, la vente au détail, et bien plus encore.
MQTT et Ably
MQTT est un protocole populaire, largement pris en charge et relativement mature. Il est idéal pour de
nombreuses applications en temps réel , et pas seulement pour le déploiement de l'IoT. Cependant, comme la production et la consommation de données en temps réel continuent
de croître de façon exponentielle , MQTT n'est pas toujours le bon protocole pour répondre à vos besoins de streaming. Suivez notre section
Concepts en temps réel pour obtenir des informations sur les autres protocoles et la façon dont ils conviennent à votre situation.
Ably fournit un
courtier et un adaptateur de protocole MQTT avec traduction dans le propre protocole d'Ably dans les deux sens, ce qui vous permet de vous intégrer à tous les systèmes et connexions existants. WebSockets, HTTP, SSE, gRPC (en cours de développement), STOMP, AMQP et autres protocoles pris en charge pour organiser une infrastructure de messagerie distribuée en temps réel. Il existe plus de 40 bibliothèques clientes SDK et la prise en charge de protocoles propriétaires en temps réel.