Today we decided to tell you about one of these technologies - the WebSocket protocol. We will explain how it works and its advantages in simple examples.
How did the Internet work before WebSocket?
Before the WebSocket advent, the client (browser) had to send a request to get new information from the server, and the server sent a response. Without the request, there was no response. That is, no page update - the server could not send anything itself. This model is still working on the web but in fewer quantities.
For example, the user received a message on the website. For the client (browser) to know about it, it had to poll the server at some intervals to see if there was any new data.
There was another option. Browsers found out about the new data only when users interacted with the website: when they navigated to other pages, manually refreshed a tab, or re-opened the website.
There were disadvantages to this approach:
- Superfluous network load. The client (browser) had to constantly send requests to the server, even if there was no new information.
- The overhead of establishing a new connection with each request/response. This also consumed some time. Going forward, we note that the connection is established once and kept open in WebSocket, so there is no additional overhead.
- Low data update rate. The client (browser) couldn't get the data as soon as it appeared on the server. New data reached the browser only after the server had received the request. If it was important to get the data as soon as possible, the browser could contact the server more frequently, for example, once every 0.5 seconds. However, this placed an additional load on the network and the server, which had to conduct and process many requests.
On the other hand, WebSockets allow for an always-on connection so that the server can send new data to the client without waiting for a request. This interactivity eliminates the above disadvantages. To see the benefits of WebSocket, let's compare it with HTTP.
How does WebSocket differ from HTTP?
Before the advent of Web Sockets, the primary protocol was and still remains HTTP. The HTTP protocol is unidirectional. After the request-response cycle, the connection is closed. Any subsequent request establishes a new connection to the server: as many requests as there are connections. It wasn't a problem for static content like an informational article on a website. But you need to refresh the page manually to find out about changes in interactive content (such as a new message in an online chat, comments, or push notifications).
The data transfer process is also somewhat delayed. This is due to the overhead of establishing a new connection for each request/response, as well as the network and server load due to the abundance of periodic requests.
Pure HTTP protocol is used less now as HTTPS replaced it. It's not a standalone protocol but an add-on to HTTP that allows you to encrypt your data.
The first version of the WebSocket protocol appeared in 2009. Already in 2011, it received RFC (Request for Comments) status. It was recognized as a standard widely used on the World Wide Web. Today, WebSocket technology is used in all mobile, desktop, and server devices.
The WebSocket protocol is bidirectional, full-duplex, meaning it can both receive and transmit information. A WebSocket does this many times over a single open connection. This connection also has a higher speed than HTTP.
Web sockets also have the ability to encrypt data in transit. This is done using the WSS protocol. If transmitted data is not encrypted, it becomes an object of attraction for such threats as unauthorized access to the client by third parties or the use of malware. Special add-on data transfer protocols encrypt information on the sending side and decrypt it on the receiving side, leaving it encrypted for any intermediaries. This adds a secure transport layer.
To illustrate the differences between HTTP and WebSocket, let's take a chat room example. For users to receive new messages, the browser would periodically ask the server if there were new messages for the user. Each such request would establish a new connection and cause unnecessary network load.
How does WebSocket work?
On the Internet, there are strict rules for transferring data between client and server (TCP/IP protocol stack), but there are no strict rules on establishing a connection and structuring the message transmitted. And this affects speed.
To establish a connection, WebSocket uses the open handshake method. The client precedes the sending/receiving of messages with a preliminary request, in which the client and the server "agree" to use web sockets. This is the "handshake". The structure of such a request is similar but slightly different from HTTP. The client and server then exchange data within that connection.
Web sockets also have additional extensions that supplement and extend the protocol. For example, there is an extension for data compression. Or the ability to transfer data in SOAP, WAMP, or XMPP protocols. For these extensions to work, they need to be supported by both the server and the client.
Advantages and disadvantages of using WebSocket
Advantages of WebSocket:
- Standardization of solutions, which makes it easier to develop cross-platform applications
- Unlimited lifetime of the connection; It does not need to be refreshed periodically
- Multiple sessions open at the same time
- Fast transfer of dynamically updated data without overloading the network and server
Disadvantages of WebSocket:
- Increased server hardware requirements.
- Connection rejection without notifications. Sometimes it is necessary to introduce additional communication mechanisms between the client and the server to understand whether the client is responding.
- Changing the network by the client. The server will not receive information about the address change if the client does not close the connection when reconnecting to another network.
WebSocket is a convenient technology for transmitting dynamically updated data. Its implementation allows developers to reduce the network and server hardware load and accelerate the website's work.
When to use and when not to use WebSocket
WebSocket is suitable when you need real-time data updates and the ability to deliver messages to the client. Here are a few examples of projects where WebSocket should be used:
- Trading applications with volatile quotes or real-time prices: sales platforms, exchanges
- Gaming applications
- Chats
- Push notifications
- Social media
- Device management in the IoT (using the WAMP sub-protocol)
- Online games, especially multiplayer
- Collaborative web applications
- Online auctions and bidding platforms
- Live streaming
When you need immutable data that is retrieved only once to be processed by an application, it's better to use the HTTP protocol rather than WebSocket. This could be, for example, an article page. Once published, the article changes very little, so there is no point in using a persistent connection to display it.
Also, the HTTP protocol is preferable if we don't want to keep a connection for a certain time or to reuse a single connection to transmit data. These are, for example, situations where the server has to give all the data for a form in one response.
WebSocket vs. REST
WebSockets and Representational State Transfer (REST) are both protocols used in web applications, but they have different characteristics and use cases. Let's discuss them:
- Communication model. WebSockets provide a full-duplex, bidirectional communication channel between a client and a server, allowing real-time communication in both directions. Conversely, REST follows a client-server model where the client sends requests to the server, and the server responds with the requested data. REST is typically based on the request-response pattern, while WebSockets enable continuous communication without the need for repeated requests.
- Real-time communication. WebSockets are ideal for real-time applications where immediate updates and real-time data exchange are required, such as chat applications, gaming, or live streaming. On the other hand, REST is typically used for request-response scenarios where the client requests data from the server and receives a response, which may not be real-time.
- Scalability. WebSockets can be more scalable in certain scenarios due to their ability to maintain persistent connections and push updates to clients without the need for repeated requests. On the other hand, REST may require multiple requests from clients to get updates, which can result in increased overhead and reduced scalability.
- Protocol overhead. WebSockets have lower protocol overhead than REST, as they use a single connection that remains open for the duration of the session, reducing the need for repeated handshakes and headers. REST, on the other hand, requires separate HTTP requests and responses for each communication, which can result in higher overhead in terms of bandwidth and latency.
- Caching and caching mechanisms. REST relies on standard HTTP caching mechanisms, such as ETag and Last-Modified headers, which can be used for caching responses and improving performance. WebSockets do not have built-in caching mechanisms, as they are designed for real-time, dynamic communication.
- State management. REST is stateless, meaning that each request from a client must contain all the necessary information for the server to understand and process the request. WebSockets, on the other hand, maintain a persistent connection and can maintain stateful communication between the client and the server, allowing for more complex interactions and workflows.
- Client compatibility. REST APIs can be accessed from various clients, including web browsers, mobile apps, and other servers, using standard HTTP methods. On the other hand, WebSockets require client-side support for the WebSocket protocol, which may not be available in all clients or require additional implementation effort.
- Security. Both REST and WebSockets can be secured using encryption protocols such as HTTPS and WSS (WebSocket Secure) to ensure secure communication between the client and the server. REST relies on standard HTTP security mechanisms. At the same time, WebSockets have their own security considerations, such as preventing cross-site scripting (XSS) and cross-site request forgery (CSRF) attacks on WebSocket connections.
So, WebSockets are well-suited for real-time applications that require continuous communication and low-latency updates. At the same time, REST is typically used for request-response scenarios and may be more suitable for applications that require caching, statelessness, and wide client compatibility. The choice between WebSockets and REST depends on the specific requirements of the application and the nature of the communication needed.
MaybeWorks - a reliable IT staff augmentation provider with skilled WebSockets developers
One of the last projects where our developers assisted in project development using WebSocket was a Zoom-like application that allows users to create rooms and have video calls with their friends/partners. The critical difference was that this project was more aimed at small and thematic groups who wanted to play some built-in games or just have fun talking to each other.
This client hired 2 MaybeWorks full-stack developers for his small team to assist in building the project. They:
- Developed the video chat based on the WebRTC using Twilio API
- Implemented Node JS of our API and socket server
- Rewrote the whole app on TypeScript
- Transferred all the data from MongoDB to PostgreSQL
Our developers worked with Typescript, NodeJS, Express, and WebSockets in the backend. They also worked with React and Twilio WebRTC API in the frontend.
As an IT staff augmentation provider, we allowed our client to get the required experts for Zoom-like app development quickly and effortlessly. Feel free to contact us right now!
Share
