IoT Protocols Compared — MQTT vs CoAP vs HTTP vs AMQP vs LwM2M
Choosing the right IoT protocol determines your device’s battery life, bandwidth usage, latency, and security posture. This guide compares MQTT, CoAP, HTTP, AMQP, and LwM2M across the dimensions that matter most in production.
In this tutorial, you’ll learn the strengths and trade-offs of each protocol so you can pick the right one for sensors, actuators, gateways, and cloud backends. Getting this wrong means rebuilding your device firmware from scratch.
A smart-city project with 10,000 parking sensors needs a protocol that sips battery, handles intermittent connectivity, and delivers messages reliably — MQTT fits. A medical device streaming real-time vitals needs low latency with security — CoAP over DTLS. An industrial PLC logging telemetry every millisecond needs AMQP’s enterprise queuing.
Protocol Comparison Table
| Feature | MQTT | CoAP | HTTP/2 | AMQP | LwM2M |
|---|---|---|---|---|---|
| Transport | TCP | UDP | TCP | TCP | UDP + DTLS |
| Header size | 2–14 bytes | 4 bytes | 8–80 bytes | 8–30 bytes | 4–12 bytes |
| Power consumption | Low | Very low | High | Medium | Very low |
| QoS levels | 0, 1, 2 | 0, 1 | N/A (stream) | Settlements | N/A |
| Security | TLS / mTLS | DTLS | TLS | TLS / SASL | DTLS / OSCORE |
| Pub/Sub | Native | Optional | No | Native | No (Observe) |
| Request/Response | Via topics | Native (GET/PUT/POST/DELETE) | Native | Via queues | Native |
| Payload format | Binary | Binary + CBOR | Text (JSON/XML) | AMQP type system | TLV, JSON, CBOR |
| Max message size | 256 MB | 64 KB | Unlimited | 4 GB | 64 KB |
| Ideal device class | ESP32, gateway | 8-bit MCU, sensor | Server, gateway | Server, PLC | Constrained sensor |
Protocol Architecture Comparison
graph TD
subgraph "Constrained Devices"
S1[Sensor 8-bit] -->|CoAP / LwM2M| GW[Gateway]
S2[Sensor 32-bit] -->|MQTT| GW
end
subgraph "Gateway"
GW -->|Protocol Bridge| AGW[Edge Gateway]
AGW -->|AMQP| Cloud[Cloud]
end
subgraph "Cloud"
Cloud -->|HTTP/2| Dashboard[Dashboard]
Cloud -->|MQTT| App[Mobile App]
end
style S1 fill:#e74c3c,color:#fff
style S2 fill:#e67e22,color:#fff
style GW fill:#27ae60,color:#fff
style Cloud fill:#3498db,color:#fff
MQTT — Publish/Subscribe for IoT Backbone
MQTT uses a broker to decouple publishers and subscribers. Devices connect to the broker and publish to topics; subscribers receive messages by subscribing to those topics. The broker handles routing, buffering, and delivery.
Quality of Service Levels
| QoS | Delivery guarantee | Overhead |
|---|---|---|
| 0 (At most once) | Fire-and-forget, may lose messages | Minimal — no ACK |
| 1 (At least once) | Guaranteed, may duplicate | PUBACK required |
| 2 (Exactly once) | Guaranteed, no duplicates | Four-way handshake (PUB→PUBREC→PUBREL→PUBCOMP) |
# MQTT QoS 2 publisher with Paho
import paho.mqtt.client as mqtt
def on_publish(client, userdata, mid):
print(f"Message {mid} delivered")
client = mqtt.Client(client_id="sensor-001", protocol=mqtt.MQTTv311)
client.on_publish = on_publish
client.connect("broker.example.com", 1883)
client.publish("factory/machine-1/temp", payload=85.3, qos=2)
client.loop_forever()MQTT’s last-will-and-testament feature lets devices notify others when they disconnect unexpectedly — critical for safety systems.
CoAP — REST for Constrained Nodes
CoAP implements a REST-like request/response model over UDP with built-in discovery and resource observation. It maps directly to HTTP for proxy translation.
# CoAP client with aiocoap
import asyncio
from aiocoap import *
async def main():
protocol = await Context.create_client_context()
request = Message(code=GET, uri="coap://sensor.local/temperature")
response = await protocol.request(request).response
print(f"Temperature: {response.payload.decode()}")
asyncio.run(main())CoAP uses four message types: CON (confirmable), NON (non-confirmable), ACK (acknowledgment), and RST (reset). CON messages require ACK — simple retransmission with exponential backoff replaces TCP’s complexity.
AMQP — Enterprise Message Queuing
AMQP is designed for business messaging with sophisticated routing (direct, topic, fanout, headers exchanges), message acknowledgments, and transactions. It’s heavier than MQTT but offers durable queues, dead-letter exchanges, and complex routing topologies.
# AMQP 1.0 producer with python-qpid-proton
from proton import Message, Messenger
mng = Messenger()
mng.start()
msg = Message(body="{'machine': 'CNC-3', 'vibration': 2.3}")
msg.address = "amqps://iot-cluster:5671/factory/telemetry"
mng.put(msg)
mng.send()
print("AMQP message sent")AMQP’s link recovery and distributed transactions make it suitable for financial IoT and industrial control where message loss is unacceptable.
LwM2M — Device Management + Data
LwM2M (Lightweight Machine-to-Machine) defines both data reporting and device management (firmware update, reboot, diagnostics) in one protocol. It uses an object/resource model where every sensor and actuator is a standardised object.
| LwM2M Object | ID | Resources |
|---|---|---|
| Temperature | 3303 | Sensor Value, Min/Max, Alarm |
| Pressure | 3323 | Sensor Value, Calibration |
| Accelerometer | 3313 | X, Y, Z values, Range |
| Firmware Update | 5 | Package URI, Update State, Result |
Common Mistakes
- Using MQTT QoS 2 for all messages: QoS 2 doubles network traffic with a four-way handshake. Use QoS 0 for telemetry, QoS 1 for commands, QoS 2 only for financial transactions.
- Ignoring CoAP congestion control: CoAP uses UDP — sending too many CON messages without waiting for ACKs floods the network. Implement CoAP’s default congestion control (NSTART=1).
- No TLS on public networks: MQTT on 1883 (plaintext) exposes credentials and payloads. Always use 8883 (TLS) or add a VPN for site-to-site.
- Using HTTP/1.1 for constrained devices: HTTP/1.1’s connection overhead (multiple round-trips for TLS, keep-alive management) drains batteries. Use CoAP or MQTT instead.
- Assuming AMQP is too heavy: AMQP 1.0 has lightweight profiles. For industrial gateways with sufficient RAM, AMQP’s reliability features justify the overhead.
Practice Questions
Which protocol would you choose for a sensor running on a coin-cell battery reporting once per hour? CoAP or LwM2M over UDP with DTLS. The connectionless protocol avoids TCP’s keep-alive overhead, extending battery life to years.
Why does MQTT need a broker while CoAP doesn’t? MQTT uses a publish/subscribe model requiring a central broker to route messages. CoAP is peer-to-peer — devices communicate directly using REST-like requests.
What does MQTT’s last-will-and-testament feature do? It publishes a pre-configured message when a device disconnects unexpectedly, alerting other devices. Used in safety systems and device monitoring.
How does AMQP differ from MQTT in message routing? AMQP uses exchanges with routing keys and bindings for complex routing (direct, topic, fanout). MQTT uses a simpler topic hierarchy with wildcards.
What is the CoAP Observe pattern? A client subscribes to a resource URI. The server pushes updates when the resource changes, eliminating polling. Used for real-time sensor readings.
Challenge
Build a multi-protocol bridge: an MQTT sensor publishes temperature → a gateway translates to CoAP → a CoAP client reads it. Compare latency, message size, and delivery reliability between the two protocols.
FAQ
Cross-References
Built by the developers of DodaTech
Doda Browser, DodaZIP & Durga Antivirus Pro