2. Protocole d'application contraint
Le modèle d'interaction de CoAP est similaire au modèle client/serveur de HTTP. Cependant, les interactions machine à machine aboutissent généralement à une implémentation CoAP agissant à la fois dans les rôles de client et de serveur. Une requête CoAP est équivalente à celle de HTTP et est envoyée par un client pour demander une action (à l'aide d'un code de méthode) sur une ressource (identifiée par un URI) sur un serveur. Le serveur envoie ensuite une réponse avec un code de réponse ; cette réponse peut inclure une représentation de la ressource.
Contrairement à HTTP, CoAP traite ces échanges de manière asynchrone sur un transport orienté datagramme tel que UDP. Cela se fait logiquement en utilisant une couche de messages qui prend en charge une fiabilité optionnelle (avec un recul exponentiel). CoAP définit quatre types de messages : Confirmable (Confirmable), Non-confirmable (Non confirmable), Acknowledgement (Accusé de réception), Reset (Réinitialisation). Les codes de méthode et les codes de réponse inclus dans certains de ces messages leur permettent de transporter des requêtes ou des réponses. Les échanges de base des quatre types de messages sont quelque peu orthogonaux aux interactions requête/réponse ; les requêtes peuvent être transportées dans des messages Confirmable et Non-confirmable, et les réponses peuvent être transportées dans ceux-ci ainsi que superposées dans des messages d'accusé de réception.
On pourrait penser logiquement à CoAP comme utilisant une approche à deux couches, une couche de messagerie CoAP utilisée pour traiter UDP et la nature asynchrone des interactions, et les interactions requête/réponse utilisant des codes de méthode et de réponse (voir Figure 1). CoAP est cependant un protocole unique, la messagerie et la requête/réponse n'étant que des fonctionnalités de l'en-tête CoAP.
+----------------------+
| Application |
+----------------------+
+----------------------+ \
| Requêtes/Réponses | |
|----------------------| | CoAP
| Messages | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+
Figure 1 : Couches abstraites de CoAP
2.1. Modèle de messagerie
Le modèle de messagerie CoAP est basé sur l'échange de messages sur UDP entre des points de terminaison.
CoAP utilise un court en-tête binaire de longueur fixe (4 octets) qui peut être suivi d'options binaires compactes et d'une charge utile. Ce format de message est partagé par les requêtes et les réponses. Le format de message CoAP est spécifié dans la Section 3. Chaque message contient un ID de message utilisé pour détecter les doublons et pour une fiabilité optionnelle. (L'ID de message est compact ; sa taille de 16 bits permet jusqu'à environ 250 messages par seconde d'un point de terminaison à un autre avec les paramètres de protocole par défaut.)
La fiabilité est assurée en marquant un message comme Confirmable (CON). Un message Confirmable est retransmis en utilisant un délai d'attente par défaut et un recul exponentiel entre les retransmissions, jusqu'à ce que le destinataire envoie un message d'accusé de réception (ACK) avec le même ID de message (dans cet exemple, 0x7d34) depuis le point de terminaison correspondant ; voir Figure 2. Lorsqu'un destinataire n'est pas du tout capable de traiter un message Confirmable (c'est-à-dire, pas même capable de fournir une réponse d'erreur appropriée), il répond par un message de réinitialisation (RST) au lieu d'un accusé de réception (ACK).
Client Serveur
| |
| CON [0x7d34] |
+----------------->|
| |
| ACK [0x7d34] |
|<-----------------+
| |
Figure 2 : Transmission fiable de messages
Un message qui ne nécessite pas de transmission fiable (par exemple, chaque mesure unique d'un flux de données de capteur) peut être envoyé comme un message Non-confirmable (NON). Ceux-ci ne font pas l'objet d'un accusé de réception, mais ont toujours un ID de message pour la détection des doublons (dans cet exemple, 0x01a0) ; voir Figure 3. Lorsqu'un destinataire n'est pas capable de traiter un message Non-confirmable, il peut répondre par un message de réinitialisation (RST).
Client Serveur
| |
| NON [0x01a0] |
+----------------->|
| |
Figure 3 : Transmission non fiable de messages
Voir la Section 4 pour les détails des messages CoAP.
Comme CoAP fonctionne sur UDP, il prend également en charge l'utilisation d'adresses de destination IP multicast, permettant les requêtes CoAP multicast. La Section 8 discute de l'utilisation appropriée des messages CoAP avec des adresses multicast et des précautions pour éviter la congestion des réponses.
Plusieurs modes de sécurité sont définis pour CoAP dans la Section 9, allant de l'absence de sécurité à la sécurité basée sur des certificats. Ce document spécifie une liaison à DTLS pour sécuriser le protocole ; l'utilisation d'IPsec avec CoAP est discutée dans [IPsec-CoAP].
2.2. Modèle requête/réponse
La sémantique des requêtes et réponses CoAP est transportée dans les messages CoAP, qui incluent soit un code de méthode, soit un code de réponse, respectivement. Les informations de requête et de réponse optionnelles (ou par défaut), telles que l'URI et le type de média de la charge utile, sont transportées sous forme d'options CoAP. Un jeton (Token) est utilisé pour faire correspondre les réponses aux requêtes indépendamment des messages sous-jacents (Section 5.3). (Notez que le jeton est un concept distinct de l'ID de message.)
Une requête est transportée dans un message Confirmable (CON) ou Non-confirmable (NON), et, si elle est immédiatement disponible, la réponse à une requête transportée dans un message Confirmable est transportée dans le message d'accusé de réception (ACK) résultant. C'est ce qu'on appelle une réponse superposée (piggybacked response), détaillée dans la Section 5.2.1. (Il n'est pas nécessaire d'accuser réception séparément d'une réponse superposée, car le client retransmettra la requête si le message d'accusé de réception transportant la réponse superposée est perdu.) Deux exemples pour une requête GET de base avec réponse superposée sont montrés dans la Figure 4, l'un réussi, l'autre aboutissant à une réponse 4.04 (Non trouvé).
Client Serveur Client Serveur
| | | |
| CON [0xbc90] | | CON [0xbc91] |
| GET /temperature | | GET /temperature |
| (Token 0x71) | | (Token 0x72) |
+----------------->| +----------------->|
| | | |
| ACK [0xbc90] | | ACK [0xbc91] |
| 2.05 Content | | 4.04 Not Found |
| (Token 0x71) | | (Token 0x72) |
| "22.5 C" | | "Not found" |
|<-----------------+ |<-----------------+
| | | |
Figure 4 : Deux requêtes GET avec réponses superposées
Si le serveur n'est pas en mesure de répondre immédiatement à une requête transportée dans un message Confirmable, il répond simplement par un message d'accusé de réception vide afin que le client puisse arrêter de retransmettre la requête. Lorsque la réponse est prête, le serveur l'envoie dans un nouveau message Confirmable (qui doit alors à son tour être acquitté par le client). C'est ce qu'on appelle une "réponse séparée", comme illustré dans la Figure 5 et décrit plus en détail dans la Section 5.2.2.
Client Serveur
| |
| CON [0x7a10] |
| GET /temperature |
| (Token 0x73) |
+----------------->|
| |
| ACK [0x7a10] |
|<-----------------+
| |
... Temps passe ...
| |
| CON [0x23bb] |
| 2.05 Content |
| (Token 0x73) |
| "22.5 C" |
|<-----------------+
| |
| ACK [0x23bb] |
+----------------->|
| |
Figure 5 : Une requête GET avec une réponse séparée
Si une requête est envoyée dans un message Non-confirmable, alors la réponse est envoyée en utilisant un nouveau message Non-confirmable, bien que le serveur puisse à la place envoyer un message Confirmable. Ce type d'échange est illustré dans la Figure 6.
Client Serveur
| |
| NON [0x7a11] |
| GET /temperature |
| (Token 0x74) |
+----------------->|
| |
| NON [0x23bc] |
| 2.05 Content |
| (Token 0x74) |
| "22.5 C" |
|<-----------------+
| |
Figure 6 : Une requête et une réponse transportées dans des
messages non confirmables
CoAP utilise les méthodes GET, PUT, POST et DELETE de manière similaire à HTTP, avec la sémantique spécifiée dans la Section 5.8. (Notez que la sémantique détaillée des méthodes CoAP est "presque, mais pas entièrement différente" [HHGTTG] de celle des méthodes HTTP : l'intuition tirée de l'expérience HTTP s'applique généralement bien, mais il y a suffisamment de différences pour qu'il vaille la peine de lire réellement la présente spécification.)
Des méthodes au-delà des quatre de base peuvent être ajoutées à CoAP dans des spécifications séparées. Les nouvelles méthodes ne doivent pas nécessairement utiliser des requêtes et des réponses par paires. Même pour les méthodes existantes, une seule requête peut donner lieu à plusieurs réponses, par exemple pour une requête multicast (Section 8) ou avec l'option Observe [OBSERVE].
La prise en charge des URI dans un serveur est simplifiée car le client analyse déjà l'URI et le divise en composants hôte, port, chemin et requête, en utilisant des valeurs par défaut pour l'efficacité. Les codes de réponse se rapportent à un petit sous-ensemble de codes d'état HTTP avec quelques codes spécifiques à CoAP ajoutés, tels que définis dans la Section 5.9.
2.3. Intermédiaires et mise en cache
Le protocole prend en charge la mise en cache des réponses afin de satisfaire efficacement les requêtes. Une mise en cache simple est activée à l'aide d'informations de fraîcheur et de validité transportées avec les réponses CoAP. Un cache peut être situé dans un point de terminaison ou un intermédiaire. La fonctionnalité de mise en cache est spécifiée dans la Section 5.6.
L'utilisation de proxys est utile dans les réseaux contraints pour plusieurs raisons, notamment pour limiter le trafic réseau, améliorer les performances, accéder aux ressources des appareils en veille et pour des raisons de sécurité. La transmission de requêtes par proxy au nom d'un autre point de terminaison CoAP est prise en charge dans le protocole. Lors de l'utilisation d'un proxy, l'URI de la ressource à demander est inclus dans la requête, tandis que l'adresse IP de destination est définie sur l'adresse du proxy. Voir la Section 5.7 pour plus d'informations sur la fonctionnalité de proxy.
Comme CoAP a été conçu selon l'architecture REST [REST], et présente donc des fonctionnalités similaires à celles du protocole HTTP, il est assez simple de mapper de CoAP vers HTTP et de HTTP vers CoAP. Un tel mappage peut être utilisé pour réaliser une interface HTTP REST en utilisant CoAP ou pour convertir entre HTTP et CoAP. Cette conversion peut être effectuée par un proxy inter-protocole ("cross-proxy"), qui convertit le code de méthode ou de réponse, le type de média et les options en la fonctionnalité HTTP correspondante. La Section 10 fournit plus de détails sur le mappage HTTP.
2.4. Découverte de ressources
La découverte de ressources est importante pour les interactions machine à machine et est prise en charge à l'aide du format de lien CoRE [RFC6690] comme discuté dans la Section 7.