This article was written with reference to the blog author "Lu Youyou" and the online course "Analysis and Actual Combat of Instant Messaging Technology", and I would like to express my gratitude.
1 Introduction
With the development of the mobile Internet, the application of IM technology is not limited to the chat application itself. It has long been integrated into various application forms, such as: host interaction in live broadcast, player interaction in online games, and real-time in takeaway/taxi applications. Location sharing, interactive whiteboards in online education applications, etc.
In these application scenarios with very different styles, although the functional forms presented by IM technology are different, there is no difference in the technical feature of "real-time".
So, for the technical layman, what is the "real-time nature" of IM? How to understand it? This is the subject of this article.
Different from powerful native applications, it is very difficult for the IM system on the Web side to achieve real "real-time" for a long period of time, because UDP and TCP communication protocols cannot be used directly. Before the emergence of WebSocket in HTML5, There is almost no real "two-way real-time communication" technology on the Web.
Because of this, understanding the evolution of Web-side instant messaging technology, it is natural to experience the "real-time nature" in the IM system step by step. Therefore, this article will focus on the Web-side instant messaging technology to expand the topic of IM "real-time" for you.
Friendly reminder: This series of articles focuses on the theoretical concepts. The space is limited. If you need to learn all aspects of IM technology in a systematic, in-depth, and specific manner, please start with this article: "One entry for beginners is enough: from zero Develop mobile terminal IM " (epic article, suitable for getting started to giving up).
study Exchange:
-5 groups for instant messaging/push technology development and exchange: 215477170 [recommended]
-Introduction to Mobile IM Development: "One entry is enough for novices: Develop mobile IM from scratch "
-Open source IM framework source code: https://github.com/JackJiang2011/MobileIMSDK
(This article was published synchronously at: http://www.52im.net/thread-3143-1-1.html )
2. Series of articles catalog
" Quick Start of IM Development (1): What is an IM system? 》
" Quick Start of IM Development (2): What is the real-time nature of the IM system? "(* This article)
"Quick Start of IM Development (3): What is the reliability of the IM system? (To be released later)》
"Quick Start of IM Development (4): What is the consistency of the IM system? (To be released later)》
"Quick Start of IM Development (5): What is the security of the IM system? (To be released later)》
"Quick Start of IM Development (6): What is the heartbeat mechanism of the IM system? (To be released later)》
"Quick Start of IM Development (7): How to understand and realize the unread IM system message? (To be released later)》
"Quick Start of IM Development (8): How to understand and realize the multi-terminal message roaming of the IM system? (To be released later)》
3. Short polling technology
In the early Web era, technology creators could not foresee the various forms of technology applications that are now selected. They believed that data was only used for "seeing", and data acquisition was basically a question of "request -> response". One answer form. Including the various portal websites that we usually browse all adopt the "request and response" model.
This data acquisition mode that relies on the user's "active" request, if you want to implement an IM system, it is impossible to get the latest chat messages immediately, because the user does not know when the new message will arrive, and the server has no way to actively notify the user. .
In this period, although technology and ideas are limited by the technological level of the time, IM can't help but do it.
As a result, a data acquisition mode called "short polling" emerged. In the "short polling" mode, the IM client polls the server regularly to let the user know whether there are new chat messages.
In this mode, after the server receives the request, it immediately queries whether there is a new message, returns it to the client if it has it, and returns nothing if it does not, and closes the connection immediately.
Compared with the previous way that users need to "manually" refresh the page, this mode only changes the user's "manual" to "automatic", and the nature of the technology has not undergone any substantial changes.
This mode of short polling is like a person waiting for important mail in the old age. He needs to go to the post office by himself every day and ask if he has his own mail. If there is one, he will take it home. If not, he will continue to go the next day. ask. It's very inefficient to come and go.
The technical principle is summarized as shown in the figure below:
This mode of short polling has advantages and disadvantages.
Benefits are:
- 1) The technology is simple and easy to implement;
- 2) Maintainability is strong, because it is not complicated.
The disadvantages are:
- 1) Because it is impossible to predict whether the data exists, most requests are useless and waste computing resources;
- 2) In order to improve real-time performance, high-frequency requests will increase the performance load of the server.
To sum up, this mode of short polling is very low for IM technology masters, because the technical implementation is really simple and rude.
4. Long polling technology
As you can see, using short polling technology to ensure the real-time performance of IM is indeed difficult to say elegant. However, this is difficult for omnipotent programmers, and a data acquisition mode called "long polling" has emerged.
Technically speaking, the biggest improvement of IM implemented by long polling over short polling is that in the case of short polling, the server will disconnect immediately after the request is completed, regardless of whether there is a new message. In the case of long polling, if there is no new message for this request, Yin will not disconnect and return immediately, but will "suspend" the connection for a period of time. If there is When a new chat message appears, it can be read and returned to the client immediately, and then the connection is ended. After a period of time, the request will be initiated again, and so on.
The long polling model, taking the example of waiting for mail in the previous section, is like the recipient who goes to the post office every day to ask if there is a letter. If not, he does not go home immediately, but stays at the post office for a period of time. , If this period of time has passed, and still not, go home first, and then come back the next day.
The technical principle is summarized as shown in the figure below:
The advantages of long polling are:
- 1) Compared with short continuous inquiry, the server request load is reduced to a certain extent;
- 2) Compared with the short continuous inquiry, the real-time performance is improved, because it is an active "waiting" message.
The disadvantages of long polling are:
- 1) In the long polling mode, during the period of time when the connection is "suspended", the server needs to cooperate to start a separate message query thread, and there is still useless work;
- 2) Compared with the short continuous polling mode, there is still a "real-time" blind spot in the window period between the end of a long polling and the next polling start.
In fact, in the Web-side instant messaging technology, long polling has a professional term called "Comet". If you are interested, you can learn in detail " Comet Technology Explained: Web-side Real-time Communication Technology Based on HTTP Long Connection ".
5. Polling cannot achieve true "real-time"
For the web-side instant messaging technology, whether it is short polling or long polling mentioned above, they all have "real-time" blind spots.
We return to the schematic diagrams of the short polling and long polling techniques introduced in the previous two sections.
Let's take a look at the short polling picture:
Obviously, in the interval between the end of each poll and the beginning of the next poll, the short polling cannot perceive new messages, which also forms a "real-time blind spot". In other words, the short polling technology is in the "real-time blind zone" and cannot achieve "real-time".
Let's look at long polling again:
Like short polling, long polling will still form a "real-time blind spot" in the interval between the end of each polling and the beginning of the next polling.
To understand the real-time flaws of entangled polling technology, you must understand the technology behind them-HTTP protocol.
The purpose of the HTTP protocol design is to realize the data interaction of the "request-response" model, which is the well-known "short connection" design. No matter whether it is short polling or long polling, there is no way to jump out of the innate technical logic of HTTP (request-response-disconnect).
So, in the final analysis, if you want to implement IM based on the HTTP protocol, it is quite reluctant to achieve true "real-time performance". Because the purpose of HTTP design is to use "short connections" to simplify the complexity of traditional TCP long connection communication, and the real-time nature of IM happens to use the long connection characteristics of TCP, so this is a paradox.
To truly realize the "real-time nature" of IM on the Web side, we must not forcefully make a fuss on HTTP. We need new technologies.
6. WebSocket makes the real "real-time nature" of Web-side IM possible
The good news is that WebSocket technology has been introduced in HTML5. WebSocket is a true full-duplex two-way communication technology (see: " WebSocket from entry to proficiency, half an hour is enough! ").
The comparison between the old polling technology and WebSocket on the following figure:
As can be seen from the figure above:
- 1) The polling technology has one question and one answer. Before the next request is initiated, there is a "real-time" blind spot;
- 2) Once the WebSocket connection is established, the data can communicate in both directions at any time (that is, the client can send messages to the server at any time, and the server can also notify the client of new messages at any time).
For example, polling technology is equivalent to the traditional mail delivery method (you have to go to the post office to ask if you have new mail), and WebSocket is equivalent to a modern telephone system, as long as you dial in, you can listen to the other party in real time at any time Voice, the other party can listen to your voice at any time. perfect!
To summarize the advantages of WebSocket:
- 1) True real-time: support the real two-way real-time communication between the client and the server;
- 2) Significantly reduce the load: The high-frequency useless requests in the polling technology are eliminated, which can greatly reduce the QPS pressure on the server;
- 3) Reduced network overhead: Connect once, use it at any time, and no longer need to initiate an HTTP request every time in the polling technology (there are a lot of redundant protocol header information for each HTTP, etc.).
7. Summary of this article
This article takes the evolution of Web-side instant messaging technology as an example, from short polling to long polling, and then to WebSocket, the theory is combined with practice to explain the technical changes of the "real-time nature" of Web-side IM, so as to help readers understand the "real-time" in IM. "Sex" is the most critical technical feature.
Appendix: More web-side instant messaging information
" Inventory of Instant Messaging Technologies on the Web: Short Polling, Comet, Websocket, SSE "
" Detailed SSE Technology: A New HTML5 Server Push Event Technology "
" Quick Start for Novices: A Concise Tutorial on WebSocket "
" Detailed Explanation of WebSocket (1): A Preliminary Understanding of WebSocket Technology "
" WebSocket Detailed Explanation (2): Technical Principles, Code Demonstrations and Application Cases "
" Detailed WebSocket (3): In-depth WebSocket communication protocol details "
" Detailed Explanation of WebSocket (6): Questioning the relationship between WebSocket and Socket "
" Practice and Ideas for Socket.io to Realize Message Push "
" LinkedIn's Web end IM Practices: Implementing a stand-alone hundreds of thousands of long connection "
" Using WebSocket and SSE Technology to Realize Web-side Message Push "
" Explain the evolution of web-side communication: from Ajax, JSONP to SSE, Websocket "
" Why does MobileIMSDK-Web's network layer framework use Socket.io instead of Netty? 》
" How to use WebSocket to achieve long connection in WeChat applet (including complete source code) "
" Eight Questions about WebSocket Protocol: Quickly Answer Hot Questions about WebSocket "
" Quick understanding of Electron: a new generation of Web-based cross-platform desktop technology "
" WebSocket from beginner to proficient, half an hour is enough! 》
This article has been simultaneously published on the official account of "Instant Messaging Technology Circle":
▲ The link of this article on the official account is: click here to enter , the original link is: http://www.52im.net/thread-3143-1-1.html