Understanding the Differences between MQTT and WebSockets for IoT
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 the sensor to the 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
As WebSockets behave in a similar way to TCP sockets, protocols that 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 that 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:
HiveMQ’s open source software
HiveMQ’s public MQTT broker
Other MQTT client libraries
MQTT 5 Essentials (the latest version of MQTT)
Watch the Video
Ian Craggs
Ian Craggs works for IBM, and has been involved with MQTT for more than 10 years. He wrote the IBM MQTT server Really Small Message Broker which became the inspiration for the Eclipse Mosquitto project. He contributed C client libraries to the Eclipse Paho project at its onset and is now the project leader.
