MQTT vs HTTP for IoT: persistent publish-subscribe or request-response?

MQTT and HTTP both run over TCP and both can carry the same JSON reading, but they organize a conversation differently. With MQTT, a device opens one connection to a broker, keeps it open, and publishes to and receives from named topics. With HTTP, a client sends a request to a server and gets one response; the server cannot speak first. That single difference decides most of the trade-offs below.

The short answer. Use MQTT when devices send frequent small messages, when the cloud needs to push commands or configuration to devices without waiting for them to ask, when several applications consume the same data, or when links are unreliable. Use HTTP (usually a REST API) when devices report rarely, when they mostly fetch things such as configuration or firmware, when you integrate with existing web services, or when you do not want to run a broker. Many fleets use both: MQTT for telemetry and commands, HTTPS for firmware downloads and provisioning.

	MQTT	HTTP (REST)
Pattern	Publish-subscribe through a broker	Request-response between client and server
Connection	Long-lived, kept alive with pings	Per request, or reused while traffic flows
Reaching the device	Broker pushes on subscribed topics	Device has to poll or hold a request open
Minimum header	2-byte fixed header	Text request line and headers
Delivery options	QoS 0, 1, 2; retained messages; Last Will	Status codes; retries left to the client
Specification	OASIS MQTT 3.1.1 and 5.0	IETF RFC 9110 and related RFCs

How do the two models differ?

HTTP is defined as a stateless request-response protocol: each request carries everything the server needs, and the response closes the exchange. A device that wants to report a temperature sends a POST to a URL; a device that wants a setting sends a GET. The server never initiates anything. This model is simple to reason about, cache, load-balance and debug, which is why it dominates the web.

MQTT is publish-subscribe. Devices and applications connect to a broker as clients, publish messages to topics such as site1/pump3/pressure, and subscribe to topic patterns. Publishers do not know who receives their messages, and a new consumer can subscribe without any change on the device. The broker keeps per-client session state: under the MQTT 5.0 specification that includes the client’s subscriptions and the QoS 1 and 2 messages still waiting to be delivered to it. The protocol is stateful by design, and that state lives in the broker.

How much overhead does each add?

MQTT was designed for small packets. Every control packet starts with a fixed header of two bytes at minimum, a type byte and a variable-length “remaining length”, and a keep-alive ping is just that header. A PUBLISH adds the topic name and, for QoS 1 or 2, a packet identifier before the payload.

An HTTP/1.1 request carries a request line and text headers (host, content type, length, authorization) on every message, which for a ten-byte sensor reading can be many times the payload. HTTP/2 compresses repeated headers with HPACK, which narrows the gap on a long-lived connection but adds its own framing.

The bigger cost is often the connection, not the headers. Opening TCP and negotiating TLS takes several round trips plus a certificate exchange that is usually much larger than a sensor reading. A device that keeps one MQTT connection open pays that once. A device that opens a new HTTPS connection for every reading pays it every time. HTTP/1.1 defaults to persistent connections, so a client sending a burst of requests can reuse one, but servers and proxies close idle connections, and devices that sleep between reports usually reconnect anyway. AWS summarizes the difference for its own service by rating MQTT’s protocol overhead and power consumption as lower than HTTPS.

How does each reach the device?

This is where MQTT clearly wins. A device subscribed to devices/42/commands receives a command as soon as the broker gets it, over the connection it already holds. With HTTP the device has to ask: it polls on a timer (slow to react, wasteful when nothing changes) or holds a long-poll request open (which is a persistent connection again, built from parts not designed for it).

The difference shows up in platform features. AWS IoT Core lets HTTPS clients publish only, while MQTT clients publish and subscribe, and only MQTT gives it device disconnection detection and messages held for a device that was offline. MQTT also adds the Last Will, a message the broker publishes when a client drops without saying goodbye, and retained messages, which hand a new subscriber the last known value immediately.

Which one is better for battery-powered devices?

It depends on how often the device talks. A device that reports every few seconds or must accept commands at any time is far better off holding one MQTT connection: the cost of each message is a few bytes, and the keep-alive interval, which MQTT expresses in seconds, can be tuned to what the network’s NAT timeouts allow.

A device that wakes once an hour, sends one reading and sleeps is a different case. Keeping a TCP connection alive through an hour of sleep is usually not possible, so it reconnects either way, and the comparison comes down to MQTT’s CONNECT and PUBLISH against a single HTTP POST over a fresh TLS session. The difference is small, and simplicity on the server side may decide it. For the most constrained devices, on NB-IoT or battery radios, the better answer may be neither: CoAP over UDP avoids TCP altogether.

When is HTTP the better choice?

Rare reports and no commands. A meter that uploads once a day gains little from a broker.
Fetching rather than receiving. Firmware images, certificates and configuration files fit request-response, with ranges, caching and content delivery networks for free.
Integration with web services. Webhooks, third-party APIs and serverless functions speak HTTP natively, and every developer knows the tools.
No broker to run. A small project with one backend may not justify operating a broker and its security.
Strict request-response semantics. When the device needs a definite answer to a definite question, HTTP status codes are clearer than MQTT 5’s request-response properties.

MQTT is the better choice for fleets that need commands and live state, for fan-out to several consumers, and for unreliable cellular or satellite links where its session and QoS model saves you from writing your own retry logic.

What about MQTT over WebSocket?

The MQTT specification defines WebSocket as a transport: MQTT packets travel in binary WebSocket frames, and the connection negotiates the subprotocol name mqtt. The WebSocket protocol starts as an HTTP request and upgrades the connection, so it passes through proxies and firewalls that allow only web traffic, typically on port 443. AWS IoT Core, for example, accepts MQTT over WebSocket on port 443 with the same publish and subscribe operations as plain MQTT.

Two uses dominate. Browser dashboards cannot open raw TCP sockets, so they subscribe to live device data over WebSocket. Devices behind corporate networks that block port 8883, which the specification notes is registered with IANA for MQTT over TLS, can still reach a broker. The cost is an HTTP upgrade at connection time and a few bytes of WebSocket framing per packet, which matters little once the connection is up.

Where to go next

MQTT explained covers topics, QoS levels, sessions and security in depth.
CoAP explained describes the REST-style alternative built for constrained devices over UDP.
The IoT data pipeline shows what happens to messages after the broker or the API.
ESP32 vs Arduino vs Raspberry Pi helps choose the hardware that will run the client.

Topics: MQTT, HTTP, REST, protocols, comparison