| Tip |
|---|
The usual AJAX request/response we’re all used to doesn’t keep the connection open for this sort of use case. Instead we need a push-based method like WebSockets, Long Polling, Server-Sent Events (SSE) and more recently HTTP2 push. |
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.
A client initiates an XHR/AJAX request, requesting some data from a server.
The server does not immediately respond with request information but waits until there is new information available.
When there is new information available, the server responds with new information.
The client receives the new information and immediately sends another request to the server restarting the process.
Challenges / Cons
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.
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.
There is no in-built guarantee that duplicate data won’t be written more than once.
Performance and scaling : it is a lot more intensive on the server.
Device support and fallbacks.
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.
3
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.
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.
3. 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.
4. The connection will be closed once the server or the client decides to close the connection.
Challenges / Cons
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.
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.
Intermediary/Edge caching is not possible with WebSockets unlike HTTP.
Security issues : https://blog.securelayer7.net/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
On this page.
| Table of Contents |
|---|