Understanding the Differences between MQTT and WebSockets for IoT
Written by Ian Craggs
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.
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
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
|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|
|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||
|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:
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)|
|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)|
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.
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 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:
- MQTT essentials
- HiveMQ’s open source software
- HiveMQ’s public MQTT broker
- Other MQTT client libraries
- MQTT 5 essentials (the latest version of MQTT)