CoAP & protocoles contraints¶

REST sur UDP pour les microcontrôleurs à quelques kilooctets de RAM : CoAP apporte les verbes HTTP aux objets les plus limités, sans le coût d'une pile TCP.

CoAP — Constrained Application Protocol (RFC 7252)¶

CoAP est un protocole applicatif RESTful sur UDP, standardisé par l'IETF en 2014. Il reprend les concepts HTTP (GET, POST, PUT, DELETE, codes de réponse) mais compresse les échanges à quelques dizaines d'octets. L'overhead d'un header CoAP est de 4 octets fixes, contre ~200 octets pour HTTP/1.1.

Modèle de message¶

CoAP définit quatre types de messages :

Les messages CON garantissent la livraison malgré UDP via un mécanisme d'exponential backoff (délai initial 2 s, facteur 1.5, max 5 tentatives).

Codes de réponse¶

CoAP réutilise la structure HTTP : 2.xx succès, 4.xx erreur client, 5.xx erreur serveur.

2.05 Content    — réponse GET avec données
2.01 Created    — ressource POST créée
4.04 Not Found  — ressource inexistante
4.01 Unauthorized
5.00 Internal Server Error

Observe pattern — notifications push¶

L'extension Observe (RFC 7641) transforme CoAP en protocole push : un client s'abonne à une ressource et reçoit des notifications à chaque modification, sans polling répété.

sequenceDiagram
    participant C as Client CoAP
    participant S as Serveur CoAP\n(capteur)

    C->>S: GET /temperature\n(CON, Observe: 0, Token: 0xA4)
    S->>C: ACK 2.05 Content\n(Observe: 1234, Payload: 22.5°C)
    Note over S: Température change → 23.1°C
    S-->>C: CON 2.05 Content\n(Observe: 1235, Payload: 23.1°C)
    C-->>S: ACK
    Note over S: Température change → 24.0°C
    S-->>C: CON 2.05 Content\n(Observe: 1236, Payload: 24.0°C)
    C-->>S: ACK
    C->>S: GET /temperature\n(CON, Observe: 1 = désabonnement)
    S->>C: ACK 2.05 Content\n(dernier état)

Le client annule l'abonnement en envoyant une requête avec Observe: 1, ou simplement en ne répondant plus aux CON (le serveur arrête après quelques retransmissions sans ACK).

LwM2M — gestion de device standardisée¶

Lightweight M2M (OMA SpecWorks) est un protocole de device management construit sur CoAP. Il standardise les opérations de provisioning, monitoring, mise à jour firmware (FOTA) et configuration distante.

Modèle objet/ressource¶

LwM2M organise les données en objets numérotés, chacun contenant des ressources :

/3/0/0    → Device / Instance 0 / Manufacturer
/3/0/9    → Device / Instance 0 / Battery Level (%)
/5/0/3    → Firmware Update / Package URI
/5/0/5    → Firmware Update / State (0=idle, 1=downloading…)
/3303/0/5700 → Temperature / Instance 0 / Sensor Value

Les objets standards sont définis dans le registre OMNA (0–32767). Les objets propriétaires utilisent la plage 32768+.

Phases du cycle de vie¶

stateDiagram-v2
    [*] --> Bootstrap : Première mise en service
    Bootstrap --> Registration : Credentials reçus
    Registration --> Management : Enregistrement broker LwM2M
    Management --> Management : Read / Write / Execute / Observe
    Management --> DeRegistration : Mise hors service
    Management --> Bootstrap : Reset ou rotation credentials

Opérations principales¶

CBOR — sérialisation binaire compacte¶

Concise Binary Object Representation (RFC 7049 / RFC 8949) est l'alternative binaire à JSON pour les environnements contraints. Conçu par l'IETF pour être décodable sans schéma préalable.

Exemple : {"t": 22.5, "h": 65} en JSON = 18 octets ; en CBOR = 11 octets (−39%).

CBOR est utilisé natif dans LwM2M, COSE (signatures), CDDL (schémas) et les WebAuthn credentials.

DTLS — sécurité sur UDP¶

CoAP sur UDP nécessite DTLS (Datagram TLS, RFC 6347) pour la confidentialité et l'authentification. DTLS est TLS adapté à UDP : gestion des pertes de datagrammes, retransmission des handshakes, pas d'ordre garanti.

Modes de sécurité LwM2M¶

Le handshake DTLS avec PSK sur un Cortex-M4 @ 120 MHz prend environ 200–400 ms et consomme ~8 Ko de RAM. C'est souvent le facteur limitant sur les MCU les plus contraints.

CoAP vs MQTT — quand choisir quoi ?¶

graph TD
    A{Besoin principal ?} --> B[Lire/écrire\nune ressource]
    A --> C[Diffuser des données\nen continu]
    B --> D{Ressources MCU ?}
    D -->|Très contraintes\n< 32 Ko RAM| E[CoAP + CBOR\nDTLS PSK]
    D -->|MCU standard\n> 64 Ko RAM| F[CoAP ou HTTP REST]
    C --> G{Nombre de\nconsommateurs ?}
    G -->|1 ou peu| H[CoAP Observe]
    G -->|Nombreux, découplés| I[MQTT pub/sub]

Règle de décision rapide¶

• CoAP : microcontrôleur < 64 Ko RAM, réseau UDP ou 6LoWPAN, besoin de device management LwM2M.
• MQTT : MCU standard, nombreux consommateurs découplés, infrastructure broker existante.
• Les deux peuvent coexister : une gateway traduit CoAP (réseau capteurs) → MQTT (backbone cloud).

Ce qu'il faut retenir¶

• CoAP est REST sur UDP avec un overhead minimal de 4 octets — conçu pour les microcontrôleurs les plus contraints.
• Le pattern Observe permet des notifications push sans polling, économisant batterie et bande passante.
• LwM2M standardise le device management (provisioning, FOTA, configuration) au-dessus de CoAP.
• CBOR réduit la taille des payloads de 40 à 60% face à JSON, critique sur les liaisons radio contraintes.
• DTLS apporte la sécurité sur UDP, avec un overhead de handshake à dimensionner selon les ressources MCU.

Chapitre suivant : BLE & courte portée — Bluetooth Low Energy 5.x, mesh, NFC et RFID pour les communications de proximité.