Comparison

HTTP vs MQTT: Choose the Best Protocol for your IoT Project

Laurenz Dallinger12.10.202219.04.2024

“IT” is so entrenched in our linguistic usage that we no longer even think about what it means. Information technology means orchestrating the exchange of information.

Often we think of it as push and pull – that is, “I want a piece of information,” and I receive it. That would be the natural use case for the HTTP protocol.

But what if the devices need to communicate with each other? And even further: listen to each other, and their processes are interdependent. In this case, it quickly becomes clear that the MQTT protocol is suitable for this task.

Read this article to see the comparison of HTTP vs MQTT. I assure you that, in the end, you will be able to choose the one that best fits your project requirements.

What is MQTT?

MQTT, also known as MQ Telemetry Transport, is a data transmission protocol. IBM developed MQTT protocol in 1999 for transmitting information between low-power sensors. It is based on the publish/subscribe model (pub-sub).

Publish / Subscribe model

Honestly, the name publish-subscribe model presents an obstacle to understanding MQTT.

So let me try an illustrative example: Imagine several people are comfortable in a swimming pool, and some start chatting about the weather.

Person 1 starts the conversation and says the weather is lovely today. Three interested people pick this message up.

And with that, we already have our first pub-sub exchange. Person 1 has taken on the publisher role and shared a message with the group about the weather. The interested bathers have taken it up. With this, they have become so-called subscribers.

In this example, the pub-sub model offers interested people the possibility to exchange information about a topic.

In the future, the subscribers will answer. For example, one would say that the weather is nice but also too warm. In this case, the subscriber switches roles and becomes a publisher whose message that “it is too warm” the interested parties can receive, in return. And already an exchange has taken place.

So the pub-sub model takes clients and allows you to exchange information about so-called topics. All clients can be publishers and subscribers who can publish on topics but also subscribe to these topics.

Back to the swimming pool: So far, few bathers have communicated using only one topic. However, it is possible to scale both variables: More bathers communicating via multiple Topics. The result: the system breaks down.

Therefore, the so-called broker now comes into play. 

The system is restructured as follows: The publisher gives his message, “The weather is nice,” directly to the broker. The broker knows who is interested in the message, i.e., has subscribed to the topic and forwards it to those interested. And so it happens with the answer of the bather that it is too warm.

By the way, this broker operates for all bathers and all topics. And as you might have guessed, the broker not only takes care of the bathers’ communication needs but also plays the role of the overseer/lifeguard.

To exchange information using the publish/subscribe model, an MQTT client (any device connected to the broker) uses an MQTT library. Read more about MQTT libraries and the publish/subscribe model in the MQTT Connections article.

MQTT Maintenance

Everything that happens in the pool goes through the broker. And only through the broker. This fact makes it so easy for a system architect to maintain the MQTT setup.

And whenever a client leaves the pool? No problem. This client logs off at the broker and does not affect the other bathers after leaving the pool. The same happens when new clients enter the pool. Every connection that a client can make within the pool can only take place via the broker. It is worth mentioning that direct connections between clients are prohibited.

The MQTT Broker

Also, the broker shoulders most of the workload. As said, the broker deals with all packets, including each command and flag that causes actions by the broker.

Read more about the duties of an MQTT broker here.

MQTT packets

MQTT communication is based on the exchange of so-called MQTT packets. These packets only differ in their contents: commands, flags, and whether it includes a payload or not. 

Each package’s purpose (command) is specified in the package type, which occupies a part of the control panel. The flags occupy the other position.

Of course, the size of the packets varies considerably based on the job of the packet. The minimum packet size is 2 bytes. The maximum is 256 MB. The “CONNECT” packet is, of course, more extensive than a much simpler PUBLISH packet.

It is fair to say that MQTT is one of the lightweight protocols characterized by a small code footprint.

Read our complete MQTT packets guide to learn more about its types, format, and other information.

Make the MQTT communication reliable, and smart

Messaging connections must be reliable – for MQTT, reliability is critical because it works with open connections and many participating devices.

To provide reliability, MQTT offers several options you can combine as you see fit:

• The so-called “Quality of Service” (QoS) offers three different levels from which you can choose and determine how to send a message reliably. Read about QoS here.
• You can add a will with different functions if the client disconnects unexpectedly. Read more about the MQTT Last Will parameters.
• It is also possible to use a persistent or clean session (MQTT v.3.1). It is up to you whether you want to revert to an old session or start over.

MQTT IoT example

A sensor on a car door indicates whether the door is open or closed. This is important for locking the car – of course. The car door should be closed when you lock the car. Otherwise, there should be an alarm. Or even when you want to drive off.

Using the MQTT protocol to exchange data in the car is helpful for several reasons:

• The car is always remotely controlled.
• Reliable data transmission is crucial.
• Data must be sent quickly because the car is a moving vehicle.

Since the door is rarely but frequently used, it makes sense to set a retain flag. If no retained flag is set (retainFlag=false), one must wait until the door is opened or closed the next time to learn the status.

One learns this immediately with retained messages (retainFlag=true) because the retained message indicates the last status. A stored message stores the last known value of the subject.

MQTT for commercial use

MQTT is even more powerful when you use Pro Edition for Eclipse Mosquitto. For example, if you want to increase reliability and ensure that workflow continues even if one broker fails, you can add MQTT high availability to your MQTT environment. For this purpose, you can add two more brokers to your setup to create a cluster. Whenever the running broker fails, one of the additional brokers will take over the workload. And you have another one as a backup in case that broker also fails. Sign up for our Pro Mosquitto free trial and test basic MQTT scenarios, like connecting and disconnecting a client, modifying the client’s permissions, publishing messages and subscribing to topics, and more.

What is HTTP?

HTTP (Hyper Text Transfer Protocol) enables data retrieval on request. The protocol is a so-called “client-server” protocol. Thus, the HTTP protocol allows posting (“POST”) data to a server (storing data on the server), which any other client (transferring stored data from a server to the client) can also request (“GET”).

A HTTP request/response

Now let’s look at what an HTTP request/response pair looks like and how it works. The requesting client is either the user themselves, something (such as a web browser) on behalf of the user, or even internet crawling bots.

To explain this, I’ll show you a request/response with a simple web browser going to a website.

HTTP is based on the exchange of documents. Each document relies on text. Then, the browser requests the website document, which is text-based. All media to be displayed on the website are included in the document. For each media file, the browser must make another individual request. This process also applies to any design-related information (such as CSS files), web APIs, JavaScript, etc.

So each session consists of a request (plus additional requests for media files, etc.) sent by the client to the entity that stores the resource, usually the server. Their URL (e.g., https://www.cedalo.com/blog/ ) helps identify the servers.

A request contains:

• HTTP method (most common methods are GET, POST, PUT, DELETE)
• Path-URL
• HTTP protocol version
• Optional headers (additional information for the server)
• Body (containing the resource request, e.g., videos, media files, etc.)

Imagine you want to request information about a sensor. An elementary example of such a request would include the following:

• HTML (base layer of the document – text, images, additional material).
• unusual, but the document might include:
• CSS (specification of how the site and its components should look).

but also:

• WebAPIs (interfaces that allow using code written by third parties).
• Javascript (implementing code to manipulate the displayed information/data.)

The server would then respond, including

• HTTP protocol version (here is an overview of all HTTP protocol versions)
• Status code (see a list of all status codes here)
• Status message (description of the status code)
• HTTP requests (read about this here)
• Optional: body (containing requested resource in textual form – not binary!)

Layered design

MQTT relies on TCP/IP standards, just like HTTP.
TLS encryption,  the successor to the Secure Sockets Layer (SSL), provides even more security. In this way, one can send information/data over encrypted pipes. Read about how to configure TLS for the Cedalo MQTT Mosquitto broker.

HTTP request/response workflow:

A client initiates the connection and sends the request:

So the default behavior of a client is to open a new TCP connection for each HTTP request/response pair. So, to change anything, you need to send a new request and open a new connection.

Imagine you are surfing the web and looking for a new sports jacket – or an informative article about HTTP vs MQTT – you need to search for the item (e.g., “sports jacket”) – e.g., using Google. This is the first HTTP request you send. Google will list websites. You will open some of them. That’s another HTTP request each time. As you can see, you generate a lot of work right away.

Note: There are many efforts to enable HTTP communication only at the application layer (see this article here).

Comparing HTTP vs MQTT

MQTT is superior to HTTP if you have devices that communicate regularly. The MQTT protocol can keep a connection open for as long as possible, sending only a single data packet. Unlike HTTP communication, which requires you to open and close a connection (including TCP) for every data packet you want to send, you can significantly reduce CPU usage.

Also, an MQTTs payload does not need to be encrypted or decrypted to be sent. An HTTP document is always text-based; you must encrypt and decrypt any data format other than text.

What this is in numbers will be shown next:

HTTP vs MQTT: Data packet size

• An MQTT packet contains at least two bytes if a connection is already open. Otherwise, the MQTT CONNECT packet depends on its commands (lastWill, etc.) – read about the CONNECT packet here.
• An HTTP packet contains more than eight bytes.
• Also, remember that HTTP relies on text. Base64 encodes and decodes any binary code. You are creating more workload for the CPU.
• An MQTT payload can be any type of data – encoding is not necessary.

We can see that MQTT packets can have significant advantages over HTTP.

HTTP vs MQTT: Transfer time for one single message

• Each HTTP session (1. Open TCP/IP connection, 2. Send an HTTP request, 3. Receive a response, 4. Close connection) takes approximately 247-289 milliseconds (according to Google)
• MQTT packets (e.g., CONNECT packet, PUBLISH packet, see all of them here) are transferred at around 191-207 milliseconds

We see that there is not much difference between MQTT and HTTP in in terms of how much time they require for data transmission when they only send a single message (/data packet).

HTTP vs MQTT: Transfer for multiple messages

MQTT shows its talent when more than one message is sent via one connection:

In the above graph, the numbers 1 – 1000 indicate the different numbers of messages transmitted over the same connection. i.e., MQTT 1 = one single message sent using one open connection.

As explained above, the MQTT protocol performs very efficiently when an already open connection is used. It outperforms HTTP in data usage (no more connecting needed) and, time used to transfer the data (approximately 25 percent).

Why? Because MQTT does not rebuild the connection over and over again. In the layer structure graphic, you can see how much effort HTTP requires for each message transmission and, thus, for the connection setup.

Note:
– The figures used are from an external source: See Google’s overview comparing MQTT vs HTTP. Necessary: Google has used its own Google IoT Core. Response times may vary slightly based on client network connectivity.
– It is common to add integrations to the HTTP protocol to improve its processing, such as a cache.

HTTP vs MQTT: Reliability

A reliable protocol is a must whenever the client has to know whether or not the sent data was received (and acknowledged). MQTT deals with it using QoS (Quality of Service) -levels. To achieve reliability, you will need to implement add-ons for HTTP.

HTTP vs MQTT: Purposes

Indeed, the most significant difference lies within the purpose of the HTTP and MQTT protocols. We see the pub/sub- (MQTT), and the one-to-many- (HTTP) models aim for different things. 

MQTT is better than HTTP for IoT is the ability to maintain so-called “connection pools,” – enabling bidirectional communication for many devices connected by a single entity. Also, MQTT enables real-time communication as a sequential hierarchy does not lead it. HTTP must work off each request in hierarchical order – first come, first serve.

Note: It’s possible to add similar features to HTTP to emulate MQTT features.

Performance comparison of HTTP vs MQTT

Note: With “QUIC,” Google is designing a new transport protocol built on UDP – up to now, not a mature non-reliable alternative to TCP. “QUIC” is more suitable for the HTTP (-application layer).

Key Takeaways

HTTP and MQTT are made for different purposes, even though the pub-sub model of the MQTT setup looks similar to the HTTP’s request-response document-exchange protocol. 

MQTT provides a strong argument for use in the IoT (and IIoT) domain through bidirectional communication. It also enables reliable transfer by default, prevents data overload (provided that the clients use a connection that is kept open), and can transport messages from publisher to subscriber more quickly. All this will be null and void if one connection is not open. In this case, HTTP is ahead because it was developed for precisely this process: requesting one single document with all components only once.

While HTTP is a good choice for displaying information only once, MQTT is the solution whenever you want to enable communication (exchanging messages (data) ) frequently.

MQTT points out its ability to hold connections open and its way of handling data formats. Both enable successful, reliable message transfer.

On the other hand, if you do not exchange messages frequently, HTTP should be your choice.

About the author

Laurenz Dallinger

Customer Success Manager at Cedalo

Laurenz Dallinger, a go-to expert for IoT use cases, problem-solving, and customer care, brings a wealth of experience to Cedalo's MQTT and IoT-focused blog. With a diverse professional background, including previous roles as an Application Engineer and a role explaining the digitization of the German health system, Laurenz is well-versed in navigating complex technological landscapes.

Beyond his professional pursuits, Laurenz is passionate about art and tirelessly conveys to customers that digitalization is akin to the canals of Venice. He likens it to the digital Canal Grande, emphasizing the importance of navigating the smaller canals—the intricacies of digital transformation.