MQTT vs. WebSocket - Key differences and when to use them together

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.

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. 

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.