A network abnormal traffic monitoring method for electronic examination

Abstract

The application relates to the technical field of communication network security monitoring, and discloses a network abnormal flow monitoring method for electronic examination, which comprises the following steps: according to the TCP first request window and the actual release completion deadline, the connection request rate, the handshake completion rate and the bidirectional response rate are counted, and the DDoS attack is confirmed according to the same period queue occupation and the response time delay; the established connection with the sustained bidirectional response is regulated and protected by executing the bounded proportional integral; when the actual release is reduced and the service feedback is continuously deteriorated, the integral is frozen, the service capacity is retested, the target value is corrected, the admission is tightened when the capacity is insufficient; after the attack evidence disappears, the release rate of the newly-built connection is gradually recovered according to the admission budget of the deducted to-be-queued connection and the established connection re-queued reserved amount. The technical scheme of the application realizes the continuous verification of the protocol observation, the service feedback and the admission execution, and reduces the judgment and control deviation in the centralized access and the flow recovery process.

Description

Technical Field

[0001] This application relates to the field of communication network security monitoring technology, specifically to a method for monitoring abnormal network traffic during electronic examinations. Background Technology

[0002] In existing technologies, abnormal traffic monitoring of electronic examination service networks typically relies on traffic thresholds, connection status statistics, and ingress rate limiting mechanisms. These mechanisms identify short-term access pressure and trigger traffic restrictions to meet the need to maintain network service availability during DDoS (Distributed Denial of Service) attacks. However, existing abnormal traffic monitoring methods for electronic examination networks have some significant shortcomings when legitimate concentrated access and attack traffic coexist.

[0003] Electronic examinations often see a surge in legitimate clients establishing connections simultaneously during peak periods such as unified login, resource loading, and centralized submission. This rapid increase in connection requests simultaneously intensifies server processing pressure. Similarly, DDoS attacks can cause sudden connection pressure, protocol disruptions, and slower service responses. Current technologies, which use ingress traffic or single connection status as primary triggers, compress the judgment boundary due to the similarity in access scale between legitimate high concurrency and malicious requests. When rate limiting uses fixed thresholds or continuously tightens based solely on preset states, the discrepancy between service capacity changes, actual rate limiting results, and queue backlogs continues to propagate to subsequent control mechanisms. This leads to excessive restrictions on established connections and new service pressure fluctuations during connection recovery after an attack subsides.

[0004] Therefore, existing technologies often suffer from problems such as the vulnerability of DDoS attack confirmation boundaries to legitimate traffic peaks under high-concurrency access during electronic examinations, and insufficient coordination between attack handling and changes in service resource status, which affects normal connection and continuous communication. These are the shortcomings of existing technologies.

[0005] In view of this, it is necessary to provide a method for monitoring abnormal network traffic in electronic examinations to address the aforementioned deficiencies in the existing technology. Summary of the Invention

[0006] The purpose of this application is to address the shortcomings of existing technologies, such as the susceptibility of DDoS attack confirmation boundaries to legitimate traffic peaks under high-concurrency access in electronic examinations, and the insufficient connection between attack handling and changes in service resource status, which affects normal connection and continuous communication. This application provides a method for monitoring abnormal network traffic in electronic examinations to solve the aforementioned technical problems.

[0007] To achieve the above objectives, this application provides the following technical solution: This application provides a method for monitoring abnormal network traffic during electronic examinations, including: Step S1: Collect network traffic for the electronic examination, calculate the connection request rate according to the window to which the TCP first request belongs, set a completion deadline from the actual release date, use the ratio of the number of handshake-completed connections within the completion deadline to the actual number of released requests as the handshake completion rate, and use the matching ratio of server response and client return in the already handshake-connected connections as the bidirectional response rate. Step S2: Collect the number of concurrent connections in the queue as queue occupancy, and use the average of the completed service duration and the uncompleted service waiting duration as the response latency. When the connection request rate exceeds the limit, the handshake completion rate or the bidirectional response rate is insufficient, and the queue occupancy and response latency continue to exceed the limit, a DDoS attack is confirmed. Step S3: Subtract the actual value from the positive target value of queue occupancy and response delay, divide by the corresponding target value, take the minimum value for bounded proportional integral adjustment, reduce the new connection release rate, protect the established connections with continuous bidirectional response, and count the actual release volume. Step S4: When the actual number of connections released decreases while the queue occupancy and response latency continue to increase, freeze the points and maintain the rate of new connection release, retest the service capacity and correct the target value. If the capacity is insufficient, reduce the new connection release rate by deducting the admission budget based on the queue exceeding the target amount. Step S5: Unfreeze when queue occupancy and response latency are not higher than their respective target values. After verifying that the evidence of the DDoS attack has disappeared, gradually restore the new connection release rate according to the acceptance budget after deducting the re-entry reserve of established connections. Update the network abnormal traffic monitoring results of the electronic examination.

[0008] By incorporating connection pressure, protocol interaction progress, service resource load, and actual allowed throughput into the continuous monitoring and control chain of the electronic examination network, the system achieves closed-loop status closure for DDoS attack confirmation, new connection allowance adjustment, established connection protection, anomaly control suppression, and attack regression recovery. This reduces confirmation bias caused by traffic peaks alone when legitimate concentrated access and attack traffic have similar burst characteristics. Furthermore, the new connection allowance rate is constrained and adjusted according to continuous changes in queue occupancy, response latency, and actual allowed throughput. This meets the requirements of clear DDoS attack confirmation boundaries, continuous connection between attack handling and service resource status, and maintenance of normal connection and continuous communication under high-concurrency access in electronic examinations.

[0009] Specifically, connection request rate, handshake completion rate, and bidirectional response rate respectively characterize access pressure, connection establishment progress, and continuous communication progress. This ensures that a surge in legitimate concentrated access traffic is no longer directly equivalent to protocol failure and provides input for subsequent server-side verification of protocol status. After queue occupancy and response latency are confirmed as part of an attack, protocol progress obstruction only enters a DDoS attack state when it occurs simultaneously with continuous pressure on service resources. This establishes a correspondence between entry point anomalies and server load consequences, tightens the attack confirmation boundary, and transforms the protocol status of the previous stage into a control basis. Bounded proportional-integral adjustment is implemented around the deviations of queue occupancy and response latency from their respective target values, while protecting established connections with continuous bidirectional responses. This causes the rate of new connection release to be bounded down with resource pressure, prioritizing processing capacity for... Effective communication connections are established, and the actual allowed throughput serves as the input for subsequent control verification. When the actual allowed throughput decreases while queue occupancy and response latency continue to increase, the accumulated integral is frozen and the service capacity is retested. This allows for a direct comparison between the executed rate-limiting actions and the deteriorated service status, preventing excessive tightening caused by the continuous accumulation of control errors. Furthermore, by correcting their respective target values, control boundaries consistent with the current service capacity are rebuilt. Once queue occupancy and response latency fall back to their respective target value ranges, the integral freeze is lifted, and the DDoS attack is reviewed. This ensures that the recovery action is simultaneously constrained by resource status and attack evidence. After the attack evidence disappears, the rate of new connection release is gradually restored to avoid a sudden backflow of connection pressure. The new network status continues to be fed back to the network abnormal traffic monitoring results of the electronic examination, forming a complete closed loop from confirmation, handling, to recovery.

[0010] Preferably, step S1 specifically includes: Divide the window into equal-length windows based on the arrival time of the first TCP request, identify the first request according to the connection 5-tuple and the initial sequence number, merge and count retransmission requests of the same connection, and calculate the connection request rate based on the ratio of the number of first requests to the window length. The initial request is matched with the entry release record. For the actual release request, a completion deadline covering the handshake and bidirectional response matching is set from the release time. Connections that complete the handshake within the completion deadline are counted in the window to which the initial request belongs. The handshake completion rate is calculated as the ratio of the number of handshake-completed connections to the number of actual release requests. Match the client acknowledgment number or subsequent application message according to the sequence number range of the server response. Deduplicate the connections that are matched within the completion period by the connection 5-tuple and the initial sequence number and include them in the window to which the first request belongs. Divide the number of deduplicated connections by the number of handshake-completed connections to obtain the bidirectional response rate. After all completion periods are over, fix the statistical results. When the denominator is zero, output the corresponding proportion of missing test status.

[0011] By adopting the above technical solution, the statistical attribution is based on the window to which the first TCP (Transmission Control Protocol) request belongs. The retransmission request is merged, the actual release record is matched, the completion deadline and the bidirectional message matching are integrated into the formation of the connection request rate, handshake completion rate and bidirectional response rate. This ensures that the same connection will not be repeatedly amplified due to repeated transmissions. Each ratio also corresponds to the actual release and protocol progress facts, thereby providing input with consistent time boundaries and identifiable missing test states for subsequent DDoS attack confirmation, and reducing the interference of statistical caliber changes on the judgment of continuous windows.

[0012] Preferably, step S2 specifically includes: The upper limit of connection request rate, handshake completion rate and lower limit of bidirectional response rate are determined based on the window where the deadline has expired in the normal examination network traffic, and the upper limit of queue occupancy and response latency are determined based on service feedback. Collect the number of connections in the queue, and average the completed service duration of completed service connections within the window with the incomplete service waiting time of the queued connections at the comparison point as the response latency. Align the window to which the first request belongs according to the sampling time, and reset the number of consecutive windows for windows with missing handshake completion rate and bidirectional response rate or interrupted service feedback. Compare the fixed statistical results with the upper and lower limits, and only for windows where the connection request rate exceeds the limit and at least one of the handshake completion rate and bidirectional response rate is insufficient, accumulate the number of consecutive windows where both queue occupancy and response latency exceed the limit; Compare the number of consecutive windows with the confirmation length. The confirmation length is the maximum number of consecutive windows exceeding the limit for normal network traffic plus 1. When the confirmation length is reached, a DDoS attack is confirmed. If the cumulative condition is not met, the number of consecutive windows is reset.

[0013] Based on the above scheme, the upper limit of connection request rate, the lower limit of handshake completion rate, the lower limit of bidirectional response rate, and the upper limit of queue occupation and response latency are used for continuous window determination. When both handshake completion rate and bidirectional response rate are missing or service feedback is interrupted, the continuous window number is reset so that incomplete observations will not accumulate as attack evidence. At the same time, the confirmation length is determined based on normal network traffic, so that DDoS attack confirmation exceeds the normal fluctuation duration range. In this way, the obstruction of protocol progress, the exceeding of queue occupation and response latency limits, and the duration are jointly constrained by the attack entry state, reducing the chance of legitimate concentrated access or short-term service jitter triggering the attack state, and providing the starting boundary for continuous evidence of the new connection release rate adjustment.

[0014] As a preferred approach, the steps of comparing the number of consecutive windows with the confirmation length, where the confirmation length is the maximum number of consecutive windows exceeding the limit for normal exam network traffic plus 1, and confirming a DDoS attack when the confirmation length is reached, and resetting the number of consecutive windows when the cumulative condition is not met, specifically include: For windows that meet the cumulative conditions, generate handshake anomaly flags and response anomaly flags based on insufficient handshake completion rate and normal handshake completion rate but insufficient bidirectional response rate, respectively, and record one anomaly flag for each window; When adjacent windows have handshake error flags and response error flags respectively, check that the connection request rate, queue usage and response latency of both windows exceed the limits, and count the adjacent windows into the same consecutive window count. For windows where the number of handshake-completed connections is zero but the number of actual allowed requests is not zero, a handshake error flag is generated based on the handshake completion rate. For windows where the number of actual allowed requests is zero or the service feedback is interrupted, the number of consecutive windows is reset. When the number of consecutive windows is not less than the confirmation length, the DDoS attack is confirmed. The number of consecutive windows is reset for windows where the connection request rate does not exceed the limit, the handshake completion rate and the bidirectional response rate all meet the standards, or the queue occupancy and response latency are not at least one of the limits. The count starts again from the next window that meets the accumulation conditions.

[0015] In the above scheme, a handshake anomaly flag or response anomaly flag is retained for each window. When adjacent windows continuously meet the conditions of connection request rate, queue occupancy and response latency, different anomaly flags are counted into the same continuous window segment. This ensures that the attack evidence remains continuous when the location of protocol obstruction changes during a DDoS attack. At the same time, the count is reset for windows with zero actual allowed requests, service feedback interruption, or judgment conditions being lifted. This avoids the bridging of no effective observation intervals and enhances the integrity and verifiability of attack segment boundaries.

[0016] Preferably, step S3 specifically includes: The minimum value of the ratio between queue occupancy and response delay is used as the control error. The difference between adjacent control errors is multiplied by the proportional gain to calculate the proportional increment. The current control error, the duration of the control cycle, and the integral gain are multiplied to calculate the integral increment. This is then added to the last newly established connection release rate and truncated according to the execution range. The observation period is determined based on the network interaction interval of the normal examination client. The established connection is verified by the server response and client feedback within the observation period. The established connection with the completed bidirectional response is forwarded, and the protection of the established connection that has exceeded the observation period and lacks bidirectional response is cancelled. During the duration of a DDoS attack, the minimum value between the truncation result and the current new connection release rate is used to update the new connection release rate. The incremental integral that continues to accumulate downward after reaching the lower limit is frozen. The actual release volume within the complete control cycle is calculated based on the difference in entry release count.

[0017] Based on the above processing, the bounded proportional integral adjustment is constrained by the minimum value of the ratio between queue occupancy and response latency. This ensures that the rate of new connection release follows the stricter control boundary between the two types of service pressure, preventing premature relaxation of the entry point before a single state has recovered. At the same time, the bidirectional response status of established connections is reviewed based on the observation period, reserving forwarding capacity for valid communication connections. During the duration of a DDoS attack, the rate of new connection release is restricted to either remain constant or decrease. Combined with the freezing of the integral lower limit and the statistics of actual release volume, the control calculation is linked with the entry point execution results, thereby suppressing excessive rate limiting caused by the continuous accumulation of integrals and providing an execution basis for subsequent service status verification.

[0018] As a preferred approach, the observation period is determined based on the network interaction intervals of normal examination clients. Within the observation period, the established connection is verified by server responses and client feedback. Established connections with completed bidirectional responses are forwarded, and the protection of established connections that have exceeded the observation period and lack bidirectional responses is cancelled. Specifically, this includes: The observation period is calibrated based on the network interaction interval formed by the normal examination client resource loading, automatic saving and submission. The observation period is set to be less than the connection idle timeout. The time when each established connection most recently completed a bidirectional response is recorded as the most recent completion time. The difference between the observation period and the time from the most recent completion time is truncated non-negatively to obtain the remaining observation period. The client's response is checked against the range of unconfirmed sequence numbers in the server's response. The client's confirmation number is verified to be no more than the next sequence number sent by the server. When the client's confirmation number covers the range of unconfirmed sequence numbers, the most recent completion time is updated and forwarding continues. For established connections that only require repeated confirmation of existing sequence numbers, retain the most recent completion time and perform protection verification according to the remaining observation period; When the remaining observation period reaches zero and no new bidirectional response is found, the established connection protection is cancelled and the connection is released according to the connection idle timeout. Other established connections that have completed bidirectional responses under the same egress address are maintained and forwarded.

[0019] Based on the above processing logic, the observation period is determined by the network interaction interval of the normal examination client, and the bidirectional response of the established connection is verified by the most recent completion time. The protection qualification is updated with the communication activity. The duplicate confirmation false progress is excluded by verifying the range of server response sequence number and client confirmation number. When the remaining observation period reaches zero and there is no new bidirectional response, the protection of the established connection is cancelled. Other established connections that have completed bidirectional responses under the same egress address are maintained and forwarded, thus tightening the protection boundary and reducing the service resources occupied by attack connections.

[0020] Preferably, step S4 specifically includes: Using a preset equal-length time period as the control cycle, obtain entry execution confirmation, divide the complete control cycle before and after the effective time according to the actual execution time, and compare the actual release volume with the concurrent queue occupancy and response latency. When the actual number of connections released decreases and the queue occupancy and response latency increase continuously, the release rate of the most recently confirmed new connection is locked, and the points status is frozen. The service capacity was retested based on the number of healthy instances that could accept exam requests and return valid queue feedback, and the connection queue capacity was adjusted according to the service completion rate. If the service completion rate for two consecutive valid retest cycles, after deducting the rate corresponding to the re-entry retention of established connections, is not higher than the locked new connection release rate, the amount of service completions leaving the queue, the amount of waiting to be enqueued, the amount of re-entry retention of established connections, and the amount of queue exceeding the target are deducted from the amount of service completions leaving the queue. A non-negative truncation is then performed and divided by the control cycle. The new connection release rate is then reduced, and the points are kept frozen until the end of the complete control cycle after the new target takes effect.

[0021] Using the above technical solution, the actual execution time of the confirmation record of the new connection release rate is used as the time benchmark. Within the complete control cycle, the actual release volume, queue occupancy, and response latency are compared to provide a verifiable basis for whether the entry control is effective. When the actual release volume decreases while the queue occupancy and response latency continue to increase, the confirmed new connection release rate is locked and the integral status is frozen. This can prevent the bounded proportional integral adjustment from accumulating when service capacity changes or control mismatch occurs. At the same time, the service capacity is retested and the respective target values ​​are corrected based on the number of healthy instances, connection queue capacity, and service completion rate, so that the subsequent control boundary corresponds to the service bearing conditions again, providing an observation basis for lifting the integral freeze.

[0022] Preferably, the service capacity is retested based on the number of healthy instances capable of accepting exam requests and returning valid queue feedback, and the connection queue capacity is adjusted accordingly. The steps for correcting their respective target values ​​based on the service completion rate include: Verify the number of healthy instances, retain queued connections until service completion or exit, count the number of queued connections in the same control period, count the number of connections that leave the queue after service completion as the service completion dequeue quantity, and count other exits as the release quantity; Add the queue occupancy at the start of the cycle to the number of enqueued connections, and subtract the number of services completed and released to obtain the estimated queue occupancy at the end of the cycle. Then calculate the absolute value of the difference between this estimated value and the directly sampled value. Determine the tolerance based on the normal sampling error. During the complete control period when the queue occupancy is continuously non-zero and the absolute value of the difference is not greater than the tolerance, retest the service completion rate by dividing the service completion dequeue amount by the control period, and summarize the connection queue capacity of each healthy instance. When both the service completion rate and connection queue capacity are positive, the response latency target value is corrected by the upper limit of the average time from enqueuing to service completion of a normal test connection. The minimum value of the product of the service completion rate and the response latency target value and the connection queue capacity is used to correct the queue occupancy target value. Otherwise, if the absolute value of the difference exceeds the tolerance, the original target value is used.

[0023] In the above scheme, queue conservation is checked by using enqueued connections, service completion dequeue amount, release amount, and queue occupancy at the end of the cycle. This ensures that the service completion rate is only included in the service capacity retest when the absolute value of the difference between the estimated queue occupancy and the queue occupancy is within the tolerance. The service completion rate, connection queue capacity, and the upper limit of the average duration of normal test connections are used to correct the target values ​​of response latency and queue occupancy, so that their respective target values ​​correspond to the service processing capacity, avoiding the transmission of erroneous capacity judgments in abnormal cycles to recovery control.

[0024] Preferably, step S5 specifically includes: During the full control period after the new target takes effect, the integration freeze is lifted when both queue occupancy and response latency are not higher than their respective target values, and the output starting point is reset at the current new connection release rate. If the connection request rate does not exceed the limit after the deadline, or if the connection request rate exceeds the limit but the handshake completion rate and bidirectional response rate are both valid and meet the standards, the cumulative number of consecutive windows in which the attack evidence disappears will be reset; otherwise, the exit length will be the rounded-up value of the longest interaction interval of the normal examination network traffic divided by the window duration, and it will be at least 1. When the number of consecutive windows reaches the exit length, the queue occupancy is reduced by the minimum value of the connection queue capacity and the queue occupancy target value, and the remaining queue capacity is obtained by non-negative truncation. The cycle-by-cycle increment of the new connection release rate is calculated based on the remaining queue capacity and the service completion rate. The new connection release rate is updated incrementally on a cycle-by-cycle basis. The actual release volume and service feedback are reviewed. When attack evidence reappears, the recovery is stopped and a bounded proportional integral adjustment is performed, and the monitoring results are updated.

[0025] Based on the above scheme, the points freeze is lifted after the queue occupancy and response latency return to their respective target values. The disappearance of attack evidence is continuously verified by connection request rate, handshake completion rate and bidirectional response rate. At the same time, the exit length is constrained according to the longest interaction interval of normal examination network traffic to avoid DDoS attack exit triggered by short-term improvement in status. During the period of restoring the new connection release rate, the actual release volume and service feedback are used for verification. The recovery stops when the attack evidence reappears, thus forming a reversible exit and recovery closed loop.

[0026] Preferably, when the number of consecutive windows reaches the exit length, the remaining queue capacity is obtained by subtracting the queue occupancy from the minimum value of the connection queue capacity and the target value of queue occupancy, and then performing a non-negative truncation. The step of calculating the cycle-by-cycle increment of the new connection release rate based on the remaining queue capacity and the service completion rate specifically includes: The established connection re-enqueue reserve is the maximum number of established connections re-enqueued in the most recent 3 consecutive valid complete control cycles. The service completion rate is multiplied by the control cycle, the remaining queue capacity is added, the number of connections that have been actually released but not yet enqueued and the established connection re-enqueue reserve are deducted, and after non-negative truncation, the result is divided by the control cycle to obtain the upper limit of the admission rate. The slope increment is obtained by dividing the difference between the response delay target value and the response delay by the response delay target value, performing non-negative truncation, and then multiplying by the preset recovery slope and control period. The difference between the upper limit of the acceptance rate and the current new connection release rate is truncated to a non-negative value, and the minimum value of the difference and the slope increment is taken as the cycle-by-cycle increment. When the upper limit of the acceptance rate is lower, the new connection release rate is reduced according to the upper limit. If the completion deadline statistics or service feedback for the previous release are not obtained, the increment will be reset to zero on a cycle-by-cycle basis. The number of healthy instances, their identities, or the capacity of the connection queue will also be reset to zero when they change. The service capacity will be recalculated after the service capacity retest of the new complete control cycle is effective.

[0027] Based on the above processing, the upper limit of the admission rate is limited by the remaining capacity of the queue and the service completion rate, and the slope increment is limited by the response latency recovery degree. The smaller increment of the two types of constraints is used to update the new connection release rate, so that the entry recovery is controlled by the capacity margin and the response recovery speed. When the statistical results are not closed or the number of healthy instances or the connection queue capacity changes, the increment will be set to zero every cycle. The calculation will be performed after the service capacity retest results are formed, so as to avoid the old service state driving the recovery and reduce the risk of the recovery being too fast and pushing up the queue pressure again.

[0028] Based on the above technical solution, this application has at least the following technical effects: This application provides a method for monitoring abnormal network traffic in electronic examinations. By incorporating connection pressure, protocol interaction progress, service resource load, and actual allowed traffic into the continuous monitoring and control chain of the electronic examination network, it achieves a closed-loop state for DDoS attack confirmation, new connection allowance adjustment, established connection protection, control anomaly suppression, and attack regression recovery. This reduces the confirmation offset caused by traffic peaks alone when legitimate concentrated access and attack traffic have similar burst characteristics. It also constrains and adjusts the new connection allowance rate according to continuous changes in queue occupancy, response latency, and actual allowed traffic, meeting the needs of clear DDoS attack confirmation boundaries, continuous connection between attack handling and service resource status, and maintenance of normal connection continuous communication under high-concurrency access in electronic examinations. Attached Figure Description

[0029] To facilitate the explanation of the technical solutions of the embodiments of this application, the accompanying drawings used in this application will be briefly described below.

[0030] Figure 1 This is a flowchart of a network abnormal traffic monitoring method for electronic examinations provided in this application. Detailed Implementation

[0031] The embodiments of this application will now be described with reference to the accompanying drawings. It should be understood that the following embodiments are only used to illustrate the technical solutions of this application and do not limit the scope of protection of this application. Those skilled in the art can make equivalent substitutions or improvements based on the disclosure of this application.

[0032] It should be noted that in the description of this application, the terms "comprising," "including," "having," and their synonyms are used to indicate the presence of the described features, structures, steps, operations, elements, components, or combinations thereof, but do not exclude the presence of other features, structures, steps, operations, elements, components, or combinations thereof.

[0033] It should be noted in advance that, for ease of understanding of the technical solution of this application, the following explanations are provided regarding the terminology and related technologies involved in this application: 1. DDoS Attack: A DDoS attack is a network attack in which a distributed source continuously sends a large number of connections or requests to a target network or service, consuming network, connection queue, or service processing resources and hindering normal client communication. This embodiment uses TCP connections and their service feedback as the observation object. A continuous window that meets the joint conditions and reaches the acknowledgment length is set to the DDoS attack handling state, and the protocol and service evidence of this state is recorded and updated through subsequent review.

[0034] 2. Connection 5-tuple: A combination of 5 protocol fields used to identify a network connection or network flow. It is usually composed of source address, destination address, source port, destination port and transport layer protocol. It can be used to distinguish connections and associate messages belonging to the same connection.

[0035] 3. Bounded proportional-integral control: A control method that applies boundary constraints to the control output or integral accumulation based on proportional-integral feedback control. The proportional action responds to the current deviation change, the integral action reflects the continuous accumulation of the deviation, and the boundary constraint is used to prevent the control quantity from continuously expanding into the unexecutable range under long-term deviation.

[0036] To address the issues of DDoS attack confirmation boundaries being easily affected by legitimate traffic peaks under high-concurrency access in electronic examinations, and insufficient coordination between attack handling and changes in service resource status affecting normal connection and continuous communication, existing monitoring and rate limiting methods are prone to judgment and control deviations, making it difficult to meet the actual needs of attack identification, effective communication maintenance, and smooth recovery. This application discloses a network abnormal traffic monitoring method for electronic examinations, forming a closed loop around DDoS attack confirmation, adjustment of new connection release rate, and exit recovery. This ensures that legitimate traffic peaks must be accompanied by blocked protocol interaction, queue occupancy, and continuously deteriorating response latency to form attack evidence. Established connections can maintain effective communication during the tightening of the ingress point. When the actual release volume deviates from the service status, the accumulation of points stops. After service resources are restored, the attack evidence constrains the increase in the new connection release rate. This makes attack identification, handling, and recovery actions mutually restrictive, reducing excessive handling caused by legitimate traffic peaks and repeated service pressure during the recovery phase.

[0037] like Figure 1 As shown in the figure, this embodiment provides a method for monitoring abnormal network traffic during electronic examinations, including: Step S1: Collect network traffic for the electronic examination, calculate the connection request rate according to the window to which the TCP first request belongs, set a completion deadline from the actual release date, use the ratio of the number of handshake-completed connections within the completion deadline to the actual number of released requests as the handshake completion rate, and use the matching ratio of server response and client return in the already handshake-connected connections as the bidirectional response rate. Step S2: Collect the number of concurrent connections in the queue as queue occupancy, and use the average of the completed service duration and the uncompleted service waiting duration as the response latency. When the connection request rate exceeds the limit, the handshake completion rate or the bidirectional response rate is insufficient, and the queue occupancy and response latency continue to exceed the limit, a DDoS attack is confirmed. Step S3: Subtract the actual value from the positive target value of queue occupancy and response delay, divide by the corresponding target value, take the minimum value for bounded proportional integral adjustment, reduce the new connection release rate, protect the established connections with continuous bidirectional response, and count the actual release volume. Step S4: When the actual number of connections released decreases while the queue occupancy and response latency continue to increase, freeze the points and maintain the rate of new connection release, retest the service capacity and correct the target value. If the capacity is insufficient, reduce the new connection release rate by deducting the admission budget based on the queue exceeding the target amount. Step S5: Unfreeze when queue occupancy and response latency are not higher than their respective target values. After verifying that the evidence of the DDoS attack has disappeared, gradually restore the new connection release rate according to the acceptance budget after deducting the re-entry reserve of established connections. Update the network abnormal traffic monitoring results of the electronic examination.

[0038] This embodiment uses connection request rate, handshake completion rate, and bidirectional response rate to form continuous protocol observation, making access pressure, connection establishment progress, and continuous bidirectional communication progress identifiable states. This avoids directly inferring attacks from connection request growth alone and uses protocol-side results as input for service resource verification. Queue occupancy and response latency are used together with protocol states for DDoS attack confirmation, ensuring that attack evidence simultaneously reflects access pressure, protocol progress obstruction, and service capacity degradation. This tightens the judgment boundary between legitimate high concurrency and attack traffic and provides state-based evidence corresponding to actual service impact for subsequent network security handling. For confirmed DDoS attacks, bounded proportional integral adjustment is constrained by the deviation of queue occupancy and response latency from their respective target values, while protecting established connections with continuous bidirectional responses. This causes the rate of new connection release to decrease boundedly with resource pressure and propagates the actual release volume backward, achieving controlled separation between entry control actions and effective connection communication. The decrease in actual release volume and the corresponding changes in queue occupancy and response latency are utilized to further refine the process. The continued increase in latency triggers an integral freeze and service capacity retest, blocking the accumulating control effects when service capacity changes or execution results mismatch. Adjustment boundaries adapted to the current service capacity are rebuilt by correcting their respective target values. The integral freeze is lifted after queue occupancy and response latency return to their respective target ranges. DDoS attacks are reviewed based on connection request rate, handshake completion rate, and bidirectional response rate, allowing the rate of new connection release to gradually recover after the attack evidence disappears. This suppresses repeated service status fluctuations caused by sudden surges in connection pressure and continuously updates the network anomaly traffic monitoring results for electronic examinations. Overall, protocol state observation, joint confirmation of service resources, bounded admission adjustment, execution result deviation verification, and attack exit review form a continuous feedback chain. This ensures mutual constraints between legitimate centralized access identification, normal established connection protection, and new connection recovery, helping to maintain effective communication continuity during high-concurrency phases of electronic examinations and reducing the risk of overly tightened attack handling and re-congestion during the recovery phase.

[0039] The above steps will be specifically described below based on the embodiments of this application.

[0040] In step S1, the core task is to correlate the connection establishment requests at the electronic examination network entrance with the actual release results, form the connection request rate, handshake completion rate, and bidirectional response rate within the same initial request window, retain the distinction between statistics that are not yet completed and the proportion of missing tests, and provide network observation results with a definite time attribution to the attack confirmation.

[0041] In this embodiment, network traffic for electronic examinations can be collected. The connection request rate is calculated based on the window to which the initial TCP request belongs. A completion deadline is set from the actual release date. The handshake completion rate is the ratio of the number of handshake-completed connections within the deadline to the actual number of released requests. The bidirectional response rate is the matching ratio of server responses and client responses in the already handshake-connected connections. During this process, the data collection point is set before the new connection release judgment, and records generated by the actual release process at the entry point are received. Packet collection covers both the client sending direction and the server returning direction. TCP packets are filtered according to the address and port of the examination service, and the arrival time, connection 5-tuple, and initial sequence number are assigned to the same connection processing procedure. The connection 5-tuple includes the source address, destination address, source port, destination port, and transport layer protocol. When matching return packets, the addresses and ports at both ends are exchanged to maintain a unified direction from the client to the server. After a new connection is first enqueued, it is removed from the enqueue statistics range. After the same connection completes its service, it is enqueued again to form an independent re-service process. The connection identity and the enqueue process identity are both retained.

[0042] Specifically, when identifying a connection establishment request, the synchronization and acknowledgment flags in the TCP packet are read. Packets with a synchronization flag of 1 and an acknowledgment flag of 0 are used to determine the initial request candidate. Based on the arrival time of the initial TCP request, consecutive equal-length windows are formed. First, the starting point of the first complete window after the start of data collection is determined, and then boundaries are set sequentially according to a fixed window duration. The first request whose arrival time falls at the start of the window is included in the current window, and the first request whose arrival time falls at the end of the window is included in the next window. The portion not covered in full duration during the startup phase is not temporarily included in the formal window. The packet time is given by the ingress acquisition clock, and the window duration remains unchanged during this continuous monitoring period.

[0043] While establishing window ownership, equal-length windows are divided based on the arrival time of the initial TCP request. The initial request is identified by the connection 5-tuple and initial sequence number. Retransmission requests for the same connection are merged and counted. The connection request rate is calculated as the ratio of the initial request count to the window duration. Specifically, the connection 5-tuple and initial sequence number are used as joint search conditions, and existing connection establishment records are checked one by one. When the joint search condition first appears, a connection record is established and the initial request count is incremented. Subsequently, when the same connection establishment request is received, only the most recent reception time is updated, and the initial request count is not incremented. When the client re-establishes a connection using different initial sequence numbers, the count is counted separately; the shared source address does not change the connection differentiation. Connection establishment records are retained across windows during the handshake waiting period. Even if a retransmission request falls into the next window, it continues to be associated with the window to which the initial request belonged. After receiving a connection reset or normal closure event, new progress of the connection is stopped from being received, but the deduplication basis is retained until the corresponding completion deadline and the allowed message lateness time expires. If the same joint search conditions reappear before the old connection state has ended, first check the ingress connection state and the saved handshake progress. Records that cannot be distinguished between retransmission and reconstruction are marked as pending verification. The same message is only associated with the first request. When the acquisition interface reports packet loss or clock reset, the affected window will also show the incomplete observation status.

[0044] Furthermore, the initial request is matched with the ingress release record. A completion deadline, covering handshake and bidirectional response matching, is set for the actual release request from the release time. Connections that complete the handshake within the deadline are counted in the window to which the initial request belongs. The handshake completion rate is calculated as the ratio of the number of handshake-completed connections to the number of actual release requests. The ingress generates a release event at the actual location where the request is judged to be released through a new connection. Candidate initial requests are first found using the connection 5-tuple and initial sequence number. Then, it is checked that the release time is not earlier than the arrival time of the initial request, and that the release event still belongs to the same connection establishment process. Only when a match is successful is the request counted in the actual number of release requests. Requests that the ingress has explicitly rejected only participate in the connection request rate statistics. Duplicate release events read the released status from the same connection record, only filling in missing time information, without repeatedly adding to the denominator.

[0045] In some embodiments of this application, when a brief out-of-order event occurs between the entry release event and the message acquisition event, candidate relationships are saved according to the actual event time, and the records of both parties are supplemented within a limited receiving waiting time. The waiting time is determined based on the maximum normal transmission delay of the two event interfaces, and is not extended after the window is fixed. When two candidate release events point to different connection establishment states, the creation time and initial sequence number in the entry connection table are checked, and the event consistent with the current first request is retained. Requests that still lack entry execution results after the waiting period ends are retained in the pending verification state, and the proportional validity of their respective windows is simultaneously set to unavailable. The completion deadline covers the handshake process after actual release and the matching process between the server response and the client's return message. The deadline endpoint is determined from the actual release time and the pre-set deadline duration. The deadline duration is set according to the upper bound of the completion duration in normal examination client interaction, and also takes into account the allowable deviation of the acquisition clock, and does not roll backward with delays caused by the current attack. For example, if the window duration is 1 second and the completion deadline is 3 seconds, and an initial request arrives 0.2 seconds before the window ends and is actually allowed after 0.1 seconds, the corresponding handshake and two-way response will still be filled back into the window to which the initial request belongs. The end of the window itself does not mean that the statistics of the connection have been completed.

[0046] Furthermore, after the actual release request is associated, connections that have completed the handshake within the completion period are included in the window to which the initial request belonged. The handshake completion rate is calculated as the ratio of the number of handshake-completed connections to the number of actual release requests, and this rate is sequentially matched against client synchronization requests, server synchronization acknowledgments, and client acknowledgments. The server synchronization acknowledgment must be in the sequence position following the client's initial sequence number, and the client acknowledgment also overrides the sequence position occupied by the server synchronization message. This is then checked against the established status of the ingress connection. Connections that only receive server synchronization acknowledgments but not valid client acknowledgments continue to wait. Connections that are not completed by the end of the completion period are retained in the actual release request count but not included in the handshake-completed connection count. The handshake completion time is the actual occurrence time of the last necessary event satisfying the complete handshake relationship; events equal to the end of the completion period are counted as completed within the period. When a connection that has already confirmed a completed handshake receives a duplicate acknowledgment, a retransmission synchronization request, or a duplicate synchronization acknowledgment, the handshake completion count remains unchanged. When a connection proxy is used for the entry point, the proxy-side database stores the mapping between front-end and back-end connections, associates server events, and verifies the creation time and current status of both sides. The initial sequence number of the front-end connection and the initial sequence number of the back-end connection are stored separately; sequence numbers cannot be directly compared across connection segments. Back-end events lacking a mapping are not backfilled to any front-end connection.

[0047] For established handshake connections, the client acknowledgment number or subsequent application message is matched against the sequence number range of the server response. Connections that complete the matching within the completion period are deduplicated by the connection's five-tuple and initial sequence number and included in the window of the first request. The bidirectional response rate is obtained by dividing the number of deduplicated connections by the number of handshake-completed connections. After all completion periods have ended, the statistical results are fixed, and the corresponding proportion of missing data is output when the denominator is zero. First, a response message with a payload is obtained from the server's return direction. The range of consecutive sequence numbers covered by the response message is determined by the starting sequence number and payload length. The client acknowledgment number indicates the next expected sequence position. When the acknowledgment number covers the already sent response range and does not exceed the next sent sequence number of the server, the range is considered to have been acknowledged by the client. When subsequent application messages are used as evidence of return transmission, the connection to which the message belongs and the TCP acknowledgment relationship are also checked to avoid mistaking a request on another connection as a return transmission of the current server response. When the same server response is sent in segments, the observed consecutive ranges are merged according to the sequence position, and overlapping retransmission segments only fill in the parts that have not yet been covered. If the acknowledgment number has not yet covered the end of the sent range, the system will remain inactive. Retransmission of the same sequence range by the server will not constitute a new successful match event. Sequence number wrapping is compared according to the TCP sequence space, using the currently confirmed position of the connection as a reference to determine the order, avoiding the direct exclusion of valid wrapping acknowledgments based solely on unsigned integer size. Acknowledgments that have been proven by the server's connection state to have exceeded the upper limit of transmission are not included in the matching process; in cases where missing data collection results in an incomplete transmission range, the missing data is retained.

[0048] After confirmation, connections that have completed matching within the specified timeframe are deduplicated based on their connection 5-tuple and initial sequence number and added to the window to which the initial request belonged. The bidirectional response rate is calculated as the ratio of the number of deduplicated connections to the number of connections that have completed the handshake. Each handshake-enabled connection is set to a matching completion status only once, and the number of connections with a matching completion status is then counted. When a matched connection continues to generate server responses or client feedback, the number of bidirectional response completion connections in that window is not increased. The denominator of the bidirectional response rate only reads the number of handshake completion connections within the same initial request window; it cannot be replaced by the total number of active connections in the current window. It should be noted that encrypted services still verify the progress of bidirectional communication based on TCP sequence relationships, without needing to read the test questions or answers; transport layer confirmation supports reception judgment, and answer storage still depends on the business processing result. If a client only makes a new request without a corresponding server response, a bidirectional response completion status is not generated; established connection protection is reviewed separately according to the observation period.

[0049] Before submitting the statistics, the statistical results are fixed after all completion deadlines within the window have ended. When the denominator is zero, the corresponding proportion of missing data is output. First, the deadlines for all actual release requests in the window are checked, and then the waiting time for receiving entry records and collected events is checked to ensure it has ended. During the fixed period, the number of completed bidirectional response connections is verified to be no greater than the number of completed handshake connections, and the number of completed handshake connections is no greater than the number of actual release requests. Windows that do not meet these conditions are checked for duplicate events or incorrect associations and remain unavailable. When there are no actual release requests, both the handshake completion rate and bidirectional response rate are missing data. When the number of actual release requests is not zero but the number of completed handshake connections is zero, the handshake completion rate is 0 and the bidirectional response rate is missing data. For example, a complete window contains 1000 initial requests, 800 actual releases are confirmed by the entry point, 720 connections complete handshakes within the completion deadline, and 684 connections complete bidirectional response matching. Therefore, the connection request rate corresponds to 1000 requests per second, with a handshake completion rate of 90% and a bidirectional response rate of 95%. Delayed acknowledgments arriving after the window is fixed only supplement event tracking and do not change the results already handed over to continuous attack acknowledgments; the next window is still calculated according to its first request and completion deadline. The output also includes the window start and end times, counting basis, and proportion validity status, enabling subsequent comparisons to distinguish between normal zero values, missing tests, and statistics that have not yet ended.

[0050] Thus, step S1 has formed a window result that determines the attribution based on the first request, limits the statistical objects based on actual release, and constrains the protocol progress based on the completion deadline. This ensures that the connection request rate, handshake completion rate, and bidirectional response rate have a consistent window attribution and their respective clearly defined statistical object ranges, providing input for service feedback alignment and confirmation of continuous attacks.

[0051] In step S2, the core task is to correlate the fixed network statistics with the service queue status during the same period, identify DDoS attacks within the range of increased request pressure, insufficient protocol progress, and continuous deterioration of service resources, and eliminate state jumps caused by isolated windows through continuous accumulation and explicit reset rules.

[0052] In this embodiment, the number of concurrently queued connections can be collected as queue occupancy, and the average of the duration of completed services and the waiting time for incomplete services can be used as the response latency. A DDoS attack is confirmed when the connection request rate exceeds the limit, the handshake completion rate or the bidirectional response rate is insufficient, and the queue occupancy and response latency continue to exceed the limit. During this process, the collection points are set at the locations where the queue state is actually changed during enqueueing, service completion, and other exits. When a connection enters the application processing waiting area, an enqueue event is generated. After the service begins execution, it remains in the count range of the queue until the service is completed or exited. Both waiting and currently serving connections participate in the queued connection count. When multiple incomplete requests exist for the same connection, it remains in a queued state until all current services are completed, at which point it exits the count range. Queue sampling and entry point collection use a time base that has been calibrated. The duration within a process is obtained using a monotonic clock difference, and then correlated with the window time based on the time calibration result. The queue event position is read before and after sampling. If the positions are consistent, a snapshot of the connection state obtained in the middle is submitted; if the position changes, it is corrected by replaying the events between the two positions; if the event is missing, the current sampling is marked as invalid. For example, queue occupancy is collected every 100ms, and the collection window is set at 1s. The last valid sample before the end of the window is used as the service feedback comparison point for that window. Queue occupancy and response latency must come from the same comparison point. The maximum values ​​of different times cannot be selected separately to form a double over-limit result.

[0053] In some embodiments of this application, for calculating response latency, the number of queued connections can be collected. The average of the completed service duration of connections that have completed service within the window and the incomplete service waiting time of the queued connections at the comparison point is taken as the response latency. The window to which the first request belongs is aligned according to the sampling time. For windows where both handshake completion rate and bidirectional response rate are missing or service feedback is interrupted, the number of consecutive windows is reset. At each comparison point, connections that have completed service within the current window and connections still in the queue at the comparison point are collected. The completed service duration is calculated from the time of queuing to the time of service completion, and the incomplete service waiting time is calculated from the time of queuing to the current comparison point. Connections that are currently being served and have not yet exited continue to be treated as having incomplete service waiting time. The durations of both types of connections are averaged within the same counting range, and the current queuing process of each connection contributes only one duration. For connections that have been queued in a previous window and are still incomplete, the original queuing time is retained, and the timing is not restarted when switching windows. When a service completion event and a snapshot occur simultaneously, the attribution is determined by the order in which the queue events were submitted. Completed connections are assigned to the completed service duration, while incomplete connections are assigned to the incomplete service waiting duration. Connections that exited due to cancellation or connection closure and did not complete their service are not counted as completed services; their exit count is handled separately during service capacity retesting. When the feedback is complete, the queue is empty, and there are no service completion events in the current window, the response latency is recorded as 0; empty results from interrupted feedback remain as missing tests and cannot be used as 0 in the judgment.

[0054] For example, the three connections that completed service in the current window took 0.2s, 0.4s, and 0.6s respectively. At the comparison point, two connections were still waiting, taking 0.8s and 1.0s respectively. After merging the five connections, the response latency was 0.6s. The waiting for incomplete connections continues to be included in the feedback, preventing a small number of completion events from being masked by waiting in the queue. The monitoring process writes the service feedback to the result position corresponding to the window to which the first request belonged, according to the comparison point time. The service feedback is retained until the network completion deadline has passed, and then a synchronous comparison is performed after the network result has stabilized.

[0055] In the normal examination operation record, the upper limit of connection request rate, the lower limit of handshake completion rate, and the lower limit of bidirectional response rate are determined according to the windows whose completion deadlines have expired in the normal examination network traffic. The upper limit of queue occupancy and response latency are determined by service feedback. First, the integrity of the records is checked by the login, resource loading, auto-save, and submission stages. Windows with lost data collection, service downtime, and confirmed anomalies are deleted, and the remaining windows are sorted according to their respective indicators. The connection request rate, queue occupancy, and response latency use the high quantile, while the handshake completion rate and bidirectional response rate use the low quantile. Each indicator is obtained only from valid records, and the missing test ratio is excluded from the sorted samples. Specifically, the high quantile is located to a sample position in an increasing sequence by the number of valid samples and the predetermined quantile level, and the position is rounded up if it is not an integer; the low quantile reads the lower-end samples according to the same position rules. Upper and lower limits can be formed for the normal stage, and then a set of confirmed boundaries can be selected according to the current examination stage. Stage switching only takes effect at the window boundaries. For example, the high quantile level is set to 99.5%, and the low quantile level is set to 0.5%. The boundary response to centralized login is checked by examining independent operation records covering each normal stage. If a certain stage is missing from the sample, the already verified boundary is maintained, and the judgment is not automatically relaxed based on incomplete samples.

[0056] Based on this, the fixed statistical results are compared with the upper and lower limits. Only for windows where the connection request rate exceeds the limit and at least one of the handshake completion rate and bidirectional response rate is insufficient, the cumulative number of consecutive windows where both queue usage and response latency exceed the limits is calculated. The comparison proceeds sequentially according to window time. The stress condition is met only when the connection request rate is strictly greater than the upper limit, the insufficiency condition is met only when the handshake completion rate or bidirectional response rate is strictly less than the corresponding lower limit, and the server-side condition is met only when queue usage and response latency are strictly greater than the corresponding upper limits. When the indicators are equal to the boundary, they are classified as not exceeding the limit or having met the standard, avoiding two sets of counting results due to different equivalence classifications in adjacent windows. In this process, the completeness of packet collection is first checked, and the number of consecutive windows for windows with missing collection is reset; after complete collection, the validity of the ratio is checked. When the handshake completion rate is valid and insufficient, even if the bidirectional response rate is missing due to zero handshake completion connections, there is still comparable evidence of insufficient progress. When the handshake completion rate is normal but the bidirectional response rate is missing, a response anomaly flag cannot be generated based on the missing measurement itself. For windows where both handshake completion rate and bidirectional response rate are missing or service feedback is interrupted, the consecutive window count is reset, while the reason for the reset is retained. The next complete and valid window starts from the new cumulative segment. The confirmed attack handling status is stored separately from the candidate count. The candidate count is reset due to data interruption and does not directly implement the action of relaxing the rate of allowing new connections.

[0057] Furthermore, the number of consecutive windows is compared with the confirmation length. The confirmation length is the maximum value of the number of consecutive windows exceeding the limit in normal examination network traffic plus 1. When the confirmation length is reached, a DDoS attack is confirmed; if the cumulative condition is not met, the number of consecutive windows is reset. When determining the confirmation length, normal examination records separate from boundary calibration data are used. Consecutive exceeding segments are extracted window by window, and the segment length is saved at the end of the segment. The maximum value of the number of consecutive exceeding the limit in normal examination network traffic plus 1 is used as the confirmation length, and the number of consecutive windows is compared with the confirmation length. If there are no windows in the normal record that meet the cumulative condition, the maximum length is treated as 0. For example, the longest consecutive exceeding segment in the normal review record contains 2 windows, and the confirmation length is 3. During deployment, an attack confirmation is triggered after 3 consecutive windows that meet the cumulative condition. The same set of maximum values ​​used to determine the threshold cannot be directly used as independent verification results.

[0058] In some embodiments of this application, a DDoS attack is confirmed when the number of consecutive windows is not less than the confirmation length, and the number of consecutive windows is reset for windows that do not meet the accumulation condition. Specifically, for windows that meet the accumulation condition, handshake anomaly flags and response anomaly flags can be generated based on insufficient handshake completion rate and normal handshake completion rate but insufficient bidirectional response rate, respectively, with one anomaly flag recorded for each window. First, the handshake completion rate is checked; if the insufficient condition is met, a handshake anomaly flag is determined, and then the flag selection for that window is stopped. The response anomaly flag judgment only proceeds when the handshake completion rate meets the standard and the bidirectional response rate is valid; therefore, if both the handshake completion rate and the bidirectional response rate are insufficient, only a handshake anomaly flag is generated.

[0059] Once the anomaly flags are determined, when adjacent windows have both handshake anomaly and response anomaly flags, check that both windows exceed limits for connection request rate, queue usage, and response latency, and include the adjacent windows in the same consecutive window count segment. Check that there are no gaps between two windows by window number, and then read the validity and limit-exceeding results of each window one by one. When switching between the two types of anomaly flags, if the common accumulation condition is met, the existing count continues; if the window numbers are not consecutive, any service feedback is invalid, or any common condition is not met, the existing accumulation segment ends. Further, for windows with zero handshake completed connections but non-zero actual allowed requests, a handshake anomaly flag is generated based on the handshake completion rate; for windows with zero actual allowed requests or interrupted service feedback, the consecutive window count is reset. Further, for the zero-value branch, for windows with zero handshake completed connections and non-zero actual allowed requests, a handshake anomaly flag is generated based on the handshake completion rate; for windows with zero actual allowed requests or interrupted service feedback, the consecutive window count is reset. The count body is read first, then the proportion validity status is read, ensuring that valid handshake completion rates of 0 and missing test states are handled separately. When the entry point has rejected all current requests, the connection request rate is still formed by the collection results before the release judgment, but the lack of a window with actual released objects cannot prove that the handshake is abnormal.

[0060] When the number of consecutive windows is not less than the acknowledgment length, a DDoS attack is confirmed. The number of consecutive windows is reset if the connection request rate, handshake completion rate, and bidirectional response rate all meet the standards, or if at least one of queue usage and response latency does not exceed the limits. The count restarts from the next window that meets the accumulation conditions. The triggering window, the change in the anomaly flag, and the service feedback results are submitted to the new connection adjustment process. The number of consecutive windows is reset when the connection request rate, handshake completion rate, and bidirectional response rate all meet the standards, or if at least one of queue usage and response latency does not exceed the limits. The count restarts from the next window that meets the accumulation conditions. The reset occurs while processing the window and cannot skip intermediate normal windows when splicing two anomalies. For example, consecutive acknowledgments are formed when the flags of three qualified windows are, in the order of handshake anomaly flag, response anomaly flag, and response anomaly flag; when the queue usage of the second window equals the upper limit, the two qualified windows belong to different accumulation segments.

[0061] At this point, step S2 connects fixed network statistics, concurrent service feedback, and continuous window status to form a DDoS attack confirmation result with validity checks and clear reset boundaries, providing a trigger basis for adjusting the rate of new connection access, while retaining the distinction between statistical interruption and the disappearance of attack evidence.

[0062] In step S3, the core task is to determine the new connection release rate based on the confirmed DDoS attacks and service feedback, drive the bounded proportional integral adjustment with the more unfavorable state between queue occupancy and response latency, review the established connection protection according to the continuous bidirectional response, and verify the adjustment effect with the actual number of entry points.

[0063] In this embodiment, the minimum value of queue occupancy and response latency (both positive target values ​​minus actual values) can be used for bounded proportional-integral adjustment to reduce the new connection release rate, protect established connections with continuous bidirectional responses, and count the actual number of connections released. Specifically, after the attack confirmation result arrives, the differences between queue occupancy and response latency relative to their respective positive target values ​​are calculated, and the minimum value is taken as the control error for bounded proportional-integral adjustment. Before calculation, the service feedback of the latest complete control cycle and the currently effective target value are read, without using the earlier feedback corresponding to the attack confirmation window to replace the current state. The queue occupancy target value is set from the allowed number of queued connections during normal testing, and the response latency target value is set from the allowed time from connection queuing during normal testing to service completion; both are strictly greater than 0. Each difference is formed by subtracting the actual value from the target value, and then the scale difference is eliminated according to their respective target values. When the service status exceeds the target, a negative control error is formed.

[0064] Based on this, the smaller of the two difference ratios is selected for the current control error to avoid the other positive margin offsetting the response latency when the queue occupancy is still low but the response latency has already deteriorated. The target value remains unchanged during the calculation. If service feedback is missing, timing is inconsistent, or the target value is invalid, no new proportional integral result is generated; the rate of the most recently confirmed new connection release is retained, and valid feedback continues to be obtained. Upon first entering attack handling, the current control error is simultaneously used as the initial value of the previous control error, and the proportional increment starts from 0 to avoid treating a non-existent error history before entering handling as a sudden change. The control error of the two feedbacks can be written as: , in, Indicates the numbered consecutively from 1 in time. Dimensionless control error for a complete control cycle and These represent the currently active queue occupancy target value and the queue occupancy at the comparison point of this complete control cycle, respectively, both measured in terms of the number of connections. and These represent the target value for the current response delay and the response delay at the same comparison point, respectively, both measured in seconds. Both target values ​​are strictly greater than 0, and the two asterisks represent the target values ​​of the corresponding feedback quantities.

[0065] Furthermore, the minimum of the corresponding ratios of queue occupancy and response delay is used as the control error. The difference between adjacent control errors is multiplied by the proportional gain to calculate the proportional increment. The current control error, the duration of the control cycle, and the integral gain are multiplied to calculate the integral increment. This is then added to the last new connection release rate and truncated according to the execution range. The current and previous control errors are read sequentially according to the complete control cycle. The two increments use the same unit as the new connection release rate to reflect the deviation change and its periodic continuous effect, respectively. The calculation uses the rate that the entry point has confirmed execution as the superposition starting point; commands that have not yet received execution confirmation are not written back as the execution starting point. Based on this, the upper limit of the execution range is obtained from the new connection acceptance configuration that the entry point can execute, and the lower limit is obtained from the controlled acceptance configuration required for continuous observation. The lower limit is not greater than the upper limit, and normal proportional-integral adjustment uses this execution range. Capacity protection triggered by effective capacity retesting allows the new connection release rate to be reduced below this lower limit until 0. The output of capacity protection takes precedence over the normal execution lower limit, and the entry point resets the adjustment output starting point according to the actual results.

[0066] Furthermore, during the duration of a DDoS attack, the minimum value between the truncation result and the current new connection release rate is used to update the new connection release rate. The incremental points that continue to accumulate downwards after reaching the lower limit are frozen. The actual release volume within the complete control cycle is calculated based on the difference in ingress release counts. This ensures that service improvement during the attack's duration only maintains the existing rate and does not prematurely trigger recovery. The effective incremental points are obtained using the normal incremental points method; the incremental points that continue to accumulate downwards after reaching the lower limit are frozen, the effective incremental points are set to 0, and negative increments are stopped from being added to the integral status. For example, capacity retesting requires maintaining the integral status during the integral freezing period. After unfreezing, calculations resume from the current execution starting point. The constrained new connection release rate update relationship can be written as: , in, and They represent the first At the end of a complete control cycle, the new connection release rate to be issued to the entry point for the next complete control cycle and the new connection release rate that has been most recently confirmed within this complete control cycle will be released. and These represent the lower and upper limits of the new connection release rate, which are typically adjusted by proportional-integral scaling, respectively, both measured in the number of new connections allowed per second. This represents the proportional gain, which has the same dimensions as the rate at which new connections are allowed to proceed. This indicates the control error of the previous complete control cycle. This represents the effective integral increment obtained by multiplying the integral gain, control cycle duration, and control error for the complete control cycle and subjecting it to integral freeze constraints. It is measured in the number of new connections allowed per second.

[0067] After verifying the configuration and control cycle sequence at the ingress point, the rate is switched at the release judgment position and the execution time is returned. Rate execution can replenish the acceptance quota at fixed intervals; each time a first request is passed, the quota is deducted once. First requests with insufficient quota are not released. Retransmissions of the same released connection do not deduct the acceptance quota again. The cumulative quota retains a decimal balance, allowing passage only after a connection is reached, avoiding acceptance stalls caused by independent rounding at short intervals. The burst quota allowed at the ingress point is limited to the verified configuration range; a large amount of previously remaining quota cannot be used after the rate is reduced.

[0068] Furthermore, when confirmation is delayed, the actual execution rate is still counted based on the most recent confirmation rate, and update commands are queued sequentially. Multiple unconfirmed adjustments cannot be accumulated and continuously issued. When the actual configuration reported by the entry point differs from the requested configuration, the starting point for the next overlay is reset according to the actual configuration, and the execution range is checked to see if it has been changed by external configuration. Proportional gain and integral gain are determined based on the connection queue response before deployment. Maintaining a constant number of healthy instances and connection queue capacity, small changes in the admission rate during isolation testing are used to observe the actual release volume, queue occupancy, and response latency for each complete control cycle. Local changes are analyzed only in intervals where the queue is not empty, the service completion rate is approximately stable, and the entry point can confirm execution within one control cycle. The control cycle is determined first, and then the gain is adjusted to ensure that the deviation decay rate of unsaturated calculations is slower than the unobserved execution latency. When continuously alternating increases and decreases in calculation output occur, the gain is reduced and the control cycle is reviewed.

[0069] In some embodiments of this application, in local intervals where queue occupancy determines control error, target value is fixed, and new queuing mainly comes from actual releases, the number of connections actually released but not yet queued and the new service load of established connections remain approximately constant. The new connection release rate calculated at the end of the cycle takes effect at the start of the next control cycle. A queue recursive relationship is established based on the changes in the number of queued connections and service dequeuing within the control cycle. Then, the control error changes of adjacent cycles are substituted into the proportional-integral incremental relationship. After eliminating the rate deviation, a second-order recursion about adjacent control errors is obtained. The eigenvalue of this recursion is used to screen the gain, making the eigenvalue modulus less than 1. This screening is only for local relationships without saturation and where the new connection release rate takes effect at the start of the next control cycle. Actual attack handling is also limited by unidirectional deceleration and freezing. For example, the corresponding eigenvalue relationship can be written as: , in, Characteristic factors representing the recursive relationship of local control errors. This indicates the duration of a control cycle of equal length, which is strictly greater than 0 and measured in seconds. The integral gain is expressed as the change in the rate of new connection release per second. In this local recursion, the ratio of the product of the proportional gain and the control cycle duration divided by the queue occupancy target value must be greater than 0 and less than 2. The ratio of the product of the integral gain and the square of the control cycle duration divided by the queue occupancy target value must be greater than 0 and less than 4 minus twice the previous ratio. When both conditions are met, the root of the second-order recursion lies within the unit circle. The eigenvalues ​​corresponding to the proportional gain of 80, the integral gain of 20, the control cycle duration of 1s, and the queue occupancy target value of 400 are approximately 0.8750 plus 0.1854 times the imaginary unit and 0.8750 minus 0.1854 times the imaginary unit, respectively, with a modulus of approximately 0.8944.

[0070] For example, with a control cycle of 1 second, a queue occupancy target of 400, a proportional gain of 80, an integral gain of 20, and a local eigenvalue magnitude of approximately 0.8944, this result supports the attenuation judgment of this set of parameters under the aforementioned local conditions. If the new connection release rate does not take effect at the start of the next control cycle or the response delay becomes the dominant constraint, it still needs to be re-verified according to the actual feedback. Within a complete control cycle that is not the first adjustment, with a response delay target of 0.5 seconds, a queue occupancy of 500, and a response delay of 0.75 seconds, the current control error is -0.50. The current new connection release rate is 300, the previous control error is -0.25, the proportional increment is -20, the integral increment is -10, and the execution range is 200-800, resulting in a new connection release rate of 270. Each rate is measured based on the number of new connections allowed per second.

[0071] In some embodiments of this application, the observation period can be determined based on the network interaction interval of the normal examination client. Established connections are verified by server responses and client feedback within the observation period. Established connections that have completed bidirectional responses are maintained and forwarded, while protection for established connections that have exceeded the observation period and lack bidirectional responses is cancelled. Specifically, the observation period can be calibrated based on the network interaction interval formed by normal records of resource loading, automatic saving, and submission by the normal examination client. The observation period is set to be less than the connection idle timeout. The time of the most recent completion of bidirectional responses for each established connection is recorded as the most recent completion time. Adjacent completion time intervals are obtained from continuous valid interactions of the same client. Idle periods after explicit exit from the examination are excluded, and then an observation period covering the upper bound of normal interactions is taken.

[0072] During this process, the observation period is calibrated based on the network interaction interval formed by the normal examination client resource loading, automatic saving, and submission. The observation period is set to be less than the connection idle timeout. The time of the most recent bidirectional response completed for each established connection is recorded as the most recent completion time. The difference between the observation period and the duration from the most recent completion time is truncated non-negatively to obtain the remaining observation period. The observation period takes into account the allowed delay for event transmission. When the normal interaction interval is close to or exceeds the connection idle timeout, the automatic saving configuration and entry idle timeout configuration of the examination client are checked first, and an observation period exceeding the idle timeout is not adopted. Further, the difference between the observation period and the duration from the most recent completion time is truncated non-negatively to form the remaining observation period. Each review uses a monotonic clock to calculate the elapsed time, and values ​​that have already returned to zero remain 0 and do not become positive again due to wall clock calibration. For example, the upper bound of the normal interaction interval is 12s, the observation period is 15s, and the connection idle timeout is 60s.

[0073] Furthermore, the client's response is checked against the range of unacknowledged sequence numbers in the server's response to verify that the client's acknowledgment number does not exceed the server's next sent sequence number. When the client's acknowledgment number covers the range of unacknowledged sequence numbers, the most recent completion time is updated and forwarding continues. First, the last valid acknowledgment position and the continuous range already sent for the connection are read, then it is determined which newly added response positions are covered by the new acknowledgment. Server response retransmissions only reuse the original sequence range, and client duplicate acknowledgments only point to the original acknowledgment position; neither can be considered a new bidirectional response based on an increase in the number of packets. Acknowledgments exceeding the upper limit of server sending are directly excluded; ranges lacking server sending records are awaited to be filled, and the most recent completion time cannot be updated accordingly. On connections where the acknowledgment relationship is established, when the client's acknowledgment number covers the range of unacknowledged sequence numbers, the most recent completion time is updated and forwarding continues. The completion time that formed this valid bidirectional response is written back to the corresponding connection, and the remaining observation period is calculated based on the updated most recent completion time. Simultaneously, for established connections that only duplicate acknowledgments of existing sequence numbers, the most recent completion time is maintained, and protection verification is performed based on the remaining observation period. Before and after reading, confirm the location to check for any new overlays. The receiving time of repeated confirmations will not replace the valid completion time.

[0074] In this embodiment, the protection review and new connection release judgment apply to established connections and the initial request, respectively. Specifically, when the remaining observation period reaches zero and no new bidirectional response is found, the protection of the established connection is cancelled and the connection is released according to the connection idle timeout. Other established connections that have completed bidirectional responses under the same egress address are maintained and forwarded. Other established connections that have completed bidirectional responses under the same egress address continue to be forwarded. The search and cancellation scope is limited to the connection five-tuple and the initial sequence number. Other examination clients sharing the egress address maintain their original connection status.

[0075] Furthermore, in sync with the entry point execution, the actual release volume within a complete control cycle is calculated based on the entry point release count difference. The cumulative release counts at the start and end of the cycle are obtained separately, and the increase in the count for that cycle is determined by the same entry point instance and the same continuous counting segment. The count only increases when the first request actually passes; retransmissions and established connection packets are not included in the actual release volume. Cycles spanned by entry point restarts or counter resets are marked as incomplete, and the count is recalculated from the new continuous starting point. The actual release volume, along with execution time, concurrent queue occupancy, and response latency, is submitted to service capacity retesting, preserving the distinction between command decreases and actual releases not decreasing.

[0076] Thus, step S3 transforms the dual feedback control error, constrained rate update, integral freeze, and established connection protection connection into an executable adjustment process, forming the actual release quantity of the complete control cycle, providing a practical basis for identifying changes in service capability and correcting target values.

[0077] In step S4, the core task is to distinguish between normal feedback lag after the actual decrease in the new connection release rate and changes in service capacity. The integral is frozen within the range where the actual release rate decreases while the queue occupancy and response latency continuously increase, and the target value is corrected using healthy instances, queue inflow and outflow, and service completion rate.

[0078] In this embodiment, when the actual release volume decreases while queue occupancy and response latency continue to increase, the integral can be frozen while maintaining the new connection release rate. Service capacity can be retested and the target value corrected. If capacity remains insufficient, the new connection release rate can be lowered by deducting the admission budget based on the queue exceeding the target amount. Specifically, a preset equal-length time period is used as the control cycle. Entry execution confirmation is obtained, and the complete control cycle before and after the effective date is divided according to the actual execution time. The actual release volume and concurrent queue occupancy and response latency are compared. If the actual execution time falls in the middle of the cycle, that cycle is not considered the adjusted complete cycle. Starting from the beginning of the first subsequent cycle, the cumulative release count, queue events, and service feedback are simultaneously captured. The execution time returned by the entry point is used to determine the cycle to which it belongs. The reception time of the confirmation message is only used to determine if the feedback is late, avoiding transmission delays that could alter the division before and after execution. Furthermore, for the quantities before and after adjustment, the actual release volume of the complete control cycle after the new connection release rate takes effect is compared with the last complete control cycle before the effective date. Queue occupancy and response latency are compared according to the same cycle. Each change in the new connection release rate uses the last complete control cycle before its effective date as the comparison cycle. To ensure consistency in the examination service range, queue counting range, and time length, the actual quantity of each complete cycle is read. Queue occupancy and response latency are based on the same valid sampling position before the end of each cycle; cycles with service feedback interruptions are temporarily excluded from the increase judgment.

[0079] During this process, the comparison results of adjacent complete control cycles are continuously increased, and the queue occupancy and response delay are checked cycle by cycle to ensure that the actual release volume is lower than that of the complete cycle before execution. The continuous length is determined based on the feedback lag record after normal deceleration, so that the observation interval covers the normal response time of entry execution and service queuing; the continuous increase is interrupted for equal, falling, or incomplete cycles. For example, there may be a temporary increase of at most one complete cycle in the normal adjustment test, and two consecutive complete cycles of increase can be used as the retest trigger. The peak of a single sampling point does not trigger service capacity correction.

[0080] Based on this, when the actual number of connections allowed decreases while queue occupancy and response latency continuously increase, the rate of the most recently confirmed new connection allowance is locked, and the integral status is frozen. The current effective rate of the ingress is used as the hold value, and old rate-reduction commands that have not yet been executed are canceled. The control sequence of commands is maintained, and the ingress returns the existing result for repeated commands and maintains the starting point for quota accumulation. Proportional integral processing continues to read service feedback to observe changes, but during the freeze period, new control errors are not added to the integral accumulation, and new new connection allowance rates are not issued based on proportional increments. During periods of missing feedback, this state is maintained, and complete feedback is continuously requested. A decrease in the actual number of connections allowed indicates that ingress acceptance has decreased, but the continued increase in queue occupancy and response latency may still stem from a decrease in service completion rate, delayed queuing of previously allowed connections, or continued service requests from existing connections. During the freeze period, these changes are observed separately through queue inflows and outflows; it is not possible to infer that the queue will necessarily fall back simply because the rate has decreased. In two consecutive valid retesting cycles, the service completion rate, after deducting the rate corresponding to the re-entry retention of established connections, was not higher than the locked new connection release rate, indicating persistent capacity insufficiency. Therefore, independent capacity protection was implemented to reduce the rate and maintain the integral freeze. Invalid retesting cycles interrupted continuous counting, and counting resumed after capacity protection was issued. Target value correction and new connection acceptance tightening worked together to affect subsequent queue inflows and outflows.

[0081] In some embodiments of this application, service capacity can be retested based on the number of healthy instances that can accept exam requests and return valid queue feedback, and the connection queue capacity can be adjusted in conjunction with the service completion rate. Specifically, the number of healthy instances can be verified from the health checks and queue operation information of the service process, and queued connections can be retained until the service is completed or exited. Instances that can accept exam requests and return valid queue feedback are included in the current retesting scope. The health check simultaneously verifies the process liveness, request acceptance status, and a service probe result of a limited duration. Instances that are exiting the service or whose queue feedback is interrupted are not included in the number of healthy instances. The health check results and queue feedback are verified using the same instance identity. After the instance restarts, the new startup time is read to distinguish between residual records before restart and connection processing after restart. The current retesting scope remains unchanged within the complete control cycle; cycles in which the number of healthy instances changes are invalidated and a new complete cycle is established to prevent subtracting the start and end points of queues for different instance combinations. The connection queue capacity is read from the actual effective queue capacity configuration of each healthy instance, and the statistical boundaries of waiting connections and currently serviced connections are verified to be consistent with the queue occupancy. Parameters that only limit the length of the waiting area cannot replace the total capacity of queued connections.

[0082] When processing events one by one in the queue, the number of healthy instances is checked, and queued connections are retained until service completion or exit. The number of queued connections within the same control period is counted, and the number of connections dequeued after service completion is counted as the service completion dequeue quantity, while other exits are counted as the release quantity. First, it is determined whether the current queuing process for the connection has already occurred. For connections not yet queued, the queue count increases upon receiving a valid queuing event; duplicate queuing events for already queued connections do not increment the count. Service completion events only generate the service completion dequeue quantity if the current queuing process has not yet ended; connections with a completion flag already written retain their count when receiving duplicate dequeue events. Dequeueing and release quantities caused by client cancellation, timeout exit, or abnormal closure are not included in the service completion dequeue quantity. When a connection receives a new test request after completing its service and is queued again, the next service process is established based on the new queuing start time, retaining the connection identity but restarting the count for a new duration. When enqueueing and dequeueing fall exactly at the control cycle boundary, they are assigned to a unique cycle based on the actual event time and queue submission order. Late events are made up before the cycle is fixed; if omissions are found after the cycle is fixed, the cycle is marked as unusable for capacity estimation. Two cycles cannot be modified simultaneously to eliminate differences. The first valid enqueueing of the same connection is counted as new connection enqueueing, and subsequent enqueueing after service completion is counted as established connection re-enqueueing. For the three most recent consecutive valid complete control cycles within the same healthy instance, the number of established connections re-enqueued is counted, and the maximum value is taken as the established connection re-enqueueing reserve for the next cycle. The reserve only deducts the admission budget for new connections and does not revoke the forwarding protection for established connections. If there are fewer than three consecutive valid cycles, the addition of new connections is paused while data collection continues. The number of connections actually allowed but not yet enqueued is verified one by one by the allowed and first enqueueing events, referred to as the pending enqueueing quantity; the queue occupancy minus the current queue occupancy target value, after non-negative truncation, is the queue over-target quantity.

[0083] At the end of the cycle, the queue occupancy at the cycle start is added to the number of enqueued connections, and the number of connections dequeued and released after service completion is subtracted to obtain an estimated queue occupancy at the cycle end. The absolute value of the difference between this estimated value and the directly sampled value is then calculated. Starting from the existing connections at the start, the number of connections actually enqueued in this cycle is added, and then connections that have completed services and others that have exited are removed sequentially. Event accumulation and direct sampling are aligned with the control cycle end, preserving the time difference between two reads and limiting it to within the normal sampling error range. The counting object does not change with the instance state. If the estimated value is negative or exceeds the configured capacity, duplicate dequeuing, missing enqueuing, and capacity changes are checked back. Abnormal estimated values ​​are not pruned and treated as consistent results.

[0084] Furthermore, a tolerance is determined based on normal sampling error. Within a complete control period where queue occupancy is consistently non-zero and the absolute value of the difference is no greater than the tolerance, the service completion rate is retested by dividing the service completion dequeue amount by the control period, and the connection queue capacity of each healthy instance is summarized. The allowable short-term deviation between queue event reading and endpoint sampling is collected, and a tolerance value covering the verified deviation is taken. The tolerance only accommodates limited differences caused by sampling asynchrony; continuously lost queue events cannot be handled by increasing the tolerance. Based on this, within a complete control period where queue occupancy is consistently non-zero and the absolute value of the difference is within the tolerance, the service completion rate is retested based on the ratio of the service completion dequeue amount to the control period. Queue changes within each period are checked sequentially; any empty queue interval is excluded from the valid period for service completion rate retesting. The check for consistently non-zero queue occupancy is performed sequentially along the queue events, increasing or decreasing item by item from the starting queue occupancy. An empty queue interval is recorded when any event position reaches zero; non-zero start and end points alone are insufficient to prove consistently non-zero occupancy. Valid estimation is terminated when service probe fails or instance reports disconnection within a period, maintaining the previous valid service completion rate. The service completion rate is formed by the actual completion amount of a valid and complete control cycle, reflecting the service completion capacity observed in that cycle. Subsequently, the actual effective connection queue capacity of each healthy instance is summarized to form the service capacity retest result, while retaining the range of instances participating in the summary for comparison in the next cycle. For example, if the queue occupancy at the start of the cycle is 500, the number of inbound connections during the cycle is 180, the number of service completions and dequeues is 160, and the release amount is 20, the estimated queue occupancy at the end of the cycle is 500; when the direct sampling at the end is 510, the absolute value of the difference is 10. With a tolerance of 10 and the event sequence proving that the queue is continuously non-zero, this cycle, through a consistency check, achieves a service completion rate of 160 connections completed per second by setting the control cycle to 1 second. The release amount is not included in the service completion and dequeue amount.

[0085] In this embodiment, when both the service completion rate and connection queue capacity are positive, the response latency target value is corrected using the upper limit of the average time from queuing to service completion for a normal test connection. The minimum value of the product of the service completion rate and the response latency target value and the connection queue capacity is used to correct the queue occupancy target value; otherwise, if the absolute value of the difference exceeds the tolerance, the original target value is used. The average value of each normal window is calculated according to the service duration range of the normal test phase, and then the upper limit of the average duration verified by normal operation is used as the basis for the response latency target value. When both the service completion rate and connection queue capacity are positive, the upper limit of the average time from queuing to service completion for a normal test connection is used to correct the response latency target value. The minimum value of the product of the service completion rate and the response latency target value and the connection queue capacity is used to correct the queue occupancy target value, so that the target queue size is constrained by both service completion capacity and physical queue capacity. The internal target value retains decimal calculation precision, and the queue occupancy is still compared with the actual connection integer. In the above example, the total connection queue capacity of the healthy instance is 600, the response latency target value is 0.5s, and the queue occupancy target value is corrected to 80. Two objectives take effect as a group at the same control cycle boundary, and the comparison and control error calculation cannot read a new objective and an old objective. Furthermore, in cycles where the service completion rate is zero, the connection queue capacity is zero, or the absolute value of the difference exceeds the tolerance, the original objective value is used, while the reason for invalid retesting is retained, and subsequent complete control cycles are obtained. Objective 0 is not written into control relationships with denominators. After a new objective is released, the unfreezing is still determined based on the actual service status.

[0086] After effective correction, if the service completion rate for two consecutive effective retest cycles, after deducting the rate corresponding to the re-entry retention of established connections, is not higher than the locked new connection release rate, the new connection release rate is reduced by deducting the number of pending enqueues, the re-entry retention of established connections, and the queue exceeding the target from the service completion dequeue amount, truncating it non-negatively, and dividing by the control cycle. The points freeze is maintained until the end of the complete control cycle after the new target takes effect. The queue start point and release count start point are re-obtained from the boundary where the target value takes effect. If the number of healthy instances or the connection queue capacity changes again during this period, the current review cycle is terminated and retested. Cycles that have not yet ended do not provide a basis for unfreezing. After the complete cycle ends, the current target value, queue occupancy, response latency, and retest validity status are all handed over to the recovery judgment to keep the entry execution rate consistent with the start point of this points freeze. When a persistent capacity shortage is triggered, the number of actually released but not yet enqueued connections, the re-entry retention of established connections, and the queue exceeding the target are deducted from the service completion amount of a control cycle, truncated non-negatively, and divided by the control cycle duration. The upper limit of the capacity protection rate can be written as: , in, Indicates the first The capacity protection rate limit formed by a complete control cycle is measured in the number of new connections allowed per second. This represents the service completion rate achieved during the same complete control cycle when queue income and expenditure are reconciled and the queue remains non-zero. It is measured in the number of connections completed per second. This represents the number of connections that were actually released at the end of the cycle but have not yet been queued for the first time. This represents the number of established connections retained as of the end of the cycle, determined by the maximum number of established connections re-enqueued over the most recent three consecutive valid and complete control cycles. All numbers are measured in connections.

[0087] Capacity protection distributes the lower of the currently confirmed new connection release rate and the capacity protection rate limit. If the result is lower than the normal execution lower limit, it will still be executed according to the result. After capacity protection takes effect, unused burst quotas at the ingress point are cleared, a decimal reserve is retained, and the system waits for feedback from the full cycle again, without accumulating any unexecuted rate reduction. If the service completion rate is effectively 0 and the instance scope and queue inflow / outflow are still complete, new connection release is directly suspended while existing connection protection is maintained; if feedback is missing, the confirmed execution rate is maintained and a feedback missing test status is output. When the queue capacity reaches the limit, the ingress point stops queuing new connections according to the queue capacity configuration. When the load of established connections exceeds the full service capacity, a service capacity insufficient status is output and continuous retesting is performed.

[0088] For example, in two consecutive valid retest cycles, the service completion rate is 160 connections per second, the locked new connection release rate is 260, the current queue occupancy is 500, the queue occupancy target is 80, the number of connections actually released but not yet enqueued is 20, the re-enqueue reserve for established connections is 10, and the control cycle is 1 second. After deducting the queue over-target capacity of 420, the number of connections waiting to be enqueued (20), and the re-enqueue reserve for established connections (10), the admission budget is negative 290. After non-negative truncation, the capacity protection rate limit is 0, and the entry point suspends new connection release and continues to serve queued connections. In the next cycle, if 20 connections waiting to be enqueued and 10 established connections are re-enqueued, 160 connections are served and no other connections exit, the queue occupancy decreases from 500 to 370.

[0089] At this point, step S4 differentiates control execution and service capacity changes based on actual release and queue inflow / outflow. Through integral freezing, tightening of acceptance when capacity is insufficient, and effective period retesting, a consistent service completion rate and target value are formed, providing verifiable capacity boundaries for unfreezing and constrained recovery.

[0090] In step S5, the core task is to unfreeze the points based on the corrected service status, continuously verify the disappearance of attack evidence in the complete network statistics, restore the new connection release rate periodically based on the remaining queue capacity, service completion rate and response latency, and pause the recovery when the feedback is not mature or the attack reappears.

[0091] In this embodiment, the freeze can be lifted when both queue occupancy and response latency are not higher than their respective target values. After verifying the disappearance of DDoS attack evidence, the new connection release rate is gradually restored according to the acceptance budget after deducting the re-entry reserve of established connections, and the network abnormal traffic monitoring results of electronic examinations are updated. Specifically, within the complete control cycle after the new target takes effect, the integral freeze is lifted when both queue occupancy and response latency are not higher than their respective target values, and the output starting point is reset with the current new connection release rate. The normal configuration upper limit is restored, and the current rate formed by capacity protection, which is lower than the normal execution lower limit, is still used as the actual starting point. First, it is checked that the service feedback covers the complete cycle and that the current target value is still valid, and then queue occupancy and response latency are compared separately. If any actual value is still higher than the corresponding target value, the freeze is maintained, which is equivalent to the target value being assigned to the side that allows release. If a capacity change or feedback interruption occurs within the same cycle, the freeze is lifted only after the newly established complete cycle ends, without using the previously unfailed portion. When resetting the output starting point, the most recently confirmed new connection allowance rate is read from the entry point. This rate is used as the starting point for subsequent proportional-integral increment superposition. Simultaneously, the control error at the time of release is written to the previous control error position, and control increments not executed during the freeze period are cleared. Adding allowances still requires continuous confirmation of the disappearance of attack evidence. If the service status has recovered but network anomaly evidence still exists, the unidirectional adjustment limit during the attack period is maintained.

[0092] Based on this, after the deadline, if the connection request rate is within the limit or exceeds the limit but the handshake completion rate and bidirectional response rate are both valid and meet the standard, the number of consecutive windows where attack evidence disappears is accumulated; otherwise, it is reset. The exit length is the rounded-up value of the longest interaction interval of normal network traffic divided by the window duration, and must be at least 1. Processing starts from the earliest window that has not yet been used for exit judgment. The connection request rate is based on the statistics of the first request before the release judgment. Reducing the number of entry points will not directly reduce the connection request rate to the normal range. Incomplete collection of windows resets the number of consecutive windows; confirmed attack handling remains in its current state, waiting for the next complete window to be accumulated again. During this process, for windows where the connection request rate still exceeds the limit, the number of consecutive windows is accumulated if the handshake completion rate and bidirectional response rate are both valid and meet the standard; otherwise, the number of consecutive windows is reset. First, check the denominator and completion deadline of the handshake completion rate and bidirectional response rate, and then compare them with the normal lower limit respectively. Windows with a handshake completion rate of 0 and a missing bidirectional response rate, windows with zero actual released requests resulting in missing handshake completion rate and bidirectional response rate, and windows where the bidirectional response rate has not yet been fixed cannot be considered valid and compliant windows. The number of consecutive windows entering and exiting the judgment phase is stored separately from the number of consecutive windows in the attack confirmation phase. When exiting the review, the count starts from 0 to avoid treating the attack confirmation history as the history of lost evidence.

[0093] Furthermore, the exit length is determined based on the longest interval of continuous valid network interactions between clients during the normal examination. The rounded-up value of the ratio of the longest interaction interval of normal examination network traffic to the window duration can be used as the exit length. The exit length must be at least 1. The longest interaction interval is determined from the records of clients continuously participating in the examination during resource loading, automatic saving, and submission, excluding offline time after the examination has ended. For example, when the longest interaction interval is 2.4 seconds and the window duration is 1 second, the exit length is 3. Only after three consecutive fixed, qualified windows can the calculation resume. Window numbers are re-accumulated when there are gaps or stage boundaries are adjusted; continuity cannot be judged solely by the number of results received.

[0094] In some embodiments of this application, when the number of consecutive windows reaches the exit length, the remaining queue capacity is obtained by subtracting the queue occupancy from the minimum of the connection queue capacity and the queue occupancy target value, and performing a non-negative truncation. The incremental rate of new connection release is then calculated based on the remaining queue capacity and the service completion rate. Specifically, within a complete control period where service capacity retesting is effective, the minimum of the connection queue capacity and the queue occupancy target value is taken, the current queue occupancy is subtracted, and a non-negative truncation is performed to obtain the remaining queue capacity. First, it is verified that the capacity configuration and target value fall within the range of the current healthy instance. Then, it is determined whether the queue occupancy has reached a smaller boundary. When the boundary is reached or exceeded, the remaining queue capacity is set to 0. If there is still space, only the corresponding difference is retained; not all physical spaces exceeding the queue occupancy target value are used for recovery.

[0095] After calculating the remaining queue capacity, the service completion rate and the number of connections actually released but not yet enqueued are read from the same control period. The re-enqueue reserve for established connections is the maximum number of established connections re-enqueued over the three most recent consecutive valid complete control periods. The product of the service completion rate and the control period is added to the remaining queue capacity, and the number of connections actually released but not yet enqueued and the re-enqueue reserve for established connections are subtracted. After non-negative truncation, the result is divided by the control period to obtain the upper limit of the admission rate. First, a set of connections yet to be enqueued is established based on the entry release record. Then, enqueue events are matched one by one using the connection quintuple and the initial sequence number. Connections that have already been enqueued are immediately removed from the waiting list. Duplicate enqueue events are not deducted repeatedly. Connections whose entry is explicitly closed and can no longer be enqueued are also deleted from the waiting list. During this process, connections that have not yet obtained enqueue results continue to occupy the admission budget across periods and cannot be cleared uniformly at the end of the window. Connections not enqueued after the completion deadline are first checked for ingress connection status. Connections still existing and potentially capable of submitting services continue to be counted, while released connections are removed based on release events. If feedback is lost and the status cannot be confirmed, the addition of new connections is paused. The service completion rate only reads the result of the most recent valid complete control cycle; service completion counts do not include cancellations or abnormal releases. When the upper limit of the acceptance rate is lower than the current new connection release rate, the recovery increment is set to 0, and the new connection release rate is reduced by the upper limit of the acceptance rate, allowing it to be lower than the normal execution lower limit. Recovery is paused when the current capacity budget expires or a valid service completion rate is not achieved. For cycles where the queue was previously zeroed, the saturation service completion rate is not updated; the most recent valid value can be retained if the healthy instance range and capacity configuration remain unchanged, and the budget is verified using the actual number of enqueued and dequeued connections in the current cycle. The upper limit of the acceptance rate can be written as: , in, Indicates the first The upper limit for the new connection acceptance rate in the next cycle, formed by a complete control cycle, is measured in the number of new connections allowed per second. This represents the total effective connection queue capacity within the same healthy instance, measured in the number of connections.

[0096] In some embodiments of this application, the slope increment is obtained by dividing the difference between the target response delay value and the actual response delay by the target response delay value, truncating it non-negatively, and then multiplying it by a preset recovery slope and control period. The target value and actual delay are read in the same period, and the target value must still be greater than 0. The slope increment decreases accordingly when the response delay approaches the target value, and becomes 0 when the target value is reached; only when the delay falls below the target value and the difference increases is the recovery margin gradually released. The preset recovery slope is determined from the entry execution delay and service feedback response in isolated operation, taking the rate of change that allows for complete feedback after a single increase before further adjustments, and does not increase with a sudden surge in single window requests.

[0097] Based on this, the difference between the upper limit of the acceptance rate and the current new connection release rate is truncated to a non-negative value, and the minimum value of this difference and the slope increment is taken as the periodic increment. When the upper limit of the acceptance rate is lower, the new connection release rate is reduced by this upper limit. The recovery amount is constrained by both the remaining number of connections that can be accepted and the response delay margin. Before calculation, it is re-verified that the result of the previous increase in release has been fed back, the current service capacity has not changed, and the attack evidence is still in a state of disappearance. If it fails, the increment is directly kept at 0. For example, using the observation results of the current effective control period, the periodic increment can be written as: , in, Indicates the first Each complete control cycle increments the new connection release rate based on the admission budget and response latency margin, measured in the number of new connections allowed per second. This represents a preset recovery slope that is strictly greater than 0, measured in terms of the change in the new connection release rate per second. For example, the connection queue capacity is 600, the queue occupancy target is 100, the queue occupancy is 100, the service completion rate is 200 connections completed every 1 second, the control period is 1 second, the number of connections actually released but not yet enqueued is 50, the re-enqueue reserve for established connections is 0, and the upper limit of the acceptance rate is 150 new connections accepted every 1 second. The current new connection release rate is 300, the response latency is 0.25 seconds, the response latency target is 0.5 seconds, the preset recovery slope is a new connection release rate increasing by 100 every 1 second, the slope increment is 50, the difference between the upper limit of the acceptance rate and the current rate is truncated to 0 (non-negative), and the increment per cycle is 0. Simultaneously, the entry point lowers the new connection release rate to 150, waiting for complete feedback before recalculating.

[0098] Furthermore, if the completion deadline statistics or concurrent service feedback for the last increase in release are not available, the increment will be reset to zero on a cycle-by-cycle basis. The same applies when the number of healthy instances, their identities, or connection queue capacity changes. The increment will be recalculated after the service capacity retest for the new complete control cycle is effective. The complete request window first affected by the new rate is identified based on execution time, and the system waits for all relevant completion deadlines within that window to expire. During this period, the service side continues sampling, and the next increment is only calculated when both network statistics and concurrent service feedback are available. If a control cycle has passed but the completion deadline has not yet ended, the increment remains at 0. If the current service feedback has deteriorated, the deterioration is addressed first, and the increment is not increased because network results are still pending.

[0099] Based on this, service capacity changes have an independent pausing effect. When the number of healthy instances or the connection queue capacity changes, the periodic increment is reset to zero. After obtaining the service capacity retest results for the new complete control cycle, the periodic increment is recalculated. Once the capacity change is confirmed, the use of the current recovery budget ends. Add commands that have not yet been executed are cancelled. For already executed add commands, the actual execution record is retained, and the queued and actually released but not yet enqueued connections are rechecked to prevent already accepted requests from being treated as available space again. When the retest result is invalid, the increment remains at 0. Healthy instance recovery must wait for the new complete cycle and cannot directly restore the old budget. If the identity of a healthy instance is changed, even if the number remains the same, the service completion rate and the retained amount of established connections re-enqueued for the original instance range become invalid, and a new complete cycle is collected.

[0100] In this embodiment, the new connection release rate is updated incrementally on a cycle-by-cycle basis. The actual release volume and service feedback are reviewed. When attack evidence reappears, recovery stops and bounded proportional integral adjustment is performed, and the monitoring results are updated. Update requests do not exceed the upper limit of the normal operation configuration of the ingress point. After the ingress point returns the actual new connection release rate, the actual release volume of the complete control cycle is calculated, and it is compared whether the newly admitted connections form the expected queue change. The corresponding fixed connection request rate, handshake completion rate, and bidirectional response rate are read. If the actual release volume does not increase with the command, it is checked whether the requests are insufficient and whether the ingress point has actually executed the command. Unverified increases are not further accumulated.

[0101] Furthermore, during the recovery period, the established attack confirmation criteria continue to be used. Recovery is halted and bounded proportional integral adjustment is performed when attack evidence reappears. Simultaneously, the network anomaly traffic monitoring results for the electronic examination are continuously updated. Unexecuted addition commands are first stopped, and then the proportional integral starting point is re-established based on the most recent actual execution rate and current effective service feedback. When network statistics meet the pressure and insufficient progress conditions but continuous service exceedance has not yet been confirmed, new additions are suspended while accumulation continues. Adjustments for the attack duration phase are executed after the confirmation length is reached. Monitoring results are generated according to processing windows and control cycles, outputting attack confirmation, integral freezing, service capacity retesting, and recovery status, and associating these statuses with fixed network statistics and actual execution results. The receiving end replaces the corresponding results according to the window time and control order. Late events can only supplement their respective processing processes and cannot cover more recent effective statuses. Additions stop after reaching the normal operating rate limit, and network traffic and service feedback are collected again. When anomalies matching the confirmation criteria reappear, they are still entered into adjustment through the same monitoring chain, and monitoring during the electronic examination period is not stopped due to the completion of a recovery.

[0102] Thus far, step S5 constrains the recovery starting point with service status compliance and the continuous disappearance of attack evidence, limits the increase in capacity by queue acceptance budget and response latency margin, and maintains continuous verification of the recovery process through completion deadline feedback and capacity change suspension rules, thereby generating continuously updated network abnormal traffic monitoring results.

[0103] In summary, this method identifies DDoS attacks when they occur simultaneously due to protocol obstruction and continuous pressure on service resources by correlating connection request rate, handshake completion rate, and bidirectional response rate with concurrent queue occupancy and response latency. It implements bounded proportional integral adjustment based on the actual allowance and protects established connections with continuous bidirectional responses. By freezing integrals, retesting service capacity, and correcting for changes in service resources based on target values, the recovery of the new connection allowance rate is constrained by attack evidence, the upper limit of the admission rate, and response latency. This reduces confirmation offset, excessive rate limiting, and recovery pressure fluctuations caused by legitimate concentrated access, thus maintaining the effective communication continuity of the electronic examination network.

[0104] In some embodiments of this application, a method for monitoring abnormal network traffic during electronic examinations is applied to an isolated operating environment for electronic examinations. For example, 1200 examination clients and 3 health service instances are set up. Using a unified login sequence, connection pressure, protocol progress, and service queue events are collected from the bidirectional packet collection interface at the service entry point, entry release records, and service queue events, respectively. Taking the start time of this continuous monitoring as 0s, observation continues until 80s. The initial new connection release rate is 300 connections released every 1 second. The attack status, the actual new connection release rate, and the established connection protection results are output.

[0105] A complete implementation process may include the following steps: Step 1: Load the statistical and control parameters for this run.

[0106] The parameters recorded during the normal testing phase include a 1-second window duration, a 3-second completion deadline, and a 50-ms event reception wait time. Service feedback is collected every 100ms. The connection request rate is capped at 1000 initial requests per second, the handshake completion rate and bidirectional response rate are both capped at 90%, the queue usage is capped at 350, and the response latency is capped at 0.5s. All boundaries are derived from the ranking position of the corresponding normal indicators: the connection request rate, queue usage, and response latency use the 99.5th percentile, while the handshake completion rate and bidirectional response rate use the 0.5th percentile.

[0107] Records used for reviewing continuous exceedances are read separately from records forming indicator boundaries. The longest continuous exceedance segment contains two windows, and the confirmation length is 3. The longest interaction interval for normal exam client resource loading, automatic saving, and submission is 2.4s, the observation period is set to 5s, and the connection idle timeout is set to 60s. The control cycle is 1s, the proportional gain is 80, and the integral gain is 20. The lower limit for the new connection release rate is 200 connections per second, and the upper limit is 300 connections per second. The initial queue occupancy target value is 400, the response latency target value is 0.5s, and each of the three healthy instances provides a queue capacity of 200 connections, for a total connection queue capacity of 600. The re-enqueue retention of established connections is the maximum number of established connections re-enqueued in the three most recent consecutive valid complete control cycles, with the three valid cycles before 20s having a retention of 0.

[0108] Step 2: Link the initial request, entry permission, and cross-window protocol progress.

[0109] During the window from 0s to 1s, 1120 synchronization request messages were received. After merging 120 retransmission requests based on the connection 5-tuple and initial sequence number, the initial request count was 1000. The ingress allowance record matched 300 of these initial requests, resulting in 300 actually allowed requests. Within the completion deadline, 294 connections completed handshakes, and 288 connections achieved server response and client feedback matching, resulting in a handshake completion rate of 98%. The bidirectional response rate, rounded to four decimal places, was 97.9592%. The connection request rate equals the upper limit, and no attack evidence is accumulated in the current window.

[0110] The initial request for a connection within this window arrived at 0.8s, was actually allowed through at 0.9s, and reached its completion deadline at 3.9s. The client's initial sequence number was 1000, and the server's initial sequence number was 5000. The handshake acknowledgments overwrote the sequence positions occupied by the corresponding synchronization messages. A server response with an initial sequence number of 5001 and a payload length of 200B was received at 1.2s. The client's acknowledgment number of 5201 was received at 1.25s. This acknowledgment number overwrote the server's response and did not exceed the server's next sending sequence number, thus forming a bidirectional response completion record. This record is still included in the window containing the initial request from 0s to 1s.

[0111] For subsequent retransmissions of responses with the same sequence and identical client acknowledgments for this connection, the existing completion record is retained, and the count remains at 1. Other actual release requests also wait for their respective release times to complete their respective deadlines. After verifying all deadlines and events within the 4.05s window, the statistical result is fixed. The number of connections that have completed handshakes and the number of connections that have completed bidirectional responses are read based on the connection's 5-tuple and initial sequence number. All 288 connections belong to the 294 connections that have already completed handshakes; this fixed result is then submitted to the concurrent service for feedback comparison.

[0112] Step 3: Distinguish between legitimate centralized access and observation interruption within the continuous window.

[0113] During the 1-2 second window, 1560 synchronization request messages were received. After merging 360 retransmission requests, 1200 initial requests were obtained. The actual number of requests allowed remained at 300, the number of handshake-completed connections was 294, and the number of bidirectional response-completed connections was 288, resulting in a handshake completion rate of 98% and a bidirectional response rate of 97.9592%. Before the window ended, the queue occupancy at the same valid sampling point was 340, with a response latency of 0.4 seconds. The connection request rate had exceeded the limit, but the handshake completion rate and bidirectional response rate both met the standards, and the service feedback did not exceed the limits. The number of consecutive windows remained at 0, and the entry point continued to execute the configuration of allowing 300 connections every 1 second. The synchronous response latency was calculated by averaging the completed service time and the incomplete service waiting time during this queuing process. Connections still in the queue across windows retained their original queuing time, and connections currently being served remained in the queue. Queue event positions read sequentially from the sampling positions were consistent, and this service feedback was submitted. Enqueue and completion events were assigned to a unique period based on their actual occurrence time, and the release volume was counted separately.

[0114] In the 8-9 second window, the initial request count was 1100, the actual number of allowed requests was 300, the number of handshake connections completed within the deadline was 0, the handshake completion rate was 0, and the bidirectional response rate was in a missing state. The concurrent queue occupancy was 360, the response latency was 0.6 seconds, a handshake anomaly flag was generated, and the number of consecutive windows was recorded as 1 after statistical fixing. In the 9-10 second window, service feedback was interrupted, lacking complete queue occupancy and response latency data for the same sampling point. When processing this window, the number of consecutive windows was reset to 0. After feedback is restored, the count is recalculated, and the previous window is not concatenated with the interrupted window.

[0115] Step 4: Use the protocol anomaly marker to switch and complete the attack confirmation.

[0116] From 10s to 11s, the initial number of requests was 1200, the actual number of requests allowed was 300, the number of connections completed through handshake was 120, the number of connections completed through bidirectional responses was 108, the handshake completion rate was 40%, the bidirectional response rate was 90%, the concurrent queue usage was 400, and the response latency was 0.6s. From 11s to 12s, the initial number of requests was 1250, the actual number of requests allowed was 300, the number of connections completed through handshake was 285, the number of connections completed through bidirectional responses was 171, the handshake completion rate was 95%, the bidirectional response rate was 60%, the concurrent queue usage was 450, and the response latency was 0.7s.

[0117] The initial request count between 12 and 13 seconds was 1300, with 300 requests actually allowed. The number of handshake-completed connections was 270, and the number of bidirectional response-completed connections was 135. The handshake completion rate was 90%, the bidirectional response rate was 50%, the concurrent queue usage was 500, and the response latency was 0.75 seconds. The three windows were arranged consecutively according to the initial request origin. Each window met the criteria of exceeding the connection request rate limit, having at least one insufficient protocol ratio, and exceeding both service feedback limits, generating handshake anomaly, response anomaly, and response anomaly flags respectively. Windows with a handshake completion rate of 90% were treated as compliant, but continued to generate response anomaly flags based on the insufficient bidirectional response rate.

[0118] The statistical results of these three windows are fixed at 14.05s, 15.05s, and 16.05s respectively, with the number of consecutive windows being 1, 2, and 3. After the confirmation length is reached at 16.05s, the DDoS attack is confirmed, and the trigger window and service feedback are handed over to the ingress adjustment. Attack confirmation uses the service feedback saved concurrently in each window, and the ingress adjustment also reads the queue occupancy and response latency of the latest complete control cycle.

[0119] Step 5: Perform bounded proportional integral adjustment and obtain the actual release result.

[0120] When adjustment begins at 17s, the latest queue occupancy is 500, and the response latency is 0.75s. This represents a difference of -0.25 and -0.50 relative to the target values ​​of 400 and 0.5s, respectively. The current control error is set to -0.50. Upon initial attack handling, the previous control error is also set to -0.50, the proportional increment is 0, and the effective integral increment is -10. The currently confirmed rate of new connection release is as follows. Set the gain to 300. Take 80, and execute the lower bound. Take 200, and execute the upper limit. Take 300, substitute each value into the constrained new connection release rate update relationship, and the new connection release rate formed by this service feedback is obtained. The entry point was set at 290. At 17s, the entry point switched to allowing 290 connections per second, and returned an execution confirmation including the actual execution time at 17.01s. From 17s to 18s, the cumulative allowed count increased from 10000 to 10290, with an actual allowed count of 290; the number of queued connections was 270, the number of connections dequeued after service completion was 280, the number of connections released was 10, the queue occupancy decreased from 500 to 480, the response latency was 0.625s, and the number of connections actually allowed but not yet queued was 20.

[0121] The current control error becomes -0.25, the proportional increment is 20, the integral increment is -5, and the sum is 305. After executing the upper limit truncation and unidirectional adjustment constraints during the attack, the entry point continues to execute 290. From 18s to 19s, the actual number of connections allowed is 290, the number of queued connections is 300, including 20 connections that were not yet queued in the previous cycle, the number of connections dequeued after service completion is 270, the number of connections released is 10, the queue occupancy rises back to 500, the response latency rises to 0.75s, and the number of connections actually allowed but not yet queued is 10. The control error returns to -0.50, the proportional increment is -20, the integral increment is -10, and at 19s, the new connection allowance rate of 260 is obtained and executed.

[0122] Step 6: Continuously verify the established connection protections under the same exit address.

[0123] The entry point reads the most recent completion time and the range of unacknowledged sequence numbers from the server for each established connection. Two established connections with source ports 52000 and 52001 under the same egress address are selected, and their connection 5-tuples and initial sequence numbers are saved. Both connections receive a valid bidirectional response every 16 seconds. The established connection with source port 52000 receives a client acknowledgment number 12401 at 18.2 seconds, overwriting the initial sequence number 12201 and the new server response with a payload length of 200 bytes. The acknowledgment number is equal to the server's next sending sequence number, and the most recent completion time is updated to 18.2 seconds.

[0124] When the same acknowledgment number is received again at 18.3s, the most recent completion time remains at 18.2s. At 19s, a check shows an elapsed time of 0.8s, with a remaining observation period of 4.2s, and forwarding continues. New bidirectional responses are formed at 20.4s and 22.6s, subsequently maintaining a valid interaction interval of no more than 2.4s. The established connection on source port 52001 only re-acknowledges the existing sequence number at 18s, with the most recent completion time remaining at 16s. At 21s, the remaining observation period reaches zero, and the connection protection is cancelled. The established connection on source port 52000 under the same egress address continues forwarding, while the connection on source port 52001 awaits release according to the 78s idle timeout endpoint recorded at the ingress.

[0125] Step 7: Identify the continued deterioration of service after the actual release rate drops and freeze the adjustment.

[0126] From 19s to 20s, the actual number of connections allowed was 260, and the cumulative entry allowance count increased from 10580 to 10840. During this period, the number of queued connections was 250, the number of connections dequeued after service completion was 210, the number of connections released was 10, queue occupancy increased from 500 to 530, response latency increased from 0.75s to 0.8s, and the number of connections actually allowed but not yet queued increased to 20. Both 18s to 19s and 19s to 20s are control periods covering the full duration after the corresponding new connection allowance rate takes effect. The actual number of connections allowed from 18s to 19s (290) is lower than the 300 of the full period before the 17s change, and the actual number of connections allowed from 19s to 20s (260) is lower than the 290 of the full period before the 19s change.

[0127] Based on the parameter records showing a temporary increase of at most one complete cycle after normal speed reduction, the number of complete control cycles required for this continuous increase judgment is set to 2. Queue occupancy continuously increased from 480 to 500 and 530, and response latency continuously increased from 0.625s to 0.75s and 0.8s, triggering a service capacity retest after 20 seconds. The newly established connection release rate of 260, which was most recently confirmed, was locked, the integration status was frozen, and the issuance of speed reduction commands at new proportional increments was stopped, maintaining a 260-connection release rate at the entry point every 1 second. Execution confirmation and complete cycle count were handed over to queue income and expenditure verification.

[0128] Step 8: Review the queue's income and expenditure and correct the target value in groups.

[0129] From 20s to 21s, the actual number of connections allowed was 260, and the number of queued connections was 270. This includes 20 connections that were not yet queued in the previous period and 250 connections that were queued after being allowed in the current period. The number of connections actually allowed but not yet queued is 10. The number of connections dequeued upon service completion was 250, and the number released was 10. The queue occupancy at the start of the period was 530, resulting in an estimated queue occupancy of 540 at the end of the period. The directly sampled queue occupancy was also 540, with an absolute difference of 0. Checking along the order of enqueue and dequeue events, the number of queued connections was always non-zero, with a minimum of 280. Service feedback covered the entire period.

[0130] The tolerance, read from the normal sampling error record, is 10, and the absolute value of the difference is within the tolerance. All three healthy instances can return service probe results and valid queue information. The connection queue capacity remains at 600, and the service completion rate retest is 250 connections completed per second. The average maximum duration from queuing to service completion for a normal test connection is 0.5 seconds, the response latency target remains at 0.5 seconds, and the queue occupancy target is corrected to 125. Both targets take effect simultaneously at 21 seconds. The response latency at 21 seconds is 0.82 seconds, and the queue occupancy is 540. The freeze continues, maintaining an execution rate of 260. The re-queuing retention of established connections in this period is 0, the service completion rate of 250 is lower than the lock rate of 260, and the number of valid retest periods with persistent capacity shortage is recorded as 1.

[0131] From 21s to 22s, the actual number of connections released and enqueued was 260, the number of connections dequeued upon service completion was 320, and the number of connections released was 0. At the end of the cycle, the queue occupancy dropped to 480, and the cumulative events were consistent with direct sampling. The service completion event indicated a recovery in processing capacity. The minimum queue occupancy checked along the complete cycle was 220, resulting in a valid retest result of 320 connections completed per second. Combining the connection queue capacity of 600 and the response latency target of 0.5s, the queue occupancy target was corrected to 160 and grouped into effect at 22s, initiating a new complete control cycle. The service completion rate of 320 was higher than the locking rate of 260, and the number of valid retest cycles with insufficient capacity was reset to 0. This timeline did not trigger capacity protection rate reduction.

[0132] Step 9: After the target value takes effect, observe the queue fall back and the freeze is lifted.

[0133] During the three consecutive complete control cycles from 22s to 25s, the actual number of connections released was 260, the number of connections enqueued was 260, the number of connections dequeued upon service completion was 320, and the number of connections released was 0. The queue occupancy decreased to 420, 360, and 300 respectively. The original instance range was maintained in each cycle, the entry point remained at 260 confirmed executions, the points status remained frozen, and the number of connections actually released but not yet enqueued remained at 10.

[0134] From 25s to 26s, the number of initial requests decreased, with an actual allowed throughput of 180. The 10 connections not yet queued in the previous cycle were enqueued along with the 180 connections in this cycle, bringing the total number of queued connections to 190. The number of connections dequeued after service completion was 320, queue usage decreased to 170, and response latency was 0.55s. The number of connections actually allowed but not yet queued returned to zero. At this point, both feedback values ​​were still higher than their respective target values, so the freeze continued. From 26s to 27s, both the actual allowed throughput and the number of queued connections remained at 180, the number of connections dequeued after service completion was 320, queue usage decreased to 30, and response latency was 0.25s.

[0135] After 27 seconds, the system checks that the new target has covered the entire control cycle, queue occupancy is no more than 160 (30), response latency is no more than 0.5 seconds (0.25s), and the integral freeze is lifted. The actual execution rate of 260 at the entry point is read as the starting point for the bounded proportional-integral adjustment output. The current control error is 0.50, and the previous control error is reset to 0.50. Control increments not executed during the freeze period are cleared. The entry point is temporarily maintained at 260, awaiting a continuous window of verification after the attack evidence disappears.

[0136] Step 10: Wait for the deadline to close and accumulate exit conditions.

[0137] The windows containing the initial requests from 25s to 26s, 26s to 27s, and 27s to 28s were read sequentially. The number of initial requests was 180, 180, and 280 respectively, and the number of actually allowed requests was 180, 180, and 260 respectively. All actually allowed connections completed handshakes and bidirectional responses within the completion period, with a handshake completion rate and bidirectional response rate of 100%. The connection request rate for these three windows did not exceed the limit, and the statistical results were fixed at 29.05s, 30.05s, and 31.05s respectively, based on their respective completion periods and 50ms event wait times.

[0138] The number of consecutive windows where attack evidence disappears starts from 0, and is recorded as 1, 2, and 3 after these 3 statistical fixes. The longest interaction interval for normal exam network traffic is 2.4 seconds, the window duration is 1 second, and the exit length is set to 3, which is satisfied with 31.05 seconds. During this period, the entry point remains at 260, and service feedback continues to be collected; the next window, which has not yet been fixed, is not prematurely added to the exit count.

[0139] During the four control cycles from 27s to 31s, the number of enqueued connections was 260, 260, 250, and 250 respectively; the number of connections dequeued upon service completion was 250, 240, 240, and 240 respectively; the number of connections released was 0; the queue occupancy was 40, 60, 70, and 80 respectively; and the number of connections actually allowed but not yet enqueued was 0, 0, 10, and 20 respectively. From 31s to 32s, 260 new connections were allowed, bringing the total number of enqueued connections to 340, of which 260 were from newly established connections and 80 were from repeat service requests from established connections. The number of connections dequeued upon service completion was 320; the number of connections released was 0; the queue occupancy was 100; the response latency was 0.4s; and the number of connections actually allowed but not yet enqueued was 20.

[0140] Step 11: Resume access according to the new service feedback and wait for the statistical results after the increase.

[0141] At 32 seconds, the current connection queue capacity is checked (600), the target queue occupancy is 160, and the queue occupancy is 100, yielding a remaining queue capacity of 60. Queue events from 31 to 32 seconds are consistent with direct sampling; the queue size remains non-zero, and the service completion rate is 320 connections completed per second. The number of established connections re-queued in the last three consecutive valid complete control cycles is 0, 0, and 80 respectively, resulting in a re-queuing reserve of 80 established connections. Combined with 20 connections that were actually allowed but not yet queued, the upper limit of the acceptance rate is determined. The current rate for allowing new connections is 280. The response latency is 260. The target response delay is 0.4s. The preset recovery slope is 0.5s. The new connection release rate is set at 100 per second, and the cycle-by-cycle increment is calculated based on the admission budget and response latency margin. The maximum allowable increase in the admission rate is 20, and the corresponding slope increment for the response latency is 20. The cycle-by-cycle increment is calculated accordingly. The new connection release rate was increased from 260 to 280 at 20 and 32 seconds, and an execution confirmation was obtained with an actual execution time of 32 seconds. From 32 to 33 seconds, the initial request count was 360, the actual number of released requests was 280, the number of handshake-completed connections was 274, and the number of bidirectional response-completed connections was 268, resulting in a handshake completion rate of 97.8571% and a bidirectional response rate of 97.8102%. All completion deadlines and event waits for this window ended at 36.05 seconds.

[0142] The recovery calculations from 33s to 36s will be incrementally reset to zero each cycle, with the entry point remaining at 280, continuously receiving feedback from concurrent services. During the four complete control cycles from 32s to 36s, the actual number of connections allowed is 280, the number of connections enqueued is 280, 280, 300, and 280 respectively, the number of connections dequeued upon service completion is 300, 300, 300, and 280 respectively, the number of connections released is 0, and the queue occupancy is 80, 60, 60, and 60 respectively. The number of connections actually allowed but not yet enqueued is reset to zero at 35s.

[0143] From 36s to 37s, the actual number of connections allowed was 280, and the number of queued connections was 320, including 40 re-service requests from established connections. The number of connections dequeued after service completion was 320, the queue occupancy remained at 60, and the response latency was 0.4s. Network statistics and concurrent service feedback were complete. The number of healthy instances and connection queue capacity remained unchanged. The number of re-queued established connections in the last three consecutive valid and complete control cycles was 0, 0, and 40, respectively. The re-queuing retention of established connections was 40. The remaining queue capacity was restored to 100, the acceptance rate limit was 380, and the slope increment was 20, with a cycle-by-cycle increment of 20. At 37s, the new connection allowance rate was increased to 300, reaching the normal execution limit for this period.

[0144] Step 12: Confirm the recovery results and complete the connection processing and monitoring output.

[0145] From 37s to 38s, the initial request count was 360, the actual number of requests allowed was 300, the number of handshake-completed connections was 294, and the number of bidirectional response-completed connections was 288, resulting in a handshake completion rate of 98% and a bidirectional response rate of 97.9592%. This window ended its statistical wait at 41.05s, maintaining a 300-connection execution configuration throughout. From 37s to 38s, both the number of enqueued connections and the number of service-completed dequeued connections were 300, with queue occupancy remaining at 60. From 38s to 39s, both the actual number of requests allowed and the number of enqueued connections were 280, the number of service-completed dequeued connections was 300, and queue occupancy decreased to 40.

[0146] From 39s to 42s, the actual number of connections allowed, the number of inbound connections, and the number of services completed and dequeued were all 280 for each complete control cycle, the number of connections released was 0, the queue occupancy remained at 40, and the response latency at 42s was 0.2s. Based on the established network statistics, it was confirmed that the evidence of this attack had continuously disappeared, the points freeze had been lifted, and the rate of new connection allowances had recovered. The trigger window, anomaly marker, execution confirmation, actual allowed number of connections, queue occupancy, response latency, and target value were saved, and the current abnormal network traffic monitoring results were sent back to the result receiving end.

[0147] The receiving end reads updates according to window time and control order, and previously delayed events are only updated in the corresponding window. Established connections on source port 52000 continue to generate valid bidirectional responses and are forwarded; established connections on source port 52001, after being unprotected at 21 seconds, no longer generate valid bidirectional responses, and reach the ingress idle timeout endpoint at 78 seconds and are released. Network statistics obtained up to 80 seconds did not generate new attack confirmations, the ingress maintained a maximum of 300 new connections allowed per second, and bidirectional packet collection and service feedback collection continued.

[0148] Through the complete implementation process described above, this method incorporates the connection pressure caused by legitimate centralized access to electronic examinations and the obstruction of protocol interactions into the verifiable attack confirmation scope. This ensures that established connections with effective bidirectional responses maintain continuous communication during the tightening of access points, and allows for independent verification of service capacity changes after rate limiting. The restoration of access is simultaneously constrained by service capacity, response latency, and new statistical results, helping to reduce over-processing caused by legitimate traffic peaks and repeated service pressure during the recovery phase, thereby improving the stability of the connection between abnormal traffic monitoring and access control in the electronic examination network.

[0149] The above embodiments are used to illustrate the technical solutions of this application. Equivalent substitutions, improvements, or combinations made by those skilled in the art based on the disclosure of this application shall still fall within the protection scope defined by this application.

Claims

1. A method for monitoring abnormal network traffic during electronic examinations, characterized in that, include: Step S1: Collect network traffic for the electronic examination, calculate the connection request rate according to the window to which the TCP first request belongs, set a completion deadline from the actual release date, use the ratio of the number of handshake-completed connections within the completion deadline to the actual number of released requests as the handshake completion rate, and use the matching ratio of server response and client return in the already handshake-connected connections as the bidirectional response rate. Step S2: Collect the number of concurrent connections in the queue as queue occupancy, and use the average of the completed service duration and the uncompleted service waiting duration as the response latency. When the connection request rate exceeds the limit, the handshake completion rate or the bidirectional response rate is insufficient, and the queue occupancy and response latency continue to exceed the limit, a DDoS attack is confirmed. Step S3: Subtract the actual value from the positive target value of queue occupancy and response delay, divide by the corresponding target value, take the minimum value for bounded proportional integral adjustment, reduce the new connection release rate, protect the established connections with continuous bidirectional response, and count the actual release volume. Step S4: When the actual number of connections released decreases while the queue occupancy and response latency continue to increase, freeze the points and maintain the rate of new connection release, retest the service capacity and correct the target value. If the capacity is insufficient, reduce the new connection release rate by deducting the admission budget based on the queue exceeding the target amount. Step S5: Unfreeze when queue occupancy and response latency are not higher than their respective target values. After verifying that the evidence of the DDoS attack has disappeared, gradually restore the new connection release rate according to the acceptance budget after deducting the re-entry reserve of established connections. Update the network abnormal traffic monitoring results of the electronic examination.

2. The method for monitoring abnormal network traffic in electronic examinations as described in claim 1, characterized in that, Step S1 specifically includes: Divide the window into equal-length windows based on the arrival time of the first TCP request, identify the first request according to the connection 5-tuple and the initial sequence number, merge and count retransmission requests of the same connection, and calculate the connection request rate based on the ratio of the number of first requests to the window length. The initial request is matched with the entry release record. For the actual release request, a completion deadline covering the handshake and bidirectional response matching is set from the release time. Connections that complete the handshake within the completion deadline are counted in the window to which the initial request belongs. The handshake completion rate is calculated as the ratio of the number of handshake-completed connections to the number of actual release requests. Match the client acknowledgment number or subsequent application message according to the sequence number range of the server response. Deduplicate the connections that are matched within the completion period by the connection 5-tuple and the initial sequence number and include them in the window to which the first request belongs. Divide the number of deduplicated connections by the number of handshake-completed connections to obtain the bidirectional response rate. After all completion periods are over, fix the statistical results. When the denominator is zero, output the corresponding proportion of missing test status.

3. The method for monitoring abnormal network traffic in electronic examinations as described in claim 2, characterized in that, Step S2 specifically includes: The upper limit of connection request rate, handshake completion rate and lower limit of bidirectional response rate are determined based on the window where the completion deadline has expired in the normal examination network traffic, and the upper limit of queue occupancy and response latency are determined based on service feedback. Collect the number of connections in the queue, and average the completed service duration of completed service connections within the window with the incomplete service waiting time of the queued connections at the comparison point as the response latency. Align the window to which the first request belongs according to the sampling time, and reset the number of consecutive windows for windows with missing handshake completion rate and bidirectional response rate or interrupted service feedback. Compare the fixed statistical results with the upper and lower limits, and only for windows where the connection request rate exceeds the limit and at least one of the handshake completion rate and bidirectional response rate is insufficient, accumulate the number of consecutive windows where both queue occupancy and response latency exceed the limit; Compare the number of consecutive windows with the confirmation length. The confirmation length is the maximum number of consecutive windows exceeding the limit for normal network traffic plus 1. When the confirmation length is reached, a DDoS attack is confirmed. If the cumulative condition is not met, the number of consecutive windows is reset.

4. The method for monitoring abnormal network traffic in electronic examinations as described in claim 3, characterized in that, The steps involve comparing the number of consecutive windows with the confirmation length. The confirmation length is the maximum number of consecutive windows exceeding the limit for normal exam network traffic plus 1. A DDoS attack is confirmed when the confirmation length is reached. If the cumulative condition is not met, the number of consecutive windows is reset. These steps specifically include: For windows that meet the cumulative conditions, generate handshake anomaly flags and response anomaly flags based on insufficient handshake completion rate and normal handshake completion rate but insufficient bidirectional response rate, respectively, and record one anomaly flag for each window; When adjacent windows have handshake error flags and response error flags respectively, check that the connection request rate, queue usage and response latency of both windows exceed the limits, and count the adjacent windows into the same consecutive window count. For windows where the number of handshake-completed connections is zero but the number of actual allowed requests is not zero, a handshake error flag is generated based on the handshake completion rate. For windows where the number of actual allowed requests is zero or the service feedback is interrupted, the number of consecutive windows is reset. When the number of consecutive windows is not less than the confirmation length, the DDoS attack is confirmed. The number of consecutive windows is reset for windows where the connection request rate does not exceed the limit, the handshake completion rate and the bidirectional response rate all meet the standards, or the queue occupancy and response latency are at least not exceeded. The count starts again from the next window that meets the accumulation condition.

5. The method for monitoring abnormal network traffic in electronic examinations as described in claim 1, characterized in that, Step S3 specifically includes: The minimum value of the ratio between queue occupancy and response delay is used as the control error. The difference between adjacent control errors is multiplied by the proportional gain to calculate the proportional increment. The current control error, the duration of the control cycle, and the integral gain are multiplied to calculate the integral increment. This is then added to the last newly established connection release rate and truncated according to the execution range. The observation period is determined based on the network interaction interval of the normal examination client. The established connection is verified by the server response and client feedback within the observation period. The established connection with completed bidirectional response is forwarded, and the protection of the established connection that has exceeded the observation period and lacks bidirectional response is cancelled. During the duration of a DDoS attack, the minimum value between the truncation result and the current new connection release rate is used to update the new connection release rate. The incremental integral that continues to accumulate downward after reaching the lower limit is frozen. The actual release volume within the complete control cycle is calculated based on the difference in entry release count.

6. The method for monitoring abnormal network traffic in electronic examinations as described in claim 5, characterized in that, The observation period is determined based on the network interaction intervals of normal examination clients. Within the observation period, the established connection is verified by server responses and client feedback. Established connections with completed bidirectional responses are forwarded. Steps to protect established connections that have exceeded the observation period and lack bidirectional responses are cancelled. Specifically, this includes: The observation period is calibrated based on the network interaction interval formed by the normal examination client resource loading, automatic saving and submission. The observation period is set to be less than the connection idle timeout. The time when each established connection most recently completed a bidirectional response is recorded as the most recent completion time. The difference between the observation period and the time from the most recent completion time is truncated non-negatively to obtain the remaining observation period. The client's response is checked against the range of unconfirmed sequence numbers in the server's response. The client's confirmation number is verified to be no more than the next sequence number sent by the server. When the client's confirmation number covers the range of unconfirmed sequence numbers, the most recent completion time is updated and forwarding continues. For established connections that only require repeated confirmation of existing sequence numbers, retain the most recent completion time and perform protection verification according to the remaining observation period; When the remaining observation period reaches zero and no new bidirectional response is found, the established connection protection is cancelled and the connection is released according to the connection idle timeout. Other established connections that have completed bidirectional responses under the same egress address are maintained and forwarded.

7. The method for monitoring abnormal network traffic in electronic examinations as described in claim 1, characterized in that, Step S4 specifically includes: Using a preset equal-length time period as the control cycle, obtain entry execution confirmation, divide the complete control cycle before and after the effective time according to the actual execution time, and compare the actual release volume with the concurrent queue occupancy and response latency. When the actual number of connections released decreases and the queue occupancy and response latency increase continuously, the release rate of the most recently confirmed new connection is locked, and the points status is frozen. The service capacity was retested based on the number of healthy instances that could accept exam requests and return valid queue feedback, and the connection queue capacity was adjusted according to the service completion rate. If the service completion rate, after deducting the rate corresponding to the re-entry retention of established connections, is not higher than the locked new connection release rate for two consecutive valid retest cycles, the amount of service completions leaving the queue, the amount of waiting to be enqueued, the amount of re-entry retention of established connections, and the amount of queue exceeding the target are deducted from the amount of service completions leaving the queue. A non-negative truncation is then performed and divided by the control cycle. The new connection release rate is then reduced, and the points are kept frozen until the end of the complete control cycle after the new target takes effect.

8. The method for monitoring abnormal network traffic in electronic examinations as described in claim 7, characterized in that, Based on the number of healthy instances capable of accepting exam requests and returning valid queue feedback, and the connection queue capacity, the service capacity is retested. The steps for correcting their respective target values, combined with the service completion rate, specifically include: Verify the number of healthy instances, retain queued connections until service completion or exit, count the number of queued connections in the same control period, count the number of connections that leave the queue after service completion as the service completion dequeue quantity, and count other exits as the release quantity; Add the queue occupancy at the start of the cycle to the number of enqueued connections, and subtract the number of services completed and released to obtain the estimated queue occupancy at the end of the cycle. Then calculate the absolute value of the difference between this estimated value and the directly sampled value. Determine the tolerance based on the normal sampling error. During the complete control period when the queue occupancy is continuously non-zero and the absolute value of the difference is not greater than the tolerance, retest the service completion rate by dividing the service completion dequeue amount by the control period, and summarize the connection queue capacity of each healthy instance. When both the service completion rate and connection queue capacity are positive, the response latency target value is corrected by the upper limit of the average time from enqueuing to service completion of a normal test connection. The minimum value of the product of the service completion rate and the response latency target value and the connection queue capacity is used to correct the queue occupancy target value. Otherwise, if the absolute value of the difference exceeds the tolerance, the original target value is used.

9. The method for monitoring abnormal network traffic in electronic examinations as described in claim 8, characterized in that, Step S5 specifically includes: During the full control period after the new target takes effect, the points freeze is lifted when the queue occupancy and response latency are not higher than their respective target values, and the output starting point is reset at the current new connection release rate. If the connection request rate does not exceed the limit after the deadline, or if the connection request rate exceeds the limit but the handshake completion rate and bidirectional response rate are both valid and meet the standards, the cumulative number of consecutive windows in which the attack evidence disappears will be reset; otherwise, the exit length will be the rounded-up value of the longest interaction interval of the normal examination network traffic divided by the window duration, and it will be at least 1. When the number of consecutive windows reaches the exit length, the queue occupancy is reduced by the minimum value of the connection queue capacity and the queue occupancy target value, and the remaining queue capacity is obtained by non-negative truncation. The cycle-by-cycle increment of the new connection release rate is calculated based on the remaining queue capacity and the service completion rate. The new connection release rate is updated incrementally on a cycle-by-cycle basis. The actual release volume and service feedback are reviewed. When attack evidence reappears, the recovery is stopped and a bounded proportional integral adjustment is performed. The monitoring results are then updated.

10. The method for monitoring abnormal network traffic in electronic examinations as described in claim 9, characterized in that, When the number of consecutive windows reaches the exit length, the remaining queue capacity is obtained by subtracting the queue occupancy from the minimum value of the connection queue capacity and the target value of queue occupancy, and performing a non-negative truncation. The cycle-by-cycle increment of the new connection release rate is then calculated based on the remaining queue capacity and the service completion rate. This process specifically includes: The established connection re-enqueue reserve is the maximum number of established connections re-enqueued in the most recent 3 consecutive valid complete control cycles. The service completion rate is multiplied by the control cycle, the remaining queue capacity is added, the number of connections that have been actually released but not yet enqueued and the established connection re-enqueue reserve are deducted, and after non-negative truncation, the result is divided by the control cycle to obtain the upper limit of the admission rate. The slope increment is obtained by dividing the difference between the response delay target value and the response delay by the response delay target value, performing non-negative truncation, and then multiplying by the preset recovery slope and control period. The difference between the upper limit of the acceptance rate and the current new connection release rate is truncated to a non-negative value, and the minimum value of the difference and the slope increment is taken as the cycle-by-cycle increment. When the upper limit of the acceptance rate is lower, the new connection release rate is reduced according to the upper limit. If the completion deadline statistics or service feedback for the previous release are not obtained, the increment will be reset to zero on a cycle-by-cycle basis. The number of healthy instances, their identities, or the capacity of the connection queue will also be reset to zero when they change. The service capacity will be recalculated after the service capacity retest of the new complete control cycle is effective.

Images