Understanding the Differences between MQTT and WebSockets for IoT

Understanding the Differences between MQTT and WebSockets for IoT

author portrait

Written by Ian Craggs

Category: MQTT IoT

Published: July 20, 2022


MQTT and WebSockets are not really in competition with each other, but complementary. MQTT was designed for the Internet of Things (although it wasn’t called that at the time). The WebSocket protocol was created to give applications in web browsers access to TCP-based socket APIs, hence “WebSockets” . They both run over TCP connections, but the WebSockets functionality is more comparable with TCP itself rather than MQTT. 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. WebSockets allows the same behavior when working in conjunction with MQTT, but at the cost of higher overheads.

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 Pattern

The MQTT commands are CONNECT, SUBSCRIBE, PUBLISH, UNSUBSCRIBE and DISCONNECT. Topics are the medium of distribution, to which clients can PUBLISH and SUBSCRIBE. All authorized subscribers to a topic will receive all messages published to the topic. MQTT topics do not have to be pre-defined: client applications can create them simply by publishing or subscribing to them.

What is the WebSocket protocol?

The WebSocket Protocol was created to allow web applications to conduct two-way communications with web servers, as HTTP cannot do that without awkward workarounds. It is defined in RFC 6455.

A web browser that has WebSocket support allows web applications to communicate with a server like TCP does for regular applications - sending and receiving data asynchronously in both directions. However, WebSockets in the browser are restricted to the TCP connection that has already opened for the HTTP connection, for security reasons.

Using WebSockets with MQTT

As WebSockets behave in a similar way to TCP sockets, protocols which run over TCP can also run over WebSockets. There are many MQTT servers and client libraries which now support WebSockets. The first client libraries to offer support were the ones that run in web browsers, principally JavaScript, as illustrated here:

Using WebSockets to Tunnel MQTT

There is a lot of IT infrastructure geared towards securing HTTP connections while shutting out unwanted TCP traffic. Many organizations are reluctant to open the MQTT standard ports (1883 and 8883) to allow MQTT applications to communicate with the intra-organization infrastructure. The WebSocket protocol allows MQTT communications to use the already existing HTTP facilities: TCP port 80, firewalls, proxies and so on. For this reason many MQTT client libraries which do not run in web browsers also support WebSockets, such as the Eclipse Paho C Client.

MQTT and WebSockets comparison summary

MQTT WebSockets
Full name MQTT (the OASIS standardization group decided it would not stand for anything) The WebSocket Protocol
Architecture Publish subscribe (MQTT does have a request/reply mode as well) Bidirectional, socket-like API
Command targets Topics WebSockets
Underlying Protocol TCP TCP
Secure connections TLS + username/password (SASL support possible) TLS on the TCP socket
Client observability Known connection status (will messages) Unknown connection status
Messaging Mode Asynchronous, event-based Asynchronous
Message queuing The broker can queue messages for disconnected subscribers None
Message overhead 2 bytes minimum.  Header data can be binary
  • 2 bytes minimum
  • 6 bytes minimum for masked frames
Message Size 256MB maximum 2^63 bytes per frame
Content type Any (binary) Any (binary)
Message distribution One to many One to one
Reliability Three qualities of service:
  • 0 - fire and forget
  • 1 - at least once
  • 2 - once and only once
None

MQTT Performance over TCP and WebSockets

Here is a comparison of the data used for MQTT over TCP and WebSockets without TLS. These figures include the extra data sent and received internally by TCP.

MQTT over TCP(Bytes) MQTT over WebSockets(Bytes)
Establish connection 512 1161
Subscription request 291 299
Disconnect 334 418
For each 256 byte QoS 1 message published 545 555

The connection establishment figure for MQTT over WebSockets is larger because of the WebSocket protocol startup, which is in addition to that of TCP and MQTT. 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.

In all cases, the data used by WebSockets is greater. Next, message throughput:

No. of messages Payload Size (bytes) MQTT QoS MQTT over TCP (msgs per sec) MQTT over WebSockets (msgs per sec)
10k 256 0 6631 5708
10k 256 1 1591 1306
10k 256 2 1344 1095
10k 100k 0 1119 705
10k 100k 1 1060 676
10k 100k 2 1042 660

These measurements are made by waiting for the acknowledgement each time before sending the next message, using the Paho C client and the HiveMQ CE broker. They show the extra overhead of using a WebSocket connection versus plain TCP.

As the payload size increases, the relative difference between TCP and WebSockets also increases. This is because the WebSocket payloads have to be masked at the sending end and unmasked at the receiving end, causing extra processing overhead.

MQTT summary

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 which don’t have the capacity to do it themselves.

WebSockets summary

WebSockets is not really in competition with MQTT here. It allows web applications to use a TCP socket like API, and for non-web applications to tunnel through existing organization firewalls that allow and protect HTTP traffic. MQTT can run over WebSockets, as can other IoT protocols, but the overhead is greater than using TCP alone. For that reason, you wouldn’t choose to use MQTT over WebSockets for better performance, but to simplify an IoT solution.

Conclusion: MQTT Vs. WebSockets - Which is better for IoT?

MQTT is obviously better for IoT. On its own, for WebSockets to compete with MQTT all those facilities that MQTT contains would have to be implemented in the client and server applications. Other IoT protocols that normally use TCP could also use WebSockets, if the implementations support it.

For IoT purposes, you’ll find that MQTT does much more than HTTP and WebSockets, and it’s not difficult to get started. If you are familiar with HTTP and WebSockets and are wondering what MQTT can offer you then check out these resources:

About Ian Craggs

Ian Craggs has worked with MQTT since 2002. He has created MQTT client and server implementations, notably in the Eclipse Paho project. He is secretary of the OASIS MQTT standardization committee and worked on the standardization of MQTT 5.0. He is co-chair of the OASIS MQTT-SN standardization committee, and is also contributing to the standardization of Eclipse Sparkplug.
newer posts Building Industrial Digital Twins on AWS Using MQTT Sparkplug
The Key Differences Between OPC UA And MQTT Sparkplug older posts