Talk about four real-time communication technologies: short polling, long polling, WebSocket and SSE
In this article, we will talk about four real-time communication technologies: short polling, long polling, WebSocket and SSE.
1. Short polling
The browser sends HTTP requests to the server periodically (such as every second), and the server immediately returns the current data (regardless of whether it has been updated).
Advantages: simple implementation, excellent compatibility
Disadvantages: high-frequency requests waste resources, poor real-time performance (depends on polling interval)
Delay: high (depends on polling frequency)
Applicable scenarios: simple scenarios with high compatibility requirements and insensitive to delay.
The most impressive short-polling application scenario in the author's career is live score:
As shown in the figure, the user enters the live score interface, and the browser periodically queries the game information (score changes, yellow and red cards, etc.). If the data changes, the page is re-rendered.
This method is very simple and reliable to implement, but frequent calls to the backend interface will affect the backend performance (mainly CPU). At the same time, because it depends on the polling interval, the page data changes are delayed, and the user experience is not very good.
2. Long polling
After the browser sends an HTTP request, the server hangs up the connection until the data is updated or times out. After returning the response, the browser immediately starts a new request.
Advantages: Reduce invalid requests, better real-time performance than short polling
Disadvantages: The server needs to maintain the connection, and high resource consumption at high concurrency
Latency: Medium (depends on the frequency of data updates)
Applicable scenarios: Scenarios that require better real-time performance and cannot use WebSocket/SSE (such as message notifications)
The most common application scenarios of long polling are: configuration center, the registration center Nacos and Apollo that we are familiar with all rely on the long polling mechanism.
3. WebSocket
Full duplex protocol based on TCP, establishes a persistent connection (two-way instant communication) through HTTP upgrade handshake (Upgrade: websocket).
Advantages: Minimum latency, support for two-way interaction, bandwidth saving
Disadvantages: Complex implementation, need to handle connection status separately
Latency: Very low
Applicable scenarios: Chat rooms, online games, collaborative editing, etc. High real-time two-way interaction requirements
The author once worked for an e-commerce company in Beijing and participated in the development of the live quiz function.
The overall architecture of the live quiz is shown in the figure below:
The technical options for the TCP gateway are: Netty, ProtoBuf, and WebSocket. WebSocket is chosen because it supports two-way real-time communication. At the same time, Netty has a built-in WebSocket implementation class, which makes the project relatively simple to implement.
4. Server Send Event (SSE)
Based on the HTTP protocol, the server can actively push data streams (such as Content-Type: text/event-stream), and the browser monitors through the EventSource API.
Advantages: native support for disconnection reconnection, lightweight (HTTP protocol)
Disadvantages: one-way communication (server-->client), not supported by low-level IE browsers
Delay: low (server can push in real time)
Applicable scenarios: stock quotes, real-time logs, etc., where one-way server push is required.
The most classic application scenario of SSE is: DeepSeek web chat interface, as shown in the figure:
When the DeepSeek dialog box sends a message, the browser will send an HTTP request, and the server will send the data back to the browser via SSE.
5. Summary
Selection suggestions:
Need simple compatibility → Short polling
Need medium real-time → Long polling
Only server push → SSE
Need full duplex real-time interaction → WebSocket