CoAP Protocol Deep Dive

The HTTP-like REST model

CoAP requests target a URI:

coap://sensor.example.com/temperature
coaps://lock.example.com/state         (over DTLS)

Methods match HTTP semantics:

• GET — read a resource.
• POST — create a sub-resource.
• PUT — update a resource.
• DELETE — remove a resource.

Status codes are similar: 2.05 Content ≈ HTTP 200, 4.04 Not Found ≈ HTTP 404, 5.00 Internal Server Error ≈ HTTP 500. The format differs (X.YY instead of XYY) but the meanings translate directly.

Why UDP

TCP has connection state — both endpoints maintain a control block per connection, retransmission buffers, congestion windows. For a microcontroller with a few KB of RAM serving dozens of clients, TCP state is expensive. UDP has no per-connection state at all; a message goes out, possibly with retransmission at the application layer if reliability is needed.

The tradeoff: CoAP has to handle reliability and ordering itself when needed. The protocol provides this via confirmable messages.

Confirmable vs non-confirmable

Every CoAP message is one of four types:

Confirmable adds reliability with minimal state — the sender remembers the message ID and retransmits if no ACK arrives in a bounded time. Non-confirmable is "fire and forget," appropriate for periodic sensor readings where missing one is acceptable.

Observe: pub-sub for resources

CoAP's Observe extension (RFC 7641) provides a publish-subscribe model on top of REST. The client registers interest in a resource by sending a GET with the Observe option set; the server responds and continues to send notifications whenever the resource changes:

Client → GET /temperature  Observe: 0  (register)
Server → 2.05 Content      Observe: 12  (initial value)
... time passes, temperature changes ...
Server → 2.05 Content      Observe: 13  (notification)
... more changes ...
Server → 2.05 Content      Observe: 14  (notification)
Client → GET /temperature  Observe: 1  (deregister)

The Observe sequence number monotonically increases so the client can detect lost or reordered notifications.

Block-wise transfer

UDP datagrams have practical size limits (MTU is typically ~1500 bytes; for 6LoWPAN much smaller). Larger payloads — firmware images, large sensor readings — need to be split. Block-wise transfer (RFC 7959) provides a standard mechanism:

1. Server's first response includes the first block of the resource and indicates more blocks follow.
2. Client requests the next block.
3. Server sends the next block.
4. Repeat until done.

Block sizes are negotiable: 16, 32, 64, 128, 256, 512, or 1024 bytes. The client picks based on its link MTU.

Security: DTLS and OSCORE

CoAP over plaintext UDP is vulnerable to the usual network attacks. Two security layers:

• DTLS — Datagram TLS. UDP version of TLS, providing the same encryption and authentication. CoAP over DTLS is conventionally written coaps:// and uses port 5684 by default (vs port 5683 for plain CoAP). Most deployments rely on DTLS with PSK (pre-shared key) or ECC certificates.
• OSCORE — Object Security for Constrained RESTful Environments. Encrypts at the message layer rather than transport layer, so CoAP traffic can traverse proxies without losing end-to-end security. Useful when intermediaries (like cloud-to-device proxies) shouldn't see the payload.

Multicast

CoAP supports multicast natively — a request can target a multicast group address, and any device subscribed to that group can respond. This is useful for discovery ("anyone with temperature readings?") and one-to-many control ("all lights off"). MQTT has no multicast equivalent; everything goes through the broker.

Multicast in CoAP is non-confirmable by definition — confirming many recipients individually defeats the purpose.

The /.well-known/core discovery endpoint

Every CoAP server typically exposes /.well-known/core — a resource that lists all the other resources the device offers. Clients can discover capabilities via:

GET /.well-known/core
→ Response lists: </temperature>;rt="sensor",</state>;rt="actuator"

Combined with multicast, this enables automatic device discovery on a network.

When CoAP vs MQTT vs HTTP

Where CoAP is used

• Thread network — uses CoAP for device control.
• OMA Lightweight M2M — IoT device management standard built on CoAP.
• OPC UA over CoAP — industrial IoT.
• Smart home / Matter — Matter uses a derivative of CoAP for operational data over Thread/IPv6.
• Building automation, smart metering — many sectoral standards.

Frequently Asked Questions

What is CoAP?

Constrained Application Protocol — a request/response protocol for IoT devices that looks like HTTP but runs over UDP and is designed for tiny code footprint and tiny packets. CoAP is REST-style — GET, POST, PUT, DELETE on URIs — but optimized for constrained devices and lossy networks where HTTP/TCP is too heavy.

What is the difference between CoAP and HTTP?

CoAP uses UDP instead of TCP, binary headers instead of text, has a much smaller code footprint (a CoAP stack fits in a few KB of flash), and adds IoT-specific features like Observe (publish-subscribe on resources) and block-wise transfer (for payloads larger than one UDP datagram). The REST model (GET, POST, PUT, DELETE on URIs) is preserved, so the mental model maps closely.

What is the Observe option?

A CoAP extension (RFC 7641) that lets a client subscribe to a resource. The server pushes notifications whenever the resource changes, until the client explicitly unsubscribes. It is CoAP's equivalent of MQTT's publish-subscribe — but per-resource instead of per-topic, and tied to specific URIs.

How does CoAP handle security?

DTLS (Datagram TLS) — the UDP equivalent of TLS. CoAP over DTLS provides the same encryption, authentication, and integrity guarantees as HTTPS, with overhead suited to constrained devices. Alternatively, OSCORE (Object Security for CoAP) provides end-to-end security at the message layer rather than the transport layer, useful when CoAP traffic passes through proxies.

When should I use CoAP instead of MQTT?

When you have a request-response interaction pattern (read a sensor value, set an actuator), when you want to address specific resources via URIs, when devices are too constrained to keep an MQTT connection open, or when you need multicast (CoAP supports multicast natively; MQTT does not). MQTT wins for many-to-many pub-sub with persistent connections; CoAP wins for stateless REST-style interactions on extremely constrained devices.