IM Engineer Study Notes
← Back to list
Networking
#CoAP#IoT#UDP#REST#OSCORE
Last updated · 2026-10-24

CoAP (Constrained Application Protocol)

1. Overview

A. Definition

CoAP (Constrained Application Protocol) is a lightweight RESTful application-layer protocol standardized by the IETF CoRE working group (RFC 7252, 2014) for constrained devices and constrained networks (low-power, lossy networks, LLN) whose memory, computation, power, and bandwidth are severely limited. While inheriting HTTP's resource-oriented (REST) model, it operates over UDP rather than TCP and compresses the header to 4 bytes, so that Internet of Things (IoT) endpoints can communicate in a web-like fashion with minimal resources.

The starting point for understanding CoAP is the practical recognition that "HTTP cannot be used in IoT as is." HTTP, which underpins the web, presupposes text headers of tens to hundreds of bytes, a TCP 3-way handshake for connection setup, and the cost of maintaining state. However, constrained devices such as sensors and actuators must survive for years on tens of KB of RAM, hundreds of KB of flash, and a coin-cell battery, and the networks they sit on are wireless (6LoWPAN, Zigbee, NB-IoT, etc.) with a few kbps of bandwidth and high packet-loss rates. In such environments, the heavy connection and header cost of HTTP/TCP translates directly into power consumption and shortened lifespan. CoAP was created precisely to fill this gap, with the design philosophy of "keep the familiarity of REST, but cut the transport cost to the extreme."

As a result, CoAP provides three structural values. First, with a 4-byte fixed header and a UDP base, it minimizes overhead and power consumption. Second, because it is a REST model that uses GET/POST/PUT/DELETE and URIs and media types directly, it has high conceptual compatibility with existing web developers and systems, and IoT resources can be handled with the same mindset as [[rest-api]]. Third, to compensate for the unreliability of UDP, it layers on optional reliability (retransmission, deduplication) and asynchronous observation (Observe) at the message layer by itself, securing a communication quality that is light yet serviceable.

B. Key Characteristics

CoAP's core characteristics are (1) UDP-based lightweight transport (default port 5683, with security via DTLS-based CoAPs 5684), (2) a 4-byte fixed header and binary encoding, (3) a REST resource model (methods, URIs, response codes), (4) four message types CON/NON/ACK/RST with Message ID and Token, and (5) IoT-specific extensions such as Observe (subscribing to resource changes), Block-wise (large-payload split transfer), and resource discovery (/.well-known/core). These characteristics are interlocked: the lightness of UDP enables low power, and the resulting reliability gap is compensated by the message layer and the extension features.

In particular, on the representation (media type) side, CoAP provides a Content-Format option corresponding to HTTP's Content-Type, and favors not only text and JSON but also CBOR (Concise Binary Object Representation), a binary format optimized for constrained environments. Encoding the payload with CBOR instead of verbose JSON greatly reduces the byte count, so the benefit of header lightening extends into the body as well. That is, CoAP's "lightness" does not stop at the header alone but runs consistently through the whole stack—transport layer (UDP), header (4 bytes), body (CBOR), and security (OSCORE/COSE)—as a whole-stack lightweighting philosophy, which demonstrates the completeness of the design.

C. Background and Necessity

Behind CoAP's standardization lay the explosion in the number of IoT endpoints around 2010 and the demand to integrate them naturally into the web ecosystem. Lightweight protocols such as MQTT existed even then, but MQTT is a broker-centric publish/subscribe (pub/sub) model, which differed in character from the web's resource-oriented paradigm of "identifying a resource by a URI and querying or changing its state." The IETF aimed at a "Web of Things" in which billions of sensors are each treated like a single web resource, and for this it needed a protocol that is semantically mappable to HTTP yet runs in a constrained environment.

The second driver is the physical limits of constrained devices. RFC 7228 classifies constrained devices by RAM and code size into Class 0 (≤10KB RAM), Class 1 (~10KB), and Class 2 (~50KB), and Class 1 devices cannot afford to load an entire TLS/HTTP stack. CoAP was designed to be implementable in a few KB of code even on such devices, making secure web communication possible within the power and memory budget. The third is coping with lossy networks. Since packet loss and duplication are common in wireless low-power networks, CoAP implemented minimal reliability directly on top of UDP, without TCP, through Message-ID-based deduplication and exponential-backoff retransmission of CON messages.

These three drivers are mutually reinforcing rather than independent. The demand for web integration led to the REST model, device limits required UDP and binary headers, and lossy networks gave rise to the reliability mechanisms of the message layer. The fact that the three factors simultaneously point to "a protocol that is lightweight yet web-compatible" is what established CoAP as one axis of IoT standards.

A point to note here is that CoAP does not seek to "replace" MQTT but provides a different communication paradigm. If MQTT is a "pipe that streams data," CoAP is closer to a "handle that manipulates resources." CoAP's resource-oriented model is natural when the interaction needs to read a sensor's current value immediately, set an actuator's state to a specific value, and identify that resource by a single URI. This difference is the fundamental reason the two protocols came to coexist later through division of roles rather than competition.

2. CoAP Protocol Structure

CoAP is a single protocol, but the key is to understand it as internally divided into two sublayers. The lower Message Layer is responsible for message reliability and deduplication on top of UDP, while the upper Request/Response Layer is responsible for REST semantics (methods, tokens, response codes). Thanks to this dual structure, reliability (whether to retransmit) and semantics (whether the request succeeded) can be handled separately. The overall structure diagram below shows CoAP's place in the protocol stack and the relationship between the two sublayers.

flowchart TB
  APP["IoT application(sensor·actuator resources)"]
  subgraph COAP["CoAP"]
    RR["Request/Response Layer(REST: methods·tokens·response codes)"]
    MSG["Message Layer(CON·NON·ACK·RST, Message-ID dedup·retransmission)"]
    RR --- MSG
  end
  SEC["DTLS / OSCORE(security option)"]
  UDP["UDP (default 5683 / secure 5684)"]
  NET["IP·6LoWPAN·low-power wireless(LLN)"]
  APP --> RR
  MSG --> SEC
  SEC --> UDP
  UDP --> NET
  style COAP fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
  style SEC fill:#fef3e8,stroke:#ed8f2f,stroke-width:1px

A noteworthy point in this structure is that CoAP was designed to map one-to-one with HTTP. Because its methods (GET, POST, PUT, DELETE) and response codes (2.xx success, 4.xx client error, 5.xx server error) follow the same semantic system as HTTP, placing a CoAP-HTTP proxy at the boundary lets CoAP endpoints inside a constrained network and HTTP services on the Internet interwork transparently through translation. This is a decisive advantage for grafting IoT endpoints onto existing web and cloud infrastructure.

However, this dual-layer separation must not be misunderstood. The message layer's "success (ACK received)" and the request/response layer's "success (2.xx response)" are separate events. An empty ACK for a CON request means only "the message arrived," not "the request was processed," and the actual processing result is conveyed by the following response code (in the case of a separate response). Thanks to this separation, the server can perform long processing asynchronously while immediately signaling "I am alive" to the network, but implementers must take care not to confuse the states of the two layers and mistake "ACK = processing complete." This is one of the mistakes commonly made in CoAP application design.

A. Message Header and Identifiers

A CoAP message begins with a 4-byte fixed header. It consists of Version (2 bits), Type (2 bits), Token Length (4 bits), Code (8 bits, method or response code), and Message ID (16 bits), followed by the Token, Options (URI path, query, content format, etc.), and Payload. Two identifiers play key roles here. The Message ID is used at the message layer to filter out duplicate reception and to match an ACK to a specific message, and the Token is used at the request/response layer to pair which response belongs to which request. If the Message ID is "the tag of the transport unit," the Token is "the tag of the logical conversation"; because the two were separated, even asynchronous responses that arrive late—such as the separate response explained below—are matched correctly.

The Option that follows the header conveys metadata corresponding to HTTP headers, and to save bytes it is encoded by recording only the difference value (delta) of the option number. Uri-Path and Uri-Query express the resource path and query, Content-Format the payload format, ETag the cache validity, Max-Age the caching lifetime, and Observe the subscription. This design of conveying only the necessary metadata, compressed on a number basis, is what makes the decisive overhead difference from HTTP, which repeatedly carries text headers.

B. The Four Message Types

The message layer provides a spectrum of reliability on top of UDP through four types: CON, NON, ACK, and RST. CON (Confirmable) is reliable transport, retransmitted with exponential backoff until the receiver's ACK is received. NON (Non-confirmable) is unreliable transport, used for data where losing one or two is acceptable, such as periodic sensor reports. ACK (Acknowledgement) is the receipt confirmation of a CON, and RST (Reset) is a rejection signal sent when a message cannot be processed (e.g., loss of context due to a reboot). Letting reliability be chosen per transport unit in this way is a design that reflects the economics of constrained environments: "forcing TCP-level reliability on all communication is expensive."

CON retransmission is designed to converge not arbitrarily but on fixed parameters. By default, it sets the first retransmission point by mixing random jitter into the initial timeout (ACK_TIMEOUT, about 2 seconds), then doubles the timeout each time and gives up after attempting only up to the maximum number of retransmissions (MAX_RETRANSMIT, default 4). Setting such a ceiling is to prevent congestion collapse, in which endless retransmission on a highly lossy network would instead paralyze the network and drain power. In addition, when sending requests to many servers simultaneously (e.g., multicast), there is also a rule to spread out the delay (Leisure) so that responses do not pile up all at once, gently controlling congestion in the constrained network even without TCP. In this way, CoAP is characterized by reproducing the complex congestion control of the transport layer with "minimal rules" at the application-protocol level.

3. Request/Response Model and IoT-Specific Features

CoAP's request/response proceeds in two ways under reliable transport (CON). If the server can process the request immediately, it sends the response piggybacked on the ACK—the piggybacked response; if processing takes time, it first confirms only receipt with an empty ACK and later sends the result in a separate CON—the separate response. The sequence diagram below shows the two ways and token matching. The key is that even on top of the statelessness of UDP, both reliability and asynchrony are achieved through the division of labor between Message ID and Token.

sequenceDiagram
  participant C as Client
  participant S as Server(sensor)
  Note over C,S: Piggybacked response(immediate processing)
  C->>S: CON [MID=1, Token=A] GET /temperature
  S-->>C: ACK [MID=1, Token=A] 2.05 Content "21.5"
  Note over C,S: Separate response(delayed processing)
  C->>S: CON [MID=2, Token=B] GET /slow-sensor
  S-->>C: ACK [MID=2] (empty confirmation)
  S->>C: CON [MID=9, Token=B] 2.05 Content "data"
  C-->>S: ACK [MID=9]

A. Observe — Subscribing to Resource Changes

In HTTP's request/response, learning state requires the client to poll repeatedly, and polling is a waste of power on constrained devices. CoAP solves this with the Observe option (RFC 7641). When a client attaches the Observe option to a GET request, the server "registers an observation" of that resource and actively pushes a notification each time the resource value changes. This implements an effect close to publish/subscribe end-to-end without a broker, enabling event-based communication at low power, such as a temperature sensor reporting only when it crosses a threshold. Each notification carries a sequence number to detect reordering, and the server can cancel the observation registration according to its memory limits.

The reason Observe is more power-efficient than polling is quantitatively clear. Polling every minute incurs a request/response round trip every minute even when the value has not changed, requiring the device to wake up, whereas Observe generates traffic only when there is an actual change, so in a steady-state sensor network the communication volume and the number of wake-ups drop by tens of times. However, because the server must keep the registration state in memory, an excessive number of observers can exhaust the constrained device's resources, and if a notification is lost due to network disconnection, there is a risk that the client trusts a stale value. Therefore notifications are usually sent periodically as CON to double as a liveness check, and the design has the client re-query once Max-Age has passed. In this way, Observe is a feature that must consider both "the efficiency of push" and "the reliability of state synchronization."

B. Block-wise Transfer — Large-Payload Split Transfer

UDP datagrams are limited in size, and the MTU of constrained networks is also small (6LoWPAN is tens to hundreds of bytes), making it hard to send a firmware image or large sensor data at once. Block-wise transfer (RFC 7959) splits one large representation into multiple blocks and transmits them sequentially, negotiating the block number, size, and whether more blocks follow via the Block1 (request body) and Block2 (response body) options. Through this, large transfers are performed reliably at the application-layer level without IP fragmentation, and because only the lost block needs to be retransmitted on loss, it is efficient. A firmware OTA update is a representative use case. For example, dividing a 256KB firmware into 64-byte blocks yields thousands of blocks; if left to IP fragmentation, losing even one fragment requires retransmitting the whole, whereas Block-wise only needs to receive the lost block again, dramatically reducing retransmission cost on lossy wireless networks. Since the block size is negotiated to fit the device's buffer and MTU, the more severely constrained the device, the smaller the block it can choose to avoid memory pressure.

C. Resource Discovery and Caching

CoAP exposes the list of resources the server provides at the /.well-known/core path in the CoRE Link Format (RFC 6690), letting the client automatically discover what resources exist. It also carries a Max-Age option in the response to specify the cacheable period, so a proxy can cache frequently queried sensor values to reduce the number of device wake-ups and the network load. Placing a Resource Directory (RFC 9176) lets the resources of intermittently sleeping devices be registered and searched centrally, making large-scale device management easier.

Importantly, caching and proxies are a survival strategy for constrained devices beyond mere performance optimization. Battery devices spend most of their time asleep and wake up only briefly, so if all clients query the device directly, the device wakes up without respite and its battery drains rapidly. If a proxy returns the response on its behalf during Max-Age, the device can stay asleep for that entire period, greatly extending its lifespan. In this way, CoAP's caching carries, in addition to the HTTP-style optimization of "not processing the same request twice," the design intent from a power perspective of "not waking the constrained device."

4. Comparison: CoAP vs MQTT vs HTTP

It is accurate to see the three protocols as complements with different application domains rather than as competitors. The table below summarizes the differences, but the key lies in "why" those differences arise. The choice of communication model (request/response vs publish/subscribe) and transport layer (UDP vs TCP) gives rise to a chain of differences in reliability, real-time behavior, and scalability.

Category CoAP [[mqtt]] HTTP
Transport layer UDP(+DTLS) TCP(+TLS) TCP(+TLS)
Communication model Request/response(REST) + Observe Publish/subscribe(via broker) Request/response(REST)
Topology End-to-end(P2P), proxy possible Broker-centric(many-to-many) Client–server
Header overhead Very low(4 bytes) Low(2 bytes~) High(text headers)
Reliability Optional(CON/NON) QoS 0·1·2 Guaranteed by TCP
Suitable domain Resource query·control of constrained endpoints Intermittently connected many-to-many telemetry Web·cloud with ample resources

The difference in the transport layer is especially decisive. CoAP's choice of UDP is not mere lightweighting but because TCP's connection orientation is unsuitable for constrained devices. TCP requires state and memory for connection setup and maintenance, incurs head-of-line (HOL) blocking that blocks the entire stream from the front on loss, and requires reestablishing the connection each time an intermittently sleeping device wakes up. UDP, by contrast, is stateless, so a device can wake up at any time, send just one message, and go back to sleep, retransmitting only the lost messages selectively. That is, UDP + lightweight reliability inherently fits "a sensor that occasionally wakes up to exchange one or two messages" better than TCP, which assumes "two always-connected hosts." This is the fundamental reason CoAP took a different path from HTTP while using the same REST model.

The practical implications are clear. CoAP is advantageous for sensor/actuator control where querying and controlling resources by URI and low-latency end-to-end interaction matter, while broker-based MQTT is advantageous for telemetry and monitoring that gather the states of many endpoints centrally and distribute them to multiple consumers. In practice the two protocols are often used together, so a hybrid architecture is common in which field sensors are controlled with CoAP and the collected data is pushed to the cloud via MQTT at the gateway. HTTP is used in the gateway and cloud segments where there are no resource constraints, connected to the constrained network via a CoAP-HTTP proxy. In the end, the three protocols are not "competitors from which one must be chosen" but "components placed per segment," and the correct design combines them in the right places according to whether a given segment requires resource constraint, real-time behavior, fan-out, or security.

That said, CoAP's limitations must also be clearly recognized. First, being UDP-based, it is tricky to traverse NAT and firewalls. Many enterprise networks block UDP 5683 or let NAT mappings expire early, so there are large constraints on communication that crosses the public Internet. Second, it is weak at large-scale fan-out. Being a broker-less end-to-end model, pub/sub MQTT is more suitable for distributing one piece of data to a great many consumers simultaneously. Third, its ecosystem and tooling maturity is relatively shallow compared with HTTP and MQTT, so there is an entry barrier in terms of libraries and operational experience. Therefore CoAP should be positioned not as "a cure-all for all IoT" but as "a specialized tool optimized for resource-oriented communication of constrained endpoints."

5. Deep Dive — Security and Recent Trends

CoAP has evolved its own solutions to the hard problem of how to achieve security in constrained environments, beyond being a mere lightweight protocol. CoAP's security historically took DTLS (Datagram TLS) as its base. CoAPs (port 5684) is configured with DTLS, which provides confidentiality, integrity, and authentication on par with TLS over UDP, and it supports PSK (pre-shared key), RPK (raw public key), and certificate modes as authentication methods. However, the DTLS handshake is still heavy on constrained devices, and in particular there was a structural problem whereby passing through a CoAP-HTTP proxy breaks DTLS at the proxy and destroys end-to-end confidentiality. Because the proxy must see plaintext to translate the request, transport security alone cannot protect "the message itself" end-to-end.

What emerged to solve this problem is OSCORE (Object Security for Constrained RESTful Environments, RFC 8613). Because OSCORE encrypts and authenticates the CoAP message (object) itself with CBOR and COSE rather than the transport layer, an intermediate proxy sees only the outer options it needs for routing, while the sensitive payload and method are delivered to the endpoint still encrypted. That is, if DTLS "protects the path (hop-by-hop)," OSCORE "protects the content (end-to-end)," providing end-to-end security in multi-proxy and cache environments. For key establishment, it combines EDHOC (RFC 9528), a lightweight authenticated key exchange protocol, to establish session keys efficiently even on constrained devices. This aligns with the mindset of [[zero-trust]] in that it takes the data itself, not the transport path, as the unit of trust.

DTLS and OSCORE are not an exclusive choice but are used in parallel and complementarily depending on the situation. For a one-hop direct connection, DTLS alone suffices, while for multiple hops where a proxy or cache intervenes, double defense is also possible in which OSCORE protects the payload end-to-end while DTLS additionally protects the hop segments. The key is the judgment of the trust boundary—"can the path be trusted, or must the data itself be protected"—which aligns with the trend of modern security architectures that do not trust intermediate nodes.

Three recent trends stand out. First, transport diversification. RFC 8323 made it possible to run CoAP over TCP, TLS, and WebSocket as well, opening a way to communicate while maintaining CoAP semantics even in enterprise-network and cloud segments where UDP is blocked. Second, integration with standards-based IoT platforms. As OMA LwM2M, a lightweight device-management standard, adopted CoAP as its transport, cases of performing firmware management, remote control, and monitoring in a standardized way over CoAP are spreading across industry. Third, edge and gateway integration. The configuration in which an [[edge-computing]] gateway accommodates CoAP endpoints and relays upward via HTTP/MQTT is becoming common, and CoAP is solidifying its role as "the resource-oriented protocol of the field edge."

From an industrial-application standpoint, CoAP is used in smart building and lighting control, smart metering, industrial sensor networks, agricultural wireless sensor networks, and more. For example, one controls thousands of low-power lighting nodes individually by URI while subscribing to state changes via Observe to monitor energy consumption without polling. Numerically, compared with sending the same message over HTTP, CoAP has header and connection overhead several times smaller, producing a clear advantage in battery life and bandwidth (the actual effect varies with payload size, transmission frequency, and wireless method, so measurement before application is needed).

A representative standards-ecosystem case is OMA LwM2M (Lightweight M2M). When a carrier or IoT platform remotely manages millions of endpoints, LwM2M uses CoAP as its transport to define device registration, firmware update, remote configuration, and connection-status reporting as a standard resource model. Thanks to this, endpoints from different manufacturers are managed through the same CoAP/LwM2M interface, allowing a large endpoint fleet to be operated without vendor lock-in. In smart metering too, a configuration that layers CoAP/LwM2M over cellular IoT (NB-IoT) to collect metering data at low power is widely adopted, which shows that CoAP is being deployed in commercial large-scale operations beyond being a research protocol.

6. Considerations and Implications

Adopting CoAP is not a simple choice of "using a lightweight protocol" but an architectural decision spanning the communication model, security, network environment, and operational system. In particular, since many IoT devices have a lifespan exceeding 10 years, a once-chosen protocol and security method become fixed for a long time, so the ripple effect of the initial design is large. The considerations to judge strategically from a professional-engineer standpoint are as follows.

  • Judging communication-model suitability (CoAP vs MQTT): One should choose on the basis of "does it query and control resources by URI (request/response)" versus "does it gather the data of many endpoints centrally and distribute it (publish/subscribe)." Rather than an either/or, a hybrid design that divides field control to CoAP and upstream collection to MQTT is common, and placing a protocol-conversion gateway at the boundary is realistic.

  • Coping with UDP, NAT, and firewall constraints: CoAP's UDP base is a strength inside the constrained network but becomes a weakness—NAT mapping expiry and firewall blocking—when crossing the public Internet. If the public network must be traversed, one should jointly design RFC 8323's CoAP-over-TCP/WebSocket, gateway relaying, or tunneling, and establish a NAT keep-alive strategy.

  • Security level and end-to-end protection design: For simple one-hop communication DTLS suffices, but for multiple hops passing through proxies and caches, message-level security OSCORE must secure end-to-end confidentiality and integrity. One should choose the PSK/RPK/certificate mode considering even the constrained device's key management, certificate lifetime, and firmware-renewal burden, and jointly review lightweight key exchange such as EDHOC.

  • Adjusting the reliability-power trade-off: CON gives reliability but uses more power through retransmission, while NON is light but accepts loss. According to the data's importance, period, and tolerable loss rate, one should tune the message type and Observe period per task, designing the balance point between battery life and data completeness.

  • Leveraging interoperability and the standards ecosystem: Combining with higher-level standards such as LwM2M, the CoRE Resource Directory, and the CoRE Link Format—rather than CoAP alone—makes device management, discovery, and operation easier. To avoid vendor lock-in, one should choose standards-compliant implementations and specify CoAP-HTTP mapping rules (RFC 8075, etc.) to secure interworking with existing web and cloud infrastructure.

Looking ahead, IoT communication is likely to converge not on a single-protocol monopoly but on a layered combination of edge (CoAP)–collection (MQTT)–cloud (HTTP). CoAP will, as the core axis responsible for resource-oriented communication of constrained endpoints in that layer, develop in the direction of strengthening security and interoperability through OSCORE/EDHOC-based lightweight end-to-end security and transport diversification. For a professional engineer, the core competency becomes not "which is the better protocol" but the ability to design "what is the right combination for this task, network environment, and security requirement."

References

In one line: CoAP is a lightweight RESTful IoT protocol running over UDP with a 4-byte header; it provides optional reliability through CON/NON messages and tokens, supports constrained environments with Observe, Block-wise, and resource discovery, and integrates constrained endpoints into the web ecosystem through DTLS/OSCORE security and HTTP mapping.