Ever wonder how location tracking on your favourite delivery application worked? Or how some websites were able to display real-time data in a matter of Zeptoseconds?

Photo by Christian Wiediger on Unsplash

Alright, maybe information isn’t displayed that quickly but on average a single WebSocket request (using Socket.io) takes around 83 milliseconds compared to 107 milliseconds for an HTTP request. This may not seem like a significant difference but once we start examining the time it takes for multiple parallel requests, the time difference becomes striking.

WebSockets allow us to build real-time features by establishing a two way connection between a client and a server.

Now that we have a basic definition in place, let’s break it down a little more.

HTTP vs WebSockets

First, let’s look at how a traditional HTTP connection happens and then look at how a WebSocket connection differs.

An HTTP connection is created when a client sends a request to a server. This creates a TCP/IP connection between the server and the client. The server then sends the client back a response, at which point the connection is terminated. This means that every time a client sends a new request, a new connection must be established.

Icons made by xnimrodx.

In the early days of the world wide web, this kind of request-response model made sense but as the web grew more sophisticated, the need for real-time updates became more apparent. That’s when different HTTP request manipulations started to emerge. These manipulations are often referred to as Comet techniques and HTTP long polling is one of the most popular ones.

Now you may be asking — what’s HTTP long polling?

The connection flow is the same as with a traditional HTTP request except that the server tries to hold a client’s connection for as long as possible. This is done by only sending back a response once the server has new data to push to the client (or if the timeout expires.) This creates an illusion that the data is being updated in real-time. Long polling is used by Facebook and Google.

Now, let’s look at how WebSockets work.

A WebSocket connection begins with the client sending a request to the server. However, the request looks a little different. Instead of the request starting with http:// , it starts with ws://

WS request to server

If the server agrees, it’ll send back a response that includes a 101 status code, which confirms that the switch in protocol has been accepted.

WS response to client

At this point, a handshake between the client and the server has been initiated, meaning that a TCP/IP connection has been established and is being left open. This allows bi-directional messages to flow between the server and the client at a fast speed. This connection will stay open up until either the client or the server decides to terminate it. Technically speaking, a WebSocket connection uses HTTP up until the initial handshake. Afterwards, it simply converts the HTTP connection to a WebSocket connection.

Icons made by xnimrodx.

This type of connection is often referred to as a Full-Duplex connection, a tele-communication term that describes how a land-line functions. While on the phone with each other, both parties are able talk and be heard all at the same time. This term really brings home the point of how a WebSocket’s connection flows.

Now that we have an overall idea of what a WebSocket connection is, let’s look at some more concrete examples.

A Brief History of WebSockets

Back in the early days, we had different chat programs like MSN and AOL Instant Messenger but these programs weren’t being run directly in the browser. In December 2009, this all changed. The emergence of WebSockets allowed gaming and chatting apps to be run directly on the browsers.

What kind of Applications use WebSockets?

WebSockets could be used whenever you need to have a quick flow of information going from client to server and server to client.

They could be used for:

And the list goes on ...

Now that we have a basic understanding of how WebSockets work, let’s take a deeper dive into how we could actually implement them in our code.

WebSocket JS API demo from https://developer.mozilla.org/en-US/docs/Web/API/WebSocket

There are quite a few options out there for anyone interested in setting up a WebSocket connection. Like with most APIs, there are free/open-source options as well as premium/managed options.

Here is a brief overview of the most actively maintained, open-source WebSocket Libraries:

For Ruby, a popular WebSocket Gem is Faye-web socket, which provides classes for building WebSocket servers and clients.

Ruby WebSocket example from https://github.com/faye/faye-websocket-ruby

If you’re looking for a paid/managed solution, the most popular APIs are:

Conclusion

When we’re building applications that rely on real-time data, we only have one option and that is to implement WebSockets. By creating a persistent connection, it allows us to send data directly from the server to the client which increases the speed at which the information is being transferred, even if it’s just a matter of few milliseconds. When we’re dealing with large quantities of data, these small fractions of time certainly add up! Maybe someday soon, new ways of transferred data will come about and allow us to update data in a matter of Zeptoseconds!

References:

Full-stack web developer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store