A method for effectively detecting a typical concurrent problem architecture design of a server
By employing a test architecture that incorporates multi-protocol concurrent connections and cross-connection packet order mutation, the problem of insufficient scenario coverage in server-side concurrency testing is resolved. This enables efficient detection of concurrency issues and enhances the system's security and resistance to attacks.
Patent Information
- Application Number
- CN202610636021.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-05-10
- Publication Date
- 2026-08-25
AI Technical Summary
Existing technologies lack sufficient scenario coverage in server-side concurrency testing, have a low vulnerability trigger rate, and are difficult to effectively detect concurrency issues.
The test architecture employs multi-protocol concurrent connections and cross-connection packet order mutation. By forcing protocol state anomalies and systematic mutation strategies, it ensures a high probability of triggering protocol vulnerabilities. This includes configuring multiple types of network connections, generating clearly identified packet sequences, sending cross-connection packets in a preset order, and mutating the content and order of the packets.
It significantly improved the detection efficiency of server-side concurrency issues, expanded the testing coverage, discovered more potential vulnerabilities, and enhanced the system's robustness and resistance to attacks.
Smart Images
Figure CN122633562A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of fuzz testing technology, specifically relating to an effective architecture design method for detecting typical concurrency problems on the server side. Background Technology
[0002] Protocol fuzzing and model-based fuzzing are two common security testing methods. Protocol fuzzing is a direct testing technique that detects vulnerabilities in the protocol implementation by sending random or anomalous data packets to the target protocol. All test cases are generated and sent in a loop, and tests are performed sequentially, with the next test case executed after the previous one is completed. Its advantages include simple implementation, ease of understanding and deployment, low resource consumption, and suitability for quickly verifying the basic robustness of a protocol. Its disadvantages include the inability to test multiple protocol states or complex interaction scenarios simultaneously, making it suitable for simple protocols or preliminary testing; the long execution time of a single test case may affect overall testing efficiency. In contrast, model-based fuzzing can simultaneously cover multiple protocol states and complex interaction scenarios. Each protocol state or interaction is generated by an independent test path or model, and multiple test paths can be executed simultaneously. It is suitable for complex protocols or high coverage requirements, and can significantly improve the comprehensiveness of testing and vulnerability discovery capabilities. Therefore, different fuzzing methods are suitable for different testing scenarios and needs, and the rational selection and optimization of testing methods are crucial for building an efficient security testing system. Summary of the Invention
[0003] (a) Technical problems to be solved The technical problem this invention aims to solve is how to provide an effective architectural design method for detecting typical concurrency problems on the server side, so as to solve the problems of insufficient scenario coverage and low vulnerability trigger rate in server concurrency testing.
[0004] (II) Technical Solution To address the aforementioned technical problems, this invention proposes an architecture design method for effectively detecting typical concurrency issues on the server side. This method includes the following steps: S1. Configure multiple types of concurrent connections: Establish at least two network connections of different protocol types, including TCP connections and UDP connections, and support concurrent sending of data packets; S2. Generate test cases: Define the identifier for each connection and the corresponding data packet sequence to ensure that each data packet belongs to a specific connection; S3. Send cross-connection data packets in a preset order: Based on the cross-connection data packet order defined in the test case, strictly send data packets to the server in the order they are sent. S4. Use Case Variation: Variation of data packet content, including adjusting data packet size, format or content, and sequence variation, i.e., random or regular adjustment of the order in which data packets are sent between different connections. S5. Detect concurrency issues: Monitor the server's response when processing mutated data packets, and record resource contention, deadlock, state machine anomalies, or protocol parsing vulnerabilities.
[0005] (III) Beneficial Effects This invention proposes an architecture design method for effectively detecting typical concurrency problems on the server side. The present invention has significant advantages over the prior art: 1) By forcing each protocol state to be in an interleaved or abnormal state, the high probability of triggering protocol vulnerabilities is ensured, thereby improving the detectability of the problem.
[0006] 2) Supports multiple protocol types and field combinations to ensure the diversity and realism of testing, and is closer to the actual protocol implementation environment.
[0007] 3) Not only are the protocol data packets themselves mutated, but the order of data packets in different protocol states or interactions is also mutated, further expanding the scope of testing and uncovering more potential vulnerabilities. Attached Figure Description
[0008] Figure 1 This is a block diagram illustrating the architecture design for effectively detecting typical concurrency issues on the server side in this invention. Detailed Implementation
[0009] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.
[0010] This invention addresses the issues of insufficient scenario coverage and low vulnerability trigger rate in server-side concurrent testing by proposing a test architecture that coordinates multi-protocol concurrent connections and cross-connection data packet order mutation. Through forced protocol state anomalies and systematic mutation strategies, it improves the detection efficiency of concurrency defects such as resource contention and deadlock.
[0011] This invention relates to a server-side concurrency problem detection architecture, belonging to the field of protocol fuzz testing and deadlock detection technology. Addressing the problems of insufficient coverage and low testing efficiency in existing concurrency scenarios, this invention proposes a testing architecture based on multi-connection concurrency and data packet order mutation. This includes supporting concurrent data packet sending across multiple TCP / UDP connection types; explicitly identifying the data packet affiliation of each connection in test cases; sending cross-connection data packets in a preset order to verify system processing capabilities; and synchronously mutating data content and cross-connection order during test case mutation to cover concurrency anomaly scenarios. By forcing protocol state anomalies and employing a systematic mutation strategy, the probability of vulnerability triggering is increased, overcoming the shortcomings of traditional methods in covering complex interactions. This enhances testing diversity and realism, supporting multi-protocol combinations; and expands coverage through order mutation, effectively detecting resource contention, deadlock, and state anomalies, improving system robustness and anti-attack capabilities. In the test case mutation stage, in addition to content mutation of the data packets themselves, this invention also mutates the order of data packets in different connections. Order mutation refers to randomly or regularly adjusting the order of data packet transmission between different connections to simulate timing disturbances in concurrent scenarios. Specifically, in the use case mutation phase, the content of the data packets can be mutated, such as changing the size, content, or format of the data packets, to test the system's robustness when processing different data packets. At the same time, through sequence mutation (such as adjusting the sending timing of cross-connection data packets, swapping the order of data packets between different connections, etc.), the system's performance when processing data packets in different orders can be tested, and potential concurrency issues can be discovered.
[0012] This invention proposes an effective architecture design method for detecting typical concurrency problems on the server side, as shown in the appendix. Figure 1 As shown. Specifically, the method includes the following points: 1. Allowing data packets to be sent from multiple connections, including different types of connections, such as concurrent TCP and UDP; 2. Test cases include data packets sent from different connections, each belonging to a specific connection; 3. The data packets in the test cases are ordered, meaning that there is a sequential relationship between data packets across different connections, and this relationship is strictly followed during actual testing; 4. In the test case mutation phase, in addition to mutating the data packets themselves, the order of data packets in different connections is also mutated. This ensures that the test covers various concurrency scenarios and uncovers potential concurrency issues.
[0013] 1) Allow data packets to be sent from multiple connections, including different types of connections such as concurrent TCP and UDP. The system should support multiple types of network connections, including TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). TCP is a connection-oriented, reliable protocol suitable for scenarios requiring guaranteed in-order, lossless data packet transmission; UDP is a connectionless, best-effort protocol suitable for scenarios with high transmission speed requirements and tolerating a certain degree of data packet loss. Simultaneously, the system needs to be able to process data packets from multiple connections simultaneously. Each connection can independently send multiple data packets, and the system needs to be able to effectively manage and schedule these packets, ensuring they are processed in the correct order.
[0014] 2) Test cases contain data packets originating from different connections, each packet belonging to a specific connection. Specifically, each test case simulates multiple connections, each of which can be of different types, such as TCP and UDP connections. Each connection sends a series of data packets, which are explicitly identified in the test case and belong to a specific connection. This ensures that the test covers various connection types and data packet sending scenarios, verifying the correctness and performance of the system when handling multiple concurrent connections. Furthermore, each data packet is explicitly assigned to a specific connection, ensuring that the system can correctly route and process these data packets. For example, a test case might include the following: Connection 1 (TCP connection): Data packet 1: Request A Data packet 2: Request B Connection 2 (UDP connection): Data packet 3: Request C Data packet 4: Request D Connection 3 (TCP connection): Data packet 5: Request E Data packet 6: Request F 3) The data packets in the test cases are ordered; that is, the data packets between different connections have a sequential relationship, and this relationship will be strictly followed during actual testing. The data packets in the test cases need to be sent in a predetermined order. For example, the data packet sending order in the above test cases is: data packet 1, data packet 2, data packet 3, data packet 4, data packet 5, data packet 6. The system needs to ensure that the data packets are sent and processed strictly in this order during actual testing. Furthermore, during the testing process, it is necessary to verify whether the data packets for each connection arrive in the correct order to ensure the system's sequential processing capability.
[0015] 4) In the use case mutation phase, in addition to mutating the data packets themselves, the order of data packets in different connections will also be mutated. Specifically, in the use case mutation phase, the content of the data packets can be mutated, such as changing the size, content, or format of the data packets, to test the robustness of the system when processing different data packets. At the same time, besides mutating the content of the data packets, the order of data packets in different connections can also be mutated. For example, the sending order of data packets 1 and 3 can be swapped, or the sending order of data packets 2 and 4 can be swapped. In this way, the system's performance when processing data packets in different orders can be tested, and potential concurrency issues can be discovered.
[0016] Through the above design, protocol fuzzing can comprehensively cover various abnormal scenarios, ensuring the robustness and security of the system when handling random, abnormal, or illegal data packets. This allows for the discovery and resolution of potential protocol parsing vulnerabilities, state machine errors, or anomaly handling defects, thereby improving the overall security and attack resistance of the system.
[0017] The principle of this invention: A globally ordered cross-connection data stream is constructed based on multi-protocol concurrent connections (TCP / UDP), generating test cases containing session identifiers and timing constraints. By synchronously implementing data content mutations (such as boundary value tampering and noise injection) and cross-connection order perturbations (timing swaps and random rearrangements), protocol compliance and server-side processing logic are disrupted. Memory, thread scheduling, and protocol state machine anomalies are monitored, and the synergistic effect of concurrent timing perturbations and data distortion is leveraged to force the protocol into unexpected state combinations, triggering complex interaction vulnerabilities that are difficult to cover using traditional methods.
[0018] Example 1: Multi-protocol Concurrency Test The system first establishes three concurrent connections (two TCP connections and one UDP connection), each assigned an independent session identifier (e.g., T001, T002, U001). The test cases define the global packet order as follows: after TCP connection 1 sends an HTTP request, TCP connection 2 immediately sends an ACK packet, followed by the UDP connection sending a DNS query packet, and finally TCP connection 1 sends a POST request again. The scheduler strictly controls the packet sending sequence according to this order. In the initial test, the server experienced a 200ms delay due to TCP connection contention for the shared buffer lock, and a UDP session ID conflict triggered an alarm.
[0019] During the mutation phase, the content and order of data packets are adjusted synchronously: the HTTP header of the TCP connection is changed to an invalid value (such as Content-Length: -1), the UDP payload is replaced with all zero bytes and its length is extended; the global order is adjusted so that UDP packets are sent before TCP connection 1. After the mutation, the server triggers a segmentation fault due to the protocol parsing module accessing an invalid memory address, and the reversed TCP connection order causes a thread pool deadlock, resulting in no response for 10 seconds.
[0020] Example 2: Large-scale concurrent stress test Expand to 50 hybrid connections (30 TCP + 20 UDP), generating test cases containing 200 cross-connection packets, sent in an alternating order (TCP→UDP→TCP). The packet order is randomly mutated 1000 times, for example, by inserting UDP interference packets during the TCP handshake phase, or by alternating data transmission between TCP / UDP connections with the same session ID.
[0021] Tests revealed that when TCP SYN packets were preempted by UDP packets, the server's CPU utilization spiked to 100%, causing a denial-of-service attack; the kernel protocol stack packet loss rate exceeded 15% under high-frequency alternating transmission mode; and duplicate session IDs across connections caused memory leaks, with 200MB leaked per hour.
[0022] Through the above implementation, the system can accurately trigger server-side concurrency defects, verifying the effectiveness and robustness of the architecture in real-world scenarios.
[0023] Example 3: An effective architecture design method for detecting typical server-side concurrency issues includes the following steps: S1. Configure multiple types of concurrent connections: Establish at least two network connections of different protocol types, including TCP connections and UDP connections, and support concurrent sending of data packets; S2. Generate test cases: Define the identifier for each connection and the corresponding data packet sequence to ensure that each data packet belongs to a specific connection; S3. Send cross-connection data packets in a preset order: Based on the cross-connection data packet order defined in the test case, strictly send data packets to the server in the order they are sent. S4. Use Case Variation: Variation of data packet content, including adjusting data packet size, format or content, and sequence variation, i.e., random or regular adjustment of the order in which data packets are sent between different connections. S5. Detect concurrency issues: Monitor the server's response when processing mutated data packets, and record resource contention, deadlock, state machine anomalies, or protocol parsing vulnerabilities.
[0024] In step S1, the TCP connection is a connection-oriented reliable transport protocol that supports in-order transmission; the UDP connection is a connectionless best-effort transport protocol that supports high-throughput data transmission; the system needs to manage multiple TCP and UDP connections simultaneously and assign an independent session identifier to each connection.
[0025] In step S2, the test case includes the following structure: Each connection corresponds to a unique identifier; The packet sequence for each connection is arranged in order, and the order of packets across connections is defined globally; The data packet content includes protocol fields, payload data, and verification information.
[0026] In step S3, the sending order of cross-connection data packets is implemented by a scheduling algorithm. The scheduling algorithm controls the sending sequence of data packets of different connections according to the global order defined by the test cases, ensuring that the data packets arrive at the server in a preset order.
[0027] In step S4, the data packet content mutation includes at least one of the following operations: Modify the data packet length, ranging from 64 bytes to 1500 bytes; Replace the protocol field value with an illegal or boundary value; Insert random noise data; The sequence mutation includes at least one of the following operations: Swap the sending order of adjacent data packets in different connections; Randomly adjust the global order of packets across connections; Repeatedly send the same data packet to simulate a retransmission scenario.
[0028] In step S5, concurrency issues are detected in the following way: Monitor server-side memory usage and identify memory out-of-bounds errors; Analyze thread scheduling logs to detect resource contention or deadlocks; Verify whether the protocol state machine transitions are as expected, and identify abnormal transitions; Record session ID conflicts or packet processing timeout events.
[0029] The present invention has significant advantages over the prior art: 1) By forcing each protocol state to be in an interleaved or abnormal state, the high probability of triggering protocol vulnerabilities is ensured, thereby improving the detectability of the problem.
[0030] 2) Supports multiple protocol types and field combinations to ensure the diversity and realism of testing, and is closer to the actual protocol implementation environment.
[0031] 3) Not only are the protocol data packets themselves mutated, but the order of data packets in different protocol states or interactions is also mutated, further expanding the scope of testing and uncovering more potential vulnerabilities.
[0032] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.
Claims
1. An effective architectural design method for detecting typical concurrency problems on the server side, characterized in that, The method includes the following steps: S1. Configure multiple types of concurrent connections: Establish at least two network connections of different protocol types, including TCP connections and UDP connections, and support concurrent sending of data packets; S2. Generate test cases: Define the identifier for each connection and the corresponding data packet sequence to ensure that each data packet belongs to a specific connection; S3. Send cross-connection data packets in a preset order: Based on the cross-connection data packet order defined in the test case, strictly send data packets to the server in the order they are sent. S4. Use Case Variation: Variation of data packet content, including adjusting data packet size, format or content, and sequence variation, i.e., random or regular adjustment of the order in which data packets are sent between different connections. S5. Detect concurrency issues: Monitor the server's response when processing mutated data packets, and record resource contention, deadlock, state machine anomalies, or protocol parsing vulnerabilities.
2. The architecture design method for effectively detecting typical concurrency problems on the server side as described in claim 1, characterized in that, In step S1, the system processes data packets from multiple connections simultaneously. Each connection sends multiple data packets independently, and the system can effectively manage and schedule these data packets.
3. The architecture design method for effectively detecting typical concurrency problems on the server side as described in claim 1, characterized in that, In step S2, each test case simulates multiple connections, each of different types. Each connection sends a series of data packets, which are explicitly identified in the test case and belong to a specific connection. This ensures that the test covers various connection types and data packet sending scenarios, verifying the correctness and performance of the system when handling multiple concurrent connections. Furthermore, each data packet is explicitly assigned to a specific connection, ensuring that the system can correctly route and process these data packets.
4. The architecture design method for effectively detecting typical concurrency problems on the server side as described in claim 3, characterized in that, In step S2, the test case includes the following structure: Each connection corresponds to a unique identifier; The packet sequence for each connection is arranged in order, and the order of packets across connections is defined globally; The data packet content includes protocol fields, payload data, and verification information.
5. The architecture design method for effectively detecting typical concurrency problems on the server side as described in claim 1, characterized in that, In step S3, during the testing process, it is necessary to verify whether the data packets of each connection arrive in the correct order to ensure the sequential processing capability of the system.
6. The architecture design method for effectively detecting typical concurrency problems on the server side as described in claim 4, characterized in that, In step S3, the sending order of cross-connection data packets is implemented by a scheduling algorithm. The scheduling algorithm controls the sending sequence of data packets of different connections according to the global order defined by the test cases, ensuring that the data packets arrive at the server in a preset order.
7. The architecture design method for effectively detecting typical concurrency problems on the server side as described in claim 1, characterized in that, In step S4, during the use case variation stage, the content of the data packet is varied to change the size, content, or format of the data packet in order to test the robustness of the system when processing different data packets.
8. The architecture design method for effectively detecting typical concurrency problems on the server side as described in claim 7, characterized in that, In step S4, during the use case mutation phase, the order of data packets in different connections is mutated. In this way, the system's performance in processing data packets in different orders is tested, and potential concurrency issues are discovered.
9. The architecture design method for effectively detecting typical concurrency problems on the server side as described in claim 8, characterized in that, In step S4, the data packet content mutation includes at least one of the following operations: Modify the data packet length, ranging from 64 bytes to 1500 bytes; Replace the protocol field value with an illegal or boundary value; Insert random noise data; The sequence mutation includes at least one of the following operations: Swap the sending order of adjacent data packets in different connections; Randomly adjust the global order of packets across connections; Repeatedly send the same data packet to simulate a retransmission scenario.
10. The architecture design method for effectively detecting typical concurrency problems on the server side as described in claim 9, characterized in that, In step S5, concurrency issues are detected in the following way: Monitor server-side memory usage and identify memory out-of-bounds errors; Analyze thread scheduling logs to detect resource contention or deadlocks; Verify whether the protocol state machine transitions are as expected, and identify abnormal transitions; Record session ID conflicts or packet processing timeout events.