In the previous post we looked at how IoT data splits into three paths once it arrives in IoT Hub. Before we get into the architecture posts, there’s a detour worth making: what do IoT devices actually send, and how do they send it?
The second question is more interesting than it sounds. HTTP is everywhere, it’s well understood, and Azure IoT Hub supports it. But IoT devices operate in a very different environment from a laptop or a server - and that shapes which protocols actually work well in practice.
What IoT devices send #
Before getting to protocols, it helps to understand what data we’re actually talking about. IoT devices generate three types of data:
Sensor data (telemetry) is what most people picture first. A temperature sensor measuring the current room temperature, a pressure sensor on an industrial machine, an accelerometer in a fitness tracker. In IoT, sensor data is specifically called telemetry - you’ll see that term throughout Azure IoT documentation. It’s continuous, often high-frequency, and the data that typically drives dashboards and alerts.
User input covers direct interactions with the device. A person adjusting the target temperature on a thermostat, selecting a workout mode on a fitness tracker, or pressing a button on a machine. This is less frequent than telemetry but equally valid as a data source.
Device state describes the current condition of the device itself. Whether it’s on or off, what mode it’s operating in, how much battery it has left. For a thermostat, the state might be “heating” or “cooling”. For a connected vehicle, it could be “parked” or “driving”.
Most real IoT deployments deal with all three types, often from the same device. A smart thermostat sends temperature readings continuously (telemetry), accepts commands to change the target temperature (user input), and reports its current operating mode (state).
The network problem #
IoT devices don’t live in a data center. A truck sending its location is moving between cellular towers. A device on a factory floor is in a metal-heavy environment with interference. A smart meter is in a location where Wi-Fi signal is weak and intermittent. A fitness tracker uses Bluetooth to relay data through a phone, which may or may not have a stable connection.
Network connections in IoT are often unreliable. This is not an edge case - it’s the expected operating environment for most IoT hardware. And this is exactly what shapes which protocols make sense.
How HTTP handles a lost connection #
HTTP is the protocol your browser uses to load web pages and send form submissions. It follows a request-response model: the client sends a request, the server responds. Simple and stateless.
But HTTP has no built-in mechanism for handling a lost connection during transmission. If a device sends a message and the connection drops before the server acknowledges receipt, the message is gone. The device has no way to know whether the message arrived, and HTTP has no built-in retry logic. You’d have to implement that yourself in application code - buffering unsent messages locally, detecting connection failures, and retrying.
For a laptop loading a webpage, this is fine. You just hit refresh. For a temperature sensor sending hundreds of readings per hour, it’s a problem you’d have to solve every time.
There’s another issue specific to Azure IoT Hub: when a device uses HTTPS, it has to poll for cloud-to-device messages. Microsoft’s own guidance recommends polling no more than once every 25 minutes to avoid throttling. That’s not exactly real-time.
What MQTT and AMQP do differently #
MQTT (Message Queuing Telemetry Transport) and AMQP (Advanced Message Queuing Protocol) are the protocols Azure IoT Hub recommends for most IoT scenarios. Both are designed for exactly the kind of unreliable, resource-constrained environments IoT devices operate in.
Persistent connections #
MQTT and AMQP maintain a persistent TCP connection between the device and the broker (IoT Hub, in this case). HTTP, by contrast, opens a new connection for each request. For a device sending sensor readings every few seconds, reopening a connection constantly is expensive in terms of both bandwidth and battery.
A persistent connection also enables server push: when IoT Hub has a cloud-to-device message for a device, it can send it immediately over the existing connection. No polling required.
Quality of Service levels and reliable delivery #
MQTT has a built-in concept called Quality of Service (QoS), which controls delivery guarantees:
- QoS 0 - fire and forget, no delivery confirmation
- QoS 1 - at-least-once delivery, with acknowledgement from the receiver
- QoS 2 - exactly-once delivery, with a two-phase handshake The Azure IoT Hub device SDKs use QoS 1 by default when connecting over MQTT. This means every message is acknowledged, and unacknowledged messages can be retried.
AMQP has a similar acknowledgement model. Both protocols give you delivery guarantees that HTTP simply doesn’t have at the protocol level.
Message buffering #
When a connection drops, MQTT doesn’t just give up. Both sides play a role: the broker holds on to any incoming messages for the device until it reconnects, and the device keeps track of outgoing messages it hasn’t received confirmation for yet. Once the connection is restored, both sides catch up.
The result is that a device with intermittent connectivity can drop off the network, miss some incoming commands, and receive them reliably when it reconnects - without losing data in either direction.
Compact format #
MQTT and AMQP use binary protocol headers. HTTP is text-based, which means significantly more overhead per message. For the same payload, an MQTT packet is much smaller than the equivalent HTTP request.
For a device running on a battery and sending data over a cellular network, every kilobyte counts. MQTT headers are minimal by design - the protocol was originally built for satellite communication links and early machine-to-machine use cases where bandwidth was scarce.
MQTT vs AMQP: when to use which #
Both protocols are solid choices for IoT devices. The main difference relevant to Azure IoT Hub is connection multiplexing:
MQTT supports one device identity per TLS connection. For most IoT devices, that’s fine - a device is just itself.
AMQP supports multiple device identities over a single connection. This makes it the better fit for field gateway scenarios, where a single gateway device aggregates data from many downstream devices.
For individual devices connecting directly to IoT Hub, MQTT is typically the default choice. The SDKs default to it, it’s lightweight, and it handles connection management well.
Does this mean HTTP is wrong for IoT? #
Not exactly. HTTP works and is supported by Azure IoT Hub. For certain scenarios - devices that send data infrequently, environments where MQTT and AMQP ports (8883 and 5671) are blocked by a firewall, or situations where you need to fall back to something universally supported - HTTP is a valid option.
The recommendation to use MQTT or AMQP isn’t absolute. It’s based on what the typical IoT operating environment looks like: lots of devices, sending data frequently, over connections that aren’t always stable. In that context, a protocol with built-in delivery guarantees, persistent connections, and compact message format is a much better fit than a protocol designed for web browsers.
If your IoT device only checks in once an hour and lives on a stable Wi-Fi network, HTTP might be perfectly fine. But as soon as you add real-time requirements, battery constraints, or unreliable connectivity, MQTT or AMQP are the right tools.
What comes next? #
Now that we’ve covered devices and protocols, we can move on to what happens inside IoT Hub: message routing. That’s the mechanism that decides where a message goes after it arrives in IoT Hub - to the cold path, the warm path, the hot path, or a combination of all three.