Network fault detection method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a network fault detection method and device, electronic equipment and a storage medium. The method comprises the following steps: sending a traffic monitoring instruction carrying a server address to network equipment; receiving traffic monitoring information collected by the network device in response to the traffic monitoring instruction, the traffic monitoring information comprising traffic transmission information of a target traffic, and the target traffic being a traffic forwarded between a target server to which the server address belongs and the terminal device through the network device; the target traffic comprises simulation traffic generated by the terminal equipment through simulating a user behavior based on the task information and feedback traffic generated by the target server in response to the simulation traffic; and performing fault detection according to the analog flow and the feedback flow to obtain a network fault detection result. According to the method, the target flow is the application layer flow generated by simulating the user operation, and the application layer flow truly reflects the service interaction process, so that the network fault can be accurately analyzed based on the flow monitoring information of the application layer flow.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a network fault detection method, apparatus, electronic device, and storage medium. Background Technology

[0002] In the field of traditional network fault detection, technical solutions mainly rely on low-level network protocol analysis (such as ICMP, SNMP) or physical / transport layer traffic statistics (such as port packet loss rate, bandwidth utilization). However, with the increasing complexity of network services, especially the diversification of application layer services (such as HTTP, HTTPS, DNS), existing tools (such as Ping, Traceroute) lack in-depth parsing capabilities for application layer protocols (such as HTTPS, SMTP) in the 7-layer model, resulting in low test coverage and an inability to identify application layer interaction faults. Summary of the Invention

[0003] In view of this, embodiments of this application propose a network fault detection method, apparatus, electronic device, and storage medium, which can accurately determine and perform network fault detection.

[0004] In a first aspect, embodiments of this application provide a network fault detection method applied to a terminal device. The method includes: acquiring task detection information, the task detection information including task information of a task to be detected and the server address of the server executing the task; sending a traffic monitoring instruction carrying the server address to a network device; receiving traffic monitoring information collected by the network device in response to the traffic monitoring instruction, the traffic monitoring information including traffic transmission information of target traffic, wherein the target traffic is traffic forwarded between the target server to which the server address belongs and the terminal device through the network device; the target traffic includes simulated traffic generated by the terminal device based on the task information simulating user behavior, and feedback traffic generated by the target server in response to the simulated traffic; and performing fault detection based on the traffic monitoring information to obtain a network fault detection result.

[0005] Secondly, embodiments of this application provide a network fault detection device applied to a terminal device. The device includes: a task information acquisition module for acquiring task detection information, the task detection information including task information of a task to be detected and the server address of the server executing the task; an instruction sending module for sending a traffic monitoring instruction carrying the server address to a network device; a traffic information acquisition module for receiving traffic monitoring information collected by the network device in response to the traffic monitoring instruction, the traffic monitoring information including traffic transmission information of a target traffic, and the target traffic being the traffic forwarded between the target server to which the server address belongs and the terminal device through the network device; the target traffic including simulated traffic generated by the terminal device based on the task information simulating user behavior, and feedback traffic generated by the target server in response to the simulated traffic; and a fault result acquisition module for performing fault detection based on the traffic monitoring information to obtain a network fault detection result.

[0006] In one possible implementation, the network fault detection device further includes a traffic generation module, a traffic transmission module, and a task completion judgment module; the traffic generation module is used to generate simulated traffic based on the task information by simulating user behavior, and transmit the simulated traffic to the target server through the network device, so that the target server generates feedback traffic based on the simulated traffic; the traffic transmission module is used to receive the feedback traffic sent by the target server to the terminal device through the network device; the task completion judgment module is used to determine whether the task to be detected has been completed based on the feedback traffic and the task information; the traffic information acquisition module is further used to acquire the traffic transmission information of the target traffic collected by the network device in response to the traffic monitoring command when the task to be detected is completed.

[0007] In one possible implementation, the network fault detection device further includes an instruction receiving and judging module, used to determine whether a network monitoring termination instruction has been received when the task to be detected has not been completed; and a traffic information acquisition module, used to acquire traffic transmission information of the target traffic collected by the network device in response to the traffic monitoring instruction when the network monitoring termination instruction is received.

[0008] In one possible implementation, the target traffic further includes Domain Name System (DNS) request traffic and DNS response traffic, and the transmission information includes transmission time. The fault result acquisition module includes a response duration acquisition submodule, a first judgment submodule, a response delay acquisition submodule, and a fault result acquisition submodule. The response duration acquisition submodule is used to obtain the task response duration based on the transmission time corresponding to the simulated traffic and the feedback traffic, respectively. The first judgment submodule is used to determine whether the task response duration is less than a preset response duration. The response delay acquisition submodule is used to obtain the DNS response delay based on the DNS request traffic and DNS response traffic when the task response duration is not less than the preset response duration. The fault result acquisition submodule is used to generate a network fault detection result to indicate DNS service abnormality when the DNS response delay is not less than the preset delay.

[0009] In one possible implementation, the fault result acquisition module further includes a transmission speed acquisition submodule, which is used to obtain the data transmission speed based on the data transmission volume and transmission time corresponding to the simulated traffic and the feedback traffic when the task response time is less than the preset response time; the response delay acquisition submodule is also used to obtain the domain name system response delay based on the domain name system request traffic and the domain name system response traffic when it is determined that the data transmission speed is abnormal.

[0010] In one possible implementation, the traffic monitoring information further includes the number of packet losses counted for the task to be detected at multiple times; the fault result acquisition module further includes a packet loss judgment submodule, which is used to determine whether the network device has experienced packet loss based on the number of packet losses at multiple times when the domain name system response delay is less than a preset delay; the fault result acquisition submodule is also used to generate a network fault detection result to indicate the existence of abnormal routing configuration or abnormal transmission line when it is determined that the network device has not experienced packet loss.

[0011] In one possible implementation, the fault result acquisition module further includes a second judgment submodule, used to determine whether the network device has deployed a packet loss policy corresponding to the server address when it is determined that packet loss has occurred in the network device; the fault acquisition submodule is used to generate a network fault detection result to indicate abnormal network device performance when it is determined that the network device has not deployed a packet loss policy corresponding to the server address; the fault acquisition submodule is also used to generate a network fault detection result to prompt for checking the network device's packet loss policy when it is determined that the network device has deployed a packet loss policy corresponding to the server address.

[0012] In one possible implementation, the network fault detection device further includes a result display module for displaying the network fault detection results via a web user interface.

[0013] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory; one or more programs are stored in the memory and configured to be executed by the processor to implement the above-described method.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing program code, wherein the above-described method is executed when the program code is run by a processor.

[0015] Fifthly, embodiments of this application provide a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device retrieves the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method described above.

[0016] This application provides a network fault detection method, apparatus, electronic device, and storage medium. The method includes: acquiring task detection information, which includes task information of a task to be detected and the server address of the server executing the task; sending a traffic monitoring command carrying the server address to a network device; receiving traffic monitoring information collected by the network device in response to the traffic monitoring command, wherein the traffic monitoring information includes traffic transmission information of target traffic, and the target traffic is traffic forwarded between the target server (to which the server address belongs) and the terminal device through the network device; the target traffic includes simulated traffic generated by the terminal device based on the task information simulating user behavior, and feedback traffic generated by the target server in response to the simulated traffic; and performing fault detection based on the traffic monitoring information to obtain a network fault detection result. By employing the above method, since the target traffic is application-layer traffic generated by simulating user operations and consistent with actual business operations, this application-layer traffic truly reflects the business interaction process. Therefore, traffic monitoring information based on application-layer traffic can accurately analyze network faults, avoiding the problem in related technologies where the inability to simulate real user behavior leads to low application-layer test coverage and thus inaccurate fault detection results. Attached Figure Description

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

[0018] Figure 1A flowchart illustrating a network fault detection method provided in an embodiment of this application is shown;

[0019] Figure 2 It shows Figure 1 A flowchart illustrating step S140;

[0020] Figure 3 This paper illustrates another flowchart of a network fault detection method provided in an embodiment of this application.

[0021] Figure 4 A schematic diagram of a network fault detection system provided in an embodiment of this application is shown;

[0022] Figure 5 This paper shows a connection block diagram of a network fault detection device according to an embodiment of this application;

[0023] Figure 6 A structural block diagram of an electronic device for performing the methods of embodiments of this application is shown. Detailed Implementation

[0024] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0025] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0026] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0027] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0028] It should be noted that "multiple" in this article refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0029] Figure 1 This application provides a network fault detection method that can be applied to terminal devices. The method includes:

[0030] Step S110: Obtain task detection information, which includes task information of the task to be detected and the server address of the server executing the task to be detected.

[0031] In one possible implementation, the simulated detection and inspection command can be generated in response to a user's operation on the visual interface. For example, the user fills in or selects the following in the graphical interface of the WebUI (Web User Interface): the protocol type used by the task to be detected (e.g., HTTP (Hypertext Transfer Protocol), DNS (Domain Name System), SMTP (Simple Mail Transfer Protocol), etc.), task details of the task to be detected, and the server address (e.g., target URL (Uniform Resource Locator)) or target IP (Internet Protocol)). The server address can be manually entered (e.g., www.example.com) or a preset address selected (e.g., www.baidu.com). Subsequently, if the user triggers the target control of the WebUI's graphical interface, a simulated detection command can be generated, and task detection information can be extracted from the WebUI's graphical interface.

[0032] In another possible implementation, the simulated detection and inspection command can be automatically generated by an external system (such as an operation and maintenance platform or a monitoring and alarm system) through an API (Application Programming Interface). For example, when the monitoring system detects abnormal network performance (such as the interface packet loss rate exceeding a threshold), it can call the RESTful API (Representational State Transfer API) of the terminal device to initiate a simulated detection command. This simulated detection command carries the server address and may also carry the protocol type. Upon receiving the simulated detection command, the task to be tested is selected from multiple preset tasks, and the server address carried in the simulated detection command is determined as the server address of the task to be tested.

[0033] The task to be tested can be a login task, a data acquisition task, an email sending task, etc. The task information of the task to be tested can include the task name, as well as task details, such as the application layer protocol used by the task (e.g., HTTP / HTTPS, DNS, SMTP, etc.), test parameters (e.g., number of requests, test duration, data packet size, etc.), authentication information (e.g., login credentials and verification certificates, etc.), and expected results (e.g., preset response time threshold).

[0034] Step S120: Send a traffic monitoring command carrying the server address to the network device.

[0035] The traffic monitoring command can be used to instruct network devices to monitor the traffic transmitted between the target server to which the server address belongs and the terminal device, so as to obtain the traffic transmission time, the amount of data transmitted, and whether packet loss occurred during the transmission.

[0036] Step S130: Receive traffic monitoring information collected by the network device in response to the traffic monitoring command. The traffic monitoring information includes traffic transmission information of the target traffic, and the target traffic is the traffic forwarded between the target server to which the server address belongs and the terminal device through the network device. The target traffic includes simulated traffic generated by the terminal device based on the task information to simulate user behavior, and feedback traffic generated by the target server in response to the simulated traffic.

[0037] The target traffic transmission information may include the time when the network device receives and / or forwards the target traffic, as well as the size of the target traffic data packets; the traffic monitoring information may also include the number of packet losses between the target server (to which the server address belongs) and the terminal device, counted at specified intervals after receiving the traffic monitoring instruction.

[0038] It is worth mentioning that after obtaining the task detection information, the terminal device can execute the task to be detected. Based on the task information, the terminal device can simulate user behavior to generate simulated traffic and transmit this simulated traffic to the target server via the network device. The target server can respond to the simulated traffic by generating feedback traffic and sending this feedback traffic to the terminal device via the network device. It should be understood that the target device can interact with the server one or more times during the execution of the task to be detected.

[0039] The method for obtaining the traffic monitoring information collected by the network device in response to the traffic monitoring command can be either to obtain the traffic monitoring information collected by the network device in response to the traffic monitoring command when it is determined that the task to be detected has been completed, or to obtain the traffic monitoring information collected by the network device in response to the traffic monitoring command when a termination network monitoring command is received from the user. The termination network monitoring command can be used to instruct the network device to stop collecting traffic transmission information between the target server and the terminal device. Specifically, when the terminal device receives the termination network monitoring command, it executes step S130 above and sends the termination network monitoring command to the network device, so that the network device stops collecting traffic monitoring information.

[0040] Step S140: Perform fault detection based on the traffic monitoring information to obtain network fault detection results.

[0041] In one possible implementation, a fault detection result can be predicted based on traffic monitoring information using a fault identification model. The fault identification model can be a pre-trained neural network model, which can be obtained by iteratively training the neural network model using sample traffic monitoring information and the corresponding fault labels.

[0042] In another possible implementation, information such as traffic latency and packet loss rate can be obtained from traffic monitoring information, and the network fault detection result can be determined based on traffic latency and packet loss rate.

[0043] In this implementation, the target traffic also includes Domain Name System (DNS) request traffic and DNS response traffic, and the transmission information includes the transmission time; please refer to reference 2, the above step S140 includes:

[0044] Step S141: Obtain the task response time based on the transmission time corresponding to the simulated traffic and the feedback traffic respectively.

[0045] The transmission time corresponding to the simulated traffic may include the time when the network device sends the simulated traffic and the time when the server receives the simulated traffic, and may also include the time when the network device forwards the simulated traffic. The transmission time corresponding to the feedback traffic may include the time when the server sends the feedback traffic, the time when the terminal device receives the feedback traffic, and may also include the time when the network device forwards the feedback traffic. No specific limitation is made here.

[0046] Step S141 above can be to calculate the difference between the transmission times corresponding to the simulated traffic and the feedback traffic to obtain the task response time.

[0047] It is worth mentioning that if there are multiple simulated traffic and feedback traffic, the total response time or average response time can be obtained based on the transmission time corresponding to each simulated traffic and each feedback traffic, and thus used as the task response time. For example, the difference between the time when the network device forwards each simulated traffic and the time when it forwards the feedback traffic based on that simulated traffic can be calculated to obtain the response time corresponding to each simulated traffic. The response times corresponding to multiple simulated traffic can then be summed or averaged to obtain the task response time.

[0048] Step S142: Determine whether the task response time is less than the preset response time.

[0049] The preset response time can be determined based on the task type and the response time required to execute the task under normal circumstances; no specific limitation is made here.

[0050] If it is not less than, then proceed to step S143: obtain the Domain Name System (DNS) response delay based on the DNS request traffic and DNS response traffic.

[0051] The method of obtaining the DNS response latency based on the DNS request traffic and DNS response traffic is similar to the aforementioned step S141, and will not be described in detail here.

[0052] Step S144: Determine whether the domain name system response latency is less than the preset latency.

[0053] If the domain name system response delay is not less than the preset delay, a network fault detection result is generated to indicate domain name system service abnormalities.

[0054] The preset delay can be set according to the actual situation, and no specific limitation is made here.

[0055] It's worth noting that Domain Name System (DNS) request traffic is the starting point for network requests, and all application-layer services (such as web page access and email sending) rely on DNS resolution results. If the DNS response latency exceeds the preset latency, it indicates that the fault may be concentrated in the DNS service itself or the network links it depends on.

[0056] For example, if a user experiences a timeout when accessing a website, and the Domain Name System (DNS) response delay exceeds a preset delay (e.g., 500ms), the problem can be directly identified as insufficient DNS server performance or network link congestion, without needing to check whether the target server is down.

[0057] If the Domain Name System (DNS) response delay is not less than the preset delay, a network fault detection result is generated to indicate DNS service anomalies.

[0058] In one possible implementation, the traffic transmission information further includes the data transmission volume, and step S140 further includes:

[0059] If the task response time is less than the preset response time, then step S145 is executed: the data transmission speed is obtained based on the data transmission volume and transmission time corresponding to the simulated traffic and the feedback traffic, respectively.

[0060] The data transmission amounts corresponding to the feedback traffic and the simulated traffic can be summed to obtain the total data transmission amount; then, the total transmission amount is divided by the corresponding task duration calculated in step S141 above to obtain the data transmission speed.

[0061] It is worth mentioning that if there are multiple feedback traffic and multiple analog traffic, the total data volume obtained by summing the data transmission volume of each of the multiple feedback traffic and analog traffic can be divided by the total response time obtained by summing the response times of each of the multiple analog traffic to obtain the data transmission speed.

[0062] After obtaining the data transmission speed, step S146 can be executed: determine whether the data transmission speed is normal.

[0063] Specifically, the data transmission speed can be compared with a preset speed threshold. If it is lower than the preset speed threshold, the data transmission speed is determined to be abnormal; if it is not lower than the preset speed threshold, the data transmission speed is determined to be normal. The preset speed threshold can be set according to actual needs, such as based on the link bandwidth of the network device. For example, the preset speed threshold could be 20%, 30%, or 50% of the link bandwidth. The preset speed threshold can also be determined based on the average transmission rate of the past N tasks, such as 70%, 80%, or 60% of the average transmission rate of the past N tasks.

[0064] If the data transmission speed is confirmed to be normal, then there is no network problem.

[0065] If the data transmission speed is determined to be abnormal, then step S143 is executed again: the domain name system response delay is obtained based on the domain name system request traffic and domain name system response traffic.

[0066] In one possible implementation, the traffic monitoring information further includes the number of packet losses counted for the task to be detected at multiple times; step S140 further includes:

[0067] If the domain name system response delay is less than the preset delay, then step S147 is executed: determine whether the network device has experienced packet loss based on the number of packet losses at multiple times.

[0068] Specifically, whether packet loss has occurred in a network device can be determined by whether the number of lost packets changes at multiple points in time. If the number of lost packets changes, it is determined that packet loss has occurred; if the number of lost packets does not change, it is determined that no packet loss has occurred.

[0069] If it is determined that no packet loss has occurred in the network device, a network fault detection result is generated to indicate that there is an abnormal routing configuration or transmission line abnormality.

[0070] In one possible implementation, if it is determined that the network device has experienced packet loss, then step S148 is executed: determine whether the network device has deployed a packet loss policy corresponding to the server address.

[0071] If it is determined that the network device has not deployed a packet loss policy corresponding to the server address, a network fault detection result is generated to indicate abnormal network device performance. If it is determined that the network device has deployed a packet loss policy corresponding to the server address, a network fault detection result is generated to prompt the user to check the network device's packet loss policy.

[0072] By employing steps 141-S148 above, the task response time can be used to quickly determine if there are network performance anomalies. If a network performance anomaly is confirmed, it is further determined whether the response latency has timed out. If it has timed out, it can be determined that there may be an anomaly in the DNS server or the link. At this time, a network fault detection result indicating an abnormal Domain Name System service is generated to avoid ineffective troubleshooting. If the response latency has not timed out, it is determined whether packet loss has occurred. If no packet loss has occurred, there may be a hardware failure. At this time, a network fault detection result indicating an abnormal routing configuration or transmission line is generated. If packet loss has occurred, it is necessary to further determine whether it is policy-based packet loss. If it is policy-based packet loss, a network fault detection result is generated to check whether the packet loss policy is normal. If it is not policy-based packet loss, there may be an abnormality in the performance of network devices. At this time, a network fault detection result is generated. By adopting the above settings, the network fault situation can be accurately analyzed so that users can troubleshoot according to the network fault situation, thereby improving the efficiency of network fault troubleshooting.

[0073] This application provides a network fault detection method. When network fault detection is required, the method involves: acquiring task detection information; sending a traffic monitoring command carrying the server address to a network device; receiving traffic monitoring information collected by the network device in response to the traffic monitoring command; the traffic monitoring information including traffic transmission information of target traffic, wherein the target traffic is the traffic forwarded between the target server (to which the server address belongs) and the terminal device through the network device; the target traffic including simulated traffic generated by the terminal device based on the task information simulating user behavior, and feedback traffic generated by the target server in response to the simulated traffic; and performing fault detection based on the traffic monitoring information to obtain a network fault detection result. By adopting the above method, since the target traffic is application-layer traffic generated by simulating user operations and consistent with actual business, this application-layer traffic truly reflects the business interaction process. Therefore, traffic monitoring information based on application-layer traffic can accurately analyze network faults, avoiding the problem in related technologies where the inability to simulate real user behavior leads to low application-layer test coverage and thus inaccurate fault detection results.

[0074] In one possible implementation, please refer to Figure 3 The method further includes the following steps before performing step S130:

[0075] Step S150: Based on the task information, simulate user behavior to generate simulated traffic, and transmit the simulated traffic to the target server through the network device, so that the target server generates feedback traffic based on the simulated traffic.

[0076] Specifically, the task information carries application layer protocols, which can be used to determine the script logic for simulating user behavior. Based on the application layer protocols and script logic carried in the task information, the protocol library is called to generate simulated traffic that conforms to the protocol specifications.

[0077] Step S160: Receive the feedback traffic sent by the target server to the terminal device through the network device.

[0078] Specifically, you can use packet capture tools (such as tcpdump or Wireshark) on the terminal or network device to capture the feedback traffic.

[0079] Step S170: Determine whether the task to be detected has been completed based on the feedback traffic and the task information.

[0080] Specifically, it can detect whether the feedback traffic contains the expected content (such as an HTTP 200 status code or a successful email delivery receipt). If it does, the execution is complete; otherwise, it is considered complete. It can also verify the completeness of multi-step tasks based on task information (such as an FTP task requiring the completion of the entire process of connecting, transferring, and disconnecting).

[0081] If the task to be detected is completed, then step S130 is executed.

[0082] If the task to be detected has not been completed, then proceed to step S180: determine whether a command to terminate network monitoring has been received.

[0083] The terminal device can receive network monitoring commands through associated devices or operating interfaces. If received, step S130 above can be executed; if not received, step S190 is executed: based on the feedback traffic and task information, simulate user behavior to generate new simulated traffic, and transmit the simulated traffic to the target server through the network device, so that the target server generates feedback traffic based on the simulated traffic; and return to execute step S160 until the task to be detected is completed or a termination network monitoring command is received, and then execute the step of obtaining the traffic transmission information of the target traffic collected by the network device in response to the traffic monitoring command.

[0084] By adopting the above process, user operations can be realistically reproduced using simulated traffic and feedback traffic to reflect the business execution process, so as to accurately detect network faults based on the traffic transmission information of simulated traffic and feedback traffic collected by the network devices.

[0085] Please combine Figure 4 As shown, this application provides a network fault detection method, applied to, for example... Figure 4 The network fault detection system shown includes terminal devices, network devices, and a target server. The terminal devices have an application program installed, providing an interactive interface, and include software modules such as a data analysis module, a user behavior simulation module, and a traffic transmission module. The network devices have software modules such as an HTTPS server module and a forwarding layer monitoring module.

[0086] The interactive interface can be a web browser that interacts with the user, where the user can create a network service awareness detection task. It also supports displaying the detection and analysis results of network service awareness obtained from the device in an intuitive graphical way.

[0087] The user behavior simulation module can be a user behavior simulation program deployed on a terminal device, supporting the simulation of common application layer protocol behaviors such as http, https, DNS, DHCP, FTP, SSH, SMTP, POP3, IMAP, and other application layer protocols.

[0088] The traffic transmission module may include a client that supports the aforementioned application layer protocols. This client can simulate user network usage to generate simulated traffic and send it to the target server via network devices. The HTTPS server module receives traffic monitoring commands uploaded by terminal devices and can also receive commands from terminal devices to terminate network monitoring.

[0089] The forwarding layer monitoring module is used to respond to traffic monitoring commands and monitor the path and packet loss of traffic forwarded between terminal devices and target servers.

[0090] The data analysis module is used to acquire traffic monitoring information and analyze network fault detection results so that the interactive interface can display the network fault detection results.

[0091] When using the aforementioned network fault detection system for network fault detection, users can operate on their PC (terminal) to create task detection information. The task detection information includes task details, the protocol to be tested, and the server address (which can be a URL address or an IP address) of the server executing the task to be tested. Afterward, it can be submitted to the terminal device.

[0092] After receiving the task detection information, the terminal device can send a traffic monitoring command carrying the server address to the network device. When the HTTPS server module of the network device receives the traffic monitoring command, it forwards the traffic monitoring command to the forwarding layer monitoring module so that the forwarding layer monitoring module can start monitoring the traffic of the terminal device.

[0093] The terminal device can also forward the received task detection information to the user behavior simulation module. The user behavior simulation module is responsible for scheduling internal user interactions; for example, some services require login before sending emails. The user behavior simulation module initiates an HTTPS access action, generates a client through the traffic injection module, executes the user behavior, generates simulated traffic, and sends the simulated traffic to the target server via network devices. The user behavior simulation module can also track the time it takes to receive a response and the size of the response data.

[0094] It's worth noting that the terminal device first sends a Domain Name System (DNS) request to the target server. This allows the target server to resolve the URL after receiving the DNS response traffic based on the DNS request, and then initiate an HTTPS request. During this process, the forwarding layer monitoring module can capture the user's DNS request traffic, obtain the DNS address, and then monitor the subsequent TCP interaction flow (i.e., simulated traffic and response traffic). The process also requires collecting information such as the outgoing interface lines of the aforementioned traffic, the routes forwarded by the user, the user's DNS latency, and the device's packet loss status.

[0095] If the user actively terminates the network monitoring task, or if the network monitoring task completes and stops, the terminal device will initiate a request to stop network monitoring to the forwarding layer monitoring module on the device side. This will cause the forwarding layer monitoring module to stop collecting data and transmit the collected data to the terminal device's data analysis module. The terminal device's data analysis module can then execute steps S141-S146 as described above to obtain network fault detection results. Finally, the fault detection results are displayed through an interactive interface.

[0096] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0097] Please see Figure 5Another embodiment of this application provides a network fault detection device 200, applied to a terminal device. The network fault detection device 200 includes: a task information acquisition module 210, used to acquire task detection information, the task detection information including task information of the task to be detected and the server address of the server executing the task to be detected; an instruction sending module 220, used to send a traffic monitoring instruction carrying the server address to the network device; a traffic information acquisition module 230, used to receive traffic monitoring information collected by the network device in response to the traffic monitoring instruction, the traffic monitoring information including traffic transmission information of target traffic, and the target traffic being the traffic forwarded between the target server to which the server address belongs and the terminal device through the network device; the target traffic including simulated traffic generated by the terminal device based on the task information simulating user behavior, and feedback traffic generated by the target server in response to the simulated traffic; and a fault result acquisition module 240, used to perform fault detection based on the traffic monitoring information to obtain a network fault detection result.

[0098] In one possible implementation, the network fault detection device 200 further includes a traffic generation module, a traffic transmission module, and a task completion judgment module; the traffic generation module is used to generate simulated traffic based on the task information by simulating user behavior, and transmit the simulated traffic to the target server through the network device, so that the target server generates feedback traffic based on the simulated traffic; the traffic transmission module is used to receive the feedback traffic sent by the target server to the terminal device through the network device; the task completion judgment module is used to determine whether the task to be detected has been completed based on the feedback traffic and the task information; the traffic information acquisition module 230 is further used to acquire the traffic transmission information of the target traffic collected by the network device in response to the traffic monitoring command when the task to be detected is completed.

[0099] In one possible implementation, the network fault detection device 200 further includes an instruction receiving and judging module, used to determine whether a network monitoring termination instruction has been received when the task to be detected has not been completed; a traffic generation module, used to generate new simulated traffic based on the feedback traffic and task information when no network monitoring termination instruction has been received; and a traffic information acquisition module, used to acquire traffic transmission information of the target traffic collected by the network device in response to the traffic monitoring instruction when the task to be detected has been completed or a network monitoring termination instruction has been received.

[0100] In one possible implementation, the target traffic further includes Domain Name System (DNS) request traffic and DNS response traffic, and the transmission information includes transmission time. The fault result acquisition module 240 includes a response duration acquisition submodule, a first judgment submodule, a response delay acquisition submodule, and a fault result acquisition submodule. The response duration acquisition submodule is used to obtain the task response duration based on the transmission time corresponding to the simulated traffic and the feedback traffic, respectively. The first judgment submodule is used to determine whether the task response duration is less than a preset response duration. The response delay acquisition submodule is used to obtain the DNS response delay based on the DNS request traffic and DNS response traffic when the task response duration is not less than the preset response duration. The fault result acquisition submodule is used to generate a network fault detection result to indicate DNS service abnormality when the DNS response delay is not less than the preset delay.

[0101] In one possible implementation, the fault result acquisition module 240 further includes a transmission speed acquisition submodule, which is used to obtain the data transmission speed based on the data transmission volume and transmission time corresponding to the simulated traffic and the feedback traffic when the task response time is less than the preset response time; the response delay acquisition submodule is also used to obtain the domain name system response delay based on the domain name system request traffic and the domain name system response traffic when it is determined that the data transmission speed is abnormal.

[0102] In one possible implementation, the traffic monitoring information further includes the number of packet losses counted for the task to be detected at multiple times; the fault result acquisition module 240 further includes a packet loss judgment submodule, which is used to determine whether the network device has experienced packet loss based on the number of packet losses at multiple times when the domain name system response delay is less than a preset delay; the fault result acquisition submodule is also used to generate a network fault detection result to indicate the existence of abnormal routing configuration or abnormal transmission line when it is determined that the network device has not experienced packet loss.

[0103] In one possible implementation, the fault result acquisition module 240 further includes a second judgment submodule, used to determine whether the network device has deployed a packet loss policy corresponding to the server address when it is determined that packet loss has occurred in the network device; the fault acquisition submodule is used to generate a network fault detection result to prompt abnormal network device performance when it is determined that the network device has not deployed a packet loss policy corresponding to the server address; the fault acquisition submodule is also used to generate a network fault detection result to prompt for checking the network device's packet loss policy when it is determined that the network device has deployed a packet loss policy corresponding to the server address.

[0104] In one possible implementation, the network fault detection device 200 further includes a result display module for displaying the network fault detection results via a web user interface.

[0105] Each module in the above-described device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module. It should be noted that the device embodiments in this application correspond to the foregoing method embodiments. The specific principles of the device embodiments can be found in the foregoing method embodiments, and will not be repeated here.

[0106] The following will combine Figure 6 This application provides a description of an electronic device 100.

[0107] Please see Figure 6 Based on the methods provided in the above embodiments, this application also provides another electronic device 100 including a processor 102 capable of executing the aforementioned methods. The electronic device 100 may be a server or a terminal device.

[0108] The electronic device 100 also includes a memory 104. The memory 104 stores a program that can execute the contents of the foregoing embodiments, and the processor 102 can execute the program stored in the memory 104.

[0109] The processor 102 may include one or more cores for data processing and message matrix units. The processor 102 connects to various parts within the electronic device 100 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 104, and by calling data stored in the memory 104. Optionally, the processor 102 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 102 may integrate one or more of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 102 and may be implemented separately using a communication chip.

[0110] The memory 104 may include random access memory (RAM) or read-only memory (ROM). The memory 104 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 104 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function, instructions for implementing the various method embodiments described below, etc. The data storage area may also store data acquired by the electronic device 100 during use (e.g., parking location, environmental information, and images).

[0111] The electronic device 100 may also include a network module and a screen. The network module is used to receive and transmit electromagnetic waves, converting electromagnetic waves into electrical signals, thereby enabling communication with communication networks or other devices, such as audio playback devices. The network module may include various existing circuit elements used to perform these functions, such as antennas, radio frequency transceivers, digital signal processors, encryption / decryption chips, SIM cards, memory, etc. The network module can communicate with various networks such as the Internet, corporate intranets, and wireless networks, or communicate with other devices via wireless networks. The aforementioned wireless networks may include cellular telephone networks, wireless local area networks, or metropolitan area networks. The screen can display interface content and perform data interaction, such as displaying the aforementioned interface and triggering operations through the screen.

[0112] This application also provides a structural block diagram of a computer-readable storage medium. The computer-readable medium stores program code, which can be called by a processor to execute the methods described in the above method embodiments.

[0113] Computer-readable storage media can be electronic storage devices such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Optionally, computer-readable storage media includes non-transitory computer-readable storage medium. The computer-readable storage medium has storage space for program code that performs any of the method steps described above. This program code can be read from or written to one or more computer program products. The program code can be compressed, for example, in a suitable form.

[0114] This application also provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods described in the various optional implementations above.

[0115] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A network fault detection method, characterized by, The method is applied to a terminal device, and comprises the following steps: Obtaining task detection information, wherein the task detection information comprises task information of a task to be detected and a server address of a server for executing the task to be detected; Sending a traffic monitoring instruction carrying the server address to a network device; Receiving traffic monitoring information collected by the network device in response to the traffic monitoring instruction, wherein the traffic monitoring information comprises traffic transmission information of target traffic, and the target traffic is traffic forwarded between a target server to which the server address belongs and the terminal device through the network device; the target traffic comprises simulation traffic generated by simulating user behavior based on the task information, and feedback traffic generated by the target server in response to the simulation traffic; Performing fault detection based on the traffic monitoring information to obtain a network fault detection result.

2. The method of claim 1, wherein, Before the step of obtaining the traffic transmission information of the target traffic collected by the network device in response to the traffic monitoring instruction, the method further comprises the following steps: Generating simulation traffic by simulating user behavior based on the task information, and transmitting the simulation traffic to the target server through the network device, so that the target server generates feedback traffic based on the simulation traffic; Receiving the feedback traffic sent by the target server to the terminal device through the network device; Determining whether the task to be detected is executed completely based on the feedback traffic and the task information; If the task to be detected is executed completely, performing the step of obtaining the traffic transmission information of the target traffic collected by the network device in response to the traffic monitoring instruction.

3. The method of claim 2, wherein, The method further comprises the following steps: If the task to be detected is not executed completely, determining whether a network monitoring termination instruction is received; If the network monitoring termination instruction is received, performing the step of obtaining the traffic transmission information of the target traffic collected by the network device in response to the traffic monitoring instruction.

4. The method of claim 1, wherein, The target traffic further comprises domain name system request traffic and domain name system response traffic, and the transmission information comprises transmission time; The step of performing fault detection based on the traffic monitoring information to obtain a network fault detection result comprises the following steps: Obtaining a task response duration based on the transmission time corresponding to the simulation traffic and the feedback traffic respectively; Determining whether the task response duration is less than a preset response duration; If the task response duration is not less than the preset response duration, obtaining a domain name system response time delay based on the domain name system request traffic and the domain name system response traffic; If the domain name system response time delay is greater than a preset time delay, generating a network fault detection result for prompting domain name system service abnormity.

5. The method of claim 4, wherein, The traffic transmission information further comprises data transmission amount, and the step of performing fault detection based on the traffic monitoring information to obtain a network fault detection result further comprises the following steps: If the task response duration is less than the preset response duration, obtaining a data transmission speed based on the data transmission amount and the transmission time corresponding to the simulation traffic and the feedback traffic respectively; If it is determined that the data transmission speed is abnormal, performing the step of obtaining the domain name system response time delay based on the domain name system request traffic and the domain name system response traffic.

6. The method of claim 4, wherein, The flow monitoring information further comprises a number of packet losses counted for the to-be-detected task at multiple time instants; The obtaining a network fault detection result according to the flow monitoring information further comprises: If the domain name system response delay is less than a preset delay, determining whether the network device has packet loss according to the number of packet losses at multiple time instants; If it is determined that the network device has no packet loss, generating a network fault detection result for prompting that there is a routing configuration exception or a transmission line exception.

7. A network fault detection apparatus characterized by comprising: The apparatus is applied to a terminal device, and the apparatus comprises: a task information obtaining module, configured to obtain task detection information, the task detection information comprising task information of a to-be-detected task and a server address of a server performing the to-be-detected task; an instruction sending module, configured to send a flow monitoring instruction carrying the server address to a network device; a flow information obtaining module, configured to receive flow monitoring information collected by the network device in response to the flow monitoring instruction, the flow monitoring information comprising flow transmission information of target flow, and the target flow being flow forwarded between a target server to which the server address belongs and the terminal device through the network device; the target flow comprising simulation flow generated by the terminal device based on the task information to simulate user behavior, and feedback flow generated by the target server in response to the simulation flow; a fault result obtaining module, configured to perform fault detection according to the flow monitoring information to obtain a network fault detection result.

8. An electronic device, comprising: comprise: one or more processors; a memory; one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs are configured to perform the method of any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer readable storage medium stores program code, and the program code can be invoked and executed by the processor to perform the method of any one of claims 1-6.

10. A computer program product comprising computer programs / instructions, characterized in that, The computer program / instruction is executed by the processor to implement the steps of the method of any one of claims 1-6.

Images