Shulou(Shulou.com)06/03 Report--

In recent years, whether it is the rapid growth of live streaming, distance education and IM chat scenarios, or the system reminders used in conventional enterprise systems, the demand for websocket is increasing, and the demand for websocket is getting higher and higher. From the early application of websocket limited to a small number of functions and special scenarios such as IM, it has gradually developed into a highly available websocket service that supports high concurrency, millions and tens of millions of communications per second.

In the face of the increasing demand for websocket function and performance in various new scenarios, different teams have different choices, some directly use mature and stable third-party websocket services developed by professional teams, and some choose self-built websocket services.

As a veteran programmer with many years of experience in websocket development, he has experienced the process of GoEasy enterprise websocket services from scratch to large. This article is based on the holes that have been stepped on in the process of GoEasy development in the past few years, as well as some experiences and experiences in providing websocket services for many development teams and communicating with many developers.

This time, we mainly share the basic functions and features of websocket services. Next time, we have the opportunity to share more about the high concurrency, massive messages, cluster disaster recovery, scale-out, and automated operation and maintenance that we have to face when building a highly available websocket.

The following are some technical features that I think must be considered when building websocket services and functions that can significantly improve the user experience for your reference:

1. Establish a heartbeat mechanism

Heartbeat mechanism is the first step in almost all network programming, and it is often ignored by beginners. Because in the websocket persistent connection, the client and the server will not communicate all the time, if the two sides do not communicate for a long time, they do not know the current status of each other, so it is necessary to send a small message to tell the other side that "I am still alive". There are two other purposes:

The server detects that a client has a slow heartbeat and can actively close the channel and take it offline.

The client can reconnect to get a new connection if it detects that a server has failed to respond to the heartbeat.

two。 Establish a client SDK with good compatibility

Although mainstream browsers support websocket, they still encounter browser compatibility problems in coding, and the clients that communicate through websocket are not limited to a variety of web browsers, but also include more and more APP and Mini Program. Therefore, it requires that the built websocket service must be able to support a variety of clients amicably. The best way is to build a client SDK that is compatible with all mainstream browsers, Mini Program and APP, as well as various front-end frameworks such as uni-app, vue, react-native and so on, so that no matter what front-end technology the company's projects use, it can quickly integrate websocket services.

3. Automatic reconnection and message reissue mechanism of disconnected network

In the era of mobile Internet, the network environment of end users is diverse and complex, such as users going in and out of elevators, basement or subway, or network instability caused by other reasons is a very common scene. Therefore, a reliable websocket service must have a perfect automatic reconnection mechanism. After the network is cut off, once the network is restored, the long-standing connection can be automatically re-established as soon as possible, and the messages sent during the period of network instability can be reissued immediately.

4. Offline message

Basic Websocket communication from a technical point of view, the prerequisite for message delivery is to establish a long connection. It is rogue to discuss communication without establishing a network connection. But from the user's point of view, the situation that shuts down the browser, or directly kills the Mini Program or APP process, which leads to the disconnection of the network, occurs at any time. Then we subconsciously expect that the next time I open a browser to visit the web page, or open APP, I will receive all the information about the time the user is away from the system. Technically, this is a requirement that has little to do with websocket, but in fact it is an indispensable basic feature of websocket services and a feature that can greatly improve the user experience.

5. Online reminder and client online list

Knowing which users are online in the current system and capturing user online and offline events is an essential feature of building an enterprise-level websocket service, especially the development of IM and game products.

6. Support historical message query

Websocket service, in a sense, also belongs to a messaging system, and the query requirements for historical messages can not be bypassed. For example, historical messages are common in IM systems, so it is a necessary work to implement a high-speed and reliable message queuing mechanism in websocket services to support the query of historical messages in websocket services.

7. Message compression mechanism

Whether it is to ensure the speed and real-time performance of message communication, or to save traffic and bandwidth costs, or to improve the efficiency of the use of the network card and increase the throughput of the system, it is necessary to compress messages in the process of communication.

In addition to the above seven points, the author believes that there are several issues that deserve the active attention of beginners:

1. Caching and persistence

Choosing the appropriate message caching mechanism is a problem that must be considered to guarantee the performance of enterprise-level websocket services.

two。 Asynchronous invocation

For a high-performance system that supports a large number of message communication, asynchronous calls must be recommended. If designed for synchronous invocation, the caller needs to wait for the callee to complete. If a layer-by-layer synchronous call continues, all callers need the same waiting time, and the caller's resources will be wasted. To make matters worse, once something goes wrong with the callee, other calls will have a domino effect that will follow the problem, causing the fault to spread. Return the result immediately after receiving the request, and then execute it asynchronously, which can not only increase the throughput of the system, but also make the decoupling between services more thorough.

3. Independent of business and standardization

Although regular http services and websocket services can exist in a web project at the same time, especially for single-application web systems with low performance requirements, this approach is simpler and easier to maintain. However, for enterprise systems or Internet platforms with high performance and availability, a better way is to design websocket services as a separate micro-service to avoid preempting resources with conventional http services, resulting in uncontrollable system performance and more convenient for scale-out.

A well-designed enterprise websocket service should be a standardized technical micro-service independent of the business system, which can provide communication services for all the company's projects as part of the company's infrastructure.

4. Idempotency and filtering of duplicate messages

The so-called idempotency means that one and multiple requests for an interface should have the same consequences. Why do you need it? Calls to each interface have three possible outcomes: success, failure, and timeout. Many of the last reasons may be packet loss on the network, the request may not arrive, or the return may not be received. Therefore, there is often a retry mechanism when calling an interface, but the retry mechanism can easily lead to repeated transmission of messages, which is often unacceptable from the user level, so when designing the interface, we need to consider the idempotence of the interface. make sure that the same message is sent once and ten times will not lead to repeated arrival of the message.

5. Support for QoS quality of service rating

In fact, for the problem of message repetition on the previous point, the industry already has solutions and standards. For message arrival rate and repetition, the common means is to ensure the arrival of messages through message confirmation. The higher the requirements, the more complex the confirmation mechanism and the higher the cost. In order to strike a good balance between cost and arrival rate, the quality of service (QoS) of the messaging system is usually divided into the following three levels:

QoS 0 (At most once): "send it at most", which means it can be sent without confirmation mechanism. It is suitable for scenarios with low requirements, and can accept a certain rate of non-arrival with the lowest cost.

QoS 1 (At least once): "send at least once" means that the sender must clearly receive the acknowledgement signal from the receiver, otherwise it will be sent repeatedly. Each message needs at least two communications to confirm its arrival. It is acceptable for some messages to be retransmitted, but the cost is not high.

QoS 2 (Exactly once): "make sure to send only once" means that each message can only arrive once, and repeated arrival is not allowed. In order to achieve this goal, both parties need to communicate at least three times, and the cost is the highest.

In the face of different application scenarios, a perfect websocket service should be able to support the selection of different levels of QoS to strike a balance between cost and quality of service.

Last

Although websocket has been widely used in various systems and platforms, if you want to build a reliable, secure and stable websocket service that meets enterprise or large-scale Internet platforms, for inexperienced students, there are still many holes to step on in the specific technical practice process.

There are higher requirements for websocket services, so choosing a mature and reliable third-party web socket service is actually a lower-cost and efficient choice. As the leading third-party websocket messaging platform in China, GoEasy has been running steadily for 5 years, supporting 10 million levels of message concurrency. It is not only compatible with all common browsers, but also compatible with uni-app, various Mini Program, vue, react-native and other common front-end frameworks.

I hope this article can provide some help and reference for the students who set up websocket service for the first time. I also welcome your predecessors to criticize and correct them. at the same time, I also hope to have the opportunity to communicate with you on more technologies in the future. GoEasy official website: www.goeasy.io Wechat: GoEasySupport

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.