An Introduction to WebSockets for Building Real-time Applications

The WebSocket is a type of network protocol that has allowed for improved full-duplex communication over the web, where a server and client can communicate in both directions simultaneously. Ever since its creation, developers can leverage this protocols’ versatility in building real-time web applications. Before we dive in on what WebSockets are and its implementation, we’ll go over a brief history of older architectures such as those that utilize HTTP.

A Brief Overview of the HTTP Architecture

The backbone of the web was built upon the HTTP protocol where a client (usually a web browser) sends a request over to the server on an open connection, and then receives a response from the server with the requested resource such as an HTML page.

In HTTP 1.0, new connections had to be established for every request from the client. And in HTTP 1.1, connections were made reusable to retrieve different resources such as images, scripts, and so on. However, both versions had some major drawbacks:

HTTP stems from a half-duplex system, where traffic is unidirectional.
It was designed for resource sharing and not the interactive applications we are accustomed to today on the web.
The amount of information (e.g. in the request header) needed for communication between the client and server via this protocol adds up quickly relative to the number of interactions.

Given these restrictions, engineers started looking for ways to emulate real-time back-and-forth communication between the web page and the server. The most common of these methods was known as long polling.

Long polling is a type of persistent communication method where the server remains open on an established connection to deliver a response to its client until it reaches the end of its designated timeout.

The server holds the request open until new data is available. Once available, the server responds and sends the new information. When the client receives the new information, it immediately sends another request, and the operation is repeated. In essence, this mechanism allows the server to send responses to the client without the client first making a request.

Long polling is also known as Comet or Reverse Ajax which delays the completion of the HTTP response until the server has something to send to the client, a technique called a hanging-GET or pending-POST. All in all, this “almost-real-time communication” was found tricky to do and have limitations such as:

It involves HTTP request and response headers, which contain lots of additional and unnecessary header data and latency.
It lacks performance improvements as the client must constantly reconnect to the server to fetch new information, resulting in a network behavior equivalent to rapid polling.

A New World, WebSockets!

To eliminate these inefficiencies, Michael Carter and Ian Hickson collaborated on IRC to create a new standard for modern real-time, bi-directional communication on the web, also know as WebSockets.

The WebSocket protocol enables interaction between a client and a server with lower overhead than half-duplex alternatives such as HTTP long polling, facilitating real-time data transfer from and to the server. It also reduces latency because once the WebSocket connection is established, the server can send messages as they become available.

Some of the reasons why we need WebSockets are:

It improves performance, saves bandwidth, CPU power, and latency
It allows for a simplified version vs the older architectures
Other network protocols can be built on top of it
It provides enhanced capabilities to HTML5

So How Does One Implement WebSocket?

The client establishes a WebSocket connection through a process known as the WebSocket handshake. The browser (client) sends a request to the server, indicating that it wants to switch protocols from HTTP to WebSocket. The client then expresses its desire through the Upgrade header:

GET ws://websocket.example.com/ HTTP/1.1
Origin: http://example.com
Connection: Upgrade
Host: websocket.example.com
Upgrade: websocket

The Upgrade header indicates that the client would like to upgrade the connection to a different protocol. In this case, the different protocol is WebSocket.

If the server understands the WebSocket protocol, it agrees to the protocol switch through the Upgrade header.

HTTP/1.1 101 WebSocket Protocol Handshake
Date: Wed, 16 Oct 2013 10:07:34 GMT
Connection: Upgrade
Upgrade: WebSocket

After the handshake is complete, the initial HTTP connection is replaced by a WebSocket connection that uses the same underlying TCP/IP connection. At this point, either party can start sending data.

“Data is transferred through a WebSocket as messages, each of which consists of one or more frames containing the data you are sending (the payload). In order to ensure the message can be properly reconstructed when it reaches the client each frame is prefixed with 4–12 bytes of data about the payload. Using this frame-based messaging system helps to reduce the amount of non-payload data that is transferred, leading to significant reductions in latency.” — Matt West.

You can learn how to use and create a WebSocket connection here.

Popular WebSocket Libraries

Most WS libraries are open source and usually fall in two classes: those that implement the protocol and leave the rest to the developer, and those that build on top of the protocol with various additional features commonly required by real-time messaging applications.

ws is a “simple to use, blazing fast and thoroughly tested WebSocket client and server for Node.js”

Usage example:

Sending and receiving text data

const WebSocket = require('ws');

const ws = new WebSocket('ws://www.host.com/path');

ws.on('open', function open() {
  ws.send('something');
});

ws.on('message', function incoming(data) {
  console.log(data);
});

Simple server

const WebSocket = require('ws');

const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', function connection(ws) {
  ws.on('message', function incoming(message) {
    console.log('received: %s', message);
  });

  ws.send('something');
});

Socket.io

Socket has been said to be the jQuery of WebSockets. It uses both long polling and WebSockets for its transport protocol, by default starting with long polling and then upgrading to WebSockets if available.

Client (index.html)

<script src="/socket.io/socket.io.js"></script>
<script>
  const socket = io('http://localhost');
  socket.on('news', (data) => {
    console.log(data);
    socket.emit('my other event', { my: 'data' });
  });
</script>

Server (app.js)

const app = require('http').createServer(handler)
const io = require('socket.io')(app);
const fs = require('fs');

app.listen(80);

function handler (req, res) {
  fs.readFile(__dirname + '/index.html',
  (err, data) => {
    if (err) {
      res.writeHead(500);
      return res.end('Error loading index.html');
    }

    res.writeHead(200);
    res.end(data);
  });
}

io.on('connection', (socket) => {
  socket.emit('news', { hello: 'world' });
  socket.on('my other event', (data) => {
    console.log(data);
  });
});