MQTT (Message Queuing Telemetry Transport) and WebSocket are communication protocols often used to facilitate realtime communication between IoT applications, web browsers, and devices. Often, people find it challenging to select the right one for their specific use case.
Although MQTT and WebSocket are somewhat in competition (in the sense that you can use either one of them for some use cases, such as live chat for mobile devices), they also complement each other; you can use MQTT over WebSockets to consume MQTT messages in a browser.
In this blog post, we will compare these two protocols, help you understand how they work, how they complement each other, and the distinctive characteristics of MQTT and WebSocket.
Below are the topics that we’ll discuss in this post:
WebSocket is a realtime protocol that provides a persistent, full-duplex communication channel between a web client and a web server over a single TCP connection. WebSocket is ideal for systems requiring realtime updates and in scenarios where client and server communication is bidirectional and doesn't belong to the simple "request-response" schema. Examples include financial tickers, realtime multiplayer games, chat apps, and realtime geolocation updates.
A WebSocket connection starts as an HTTP request/response handshake between the client and the server. The client always initiates the handshake; it sends a
GET request to the server, indicating that it wants to upgrade the connection from HTTP to WebSockets. The server must return an
HTTP 101 Switching Protocols response code for the WebSocket connection to be established.
Once the connection upgrade is successful and switches from HTTP to WebSocket, the client and server can freely exchange messages over the connection as and when needed. After the WebSocket connection has served its purpose, it can be terminated via a closing handshake (both the client and server can initiate it).
MQTT is a lightweight communication protocol that uses the publish/subscribe messaging pattern to enable machine-to-machine communication on networks with limited bandwidth or unpredictable connectivity. It's simple to use, scalable and ideal for small-sized, constrained devices with limited CPU, memory, and battery life.
Similar to WebSockets, MQTT runs over TCP. Unlike WebSockets, MQTT natively provides one-to-one, one-to-many, and many-to-many data streams between devices and applications. In an MQTT architecture, we have:
Publishers (producers) and subscribers (consumers).
A broker which acts as the middleware MQTT server that manages the exchange of messages between publishers and subscribers. Note that messages are stored in topics (or channels).
In the previous section, we established that MQTT is suitable for high-latency networks and constrained devices such as low-powered devices and IoT sensors. One thing worth mentioning is that you can't directly send MQTT messages to a browser, because web browsers don’t have MQTT support built-in.
However, you can send MQTT messages to a browser client over WebSockets. Many MQTT client libraries such as Paho, MQTT X Web, and MQTT.js support WebSockets. These libraries provide the essential capabilities browser clients need to establish connections to MQTT brokers for subscribing to topics, publishing, and receiving messages.
To give a practical example, you can use MQTT over WebSocket to collect data from IoT sensors (e.g., gas sensors); this is done over MQTT. Data from sensors is transferred to the MQTT broker, which can then push it to a browser client over WebSockets (for example, to power a live dashboard that monitors gas levels and warns against imminent hazards).
Of course, as both MQTT and WebSockets are bidirectional, you can also send messages from web browsers (over WebSockets) to the MQTT broker, which can then forward them to the IoT consumers.
Now that you know what MQTT and WebSockets are and what it means to use MQTT over WebSockets, the following sections will help you better understand the different characteristics of MQTT and WebSocket, the performance of MQTT over TCP vs MQTT over WebSocket, and how MQTT and WebSocket compare with HTTP.
The table below compares the major differences between MQTT and WebSocket.
|Use cases||MQTT is suitable for low-powered devices with limited CPU and memory, and unreliable, low-bandwidth networks. It’s the go-to protocol for IoT use cases.||WebSockets are suitable for web apps and devices unrestricted (or less restricted) by low bandwidth. Suitable for use cases such as as financial tickers, online multiplayer games, chat, geolocation updates, live polls, etc.|
|Architecture||MQTT uses a publish/subscribe messaging pattern.||Bidirectional, socket-like API. Note: many WebSocket frameworks and libraries add pub/sub capabilities on top of WebSockets.|
|Messaging QoS||MQTT has three QoS (quality of service) options: 0 (at most once delivery), 1 (at least once delivery), and 2 (exactly-once delivery).||Raw WebSockets don't provide QoS options.|
|Messaging mode||Asynchronous, event-based||Asynchronous, event-based|
|Message size||Maximum of 256 MB||2^63 bytes per frame|
|Message overhead||Minimum of 2 bytes||Minimum of 2 bytes for all messages except masked frames, which have a minimum of 6 bytes.|
|Message queuing||MQTT brokers queue messages for all disconnected clients subscribed to a topic.||Raw WebSocket doesn't support message queuing.|
The table below compares the performance of MQTT over TCP and MQTT over WebSockets. Unsurprisingly, the performance of MQTT over TCP is faster than MQTT over Websocket, and this is primarily due to the overhead in MQTT over Websocket architecture.
MQTT over TCP has relatively minimal overhead. In comparison, the overhead with MQTT over Websocket is slightly higher. This is caused by the initial exchange of complex headers between client and server and the piping and unpacking at both the client and server end.
|Criteria||MQTT Over TCP (in Bytes)||MQTT Over WebSocket (in Bytes)|
|QoS 1 message published / 256 byte||545||555|
MQTT over TCP vs MQTT over WebSocket. Source: https://go.ably.com/b73
One factor differentiating MQTT and WebSocket from HTTP (Hypertext Transfer Protocol) is that the MQTT and WebSocket are event-driven protocols, while HTTP is request-driven.
WebSockets are stateful, and the connection between a client and a server remains active until either the client or server closes the connection. MQTT is also stateful and operates differently than HTTP - it uses push-based pub/sub communication instead of the GET/POST pattern in HTTP.
In contrast to WebSocket and MQTT, HTTP is stateless and needs a new connection with every request (this process is very resource-intensive). HTTP is sometimes referred to as an asymmetric 'request-and-response' client-server protocol. Learn more about the differences between WebSocket and HTTP.
The choice of which protocol to use entirely depends on your use case and what you're trying to achieve. If you aim to enable M2M communication for sensors, IoT applications, and apps operating in networks with low bandwidth and high latency, then it's advisable to use MQTT.
If you want to enable full-duplex, two-way communication in an environment where you don't necessarily deal with constrained devices, then you should consider using WebSockets. As mentioned before, you can use WebSockets to build functionality like chat applications, realtime multiplayer games, and live geolocation updates, among many other examples. Consider using MQTT over WebSocket if you want to send MQTT messages directly from low-powered devices and sensors to web browsers.
Ably is a realtime platform designed for last-mile pub/sub messaging. We make it easy for developers to build realtime experiences like chat, live dashboards, and asset tracking for millions of users, without the hassle of managing and scaling infrastructure.
At Ably, we embrace open standards and interoperability. Our realtime client library is WebSocket-based. Going beyond WebSockets, we believe that you should have the flexibility to choose the right protocol for the job at any given moment. That’s why in addition to WebSockets we support many other protocols, including MQTT.
AMQP is not two versions of the same protocol, but two entirely different protocols: one is called "0-9-1", and the other "1.0". RabbitMQ uses AMQP 0-9-1.
Java and WebSockets: Building dependable realtime apps
Learn how to build dependable realtime apps that scale with Java and WebSockets, and the challenges associated with this.
WebSocket vs REST - Key differences and use cases
Discover the different features, performance characteristics, and use cases for WebSocket - a stateful protocol, and REST - a stateless architectural style.