Quick introduction to IM communication technology: short polling, long polling, SSE, WebSocket

Preface

• Hello, everyone. I’m Lorraine. For developers who are familiar with Web instant messaging technology, looking back at the development of the underlying communication technology of the entire web IM, from short polling, long polling, to the later SSE and WebSocket, the technology we use is becoming more and more advanced, and the threshold for use is getting lower and lower, bringing you a better and better web experience.

• Therefore, we often do not need to blindly pursue new technologies. Instead, the technology that suits the scenario is the best technology. Mastering mainstream new technologies such as WebSocket is important, but understanding the so-called "old technologies" such as short polling and long polling is still very helpful. This is why I share this technology.

Instant Messaging

• For instant messaging systems such as IM/message push, the key to the system is the "real-time communication" capability. The so-called real-time communication has the following two meanings:

 1、客户端可以主动向服务端发送信息。 2、当服务端内容发生变化时，服务端可以实时通知客户端。

Commonly used techniques

• Client polling: Traditional short polling

• Server-side polling: Long Polling

• One-way server push: Server-Sent Events (SSE)

• Full-duplex communication: WebSocket

Short Polling

Implementation principle

• The client sends a request to the server, the server returns data, and then the client processes the data returned by the server.

• The client continues to send requests to the server and repeats the above steps. (In order to reduce the pressure on the server, a timed polling method is generally used)

Short polling communication process

advantage

• Simple to implement, no additional development required, just initiate requests at regular intervals and parse the responses.

shortcoming

• Constantly initiating and closing requests results in performance loss and puts a lot of pressure on the server, and HTTP requests themselves are quite resource-intensive.

• The polling interval is difficult to control. If real-time requirements are high, short polling is an obvious shortcoming, but if it is set too long, it will cause message delays.

Long Polling

Implementation principle

• The client sends a request and the server holds the request.

• Data will not be returned until the monitored content changes, and the connection will be disconnected (or if the request is not returned within a certain period of time, the connection will be automatically disconnected due to timeout);

• The client continues to send requests and repeats the above steps.

Long polling communication process

Improvements

• Long polling is an improved version based on short polling: it reduces the overhead of the client initiating the Http connection and instead allows the server to actively determine whether the content of interest has changed.

iframe-based long polling

• iframe-based long polling is another implementation of long polling.

Implementation principle

• Embed an iframe in the page, with the address pointing to the polled server address, and then place an execution function in the parent page, such as execute(data);

• When the server has content changes, it sends a script to the iframe;

• Through the sent script, the method in the parent page is actively executed to achieve the push effect.

Summarize

• The underlying technology of iframe-based long polling is still long polling technology, but the implementation method is different. In addition, the browser will display that the request has not been loaded, and the icon will keep rotating. It is simply a killer for obsessive-compulsive disorder. I personally do not recommend it.

iframe long polling

Server-Sent Events (SSE)

• In the short polling and long polling technologies described above, the server cannot actively push messages to the client. The client actively requests the server to obtain the latest data. SSE is a technology that can actively push messages from the server.

• The essence of SSE is actually a long connection of HTTP, but it does not send a one-time data packet to the client, but a stream in the format of text/event-stream. Therefore, the client will not close the connection and will always wait for new data streams from the server.

Implementation principle

• The client initiates an HTTP persistent connection to the server, and the server returns a stream response. The client does not close the connection after receiving the stream response but waits for the server to send a new data stream.

picture

SSE Communication Process

Browser support for SSE

Browser support for SSE

SSE vs WebSocket

• SSE uses the HTTP protocol, which is supported by existing server software. WebSocket is an independent protocol.

• SSE is lightweight and easy to use; the WebSocket protocol is relatively complex.

• SSE supports reconnection by default, but WebSocket needs to be implemented by yourself.

• SSE is generally only used to transmit text. Binary data needs to be encoded before transmission. WebSocket supports the transmission of binary data by default.

• SSE supports customizing the message types sent.

Summarize

• For scenarios where the server only needs to push data to the client, we can consider implementing a simpler SSE instead of using WebSocket directly.

WebSocket

• WebSocket is a network transport protocol that enables full-duplex communication over a single TCP connection and resides at the application layer of the OSI model.

• WebSocket makes data exchange between the client and the server much simpler, allowing the server to actively push data to the client. The client and the server only need to complete a handshake to create a persistent connection between the two and perform two-way data transmission.

Implementation principle

• The client sends an HTTP GET request to the server, and the path of the request is the path of the WebSocket (similar to ws://example.com/socket). The request contains some special header fields, such as Upgrade: websocket and Connection: Upgrade, to indicate that the client wants to upgrade the connection to WebSocket.

• After receiving this request, the server returns an HTTP 101 status code (protocol switching protocol). The response header also contains Upgrade: websocket and Connection: Upgrade, as well as some other WebSocket-specific header fields, such as Sec-WebSocket-Accept, which is used to verify the legitimacy of the handshake.

• The connection between the client and the server is upgraded from a normal HTTP connection to a WebSocket connection. After that, the communication between the client and the server becomes the transmission of WebSocket frames instead of normal HTTP requests and responses. The client and the server communicate with each other.

WebSocket Communication Process

advantage

• Real-time: WebSocket provides two-way communication, and the server can actively push data to the client, achieving very high real-time performance, which is suitable for applications such as real-time chat and online collaboration.

• Reduced network latency: WebSockets can significantly reduce network latency compared to polling and long polling because there is no need to establish and close a connection between each request.

• Smaller data transmission overhead: WebSocket data frames are smaller than HTTP request messages, reducing the transmission overhead in each request, making it particularly suitable for applications that require frequent communication.

• Lower server resource usage: Due to the long connection feature of WebSocket, the server can handle more concurrent connections and has lower resource usage compared to short connections.

• Cross-domain communication: WebSocket makes cross-domain communication easier to implement than some other cross-domain communication methods.

shortcoming

• Maintaining the connection state: Maintaining the connection for a long time may cause both the server and the client to maintain the connection state, which may increase some burden.

• Not suitable for all scenarios: For some scenarios with simple request-response patterns, the real-time features of WebSocket may not be necessary, and using HTTP requests may be more appropriate.

• Complexity: Compared with traditional HTTP requests, WebSocket implementation and management may be slightly more complicated, especially in handling connection status, exceptions, etc.

Summarize

• In this article, we introduce four commonly used technologies in IM communication technology: short polling, long polling, SSE, and WebSocket. When using, you can choose the appropriate communication technology based on your actual scenario. In complex application scenarios, we may need to combine different technologies to meet different needs. The following are some common considerations:

Real-time requirements

• If the real-time requirements are low, short polling or long polling may be sufficient; if higher real-time requirements are required, consider using SSE or WebSocket. If only server-side push is required, consider SSE as much as possible.

Network and server resources

• Short polling and long polling may generate more invalid requests, increase bandwidth and server burden; SSE and WebSocket are relatively more efficient.

Personal Profile

👋 Hello, I'm Lorin, a Java backend technology developer! Motto: Technology has the power to make the world a better place.