Chapitre 5 Protocoles Applicatifs Iot: MQTT Coap

Chapitre 5
Protocoles applicatifs IoT

HTTP
MQTT
CoAP
Introduction
Introduction
 Une plateforme IoT combine plusieurs protocoles et des
réseaux hétérogènes afin d'aider les entreprises à gérer
leurs actifs et à créer une application pour l'utilisateur
final.
 Il existe plusieurs plateformes IoT, qui présentent toutes
des avantages spécifiques et ciblent des marchés
différents. Les connexions entre le serveur IoT et la
plateforme IoT supportent souvent les protocoles
applicatifs HTTP et MQTT.
 Un protocole applicatif est un ensemble de règles
définissant le mode de communication entre deux
applications informatiques.
2
 Le dialogue entre les serveurs IoT et la plateforme IoT peut se faire à
l'aide de différents protocoles applicatifs (MQTT, HTTP et CoAP).
3
HTTP
 L’architecture client/serveur
Le terme client / serveur décrit un type de traitement distribué
dans lequel une application est divisée en deux parties. Chaque
partie peut être sur des systèmes d'exploitation distincts, mais ils
fonctionnent ensemble pour fournir un service à l'utilisateur.
4
HTTP
 L’architecture client/serveur désigne un mode de

communication à travers un réseau entre plusieurs
programmes ou logiciels :
 Le processus client envoie des requêtes pour demander
un service.
 Le processus serveur attend les requêtes des clients et
y répond en offrant le service.
 La communication débute TOUJOURS à la demande du
client.
5
HTTP
La plateforme IoT sera le lien avec l'utilisateur et devra effectuer

les actions suivantes
 Uplink : du serveur LoRaWAN vers la plateforme IoT (application
utilisateur).
 Downlink : de la plateforme IoT (application utilisateur) au serveur IoT
(LoRaWAN par exemple).
6
HTTP
 Le protocole HTTP (Hyper Text Transfer Protocol) est le

protocole au niveau application le plus utilisé sur
Internet.
 Le but du protocole HTTP est de permettre un transfert

de fichiers (essentiellement au format HTML) localisés
grâce à une chaîne de caractères appelée URL entre un
navigateur (le client) et un serveur Web.
7
HTTP
 Il se base sur la suite TCP/IP (Transmission Control Protocol

/ Internet Protocol).
 TCP/IP représente l'ensemble des règles de communication
sur internet et se base sur la notion adressage IP, c'est-à-
dire le fait de fournir une adresse IP à chaque machine du
réseau afin de pouvoir acheminer des paquets de données.
 HTTP est un protocole gourmand pour un appareil IoT.
 Il comporte de grands messages, car ils sont envoyés dans

un format lisible par l‘Homme.
8
HTTP
 La communication entre le navigateur et le serveur se fait en

deux temps :
 Le navigateur (client) effectue une requête HTTP
 Le serveur traite la requête puis envoie une réponse HTTP
9
HTTP
Requête HTTP
 Une requête HTTP est un ensemble de lignes envoyées au
serveur par le navigateur. Elle comprend :
 Une ligne de requête: La ligne comprend trois éléments devant
être séparés par un espace :
 La méthode (GET, POST, DELETE, PUT,…)
 L'URL
 La version du protocole utilisé par le client (HTTP/1.0)
10
HTTP
 Les champs d'en-tête de la requête (invisible pour les

utilisateurs)
 Il s'agit d'un ensemble de lignes facultatives permettant de

donner des informations supplémentaires sur la requête
et/ou le client (Navigateur, système d'exploitation, ...).
 Chacune de ces lignes est composée d'un nom qualifiant le
type d'en-tête, suivi de deux points (:) et de la valeur de
l'en-tête.
11
HTTP
 Exemple d’une requête HTTP
12
HTTP
Réponse HTTP
 Une réponse HTTP est un ensemble de lignes envoyées au
navigateur par le serveur.
 Elle comprend :Une ligne de statut: c'est une ligne précisant la
version du protocole utilisé et l'état du traitement de la
requête à l'aide d'un code et d'un texte explicatif. La ligne
comprend trois éléments devant être séparés par un espace :
 La version du protocole utilisé
 Le code de statut
 La signification du code 13
HTTP
 Les champs d'en-tête de la réponse: il s'agit d'un ensemble de
lignes facultatives permettant de donner des informations
supplémentaires sur la réponse et/ou le serveur. Chacune de
ces lignes est composée d'un nom qualifiant le type d'en-tête,
suivi de deux points (:) et de la valeur de l'en-tête
 Le corps de la réponse: il contient le document demandé
 Exemple
14
HTTP
Commandes HTTP
15
MQTT
 MQTT(Message Queuing Telemetry Transport) est un
standard ISO (ISO/IEC PRF 20922) basé sur TCP.
 MQTT est un protocole de messagerie de
publication/souscription (publish/subscribe) léger
conçu pour M2M (machine to machine) dans les
environnements à faible bande passante.
 Au départ, ce protocole a été développé par Andy
Stanford-Clark (IBM) et Arlen Nipper (Eurotech) en
1999
 MQTT est un protocole ouvert, simple, léger et
facile à mettre en œuvre. 16
MQTT
 Ce protocole est idéal pour répondre aux besoins suivants :
17
MQTT
 MQTT peut fournir des services de messagerie fiables en

temps réel pour les appareils connectés au réseau avec un
code minimal.
 Le protocole MQTT est largement utilisé en IoT (Internet

mobile, Smart Hardware, Smart Cities, Télémédecine,
Énergie).
18
MQTT
 Le protocole MQTT utilise une architecture

«publish/subscribe » tandis que le protocole HTTP utilise
une architecture « request/response ».
 Contrairement au principe de client/serveur utilisé sur le
web, MQTT utilise celui de la publication/souscription. En
effet, plusieurs clients se connectent à un serveur unique
(le broker) soit pour publier des informations, soit pour
souscrire à leur réception.
 MQTT peut être implémenté dans la plupart langages de
programmation (python, C, Java,…). 19
MQTT
 La différence est importante, car elle évite de devoir

demander (requête) des données dont on ne sait pas
quand elles arriveront.
 Une donnée sera directement transmise aux Subscribers

dès qu'elle aura été reçue dans le Broker (serveur
central). Pour recevoir les données appartenant à un
Topic, le Subscriber doit d'abord souscrire à un Topic.
20
MQTT
Remarque: Le Serveur HTTP est un serveur web ( Exemple : Apache HTTP). 21

MQTT
22
MQTT
23
MQTT
Le broker MQTT
 Le broker le plus connu reste Mosquitto (géré par la
fondation eclipse)
 Le point central de la communication est le broker
MQTT qui est en charge de relayer les messages des
émetteurs vers les clients.
 Chaque client s’abonne via un message vers le broker
: le « topic » (sorte d’information de routage pour le
broker) qui permettra au broker de réémettre les
messages reçus des éditeurs ‘publishers’ vers les
clients.
 Les clients n’ont pas à se connaître, ils ne
communiquent qu’ à travers des topics. 24
MQTT
Authentification du client
 Un broker ‘Mosquitto’ peut vérifier l'identité d'un client
MQTT de trois manières:
 Identifiants clients (clients Ids)
 Noms d'utilisateur et mots de passe (Usernames and
passwords)
 Certifications des clients (Client Certificates)
25
MQTT
Identifiant client (client Id)
 Tous les clients MQTT doivent fournir un identifiant client.
 Lorsqu'un client s'abonne à une ou plusieurs rubriques (Topics), l'ID
client lie la rubrique au client et à la connexion TCP (protocole
Transport).
Username and Password
 Un broker MQTT peut exiger un nom d'utilisateur et un mot de passe
valides d'un client avant qu'une connexion ne soit autorisée.
 C’est le moyen le plus facile et le plus utilisé pour restreindre
l'accès à un broker.
Certifications des clients
 En cryptographie, un certificat client est un type de certificat
numérique utilisé par les clients pour effectuer des requêtes
authentifiées à un serveur distant. 26
MQTT
Les Topics MQTT
27
MQTT
Les Topics MQTT

 Les clients de souscription MQTT s’enregistrent auprès de broker sur
des Topics (des chemins d’accès à une ressource). Ils demandent
ainsi à être notifiés lorsque quelqu’un publie sur ces Topics.
 Un « topic MQTT » est une chaîne de caractères qui peut posséder
une hiérarchie de niveaux séparés par le caractère « / » (une
arborescence).
Exemple
 La température du salon pourrait être envoyée sur le topic «
maison/salon/température »
La température de la cuisine sur « maison/cuisine/température ».
28

MQTT
 Un Topic est une hiérarchie de chaînes de caractères séparées

par la barre oblique "/" comme séparateur.
Exemple de hiérarchie avec la liste des Topics associés 29

MQTT
Les Topics MQTT

 Un client peut s'abonner à des branches entières de l'arborescence à
l'aide des deux caractères génériques suivants (wildcards) :
 le signe plus (+), qui correspond à un seul niveau,
 le dièse (#) pour plusieurs niveaux.
 Un client peut recevoir toutes les températures :
maison/+/temperature. Il recevra donc les températures de la
cuisine (maison/cuisine/temperature) et les températures du
salon (maison/salon/temperature).
 Par exemple, si un client s’abonne au topic « maison/salon/# », il
recevra toutes les données du salon. De même, s’il s’abonne au
topic « maison/# », il collectera toutes les données des capteurs
déployés dans la maison (température, humidité,........).
30
MQTT
31
MQTT
Exemples de Topics MQTT
32
MQTT
33
MQTT
 Le publisher transmet des message de type PUBLISH pour

publier une nouvelle donnée et le subscriber utilise un
message SUBSCRIBE pour recevoir des données.
 Le client s'authentifie en envoyant un nom d'utilisateur et
un mot de passe au serveur « broker » lors de la séquence
de paquets CONNECT/CONNACK.
 Le service confirmé (Acknowledged Service) 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. 34
MQTT
 Un client peut effectuer une autre 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 permet de maintenir une connexion
active et de s'assurer que la connexion TCP n'a pas été
interrompue.
 Lorsqu'un éditeur ou un abonné souhaite mettre fin à une
session MQTT, il envoie un message DISCONNECT au
broker.
35
MQTT
 Pour cet exemple, nous utilisons:
■ Le Broker Mosquitto
■ Le client Subscriber de MQTT Box
■ Le client Publisher de MQTT Box
36
MQTT
Configuration d'un Publisher et d'un Subscriber MQTT

 Nous utilisons le client MQTT MQTTBox.
 Lancez le logiciel MQTTBox.
 MQTTBox > Create MQTT Client.
 Un client MQTT doit connaître l'adresse du Broker :
■ Protocole : mqtt / tcp
■ Host : test.mosquitto.org
37
MQTT
 MQTT intègre la qualité de service (QoS). En effet le

publisher a la possibilité de définir la qualité de son
message.
 Trois niveaux sont possibles :
 Un message de QoS niveau 0 « At most once ». Ce qui
signifie que le message est envoyé sans garantie de
réception, (le broker n’informe pas l’expéditeur qu’il a
reçu le message)
38
MQTT
 Un message de QoS niveau 1 « At least once ». Le client

transmettra plusieurs fois s’il le faut jusqu’à ce que le
Broker lui confirme que le message était transmis sur le
réseau.
 Un message de QoS niveau 2 « exactly once » sera
obligatoirement sauvegardé par l’émetteur et le
transmettra toujours tant que le récepteur ne confirme
pas son envoi sur le réseau.
39
MQTT
40
MQTT
Exportation des données avec le protocole MQTT

Il existe plusieurs possibilités pour utiliser le protocole MQTT avec un
serveur LoRaWAN. Cela dépend de qui est le Broker et de qui sont le
Publisher et le Subscriber.
 Serveur LoRaWAN en tant que Broker MQTT
La première architecture est simple.
■ Le serveur LoRaWAN est le Broker MQTT.
■ Vous devez souscrire au Topic approprié pour recevoir des
données (1) .
■ Vous devez publier sur le Topic approprié pour envoyer des
données (2) . 41
MQTT
42
MQTT
 Le serveur LoRaWAN en tant que client MQTT

Cette deuxième architecture de réseau consiste à :
■ Un Broker MQTT est placé entre le serveur LoRaWAN et l'Application
Utilisateur.
■ Le serveur LoRaWAN publie sur le Topic approprié pour envoyer des
données au Broker (1) .
■ Vous devez souscrire au Topic approprié sur le Broker pour recevoir des
données (2) .
■ Vous devez publier au Topic approprié sur le Broker pour envoyer des
données (3) .
■ Le serveur LoRaWAN souscrit au Topic approprié pour recevoir les données
du Broker (4) . 43
MQTT
44
MQTT
 Vous avez toujours besoin des informations suivantes :
 L'URL du Broker MQTT
 Le nom d'utilisateur pour se connecter à votre Broker.
 Le mot de passe pour se connecter à votre Broker.
 Le Topic que vous choisissez pour la réception des données.
 Le Topic sur lequel il faut publier pour envoyer des données.

45
MQTT
Exemple
46
MQTT
 Dans Actility, il faut d'abord créer et configurer le client MQTT :
Actility > Connexions > TPX > MQTT .
 TPX: Actility ThingPark X IoT Flow est le module de flux de
données de la plateforme ThingPark qui traite les messages
uplink (capteur à réseau) et messages downlink (commandes
aux capteurs et aux actionneurs).
 Puis vous entrez les paramètres suivants :
 Hostname: broker.hivemq.com:1883
 MQTT Username: test
 MQTT Password: test
 Uplink topic pattern: mqtt/things/{DevEUI}/uplink
 Downlink topic pattern: mqtt/things/{DevEUI}/downlink 47
 Vous devez changer {DevEUI} par votre Device EUI

CoAP
 CoAP, pour ‘Constrained Application Protocol’, est un

protocole web basé sur une architecture client/serveur. Ce
protocole reprend en partie les méthodes et nomenclatures
du protocole HTTP.
 Contrairement au protocole HTTP, qui se base sur la suite

TCP/IP, le protocole CoAP se base sur la suite UDP/IPv6.
48
CoAP
 La taille des messages CoAP est allégée par rapport à celle des messages
HTTP; l’en-tête d’un message CoAP est fixé à 4 octets alors que celui des
messages HTTP est variable.
 L’en-tête de chaque paquet contient le type de message et la qualité de
service souhaitée pour la transmission du message :
 Confirmable : Message envoyé avec une demande d’accusé de
réception, noté CON
 Non-Confirmable : Message envoyé sans demande d’accusé de
réception, noté NON
 Acknowledgment : Accusé de réception du message de type
«confirmable », noté ACK
 Reset : Accusé de réception d’un message qui n’est pas exploitable,
49
noté RST
CoAP
 Pour transmettre une donnée, un client envoie à un serveur

une requête CoAP, dans laquelle se trouve :
 le type du message (CON ou NON)
 l’identifiant du message (mid)
 une action (GET, POST, PUT ou DELETE)
 l’information (température,....)
 Si la requête est du type CON alors le serveur retourne une
réponse dans laquelle se trouve:
 le type du message (ACK)
 le même ‘mid’ que celui de la requête
 un code réponse (2.xx, 4.xx ou 5.xx)
une représentation de la ressource
50

CoAP
 La signification du code réponse est la suivante :

 2.xx signifie que la requête a été correctement reçue et
traitée
 4.xx signifie qu’une erreur a été rencontrée par le client
 5.xx signifie que le serveur n’est pas capable de traiter la
requête
51
CoAP
 CoAP est un protocole asynchrone adapté au transfert entre un client et
un serveur.
 Soit une requête de type GET transportée dans un message CON avec la
réponse retournée dans un message ACK. Une des réponses indique un
succès (2.05) et l’autre indique un échec (4.04).
52
CoAP
 Si le serveur n’est pas en mesure de répondre
immédiatement à une requête (GET) transportée dans un
message CON, il répond simplement via un message ACK sans
contenu.
 Lorsque la réponse est prête, le serveur l’émet dans un
nouveau message CON (qui devra être acquitté par le client
via un message ACK sans contenu).
Rq: Le token est une donnée créée par le serveur contenant des
informations permettant d’associer une requête avec une réponse. il
peut y avoir plusieurs jetons pour le même utilisateur. Le jeton a une
durée de vie. Il est valide pendant 1800 secondes à partir de sa
création (configurable). Les jetons expirés ne sont pas valides.
53
Comparaison
54
 Application
Expliquez ces échanges
selon le protocole MQTT.
55
Correction
 Le client C est un publisher, il transmet un message de
type PUBLISH pour publier une nouvelle donnée selon un
Topic2. Le Broker confirme la réception de son message
en envoyant PUBREC.
 Le client A est un publisher aussi, il transmet un message
de type PUBLISH pour publier une nouvelle donnée selon
un Topic1. Le Broker confirme la réception de son
message en envoyant PUBREC.
 Le client F est un subscriber, il s’authentifie en envoyant
un nom d'utilisateur et un mot de passe au serveur
« broker » lors de la séquence de paquets 56
CONNECT/CONNACK.
 Ensuite, le client F se souscrit (s’abonne) au niveau du

broker à un Topic3 en utilisant un
message SUBSCRIBE pour recevoir des données. Le broker
confirme la souscription avec un message SUBACK.
 Tant que le client F s’est souscrit au Topic3, alors le

Broker lui transmet toute donnée en relation avec ce
Topic à travers un message PUBLISH (Topic3). Et le client
F confirme la reception avec un message PUBREC.
57

Chapitre 5 Protocoles Applicatifs Iot: MQTT Coap

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Chapitre 5 Protocoles Applicatifs Iot: MQTT Coap

Transféré par

Droits d'auteur :

Formats disponibles

Chapitre 5

Protocoles applicatifs IoT

 L’architecture client/serveur désigne un mode de

La plateforme IoT sera le lien avec l'utilisateur et devra effectuer

 Le protocole HTTP (Hyper Text Transfer Protocol) est le

 Le but du protocole HTTP est de permettre un transfert

 Il se base sur la suite TCP/IP (Transmission Control Protocol

 Il comporte de grands messages, car ils sont envoyés dans

 La communication entre le navigateur et le serveur se fait en

 Les champs d'en-tête de la requête (invisible pour les

 Il s'agit d'un ensemble de lignes facultatives permettant de

 Exemple d’une requête HTTP

 Ce protocole est idéal pour répondre aux besoins suivants :

 MQTT peut fournir des services de messagerie fiables en

 Le protocole MQTT est largement utilisé en IoT (Internet

 Le protocole MQTT utilise une architecture

 La différence est importante, car elle évite de devoir

 Une donnée sera directement transmise aux Subscribers

Remarque: Le Serveur HTTP est un serveur web ( Exemple : Apache HTTP). 21

Les Topics MQTT

Les Topics MQTT

 Un Topic est une hiérarchie de chaînes de caractères séparées

Exemple de hiérarchie avec la liste des Topics associés 29

Les Topics MQTT

Exemples de Topics MQTT

 Le publisher transmet des message de type PUBLISH pour

 Un client peut effectuer une autre opération au cours de

 Pour cet exemple, nous utilisons:

■ Le client Subscriber de MQTT Box

■ Le client Publisher de MQTT Box

Configuration d'un Publisher et d'un Subscriber MQTT

 MQTT intègre la qualité de service (QoS). En effet le

 Un message de QoS niveau 1 « At least once ». Le client

Exportation des données avec le protocole MQTT

 Le serveur LoRaWAN en tant que client MQTT

 Vous avez toujours besoin des informations suivantes :

 L'URL du Broker MQTT

 Le nom d'utilisateur pour se connecter à votre Broker.

 Le mot de passe pour se connecter à votre Broker.

 Le Topic que vous choisissez pour la réception des données.

 Le Topic sur lequel il faut publier pour envoyer des données.

 Vous devez changer {DevEUI} par votre Device EUI

 CoAP, pour ‘Constrained Application Protocol’, est un

 Contrairement au protocole HTTP, qui se base sur la suite

 Pour transmettre une donnée, un client envoie à un serveur

 La signification du code réponse est la suivante :

 Ensuite, le client F se souscrit (s’abonne) au niveau du

 Tant que le client F s’est souscrit au Topic3, alors le

Vous aimerez peut-être aussi