A brief analysis of Web real-time communication technology!

Web-based instant messaging

The server can immediately reflect data updates or changes to the client, such as instant message push.

However, due to the limitations of browsers on the Web, some methods are needed to achieve instant messaging.

The main reasons for this limitation are:

• In general web communication, the browser first sends a request to the server, and the server then responds to complete the actual update of the data.

Implementing Web-based Instant Messaging

There are four main methods: short polling, long polling, SSE, and WebSocket.

Comparison of Four Web Instant Messaging Technologies

From the compatibility perspective:

• Short polling > Long polling > SSE > WebSocket.

Considering performance:

• WebSocket > SSE > Long Polling > Short Polling.

Short Polling

Polling is a method in which a client periodically sends HTTP requests to a server, and the server returns data to the browser in real time to check whether there is new data or updates.

The client will set a fixed time interval and continuously initiate HTTP requests to the server, and will get a response regardless of whether new data is returned.

Applicable scenarios

Polling is applicable to the following scenarios:

No real-time updates required:

• The system does not need to obtain data in real time, but only needs to be synchronized intermittently, such as stock price updates or refreshes of news clients.

Lightweight updates:

• The server resources are limited and cannot sustain high-concurrency long connections.

shortcoming

High resource consumption:

• If the polling interval is too short, the server may be overwhelmed with invalid requests.

Poor timeliness:

• The data is not updated in real time, but based on a set polling interval.

Long Polling

Long polling is an improved polling method.

After the client sends a request, the server maintains the connection (blocking the request) until new data is generated before returning a response.

Once there is new data, the server responds to the client, and after the client processes the data, the client immediately initiates the request again, maintaining a push-like effect.

Applicable scenarios

Need near real-time data:

• Application scenarios require fast data updates, such as chat systems, notification reminders, etc.

Reduce unnecessary requests:

• Compared with traditional polling, long polling can reduce invalid requests.

advantage

Reduce invalid requests:

• A response is returned only when there is new data, avoiding frequent invalid requests in traditional polling.

Near real-time updates:

• Since the server only responds when there is new data, quasi-real-time data synchronization can be achieved.

shortcoming

Stay connected for a long time:

• In some scenarios, a large amount of server connection resources may be occupied.

Not suitable for high-frequency updates:

• If data is updated frequently, the frequent reconnections of long polling may become a burden.

Precautions

Network timeout:

In long polling, the client's request will be maintained for a longer time, so you need to ensure that the timeout settings of the client and the server are appropriate.

Load issues:

Although long polling saves more resources than ordinary polling, the number of server connections may be exhausted quickly in high-concurrency scenarios, and a reasonable resource management mechanism needs to be designed.

• Or consider using a more appropriate technology such as WebSocket.

Reconnection mechanism:

Whether it is normal polling or long polling, a reasonable reconnection mechanism needs to be designed to ensure that the client can continue to request without interruption after the request fails.

SSE

SSE opens a one-way channel between the server and the browser.

The server responds to the data packet in a text/event-stream format instead of a one-time data packet.

The server streams data to the client when the data changes.

SSE Principle

SSE allows the server to continuously push updates to the client through a persistent HTTP connection.

The client only needs to establish a connection once, the server can continuously push data, and the client will continue to receive data.

Scenario:

Suitable for applications with one-way data flow, such as real-time notifications, stock prices, social media push, messaging systems, and other scenarios that require frequent data updates.

advantage:

Simple implementation, supports automatic reconnection.

shortcoming:

Due to browser compatibility issues, two-way communication cannot be achieved.

Simulating an online payment scenario, how to implement this process using SSE?

Users scan the code to pay the payment system (WeChat, Alipay, Apple).

After the payment is completed, inform the server that I have initiated the payment (establish an SSE connection).

The payment system tells the server, or the client sends the payment credentials to the server for verification, that the user has indeed made a successful payment.

The server sends a message to the user: Your payment has been successful, and you are redirected to the payment success page.

• Through the SSE connection, the server informs the user's client browser.

picture

Simulate the server:

picture

WebSocket

WebSocket is a full-duplex communication protocol based on TCP connection:

• Full-duplex: Allows data to be transmitted in both directions simultaneously.
• Half-duplex: allows data to be transmitted in both directions, but only in one direction at a time.

The WebSocket protocol is built on the basis of the TCP protocol, so it is easy to implement on the server side and is supported by different languages.

advantage:

Low latency, suitable for real-time communication.

shortcoming:

This may be limited in some network environments.

Implementing WebSocket using SpringBoot

Introduce dependencies:

 implementation 'org.springframework.boot:spring-boot-starter-websocket'

Implementation class:

picture

picture

picture

Spring configuration:

picture

Startup and testing:

Execute the Main method to start the application.

Test using the WebSocket online debugging tool: http://coolaf.com/tool/chattest

picture

in conclusion

When choosing a server-side communication technology, the specific needs and scenarios of the application should be considered.

WebSocket is suitable for applications that require high real-time and two-way communication.

SSE is suitable for simple one-way data push.

Short polling and long polling are suitable for scenarios where the update frequency is not high.

Choosing the right technology can significantly improve user experience and application performance.