Gateway fault detection method, device, equipment and readable storage medium

Abstract

The application discloses a gateway fault detection method and device, electronic equipment and a computer readable storage medium. The method comprises the following steps: controlling a test client to send a test request through a test virtual bridge in a measured gateway, so that the test request is forwarded to a test server through the test virtual bridge after being processed by the measured gateway; controlling the test server to respond to a target test request obtained through the test virtual bridge to obtain response data; if it is detected that the test request and the response data do not match, it is determined that the measured gateway has a gateway fault; the result-oriented fault detection method can determine that the measured gateway has a fault when the measured gateway cannot support normal operation of a service, and the fault detection efficiency and accuracy are high.

Description

Technical Field

[0001] This application relates to the field of gateway technology, and in particular to a gateway fault detection method, gateway fault detection device, electronic device, and computer-readable storage medium. Background Technology

[0002] An application gateway is a network device that connects one network to another, providing inter-network connectivity for specific applications and implementing corresponding application protocols. An application gateway can be viewed as an intermediary between a client requesting a specific service and a server providing that service. From the user's perspective, it acts as a server; from the server's perspective, it is a client.

[0003] Detecting proxy failures in an application gateway transparent system is essentially detecting failures in a software system. This software system has a highly complex architecture, consisting of numerous microservices, databases, message brokers, and other components or processes that must be organically combined to achieve the full functionality of the application proxy. Related technologies detect failures by performing heartbeat checks on each subsystem; however, this method requires checking a large number of objects, is time-consuming, and is prone to false alarms, resulting in low detection accuracy. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a gateway fault detection method, gateway fault detection device, electronic device and computer-readable storage medium, which have high fault detection efficiency and accuracy.

[0005] To address the aforementioned technical problems, this application provides a gateway fault detection method, comprising:

[0006] The control test client sends test requests through the test virtual bridge in the gateway under test, so that the test requests are processed by the gateway under test and then forwarded to the test server through the test virtual bridge;

[0007] The test server is controlled to respond to the target test requests obtained through the test virtual bridge, and response data is obtained.

[0008] If a mismatch is detected between the test request and the response data, it is determined that the gateway under test has experienced a gateway failure.

[0009] Optionally, at least one service application is deployed on the test server to control the test server to respond to target test requests obtained through the test virtual bridge, and to obtain response data, including:

[0010] The test server is controlled to obtain the target test request through the virtual bridge.

[0011] The test server is controlled to determine the target service application using the target test request, and respond to the target test request based on the target service application to obtain the response data.

[0012] Optionally, the test server deploys multiple service applications of different types, and the control test client sends test requests through the test virtual bridge in the gateway under test, including:

[0013] Identify the service application to be tested;

[0014] The test client is controlled to generate a test request that matches the application under test.

[0015] The test request is sent to the test server through the test virtual bridge;

[0016] Update the application of the service to be tested.

[0017] Optionally, both the test client and the test server are deployed in the gateway under test.

[0018] Optionally, it also includes:

[0019] Deploy the test client on the client device connected to the gateway under test;

[0020] The test server is deployed on the server-side device connected to the gateway under test.

[0021] Optionally, the test request includes a first test request, and detecting a mismatch between the test request and the response data includes:

[0022] Obtain the preset valid response data corresponding to the first test request, and determine whether the first response data corresponding to the first test request is the same as the preset valid response data;

[0023] If they are not the same, update the exception count;

[0024] When the anomaly count is greater than the anomaly threshold, it is determined that the test request and the response data do not match.

[0025] Optionally, the test request includes a second test request, and detecting a mismatch between the test request and the response data includes:

[0026] Determine whether there is a second response data corresponding to the second test request;

[0027] If the second response data does not exist, update the exception count;

[0028] When the anomaly count is greater than the anomaly threshold, it is determined that the test request and the response data do not match.

[0029] Optionally, determining whether there is second response data corresponding to the second test request includes:

[0030] Obtain the first user connection characteristics of the second test request;

[0031] Obtain the second user connection feature corresponding to the candidate response data; wherein, the candidate response data is the response data obtained within a preset time period after the second test request is sent;

[0032] Determine whether the second user connection feature contains a target user connection feature that is identical to the first user connection feature;

[0033] If the target user connection characteristics do not exist, then it is determined that the second response data does not exist.

[0034] This application also provides a gateway fault detection device, including:

[0035] The sending module is used to control the test client to send test requests through the test virtual bridge in the gateway under test, so that the test requests are processed by the gateway under test and then forwarded to the test server through the test virtual bridge.

[0036] The response module is used to control the test server to respond to the target test requests obtained through the test virtual bridge and obtain response data;

[0037] The fault determination module is used to determine that the gateway under test has experienced a gateway fault if the test request and the response data do not match.

[0038] This application also provides an electronic device, including a memory and a processor, wherein:

[0039] The memory is used to store computer programs;

[0040] The processor is used to execute the computer program to implement the gateway fault detection method described above.

[0041] This application also provides a computer-readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the above-described gateway fault detection method.

[0042] The gateway fault detection method provided in this application controls the test client to send a test request through the test virtual bridge in the gateway under test, so that the test request is processed by the gateway under test and then forwarded to the test server through the test virtual bridge; controls the test server to respond to the target test request obtained through the test virtual bridge and obtain response data; if a mismatch is detected between the test request and the response data, it is determined that the gateway under test has experienced a gateway fault.

[0043] As can be seen, this method adopts a result-oriented fault detection approach, that is, judging whether a fault has occurred from the gateway's operational results, thus solving the problem of detection accuracy caused by incomplete detection objects or processes, or incomplete items resulting from detection faults. In this application, a test virtual bridge is deployed in the gateway under test. It can be understood that the test virtual bridge and other application virtual bridges used to execute business operations correspond to the same application server. Therefore, when a test request based on the test virtual bridge cannot be responded to normally, it can be determined that the business operations of the application virtual bridge are also unable to execute normally. The test client sends a test request through the test virtual bridge, and the test server responds to the target test request obtained through the test virtual bridge to obtain response data. If the test request and response data do not match, it indicates that the gateway under test cannot forward data traffic between the client and the server to support normal business operations, thus confirming that the gateway under test has failed. This method can determine that a fault has occurred when the gateway under test cannot support normal business operations, resulting in high fault detection efficiency and accuracy.

[0044] In addition, this application also provides a gateway fault detection device, an electronic device, and a computer-readable storage medium, which also have the above-mentioned beneficial effects. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0046] Figure 1 A flowchart of a gateway fault detection method provided in an embodiment of this application;

[0047] Figure 2 This is a schematic diagram of another zero-trust gateway structure provided in an embodiment of this application;

[0048] Figure 3 A diagram illustrating a test virtual bridge deployment interface provided in this application embodiment;

[0049] Figure 4A schematic diagram of a specific zero-trust gateway structure provided in this application embodiment;

[0050] Figure 5 This is a schematic diagram of a test request flow provided in an embodiment of this application;

[0051] Figure 6 This is another schematic diagram of the test request flow provided in the embodiments of this application;

[0052] Figure 7 This is a schematic diagram of the structure of a gateway fault detection device provided in an embodiment of this application;

[0053] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0054] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0055] Application gateways, especially zero-trust application gateways, are widely used in enterprise office environments. To ensure high availability, application gateways typically bypass business traffic (or application traffic) when they detect a failure, thus guaranteeing service access continuity. Therefore, the ability to promptly detect application gateway failures and allow traffic in a timely manner is crucial for achieving high availability.

[0056] In related technologies, detection is typically performed on each subsystem of the gateway software system, such as various microservices, databases, message middleware, and other components or processes. Alternatively, the gateway's operating environment status is monitored, such as the utilization and health of resources like CPU, memory, I / O, and network. Both of these detection methods involve numerous detection items and dimensions, require significant time, and have poor accuracy. This is because gateway fault types are numerous and complex, easily confused with normal conditions, thus leading to a large number of false alarms.

[0057] To address the aforementioned issues, this application provides a novel gateway fault detection method. This application adopts a result-oriented approach to fault definition, defining any situation that prevents the application gateway from functioning properly as a gateway fault. Based on the working principle of the application gateway, continuously monitoring the reachability of any service session request flowing from the ingress port to the egress port yields the fault status of the application transparent proxy, thereby accurately detecting whether a gateway fault has occurred.

[0058] For details, please refer to Figure 1 , Figure 1 A flowchart illustrating a gateway fault detection method provided in this application embodiment. The method includes:

[0059] S101: Control the test client to send test requests through the test virtual bridge in the gateway under test, so that the test requests are processed by the gateway under test and then forwarded to the test server through the test virtual bridge.

[0060] It should be noted that each step in this application can be performed by a designated electronic device, which can be the gateway under test. That is, the electronic device can detect whether it has a fault by executing the gateway fault detection method of this application; or, the electronic device can be a test device for testing the gateway under test, such as a test server or a test terminal.

[0061] A test client is a client used to send test requests. It can be a physical client or a virtual client, such as a Linux client. The test client initiates the traffic requests (i.e., test requests) for fault detection. Furthermore, it can also be the decision-making point for determining whether a fault exists; that is, in one implementation, the aforementioned electronic device can be the device on which the test client is deployed. The deployment location of the test client is not limited; for example, it can be deployed directly in the gateway under test, or it can be deployed in other electronic devices that are not the gateway under test.

[0062] A test virtual bridge is a virtual bridge used to forward test requests, such as a Linux bridge. The test virtual bridge resides in the gateway under test and can be built based on network interface pairs. By using a test virtual bridge, test requests can be processed like normal business traffic. Therefore, it's understandable that if the processing of test requests malfunctions, it can be determined that normal business traffic also cannot be processed properly, thus indicating a gateway failure in the gateway under test.

[0063] A test request is a request used to test the virtual bridge and the gateway under test. Its specific content is not limited; for example, it can be a special request designed based on the services provided by the test server, such as a TCP login-free authentication application request or a TCP super session authentication application request. The test server is the server that responds to the received test requests; the specific application services it provides can be configured as needed.

[0064] Understandably, the virtual bridge needs to be deployed before testing. In one implementation, the deployment process may include the following steps:

[0065] Step 11: Deploy the test client and test server.

[0066] Step 12: Deploy the service application for the test server.

[0067] Step 13: Generate test network interface pairs corresponding to the test client and test server, and use the test network interface pairs to build a test virtual bridge.

[0068] Before deploying the test virtual bridge, test clients and test servers can be deployed first. The deployment process involves starting and executing the client and server programs on a designated device. In one implementation, the test client and test server can be deployed directly on the gateway under test itself. In this case, to isolate the test client and test server, they can be deployed in different namespaces. Specifically, a first test namespace and a second test namespace can be created. The test client is deployed in the first test namespace, and the test server is deployed in the second test namespace. Namespaces are used to organize and reuse code. Similar to names, because the number of words available to humans is limited, and different programs cannot possibly have all variables without duplicate names, this problem is particularly serious for libraries. If two library files contain variables or functions with the same name (which is usually unavoidable), problems will arise. To solve this problem, the concept of namespaces is introduced. By using `namespace xxx`, the library functions or variables used are defined within that namespace, thus avoiding unnecessary conflicts. Please refer to [reference needed]. Figure 2 , Figure 2 The diagram below shows another zero-trust gateway architecture provided in this application embodiment. As can be seen, the test client is deployed in namespace ns0, and the test server is deployed in namespace ns1.

[0069] In another embodiment, the test client and the test server may be deployed on two different hardware devices, and both of the two hardware devices need to be connected to the gateway under test, so as to ensure that the test request can reach the test server through the gateway under test, that is, the test client is deployed in the client device connected to the gateway under test, and the test server is deployed in the server device connected to the gateway under test.

[0070] After the deployment is completed, a service application is deployed on the test server, so that the test server can respond to the request. After the deployment of the test client and the test server is completed, test network ports corresponding to the two respectively are generated and bound as a test network port pair, and then the test virtual bridge is constructed by using the test network port pair. This embodiment does not limit the specific setting manner of the test virtual bridge, for example, reference may be made to Figure 3 , Figure 3 is a deployment interface diagram of a test virtual bridge provided in an embodiment of the present application, which shows a setting interface for deploying a virtual bridge in a gateway under test, and the interface may be provided by setting software or other control systems supporting the gateway under test. A user can construct a network port pair by inputting the network port identification information corresponding to the two network ports respectively on the interface and identifying the corresponding relationship between the two. The specific process of generating the virtual bridge by the gateway under test according to the determined network port pair is not limited, and reference may be made to related technologies.

[0071] Please refer to Figure 4 , Figure 4This is a schematic diagram of a specific zero-trust gateway structure provided in this application embodiment. The client is the test client, the server is the test server, and the Linux bridge br0 is the test virtual bridge. The virtual network ports constituting the test virtual bridge are veth0 and veth1, which are connected to the test client and the test server respectively. It can be seen that the test virtual bridge, along with other virtual bridges (Linux bridge br1 to Linux bridge brn), corresponds to the same reverse proxy server, specifically nginx / openresty, a web application server. This web application server can process the traffic passing through each virtual bridge in stages. The processing flow and logic of the traffic for each virtual bridge are consistent, for example, the processing flow is designed according to the HTTP or TCP protocol. Based on this, zero-trust transparent deployment can be achieved. The operating principle of zero-trust transparent deployment is based on the connection between the network ports and the upstream and downstream access traffic, establishing a connection between the Linux kernel space and the user space nginx, thereby forming a transparent reverse proxy. Based on a reverse proxy for user traffic and combined with a complete zero-trust security architecture, user authentication protection for accessed resources is achieved. All user traffic passes through the entire zero-trust security architecture system, and the interaction of all modules within the system is to ensure the security, legitimacy, and success of user traffic access. Therefore, if a system failure occurs, it will inevitably directly affect all user traffic access, with the most direct and significant impact being the disruption of business traffic. In this application, a test client is used to simulate the actual behavior of a client accessing the server. By detecting the quality of request and response, the effectiveness of detecting failures in the transparent deployment system of the zero-trust gateway can be achieved.

[0072] For details, please refer to Figure 5 , Figure 5 This is a schematic diagram of a test request flow provided in an embodiment of this application.

[0073] nginx / openresty can process traffic passing through each virtual bridge in stages, that is... Figure 5Phases 1 through n in the protocol hierarchy vary in number and content depending on the protocol. For example, the HTTP protocol's processing flow includes: post-read phase -> server-rewrite phase -> find-config phase -> rewrite phase -> post-rewrite phase -> reaccess phase -> access phase -> post-access phase -> try-files phase -> content phase -> log phase; the TCP protocol's processing flow includes: post-accept phase -> reaccess phase -> access phase -> SSL phase -> preread phase -> content phase -> log phase. After processing, the processed traffic is sent out through the eth out network interface to reach the server.

[0074] After the test begins, the electronic device can command the test client to send a test request, i.e., control the test client to send the test request through the test virtual bridge. Typically, a server can provide multiple types of service applications to respond to different types of client requests. A fault in the gateway under test may manifest as an inability to process some types of requests correctly. To comprehensively test the gateway under test, multiple service applications of different types can be deployed on the test server. During testing, the service application to be tested can be determined first. The service application to be tested refers to the service application that the test request aims to test; it can be any of the service applications available on the test server. In one implementation, the service applications on the test server can be arranged in a preset order, and a pointer to the service application to be tested can be set; the service application pointed to by this pointer is the service application to be tested. The test client generates a test request matching the service application to be tested. The content of the test request is related to the service application to be tested. After generation, the test client sends the test request to the test server through the test virtual bridge. To conduct comprehensive testing, after sending the request, the application under test can be updated so that another application can be selected as the new application under test, thereby detecting the processing effect of the gateway under test on various test requests.

[0075] Please refer to Figure 6 , Figure 6This is another schematic diagram of the test request flow provided in this embodiment. In this embodiment, four service applications are deployed in the test server (i.e., the detection server in the figure): a TCP authentication-free application, a TCP super session application, an HTTP authentication-free application, and an HTTP super session application. These correspond to address 127 of the server under test and ports 5051, 5052, 5053, and 5054, respectively. All four applications are deployed in the zero-trust system of the server under test. The test client (i.e., the detection client in the figure) communicates with the detection server based on br0 (i.e., the test virtual bridge), and the request traffic passes through the nginx / openresty reverse proxy. The test server provides four typical applications, which are permanently deployed in the zero-trust system. The authentication-free application simulates a normal authentication-free business application, and the super session application simulates a normal business application. The super session application configuration includes the super session's account password, preventing the detection client from being redirected to a login page to request a password when it first probes the server. This allows the test client and test server to run automatically without human intervention. In addition to username and password, the configuration of a super session can also include certificate configurations required for access authentication. The logic of the test client is to periodically probe and test the four applications on the server. When a test client performs gateway fault determination, it can also perform access integrity statistics. If the integrity reaches a certain threshold, the system is considered to be operating normally; otherwise, a fault is considered to have occurred. That is, after deployment, the test client controls itself to send test requests to trigger subsequent processes, and then determines whether a fault has occurred based on the received response data.

[0076] S102: Control the test server to respond to the target test request obtained through the test virtual bridge and obtain the response data.

[0077] For the test server, it obtains target test requests through the test virtual bridge and then responds to these requests, obtaining response data. The response process is essentially the process of using the service application to process the target test requests. It's important to note that the target test request refers to the test requests obtained by the test server through the test virtual bridge. The test server may not be able to obtain all test requests sent by the test client, or it may not be able to obtain normal or complete test requests. The specific target test requests obtained by the test server depend on whether the gateway under test is malfunctioning. It can be understood that both the number of test requests sent by the test client and the number of target test requests obtained by the test server can be multiple, and the number of test requests is not less than the number of target test requests.

[0078] Understandably, at least one service application is deployed on the test server. After controlling the test server to obtain the target test request through the virtual bridge, the target service application can be identified using the target test request. The target service application refers to the service application that matches the category of the target test request. The method of identification is not limited; for example, the port number in the target test request can be viewed to determine the target service application. The test server then responds to the target test request based on the target service application, obtaining the response data. The response data refers to the response result obtained by the test server after responding to the target test request.

[0079] S103: If a mismatch is detected between the test request and response data, it is determined that the gateway under test has experienced a gateway failure.

[0080] The electronic device executing each step in this application can obtain the response data obtained in step S102. For example, when it is the gateway under test, if both the test client and the test server are deployed on the gateway under test, the gateway under test can directly obtain the response data. If neither the test client nor the test server is deployed on the gateway under test, the electronic device deployed on the test server needs to send the response data to the gateway under test. If the electronic device executing each step in this application is not the gateway under test, for example, if it is a test client not deployed on the gateway under test, the test server can send the response data to the gateway under test, which will then forward it to the test client.

[0081] After receiving the response data, it is determined whether the test request and response data match. If a mismatch is detected, it is determined that the tested gateway has failed. Specifically, a mismatch could be due to the response data lacking content corresponding to a particular test request, or the content in the response data corresponding to a particular test request not being preset valid content. It should be noted that this embodiment does not limit the specific execution method of this step. In one feasible implementation, the above steps can be performed in real time for each test request; that is, after sending a test request, it is determined in real time whether valid response data corresponding to the test request has been obtained. If no valid response data is obtained after a preset time period, or if incorrect response data is obtained within the preset time period, a mismatch is determined. Alternatively, in another feasible implementation, the above steps can be performed according to a preset cycle; that is, after a preset cycle, it is determined whether the test requests sent in the previous cycle and the obtained response data match.

[0082] Specifically, in one implementation, the test request includes a first test request. During detection, preset valid response data corresponding to the first test request can be obtained, and it can be determined whether the first response data corresponding to the first test request is the same as the preset valid response data. If they are different, the anomaly count is updated. The anomaly count represents the probability of a fault occurring in the gateway under test, and its specific type is not limited. For example, it can be the number of matching requests among a target number of test requests, where a matching request is a test request whose corresponding response data is the preset valid response data. Alternatively, the anomaly count can be the number of consecutively detected first response data that is different from the corresponding preset valid response data. There can be one or more anomaly counts. An anomaly threshold is used to characterize a gateway fault occurring in the gateway under test. When the anomaly count is greater than the anomaly threshold, it is determined that the test request and response data do not match. Specifically, when there are multiple anomaly counts, the anomaly thresholds corresponding to each anomaly count can be the same or different. When one, some, or all of the anomaly counts are greater than the anomaly threshold, it can be determined that the test request and response data do not match.

[0083] Furthermore, in another implementation, some test requests may not be responded to. Specifically, the test requests include a second test request. After determining that a second test request has been issued, it is first determined whether there is second response data corresponding to the second test request. If there is no second response data, for example, if the corresponding second response data is not obtained within a preset time period after the second test request was issued, the exception count is updated. When the exception count is greater than the exception threshold, it is determined that the test request and response data do not match. Therefore, it can be understood that for a first test request, its identity can initially be a second test request, and after obtaining the corresponding second response data, its identity can be converted back to a first test request, and the corresponding second response data can also be converted back to first response data.

[0084] This embodiment does not limit the specific method for determining whether the second response data has been obtained. In one implementation, the test request and response data can use user connection features to characterize their identities. User connection features are typically five-tuple features (i.e., source IP address, source port, destination IP address, destination port, and transport layer protocol) or seven-tuple features (i.e., source IP address, source port, destination IP address, destination port, source MAC address, destination MAC address, and transport layer protocol). During the determination, the first user connection feature of the second test request is obtained, and the second user connection feature corresponding to the candidate response data is obtained. The candidate response data is the response data obtained within a preset time after the second test request is sent. It is determined whether the second user connection feature contains a target user connection feature identical to the first user connection feature. If it does, the two correspond; otherwise, it is determined that no second response data exists.

[0085] After determining that the test request and response data do not match, it can be concluded that the gateway under test has malfunctioned. In this case, the fault can be proactively reported for handling. For example, you can refer to... Figure 2 The fault notification and control module notifies the gateway of faults and reports the fault status. Understandably, the fault status can be cleared under certain conditions; for example, if the detected anomaly count is not greater than an anomaly threshold, the fault notification and control module can be notified to clear the fault status.

[0086] The gateway fault detection method provided in this application adopts a result-oriented fault detection approach, that is, determining whether a fault has occurred based on the gateway's operational results. This solves the problem of detection accuracy caused by incomplete detection objects or processes, or incomplete items resulting from fault detection. In this application, a test virtual bridge is deployed in the gateway under test. It can be understood that the test virtual bridge and other application virtual bridges used for executing services correspond to the same application server. Therefore, when a test request based on the test virtual bridge cannot be responded to normally, it can be determined that the services of the application virtual bridge also cannot be executed normally. The test client sends a test request through the test virtual bridge, and the test server responds to the target test request obtained through the test virtual bridge to obtain response data. If the test request and response data do not match, it indicates that the gateway under test cannot forward data traffic between the client and the server to support normal service operation, thus confirming that the gateway under test has experienced a gateway fault. This method can determine that a fault has occurred when the gateway under test cannot support normal service operation, resulting in high fault detection efficiency and accuracy.

[0087] The gateway fault detection device provided in the embodiments of this application is described below. The gateway fault detection device described below can be referred to in correspondence with the gateway fault detection method described above.

[0088] Please refer to Figure 7 , Figure 7 A schematic diagram of a gateway fault detection device provided in this application embodiment includes:

[0089] The sending module 110 is used to control the test client to send test requests through the test virtual bridge in the gateway under test, so that the test requests are processed by the gateway under test and then forwarded to the test server through the test virtual bridge.

[0090] The response module 120 is used to control the test server to respond to the target test request obtained through the test virtual bridge and obtain response data;

[0091] The fault determination module 130 is used to determine that the gateway under test has a gateway fault if a mismatch is detected between the test request and response data.

[0092] Optionally, at least one service application is deployed on the test server, and the response module 120 includes:

[0093] The acquisition unit is used to control the test server to acquire target test requests through the virtual bridge.

[0094] The response unit is used to determine the target service application using the target test request, and to respond to the target test request based on the target service application to obtain response data.

[0095] Optionally, the test server deploys multiple service applications of different types, and the sending module 110 includes:

[0096] The test-determination unit is used to determine the service application to be tested;

[0097] The generation unit is used to control the test client to generate test requests that match the service application under test;

[0098] The sending unit is used to send test requests to the test server through the test virtual bridge.

[0099] The update unit is used to update the service application under test.

[0100] Optionally, both the test client and the test server are deployed in the gateway under test.

[0101] Optionally, the first deployment module includes:

[0102] The second deployment unit is used to deploy the test client on the client device connected to the gateway under test;

[0103] The third deployment unit is used to deploy the test server in the server-side device connected to the gateway under test.

[0104] Optionally, the test request includes a first test request, and the fault determination module 130 includes:

[0105] The validity judgment unit is used to obtain the preset valid response data corresponding to the first test request, and to determine whether the first response data corresponding to the first test request is the same as the preset valid response data;

[0106] The first counting update unit is used to update the abnormal count if they are not the same.

[0107] The first determination unit is used to determine that the test request and response data do not match when the anomaly count is greater than the anomaly threshold.

[0108] Optionally, the test request includes a second test request, and the fault determination module 130 includes:

[0109] A judgment unit is obtained to determine whether there is second response data corresponding to the second test request;

[0110] The second technical update unit is used to update the anomaly count if no second response data exists.

[0111] The second determination unit is used to determine that the test request and response data do not match when the anomaly count is greater than the anomaly threshold.

[0112] Optionally, the judgment unit includes:

[0113] The feature acquisition subunit is used to acquire the first user connection feature of the second test request;

[0114] The candidate acquisition subunit is used to acquire the second user connection feature corresponding to the candidate response data; wherein, the candidate response data is the response data acquired within a preset time after the second test request is sent;

[0115] The feature judgment subunit is used to determine whether there is a target user connection feature in the second user connection feature that is the same as the first user connection feature;

[0116] The anomaly detection subunit is used to determine that there is no second response data if the target user connection characteristics are not present.

[0117] The electronic device provided in the embodiments of this application is described below. The electronic device described below can be referred to in correspondence with the gateway fault detection method described above.

[0118] Please refer to Figure 8 , Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 100 may include a processor 101 and a memory 102, and may further include one or more of a multimedia component 103, an information input / output (I / O) interface 104, and a communication component 105.

[0119] The processor 101 controls the overall operation of the electronic device 100 to complete all or part of the steps in the gateway fault detection method described above. The memory 102 stores various types of data to support the operation of the electronic device 100. This data may include, for example, instructions for any application or method operating on the electronic device 100, as well as application-related data. The memory 102 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as one or more of Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0120] Multimedia component 103 may include a screen and an audio component. The screen may be, for example, a touchscreen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in memory 102 or transmitted via communication component 105. The audio component also includes at least one speaker for outputting audio signals. I / O interface 104 provides an interface between processor 101 and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual or physical buttons. Communication component 105 is used for wired or wireless communication between electronic device 100 and other devices. Wireless communication may include Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, or 4G, or a combination of these. Therefore, the corresponding communication component 105 may include a Wi-Fi component, a Bluetooth component, or an NFC component.

[0121] The electronic device 100 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to execute the gateway fault detection method given in the above embodiments.

[0122] The computer-readable storage medium provided in the embodiments of this application is described below. The computer-readable storage medium described below can be referred to in correspondence with the gateway fault detection method described above.

[0123] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the gateway fault detection method described above.

[0124] The computer-readable storage medium may include various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0125] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0126] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0127] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0128] Finally, it should be noted that in this document, relationships such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "include," "contain," or any other variations are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus.

[0129] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A gateway fault detection method, characterized in that, include: The test client sends test requests through the test virtual bridge in the gateway under test, so that the test requests are processed by the gateway under test and then forwarded to the test server through the test virtual bridge; both the test client and the test server are deployed in the gateway under test. The gateway under test also includes an application virtual bridge, and the test virtual bridge and the application virtual bridge correspond to the same application server. The test server is controlled to respond to the target test requests obtained through the test virtual bridge, and response data is obtained. If a mismatch is detected between the test request and the response data, it is determined that the gateway under test has experienced a gateway failure.

2. The gateway fault detection method according to claim 1, characterized in that, At least one service application is deployed on the test server to control the test server to respond to target test requests obtained through the test virtual bridge, and to obtain response data, including: The test server is controlled to obtain the target test request through the virtual bridge. The test server is controlled to determine the target service application using the target test request, and respond to the target test request based on the target service application to obtain the response data.

3. The gateway fault detection method according to claim 1, characterized in that, The test server is deployed with multiple service applications of different types. The control test client sends test requests through the test virtual bridge in the gateway under test, including: Identify the service application to be tested; The test client is controlled to generate a test request that matches the application under test. The test request is sent to the test server through the test virtual bridge; Update the application of the service to be tested.

4. The gateway fault detection method according to claim 1, characterized in that, Also includes: Deploy the test client on the client device connected to the gateway under test; The test server is deployed on the server-side device connected to the gateway under test.

5. The gateway fault detection method according to claim 1, characterized in that, The test request includes a first test request, and detecting a mismatch between the test request and the response data includes: Obtain the preset valid response data corresponding to the first test request, and determine whether the first response data corresponding to the first test request is the same as the preset valid response data; If they are not the same, update the exception count; When the anomaly count is greater than the anomaly threshold, it is determined that the test request and the response data do not match.

6. The gateway fault detection method according to claim 1, characterized in that, The test request includes a second test request, and detecting a mismatch between the test request and the response data includes: Determine whether there is a second response data corresponding to the second test request; If the second response data does not exist, update the exception count; When the anomaly count is greater than the anomaly threshold, it is determined that the test request and the response data do not match.

7. The gateway fault detection method according to claim 6, characterized in that, The determination of whether there is second response data corresponding to the second test request includes: Obtain the first user connection characteristics of the second test request; Obtain the second user connection feature corresponding to the candidate response data; wherein, the candidate response data is the response data obtained within a preset time period after the second test request is sent; Determine whether the second user connection feature contains a target user connection feature that is identical to the first user connection feature; If the target user connection characteristics do not exist, then it is determined that the second response data does not exist.

8. A gateway fault detection device, characterized in that, include: The sending module is used to control the test client to send test requests through the test virtual bridge in the gateway under test, so that the test request is processed by the gateway under test and then forwarded to the test server through the test virtual bridge; both the test client and the test server are deployed in the gateway under test. The gateway under test also includes an application virtual bridge, and the test virtual bridge and the application virtual bridge correspond to the same application server. The response module is used to control the test server to respond to the target test requests obtained through the test virtual bridge and obtain response data; The fault determination module is used to determine that the gateway under test has experienced a gateway fault if the test request and the response data do not match.

9. An electronic device, characterized in that, Includes memory and processor, wherein: The memory is used to store computer programs; The processor is configured to execute the computer program to implement the gateway fault detection method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store a computer program, wherein the computer program, when executed by a processor, implements the gateway fault detection method as described in any one of claims 1 to 7.

Images