Che cos'è CoAP e come funziona?

CoAP, il Constrained Application Protocol, è ciò che si ottiene prendendo le idee del web, risorse identificate da URL e manipolate con GET, PUT, POST e DELETE, e ricostruendole per un dispositivo con pochi kilobyte di RAM e una radio che trasporta solo pacchetti piccoli. È stato standardizzato dall’IETF come RFC 7252 nel giugno 2014, progettato insieme a 6LoWPAN perché i sensori a batteria su radio IEEE 802.15.4 potessero partecipare a pieno titolo a una rete IP.

Dove MQTT è un protocollo di messaggistica costruito attorno a un broker centrale, CoAP è un protocollo richiesta-risposta in cui i dispositivi sono server che espongono risorse e client che le chiamano. I due risolvono problemi in parte sovrapposti con forme diverse, e la scelta tra loro è una delle decisioni ricorrenti nella progettazione IoT. Questa guida spiega come funziona CoAP, cosa lo rende adatto ai dispositivi più piccoli e dove si colloca.

Come funziona REST sui dispositivi piccoli?

Un server CoAP, che potrebbe essere un termostato, espone risorse a percorsi come /temperature o /setpoint. Un client invia una richiesta con un metodo e un percorso e riceve una risposta con un codice e un payload, esattamente come in HTTP:

GET coap://[2001:db8::1]/temperature
-> 2.05 Content   {"t": 21.4}

PUT coap://[2001:db8::1]/setpoint   {"t": 20.0}
-> 2.04 Changed

I metodi sono GET, POST, PUT e DELETE, e un’estensione successiva, la RFC 8132, ha aggiunto FETCH, PATCH e iPATCH. I codici di risposta rispecchiano le classi HTTP (2.xx successo, 4.xx errore del client, 5.xx errore del server) in forma compatta. Il contenuto è descritto da un’opzione content-format numerica invece che da una lunga stringa di media type, e CBOR è la codifica naturale del payload, essendo una forma binaria del modello di dati JSON che costa molti meno byte.

Poiché il modello ricalca HTTP così da vicino, un proxy può tradurre tra i due con perdite minime, ed è questo che permette ai dispositivi a risorse limitate di inserirsi nelle architetture a API REST.

Perché CoAP funziona su UDP?

CoAP funziona su UDP anziché su TCP, anche se la RFC 8323 ha poi aggiunto i binding per TCP, TLS e WebSocket per le reti che bloccano UDP. TCP richiede stato, buffer e un handshake per ogni connessione, un costo alto in memoria e in tempo radio per un dispositivo che si sveglia brevemente per inviare una sola lettura. UDP è senza stato: una richiesta è un datagramma, una risposta è un altro, e un’intestazione CoAP di quattro byte più le opzioni sta comodamente nei piccoli frame che le radio 802.15.4 e LPWAN trasportano.

L’affidabilità, dove serve, è gestita da CoAP stesso. Ogni messaggio è di uno di quattro tipi:

• Confirmable (CON): il mittente si aspetta una conferma e ritrasmette con backoff esponenziale finché non la riceve.
• Non-confirmable (NON): invia e dimentica, per le letture in cui la successiva sostituirà quella persa.
• Acknowledgment (ACK): conferma un messaggio CON e può trasportare la risposta nello stesso pacchetto (risposta piggybacked).
• Reset (RST): segnala che un messaggio non ha potuto essere elaborato.

Una risposta che richiede più tempo della finestra di conferma può essere inviata separatamente, così un server può confermare subito e rispondere quando ha i dati. I message ID abbinano le richieste alle conferme, e i token abbinano le richieste alle risposte: è così che un client gestisce molte richieste in sospeso contemporaneamente.

Come fa Observe a inviare dati senza un broker?

Un modello richiesta-risposta puro costringerebbe un client a interrogare ripetutamente (polling) un sensore, sprecandone l’energia. L’estensione Observe (RFC 7641) risolve il problema. Un client invia una GET con l’opzione Observe e il server lo aggiunge a una lista di osservatori di quella risorsa. Ogni volta che la risorsa cambia, il server invia una notifica a ciascun osservatore usando il token originale. Il client vede un flusso di risposte a una singola richiesta.

Observe dà a CoAP un sapore publish-subscribe, ma con la relazione tenuta direttamente tra il client e il dispositivo anziché attraverso un broker. È più leggero ma meno disaccoppiato: il client deve conoscere l’indirizzo del dispositivo, e il dispositivo deve mantenere stato per ogni osservatore. Per la distribuzione molti-a-molti un protocollo basato su broker resta più semplice.

Come fa il trasferimento a blocchi a spostare payload grandi?

Un singolo datagramma UDP su una radio per dispositivi a risorse limitate trasporta al massimo da poche decine a qualche centinaio di byte. Le immagini firmware e le configurazioni grandi non ci stanno. Il trasferimento a blocchi (RFC 7959) divide un payload in blocchi numerati che vengono richiesti o inviati uno alla volta, ciascuno contenuto in un solo datagramma, e il ricevente può controllare la dimensione dei blocchi. È così che i dispositivi CoAP ricevono gli aggiornamenti OTA.

Come scopre un client le risorse di un dispositivo?

Un server CoAP può descrivere le proprie risorse. Una GET su /.well-known/core restituisce un elenco dei percorsi delle risorse con i loro tipi nel CoRE Link Format (RFC 6690), così uno strumento di commissioning o un gateway può scoprire cosa offre un dispositivo appena entrato nella rete senza un driver specifico per quel prodotto. Le richieste multicast permettono a un client di trovare tutti i dispositivi su un collegamento con una sola interrogazione.

Come proteggono CoAP DTLS e OSCORE?

Poiché CoAP funziona su UDP, non può usare TLS direttamente. Il livello di sicurezza standard è DTLS, una versione di TLS adattata ai datagrammi, con chiavi precondivise, chiavi pubbliche raw o certificati X.509 per l’autenticazione. La variante sicura usa lo schema coaps. L’handshake DTLS è l’operazione più costosa che un dispositivo a risorse limitate compie, quindi la ripresa delle sessioni e le sessioni di lunga durata sono importanti.

DTLS protegge la tratta tra il dispositivo e il suo interlocutore, ma un proxy nel mezzo la termina e vede tutto. Object Security for Constrained RESTful Environments (OSCORE, RFC 8613) cifra il messaggio CoAP stesso, così che resti protetto end-to-end attraverso i proxy, il che si adatta alle installazioni in cui tra dispositivo e applicazione si frappongono un gateway o una rete di terzi.

Dove si colloca CoAP nell’ecosistema IoT?

CoAP è il trasporto di LwM2M, lo standard di gestione dei dispositivi di OMA SpecWorks, che definisce sopra CoAP un insieme standard di risorse per informazioni sul dispositivo, connettività, aggiornamento del firmware e sensori. I moduli IoT cellulari e molti sistemi operativi per dispositivi a risorse limitate implementano LwM2M, quindi scegliere CoAP significa spesso avere la gestione dei dispositivi senza costi aggiuntivi.

CoAP è anche il protocollo applicativo nativo delle reti Thread, dove è usato sia per il commissioning e la gestione di Thread stesso sia dalle applicazioni. Matter ha scelto un proprio modello di interazione invece di CoAP, ma gira sulla stessa base UDP e IPv6.

Come scegliere tra CoAP e MQTT?

Usa CoAP quando il dispositivo è davvero limitato nelle risorse: pochi kilobyte di RAM, una radio a basso consumo, la necessità di dormire per la maggior parte del tempo o una rete che non trasporta bene TCP. Usalo quando l’interazione è per natura richiesta-risposta, quando i dispositivi devono essere raggiunti direttamente da altri dispositivi o gateway, quando conta la scoperta delle risorse o quando sei già nel mondo LwM2M o Thread.

Usa MQTT quando i dispositivi hanno una connessione IP con uno stack adeguato, quando molti consumatori hanno bisogno degli stessi dati, quando vuoi che un broker trattenga i messaggi per i dispositivi offline o quando la piattaforma che usi se lo aspetta. La maggior parte delle piattaforme IoT cloud parla prima di tutto MQTT e CoAP, se lo fa, attraverso un gateway.

I due non si escludono: un’architettura comune ha dispositivi a risorse limitate che parlano CoAP con un gateway locale, il quale ripubblica via MQTT verso il cloud.

Per continuare

• MQTT spiegato descrive in dettaglio l’alternativa basata su broker.
• Thread spiegato copre la rete mesh IPv6 in cui CoAP è nativo.
• Tipi di dispositivi IoT e i vincoli che ne determinano la progettazione spiega perché alcuni dispositivi non possono permettersi TCP.
• Panoramica della connettività IoT copre le radio su cui CoAP di solito funziona.

Argomenti: CoAP, protocolli, UDP, dispositivi a risorse limitate, REST