In the past, I’ve always thought that when I want to implement chat like application I must use WebSockets.
I haven’t fully understood what it meant at the time and just used them without understanding what actually is under the hood, or even if they are the right tool for the existing job.

Today I hope in our small journey, we will go through the short history of why web sockets came to be, and after we will have a detailed understanding of why we need them and how to use them.

In today’s web development, front-end developers use mostly HTTP to receive or send data from/to an HTTP server.
HTTP is a stateless protocol, meaning once we fired a request to the HTTP server and got the response, the connection has been closed.

For the experts who know about TCP connection which is kept open for a long period of time, so when you want another request after 5 seconds, just for the example, you do will send a request again on TCP connection.

Honest disclaimer, 5 seconds was just an example.
Each TCP implementation and many techniques to use with it, varies in their own time which they maintain the TCP connection open, so it could be much smaller and bigger time gap.

But what about the case when the server wants to initiate a session with you, the roaming client with his awesome mobile app?
Well, he can’t because you’re changing your IP all the time and it’s hard to track all the clients all the time.

For this article, I hope you do understand how web development is done and it’s key components to talk with a back-end application.
If not I really suggest reading a previous article of mine, in the hope it will give a glimpse of what we will talk about here.

Let’s go back in time!

In the past, when front-end developers wanted to have a piece of their website be updated in real-time from any sort of updates?
They used Ajax which helped them out to initiate an HTTP request in small intervals, so each request will update the web page.

The purpose is simple, it was to receive updates from a pre-configured URL and a specific HTTP method(GET, POST, PUT, DELETE, …) and receive the data for use, so we could update our web application, and have a real-time effect.

Now we can understand that Ajax is simply an HTTP pooling technique.
HTTP Pooling is simply issuing HTTP requests every few seconds to the server. On each request, the server can send an update or not.
This is a very consuming process in terms of networking, because we issue a request every interval of time we configure, when you might even don’t have any updates to receive at all…

HTTP is using a TCP connection in terms of OSI model. Because of that, you don’t need to ensure if the request are whole and good because TCP has it’s own mechanism to insure data integrity that was received as it is from end to end, but that’s all true if we ignore Man In the Middle attacks and all security subject 🙂

Why not use a simple Socket?

Well, to tell it very fast and short… you don’t have a socket inside web browser JavaScript implementations.

JavaScript as of today is rendered and converted to actual commands by the browser JavaScript engine, with Google it’s V8 and Firefox SpiderMonkey.
So when you issue a HTTP request, you actually using an API which has been exposed for you using JavaScript through C/C++ code of the browser itself, which is actually the one issuing the request itself.
What it doesn’t offer you is a socket API/interface for use inside JavaScript.

The web development community understood they have to go under a change.
They knew they have to do something to make the development cycle of real time communication of sockets for web application to a whole another level.
That’s when they developed in part of the HTML5, the infamous WebSocket we so love.

Big change has come

Let’s keep it simple… WebSocket allows a web server and a web client to send messages to each other like 2 friends chatting with one another.
It opens for us a TCP connection which is managed by the application layer, to allow for us to have a simple interface for sending and handling incoming data.

I’ll let you on a little secret. WebSocket is actually based on HTTP.
If you look on Wikipedia, you will see that HTTP has an upgrade header.

When we want to open a WebSocket connection, an HTTP request consisting of the Upgrade header will be sent to the server.
If the server responds back with agreeing to upgrade their connection, they will initiate a WebSocket connection.
What they will actually do, is take the TCP connection used for HTTP, and use it for the WebSocket.
Basically, they replaced the application layer protocol from HTTP to WebSocket.

After effect

As a result, today mobile and other applications which are not web applications, use WebSockets to make chat like features.

Why do they do that while they have normal sockets to use?
To explain this in the simplest way as possible, would you rather?..
Use a coffee machine which simply makes the coffee for you in a push of a button, or make it your self while dealing with boiling water, adding coffee to the cup and more…

I know there are coffee junkies out there that will say they prefer to make it by yourself, but I think you do get the point ☺

You might be thinking right now, why the hell do I talk about a coffee machine?
Well, a big crowd of programmers loves coffee so I hope I caught your attention 🙂
But for the main part, you can use normal Tcp/Udp socket in mobile or other applications instead of WebSocket.
Like the coffee machines, you will have more trouble to maintain the normal socket instead of a WebSocket connection.

Because of that, most people prefer to use WebSockets in situations you want real-time communications in terms of fast data transfer(not fast in some cases) and ease of implementation/maintenance.

But there’s an even more important reason to use web sockets.
When we wish to have real-time updates from our server, we can do the old school way which is doing multiple HTTP requests, in a fixed interval time.
In each request, we will sample the server with the question “Do you have an update for my data?”

This pooling mechanism sometimes takes a lot out of the smartphone or web browsers, and it’s not efficient, and we can have a more elegant solution.
Therefore, our web sockets help us to maintain a connection, which allows the servers to send notifications about new data directly to the client back.

Let’s take a stock market website which is stockstracker.com.
If you will do inspect elements on it, and go to the Network tab, you would be able to see it has a secured web socket opened.

I don’t know what their implementation is on their website, but if we take a look at that WebSocket Messages tab, we can see it receives messages and corresponds to the UI updates on the web app itself.
So in the end, it’s highly likable that they used it for getting real-time updates regarding the stocks, so we as the users would be real-time updated.

Conclusion

Today many application use WebSocket and they have a very huge reason why they should.

I do suggest you to see WebSockets implementation with Node.js, I think it will give you a more detailed and understanding of the subject.
There could be an entire sets of articles about WebSockets, so I tried to sum up in short about the subject and I hope I supplied it to you 🙂

I hope you had a great time reading this piece, and if you have any more further questions I would be delighted to answer them.
Also, if you have any opinions or suggestions for improving this piece, I would like to hear 🙂

Thank you and have a great journey on your journey for knowledge! 🙂