IM has gone through several representative stages in the pursuit of "message real-time" architecture.
1. Short polling scenario
In the early days of PC Web, most applications used a "request-response" model for data acquisition. In fact, like now we browse news on most portal websites and use Weibo The "request response" mode. However, this mode of relying on "manual" triggering cannot be well perceived and obtained when new messages are generated in the instant messaging system, so it is obviously not suitable for scenarios that require high real-time performance. Therefore, many IM software of this period adopted a "short polling" mode to poll the server for new messages regularly and frequently. In the short polling mode, after the server receives the request, if there is a new message, it will return the new message to the client, if there is no new message, it will return an empty list and close the connection.
As shown below:
Disadvantages of short polling:
In order to improve real-time performance, the frequency of short polling is generally high, but most of the polling requests are actually useless, and the client both costs electricity and traffic; high-frequency requests also put a lot of pressure on the resources of the server. A large number of servers are used to carry high-frequency polling QPS (query rate per second), and secondly, it also puts greater pressure on back-end storage resources.
scenes to be used:
Therefore, it is suitable for small applications where the user scale is relatively small and does not want to spend too much service transformation costs.
2. Long polling scenario
Compared with long polling and short polling, one of the biggest improvements is that in the short polling mode, the server will respond and return immediately regardless of whether a new message is generated in this round. In the long polling mode, when a new message is not obtained in this request, it will not end the return immediately, but will "hang" on the server side and wait for a period of time; if there is a new message during the waiting period When the message is generated, it can respond immediately.
As shown below:
Disadvantages of long polling:
(1) The server hangs the request, which only reduces the QPS of the entry request, but does not reduce the pressure on the back-end resource polling. If there are 1000 requests waiting for messages, it may mean that 1000 threads are constantly polling message storage resources.
(2) When the long polling fails to obtain a message within the timeout period, it will end the return, so the problem of "invalid" requests from the client is still not completely solved.
scenes to be used:
The real-time requirements are relatively high, but the overall user volume is not too large. It is still more used in scenarios where the browser does not support WebSocket.
3.WebSocket
With the advent of HTML5, full-duplex WebSocket completely solves the problem of server-side push.
Compared with short polling and long polling, for IM services based on WebSocket, the client and server only need to complete a handshake to create a persistent long connection and perform two-way data transmission at any time. When the server receives a new message, it can push it directly through the established WebSocket connection, which truly achieves "edge triggering" and ensures the real-time arrival of the message.
advantage:
Support the two-way communication of server push, greatly reducing the pressure of server polling;
The control overhead of data interaction is low, which reduces the network overhead of communication between the two parties;
Web native support, relatively simple to implement.
There are other communication protocols derived from TCP long connections, such as XMPP protocol, MQTT protocol and various proprietary protocols.
XMPP: Although the XMPP protocol is relatively mature and has good scalability, the XML format-based protocol has more redundancy in transmission, is not very friendly in terms of traffic, and is more complicated in overall implementation. It is not used in today's mobile network scenarios. many.
MQTT: The lightweight MQTT is based on the proxy "publish/subscribe" model, which is more prominent in terms of traffic saving and scalability. It is widely used in many message push scenarios, but this protocol is not a proprietary protocol in the IM field Therefore, for many personalized business scenarios under IM, a large number of complex extensions and developments are still required, such as not supporting group functions and offline messaging.
In order to better solve the real-time problem, several iterative upgrades of technologies in the instant messaging field have been experienced:
1. Gradually upgrade from simple and inefficient short polling to relatively efficient and controllable long polling;
2. With the advent of HTML5, the full-duplex WebSocket completely solves the problem of server-side push;
3. At the same time, various stateful communication protocols derived from TCP long connections can also be actively pushed by the server, so as to better solve the problem of "message sending and receiving in real time".