MQTT V/s HTTP (REST)

Protocols are essentially the established set of rules which characterize how the data is transmitted between different devices within a network. Protocols also ensure whatever the differences in the internal working of the devices may be, they should be able to communicate with each other using the established protocol. When we talk about the internet, there are many protocols for communication and transfer of a specific sets of data HTTP (Web pages), FTP (Files), RTP & RTMP (Video) and so on.

Let’s review two of the most used protocols for communication – HTTP/HTTPS and MQTT

MQTT Protocol

MQTT is a lightweight protocol established to transmit small messages in a Publish-Subscribe model. There is a Broker in the middle and clients can subscribe to receive messages from the Broker and publish messages to the Broker which are then transmitted to all subscribed clients. MQTT also supports Quality of Service (QoS) for reliable message delivery.

IoT Agent interacts indirectly with IoT devices through a MQTT Broker

IoT Agent interacts directly with IoT Devices

HTTP Protocol

The HyperText Transfer Protocol (HTTP) is widely used as a document-centric protocol that transmits messages which are formatted as webpages requested by the client from the Server. It operates on TCP/IP and supports TLS (Transport Layer Security) in the form of HTTPs. It’s widely used in client-server models for REST API between two different platforms or interfaces.

Quality of Service (QoS)

It is an agreement that dictates and guarantees the delivery of a message between a publisher and a receiver. MQTT supports 3 different levels of QoS as below.

Level 0 – at most once: Simplest and method of sending a message with the least overhead. The client simply publishes the message and doesn’t wait for an acknowledgment by the broker to ensure if the message was delivered to the subscriber or not.
Level 1 – at least once: This level guarantees that the message was delivered to the broker at least once. And if the ACK message was not received by the Sender, then it will keep sending a message to the broker multiple times until it receives an ACK message. Can cause overhead due to message transmission retries in case of intermittent transmission.
Level 2 – exactly once: This is the highest level of service where the publisher and the broker undergo multiple handshakes up to 4 in order to ensure that the message has been delivered exactly once and not more than that. Overhead is reduced but still requires multiple handshakes for confirmation.

Which is better for IoT, MQTT V/s HTTPs?

MQTT is very simple to design and implement between multiple devices in a pub-sub model whereas HTTPs with REST can become complex to implement between a client and a server. We have to define the Request and the Response Data model, and any authentication or validation mechanism adds further complexity.
QTT is more data-centric where small packets of data (JSON, String, etc.,) are transmitted. These payloads comprise of simple measurements temperature sensor data, humidity sensor data. Such a payload is also encrypted so MQTT is payload agnostic. HTTPs are more document-centric where large messages or webpage data is transmitted to the client machine and in the case of REST API’s, large JSON data is transmitted from server to client.
MQTT transmission is carried out by simple Message types such as Connect, Publish, Subscribe, Disconnect, etc.., The lifecycle of an MQTT message starts with Connect and ends with Disconnect. Here the connection can be held for a duration so we can transmit batch data as well. HTTPs has various Request types such as GET, PUT, POST, DELETE, UPDATE. Each of these request types is used one at a time depending on the nature of the Request like getting for rendering a webpage or getting information from the server. POST & PUT for sending information to be stored on the Server and so on.
MQTT has support for TLS and Authentication via Username and Password OR Private certificates without which it is not possible to publish or receive messages from the Broker. HTTP (port 80) natively uses plain text for transmission and is insecure which is why we have HTTPs (port 443) specifically for secure HTTP transmission of data where a private certificate is used to encrypt the data being transmitted.
MQTT payload header can be as small as 2 Bytes and can also scale very efficiently while transmitting a large number of messages like 1,000 or > 10,000 messages. The overall message size does not grow exponentially. In the case of HTTPs, the minimum header size is > 8 bytes as it uses ASCII characters and scaling can become problematic if 1,000 or greater messages need to be transmitted, the message size increases gradually.

Real time data acquisition based on IoT using MQTT Protocol

There is an increase of 937% in overall message size when we transmit 1000 messages over HTTPs when compared to a mere increase of 22% for 1000 MQTT messages with QoS 0 and 50% with QoS 1.

Conclusion

Determining an efficient & reliable protocol goes a long way in IoT where there can be 1000’s of sensors, gateways and interconnected devices wanting to communicate between themselves. Because the device gateways have to be configured to support any protocol. And once the configuration is done and services are up and running, it becomes extremely difficult to change the transmission protocol. In this blog, we saw why MQTT is the most sought-after protocol for IoT due to its low power consumption, reliability and efficiency in transmission of data between large number of devices. MQTT is also constantly being improved by the addition of many features like Load balancing, Message Expiry introduced in MQTT v5.0