Il y a 5 ans -
Temps de lecture 13 minutes
Internet des Objets : Quels protocoles applicatifs utiliser ? (1/2)
Dans la suite de notre série d’articles autour de l’IoT et après avoir abordé les protocoles radios dans cet article, nous nous attaquons ici aux protocoles applicatifs. Avec le développement de l’IoT au cours de ces dernières années, les protocoles applicatifs se sont multipliés au point que cela devient difficile pour un néophyte de s’y retrouver, et de savoir par où commencer. Ce premier article a pour but d’énumérer quelques protocoles en question, puis nous présenterons dans le second article des exemples d’utilisation.
Protocoles applicatifs et IoT: à quoi ça sert ?
Un protocole applicatif est un ensemble de règles définissant le mode de communication entre deux applications informatiques. Ils se basent sur les protocoles de transport (TCP/UDP) pour établir dans un premier temps des routes et échanger les données selon l’ensemble des règles du protocole applicatif sélectionné.
Pour rappel, un écosystème IoT se présente comme sur l’image suivante:
Écosystème de l’Internet des Objets
Afin que les données brutes puissent être reçues par notre plateforme IoT (cloud), il nous faut une « façade » à travers laquelle les objets puissent se connecter et communiquer. Cette façade constitue ce qu’on appelle une interface d’applications et c’est là que les protocoles applicatifs sont utilisés.
Il est important de noter que l’infrastructure du web classique n’est pas adapté à la majorité des applications IoT. En effet, certains objets connectés, dits contraints, sont limités par de petits microcontrôleurs avec de petites quantités de mémoire (flash et RAM), tandis que les contraintes sur les réseaux IoT, tel que ZigBee, sont dues à des taux d’erreurs de paquets élevés et à un débit faible (quelques dizaines de kbit/s). Par conséquent, pour palier à ces contraintes il faut des protocoles moins verbeux avec un nombre limité de messages et de petites tailles.
Pour la suite, nous avons identifié quatre familles, et pour chacune d’elle nous avons sélectionné les protocoles applicatifs les plus utilisés:
- Protocole de messagerie: MQTT, XMPP et AMQ.
- Protocole de transfert web: CoAP, API REST
- Protocole réseau: Websocket
Protocoles de messagerie
MQTT (Standard dans l’IoT depuis 2015)
topic. Par la suite, ces messages peuvent être lus par des abonnés, appelés subscribers, qui au préalable ont établi une connexion de type ‘subscribe’ avec le broker. Ainsi, la transmission et la consommation des messages se font de manière asynchrone. Le fonctionnement que nous venons de détailler est illustré dans le schéma ci-dessous. Client-A, Client-B et Client-F sont des publishers alors que Client-C, Client-D et Client-E sont des subscribers.
accusés de réception supplémentaires.
L’image suivant schématise ce que nous venons d’énoncer. 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.
En résumé, 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
XMPP
XMPP, pour ‘Extensible Messaging and Presence Protocol‘, est à l’origine un protocole de messagerie instantanée utilisé notamment dans les services Jabber et Google Talk. En outre, son extensibilité a permis son utilisation dans d’autres applications telle que la VoIP. Son fonctionnement est basé sur une architecture client/serveur où l’échange de données, au format XML, se fait sur le même principe que les messageries électroniques. En effet, la communication entre deux clients est asynchrone et est réalisée au travers de serveurs XMPP. Dans un premier temps, un client établit une connexion TCP avec son serveur XMPP, qui communique alors la donnée au serveur XMPP du destinateur. Ce dernier transmet la donnée au destinateur si celui-ci est connecté. Dans le cas contraire, le serveur XMPP mémorise la donnée tant que le destinateur en question ne s’est pas connecté. On peut ajouter qu’un système XMPP est décentralisé et potentiellement temps réel si l’émetteur et le destinateur sont connectés durant la livraison des messages. De plus, chaque client est distingué par un identifiant unique construit sur le modèle suivant :<nom-du-client>@<nom-du-serveur>
L’image suivante illustre ce que nous venons d’expliquer. Lorsque le clientA
souhaite envoyer un message au clientE
, celui-ci spécifie dans le message XMPP :
- l’identifiant de l’émetteur (ici
clientA@domainA
) - l’identifiant du destinataire (ici
clientE@domainB
) - l’information à transmettre dans la partie
body
(iciHello IoT
)
Fonctionnement du protocole XMPP
Les principaux atouts de ce protocole sont son adressage avec identifiant unique, sa facilité de mise en place de la sécurité, son format de messages qui fournit des données structurées et son système de serveurs. Tout cela en fait un protocole plus adapté, contrairement au protocole MQTT, aux applications M2M (Machine-to-Machine). En effet, il gère mieux l’intégration de nouveaux objets connectés et permet interopérabilité avec d’autres plateformes IoT et donc d’autres écosystèmes IoT.
AMQP
AMQP, pour ‘Advanced Message Queuing Protocol’, est un protocole de messagerie qui est une solution alternative aux produits payants MOM (Message-Oriented Middleware) et au JMS. En effet, l’interopérabilité entre différentes implémentations de JMS est très difficile voire n’est pas possible, ce qui présente un énorme frein dans le monde de l’IoT. C’est pour cela que nous n’avons pas choisi ce dernier dans la liste des solutions à étudier.
Le fonctionnement du protocole AMQP est basé sur le même principe que celui de MQTT, toutefois la notion de publisher/subsciber est remplacée par celle de producer/consumer. En outre, grâce à un mécanisme interne noté « exchange », AMQP permet de router un message d’un producer vers plusieurs topics. Les critères de routage peuvent se faire de plusieurs façons ; inspection du contenu, de l’en-tête, clés de routage, etc. Ainsi, un même message peut être consommé par différents consumers via plusieurs topics.
Par conséquent, AMQP est plus adapté aux situations exigeant la fiabilité, des scénarios de messageries plus sophistiqués, l’interopérabilité entre implémentations du protocole et la sécurité. Ainsi, il est plus destiné aux objets connectés avec des contraintes de communication faibles et des exigences de sécurités importantes.
Protocoles de transfert web
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. En revanche, contrairement au protocole HTTP, qui se base sur la suite TCP/IP, le protocole CoAP se base sur la suite UDP/IPv6/6LowPAN, dont les mécanismes d’échange de messages définis par le protocole UDP sont nettement allégés. La correspondance de ces suites par rapport au modèle OSI se trouve dans l’image ci-dessous :
Suites TCP/IP et UDP/IPv6/6LowPAN
En outre, la taille des messages CoAP est également 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, noté RST
Pour transmettre une donnée (comme indiqué en exemple dans l’image ci-dessous), 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) et une action (GET, POST, PUT ou DELETE) sur une ressource identifiée par une URI.
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 et un code réponse (2.xx, 4.xx ou 5.xx) et une représentation de la ressource.
Fonctionnement du protocole 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 que une erreur a été rencontrée par le client
- 5.xx signifie que le serveur n’est pas capable de traiter la requête
Comme on vient de le voir, CoAP est donc un protocole asynchrone adapté au transfert d’états entre un client et un serveur.
API REST
REST, pour ‘Representational State Transfer’, est un protocole qui permet de gérer, identifier et manipuler des ressources (utilisateurs, images, données capteurs, etc.) par l’intermédiaire d’une interface de programmation d’application (ce que l’on appelle en anglais API – Application Programming Interface). Cette interface correspond à un ensemble d’URI accessible via les différentes méthodes (GET, PUT, POST et DELETE) des requêtes HTTP. Les réponses du serveur, contenues dans le corps de la trame HTTP, peuvent être délivrées dans de multiples formats. JSON est souvent le format privilégié même si les formats XML, CSV sont aussi envisageables. Le serveur ajoute également un code réponse HTTP, à trois chiffres, afin d’indiquer l’état de la réponse dont la forme est comme suit :
- 2xx indique le succès du traitement de la requête du client (exemple : 200 pour OK)
- 3xx redirige le client vers un autre lien
- 4xx indique une faute dans la requête du client (exemple : 404 pour Not Found)
- 5xx indique une erreur de la part du serveur (exemple : 500 pour Internal Server Error)
Afin d’illustrer ce fonctionnement, prenons l’exemple du tableau ci-dessous, qui donne la signification de chaque URI d’une API REST :
URI | Méthode | Signification |
---|---|---|
/device/:device/temperature/:temperature | POST | Effectuer un POST en spécifiant, pour l’objet :device , une nouvelle valeur de température :temperature en °C |
/device/:device/location/date/:date | GET | Effectuer un GET pour obtenir la position GPS d’un objet :device à une date donnée :date |
Dans l’exemple de l’image ci-dessous, le client envoie une requête POST pour indiquer au serveur une nouvelle température de 21°C, pour l’objet X043UI. Le serveur lui répond avec un code de 200 pour indiquer que tout est OK. Par la suite, le client envoie une requête GET pour demander la localisation de l’objet A012BE à la date du 01-02-2018. Le serveur répond, dans le corps de la réponse HTTP, les coordonnées : latitude=48.875559, longitude=2.311018.
de communication comme par exemple les smartphones.
Protocole réseau (Websocket)
Le protocole Websocket permet l’établissement d’un canal de communication full-duplex en une seule connexion TCP entre un client et un serveur. L’image ci-dessous indique les trois principales phases de la vie du canal :
- la phase de connexion appelé « Handshake » initié par le client
- la phase d’échange bidirectionnel de messages
- la phase de clôture du canal initié par l’une des deux parties
Fonctionnement d’un protocole Websocket
À l’origine, ce protocole a été mis en place pour palier les lacunes du protocole HTTP dans les communications bidirectionnelles entre une application web et des processus serveur. En effet, la communication est asynchrone, c’est-à-dire que le serveur ne peut envoyer une réponse que si le client a, au préalable, envoyé une requête. Websocket permet donc d’établir des échanges de messages temps réel idéals pour les remontées d’alertes, des notifications.
Ce genre de communication est coûteux en termes de ressources matérielles (CPU, mémoires, source d’énergie) et de bande passante, il n’est donc adapté qu’à des capteurs avec des ressources suffisantes. Il est principalement adapté aux situations de surveillance et d’envoi d’informations en temps réel.
Conclusion
Ainsi s’achève notre premier article sur les protocoles applicatifs dans l’IoT. Nous avons vu différentes familles de protocoles et que chacune d’elles réponde à un besoin spécifique dans l’IoT. Ainsi, cela permet de sélectionner les bons protocoles en fonction des objets connectés utilisés dans son écosystème IoT.
Le tableau ci-dessous résume les caractéristiques des protocoles que nous avons abordés et donne également un comparatif.
Protocole | MQTT | XMPP | AMQP | CoAP | WebSocket | API REST |
Type de protocole | Messagerie | Messagerie | Messagerie | Transfert web | Réseau | Transfert web (HTTP) |
Modèle de communication | Publish/Subscribe | Publish/Subscribe
Request/Response |
Producer/Consumer | Request/Response | bidirectionel | Request/Response |
Transport | TCP/IP | TCP/IP | TCP/IP | UDP/IPv6/6LowPAN | TCP/IP | TCP/IP |
Sécurité | TLS/SSL | TLS/SSL | TLS/SSL | DTLS | TLS/SSL | TLS/SSL |
Format | Binaire, Text (json, xml, csv) | XML | Binaire, Text | Binaire, Text | Binaire, Text | Binaire, Text |
Contraintes sur les objets connectées | Fortes | Faibles/Moyennes | Moyennes | Fortes | Faibles | Faibles |
Principaux framework | Emqtt, HiveMQ, Mosquitto, Eclipse Paho | Jabber, XMPPFramework | RabbitMQ, StormMQ | Eclipse Californium, nCoAP | jetty websocket, Apache Tomcat | Django REST, Apache Tomcat, Node.js, Ruby on Rails |
Dans le second article nous mettrons en pratique ce qui vient d’être étudié sous forme d’exemples d’utilisation.
Commentaire
3 réponses pour " Internet des Objets : Quels protocoles applicatifs utiliser ? (1/2) "
Published by Jérémie A , Il y a 5 ans
Très intéressant, en revanche j’ai une question : REST n’est-il pas plus une manière d’architecturer un service utilisant HTTP qu’un protocole à part entière ?
Published by Laurent , Il y a 5 ans
Il serait intéressant de rajouter MQTT-SN qui est plus destiné à l’IOT avec des messages plus courts.
Pour ce qui est de Coap, il fonctionne parfaitement sur de l’IPv4 ou de l’IPv6, pas seulement sur du 6LowPAN. De plus avec la fonction Observe, il a un comportement proche du pub/sub.
Je trouve que présenter le MQTT comme standard dans l’IOT me semble un peu exagéré. Je n’ai pas encore trouvé de capteurs IOT qui envoient leurs données en MQTT, seulement des passerelles alimentées qui convertissent les messages IoT en MQTT.
Finalement OPC UA est presque plus un standard (mais plus pour l’IIOT, il est vrai) avec des capteurs qui l’implémentent directement et des passerelles, mais il est moins grand-public. Son avantage est que ce n’est pas qu’un protocole de transport mais il structure également la donnée.
Parce que MQTT a beau être mis en avant, il n’y a pas deux serveurs IoT qui comprennent les mêmes messages (souvent échangés en json)… Et je pense que le futur de l’IOT ne passera que par une standardisation des échanges.
Merci pour l’article
Published by Yassir Sennoun , Il y a 5 ans
Merci pour ce complément d’information. Le but de cet article est de donner suffisamment de détails tout en restant exhaustif c’est pour cela que je n’ai pas aboder MQTT-SN… Selon le lien suivant, MQTT est bien un standard pour le consortium OASIS.