Traffic collection and analysis method and system within cloud environment
By deploying agent probes on cloud nodes to receive configuration messages from the management platform and build new configuration instances, combined with kernel-level packet filtering programs and asynchronous packet processing, the monitoring blind spots and resource consumption issues in traffic collection in the cloud environment are resolved, achieving efficient traffic collection and analysis.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING SHENGXIN NETWORK TECH CO LTD
- Filing Date
- 2026-05-15
- Publication Date
- 2026-07-31
AI Technical Summary
In cloud environments, existing traffic acquisition solutions suffer from monitoring blind spots, data interruptions, and excessive system resource consumption. In particular, when multiple network interface cards are monitored concurrently, updating the configuration of the acquisition probe can lead to interruptions in traffic acquisition and excessive system resource consumption.
By deploying Agent probes on cloud nodes, receiving configuration messages from the management platform, building new configuration instances and switching within preset processing threads, and combining kernel-level packet filtering programs and asynchronous packet processing, traffic collection and analysis are achieved.
It enables seamless and smooth replacement of policy configurations without interrupting the current data collection task, reducing system maintenance costs, minimizing redundant traffic copying, and improving traffic throughput and processing concurrency performance.
Smart Images

Figure CN122226817B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of cloud network traffic monitoring technology, specifically to a method and system for traffic collection and analysis in a cloud environment. Background Technology
[0002] Conventional cloud traffic collection solutions typically involve deploying centralized traffic monitoring devices at the cloud boundary or utilizing the port mirroring function of virtual switches to replicate and aggregate network traffic for unified processing. For direct communication traffic distributed between cloud nodes, these solutions suffer from significant monitoring blind spots, making it difficult to obtain a complete view of network traffic. Furthermore, in existing distributed collection methods, the collection program usually requires a restart to take effect when policies are adjusted, which can cause interruptions and loss of monitoring data during the restart process. Simultaneously, as network throughput increases, the copying of large amounts of data packets from kernel space to user space generates significant system resource overhead, thereby impacting the performance of services running on cloud nodes.
[0003] The information disclosed in this background section is intended only to enhance the understanding of the overall background of the invention and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention
[0004] The purpose of this invention is to solve the technical problems of traffic collection interruption caused by configuration updates of the acquisition probe under the condition of concurrent monitoring of multiple network cards in a cloud environment, and the excessive system resource overhead caused by lock contention and frequent copying of invalid packets due to multi-threaded modification of shared state during cross-network card aggregation processing. The invention provides a traffic collection and analysis method and system in a cloud environment.
[0005] The first aspect of this invention provides a method for traffic collection and analysis in a cloud environment, applied to an Agent probe deployed on a cloud node, comprising: receiving a configuration message issued by a management platform, the configuration message including at least a collection strategy and a forwarding strategy; parsing and verifying the configuration message; during the execution of the current collection task, constructing a new configuration instance based on the configuration message, and switching to the new configuration instance within a preset processing thread; determining a target network interface card (NIC) matching the collection strategy, and creating a collection instance for each target NIC; wherein the collection instance loads a kernel-level packet filtering program compiled according to the collection strategy for capturing data packets at the kernel level; asynchronously delivering the data packet objects captured by each collection instance to a preset event loop thread; within the event loop thread, a traffic processing instance performs serial processing on the delivered data packet objects to obtain processed data packets, wherein the serial processing includes identifying and filtering data packets based on the filtering conditions in the collection strategy; and sending the processed data packets to the corresponding forwarding target through a preset forwarding protocol according to the forwarding strategy.
[0006] In one embodiment of the present invention, the step of constructing a new configuration instance based on the configuration message during the execution of the current acquisition task and switching to the new configuration instance within a preset processing thread includes: constructing the new configuration instance containing new acquisition strategy logic and new forwarding strategy logic outside the execution environment of the currently effective configuration; issuing a stop reading command to the currently running old configuration instance to cut off the data stream input of the front-end packets; allocating a preset grace period for delays to objects in the old configuration instance; and, after confirming that the in-transit data packets in the preset processing thread queue and sending buffer have been consumed, reclaiming the old configuration instance within the preset processing thread and switching to the new configuration instance.
[0007] In one embodiment of the present invention, determining the target network interface card (NIC) matching the acquisition strategy and creating an acquisition instance for each target NIC includes: obtaining a full list of NICs for the current node; comparing the NIC names in the full list with the NIC filtering rules in the acquisition strategy, and extracting a set of matching NICs as the target NICs; allocating an independent underlying packet capture handle and file descriptor for each target NIC; extracting the stateless conditions based on network layer and transport layer features in the acquisition strategy and converting them into kernel-level packet filtering interface (BPF) expressions, generating the kernel-level packet filtering program and attaching it to the underlying packet capture handle.
[0008] In one embodiment of the present invention, the step of asynchronously delivering the data packet objects captured by each of the acquisition instances to a preset event loop thread includes: each acquisition instance reading the data packet object from the kernel space of the corresponding target network card using an independent kernel read handle; each acquisition instance acting as an independent data production end asynchronously delivering the data packet object in a read-only state to the event loop thread through a lockless circular buffer.
[0009] In one embodiment of the present invention, the step of identifying and filtering data packets based on the filtering conditions in the acquisition strategy includes: extracting the network layer and transport layer header information of the data packet object to construct a unique TCP stream identifier; establishing a stream state cache table in memory, maintaining the TCP stream state and the initial packet cache queue based on the unique TCP stream identifier; intercepting the preceding bytes of the TCP payload of the data packet and matching them with a preset protocol feature code execution mode to determine whether the network protocol to which the current data packet belongs is the target protocol; when the match is determined to be the target protocol, extracting and allowing the historical data packets and the current data packet in the initial packet cache queue of the corresponding TCP stream; when the match is determined to be a non-target protocol, discarding the subsequent arriving data packets of the corresponding TCP stream.
[0010] In one embodiment of the present invention, the step of sending the processed data packet to the corresponding forwarding target through a preset forwarding protocol according to the forwarding strategy includes: constructing a sending instance within the preset event loop thread and establishing a token bucket that matches the bandwidth configuration; deducting tokens from the token bucket according to the expected number of bytes of the data packet to be sent, and discarding the data packet to be sent when the token balance is less than a preset balance threshold; monitoring the capacity status of the sending buffer, and generating asynchronous congestion feedback information when a preset high-water mark is reached, and feeding it back to the collection instance to adjust the collection strategy.
[0011] In one embodiment of the present invention, the method further includes: attaching an extended BPF probe to the target function address of a user-space process to extract an encrypted session key and corresponding first basic association information; identifying the current cryptographic library version, matching a preset version profile to obtain the corresponding structure field offset configuration, and reading key data based on the offset configuration; performing a time window interval preliminary screening on the captured encrypted network data stream based on the extracted time attribute of the encrypted session key to obtain candidate data streams; extracting second basic association information from the candidate data streams, comparing it with the first basic association information for feature consistency, and associating the encrypted session key with the corresponding encrypted network data stream when the verification passes.
[0012] A second aspect of the present invention provides a traffic acquisition and analysis system in a cloud environment, applied to an Agent probe deployed on a cloud node, comprising: a receiving module for receiving a configuration message issued by a management platform, the configuration message including at least a collection strategy and a forwarding strategy; a first processing module for parsing and verifying the configuration message, constructing a new configuration instance based on the configuration message during the execution of the current collection task, and switching to the new configuration instance within a preset processing thread; a determining module for determining a target network interface card (NIC) matching the collection strategy, and creating a collection instance for each target NIC; wherein the collection instance loads a kernel-level packet filtering program compiled according to the collection strategy, for capturing data packets at the kernel level; a second processing module for asynchronously delivering the data packet objects captured by each collection instance to a preset event loop thread; a third processing module for serially processing the delivered data packet objects by a traffic processing instance within the event loop thread to obtain processed data packets, wherein the serial processing includes identifying and filtering data packets based on the filtering conditions in the collection strategy; and a sending module for sending the processed data packets to the corresponding forwarding target through a preset forwarding protocol according to the forwarding strategy.
[0013] A third aspect of the present invention provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a traffic acquisition and analysis method in a cloud environment as described in the first aspect.
[0014] A fourth aspect of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the traffic acquisition and analysis method in a cloud environment as described in the first aspect.
[0015] Compared with the prior art, the technical effects achieved by the present invention are as follows:
[0016] By applying the collection and forwarding policies issued by the application management platform, and constructing new configuration instances based on these configurations, atomic switching is performed within a preset processing thread to achieve hot updates of the collection policies. This allows for seamless and smooth replacement of policy configurations without interrupting the current collection task, significantly reducing system maintenance costs. By monitoring the local network interface card (NIC) and creating independent collection instances for each target NIC, combined with the mounted kernel-level packet filtering program, refined packet processing, concurrent collection across multiple NICs, and efficient initial screening in the kernel mode are achieved. This effectively reduces redundant traffic copying to user-mode memory and significantly lowers the CPU load on the host system. By asynchronously delivering packet objects collected by multiple collection instances to the event loop thread, a single traffic processing instance performs unified serial processing. This eliminates data contention caused by shared state modifications in traffic filtering and processing logic during multi-threaded concurrent collection, ensuring consistency and thread safety in the processing process, while simultaneously improving the overall system throughput and concurrent processing performance. Attached Figure Description
[0017] Figure 1 This is a flowchart illustrating a method for traffic collection and analysis in a cloud environment according to an embodiment of the present invention. Figure 2 This is a schematic diagram of the framework of a traffic acquisition and analysis system in a cloud environment according to an embodiment of the present invention. Figure 3 This is a schematic diagram of the frame of an electronic device according to an embodiment of the present invention. Detailed Implementation
[0018] Unless otherwise expressly stated, throughout the specification and claims, the term "comprising" or its variations such as "including" or "comprises" shall be understood to include the stated elements or components without excluding other elements or other components.
[0019] The technical solution of the present invention is illustrated below through specific embodiments. It should be understood that the one or more steps mentioned in the present invention do not preclude the existence of other methods and steps before or after the combined steps, or that other methods and steps may be inserted between these explicitly mentioned steps. It should also be understood that these examples are for illustrative purposes only and are not intended to limit the scope of the present invention. Unless otherwise stated, the numbering of each method step is only for the purpose of identifying each method step, and not for limiting the order of each method or limiting the scope of the present invention. Changes or adjustments to their relative relationships, without substantial changes to the technical content, can also be considered as within the scope of the present invention.
[0020] This invention provides a method for collecting and analyzing east-west traffic within a cloud. The application scenario is an agent-based east-west traffic collection and analysis system within a cloud, consisting of a management platform and lightweight agent probes deployed on various cloud nodes (such as physical servers, virtual machines, or container hosts). The management platform, as the system's control and analysis center, is responsible for unified configuration management, distributed probe status monitoring, and data aggregation and analysis. The agent probes, as distributed collection nodes, are responsible for capturing, filtering, identifying protocols, and reporting local traffic.
[0021] like Figure 1 As shown in this embodiment, a method for collecting and analyzing east-west traffic within a cloud may specifically include the following steps: S101 receives configuration messages from the management platform. The configuration messages include at least the collection policy and the forwarding policy. The management platform acts as the control plane, pushing configuration messages to the Agent probe through a pre-defined southbound interface (such as a long-connection channel based on HTTP / 2).
[0022] When the management platform detects the addition of a new probe, a user modifying the monitoring scope, or a change in network topology, it pushes configuration messages to the Agent probe via a persistent connection or asynchronous message queue. These configuration messages are typically encapsulated in a serialized format (such as JSON or Protocol Buffers).
[0023] The collection policy defines the target traffic range to be monitored, which may include network card filtering regular expressions, IP address range (CIDR format), port range, direction (inbound / outbound) and policy type (allow or block), etc. The forwarding policy defines the data processing path after collection, including parameters such as forwarding target host (supporting IPv4, IPv6 or domain name, forwarding protocol) and bandwidth limit threshold.
[0024] In addition, in some implementation scenarios, the probe can also adopt an active pull mode, which obtains the latest configuration updates by periodically accessing the configuration interface of the management platform.
[0025] S102, parse and verify the configuration message, construct a new configuration instance based on the configuration message during the execution of the current collection task, and switch to the new configuration instance within the preset processing thread; In this embodiment, after receiving the data stream, the Agent probe first uses a preset verification algorithm (such as MD5 signature verification or logical integrity check) to ensure that the configuration message has not been tampered with during transmission and that its semantics are valid. It should be understood that, in order to achieve hot updates of the collection task without restarting the process, the Agent probe will allocate a new space in memory and instantiate a new configuration object (i.e., a new configuration instance), which contains the updated policy logic pointer.
[0026] During the switching process, this embodiment employs a smooth transition mechanism similar to copy-on-write or reference counting management. After ensuring that the preset processing thread (such as the main logic loop thread) has completed processing the current data packet, the global configuration pointer is pointed to the new configuration instance through atomic operations, thereby achieving seamless replacement of the acquisition logic and avoiding the risk of packet loss due to configuration loading.
[0027] S103, determine the target network interface card that matches the acquisition strategy, and create an acquisition instance for each target network interface card; wherein, the acquisition instance loads a kernel-level packet filtering program compiled according to the acquisition strategy, which is used to capture data packets at the kernel level; Specifically, the agent probe calls the operating system kernel interface to obtain a full list of network interfaces of the current node and compares it one by one with the filtering rules in the collection strategy. The target network interface can be, for example, a physical network interface (eth0), a virtual bridge port (veth pair), or a loopback interface (lo).
[0028] In one embodiment of this application, resources are independently allocated for each selected target network interface card (NIC) to create a dedicated acquisition instance; wherein, the acquisition instance loads a kernel-level packet filter program compiled according to the acquisition strategy. The kernel-level packet filter program may be, for example, classic Berkeley Packet Filter (BPF) bytecode or enhanced Berkeley Packet Filter (eBPF) instruction set, which is directly mounted on the kernel's network protocol stack hook functions.
[0029] In this way, data packets can be initially filtered according to the policy when they arrive at the network card driver layer or enter the early stages of the protocol stack. Only packets that match the rules will be captured and sent to user space, thereby greatly reducing the system overhead caused by frequent context switching between kernel space and user space.
[0030] S104, asynchronously deliver the data packet objects captured by each acquisition instance to the preset event loop thread; It should be understood that, in order to fully utilize the concurrent performance of multi-core processors and prevent instantaneous high voltage at the acquisition end from blocking subsequent processing, this application adopts an asynchronous decoupled producer-consumer architecture. Each acquisition instance acts as an independent data producer, delivering the captured data packet objects (containing the packet payload and its timestamp, ingress interface index, and other metadata) to one or more pre-defined event loop threads through efficient memory mapping logic (such as mmap) or a lock-free ring buffer.
[0031] In this asynchronous model, the collection instance is only responsible for the rapid reading and storage of underlying messages, without participating in complex analysis operations, thus ensuring the real-time nature of the collection action.
[0032] S105, within the event loop thread, the traffic processing instance performs serial processing on the delivered data packet objects to obtain the processed data packets; Specifically, the serial processing includes at least identifying and filtering data packets based on the filtering conditions in the acquisition strategy.
[0033] In one optional embodiment of this application, the traffic processing instance sequentially extracts packet objects from the event loop queue and performs deep packet inspection (DPI) or flow state tracing. As a concrete processing method, it parses the network layer (such as IP header) and transport layer (such as TCP / UDP header) characteristics of the packets and performs secondary filtering based on the fine-grained rules in the policy (such as blocking traffic of specific domain names or retaining only the header information of specific protocols).
[0034] By performing unified serial processing in user space, the sequential order and state consistency of TCP streams can be effectively maintained, ultimately resulting in structured processed data packets that meet the analysis requirements.
[0035] S106, according to the forwarding strategy, the processed data packet is sent to the corresponding forwarding target through the preset forwarding protocol.
[0036] In one embodiment of this application, the forwarding target may be, for example, a remote traffic analysis platform, a centralized storage cluster, or a security audit server.
[0037] The agent probe re-encapsulates the processed data packets according to a predefined forwarding strategy. This predefined forwarding protocol can be, for example, VXLAN encapsulation (used to transparently transmit raw Layer 2 packets across Layer 3 networks), a standard UDP tunnel, or an encrypted TLS link. During transmission, the agent probe invokes the operating system's socket interface to push the encapsulated data packets onto the network link, ensuring reliable transmission of traffic from the collection end to the analysis end.
[0038] In summary, this embodiment constructs an integrated traffic-aware architecture that combines high performance and flexibility by performing efficient filtering at the kernel layer, asynchronous decoupled delivery in user space, and a configuration switching mechanism that supports hot updates.
[0039] In this embodiment of the invention, by applying the collection and forwarding strategies issued by the application management platform, and constructing a new configuration instance based on the configuration, atomic switching is performed within a preset processing thread, achieving hot updates of the collection strategy. This allows for seamless and smooth replacement of the strategy configuration without interrupting the current collection task, significantly reducing system maintenance costs. By monitoring the local network interface card (NIC) and creating an independent collection instance for each target NIC, combined with the mounted kernel-level packet filtering program, refined packet processing, concurrent collection from multiple NICs, and efficient initial screening in the kernel mode are achieved. This effectively reduces redundant traffic copying to user-mode memory, significantly reducing the load on the host CPU from data collection. By asynchronously delivering the packet objects collected by multiple collection instances to the event loop thread, a single traffic processing instance performs unified serial processing, eliminating data contention caused by shared state modifications in traffic filtering and processing logic during multi-threaded concurrent collection. This ensures consistency and thread safety in the processing process, while simultaneously improving the overall system throughput and concurrent processing performance.
[0040] In an optional embodiment of this application, step S102 may specifically include the following steps: S201, outside the execution environment of the currently effective configuration, construct a new configuration instance containing new collection strategy logic and new forwarding strategy logic; In one embodiment of this application, after the Agent probe's master control process has finished parsing the issued configuration message, it will not directly overwrite or modify the existing business variables in the global memory area that is currently being frequently accessed by the data processing thread.
[0041] Specifically, the system reallocates an isolated memory region in a separate heap memory space and instantiates a brand new configuration management object as the new configuration instance. This new configuration instance can be, for example, a C++ class object encapsulating a multi-level filtering rule hash table and a remote IP routing table, a Go language struct, or a Rust memory-safe instance.
[0042] By pre-building outside the execution environment of the currently effective configuration, the data race problem caused by concurrent reads from multi-core CPUs can be effectively avoided, thus providing a physical basis for memory isolation for subsequent lock-free state switching.
[0043] S202, issues a stop reading command to the currently running old configuration instance, cutting off the data stream input of the front-end message; It should be understood that, in order to prevent old configuration instances from continuing to inject dirty data captured according to old rules into the system's internal buffer during the upcoming transition period, the master thread must actively intervene in the current data production chain.
[0044] As a preferred implementation, the master thread issues the stop reading instruction to the underlying packet capture handle bound to the old configuration instance (e.g., by modifying the atomic flag to False, closing the file descriptor, or unregistering the event listener of epoll / kqueue), causing the user-space program of the probe to forcibly stop pulling newly arriving packets from the kernel-level network interface or memory-mapped (mmap) shared region.
[0045] After the underlying data packets are captured by the BPF program, they will be temporarily stored in the kernel buffer or directly discarded according to the preset policy because the user space stops pulling them. This completely cuts off the data flow input of the front-end packets at the physical logic level, ensuring that the amount of data to be processed under the old configuration becomes a finite, no longer growing closed set.
[0046] S203, allocate a preset grace period for objects in the old configuration instance; Specifically, after cutting off the front-end data input, some data packets that have been pulled but not yet processed still remain in the unlocked ring buffer and the back-end event processing queue. The memory structure corresponding to the old configuration instance cannot be released immediately, otherwise it will cause the processing thread to access illegal memory and cause the process to crash (Core Dump).
[0047] To this end, the agent probe starts an asynchronous timer or reference count tracker to allocate a delay grace period for the old configuration instance. The preset delay grace period can be set to, for example, a fixed 500 milliseconds to 2 seconds, or a drain time dynamically calculated based on the current system network throughput and buffer water level.
[0048] S204 After confirming that the in-transit data packets in the preset processing thread queue and the sending buffer have been consumed, the old configuration instance is recycled and the new configuration instance is switched in the preset processing thread.
[0049] In one specific embodiment of this application, the event loop thread polls and checks its own task queue length and the reference count of the remaining tasks in the send buffer at the end of each processing cycle. When the number pointer of the in-transit data packets is detected to be zero, or the atomic reference count associated with the old configuration instance drops to zero, it is determined that the in-transit data in the old context has been completely cleaned and sent outbound.
[0050] Subsequently, within a preset processing thread, atomic operation instructions provided by the CPU hardware level (such as CAS, Compare-And-Swap instructions) are used to instantly redirect the global pointer pointing to the currently effective configuration to the memory address of the new configuration instance created in step S201.
[0051] Once the atomic switch is complete and it is confirmed that no background thread is holding a read lock or reference to the old configuration instance, the memory reclamation function will be called to safely destroy and release the memory space occupied by the old configuration instance.
[0052] In an optional embodiment of this application, step S103 may specifically include the following steps: S301, retrieve the full list of network interface cards (NICs) for the current node; Specifically, when the Agent probe initializes or detects a change event in the system's network device, the Agent probe's user-space process calls the operating system's underlying network management interface (such as the netlink socket communication mechanism or the getifaddrs() system call in Linux) to traverse the current host's network namespace.
[0053] The full list of network interface cards (NICs) obtained through the above calls can be, for example, a linked list structure or array set containing metadata of various network devices such as physical Ethernet interfaces (e.g., eth0, eth1), virtual LAN interfaces (e.g., vlan10), container bridging interfaces (e.g., docker0, cni0), or virtual NIC pairs (e.g., veth peer), thereby providing a global network topology perspective for subsequent targeted data collection.
[0054] S302 compares the network card names in the full list of network cards with the network card filtering rules in the collection strategy, and extracts the matching set of network cards as the target network cards; In one embodiment of this application, the policy matching engine within the Agent probe extracts all network interface attributes and performs a string comparison algorithm against the issued policy. Network interface card (NIC) filtering rules include, but are not limited to, string matching instructions, fuzzy expressions with wildcards, or regular expressions based on specific container network naming conventions.
[0055] After executing the above comparison logic, the system will filter out network interfaces that are not related to the business (such as loopback interfaces or management interfaces), and the intersection of the outputs is the target network card to be monitored, thereby avoiding the waste of CPU resources caused by blindly monitoring non-target network links.
[0056] S303 assigns an independent low-level packet capture handle and file descriptor to each target network card; As a preferred implementation method, after determining the target network interface card (NIC) set, in order to achieve high-concurrency lock-free data acquisition in a multi-NIC environment, the Agent probe will establish an independent I / O channel for each target NIC at the system kernel layer.
[0057] Specifically, the agent probe requests resources from the kernel through network libraries (such as libpcap) or raw socket system calls. The underlying packet capture handle can be a pointer to a pcap_t structure that maintains the underlying loopback state, or it can be a raw socket instance of type AF_PACKET or a high-performance data path object based on AF_XDP technology.
[0058] In this embodiment, the file descriptor includes, but is not limited to, the non-negative integer index value allocated by the operating system kernel to the socket instance, which serves as the unique identifier for maintaining a long-term connection communication channel between the kernel space and the user space.
[0059] By assigning independent handles and descriptors to each network card, the data streams of different network cards are physically isolated, effectively eliminating the lock contention bottleneck during multi-threaded concurrent reads.
[0060] S304: Extract the stateless conditions based on network layer and transport layer features in the acquisition strategy, transform them into kernel-level network packet filtering interface (BPF) expressions, generate kernel-level packet filtering programs, and attach them to the underlying packet capture handle.
[0061] It should be understood that stateless conditions are static attribute rules that can be used to make judgments using a single packet header, such as matching the mask for the source / destination IP address (e.g., limiting the 192.168.1.0 / 24 network segment), matching a specific transport layer port number (e.g., TCP port 80 or 443), or matching the protocol type (e.g., allowing only ICMP protocol). These rules do not depend on the network connection context state.
[0062] The compiler engine inside the Agent probe translates these human-readable stateless conditions into the kernel-level network packet filtering interface (BPF) expression. This expression can be, for example, a binary instruction set containing multiple BPF virtual machine opcodes or an eBPF bytecode file. Subsequently, the probe directly mounts the compiled instruction set to the underlying packet capture handle established in step S303 by calling kernel-level system calls such as setsockopt(..., SO_ATTACH_FILTER, ...).
[0063] Based on this underlying physical principle, when the network card driver layer receives an external data packet, the BPF virtual machine in the kernel will perform a bitwise AND operation on the data packet in the very early stage of the kernel-mode network protocol stack before the data packet is copied to user mode. Data packets that do not match the rules will be silently discarded in the kernel layer. Only matching data packets will trigger an interrupt and perform zero-copy mapping (mmap) to user mode space, thereby greatly reducing the performance overhead of cross-mode memory copying.
[0064] In an optional embodiment of this application, step S104 may specifically include the following steps: S401, each acquisition instance uses an independent kernel read handle to read data packet objects from the corresponding target network card kernel space; Specifically, a capture instance can be an independent worker thread, coroutine, or instantiated packet capture object entity running in user space responsible for specific network interface card I / O tasks. The kernel read handle serves as the physical link between user space and the kernel protocol stack; for example, it can be a file descriptor based on a raw socket, a virtual address pointer based on a high-performance memory mapping mechanism (mmap), or a receive descriptor in AF_XDP technology.
[0065] It should be noted that the data packet object not only contains the original payload of the message, but also encapsulates its associated metadata, such as nanosecond-level reception timestamps, network interface indexes, and original packet lengths.
[0066] In one embodiment of this application, after an external packet is written to the kernel-reserved circular buffer via NIC DMA technology, the acquisition instance initiates a non-blocking read request through the aforementioned independent handle, quickly guiding the data to the corresponding user-space buffer. Based on the design principle that each instance has an independent handle, parallel acquisition at the physical layer is achieved, eliminating serialization contention during the kernel read phase when multiple NICs are concurrent.
[0067] S402, each acquisition instance acts as an independent data production end, asynchronously delivering read-only data packet objects to the event loop thread through a lockless circular buffer.
[0068] Specifically, the lock-free circular buffer can be, for example, a contiguous shared memory region that is pre-allocated during system startup and supports a multi-producer single-consumer (MPSC) model. Logically, it uses atomic comparison and exchange instructions (such as CAS instructions) provided by the underlying CPU to maintain head and tail index pointers, rather than relying on traditional synchronization mechanisms such as mutexes or spinlocks.
[0069] A data packet object in a read-only state refers to an object in which, at the moment of delivery, the acquisition instance transfers control of the data by passing a memory reference or a constant pointer, and uses memory barriers or semantic protection mechanisms to ensure that the object cannot be modified within the buffer.
[0070] As an feasible approach, the event loop thread, acting as the sole consumer, is typically bound to a specific CPU core and monitors the buffer status through polling or event-driven methods (such as epoll_wait). In this asynchronous architecture, the acquisition instance can immediately return to execute the next round of capture after completing the packet delivery action, without waiting for feedback from the backend analysis logic. This design achieves extremely high data throughput through lock-free memory interaction and, in physical principle, guarantees the unidirectionality and security of data flow, ultimately providing a high-performance data supply path for backend traffic identification and protocol analysis.
[0071] In an optional embodiment of this application, the step S105 above, "identifying and filtering data packets based on the filtering conditions in the acquisition strategy," may specifically include the following steps: S501, extract the network layer and transport layer header information of the data packet object, and construct a unique identifier for the TCP stream; Specifically, after the event loop thread extracts the data packet object from the lock-free circular buffer, the protocol parsing engine in the system will peel off the Ethernet frame header in reverse order of the network protocol stack encapsulation, extract the source IP address and destination IP address in the network layer IP header, and further extract the source port number and destination port number in the transport layer TCP header.
[0072] In this embodiment, the unique identifier of the TCP stream can be, for example, an integer hash value calculated by a non-cryptographic hash algorithm based on the above five-tuple information (source IP, destination IP, source port, destination port, protocol number), or a byte sequence directly concatenated. It serves as the global addressing key value of the network connection in the system memory, providing basic data support for subsequent cross-message context association.
[0073] S502 establishes a stream state cache table in memory and maintains the TCP stream state and initial packet cache queue based on the unique identifier of the TCP stream. It should be noted that the stream state cache table, for example, can be a state management area dynamically allocated and maintained in user space, based on data structures with high concurrency query efficiency such as hash tables or red-black trees. When it is determined that a TCP stream's unique identifier is appearing for the first time (e.g., when a TCP SYN packet is detected), a stream context entry is allocated for it in this cache table, recording its current TCP stream state, such as new connection or handshake.
[0074] Meanwhile, the initial message buffer queue can be, for example, a sliding window or linked list structure with a pre-allocated fixed size (such as the first 2048 bytes of the buffer).
[0075] Since the application layer protocol characteristics are often not fully exposed in the early stages of TCP connection establishment, the payload of early arriving packets is temporarily copied and stored in the initial packet buffer queue. The underlying logic is to use space to trade for time, avoid making premature misjudgments due to insufficient information in the preceding packets, and thus prevent the loss of the first packet of critical business.
[0076] S503: Extract the preceding bytes of the TCP payload of the data packet and match them with the preset protocol signature execution mode to determine whether the network protocol to which the current data packet belongs is the target protocol; In this embodiment, when the data in the initial message buffer queue accumulates to a preset threshold, or when a PSH flag message carrying the actual application layer payload is received, the feature extraction engine will read the header byte stream of the payload.
[0077] The preset protocol signature can be, for example, a plaintext ASCII string such as "GET", "POST" or "HTTP / 1.1" that identifies the HTTP protocol, or a specific hexadecimal magic number that identifies the TLS encrypted handshake process.
[0078] The system calls a multi-pattern matching algorithm (such as the Aho-Corasick automaton algorithm) or a regular expression engine to compare the truncated preceding bytes with these feature codes to determine whether the TCP stream belongs to the target protocol of interest in the policy issued by the management platform.
[0079] S504, when the match is determined to be the target protocol, extract and allow the historical data packets and current data packets in the initial message buffer queue of the corresponding TCP stream; Specifically, based on the result of the feature matching operation, the corresponding context entry is found in the stream state cache table, and the TCP stream state uniquely identified by the TCP stream is updated to "Allowed" in place.
[0080] At this point, the event loop thread is triggered to perform the extraction action, which reassembles the historical data packet memory block temporarily stored in the initial message buffer queue, together with the currently triggered matching data packet object, according to the order of TCP sequence numbers, and asynchronously delivers it to the subsequent sending processing queue.
[0081] S505 discards subsequent arriving data packets of the corresponding TCP stream when the match is determined to be a non-target protocol.
[0082] Specifically, if the preceding bytes cannot match any preset protocol signature, or if an explicit exclusion rule is hit, the state uniquely identified by the TCP stream is forcibly marked as "blocked" or "dropped" in the stream state cache table.
[0083] Based on this state flag update, when subsequent related packets of this TCP connection (such as ACK packets or remaining payload fragments) are delivered from the underlying acquisition end to the event loop thread, the initial hash lookup stage can directly hit the "ignore" state. Therefore, all subsequent deep parsing logic is bypassed, and the memory release function is directly called to destroy the packet object.
[0084] This blocking mechanism, which directly interrupts subsequent processing in the early stages of the data stream, cuts off invalid memory copies at the underlying physical operation level, significantly reducing the CPU's computational load and unnecessary memory usage.
[0085] In an optional embodiment of this application, step S106 may specifically include the following steps: S601 constructs a sending instance within a preset event loop thread and establishes a token bucket that matches the bandwidth configuration. Specifically, the sending instance can be a Socket connection object built based on non-blocking I / O, or a network packet sending handle encapsulating a specific tunneling protocol (such as VXLAN or UDP). When the probe initializes or updates the forwarding module, it parses the bandwidth configuration parameters (such as limiting the maximum sending rate to 10Mbps) in the forwarding policy issued by the management platform and instantiates the token bucket in user-space memory.
[0086] The token bucket, as a logical control structure for traffic shaping, can be a memory availability counter variable driven by a high-precision timer. It periodically increases the number of available tokens according to a constant byte generation rate matched to the bandwidth configuration until a preset maximum bucket capacity limit is reached. Based on this structure, the probe establishes a fine-grained bandwidth control benchmark at the software level, independent of the underlying physical network interface card (NIC) hardware rate-limiting mechanism.
[0087] S602, deduct tokens from the token bucket based on the expected number of bytes of the data packet to be sent, and discard the data packet to be sent when the token balance is less than a preset balance threshold; In this embodiment, before the event loop thread pushes the data packet, after deep packet inspection and protocol encapsulation, into the socket, it first calculates and obtains the estimated number of bytes for the data packet. The estimated number of bytes can be the overall serialized memory length value, including the outer network protocol header encapsulation (such as IP header, UDP header, and VXLAN header) and the original packet payload. Subsequently, the traffic shaping engine performs an atomic subtraction operation, attempting to deduct the corresponding estimated number of bytes from the current count state of the token bucket.
[0088] As an feasible approach, if the calculation result shows that the remaining token after deduction is less than the preset remaining threshold, which can be, for example, zero or a negative lower limit that allows for a very small degree of sudden overdraft, then it is determined that the current instantaneous transmission rate has been overloaded.
[0089] At this point, the executing entity will immediately trigger a memory destruction action, directly discarding the data packet to be sent from the user space. By precisely cutting off traffic bursts exceeding the quota at the source of network transmission, it ensures that the actual number of bytes transmitted outward by the probe is strictly controlled within the set quota range, thereby avoiding the probe from crowding out the normal network communication channels of the core business side.
[0090] S603 monitors the capacity status of the transmission buffer. When it determines that the preset high water level has been reached, it generates asynchronous congestion feedback information and feeds it back to the acquisition instance to adjust the acquisition strategy.
[0091] It should be noted that the sending buffer may be, for example, a ring queue allocated by the system in user space for the aforementioned sending instance, or a low-level write buffer (SO_SNDBUF) allocated by the operating system kernel for the socket; the high-water mark may be, for example, a capacity waterline indicating that the queue is 80% full, or a scalar threshold parameter indicating that the accumulated unacknowledged data packets have reached a warning megabyte count. Specifically, the system's monitoring module or event-driven callback mechanism periodically polls the current sending buffer occupancy index. Once the calculation determines that the current backlog of data has triggered or exceeded the high-water mark, the system instantiates and generates the asynchronous congestion feedback information. This information may, for example, be a control signaling structure containing instructions to reduce the sampling rate, briefly pause packet retrieval, or increase the filtering level, which is transmitted back to the front-end acquisition instance through an in-process lock-free queue or inter-process communication (IPC) mechanism. The underlying logic of this design lies in the introduction of a closed-loop feedback mechanism based on backpressure: when the outgoing capacity of the backend network is limited or the remote link is congested, internal signaling forces the frontend source to actively slow down or perform early packet loss. This physically prevents the unlimited accumulation of data packets in the probe memory pool, effectively ensuring the system's survivability and architectural robustness under extreme network surges.
[0092] In an optional embodiment of this application, the following specific steps may also be included: S701, attaches an extended BPF probe to the target function address of the user space process to extract the encrypted session key and the corresponding first basic association information; Specifically, the Agent probe scans the business processes running on the host machine to identify the dynamic libraries of the encryption protocol stack loaded within them. The target function address can be the memory entry point of a specific exported function in the cryptographic library responsible for handshake completion or data encryption. Extended BPF probes can be uprobe probes based on eBPF technology, which achieve non-intrusive interception of the execution flow by dynamically replacing breakpoint instructions at the target function. When the business process calls the encryption function, the probe is triggered and runs in the kernel sandbox environment, thereby capturing the raw byte stream in the current call stack.
[0093] The first basic association information can be the five-tuple metadata (source / destination IP, source / destination port, protocol number) corresponding to the encrypted connection in kernel mode, or it can be the thread ID and file descriptor related to the process, serving as a unique index anchor for subsequent association analysis.
[0094] S702 identifies the current cryptographic library version, matches the preset version profile to obtain the corresponding structure field offset configuration, and reads the key data based on the offset configuration; As an feasible approach, since the internal data structures (such as the ssl_st structure in OpenSSL) of different versions of cryptographic libraries have different layouts, the probe needs to determine its specific version number through symbol table or binary fingerprinting technology before reading the key. The preset version profile can be an offset mapping table pre-stored in memory, which records the number of physical offset bytes of the "key data pointer" relative to the base address of the structure under different versions.
[0095] Based on the above principle, the BPF probe uses kernel helper functions (such as bpf_probe_read_user) to overcome process space limitations, and accurately locates and reads the symmetric encryption key in memory according to the offset configuration of the structure field.
[0096] The key data can be the server_traffic_secret in the TLS 1.3 protocol or the Master Secret in the TLS 1.2 protocol. This process enables real-time awareness of dynamic keys by leveraging underlying memory layout characteristics without intruding on business logic.
[0097] S703, based on the time attribute of the extracted encrypted session key, performs a time window interval screening on the captured encrypted network data stream to obtain candidate data streams; It should be noted that the time attribute can be a high-precision nanosecond timestamp of the moment the BPF probe captures the key in kernel mode. Because while the probe is intercepting the key in user mode, the underlying network interface card (NIC) acquisition module (such as the NIC acquisition example in the previous steps) is continuously capturing massive amounts of encrypted network data packets.
[0098] To quickly narrow down the comparison range, the analysis engine defines a very short logical time range (e.g., ±500 milliseconds) centered on the time attribute. Within this range, the system execution entity retrieves all encrypted message sequences collected from the underlying layer and extracts message fragments that match this time interval as candidate data streams.
[0099] S704, extract the second basic association information from the candidate data stream, compare it with the first basic association information for feature consistency, and associate the encrypted session key with the corresponding encrypted network data stream when the verification passes.
[0100] Specifically, the protocol header (such as the TCP / IP header) in the candidate data stream is parsed to extract the second basic association information contained therein; The second basic association information has the same attribute category as the first basic association information, for example, both are message quintuples.
[0101] Subsequently, feature consistency comparison logic is executed, which involves bit-to-bit matching of associated features from two independent sources (one intercepted by a user-space function, and the other captured by a kernel-space network interface card). It should be understood that when the two sets of features match perfectly, it proves that the key is the encryption / decryption credential for the data stream. At this point, a logical binding relationship between the encrypted session key and the corresponding data stream is established in the state mapping table, ultimately enabling the backend analysis platform to transparently reconstruct stored encrypted messages using this key.
[0102] This closed-loop process achieves precise pairing of control plane keys and data plane traffic in physical principles, providing a core data foundation for deep threat perception in encrypted scenarios.
[0103] Another embodiment of the present invention relates to a traffic acquisition and analysis system in a cloud environment, applied to agent probes deployed on cloud nodes, such as... Figure 2 As shown, the system specifically includes: The receiving module 20 is used to receive configuration messages issued by the management platform, wherein the configuration messages include at least a collection strategy and a forwarding strategy; The first processing module 21 is used to parse and verify the configuration message, construct a new configuration instance based on the configuration message during the execution of the current collection task, and switch to the new configuration instance within a preset processing thread; The determination module 22 is used to determine the target network interface card that matches the acquisition strategy and create an acquisition instance for each target network interface card; wherein, the acquisition instance is loaded with a kernel-level packet filtering program compiled according to the acquisition strategy, which is used to capture data packets at the kernel level; The second processing module 23 is used to asynchronously deliver the data packet objects captured by each of the acquisition instances to a preset event loop thread; The third processing module 24 is used to perform serial processing on the delivered data packet objects by the traffic processing instance within the event loop thread to obtain the processed data packets. The serial processing includes identifying and filtering data packets based on the filtering conditions in the acquisition strategy. The sending module 25 is used to send the processed data packet to the corresponding forwarding target through a preset forwarding protocol according to the forwarding strategy.
[0104] Optionally, in this embodiment, the first processing module 21 includes: The first processing submodule is used to construct a new configuration instance containing new collection strategy logic and new forwarding strategy logic outside the execution environment of the currently effective configuration; The first control submodule is used to issue a stop reading command to the currently running old configuration instance and cut off the data stream input of the front-end message; The second processing submodule is used to allocate a preset grace period for objects in the old configuration instance; The third processing submodule is used to reclaim the old configuration instance and switch to the new configuration instance within the preset processing thread after confirming that the in-transit data packets in the preset processing thread queue and sending buffer have been consumed.
[0105] Optionally, in this embodiment, the determining module 22 includes: The first acquisition submodule is used to obtain the full list of network interface cards (NICs) of the current node; The fourth processing submodule is used to compare the network card names in the full list of network cards with the network card filtering rules in the acquisition strategy, and extract the matching set of network cards as the target network cards; The fifth processing submodule is used to allocate an independent low-level packet capture handle and file descriptor to each of the target network cards; The sixth processing submodule is used to extract the stateless conditions based on network layer and transport layer features in the acquisition strategy, convert them into kernel-level network packet filtering interface (BPF) expressions, generate the kernel layer packet filtering program, and attach it to the underlying packet capture handle.
[0106] Optionally, in this embodiment, the second processing module 23 includes: The second acquisition submodule is used by each acquisition instance to read the data packet object from the kernel space of the corresponding target network card using an independent kernel read handle; The seventh processing submodule is used by each of the acquisition instances as an independent data production end, to asynchronously deliver the data packet object in read-only state to the event loop thread through a lock-free circular buffer.
[0107] Optionally, in this embodiment, the third processing module 24 includes: The third acquisition submodule is used to extract the network layer and transport layer header information of the data packet object and construct a unique TCP stream identifier; The eighth processing submodule is used to establish a stream state cache table in memory and maintain the TCP stream state and initial packet cache queue based on the TCP stream unique identifier. The interception submodule is used to intercept the preceding bytes of the TCP payload of the data packet and match them with the preset protocol signature execution mode to determine whether the network protocol to which the current data packet belongs is the target protocol. The fourth acquisition submodule is used to extract and allow historical data packets and current data packets in the initial message buffer queue of the corresponding TCP stream when the match is determined to be the target protocol; The discard submodule is used to discard subsequent arriving data packets of the corresponding TCP stream when the match is determined to be a non-target protocol.
[0108] Optionally, in this embodiment, the sending module 25 includes: The first sending submodule is used to construct a sending instance within the preset event loop thread and establish a token bucket that matches the bandwidth configuration. The ninth processing submodule is used to deduct tokens from the token bucket based on the expected number of bytes of the data packet to be sent, and discard the data packet to be sent when the token balance is less than a preset balance threshold. The tenth processing submodule is used to monitor the capacity status of the sending buffer. When it is determined that the preset high water level has been reached, asynchronous congestion feedback information is generated and fed back to the acquisition instance to adjust the acquisition strategy.
[0109] Optionally, in this embodiment, it further includes: The fourth processing module is used to mount an extended BPF probe on the target function address of the user space process to extract the encrypted session key and the corresponding first basic association information. The fifth processing module is used to identify the current cryptographic library version, match the preset version profile to obtain the corresponding structure field offset configuration, and read the key data based on the offset configuration; The sixth processing module is used to perform a preliminary screening of the captured encrypted network data stream within a time window interval based on the time attribute of the extracted encrypted session key to obtain candidate data streams; The seventh processing module is used to extract the second basic association information from the candidate data stream, compare it with the first basic association information for feature consistency, and associate the encrypted session key with the corresponding encrypted network data stream when the verification is successful.
[0110] Another embodiment of the present invention relates to an electronic device, such as Figure 3 As shown, it includes: at least one processor 301; and a memory 302 communicatively connected to the at least one processor 301; wherein the memory 302 stores instructions executable by the at least one processor 301, the instructions being executed by the at least one processor 301 to enable the at least one processor 301 to perform the traffic acquisition and analysis method in the cloud environment in the above embodiments.
[0111] The memory and processor are connected via a bus, which can include any number of interconnecting buses and bridges, connecting various circuits of one or more processors and memories. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and will not be described further herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by the processor is transmitted over the wireless medium via an antenna, which further receives data and transmits it to the processor.
[0112] The processor manages the bus and general processing, and also provides various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory is used to store data used by the processor during operation.
[0113] Another embodiment of the present invention relates to a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the method embodiments described above.
[0114] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0115] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0116] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0117] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the protection scope of the claims of the present invention.
Claims
1. A method for traffic collection and analysis in a cloud environment, characterized in that, Agent probes deployed on cloud nodes include: Receive configuration messages issued by the management platform, wherein the configuration messages include at least a collection policy and a forwarding policy; The configuration message is parsed and verified. During the execution of the current data collection task, a new configuration instance is constructed based on the configuration message, and the process is switched to the new configuration instance within a preset processing thread. Identify the target network interface card (NIC) that matches the acquisition strategy, and create an acquisition instance for each target NIC; wherein, the acquisition instance loads a kernel-level packet filtering program compiled according to the acquisition strategy, which is used to capture data packets at the kernel level; The data packet objects captured by each of the aforementioned acquisition instances are asynchronously delivered to a preset event loop thread; Within the event loop thread, the traffic processing instance performs serial processing on the delivered data packet objects to obtain processed data packets. The serial processing includes identifying and filtering data packets based on the filtering conditions in the acquisition strategy. According to the forwarding strategy, the processed data packets are sent to the corresponding forwarding targets through a preset forwarding protocol.
2. The method according to claim 1, characterized in that, The step of constructing a new configuration instance based on the configuration message during the execution of the current data acquisition task, and switching to the new configuration instance within a preset processing thread, includes: Outside the execution environment of the currently effective configuration, construct a new configuration instance containing the new collection strategy logic and the new forwarding strategy logic; Issue a stop reading command to the currently running old configuration instance, cutting off the data stream input of the front-end message; Assign a preset grace period to the objects in the old configuration instance; After confirming that all in-transit data packets in the preset processing thread queue and sending buffer have been consumed, the old configuration instance is reclaimed within the preset processing thread and the process is switched to the new configuration instance.
3. The method according to claim 1, characterized in that, The step of determining the target network interface card (NIC) that matches the acquisition strategy and creating an acquisition instance for each target NIC includes: Get the full list of network interface cards (NICs) for the current node; The network interface card (NIC) names in the full list of NICs are compared with the NIC filtering rules in the acquisition strategy, and the matching NIC set is extracted as the target NIC. Each target network interface card is assigned an independent low-level packet capture handle and file descriptor; The stateless conditions based on network layer and transport layer features in the acquisition strategy are extracted and transformed into kernel-level network packet filtering interface (BPF) expressions. The kernel-level packet filtering program is then generated and attached to the underlying packet capture handle.
4. The method according to claim 1, characterized in that, The step of asynchronously delivering the data packet objects captured by each of the acquisition instances to a preset event loop thread includes: Each of the aforementioned acquisition instances uses an independent kernel read handle to read the data packet object from the kernel space of the corresponding target network interface card; Each of the aforementioned acquisition instances acts as an independent data production end, asynchronously delivering the data packet objects in a read-only state to the event loop thread through a lock-free circular buffer.
5. The method according to claim 1, characterized in that, The process of identifying and filtering data packets based on the filtering conditions in the acquisition strategy includes: Extract the network layer and transport layer header information of the data packet object to construct a unique TCP stream identifier; A stream state cache table is established in memory, and the TCP stream state and initial packet cache queue are maintained based on the unique identifier of the TCP stream. Extract the leading bytes of the TCP payload of the data packet and match them with the preset protocol signature execution mode to determine whether the network protocol to which the current data packet belongs is the target protocol; When the match is determined to be the target protocol, extract and allow the historical data packets and current data packets in the initial packet buffer queue of the corresponding TCP stream; If the match is determined to be a non-target protocol, subsequent arriving packets in the corresponding TCP stream are discarded.
6. The method according to claim 1, characterized in that, The step of sending the processed data packet to the corresponding forwarding target via a preset forwarding protocol according to the forwarding strategy includes: Within the preset event loop thread, a sending instance is constructed, and a token bucket matching the bandwidth configuration is established; The token bucket is deducted based on the expected number of bytes in the data packet to be sent, and the data packet to be sent is discarded when the remaining tokens are less than a preset remaining threshold. The capacity status of the sending buffer is monitored. When it is determined that the preset high water level has been reached, asynchronous congestion feedback information is generated and fed back to the collection instance to adjust the collection strategy.
7. The method according to claim 1, characterized in that, Also includes: An extended BPF probe is attached to the target function address of the user space process to extract the encrypted session key and the corresponding first basic association information. Identify the current cryptographic library version, match it with a preset version profile to obtain the corresponding structure field offset configuration, and read the key data based on the offset configuration; Based on the time attribute of the extracted encryption session key, a time window interval is used to perform preliminary screening of the captured encrypted network data stream to obtain candidate data streams; Extract the second basic association information from the candidate data stream, compare it with the first basic association information for feature consistency, and associate the encrypted session key with the corresponding encrypted network data stream when the verification passes.
8. A traffic acquisition and analysis system in a cloud environment, characterized in that, Agent probes deployed on cloud nodes include: The receiving module is used to receive configuration messages issued by the management platform. The configuration messages include at least a collection strategy and a forwarding strategy. The first processing module is used to parse and verify the configuration message, construct a new configuration instance based on the configuration message during the execution of the current collection task, and switch to the new configuration instance within a preset processing thread. The determination module is used to determine the target network interface card (NIC) that matches the acquisition strategy, and to create an acquisition instance for each target NIC; wherein, the acquisition instance is loaded with a kernel-level packet filtering program compiled according to the acquisition strategy, which is used to capture data packets at the kernel level; The second processing module is used to asynchronously deliver the data packet objects captured by each of the acquisition instances to a preset event loop thread; The third processing module is used to perform serial processing on the delivered data packet objects by the traffic processing instance within the event loop thread to obtain the processed data packets. The serial processing includes identifying and filtering data packets based on the filtering conditions in the acquisition strategy. The sending module is used to send the processed data packets to the corresponding forwarding target through a preset forwarding protocol according to the forwarding strategy.
9. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the traffic acquisition and analysis method in the cloud environment as described in any one of claims 1 to 7.
10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the traffic acquisition and analysis method in the cloud environment as described in any one of claims 1 to 7.