What are WebSockets?
What are WebSockets?
A WebSocket is a communication protocol that provides full-duplex communication channels over a single TCP connection. It enables real-time, event-driven communication between a client and a server.
Unlike traditional HTTP, which follows a request-response model, WebSockets allow bi-directional communication. This means that the client and the server can send data to each other anytime without continuous polling.
What are WebSockets Used For?
WebSockets are used for real-time, event-driven communication between clients and servers. They are particularly useful for building applications requiring instant updates, such as real-time chat, messaging, and multiplayer games.
In traditional HTTP, the client sends a request to the server, and the server responds with the requested data. This request-response model requires continuous polling from the client to the server, which can result in increased latency and decreased efficiency.
On the other hand, WebSockets establish a persistent connection between the client and the server. This means that once the connection is established, the client and the server can send data to each other at any time without continuous polling. This allows realtime communication, where updates can be sent and received instantly.
For example, when a user sends a message in a chat application, it can be instantly delivered to all other users without refreshing the page or making frequent HTTP requests. This results in a more seamless and efficient user experience.
Furthermore, Web Sockets also allow for bi-directional communication, meaning that both the client and the server can send data to each other. This opens up possibilities for more interactive and engaging applications, where the server can push updates or notifications to the client without the client explicitly requesting them.
Drawbacks of Web Sockets
The drawbacks of WebSockets include:
Browser Support: Although most modern browsers support WebSockets, some older ones do not. This can limit the reach of your application and require additional fallback mechanisms for older browsers.
Proxy and Firewall Limitations: Some proxy servers and firewalls may block or interfere with WebSocket connections. This can cause connectivity issues, especially in corporate or restricted network environments.
Scalability: Web Sockets maintain a persistent connection between the client and the server, which can strain server resources when dealing with many concurrent connections. Proper load balancing and resource management techniques must be implemented to ensure scalability. Open-source resources, like Socket.io, are not great for large-scale operations or quick growth.
Stateful Nature: Unlike traditional HTTP, which is stateless, WebSockets are stateful. This means that the server needs to maintain the connection state for each client, leading to increased memory usage and potential scalability challenges.
Security Considerations: With the persistent connection established by WebSockets, there is a need for proper security measures to protect against potential vulnerabilities, such as cross-site scripting (XSS) and cross-site request forgery (CSRF). Secure WebSocket connections (wss://) using SSL/TLS encryption should be implemented to ensure data privacy and integrity.
If a connection over Web Sockets is lost, there are no included load balancing or reconnecting mechanisms.
It is still necessary to have fallback options, like HTTP streaming or long polling, in environments where Web Sockets may not be supported.
Features like Presence do not work well over WebSocket connections because disconnections are hard to detect.
WebSockets vs. HTTP vs. web servers vs. polling
HTTP connections vs. WebSockets
To understand the WebSocket API, it is also important to understand the foundation it was built on – HTTP (Hypertext Transfer Protocol) and its request/response model. HTTP is an application layer protocol and the basis for all web-based communication and data transfers.
When using HTTP, clients—such as web browsers—send requests to servers, and then the servers send messages back, known as responses. The web as we know it today was built on this basic client-server cycle, although there have been many additions and updates to HTTP to make it more interactive. There are currently a few viable and supported versions of HTTP—HTTP/1.1 and HTTP/2—and a secure version known as HTTPS.
Basic HTTP requests work well for many use cases, such as when someone needs to search on a web page and receive relevant, non-time-sensitive information. However, it is not always best suited for web applications requiring real-time communication or data that needs to update quickly with minimal latency.
Whenever the client makes a new HTTP server request, the default behavior is to open a new HTTP connection. This is inefficient because it uses bandwidth on recurring non-payload data and increases latency between the data transfers.
Additionally, HTTP requests can only flow in one direction—from the client side. There is traditionally no mechanism for the server to initiate communication with the client. The server cannot send data to the client unless it requests it first. This can create issues for use cases where messaging needs to go out in real time from the server side.
Short polling vs. WebSockets
One of the first solutions for receiving regular data updates was HTTP polling. Polling is a technique where the client repeatedly sends requests to the server until it updates. For example, all modern web browsers offer support for XMLHttpRequest, one of the original methods of polling servers.
These earlier solutions were still not ideal for efficient real-time communication—short polling is intensive because, for every request, the non-payload data is re-sent and must be parsed, including the header HTML, the web URL, and other repetitive information that wastes resources.
Long polling vs. Web Sockets
The next logical step to improve latency was HTTP long polling. When long polling, the client polls the server, and that connection remains open until the server has new data. The server sends the response with the relevant information, and then the client immediately opens another request, holding again until the next update. Long polling can hold a connection open for a maximum of 280 seconds before automatically sending another request. This method effectively emulates an HTTP server push.
Long polling provides fast communication in many environments and is widely used, often as opposed to true push-based methods like WebSocket connections or Server Side Events (SSE). Long polling can seem intensive on the server side, as it requires continuous resources to hold a connection open, but it uses much less than repeatedly sending polling requests.
What are WebSockets used for?
Developers invented WebSockets to facilitate real-time results effectively. WebSockets initiate continuous, full-duplex communication between a client and WebSocket server. This reduces unnecessary network traffic, as data can immediately travel both ways through a single open connection. This provides speed and realtime capability on the web. Websockets also enable servers to keep track of clients and “push” data to them as needed, which was not possible using only HTTP.
WebSocket connections enable the streaming of text strings and binary data via messages. WebSocket messages include a frame, payload, and data portion. Very little non-payload data gets sent across the existing network connection this way, which helps to reduce latency and overhead, especially when compared to HTTP request and streaming models.
Google Chrome was the first browser to include standard support for WebSockets in 2009. RFC 6455—The WebSocket Protocol—was officially published online in 2011. The WebSocket Protocol and WebSocket API are standardized by the W3C and the IETF, and support across browsers is very common.
How do WebSockets work (and their connections)
Before a client and server exchange data, they must use the TCP (Transport Control Protocol) layer to establish the connection. Using their WebSocket protocol, webSockets effectively run as a transport layer over the TCP connection.
Once connected through an HTTP request/response pair, the clients can use an HTTP/1.1 upgrade header to switch their connection from HTTP to WebSockets. WebSocket connections are fully asynchronous, unlike HTTP/1.1, however. WebSocket connection is established through a WebSocket handshake over the TCP. During a new WebSocket handshake, the client and server also communicate which subprotocol will be used for subsequent interactions. After this is established, the connection will run on the WebSocket protocol.
It is important to note that when running on the WebSocket protocol layer, WebSockets require a uniform resource identifier (URI) to use a “ws:” or “wss:” scheme, similar to how HTTP URLs will always use a “http:” or “https:” scheme.
What libraries are available for implementing WebSockets?
Several libraries can provide the necessary tools and functionalities when implementing WebSockets in your realtime chat and messaging applications. These libraries offer a wide range of features and support for different programming languages, making it easier for developers to integrate WebSockets into their applications. Here are some of the popular libraries that you can consider:
4. ws: ws is a simple and lightweight WebSocket implementation for Node.js. It provides a straightforward API for creating WebSocket servers and clients, making it easy to integrate websockets into your Node.js applications. ws offers per-message compression, automatic reconnection, and customizable options for handling incoming and outgoing messages.
5. Django Channels: Django Channels is a library that extends the capabilities of the Django web framework to handle real-time applications. It supports websockets and other protocols like HTTP long-polling and Server-Sent Events. Django Channels allows you to build real-time chat and messaging applications using the familiar Django syntax and tools.
Reasons to consider WebSockets for real-time communication
Websockets provide real-time updates and open lines of communication.
Websockets are HTML5 compliant and offer backward compatibility with older HTML documents. Therefore, all modern web browsers—Google Chrome, Mozilla Firefox, Apple Safari, and more- support them.
WebSockets are compatible across Android, iOS, web, and desktop platforms.
A single server can have multiple WebSocket connections open simultaneously and multiple connections with the same client, which opens the door for scalability.
WebSockets can stream through many proxies and firewalls.
PubNub’s Take on WebSockets vs. Long Polling
PubNub takes a protocol-agnostic stance, but in our current operations, we have found that long polling is the best bet for most use cases. This is partly because of the maintenance and upkeep required to scale WebSockets on the backend and potential issues that can arise when you can not easily identify a disconnection. WebSockets are a great tool, but long polling works reliably in every situation.
PubNub uses long polling to ensure reliability, security, and scalability in all networking environments, not just most. Long polling can be as efficient as WebSockets in many real-world, real-time implementations. We have developed a method for efficient long polling – written in C and with multiple kernel optimizations for scale.
PubNub is a real-time communications platform that provides the foundation for authentic virtual experiences, like live updates, in-app chat, push notifications, and more. The building block structure of our platform allows for extra features like Presence, operational dashboards, or geolocation to be incorporated. PubNub also makes it extremely easy to scale, especially compared to socket frameworks like Socket.io or SocksJS.
To conclude, WebSockets are a very useful protocol for building real-time functionality across web, mobile, and desktop variants, but they are not a one-size-fits-all approach. WebSockets are just one tool that fits into a larger arsenal when developing real-time, communication-based applications that require low latency. It is possible to build off of basic WebSocket protocol, incorporate other methods like SSE or long polling, and construct an even better, more scalable real-time application. The problem is that when you use WebSockets, the shortcomings can be difficult to manage if you are not an expert in building real-time systems.
Using PubNub provides a better user experience, saves significant development time and maintenance costs, speeds up time to market, and reduces the complexity of what your engineering and web development team will need to develop, manage, and grow.
With over 15 points of presence worldwide supporting 800 million monthly active users and 99.999% reliability, you’ll never have to worry about outages, concurrency limits, or any latency issues caused by traffic spikes. PubNub is perfect for any application that requires real-time data.
Sign up for a free trial and get up to 200 MAUs or 1M total transactions per month included.