MQTT vs. HTTP For IoT

08/06/2022, 12:13 MQTT Vs.
HTTP for IoT
Overview
MQTT Vs. HTTP for IoT Related Links
HiveMQ Product Info
Written by Ian Craggs
Category:
MQTT • IoT Get HiveMQ
Published: May 16, 2022 MQTT Essentials

MQTT Vs. HTTP: Understanding the Differences

MQTT was designed for the Internet of Things (although it wasn’t called
that at the time) whereas HTTP was created to make documents
available across the internet. They both run over TCP connections, and
https://www.hivemq.com/blog/mqtt-vs-http-protocols-in-iot-iiot/ 1/18
08/06/2022, 12:13 MQTT Vs. HTTP for IoT
are both client-server in architecture, but MQTT allows messages to pass

in both directions between clients and servers whereas HTTP servers
only respond to requests from clients.
Once an MQTT connection is
established, any number of messages can be sent through it in both
directions, data from sensor to back-end, and commands the other way.
HTTP deals with requests one at a time, with overhead such as
authentication being carried out each time. HTTP does have some ability
to pool TCP connections, but the overhead for each message remains.
MQTT message payloads are binary, whereas HTTP are textual so that
binary data needs to be base64 encoded.
What is MQTT?
MQTT is a communication protocol with features specifically targeted at
IoT solutions:
Uses TCP connections, for reliability (assured delivery and packet

error checking), fragmentation and ordering.
Aims to minimize data overhead of each MQTT packet.
The last known good data value for a device can be stored (retained
messages).
Notifications when client unexpectedly disconnects (will message)

to allow client state to be monitored.
Bi-directional message flow - data from and commands to devices
can use the same TCP connection.
Publish subscribe routing, which allows the easy addition of more
consumers and producers of data.
MQTT Publish / Subscribe Architecture
The MQTT commands are CONNECT, SUBSCRIBE, PUBLISH,

UNSUBSCRIBE and DISCONNECT. MQTT Topics are the unit of
distribution, to which clients can PUBLISH and SUBSCRIBE. All authorized
subscribers to a topic will receive all messages published to it. MQTT
topics do not have to be predefined: applications can create them simply
by using them.
What is HTTP?
HTTP (HyperText Transfer Protocol) was invented as a component of the
World Wide Web to transfer documents. It is most familiar to us as one of
the enabling technologies that allows web browsers to work. Servers
contain resources that are identified by the URLs that have the basic
familiar form:
https://www.hivemq.com/mqtt-
essentials/
to which HTTP clients can make requests: GET, PUT, DELETE and POST,
to name the most common. In a normal web environment the simple
model is a web browser retrieving web pages from a server with the GET
method:
HTTP GET Method
In an IoT environment, a common use of HTTP is to allow devices to

POST to a resource that represents the device state on the IoT service:
HTTP protocol in IoT
MQTT and HTTP Comparison Summary

MQTT HTTP
MQTT HTTP
Full name MQTT (the OASIS Hyper Text Transfer

standardization group Protocol
decided it would not
stand for anything)
Architecture Publish subscribe (MQTT Request response

does have a
request/reply mode as
well)
Command Topics URIs

targets
Underlying TCP/IP TCP/IP

Protocol
MQTT HTTP
Secure TLS + TLS +

connections username/password username/password
(SASL support possible) (SASL support
possible)
Client Known connection status Unknown

observability (will messages) connection status
Messaging Asynchronous, event- Synchronous

Mode based
Message The broker can queue Application needs to

queuing messages for implement
disconnected
subscribers
MQTT HTTP
Message 2 bytes minimum. 8 bytes minimum

overhead Header data can be (header data is text -
binary compression
possible)
Message 256MB maximum No limit but 256MB

Size is beyond normal
use cases anyway.
Content type Any (binary) Text (Base64

encoding for binary)
Message One to many One to one

distribution
Reliability Three qualities of Has to be

service: 0 - fire and implemented in the
forget, 1 - at least once, 2 application
- once and only once
MQTT Performance vs HTTP Performance in IoT

There are many different ways of measuring performance, one example,
which compares MQTT and HTTP methods of connecting to Google IoT
Core. First of all, TCP message overhead:
MQTT Bytes HTTP Bytes
Establish connection 5572 2261
Disconnect 376 (optional) 0
For each message published 388 3285
Sum for 1 message 6336 5546
Sum for 10 messages 9829 55,460
Sum for 100 messages 44,748 554,600
The connection establishment figure for MQTT is larger because of the

MQTT CONNECT packet exchange after the TCP connection is
completed. The equivalent “overhead” for HTTP has to be included with

every request which is why the per message overhead is much bigger.
The MQTT disconnect overhead shown here can in fact be 0, as it is not

compulsory to send a DISCONNECT packet before closing the TCP
connection.
Next, response times:
No. messages in a MQTT avg. response HTTP avg.

connection cycle for time per message (ms) response time per
MQTT (QoS 1) message (ms)
1 113 289
100 47 289
1000 43 289
The reduction in response time as we send more messages during a

single TCP connection is expected, as we do not incur the connection
setup overhead for each message. HTTP does not have that ability -
some approaches such as caching or connection pooling can improve

response times and overhead but not to the extent to match MQTT.
These measurements are made using MQTT QoS (Quality of Service) 1,

waiting for the acknowledgment each time before sending the next
message. The performance can be improved by sending subsequent
messages before receiving the preceding acknowledgment (at the cost
of some coding complexity), or using QoS 0, which does not require an
acknowledgment (at the cost of some reliability).
To illustrate the extra relative throughput and response times possible

using QoS 0 vs QoS 1, these are figures obtained with a local HiveMQ
broker, using a round-trip scenario (one message received on a
subscription for each message published):
No. MQTT Messages per Avg. round trip time

messages QoS second (ms)
10000 1 1234 0.81
10000 0 18416 0.054
The Advantages and Disadvantages of MQTT in IoT

08/06/2022, 12:13
g g
MQTT Vs. HTTP for IoT
A minor disadvantage of MQTT compared with HTTP is in the cost of

connection setup. If only one message is being sent in each TCP session,
then this overhead can be greater than HTTP. This is not the normal
scenario for IoT, however, and where multiple messages are sent and
received in the same TCP session, MQTT’s advantage quickly grows.
One
of the greatest attributes of MQTT is the flexibility with which solutions
can be created. The publish-subscribe paradigm allows many clients to
produce and share information with each other as well as back-end
systems. Brokers can be chained together, and MQTT gateways
connected to cloud services just by mapping the flow of messages
through topics. Over the air updates of firmware and configurations can
be broadcast to devices.
The inbuilt queueing of MQTT brokers can deal
with connection interruptions and provide buffering for constrained
devices that don’t have the capacity to do it themselves.
The Advantages and Disadvantages of HTTP in IoT
The principal advantage of HTTP for use in IoT is its familiarity to

developers, many of whom have implemented web solutions of one kind
or another. A consequence of this is the availability of client libraries and
servers. However, MQTT is not far behind these days, a search for MQTT
software will show up lots of options including HiveMQ’s open source
software.
HTTP has no equivalent of many MQTT features that are useful
for IoT such as queuing, QoS, retained messages and message push.
MQTT Vs. HTTP – Which is Better for IoT?

As MQTT was designed for IoT solutions it fits many more IoT scenarios
than HTTP. The only case where HTTP might be a valid choice is to
connect devices which already have an HTTP client installed to a provider
which has an HTTP option. But then only for low volume data
transmission, and without the option of sending control commands to the
device.
Conclusion
If you are familiar with HTTP and are wondering what MQTT can offer
you then check out these resources:
MQTT Essentials Series
HiveMQ’s
open source software
HiveMQ’s free public MQTT broker
Other MQTT
client libraries
MQTT 5 (the latest version of MQTT) Essentials Series
For IoT purposes, you’ll find that MQTT does

much more than HTTP, and it’s not difficult to
get started.
Note: If you have any questions about this topic or feedback on this
article, please leave a comment below.
About Ian Craggs

Ian Craggs has worked with MQTT since 2002. He
has created MQTT client and server
implementations, notably in the Eclipse Paho project.
He is secretary of the OASIS MQTT standardization
committee and worked on the standardization of
MQTT 5.0. He is co-chair of the OASIS MQTT-SN
standardization committee, and is also contributing
to the standardization of Eclipse Sparkplug.
HiveMQ 4.5.15 Maintenance Release
HiveMQ 4.7.7 Maintenance Release
Keep up to date on HiveMQ

Subscribe to our newsletter for updates on HiveMQ, MQTT, and IoT.
Enter Your Email-Adress*
Submit
By clicking the subscribe button, you give your consent to the use of your data according to our Privacy Policy.You can
withdraw your consent at any time with future effect.
0 Comments HiveMQ 🔒 Disqus' Privacy Policy 

1 Login
 Favorite t Tweet f Share Sort by Best
Start the discussion…
LOG IN WITH
OR SIGN UP WITH DISQUS ?
Name
Be the first to comment.
✉ Subscribe d Add Disqus to your siteAdd DisqusAdd ⚠ Do Not Sell My Data
Product Cloud Developers MQTT Solutions Blog Company Try HiveMQ
HiveMQ Sign up Resources Overview Automotive MQTT Client Tools About us Download HiveMQ
Features Confluent Cloud

Getting Started Glossary Transportation MQTT Introduction Logos & Media Kit Docker
Editions Integration Documentation MQTT 5 Essentials Manufacturing News AWS
HiveMQ Swarm HiveMQ MQTT Essentials Technology Get started with Events
Marketplace HiveMQ Cloud MQTT Sparkplug Azure Solution MQTT Partners
Customer Stories HiveMQ Swarm Essentials Kafka Solution Publish and Career
Pricing Security MQTT Security HiveMQ Subscribe Contact
Contact Sales Extension MQTT Client Security Services
Kafka Library Kubernetes Support
Extension MQTT Toolbox MQTT
Bridge Public MQTT Sparkplug
Extension Broker
Kubernetes FAQ
Operator
Open Source
Webinars
Newsletter
HiveMQ GmbH
Ergoldingerstr. 2a
Follow us on
84030 Landshut
Bavaria, Germany
© 2022 HiveMQ GmbH | Imprint | Privacy Policy | PGP

MQTT vs. HTTP For IoT

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MQTT vs. HTTP For IoT

Uploaded by

Copyright:

Available Formats

08/06/2022, 12:13 MQTT Vs.

HTTP for IoT

MQTT Vs. HTTP: Understanding the Differences

are both client-server in architecture, but MQTT allows messages to pass

Uses TCP connections, for reliability (assured delivery and packet

Notifications when client unexpectedly disconnects (will message)

MQTT Publish / Subscribe Architecture

The MQTT commands are CONNECT, SUBSCRIBE, PUBLISH,

HTTP GET Method

In an IoT environment, a common use of HTTP is to allow devices to

HTTP protocol in IoT

MQTT and HTTP Comparison Summary

Full name MQTT (the OASIS Hyper Text Transfer

Architecture Publish subscribe (MQTT Request response

Command Topics URIs

Underlying TCP/IP TCP/IP

Secure TLS + TLS +

Client Known connection status Unknown

Messaging Asynchronous, event- Synchronous

Message The broker can queue Application needs to

Message 2 bytes minimum. 8 bytes minimum

Message 256MB maximum No limit but 256MB

Content type Any (binary) Text (Base64

Message One to many One to one

Reliability Three qualities of Has to be

MQTT Performance vs HTTP Performance in IoT

MQTT Bytes HTTP Bytes

Establish connection 5572 2261

Disconnect 376 (optional) 0

For each message published 388 3285

Sum for 1 message 6336 5546

Sum for 10 messages 9829 55,460

Sum for 100 messages 44,748 554,600

The connection establishment figure for MQTT is larger because of the

completed. The equivalent “overhead” for HTTP has to be included with

The MQTT disconnect overhead shown here can in fact be 0, as it is not

Next, response times:

No. messages in a MQTT avg. response HTTP avg.

The reduction in response time as we send more messages during a

some approaches such as caching or connection pooling can improve

These measurements are made using MQTT QoS (Quality of Service) 1,

To illustrate the extra relative throughput and response times possible

No. MQTT Messages per Avg. round trip time

10000 1 1234 0.81

10000 0 18416 0.054

The Advantages and Disadvantages of MQTT in IoT

A minor disadvantage of MQTT compared with HTTP is in the cost of

The Advantages and Disadvantages of HTTP in IoT

The principal advantage of HTTP for use in IoT is its familiarity to

MQTT Vs. HTTP – Which is Better for IoT?

For IoT purposes, you’ll find that MQTT does

About Ian Craggs

HiveMQ 4.5.15 Maintenance Release

HiveMQ 4.7.7 Maintenance Release

Keep up to date on HiveMQ

Enter Your Email-Adress*

withdraw your consent at any time with future effect.

0 Comments HiveMQ 🔒 Disqus' Privacy Policy 

 Favorite t Tweet f Share Sort by Best

Start the discussion…

Be the first to comment.

✉ Subscribe d Add Disqus to your siteAdd DisqusAdd ⚠ Do Not Sell My Data

Product Cloud Developers MQTT Solutions Blog Company Try HiveMQ