In recent years, whether it is the rapidly growing live broadcast, distance education and IM chat scenes, or the system reminder used in the conventional enterprise system, the demand for Websocket is increasing, and the requirements for Websocket are also getting higher and higher. From the early application of Websocket was limited to a few functions and SPECIAL scenarios such as IM, it gradually developed into the pursuit of high concurrency, high availability of Websocket services with millions and tens of millions of levels of communication per second.
As an old program ape with many years of websocket development experience, experienced the GoEasy enterprise webSocket service from scratch, from small to large process, this article is based on the past few years in the GoEasy development process stepped on the pit, As well as providing websocket services for many development teams, and communicating with many developers summed up some experience and experience.
This time, I will share some basic functions and features of webSocket service. Next time, I will share more information about high concurrency, massive messages, cluster disaster recovery, horizontal expansion, and automatic operation and maintenance when building a high availability Websocket.
The following are some technical features that I think must be considered when building webSocket services and features that can significantly improve user experience for your reference:
1. Establish a heartbeat mechanism
The heartbeat mechanism is the first step in almost all network programming and is often overlooked by novices. In a Websocket connection, the client and server do not always communicate with each other. If they do not communicate with each other for a long time, they do not know the current status of each other. Therefore, they need to send a small message to tell each other that they are still alive. There are two other purposes:
-
When detecting that the heartbeat of a client is not coming, the server can actively close the channel and make it offline.
-
If a client detects that a server is not responding, the heartbeat can be reconnected to obtain a new connection.
2. Establish a client SDK with good compatibility
Although websocket is now supported by mainstream browsers, there are still browser compatibility problems in coding, and clients communicating through Websocket are not limited to various Web browsers, but also include more and more apps and small programs.
Therefore, it is required to build websocket service must be able to support a variety of client friendly. The best way is to build a client SDK that is compatible with all major browsers, applets and apps, as well as uni-App, Vue, React-Native and other common front-end frameworks, so that no matter what front-end technologies are used in each project of the company, webSocket service can be quickly integrated.
3. Automatic reconnection and message resending mechanism when the network is disconnected
In the era of mobile Internet, the network environment of end users is diverse and complex. For example, it is common for users to enter and exit elevators, basements, subways and other places with unstable network, or network instability caused by other reasons.
Therefore, a reliable Websocket service must have a perfect automatic reconnection mechanism. Ensure that long connections can be automatically re-established and messages sent during network instability can be resent immediately once the network is restored after disconnection.
4. Offline message
Basic Websocket communication Technically, the prerequisite for message delivery is to establish a long connection, and to discuss communication without establishing a network connection is hooliganism.
However, from the user’s point of view, it happens all the time that the Internet connection is disconnected by closing the browser or killing the small program or APP process. And then our subconscious expectation is that the next time I open the browser to visit the web page, or open the APP, I will receive all the information that the user left the system. This is technically a requirement that has little to do with WebSocket, but is actually an essential feature of the WebSocket service and one that can greatly improve the user experience.
5. Online notification and list of clients
It is an essential feature to build an enterprise-class Websocket service, especially to develop IM and game products, to master which users are online in the current system and to capture users’ online and offline events.
6. Query historical messages
Websocket service, in a sense, also belongs to a message system, for the historical message query requirements, is unable to bypass the topic. For example, historical messages are common in IM system, so it is a necessary work to implement a high-speed and reliable message queue mechanism in Websocket service to support the query of historical messages.
7. Message compression mechanism
In order to ensure the speed and real-time of message communication, or to save the cost of traffic and bandwidth, or to improve the efficiency of the use of network card and increase the throughput of the system, it is essential to compress the message in the process of communication.
In addition to the need to consider the above seven points, the author believes that there are several problems are also worth active attention of beginners:
1. Caching and persistence
Choosing the appropriate message caching mechanism is a problem that must be considered to ensure the performance of enterprise websocket service.
2. Asynchronous invocation
Asynchronous invocation is certainly recommended for high-performance systems that support large amounts of messaging. If the call is designed to be synchronous, the caller needs to wait for the called to complete. If the synchronous call goes on layer by layer, all callers need the same waiting time, and the resources of callers will be greatly wasted.
Even worse, once the called party fails, the other calls will have a domino effect and fail, causing the failure to spread. Returning the results immediately upon receipt of the request and then executing them asynchronously not only increases the throughput of the system, but also makes the decoupling of services more complete.
3. Business and standardization independence
Although it is possible to have both regular HTTP services and Websocket services in a Web project, this approach is simpler and easier to maintain, especially for single-application Web systems with low performance requirements.
However, for enterprise-class systems or Internet platforms with high performance and availability, it is better to design Websocket service as a separate micro-service to avoid resource preemption with conventional HTTP service, which leads to uncontrollable system performance and is more convenient for horizontal expansion.
A well-designed enterprise-level Websocket service should be a separate, standardized, technical microservice that can be used as part of a company’s infrastructure to provide communications services for all of its projects.
4. Idempotency and filtering of duplicate messages
Idempotent means that one or more requests to an interface should have the same consequences. Why? Each call to an interface has three possible outcomes: success, failure, and timeout.
For the last one, many possible causes are network packet loss, the request may not arrive, or the return may not be received. So often have a retry mechanism when docking ports of call, but retry mechanism is easy to lead to repeated message to send, this is often not acceptable from a user level, so in the design of the interface, we need to consider the idempotence of the interface, to ensure that the same message sent once or ten times will not lead to repeated messages arrive.
5. QoS quality grading is supported
In fact, for the problem of message repetition mentioned above, the industry already has solutions and standards. For message arrival rate and repetition, the commonly used means is to ensure message arrival through message confirmation. The higher the requirements, the more complex the confirmation mechanism, the higher the cost.
In order to achieve a good balance between cost and arrival rate, there are usually three levels of quality of service (QoS) for messaging systems:
-
QoS 0(At most once) : this mode is applicable to scenarios with low requirements. It can accept a certain no-arrive rate and has the lowest cost.
-
QoS 1(At least once) : indicates that the sender must clearly receive the acknowledgement signal from the receiver. Otherwise, the sender will send the message repeatedly. Each message needs At least two communications to confirm its arrival.
-
QoS 2(Exactly once) : “Ensure only once”, meaning that each message can arrive only once and cannot be repeated. In order to achieve this goal, both parties need to communicate at least three times, which is the highest cost.
A perfect Websocket service should be able to choose different levels of QoS in different application scenarios, so as to achieve a balance between cost and quality of service.
The last
Although Websocket has been widely used in a variety of systems and platforms, if you want to build a reliable, safe and stable Websocket service to meet the needs of enterprise or large Internet platforms, for students without experience, there are still many pits to step on in the specific technical practice process.
Because of high requirements for Websocket services, it is also a cheaper and more efficient choice to choose mature and reliable third-party Websocket services. As the leading third-party Websocket messaging platform in China, GoEasy has been running statically for 5 years and supports tens of millions of message concurrency. In addition to all common browsers, GoEasy is also compatible with Uni-App, various small programs, vue, React-Native and other common front-end frameworks.
I hope this article can be helpful and reference for the students who build websocket service for the first time. I also welcome your comments and comments. I also hope to have the opportunity to communicate with you on more technologies in the future.
GoEasy
1, uniAPP version of the direct broadcast chat room (support packaged into android /ios APP, wechat small program) : gitee.com/goeasy-io/G…
2, UNIAPP version of instant messaging IM (support packaged into Android /ios APP, wechat small program) : gitee.com/goeasy-io/G…
3, wechat small program version of instant messaging IM: gitee.com/goeasy-io/G…
4, VUE version of instant messaging IM: gitee.com/goeasy-io/G…
5, H5 version of instant messaging IM: gitee.com/goeasy-io/G…
6, H5 version of the direct broadcast chat room: gitee.com/goeasy-io/G…