When designing an IoT system, one of the earliest and most consequential decisions is which protocol your devices will use to communicate. MQTT and HTTP dominate this space — and both are capable, battle-tested, and widely supported. But they solve different problems, and choosing the wrong one creates real engineering pain down the line.
This guide gives you the technical grounding to make the right choice for your specific deployment context.
Protocol Fundamentals
HTTP: The Web's Native Language
HTTP (Hypertext Transfer Protocol) is the foundation of the web. In IoT contexts, devices typically use HTTP/1.1 or HTTP/2 to make RESTful requests — sending data to an endpoint via POST or retrieving configuration via GET. Each request is independent: the device opens a connection, sends a request, receives a response, and closes the connection.
HTTP is familiar to every developer, supported by virtually every networking library, and trivially debuggable with standard tooling (curl, Postman, browser dev tools). Its ubiquity is its greatest strength.
MQTT: Purpose-Built for Constrained Environments
MQTT (Message Queuing Telemetry Transport) is a publish-subscribe messaging protocol designed specifically for environments where bandwidth is limited, network connections are unreliable, and devices have minimal processing power. It runs over a persistent TCP connection to a central broker. Devices publish messages to topics; subscribers receive them without any direct coupling between publisher and subscriber.
MQTT was originally developed in the late 1990s for satellite-based oil pipeline monitoring — a context that explains its extreme focus on efficiency and resilience. Today it's standardised as OASIS MQTT 3.1.1 and 5.0, with broad support across device firmware ecosystems.
Head-to-Head Comparison
| Property | MQTT | HTTP/REST |
|---|---|---|
| Communication model | Publish-subscribe (broker-mediated) | Request-response (direct) |
| Connection type | Persistent TCP | Stateless (new connection per request) |
| Overhead per message | Very low (2-byte fixed header minimum) | High (headers, status lines, body formatting) |
| Bandwidth efficiency | Excellent | Moderate to poor at high frequency |
| Reliability guarantees | QoS 0, 1 or 2 (at-most-once, at-least-once, exactly-once) | Application-layer only (TCP ensures delivery of the request, not idempotent delivery) |
| Offline message delivery | Yes (persistent sessions + retained messages) | No (client must retry) |
| Bidirectional communication | Native (server publishes to device topics) | Requires polling or long-polling |
| Firewall traversal | Requires open port 1883 or 8883 (TLS) | Port 443 (HTTPS) — universally open |
| Developer familiarity | Specialist knowledge required | Universal |
| Tooling ecosystem | Good (Mosquitto, HiveMQ, EMQX) | Excellent (every web framework, language, cloud platform) |
| Payload flexibility | Any binary or text payload | Typically JSON, also binary, XML |
When to Choose MQTT
MQTT is the right choice when one or more of these conditions apply:
- High-frequency telemetry: Devices reporting every second or faster. HTTP's per-request overhead becomes prohibitive; MQTT's persistent connection eliminates it.
- Constrained devices: Microcontrollers with limited RAM and processing power (ESP8266, STM32, Nordic nRF series). The MQTT client library footprint is an order of magnitude smaller than a full HTTP stack.
- Unreliable networks: 2G/3G cellular, satellite, or industrial wireless networks with intermittent connectivity. MQTT's QoS 1 and QoS 2 guarantees and persistent sessions ensure messages survive disconnections.
- Push-to-device commands: When the platform needs to send commands or configuration updates to devices without polling, MQTT's publish-subscribe model makes this trivially simple.
- Large device fleets: At thousands of devices reporting frequently, the bandwidth savings of MQTT become significant at scale — measurable in infrastructure cost reduction.
When to Choose HTTP
HTTP is the pragmatic choice in these scenarios:
- Low-frequency reporting: Devices sending data every few minutes or hours. The connection overhead of HTTP is negligible relative to the reporting interval.
- Firewall-constrained environments: Corporate networks or strict industrial DMZ configurations where only port 443 (HTTPS) is reliably available.
- Simple device firmware: When using off-the-shelf hardware or platforms (Raspberry Pi, Arduino with WiFi) where HTTP client libraries are already integrated and MQTT would add complexity.
- Integration with web services: When devices need to call third-party APIs directly, or when the back end is a standard web application server without MQTT broker infrastructure.
- Development speed: HTTP endpoints are trivial to test and debug. For rapid prototyping, pilot projects or internal tooling, HTTP's developer experience advantage often justifies its efficiency cost.
MQTT Quality of Service Levels Explained
One of MQTT's most valuable features is its configurable delivery guarantee, expressed as Quality of Service (QoS):
- QoS 0 (At most once): Fire-and-forget. No acknowledgement, no retransmission. Appropriate for high-frequency sensor readings where occasional loss is acceptable — the next reading arrives seconds later.
- QoS 1 (At least once): The broker acknowledges receipt. The publisher retransmits until acknowledged. Messages may be delivered more than once — the consumer must handle duplicates. Use for important events where loss is unacceptable but occasional duplication is tolerable.
- QoS 2 (Exactly once): A four-part handshake guarantees exactly-once delivery. Higher overhead — reserve for high-value transactions like billing events, actuation commands or safety-critical alerts.
MQTT 5.0: What Changed
MQTT 5.0 (published 2019, now the recommended standard) introduced several important additions over the widely deployed 3.1.1:
- Reason codes on all acknowledgements — enabling proper error diagnostics
- User-defined message properties — key-value metadata on any message
- Subscription identifiers — enabling efficient routing in complex broker topologies
- Shared subscriptions — enabling load-balanced consumer groups
- Message expiry intervals — automatic TTL on retained and in-flight messages
- Request/response correlation — enabling RPC-style patterns over pub-sub
If your device ecosystem supports MQTT 5.0, it's the recommended baseline for new deployments. Legacy devices using 3.1.1 are fully compatible with modern brokers.
Can You Use Both?
Absolutely — and many production deployments do. A common architecture uses MQTT for device-to-cloud telemetry (where efficiency and reliability matter) and HTTP for cloud-to-application APIs (where developer experience and firewall compatibility matter). The IIoT platform acts as the translation layer, ingesting MQTT streams from devices and exposing REST APIs to downstream applications.
SIMBIOSYS supports both MQTT and HTTP ingestion natively, allowing you to connect device fleets that use either protocol without requiring additional middleware or translation layers.
Conclusion
MQTT wins decisively for high-frequency, constrained-device, unreliable-network scenarios — the canonical industrial IoT deployment. HTTP wins for simplicity, firewall compatibility and lower-frequency reporting where developer experience and integration ease outweigh raw efficiency.
The choice is rarely binary: design your architecture to support both where your device ecosystem is heterogeneous, and let the platform handle the translation. The wrong choice is optimising prematurely for one when your actual device mix demands the other.