MQTT vs HTTP: Which Protocol Is Best for Your IoT Project?
For architects and developers building Internet of Things (IoT) solutions, protocol choice is a foundational decision that dictates power consumption, latency, scalability, and overall system reliability. Two protocols dominate the landscape: MQTT (Message Queuing Telemetry Transport) and HTTP (Hypertext Transfer Protocol). While HTTP powers the web, MQTT was purpose-built for constrained, low-bandwidth, and high-latency environments. Understanding the nuanced trade-offs between these two protocols—specifically in the context of IoT—is critical to avoiding costly redesigns and performance bottlenecks.
Core Architectural Differences: Request-Response vs. Publish-Subscribe
The fundamental distinction lies in their communication models. HTTP is a synchronous, stateless, client-server protocol. A client (e.g., a temperature sensor) sends an HTTP GET or POST request to a server (e.g., a cloud API), and the server responds with data or an acknowledgement. The client must actively initiate every interaction. This creates polling overhead if the client needs to check for updates frequently.
MQTT, conversely, uses a publish-subscribe (pub-sub) model. A central broker decouples publishers (sensors) from subscribers (dashboards, databases). A device publishes a message to a specific topic (e.g., /factory/floor2/temperature). Any subscriber that has subscribed to that topic receives the message instantly. The broker handles routing, scaling, and message persistence. This removes the need for continuous polling and enables true event-driven communication, which is far more efficient for sporadic sensor data.
Bandwidth Efficiency and Overhead
HTTP headers are verbose. A standard HTTP POST request carrying a single JSON payload of 50 bytes can easily carry 500–800 bytes of headers (cookies, caching directives, content-type, user-agent). This overhead is multiplied across thousands of devices. For cellular IoT (2G/3G/4G/LTE-M) or satellite links, where data is metered and expensive, this is unsustainable.
MQTT’s binary header is minimal—just 2 bytes for the smallest message, scaling to 14 bytes for complex QoS (Quality of Service) and session controls. A 50-byte payload on MQTT results in a 52-byte total message. Over a fleet of 10,000 devices publishing once per minute, MQTT would save approximately 4.3 GB of data per month compared to HTTP. This efficiency directly reduces cloud data-transfer costs and extends device battery life by minimizing radio-on time.
Latency and Real-Time Delivery
HTTP’s request-response cycle inherently introduces latency. A client must first establish a TCP connection (SYN, SYN-ACK, ACK), then send the request, wait for the server to process it, and finally receive the response. For near-real-time applications—like industrial machine monitoring, predictive maintenance, or connected vehicle telemetry—this round-trip delay (often 50–300 ms) can be unacceptable.
MQTT maintains a persistent TCP connection between the client and broker. Once established, messages flow over this open socket without reconnection overhead. Combined with Quality of Service (QoS) levels—QoS 0 (fire-and-forget), QoS 1 (at-least-once delivery), and QoS 2 (exactly-once delivery)—MQTT can deliver messages in as little as 10–20 ms over reliable networks. For critical alerts (e.g., a pressure valve exceeding a threshold), MQTT’s push-based delivery is vastly superior to HTTP’s poll-on-demand latency.
Power Consumption and Device Longevity
Battery-powered IoT devices—such as wireless sensors, asset trackers, and environmental monitors—optimize deeply for sleep cycles. HTTP requests require the device to wake fully, connect to the network (Wi-Fi, NB-IoT, or LoRaWAN gateway), send a request over a new TCP socket, wait for a response, and then disconnect. This period of high-power radio activity lasts multiple seconds.
MQTT’s persistent connection and lighter messaging payload reduce this wake-up time. Furthermore, MQTT supports “last will and testament” (LWT) and “retained messages,” allowing devices to set a final status in case of unexpected disconnection. Many MQTT implementations also support MQTT-SN (Sensor Networks), which further reduces overhead for extremely constrained devices. Benchmarking consistently shows MQTT consumes 50–70% less energy per message than HTTP for typical periodic sensor reporting.
Security Considerations
Both protocols operate over encrypted channels. HTTP uses TLS (HTTPS). MQTT uses TLS or, in some cases, WebSockets. However, the security patterns differ.
For HTTP, authentication often relies on API keys, OAuth 2.0 tokens, or basic auth, passed in headers. Authorization is typically handled at the server side for each endpoint. This works well but requires managing token expiration and rotation across thousands of clients.
For MQTT, security is layered: The broker can enforce username/password authentication, X.509 client certificates, and token-based authentication. Authorization is fine-grained using Access Control Lists (ACLs) that define which topics a specific client can publish or subscribe to. For example, a temperature sensor might only be allowed to publish to /sensors/temperature/ topics, not to /actuators/. This topic-level security is a powerful feature that reduces attack surface. However, MQTT brokers can become a single point of failure; high-availability clustering and load balancing are often required in production.
Reliability and Message Delivery Guarantees
HTTP inherently supports data integrity through status codes (e.g., 200 OK, 201 Created, 500 Internal Server Error). If a POST fails, the client must implement retry logic. For many sensor applications, a missed reading is acceptable; for actuation or financial IoT, it is not.
MQTT’s QoS levels were designed precisely for reliability matching use-case value. QoS 0 is used for non-critical telemetry where loss is tolerable. QoS 1 ensures the message is delivered at least once (duplicates possible). QoS 2 ensures exactly once delivery, with a four-way handshake between client and broker. This is crucial for commands like unlocking a door or adjusting a medical device. HTTP lacks this native granularity; implementing exactly-once semantics over HTTP requires complex application-layer logic (idempotency keys, idempotent endpoints, deduplication tables).
Scalability and Infrastructure Requirements
HTTP scales horizontally using standard web server farms and load balancers. RESTful APIs are mature, and infrastructure (AWS API Gateway, Azure API Management, NGINX, HAProxy) is well-understood. However, scaling HTTP for millions of persistent, low-interaction IoT devices can lead to inefficiencies in connection management.
MQTT brokers are designed for high concurrency with low overhead. Open-source brokers like Eclipse Mosquitto, EMQX, and VerneMQ can handle hundreds of thousands to millions of concurrent connections on modest hardware. Commercial platforms (AWS IoT Core, Azure IoT Hub, HiveMQ) offer fully managed MQTT-based services with built-in rules engines, state management, and device shadows. The pub-sub model decouples producers and consumers, allowing easy horizontal scaling by adding more broker nodes behind a load balancer.
Use Cases: When to Use MQTT vs. HTTP
MQTT is the optimal choice for:
- Low-power, battery-operated sensors (temperature, humidity, vibration, location trackers)
- Real-time monitoring and control (industrial automation, smart grid, connected vehicles)
- Unreliable networks (rural IoT, maritime, construction sites) where persistent sessions and offline queuing are critical
- Massive device fleets (thousands to millions) where bandwidth costs and central processing loads matter
- Event-driven actuation (smart locks, valve controllers, drug dispensers)
HTTP remains appropriate for:
- RESTful APIs for device configuration, firmware over-the-air (OTA) updates, or retrieving historical data
- High-bandwidth data uploads (image or video from drones, CCTV cameras) where polling and header overhead are trivial compared to payload size
- Web-based dashboards accessing IoT data through a browser
- Devices with frequent, non-critical polling (e.g., a weather station logging data every hour with no need for real-time command reception)
- Prototyping and proof-of-concept phases, where faster HTTP development outweighs long-term efficiency gains
Integration and Ecosystem Compatibility
HTTP enjoys universal support across platforms and programming languages. It is often the default for cloud-to-device and device-to-cloud communication in IoT frameworks that are not latency-sensitive. However, for device-to-device or gateway-to-cloud communication, MQTT’s publish-subscribe pattern simplifies complex orchestration.
Many modern IoT architectures adopt a hybrid approach: using MQTT for live telemetry and command-and-control, and HTTP for non-real-time operations like logging, large file transfers, and administrative APIs. AWS IoT Core, for example, allows devices to communicate via MQTT while interacting with S3, Lambda, and DynamoDB via HTTP. This layered strategy leverages the strengths of both protocols.
Technical Constraints: Firewalls and NAT Traversal
HTTP over port 80 or 443 is almost universally allowed through enterprise and home firewalls. It is a safe default. MQTT typically uses port 1883 (unsecured) or port 8883 (secured with TLS). While most networks permit these ports, restrictive corporate firewalls may block MQTT traffic, requiring WebSocket tunneling (MQTT over WebSockets on port 443). This adds overhead but circumvents strict firewall policies.
For devices behind Network Address Translation (NAT), HTTP’s request-response model requires only that the client can establish an outbound connection. MQTT’s persistent connection also originates from the device, so NAT is usually not a problem. However, extremely constrained devices with NAT timeouts of 60 seconds may require keepalive messages (ping requests) to maintain the MQTT session, adding minor overhead.
Data Encoding and Payload Format
Neither protocol enforces a specific payload format; JSON and binary protocols (Protocol Buffers, CBOR, MessagePack) are common with both. However, MQTT’s minimal overhead favors compact binary encodings. Using Protocol Buffers over MQTT can reduce payload sizes by 50–80% compared to JSON, which is beneficial for bandwidth-constrained networks. HTTP, with its larger header overhead, still benefits from binary encoding but gains less relative advantage.
State Management and Device Shadows
HTTP is stateless by nature; each request is independent. State must be managed externally (e.g., in a database). MQTT sessions can be persistent; the broker stores subscription information and missed messages (if QoS 1 or 2) for offline clients. This is critical for mobile or intermittently connected devices. Features like “device shadows” or “digital twins” are naturally implemented using MQTT’s retained messages and session state, whereas HTTP requires explicit state synchronization logic.
Network Bandwidth Variability
Over constrained networks like LoRaWAN (where packet size limits are 51–242 bytes) or NB-IoT, MQTT’s small header is essential. HTTP headers alone would consume an entire LoRaWAN packet, leaving no room for payload. For cellular LTE-M or Cat-M1 networks, MQTT’s efficiency translates to lower SIM card data costs. HTTP can still function, but data plans optimized for IoT (e.g., 500 MB per year) become impractical when HTTP overhead consumes 30–40% of the allocation.