IoT Connectivity Protocols Compared: MQTT, HTTP, CoAP, and More

Choosing the Right IoT Protocol

One of the most important decisions in any IoT project is selecting the communication protocol. The right choice depends on your power constraints, bandwidth availability, latency requirements, and scale.

Protocol Overview

Here's a quick comparison of the most common IoT protocols:

| Protocol | Transport | Best For | Power Usage | |----------|-----------|----------|-------------| | MQTT | TCP | Telemetry, sensors | Low | | HTTP/REST | TCP | Web integration | Medium-High | | CoAP | UDP | Constrained devices | Very Low | | WebSocket | TCP | Real-time bidirectional | Medium | | LoRaWAN | RF | Long-range, low-power | Very Low | | Zigbee | RF | Short-range mesh | Low |

MQTT — The IoT Workhorse

MQTT (Message Queuing Telemetry Transport) is the most widely used IoT protocol, and for good reason:

• Lightweight — Minimal overhead, small packet size
• Publish/Subscribe model — Decouples senders from receivers
• QoS levels — Choose between fire-and-forget (0), at-least-once (1), or exactly-once (2)
• Retained messages — New subscribers get the last known value immediately

# MQTT topic structure example
sensors/building-a/floor-1/temperature
sensors/building-a/floor-1/humidity
devices/router-01/status

MQTT is ideal for sensor data collection, device telemetry, and any scenario where you need reliable message delivery with low bandwidth.

HTTP/REST — When Simplicity Wins

HTTP is familiar and well-supported everywhere. It's a good choice when:

• Your devices have sufficient power and bandwidth
• You need to integrate with existing web APIs
• Request-response patterns match your use case
• You're prototyping and want quick results

The downside is higher overhead per message compared to MQTT.

CoAP — For Constrained Devices

CoAP (Constrained Application Protocol) is designed specifically for resource-limited IoT devices:

• Runs over UDP (lower overhead than TCP)
• RESTful design similar to HTTP
• Built-in discovery mechanism
• Supports multicast

Use CoAP when your devices have very limited memory, processing power, or battery.

LoRaWAN — Long Range, Low Power

For sensors deployed across large areas (farms, cities, industrial sites):

• Range of 2-15 km depending on environment
• Extremely low power consumption
• Low data rate (suitable for periodic sensor readings)
• Requires a LoRa gateway

How I Choose

In my IoT projects, I follow this decision tree:

1. Need long range outdoors? → LoRaWAN
2. Constrained battery device? → CoAP or MQTT with QoS 0
3. Real-time bidirectional? → WebSocket or MQTT
4. Simple web integration? → HTTP/REST
5. General telemetry at scale? → MQTT

Frequently Asked Questions

Which IoT protocol is best for battery-powered sensors?

For battery-powered sensors, MQTT with QoS 0 or CoAP are the best choices for short-range communication, while LoRaWAN is ideal for long-range deployments. MQTT's lightweight publish/subscribe model keeps overhead minimal, and QoS 0 (fire-and-forget) avoids the extra round-trips of acknowledgement. CoAP runs over UDP, which has even lower overhead than MQTT's TCP connection. For sensors spread across large areas (farms, cities, industrial sites), LoRaWAN offers 2-15 km range with extremely low power consumption — sensors can run for years on a single battery.

What is the difference between MQTT and HTTP for IoT?

MQTT uses a publish/subscribe pattern where devices publish to topics and subscribers receive messages automatically, while HTTP uses a request/response pattern where the client must actively poll for updates. MQTT has much lower overhead per message (as little as 2 bytes of header), maintains persistent connections, and supports three QoS levels. HTTP is heavier (large headers per request) but is universally supported and easier to integrate with existing web APIs. Choose MQTT for continuous telemetry at scale; choose HTTP when you need simple web API integration or are prototyping.

Can I use multiple IoT protocols in the same project?

Yes, and it's a common architecture pattern. For example, you might use LoRaWAN for outdoor long-range sensors, Zigbee for indoor mesh sensor networks, and MQTT as the central messaging backbone that connects everything to your cloud platform. An IoT gateway typically bridges different protocols — receiving data from field devices over one protocol and forwarding it over MQTT or HTTP to your server. Platforms like ThingsBoard and Node-RED are designed for exactly this multi-protocol integration.

What is CoAP and when should I use it instead of MQTT?

CoAP (Constrained Application Protocol) is a lightweight RESTful protocol designed specifically for resource-constrained IoT devices with limited RAM, processing power, or battery. It runs over UDP instead of TCP, which means lower overhead and no connection maintenance. Use CoAP over MQTT when your devices are extremely constrained (8-bit microcontrollers with kilobytes of RAM), when you need multicast communication to groups of devices, or when the RESTful request/response pattern matches your use case better than publish/subscribe. MQTT is better for most general IoT telemetry scenarios.

Conclusion

There's no one-size-fits-all protocol for IoT. Understanding the tradeoffs between power, bandwidth, latency, and complexity helps you make the right choice for each specific project.

Want to put these protocols into action? Read our guide on Best Open-Source Tools for SNMP Monitoring & IoT — featuring ThingsBoard, Mosquitto, and more.