Long-Polling vs WebSockets vs Server-Sent Events (SSE)

Long Polling

Overview

Long polling is essentially a more efficient form of the original polling technique (with JavaScript - XMLHttpRequest). Making repeated requests to a server wastes resources, as each new incoming connection must be established, the HTTP headers must be parsed, a query for new data must be performed, and a response (usually with no new data to offer) must be generated and delivered.

The connection must then be closed and any resources cleaned up. Rather than having to repeat this process multiple times for every client until new data for a given client becomes available, long polling is a technique where the server elects to hold a client’s connection open for as long as possible, delivering a response only after data becomes available or a timeout threshold is reached.

Open

Http Long Polling

1. A client initiates an XHR/AJAX request, requesting some data from a server.

2. The server does not immediately respond with request information but waits until there is new information available.

3. When there is new information available, the server responds with new information.

4. The client receives the new information and immediately sends another request to the server restarting the process.

Challenges / Cons

1. Message ordering and delivery guarantees : Cannot be guaranteed if the same client opens multiple connections to the server or if client was not able to receive the message then there will be possible message loss.

2. Depending on the server implementation, confirmation of message receipt by one client instance may also cause another client instance to never receive an expected message at all.

3. There is no in-built guarantee that duplicate data won’t be written more than once.

4. Performance and scaling : it is a lot more intensive on the server. Server needs to do more jobs such as holding the connection open, establishing what pieces of data are already sent to the client in the previous connections and what more needs to be sent.

5. Maximal Latency: because of the way Long-Polling works, once the server sends a response to the client, it can not send anything else and it needs to wait until a new request is made. There are some methods that can reduce latency such as HTTP pipelining, but they are not always available.

WebSockets

Overview

WebSocket is a computer communication protocol which provides full-duplex communication channels over a single TCP connection.

• It is different from HTTP but compatible with HTTP.

• Located at layer 7 in the OSI model and depends on TCP at layer 4.

• Works over port 80 and 443 ( in case of TLS encrypted) and supports HTTP proxies and intermediaries.

• To achieve compatibility, the WebSocket handshake uses Upgrade header to update the protocol to the WebSocket protocol.

Open

3

1. A client initiates a WebSocket handshake process by sending a request which also contains Upgrade header to switch to WebSocket protocol along with other information.

2. The server receives WebSocket handshake request and process it.

2(a). If the server can establish the connection and agrees with client terms then sends a response to the client, acknowledging the WebSocket handshake request with other information.

2(b). If the server can not establish the connection then it sends response acknowledging it cannot establish WebSocket connection.

1. Once the client receives a successful WebSocket connection handshake request, WebSocket connection will be opened. Now, client and servers can start sending data in both directions allowing real-time communication.

1. The connection will be closed once the server or the client decides to close the connection.

Challenges / Cons

1. Hard to scale : connections to WebSocket server need to be persistent. Even nodes are scaled (horizontal and vertical), we need a solution for sharing data between nodes.

2. WebSockets don’t automatically recover when connections are terminated – this is something you need to implement yourself, and is part of the reason why there are many client-side libraries in existence.

3. Intermediary/Edge caching is not possible with WebSockets unlike HTTP.

4. Security issues : Websocket: common vulnerabilities plaguing it and managing them.

Why WebSocket protocol is a better choice

Long polling is much more resource intensive on servers whereas WebSockets have an extremely lightweight footprint on servers.

Why you should build with WebSockets:

• Full-duplex asynchronous messaging. In other words, both the client and the server can stream messages to each other independently.

• WebSockets pass through most firewalls without any reconfiguration.

Server-Sent Events

Overview

Unlike WebSockets, Server-Sent Events are a one-way communication channel where events flow from server to client only. Server-Sent Events allows browser clients to receive a stream of events from a server over an HTTP connection without polling.

1. Browser client creates a connection using an EventSource API with a server endpoint which is expected to return a stream of events over time. This essentially makes an HTTP request at given URL.

2. The server receives a regular HTTP request from the client and opens the connection and keeps it open. The server can now send the event data as long as it wants or it can close the connection if there are no data.

3. The client receives each event from the server and process it. If it receives a close signal from the server it can close the connection. The client can also initiate the connection close request.

Challenges / Cons

• No native support for binary types.

• Unilateral communication : Unidirectional nature can cause a problem if the connection is lost.

• No way to add headers with the EventSource object.

• Max of 6 client connections from a single host : Limitation related to the number of connections that can be opened between the client and server at the same time.

Why SSE is a better choice

SSE provides a layer of connection management and parsing logic, allowing us to easily keep the connection open while a server pushes new events to the client as they become available.