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:

• 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)

Fonctionnement du protocole MQTT

É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.

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.

 

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.

Dans le second article nous mettrons en pratique ce qui vient d’être étudié sous forme d’exemples d’utilisation.