MQTT Vs. HTTP for IoT

Understanding the Differences Between MQTT and HTTP

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 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:

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 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:

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:

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):

The Advantages and Disadvantages of MQTT in 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

• HiveMQ’s open source software

• HiveMQ’s public MQTT broker

• Other MQTT client libraries

• MQTT 5 Essentials (the latest version of MQTT)

Additional Reading

1. Read the blog MQTT Vs. AMQP for IoT to learn the differences between MQTT and AMQP protocol.

2. Read the blog MQTT Vs. ZeroMQ for IoT to learn the differences between MQTT and ZeroMQ protocol.

3. Read the blog MQTT Vs. CoAP for IoT to learn the differences between MQTT and CoAP protocol.

4. Read the blog Transferring Data from Modbus to MQTT Broker for Advanced IIoT Data Use Cases to learn the differences between MQTT and Modbus TCP.