2. Constrained Application Protocol (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 conduisent 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 (utilisant un Method Code) sur une ressource (identifiée par un URI) sur un serveur. Le serveur envoie alors une réponse avec un Response Code; cette réponse peut inclure une représentation de ressource.
Contrairement à HTTP, CoAP traite ces échanges de manière asynchrone sur un transport orienté datagramme tel que UDP. Cela est fait logiquement en utilisant une couche de messages qui supporte une fiabilité optionnelle (avec un back-off exponentiel). CoAP définit quatre types de messages: Confirmable, Non-confirmable, Acknowledgement, Reset. Les Method Codes et Response Codes 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 qu'embarquées dans des messages Acknowledgement.
On pourrait penser à CoAP logiquement 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 les Method et Response Codes (voir Figure 1). CoAP est cependant un protocole unique, avec la messagerie et la requête/réponse comme simples fonctionnalités de l'en-tête CoAP.
+----------------------+
| Application |
+----------------------+
+----------------------+ \
| Requests/Responses | |
|----------------------| | CoAP
| Messages | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+
Figure 1: Couches abstraites de CoAP
2.1. Messaging Model (Modèle de messagerie)
Le modèle de messagerie CoAP est basé sur l'échange de messages sur UDP entre points de terminaison.
CoAP utilise un en-tête binaire court 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 Message ID utilisé pour détecter les doublons et pour la fiabilité optionnelle. (Le Message ID 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 par défaut et un back-off exponentiel entre les retransmissions, jusqu'à ce que le destinataire envoie un message Acknowledgement (ACK) avec le même Message ID (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, même pas capable de fournir une réponse d'erreur appropriée), il répond avec un message Reset (RST) au lieu d'un Acknowledgement (ACK).
Client Server
| |
| CON [0x7d34] |
+----------------->|
| |
| ACK [0x7d34] |
|<-----------------+
| |
Figure 2: Transmission de message fiable
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 sont pas accusés de réception, mais ont toujours un Message ID pour la détection de 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 avec un message Reset (RST).
Client Server
| |
| NON [0x01a0] |
+----------------->|
| |
Figure 3: Transmission de message non fiable
Voir Section 4 pour les détails des messages CoAP.
Comme CoAP fonctionne sur UDP, il supporte également l'utilisation d'adresses IP de destination multicast, permettant des 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. Request/Response Model (Modèle requête/réponse)
La sémantique des requêtes et réponses CoAP est transportée dans des messages CoAP, qui incluent soit un Method Code soit un Response Code, 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 en tant qu'options CoAP. Un Token est utilisé pour faire correspondre les réponses aux requêtes indépendamment des messages sous-jacents (Section 5.3). (Notez que le Token est un concept séparé du Message ID.)
Une requête est transportée dans un message Confirmable (CON) ou Non-confirmable (NON), et, si immédiatement disponible, la réponse à une requête transportée dans un message Confirmable est transportée dans le message Acknowledgement (ACK) résultant. C'est ce qu'on appelle une réponse embarquée, 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 embarquée, car le client retransmettra la requête si le message Acknowledgement transportant la réponse embarquée est perdu.) Deux exemples d'une requête GET de base avec réponse embarquée sont montrés dans la Figure 4, l'un réussi, l'autre résultant en une réponse 4.04 (Not Found).
Client Server Client Server
| | | |
| 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 embarquées
Si le serveur n'est pas capable de répondre immédiatement à une requête transportée dans un message Confirmable, il répond simplement avec un message Acknowledgement 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 accusé de réception 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 Server
| |
| CON [0x7a10] |
| GET /temperature |
| (Token 0x73) |
+----------------->|
| |
| ACK [0x7a10] |
|<-----------------+
| |
... Le 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 Server
| |
| 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-confirmable
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 effectivement 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 n'ont 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 produire plusieurs réponses, par exemple, pour une requête multicast (Section 8) ou avec l'option Observe [OBSERVE].
Le support d'URI dans un serveur est simplifié car le client analyse déjà l'URI et le divise en composants hôte, port, chemin et requête, utilisant des valeurs par défaut pour l'efficacité. Les Response Codes se rapportent à un petit sous-ensemble de codes de statut HTTP avec quelques codes spécifiques à CoAP ajoutés, comme défini dans la Section 5.9.
2.3. Intermediaries and Caching (Intermédiaires et mise en cache)
Le protocole supporte la mise en cache des réponses afin de satisfaire efficacement les requêtes. Une mise en cache simple est activée en utilisant des informations de fraîcheur et de validité transportées avec les réponses CoAP. Un cache pourrait ê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.
Le proxying 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 de dispositifs en veille et pour des raisons de sécurité. Le proxying de requêtes au nom d'un autre point de terminaison CoAP est supporté 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 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 une fonctionnalité similaire à celle 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 REST HTTP en utilisant CoAP ou pour convertir entre HTTP et CoAP. Cette conversion peut être effectuée par un proxy inter-protocoles ("cross-proxy"), qui convertit le Method ou Response Code, le type de média et les options vers la fonctionnalité HTTP correspondante et vice versa. La Section 10 fournit plus de détails sur le mappage HTTP.
2.4. Resource Discovery (Découverte de ressources)
La découverte de ressources est importante pour les interactions machine-à-machine et est supportée en utilisant le CoRE Link Format [RFC6690] qui est discuté dans la Section 7.