CoAP () est un protocole de transfert Web optimisé pour les périphériques et réseaux contraints utilisés dans les réseaux de capteurs sans fil pour former l'Internet des objets. Basé sur le style architectural REST, il permet de manipuler au travers d’un modèle d’interaction client-serveur les ressources des objets communicants et capteurs identifiées par des URI en s'appuyant sur l'échange de requêtes-réponses et méthodes similaires au protocole HTTP.
En 2016, l'utilisation des services web est courante sur les applications Internet. CoAP étend ce paradigme à l’Internet des objets et aux applications M2M qui peuvent ainsi être développées avec des services web RESTful partagés et réutilisables. Tout en prenant en compte les contraintes et besoins de l'Internet des objets tels que le support de l'asynchrone ou du multicast. CoAP est prévu pour devenir un protocole d'application omniprésent dans le futur Internet des objets.
Le protocole CoAP se situe au niveau applicatif de la couche OSI et s’appuie sur UDP pour la communication. Il met en œuvre une méthode d’observation des ressources et fournit des fonctions de découverte des périphériques pour minimiser l’intervention humaine. Implémenté avec différents langages, ce protocole peut être utilisé dans des domaines tels que la santé ou la gestion énergétique. Il offre des performances adaptées aux objets à faibles ressources ainsi que la sécurité pour les données sensibles.
Description CoAP a été créé par le groupe de travail CoRE (Constrained Restful Environment) et s'inscrit dans la continuité des travaux réalisés par l'IETF avec la spécification 6LoWPAN qui permet aux réseaux de capteurs sans fils contraintsEn Anglais, Wireless Sensor Network, « WSN » d’utiliser le protocole « IPv6 ». CoAP permet l’interaction avec ces capteurs au travers de services web RESTful. Ce protocole a été élaboré pour les périphériques contraints alimentés par batterie, équipés de microprocesseurs peu performants et disposant d’une quantité de mémoire RAM et ROM limitée. Il offre simplicité, faible surchargeEn Anglais, low overhead pour environnements réseaux contraints de faible puissance confrontés à des taux de perte important. CoAP permet les communications M2M requises pour l’interaction et l'exploitation des systèmes embarquésEn Anglais, Embedded Devices. Il est défini comme protocole générique pour les réseaux à basse puissance et avec pertesEn Anglais, Low Power and Lossy Network : LLN et s'appuie sur les protocoles et réseaux sous-jacents 6LoWPAN, IEEE802.15.4. CoAP se différencie cependant de son homologue HTTP de par sa complexité réduite avec l'utilisation d'UDP qui lui permet d'avoir un entête de taille réduit, compris entre 10 et facilement interprétable par des périphériques contraints, tout en conservant un mécanisme de retransmission en cas de perte de messages. Spécialement élaboré pour les environnements contraints, il apporte ces principales fonctionnalités : Faible surcharge d'entête et complexité d’interprétation réduite; Transport UDP avec une couche application unicast fiable et le support du multicast; Échange de messages sans état en asynchrone; Possibilité d'utiliser des proxys (facilite l’intégration avec l'existant) et de mettre les informations en cache (périphériques en veille); Découverte et observation des ressources; Représentation des ressources URI et support de différents types de contenus.
Architecture vignette|404x404px|Figure 1: Un client interrogeant un capteur pour obtenir la température ambiante.CoAP s'appuie sur un modèle client-serveur semblable à HTTP, où les clients envoient des requêtes sur des ressources REST pour récupérer de l'information d'un capteur ou contrôler un périphérique et son environnement. Cependant CoAP traite les échanges de manière asynchrone au travers de datagrammes UDP. HTTP est un protocole éprouvé, cependant son implémentation requiert un code de taille conséquente pour des périphériques ne disposant que de de mémoire ROM et un usage important des ressources réseau.
Une requête CoAP est similaire à une requête HTTP. Elle est envoyée par le client pour demander une action GET, POST, PUT ou DELETE sur une ressource identifiée par une URI. Le serveur répond par un code réponse accompagné éventuellement de la représentation de la ressource.
cadre|Figure 2 : Architecture CoAPL'architecture CoAP est divisée en deux couches. Une couche message qui apporte fiabilité et le séquencement des échanges de bout en bout qui repose sur UDP. Une couche « Request/Response » qui utilise des méthodes et codes réponses pour les interactions requêtes/réponses. Il s'agit cependant bien d'un seul et même protocole qui propose ces fonctionnalités dans son entête.
Couche Message vignette|Figure 3 : Transaction CoAP|gaucheLa couche Message apporte la fiabilité pour les messages typés Confirmables. Elle assure alors un contrôle de bout en bout et leur retransmission en cas de perte. L'utilisation d'un jetonEn Anglais, Token permet à CoAP de faire l'association entre les requêtes et réponses au cours d'une communication. Tandis qu'un « Label » généré et inséré par le client dans chaque entête de message CoAP permet de détecter les doublons. Lorsque les messages ne requièrent pas de garantie de bon acheminement, il est aussi possible tout en bénéficiant de la détection des doublons d'utiliser des messages de types Non-Confirmables. Un serveur qui reçoit un message Confirmable doit acquitter sa réception auprès du client qui initie la connexion et répondre par un message d’acquittement typé ACK. Dans le cas où le serveur peut donner la réponse immédiatement, celle-ci est ajoutée au message d’acquittement et la transaction prend fin. Sinon, un message d’acquittement vide est retourné au client pour indiquer que la réponse est retardée. Lorsqu'un message Confirmable est envoyé au serveur, le client décompte le temps écoulé et réémet le message périodiquement tant que le message n'a pas été acquitté. Dans le cas où le serveur n'est pas en mesure de traiter la demande, il peut l'indiquer au client en répondant par un message de type RST.
Couche Requête-Réponse CoAP dispose des méthodes suivantes MéthodeAction« GET »Cette méthode récupère la représentation de l'information correspondant à la ressource identifiée par la requête URI.« POST »Cette méthode demande le traitement de la représentation jointe à la ressource identifiée par la requête URI. Normalement cela aboutit à la création d'une nouvelle ressource ou de sa mise à jour.« PUT »Cette méthode demande que la ressource identifiée par la requête URI soit mise à jour avec la représentation jointe. Le format de la représentation est spécifié par le type de media et le codage contenu dans l'option Content-Format, si fournie.« DELETE »Cette méthode demande que la ressource identifiée par la requete URI soit supprimée. Les réponses sont identifiées par des codes réponses analogues aux codes d'état de succès 2.xx, d'erreur 4.xx ou 5.xx du protocole HTTP qui indiquent le statut de l'opération. Success 2.xx, indique que la requête a été correctement reçue, comprise et acceptée.
Client Error 4.xx indique que le client a rencontré une erreur.
Internal Server Error 5.xx indique que le serveur est dans l'impossibilité de traiter la requête.
Positionnement dans le modèle OSI CoAP s'insère dans un modèle à 5 couches, physique, liaison de données, réseau, transport et application.
Figure 4 : Position de CoAP |415x415px|vignette Niveau 5 CoAP en tant que protocole de transfert Web au même niveau que le protocole HTTP, les couches supérieures sont du périmètre du navigateur Web et des applications M2M. Niveau 4 La couche transport UDP s'interface avec la sous-couche Message de CoAP. Les messages sont placés dans des datagrammes UDP, son utilisation économise la bande passante et apporte le support du multicast. Niveau 3 IPv6, les datagrammes UDP sont placés dans des paquets IPv6. La couche 6LowPAN procède aux adaptations, pour la couche sous-jacente disposant d'une taille de trame limitée à . Elle procède à la compression des entêtes IPv6, réalise la fragmentation et le ré assemblage des paquets IPv6. Mais également chargé de l'adressage, du routage. Niveau 2 et 1 IEEE 802.15.4 est le standard qui précise les spécifications des couches 1 et 2 pour les réseaux personnels sans fil.
Format du Message CoAP
vignette|426x426px|Figure 5 : Entête CoAPLes messages CoAP sont par défaut transportés au travers de datagrammes UDP. Cette communication peut être transmise via DTLS mais aussi par d’autres moyens comme SMS, TCP, ou SCTP. Les messages sont encodés dans un format binaire simple. Un message commence par un entête de longueur fixe de , suivi par un champ « Token » de taille variable comprise entre 0 et qui permet dans les échanges d’associer les requêtes aux réponses. Sa longueur est indiquée par le champ « TKL ». Il apparait ensuite, une séquence d’options au format TLV« TLV », Type Longueur Valeur suivie en option des données qui occupent le reste du datagramme. Dans le cas où ces dernières sont présentes, elles sont séparées de l’entête grâce à un marqueur d’ contenant la valeur « 0xFF ».
L'entête en version 1 contient les informations suivantes
{| class="wikitable" !Champ ! colspan="2" |Description |- |Ver (Version) | colspan="2" |Le champ Ver possède 2 bits, indiquant la version de CoAP utilisée. |- |T (Type) |Le champ Type est utilisé pour préciser le type du message : Confirmable (0) : Le message requiert une réponse qui peut être véhiculée par un message d'acknowlegment ou envoyé de façon asynchrone si la demande ne peut être traitée immédiatement. Dans ce cas un Reset sera retourné. Nota, un message Confirmable peut être aussi bien une requête qu'une réponse qui doit être acquittée; Non-confirmable (1) : Le message ne requiert aucune réponse ou acquittement; Acknowledgment (2) : Le message confirme la réception d'un message Confirmable. Il peut éventuellement contenir la réponse d'un message Confirmable dans le cas où la demande n'aurait pu être traitée de façon synchrone, le message ID sera alors utilisé pour associer la réponse à la demande; Reset'' (3) : Dans le cas où le message n'a pu être traité. |vignette|426x426px|Figure 6 : Message de type Confirmable (0)|néant
vignette|428x428px|Figure 7 : Message de type Acknowlegment (2) contenant la réponse|néant |- |TKL (Token Length) | colspan="2" |est composé de 4 bits, indiquant la longueur du champ Token. |- |Code | colspan="2" |est composé de 8 bits, dont les 3 bits les plus significatifs (c) indiquent la classe et les 5 bits les moins significatifs les détails (dd). Le code au format « c.dd », permet d’indiquer le type de message, « 0 » pour une requête, « 2 » pour une réponse OK, « 4 » pour réponse en erreur client, « 5 » pour une erreur serveur. Dans le cas d’une requête le code indique la méthode de la requête et dans le cas d’une réponse, le code de la réponse. Le code « 0.00 » indique quant à lui un message vide. |- |Message ID | colspan="2" |est composé de 16 bit, utilisés pour détecter la duplication de messages et faire correspondre les messages acknowledgment/reset aux messages de type Confirmable/Non-Confirmable. |- |Token | colspan="2" |est composé de 0 à 8 octets, utilisés pour associer une requête avec une réponse.
Observation vignette|Figure 8 : Observation d'un ressource dans CoAP|400x400px