WebSockets Not In A Nutshell

Usama Ahmed
Mar 6 · 6 min read

Normally when a browser visits a web page, an HTTP request is sent to the web server that hosts that page. The web server acknowledges this request and sends back the response.

In many cases, for example, for stock prices, news reports, ticket sales, and so on, the response could be stale by the time the browser renders the page.

If you want to get the most up-to-date “real-time” information, you can constantly refresh that page manually, but that’s obviously not a great solution.


Around 2005, with AJAX, the web browser could tell the server, “Hey, I would like to update this section of the web page.” Things sped up a little bit, but it was still the web browser requesting something from the web server.

Based on AJAX, a lot of technologies was built, They all depended on javascript without creating new protocol using HTTP (simulation).

  • Polling
  • Long Polling
  • Streaming/forever response
  • Multiple connections

And each technique solves a problem was found in the previous one.

Polling “keep asking”

  • The browser sends HTTP requests at regular intervals and immediately receives a response.
  • The server always Immediately responds with or without data.


  • This is a good solution if the exact interval of message delivery is known because you can synchronize the client request to occur only when information is available on the server. However, real-time data is often not that predictable, making unnecessary requests inevitable and, as a result, many connections are opened and closed needlessly in low-message-rate situations.
  • Obvious waste (CPU and bandwidth) when there is no data.


 Web Browser: I'm going to keep this line open in case you have 
somestuff to send me.
Web Server: Okay. Check on me.
Web Browser: You got anything yet?
Web Server: No.
Web Browser: You got anything yet?
Web Server: No
Web Browser: You got anything yet?
Web Server: Yep, here it is.

Long Polling

To solve CPU and bandwidth waste in polling, The browser sends a request to the server and the server keeps the request open for a set period. If a notification is received within that period, a response containing the message is sent to the client. If a notification is not received within the set time period, the server sends a response to terminate the open request.

Animation of a Long Polling connection being established
  • The browser sends an initial request.
  • The server waits until it has data to respond.
  • The browser receives a response and immediately creates a new request (loop)
(function poll() {
setTimeout(function () {
url: 'https://api.example.com/endpoint/',
success: function (data) {
//Do something with 'data'

//Setup the next poll recursivly
datatype: 'json'
  • Each request/response creates and closes a connection
  • When you have a high message volume, long-polling does not provide any substantial performance improvements over traditional polling.
bullshit loading please wait!


To solve the open/close connection issue in long polling.

The browser sends a complete request, but the server sends and maintains an open response that is continuously updated and kept open indefinitely (or for a set period of time).

The response is then updated whenever a message is ready to be sent, but the server never signals to complete the response, thus keeping the connection open to deliver future messages.

However, since streaming is still encapsulated in HTTP, intervening firewalls and proxy servers may choose to buffer the response, increasing the latency of the message delivery.

Therefore, many streaming Comet solutions fall back to long-polling in case a buffering proxy server is detected. Alternatively, TLS (SSL) connections can be used to shield the response from being buffered, but in that case the setup and tear down of each connection taxes the available server resources more heavily.

stream connection


  • The client sends an initial request.
  • The server waits until it has data to respond.
  • The server responds with streaming data.
  • Connection is maintained


  • Has problems with proxies.
  • It’s half-duplex (will talk about it)
The server keeps the connection opened

This was server-side push techniques and the browser couldn't send anything to the server in the connection

Multiple Connections

  • Long polling over two separate HTTP connections, one for the upstream, for example, uber client current coordinates, and one for the downstream, for example, receiving uber driver current coordinates.


  • Two connections are used for every client.
  • Non-trivial connection coordination and management

Hidden cost of mentioned HTTP technique

  • TCB handshake when establishing a new connection (even worse in SSL).
  • HTTP headers on every message.
For small messages, you may end pushing around more HTTP headers than data!

“Reducing kilobytes of data to 2 bytes…and reducing latency from 150ms to 50ms is far more than marginal. In fact, these two factors alone are enough to make WebSocket seriously interesting to Google.”

— Ian Hickson (Google, HTML5 spec lead)

Connection modes


  • A simplex communication channel only sends information in one direction. For example, a radio station usually sends signals to the audience but never receives signals from them,

Half duplex

  • In half-duplex mode, data can be transmitted in both directions on a signal carrier except not at the same time. At a certain point, it is actually a simplex channel whose transmission direction can be switched.
Half duplex
  • The walkie-talkie is a typical half-duplex device. It has a “push-to-talk” button which can be used to turn on the transmitter but turn off the receiver. Therefore, once you push the button, you cannot hear the person you are talking to but your partner can hear you. An advantage of half-duplex is that the single track is cheaper than the double tracks.

Full duplex

  • Refers to the transmission of data in two directions in one connection.
Full duplex
how the internet works

There is a better way regardless this shit, it’s HTML5 Websockets

  • Full duplex
  • Single long-running connection
  • Connection upgraded from HTTP
  • Efficient use of bandwidth and CPU

To establish a WebSocket connection, the client sends a WebSocket handshake request, for which the server returns a WebSocket handshake response, as shown in the example below.

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

Server response:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

Once the web socket is established

  • Both sides notified that the socket is open.
  • Frames are transferred back and forth.
  • Either side can send messages at any time.
  • Either side can close the socket.
chrome developer tools from tree house

It’s important to note that WebSockets convert their HTTP connection to a WebSocket connection. In other words, a WebSocket connection uses HTTP only to do the initial handshake (for authorization and authentification), after which the TCP connection is utilized to send data via the its own protocol

WebSocket is not supported in all browser since they are periodically released, and socket.io work as a coordinator between mentioned technique (long polling, streaming.. etc ) based on browser compatibility.

Some photos are taken from https://blog.stanko.io/do-you-really-need-websockets-343aed40aa9b

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade