IoT protocols for asset tracking: MQTT vs HTTP vs CoAP — what to use when

Choosing an unsuitable protocol in an asset tracking stack does not lead to immediate failure but to massive failures. There will be higher latencies, shorter than expected battery life, and even the message broker might be unable to handle thousands of concurrent connections.
The following is the right choice criterion.

Overview of three protocols

MQTT

Message Queuing Telemetry Transport
Pub/sub over TCP. Designed for unreliable networks and constrained devices. There is a broker that mediates communication between publisher and subscriber; peer-to-peer communication is never used.

• Pub/Sub properties
• Based on TCP
• Persistent connections

HTTP

Hypertext Transfer Protocol
Client-server request/response mechanism over TCP. In HTTP, each device establishes a connection, sends the data, waits for a response and closes the connection. High level of compatibility allows communication to happen everywhere.

• Req/Response features
• Stateless
• Universal application

CoAP

Constrained Application Protocol
HTTP semantics over UDP. Created especially for IoT constrained devices with low latency, multicast abilities, and an observe option for asynchronous delivery of messages.

• UDP based
• Lightweight
• Multicast

MQTT vs HTTP vs CoAP

Criteria	MQTT	HTTP	CoAP
Transport	TCP	TCP	UDP (lightest)
Overhead	2 byte header (wins)	~800 byte headers	4 byte header
Connection	Persistent (wins)	Per-request	Connectionless
Battery impact	Low	High	Lowest (wins)
Reliability	QoS 0/1/2 (wins)	TCP guaranteed	Optional ACK
Scalability	High (broker fans out) (wins)	Medium	High (multicast)
Ecosystem	Strong IoT support	Universal (wins)	Niche IoT only
Firewall-friendly	Port 1883/8883	Port 80/443 (wins)	Port 5683 (UDP)

MQTT

: location update publication
The use of an ongoing connection means that the handshaking process per each message is no longer relevant, which makes it very effective in cases when thousands of tags report their location every few seconds.

const mqtt = require('mqtt')
const client = mqtt.connect('mqtts://broker.assettrackpro.com', {
  clientId: 'asset-tag-7821',
  username: 'device',
  password: process.env.MQTT_TOKEN,
  clean: false,                 // persist session across reconnects
  reconnectPeriod: 1000
})

// Publish with QoS 1 — at least once delivery
client.publish(
  'assets/7821/location',
  JSON.stringify({ lat: 43.65, lng: -79.38, ts: Date.now() }),
  { qos: 1, retain: false }
)

HTTP

: simplicity beats efficiency
If the update interval is quite long (every five minutes or even longer), if the backend system is built on REST architecture, or if the updates have to go through firewalls which do not allow access to nonstandard ports, then HTTP may be preferred. While the overhead is significant, it becomes reasonable in low update frequency cases.

// Simple HTTP POST — works everywhere, no broker needed
await fetch('https://api.assettrackpro.com/v1/location', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Authorization': `Bearer ${TOKEN}`
  },
  body: JSON.stringify({
    assetId: '7821',
    lat: 43.65, lng: -79.38,
    ts: new Date().toISOString()
  })
})

CoAP

: when low power consumption comes first
CoAP, being based on UDP, does not require connection setup and skips roundtrips inherent to TCP connections. In case the tag consumes energy from a battery designed to function for decades with one charge and updates location every fifteen minutes, then the number of transmitted bytes could make a difference in terms of extended functionality. The next code sample shows an example of CoAP POST with node-coap module.

const coap = require('coap')

const req = coap.request({
  hostname: 'coap.assettrackpro.com',
  pathname: '/location',
  method: 'POST',
  confirmable: true      // CON message — expects ACK
})

req.write(JSON.stringify({
  id: '7821', lat: 43.65, lng: -79.38
}))

req.on('response', res => console.log(res.code))
req.end()

QoS recommendations for MQTT messages

• QoS level 0 works well for high frequency location pings if some data loss is acceptable (position updates every five seconds with acceptable loss of one message).
• QoS 1 can be used to send alerts, breach messages, and other events for which the delivery of every message is crucial.
• QoS 2 (Exactly Once) will rarely be necessary for asset tracking purposes.

Protocol to be Selected for a Particular Situation: An Empirical Decision Approach

The following decision model highlights how different communication protocols can be assigned to certain applications. According to empirical observations, the following protocol assignments take place:

• Large amounts of data to be updated within thousands of devices: MQTT
• Real-time dashboard applications and alerts: MQTT
• Limited pinging through firewall: HTTP
• Back-end API integration and fast interoperability: HTTP
• Extremely low power consumption with decades-long battery lifespans: CoAP
• Restricted environments with low RAM in microcontrollers: CoAP

For practical asset tracking stacks, usually, MQTT is used for devices' communications, whereas HTTP interfaces are created for integrations with other services and systems. As far as CoAP is concerned, it still plays a rather specialized role and proves extremely useful when focusing on the maximum possible battery lifespan in the case of LoRaWAN or NB-IoT.

Empirical evidence suggests that AssetTrackPro allows devices to send their data through MQTT, HTTP, and CoAP.
Learn More about AssetTrackPro↗