Performance of MQTT over TLS vs. MQTT

Question

While MQTT is quite versatile it is also not secured on itself. This is by design.

According to Stanford-Clark, security was consciously left out of the protocol initially because he and Nipper knew security mechanisms could be wrapped around MQTT to boost security. Also, at the time, Stanford-Clark said information sent via MQTT, such as wind speed data from a weather station, wasn't particularly in need of securing. - Source

One of those security mechanisms that can be wrapped around MQTT is TLS. Most brokers support this nowadays. Of course any wrapping measure produces overhead. This overhead might be negligible (cf. HiveMQ blog).

Currently I am looking for information (hopefully an authoritative source) about the performance loss of MQTT over TLS vs. plain MQTT to evaluate the viability of MQTT for my project. Especially when the technology scales into a large number of subscribers.

Is there a way besides prototyping to get valid data on the performance of MQTT over TLS?

Answer 1

I wouldn't expect the difference to be too significant, once the connection is set up.

A breakdown of the overhead that TLS produces in general can be found here. The important bits are:

• The total overhead to establish a new TLS session comes to about 6.5k bytes on average
• The total overhead to resume an existing TLS session comes to about 330 bytes on average
• The total overhead of the encrypted data is about 40 bytes (20 + 15 + 5)
• It is easy to modify the above calculations to reflect more precisely the specifics of an environment, so this should be considered a basis for TLS overhead and not the authoritative answer to the question posed.

It's worth a read to see how these figures were calculated—you should come out with a greater understanding of how TLS works with all of that. As noted in other answers, the radio transmission is likely to be one of the biggest uses of energy, which is often a constraint in the IoT, so once the session is established, the overhead isn't too significant, particularly if your messages are not trivially short.

As noted by HiveMQ in the article How does TLS affect MQTT performance?:

The good news is, that a MQTT client only needs to establish a connection once per session – in contrary to protocols like HTTP, which needs to re-establish a connection on every request (if no keep-alive is used or other techniques like Long Polling are in place). Once connected to the broker, the client can send and receive messages without any additional handshake overhead. The use of TLS needs to allocate additional buffers, so RAM consumption is also slightly higher per MQTT connection.

They also provide a graph of CPU utilisation on the broker when 50,000 clients connect:

^{Image Source: HiveMQ (see above linked article)}

Do note that this is almost certainly not a typical usage pattern, but the data is nevertheless interesting. As you can see, there is a large overhead while the handshakes are in progress, but after that, the CPU overhead is nearly identical. I would expect a similar thing on the client.

Still, the general advice here is correct: a contrived benchmark won't give you the information you really need; to know how TLS will affect your use case, you need to test it in... your use case!

Answer 2

Not really, your pretty much going to have to test and benchmark your specific situation. The following are likely to have a direct impact on performance.

• What client/broker hardware are you using, does it have any hardware acceleration for crypto?
• What is the size of the payload you are sending?
• What is the connect/reconnect profile for your application?

Answer 3

Making useful performance estimates is hard. It's likely that your application will require encryption for at least some of it's traffic, so there is unlikely to be any implementation cost to make security available for this subset of the traffic.

For an energy-constrained implementation, transmission is likely to be wireless. Even with a suitable radio channel, the energy cost of setting up the channel and negotiating the connection is likely to outweigh the processing cost for encrypting a simple message - particularly if some messages need encryption.

If your messages are non-trivial, there may be some justification in performing more processing at the endpoint to reduce the network traffic.

Finally, in a scenario where the channel is heavily loaded, performance may not be as good as you anticipate from analysing a more trivial implementation of your full system.

Even if you can find a reference for the data you're seeking, it's unlikely to answer enough of the question to be enough to base design decisions on.