Chapter Index: Constrained Application Protocol
By the end of this chapter series, you will be able to:
CoAP (Constrained Application Protocol) is a lightweight web protocol designed for tiny IoT devices with limited memory and battery. Think of it as a slimmed-down version of HTTP (the protocol your web browser uses). Where HTTP needs a powerful computer, CoAP can run on a sensor with just a few kilobytes of memory.
The Problem: You want sensors and actuators to expose web-like APIs (REST), but HTTP is too heavy:
What IoT Developers Need:
The Solution: CoAP provides “HTTP for constrained environments” - RESTful semantics compressed into a 4-byte binary header running over UDP. This chapter series teaches you everything from basic concepts to advanced implementations.
This comprehensive chapter series covers CoAP from fundamentals through advanced deployment, organized into focused topics for progressive learning. Select a topic below based on your learning goals, or follow one of the recommended learning paths.
| Chapter | Focus | Difficulty | Time |
|---|---|---|---|
| CoAP Introduction | Why CoAP exists, HTTP comparison, design philosophy | Beginner | 20 min |
| Message Format | 4-byte header, options encoding, response codes, tokens | Intermediate | 25 min |
| Message Types and Reliability | CON, NON, ACK, RST, retransmission, exponential backoff | Intermediate | 20 min |
| Chapter | Focus | Difficulty | Time |
|---|---|---|---|
| Observe Extension | Server push notifications, observer management, efficiency | Intermediate | 20 min |
| Advanced Features | Block-wise transfer, resource discovery, CoAP/TCP, DTLS | Advanced | 30 min |
| Chapter | Focus | Difficulty | Time |
|---|---|---|---|
| API Design Best Practices | RESTful patterns, URI conventions, content formats | Intermediate | 25 min |
| Decision Framework | CoAP vs MQTT vs HTTP decision matrix, real examples | Intermediate | 20 min |
| Chapter | Focus | Difficulty | Time |
|---|---|---|---|
| Features and Labs | Practical implementations, code examples, ESP32 labs | Intermediate | 45 min |
| Comprehensive Review | Complete protocol reference, advanced topics | Advanced | 60 min |
For developers who need to evaluate CoAP or make quick protocol decisions:
For comprehensive understanding and implementation readiness:
For experienced developers needing quick lookups:
Before starting this chapter series, you should be familiar with:
This chapter connects to multiple learning resources across the IoT curriculum:
Video Resources - Visit the Videos Hub for:
Practice Quizzes - Test your understanding at Quizzes Hub:
Simulations - Explore interactive tools at Simulations Hub:
Knowledge Gaps - Common misconceptions addressed at Knowledge Gaps Hub:
CoAP is “HTTP for constrained devices” - it provides familiar RESTful semantics (GET, PUT, POST, DELETE on URIs) but compresses everything into a compact binary format running over UDP. Where HTTP requires hundreds of bytes of headers and a TCP connection, CoAP uses just 4 bytes of fixed header and no connection state. The protocol offers two message types: Confirmable (CON) for reliable delivery with acknowledgments, and Non-confirmable (NON) for fire-and-forget efficiency.
If you remember nothing else: CoAP lets your 8-bit microcontroller with 2KB RAM expose web-style REST APIs, enabling direct integration with cloud services and standard tooling without HTTP’s overhead.
Hey there, future IoT engineer! Let’s learn about CoAP with the Sensor Squad!
Sammy the Temperature Sensor wants to share readings with the cloud, just like websites do. But there’s a problem…
The Problem: Imagine you want to send a postcard (your sensor reading is just 10 words), but the post office (HTTP) makes you fill out a 100-page form every time! That’s way too much work for tiny sensors with small batteries.
The Solution - CoAP to the rescue!
Think of CoAP like a super-efficient text message system:
Two types of CoAP messages:
Real-world example: Your smart thermostat uses CoAP to tell your phone the room temperature. It’s so efficient that the battery can last for years!
Fun fact: The entire CoAP message header is only 4 bytes - that’s shorter than the word “temperature”!
| Feature | Value |
|---|---|
| Full Name | Constrained Application Protocol |
| RFC | RFC 7252 (2014), Extensions: RFC 7641 (Observe), RFC 7959 (Block) |
| Transport | UDP (default port 5683), DTLS (port 5684) |
| Header Size | 4 bytes fixed (vs HTTP’s 200+ bytes) |
| Pattern | Request-Response (REST style) |
| Message Types | CON (reliable), NON (fire-and-forget), ACK, RST |
| Methods | GET, PUT, POST, DELETE (same as HTTP) |
| Content Formats | CBOR, JSON, plain text, application-specific |
| Key Features | Observe (server push), Block transfer (large payloads), Discovery |
| Aspect | CoAP | HTTP | MQTT |
|---|---|---|---|
| Transport | UDP (connectionless) | TCP (connection-oriented) | TCP (persistent) |
| Header Size | 4 bytes fixed | 200-800 bytes text | 2 bytes minimum |
| Pattern | Request-response (REST) | Request-response (REST) | Publish-subscribe |
| Broker Required | No (direct device-to-device) | No | Yes (mandatory) |
| Reliability | Optional (CON/NON) | TCP guarantees | QoS 0/1/2 levels |
| Server Push | Observe extension | Not native | Core feature |
| RAM Required | ~2KB minimum | ~50KB+ typical | ~10KB minimum |
| Best For | Constrained devices, REST APIs | Web integration, browsers | Fan-out, many subscribers |
| Typical Latency | Low (no handshake) | Higher (TCP + TLS setup) | Medium (persistent conn) |
RAM requirements comparison: \[ \begin{align} \text{CoAP stack (minimal)} &= 2{,}048 \text{ bytes} \\ \text{MQTT stack (minimal)} &= 10{,}240 \text{ bytes} \\ \text{HTTP stack (minimal)} &= 51{,}200 \text{ bytes} \\ \text{Ratio} &= \text{CoAP : MQTT : HTTP = 1 : 5 : 25} \end{align} \]
Message size for 20-byte payload: \[ \begin{align} \text{CoAP} &= 4 + 2 + 8 + 20 = 34 \text{ bytes} \\ \text{MQTT} &= 2 + 20 + 20 = 42 \text{ bytes (header + topic + payload)} \\ \text{HTTP} &= 200 + 20 = 220 \text{ bytes (headers + payload)} \end{align} \]
Power consumption per transaction (cellular): \[ \begin{align} \text{CoAP (UDP)} &: 20 \text{ ms} \times 120 \text{ mA} = 2.4 \text{ mAs} = 0.67 \text{ }\mu\text{Ah} \\ \text{MQTT (TCP)} &: 150 \text{ ms} \times 120 \text{ mA} = 18 \text{ mAs} = 5.0 \text{ }\mu\text{Ah} \\ \text{HTTP (TCP+TLS)} &: 400 \text{ ms} \times 120 \text{ mA} = 48 \text{ mAs} = 13.3 \text{ }\mu\text{Ah} \end{align} \]
Battery life (AA 2,500 mAh, 1 msg/min): \[ \begin{align} \text{Messages/day} &= 1{,}440 \\ \text{CoAP daily} &= 1{,}440 \times 0.67 \text{ }\mu\text{Ah} = 0.96 \text{ mAh} \\ \text{Battery life} &= \frac{2{,}500}{0.96} \approx 2{,}604 \text{ days} \approx 7.1 \text{ years} \\ \text{MQTT daily} &= 1{,}440 \times 5.0 \text{ }\mu\text{Ah} = 7.2 \text{ mAh} \rightarrow 347 \text{ days} \\ \text{HTTP daily} &= 1{,}440 \times 13.3 \text{ }\mu\text{Ah} = 19.2 \text{ mAh} \rightarrow 130 \text{ days} \end{align} \]
Conclusion: CoAP’s minimal overhead enables multi-year battery life (7+ years at 1 msg/min). MQTT lasts ~1 year; HTTP only ~4 months. For battery-powered devices, CoAP is clearly optimal.
Calculate the total CoAP message size based on header components. Adjust the token length, number of options, and payload size to see how CoAP keeps messages compact.
Model your deployment scenario and compare battery life across CoAP, MQTT, and HTTP. Adjust device current, transmission time, and message frequency.
CoAP uses exponential backoff for Confirmable (CON) messages. The initial timeout is randomly chosen between ACK_TIMEOUT and ACK_TIMEOUT * ACK_RANDOM_FACTOR, then doubles on each retry up to MAX_RETRANSMIT attempts.
Compare the overhead-to-payload ratio for CoAP, MQTT, and HTTP across different payload sizes. Smaller payloads amplify protocol overhead differences.
When evaluating protocols for your IoT deployment, consider these key decision factors:
| Factor | Choose CoAP | Choose MQTT | Choose HTTP |
|---|---|---|---|
| Communication Pattern | Direct request-response (sensor queries, actuator commands) | Publish-subscribe, one-to-many distribution | Traditional client-server, web integration |
| Device Constraints | <10KB RAM, battery-powered, sleep cycles | >10KB RAM, persistent connectivity | >50KB RAM, mains power |
| Message Frequency | Infrequent (minutes), event-driven | Frequent (seconds), continuous streaming | Sporadic (hours), human-initiated |
| Reliability Needs | Application-controlled (CON/NON choice) | QoS 0/1/2 levels for different data types | TCP guarantees delivery |
| Network Type | Lossy wireless (6LoWPAN, NB-IoT) | Stable (Wi-Fi, cellular) | Reliable (Ethernet, 4G/5G) |
| Broker Infrastructure | None required (direct device-to-device) | Mandatory central broker | Optional (load balancer) |
| Discovery Mechanism | Native multicast + .well-known/core |
Broker-managed topic hierarchy | DNS + service registry |
Real-World Example: Smart Agriculture System
You need to monitor 500 soil sensors and control 50 irrigation valves:
Sensors to Gateway (CoAP):
POST coap://gateway/readings {"moisture": 45}Gateway to Cloud Dashboard (MQTT):
Cloud to Valve Commands (CoAP):
PUT coap://valve23/state {"open": true}POST coap://[FF02::FD]/all-valves {"emergency_close": true}Hybrid Architecture Benefits:
This architecture overview connects all CoAP concepts in the learning journey:
Foundation Layer:
Core CoAP Concepts (Progressive Learning):
Application Layer:
Deployment Context:
CON messages require an ACK roundtrip — on lossy networks with 20% packet loss, a 4-attempt retry with exponential backoff can delay responses by 45 seconds. Use NON for periodic telemetry where data freshness matters more than guaranteed delivery; reserve CON for actuation commands.
CoAP proxies cache GET responses based on Max-Age option — a sensor returning temperature with Max-Age=60 will serve cached values for 60 seconds even if the physical reading changes. Set Max-Age to match your data freshness requirement, not the default 60 seconds.
DTLS handshake (6-8 roundtrips) dominates latency for short-lived CoAP connections — repeatedly creating new DTLS sessions for each request adds 500-2000ms overhead. Use DTLS session resumption (RFC 5077) to reduce reconnection to 1 roundtrip after the initial handshake.
Ready to dive in? Select the chapter that matches your current goal:
| Chapter | Focus | Why Read It |
|---|---|---|
| CoAP Introduction | Design philosophy, HTTP comparison, core concepts | Start here if you are new to CoAP — establishes the “why” before the “how” |
| Message Format | 4-byte header, options encoding, response codes | Essential for implementation — teaches you to read and write CoAP at the byte level |
| Message Types and Reliability | CON, NON, ACK, RST, retransmission, backoff | Critical for production deployments — explains how CoAP achieves reliability over UDP |
| Observe Extension | Server push, observer management, event-driven IoT | Read this to replace polling loops with efficient push notifications |
| Decision Framework | CoAP vs MQTT vs HTTP selection matrix | Use this when your team needs to justify a protocol choice with measurable criteria |
| Features and Labs | Hands-on ESP32 implementation, code examples | Go here when you are ready to write and run real CoAP code |