Département Génie Informatique

MQTT (Message Queuing Telemetry Transport)

Pr. Omar MOUSSAOUI
o.moussaoui@ump.ac.ma

Filière : GIE2, Année 2022-2023

 PLAN
➢ Pile de protocoles IoT
➢ Modèle OSI Vs. Modèle TCP/IP
➢ Protocoles de la couche application IoT
➢ MQTT (Message Queuing Telemetry Transport)
➢ Broker MQTT
➢ Topics MQTT
➢ Fonctionnement de MQTT
➢ Défis liés à l'utilisation de MQTT pour l’IoT
Pile de protocoles IoT
 Modèle OSI Vs. Modèle TCP/IP
L‘IoT utilise des protocoles Internet existants et introduit d’autres qui sont nouveaux.
 Protocoles de la couche application
➢ Une application IoT permet aux objets connectés d’envoyer leurs données à un
serveur Web Internet ou une plateforme Cloud.
➢ Les protocoles de la couche application permettent de transmettre des commandes
depuis les applications utilisateurs aux actionneurs des objets connectés.
➢ L‘infrastructure Web classique n’est pas adaptée à la majorité des applications IoT qui
sont dotées d’équipements de faibles ressources : petits microcontrôleurs, petites
quantités de mémoire RAM, énergie limitée, etc.
➢ Les protocoles applicatifs qui utilisent un nombre limité de messages de petites tailles
sont utilisés pour les applications IoT, et sont classés en 3 familles :
➢ Protocole de messagerie: MQTT, XMPP et AMQ
➢ Protocole de transfert web: Web REST, CoAP
➢ Protocole réseau: WebSocket
 MQTT (Message Queuing Telemetry Transport)
➢ Créé en 1999 par Andy Stanford-Clark d'IBM, et Arlen Nipper d’EuroTech.
➢ MQTT est un protocole de messagerie de publication et d’abonnement basé sur TCP/IP. Il joue un rôle
important dans l’IoT.
➢ Le client et le Broker doivent tous deux disposer d'une pile TCP/IP.
➢ L‘approche publish/subscribe classifie les messages par catégories « topics » auxquelles les destinataires
s’abonnent (subscribe).
➢ Le client qui envoie un message (topic) est nommé Publisher, celui qui reçoit le message est nommé
Subscriber.
➢ Le broker MQTT, connu par le Publisher et le Subscriber, filtre les messages reçus et les distribue.
MQTT (Message Queuing Telemetry Transport)
 MQTT (Message Queuing Telemetry Transport)

➢ Les caractéristiques du protocole MQTT en font un protocole adapté aux réseaux

IoT car il répond aux besoins suivants :
➢ Adapté aux réseaux à faible bande passante
➢ Idéal pour l’utilisation sur les réseaux sans fils grâce notamment à un nombre
limité de messages de petite taille
➢ Faible consommation en énergie car la publication et la consommation des
messages est rapide
➢ Nécessite peu de ressources de calculs et de mémoires
➢ Transmet un message à plusieurs entités en une seule connexion TCP
 Broker MQTT
➢ L'homologue du client MQTT est le Broker MQTT, qui est au cœur de tout protocole de
publication/abonnement.
➢ Selon l'implémentation, un Broker peut gérer jusqu'à des millions de clients MQTT connectés
simultanément.
➢ Le Broker MQTT est chargé de recevoir tous les messages, de filtrer les messages, de déterminer qui est
abonné à chaque message et d'envoyer le message à ces clients abonnés.
➢ Le Broker MQTT détient également les données de session de tous les clients qui ont des sessions
persistantes, y compris les abonnements et les messages manqués.
➢ Une autre responsabilité du Broker MQTT est l'authentification et l'autorisation des clients.
➢ En bref, le Broker est le hub central par lequel chaque message doit passer ➔ Par conséquent, il est
important que votre Broker soit hautement évolutif, intégrable dans les systèmes backend, facile à
surveiller, résistant aux pannes.
➢ Exemples des Brokers : Mosquitto, HiveMQ, ActiveMQ …
 Topics MQTT
➢ Les topics (sujets MQTT) :
➢ sont structurées d‘une façon hiérarchique ➔ Les chaînes décrivant un sujet forment une
arborescence en utilisant la barre oblique (/) comme caractère de séparation.
➢ sont sensibles à la casse, codées en UTF-8 et doivent comporter au moins un caractère.
➢ peuvent être génériques : possibilité de faire des souscriptions à des topics qui ne sont pas encore
définies.
➢ Un client peut s'abonner à des branches entières de l'arborescence d’un topic (ou se désabonner)
à l'aide des caractères génériques suivants :
➢ le signe plus « + » : correspond à un seul niveau,
➢ le signe dièse « # » : correspond à plusieurs niveaux.
➢ Le caractère spécial dollar « $ » : permet d'exclure un sujet de tout abonnement utilisant un caractère générique à la
racine. En règle générale, le dollar sert à transporter des messages système ou serveur spécifiques.
 Topics MQTT
➢ Exemple:
➢ La souscription au topic house# couvre :
➢ house/room1/main-light
➢ house/room1/alarm
➢ house/room2/main-light
➢ house/garage/main-light
➢ house/main-door
➢ La souscription au topic house/+/main-light couvre :
➢ house/room1/main-light
➢ house/room2/main-light
➢ house/garage/main-light
 Fonctionnement de 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 vers le broker en utilisant soit un port standard,
soit un port personnalisé défini par les opérateurs du broker.
➢ Les ports standards sont : 1883 pour la communication non chiffrée et 8883 pour la communication
chiffrée utilisant SSL/TLS.
➢ Le protocole MQTT étant avant tout destiné aux appareils disposant de ressources limitées, SSL/TLS
n'est pas toujours disponible et dans certains cas, il n'est pas souhaité.
➢ Le client s'authentifie alors en envoyant un nom d'utilisateur et un mot de passe en clair au serveur
lors de la séquence de paquets CONNECT/CONNACK.
➢ Certains brokers, en particulier les brokers ouverts publiés sur Internet, acceptent les clients
anonymes. Dans ce cas, le nom d'utilisateur et le mot de passe sont tout simplement laissés vides.
 Fonctionnement de MQTT
➢ MQTT est considéré comme un protocole léger parce que les messages ont tous une faible empreinte
logicielle.
➢ Chaque message se compose d'un en-tête fixe (2 octets), d'un en-tête variable facultatif, d'une charge
utile de message limitée à 256 Mo et d'un niveau de qualité de service.
➢ Trois niveaux de qualité de service déterminent la façon dont le protocole MQTT gère le contenu.
➢ Bien que les niveaux plus élevés soient plus fiables, ils sont également plus gourmands en termes
de latence et de bande passante.
➢ Les clients abonnés peuvent spécifier le niveau de QoS qu'ils souhaitent recevoir.
 Fonctionnement de MQTT
➢ Le niveau de qualité de service le plus simple est le service non confirmé (Unacknowledged Service).
➢ Ce niveau utilise une séquence de paquets PUBLISH : l'éditeur envoie un message une seule fois au
broker et ce dernier transmet ce message une seule fois aux abonnés.
➢ Aucun mécanisme ne garantit la réception du message et le broker ne l'enregistre pas non plus.
➢ Ce niveau de qualité de service est également appelé « QoS niveau 0 » ou QoS0, ou encore « At most
once » (au plus une fois).
 Fonctionnement de MQTT
➢ Le deuxième niveau de service est le service confirmé (Acknowledged Service).
➢ Ce niveau utilise une séquence de paquets PUBLISH/PUBACK (Publish Acknowledge) entre l'éditeur et son
broker, ainsi qu'entre le broker et les abonnés.
➢ Un paquet de confirmation vérifie que le contenu a été reçu et un mécanisme de renvoi du contenu
d'origine est déclenché si l'accusé de réception n'est pas reçu en temps voulu.
➢ Cela signifie que l'abonné peut recevoir plusieurs copies du même message.
➢ Ce niveau de qualité de service est également appelé « QoS niveau 1 » ou QoS1, ou encore « At least once »
(au moins une fois).
 Fonctionnement de MQTT
➢ Le troisième niveau de QoS est le service garanti (Assured Service) ➔ Ce niveau délivre le message
avec deux paires de paquets : PUBLISH/PUBREC et PUBREL/PUBCOMP.
➢ Les deux paires s'assurent que quel que soit le nombre de tentatives, le message ne sera délivré
qu'une seule fois.
➢ Ce niveau de qualité de service est également appelé « QoS niveau 2 » ou QoS2, ou encore «
Exactly once » (exactement une fois).
 Fonctionnement de MQTT
➢ Au cours de la phase de communication, un client peut effectuer les opérations suivantes : publication,
abonnement, désabonnement ou ping.

➢ L'opération de publication envoie un bloc binaire de données vers un sujet

défini par l'éditeur. Le format du contenu dépend de l'application.
➢ Les abonnements à des sujets sont réalisés au moyen d'une paire de
paquets SUBSCRIBE/SUBACK.
➢ Le désabonnement est réalisé de manière similaire à l'aide d'une paire de
paquets UNSUBSCRIBE/UNSUBACK.
➢ Un client peut effectuer une 4ème opération au cours de la phase de
communication : il peut envoyer une commande ping vers le serveur du
broker en utilisant une séquence de paquets PINGREQ/PINGRESP.
➔ Cette opération n'a pas d'autre fonction que de maintenir une connexion active
et de s'assurer que la connexion TCP n'a pas été coupée par une passerelle ou
un routeur.

➢ Lorsqu'un éditeur ou un abonné souhaite mettre fin à une session MQTT, il

envoie un message DISCONNECT au broker, puis met fin à la connexion
➔ On parle d'arrêt progressif, car il permet au client de se reconnecter facilement
en fournissant son identité client et de reprendre la session là où il l'avait laissée.
 Défis liés à l'utilisation de MQTT pour l’IoT
➢ Le protocole MQTT n'intègre pas de mécanismes de sécurité, mais il est souvent utilisé dans des applications
nécessitant un niveau de sécurité spécifique.
➢ le protocole MQTT intègre des fonctionnalités d'authentification minimales : Nom d'utilisateur et mot de passe sont envoyés
en clair.
➢ Toute utilisation sécurisée de MQTT exige de mettre en œuvre SSL/TLS, qui malheureusement n'est pas un protocole léger.
➢ Authentifier des clients avec des certificats client n'est pas un processus des plus simples et MQTT ne permet pas de
déterminer qui est propriétaire d'un sujet et qui peut y publier des informations.
➢ Il est donc très facile d'injecter des messages malveillants, volontairement ou non, dans le réseau. En outre, il n'y a aucun
moyen pour le récepteur de savoir qui a envoyé le message d'origine, à moins que cette information ne soit contenue dans le
message.
➢ La couche de sécurité propriétaire qui doit être ajoutée à MQTT augmente donc l'empreinte logicielle et complique la mise en
œuvre du protocole.
➢ La structure des sujets MQTT peut facilement devenir une immense arborescence ➔ Cela rend difficile la création d'un
réseau MQTT évolutif à grande échelle, car dès lors que l'arborescence des sujets grandit, la complexité augmente.
➢ MQTT présente un autre inconvénient : son manque d'interopérabilité ➔ Etant donné que la charge utile des messages
est binaire, sans aucune information quant à leur codage, des problèmes peuvent survenir, notamment dans des architectures
ouvertes où des applications de différents fabricants sont censées fonctionner de manière transparente les unes avec les autres.
➢ En dépit de ces considérations, de nombreux experts estiment que MQTT jouera un rôle important dans l’IoT, en
facilitant des opérations telles que le suivi des stocks, la télématique automobile, la surveillance des ressources et
les réseaux du corps médical.