A communication control method and system for distributed nodes

Abstract

The present invention discloses a communication control method and system for distributed nodes, and relates to the field of communication technology. The method includes: the client installs the operating environment of the application container engine, and reports the system information and token to the server; the server returns the image configuration information of the application container engine to the client; the client downloads the image of the application container engine, and reports the image information and system information of the running application container engine to the server; the server obtains the node ID from the image information and the system information, obtains the task information to be executed in the message queue through the node ID and the space ID of the area where the node is located, and returns the task information to be executed to the client; the client performs related operations. The present invention does not rely on external programs to achieve stable updates of the client during operation, ensures the security of the communication establishment process, and realizes rapid master-slave switching after the failure of the available area in the cloud network.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a communication control method and system for distributed nodes. Background Art

[0002] For the distributed node management solution, it is necessary to efficiently manage the containers and services of the distributed nodes, and the entire management method needs to adapt to a variety of network and system environments. For the client of the distributed node, the self-update technology that is often used mostly uses external programs, that is, starting a script or daemon process separately, stopping the current process, starting a new program in a new directory, and deleting the current directory. This requires reliance on external programs and the creation of new directories, which makes the client program too complicated. Relying on external programs will also reduce reliability. In addition, the communication security between the existing distributed nodes and the server cannot be effectively guaranteed, and the communication traffic is easily analyzed and hijacked. In particular, there is no better defense against illegal operations such as replacing the root certificate in the client and using the middleman forgery technology to hijack traffic. The main reason is that the verification of the server is not sufficient. In addition, due to the large number of distributed nodes, the wide area involved, and the need to ensure the stability of their communication, the current CDN cannot meet the needs of two-way certificate verification, and the single-cloud distributed nodes are too dependent on a certain cloud service provider. When a large-scale failure occurs in a single cloud, the system fault tolerance is poor. Summary of the invention

[0003] In view of the above-mentioned defects or deficiencies in the prior art, the present invention provides a communication control method and system for distributed nodes, which, on the one hand, can realize stable update of the client during operation without relying on external programs, thereby improving the reliability of the client program. No new directory needs to be created during operation, and the update can be realized based on the original client program, thereby reducing the maintenance cost. On the other hand, the key parts of the TLS handshake between the client and the server are verified by hook, thereby ensuring the security of the communication establishment process and reducing the possibility of man-in-the-middle attacks. On the third hand, a multi-cloud and multi-node approach is used to forward traffic, and cloud dialing is used to perform health checks in combination with the survival status of distributed nodes, and DNS zone resolution technology is combined to realize fast master-slave switching after failure of the available area in the cloud network.

[0004] One aspect of the present invention provides a communication control method for distributed nodes, including: a client installs an operating environment of an application container engine in a node, and reports the system information and token of the node to a server; the server verifies whether the token and the system information of the node are legal, and returns the image configuration information of the application container engine to the client if they are legal; the client downloads the image of the application container engine according to the returned image configuration information of the application container engine, runs the image of the application container engine and reports the image information and system information of the running application container engine to the server; the server obtains a node ID from the image information and system information of the running application container engine, obtains task information to be executed in a message queue through the node ID and the space ID of the area where the node is located, and returns the task information to be executed to the client; the client performs related operations according to the task information to be executed.

[0005] Furthermore, the client performs steps of performing related operations according to the task information to be executed, including: if the task information to be executed is a client update task, downloading a new client program to a temporary directory of the operating system, and performing availability and compatibility checks on the new client program; if the version of the new client program is higher than the version of the original client program, the new client program can run normally, and the new client program is compatible with the current application container engine, deleting the original client program file using the operating system API, overwriting the installation path of the original client program with the new client program, granting executable permissions to the new client program, sending a signal to restart the client program service to the operating system, shutting down the service of the original client program through the operating system API, and starting the service using the new client program.

[0006] Furthermore, it also includes: the server verifies the system information of the token and the node, uses the system information of the node to issue a root certificate, and returns the root certificate to the client; the client performs a hash check on the root certificate to confirm that the root certificate is issued by the server; the root certificate that has been hashed is used to communicate with the client certificate for mTLS, and the legitimacy of the root certificate is verified during the TLS handshake process through a hook method, and if the verification is legal, the TLS handshake is completed; the server obtains the client certificate and verifies the legitimacy of the client certificate, and if the verification is legal, the TLS handshake continues; the client verifies whether the server has obtained the client certificate during the TLS handshake, and if so, a trusted connection is established between the client and the server, and periodically performs security checks on the trusted connection, including: obtaining the hash value of the root certificate and comparing it with the built-in whitelist, determining whether the server has obtained the client certificate, and whether the IP issued by the server root certificate is consistent with the communication IP; if any of the above security checks fails to pass the verification, the trusted connection is disconnected.

[0007] Furthermore, the step of establishing a trusted connection between the client and the server includes: a client of the first node in the first area of ​​the first cloud network receives the server IP closest to the first area returned by the DNS server, and establishes a connection with the first forwarding node in the first area, and periodically reports the survival information of the first node to the server corresponding to the server IP through the first forwarding node; after the server verifies the certificate, the survival information of the first node is stored in the database; when the communication between the first node and the server cannot be connected, the client of the first node sends other server addresses in the server list to the DNS server for resolution, receives the new server IP returned by the DNS server, and establishes a connection with the second forwarding node in the second cloud network or the third forwarding node in the second area of ​​the first cloud network, and periodically reports the survival information of the first node to the new server through the second forwarding node or the third forwarding node; the client checks whether the original communication connection between the first node, the first forwarding node and the original server is restored, and if restored, switches the current communication connection back to the original communication connection.

[0008] Furthermore, it also includes: the server obtains the node survival information stored in the database, and judges the communication results of different nodes according to the node survival information and the test results of the cloud dialing test. If the node communication in the first area of ​​the first cloud network fails or the nodes in the first area are collectively disconnected, the DNS resolution result of the forwarding node address of the first area is modified to other available areas of the first cloud network.

[0009] Furthermore, it also includes: if a large-scale failure occurs in the first cloud network, the DNS resolution result of the forwarding node address of the first cloud network is switched to the second cloud network.

[0010] Furthermore, it also includes: if the test result of the cloud dial test is that the communication is restored, the DNS resolution result of the forwarding node address is restored to the first area in the original first cloud network.

[0011] On the other hand, the present invention also provides a communication control system for distributed nodes, including: a client, used to install the operating environment of the application container engine in the node, and report the system information and token of the node to the server; download the image of the application container engine according to the image configuration information of the application container engine returned by the server, run the image of the application container engine and report the image information and system information of the running application container engine to the server; perform related operations according to the task information to be executed returned by the server; the server is used to verify whether the token and the system information of the node are legal, and if so, return the image configuration information of the application container engine to the client; obtain the node ID from the image information and system information of the running application container engine, obtain the task information to be executed in the message queue through the node ID and the space ID of the area where the node is located, and return the task information to be executed to the client.

[0012] The distributed node communication control method and system provided by the present invention have the following beneficial effects:

[0013] (1) No external programs are required to achieve stable updates of the client during operation. No new directories need to be created during the operation of the client program. Updates can be achieved based on the original client program, reducing maintenance costs.

[0014] (2) Verify the key parts of the TLS handshake between the client and the server through hooking to ensure the security of the communication establishment process and reduce the possibility of man-in-the-middle attacks;

[0015] (3) Use a multi-cloud, multi-node approach to forward traffic, and use cloud dial-up testing combined with the survival status of distributed nodes to perform health checks. Combined with DNS zone resolution technology, rapid master-slave switching after an available zone failure in the cloud network can be achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Other features, objects and advantages of the present application will become more apparent by reading the detailed description of non-limiting embodiments made with reference to the following drawings:

[0017] Figure 1 This is a flow chart of a communication control method for distributed nodes provided by an embodiment of the present application. Figure 1 ;

[0018] Figure 2 This is a flow chart of a communication control method for distributed nodes provided by an embodiment of the present application. Figure 2 ;

[0019] Figure 3 This is a flow chart of a communication control method for distributed nodes provided by an embodiment of the present application. Figure 3 ;

[0020] Figure 4 This is a flow chart of a communication control method for distributed nodes provided by an embodiment of the present application. Figure 4 ;

[0021] Figure 5 It is a system logic diagram of a distributed node communication control system provided by an embodiment of the present application. DETAILED DESCRIPTION

[0022] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0023] The terms used in the embodiments of the present invention are only for the purpose of describing specific embodiments, and are not intended to limit the present invention. The singular forms "a", "said" and "the" used in the embodiments of the present invention and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings.

[0024] It should be understood that although the terms first, second, third, etc. may be used to describe the acquisition modules in the embodiments of the present invention, the acquisition modules should not be limited to these terms. These terms are only used to distinguish the acquisition modules from each other.

[0025] The word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrases "if it is determined" or "if (stated condition or event) is detected" may be interpreted as "when it is determined" or "in response to determining" or "when detecting (stated condition or event)" or "in response to detecting (stated condition or event)", depending on the context.

[0026] It should be noted that the directional words such as "upper", "lower", "left", and "right" described in the embodiments of the present invention are described at the angles shown in the drawings and should not be understood as limiting the embodiments of the present invention. In addition, in the context, it should also be understood that when it is mentioned that an element is formed "on" or "under" another element, it can not only be formed directly "on" or "under" another element, but also be formed "on" or "under" another element indirectly through an intermediate element.

[0027] An embodiment of the present application provides a communication control method for a distributed node, which is adaptable to a variety of network and system environments, can obtain the status of the node and the service running on the node, and efficiently manage the container or service of the distributed node.

[0028] See also Figure 1 The communication control method of the distributed node of this embodiment includes the following steps:

[0029] Step S101, the client installs the operating environment of the application container engine in the node, and reports the system information and token of the node to the server;

[0030] Specifically, the user obtains the distributed node installation command from the system platform page and executes it. The installation command contains the installation token token, obtains the current node system information and architecture information and uploads it to the server. After receiving the uploaded information, the server verifies the token token and stores the current node system and architecture information. After the architecture and system of the node are verified, the corresponding node management program (i.e., the client program) is returned, otherwise a prompt message indicating that the verification has not passed is returned. If the verification fails, an error message is returned to the user and the program exits; if the verification passes, the client program is allowed to be installed. After the client program runs, check whether the docker environment is installed and running. If the docker environment is not installed, install the docker environment corresponding to the current system and run it. If the docker environment is installed, obtain the current node system information, for example: calculate the node ID, the machine configuration of the node, the node IP, etc. through the built-in algorithm, and report it to the server together with the token token. It should be pointed out that the server of this embodiment can be one or more servers, or a server cluster.

[0031] Step S102, the server verifies whether the system information of the token and the node is legal, and returns the image configuration information of the application container engine to the client if it is legal;

[0032] Specifically, the server verifies whether the token and system information are legal, for example, whether the node configuration meets the requirements, whether the docker image is installed repeatedly, etc. If the verification is legal, the server returns the docker image configuration information to be installed to the client. If the verification is illegal, an error message is displayed and the server exits.

[0033] Step S103, the client downloads the image of the application container engine according to the returned image configuration information of the application container engine, runs the image of the application container engine, and reports the image information and system information of the running application container engine to the server;

[0034] Specifically, the client downloads the docker image according to the returned docker image configuration information, registers the client as a system service and sets it to start running, runs the downloaded docker image according to the docker image configuration information, and reports the running docker image information and system information to the server.

[0035] Step S104, the server obtains the node ID from the image information and system information of the running application container engine, obtains the task information to be executed in the message queue through the node ID and the space ID of the area where the node is located, and returns the task information to be executed to the client;

[0036] Specifically, the server obtains the Docker image information and system information reported by the node, parses the node reported information and stores it in the database, obtains the node ID from the node reported information, and tries to obtain the task from the message queue through the node ID and the space ID of the area where the node is located, including:

[0037] Use the node ID to obtain the task from the message queue. If the task is obtained, the task information to be executed is returned to the client.

[0038] Get the task from the message queue using the space ID (region ID in the cloud network). If the task is obtained, return the task information to be executed to the client.

[0039] If the task information is not obtained using the node ID and space ID, the tasks to be executed by all nodes are obtained from the message queue, such as node self-update tasks, image update tasks, etc. If obtained, the current version of the node is compared with the version to be updated. If an update is required, the task information to be executed is returned to the client.

[0040] Step S105: the client performs relevant operations according to the task information to be executed.

[0041] Specifically, the client determines whether the node has a task to be executed. If there is no task to be executed, the client waits for a predetermined time and then executes step S103 again. If there is a task to be executed, the type of the task to be executed is determined:

[0042] If it is a task to stop or start a container, the stop or start command of the node is executed, and the docker API is used to schedule the currently running docker image to complete the task control.

[0043] If it is a container update task, the latest docker image is downloaded according to the server configuration. After the download is complete, the version of the downloaded container image is obtained and compared with the current version. If an update is required, the current container is stopped and the new version container is run. After the operation is successful, the old version docker image is deleted. If the update is not successful, the old version docker image is returned to run.

[0044] If it is a client self-update task, see Figure 2 , perform the following steps:

[0045] Step S201, downloading a new client program to a temporary directory of the operating system;

[0046] Step S202, performing availability and compatibility check on the new client program;

[0047] Step S203: If the version of the new client program is higher than the version of the original client program, the new client program can run normally, and the new client program is compatible with the current application container engine, the original client program file is deleted using the operating system API, the installation path of the original client program is overwritten with the new client program, and the executable permission is granted to the new client program;

[0048] Step S204, sending a signal to restart the client program service to the operating system, closing the service of the original client program through the operating system API, and starting the service using the new client program.

[0049] Specifically, the download link of the new executable client program will be attached to the service self-update, and the latest client program can be obtained by requesting the download link. After the new version of the client program is downloaded, the new version of the client program is saved in the / tmp directory of the node operating system. After granting execution permission, the availability check of the new version of the client program is performed. By executing the agent version instruction, it is checked whether the client program can be run and whether it is a compatible program. If it cannot be run, it will not be updated. Then, the obtained client version to be updated is compared with the currently running client version. If the client version to be updated is higher than the current version, it is updated, otherwise the update is stopped. Then, by executing the availability test command, it is checked whether the new version of the client program can be run under the current system and whether it is compatible with the docker container. If it fails to pass the check, the self-update logic is exited. If it passes the availability check, the client program will delete itself and use the new version of the client program to overwrite its own file, and then grant execution permission. Finally, by sending a restart service signal to the operating system, the system API closes the old version of the client program and uses the new client program to start the service, thereby completing the self-update of the client program.

[0050] Steps S201-S204 do not rely on external programs for updating, which reduces the complexity of the system and improves the reliability of the program. No new directory needs to be created during operation, and updates can be performed based on the original program, which reduces maintenance costs and achieves stable updates of running client programs.

[0051] See also Figure 3 , the communication control method of the distributed node also includes the following communication security verification steps:

[0052] Step S301, the server verifies the system information of the token and the node, issues a root certificate using the system information of the node, and returns the root certificate to the client;

[0053] Specifically, the client program uses the https protocol to communicate with the server, sends the node's system information and token to the server, and the server verifies whether the token and node system information are legal, uses the node's system information to issue a root certificate, and returns the root certificate to the client.

[0054] Step S302: The client performs a hash check on the root certificate to confirm that the root certificate is issued by the server; the root certificate that has undergone hash check is used to communicate with the client certificate through mTLS, and the legitimacy of the root certificate is checked during the TLS handshake process by hooking. If the check is legal, the TLS handshake is completed;

[0055] Specifically, the client performs a hash check on the root certificate returned by the server to ensure that the returned certificate is issued by the server. Since the client does not trust the system certificate, the verified server root certificate is used to communicate with the client certificate for mTLS. The specific process is: after the client initiates the connection, it performs a TLS handshake with the server, and verifies the legality of the root certificate issued by the server during the TLS handshake process through a hook method, for example: whether the IP issued in the certificate is consistent with the connection IP, whether the server certificate has been verified by the root certificate, etc. If it is illegal, the communication is exited, and if it is legal, the handshake is continued.

[0056] Step S303, the server obtains the client certificate and verifies the legitimacy of the client certificate. If the verification is legal, the TLS handshake continues;

[0057] Step S304, the client verifies whether the server has obtained the client certificate during the TLS handshake process. If so, a trusted connection is established between the client and the server, and periodic security checks are performed on the trusted connection, including: obtaining the hash value of the root certificate and comparing it with the built-in whitelist, determining whether the server has obtained the client certificate, and whether the IP issued by the server root certificate is consistent with the communication IP; if any of the above security checks fails the verification, the trusted connection is disconnected.

[0058] Steps S301-S304 verify the key parts of the TLS handshake between the client and the server by hooking, thereby ensuring the security of the communication establishment process and reducing the possibility of man-in-the-middle attacks.

[0059] See also Figure 4 The communication control method of the distributed node also includes the following steps of establishing a trusted connection between the client and the server:

[0060] Step S401: A client of a first node in a first area of ​​a first cloud network receives a server IP closest to the first area returned by a DNS server, and establishes a connection with a first forwarding node in the first area, and periodically reports survival information of the first node to a server corresponding to the server IP through the first forwarding node;

[0061] Specifically, when establishing a connection, the client of node A in zone A of cloud A first resolves the domain name in the URL of the server, and then connects to the DNS server of the public network. Due to the recursive resolution logic of DNS, the request is eventually forwarded to the DNS server of the node operating system. The DNS server returns the nearest server IP in the area where node A is located based on the IP that initiated the resolution request. The client of node A uses the server IP address returned by the DNS server to try to establish a connection with the forwarding node in zone A of cloud A. If the connection is successfully established, the survival information of node A is reported. The traffic communicates via the intranet of the forwarding node in zone A of cloud A across available areas and reaches the server cluster on the server side.

[0062] Step S402, after the certificate is verified, the server stores the survival information of the first node in a database;

[0063] Step S403, when the communication between the first node and the server cannot be connected, the client of the first node sends other server addresses in the server list to the DNS server for resolution, receives a new server IP returned by the DNS server, and establishes a connection with a second forwarding node in the second cloud network or a third forwarding node in the second area of ​​the first cloud network, and periodically reports the survival information of the first node to the new server through the second forwarding node or the third forwarding node;

[0064] Specifically, the client of node A determines whether the current communication is normal. If it is normal, it reports the node survival information. Otherwise, it tries to reconnect and executes the process of step S401. If the reconnection fails, it tries to switch to other addresses in the client's server list, and sends the new server address to the DNS server for resolution. After the DNS server completes the resolution, it returns the new server IP to the client. After the client obtains the new server IP address, it tries to connect the current node A with the forwarding node of cloud B or the forwarding node of cloud A in zone C, that is, it transfers the failed connection to the forwarding node of other clouds or the forwarding node of other areas of the current cloud. If the new connection is successful, the survival information of node A is reported to the new server. If the new connection is unsuccessful, the node list is traversed again.

[0065] Step S404: the client checks whether the original communication connection between the first node, the first forwarding node and the original server is restored, and if restored, switches the current communication connection back to the original communication connection.

[0066] Specifically, the client checks whether the original communication connection between node A, forwarding node in zone A, and the original server is restored. If not, it delays for x seconds and then checks again whether the communication connection is restored. If restored, it switches the current communication connection back to the original communication connection, thereby completing the standby-master switch.

[0067] It should be pointed out that the switching of the IP address corresponding to the domain name of the conversion node needs to wait for the server to check and wait for the DNS server to take effect, so the waiting period is relatively long. Therefore, the above method does not replace the forwarding node first, but chooses to switch the server URL first, so that the fault can be restored to normal faster.

[0068] Furthermore, the method further includes step S405:

[0069] The server obtains the node survival information stored in the database, and judges the communication results of different nodes according to the node survival information and the test results of the cloud dial test. If the node communication in the first area of ​​the first cloud network fails or the nodes in the first area are collectively offline, the DNS resolution result of the forwarding node address in the first area is modified to other available areas of the first cloud network; if a large-scale failure occurs in the first cloud network, the DNS resolution result of the forwarding node address of the first cloud network is switched to the second cloud network; if the test result of the cloud dial test is that the communication is restored, the DNS resolution result of the forwarding node address is restored to the original first area in the first cloud network.

[0070] Specifically, the server obtains the node survival information stored in the database, and judges the communication results of different nodes in combination with the cloud dial test. If the cloud dial test prompts that the node communication has failed or the nodes in a certain area are collectively offline, the DNS resolution result of the forwarding node address in the area is modified to other available areas, such as Area B of Cloud A. If a large-scale failure occurs in Cloud A, the DNS resolution result of the forwarding node address in the area is switched to Cloud B. If the cloud dial test result is that the communication is restored, the DNS resolution result of the forwarding node address is restored to Area A of Cloud A. The communication connection is periodically checked according to the above process.

[0071] The above steps S401-S405 have the following technical effects:

[0072] The server deploys single cloud and multiple nodes in multiple regions (for example, Central China, North China, Southeast China, and Northwest China) through cloud infrastructure to ensure that after a network failure in a certain region, it can switch to other regions; in a single cloud environment, use intranet communication across availability zones to ensure the stability of communication from the client to the forwarding node in region B of cloud A to the master node; at the same time, considering the instability of the infrastructure of a single cloud, use cloud B as a backup for cloud A, deploy a small number of nodes, and communicate with cloud A nodes through the public network; complete the communication from the client node to the forwarding node across clouds and regions and then to the master node, and ensure the high reliability of the service through redundant communication. Since the IP of multiple clouds and multiple nodes is not fixed and the compatibility of client use needs to be guaranteed, the DNS zone resolution function is used to enable nodes in different regions to be assigned to nodes in different regions for communication when using a unified domain name link, thereby improving access speed, reducing latency, and reducing the communication pressure on a single node. By using the cloud dial-up function and analyzing the communication data between the platform and distributed nodes, the communication reliability of multiple clouds and multiple nodes is verified. If the communication of the forwarding node in a certain area of ​​a certain cloud is abnormal, the DNS zone resolution function is used to smoothly migrate the traffic in the faulty area to other available areas to ensure communication reliability.

[0073] The client supports configuring multiple server communication addresses, adopts concurrent connections when connecting, and selects the forwarding node with the smallest communication delay for communication; when the communication between the client and the forwarding node fails, the address domain name used in the communication address will be resolved. After the server finds a regional failure, it will modify the DNS resolution address of the current area to other areas, and the client will re-resolve the address to adapt to the failover function and quickly restore the failed connection; the client will periodically detect the communication delay of multiple communication addresses in the background. When it finds that the communication delay with a communication node is less than the current communication node, it will automatically switch to reuse the current available area traffic after the failure is restored.

[0074] See also Figure 5Another embodiment of the present application further provides a communication control system for distributed nodes, the system comprising multiple clients 201 and a server 202. The client 201 may be a node client distributed in multiple regions of a single cloud, or a node client distributed in multiple regions of multiple clouds. The server 202 may be a cluster of one or more servers. The communication control system for distributed nodes of this embodiment is used to implement the method in the method embodiment.

[0075] Specifically, the communication control system of the distributed nodes includes:

[0076] The client 201 is used to install the operating environment of the application container engine in the node, and report the system information and token of the node to the server 202; download the image of the application container engine according to the image configuration information of the application container engine returned by the server 202, run the image of the application container engine and report the image information and system information of the running application container engine to the server 202; perform related operations according to the task information to be executed returned by the server 202;

[0077] The server 202 is used to verify whether the system information of the token and the node is legal. If so, it returns the image configuration information of the application container engine to the client 201; obtains the node ID from the image information and system information of the running application container engine, obtains the task information to be executed in the message queue through the node ID and the space ID of the area where the node is located, and returns the task information to be executed to the client 201.

[0078] Furthermore, the client 201 is used for:

[0079] If the task information to be executed is a client update task, the new client program is downloaded to the temporary directory of the operating system, and the new client program is checked for availability and compatibility. If the version of the new client program is higher than the version of the original client program, the new client program can run normally, and the new client program is compatible with the current application container engine, the operating system API is used to delete the original client program file, the installation path of the original client program is overwritten with the new client program, executable permissions are granted to the new client program, and a signal to restart the client program service is sent to the operating system. The service of the original client program is closed through the operating system API, and the service is started using the new client program.

[0080] Furthermore, the server 202 is also used to: verify the system information of the token and the node, issue a root certificate using the system information of the node, and return the root certificate to the client 201; obtain the client certificate, and verify the legitimacy of the client certificate, and continue the TLS handshake if the verification is legal;

[0081] The client 201 is also used to: perform hash verification on the root certificate to confirm that the root certificate is issued by the server 202; use the hash-verified root certificate to perform mTLS communication with the client certificate, and implement the legitimacy verification of the root certificate in the TLS handshake process through a hook method. If the verification is legal, the TLS handshake is completed; verify whether the server 202 has obtained the client certificate during the TLS handshake process, and if so, establish a trusted connection between the client 201 and the server 202, and perform periodic security verification on the trusted connection, including: obtaining the hash value of the root certificate and comparing it with the built-in whitelist, determining whether the server 202 has obtained the client certificate, and whether the IP issued by the server root certificate is consistent with the communication IP; if any of the above security verifications fails to pass the verification, the trusted connection is disconnected;

[0082] The client 201 includes a client of a first node in a first area of ​​a first cloud network, and is used to: receive a server IP closest to the first area returned by a DNS server, and establish a connection with a first forwarding node in the first area, and periodically report the survival information of the first node to a server 202 corresponding to the server IP through the first forwarding node; when the communication between the first node and the server 202 cannot be connected, send other server addresses in the server list to the DNS server for resolution, receive a new server IP returned by the DNS server, and establish a connection with a second forwarding node in the second cloud network or a third forwarding node in the second area of ​​the first cloud network, and periodically report the survival information of the first node to the new server 202 through the second forwarding node or the third forwarding node; check whether the original communication connection between the first node, the first forwarding node and the original server is restored, and if restored, switch the current communication connection back to the original communication connection;

[0083] The server 202 is also used to store the survival information of the first node in the database after certificate verification; obtain the node survival information stored in the database, and judge the communication results of different nodes according to the node survival information and the test results of the cloud dial test; if the node communication in the first area of ​​the first cloud network fails or the nodes in the first area are collectively disconnected, modify the DNS resolution result of the forwarding node address of the first area to other available areas of the first cloud network; if a large-scale failure occurs in the first cloud network, switch the DNS resolution result of the forwarding node address of the first cloud network to the second cloud network; if the test result of the cloud dial test is that the communication is restored, restore the DNS resolution result of the forwarding node address to the original first area in the first cloud network.

[0084] The functions implemented by various parts of the communication control system of the distributed node provided in this embodiment completely correspond to the various steps in the method embodiment, and the specific implementation principles are the same, which will not be repeated here.

[0085] The above description is only a preferred embodiment of the present invention. Those skilled in the art should understand that the scope of disclosure involved in the present invention is not limited to the technical solution formed by a specific combination of the above technical features, but also should cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosed concept. For example, the above features are replaced with the technical features with similar functions disclosed in the present invention (but not limited to) to form a technical solution.

Claims

1. A communication control method for distributed nodes, characterized in that: include: The client installs the operating environment of the application container engine in the node and reports the node's system information and token to the server; The server verifies whether the system information of the token and the node is legal, and returns the image configuration information of the application container engine to the client if it is legal; The client downloads the image of the application container engine according to the returned image configuration information of the application container engine, runs the image of the application container engine, and reports the image information and system information of the running application container engine to the server; The server obtains the node ID from the image information and system information of the running application container engine, obtains the task information to be executed in the message queue through the node ID and the space ID of the area where the node is located, and returns the task information to be executed to the client; If the task information to be executed is a client update task, then download the new client program to the temporary directory of the operating system, and perform availability and compatibility checks on the new client program. If the version of the new client program is higher than the version of the original client program, the new client program can run normally, and the new client program is compatible with the current application container engine, then use the operating system API to delete the original client program file, overwrite the installation path of the original client program with the new client program, grant executable permissions to the new client program, send a signal to restart the client program service to the operating system, shut down the service of the original client program through the operating system API, and start the service with the new client program; The server verifies the token and the node's system information, issues a root certificate using the node's system information, and returns the root certificate to the client; The client performs a hash check on the root certificate to confirm that the root certificate is issued by the server; the root certificate that has undergone hash check is used to communicate with the client certificate through mTLS, and the legitimacy of the root certificate is checked during the TLS handshake process by hooking. If the check is legal, the TLS handshake is completed; The server obtains the client certificate and verifies the legitimacy of the client certificate. If the certificate is verified to be legitimate, the server continues the TLS handshake. The client verifies whether the server has obtained the client certificate during the TLS handshake process. If so, a trusted connection is established between the client and the server, and periodic security checks are performed on the trusted connection, including: obtaining the hash value of the root certificate and comparing it with the built-in whitelist, determining whether the server has obtained the client certificate, and whether the IP issued by the server root certificate is consistent with the communication IP; If any of the above security checks fails to pass the verification, the trusted connection is disconnected.

2. A distributed node communication control method according to claim 1, characterized in that: The step of establishing a trusted connection between the client and the server includes: A client of a first node in a first area of ​​a first cloud network receives a server IP closest to the first area returned by a DNS server, and establishes a connection with a first forwarding node in the first area, and periodically reports survival information of the first node to a server corresponding to the server IP through the first forwarding node; After the certificate is verified, the server stores the survival information of the first node in a database; When the communication between the first node and the server cannot be connected, the client of the first node sends other server addresses in the server list to the DNS server for resolution, receives a new server IP returned by the DNS server, and establishes a connection with a second forwarding node in the second cloud network or a third forwarding node in the second area of ​​the first cloud network, and periodically reports the survival information of the first node to the new server through the second forwarding node or the third forwarding node; The client checks whether the original communication connection between the first node, the first forwarding node and the original server is restored, and if restored, switches the current communication connection back to the original communication connection.

3. A distributed node communication control method according to claim 2, characterized in that: Also includes: The server obtains the node survival information stored in the database, and judges the communication results of different nodes based on the node survival information and the test results of the cloud dial test. If the node communication in the first area of ​​the first cloud network fails or the nodes in the first area are collectively disconnected, the DNS resolution result of the forwarding node address in the first area is modified to other available areas of the first cloud network.

4. A distributed node communication control method according to claim 3, characterized in that: Also includes: If a large-scale failure occurs in the first cloud network, the DNS resolution result of the forwarding node address of the first cloud network is switched to the second cloud network.

5. A distributed node communication control method according to claim 4, characterized in that: Also includes: If the test result of the cloud dial test is that the communication is restored, the DNS resolution result of the forwarding node address is restored to the first area in the original first cloud network.

6. A communication control system for distributed nodes, characterized in that: include: The client is used to install the operating environment of the application container engine in the node and report the node's system information and token to the server; Download the image of the application container engine according to the image configuration information of the application container engine returned by the server, run the image of the application container engine, and report the image information and system information of the running application container engine to the server; Execute relevant operations according to the task information to be executed returned by the server; if the task information to be executed is a client update task, download the new client program to the temporary directory of the operating system, and perform availability and compatibility checks on the new client program. If the version of the new client program is higher than the version of the original client program, the new client program can run normally, and the new client program is compatible with the current application container engine, use the operating system API to delete the original client program file, overwrite the installation path of the original client program with the new client program, grant executable permissions to the new client program, send a signal to restart the client program service to the operating system, close the service of the original client program through the operating system API, and use the new client program to start the service; The server is used to verify whether the system information of the token and the node is legal, and if so, returns the image configuration information of the application container engine to the client; Obtain the node ID from the image information and system information of the running application container engine, obtain the task information to be executed in the message queue through the node ID and the space ID of the area where the node is located, and return the task information to be executed to the client; Verify the system information of the token and the node, issue a root certificate using the system information of the node, and return the root certificate to the client; Obtain the client certificate and verify the legitimacy of the client certificate. If the verification is legal, continue the TLS handshake; Perform hash verification on the root certificate to confirm that the root certificate is issued by the server; use the hash-verified root certificate to communicate with the client certificate in mTLS, and verify the legitimacy of the root certificate during the TLS handshake process by hooking. If the verification is legal, complete the TLS handshake; Verify whether the server has obtained the client certificate during the TLS handshake process. If yes, establish a trusted connection between the client and the server, and perform periodic security checks on the trusted connection, including: obtaining the hash value of the root certificate and comparing it with the built-in whitelist, determining whether the server has obtained the client certificate, and whether the IP issued by the server root certificate is consistent with the communication IP; If any of the above security checks fails to pass the verification, the trusted connection is disconnected.

Images