HTTP vs MQTT - Which Communication Protocol Should You Use in Your IoT Application?

This series of custom Internet of Things (IoT) articles will demonstrate how we can create our own IoT platform for use in IoT-related maker projects. This article will look at two messaging protocols, HTTP and MQTT, and see the relative advantages and disadvantages of each. Learn which is right for you, HTTPS and MQTT, from what MQTT and HTTPs are, advantages and disadvantages, and the best fit for your custom IoT solution!

Custom IoT Solutions Part 1 - Intro to the Internet of Things

Custom IoT Solutions Part 2 - ESP32 vs ESP8266

Custom IoT Solutions Part 3 - HTTP vs MQTT

Custom IoT Solutions Part 4 - Create an HTTP Post System

Custom IoT Part 5 - How to Make HTTP GET Requests

Getting Your Protocol Right

Creating a custom IoT platform is no small feat, especially when considering the number of pre-existing solutions available. But off-the-shelf solutions are often limited to a number of devices, are paid services, very complex to use, or just generally inappropriate for at-home hobbyists. Now that we have established what Wi-Fi device we will be using,the ESP32, it is time to choose what protocol we will use going forward when creating our custom IoT platform. While there are two major protocols,HTTP and MQTT, both are very different in operation and have their own pros and cons. So without further ado, let’s look at the first protocol: HTTP.

What is HTTP?

HTTP stands for HyperText Transfer Protocol and is the messaging protocol that drives the vast majority of the Internet and all websites. Simply look at the URL of most websites and you’ll see http or https. This messaging protocol, as its name states, uses plaintext to send commands and data using header messages that include what type of request being made, the content type, and browser information, while main body information is also described in text. The use of text to send data means that any numbers which are to be sent are sent in text form with binary values never being sent. For example, if the number 21 was to be sent, it would be written as two American Standard Code for Information Interchange (ASCII) characters, 2 and 1 instead of the binary value of 10101. This is because the ASCII table also includes commands such as carriage return and line feed which are needed to terminate the end of a line.

So how does HTTP work? When it comes to the messages themselves, HTTP is a client-driven system whereby clients initiate connections and send commands to a server. From there, the server will process the request, send a response, and close the connection. Once closed, the client and server can no longer communicate and servers can only speak when spoken to.

What is MQTT?

MQTT stands for Message Queuing Telemetry Transfer and is a messaging protocol that operates very differently from HTTP. The first major difference is that traditional MQTT data is sent as binary data as opposed to being text encoded. However, this is not a strict rule and all parts of an MQTT message can be string-encoded (which we will be doing as it allows for the use of control bytes). The second major difference between MQTT and HTTP is that MQTT is either the client or server can send messages to each other. While the client initiates a connection to an MQTT server once established, the client and server remain connected, and instead of using GET/POST requests MQTT clients use a publish-subscribe model.

Image credit: Simon Eugster, used with permission under the CC BY-SA 4.0 license

Publish

When a device publishes information they submit data to the server and specify what variable they are saving data to. These variables are global on the server any device connected to the server can send data to the variable.

Subscribe

When a device subscribes to a variable the server sends the value of the variable to the device whenever its value changes. Therefore, if another device on the network saves to a variable then any devices subscribed to that variable will receive an update on its new value.

HTTP vs. MQTT – Which Should You Use?

The two protocols are both ideal for IoT applications and each has its own pros and cons.

HTTP has the advantage that it only keeps the connection alive for a short period while a device sends and receives data whereas MQTT has to keep connections alive. Some systems are only able to handle so many connections at once and therefore HTTP (if used correctly) can potentially handle more traffic. HTTP is also arguably simpler than MQTT and a simple IoT HTTP system can be built using standard PHP files which devices POST and GET data to and from. GET is an HTTP request used for viewing something without changing it, whereas POST changes something. A common real-world example would be using GET to obtain data versus POST for a password changing form. This is complemented with the ability to easily create HTML sites around the PHP scripts which in turn creates a unified platform that runs on a single web-server.

MQTT provides the advantage that a server can send data to a client without being asked to, which can be useful when designing code on the client device. Instead of needing to probe the server for data and then process the results, it can instead be event-driven. It also allows for devices to cross-communicate easily through the server with the use of global variables that are stored on the server. For example, a switch and window can be connected together via a single variable with no need for dedicated communication links or complex probing techniques. MQTT is arguably more secure than HTTP as a connection that is always up can be established in a more complex way. Every time a device needs to submit data to an HTTP system the security protocols need to be re-established, but in MQTT this can be done just once. Since connections are not expected to be re-established in MQTT, a manual security feature can potentially be implemented whereby any device that tries to connect has to be authorised by manual confirmation at a central station (similar to a WPS button). MQTT is also more secure as less data is transmitted giving attackers fewer transactions to view to attempt to determine keys used to encrypted messages (remember, data is only sent/received during variable change events and there is no probing).

Conclusion – Which is Better, MQTT or HTTP? Picking the Best Messaging Protocol

After considering both messaging protocols, this series will use MQTT as it provides a more interesting coding project in Python, allows for very powerful features to be added, and provides many benefits such as cross-device communication. While MQTT itself does not deal with HTTP and therefore hypertext markup language (HTML), it can save all of its data in a folder accessible to an HTML site which still allows us to run an HTML server alongside our MQTT server. However, a simple HTTP system will be looked at first to show how PHP files can be used with IoT devices for GET and POST requests before we start the creation of a custom IoT platform using an MQTT like a messaging system.