Quels sont les protocoles dapplication ?

Dans la suite de notre série d’ 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 dernières années, les protocoles applicatifs se sont multipliés au point que 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. 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 :

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

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, pour ‘Message Queuing Telemetry Transport‘,est un protocole de messagerie de publication et d’abonnement (publishsubscribe) 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  de manière asynchrone. Le fonctionnement que nous venons de détailler est illustré dans le schéma . 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
supplémentaires.

É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
• 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 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 :

• 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. 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, , clés de r 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, 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, 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 :

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

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

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