Networking Protocols for IoT: MQTT, CoAP, and HTTP

Why IoT Needs Special Protocols

When your embedded device connects to the internet, it needs to exchange data with servers, cloud platforms, or other devices. While you could use plain HTTP (like a web browser), IoT devices have constraints that make specialized protocols more suitable:

• Limited bandwidth: Wireless links may be slow (LoRa, NB-IoT)
• Limited power: Every byte transmitted costs battery life
• Unreliable connections: Devices go offline, networks are lossy
• Many devices: A server may handle thousands of simultaneous connections

The three most common IoT application protocols are MQTT, CoAP, and HTTP.

HTTP (HyperText Transfer Protocol)

HTTP is the protocol that powers the web. It follows a simple request-response model: the client sends a request, the server sends a response.

How HTTP Works

Client (ESP32)                          Server
     |                                     |
     |---- GET /api/temperature ---------->|
     |                                     |
     ||
     |     {"sensor": 1, "value": 42}      |
     |<--- 201 Created -------------------|

HTTP for IoT: Pros and Cons

Pros:

• Universal: every cloud platform supports it
• Simple to understand and implement
• REST APIs are well documented
• Works with any WiFi-capable device

Cons:

• Verbose headers add overhead (hundreds of bytes per request)
• Request-response only: server cannot push data to the device
• Each request opens a new connection (or uses keep-alive)
• Not suitable for constrained networks (LoRa, NB-IoT)

Best for: WiFi-connected devices that occasionally send data to REST APIs or cloud services.

MQTT (Message Queuing Telemetry Transport)

MQTT is the most popular IoT protocol. It was designed specifically for constrained devices and unreliable networks. It uses a publish-subscribe pattern with a central broker.

How MQTT Works

                    MQTT Broker
                   (e.g., Mosquitto)
                   /      |      
                  /       |       
    Sensor Node        Server      Mobile App
    (publisher)     (subscriber)   (subscriber)

1. Sensor publishes: topic "home/temperature", payload "23.5"
2. Broker receives the message
3. Broker forwards it to ALL subscribers of "home/temperature"

Devices publish messages to a topic (a string like “home/living-room/temperature”). Other devices subscribe to topics they are interested in. The broker handles routing messages from publishers to subscribers.

MQTT Topics

Topics are hierarchical strings separated by forward slashes:

home/living-room/temperature
home/living-room/humidity
home/kitchen/temperature
factory/machine-1/status
factory/machine-1/vibration

Wildcards allow subscribing to multiple topics:

• home/+/temperature – matches temperature in any room
• home/# – matches everything under home/

MQTT Quality of Service (QoS)

QoS Level	Guarantee	Use Case
QoS 0	At most once (fire and forget)	Non-critical sensor data
QoS 1	At least once (may duplicate)	Important data, duplicates are OK
QoS 2	Exactly once (no loss, no duplicates)	Critical commands (payment, control)

MQTT Features for IoT

Last Will and Testament (LWT): When a device connects, it registers a “last will” message. If the device disconnects unexpectedly, the broker publishes this message automatically. Other devices can detect the offline status.Retained Messages: The broker stores the last message on a topic. When a new subscriber connects, it immediately receives the latest value without waiting for the next publish.Persistent Sessions: If a device goes offline, the broker queues messages. When the device reconnects, it receives the missed messages.

MQTT Code Example (ESP32)

// Using ESP-IDF MQTT client (simplified)
#include "mqtt_client.h"

esp_mqtt_client_handle_t client;

void mqtt_event_handler(void *args, esp_event_base_t base,
                        int32_t event_id, void *event_data) {
    esp_mqtt_event_handle_t event = event_data;

    switch (event->event_id) {
        case MQTT_EVENT_CONNECTED:
            // Subscribe to command topic
            esp_mqtt_client_subscribe(client, "home/device1/command", 1);
            break;

        case MQTT_EVENT_DATA:
            printf("Received on topic %.*s: %.*sn",
                   event->topic_len, event->topic,
                   event->data_len, event->data);
            break;
    }
}

void app_main(void) {
    esp_mqtt_client_config_t config = {
        .broker.address.uri = "mqtt://broker.example.com:1883",
    };

    client = esp_mqtt_client_init(&config);
    esp_mqtt_client_register_event(client, ESP_EVENT_ANY_ID,
                                   mqtt_event_handler, NULL);
    esp_mqtt_client_start(client);

    // Publish sensor data periodically
    while (1) {
        char payload[32];
        sprintf(payload, "%.1f", read_temperature());
        esp_mqtt_client_publish(client, "home/device1/temperature",
                                payload, 0, 1, 1);
        vTaskDelay(pdMS_TO_TICKS(5000));
    }
}

MQTT Characteristics

Feature	Detail
Transport	TCP (port 1883), TLS (port 8883)
Overhead	Minimal (2-byte fixed header)
Pattern	Publish-Subscribe
Bidirectional	Yes (device can publish and subscribe)
Broker Required	Yes (Mosquitto, HiveMQ, AWS IoT Core)

CoAP (Constrained Application Protocol)

CoAP is designed for very constrained devices and networks. It is like a lightweight version of HTTP but uses UDP instead of TCP, making it much lighter.

How CoAP Works

CoAP follows a request-response model similar to HTTP but with much smaller packets:

Client                               Server
  |                                     |
  |---- GET /temperature ------------->|  (4-byte header + options)
  |                                     |
  |<--- 2.05 Content "23.5" ----------|  (tiny response)
  |                                     |

CoAP also supports an observe pattern: a client subscribes to a resource, and the server pushes updates automatically when the value changes (similar to MQTT subscribe but without a broker).

CoAP Characteristics

Feature	Detail
Transport	UDP (port 5683), DTLS for security
Overhead	4-byte fixed header (very minimal)
Pattern	Request-Response + Observe
Broker	Not required (direct device-to-device)
Discovery	Built-in resource discovery

Use CoAP when: Devices are extremely constrained (8-bit MCUs, very limited RAM), networks are lossy (6LoWPAN, NB-IoT), or you need a RESTful interface without the weight of HTTP.

MQTT vs CoAP vs HTTP Comparison

Feature	HTTP	MQTT	CoAP
Transport	TCP	TCP	UDP
Header Size	Large (~700 bytes)	Small (2 bytes)	Tiny (4 bytes)
Pattern	Request-Response	Publish-Subscribe	Request-Response + Observe
Server Push	No (polling only)	Yes (subscribe)	Yes (observe)
Broker Needed	No	Yes	No
Power Efficiency	Low	Medium-High	High
Reliability	TCP guarantees	QoS levels 0/1/2	Confirmable messages
Best For	REST APIs, cloud	IoT messaging, telemetry	Constrained devices

How to Choose

Use HTTP when:

• Your device has WiFi and ample resources (ESP32, Raspberry Pi)
• You are integrating with existing REST APIs
• Data is sent infrequently (once per minute or less)

Use MQTT when:

• You need real-time bidirectional communication
• Multiple devices need to receive the same data
• You want reliable delivery with QoS guarantees
• Cloud platforms like AWS IoT, Azure IoT, or Google Cloud IoT are involved

Use CoAP when:

• Devices are extremely resource-constrained
• Network bandwidth is very limited (6LoWPAN, NB-IoT)
• You want a RESTful model without HTTP overhead
• Direct device-to-device communication without a broker

Summary

HTTP, MQTT, and CoAP each serve different needs in the IoT ecosystem. HTTP is universal but heavy. MQTT is the sweet spot for most IoT projects with its efficient publish-subscribe model and excellent cloud platform support. CoAP is the lightest option for the most constrained devices and networks. Many real-world IoT systems use a combination: MQTT between devices and broker, HTTP between the broker and web dashboards, and CoAP on the most constrained edge nodes.