#WebSockets: Part 2 WebSockets Interview Questions in Java

In Part 1, we discussed some basic Socket programming interview questions. In part 2 we will discuss WebSockets.

What is WebSocket?

• WebSocket is a thin, lightweight layer above TCP, which is used to create a communication channel between a client and a server.
• It provides efficient communication between the server and the web browser by providing bi-directional, full-duplex, real-time client and server communications. The server and client can send data to each other at any time.
• Since the WebSocket runs over TCP, it also provides a low-latency, low-level communication, and reduces the overhead of each message.
  WebSockets are typically designed to be implemented in web browsers and web servers, however, they can be used in any application where real-time communication is needed.

What are the drawbacks of Web Sockets?

• Limited Browser Support: While modern browsers widely support Web Sockets, there may be scenarios where you have to deal with legacy systems or environments where WebSocket support is limited or disabled. In such cases, you might need to provide fallback mechanisms or consider alternative communication technologies. In my case, a few of the clients were using Internet Explorer 10 and earlier versions, which do not support WebSockets. While most of them were using Internet Explorer 11, which is a later version, added support for WebSockets. That’s why based on the WebSocket support, in the backend we added a fallback code.
• Firewall and Proxy Issues: Some network configurations, firewalls, and proxy servers may not support WebSocket connections, leading to communication issues. Our client environment had some restrictions, to resolve this administrators explicitly enabled WebSocket traffic.
• Scalability: Web Sockets maintain a persistent connection between the client and the server, which can have implications for server and network resources. Servers need to manage open connections, and network infrastructure needs to handle long-lived connections effectively. Proper load balancing and resource management techniques must be implemented to ensure scalability. This may require additional server-side resources and configurations.
• No Built-in Broadcasting: The Web Sockets allow point-to-point communication, which means they do not inherently support broadcasting messages to multiple clients. Implementing a broadcasting mechanism typically involves maintaining a list of connected clients on the server and iterating through them to send messages individually. I faced this issue while replacing Java Sockets with WebSockets because in my case the server periodically broadcasts some message to all the connected clients.
• No Built-in Message Acknowledgments: Web Sockets do not inherently provide built-in acknowledgement mechanisms. The message delivery acknowledgement is crucial for our application, which is why we implemented a custom solution on top of Web Sockets.
• Resource Exhaustion: If you keep a large number of open WebSocket connections it can potentially exhaust system resources, such as file descriptors or memory, on the server. To prevent resource-related issues proper connection management and resource monitoring are important.
• Security Considerations: Web Sockets introduce new security considerations, especially when dealing with cross-origin communication. Proper security measures, such as enforcing secure connections (WSS) and implementing authentication and authorization mechanisms, are crucial.

How do WebSockets differ from traditional HTTP communication?

• The traditional HTTP follows a request-response model, the client makes a request, and after the server sends its response, the connection is closed. In future, if the client needs more data, they have to open a new connection. FYI, we can reuse the TCP/IP connection with HTTP/1.1.
• In the case of WebSocket, the client can open and use a single connection for all their WebSocket communications with the server. Both the client and server can send and receive data simultaneously/independently over a long-lived connection. This long-lived persistent connection allows for low-latency, bidirectional messages. The server can push real-time updates as soon as they become available without waiting for the client to issue a request.
• In the case of HTTP, the connection is stateless. This means that every HTTP request the server receives is independent and does not relate to requests that came before it. Because of the persistent connection, the WebSocket is stateful.

How are WebSocket connections established?Explain the WebSocket handshake process.
The WebSocket handshake involves an HTTP upgrade request from the client and an acceptance response from the server. Once the handshake is complete, the communication switches to the WebSocket protocol.

• HTTP Upgrade Request: The client initiates the handshake by sending an HTTP upgrade request to the server. This is an indication of the client’s intention to switch to the WebSocket protocol.
• Server Response: When the server receives the upgrade request, it responds with an HTTP 101 status code, indicating a successful upgrade to the WebSocket protocol.
• Headers and Key Generation: During the handshake, both the client and server exchange headers containing the information required for establishing the WebSocket connection. The client generates a random key, which is combined with a predefined Websocket GUID and then base64-encoded.
• Verification and Acceptance: The received key is verified by the server. The server then constructs a response key by concatenating the client key with the GUID and then base64-encoded it. If the server accepts the client’s request, it includes the response key in the response headers.
• Connection Establishment: After the client receives the server’s response, it verifies the response key to ensure the connection is established with the correct server. If the verification is successful, the WebSocket connection is considered open and ready for bidirectional communication.

The key headers involved include Upgrade, Connection, Sec-WebSocket-Key, and Sec-WebSocket-Accept.

Explain the purpose of the Sec-WebSocket-Protocol header in the WebSocket handshake.
The Sec-WebSocket-Protocol header is part of the WebSocket protocol’s handshake process and is used to negotiate and establish a subprotocol between the client and the server.

During the handshake, the client would ask the server what kind of subprotocols are supported by sending Sec-WebSocket-Protocol header. The client can specify one or more WebSocket protocols that you wish to use, in order of preference. The first one that is supported by the server will be selected and returned by the server in a Sec-WebSocket-Protocol header included in the response.

We can use this more than once in the header, as well; the result is the same as if you used a comma-delineated list of subprotocol identifiers in a single header.

#WebSockets: Tutorial

• Part 1: Socket Programming Interview Questions in Java
• Part 2: WebSockets Interview Questions in Java
• Part 3: Key components of the Java WebSocket API

Did you know you could give up to 50 claps?
Yes, 50 claps, isn’t it awesome? If you feel my posts are interesting or helpful to you, please press the 👏 clap button and share/ follow, and help others find this story too. Also, feel free to leave a comment below.

If you enjoyed reading my blogs, I’d appreciate it if you’d buy me a coffee☕

Keep learning and growing!
- Himanshu Shukla..