Les protocoles IP pour l'Internet des Objets

Introduction

Afin de rendre le déploiement des objets de l’Internet de plus en plus robuste et sûr, un grand nombre de protocoles ont vu le jour sous l’égide de différentes organisations. La question de savoir quel est le meilleur protocole permettant d’échanger des données entre l’Internet et les objets de l’Internet est une question ouverte et la réponse dépend certainement d’un grand nombre de facteurs et n’est donc pas unique.

Dans ce chapitre, nous analysons différents protocoles d’application reposant sur le stack IP. Ces protocoles sont toutes des technologies permettant le transfert de données de et vers les objets de l’Internet :

Hypertext Transfer Protocol (HTTP/1.1)
WebSockets
Message Queuing Telemetry Transport (MQTT)
Constrained Application Protocol (CoAP)

Ces protocoles reposent tous sur une couche de transport (comme TCP ou UDP) et sur une couche de liaison et physique (comme Ethernet, Wi-Fi ou 802.15.4). Cette liste n’est pas une liste exhaustive, mais elle permet d’aborder les points importants et d’établir ainsi une comparaison pertinente. Une telle comparaison pourrait ensuite être étendue sans grande difficulté à d’autres technologies. Dans tous les cas, il est relativement improbable qu’une seule technologie réponde à tous les besoins et la multitude de configurations et de cas d’utilisation nécessitera très probablement la mise en œuvre d’une combinaison de technologies.

Les besoins des objets de l’Internet

Afin d’analyser les différentes technologies de communication basées sur IP, les fonctionnalités suivantes seront considérées :

la qualité de service : est-ce que le protocole nécessite une couche de transport fiable ? Quelle est l’architecture générale devant être mise en œuvre ?
le modèle d’échange de données : est-ce que les données sont échangées selon un modèle request/response ou publish/subscribe ?
le support pour des communications sécurisées.
le type d’applications supportées.

Le choix de la technologie la plus appropriée peut s’effectuer sur la base de ces critères ou d’autres critères non mentionnés ici. Il est évident que chaque application n’aura pas les mêmes contraintes et que donc le choix pourra être différent pour différents types d’applications. Il se peut que la qualité de service soit très importante pour une application et beaucoup moins pour une autre. Il se peut aussi qu’un modèle de communication request/response soit plus approprié dans un cas que dans un autre. Le but est donc de construire une compréhension des différentes technologies afin de pouvoir établir un choix pour une situation donnée.

Request/Response vs. Publish/Subscribe

Le modèle traditionnel permettant d’échanger des données sur le web est le modèle request/response. Avec ce modèle, un client formule une requête pour un serveur qui répond à la requête en délivrant une réponse (qui souvent contient des données). C’est bien sûr comme cela que fonctionnent la plupart des applications web, avec un client qui est un navigateur et le serveur qui est un serveur web HTTP. Ce modèle peut bien sûr aussi être appliqué avec les systèmes embarqués.

Une manière différente permettant de transférer des données sur un réseau est le modèle publish/subscribe. Avec ce modèle, un dispositif central appelé le broker reçoit les données et les distribue. Les clients de ce broker peuvent publier des données vers ce broker ou souscrire à des données distribuées par ce broker. Un client peut bien sûr à la fois publier et souscrire vers le même ou plusieurs brokers. Avec ce mécanisme, un client ne publie des données que lorsque celles-ci sont modifiées et les clients qui souscrivent à ces données reçoivent automatiquement les nouvelles données (également uniquement lors d’un changement de données). Le broker ne sauvegarde pas les données, mais permet uniquement à ces données d’être transférées des publishers vers les subscribers.

Le protocole HTTP/1.1

HTTP/1.1 est un protocole point à point qui ne supporte pas le multicast. Il utilise uniquement TCP comme couche de transport et est basé sur un modèle de request/response. Le protocole utilise des méthodes (comme GET, POST ou PUT) afin d’indiquer l’action requise sur une ressource identifiée par un URI. Une architecture RESTful est donc entièrement réalisable, mais un modèle de communication publish/subscribe n’est pas possible avec HTTP/1.1. Les communications groupées ne sont également pas supportées, car HTTP/1.1 applique un modèle de communication strictement point à point. Afin de réaliser un protocole sécurisé, HTTP/1.1 repose sur TLS.

HTTP/1.1 est un protocole avec des entêtes textuels et qui encode les paramètres URI en Base64. Le protocole introduit donc un overhead important.

Il est intéressant de noter que la première version de HTTP nécessitait la création d’une connexion TCP pour chaque requête/réponse. Avec HTTP/1.1, une technique de keep-alive a été ajoutée afin de permettre de réutiliser une même connexion TCP pour plusieurs échanges requête/réponse.

L’organisme en charge du standard est l’IETF et les documents de spécification sont les RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing et RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content.

Le diagramme ci-dessous illustre le stack utilisé pour le protocole HTTP/1.1 ainsi que le mécanisme de transfert de données :

Le protocole WebSocket

Le protocole WebSocket utilise HTTP/1.1 pour la phase de négociation et ensuite TCP pour le transfert de données. Les WebSockets utilise uniquement la couche TCP comme couche de transport et repose également sur TLS pour la réalisation d’un protocole sécurisé.

Le but principal du protocole est de maintenir une connexion TCP ouverte pour une durée étendue, afin de permettre une communication bi-directionnelle entre le client et le serveur. Une fois que la connexion a été négociée et établie à l’aide de HTTP (entêtes Sec-WebSocket-Accept et Sec-WebSocket-Protocol), les deux entités peuvent envoyer et recevoir des messages. Le protocole est donc une alternative intéressante au mécanisme de HTTP polling, qui consiste à interroger le serveur à intervalle régulier afin de mettre à jour l’état d’une ressource.

L’organisme en charge du standard est l’IETF et le document de spécification est le RFC 6455: The WebSocket Protocol. Les spécifications établissent le format des WebSocket frames, qui sont échangés entre les deux dispositifs, mais le format du payload contenu dans chaque trame est spécifique à chaque application.

Le diagramme ci-dessous illustre le stack utilisé pour le protocole WebSocket ainsi que le mécanisme de transfert de données :

Le protocole CoAP

CoAP est un protocole qui présente de nombreuses similitudes avec HTTP/1.1. Le protocole permet de réaliser des services RESTful et une connexion point à point entre deux dispositifs. Pourtant, CoAP n’est pas une version compressée de HTTP/1.1. Il est au contraire un protocole qui a été conçu dès le départ pour être réalisé sur des dispositifs aux ressources très limitées (en mémoire et en capacité de calcul). Le protocole peut ainsi être réalisé sur des dispositifs disposant de peu de mémoire, ce qui est beaucoup plus difficile avec HTTP. CoAP peut utiliser différentes couches de transport et il a été conçu pour pouvoir utiliser UDP comme couche de transport. Une connexion sécurisée peut donc établie grâce à DTLS. CoAP supporte également les communications multicast.

Une des particularités de CoAP est de déléguer à la couche application la gestion de la fiabilité des communications. Le protocole supporte le transfert de données fiable et non fiable, en réalisant des messages quittancés ou non quittancés, au niveau de la couche application. La couche application CoAP est ainsi réalisée en deux sous-couches : la sous-couche assurant la fiabilité (reliability sub-layer) et la sous-couche assurant le mécanisme requête/réponse (selon le principe REST et avec les mêmes méthodes que HTTP/1.1).

L’organisme en charge du standard est l’IETF et le document de spécification est le RFC 7252: The Constrained Application Protocol (CoAP). D’autres documents spécifient des aspects particuliers du protocole comme les communications de groupe RFC 7390: Group Communication for the Constrained Application Protocol (CoAP) ou le mécanisme d’observation RFC 7641: Observing Resources in the Constrained Application Protocol (CoAP). Le document RFC 8323: CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets spécifie également la réalisation de CoAP sur la couche de transport TCP. L’utilisation d’un modèle de communication publish/subscribe à l’aide de CoAP est également supportée I-D.ietf-core-coap-pubsub: “Publish-Subscribe Broker for the Constrained Application Protocol (CoAP). L’ensemble de ces efforts de spécification illustre la variété des scénarios pouvant être réalisés à l’aide de ce protocole.

Le diagramme ci-dessous illustre le stack utilisé pour le protocole CoAP ainsi que le mécanisme de transfert de données :

Le protocole MQTT

Contrairement à HTTP, WebSocket et CoAP, le protocole MQTT ne réalise pas un modèle de transfert de données par requête/réponse. Le protocole adopte le mécanisme publish/subscribe et requiert des clients qu’ils se connectent à un serveur central ou broker. Les clients peuvent ensuite publier (écrire) ou souscrire (lecture notifiée) à des topics pour échanger des données.

Lorsqu’un client publie un message, il l’envoie au broker pour que celui-ci puisse le distribuer à tous les clients qui ont souscrit au topic associé au message. Les topics constituent une arborescence permettant de définir une source d’informations hiérarchisées auxquelles les clients peuvent souscrire. Ce mécanisme permet aux clients de sélectionner les sources d’informations d’intérêt pour eux, en même temps que la qualité de service qui doit être réalisée pour cette source d’information. MQTT permet de réaliser différentes qualités de services et ainsi permet de garantir la délivrance des messages. Les qualités de service réalisées sont At most once (pertes possibles), At least once (sans perte, mais avec duplications possibles) et Exactly once (sans perte, sans duplication).

Comme les clients peuvent à la fois publier vers et souscrire à des topics, MQTT permet une communication bi-directionnelle entre les clients via le broker. Chaque client se connecte au broker via un socket TCP/TLS. Une fois connecté, le client peut librement publier vers ou souscrire à des topics.

MQTT for Sensor Networks (MQTT-SN) est une adaptation de MQTT permettant un meilleur fonctionnement sur des réseaux sans-fil où les pertes de données sont fréquentes et avec une taille de paquet réduite au niveau de la couche de liaison/physique. Alors que MQTT repose sur TCP comme couche de transport, MQTT-SN a adopté UDP comme couche de transport. L’architecture MQTT-SN est également différente avec des clients, des serveurs, des gateways et des forwarders.

L’organisme en charge du standard n’est pas l’IETF, mais OASIS. Le document de spécification est le OASIS Standard MQTT Version 3.1.1 Plus Errata 01. Le document de spécification de MQTT-SN est le MQTT For Sensor Networks (MQTT-SN).

Le diagramme ci-dessous illustre le stack utilisé pour le protocole MQTT ainsi que le mécanisme de transfert de données :

Conclusion

Chacune des technologies de transfert de données présentées ci-dessus peut être un choix pertinent en fonction de l’application et des contraintes pour la réalisation de cette application. Plusieurs des technologies ont été développées en tenant compte des ressources limitées disponibles sur les dispositifs devant héberger les applications et ces contraintes ont donc une influence importante dans le choix d’une technologie.

De manière générale, nous pouvons dire que :

Lorsque la couche physique et de liaison met en œuvre des technologies radio à basse consommation, les technologies de transfert qui utilisent un encodage compact présentent des avantages. C’est le cas du protocole CoAP qui peut s’avérer un meilleur choix que HTTP dans ces cas.
Si les applications qui requièrent des communications groupées, les protocoles MQTT et CoAP sont alors appropriés. Seul CoAP support le multicast IP, qui peut être utile pour la découverte de dispositifs.
Si une application ne requiert pas un transfert de données fiable dans tous les cas (par exemple les réseaux de capteurs dans certains cas), l’utilisation d’une couche de transport avec un overhead limité comme UDP peut s’avérer un choix judicieux. Dans la plupart des cas, la perte d’un message reste improbable et l’économie réalisée pour tous les échanges peut être importante.
La mise en œuvre d’un protocole de transfert sécurisé est possible dans tous les cas avec TLS ou DTLS.
HTTP est le protocole utilisé dans tous les environnements où un navigateur web est disponible. HTTP requiert une connexion robuste et implique une utilisation de ressources supérieure ainsi qu’un overhead supérieur.
CoAP et MQTT sont des protocoles assez récents, cependant ils gagnent en popularité, sont disponibles via des réalisations open source dans divers environnements et continuent à se développer au sein de leurs organisations respectives (IETF et OASIS).
De nombreuses études ont commencé à comparer les différentes technologies (en particulier MQTT et CoAP) sur différents critères et les résultats de ces études permettront d’effectuer les meilleurs choix possibles pour le futur.

Dans le cadre de ce cours, nous allons étudier les protocoles MQTT et CoAP de manière plus détaillée. Nous mettrons également en œuvre ces protocoles dans les travaux pratiques à venir.