Communication method and system, electronic equipment and computer program product

Abstract

The invention discloses a communication method and system, electronic equipment and a computer program product. The method comprises the steps that a request forwarded by a server side through a first long connection is received, the request carries a target container group identifier of a target container group where a target client side is located, the first long connection is the long connection between the server side and a leader container group, and the target container group and the leader container group are located under the same target node of a cluster; obtaining a target container group identifier from the request, and determining a second long connection between the leader container group and the target client based on the target container group identifier; and forwarding the request to the target client through the second long connection. According to the method and the device, the technical problems that security protection is realized through containerized deployment of the clients, the number of the clients is large under the condition of large protection scale, the number of servers required by the server side communicating with the clients is large, and the cost is high in the prior art are solved.

Description

Communication methods, systems, electronic devices and computer program products Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a communication method, system, electronic device, and computer program product. Background Technology

[0002] In the field of security protection, security protection can be achieved by deploying clients on hosts. To expand the scale of protection, security protection can also be achieved by deploying clients in containers, that is, by relying on clients in containers in the Kubernetes cluster to detect threats and risks and implement protection.

[0003] In a containerized deployment scheme, a client is deployed in a container. During the protection process, the server needs to process the information reported by the client and issue corresponding instructions. The client and the server communicate frequently through long connections. Compared with the same number of host deployments, containerized deployment can virtualize multiple containers, which makes a multiple number of clients need to maintain long connections with the server.

[0004] It should be noted that the number of ports on the server is fixed. As the scale of protection increases and the number of clients increases, the number of servers required will also increase exponentially, leading to increased costs.

[0005] There is currently no effective solution to the above problems. Summary of the Invention

[0006] This application provides a communication method, system, electronic device, and computer program product to at least solve the technical problems in the related art where security protection is achieved by deploying clients in a containerized manner, resulting in a large number of clients and a large number of servers required for the server to communicate with the clients, leading to high costs.

[0007] According to one aspect of the embodiments of this application, a communication method is provided, applied to a master container group under any node in a cluster, comprising: receiving a request forwarded by a server through a first long connection, wherein the request carries a target container group identifier of the target container group where the target client is located, the first long connection is a long connection between the server and the master container group, and the target container group and the master container group are under the same target node in the cluster; obtaining the target container group identifier from the request, and determining a second long connection between the master container group and the target client based on the target container group identifier; and forwarding the request to the target client through the second long connection.

[0008] According to another aspect of the embodiments of this application, another communication method is also provided, applied to a server, comprising: initiating a request; determining a master container group under the same target node as the target container group based on the target container group identifier in the request, wherein the target container group identifier is the container group identifier of the target container group where the target client is located; determining a first long connection between the server and the master container group based on the container group identifier of the master container group; forwarding the request to the master container group through the first long connection, wherein the master container group determines a second long connection between the master container group and the target client based on the target container group identifier, and forwards the request to the target client through the second long connection.

[0009] According to another aspect of the embodiments of this application, a communication method is also provided, applied to a target client under a container group on any node in a cluster, comprising: after startup, obtaining container group information of the master container group of the node to be located from the server through a short connection, and initiating a second long connection establishment request to the master container group, wherein, after the master container group successfully establishes the second long connection, it records the target container group identifier of the container group where the client is located and the information of the client's second long connection; after establishing the second long connection with the master container group, receiving a request forwarded from the server by the master container group through the second long connection, wherein, the master container group obtains the target container group identifier from the request, determines the second long connection between the master container group and the target client based on the target container group identifier, and forwards the request to the target client through the second long connection.

[0010] According to another aspect of the embodiments of this application, a communication system is also provided, comprising: a server, configured to initiate a request, determine a master container group under the same target node as the target container group based on the target container group identifier in the request, wherein the target container group identifier is the container group identifier of the target container group where the target client is located, and determine a first long connection between the server and the master container group based on the master container group identifier, and forward the request to the master container group through the first long connection; a cluster, comprising different nodes, each node comprising a master container group and container groups managed by the master container group, wherein the master container group is configured to receive the request forwarded by the server through the first long connection, obtain the target container group identifier from the request, determine a second long connection between the master container group and the target client based on the target container group identifier, and forward the request to the target client through the second long connection; and a client, deployed in container groups managed by the master container group under different nodes of the cluster, configured to receive the request forwarded by the master container group of the node where the client is located through the second long connection.

[0011] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0012] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods in various embodiments of this application.

[0013] In this embodiment, a lord container group is set up between the client and the server, establishing a long connection between the server and the lord container group, and establishing a long connection between the client and the lord container group under its node. The server determines the lord container group under the same node as the target container group based on the target container group identifier of the target client carried in the request, and obtains the first long connection between the lord container group and the server. The server forwards the request to the lord container group through the first long connection. The lord container group determines the second long connection between the lord container group and the target client based on the target container group identifier carried in the request, and forwards the request to the target client through the second long connection. This achieves the goal of not needing to deploy a corresponding number of server servers to meet a large number of long connections when facing a large number of client long connections. Thus, it achieves the technical effect of using fewer server servers to carry long connections without reducing the number of clients. This solves the technical problem in related technologies where security protection is achieved by deploying clients in a containerized manner, but the number of clients is large and the number of servers required for communication with clients is large, resulting in high costs.

[0014] It is worth noting that the general description above and the detailed description that follow are merely for illustrative purposes and do not constitute a limitation on this application. Attached Figure Description

[0015] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0016] Figure 1 shows a hardware structure block diagram of a computer terminal (or mobile device) for implementing a communication method;

[0017] Figure 2 is a structural block diagram of a computing environment according to an embodiment of this application;

[0018] Figure 3 is a flowchart of a communication method according to an embodiment of this application;

[0019] Figure 4 is a flowchart of another communication method according to an embodiment of this application;

[0020] Figure 5 is a structural block diagram of a communication system according to an embodiment of this application;

[0021] Figure 6 is a structural block diagram of an optional communication system according to an embodiment of this application;

[0022] Figure 7 is a flowchart of establishing a long connection between the server and the lord container group according to an embodiment of this application;

[0023] Figure 8 is a flowchart of establishing a long connection between a client and a lord container group according to an embodiment of this application;

[0024] Figure 9 is a flowchart of an optional communication method according to an embodiment of this application;

[0025] Figure 10 is a flowchart of another communication method according to an embodiment of this application;

[0026] Figure 11 is a structural block diagram of a communication device according to an embodiment of the present application;

[0027] Figure 12 is a structural block diagram of another communication device according to an embodiment of this application;

[0028] Figure 13 is a structural block diagram of another communication device according to an embodiment of this application. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] To address the high costs associated with containerized client deployment for security protection, especially on large scales, which involve a large number of clients and servers communicating with them, the following approach can be adopted:

[0032] A reverse proxy layer is added between the server and the client, allowing the server to establish a long-lived connection with the reverse proxy layer. The reverse proxy layer then establishes a long-lived connection with the client through the proxy, reducing the number of connections between the server and the client. The reverse proxy layer is equipped with a reverse proxy server, so the server does not need any information from the target client and can directly access the reverse proxy server to obtain the target client's resources.

[0033] However, this method has the following problems in a container environment: When the project is deployed, the reverse proxy server is configured with a fixed IP (Internet Protocol) address of the container group and establishes a long connection with the corresponding client. If the container migrates and the IP address of the container group corresponding to the container changes, the fixed IP address of the container group and the long connection with the corresponding client will become invalid, making it impossible for the reverse proxy server to request the corresponding target client.

[0034] Therefore, this application aims to provide a solution that can solve the above-mentioned technical problems, the details of which will be described in subsequent embodiments.

[0035] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0036] For ease of description, some nouns or terms appearing in the description of the embodiments of this application shall be interpreted as follows:

[0037] k8s cluster: is short for Kubernetes, an open-source application used to manage containerized applications on multiple hosts in a cloud platform. The containerized cluster launched by this application is called a k8s cluster.

[0038] node: A node is the server where a container resides in a Kubernetes cluster.

[0039] pod: a container group, which is the smallest unit in a Kubernetes cluster and contains a group of containers.

[0040] Leader pod: The leader container group, used to associate container groups under the same node.

[0041] Long connection: A connection is established between two parties and remains open, occupying the ports of both parties.

[0042] Short connection: Both parties share a connection, and the connection is closed after communication is completed, without occupying the ports of either party.

[0043] Example 1

[0044] According to an embodiment of this application, a communication method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0045] The method embodiment provided in Embodiment 1 of this application can be executed in a mobile terminal, computer terminal, or similar computing device. Figure 1 shows a hardware structure block diagram of a computer terminal (or mobile device) for implementing a communication method. As shown in Figure 1, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in Figure 1) (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission module 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that the structure shown in Figure 1 is merely illustrative and does not limit the structure of the above-described electronic device. For example, the computer terminal 10 may also include more or fewer components than shown in Figure 1, or have a different configuration than shown in Figure 1.

[0046] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0047] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the method in the embodiments of this application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the method in the above embodiments. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0048] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0049] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0050] The hardware structure block diagram shown in Figure 1 can serve as an exemplary block diagram not only for the aforementioned computer terminal 10 (or mobile device) but also for the aforementioned server. In an optional embodiment, Figure 2 illustrates an example of using the computer terminal 10 (or mobile device) shown in Figure 1 as a computing node in the computing environment 201. Figure 2 is a structural block diagram of a computing environment according to an embodiment of this application. As shown in Figure 2, the computing environment 201 includes multiple computing nodes (such as servers) running on a distributed network (shown as 210-1, 210-2, ..., in Figure 2). Each computing node contains local processing and memory resources, and the end user 202 can remotely run applications or store data in the computing environment 201. Applications can be provided as multiple services 220-1, 220-2, 220-3, and 220-4 in the computing environment 201, representing services "A", "D", "E", and "H", respectively.

[0051] End user 202 can provide and access services through a web browser or other software application on a client. In some embodiments, the provisioning and / or requests of end user 202 can be provided to ingress gateway 230. Ingress gateway 230 may include a corresponding agent to handle the provisioning and / or requests for services (one or more services provided in computing environment 201).

[0052] The services are provided or deployed based on various virtualization technologies supported by the computing environment 201. In some embodiments, services may be provided based on virtual machine (VM)-based virtualization, container-based virtualization, and / or similar methods. VM-based virtualization can simulate a real computer by initializing a virtual machine, executing programs and applications without directly accessing any actual hardware resources. While the machine is virtualized by a virtual machine, container-based virtualization can launch containers to virtualize an entire operating system (OS), allowing multiple workloads to run on a single OS instance.

[0053] In one embodiment based on container virtualization, several containers of a service can be assembled into a Pod (e.g., a Kubernetes Pod). For example, as shown in Figure 2, service 220-2 can be equipped with one or more Pods 240-1, 240-2, ..., 240-N (collectively referred to as Pods). A Pod can include a proxy 245 and one or more containers 242-1, 242-2, ..., 242-M (collectively referred to as containers). One or more containers in a Pod handle requests related to one or more corresponding functions of the service. The proxy 245 typically controls service-related network functions such as routing and load balancing. Other services can also be equipped with similar Pods.

[0054] During operation, executing a user request from end user 202 may require calling one or more services in computing environment 201, and executing one or more functions of one service may require calling one or more functions of another service. As shown in Figure 2, service "A" 220-1 receives a user request from end user 202 from ingress gateway 230. Service "A" 220-1 can call service "D" 220-2, and service "D" 220-2 can request service "E" 220-3 to execute one or more functions.

[0055] The aforementioned computing environment can be a cloud computing environment, where resource allocation is managed by cloud services, allowing functionality development without needing to consider implementation, adjustment, or server scaling. This computing environment allows developers to execute event-responsive code without building or maintaining complex infrastructure. Services can be partitioned into a set of functions that can automatically and independently scale, rather than scaling a single hardware device to handle potential loads.

[0056] In the aforementioned operating environment, this application provides a communication method. This communication method can be applied to security protection scenarios. In such scenarios, security protection can be achieved through containerized client deployment. A client with security protection functions is deployed within a container of a Kubernetes cluster. Relying on the client within the container of the Kubernetes cluster, the system can detect whether there are any threats or risks in the running container in real time, and implement protection measures if threats or risks are detected. During this process, the server sends the information required for security protection to the client through the communication method of this embodiment, and the client reports information to the server through the same communication method.

[0057] The communication method of this application is applied to a lord container group under any node in the cluster. Figure 3 is a flowchart of the communication method according to an embodiment of this application. As shown in Figure 3, the method includes:

[0058] S32, receive the request forwarded by the server through the first long connection, wherein the request carries the target container group identifier of the target container group where the target client is located, the first long connection is a long connection between the server and the master container group, and the target container group and the master container group are under the same target node in the cluster.

[0059] In a security protection scenario, the server initiates security protection-related requests to the client. The client can be a security plugin embedded in a container in the cluster, used to detect threats and risks that exist during container operation, implement security protection, and report the threats, risks, and protection status to the server.

[0060] The server can send requests to the client via HTTP (Hypertext Transfer Protocol) or TCP (Transmission Control Protocol). This embodiment does not limit the content of the request. It can request the distribution of security protection configuration information (e.g., a list of processes to be blocked) to the target client, or request the distribution of security protection execution scripts (e.g., issuing defense instructions to terminate specific processes in the container group) to the target client, or request the acquisition of information about the container group where the target client is located, or even request the establishment of a heartbeat between the server and the target client.

[0061] Because the server and client need to communicate frequently, they need to communicate via persistent connections. After establishing a persistent connection, the server and client do not disconnect after a single connection is established, and this connection occupies the ports of both parties. To avoid an excessive number of clients when the protection scale is large, multiple servers or a large number of servers need to be set up to meet the number of persistent connections. In this embodiment, a lord container group layer is set up between the client and the server to realize communication between the client and the server. Setting up a lord container group layer means setting up a regular container group and at least one lord container group under each node of the cluster. Each container group can have multiple containers or one container. One client is implanted into a container under each container group. That is, one client is implanted under each container group. The lord container group can manage the clients implanted in the containers of the regular container groups under the same node. The lord container groups in the cluster constitute the lord container group layer.

[0062] Using a lord container group layer to achieve communication between the client and the server means establishing a long-lived connection between the server and the lord container group in the lord container group layer. The server registers the container group information of the lord containers with established long-lived connections, and establishes a long-lived connection between the client and the lord container group under its node. The server communicates with the lord container group in the lord container group layer through the established long-lived connection, and the lord container group then communicates with the client in the container under the same node through the established long-lived connection. In this way, without reducing the number of clients, fewer servers are used to carry long-lived connections.

[0063] In this embodiment, the first long connection refers to the long connection established between the server and the master container under the target node where the target container group of the target client is located. When forwarding the request, the server adds the address information of the master container group (e.g., IP address), port information and target container group identifier (e.g., pod ID) to the protocol header, and then forwards the request to the corresponding master container group through the first long connection, so that the master container group receives the request through the first long connection.

[0064] S34, obtain the target container group identifier from the request, and determine the second long connection between the lord container group and the target client based on the target container group identifier.

[0065] It should be noted that the lord container group stores the association between the container group identifier and the second long connection. The second long connection refers to the long connection between the target client under the container group indicated by the container group identifier and the lord container group. The server-forwarded request can be parsed to obtain the target container group identifier. Based on the target container group identifier and the association stored in the lord container group, the second long connection between the target client corresponding to the target container group identifier and the lord container group can be found.

[0066] S36 forwards the request to the target client via a second long connection.

[0067] It should be noted that the information in the second long connection includes the address and port information of the lord container group and the address and port information of the target client. The long connection channel reserved between the two can be determined through the information in the second long connection, and the request can be forwarded from the port of the lord container group to the port of the target client through this long connection channel.

[0068] Through the embodiments of this application, a lord container group is set up between the client and the server, establishing a long connection between the server and the lord container group, and establishing a long connection between the client and the lord container group under its node. The server determines the lord container group under the same node as the target container group based on the target container group identifier of the target client carried in the request, and obtains the first long connection between the lord container group and the server. The server forwards the request to the lord container group through the first long connection. The lord container group determines the second long connection between the lord container group and the target client based on the target container group identifier carried in the request, and forwards the request to the target client through the second long connection. This achieves the goal of not deploying a corresponding number of server servers to meet a large number of long connections when facing a large number of client long connections. Thus, it achieves the technical effect of using fewer server servers to carry long connections without reducing the number of clients. This solves the technical problem in related technologies where security protection is achieved by deploying clients in a containerized manner, but the number of clients is large and the number of servers required for communication with clients is large, resulting in high costs.

[0069] Optionally, in the communication method of this application embodiment, the lord container group stores a second association table, and determining the second long connection between the lord container group and the target client based on the target container group identifier includes: searching for information of the second long connection associated with the target container group identifier from the second association table, wherein the information of the second long connection includes the address information and port information of the lord container group and the address information and port information of the target client.

[0070] The second association table contains the container group identifier of the client managed by the lord container group, as well as the information of the long connection established between the managed client and the lord container group after startup. The long connection information includes the address information (e.g., IP address) and port information of the two communicating parties. Therefore, after obtaining the target container group identifier from the request, the information of the second long connection associated with the target container group identifier can be found in the second association table based on the target container group identifier. The address information and port information of the two communicating parties can be obtained from the information of the second long connection, thereby obtaining the long connection channel reserved between the two.

[0071] In this embodiment, a second association table is stored in the lord container group to store the container group identifier of the managed client and the client's long connection information. This allows the lord container group to quickly find the second long connection of the target client after receiving a request forwarded by the server, laying the foundation for communication between the lord container group and the target client.

[0072] The second association table is constructed based on the long connection between the lord container group and the client. Optionally, in the communication method of this application embodiment, before searching for the information of the second long connection associated with the target container group identifier in the second association table, the method further includes: responding to the long connection establishment request issued by the client managed by the lord container group after startup, establishing a long connection between the lord container group and the client; recording the container group identifier of the container group where the client is located, and recording the long connection information of the client; constructing the second association table based on the container group identifier of the container group where the client is located and the long connection information of the client, and synchronizing the container group identifier of the client connected to the lord container group to the server.

[0073] For example, establishing a long connection between the master container group and the client means that after the client starts up in the cluster, it obtains the container group information of the master container group of the node where the client is located from the server through a short connection, including address information and port information. Then, it sends a long connection establishment request to the master container group. The master container group responds to the long connection establishment request sent by the client. For example, for the TCP protocol, the two establish a long connection through a three-way handshake. After the long connection is established, they record each other's address information and port information, and at the same time, they retain the long connection channel and periodically send messages to keep the long connection alive. When using the established long connection for communication again, there is no need to perform a three-way handshake again, and the request can be sent through the existing long connection channel.

[0074] It's important to note that the lord container group can establish multiple long-lived connections with different clients, recording information about these connections. This information includes the addresses and ports of both parties, as well as the container group identifier of the client. A second association table is generated based on the long-lived connection information and container group identifiers from multiple clients. Simultaneously, the container group identifiers of the clients connected to the lord container group are synchronized with the server, along with the long-lived connection information between the lord container group and the managed clients. This updates the client management information of the lord container group on the server. Thus, when the server sends a request to a target client, after forwarding it to the lord container group responsible for managing the target client, the lord container group can find the information about the second long-lived connection between itself and the target client through the second association table. It then uses this information to determine the second long-lived connection and sends the request to the corresponding target client through that connection.

[0075] This embodiment constructs a second association table based on the container group identifier of the container group where the client is located and the client's long connection information, establishing a routing relationship between the client's container group identifier and the client's long connection. This allows the lord container group to efficiently and accurately find which long connection to use to communicate with the target client based on the identifier of the target container group and the routing relationship.

[0076] The occurrence of container drift affects the communication between the server and the client. In order for the server to find the drifted client after the container drifts, optionally, in the communication method of this application embodiment, the method further includes: responding to the long connection establishment request issued by the client that has drifted to the target node after startup, establishing a long connection between the master container group and the drifted client; updating the container group identifier of the container group where the drifted client is located, and updating the long connection information of the client; updating the second association table according to the container group identifier of the container group where the drifted client is located and the long connection information of the drifted client, and synchronizing the container group identifier of the client connected to the master container group to the server.

[0077] It should be noted that each container group in the cluster is assigned a container group IP address. This container group IP address represents the network location of the container group and generally remains unchanged during the lifecycle of the container group. However, when a container migrates to another node, its container group IP address changes, indicating that the container's network location has changed. The long-lived connection between the client in the container and the parent container group of the node where the container was located before migration will be broken, and the server will not be able to find the client through the client's container group IP address.

[0078] Therefore, in this embodiment, after a container drifts and the client in the container restarts, the server obtains the container group information of the lord container group of the node where the client is currently located (i.e., the node the container has drifted to) via a short connection. This information includes the address and port information. Then, the server initiates a long connection establishment request to the lord container group where the container is currently located. The lord container group responds to the long connection establishment request sent by the client and establishes a long connection. At the same time, the server synchronizes the container group identifier of the client connected to the lord container group with the server and synchronizes the long connection information of the lord container group and the managed clients. This updates the client management information of the lord container group on the server and records the long connection information of the clients. After a container drifts, the server can maintain a long connection with the client in the drifted container through the correct lord container group, thereby finding the drifted client and communicating with it.

[0079] This embodiment re-establishes a long connection between the client and the lord container group of the node to which the container has drifted after the container has drifted. It also updates the long connection information in the lord container group and updates the client management information in the lord container group on the server side, thereby solving the problem that the server cannot find the drifted client after the container has drifted.

[0080] There is a preset threshold for the number of clients managed by the lord container group. When establishing a long connection between the client and the lord container group, it is necessary to ensure that the number of long connections of the lord container group does not exceed the preset threshold. Optionally, in the communication method of this application embodiment, the method further includes: if it is detected that the number of clients connected to the lord container group reaches the preset threshold, a new lord container group is created under the target node, a long connection is established between the started client and the new lord container group, the new lord container group is registered in the server, and the container group identifier of the client connected to the new lord container group is recorded.

[0081] It should be noted that when setting the preset threshold, it is limited by both the number of ports on the server and the actual load performance allocated to the lord container group. Provided that it is less than the number of ports on the server (e.g., 65536), the preset threshold is flexibly determined according to the actual load performance of the lord container group.

[0082] For example, after the client starts, it obtains the preset threshold for long connections of the same node's lord container group from the server via a short connection, and also obtains the number of clients connected to the lord container group. When the number of clients connected to the lord container group reaches the preset threshold, a new lord container group is established under the current node, and a long connection is established between the new lord container group and the client. Further, the association between the client's container group identifier and the client's long connection is recorded in the new lord container group. The new lord container group synchronizes its container group information with the server via a short connection, and also synchronizes the container group identifiers of the clients connected to the new lord container group, as well as the long connection information between the new lord container group and the managed clients. The server registers the container group information of the new lord container group and records the container group identifiers and connection information of the clients connected to the new lord container group, thus updating the client management information of the lord container group.

[0083] This embodiment sets a preset threshold for long connections for the lord container group. When the number of long connections in the lord container group reaches the preset threshold, a new lord container group is created to ensure that the number of long connections in each lord container group does not exceed the preset threshold. This reduces the number of long connections on the server while taking into account the load performance of the lord container group.

[0084] The first long connection refers to the long connection established between the server and the lord container under the target node of the target container group where the target client is located. Optionally, in the communication method of this application embodiment, the first long connection is determined in the following way: the server initiates a request; the server determines the lord container group under the same target node as the target container group based on the target container group identifier in the request, wherein the target container group identifier is the container group identifier of the target container group where the target client is located; the server determines the first long connection between the server and the lord container group based on the container group identifier of the lord container group.

[0085] It should be noted that before obtaining the first long connection, a long connection between the server and the lord container group needs to be established first, and then the first long connection is obtained from the established long connections.

[0086] For example, when starting the cluster, the master container group is launched according to the nodes of the cluster to ensure that there is a master container group on each node. Then, a long connection is established between the master container group and the server. The information of the master container group is registered on the server, the information of the long connection established between the registered master container group and the server is recorded, and a first association table is constructed based on the container group identifier of the registered master container group and the information of the long connection of the registered master container group. The information of the master container group includes the address information and port information of the container group, the cluster information of the cluster where the master container group is located, etc.

[0087] Furthermore, when initiating a request, the server adds a protocol header to the request content. This header contains the target container group identifier of the target client's container group, making the request clearly identify the corresponding access target. In this way, the server uses the target container group identifier to find the registered master container group corresponding to the target container group, and then finds the first long-lived connection between the registered master container group and the server.

[0088] In this embodiment, a first association table is constructed based on the container group identifier of the lord container group and the long connection information of the lord container group. The routing relationship between the container group identifier of the lord container group and the long connection of the lord container group is established. This allows the server to efficiently and accurately determine which long connection to use to communicate with the lord container group after finding the lord container group that manages the target client based on the target container group identifier of the target client, based on the container group identifier of the lord container group and the routing relationship.

[0089] Example 2

[0090] According to an embodiment of this application, in the above-described operating environment, another communication method is provided and applied to the server. Figure 4 is a flowchart of another communication method according to an embodiment of this application. As shown in Figure 4, the method includes:

[0091] S42, initiate a request.

[0092] In a security protection scenario, the server initiates security protection-related requests to the client. The client can be a security plugin embedded in a container in the cluster, used to detect threats and risks that exist during container operation, implement security protection, and report the threats, risks, and protection status to the server.

[0093] The server can send requests to the client via HTTP or TCP protocols. This embodiment does not limit the content of the requests. The server can request the distribution of security protection configuration information to the target client (e.g., a list of processes to be intercepted), the server can request the distribution of security protection execution scripts to the target client (e.g., issuing defense instructions to terminate specific processes in the container group), the server can request the acquisition of information about the container group where the target client is located, and the server can also request the establishment of a heartbeat between the server and the target client.

[0094] When the server initiates a request, it adds a protocol header to the request content. The protocol header contains the target container group identifier (e.g., a pod ID) of the target container group where the target client is located, to indicate which client the request is sent to. Therefore, the request carries the target container group identifier of the target container group where the target client is located. The request can be parsed to obtain the target container group identifier of the target container group where the target client is located.

[0095] S44. Determine the master container group under the same target node as the target container group based on the target container group identifier in the request, where the target container group identifier is the container group identifier of the target container group where the target client is located.

[0096] It should be noted that each node in the cluster is configured with a regular container group and at least one master container group. Each container group can have multiple or one container. One client is implanted into a container under each container group. That is, one client is implanted under each container group. The master container group can manage the clients implanted in the containers of the regular container groups under the same node.

[0097] After a client establishes a persistent connection with the lord server on the same node, the server records the container group identifier of the container group to which the client belongs, as well as the client's connection information, thus recording the client management information of the lord container group. Therefore, based on the target container group identifier, the lord container group under the target node can be found from the client management information of the lord container group.

[0098] S46, determine the first long connection between the server and the lord container group based on the container group identifier of the lord container group.

[0099] It should be noted that the server stores the association between the container group identifier of the registered lord container group and the long connection information of the registered lord container group. Based on the lord container group identifier and the association stored in the server, the first long connection between the lord container group corresponding to the lord container group identifier and the server can be found.

[0100] S48, the request is forwarded to the lord container group through the first long connection, wherein the lord container group determines the second long connection between the lord container group and the target client based on the target container group identifier, and forwards the request to the target client through the second long connection.

[0101] The information in the first long connection includes the address and port information of the lord container group and the address and port information of the server. The long connection channel reserved between the two can be determined through the information in the first long connection, and the request can be forwarded from the port of the server to the port of the lord container group through the long connection channel.

[0102] It's important to note that the master container group stores the association between the container group identifier and the second long connection. The second long connection refers to the persistent connection between the target client under the container group indicated by the container group identifier and the master container group. The server-forwarded request can be parsed to obtain the target container group identifier. Based on the target container group identifier and the association stored in the master container group, the second long connection between the target client and the master container group corresponding to the target container group identifier can be found. The information in the second long connection includes the address and port information of both the master container group and the target client. This information allows the identification of the maintained long connection channel between them, and through this channel, requests can be forwarded from the master container group's port to the target client's port.

[0103] Through the embodiments of this application, a lord container group is set up between the client and the server, establishing a long connection between the server and the lord container group, and establishing a long connection between the client and the lord container group under its node. The server determines the lord container group under the same node as the target container group based on the target container group identifier of the target client carried in the request, and obtains the first long connection between the lord container group and the server. The server forwards the request to the lord container group through the first long connection. The lord container group determines the second long connection between the lord container group and the target client based on the target container group identifier carried in the request, and forwards the request to the target client through the second long connection. This achieves the goal of not deploying a corresponding number of server servers to meet a large number of long connections when facing a large number of client long connections. Thus, it achieves the technical effect of using fewer server servers to carry long connections without reducing the number of clients. This solves the technical problem in related technologies where security protection is achieved by deploying clients in a containerized manner, but the number of clients is large and the number of servers required for communication with clients is large, resulting in high costs.

[0104] Optionally, in the communication method of this application embodiment, the server stores a first association table, and determining the first long connection between the server and the lord container group based on the container group identifier of the lord container group includes: searching for information on the first long connection associated with the container group identifier of the lord container group from the first association table, wherein the information on the first long connection includes the address information and port information of the lord container group and the address information and port information of the server; and determining the first long connection based on the information on the first long connection.

[0105] The first association table contains the container group identifier of the master container group and the information of the long connection established between the master container group and the server. The information of the long connection includes the address information (e.g., IP address) and port information of the two communicating parties. Therefore, after finding the master container group under the target node from the client management information of the master container group based on the target container group identifier, the information of the first long connection associated with the master container group identifier can be found in the first association table based on the master container group identifier. The address information and port information of the two communicating parties can be obtained from the information of the first long connection, thereby obtaining the long connection channel reserved between the two.

[0106] In this embodiment, the server stores a first association table containing the container group identifier of the lord container group and the information of the long connection of the lord container group. This allows the server to quickly find the first long connection of the lord container group under the same node as the target client after initiating a request, laying the foundation for communication between the lord container group and the server.

[0107] The first association table is constructed based on the long connection between the lord container group and the server. Optionally, in the communication method of this application embodiment, before searching for the information of the first long connection associated with the container group identifier of the lord container group in the first association table, the method further includes: responding to a long connection establishment request initiated by a newly created lord container group in the cluster, establishing a long connection between the server and the newly created lord container group; registering the newly created lord container group on the server, recording the container group identifier of the client connected to the registered lord container group, and recording the information of the long connection of the registered lord container group; and constructing the first association table based on the container group identifier of the registered lord container group and the information of the long connection of the registered lord container group.

[0108] For example, establishing a long connection between the server and the newly created master container group means that when starting the cluster, the master container group is started according to the nodes of the cluster (the master container group can be started through a specific image, and like other ordinary container groups, it does not require special permissions). This ensures that there is a master container group on each node. Then, the master container group initiates a long connection establishment request to the server. The server responds to the long connection establishment request sent by the master container group. For example, for the TCP protocol, the two establish a long connection through a three-way handshake. After the long connection is established, they record each other's address information and port information, and at the same time, they retain the long connection channel and periodically send messages to keep the long connection alive. When using the established long connection for communication again, there is no need to perform a three-way handshake again, and the request can be sent through the existing long connection channel.

[0109] It's important to note that the server can establish multiple long-lived connections with different master container groups. After establishing these connections, the server registers the master container group information (including address and port information, cluster information, etc.) and records the long-lived connection information for each registered master container group. This information includes the address and port information of both parties, the container group identifier, and a first association table is generated based on the long-lived connection information and container group identifiers for each registered master container group. Thus, when the server wants to send a request to a target client, it can find the first long-lived connection information between the master container group and the server through the first association table, then determine the first long-lived connection through the second long-lived connection information, and send the request to the corresponding master container group via the first long-lived connection. The master container group then forwards the request to the target client.

[0110] In this embodiment, a first association table is constructed based on the container group identifier of the lord container group and the long connection information of the lord container group. The routing relationship between the container group identifier of the lord container group and the long connection of the lord container group is established. This allows the server to efficiently and accurately determine which long connection to use to communicate with the lord container group after finding the lord container group that manages the target client based on the target container group identifier of the target client, based on the container group identifier of the lord container group and the routing relationship.

[0111] The occurrence of container drift affects the communication between the server and the client. In order for the server to find the drifted client after the container drifts, optionally, in the communication method of this application embodiment, the method further includes: responding to the update instruction issued by the destination lord container group corresponding to the drifted container in the cluster, updating the container group information of the destination lord container group in the server, and updating the container group identifier of the client connected to the destination lord container group.

[0112] It should be noted that each container group in the cluster is assigned a container group IP address. This container group IP address represents the network location of the container group and generally remains unchanged during the lifecycle of the container group. However, when a container migrates to another node, its container group IP address changes, indicating that the container's network location has changed. The long-lived connection between the client in the container and the parent container group of the node where the container was located before migration will be broken, and the server will not be able to find the client through the client's container group IP address.

[0113] Therefore, in this embodiment, after a container drifts and the client in the container restarts, the container group information of the lord container group of the current node where the client is located (i.e., the node the container has drifted to) is obtained from the server via a short connection. This information includes address and port information. Then, a long connection establishment request is initiated to the lord container group where the container is currently located. The lord container group responds to the long connection establishment request sent by the client and establishes a long connection. At the same time, it synchronizes the container group identifier of the client connected to the lord container group, the long connection information of the lord container group and the managed clients to the server via an update instruction. The server responds to the update instruction issued by the destination lord container group corresponding to the drifted container in the cluster, updates the container group information of the destination lord container group, updates the container group identifier of the client connected to the destination lord container group, and the long connection information of the client in the server. After a container drifts, the server can maintain a long connection with the client in the drifted container through the correct lord container group, thereby finding the drifted client and communicating with it.

[0114] This embodiment re-establishes a long connection between the client and the lord container group of the node to which the container has drifted after the container has drifted. The client management information of the lord container group is updated on both the lord container group and the server, thereby solving the problem that the server cannot find the drifted client after the container has drifted.

[0115] Example 3

[0116] According to another aspect of the embodiments of this application, a communication system is also provided. FIG5 is a structural block diagram of the communication system according to the embodiments of this application. As shown in FIG5, the system includes:

[0117] The server initiates requests and determines the master container group under the same target node as the target container group based on the target container group identifier in the request. The target container group identifier is the container group identifier of the target container group where the target client is located. Based on the master container group identifier, the server determines the first long connection between the server and the master container group and forwards the request to the master container group through the first long connection.

[0118] In this embodiment, the server can send requests to the client via HTTP or TCP protocols. The content of the requests is not limited. For example, it can request the distribution of security protection configuration information (e.g., a list of processes to be intercepted) to the target client, or it can request the distribution of security protection execution scripts (e.g., issuing defense instructions to terminate specific processes in the container group) to the target client, or it can request the acquisition of information about the container group where the target client is located, or it can request the establishment of a heartbeat between the server and the target client.

[0119] In related technologies, the number of long connections may be insufficient because the server may need to communicate with a large number of clients. Therefore, this embodiment sets up a lord container group layer between the client and the server to realize communication between the client and the server. That is, a long connection is established between the server and the lord container group in the lord container group layer. The server registers the container group information of the lord containers with established long connections and establishes a long connection between the client and the lord container group under its node. The server communicates with the lord container group in the lord container group layer through the established long connection. The lord container group then communicates with the clients in the containers under the same node through the established long connection. Thus, without reducing the number of clients, fewer servers are used to carry long connections.

[0120] In this process, the server adds a protocol header to the request content when initiating a request. This header contains the target container group identifier of the target client's container group, indicating which client the request is directed to. Therefore, by carrying the target container group identifier of the target client's container group in the service, the request can be parsed to obtain the target container group identifier of the target client's container group. The server stores the association between the container group identifiers of registered master container groups and the information of long-lived connections to registered master container groups. Based on the master container group identifier and the association stored on the server, the first long-lived connection between the master container group corresponding to the master container group identifier and the server can be found.

[0121] The cluster consists of different nodes, each node containing a master container group and container groups managed by the master container group. The master container group receives requests forwarded by the server through a first long connection, obtains the target container group identifier from the request, and determines a second long connection between the master container group and the target client based on the target container group identifier. The request is then forwarded to the target client through the second long connection.

[0122] It should be noted that each node in the cluster is configured with a regular container group and at least one master container group. Each container group can have multiple containers or only one container. One client is implanted into a selected container within each container group. That is, one client is implanted into each container group. The master container group can manage the clients implanted in containers within the regular container groups on the same node. The master container group establishes a connection with the server, while clients under other regular container groups establish connections with the master container group. The master container group records which container groups it manages, records the container group identifier of the clients under the managed container groups, and the information of the client's long connection. The second long connection refers to the long connection between the target client under the container group indicated by the container group identifier and the master container group.

[0123] The overlord container group can parse the requests forwarded by the server, obtain the target container group identifier, and, based on the target container group identifier and the association stored in the overlord container group, find the second long connection between the target client and the overlord container group corresponding to the target container group identifier. The information in the second long connection includes the address and port information of the overlord container group and the target client. Through the information in the second long connection, the long connection channel maintained between the two can be determined, and through this long connection channel, the request can be forwarded from the port of the overlord container group to the port of the target client.

[0124] The client is deployed in the container group managed by the lord container group on different nodes of the cluster. It is used to receive requests forwarded by the lord container group on the node through a second long connection.

[0125] In the context of security protection, the client can be a security plugin embedded in a container within the cluster. This plugin receives security protection requests initiated by the master container group, detects threats and risks present during container operation, implements security protection, and reports the threats, risks, and protection status to the server. For example, if the client detects a malicious intrusion, it can locate the master container group on its node and send malicious file information to the master container group via a second long connection. The master container group then reports the malicious file information to the master container group via a first long connection.

[0126] Figure 6 is a structural block diagram of an optional communication system according to an embodiment of this application. As shown in Figure 6, the server and client form a federated connection mode through the leader pod (master container group). That is, the server connects to the leader pod (master container group), and the leader pod connects to the clients in the container group (pod) within the management domain. The server establishes long-lived connections with only 5 clients through 2 long-lived connections, which can reduce the number of servers. The leader pod is the master container group of the clients in other pods under the corresponding node in the Kubernetes cluster. In the Kubernetes cluster, the leader pod can be started by a specific image and does not require special permissions like other pods. The leader pod is responsible for establishing long-lived connections with clients under the domain, and the server only needs to establish long-lived connections with the leader pod to establish long-lived connections with all clients. Thus, as the number of clients in the container grows, there is no need for a large number of servers to meet the number of long-lived connections. Without reducing the number of clients, fewer servers are used to carry long-lived connections.

[0127] The server determines the first long connection between the server and the lord container group based on the container group identifier of the lord container group from the first association table stored on the server. The first association table is constructed based on the long connection between the lord container group and the server. Optionally, in the communication system of this application embodiment, after the cluster starts, lord container groups are created on different nodes respectively, and the first long connection between the lord container group and the server is established respectively. The lord container group is registered on the server, the container group identifier of the client connected to the lord container group is recorded, the information of the first long connection of the lord container group is recorded, and the first association table is constructed based on the container group identifier of the lord container group and the information of the long connection of the lord container group.

[0128] Figure 7 is a flowchart illustrating the establishment of a long connection between the server and the master container group according to an embodiment of this application. As shown in Figure 7, the steps include: when starting the Kubernetes cluster, starting the master container group according to the nodes of the cluster (the master container group can be started using a specific image, and like other ordinary container groups, it does not require special permissions), ensuring that each node has a master container group. Then, the master container group establishes a long connection with the server. The master container group initiates a long connection establishment request to the server, and the server responds to the long connection establishment request sent by the master container group. For example, for the TCP protocol, the two establish a long connection through a three-way handshake, mutually recording each other's address information and port information, while maintaining the long connection channel and periodically sending messages to keep the long connection alive. After establishing the long connection between the master container group and the server, the information of the master container group is registered on the server (the information of the master container group includes the address information and port information of the container group, the cluster information of the cluster where the master container group is located, etc.).

[0129] It's important to note that the server can establish multiple long-lived connections with different lord container groups, recording information about these connections for each registered lord container group. This information includes the addresses and ports of both parties, the container group identifier of the lord container group, and a first association table is generated based on the long-lived connection information and container group identifiers from the multiple registered lord container groups. Thus, when the server wants to send a request to the target client, it can find the first long-lived connection information between the lord container group and the server through the first association table, then determine the first long-lived connection through the second long-lived connection information, and send the request to the corresponding lord container group via the first long-lived connection, which then forwards it to the target client.

[0130] In this embodiment, a first association table is constructed based on the container group identifier of the lord container group and the long connection information of the lord container group. The routing relationship between the container group identifier of the lord container group and the long connection of the lord container group is established. This allows the server to efficiently and accurately determine which long connection to use to communicate with the lord container group after finding the lord container group that manages the target client based on the target container group identifier of the target client, based on the container group identifier of the lord container group and the routing relationship.

[0131] The second association table, which determines the second long connection between the lord container group and the target client based on the target container group identifier, is constructed based on the long connection between the lord container group and the client. Optionally, after the client starts, it obtains the lord container group of its own node from the server through a short connection and establishes a second long connection with the lord container group of its own node. After the lord container group of its own node successfully establishes the second long connection, it records the target container group identifier of the container group where the client is located and the information of the client's second long connection. Based on the container group identifier of the container group where the client is located and the information of the client's second long connection, the second association table is constructed, and the container group identifier of the client connected to the lord container group is recorded in the server.

[0132] In one alternative implementation, after initial startup, clients in the cluster can obtain container group information, including address and port information, of the master container group of the node where the client resides from the server via a short connection. Then, they can initiate a long connection establishment request to the master container group. The master container group responds to the long connection establishment request sent by the client. For example, for the TCP protocol, the two establish a long connection through a three-way handshake. After the long connection is established, they record each other's address and port information, and retain the long connection channel. They periodically send messages to keep the long connection alive. When communicating again using the established long connection, there is no need to perform a three-way handshake again; the request can be sent through the existing long connection channel.

[0133] It's important to note that the lord container group can establish multiple long-lived connections with different clients, recording information about these connections. This information includes the addresses and ports of both parties, as well as the container group identifier of the client. A second association table is generated based on the long-lived connection information and container group identifiers from multiple clients. Simultaneously, the container group identifiers of the clients connected to the lord container group are synchronized with the server, along with the long-lived connection information between the lord container group and the clients it manages. This updates the client management information of the lord container group on the server. Thus, when the server wants to send a request to a target client, after forwarding it to the lord container group responsible for managing the target client, it can find the information about the second long-lived connection between the lord container group and the target client through the second association table. Then, it uses this information to determine the second long-lived connection and sends the request to the corresponding target client through that connection.

[0134] This embodiment constructs a second association table based on the container group identifier of the container group where the client is located and the client's long connection information, establishing a routing relationship between the client's container group identifier and the client's long connection. This allows the lord container group to efficiently and accurately find which long connection to use to communicate with the target client based on the identifier of the target container group and the routing relationship.

[0135] In another alternative implementation, after a container migrates and restarts, the client in the cluster can obtain the container group information of the master container group of the node where the client is currently located (i.e., the node the container has migrated to) from the server via a short connection. This information includes the address and port information. Then, the client initiates a long connection establishment request to the master container group where the container is currently located. The master container group responds to the long connection establishment request sent by the client and establishes a long connection. At the same time, it synchronizes the container group identifier of the client connected to the master container group with the server, and synchronizes the long connection information of the master container group and the managed clients. This allows the server to update the client management information of the master container group and record the client's long connection information. After a container migrates, the server can maintain a long connection with the client in the migrated container through the correct master container group, thereby finding the migrated client and communicating with it.

[0136] This embodiment re-establishes a long connection between the client and the lord container group of the node to which the container has drifted after the container has drifted. It also updates the long connection information in the lord container group and updates the client management information in the lord container group on the server side, thereby solving the problem that the server cannot find the drifted client after the container has drifted.

[0137] It should be noted that the lord container group is launched independently and contains one or more containers. There is a preset threshold for the number of clients managed by the lord container group; in this embodiment, one threshold can be set. If there are many clients under the node where the lord container group resides, the configuration can be expanded to include multiple containers in the lord container group. Alternatively, multiple lord container groups can be launched. When setting the preset threshold, it is limited by both the number of ports on the server and the actual load performance allocated to the lord container group. Provided that the number of ports is less than the number of ports on the server (e.g., 65536), the preset threshold is flexibly determined based on the actual load performance of the lord container group.

[0138] When establishing a long connection between a client and a lord container group, it is necessary to ensure that the number of long connections in the lord container group does not exceed a preset threshold. Figure 8 is a flowchart of establishing a long connection between a client and a lord container group according to an embodiment of this application. As shown in Figure 8, after the client starts, the client obtains the container group information of the lord container group on the same node from the server through a short connection, including the preset threshold for long connections and the number of clients already managed by the lord container group (clients already managed by the lord container group refer to clients that have established long connections with the lord container group). If the number of clients managed by the lord container group has not reached the preset threshold, a long connection is established between the lord container group and the client. If the number of clients managed by the lord container group has reached the preset threshold, a new lord container group is launched on the current node, and a new long connection is established between the lord container group and the client.

[0139] After establishing a long connection between the client and the master container group, the master container group records the container group identifier (which can be a Pod ID) of the container group where the client resides and the long connection information of the client. It also updates the master container group information and the container group identifier of the managed client in the client. Specifically, the master container group synchronizes the container group information of the master container group, the container group identifier of the client connected to the master container group, and the long connection information between the master container group and the managed client to the server through a short connection. The server registers the new container group information of the master container group and records the container group identifier of the client connected to the master container group and the client's connection information, thereby updating the client management information of the master container group.

[0140] This embodiment sets a preset threshold for long connections for the lord container group. When the number of long connections in the lord container group reaches the preset threshold, a new lord container group is created to ensure that the number of long connections in each lord container group does not exceed the preset threshold. This reduces the number of long connections on the server while taking into account the load performance of the lord container group.

[0141] In the communication system of this application embodiment, a communication method is also provided. FIG9 is a flowchart of an optional communication method according to an embodiment of this application. As shown in FIG9, the method includes:

[0142] The server initiates a request. This request includes the pod ID of the container group the client is currently in.

[0143] The server retrieves the leader pod information based on the current client's pod ID. The server stores the registered leader pods and the pod IDs of the container groups where the clients managed by the leader pods reside.

[0144] The server acquires a persistent connection to the leader pod and initiates communication with it through this connection, including the pod ID in the communication request. The server stores a list of registered leader pods and established persistent connections with it.

[0145] The leader pod retrieves the current persistent connection to the client based on the pod ID and initiates communication with the client. The leader pod stores the established persistent connections between the leader pod and the client.

[0146] The client can accept requests and also report the execution information of the requests to the server based on the established links.

[0147] This embodiment addresses two key issues. First, by adding a leader pod forwarding layer to both the server and client, the request carries the pod ID of the client's container. The server can locate the corresponding leader pod based on the pod ID and find the long-lived connection between the server and the leader pod. It then forwards the request to the leader pod through this long-lived connection. Similarly, the leader pod can find the long-lived connection between the client and the leader pod based on the pod ID and forward the request to the client through this long-lived connection. This reduces the number of servers required to handle long-lived connections. Second, both the server and the leader pod forwarding layer consistently maintain the correct long-lived connections between the server and the leader pod, as well as the long-lived connection between the leader pod and the client, and store the pod ID of the client's pod. Even if a container migrates, the server can still find the requesting client using the correct link information.

[0148] Example 4

[0149] According to an embodiment of this application, a communication method is also provided, applied to a target client under a container group on any node in a cluster. Figure 10 is a flowchart of another communication method according to an embodiment of this application. As shown in Figure 10, the method includes:

[0150] S1002 After startup, the system obtains the container group information of the lord container group of the node through a short connection from the server and initiates a second long connection establishment request to the lord container group. After the lord container group successfully establishes the second long connection, it records the target container group identifier of the container group where the client is located and the information of the client's second long connection.

[0151] It should be noted that each node in the cluster is configured with a regular container group and at least one master container group. Each container group can have multiple or one container. One client is implanted into a container under each container group. That is, one client is implanted under each container group. The master container group can manage the clients implanted in the containers of the regular container groups under the same node.

[0152] In this process, after a client in a regular container group in the cluster starts up, it obtains the container group information of the master container group of the node where the client is located from the server through a short connection, including address information and port information. Then, it initiates a long connection establishment request to the master container group. The master container group responds to the long connection establishment request sent by the client. For example, for the TCP protocol, the two establish a long connection through a three-way handshake. After the long connection is established, they record each other's address information and port information, and at the same time, they maintain the long connection channel and periodically send messages to keep the long connection alive. When using the established long connection for communication again, there is no need to perform a three-way handshake again, and the request can be sent through the existing long connection channel.

[0153] It should be noted that the lord container group can establish multiple long connections with different clients, record the long connection information of different clients, including the address information and port information of both parties, and record the container group identifier of the container group to which the client belongs. A second association table is generated based on the long connection information of multiple clients and the container group identifier. At the same time, the container group identifier of the client connected to the lord container group is synchronized with the server, and the long connection information of the lord container group and the managed clients is synchronized, so as to update the client management information of the lord container group on the server.

[0154] S1004. After establishing a second long connection with the lord container group, the lord container group receives a request forwarded from the server through the second long connection. The lord container group obtains the target container group identifier from the request, determines the second long connection between the lord container group and the target client based on the target container group identifier, and forwards the request to the target client through the second long connection.

[0155] It should be noted that the server and client need to communicate frequently, and they need to communicate through long-lived connections. For example, in a security protection scenario, the server is used to send security protection-related requests to the client.

[0156] If the server wants to send a request to the target client, it can first forward the request to the lord container group that manages the target client. The lord container group can find the information of the second long connection between the lord container group and the target client through the second association table, and then determine the second long connection through the information of the second long connection, and send the request to the corresponding target client through the second long connection.

[0157] In this way, the target client can receive the request forwarded by the lord container group through the second long connection, respond to the request, and send the execution result back to the lord container group through the second long connection. The lord container group then sends it to the server, so that the server can know the execution result of the request.

[0158] Through the embodiments of this application, a lord container group is set up between the client and the server, establishing a long connection between the server and the lord container group, and establishing a long connection between the client and the lord container group under its node. The server determines the lord container group under the same node as the target container group based on the target container group identifier of the target client carried in the request, and obtains the first long connection between the lord container group and the server. The server forwards the request to the lord container group through the first long connection. The lord container group determines the second long connection between the lord container group and the target client based on the target container group identifier carried in the request, and forwards the request to the target client through the second long connection. This achieves the goal of not deploying a corresponding number of server servers to meet a large number of long connections when facing a large number of client long connections. Thus, it achieves the technical effect of using fewer server servers to carry long connections without reducing the number of clients. This solves the technical problem in related technologies where security protection is achieved by deploying clients in a containerized manner, but the number of clients is large and the number of servers required for communication with clients is large, resulting in high costs.

[0159] Example 5

[0160] According to an embodiment of this application, a communication device for implementing the above-described communication method is also provided, which is applied to a lord container group under any node in a cluster. FIG11 is a structural block diagram of the communication device according to an embodiment of this application. As shown in FIG11, the device includes: a first receiving unit 1102, a first acquiring unit 1104, and a first forwarding unit 1106.

[0161] The first receiving unit 1102 is used to receive a request forwarded by the server through the first long connection. The request carries the target container group identifier of the target container group where the target client is located. The first long connection is a long connection between the server and the master container group. The target container group and the master container group are under the same target node in the cluster.

[0162] The first acquisition unit 1104 is used to obtain the target container group identifier from the request and determine the second long connection between the lord container group and the target client based on the target container group identifier.

[0163] The first forwarding unit 1106 is used to forward the request to the target client through the second long connection.

[0164] Optionally, in the communication device of this application embodiment, the lord container group stores a second association table, and the first acquisition unit 1104 includes: a first search module, used to search for information of the second long connection associated with the target container group identifier from the second association table, wherein the information of the second long connection includes the address information and port information of the lord container group and the address information and port information of the target client.

[0165] Optionally, in the communication device of this application embodiment, the device further includes: a first response unit, configured to respond to a long connection establishment request issued by the client managed by the lord container group after startup, and establish a long connection between the lord container group and the client before searching for the information of the second long connection associated with the target container group identifier in the second association table; a first recording unit, configured to record the container group identifier of the container group where the client is located, and record the long connection information of the client; and a first construction unit, configured to construct the second association table according to the container group identifier of the container group where the client is located and the long connection information of the client, and synchronize the container group identifier of the client connected to the lord container group to the server.

[0166] Optionally, in the communication device of this application embodiment, the device further includes: a second response unit, configured to respond to a long connection establishment request issued by a client that has migrated to the target node after startup, and establish a long connection between the lord container group and the client that has migrated; a first update unit, configured to update the container group identifier of the container group where the client that has migrated is located, and update the long connection information of the client; and a second update unit, configured to update a second association table according to the container group identifier of the container group where the client that has migrated is located and the long connection information of the client that has migrated, and synchronize the container group identifier of the client connected to the lord container group to the server.

[0167] Optionally, in the communication device of this application embodiment, the device further includes: a new creation unit, configured to create a new lord container group under the target node when the number of clients connected to the lord container group reaches a preset threshold, establish a long connection between the started client and the new lord container group, register the container group information of the new lord container group in the server, and record the container group identifier of the client connected to the new lord container group.

[0168] Optionally, in the communication device of this application embodiment, the first long connection is determined in the following way: the server initiates a request; the server determines the lord container group under the target node according to the target container group identifier in the request; the server determines the first long connection between the server and the lord container group based on the container group identifier of the lord container group.

[0169] It should be noted that the preferred implementation schemes involved in the above embodiments of this application are the same as the schemes, application scenarios and implementation processes provided in Embodiment 1, but are not limited to the schemes provided in Embodiment 1.

[0170] Example 6

[0171] According to an embodiment of this application, a communication device for implementing the above-described communication method is also provided, which is applied to a server. FIG12 is a structural block diagram of another communication device according to an embodiment of this application. As shown in FIG12, the device includes: a second acquisition unit 1202, a first determination unit 1204, a second determination unit 1206, and a second forwarding unit 1208.

[0172] The second acquisition unit 1202 is used to initiate a request.

[0173] The first determining unit 1204 is used to determine the lord container group under the same target node as the target container group based on the target container group identifier in the request, wherein the target container group identifier is the container group identifier of the target container group where the target client is located;

[0174] The third determining unit 1206 is used to determine the first long connection between the server and the lord container group based on the container group identifier of the lord container group.

[0175] The second forwarding unit 1208 is used to forward the request to the master container group through the first long connection, wherein the master container group determines the second long connection between the master container group and the target client based on the target container group identifier, and forwards the request to the target client through the second long connection.

[0176] Optionally, in the communication device of this application embodiment, the server stores a first association table, and the second acquisition unit 1202 includes: a first lookup module, used to look up information of a first long connection associated with the container group identifier of the lord container group from the first association table, wherein the information of the first long connection includes the address information and port information of the lord container group and the address information and port information of the server; and a determination module, used to determine the first long connection based on the information of the first long connection.

[0177] Optionally, in the communication device of this application embodiment, the device further includes: a third response unit, configured to respond to a long connection establishment request initiated by a newly created lord container group in the cluster and establish a long connection between the server and the newly created lord container group before searching for information on the first long connection associated with the container group identifier of the lord container group from the first association table; a second recording unit, configured to register the container group information of the newly created lord container group on the server, record the container group identifier of the client connected to the lord container group that has been registered, and record the information on the long connection of the lord container group that has been registered, wherein the container group information includes at least the container group identifier of the lord container group that has been registered; and a second construction unit, configured to construct the first association table based on the container group identifier of the lord container group that has been registered and the information on the long connection of the lord container group that has been registered.

[0178] Optionally, in the communication device of this application embodiment, the device further includes: a fourth response unit, configured to respond to an update instruction issued by the destination lord container group corresponding to the container that has drifted in the cluster, update the container group information of the destination lord container group on the server, and update the container group identifier of the client connected to the destination lord container group.

[0179] It should be noted that the preferred implementation schemes involved in the above embodiments of this application are the same as the schemes, application scenarios and implementation processes provided in Embodiment 2, but are not limited to the schemes provided in Embodiment 2.

[0180] Example 7

[0181] According to an embodiment of this application, a communication device for implementing the above-described communication method is also provided, which is applied to a server. FIG13 is a structural block diagram of another communication device according to an embodiment of this application. As shown in FIG13, the device includes: an initiating unit 1302 and a second receiving unit 13204.

[0182] The initiating unit 1302 is used to obtain the container group information of the lord container group of the node after startup through a short connection from the server, and initiate a second long connection establishment request to the lord container group. After the lord container group successfully establishes the second long connection, it records the target container group identifier of the container group where the client is located and the information of the client's second long connection.

[0183] The second receiving unit 13204 is used to receive a request from the server forwarded by the lord container group through the second long connection after establishing a second long connection with the lord container group. The lord container group obtains the target container group identifier from the request, determines the second long connection between the lord container group and the target client based on the target container group identifier, and forwards the request to the target client through the second long connection.

[0184] It should be noted that the preferred implementation schemes involved in the above embodiments of this application are the same as the schemes, application scenarios and implementation processes provided in Embodiment 4, but are not limited to the schemes provided in Embodiment 4.

[0185] Example 8

[0186] Embodiments of this application may provide an electronic device, which may be any one of a group of electronic devices. Optionally, in this embodiment, the aforementioned electronic device may also be replaced by a terminal device such as a mobile terminal.

[0187] Optionally, in this embodiment, the aforementioned electronic device may be located in at least one of a plurality of network devices in a computer network.

[0188] In this embodiment, the computer terminal described above can execute the program code in the method.

[0189] Optionally, the electronic device may include one or more processors, memory, memory controller, and peripheral interface, wherein the peripheral interface is connected to a radio frequency module, an audio module, and a display.

[0190] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the methods in the above embodiments. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to electronic devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0191] The processor can invoke information and applications stored in the memory through the transmission device to execute the steps of the communication method in any of the above embodiments.

[0192] Those skilled in the art will understand that electronic devices can also be smartphones, tablets, PDAs, mobile internet devices (MIDs), PADs, and other terminal devices. This figure does not limit the structure of the aforementioned electronic devices. For example, electronic devices may include more or fewer components (such as network interfaces, display devices, etc.), or have different configurations than those shown in this figure.

[0193] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0194] Example 9

[0195] Embodiments of this application also provide a computer-readable storage medium. Optionally, in this embodiment, the computer-readable storage medium can be used to store program code executed by the method provided in the above embodiments.

[0196] Optionally, in this embodiment, the storage medium may be located in any one of the electronic devices in the group of electronic devices in the computer network, or in any one of the mobile terminals in the group of mobile terminals.

[0197] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for performing the steps of the communication method of any of the above embodiments.

[0198] Example 10

[0199] Embodiments of this application also provide a computer program product. Optionally, the computer program product may include a non-volatile computer-readable storage medium, which can be used to store a computer program that, when executed by a processor, implements the method provided in the above embodiments.

[0200] Example 11

[0201] Embodiments of this application also provide a computer program. Optionally, in this embodiment, when the computer program is executed by a processor, it implements the method provided in the above embodiments.

[0202] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0203] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0204] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A communication method, characterized in that, An application to a master container group under any node in a cluster includes: receiving a request forwarded by a server through a first long connection, wherein the request carries a target container group identifier of the target container group where the target client is located, the first long connection being a long connection between the server and the master container group, and the target container group and the master container group being under the same target node in the cluster; obtaining the target container group identifier from the request, and determining a second long connection between the master container group and the target client based on the target container group identifier; and forwarding the request to the target client through the second long connection.

2. The method according to claim 1, characterized in that, The lord container group stores a second association table. Determining the second long connection between the lord container group and the target client based on the target container group identifier includes: searching for information about the second long connection associated with the target container group identifier in the second association table, wherein the information about the second long connection includes the address information and port information of the lord container group and the address information and port information of the target client.

3. The method according to claim 2, characterized in that, Before searching for the information of the second long connection associated with the target container group identifier in the second association table, the method further includes: responding to a long connection establishment request issued by a client under the target node after startup, establishing a long connection between the lord container group and the client; recording the container group identifier of the container group where the client is located, and recording the long connection information of the client; constructing the second association table based on the container group identifier of the container group where the client is located and the long connection information of the client, and synchronizing the container group identifier of the client connected to the lord container group to the server.

4. The method according to claim 2, characterized in that, The method further includes: responding to a long connection establishment request issued by a client that has migrated to the target node after startup, establishing a long connection between the lord container group and the client that has migrated; updating the container group identifier of the container group where the client that has migrated is located, and updating the long connection information of the client; updating the second association table according to the container group identifier of the container group where the client that has migrated is located and the long connection information of the client that has migrated, and synchronizing the container group identifier of the client connected to the lord container group to the server.

5. The method according to claim 3 or 4, characterized in that, The method further includes: if the number of clients connected to the lord container group reaches a preset threshold, then a new lord container group is created under the target node, a long connection is established between the started client and the new lord container group, the new lord container group is registered in the server, and the container group identifier of the client connected to the new lord container group is recorded.

6. The method according to claim 1, characterized in that, The first long connection is determined in the following way: the server initiates the request; the server determines the lord container group under the target node based on the target container group identifier in the request; the server determines the first long connection between the server and the lord container group based on the container group identifier of the lord container group.

7. A communication method, characterized in that, Applied to the server side, the method includes: initiating a request; determining a lord container group under the same target node as the target container group based on the target container group identifier in the request, wherein the target container group identifier is the container group identifier of the target container group where the target client is located; determining a first long connection between the server and the lord container group based on the container group identifier of the lord container group; forwarding the request to the lord container group through the first long connection, wherein the lord container group determines a second long connection between the lord container group and the target client based on the target container group identifier, and forwards the request to the target client through the second long connection.

8. The method according to claim 7, characterized in that, The server stores a first association table. Determining the first long connection between the server and the lord container group based on the container group identifier of the lord container group includes: searching for information about the first long connection associated with the container group identifier of the lord container group in the first association table, wherein the information about the first long connection includes the address information and port information of the lord container group and the address information and port information of the server; and determining the first long connection based on the information about the first long connection.

9. The method according to claim 8, characterized in that, Before searching for information about the first long-lived connection associated with the container group identifier of the lord container group in the first association table, the method further includes: responding to a long-lived connection establishment request initiated by a newly created lord container group in the cluster, establishing a long-lived connection between the server and the newly created lord container group; registering the newly created lord container group on the server, recording the container group identifier of the client connected to the registered lord container group, and recording the long-lived connection information of the registered lord container group; and constructing the first association table based on the container group identifier of the registered lord container group and the long-lived connection information of the registered lord container group.

10. The method according to claim 9, characterized in that, The method further includes: responding to an update instruction issued by the destination lord container group corresponding to the container that has drifted in the cluster, updating the container group information of the destination lord container group on the server, and updating the container group identifier of the client connected to the destination lord container group.

11. A communication method, characterized in that, This method is applied to a target client located in a container group on any node in a cluster. After startup, the client obtains container group information of the master container group of its node from the server via a short connection and initiates a second long connection establishment request to the master container group. After the second long connection is successfully established, the master container group records the target container group identifier of the client's container group and the client's second long connection information. After establishing the second long connection with the master container group, the client receives a request forwarded from the server by the master container group via the second long connection. The master container group obtains the target container group identifier from the request, determines the second long connection between the master container group and the target client based on the target container group identifier, and forwards the request to the target client via the second long connection.

12. A communication system, characterized in that, include: The server initiates a request, determines the lord container group under the same target node as the target container group based on the target container group identifier in the request, wherein the target container group identifier is the container group identifier of the target container group where the target client is located, and determines a first long connection between the server and the lord container group based on the lord container group's container group identifier, and forwards the request to the lord container group through the first long connection; the cluster includes different nodes, each node including the lord container group and container groups managed by the lord container group, wherein the lord container group receives the request forwarded by the server through the first long connection, obtains the target container group identifier from the request, and determines a second long connection between the lord container group and the target client based on the target container group identifier, and forwards the request to the target client through the second long connection; the client is deployed in container groups managed by the lord container group under different nodes of the cluster, and is used to receive requests forwarded by the lord container group of its node through the second long connection.

13. The system according to claim 12, characterized in that, After the cluster starts, it creates a lord container group on different nodes and establishes a first long connection between the lord container group and the server. The server registers the lord container group, records the container group identifier of the client connected to the registered lord container group, records the information of the first long connection of the registered lord container group, and constructs a first association table based on the container group identifier and the information of the long connection of the registered lord container group.

14. The system according to claim 12, characterized in that, After startup, the client obtains the lord container group of its current node from the server via a short connection and establishes a second long connection with the lord container group of its current node. After the second long connection is successfully established, the lord container group of the current node records the container group identifier of the client's container group and the information of the client's second long connection. Based on the container group identifier of the client's container group and the information of the client's second long connection, a second association table is constructed, and the container group identifier of the client connected to the lord container group is recorded in the server.

15. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the method according to any one of claims 1 to 11.

16. A computer program product, characterized in that, The method includes a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 11.

Images