CoAP and other constrained protocols compared with HTTP

The problem CoAP solves

HTTP is the language of the web, and it would be convenient if every sensor spoke it. The difficulty is cost. HTTP/1.1 sends long text headers, needs a TCP connection (and a TLS handshake for HTTPS) before any data moves, and expects the client to ask whenever it wants news. On a battery device with a few kilobytes of memory and a radio link that carries around a hundred bytes per frame, that overhead hurts.

The Constrained Application Protocol (CoAP), defined in RFC 7252, keeps the REST (representational state transfer) model you know from web APIs: resources identified by URIs, methods such as GET and PUT, and response codes. It then makes everything smaller. Messages travel over UDP, the fixed header is just 4 bytes, and options are encoded in binary. Response codes look familiar but are written as 2.05 Content or 4.04 Not Found.

How CoAP works

Because UDP does not guarantee delivery, CoAP adds a light reliability layer with four message types:

• CON (confirmable): must be acknowledged; the sender retries with increasing back-off if no ACK arrives.
• NON (non-confirmable): sent once with no acknowledgement, good for frequent readings.
• ACK: acknowledges a CON message and can carry the response directly (a "piggybacked" response).
• RST (reset): tells the sender the message could not be processed.

Several extensions make CoAP practical. Observe (RFC 7641) lets a client register interest in a resource, after which the server sends a notification whenever it changes, giving push behaviour without polling. Block-wise transfer (RFC 7959) splits large payloads such as firmware images into numbered blocks. Resource discovery lets a client GET /.well-known/core to list what a device offers. CoAP also supports multicast requests, for example "all lights in this group, switch off", which HTTP cannot do.

You can experiment with the coap-client tool from the libcoap project against a device or simulator in your own lab:

coap-client -m get coap://[fd00:10::21]/.well-known/core
coap-client -m get -s 60 coap://[fd00:10::21]/sensors/temp
coap-client -m put -e '1' coap://[fd00:10::21]/actuators/led

The -s option subscribes using Observe for the given number of seconds.

Securing CoAP

CoAP has two main protection options. Datagram TLS (DTLS) gives TLS-style encryption and authentication for UDP and uses the coaps:// scheme on port 5684. Devices may authenticate with pre-shared keys, raw public keys or certificates. DTLS protects the hop between two endpoints, so a proxy or gateway in the middle sees plain data.

OSCORE (Object Security for Constrained RESTful Environments, RFC 8613) protects the CoAP message itself, end to end, even through proxies, and adds little overhead. It suits multi-hop deployments. Whichever you choose, the usual rules apply: never leave devices reachable without authentication, and limit UDP 5683/5684 at your firewall. Unprotected CoAP servers on the internet have been abused for reflection and amplification attacks, because a small spoofed request can trigger a larger reply to a victim.

Choosing a protocol

In practice many systems mix protocols: CoAP inside a low-power mesh, a gateway that translates to MQTT or HTTPS, and HTTP APIs in the cloud. When comparing, ask how constrained the device is, whether data flows one-to-many, whether devices must be reachable for commands, and what your platform already supports.

Tip: a classic exam question asks why CoAP uses UDP. The answer: no connection set-up, smaller packets, multicast support and better behaviour on lossy links, with reliability added only where you need it through CON messages.