Plus connu sous l’acronyme MQTT, le protocole Message Queuing Telemetry Transport est un protocole de messagerie léger adapté aux situations où les clients doivent utiliser peu de code et sont connectés à des réseaux peu fiables ou limités en bande passante. Il est principalement utilisé dans la communication entre machines (M2M) ou sur les types de connexions propres à l’Internet des Objets.
Créé par Andy Stanford-Clark et Arlen Nipper en 1999, MQTT est un protocole de messagerie qui, à son origine, visait à permettre aux capteurs utilisés dans l’industrie pétrolière et gazière d’envoyer leurs données à des serveurs distants. Ces appareils de supervision étaient la plupart du temps installés dans des lieux reculés où il était difficile, sinon impossible, d’installer une ligne téléphonique, une connexion filaire ou un système de transmission radio. À l’époque, la seule solution pour ces cas de figure était la liaison satellite, une option extrêmement onéreuse et facturée à l’aune de la quantité de données consommée. Les acteurs de l’industrie, qui avaient déployé des milliers de capteurs sur le terrain, avaient besoin d’un mode de communication capable de transmettre des données avec toute la fiabilité requise, tout en consommant un minimum de bande passante.
MQTT a été standardisé en tant que format ouvert par l’Organization for the Advancement of Structured Information Standards (OASIS) en 2013. À ce jour, l’OASIS gère encore le standard MQTT.
MQTT est un protocole de messagerie push-subscribe basé sur le protocole TCP/IP. Dans l’architecture MQTT, il existe deux types de systèmes : les clients et les brokers (courtiers). Le broker est le serveur avec lequel les clients communiquent. Il reçoit les communications qui émanent des clients et les retransmet à d’autres clients. Ainsi, les clients ne communiquent pas directement entre eux, mais toujours par l’intermédiaire du broker. Chaque client peut être soit éditeur, soit abonné, soit les deux.
MQTT est un protocole orienté événements. Afin de minimiser le nombre de transmissions, les données ne sont envoyées ni à intervalles définis, ni en continu. Un client publie uniquement quand il a des informations à transmettre, et un broker n’envoie des informations aux abonnés que quand il reçoit de nouvelles données.
MQTT minimise également ses transmissions grâce à un système de messages à la construction allégée et bien cadrée. Chaque message se compose d’un en-tête fixe de 2 octets, auquel peut s’ajouter un en-tête facultatif dont l’usage va toutefois alourdir le poids du message. La charge utile des messages est, pour sa part, limitée à 256 Mo. Les trois niveaux de qualité de service laissent aux concepteurs de réseau le choix de minimiser le nombre de transmissions de données ou d’en maximiser la fiabilité.
- QoS 0 — c’est le niveau minimal de transmission de données. Quand on choisit ce niveau de QoS, chaque message est envoyé à l’abonné une seule fois, sans accusé de réception. Il est donc impossible de savoir si l’abonné l’a reçu. Dans ce niveau de qualité de service, les messages sont expédiés « au plus une fois ». Comme ce niveau de QoS part du principe que les messages sont systématiquement remis, ces derniers ne sont pas conservés en vue d’un envoi ultérieur aux clients qui seraient déconnectés au moment de leur transmission.
- QoS 1 — le broker tente de remettre le message, puis attend un accusé de réception de la part de l’abonné. Si cet accusé n’est pas reçu dans le délai défini, le message est réexpédié. Avec cette méthode, l’abonné peut recevoir le message plus d’une fois si le broker ne reçoit pas de confirmation de réception dans le temps imparti. Dans ce niveau de QoS, les messages sont assurés d’arriver « au moins une fois ».
- QoS 2 — le client et le broker utilisent deux paires de paquets pour s’assurer que le message a été remis, et pour vérifier qu’il n’a été reçu qu’une seule fois. Dans ce niveau de QoS, les messages sont assurés d’arriver « exactement une fois ».
Dans les situations où les communications sont fiables, mais limitées, QoS 0 peut apparaître comme la meilleure option. Dans celles où les liaisons ne sont pas fiables, mais où les connexions ne sont pas limitées, QoS 2 semble être un choix tout indiqué. Quant au QoS 1, il réunit pour ainsi dire le meilleur des deux mondes, mais requiert que l’application qui reçoit les données soit capable de gérer des doublons.
Dans le cas de QoS 1 comme de QoS 2, les messages sont mémorisés ou placés en file d’attente à l’intention des clients qui sont hors ligne et ont établi une session permanente. Ces messages sont réexpédiés (en fonction du niveau de QoS correspondant) dès que le client se sera reconnecté.
Sous MQTT, les messages sont publiés en tant que topics (rubriques), c’est-à-dire de structures hiérarchisées qui utilisent le caractère slash (/) comme délimiteur. Ces structures ressemblent à l’arborescence de l’explorateur Windows. Ainsi, une structure de type capteurs/PétroleetGaz/Pression/permet à un abonné de préciser qu’il souhaite ne recevoir que les données émanant des clients publiant dans la rubrique Pression, ou peut-être, s’il souhaite élargir ses horizons, toutes les données du rubrique capteurs/PétroleetGaz. Les rubriques ne sont pas créées sous MQTT à proprement parler : si un broker reçoit des données publiées sur une rubrique qui n’existe pas à ce moment-là, celle-ci sera automatiquement créée, après quoi les clients pourront s’y abonner.
Pour alléger au maximum le protocole, les messages reçus ne sont pas conservés sur le broker, sauf à ce qu’ils soient indiqués comme « conservés ». On parle alors de messages conservés. Les utilisateurs qui veulent sauvegarder les messages qu’ils reçoivent devront le faire en dehors de MQTT. Il y a toutefois une exception à la règle.
MQTT étant un protocole orienté événements, il est possible et même probable qu’un abonné reçoive très peu de messages relatifs à une rubrique donnée, même pendant une longue période. Dans le cas d’une rubrique structurée comme dans l’exemple plus haut, il se peut que les messages de la sous-rubrique Pression ne soient envoyés que lorsqu’un capteur s’aperçoit que la pression a dépassé un certain niveau. Or, si l’on part du principe que la variable surveillée par ce capteur, quelle qu’elle soit, ne connaît que rarement des défaillances, il peut s’écouler plusieurs mois, parfois même des années, avant qu’un client ne publie un message relatif à cette rubrique.
Pour s’assurer qu’un nouvel abonné reçoit les messages portant sur une rubrique, les brokers peuvent être configurés pour conserver le dernier message envoyé à chaque rubrique. On parle alors de message conservé. Quand un nouveau client s’abonne à une rubrique ou quand un client existant se reconnecte, le message conservé est envoyé aux abonnés afin de vérifier que l’abonnement est actif et que le destinataire a reçu les informations les plus récentes.
Lorsque la liaison n’est pas fiable, il peut arriver qu’un éditeur soit brutalement déconnecté du réseau. Pour éviter que les abonnés soient pris au dépourvu si une telle situation se produisait, l’éditeur peut programmer un message qui leur sera transmis en cas de déconnexion inopinée. Appelé dernières volontés et testament, ce message est mis en cache sur le broker et envoyé aux abonnés si l’éditeur est brutalement déconnecté. En général, il comprend des informations permettant d’identifier l’éditeur déconnecté afin que les mesures adéquates puissent être prises.
Pour minimiser la charge du protocole, un client ne peut effectuer que quatre opérations au cours de la phase de communication : publication, abonnement, désabonnement ou ping.
- Publication — envoie un bloc de données contenant le message à envoyer. Ces données, propres à chaque implémentation, ne sont généralement qu’une simple indication marche/arrêt, ou une valeur d’un capteur précis, comme un relevé de température, de pression, etc. Si la rubrique à publier n’existe pas, le broker se charge de la créer.
- Abonnement — permets au client de s’abonner à une rubrique. Le client peut s’abonner à une rubrique précise ou utiliser des caractères de remplacement pour s’abonner à tout ou partie d’une famille de rubriques. Pour s’abonner, le client envoie un paquet SUBSCRIBE et reçoit en retour un paquet SUBACK. S’il y a un message conservé dans la rubrique en question, le nouvel abonné le recevra également.
- PING – Un client peut envoyer une commande ping vers le serveur. Un paquet PINGREQ est envoyé par l’abonné, qui recevra un paquet PINGRESP en guise de réponse. Les commandes ping peuvent servir à vérifier que la connexion est toujours fonctionnelle et que la session TCP n’a pas été inopinément coupée par un autre périphérique réseau comme un routeur ou une passerelle.
- DISCONNECT – Un abonné ou éditeur peut envoyer un message DISCONNECT au broker. Ce message informe le broker qu’il n’y a plus lieu qu’il envoie ou mette en file d’attente des messages destinés à un abonné, et qu’il ne recevra plus de données le part d’un éditeur. Ce genre de procédure d’arrêt permet au client de se reconnecter à l’aide du même client qu’auparavant. Si un client se déconnecte sans avoir transmis de message de déconnexion, ses dernières volontés et son testament sont envoyés aux abonnés.
À son origine, l’objectif du protocole MQTT était de proposer la méthode de transmission de données la plus légère et la plus efficace pour offrir une alternative viable aux liaisons onéreuses et manquant de fiabilité. À ce titre, la sécurité n’était pas la préoccupation première des équipes chargées de la conception et du déploiement de MQTT.
Certaines options de sécurité sont toutefois disponibles, au prix toutefois d’une augmentation du nombre de transmissions et du poids des données.
- Sécurité réseau – Si l’on peut sécuriser le réseau en soi, la transmission de données MQTT non sécurisées est sans gravité. Dans un tel cas de figure, d’éventuels problèmes de sécurité proviendraient du réseau lui-même, peut-être via une personne malveillante ou toute autre forme d’intrusion du réseau.
- Identifiant et mot de passe — MQTT intègre un système d’identifiants et de mots de passe qui permet aux clients d’établir une connexion avec un broker. Cela étant, on déplorera que les identifiants et mots de passe soient transmis en clair. En 1999, cela suffisait largement, dans la mesure où il était si difficile d’intercepter une communication satellite que personne n’aurait songé à le faire pour se procurer les valeurs relevées par un capteur sans grande importance. Aujourd’hui, en revanche, il est si simple d’intercepter toutes sortes de communications réseau sans fil qu’une procédure d’authentification serait plus qu’utile.
Dans bien des situations, un identifiant et un mot de passe sont demandés non pas pour se prémunir des personnes malveillantes, mais simplement pour éviter les connexions involontaires. - SSL/TLS – Comme MQTT est basé sur TCP/IP, le protocole SSL/TLS apparaît comme la solution logique pour sécuriser les transmissions entre les clients et les brokers. Malheureusement, son recours alourdit nettement la charge d’un protocole dont la vocation première est de rester léger.
Le 3 avril 2019, l’OASIS a publié le standard officiel MQTT v5.0.
Les nouvelles fonctionnalités majeures de MQTT v5.0
- Codes d’erreur – À l’origine, MQTT n’entreprenait rien en cas de panne. La panne elle-même était le seul code d’erreur. Dans sa version 5.0, les accusés de réception prennent désormais en charge l’usage de codes de retour, qui précisent en termes simples la cause de la panne. Bien sûr, l’usage de codes de retour alourdit légèrement la charge du protocole.
- Abonnements partagés – Quand une rubrique réunit trop d’abonnés, le broker peut rencontrer des problèmes de charge. Les abonnements partagés permettent de lisser la charge de travail entre les différents clients.
- Expiration des messages – Les messages peuvent être configurés pour être supprimés s’ils ne sont pas reçus par leur destinataire à l’expiration d’un délai défini. On évite ce faisant que des messages qui ne sont plus d’actualité soient envoyés à des abonnés qui sont déconnectés depuis un certain temps.
- Alias de rubrique – Les noms des rubriques peuvent devenir si longs qu’ils finissent par alourdir le nombre d’octets transmis. Les chaînes de nom peuvent désormais être remplacées par un chiffre unique à utiliser à chaque fois que l’on parle d’une rubrique précise.
Obtenez deux livres blancs gratuits
Livre blanc I
Dans l'informatique industrielle moderne, les bonnes équipes ont besoin des bonnes données. Notre guide montre comment mettre en œuvre une supervision holistique qui rassemble les éléments de l'informatique, de l'OT et de l'IIoT dans vos tableaux de bord.
Livre blanc II
Notre deuxième guide vous donne de l'inspiration et des idées pour des tableaux de bord qui présentent des données informatiques, OT et IIoT, le tout en un seul endroit. Nous vous montrons à quoi ressemblent des tableaux de bord industriels véritablement convergents !