16 WebSockets Interview Questions Web Devs Must Know

WebSocket is a technology that allows a client to establish two-way full-duplex communication with the server.

The key word in that definition is two-way: with WebSocket, both the client and the server can trigger communication with one another, and both can send messages, at the same time. By a contrast In a traditional HTTP system communication can only be initiated in one direction: from the client to the server.

Alongside with short and long polling, SSE is a technique for sending messages is the Server-Sent Events API, which allows the server to push updates to the client by leveraging the JavaScript EventSource. EventSource opens a persistent, one-directional connection with the server over HTTP using a special text/event-stream header and listens for messages, which are treated like JavaScript events by your code.

Server-Sent Events (SSE) are great for apps where you don’t need to send the server any data—for example, a Twitter-style news feed or a real-time dashboard of stock quotes. Another pro is that Server-Sent Events work over HTTP and the API is relatively easy to use.

However:

• SSE is not supported by older browsers,
• most browsers limit the number of SSE connections you can make at the same time.

Low latency means that there is very little delay between the time you request something and the time you get a response. As it applies to webSockets, it just means that data can be sent quicker (particularly over slow links) because the connection has already been established so no extra packet roundtrips are required to establish the TCP connection.

Short Polling or Ajax Polling is a technique when we have the client ping the server repeatedly, say, every 500ms (or over some fixed delay). That way, you get new data every 500ms:

1. client requests a webpage from a server using regular HTTP.
2. The client receives the requested webpage and executes the JavaScript on the page which requests a file from the server at regular intervals (e.g. 0.5 seconds).
3. The server calculates each response and sends it back, just like normal HTTP traffic.

There are a few obvious downsides to this:

• there’s a 500ms delay,
• it consumes server resources with a barrage of requests, and most requests will return empty if the data isn’t frequently updated.

A WebSocket is a continuous connection between client and server. That continuous connection allows the following:

1. Data can be sent from server to client at any time, without the client even requesting it. This is often called server-push and is very valuable for applications where the client needs to know fairly quickly when something happens on the server (like a new chat messages has been received or a new price has been udpated). A client cannot be pushed data over http. The client would have to regularly poll by making an http request every few seconds in order to get timely new data. Client polling is not efficient.

2. Data can be sent either way very efficiently. Because the connection is already established and a webSocket data frame is very efficiently organized, one can send data a lot more efficiently that via an HTTP request that necessarily contains headers, cookies, etc...

Socket.io is a library which enables real-time and full duplex communication between the Client and the Web servers.

• It helps in broadcasting to multiple sockets at a time and handles the connection transparently.
• It works on all platform, server or device ensuring the equality, reliability, and speed.
• It automatically upgrades the requirement to WebSocket if needed.
• It is a custom real-time transport protocol implementation on top of other protocols.
• It requires both libraries to be used Client side as well as a server-side library.
• IO works on work-based events. there are some reserved events which can be accessed using the Socket on server side like Connect, message, Disconnect, Ping and Reconnect.
• There are some Client based reserved events like Connect, connect- error, connect-timeout and Reconnect etc.

Using Long polling (or Ajax Long Polling) method the server receives a request, but doesn’t respond to it until it gets new data from another request.

Long polling is more efficient than pinging the server repeatedly since it saves the hassle of parsing request headers, querying for new data, and sending often-empty responses.

However

• the server must now keep track of multiple requests and their order,
• requests can time out, and new requests need to be issued periodically.

Steps:

1. A client requests a webpage from a server using regular HTTP (see HTTP above).
2. The client receives the requested webpage and executes the JavaScript on the page which requests a file from the server.
3. The server does not immediately respond with the requested information but waits until there's new information available.
4. When there's new information available, the server responds with the new information.
5. The client receives the new information and immediately sends another request to the server, re-starting the process.

Advantages of SSE over Websockets:

• Transported over simple HTTP instead of a custom protocol
• Can be poly-filled with javascript to "backport" SSE to browsers that do not support it yet.
• Built in support for re-connection and event-id
• Simpler protocol
• No trouble with corporate firewalls doing packet inspection

Ideal use cases of SSE:

• Stock ticker streaming
• twitter feed updating
• Notifications to browser

• AJAX - request → response. Creates a connection to the server, sends request headers with optional data, gets a response from the server, and closes the connection. Supported in all major browsers.

• Long poll - request → wait → response. Creates a connection to the server like AJAX does, but maintains a keep-alive connection open for some time (not long though). During connection, the open client can receive data from the server. The client has to reconnect periodically after the connection is closed, due to timeouts or data eof. On server side it is still treated like an HTTP request, same as AJAX, except the answer on request will happen now or some time in the future, defined by the application logic.

• WebSockets - client ↔ server. Create a TCP connection to the server, and keep it open as long as needed. The server or client can easily close the connection. The client goes through an HTTP compatible handshake process. If it succeeds, then the server and client can exchange data in both directions at any time. It is efficient if the application requires frequent data exchange in both ways. WebSockets do have data framing that includes masking for each message sent from client to server, so data is simply encrypted.

• WebRTC - peer ↔ peer. Transport to establish communication between clients and is transport-agnostic, so it can use UDP, TCP or even more abstract layers. This is generally used for high volume data transfer, such as video/audio streaming, where reliability is secondary and a few frames or reduction in quality progression can be sacrificed in favour of response time and, at least, some data transfer. Both sides (peers) can push data to each other independently. While it can be used totally independent from any centralised servers, it still requires some way of exchanging endPoints data, where in most cases developers still use centralised servers to "link" peers. This is required only to exchange essential data for establishing a connection, after which a centralised server is not required.

• Server-Sent Events - client ← server. Client establishes persistent and long-term connection to server. Only the server can send data to a client. If the client wants to send data to the server, it would require the use of another technology/protocol to do so. This protocol is HTTP compatible and simple to implement in most server-side platforms. This is a preferable protocol to be used instead of Long Polling.

Websockets and SSE (Server Sent Events) are both capable of pushing data to browsers, however they are not competing technologies.

• Websockets connections can both send data to the browser and receive data from the browser. A good example of an application that could use websockets is a chat application.

• SSE connections can only push data to the browser. Online stock quotes, or twitters updating timeline or feed are good examples of an application that could benefit from SSE.

It can be overkill for some types of application to use WebSockets, and the backend could be easier to implement with a protocol such as SSE. Furthermore SSE can be polyfilled into older browsers that do not support it natively using just JavaScript.