Concept renderUse MQTT when the cloud must reach the device at any time and the device can hold a connection open. Use HTTPS when the device wakes, sends a report, sleeps and can poll for commands. For rare reports on LTE-M or NB-IoT, also compare CoAP over DTLS with Connection ID, which needs no open connection.
Most MQTT vs HTTP comparisons are written for servers and dashboards. A battery device asks different questions. How often must the radio wake? Can the cloud reach the device while it sleeps? What does each reconnect cost in TLS bytes and modem time? This guide answers those with the standards text and two cloud providers' published limits. It also covers CoAP and LwM2M, because the right answer for a tracker is often neither MQTT nor HTTP.
This is an engineering summary. Cloud limits change, so confirm each figure on the provider's page before you design around it. We quote no current or battery figure here, because none of the pages we read gives one for your hardware.
MQTT vs HTTP: what changes for a battery-powered device?
The core difference is the connection. MQTT keeps one connection open to a broker, and either side can send at any time. HTTP is a request and a response. RFC 9112 says HTTP/1.1 defaults to persistent connections, but servers usually close an inactive connection after a timeout, and the standard sets no length for it (as of November 2026). For a device that sleeps, HTTP means a fresh connection on most wake-ups.
| Question | MQTT | HTTP | CoAP |
|---|---|---|---|
| Connection model | One long-lived connection to a broker. The spec needs an ordered, lossless, two-way byte stream, such as TCP/IP or WebSocket. | A request and a response. HTTP/1.1 keeps connections open by default, but servers close idle ones after a timeout they choose. | Request and response messages over UDP by default, with no connection to hold open. |
| Who can start a message | Either side, while the connection is open. | The device. To get commands, it asks the server on a schedule. | Either endpoint, because a CoAP node can act as client and server. In practice a sleeping device starts, and the server can push updates after the device registers with the Observe option. |
| Smallest control packet | PINGREQ: 2 bytes at the MQTT layer, with no variable header and no payload. | A text request line and headers on every request. | A 4-byte fixed header on every message. |
| Delivery guarantees | QoS 0 at most once, QoS 1 at least once, QoS 2 exactly once. Cloud brokers may cap this. | None in the protocol. The device reads the status code and retries. | Confirmable messages are retransmitted with growing intervals until acknowledged or out of attempts. Observe notifications are best effort. |
| Messages sent while the device was away | Held in a persistent session and delivered on reconnect, if the broker keeps one. | Nothing is held for the device by the protocol. | Nothing is held by the base protocol. LwM2M adds a Queue Mode for clients that may be disconnected. |
| Security layer | TLS over TCP. | TLS over TCP. | DTLS over UDP. DTLS 1.2 can add the optional Connection ID extension for devices behind NAT. |
Sources, as of November 2026: OASIS MQTT 5.0 (OASIS Standard, March 7, 2019), RFC 9112 (June 2022), RFC 7252 (June 2014), RFC 7641 (September 2015), LwM2M Core 1.2.2.
Header bytes matter less than they seem. On a cellular plan, the bigger costs are TLS handshakes and the time the modem stays awake. For a byte-by-byte data plan model, see tracker data plan sizing.
How can the cloud send a command to the device?
This question usually decides the protocol. If a user taps a button in the app and expects the device to react in seconds, the cloud needs a path to the device right now.
With MQTT
The device subscribes to a command topic, and the broker forwards messages on the open connection. If the device drops off, a persistent session can hold messages until it returns. AWS IoT Core keeps subscriptions and unacknowledged QoS 1 messages in a persistent session and sends them when the device reconnects. Its default session expiry is 3600 seconds and can be raised (as of November 2026). MQTT 5.0 sets this with the Session Expiry Interval; a value of 0 ends the session when the connection closes.
With HTTP
The device asks. A poll every few minutes adds that delay to every command, and each poll may need a new connection. AWS IoT Core accepts HTTPS from devices for publishing only, and its comparison table marks client ID support and disconnect detection as MQTT only (as of November 2026). For devices that report and wait, that is often fine. The server can also put a pending command in the response to the next report.
With CoAP
A CoAP client can register with a GET request that carries the Observe option set to 0. The server then sends notifications when the resource changes. RFC 7641 calls this best effort with eventual consistency: a client may miss intermediate states, but once the resource stops changing, every observer ends up with its latest state (as of November 2026). The server can only reach a device whose network path is still open.
What does the MQTT keep-alive cost on LTE-M and NB-IoT?
An idle MQTT connection is not free. In MQTT 5.0, Keep Alive is a two-byte value in seconds, up to 65,535 (about 18 hours). A value of 0 turns it off. When Keep Alive is not 0 and the server receives no packet within one and a half times that period, it must close the connection. A server can also send its own Server Keep Alive, and the client must then use that value (as of November 2026).
Cloud brokers cap the interval far below the spec maximum:
- AWS IoT Core applies 1200 seconds when a client asks for 0 or more than 1200, and treats requests under 30 seconds as 30 (AWS quotas, as of November 2026).
- Azure IoT Hub caps its server-side timeout at 1,767 seconds, so the largest client keep-alive is 1177 seconds. Its Python device SDK defaults to 60 seconds and its C SDK to 240 (Microsoft Learn, page updated August 2026).
The arithmetic is simple. At 1200 seconds, a connected device sends 72 pings a day. At 240 seconds, it sends 360. Each PINGREQ and PINGRESP is only 2 bytes at the MQTT layer, but each one wakes the modem, and TCP, IP and TLS add their own bytes. Measure the wake time and current on your board.
Now compare that with cellular power saving. A modem in PSM sleep is not reachable, so it neither sends nor answers pings. For the PSM and eDRX timers and the battery math, see PSM vs eDRX tracker battery life. If the device sleeps longer than 1.5 times the keep-alive, the broker closes the connection. If the device set a Will message, the broker can then publish it, because the connection did not end with a normal DISCONNECT. Many trackers therefore disconnect cleanly, sleep, and reconnect to a persistent session at the next report. That trades keep-alive traffic for one TCP and TLS setup per wake.
What does TLS add to each connection, and how do you reduce it?
Both AWS IoT Core and Azure IoT Hub require TLS. AWS accepts TLS 1.2 and 1.3; Azure asks direct MQTT clients for TLS 1.2 (as of November 2026). A full handshake carries certificates, and its size depends on your certificate chain and cipher suites. No source we read gives one figure that fits your setup, so capture it on your own link.
Two standard tools shrink the cost of reconnecting:
- TLS 1.3 resumption. After a handshake, the server can give the client a pre-shared key identity for future handshakes. When the server authenticates with that key, it sends no Certificate or CertificateVerify message (RFC 8446, as of November 2026). Check that your device TLS library and the cloud endpoint both support it.
- DTLS 1.2 Connection ID. DTLS normally finds a session by IP address and port. RFC 9146 says NAT rebinding while an IoT device is in an extended sleep breaks the connection, and the cost is a new handshake. A Connection ID in the record header avoids that (RFC 9146, March 2022, as of November 2026).
Avoid TLS 1.3 early data (0-RTT) for commands that change state. RFC 8446 gives no guarantee against replay between connections.
MQTT vs CoAP: when does CoAP fit better?
CoAP was built for constrained nodes. RFC 7252 describes nodes that often have 8-bit microcontrollers with small amounts of ROM and RAM. It runs over UDP by default, uses a 4-byte fixed header, and advises that a message fit in a single IP packet, with 1152 bytes as a good upper bound when header sizes are unknown (as of November 2026). It also maps cleanly to HTTP through proxies.
Retries are built into the protocol. A Confirmable message is retransmitted at doubling intervals until it is acknowledged or the retry count reaches MAX_RETRANSMIT, with defaults of ACK_TIMEOUT 2 seconds, ACK_RANDOM_FACTOR 1.5, MAX_RETRANSMIT 4 and NSTART 1. These values set how long the radio stays awake when an acknowledgment is lost, so test them on a weak signal.
The catch is the server side. AWS IoT Core lists MQTT, MQTT over WebSocket and HTTPS as its device protocols, and CoAP is not among them (as of November 2026). Azure's IoT Hub MQTT page covers MQTT 3.1.1. A CoAP device needs a server that speaks CoAP and DTLS, or a gateway that translates.
Where LwM2M fits
LwM2M is an OMA standard for device management and service enablement. The Transport Bindings spec, version 1.2 (November 10, 2020), defines CoAP over UDP, SMS and TCP, each with or without DTLS or TLS, CoAP over Non-IP, plus MQTT over TLS and HTTP over TLS. HTTP and MQTT bindings were added in version 1.2 (OMA LwM2M Transport 1.2, as of November 2026). The Core spec, version 1.2.2 (June 13, 2024), includes a Firmware Update object and a Queue Mode for clients that may be disconnected (OMA LwM2M Core 1.2.2). If you would otherwise invent your own config and update topics, LwM2M is worth a look.
What do AWS IoT Core and Azure IoT Hub support for MQTT?
Neither cloud service implements every part of the MQTT spec. Plan topics, QoS and session handling around what the broker you pick actually does.
| Item | AWS IoT Core | Azure IoT Hub |
|---|---|---|
| Device protocols | MQTT and MQTT over WebSocket Secure can publish and subscribe. HTTPS is publish only. | Its MQTT page covers MQTT 3.1.1 on port 8883, and over WebSocket on port 443. No unencrypted MQTT on port 1883. |
| QoS | QoS 0 and 1 only. A QoS 2 request gets no PUBACK or SUBACK. | No QoS 2. A QoS 2 publish closes the connection; a QoS 2 subscribe is granted QoS 1. |
| Keep-alive | A request of 0 or over 1200 seconds gets the 1200-second default. A request above 0 and under 30 seconds is treated as 30. | Server timeout is capped at 1,767 seconds, so the largest client keep-alive is 1177 seconds. |
| Largest message | 128 KB payload per publish. | 256 KB. Microsoft points to Event Grid, with a 512 KB limit, when you need a full MQTT broker. |
| Offline messages | Persistent sessions keep subscriptions and unacknowledged QoS 1 messages. Default expiry 3600 seconds, adjustable. | A device that reconnects with CleanSession 0 gets messages sent while it was away. |
| Retained messages | Supported. One retained message per topic. | Not persisted. The flag is passed to the back end as a property. |
| Connections per device | Two clients with the same client ID cannot stay connected at once. | One active MQTT connection per device. |
Sources, as of November 2026: AWS device communication protocols, AWS IoT Core MQTT, AWS IoT Core quotas, Use MQTT with Azure IoT Hub (updated August 27, 2026).
Two rows often surprise teams. First, both services allow only one live connection per device identity, so a second connection with the same ID drops the first. A firmware bug that opens two sockets can cause a loop of disconnects. Second, QoS 1 means at least once, and AWS notes that on rare occasions its broker might resend the same message with a different packet ID. Make your messages safe to process twice. AWS also says that with X.509 certificates or custom authentication an MQTT connection has no hard time limit but can be as short as a few minutes, so devices must detect disconnects and reconnect.
Where the broker runs and who holds the keys are architecture questions. See IoT architecture for connected devices.
Which protocol should your device use?
Start from how fast the cloud must reach the device and how often the device reports. The rows are engineering reasoning from the sources above. None of them describes a specific project.
| Situation | Start with | Why |
|---|---|---|
| The app or cloud must reach the device within seconds, at any time | MQTT over TLS | Only an open connection lets the cloud push without waiting for the next poll. |
| A tracker reports a few times a day on LTE-M or NB-IoT and can wait for commands | HTTPS POST, or CoAP over DTLS | No keep-alive traffic between reports. Commands ride on the response or the next poll. |
| Reports are rare, the network rebinds NAT while the device sleeps, and you control the server | CoAP over DTLS 1.2 with Connection ID | The session survives an address change without a new handshake. |
| You also need remote configuration and firmware update objects from a standard | LwM2M, over CoAP or one of its other bindings | The standard already defines a Firmware Update object and a Queue Mode. |
| The device downloads large files, such as a firmware image | HTTPS for the file, plus MQTT or CoAP for messages | Cloud MQTT payload caps, such as 128 KB on AWS IoT Core, are far below an image size. |
| The device is mains powered and sits on Wi-Fi | MQTT over TLS | The keep-alive cost matters less, and push and session features are worth having. |
On a small MCU, the protocol also decides how much of the network stack you carry. An MQTT client usually runs as a task beside TCP/IP and TLS, which shapes RAM and task planning. See what an RTOS is for that side of the choice.
What should you ask your hardware team?
Bring these questions to the architecture review, before firmware and the back end are written against one protocol.
- Does any feature need the cloud to reach the device within seconds? If not, why hold a connection open?
- What keep-alive interval does the firmware send, and what does the chosen broker do with it?
- How long does the modem stay awake after each keep-alive or report? Show the current trace.
- What happens when the device sleeps longer than 1.5 times the keep-alive? Which Will message fires?
- Does the TLS stack resume sessions, and how many bytes does a full handshake take with our certificates?
- Which QoS level does each topic use, and does the back end handle duplicates from QoS 1?
- Where do large files come from, and does that path need its own retry and resume logic?
- If we use CoAP, does the server side support DTLS Connection ID, and who runs that server?
Protocol choice sits with the firmware, app and cloud work. For how Duobay splits the device, app and cloud, see device, app and cloud architecture.
Questions about MQTT, HTTP and CoAP
Is MQTT faster than HTTP?
Once the connection is open, an MQTT publish skips the request line and headers that every HTTP request carries. AWS rates MQTT lower than HTTPS for protocol overhead and power in its device protocol comparison (AWS IoT Core, as of November 2026). The first connection costs TCP and TLS setup with either protocol, so a device that connects once per report gains less.
Can one device use both MQTT and HTTP?
Yes, and many do. A common split is MQTT for small messages and commands, and HTTPS for large downloads. AWS IoT Core caps an MQTT payload at 128 KB (AWS quotas, as of November 2026), so firmware images usually come from a separate file endpoint.
Can MQTT run over UDP?
Not as written. MQTT 5.0 needs a network connection that carries an ordered, lossless stream of bytes in both directions, such as TCP/IP or WebSocket (OASIS MQTT 5.0, as of November 2026). If you need UDP, look at CoAP or at LwM2M, which binds to CoAP over UDP.
Which QoS level should a battery device use?
QoS 1 is the usual choice for data you cannot lose, and both AWS IoT Core and Azure IoT Hub stop at QoS 1 (as of November 2026). AWS describes QoS 1 as sent at least once and then again until a PUBACK arrives, so a message can arrive more than once. Give each report an ID and let the back end drop duplicates. Use QoS 0 for data the next report replaces.
How can Duobay help choose a protocol for my device?
Duobay develops custom devices with a Shenzhen engineering team that covers electronics, firmware, enclosure and app. By default we deliver the device and an SDK tested against your own backend, and we can build the app and backend in your own cloud account. We also build samples and small batches. Initial calls are free. Tell us about your device.
If you want your connection model checked against your report rate, radio and cloud, tell us about your device.
Sources. All pages accessed November 6, 2026. Cloud limits and standards are revised, so confirm current values before you decide.
- OASIS, MQTT Version 5.0, OASIS Standard, March 7, 2019 (link)
- IETF, RFC 9112, HTTP/1.1, June 2022 (link)
- IETF, RFC 7252, The Constrained Application Protocol (CoAP), June 2014 (link)
- IETF, RFC 7641, Observing Resources in CoAP, September 2015 (link)
- IETF, RFC 9146, Connection Identifier for DTLS 1.2, March 2022 (link)
- IETF, RFC 8446, TLS 1.3, August 2018 (link)
- AWS, Device communication protocols, AWS IoT Core Developer Guide (link)
- AWS, MQTT, AWS IoT Core Developer Guide (link)
- AWS, AWS IoT Core endpoints and quotas (link)
- Microsoft, Use MQTT to communicate with Azure IoT Hub, updated August 27, 2026 (link)
- OMA SpecWorks, LwM2M Transport Bindings, Approved Version 1.2, November 10, 2020 (link)
- OMA SpecWorks, LwM2M Core, Approved Version 1.2.2, June 13, 2024 (link)
Planning a device like this? Tell us what it needs to do. A Duobay engineer replies within 1 business day. Send a project brief →