Technical Brief: MQTT vs HTTP vs CoAP — Choosing the Right IoT Protocol

Overview

Every IoT device that connects to VX-Olympus does so through a protocol. The protocol determines how data gets from the device to the platform: the connection model, the message format, the acknowledgment mechanism, and the overhead each transmission carries.

Three protocols cover the vast majority of IoT deployments: MQTT, HTTP/HTTPS, and CoAP. All three are supported by VX-Olympus. The choice between them is not arbitrary — it has direct consequences for battery life, cellular data consumption, message delivery reliability, and system latency.

This brief covers each protocol’s technical characteristics, the tradeoffs they present, and the decision framework for matching protocol to device class and deployment requirements.

Protocol Fundamentals

MQTT (Message Queuing Telemetry Transport)

MQTT is a publish-subscribe messaging protocol designed for constrained devices and unreliable networks. Originally developed by IBM in the late 1990s for monitoring oil pipelines over satellite links, it has become the dominant protocol for IoT messaging.

Connection model: MQTT uses persistent TCP connections. A device connects to an MQTT broker (VX-Olympus in this context) and maintains that connection continuously. Messages are published to topics — named channels like facility/floor2/equipment/press-14/temperature. The broker routes published messages to any subscribers of that topic.

Header overhead: MQTT’s fixed header is 2 bytes. The total message overhead for a minimal MQTT PUBLISH packet is typically 10–20 bytes, depending on topic length and QoS level. A 100-byte sensor payload requires a packet of approximately 120 bytes.

QoS levels: MQTT defines three Quality of Service levels:

• QoS 0 (At most once): Fire-and-forget. The broker delivers the message once or not at all. No acknowledgment. Lowest overhead.
• QoS 1 (At least once): Acknowledged delivery. The sender retransmits until it receives an acknowledgment. Messages may be delivered more than once.
• QoS 2 (Exactly once): Four-part handshake guarantees exactly-once delivery. Highest reliability, highest overhead.

Keep-alive and reconnection: Persistent connections require a keep-alive mechanism. MQTT defines a PING/PINGRESP exchange at configurable intervals to detect disconnection. On connection loss, the device reconnects and the broker can deliver messages queued during the outage (if a persistent session was configured).

Last Will and Testament (LWT): A device can register a “last will” message with the broker at connect time. If the device disconnects unexpectedly (without a clean disconnect), the broker publishes the LWT message to the specified topic. Reliable mechanism for detecting device offline events.

HTTP/HTTPS (Hypertext Transfer Protocol)

HTTP is the protocol of the web. It operates on a request-response model over TCP — a client sends a request, the server sends a response. HTTPS is HTTP with TLS encryption.

Connection model: HTTP/1.1 supports persistent connections (keep-alive), but in practice, most IoT implementations open a new TCP connection per request, send the data, receive the response, and close the connection. Each connection requires a TCP three-way handshake (3 round trips) plus TLS handshake for HTTPS (2–3 additional round trips). For an IoT device on cellular with 50 ms round-trip latency, connection setup alone adds 250–500 ms before the actual data is transmitted.

Header overhead: HTTP headers are plaintext and verbose. A minimal HTTP POST request includes method, host, content-type, content-length, and connection headers. A typical HTTP POST from an IoT device carries 300–800 bytes of header overhead — compared to the 10–20 bytes of MQTT. For a device sending a 50-byte sensor reading, the HTTP envelope may be 10–20x larger than the payload itself.

No server-to-device push: HTTP is strictly request-response. The server cannot push data to the device. For commands or configuration updates, the device must poll — repeatedly requesting “do you have anything for me?” at some interval. Polling frequency determines the latency of downlink commands.

Simplicity and ubiquity: HTTP’s advantage is that every platform, language, and tool speaks it. There are no broker dependencies. Firewalls and network devices universally support it. Debugging HTTP traffic is straightforward — the data is visible in plaintext.

CoAP (Constrained Application Protocol)

CoAP is a specialized protocol designed for constrained nodes and constrained networks. Developed by the IETF as a “IoT version of HTTP,” it provides a similar request-response model but with radically lower overhead.

Connection model: CoAP uses UDP rather than TCP. UDP has no connection setup, no three-way handshake, no connection state. A CoAP message can be sent with a single UDP packet. This eliminates the connection overhead that burdens HTTP on battery-powered devices.

Header overhead: CoAP’s fixed header is 4 bytes. A complete CoAP message carrying a 50-byte payload is approximately 60–70 bytes total — comparable to MQTT, dramatically less than HTTP.

Reliability over UDP: Because UDP provides no delivery guarantees, CoAP implements its own lightweight acknowledgment mechanism:

• Confirmable (CON) messages: Require acknowledgment. If not acknowledged, the sender retransmits with exponential backoff. Equivalent to MQTT QoS 1.
• Non-confirmable (NON) messages: No acknowledgment required. Fire-and-forget. Lowest overhead.

Observe extension: CoAP’s Observe option allows a server to subscribe to a resource on a device — rather than polling, the server registers as an observer and the device sends updates when the value changes. This provides a publish-subscribe model similar to MQTT, without a persistent connection.

NAT traversal challenges: UDP and NAT (Network Address Translation) interact poorly. A CoAP device behind a NAT router may not receive inbound messages unless the device initiates contact first to open a hole in the NAT table. MQTT’s persistent TCP connection handles NAT naturally; CoAP requires more careful network configuration for bidirectional communication.

Head-to-Head Comparison

Battery and Bandwidth Impact Analysis

The protocol choice has concrete effects on battery life and cellular data consumption. The wrong protocol degrades deployments over months. For a device sending a 50-byte sensor reading every 10 minutes over cellular:

MQTT (QoS 1, persistent connection):

• Connection setup: one-time cost at power-on
• Per-message overhead: approximately 20 bytes
• Per-message transmission: 70 bytes total
• Keep-alive traffic: PING/PINGRESP exchange — 4 bytes each, every 60 seconds
• Daily data: ~10 KB per 10-minute interval device
• Battery consideration: persistent TCP connection requires the cellular modem to stay active. For Class A LoRaWAN devices, MQTT over cellular is incompatible with deep sleep cycles.

HTTP/HTTPS POST:

• Per-message: TCP handshake + TLS handshake + request + response + connection teardown
• Per-message overhead: 400–800 bytes header overhead per message
• Per-message transmission: 700–1,100 bytes for a 50-byte payload
• Daily data: ~100 KB per 10-minute interval device — 10x MQTT
• Battery consideration: TCP/TLS handshake CPU cycles add to energy consumption per message beyond the radio transmission time

CoAP (CON over UDP):

• Per-message: single UDP packet with acknowledgment
• Per-message overhead: approximately 20 bytes
• Per-message transmission: 70 bytes total
• No keep-alive traffic required
• Daily data: ~10 KB per 10-minute interval device
• Battery consideration: no persistent connection — device can transmit and sleep. Best option for deep-sleep devices on cellular.

Decision Framework by Device Class

Always-On Ethernet or Wi-Fi Devices

Recommended: MQTT

Devices with reliable, low-cost network access are ideal MQTT clients. The persistent connection overhead is negligible on a wired or Wi-Fi link. The publish-subscribe model enables real-time delivery to multiple subscribers without polling. LWT provides automatic offline detection. Server-to-device push enables low-latency command delivery.

Use cases: factory floor gateways, HVAC controllers, energy meters, industrial machines with network connectivity.

Battery-Powered Cellular Devices (Periodic Reporting)

Recommended: CoAP or HTTP

Devices that wake on a schedule, transmit, and return to deep sleep cannot maintain a persistent TCP connection. Each wakeup cycle must be brief to preserve battery life.

CoAP’s UDP model is purpose-built for this use case: wake, send UDP packet, optionally wait for CON acknowledgment, sleep. No connection state, no handshake overhead.

HTTP is viable if the device framework has better HTTP library support than CoAP, and if the higher per-message overhead is acceptable given the transmission interval and data plan.

Use cases: remote sensors, agricultural monitoring nodes, environmental monitoring stations, asset trackers with infrequent reporting.

Battery-Powered Devices Requiring Low Latency Commands

Recommended: MQTT with careful keep-alive configuration

If the application requires near-real-time command delivery to a battery-powered device (e.g., a remotely configurable setpoint or a downlink configuration command), MQTT with a short keep-alive is the most reliable approach. The device pays a battery cost to maintain the connection but gains reliable bidirectional communication.

Alternative: CoAP Observe allows a device to register with the server for updates without maintaining a TCP connection. This is the lower-power option if the platform and device both support CoAP Observe well.

LoRaWAN Devices

Not applicable: protocol selection is handled by the LoRaWAN stack

LoRaWAN devices use the LoRaWAN protocol at the radio layer, with payload delivery handled by the network server (IoT SimpleLink). The protocol for data delivery from IoT SimpleLink to VX-Olympus is HTTPS POST — not configurable by the end device. For LoRaWAN deployments, the protocol decision is made at the gateway-to-platform layer, not at the device layer.

Protocol Support in VX-Olympus

VX-Olympus’s ingestion layer accepts device connections on all three protocols:

MQTT broker: VX-Olympus runs a full MQTT broker supporting MQTT 3.1.1 and MQTT 5.0. Topics are organized by device ID. QoS 0 and QoS 1 are supported. QoS 2 is supported for deployments where exactly-once semantics are required. TLS is required for cloud deployments (port 8883). Plain TCP (port 1883) is available for on-premises deployments within controlled networks.

HTTPS POST endpoint: Devices POST to a device-specific endpoint URL using a bearer token for authentication. The payload format is JSON. Response includes a 200 status for successful ingestion or a 4xx/5xx code for errors. Rate limiting applies per device to prevent malfunction-driven flooding.

CoAP endpoint: Available on port 5684 (DTLS). CoAP is recommended for constrained cellular devices where UDP overhead reduction is valuable.

Protocol Selection for Multi-Protocol Deployments

Large IoT deployments frequently include multiple device classes — some always-on, some battery-powered, some LoRaWAN. VX-Olympus’s protocol-agnostic ingestion layer means each device class can use the appropriate protocol. The rule engine and storage layer receive normalized telemetry regardless of the protocol used to deliver it.

Common Protocol Mismatches

Security Considerations

All three protocols require transport-layer security in production deployments:

• MQTT over TLS (MQTTS): Port 8883. Client certificate authentication or username/password authentication. VX-Olympus supports both.
• HTTPS: TLS is inherent in HTTPS. Authentication via bearer token or client certificate.
• CoAP over DTLS: Port 5684. DTLS (Datagram TLS) provides TLS-equivalent security over UDP.

Plain (unencrypted) variants of all three protocols exist but are only appropriate for isolated on-premises networks with controlled access. Cloud-connected deployments must use the TLS variants.

Conclusion

Protocol selection is a technical decision with operational consequences that compound over a deployment’s lifecycle. The right choice depends on device power model, network type, transmission frequency, and whether the application requires server-to-device push.

For most industrial IoT deployments:

• Always-on devices on Ethernet or Wi-Fi: MQTT
• Deep-sleep battery devices on cellular: CoAP or HTTP
• LoRaWAN devices: protocol handled by IoT SimpleLink, not configurable at device level

VX-Olympus supports all three protocols — platform fits the device. Devices don’t have to compromise their power budget or firmware complexity.

Talk to our team about protocol configuration for your VX-Olympus deployment.