The WebSocket technology has broad applicability.

You can use it for different purposes, such as

streaming data between backend services, or connecting a backend with a frontend via long-
lasting, full-duplex connections. In a nutshell, WebSocket’s are an excellent choice for
architecting event-driven systems and building real-time apps and services where it’s essential
for data to be delivered immediately.

We can broadly group WebSocket use cases into two distinct categories:
 Realtime updates, where the communication is unidirectional, and the server is streaming
low-latency (and often frequent) updates to the client. Think of live sports updates, alerts,
real-time dashboards, or location tracking, to name just a few use cases.
 Bidirectional communication, where both the client and the server can send and receive
messages. Examples include chat, virtual events, and virtual classrooms (the last two
usually involve features like polls, quizzes, and Q&As). WebSockets can also be used to
underpin multi-user synchronized collaboration functionality, such as multiple people
editing the same document simultaneously.

And here are some of the main benefits of using WebSocket’s:

 Improved performance. Compared to HTTP, WebSocket’s eliminate the need for a new
connection with every request, drastically reducing the size of each message (no HTTP
headers). This helps save bandwidth, improves latency, and makes WebSocket’s more
scalable than HTTP (note that scaling WebSocket’s is far from trivial, but at scale,
WebSocket’s are significantly less taxing on the server-side).
 Extensibility. Flexibility is ingrained into the design of the WebSocket technology, which
allows for the implementation of subprotocols (application-level protocols) and
extensions for additional functionality. Learn more about Extensions and Subprotocols.
 Fast reaction times. As an event-driven technology, WebSocket’s allow data to be
transferred without the client requesting it. This characteristic is desirable in scenarios
where the client needs to react quickly to an event (especially ones it cannot predict, such
as a fraud alert).

A request/response protocol by design, HTTP doesn’t support bidirectional, always on, real-time
communication between client and server over the same connection. You can create the illusion
of bidirectional real-time communication by using two HTTP connections. However, the
maintenance of these two connections introduces significant overhead on the server, because it
takes double the resources to serve a single client.
With the web continuously evolving, and user expectations of rich, real-time web-based
experiences growing, it was becoming increasingly obvious that an alternative to HTTP was
needed.
The WebSocket technology includes two core building blocks:
 The WebSocket protocol. Enables communication between clients and servers over the
web, and supports transmission of binary data and text strings.
 The WebSocket API. Allows you to perform necessary actions, like managing the
WebSocket connection, sending and receiving messages, and listening for events
triggered by the server.
HTTP and WebSocket’s are designed for different use cases. For example, HTTP is a good
choice if your app relies heavily on CRUD operations, and there’s no need for the user to react to
changes quickly. On the other hand, when it comes to scalable, low-latency real-time
applications, WebSocket’s are the way to go.

The WebSocket technology has broad applicability. You can use it for different purposes, such as
streaming data between backend services, or connecting a backend with a frontend via long-
lasting, full-duplex connections.

The WebSocket API enables event-driven communication over a persistent connection. This
allows you to build web apps that are truly real-time and less resource-intensive on both the
client and the server compared to HTTP techniques.

A WebSocket server can be written in any server-side programming language that is capable of
Berkeley sockets. The server listens for incoming WebSocket connections using a standard TCP
socket. Once the opening handshake has been negotiated, the server must be able to send, receive
and process WebSocket messages.

The goal of the WebSocket is to provide a mechanism for browser-based applications that need a
two-way communication with servers that does not rely on opening multiple HTTP connections.
This technique is particularly useful in situations where low-latency or serverinitiated messages
are required, and it can be adopted for a variety of Web applications, such as multiplayer games,
stock tickers, shared document editing, instant messaging, real-time analytics, push notifications,
et cetera. Basically, the protocol works as follow: once the client and server have both sent their
handshakes, and the procedure was successful, then the data transfer part starts. The method
results in a two-way communication channel where each side can, independently from the other,
send data at will. After a successful handshake, clients and servers transfer data back and forth in
conceptual units referred to in the WebSocket specification as” messages”. On the wire, a
message is composed of one or more frames. The WebSocket message does not necessarily
correspond to a particular network layer framing, as a fragmented message may be coalesced or
split by an intermediary.

WebSocket connections are typically long-lived as they normally stay open and idle until either the client
or the server is ready to send a message. Supposing a WebSocket server is properly configured and
listening for incoming connections, a WebSocket client can normally use client-side JavaScript to create a
connection to the server, as follows: let ws = new WebSocket("wss://my-website.com/chat"); The
connection is established by the client and the server performing a WebSocket handshake over HTTP.