Introduction to WebSockets
Almost all modern web browser can now deal with push notification, real-time applications and live updates. The is possible thanks to a technology called WebSockets. This blog post explains what WebSockets are, what they do, what type of applications use WebSockets and why web developers need abstraction libraries for applications that use WebSockets.
What are WebSockets?
WebSocket is an connection-based communication protocol that is part of the HTML5 specification. The protocol can be applied in web browsers and web servers for enabling the creation of bidirectional connections between client and server named WebSockets. This way, data can be transferred from one to the other and vice versa in real-time. You can compare a WebSocket with a voice connection over a mobile phone, where you are able to send and receive data at the same time. This type of communication is also referred to as "full-duplex".
Bidirectional connections enabled by WebSockets make that a server and client side of an app can now talk to each other without interruptions, because after a response has been received, the connection remains open. This also means that the server is in control and can update all the connected clients immediately when something happens, for example when a client drops.
The term WebSocket is derived from physical sockets. Both are connecting devices: just as multiple devices can connect to the same socket, multiple frontends can connect to the same WebSocket.
Applications that use WebSockets
In general, WebSockets are most useful for applications that rely on live-updates, such as chat programs, sport match updates or financial data feeds. Other examples are push notifications in Twitter feeds, or a WhatsApp message that says that one of your contacts is writing you a message at the same moment you are using the application. Apps for collaborative editing and coding also make use of WebSockets, as do online education apps that enable real-time interaction between teachers and students.
WebSockets history
WebSockets can be seen as a logical step in the evolution of the interaction between the user and a web page. In the early days of the internet, webpages were static things that allowed no interaction at all between the user and the web page. This changed with the arrival of RESTful API design in the year 2000, that introduced information flows starting with a client request followed by server response.
The problem was that in order to receive new information, the entire web page had to be refreshed. This wasn't very effective, as only parts of a webpage had to be updated while the majority of the webpage would stay the same. A new client-side technique for updating HTML code of a webpage called AJAX (Asynchronous JavaScript and XML) made it possible to refresh a webpage without refreshing it entirely, communication between client and server was one-directional. However, it didn't meet the needs of real-time applications, such as low-latency and bidirectional communication between server and client.
Before WebSockets were introduced, full-duplex communication did exist though: in 2006, a set of techniques under the umbrella named Comet were introduced that allowed the server to push data to the browser without explicitly asking for it. Over time, disadvantages of Comet came to light as it proved to be inefficient for small messages and heavy because it functioned on top of HTTP. WebSockets proved to be a valuable alternative to Comet, and also solved polling issues that came with the previous HTTP protocol, that are covered next.
WebSockets as an improvement over HTTP
In order to understand how WebSockets improved HTTP server requests, it’s important to know how HTTP handled server requests before WebSockets were introduced. The previous HTTP protocol offered two ways of making requests to the server of a webpage: short and long polling. Short polling relies on constantly sending GET requests to the server, so that the client is always updated. With many different clients polling one server, for example in a multi-player game, keeping the user experiences synchronized proved to be problematic.
Long polling reduces the number of requests by opening a connection between the client and server and makes a request where the server doesn't respond until something changes or the connection time is up. This procedure is very expansive in terms of CPU, bandwidth consumption and storage. WebSockets are a better solution to long polling as they allow a long-held single TCP (transmission control protocol) socket connection to be established between the client and the server, done with minimal overhead resulting in a low latency connection.
As stated before, WebSockes run in web browsers and web servers. In order to be able to use WebSockets, both client and web applications on the server need to support the protocol. Before you can start using WebSockets in a client-server infrastructure, both server and client need to be informed that they will be using the WebSocket protocol first. This is done through a TCP-handshake, which refers to an automated process of negotiation between two communicating participants. This handshake upgrades the HTTP protocol to a WebSocket protocol, and messages can be sent back and forth between the client and the server.
WebSocket Developer Libraries
There are two major problems that come with WebSockets. Because it is still a relatively new technology, not all browsers support WebSockets which results in compatibility problems. The second problem is that intermediaries such as HTTP proxies, firewalls and hosting providers don't support WebSockets yet as it uses a different communication protocol than HTTP.
The solution to this problem is to use an abstraction library that optimizes usability by switching between protocols according to the available resources, such as Tornado (Python), Jetty (Java) and em-websocket (Ruby). However, the most popular library is probably socket.io for Node.JS, that can be used for real-time JavaScript applications such as real-time analytics, instant messaging and document collaboration.
Conclusion
This blog post covered WebSocket, a connection-based communication protocol that is part of the HTML5 specification. We saw how it meant an evolution in client-server communication, enables real-time applications and solves problems with the previous HTTP protocol. Even though there are many advantages to using WebSockets, developers have to use abstraction libraries such as socket.io as a result of compatibility and fragmentation issues.