Network traffic detection method and system, vehicle and computer program product

Abstract

The invention discloses a network traffic detection method and system, a vehicle and a computer program product. The method is applied to a kernel mode driving end, the kernel mode driving end and a user mode application end run in the same operating system, and the method comprises the steps that process identification information from the user mode application end is received, and the process identification information is used for identifying a process corresponding to a to-be-detected service; identifying that the file is a socket file by using a file descriptor of the file associated with the process identification information, the file descriptor being used for identifying the file opened through the process; according to the socket file, accessing network stack data of a kernel where the kernel mode driving end is located to obtain a traffic detection result of the service, the traffic detection result being used for representing the network traffic used by the service in the process of using the process to perform network communication; and sending a flow detection result to the user mode application end for display. The technical problem of low network flow detection efficiency is solved.

Description

Technical Field

[0001] This application relates to the field of computer network technology, and more specifically, to a method, system, vehicle, and computer program product for detecting network traffic. Background Technology

[0002] Currently, in computing environments, especially in applications based on operating systems (such as Linux), real-time monitoring and detailed statistics of network traffic are becoming increasingly important. This not only helps optimize network performance but also plays a crucial role in security threat detection and resource management.

[0003] Network traffic monitoring tools in related technologies, such as Transmission Control Protocol Packet dump (tcpdump), network statistics (netstat), and socket statistics (ss), are based on user-space packet capture mechanisms, that is, they capture and analyze data packets from network interfaces through the libpcap library or other similar technologies.

[0004] While the methods described above are widely used in network monitoring, they have significant limitations in terms of real-time performance. User-space packet capture tools rely on capturing data packets from network interfaces. These capture methods are affected by kernel scheduling and packet processing delays, resulting in poor real-time performance of traffic statistics and difficulty in reflecting instantaneous changes on the network. Therefore, the technical problem of low network traffic detection efficiency remains.

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

[0006] This application provides a method, system, vehicle, and computer program product for detecting network traffic, in order to at least solve the technical problem of low efficiency in network traffic detection.

[0007] According to one aspect of the embodiments of this application, a method for detecting network traffic is provided. This method is applied to a kernel-mode driver, where the kernel-mode driver and a user-mode application run in the same operating system. The method includes: receiving process identification information from the user-mode application, wherein the process identification information identifies the process corresponding to the service to be detected, and the service runs on the user-mode application; identifying the file as a socket file using a file descriptor associated with the process identification information, wherein the file descriptor identifies a file opened by a process; accessing the network stack data of the kernel where the kernel-mode driver resides according to the socket file to obtain a traffic detection result for the service, wherein the traffic detection result represents the network traffic used by the service during network communication using the process; and sending the traffic detection result to the user-mode application for display.

[0008] Optionally, according to the socket file, access the network stack data of the kernel where the kernel-mode driver resides to obtain the service traffic detection result, including: according to the socket file, access the kernel's network stack data to obtain the socket structure corresponding to the socket file; using the socket structure, obtain the network traffic value and / or network status information used by the service during network communication using the process, wherein the network status information is used to indicate whether the network status corresponding to the network traffic is a normal network status or an abnormal network status; and determine the traffic value and / or network status information as the traffic detection result.

[0009] Optionally, using the socket structure, the traffic value and / or network status information of the network traffic used by the service during network communication using the process are obtained, including: determining the network protocol type used by the service during network communication using the process, wherein the network protocol type includes Transmission Control Protocol type and / or User Datagram Protocol type; and using the socket structure, obtaining the traffic value and / or network status information of the network traffic corresponding to the network protocol type.

[0010] Optionally, the kernel-mode driver includes a kernel driver module and a protocol stack module. It accesses the kernel's network stack data according to the socket file to obtain the socket structure corresponding to the socket file. This includes: the kernel driver module accessing the kernel's network stack data according to the socket file to determine the socket structure in the protocol stack module; using the socket structure to obtain the network traffic value and / or network status information used by the service during network communication using the process. This includes: the protocol stack module using the socket structure to obtain the network traffic value and / or network status information; and sending the traffic detection results to the user-mode application for display. This includes: the protocol stack module sending the traffic detection results to the user-mode application for display via the kernel driver module.

[0011] Optionally, identifying a file as a socket file using the file descriptor associated with the process identification information includes: obtaining a list of file handles opened by the process corresponding to the process identification information, wherein the file handle list is used to store the mapping relationship between different file descriptors and different file objects; and identifying the file as a socket file based on the file objects corresponding to the file descriptors in the file handle list.

[0012] Optionally, identifying a file as a socket file based on the file object corresponding to the file descriptor in the file handle list includes: traversing each file descriptor in the file handle list; determining a target file object in the file handle list that has a mapping relationship with the traversed target file descriptor; and identifying the file corresponding to the target file descriptor as a socket file based on the target file object.

[0013] Optionally, the kernel-mode driver includes a protocol stack module that, based on the target file object, identifies the file corresponding to the target file descriptor as a socket file, including: the protocol stack module determining the target pointer type corresponding to the socket file to be identified, wherein the target pointer type is a predefined pointer type for the socket file to be identified; the protocol stack module, in response to the pointer type of the target file object being the target pointer type, identifies the file corresponding to the target file descriptor as a socket file; and / or, the kernel-mode driver includes a kernel driver module that iterates through each file descriptor in the file handle list, including: the kernel driver module iterating through each file descriptor in the file handle list; and / or, in the file handle list, determining the target file object that has a mapping relationship with the traversed target file descriptor, including: the kernel driver module determining the target file object that has a mapping relationship with the target file descriptor in the file handle list.

[0014] Optionally, obtaining the list of file handles opened by the process corresponding to the process identification information includes: using the process identification information to find the process's main data structure in the kernel, and determining a first type pointer from the main data structure, wherein the main data structure includes information for describing the process, including process identification information; accessing the file management data structure pointed to by the first type pointer, and determining a second type pointer from the file management data structure, wherein the file management data structure includes information for maintaining file descriptors; and reading the list of file handles pointed to by the second type pointer.

[0015] Optionally, according to the socket file, the detection service obtains traffic detection results by detecting the network traffic used by the process during network communication, including: locking the socket file; obtaining traffic detection results by detecting the network traffic used by the process during network communication according to the locked socket file; and unlocking the locked socket file after obtaining traffic detection results by detecting the network traffic used by the process during network communication according to the socket file.

[0016] Optionally, receiving process identification information from the user-space application includes: receiving process identification information from the first control instruction in response to a first control instruction from the control interface in the user-space application; and sending traffic detection results to the user-space application for display includes: sending traffic detection results corresponding to the network protocol type in the second control instruction to the user-space application for display in response to a second control instruction from the control interface.

[0017] According to another aspect of the embodiments of this application, a network traffic detection system is also provided. This system may include: a user-mode application terminal, configured to send process identification information to a kernel-mode driver terminal, wherein the process identification information is used to identify the process corresponding to the service to be detected, and the service runs on the user-mode application terminal; a kernel-mode driver terminal, configured to identify a file as a socket file using a file descriptor associated with the process identification information, wherein the file descriptor is used to identify a file opened by a process; accessing the network stack data of the kernel where the kernel-mode driver terminal resides according to the socket file to obtain the service traffic detection result, wherein the traffic detection result is used to represent the network traffic used by the service during network communication using the process; and sending the traffic detection result to the user-mode application terminal; wherein the user-mode application terminal is used to display the traffic detection result.

[0018] According to another aspect of the embodiments of this application, a network traffic detection device is also provided. The device may include: a receiving unit, configured to receive process identification information from a user-mode application, wherein the process identification information is used to identify the process corresponding to the service to be detected, and the service runs on the user-mode application; an identification unit, configured to identify the file as a socket file using the file descriptor of the file associated with the process identification information, wherein the file descriptor is used to identify the file opened by the process; an access unit, configured to access the network stack data of the kernel where the kernel-mode driver is located according to the socket file, and obtain the traffic detection result of the service, wherein the traffic detection result is used to represent the network traffic used by the service in the process of using the process for network communication; and a sending unit, configured to send the traffic detection result to the user-mode application for display.

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

[0020] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0021] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

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

[0023] According to another aspect of the embodiments of this application, a computer program is also provided, which, when executed by a processor, implements the methods of the various embodiments of this application.

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

[0025] In this embodiment, if process identification information sent from a user-space application is detected, the file descriptor of the file associated with the process identification information can be obtained, and the file can be identified as a socket file using the file descriptor. Based on the socket file, the network stack data of the kernel where the kernel-space driver resides is accessed to obtain the traffic detection result of the service to be monitored identified by the process identification information. The traffic detection result can then be returned to the user-space application for display.

[0026] In this embodiment, after the kernel-mode driver receives the process identification information from the user-mode application, it does not rely on the user-space packet capture mechanism in related technologies. Instead, it directly uses file descriptors to locate the process-related socket file, thereby seamlessly accessing the kernel network stack data. This method avoids the complex process of network monitoring tools capturing packets from the network interface and transmitting them to user space, eliminating the latency and performance loss caused by kernel-user space interaction. Furthermore, it directly reads data in kernel mode, greatly accelerating the speed of traffic data access. In summary, by directly accessing and processing data in kernel mode, the path for network traffic detection is simplified, the speed of traffic data processing is improved, and the efficiency and real-time performance of network traffic detection are fundamentally improved. This achieves the technical effect of improving the efficiency of network traffic detection and solves the technical problem of network traffic detection efficiency. Attached Figure Description

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

[0028] Figure 1 This is a flowchart illustrating a network traffic detection method according to an embodiment of this application;

[0029] Figure 2 This is a flowchart illustrating a process-level network traffic statistics method in a Linux environment according to an embodiment of this application;

[0030] Figure 3 This is a flowchart illustrating a method for finding a file handle list based on process identifier information, according to an embodiment of this application.

[0031] Figure 4 This is a schematic diagram of a network traffic detection system according to an embodiment of this application;

[0032] Figure 5 This is a structural block diagram of a network traffic detection device according to an embodiment of this application;

[0033] Figure 6 This is a structural block diagram of an autonomous vehicle according to an embodiment of this application. Detailed Implementation

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

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

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

[0037] This application provides a vehicle navigation control method. This method can be used to detect network traffic in preset application scenarios. These preset application scenarios can include the following scenarios in the vehicle field: autonomous driving scenarios for commuting, AI-powered driver assistance scenarios for family cars, Automatic Parking Assist (APA) scenarios (such as memory parking for self-owned parking spaces in garages, intelligent parking for designated parking spaces in parking lots, etc.), and Navigation Guided Pilot (NGP) scenarios in urban or highway areas. Furthermore, the preset application scenarios may also include, but are not limited to: autonomous driving scenarios in the logistics and transportation field for intelligent driving trucks or unmanned trucks requiring augmented reality navigation, autonomous driving scenarios in the agricultural machinery field for autonomous agricultural vehicles requiring augmented reality navigation, autonomous driving scenarios for drones requiring augmented reality navigation, and autonomous driving scenarios for intelligent robots (such as cleaning robots, service robots, delivery robots, etc.) requiring augmented reality navigation.

[0038] When the aforementioned preset application scenario is a scenario in a field other than the vehicle field, those skilled in the art should understand that the vehicle in the above network traffic detection method can be replaced with other objects (such as agricultural machinery, drones, robots, etc.). Based on this, this application embodiment takes the vehicle field as an example to illustrate the specific implementation of the above network traffic detection method.

[0039] Figure 1 This is a flowchart illustrating a network traffic detection method according to an embodiment of this application, such as... Figure 1 As shown, this method is applied to the kernel-mode driver, where the kernel-mode driver and the user-mode application run on the same operating system. The method includes the following steps:

[0040] Step S102: Receive process identification information from the user-mode application.

[0041] In the technical solution provided in step S102 of this application, the process identification information is used to identify the process corresponding to the service to be detected, and the service runs on the user-mode application end.

[0042] Optionally, a kernel-mode driver refers to a software module or program running within the kernel space of an operating system (e.g., Linux), capable of accessing or controlling hardware devices or providing advanced system services. In this embodiment, the kernel-mode driver is a kernel module used to capture and statistically analyze network traffic. Working closely with the network protocol stack, it can directly obtain process-level network traffic information from the kernel. The kernel-mode driver connects the user application (UserApp) and the kernel's network stack, receiving requests and parameters from the UserApp, performing specific traffic capture and statistical operations in kernel space, and finally feeding back the results to the user application. The kernel driver can be a kernel-mode driver program, which may include a kernel driver and a network protocol stack.

[0043] Optionally, a user-mode application refers to an application running in the user space of an operating system (e.g., Linux). That is, a user-mode application can be a Linux user-mode application. In this embodiment, a user-mode application refers to an application that needs to monitor or analyze the network traffic of a specific process, such as network monitoring software, security auditing tools, or software used in autonomous vehicles to monitor real-time network services. The user-mode application initiates requests (e.g., requests to detect network traffic) to the kernel-mode driver, provides the process identification information of the service to be detected, and receives the traffic detection results processed and returned by the kernel-mode driver for further data analysis, display, or decision-making.

[0044] It should be noted that the above user-mode application is only an example and is not specifically limited here. Any application that can be used to trigger the network traffic detection method of the embodiments of this application is within the protection scope of the embodiments of this application, and will not be listed here.

[0045] Optionally, the aforementioned process identification information (Process ID, or PID) can be a unique identifier assigned to each process by the operating system, used to distinguish and manage different processes. Process identification information is an important parameter passed from the user-mode application to the kernel-mode driver, used to explicitly indicate the process to which the traffic detection service (the service to be detected) belongs.

[0046] Optionally, the aforementioned services are logical units providing specific functions within a software system. In this embodiment, a service can be any software module in an autonomous vehicle, such as path planning, obstacle detection, or vehicle control. These services can interact with the network, for example, by receiving remote commands or sending sensor data. Services are the targets of traffic detection; the traffic statistics results from the kernel-mode driver are directly correlated with the network communication of a specific service, helping user-mode applications to more accurately understand and control the network behavior of the service.

[0047] It is worth noting that the services targeted in this application embodiment are mainly for vehicle application scenarios. However, if the network traffic detection method used in this application embodiment is applicable to other application scenarios, then the services in other application scenarios are also within the protection scope of this application embodiment. Examples will not be given here.

[0048] Optionally, a process is a dynamic execution of a program in an operating system that performs a specific task. It can be considered an independent execution unit with its own address space and system resources (such as file descriptors). In this embodiment, a process can refer to a program instance running on a user-mode application, which may be part of a vehicle's autonomous driving system, used to perform specific tasks or services. A process is the basic unit of network traffic detection. The kernel-mode driver locates a specific process using its PID, then monitors and statistically analyzes the process's network activity, thereby achieving accurate detection of service network communication.

[0049] In this embodiment, the kernel-mode driver can monitor in real time whether the user-mode application needs to detect network traffic; that is, it can monitor in real time whether the user-mode application sends process identification information. If process identification information is detected, it indicates that the user-mode application needs to detect the network traffic used by the corresponding process during network communication.

[0050] Optionally, the purpose of the process identification information received by the kernel-mode driver from the user-mode application is to indicate to the kernel-mode driver which specific process it needs to monitor. Since the user-mode application and the kernel-mode driver run in different spaces of the operating system (user space and kernel space), they cannot directly share data or perform operations on each other. Therefore, through system calls, such as input / output control (ioctl), the user-mode application can pass the PID to the kernel-mode driver, which then uses the PID to locate and obtain the network communication details of the corresponding process.

[0051] Optionally, in complex network environments, especially in the context of autonomous vehicles, each service or function can be implemented by different processes, and the network traffic of these processes changes in real time. Accurately identifying the process requiring network traffic detection and monitoring its network traffic in real time is crucial for ensuring operating system stability, reasonable allocation of network bandwidth, and timely detection of potential network security threats. User-space applications send requests to kernel-space drivers via system call interfaces (such as ioctl), carrying the process ID (PID) in the request.

[0052] The method for receiving process identification information from the user-mode application in step S102 of this embodiment will be further explained below.

[0053] As an optional implementation, step S102, receiving process identification information from the user-mode application terminal, includes: in response to a first control command from the control interface in the user-mode application terminal, receiving process identification information from the first control command.

[0054] In this embodiment, if a first control command from the control interface of the user-mode application is detected during the process of receiving process identification information from the user-mode application, the process identification information can be obtained from the first control command.

[0055] Optionally, the aforementioned control interface can refer to a mechanism for communication and control between the user-space application and the kernel-space driver, enabling user-space programs to request or control kernel resources in a specific manner. The design of the control interface often needs to comply with the operating system's interface specifications to ensure stable interaction with the kernel. In this embodiment, for the Linux system, ioctl can be used as the control interface. ioctl allows user-space applications to send control requests to the kernel via system calls and receive responses from the kernel. ioctl can be used to perform device-specific operations, such as configuring hardware parameters, starting or stopping device functions, and obtaining device status.

[0056] Optionally, the aforementioned first control instruction can be used to receive and transmit process identification information from the user-mode application to the kernel-mode driver. In this embodiment, the first control instruction can be IOCTL_SET_PID, whose main function is to receive a process identifier (PID) from the user-mode application and pass it to the kernel-mode driver. Through the IOCTL_SET_PID instruction, the kernel-mode driver can determine which process's network traffic needs to be monitored and statistically analyzed.

[0057] Alternatively, in a Linux environment, communication between user-mode applications and kernel-mode drivers typically requires system calls. System calls provide a mechanism that allows applications to request the kernel to perform specific operations or access kernel-managed resources. `ioctl` is an important system call in Linux for device control, allowing applications to interact with the kernel through device files and perform device-specific control operations.

[0058] Optionally, the kernel-mode driver can receive process identification information (PID) by responding to specific control commands sent by the user-mode application, thereby locating and monitoring the network traffic of a specified process. For example, UserApp sends IOCTL_SET_PID to the kernel-mode driver via the ioctl control interface. When the kernel-mode driver detects the IOCTL_SET_PID command, it begins parsing the parameters of the command. These parameters contain the process ID (PID) to be monitored, and the kernel-mode driver needs to accurately extract the PID from the aforementioned IOCTL_SET_PID.

[0059] For example, `IOCTL_SET_PID` is a custom ioctl command used to initialize the kernel-mode driver and specify the process to be monitored. In implementation, this instruction can be created using a macro definition like `_IOW('s', 1, int)`. That is, the first control instruction can be defined using `#define IOCTL_SET_PID_IOW('s', 1, int)`, where 's' is the ioctl character identifier, 1 is the number used to distinguish different ioctl commands, and `int` indicates that the command receives an integer parameter, i.e., the PID. In this embodiment, through ioctl, the application can send control instructions to the kernel-mode driver, thereby enabling the monitoring of network traffic for a specific process.

[0060] In this embodiment, a direct communication bridge between the user-mode application and the kernel-mode driver is constructed through the ioctl system call and a custom IOCTL_SET_PID control instruction. This mechanism allows the user-mode application to precisely specify the PID to be monitored, enabling the kernel-mode driver to directly locate the network activity of that process and perform more efficient and accurate traffic statistics. This method optimizes the data transfer and processing between user space and kernel space in related network monitoring methods, improving system response speed and monitoring accuracy. It is particularly suitable for scenarios requiring real-time network traffic monitoring, such as real-time monitoring of the traffic required for the service network behavior of autonomous vehicles.

[0061] Step S104: Using the file descriptor of the file associated with the process identification information, the file is identified as a socket file.

[0062] In the technical solution provided in step S104 of this application, a file descriptor (fd) can be used to identify files opened by a process. In the Linux system, a file descriptor is a non-negative integer that represents a reference to a file or device opened by a process. Each open file or socket is assigned a unique file descriptor. Standard input, standard output, and standard error output are pre-assigned file descriptors 0, 1, and 2 in the process, respectively. Each process has a file descriptor table (fdtable / fd table), which records the file descriptors of each open file. When a process opens a file or socket, the kernel assigns a file descriptor to the process and adds it to the process's file descriptor table. Through the process ID (PID), the kernel can access the process's file descriptor table and thus handle operations related to these file descriptors.

[0063] Optionally, in Linux systems, socket files are also a special type of file used for network communication or inter-process communication. Socket files are represented in the kernel similarly to ordinary files, but in user space they are typically treated as file descriptors. Socket files can be categorized into several types, including stream sockets (SOCK_STREAM, such as TCP), datagram sockets (SOCK_DGRAM, such as UDP), raw sockets (SOCK_RAW), and connection-pair sockets (SOCK_SEQPACKET). In kernel space, a file descriptor can be identified as pointing to a socket file by examining the f_op field in the file structure (struct file) object associated with each file descriptor. The file operations (file_operations, abbreviated as f_op) field is a pointer to a file operation method table (struct file_operations, abbreviated as socket_file_ops). For socket files, f_op can point to the file operation structure of socket_file_ops. Therefore, if a file descriptor's f_op points to socket_file_ops, then it can be determined that the file descriptor represents a socket file. These socket files can then be used to form a socket list.

[0064] In this embodiment, after receiving process identification information from the user-space application, the file can be identified as a socket file by using the file descriptor of the file associated with the process identification information.

[0065] Optionally, in a Linux environment, process identification information (PID) and its associated file descriptors can be used to precisely identify which files are socket files, enabling further monitoring and statistical analysis of network traffic for specific processes. In Linux systems, each open file or device has an associated file descriptor, which is a non-negative integer used to identify file resources accessible by a process. Socket files, as a key component for inter-process communication and network communication, also follow these rules. After a socket file is opened, a file descriptor can be allocated to it.

[0066] Optionally, the kernel-mode driver can locate the corresponding process structure (struct task_struct) based on the PID. This process structure is a core data structure in the Linux kernel representing process states. The files member of task_struct points to a file structure (struct files_struct), which manages the various open files of the process. The files_struct structure contains a file descriptor table pointer (fdtab) that points to a file handle table (struct fdtable). fdtable stores a list of struct file objects containing open files. Each struct file object represents an open file or device.

[0067] Optionally, the kernel iterates through the list of struct file objects in the fdtable, examining each file descriptor. This process involves traversing the elements of the array fdtable->fd to find the file associated with the specified process ID. For each struct file object, the kernel examines its f_op member variable, which is a pointer to struct file_operations. If f_op points to socket_file_ops, a structure specifically used for handling socket file operations, then the file descriptor represents a socket file.

[0068] In this embodiment, by traversing and examining file descriptors associated with process identifiers using process identification information, it is possible to identify and locate which files are socket files. This step is crucial for process-level network traffic monitoring because it allows the kernel to focus on the network communication status of specific processes, laying a solid foundation for subsequent traffic statistics and analysis. Through the internal structures and function calls used in the above method, efficient transfer and processing of information from user space to kernel space is achieved, ensuring the accuracy and efficiency of network traffic monitoring.

[0069] The following section further explains how, in step S104 of this embodiment, a method is used to identify a file as a socket file by utilizing the file identifier of the file associated with the process identification information.

[0070] As an optional implementation, step S104, identifying a file as a socket file using the file descriptor associated with the process identification information, includes: obtaining a list of file handles opened by the process corresponding to the process identification information, wherein the file handle list is used to store the mapping relationship between different file descriptors and different file objects; and identifying the file as a socket file based on the file objects corresponding to the file descriptors in the file handle list.

[0071] In this embodiment, during the process of identifying a file as a socket file using the file descriptor associated with the process identification information, a list of file handles opened by the process corresponding to the process identification information can be obtained. Based on the file objects corresponding to the file descriptors in the file handle list, the file is identified as a socket file. The file handle list (file handle fd list) can be used to store the mapping relationship between different file descriptors and different file objects. The file object can be a struct file object.

[0072] Optionally, in a Linux system, the process of identifying whether a file handle (fd) corresponds to a socket file involves accessing and parsing several key data structures in the kernel.

[0073] Optionally, based on process identification information, the kernel-mode driver can find the corresponding `struct task_struct`. From `struct task_struct`, the `files_struct` can be accessed through the `files` member. `struct files_struct` contains an `fdtab` pointer, which points to `struct fdtable`, the list of file descriptors used to maintain the mapping between file descriptors and `struct file` objects. The `fd` array in `struct fdtable` is traversed. For each file descriptor, its corresponding `struct file` object is checked to determine if the file descriptor points to a socket file. For each `struct file` object in the traversal, its `f_op` member is checked. `f_op` is a pointer to `struct file_operations`, defining a series of file operations, such as read, write, open, and close. For sockets, `f_op` will point to `socket_file_ops`, a predefined instance of `struct file_operations` that provides specific operation support for socket files.

[0074] Optionally, if `f_op` matches `socket_file_ops`, it confirms that the `struct file` object describes a socket file. In this case, the `struct socket` can be further obtained through the `private_data` member of the `struct file` object. This is a concrete instance of a socket, containing more socket information. From the `struct socket`, the socket structure (`struct sock`) can be further accessed. This is a key data structure in the network protocol stack, used to handle specific network connections and data transmissions.

[0075] Optionally, once the struct file object is identified as belonging to a socket file and the relevant struct sock is located, specific fields in the struct sock can be accessed according to the network protocol to be statistically analyzed, such as Transmission Control Protocol (TCP) or User Datagram Protocol (UDP), thereby enabling the monitoring and statistics of network traffic.

[0076] In this embodiment, the method described above embodies the core logic of process-level network traffic statistics in the Linux kernel. Starting with process identification information, it uses a series of complex but ordered data structures for association and traversal to ultimately locate and identify socket files, thereby accurately obtaining network traffic information related to a specific process. This method overcomes the limitations of user-space tools in terms of real-time performance and accuracy, providing more detailed and real-time network traffic monitoring capabilities.

[0077] The method for obtaining the list of file handles opened by the process corresponding to the process identifier information in this embodiment will be further described below.

[0078] As an optional implementation, obtaining the list of file handles opened by the process corresponding to the process identification information includes: using the process identification information to find the process's main data structure in the kernel, and determining a first type pointer from the main data structure, wherein the main data structure includes information for describing the process, including process identification information; accessing the file management data structure pointed to by the first type pointer, and determining a second type pointer from the file management data structure, wherein the file management data structure includes information for maintaining file descriptors; and reading the list of file handles pointed to by the second type pointer.

[0079] In this embodiment, during the process of obtaining the list of file handles opened by the process corresponding to the process identification information, the process identification information can be used to locate the process's main data structure in the kernel, and a first type pointer can be determined from the main data structure. The file management data structure pointed to by the first type pointer is accessed, and a second type pointer is determined from the file management data structure. The list of file handles pointed to by the second type pointer is read. The main data structure may include information describing the process, which may include process identification information and can be a `struct task_struct`. The first type pointer can be a `files` member. The file management data structure may include information for maintaining file descriptors and can be a `struct files_struct`. The second type pointer can be a `fdtab` member.

[0080] Optionally, this embodiment illustrates how, in the Linux kernel, process identification information (usually PID) is used to obtain a list of file handles opened by a process, especially for identifying and counting network socket traffic.

[0081] Optionally, when it's necessary to retrieve a process's file handle list based on its PID, the corresponding `struct task_struct` is located in the kernel. `struct task_struct` is a key data structure in the Linux kernel describing processes, containing process control information, status information, resource utilization information, etc. The search process can locate the specific task structure by traversing the kernel's process table. `struct task_struct` has a member `files`, which is a pointer to `struct files_struct`, a structure used to manage process file descriptors. The `files` pointer allows access to the process's file descriptor management area. `struct files_struct` contains an `fdtab` pointer, which points to `struct fdtable`. The `fdtable` structure contains a list of file descriptors for each open file in the process. This list acts as a bridge between file descriptors and `struct file` objects; through this list, each open file of the process can be located.

[0082] Optionally, the `fd` member of `struct fdtable` is actually an array, where each element is a pointer to a `struct file` object. The `struct file` object contains specific information about the file or device, such as file type, open mode, and file operation table. By traversing the `fd` array, each `struct file` object can be accessed, thus obtaining detailed information about all file handles opened by the process. While traversing `struct file` objects, the `f_op` member can be checked to identify whether the file is a socket type. If the `f_op` pointer points to `socket_file_ops`, it indicates that the file is a socket file. Furthermore, through the `private_data` member of `struct file`, a `struct socket` object can be obtained, and then a `struct sock` can be retrieved from the `struct socket` object, allowing for more detailed network connection information and data flow statistics.

[0083] In this embodiment, the method described above demonstrates the depth and complexity of process file handle management in the Linux kernel. It also illustrates how to accurately locate specific file types (such as socket files) within a multi-layered data structure, which is of significant technical importance for implementing process-level network traffic monitoring and statistics. This method ensures efficient and accurate collection of the required network traffic data at the kernel level, avoiding the real-time and performance limitations of user-space tools in related technologies.

[0084] The following description further explains the method for identifying a socket file based on the file object corresponding to the text descriptor in the text handle list in this embodiment.

[0085] As an optional implementation, identifying a file as a socket file based on the file object corresponding to the file descriptor in the file handle list includes: traversing each file descriptor in the file handle list; determining a target file object in the file handle list that has a mapping relationship with the traversed target file descriptor; and identifying the file corresponding to the target file descriptor as a socket file based on the target file object.

[0086] In this embodiment, during the process of identifying a file as a socket file based on the file object corresponding to the file descriptor in the file handle list, each file descriptor in the file handle list can be processed. Within the file handle list, target file objects with a mapping relationship to the traversed target file descriptor can be identified, and based on these target file objects, the file corresponding to the target file descriptor can be identified as a socket file.

[0087] Optionally, this embodiment illustrates how, in the Linux kernel, the list of file descriptors in the struct fdtable is traversed to identify and locate socket files. The fd array in the struct fdtable contains descriptors of files opened by a process, and each descriptor is a pointer to a struct file. The basic steps for traversing this array are: starting from the first element of the array, check each element one by one to see if it is valid (i.e., not NULL). If it is valid, the struct file object of that element represents an open file.

[0088] Optionally, when a valid file descriptor is encountered, a pointer to a `struct file` is obtained. `struct file` is a generic structure in the Linux kernel representing an open file, which can contain various file attributes and operation methods. Each file descriptor corresponds to a `struct file` object. After determining the `struct file` object mapped to the file descriptor, it can be further determined whether the file object represents a socket file. This determination is based on the `f_op` member in `struct file`, which is a pointer to `struct file_operations`. `struct file_operations` defines file operations such as reading, writing, opening, and closing.

[0089] In this embodiment, the above method enables efficient traversal and identification of socket files within the Linux kernel. Compared to related technologies that use user-space tools (such as libpcap or netfilter) to capture and analyze network packets, this kernel-level access provides higher accuracy and real-time performance. It avoids unnecessary switching between user space and kernel space, reducing system overhead, and is particularly suitable for scenarios requiring real-time statistics and monitoring of a large number of network connections. The implementation of this method greatly simplifies the process and improves the efficiency and accuracy of network traffic statistics, which is especially important when dealing with complex network environments and high-concurrency connections.

[0090] The following description further explains the method for identifying the text corresponding to the target file descriptor as a socket file based on the target file object in this embodiment.

[0091] As an optional implementation, identifying the file corresponding to the target file descriptor as a socket file based on the target file object includes: determining the target pointer type corresponding to the socket file to be identified, wherein the target pointer type is a predefined pointer type for the socket file to be identified; and identifying the file corresponding to the target file descriptor as a socket file in response to the pointer type of the target file object being the target pointer type.

[0092] In this embodiment, during the process of identifying the file corresponding to the target file descriptor as a socket file based on the target file object, the target pointer type corresponding to the socket file to be identified can be determined. If the pointer type of the target file object is a target pointer type, it can be concluded that the file corresponding to the identified target file descriptor is a socket file. The target pointer type can be a predefined pointer type of the socket file to be identified, for example, it can be `socket_file_ops`. The pointer type of the target file object can be `struct file`'s `f_op`.

[0093] Optionally, this embodiment illustrates how to identify whether a file corresponding to a descriptor is a socket file based on a struct file object.

[0094] Optionally, in the Linux kernel, each file type has its own predefined set of file operation methods, stored in the `struct file_operations` structure. For socket files, this predefined set of file operation methods is called `socket_file_ops`. `socket_file_ops` is a global variable containing common operation functions for all socket files, such as reading, writing, and accepting connections. Each `struct file` object has an `f_op` member, which is also a pointer to `struct file_operations`, defining the specific operation methods for that file. When traversing a file descriptor and obtaining its `struct file` object, the set of operation methods for that file can be determined by checking `f_op`.

[0095] Optionally, by comparing the `f_op` pointer of the `struct file` object with the global `socket_file_ops`, it can be determined whether the file is a socket file. If they match, it means that `f_op` points to a set of file operation methods specifically designed for sockets, thus confirming that the `struct file` object describes a socket file. When `f_op` matches `socket_file_ops`, it indicates that the `struct file` object corresponding to the traversed file descriptor is a socket file. This means that the descriptor can be used to access and manage network connections.

[0096] In this embodiment, the above process is crucial because it allows the kernel to quickly and accurately identify which file descriptors are part of a network connection in a high-concurrency environment, without requiring more time-consuming additional checks. By directly comparing the f_op member of the descriptor-related struct file with the predefined socket_file_ops, the kernel can quickly determine whether the descriptor is associated with a socket, thereby deciding whether further collection and processing of statistics about the connection is necessary. This method significantly improves the efficiency and accuracy of network traffic monitoring and statistics, especially in scenarios requiring real-time monitoring of a large number of network connections.

[0097] In summary, within the Linux kernel, by checking whether the `f_op` member of a `struct file` object is `socket_file_ops`, it's possible to directly identify whether a file handle corresponds to a network socket file. This allows for efficient location and statistics of network traffic, avoiding the limitations and inefficiencies of user-space packet capture tools. This approach fully utilizes the kernel's existing file management mechanisms, achieving fine-grained process traffic monitoring with minimal system overhead.

[0098] The following section further explains the method for traversing each file descriptor in the file handle list, determining the target file object that has a mapping relationship with the traversed target file descriptor, and identifying the file corresponding to the target file descriptor as a socket file based on the target file object.

[0099] As an optional implementation, the kernel-mode driver includes a kernel driver module and a protocol stack module. It iterates through each file descriptor in the file handle list, including: the kernel driver module iterates through each file descriptor in the file handle list; and / or, in the file handle list, it determines a target file object that has a mapping relationship with the traversed target file descriptor, including: the kernel driver module determines a target file object that has a mapping relationship with the target file descriptor in the file handle list; based on the target file object, it identifies the file corresponding to the target file descriptor as a socket file, including: the protocol stack module, based on the target file object, identifies the file corresponding to the target file descriptor as a socket file.

[0100] In this embodiment, the kernel-mode driver may include a kernel driver module (KernelDriver) and a protocol stack module (ProtocolStack). During the traversal of each file descriptor in the file handle list, the kernel driver module can traverse each file descriptor in the file handle list. In determining the target file object that has a mapping relationship with the target file descriptor, the kernel driver module can identify the target file object that corresponds to the target file descriptor as a socket file based on the target file object. This embodiment illustrates that the responsibilities of the kernel-mode driver are explicitly assigned to KernelDriver and ProtocolStack.

[0101] Optionally, the kernel driver module locates the `struct task_struct` using the PID, and then accesses the `struct files_struct` through the `files` member of `task_struct`. In `files_struct`, the `fdtab` pointer is obtained, pointing to the `struct fdtable` data structure, which stores a list of file descriptors. The kernel driver module is responsible for traversing the `fd` array in `struct fdtable`, checking the validity of each file descriptor one by one. If a descriptor is valid, it points to the corresponding `struct file` object.

[0102] Optionally, during the traversal, the kernel driver module determines the `struct file` object that maps to each traversed file descriptor. This is done by checking the `struct file` pointer pointed to by the file descriptor. Once the kernel driver module has determined the `struct file` object corresponding to a file descriptor, the protocol stack module is responsible for further identifying whether this file object describes a socket file. This identification process mainly involves checking the `f_op` member of `struct file`. If the `f_op` member points to `socket_file_ops`, then the file is confirmed to be a socket file. Once it is confirmed that the `struct file` object describes a socket file, the protocol stack module can further obtain information related to network connections and data transmission. This involves accessing `struct socket` and `struct sock` to obtain statistical information such as the amount of data sent and received. The protocol stack module is also responsible for handling traffic statistics related to specific protocols (such as TCP or UDP), including updating and reading traffic counters.

[0103] In this embodiment, through the above steps, the kernel driver module and the protocol stack module work together to accurately identify and statistically analyze the socket files opened by the process. The kernel driver module is mainly responsible for traversing the file handle list and locating the struct file object, while the protocol stack module focuses on determining the file type and processing data related to the network protocol stack. This division of labor helps improve the overall efficiency and stability of the kernel-mode driver, and also makes the traffic statistics more accurate and real-time. In summary, the interaction between the kernel driver module and the protocol stack module is crucial in the execution of the above method. They achieve in-depth analysis of file descriptors and network connections by sharing data structures and calling kernel functions. The above method not only makes full use of the internal structure and mechanisms of the kernel, but also avoids the performance bottlenecks and accuracy problems commonly encountered by user-mode tools (such as tcpdump or netstat) when handling high-concurrency network connections.

[0104] Step S106: According to the socket file, access the network stack data of the kernel where the kernel-mode driver is located to obtain the service traffic detection results.

[0105] In the technical solution provided in step S106 of this application, the traffic detection result is used to represent the network traffic used by the service during network communication using the process. The traffic detection result can also be called traffic data, statistical data, or statistical results, and can be a traffic statistics structure (structtraffic_stats for short).

[0106] Optionally, in the Linux kernel, the socket structure (struct sock) can be one of the core data structures in the network stack, used to describe network connections for all protocols above the network layer. struct sock is not limited to TCP or UDP, but encompasses the connection state and data flow of all transport layer protocols. struct sock provides a unified abstraction for various network connections (such as TCP and UDP connections), storing key data such as connection state, address information, buffer management, and error information. Fields in struct sock relate to flow control and congestion control strategies, which are crucial for understanding the efficiency and potential bottlenecks of traffic transmission. Specific fields within struct sock directly reflect the number of bytes sent and received for TCP connections, which is extremely important for traffic monitoring. Similarly, for UDP, there are similar statistical fields, such as the number of bytes in the send and receive queues.

[0107] Optionally, traffic detection results are calculated based on network stack data, particularly information in the `struct sock`, to reflect the traffic consumption of a service when using a specific process for network communication. Traffic detection results may include, but are not limited to, the following: number of bytes sent, representing the total amount of data sent from the local host through a specific connection; number of bytes received, representing the total amount of data arriving at the local host from the outside world through a specific connection; UDP send queue length, representing the amount of data waiting to be sent in the UDP socket send buffer; and UDP receive queue length, representing the amount of data received but not yet processed in the UDP socket receive buffer.

[0108] In this embodiment, after identifying the file as a socket file using the file descriptor associated with the process identification information, the network stack data of the kernel where the kernel-mode driver resides can be accessed according to the socket file to obtain the service traffic detection results. The core objective of this embodiment is to accurately and efficiently obtain the traffic detection results of a specific service in process-level network traffic monitoring. The above process delves into the Linux kernel's network stack, directly interacting with the data structures responsible for network communication to extract statistical information.

[0109] Optionally, once a specific socket file is identified, the kernel-mode driver further accesses the corresponding `struct sock` structure. The `struct sock` contains connection status, address information, buffer management, flow control data, and statistics. By directly reading the traffic statistics fields in the `struct sock` and its derived structures, the kernel driver module can accurately obtain the number of bytes sent and received by the service when using a specific socket for network communication. For TCP sockets, the traffic detection results can include the number of bytes sent and received; while for UDP sockets, the results will include the number of bytes in the send queue and the number of bytes in the receive queue. These statistics directly reflect the service's activity at the network layer, providing real-time, fine-grained traffic monitoring capabilities.

[0110] In this embodiment, operations are performed directly at the kernel level, avoiding the efficiency bottlenecks of user-space monitoring tools in related technologies, such as unnecessary context switching and data copying, thus improving the real-time performance of monitoring and the efficiency of data acquisition. It enables traffic statistics for each socket, providing process-level network traffic monitoring, which is difficult to achieve with traditional tools. In summary, by directly accessing and manipulating the kernel network stack, real-time, fine-grained, and secure monitoring of service network traffic is achieved, which is key to achieving efficient and accurate network traffic statistics.

[0111] The following section further explains how, in step S106 of this embodiment, the network stack data of the kernel where the kernel-mode driver resides is accessed according to the socket file to obtain the service traffic detection result.

[0112] As an optional implementation, step S106, accessing the network stack data of the kernel where the kernel-mode driver resides according to the socket file to obtain the service traffic detection result, includes: accessing the kernel's network stack data according to the socket file to obtain the socket structure corresponding to the socket file; using the socket structure to obtain the network traffic value and / or network status information used by the service during network communication using the process, wherein the network status information is used to indicate whether the network status corresponding to the network traffic is a normal network status or an abnormal network status; and determining the traffic value and / or network status information as the traffic detection result.

[0113] In this embodiment, during the process of accessing the network stack data of the kernel where the kernel-mode driver resides according to the socket file to obtain the traffic detection result, the kernel's network stack data can be accessed according to the socket file to obtain the socket structure corresponding to the socket file. The socket structure can be used to obtain the network traffic value and / or network status information used by the service during network communication using the process. The traffic value and / or network status information are then determined as the traffic detection result. The network status information can be used to indicate whether the network status corresponding to the network traffic is a normal network status or an abnormal network status. The socket structure can be a struct sock.

[0114] Optionally, this embodiment aims to obtain traffic values ​​and network status information corresponding to a specific socket file by directly accessing the network stack data in kernel mode, thereby achieving accurate monitoring of service traffic.

[0115] Optionally, the kernel-mode driver can locate the correct `struct sock` based on the socket file. This process involves obtaining the `struct socket` from the `private_data` field of the `struct file` object, and then finding the `struct sock` through the relevant member pointers in the `struct socket`. `struct file` is the kernel-space representation of a user-space file descriptor, and its `private_data` field points to private data related to the specific file type. For network sockets, this private data is the `struct socket`.

[0116] Optionally, the `struct sock` is the fundamental structure in the Linux kernel for managing all types of network connections, including TCP and UDP. Through this structure, kernel drivers can directly access connection statistics, such as the number of bytes sent and received, and related network status. For TCP connections, traffic information can be obtained from the `struct tcp_sock` substructure of `struct sock`, such as the `tcp_snd` and `tcp_rcv` fields. For UDP connections, the lengths of the send and receive queues provide information about the traffic sent and received. Obtaining network status information involves monitoring the status fields in `struct sock`, which reflect whether the connection is functioning correctly or whether any abnormal conditions, such as timeouts or errors, have occurred.

[0117] Optionally, once the kernel driver successfully obtains the required traffic values ​​and / or network status information from the `struct sock`, this information can be considered the result of traffic detection. Traffic values ​​directly reflect the amount of data exchanged by the service in network communication, while network status information provides an additional perspective for understanding the health of the data flow. The combination of this information forms a complete traffic detection report, including normal and potentially abnormal communication states. Packaging this information into the `struct traffic_stats` format facilitates understanding and processing by user-space applications, thereby enabling effective monitoring of service network traffic.

[0118] In this embodiment, efficient and accurate monitoring of service traffic is achieved by directly accessing kernel network stack data. This process involves locating traffic layer by layer from user-space file descriptors to the kernel-space `struct sock`, and secure access to traffic statistics fields within the `struct sock`. By integrating the acquired information into the `struct traffic_stats` format, real-time traffic reports are provided, including traffic values ​​and network status information, thereby significantly enhancing the monitoring and fault diagnosis capabilities for service network behavior. Compared to user-space monitoring methods in related technologies, this approach offers higher efficiency and lower system overhead, representing a key step in achieving fine-grained network traffic management.

[0119] The following description further explains the method described above for accessing the network stack data of the kernel where the kernel-mode driver resides according to the socket file, obtaining the socket structure corresponding to the socket file, and how to obtain the traffic value and / or network status information of the service during network communication using the process.

[0120] As an optional implementation, the kernel-mode driver includes a kernel driver module and a protocol stack module. It accesses the kernel's network stack data according to the socket file to obtain the socket structure corresponding to the socket file. This includes: the kernel driver module accessing the kernel's network stack data according to the socket file to determine the socket structure in the protocol stack module. Using the socket structure, it obtains the network traffic value and / or network status information used by the service during network communication using the process. This includes: the protocol stack module using the socket structure to obtain the network traffic value and / or network status information.

[0121] In this embodiment, during the process of accessing the kernel's network stack data according to the socket file to obtain the socket structure, the kernel driver module can access the kernel's network stack data according to the socket file to determine the socket structure in the protocol stack module. During the process of obtaining the traffic value and / or network status information corresponding to the service, the protocol stack module can utilize the socket structure to obtain the network traffic value and / or network status information.

[0122] Optionally, the kernel driver module can accurately locate the `struct socket` associated with the socket file (i.e., the file descriptor used by the user-space application) by traversing and parsing kernel data structures, and then delve into the `struct sock` through `struct socket`. `struct socket` and `struct sock` serve as a bridge connecting kernel network stack data and specific network connection states. The kernel driver module's task is to parse these structures to ensure correct access to the target socket's data, including but not limited to TCP or UDP traffic statistics.

[0123] Optionally, once the kernel driver module identifies the target `struct sock`, the protocol stack module takes over and begins reading network traffic and status information associated with that structure. The protocol stack module here essentially refers to the part of the kernel that handles protocols such as TCP and UDP. For TCP connections, the protocol stack module reads the number of bytes sent and received from the `struct tcp_sock` substructure of `struct sock`. For UDP connections, it reads information such as the lengths of the send and receive queues to estimate the traffic value. In addition to the traffic value, the protocol stack module can also check the status fields in `struct sock`, such as connection status, retransmission counter, and error count, to determine whether the current state of the network connection is normal.

[0124] Optionally, after obtaining traffic values ​​and / or network status information, this information can be integrated into `struct traffic_stats` or other suitable data structures to form the final traffic detection result. After the kernel driver module encapsulates this integrated information, it returns it to the user-space application via a system call, enabling the application to monitor the service network traffic and network health in real time.

[0125] In this embodiment, the collaboration between the kernel driver module and the protocol stack module enables accurate monitoring of network traffic. Particularly in high-concurrency network environments, socket traffic values ​​and network status information are obtained by directly accessing the kernel's network stack data. This design not only improves the speed and accuracy of data acquisition but also ensures data security and system stability in complex environments.

[0126] The following description further illustrates the method for obtaining traffic values ​​and / or network status information of a service during network communication using a socket structure in this embodiment.

[0127] As an optional implementation, the socket structure is used to obtain the network traffic value and / or network status information used by the service during network communication using the process, including: determining the network protocol type used by the service during network communication using the process, wherein the network protocol type includes Transmission Control Protocol type and / or User Datagram Protocol type; and using the socket structure to obtain the network traffic value and / or network status information corresponding to the network protocol type.

[0128] In this embodiment, during the process of obtaining the traffic value and / or network status information corresponding to the service using the socket structure, the network protocol type used by the service during network communication using the process can be determined. The socket structure can be used to obtain the traffic value and / or network status information corresponding to the network protocol type. The network protocol type may include TCP and / or UDP.

[0129] Optionally, this embodiment illustrates how to use a socket structure (struct sock) to obtain network traffic information (traffic values) and network status information used by a service in process-level network communication. When accessing and processing the struct sock, it can be determined which network protocol, such as TCP or UDP, is being used for the connection being processed. These steps are crucial because different protocols have different data structures and statistical fields. The protocol type can be determined by examining the specific protocol type field in the struct sock, or by further examining its derived structure.

[0130] Optionally, once the network protocol type is determined, the kernel-mode driver can access data statistics fields related to that protocol type. For TCP, this may include the number of bytes sent and received from the `struct tcp_sock`; for UDP, it may involve the lengths of the send and receive queues. Besides traffic values, network status information is also a key monitoring metric. This information reflects the current status of the connection, such as whether the connection has been established, whether it is in normal working order, and whether there are retransmissions or errors. For TCP, the connection status can be read from the `sk_state` field of the `struct sock`; while for UDP, although the status information is relatively simple, some basic error count fields can still be obtained.

[0131] The goal of this application is to improve the granularity of traffic statistics, moving from the port / Internet Protocol level to the process level. This means that for a specific process, it is possible to accurately obtain the number of bytes sent and received when the process communicates using TCP or UDP, as well as the related network status. Based on the `struct sock`, for TCP, the traffic statistics fields in `struct tcp_sock` are accessed; for UDP, fields such as queue length in `struct udp_sock` are accessed accordingly. This data will be used to construct `struct traffic_stats`. By directly accessing kernel data structures, real-time traffic statistics can be provided, reflecting the network communication status of services in a timely manner.

[0132] In summary, the kernel-mode driver, by carefully parsing the `struct sock`, determines the network protocol type used by the service and can access the associated traffic values ​​and network status information. This process significantly improves the granularity and real-time performance of network traffic statistics, particularly at the process level, filling gaps in existing tools and methods and providing more accurate data support for network management, fault diagnosis, and performance optimization. Furthermore, by implementing kernel-provided security mechanisms, the accuracy of the data and the stability of the system are ensured, even in environments with high network concurrency.

[0133] The following description further explains the method for obtaining traffic detection results by detecting the network traffic used by the service during network communication using the process according to the socket file in this embodiment.

[0134] As an optional implementation, according to the socket file, the detection service detects the network traffic used during network communication by the process and obtains the traffic detection results, including: locking the socket file; and according to the locked socket file, detecting the network traffic used by the service during network communication by the process and obtaining the traffic detection results.

[0135] In this embodiment, during the process of determining the traffic detection results according to the socket file, a locking operation can be performed on the socket file. The traffic detection results corresponding to the detection service are then determined according to the locked socket file. This embodiment focuses on how to ensure data accuracy and system stability through a locking mechanism when the detection service uses network traffic. In a high-concurrency network environment, multiple processes or threads may attempt to access the same network connection simultaneously, i.e., perform read and write operations through the same socket file. In such cases, without proper concurrency control, data inconsistency or loss may occur, thus affecting the accuracy of traffic detection. Therefore, locking the socket file is essential.

[0136] Optionally, the `sock_hold()` and `lock_sock()` functions can be used to lock socket files. `sock_hold()` increments the reference count of the `struct sock`. When a process attempts to access a network connection, the kernel driver can call `sock_hold()` to hold the connection, preventing other processes from releasing or modifying the structure during this time, thus ensuring data integrity and consistency. `lock_sock()` locks the `struct sock` before data access, providing an exclusive access environment and ensuring that no other concurrent operations affect the correctness of the data when reading or updating traffic statistics fields. `lock_sock()` and `unlock_sock()` are a pair of complementary functions used to lock the `struct sock` during access and unlock it after access.

[0137] Alternatively, in the Linux kernel, in addition to the locking mechanisms mentioned above, a "Read-Copy-Update" (RCU) mechanism can be used to update data structures without completely stopping the system. For struct sock data that needs to be read, RCU can avoid locking to some extent and reduce the impact on system performance, but when data needs to be modified, locking methods such as lock_sock() are still required.

[0138] Optionally, after the `struct sock` is locked and held, the kernel driver module can safely access data statistics fields associated with that socket, such as the number of bytes sent and received, or more specifically, the lengths of the TCP send and receive queues. Depending on the specific network protocol used by the process being monitored, the kernel driver reads traffic statistics from the corresponding substructure of the `struct sock`. For TCP, this might involve reading the `tcp_snd` and `tcp_rcv` fields in `struct tcp_sock`; for UDP, it might focus on the send and receive queue lengths of `struct udp_sock`. Besides traffic values, obtaining connection status information (such as whether a connection has been established, whether data transmission is in progress, whether errors have occurred, etc.) is also an important part of traffic detection. This typically involves reading the `sk_state` field in `struct sock`.

[0139] Optionally, after traffic detection is complete and the required traffic values ​​and network status information are obtained, the kernel driver module needs to properly release the locks and reference counts to allow other processes to access the struct sock. This process includes calling `release_sock()` to unlock the struct sock and calling `sock_put()` to decrement its reference count.

[0140] In this embodiment, through the aforementioned locking operation, the kernel-mode driver ensures that access to the `struct sock` is safe in a high-concurrency network environment, preventing data races or inconsistencies. This provides a solid foundation for fine-grained network traffic detection, especially when services utilize processes for network communication, enabling accurate and real-time acquisition of traffic usage and network status information, significantly improving the efficiency and accuracy of network monitoring. Furthermore, the combination of this locking mechanism and the RCU mechanism effectively balances the requirements for data accuracy and system performance.

[0141] The following description further explains the process after obtaining the traffic detection results through the above steps in this embodiment.

[0142] As an optional implementation, after detecting the network traffic used by the service during network communication using the process according to the socket file and obtaining the traffic detection results, the locked socket file is unlocked.

[0143] In this embodiment, after determining the traffic detection result according to the socket file, the locked socket file can also be unlocked.

[0144] Optionally, after completing network traffic detection, to maintain system stability and effective resource management, the kernel-mode driver can perform an unlock operation to release the previous lock on the struct sock. In the Linux kernel, locking any resource should follow good locking practices, meaning that it must be unlocked promptly after locking. This is because locking prevents other processes or threads from accessing the resource, causing temporary exclusive access. In high-concurrency network environments, if the struct sock is locked for a long time, it may delay other requests that depend on that socket, or even cause a degrade in system performance; therefore, the unlock operation is crucial. The release_sock() function can be used to unlock the socket file. The release_sock() function releases the exclusive lock previously imposed by lock_sock(), allowing other processes or threads to access the struct sock. The above steps ensure the availability of the data structure and avoid bottlenecks caused by locking.

[0145] Optionally, while unlocking, the kernel-mode driver can also call the `sock_put()` function to decrement the reference count of the `struct sock`. This is the corresponding operation to `sock_hold()`, used to release the previously increased count. Only when the count drops to zero can the `struct sock` object be reclaimed by the kernel, ensuring the reasonable use of resources and preventing memory leaks.

[0146] Optionally, in certain situations, especially where read operations far outnumber write operations, a Restricted Core (RCU) mechanism may also be involved. RCU allows read operations to proceed without blocking, but all possible read operations must complete before a major update can be performed. Therefore, if the kernel driver uses RCU, it may be necessary to call the corresponding RCU callback or synchronization primitive before unlocking to ensure all read operations have completed. Unlocking involves atomic operations to ensure consistency and safety in a multi-threaded environment. For example, decrementing the reference count and unlocking operations may require atomic functions or mutexes to avoid concurrency errors during decrementing and unlocking.

[0147] In this embodiment, the unlocking operation is a necessary step for the Linux kernel-mode driver after completing network traffic detection, ensuring the availability of the struct sock object and its safety in a multi-threaded environment. By using the release_sock() and sock_put() functions, the kernel-mode driver not only releases the previously applied exclusive lock but also properly manages the object's reference count, avoiding resource waste and potential system instability. These operations follow good programming practices in the Linux kernel and are a key component of the design of a high-performance, high-concurrency network traffic monitoring system.

[0148] Step S108: Send the traffic detection results to the user-space application for display.

[0149] In the technical solution provided in step S108 of this application, after determining the traffic detection result corresponding to the service according to the socket file, the traffic detection result can be sent from the kernel-mode driver to the user-mode application for display.

[0150] Optionally, the Linux system provides a bridge through system calls (such as ioctl) to enable efficient data exchange between kernel mode and user mode. In this embodiment, a specific ioctl command, such as IOCTL_GET_STATS, is defined to handle the acquisition and transmission of traffic detection results. The definition of the ioctl command includes the data type and direction. In IOCTL_GET_STATS, the data type is set to struct traffic_stats, which is a data structure containing protocol type and related traffic data.

[0151] The following section further explains how the traffic detection results are sent to the user-mode application for display in step S108 of this embodiment.

[0152] As an optional implementation, step S108, sending the traffic detection result to the user-space application for display, includes: the protocol stack module sending the traffic detection result to the user-space application for display via the kernel driver module.

[0153] In this embodiment, during the process of sending the traffic detection results to the user-space application for display, the traffic detection results can be sent to the user-space application for display via the kernel driver module through the protocol stack module.

[0154] Optionally, the user-space application specifies the process ID to be monitored via an ioctl command (such as IOCTL_SET_PID) to prepare for receiving traffic data. After receiving the request, the kernel driver calls the protocol stack module's interface to obtain the traffic information of the specific process. The kernel driver module formats the traffic information obtained from the protocol stack module into a struct traffic_stats or similar data structure. The kernel driver module then sends the formatted traffic detection results from kernel space to the user-space application using the copy_to_user() function. Upon receiving the traffic detection results, the user-space application parses them and displays them on the user interface.

[0155] In this embodiment, the process of securely and efficiently sending traffic results detected by the network protocol stack module to the user-space application is mediated by a kernel driver module. The above implementation fully utilizes Linux kernel mechanisms, such as ioctl and copy_to_user(), to ensure fast and reliable data transmission while maintaining data security.

[0156] The following section further explains how the traffic detection results are sent to the user-mode application for display in step S108 of this embodiment.

[0157] As an optional implementation, step S108, sending the traffic detection result to the user-space application terminal for display, includes: in response to a second control command from the control interface, sending the traffic detection result corresponding to the network protocol type in the second control command to the user-space application terminal for display.

[0158] In this embodiment, during the process of sending the traffic detection results to the user-space application for display, if a second control command from the control interface is detected, the traffic detection results corresponding to the network protocol type in the second control command can be sent to the user-space application for display. The second control command can be `IOCTL_GET_STATS_IOR('s', 2, struct traffic_stats)`, where the type identifier is `s` and the value identifier is `2`. The parameter of this ioctl command is a pointer to a structure of type `struct traffic_stats`, used to carry the returned traffic detection results.

[0159] Optionally, the kernel-mode driver and user-mode application interact through specific system calls (ioctl) to display real-time or on-demand network traffic detection results. The kernel-mode driver returns the traffic detection results corresponding to the network protocol type specified in the instruction to the user-mode application for further processing and visualization. The user-mode application requests traffic statistics for a specific network protocol (such as TCP or UDP) from the kernel-mode driver via IOCTL_GET_STATS. Upon receiving this request, the kernel parses and executes the traffic statistics logic, ultimately returning the results to user-mode. For example, when IOCTL_GET_STATS is called, the kernel-mode driver can perform the following operations: read the protocol type from the user-mode provided struct traffic_stats; traverse relevant data structures (such as structsock) according to the specified protocol type to obtain the number of bytes sent and received; and populate the obtained traffic data into struct traffic_stats to ensure that the information returned to user-mode contains complete traffic statistics results.

[0160] Optionally, the user-space application initiates an IOCTL_GET_STATS request via the ioctl system call, providing a buffer of type struct traffic_stats to receive the returned detection results. After the kernel-space driver completes traffic statistics, it uses the copy_to_user() function to copy the contents of struct traffic_stats from kernel space to the user-provided buffer. After successful data transmission, the kernel-space driver completes the ioctl system call by returning an error-free code, notifying the user-space application that data reception was successful.

[0161] In this embodiment, the ioctl mechanism enables direct and efficient communication between kernel mode and user mode, avoiding intermediate data copying or conversion and improving overall system performance. When using copy_to_user() for data transfer, the kernel checks the validity of the buffer address provided by the user to prevent potential memory access errors and ensure system stability.

[0162] The technical solutions of the embodiments of this application will be illustrated below with reference to preferred embodiments.

[0163] This application proposes a process-level network traffic statistics method for a Linux environment. By implementing a driver at the kernel level, it directly accesses and monitors network protocol stack data, solving core problems of traditional network traffic monitoring tools such as insufficient real-time performance, weak correlation between network connections and specific processes, and coarse statistical granularity. Specifically, the driver interacts directly with the kernel, and the user layer develops a specific ioctl() interface that can receive the process ID passed from the application. It then delves into the kernel to traverse the process's file descriptor list, accurately locating each socket object. Based on the specified protocol type, it performs fine-grained statistics on the number of bytes sent and received for TCP and the number of bytes sent and received for UDP. Furthermore, by utilizing kernel kref reference counting and RCU locking mechanisms, it ensures the security and reliability of data statistics in high-concurrency environments, improving the real-time performance, accuracy, and statistical granularity of network traffic monitoring, and meeting the high requirements for traffic statistics in complex network environments. This achieves the technical effect of improving network traffic detection efficiency and solves the technical problem of network traffic detection efficiency.

[0164] Figure 2 This is a flowchart illustrating a process-level network traffic statistics method in a Linux environment according to an embodiment of this application, such as... Figure 2 As shown, it may include a user application 21, a kernel driver module 22, and a network protocol stack module 23. The method may include the following steps:

[0165] Step S201: Process identification information is passed via IOCTL_SET_PID. In this embodiment, the user application 21 and the kernel driver module 22 can interact via IOCTL_SET_PID (PID = 1234). The user application 21 passes a specific process ID (e.g., PID = 1234) to the kernel driver via the ioctl system call. This operation allows the kernel driver to identify and lock the network activity of a specific process, preparing for the collection of traffic data.

[0166] Step S202: Using process identification information, the file descriptor table of the process is traversed. In this embodiment, the kernel driver module 22 traverses the file descriptor table of a specified process in the Linux kernel to find the network socket associated with that process. By accessing the struct task_struct data structure, the files pointer can be obtained, and then the fdtab member in struct files_struct can be accessed. The fdtab member contains all open file handles, including socket objects.

[0167] Step S203: Return the socket list. In this embodiment, after the driver traverses the process file descriptor (fd) table, it organizes all identified socket objects into a list; that is, the network protocol stack 23 returns the socket list to the kernel driver module 22. This list will be used for precise matching in subsequent traffic statistics to ensure the accuracy of data statistics.

[0168] Step S204: Register a statistics callback. In this embodiment, in order to capture traffic information in real time during network data transmission, the kernel driver needs to register a statistics callback function internally. This callback function is triggered whenever a data packet is processed in the network protocol stack, reading and updating the relevant traffic statistics fields.

[0169] Step S205: Return traffic data. In this embodiment, the network protocol stack 23 can return the detected traffic data to the kernel driver module 22.

[0170] Step S206: Return traffic data via IOCTL_GET_STATS. In this embodiment, the kernel driver module 22 returns the collected traffic data to the user application 21 via the IOCTL_GET_STATS call response.

[0171] In this embodiment, key data structures for traffic statistics can be defined. Through the `protocol_type` enumeration and the `traffic_stats` structure, precise classification of traffic information for different network protocols can be achieved, ensuring fine-grained and real-time statistical results. `protocol_type` (enumeration type) identifies the type of network protocol. By defining the `PROTOCOL_TCP` and `PROTOCOL_UDP` enumeration values, TCP and UDP protocols can be distinguished, providing a foundation for traffic statistics querying and processing. In this embodiment, the ioctl command macros `#define IOCTL_SET_PID_IOW('s',1,int)` and `#define IOCTL_GET_STATS_IOR('s',2,struct traffic_stats)` define the specific format and function of the ioctl command. In `#define IOCTL_SET_PID_IOW('s',1,int)`, `_IOW('s',1,int)` indicates that this is an ioctl command with a write operation. 's' is a character identifier, typically used to represent a specific device driver type; in this case, it's a socket-related driver. 1 is the ordinal number or enumeration value of the ioctl command, used to distinguish different ioctl commands. In this example, 1 indicates a command to set the PID. `int` is the data type passed from the application to the driver; that is, through this ioctl command, the application will write an integer to kernel space. In `#define IOCTL_GET_STATS_IOR('s',2,struct traffic_stats)`, `_IOR('s',2,struct traffic_stats)` indicates that this is a read-only ioctl command used to retrieve data from the kernel. 2 is also an enumeration value of the ioctl command, used to identify different ioctl commands, here indicating the retrieval of traffic statistics. `struct traffic_stats` is the data type the application expects to receive from the driver, i.e., a set of network traffic statistics, including but not limited to the number of bytes sent and received.

[0172] In this embodiment, the driver framework implements a character device traffic_status, where struct file_operations implements the basic open and ioctl methods. In the ioctl method, the user-input pid is accepted as input through IOCTL_SET_PID, and the user-specified protocol type is accepted through IOCTL_GET_STATS. The result is then filled into struct traffic_stats and returned to the application. Finding the list of file handles opened by a process based on its process ID (PID) (This step describes how to find and retrieve the list of file handles opened by a given process ID (PID) in the Linux kernel. For example, the process of finding the list of file handles based on the PID is as follows: Locate the `struct task_struct`, using the PID to find the corresponding `struct task_struct` from the kernel's process table; Access `files_struct`, entering `struct files_struct` through the `files` member of `task_struct`; Read `fdtable`, obtaining the `fdtab` pointer to `struct fdtable` from `files_struct`, this data structure contains a list of descriptors for all open files; Traverse the file descriptors, iterating through the `fd` array in `fdtable`, checking if each descriptor is valid, and if valid, further checking if it is a network socket; Identify the socket, for the `struct file` object pointed to by the file descriptor, check its type to determine if it points to a network socket, if so, retain the descriptor information for subsequent traffic statistics.)

[0173] Figure 3 This is a flowchart illustrating a method for finding a file handle list based on process identifier information, according to an embodiment of this application. Figure 3 As shown, the method may include the following steps:

[0174] Step S301: Based on the process identification information, perform process management (struct task_struct). In this embodiment, the Linux kernel finds the corresponding struct task_struct based on the process ID. task_struct is a core data structure in the kernel that describes process status and information. Each time a new process is started, the kernel creates a task_struct instance in the process table and stores detailed process information (such as PID, status, memory management information, file descriptors, etc.) in it. When an application passes the PID to the kernel via an ioctl call, the kernel first uses this PID to search for the corresponding task_struct instance in the global process table.

[0175] Step S302: Execute file management (struct files_struct). In this embodiment, once struct task_struct is located, the next step is to access the file management information associated with the process. This step involves entering the files_struct structure through the files pointer in task_struct. files_struct manages all open file descriptors of a process, including network sockets. The kernel will enter the process's struct files_struct through the files field of the struct task_struct instance. files_struct contains a pointer to struct fdtable, which is the actual array of file descriptors that stores pointers to struct files.

[0176] Step S303: Traverse the file descriptor list (struct fdtable). In this embodiment, with the fdtab pointer in structfiles_struct, the kernel can traverse the file descriptor list in struct fdtable, checking the status and type of each file descriptor to determine if it is a network socket. The kernel traverses the fd array in struct fdtable, where each element is a pointer to a struct file. It checks whether each file descriptor is valid (i.e., whether it is open). For valid file descriptors, the kernel further checks their type to determine if it is a network socket.

[0177] Step S304: Determine the final file structure object. In this embodiment, once a struct file related to a network socket is found during the traversal, the critical localization stage begins. The goal of this step is to ultimately identify and lock the specific struct file instance of the network socket for subsequent traffic statistics and information extraction. For each struct file that may be a network socket, the kernel checks its private_data field, which typically points to a struct socket, and further to a struct sock. If the struct file is indeed an instance of a network socket, the kernel locks the relevant struct sock to prevent concurrent modification, and then accesses the required traffic statistics fields through the struct sock. Finally, the kernel can encapsulate the collected traffic statistics information into a struct traffic_stats and return it to the user-space application via an ioctl call.

[0178] In this embodiment, within the Linux kernel, the `f_op` member of `struct file` is a pointer to `struct file_operations`, representing the file's operation table. For different file types (such as regular files, directories, device files, sockets, etc.), `f_op` points to different operation tables. The operation table is determined by comparing the `f_op` pointer with `socket_file_ops`, since the socket file's operation table is global (`socket_file_ops`).

[0179] In this embodiment, after obtaining the `struct file` object of the socket, the file can be checked to see if it is a socket by parsing key fields based on the protocol type. Specifically, in the Linux kernel, file descriptors (including network sockets) exist in the form of `struct file`. `struct file` has a member `f_op`, which is a pointer to `struct file_operations`. This structure defines various operations and behaviors of the file. `socket_file_ops` is a predefined instance of `struct file_operations` specifically designed for handling network sockets. Therefore, by comparing `file->f_op` and `socket_file_ops`, it can be determined whether `struct file` points to a network socket.

[0180] Optionally, the socket structure can also be obtained. Once it's confirmed that the `struct file` object describes a network socket, a pointer to a `struct socket` can be obtained through the `file->private_data` member. The `struct socket`, in turn, contains a pointer to a `struct sock`. The socket is locked, and the reference count of the `struct sock` is incremented using the `sock_hold()` function to prevent it from being accidentally released during this period. Exclusive access to the `struct sock` is ensured by `lock_sock()` until subsequent calls to `release_sock()` and `sock_put()` unlock it. Once the locked `struct sock` is acquired, specific traffic information can be collected based on the protocol type. For TCP, the focus is on the number of bytes sent and received; for UDP, the focus is on the number of bytes in the send and receive queues. Accurate statistics on TCP and UDP traffic are achieved by directly accessing specific fields of these derived structures. Finally, the socket is unlocked. After completing the above process, traffic data can be returned to the user application.

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

[0182] According to another aspect of the embodiments of this application, corresponding to the embodiments of the network traffic detection method described above, this specification also provides a network traffic detection system. Figure 4 This is a schematic diagram of a network traffic detection system according to an embodiment of this application, such as... Figure 4 As shown, the network traffic detection system 400 may include a user-space application terminal 402 and a kernel-space driver terminal 404. The user-space application terminal 402 is used to send process identification information to the kernel-space driver terminal. The kernel-space driver terminal 404 is used to identify a file as a socket file using the file descriptor associated with the process identification information; according to the socket file, it accesses the network stack data of the kernel where the kernel-space driver terminal resides to obtain the service traffic detection result; and sends the traffic detection result to the user-space application terminal; wherein, the user-space application terminal is used to display the traffic detection result.

[0183] According to another aspect of the embodiments of this application, corresponding to the embodiments of the network traffic detection method described above, this specification also provides a network traffic detection device. Figure 5 This is a structural block diagram of a network traffic detection device according to an embodiment of this application, such as... Figure 5 As shown, the network traffic detection device 500 may include: a receiving unit 502, an identification unit 504, an access unit 506, and a sending unit 508. The receiving unit 502 is used to receive process identification information from a user-mode application. The identification unit 504 is used to identify a file as a socket file using the file descriptor associated with the process identification information. The access unit 506 is used to access the network stack data of the kernel where the kernel-mode driver resides, according to the socket file, to obtain the service traffic detection result. The sending unit 508 is used to send the traffic detection result to the user-mode application for display.

[0184] Figure 6 This is a structural block diagram of an autonomous vehicle according to an embodiment of this application, such as... Figure 6 As shown, the components of the autonomous vehicle 600 include, but are not limited to, a memory 610 and a processor 620. The processor 620 and the memory 610 are connected via a bus 630, and the database 660 is used to store data.

[0185] The autonomous vehicle 600 may also include an access device 640, which enables the autonomous vehicle 600 to communicate via one or more networks 650. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 640 may include one or more of any type of wired or wireless network interface (e.g., a network interface controller, NIC), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0186] In one embodiment of this disclosure, the aforementioned components of the autonomous vehicle 600 and Figure 6 Other components not shown can also be connected to each other, for example, via a bus. It should be understood that... Figure 6 The illustrated block diagram of an autonomous vehicle is for illustrative purposes only and is not intended to limit the scope of this disclosure. Those skilled in the art can add or replace other components as needed.

[0187] Embodiments of this application also provide a computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0188] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0189] Embodiments of this application also provide a computer program product, including a non-volatile computer-readable storage medium for storing a computer program that, when executed by a processor, implements the methods in various embodiments of this application.

[0190] Embodiments of this application also provide a computer program that, when executed by a processor, implements the methods described in the various embodiments of this application.

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

[0192] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0193] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units.

[0194] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk. The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for detecting network traffic, characterized in that, Applied to a kernel-mode driver, where the kernel-mode driver and the user-mode application run on the same operating system, the method includes: Receive process identification information from the user-mode application terminal, wherein the process identification information is used to identify the process corresponding to the service to be detected, and the service runs on the user-mode application terminal; Using the file descriptor of the file associated with the process identification information, the file is identified as a socket file, wherein the file descriptor is used to identify the file opened by the process; According to the socket file, access the network stack data of the kernel where the kernel-mode driver is located to obtain the traffic detection result of the service, wherein the traffic detection result is used to represent the network traffic used by the service in the process of using the process for network communication; The traffic detection results are sent to the user-mode application for display.

2. The method according to claim 1, characterized in that, The step of accessing the network stack data of the kernel where the kernel-mode driver resides according to the socket file to obtain the traffic detection result of the service includes: According to the socket file, access the network stack data of the kernel to obtain the socket structure corresponding to the socket file; Using the socket structure, the traffic value and / or network status information of the network traffic used by the service during network communication using the process are obtained, wherein the network status information is used to indicate whether the network status corresponding to the network traffic is a normal network status or an abnormal network status. The traffic value and / or the network status information are determined as the traffic detection result.

3. The method according to claim 2, characterized in that, The step of using the socket structure to obtain the network traffic value and / or network status information used by the service during network communication using the process includes: Determine the network protocol type used by the service during network communication using the process, wherein the network protocol type includes Transmission Control Protocol type and / or User Datagram Protocol type; Using the socket structure, obtain the traffic value of the network traffic corresponding to the network protocol type and / or the network status information.

4. The method according to claim 2, characterized in that, The kernel-mode driver includes a kernel driver module and a protocol stack module. The step of accessing the kernel's network stack data according to the socket file to obtain a socket structure corresponding to the socket file includes: The kernel driver module accesses the kernel's network stack data according to the socket file in order to determine the socket structure in the protocol stack module; The step of using the socket structure to obtain the network traffic value and / or network status information used by the service during network communication using the process includes: The protocol stack module uses the socket structure to obtain the network traffic value and / or the network status information; Sending the traffic detection results to the user-mode application for display includes: The protocol stack module sends the traffic detection results to the user-space application for display via the kernel driver module.

5. The method according to claim 1, characterized in that, The step of identifying a file as a socket file using a file descriptor associated with the process identifier information includes: Obtain a list of file handles opened by the process corresponding to the process identification information, wherein the file handle list is used to store the mapping relationship between different file descriptors and different file objects; Based on the file object corresponding to the file descriptor in the file handle list, the file is identified as the socket file.

6. The method according to claim 5, characterized in that, The step of identifying the file as the socket file based on the file object corresponding to the file descriptor in the file handle list includes: The file descriptors in the file handle list are traversed. In the file handle list, determine the target file object that has the mapping relationship with the traversed target file descriptor; Based on the target file object, the file corresponding to the target file descriptor is identified as the socket file.

7. The method according to claim 6, characterized in that, The kernel-mode driver includes a protocol stack module. The step of identifying the file corresponding to the target file descriptor as the socket file based on the target file object includes: The protocol stack module determines the target pointer type corresponding to the socket file to be identified, wherein the target pointer type is a predefined pointer type for the socket file to be identified; The protocol stack module recognizes the file corresponding to the target file descriptor as the socket file in response to the pointer type of the target file object being the target pointer type; And / or, The kernel-mode driver includes a kernel driver module, and the step of traversing each file descriptor in the file handle list includes: The kernel driver module iterates through each of the file descriptors in the file handle list; And / or, The kernel-mode driver includes a kernel driver module, which determines, in the file handle list, target file objects that have the mapping relationship with the traversed target file descriptors, including: The kernel driver module determines the target file object that has the mapping relationship with the target file descriptor in the file handle list.

8. The method according to claim 5, characterized in that, The step of obtaining the list of file handles opened by the process corresponding to the process identifier information includes: Using the process identification information, the main data structure of the process is located in the kernel, and a first type pointer is determined from the main data structure, wherein the main data structure includes information describing the process, and the information includes the process identification information; Access the file management data structure pointed to by the first type of pointer, and the second type of pointer determined from the file management data structure, wherein the file management data structure includes information for maintaining the file descriptor; Read the list of file handles pointed to by the second type pointer.

9. The method according to any one of claims 1 to 8, characterized in that, The step of detecting the network traffic used by the service during network communication using the process, according to the socket file, and obtaining the traffic detection result includes: The socket file is locked. Based on the locked socket file, detect the network traffic used by the service during network communication using the process, and obtain the traffic detection result. After detecting the network traffic used by the service during network communication using the process according to the socket file and obtaining the traffic detection results, the locked socket file is unlocked.

10. The method according to any one of claims 1 to 8, characterized in that, The receiving of process identifier information from the user-mode application includes: In response to a first control command from the control interface in the user-mode application, the process identification information is received from the first control command; Sending the traffic detection result to the user-mode application for display includes: In response to a second control command from the control interface, the traffic detection result corresponding to the network protocol type in the second control command is sent to the user-mode application for display.

11. A network traffic detection system, characterized in that, This includes user-mode application and kernel-mode driver, among which, The user-mode application is used to send process identification information to the kernel-mode driver, wherein the process identification information is used to identify the process corresponding to the service to be detected, and the service runs on the user-mode application. The kernel-mode driver is used to identify the file as a socket file using the file descriptor of the file associated with the process identification information, wherein the file descriptor is used to identify the file opened by the process; according to the socket file, it accesses the network stack data of the kernel where the kernel-mode driver resides to obtain the traffic detection result of the service, wherein the traffic detection result is used to represent the network traffic used by the service during network communication using the process; and sends the traffic detection result to the user-mode application. The user-mode application is used to display the traffic detection results.

12. A vehicle, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the method according to any one of claims 1 to 10.

Images