LES PRINCIPAUX PROTOCOLES DE TRANSPORT POUR LES IOT
Le protocole CoAP
Dans le domaine de l’Internet des objets (IoT), le protocole CoAP (Constrained Application Protocol) est
devenu un protocole de communication essentiel. Les appareils étant de plus en plus interconnectés, CoAP
offre une solution efficace et légère pour les environnements à forte contrainte.
CoAP est un protocole spécialisé conçu pour faciliter la communication entre les appareils soumis à de fortes
contraintes dans les réseaux à faible puissance et à faible bande passante.
Contrairement aux protocoles traditionnels comme le HTTP, CoAP est conçu pour répondre aux demandes
spécifiques des IoT. En réduisant les besoins en ressources et en utilisant un système d’échange de messages
efficace, CoAP permet une communication fiable dans des situations de ressources limitées.
a- Qu’est-ce que le protocole CoAP ?
CoAP est un protocole d'application Internet spécialisé pour les appareils soumis à de fortes contraintes, tel
que défini dans la RFC 7252. Il permet aux appareils de communiquer sur Internet et est destiné à être utilisé
dans du matériel très simple tel que les microcontrôleurs 8 bits, les capteurs basse consommation et les
appareils similaires qui ne peuvent pas fonctionner sur HTTP ou TLS.
CoAP est une simplification du protocole HTTP fonctionnant sur UDP, ce qui permet d'économiser de la bande
passante. Il est conçu pour être utilisé entre des appareils sur le même réseau contraint (par exemple, des
réseaux à faible puissance et avec une forte latence), entre des appareils et des nœuds principaux sur Internet,
et entre des appareils sur différents réseaux contraints, tous deux reliés par Internet. CoAP est également
utilisé via d'autres mécanismes, tels que les SMS sur les réseaux de communication mobile.
Le groupe de travail sur les environnements RESTful contraints de l'Internet Engineering Task Force (IETF
CoRE) a effectué le principal travail de normalisation pour CoAP. Le cœur du protocole est spécifié dans la RFC
7252, ce qui signifie que CoAP n'est toujours pas un protocole standard.
Les deux nouvelles fonctionnalités conçues spécifiquement pour l'Internet des objets et le M2M sont :
• Observation les nouveaux événements survenus sur les capteurs ou les actionneurs.
• Gestion des appareils et leur identification à partir d’appareils externes.
Les principales caractéristiques de ce protocole sont :
• Protocole Web utilisé en M2M avec des contraintes
• Échange de messages asynchrone
• Faible surcharge et très simple à analyser
• Prise en charge des URI et des types de contenu
• Capacités de proxy et de mise en cache
Certains des cas spécifiques dans lesquels le protocole CoAP est utilisé :
• Votre matériel ne peut pas exécuter HTTP ou TLS : si tel est le cas, l'exécution de CoAP et DTLS peut
pratiquement faire la même chose que HTTP. Si l’on est un expert des API HTTP, alors la migration sera
simple. Vous recevez GET pour la lecture et POST, PUT et DELETE pour les mutations et la sécurité
s'exécute sur DTLS.
• Votre matériel utilise la batterie : s'il s'agit d'un problème, l'exécution de CoAP améliorera les
performances de la batterie par rapport à HTTP sur TCP/IP. UDP économise de la bande passante et
rend le protocole plus efficace.
• Une souscription est nécessaire : si l'on ne peut pas exécuter MQTT et que la requête HTTP est
impossible, alors CoAP est une solution.
b- Architecture CoAP
CoAP est basé sur une architecture client-serveur, reflétant la structure de HTTP mais optimisée pour l'IoT. Les
appareils d'un réseau CoAP peuvent agir en tant que clients, serveurs ou les deux. Les clients lancent la
communication en envoyant des requêtes aux serveurs, qui à leur tour répondent avec des données ou des
actions pertinentes. Ce modèle architectural simplifie la communication entre les appareils et les applications
tout en tenant compte des limites des environnements contraints.
CoAP CoAP
Clients Server
CoAP REQUESTS (CON/NON)
GET, POST, PUT, DELETE
CoAP RESPONSES (CON/ACK)
Resources Representation
• L'architecture est centrée autour du modèle client-serveur, qui est une approche fondamentale du
CoAP, similaire au HTTP. Ce protocole a optimisé cette architecture pour les exigences uniques des
environnements IoT.
• Clients CoAP : il s'agit d'appareils ou d'applications qui lancent la communication en envoyant des
requêtes CoAP aux serveurs CoAP. Les clients peuvent être des capteurs, des actionneurs ou tout autre
appareil IoT nécessitant des données ou des actions du réseau.
• Serveurs CoAP : ce sont des appareils qui répondent aux demandes CoAP des clients. Les serveurs
peuvent également servir de ressources avec lesquelles les clients interagissent. Les serveurs traitent les
demandes entrantes, effectuent les actions pertinentes et génèrent des réponses contenant les données
demandées ou indiquant l'état de l'opération.
• Requêtes CoAP : les clients envoient des requêtes CoAP aux serveurs pour lancer des actions ou
récupérer des données. CoAP prend en charge diverses méthodes de requête, telles que GET (récupérer
des données), POST (créer une nouvelle ressource), PUT (mettre à jour la ressource) et DELETE
(supprimer une ressource).
• Réponses CoAP : les serveurs génèrent des réponses CoAP contenant les données demandées ou le
résultat de l'action demandée. Les réponses peuvent être confirmables (CON) ou non confirmables
(NON), selon le niveau de fiabilité souhaité. Les réponses confirmables incluent un accusé de réception
(ACK) du client.
• Réseau CoAP et communication : la communication entre les clients et les serveurs s'effectue via le
réseau CoAP. CoAP est conçu pour fonctionner sur des réseaux contraints, qui peuvent avoir une bande
passante et des ressources limitées. La nature légère du protocole garantit une communication efficace
dans de tels environnements.
c- Types de messages CoAP
Le protocole CoAP définit quatre types de messages principaux, chacun servant un objectif spécifique :
• CON (Confirmable) : ce type garantit une communication fiable en exigeant un accusé de réception et
une retransmission des messages jusqu'à ce qu'ils soient reconnus. Il convient aux scénarios où
l’intégrité des données est cruciale.
• NON (non confirmable) : Les messages NON privilégient l'efficacité à la fiabilité, ce qui les rend adaptés
aux scénarios dans lesquels une perte de données occasionnelle est acceptable.
• ACK (accusé de réception) : Le destinataire d'un message CON envoie un message ACK pour confirmer
la réception. Il constitue un élément essentiel du mécanisme de fiabilité de CoAP.
• RST (Réinitialisation) : Lorsqu'un serveur ou un client reçoit un message qui ne peut pas être traité, il
envoie un message RST pour indiquer cette situation.
d- Ressources CoAP et URI
Les ressources CoAP sont des entités fondamentales du protocole. Ils sont identifiés à l’aide d’URI (Uniform
Resource Identifiers), similaires aux URL en HTTP. Les ressources peuvent représenter des données, des
services ou des actions qu'un appareil expose au réseau. Cette conception facilite l'interopérabilité et permet
d'appliquer les paradigmes Web aux applications IoT.
e- Méthodes CoAP
CoAP prend en charge un ensemble de méthodes que les clients peuvent utiliser pour interagir avec les
ressources :
Méthode GET
La méthode GET est l'une des méthodes fondamentales prises en charge par CoAP. Elle permet aux clients de
récupérer une représentation d'une ressource depuis un serveur. Une « représentation » peut être considérée
comme l’état ou le contenu actuel de la ressource demandée. Lorsqu'un client envoie une requête GET, il
demande au serveur de fournir des informations sur l'état actuel de la ressource.
Par exemple, dans un scénario de maison intelligente, un client CoAP (tel qu'une application pour
smartphone) peut envoyer une requête GET à un serveur CoAP qui contrôle un thermostat intelligent. Le
serveur répondrait avec une représentation du réglage actuel de la température, du niveau d’humidité et
d’autres données pertinentes du thermostat.
Méthode POST
La méthode POST permet aux clients d'envoyer des données à un serveur. Cette méthode est généralement
utilisée pour créer de nouvelles ressources sur le serveur ou soumettre des données pour traitement.
Lorsqu'un client envoie une requête POST, il demande au serveur de gérer les données incluses et d'effectuer
une action en conséquence.
Dans le contexte de l'IoT, un client CoAP peut envoyer une requête POST à un serveur qui gère un système de
sécurité domestique. La demande peut inclure des données sur un événement de mouvement détecté ou une
ouverture de porte. Le serveur traiterait ces données et prendrait potentiellement des mesures telles que
l'envoi d'alertes ou la journalisation de l'événement.
Méthode PUT
La méthode PUT permet aux clients de mettre à jour ou de créer l'état d'une ressource sur le serveur. Les
clients utilisent PUT lorsqu'ils souhaitent modifier le contenu ou les propriétés d'une ressource. Si la ressource
n'existe pas, PUT peut également être utilisé pour créer une nouvelle ressource.
Par exemple, considérons un capteur environnemental compatible CoAP. Le capteur peut envoyer une
requête PUT pour mettre à jour sa lecture de température actuelle sur le serveur. Si le capteur détecte un
changement de température, il peut utiliser PUT pour garantir que l’enregistrement de la température par le
serveur est exact.
Méthode DELETE
Comme son nom l'indique, la méthode DELETE permet de demander la suppression ou la suppression d'une
ressource sur le serveur. Lorsqu'un client envoie une requête DELETE, il demande au serveur d'éliminer la
ressource spécifiée.
Dans un contexte industriel, un client CoAP représentant un robot de maintenance pourrait envoyer une
requête DELETE à un serveur gérant une machine en panne. Cette requête pourrait inciter le serveur à
supprimer la représentation des ressources de la machine de ses enregistrements, indiquant que la machine
n'est plus opérationnelle.
En résumé, la prise en charge par CoAP de ces méthodes (GET, POST, PUT, DELETE) permet aux clients
d'interagir avec les ressources sur les serveurs de manière standardisée et significative. Qu'il s'agisse de
récupérer des données, d'envoyer des mises à jour, de créer des ressources ou de demander une suppression,
ces méthodes constituent le cœur des fonctionnalités de CoAP dans le paysage IoT.
f- Observateur CoAP
Dans CoAP (Constrained Application Protocol), un « observateur » est un mécanisme qui permet aux clients de
s'abonner à des ressources et de recevoir des mises à jour en temps réel sur les modifications apportées à ces
ressources. Le mécanisme Observer est conçu pour répondre aux scénarios dans lesquels les appareils ou les
applications doivent rester informés des changements dans l'état de ressources spécifiques sans interroger en
permanence le serveur.
Dans la communication client-serveur traditionnelle, un client envoie généralement des requêtes périodiques
au serveur pour vérifier si des modifications ont été apportées à une ressource particulière. Cette approche
consomme de la bande passante réseau et des ressources serveur, en particulier dans les cas où les
changements sont peu fréquents. Le mécanisme Observer de CoAP offre une solution plus efficace.
Comment fonctionne COAP Observer ?
Voici comment fonctionne le mécanisme Observer :
Demande d'abonnement : un client CoAP intéressé par l'observation d'une ressource envoie une requête GET
avec l'option « Observer » définie sur 0. Cette requête indique au serveur que le client souhaite observer la
ressource.
Réponse du serveur : lorsque le serveur reçoit la demande d'abonnement, il répond avec la représentation
des ressources comme d'habitude, ainsi que la valeur actuelle de l'option « Observer » (généralement définie
sur 0). Le serveur commence également à surveiller la ressource pour détecter les modifications.
Mise à jour des ressources : si l'état de la ressource observée change, le serveur envoie une nouvelle réponse
à tous les clients observateurs. Dans cette réponse, l'option « Observer » est incrémentée de 1. Le client reçoit
la représentation de la ressource mise à jour et peut agir en fonction des modifications.
Mises à jour ultérieures : le client peut continuer à recevoir des mises à jour en observant les modifications
ultérieures apportées à la ressource. Chaque fois que la ressource change, le serveur incrémente l'option «
Observer » et envoie la réponse mise à jour aux clients observateurs.
Annulation de l'observation : Si un client ne souhaite plus observer une ressource, il peut simplement arrêter
d'envoyer des demandes d'observation. Alternativement, il peut envoyer une requête GET avec l’option «
Observer » définie sur 1 pour annuler l’observation. Le serveur accusera réception de l'annulation et cessera
d'envoyer des mises à jour à ce client.
Avantages de l'observateur
Le mécanisme Observer offre plusieurs avantages :
§ Efficacité : l'observation réduit le besoin d'interrogations continues, ce qui économise la bande
passante du réseau et réduit la charge du serveur.
§ Mises à jour en temps réel : les clients reçoivent des mises à jour en temps réel sur les modifications
apportées aux ressources, permettant des réponses rapides.
§ Moins de latence : les observateurs peuvent réagir rapidement aux changements, car ils sont avertis
dès que l'état de la ressource est mis à jour.
§ Consommation d'énergie réduite : l'observation contribue à réduire la consommation d'énergie des
appareils IoT en minimisant le besoin de communications fréquentes.
Cependant, il est important de noter que le mécanisme Observer est mieux adapté aux ressources qui
changent rarement. Si l’état d’une ressource change rapidement, le flux constant de mises à jour peut
submerger le réseau et les clients.
Dans l'ensemble, le mécanisme Observer est une fonctionnalité précieuse de CoAP qui améliore l'efficience et
l'efficacité de la communication dans les applications IoT en permettant aux appareils de rester informés des
changements de ressources sans recourir à des interrogations continues.
g- Structure des messages CoAP
Les messages CoAP (Constrained Application Protocol) sont les éléments constitutifs de la communication
entre les appareils IoT et les serveurs dans des environnements contraints. Ces messages suivent une
structure bien définie pour échanger efficacement des données et contrôler les informations. Comprendre la
structure des messages CoAP est essentiel pour développer et mettre en œuvre des protocoles de
communication efficaces pour les applications IoT.
Un message CoAP se compose de plusieurs éléments :
Le header du message CoAP
Le header d'un message CoAP contient des informations essentielles sur le message et ses propriétés. Il est
divisé en plusieurs domaines :
§ Version (2 bits) : indique la version de CoAP utilisée.
§ Type (2 bits) : spécifie le type de message (CON, NON, ACK ou RST).
§ Token Length (4 bits) : détermine la longueur du champ du jeton (token).
§ Code (8 bits) : définit la méthode CoAP, la réponse ou le code d'erreur.
§ ID de message (16 bits) : identifiant unique du message, utilisé pour faire correspondre les demandes
avec les réponses.
Token (0-8 octets )
Le champ du jeton est utilisé pour corréler les messages associés dans un échange CoAP. Il s'agit généralement
d'une valeur générée de manière aléatoire qui permet d'identifier les demandes et les réponses qui vont
ensemble. La longueur du jeton est spécifiée dans l'en-tête.
Options (0 ou plusieurs options)
Les options fournissent un contexte et des métadonnées supplémentaires au message CoAP. Chaque option se
compose d'un delta de longueur variable (indiquant le numéro de l'option par rapport à l'option précédente)
et d'un champ de longueur (spécifiant la longueur de la valeur de l'option). Les options courantes incluent :
Uri-Path : identifie le chemin de la ressource dans l'URI.
Uri-Query : fournit des paramètres de requête pour la ressource.
Content-Format : spécifie le format de la charge utile.
Max-Age : Indique la durée de validité du cache.
Observing : Indique l’intérêt du client à observer la ressource.
Payload (0 octet ou plus)
La charge utile contient les données réelles envoyées ou reçues. Sa longueur et son format peuvent varier en
fonction du cas d'utilisation spécifique et de l'option de format de contenu spécifiée dans l'en-tête. La charge
utile peut inclure des données de capteur, des commandes ou toute autre information pertinente.
h- Sécurité CoAP
La sécurité est primordiale dans les environnements IoT, et CoAP répond à cette préoccupation en proposant
des mécanismes de sécurité robustes. Il utilise Datagram Transport Layer Security (DTLS) pour établir un canal
de communication sécurisé entre les appareils. Cela garantit la confidentialité et l’intégrité des données
échangées tout en déjouant les attaques potentielles.
i- Transferts par blocs CoAP
La gestion efficace de charges utiles volumineuses est un défi courant dans les réseaux contraints. CoAP relève
ce défi grâce à des transferts par blocs. Les messages sont divisés en blocs plus petits, permettant aux
appareils d'envoyer et de recevoir des données en morceaux gérables. Cette approche minimise le risque
d'erreurs de transmission et optimise le transfert de données dans des scénarios avec des ressources limitées.
j- CoAP et interopérabilité
La compatibilité de CoAP avec les technologies Web existantes, telles que HTTP, garantit une intégration fluide
des appareils IoT dans l'écosystème Internet plus large. Cette interopérabilité ouvre la porte à des applications
innovantes qui comblent de manière transparente le fossé entre les mondes physique et numérique.
Le protocole MQTT
MQTT (Message Queuing Telemetry Transport) est un protocole de messagerie léger basé sur la publish-
subscribe conçu pour les appareils aux ressources limitées et les réseaux à faible bande passante, à latence
élevée ou peu fiables.
MQTT peut fournir des services de messagerie fiables en temps réel pour les appareils connectés au réseau
avec un minimum de code. Le protocole MQTT est largement utilisé dans l'IoT, l'Internet mobile, le matériel
intelligent, l'Internet des véhicules, les villes intelligentes, la télémédecine, l'électricité, le pétrole, l'énergie et
d'autres domaines.
MQTT a été créé par Andy Stanford-Clark d'IBM et Arlen Nipper (alors d'Arcom Systems, plus tard CTO
d'Eurotech). Selon Nipper, MQTT doit avoir les fonctionnalités suivantes :
§ Simple et facile à mettre en œuvre
§ Prise en charge de la QoS (environnement réseau de périphériques complexes)
§ Léger et économe en bande passante (car la bande passante était chère à l'époque)
§ Données non pertinentes (le format des données utiles n'a pas d'importance)
§ Connaissance continue de la session (savoir toujours si l'appareil est en ligne)
Selon Arlen Nipper sur IBM Podcast, MQTT s'appelait à l'origine MQ TT. Notez l'espace entre MQ et TT. Le
nom complet est MQ Telemetry Transport. Il s'agit d'un protocole de transmission de données en temps réel
qu'il a développé alors qu'il travaillait sur un système SCADA de pipeline de pétrole brut pour Conoco Phillips
au début des années 1990. Son objectif était de permettre aux capteurs de communiquer avec l'intégrateur
MQ d'IBM via VSAT, dont la bande passante est limitée. Le nom MQ TT a été choisi conformément aux
pratiques de l'industrie, car Nipper est un professionnel de la télédétection, de l'acquisition et de la
surveillance de données.
a- Pourquoi MQTT est-il le meilleur protocole pour l'IoT ?
MQTT s'est imposé comme l'un des meilleurs protocoles IoT en raison de ses fonctionnalités et capacités
uniques adaptées aux besoins spécifiques des systèmes IoT. Certaines des principales raisons incluent :
Léger : les appareils IoT sont souvent limités en termes de puissance de traitement, de mémoire et de
consommation d'énergie. La surcharge minimale de MQTT et la petite taille des paquets le rendent idéal pour
ces appareils, car il consomme moins de ressources, permettant une communication efficace même avec des
capacités limitées.
Fiable : les réseaux IoT peuvent connaître une latence élevée ou des connexions instables. La prise en charge
par MQTT de différents niveaux de QoS, de la connaissance des sessions et des connexions persistantes
garantit une livraison fiable des messages même dans des conditions difficiles, ce qui le rend bien adapté aux
applications IoT.
Communications sécurisées : la sécurité est cruciale dans les réseaux IoT car ils transmettent souvent des
données sensibles. MQTT prend en charge le cryptage Transport Layer Security (TLS) et Secure Sockets Layer
(SSL), garantissant la confidentialité des données pendant la transmission. De plus, il fournit des mécanismes
d'authentification et d'autorisation via des informations d'identification de nom d'utilisateur/mot de passe ou
des certificats clients, protégeant ainsi l'accès au réseau et à ses ressources.
Bidirectionnalité : le modèle de Publish–subscribe de MQTT permet une communication bidirectionnelle
transparente entre les appareils. Les clients peuvent à la fois publier des messages sur des sujets et s'abonner
pour recevoir des messages sur des sujets spécifiques, permettant un échange de données efficace dans
divers écosystèmes IoT sans couplage direct entre les appareils. Ce modèle simplifie également l'intégration
de nouveaux appareils, garantissant une évolutivité aisée.
Sessions continues et avec état : MQTT permet aux clients de maintenir des sessions avec état avec le broker,
permettant au système de mémoriser les abonnements et les messages non livrés même après la
déconnexion. Les clients peuvent également spécifier un intervalle de maintien pendant la connexion, ce qui
invite le broker à vérifier périodiquement l'état de la connexion. Si la connexion est perdue, le broker stocke
les messages non remis (en fonction du niveau de QoS) et tente de les remettre lorsque le client se
reconnecte. Cette fonctionnalité garantit une communication fiable et réduit le risque de perte de données
due à une connectivité intermittente.
Prise en charge des appareils IoT à grande échelle : les systèmes IoT impliquent souvent un grand nombre
d’appareils, nécessitant un protocole capable de gérer des déploiements à grande échelle. La légèreté de
MQTT, sa faible consommation de bande passante et son utilisation efficace des ressources le rendent bien
adapté aux applications IoT à grande échelle. Le modèle de Publish–subscribe permet à MQTT d'évoluer
efficacement, car il dissocie l'expéditeur et le destinataire, réduisant ainsi le trafic réseau et l'utilisation des
ressources. De plus, la prise en charge par le protocole de différents niveaux de QoS permet de personnaliser
la livraison des messages en fonction des exigences de l'application, garantissant ainsi des performances
optimales dans divers scénarios.
Prise en charge linguistique : les systèmes IoT incluent souvent des appareils et des applications développés à
l'aide de divers langages de programmation. La large prise en charge linguistique de MQTT permet une
intégration facile avec plusieurs plates-formes et technologies, favorisant une communication et une
interopérabilité transparentes dans divers écosystèmes IoT.
b- Comment fonctionne MQTT ?
Pour comprendre le fonctionnement de MQTT, vous devez d'abord maîtriser les concepts de client MQTT, de
broker MQTT, de mode Publish–subscribe, de sujet et de QoS :
Client MQTT
Toute application ou appareil exécutant la bibliothèque client MQTT est un client MQTT. Par exemple, une
application de messagerie instantanée qui utilise MQTT est un client, divers capteurs qui utilisent MQTT pour
rapporter des données sont un client et divers outils de test MQTT sont également un client.
Broker MQTT
Le broker MQTT gère les demandes de connexion, de déconnexion, d'abonnement et de désabonnement des
clients, ainsi que le routage des messages. Un puissant broker MQTT peut prendre en charge des connexions
massives et un débit de messages de plusieurs millions, aidant ainsi les fournisseurs de services IoT à se
concentrer sur leur activité et à créer rapidement une application MQTT fiable.
Modèle de Publish–subscribe
Le modèle de Publish–subscribe diffère du modèle client-serveur dans le sens où il sépare le client qui envoie
des messages (éditeur) du client qui reçoit des messages (abonné). Les éditeurs et les abonnés n'ont pas
besoin d'établir une connexion directe et le broker MQTT est responsable du routage et de la distribution de
tous les messages.
Le diagramme suivant montre le processus de publication/abonnement MQTT. Le capteur de température se
connecte au serveur MQTT en tant que client et publie des données de température sur une rubrique (Topic)
(par exemple, Température), et le serveur reçoit le message et le transmet au client abonné à la rubrique
(Topic) Température.
Topic
Le protocole MQTT achemine les messages en fonction du topic. Le topic distingue la hiérarchie par une barre
oblique /, qui est similaire aux chemins d'URL, par exemple :
chat/salle/1
capteur/10/température
capteur/+/température
Les topics MQTT prennent en charge les caractères génériques suivants : + et #.
+ : indique un seul niveau de caractères génériques, tels que a/+ correspondant à a/x ou a/y.
# : indique plusieurs niveaux de caractères génériques, tels que a/# correspondant à a/x, a/b/c/d.
Qualité de service (QoS)
MQTT propose trois types de qualité de service et garantit la fiabilité de la messagerie dans différents
environnements réseau.
QoS 0 : le message est délivré au maximum une fois. Si le client n'est pas disponible actuellement, il perdra ce
message.
QoS 1 : le message est remis au moins une fois.
QoS 2 : le message n'est délivré qu'une seule fois.
c- Le flux de travail MQTT
Maintenant que nous comprenons les composants de base de MQTT, voyons comment fonctionne le
workflow général :
Les clients établissent une connexion au courtier à l'aide de TCP/IP, avec un cryptage TLS/SSL en option pour
une communication sécurisée. Les clients fournissent des informations d'identification d'authentification et
spécifient une session propre ou persistante.
Les clients publient des messages sur des sujets spécifiques ou s'abonnent à des sujets pour recevoir des
messages. Les clients éditeurs envoient des messages au courtier, tandis que les clients abonnés expriment
leur intérêt à recevoir des messages sur des sujets particuliers.
Le courtier reçoit les messages publiés et les transmet à tous les clients abonnés aux sujets concernés. Il
garantit une livraison fiable des messages selon le niveau de qualité de service (QoS) spécifié et gère le
stockage des messages pour les clients déconnectés en fonction du type de session.
d- Scenario des échanges MQTT
Le MQTT utilise la commande et le format d'accusé de réception de commande, ce qui signifie que chaque
commande est associée à un accusé de réception. Comme le montre la figure ci-dessus, la commande connect
a un accusé de réception de connexion, la commande Subscribe a un accusé de réception d'abonnement et la
commande de publication a un accusé de réception de publication. Ce mécanisme est similaire au mécanisme
de prise de contact du protocole TCP.
e- Structure des paquets MQTT
Le format de message MQTT se compose d'un en-tête fixe de 2 octets, présent dans tous les paquets MQTT.
Le deuxième champ est un en-tête variable, qui n'est pas toujours présent. Le troisième champ est une charge
utile, qui n’est pas toujours présente non plus. Le champ de charge utile contient essentiellement les données
envoyées. On pourrait penser que la charge utile est un champ obligatoire, mais ce n’est pas le cas. Certaines
commandes n'utilisent pas le champ de charge utile, par exemple le message de déconnexion.
