Sockets are a paradigm for handling networking, and the concept has been around for decades. Sockets were once a way to standardize networking input and output, much like an API does, so that regardless of the particulars of the hardware, applications could program to “sockets” and it would work with many different hardware implementations.

The idea behind a socket, is that it is a “port” through which data goes in and out of. Much like a real trading port for data, the socket itself is like the dock, it’s where exchanges are happening from the application standpoint. The socket itself is abstract and low level, and staying with the metaphor, many different ships, trains, and equipment can use it. We can call all of these Protocols.

On the Internet there are hundreds of protocols, but a few stand out as the most common, like HTTP, FTP, SMTP, POP3, etc. and lower level transport protocols like TCP and UDP. In essence, Protocols determine how to interpret the data going to and from the socket and the machines that are communicating with each other.

What are WebSockets?

WebSockets are really just an extension of the socket idea. While HTTP was invented for the World Wide Web, and has been used by browsers since then, it had limitations. It was a particular protocol that worked in a particular way, and wasn’t well suited for every need. In particular was how HTTP handled connections. Whenever you made a request, say to download html, or an image, a port/socket was opened, data was transferred, and then it was closed.

The opening and closing creates overhead, and for certain applications, especially those that want rapid responses or real time interactions or display streams of data, this just doesn’t work.

The other limitation with HTTP was that it was a “pull” paradigm. The browser would request or pull information from servers, but the server couldn’t push data to the browser when it wanted to. This means that browsers would have to poll the server for new information by repeating requests every so many seconds or minutes to see if there was anything new. In the late 2000’s, a movement to add Sockets to browsers was mounting.

In 2011, the WebSocket was standardized, and this allowed people to use the WebSocket protocol, which was very flexible, for transferring data to and from servers from the browser, as well as Peer-to-Peer (P2P), or direct communication between browsers. Unlike HTTP, the socket that is connected to the server stays “open” for communication. That means data can be “pushed” to the browser in real time on demand.

What is REST?

In REST, or REpresentational State Transfer, is another abstraction for creating API’s for applications in a standardized way. With typical, and now traditional, web applications, creating REST endpoints using HTTP is how the vast majority of applications are architected. Whether it’s Ruby, Java, Go, NodesJS or any of the multitude of technologies available, they are fundamentally similar in that they receive to Requests for information, and then Responding to the request.

REST organizes these Requests in predictable ways, using HTTP operation types, or verbs, to construct appropriate responses. Requests originate from the client, and the common HTTP verbs include GET, POST, PUT, DELETE but there are several others. They correspond to expected operations, retrieving data, submitting data, updating data, and deleting data.

REST is by far the most standardized way of structuring the API for Requests. But since it involves using HTTP is also has the overhead associated with that protocol. For most applications, information only needs to be transferred when a user takes an action. For instance, when browsing a news site, once the browser has requested the article, the user is busy reading it, and not taking actions. Having the port-socket close during this time is actually saving resources. With less frequent interaction, HTTP works very well, and it is why it is used.

For more real time interaction, or real time transfer or streaming of data, HTTP and REST aren’t the best suited protocol and abstraction combination. This is where Sockets and WebSockets shine.

WebSockets vs REST: A Comparison of Performance

The overhead of opening and closing connections is very real. The performance of being able to send and receive data and the number of concurrent devices that can do so is a significant consideration. The use of polling versus pushing is also a very real burden on servers.

REST Performance

Metaphorically, we could think of this as an army with a chain of command. Let’s make the server the General, and all the browsers the soldiers on the ground waiting for orders. Using HTTP/REST, if every soldier has to ask the General if there are any new orders, it burdens the General tremendously, particularly when there isn’t anything new. That means the General is saying “no, nothing new” most of the time.

If your servers are the General, their resources are being wasted mostly saying that there is nothing new. Furthermore, because the General can only answer so many soldiers at a time, it takes a long time to say “nothing new” to every soldier even once, there is a time delay where the last soldiers in line hear the “nothing new” far later than the first soldier who asked.

WebSockets Performance

Using the same metaphor, sockets being connected are like each soldier having a radio, and when the General has a new order, he can send that order into the radio and all the soldiers can receive it at the same time. It could be all the soldiers hear the same order, and, of course we can have different bands on the radio, and the General can speak order to particular groups listening on different bands.

The efficiency here is on both sides.

The General no longer needs to be burdened with unnecessary work, so you need fewer servers to service your clients. The clients also don’t need to waste networking and resources for polling and making requests. Far more efficient on both sides.