If there is one decision that silently decides whether your IoT system feels fast or sluggish, reliable or flaky, cheap or expensive to run, it is the communication protocol you choose. And yet, most teams spend weeks picking a cloud provider and about 15 minutes picking a protocol. That is a mistake.
The protocol is the language your devices speak when they talk to the cloud, to each other, or to a local gateway. Pick the wrong one and you get slow dashboards, missed alerts, bloated bandwidth bills, and devices that drain their batteries in weeks instead of years. Pick the right one and everything just works.
Let us walk through the protocols that matter in 2026, compare them honestly, and help you figure out which one fits your specific situation.
Why Protocol Choice Matters More Than You Think
Here is a quick way to understand the impact. Imagine you have 500 sensors in a factory, each sending a reading every second. That is 500 messages per second, 30,000 per minute, 43.2 million per day.
If each message has 5 KB of overhead because you chose a heavy protocol like HTTP, that is 216 GB of wasted bandwidth per day. Just overhead. Not actual data. That costs real money in cloud ingestion fees and internet bandwidth.
If you chose a lightweight protocol like MQTT where the overhead is around 2 bytes per message, the same 43.2 million messages add about 82 MB of overhead. That is a 2,600x difference.
Latency compounds the same way. If your protocol adds 200 milliseconds of connection setup per message, a real-time dashboard showing 50 data points refreshes with a noticeable lag. If the protocol uses persistent connections with near-zero per-message overhead, the same dashboard feels instant.
MQTT: The Default Choice for Most IoT
MQTT (Message Queuing Telemetry Transport) is the most widely used protocol in IoT today, and for good reason. It was designed specifically for constrained devices on unreliable networks.
How it works: your device opens a single TCP connection to an MQTT broker and keeps it open. Messages flow back and forth on this persistent connection with minimal overhead. Each message is just a topic name plus your payload plus a tiny header. No HTTP headers, no connection handshakes, no session cookies.
The publish/subscribe model is what makes MQTT powerful. A device publishes data to a topic like "factory/line-1/motor-3/temperature". Any number of subscribers, dashboards, alert engines, data pipelines, can listen to that topic. The device does not need to know who is listening. The broker handles the routing.
MQTT supports three Quality of Service levels. QoS 0 means fire and forget, the message is sent once with no confirmation. Best for telemetry where occasional data loss is acceptable, like GPS coordinates sent every 10 seconds. QoS 1 means at least once delivery, the broker confirms receipt. Good for most sensor data. QoS 2 means exactly once delivery, with a four-step handshake. Use this for critical commands like remote vehicle immobilization or emergency machine shutdown.
Latency with MQTT is typically 10 to 50 milliseconds for message delivery on a decent internet connection. On a local network, it can be under 5 milliseconds. For most EV fleet telematics and factory monitoring applications, this is more than fast enough.
When to use MQTT: it should be your default choice for device-to-cloud telemetry, real-time dashboards, alert systems, and any application where you need lightweight, fast, bidirectional communication. AWS IoT Core and Azure IoT Hub both use MQTT as their primary device protocol.
CoAP: When MQTT Is Still Too Heavy
CoAP (Constrained Application Protocol) is designed for devices that are even more resource-constrained than what MQTT handles. Think tiny microcontrollers with a few kilobytes of RAM, running on battery power, communicating over lossy networks like LoRa or NB-IoT.
The key difference from MQTT is that CoAP runs on UDP instead of TCP. This means no connection setup, no persistent connection to maintain, and lower memory usage. Each message is a self-contained datagram. For devices that wake up, send a reading, and go back to sleep, CoAP is ideal because there is no TCP handshake overhead eating into battery life.
CoAP follows a request/response model similar to HTTP (GET, PUT, POST, DELETE) but with much smaller message sizes. A typical CoAP message is 10 to 20 bytes of overhead compared to MQTT's 2 to 4 bytes. Still far lighter than HTTP.
CoAP also supports the Observe pattern, which is similar to MQTT subscriptions. A client can register to observe a resource, and the server pushes updates when the value changes. This gives you real-time-ish behaviour without the client constantly polling.
Latency with CoAP is very low on local networks, often under 10 milliseconds. Over cellular networks like NB-IoT, expect 100 to 500 milliseconds depending on network conditions.
When to use CoAP: battery-powered sensors that sleep most of the time, devices on NB-IoT or LoRa networks, and applications where memory and power are extremely limited. For most industrial IoT and fleet deployments, MQTT is the better choice.
HTTP/REST: The One Everyone Knows (and Should Mostly Avoid for IoT)
HTTP is the language of the web. Every developer knows it. Every framework supports it. And that familiarity is exactly why teams keep using it for IoT when they should not.
We covered this in detail in our article on common IoT mistakes, but here is the short version. HTTP requires a new TCP connection for each request (unless you use keep-alive, which many IoT implementations do not). Each request includes headers that can be 500 bytes to several kilobytes. There is no built-in publish/subscribe model, so you need polling to check for new data.
For a device sending a reading every second, HTTP means 86,400 TCP handshakes per day, each adding 100 to 300 milliseconds of latency. Compare that to MQTT where the device opens one connection and sends 86,400 messages on it with 10 millisecond latency each.
When HTTP makes sense for IoT: device provisioning and configuration (one-time operations), firmware download (large file transfers), and REST APIs for human-facing dashboards and mobile apps. Use it at the application layer, not the device layer.
WebSocket: Real-Time for the Browser
WebSocket gives you a persistent, bidirectional connection over TCP, similar to MQTT. The key difference is that WebSocket is designed for browser-to-server communication, while MQTT is designed for device-to-broker communication.
For IoT, WebSocket is most useful on the dashboard side. Your backend receives MQTT data from devices and pushes it to the browser over WebSocket for live dashboards. This gives users real-time updates without polling.
Some teams use WebSocket directly from devices to the cloud, and it works, but it is less efficient than MQTT for this purpose. WebSocket does not have built-in QoS levels, topic-based routing, or last-will-and-testament features that MQTT provides.
Latency with WebSocket is comparable to MQTT, typically 10 to 50 milliseconds after the initial connection is established. The initial handshake is an HTTP upgrade, which adds a one-time cost.
When to use WebSocket: live dashboards in web browsers, real-time notifications to mobile apps, and any browser-based UI that needs push updates. Pair it with MQTT on the device side for the best of both worlds.
AMQP: Enterprise Message Routing
AMQP (Advanced Message Queuing Protocol) is the enterprise cousin of MQTT. Where MQTT is designed to be simple and lightweight, AMQP is designed for complex message routing, guaranteed delivery, and transactional messaging.
AMQP supports exchanges, queues, bindings, and routing keys that give you fine-grained control over how messages flow through your system. You can set up fanout exchanges that broadcast to all queues, direct exchanges that route by key, and topic exchanges that route by pattern matching.
The trade-off is overhead. AMQP messages are larger than MQTT messages. The protocol is more complex, which means more memory and processing on the device side. Connection setup is heavier.
Latency with AMQP is typically 20 to 100 milliseconds, depending on the routing complexity and QoS settings.
When to use AMQP: when you need complex message routing between backend services, guaranteed transactional delivery, or integration with enterprise systems that already speak AMQP (like some ERP and MES systems). Azure IoT Hub supports AMQP as an alternative to MQTT. For device-to-cloud communication, MQTT is almost always the better choice.
CAN Bus: Inside the Vehicle
CAN bus is not a cloud protocol. It is a vehicle-internal communication protocol that connects electronic control units (ECUs) inside a vehicle. But it is essential to understand for fleet and EV telematics because it is where the most valuable vehicle data lives.
We have a detailed guide on CAN bus data logging, but the key point for protocol selection is this: CAN bus data needs to be read by a telematics device, decoded, and then transmitted to the cloud using a cloud-friendly protocol like MQTT.
CAN bus operates at very low latency, under 1 millisecond, because it runs on a local wired bus inside the vehicle. The bottleneck is never CAN bus itself. It is the cellular connection from the vehicle to the cloud.
When to use CAN bus: it is not a choice. If you are doing vehicle telematics, CAN bus is how you get data out of the vehicle. The choice is what you do with it next, typically MQTT to the cloud.
OPC UA: The Industrial Standard
OPC UA (Open Platform Communications Unified Architecture) is the dominant protocol for industrial automation. If your factory has modern PLCs, SCADA systems, or CNC machines, they probably speak OPC UA.
OPC UA is not lightweight like MQTT. It is a rich, feature-heavy protocol with built-in security, data modelling, historical data access, alarms, and discovery. It is designed for machine-to-machine communication on the factory floor, not for sending data to the cloud.
For IoT deployments in manufacturing, the typical pattern is: machines speak OPC UA on the local network, an edge gateway reads the OPC UA data, processes it, and forwards the important data to the cloud using MQTT. This gives you the best of both worlds. OPC UA for rich machine communication locally, MQTT for efficient cloud delivery.
Latency with OPC UA on a local network is typically 5 to 20 milliseconds. The overhead is higher than MQTT but acceptable for factory floor communication.
When to use OPC UA: communication with industrial machines, PLCs, and SCADA systems on the factory floor. Do not try to use OPC UA directly for device-to-cloud communication. Use an edge gateway to bridge OPC UA to MQTT.
LoRaWAN: Long Range, Low Power
LoRaWAN is not competing with MQTT or HTTP. It operates at a different layer. It is a wireless network protocol designed for long-range, low-power, low-bandwidth communication. Think sensors spread across a large factory campus, an agricultural field, or a smart city.
LoRaWAN can transmit data over 2 to 15 kilometres in open areas with very low power consumption. Devices can run on a single battery for years. The trade-off is bandwidth. Typical LoRaWAN data rates are 0.3 to 50 kilobits per second. You can send a temperature reading or a GPS coordinate, but not a camera image.
Latency with LoRaWAN is higher than wired or cellular protocols, typically 1 to 5 seconds depending on the network configuration and duty cycle regulations.
When to use LoRaWAN: environmental monitoring across large areas, asset tracking in warehouses and campuses, smart metering, and any application where you need long range and long battery life but only send small amounts of data infrequently.
How to Choose: A Decision Framework
Here is a simple way to pick the right protocol for your situation.
If you are sending telemetry from devices to the cloud and need real-time dashboards and alerts, use MQTT. This covers 80% of IoT use cases including fleet telematics, factory monitoring, and energy management.
If your devices are extremely constrained in memory and power and communicate over NB-IoT or LoRa, use CoAP.
If you need live updates in a web browser or mobile app, use WebSocket on top of your MQTT backend.
If you are reading data from industrial machines on a factory floor, use OPC UA locally and bridge to MQTT for cloud delivery.
If you are building vehicle telematics, read CAN bus locally and transmit via MQTT over cellular.
If you need long-range, low-power communication across a large area, use LoRaWAN for the wireless link and MQTT for the cloud delivery.
If you need complex backend message routing with guaranteed delivery, use AMQP between your backend services.
And unless you have a specific reason, avoid HTTP for device-to-cloud telemetry. Save it for APIs and configuration endpoints.
Mixing Protocols Is Normal
Real-world IoT systems almost never use a single protocol. A typical smart factory deployment might use OPC UA between machines and edge gateways, MQTT from edge gateways to the cloud, AMQP between backend microservices, WebSocket from the backend to the dashboard, and HTTP for the REST API that mobile apps and third-party integrations use.
A fleet telematics system might use CAN bus inside the vehicle, MQTT from the telematics device to the cloud over 4G, WebSocket for the live tracking dashboard, and HTTP for the driver mobile app.
The key is to use each protocol where it is strongest. Do not force one protocol to do everything. And when choosing, always benchmark latency and bandwidth in conditions that match your real deployment, not in an ideal lab setup.
How Akran IQ Handles Protocol Selection
At Akran IQ, protocol choice is one of the first architectural decisions we make for every deployment. We do not default to one protocol for everything. We match the protocol to the data pattern, the device capability, the network condition, and the latency requirement.
For EV fleet telematics, we use CAN bus for in-vehicle data and MQTT over 4G/5G for cloud delivery, with QoS 1 for telemetry and QoS 2 for critical commands like remote immobilization.
For factory IoT, we use OPC UA or Modbus for machine communication, MQTT for cloud delivery, and WebSocket for real-time dashboards.
We handle the entire stack, from edge to cloud. You tell us what data you need and how fast you need it. We pick the right protocols, set them up, and manage them. If you are planning an IoT deployment and want to make sure you get the protocol layer right from the start, talk to us.