Articles

Publié par
IoT

Il y a 5 mois -

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

Les protocoles de messagerie s’appuient sur un mécanisme de publication et d’abonnement, où les transferts de données se font de manière asynchrone. Présentons le fonctionnement et les caractéristiques des protocoles MQTT, XMPP et AMQ.

MQTT (Standard dans l’IoT depuis 2015)

 

MQTT, pour ‘Message Queuing Telemetry Transport‘,est un protocole de messagerie de publication et d’abonnement (publish/subscribe) basé sur le protocole TCP/IP. Un client, appelé publisher, établi dans un premier temps une connexion de type ‘publish’ avec le serveur MQTT, appelé broker. Puis, le publisher transmet les messages au broker sur un canal spécifique, appelé
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.
Fonctionnement du protocole MQTT
MQTT a la particularité d’être un protocole léger parce que le nombre de messages est restreint et ont des tailles faibles. En effet, chaque message se compose d’un en-tête fixe de 2 octets (spécifiant le type de message et le niveau de qualité de service employée), d’un en-tête variable facultatif, d’une payload (charge utile) limitée à 256 Mo. Il existe trois niveaux de qualité de service (QoS) qui déterminent la façon dont le protocole MQTT gère le contenu. Les clients abonnés peuvent spécifier le niveau de QoS maximal qu’ils souhaitent recevoir. Toutefois, plus le niveau de qualité est élevé et plus cela est gourmand en termes de latence et de bande passante, à cause des répétitions et des
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.

Échanges entre publishers, subscibers et un broker MQTT

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 (ici Hello 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.

Fonctionnement du protocole AMQP

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.

Fonctionnement d’un exemple de API REST
API REST est largement utilisé et a fait ses preuves, il est simple à mettre en place et à modifier grâce à une combinaison d’URI et de méthodes. Il reste adapter aux objets connectées qui n’ont pas de contraintes
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.

Publié par

Commentaire

3 réponses pour " Internet des Objets : Quels protocoles applicatifs utiliser ? (1/2) "

  1. Publié par , Il y a 5 mois

    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 ?

  2. Publié par , Il y a 5 mois

    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

  3. Publié par , Il y a 3 mois

    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.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.