Abnormal traffic processing method and apparatus

Abstract

Embodiments of the present application provide an abnormal traffic processing method and device, wherein the method comprises: obtaining a request message; the request message contains a request path of a request target interface; in response to a preset determination condition being met, marking the request message as abnormal traffic, and performing flow limiting on the request message, wherein the preset determination condition comprises: a dictionary tree of the target interface existing in a gateway memory, the request message comprising all candidate keys in the dictionary tree, a target feature key in the request message matching one candidate value in a candidate value set associated with the target candidate key. Through the present application, the technical problem that highly counterfeit, flexible and variable weak feature abnormal traffic cannot be efficiently discovered and processed in the related art is solved.

Description

Technical Field

[0001] This application relates to the field of platform operation and maintenance, and more specifically, to a method and apparatus for handling abnormal traffic. Background Technology

[0002] For weak features, namely, non-obvious, highly forged, flexible, and realistic abnormal traffic, the only way to handle abnormal traffic is through manual judgment or by using high-cost protection products to clean the traffic. This approach is characterized by low efficiency, high false positive rate, slow response, and high cost. Summary of the Invention

[0003] This application provides an abnormal traffic processing method and apparatus to at least solve the technical problem in related technologies of the inability to efficiently detect and process highly forged, flexible and changeable weak-feature abnormal traffic.

[0004] According to one aspect of the embodiments of this application, an abnormal traffic processing method is provided, the method comprising: acquiring a request message, the request message containing a request path of a target interface; in response to the satisfaction of a preset judgment condition, marking the request message as abnormal traffic and rate limiting the request message, wherein the preset judgment condition includes: the existence of a trie of the target interface in the gateway memory, the request message including all candidate keys in the trie, and the feature value of a target feature key in the request message that matches a target candidate key in the trie matching a candidate value in a set of candidate values ​​associated with the target candidate key.

[0005] According to another aspect of the embodiments of this application, an abnormal traffic processing apparatus is also provided, comprising: an acquisition module, configured to acquire a request message, the request message containing a request path of a target interface; and an abnormal traffic processing module, configured to, in response to a preset judgment condition being met, mark the request message as abnormal traffic and perform rate limiting on the request message, wherein the preset judgment condition includes: the existence of a trie of the target interface in the gateway memory, the request message including all candidate keys in the trie, and the feature value of a target feature key in the request message that matches a target candidate key in the trie matching a candidate value in a set of candidate values ​​associated with the target candidate key.

[0006] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed by a processor.

[0007] According to another aspect of the embodiments of this application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the steps in any of the method embodiments described above.

[0008] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to perform the steps of any of the above method embodiments through the computer program.

[0009] This application employs a triple-determination mechanism to efficiently detect and process highly forged, flexible, and weakly characteristic abnormal traffic. The first determination mechanism, by checking if the request link in the request packet has a trie in the gateway's memory, quickly identifies interfaces exhibiting abnormal traffic characteristics. Interfaces without abnormal traffic characteristics are directly allowed, avoiding complex feature matching for all request packets, significantly reducing unnecessary computational overhead and improving processing efficiency. The second determination mechanism, by checking if the request packet contains all candidate keys in the trie, ensures that the request packet possesses the basic characteristic pattern of abnormal traffic, avoiding misjudgments based on a single feature and improving accuracy. The third determination mechanism, by checking if the feature value of the target feature key in the request packet matches a candidate value in the candidate value set associated with the target candidate key in the trie, further ensures that the request packet's feature value conforms to the characteristic pattern of abnormal traffic, improving accuracy. This triple-determination mechanism ensures accuracy while improving efficiency, effectively solving the technical problem of efficiently detecting and processing highly forged, flexible, and weakly characteristic abnormal traffic in related technologies, thus improving the accuracy and efficiency of abnormal traffic identification. Attached Figure Description

[0010] Figure 1 This is a schematic diagram illustrating an application scenario of an abnormal traffic handling method according to an embodiment of this application;

[0011] Figure 2 This is a flowchart illustrating an optional abnormal traffic handling method according to an embodiment of this application;

[0012] Figure 3 This is a schematic diagram of an optional gateway processing flow according to an embodiment of this application;

[0013] Figure 4 This is a flowchart of an optional gateway memory traffic matching and hit determination process according to an embodiment of this application;

[0014] Figure 5 This is a flowchart of an optional asynchronous processing module according to an embodiment of this application for interface feature extraction.

[0015] Figure 6 This is a structural block diagram of an optional abnormal traffic processing device according to an embodiment of this application;

[0016] Figure 7 This is a computer system architecture block diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

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

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

[0019] According to one aspect of the embodiments of this application, an abnormal traffic handling method is provided. Optionally, in this embodiment, the above-described abnormal traffic handling method may be applied to, but is not limited to, situations such as... Figure 1The hardware environment shown includes terminal device 102, server 104, and gateway 106. Terminal device 102 is the terminal device initiating the request, which can be a personal computer, mobile phone, tablet computer, etc. Terminal device 102 sends a request message to gateway 106 via the Internet. Gateway 106 is a network device located between terminal device 102 and server 104, responsible for receiving the request message sent by terminal device 102, processing traffic, and routing forwarding. Server 104 is a server cluster that provides backend services. Terminal device 102 and gateway 106 are connected via the network, and terminal device 102 sends a request message to gateway 106. Gateway 106 and server 104 are connected via the network, and gateway 106 forwards normal traffic to server 104. Server 104 provides interface metadata from the interface documentation information library to gateway 106.

[0020] Server 104 can connect to terminal device 102 via a network and can be used to provide services (e.g., application services, etc.) to terminal device 102 or clients installed on terminal device 102. A database can be set up on server 104 or independently of server 104 to provide data storage services for server 104.

[0021] The aforementioned networks may include, but are not limited to, at least one of the following: wired networks and wireless networks. The aforementioned wired networks may include, but are not limited to, at least one of the following: wide area networks (WANs), metropolitan area networks (MANs), and local area networks (LANs). The aforementioned wireless networks may include, but are not limited to, at least one of the following: Wireless Fidelity (WIFI).

[0022] The abnormal traffic handling method in this embodiment can be executed by gateway 106. Figure 2 This is a flowchart illustrating an optional abnormal traffic handling method according to an embodiment of this application, as shown below. Figure 2 As shown, the process of this method may include the following steps:

[0023] Step S202: Obtain the request message, which contains the request path of the target interface.

[0024] Step S204: In response to the satisfaction of the preset judgment conditions, the request message is marked as abnormal traffic and the request message is rate-limited. The preset judgment conditions include: the gateway memory has a trie of the target interface, the request message includes all candidate keys in the trie, and the feature value of the target feature key in the request message that matches the target candidate key in the trie matches one of the candidate values ​​in the set of candidate values ​​associated with the target candidate key.

[0025] The abnormal traffic handling method in this embodiment can be applied to the field of platform operation and maintenance, and to the scenario of gateway traffic protection.

[0026] In the current cybersecurity environment, with the continuous evolution of network attack techniques, the characteristics of abnormal traffic are becoming increasingly difficult to identify. The discovery and handling of abnormal traffic mainly includes the following methods: First, manual discovery and targeted blocking, such as blocking specific IPs, accounts, or terminal devices. This method requires manual screening, judgment, and processing by technical personnel. Second, uniform rate limiting measures, such as rate limiting by IP, account, interface, or service. This method does not completely reject abnormal traffic but suppresses all access traffic, but traffic from normal sources may also be affected. Third, scoring requests or users to determine the risk level of traffic and deciding on specific actions based on the risk level. This method is relatively complex, requiring the collection of traffic behavior and data, and it also has a certain lag. Furthermore, this method is sensitive to identifying obviously abnormal, strong-feature traffic but has poor ability to distinguish weak-feature traffic. Fourth, directly using security products, such as WAF and DDoS protection products, which clean the traffic and directly handle malicious traffic. They are most effective against large-scale attacks, but require a high economic cost.

[0027] The relevant technologies can provide significant protection when facing their respective application scenarios, and these technologies are also the main protection methods in existing traffic protection devices. However, these technologies are mainly aimed at abnormal traffic with obvious characteristics, such as IPs that obviously come from abnormal environments or user agents that are obviously incorrect. However, they cannot achieve efficient, unified, effective, and low-cost abnormal traffic management for weak characteristics, that is, abnormal traffic that is not obvious, highly forged by the attacked party, flexible, and realistic.

[0028] To address the limitations of existing technologies in efficiently detecting and handling highly spoofed, flexible, and weakly characterized abnormal traffic, which often requires manual judgment or costly traffic cleaning, this embodiment pre-constructs a trie (presumably a dictionary of names of interfaces requested by request messages). By asynchronously processing the request messages at the gateway layer and matching the key and value in the request message with candidate keys and values ​​in the trie, a traffic determination result is obtained. This gateway-level traffic processing method enables anomaly detection before traffic enters the backend service, intercepting abnormal traffic in advance and preventing it from consuming normal service resources. Furthermore, the asynchronous processing mechanism avoids blocking the gateway's processing of current messages, ensuring normal gateway efficiency. By constructing a trie and performing triple determination, difficult-to-distinguish weakly characterized abnormal traffic can be identified and processed uniformly, efficiently, and effectively.

[0029] A request message is a network data packet sent by a client to a server to request a specific resource. It includes information such as the request domain name, request path, request headers, request body, and request parameters. The target interface refers to the specific interface provided by the backend service module requested by the request message; each interface has its specific functions and behaviors. In this application, the target interface is the interface provided by the backend service module matched by the request message through a link, and it forms the basis for feature extraction and trie construction. The gateway is an intermediate layer located between the client and the backend service, responsible for receiving client request messages, processing traffic, and routing forwarding. The gateway receives the request message, matches the target interface through the request path in the request message, and then performs abnormal traffic detection on the request message.

[0030] In this embodiment, a request message is marked as abnormal traffic if it meets preset judgment conditions. These preset judgment conditions are: first, the request link has a trie in the gateway's memory; second, the request message contains all the feature keys in the trie; and third, the feature value in the request message matches one of the candidate values ​​in the corresponding candidate value set in the trie. This embodiment employs a triple mechanism for abnormal traffic determination, which improves the accuracy and efficiency of abnormal traffic identification. The first mechanism checks whether the request link has a trie in the gateway's memory, quickly eliminating interfaces without abnormal traffic characteristics and reducing unnecessary computation. The second mechanism checks whether the request message contains all the feature keys in the trie, ensuring the request message has the basic characteristics of abnormal traffic and avoiding misjudgments. The third mechanism uses feature value matching for determination, further improving accuracy and efficiency and avoiding misjudgments that might result from perfect feature value matching. Through these three mechanisms, accuracy is guaranteed while efficiency is improved, with almost no increase in request link time.

[0031] Each interface corresponds to a trie. The trie of a target interface is a tree-like data structure built for that interface, used to store candidate key-value pairs. The trie structure includes a root node, candidate key nodes, and candidate value nodes. The root node is the starting node of the trie, representing the target interface itself. Candidate key nodes are children of the root node; each candidate key node corresponds to a candidate key and stores the name of the candidate key. Candidate value nodes are children of the candidate key nodes; each candidate value node corresponds to a candidate value and stores the possible values ​​of the candidate key. In this application, the trie is used to quickly match the characteristic keys and characteristic values ​​of request messages, improving the efficiency of abnormal traffic detection.

[0032] A trie consists of multiple candidate keys, each associated with a set of candidate values. Each candidate key refers to a field name frequently used by abnormal traffic. The set of candidate values ​​associated with each candidate key refers to the set of field values ​​repeatedly used by abnormal traffic and bound to each candidate key. The candidate keys in the trie are the field names stored in the trie that are frequently used by abnormal traffic. The candidate keys in the trie are derived by statistically analyzing the characteristic keys in request packets within a certain time range; they are the set of characteristic keys that frequently appear in abnormal traffic. The candidate values ​​in the trie are the set of field values ​​stored in the trie that are repeatedly used by abnormal traffic and bound to the candidate keys. The candidate values ​​in the trie are derived by statistically analyzing the characteristic values ​​in request packets within a certain time range; they are the set of characteristic values ​​that frequently appear in abnormal traffic.

[0033] In this embodiment, the trie of the target interface is pre-built. For example, a machine learning-based feature extraction method automatically identifies feature keys and feature values ​​in the request message by training a classification model, and then constructs a trie based on the identification results. Specifically, a large number of normal and abnormal traffic samples can be collected to train a binary classification model. The model input is each field of the request message, and the output is whether the field is a feature key. Through model prediction, feature keys can be automatically identified, and then the feature value distribution of these feature keys can be statistically analyzed to construct a trie. For example, a rule engine-based feature extraction method matches feature keys and feature values ​​in the request message using predefined rule templates, and then constructs a trie based on the matching results. Specifically, a series of rule templates can be defined, such as the request header containing a "User-Agent" field whose value differs from the normal value by more than a threshold, or the request parameters containing a "session_id" field whose value does not conform to the normal format, etc. These rule templates are used to match the request message, identify feature keys and feature values, and construct a trie.

[0034] The existence of a trie for a target interface in the gateway's memory indicates that the target interface has exhibited abnormal traffic characteristics that meet statistical thresholds within the most recent time window, and the gateway has already constructed a trie for this interface for abnormal traffic identification. Specifically, when the asynchronous processing module detects that the number of interface information entries with characteristic keys for a certain interface within a specified time range exceeds the statistical threshold, it will construct a trie for that interface and store the trie in the gateway's memory.

[0035] The request message includes multiple feature keys. Feature keys in a request message refer to key fields or parameters that characterize its features, such as specific fields in the request header or specific parameters in the request parameters. Feature values ​​in a request message refer to the specific values ​​corresponding to the feature keys, such as the specific value of a request header or the specific value of a request parameter. In this embodiment, the feature keys and feature values ​​in the request message are specific to a single request message and represent the actual field names and values ​​existing in the current request message; while the candidate keys and candidate values ​​in the trie are specific to the trie and are a set of field names and values ​​that frequently appear in abnormal traffic, obtained through statistical analysis of multiple historical request messages. It is understood that the feature keys and feature values ​​in the request message are dynamic, and each request message may have different feature keys and feature values; while the candidate keys and candidate values ​​are relatively static, representing a fixed set statistically obtained within a certain time window. In the process of abnormal traffic determination, it is necessary to match the feature key of the request message with the candidate key in the trie, and match the feature value of the request message with the corresponding candidate value set in the trie, so as to determine whether the request message is abnormal traffic.

[0036] The request message includes all candidate keys in the trie, which means that the request message may have the characteristics of abnormal traffic and requires further judgment.

[0037] A target candidate key is a candidate key in the trie that matches a specific feature key in the request message. In other words, a target candidate key is a field name frequently used by abnormal traffic. Specifically, when a feature key in the request message exactly matches a candidate key in the trie, that candidate key becomes the target candidate key. A target candidate key is a concrete instance of a candidate key in the trie that matches a feature key in the request message.

[0038] A target feature key is a feature key in a request message that matches a candidate key in the trie. Specifically, when a feature key in a request message exactly matches a candidate key in the trie, that feature key becomes the target feature key. A target feature key is a concrete instance of a feature key in a request message that matches a candidate key in the trie.

[0039] When the gateway receives a request message, it matches the feature key in the request message with candidate keys in the trie. When a feature key in the request message matches a candidate key in the trie: that candidate key in the trie becomes the target candidate key, and that feature key in the request message becomes the target feature key. Subsequently, the gateway checks whether the feature value of the target feature key matches a candidate value in the candidate value set associated with the target candidate key, thereby determining whether the request message is abnormal traffic. The candidate value set associated with the target candidate key refers to the set of field values ​​that are reused in abnormal traffic and bound to the target candidate key.

[0040] If the feature value of a target feature key in a request message that matches a target candidate key in the trie matches a candidate value in the set of candidate values ​​associated with that target candidate key, it means that the feature value of the target feature key in the request message exists in the set of candidate values ​​corresponding to the target candidate key in the trie. Specifically, each candidate key node in the trie stores all possible candidate values ​​for that candidate key. These candidate values ​​are derived by statistically analyzing request messages containing that candidate key within a certain time range. When the feature value of a certain feature key in a request message exists in the set of candidate values, it indicates that this feature value may be a feature value of abnormal traffic. When the feature values ​​of all target feature keys in a request message exist in their corresponding set of candidate values, it indicates that the request message has a pattern of abnormal traffic.

[0041] When a request message meets the above three criteria, it is marked as abnormal traffic. Abnormal traffic refers to traffic that does not conform to normal traffic characteristics and may harm the system, including but not limited to malicious attack traffic, crawler traffic, and abnormal access traffic. In this application, abnormal traffic refers to request messages that meet preset criteria. Although these request messages may superficially resemble normal traffic, their characteristic patterns indicate that they may be abnormal traffic. For example, abnormal traffic can be characterized by weak features.

[0042] When request messages are abnormal traffic, rate limiting is applied to them. This involves placing the request messages in a separate rate limiting pool to isolate them from normal traffic. Secondly, the request messages in the rate limiting pool are processed according to the rate limiting policy, such as delayed processing, rejection processing, or degradation processing. Finally, relevant information about the abnormal traffic, such as the request source, request time, and request characteristics, is recorded for subsequent analysis and optimization of protection strategies.

[0043] In some embodiments, whether it's traffic scrubbing by WAF or DDoS protection products, or scoring requests to determine the risk level of traffic, these mainstream methods all incur high implementation costs and involve intrusion into traffic requests within the traffic chain, such as tagging traffic. To address these issues, this embodiment employs an asynchronous traffic determination method. This not only avoids affecting request packets but also ensures that the gateway's memory only stores valid information, achieving low-cost computing power and non-intrusive link management. Furthermore, this embodiment reduces traffic protection costs. After connecting to the gateway of this embodiment, there's no need to purchase expensive DDoS protection packages; abnormal traffic rate limiting can be directly implemented at the gateway layer. Simultaneously, this embodiment effectively protects the traffic security of business activities. During activities, businesses may experience a large amount of abnormal traffic, such as attackers using forged traffic to participate in the purchase of promotional items, buying up discounted items in bulk for profit. This embodiment is particularly suitable for such scenarios. Additionally, this embodiment can be deployed in low-cost scenarios. Enabling weak-feature traffic processing for specific businesses ensures a high abnormal traffic hit rate, achieving high returns at low cost.

[0044] Specifically, Figure 3 This is a schematic diagram of a gateway processing flow provided in an embodiment of this application, such as... Figure 3 As shown, the gateway internally deploys software components such as a gateway layer, an asynchronous processing module, and gateway memory to implement abnormal traffic detection functions; the server includes a backend service module and an interface documentation information library. The backend service module provides specific business interface services, and the interface documentation information library stores the metadata information of the interface.

[0045] In this system, the gateway module serves as a unified traffic entry point. Traffic is processed by the gateway and forwarded to the backend service module. After receiving a response from the backend service module, the gateway returns response information. During the gateway processing, the gateway determines the traffic flow and whether to rate-limit request packets. In this embodiment, the focus of the gateway module is on the traffic characteristic determination process. The gateway module provides a fast determination method based on characteristic parameters to determine whether the traffic belongs to abnormal traffic.

[0046] The asynchronous processing module is an external asynchronous processing device that collects statistical data, quickly obtains weak characteristic information of traffic, and writes it back to the gateway's memory. The asynchronous processing module provides a method for extracting and statistically analyzing characteristic parameters to obtain characteristic information of abnormal traffic from different interfaces, which is then provided to the gateway module for traffic determination.

[0047] The backend service module consists of backend services from multiple access gateways, with the gateways routing traffic to the corresponding backend services. In this embodiment, the backend service module primarily provides the corresponding interface documentation information of the backend services to the asynchronous processing module for initial selection of traffic characteristics. By default, backend services do not need to form a fixed structure; they mainly provide backend service capabilities and the latest interface documentation information. This embodiment controls the access of backend service documentation information from the interface documentation information library to control the activation of traffic processing devices for designated backend services. The gateway module does not need to determine the request packets in the traffic, which is one of the differences from traffic switch determination in related technologies. In this embodiment, the backend service performing weak-feature traffic processing needs to provide standard interface documentation information to the asynchronous processing module. Each interface in the interface documentation information has corresponding interface path, request parameters, request headers, and other information.

[0048] like Figure 3 As shown in the embodiment of this application, a gateway processing method for weak-feature abnormal traffic is also provided. First, traffic processing is performed at the gateway layer. Upon receiving traffic, a request message is asynchronously provided to the processing module, which then extracts and statistically analyzes the features of the message.

[0049] The asynchronous processing module, operating as a separate module, does not intrude on the request chain processing within the gateway, thus not impacting gateway performance. However, it can still perform statistical analysis of request packets and independently identify weak traffic characteristics. When the asynchronous processing module receives a request packet, it does not block the gateway's processing of the current packet. Instead, based on the request information, it matches the interface documentation information library provided by the backend service module through a link. For backend services that access the unified gateway, access to the online interface documentation needs to be granted to the gateway. The asynchronous processing module quickly locates the corresponding interface documentation based on the request information and can obtain the corresponding interface parameters. The interface documentation provided by the backend services is uniformly classified into the interface documentation information library, and the content information of the interfaces in the library is considered the interface's metadata. This method allows for the rapid differentiation of which parameters in the request information cannot be identified as characteristics (generally, abnormal traffic will not forge content parameters because they cannot be used by the backend service, making its intrusion meaningless).

[0050] The asynchronous processing module performs a difference calculation between the feature keys in the request message and the content parameter keys of the corresponding interface to obtain candidate keys for the target interface. Then, it statistically analyzes the interface information with candidate keys within a certain time range, and uses a specified statistical threshold to determine the interface links and their feature information that meet the requirements within the current time window, writing this information back to the gateway's memory. The gateway's memory maintains a trie with an expiration date for each interface that meets the conditions, storing the interface's feature key-value pairs. This method ensures that only high-hit-rate feature information is retained in the gateway's memory, and expired features are automatically cleaned up. This not only guarantees the effective utilization of gateway resources but also ensures that the memory state matches the bursty characteristics of abnormal traffic, allowing the gateway to handle abnormal traffic to the greatest extent possible.

[0051] When traffic enters the gateway, an abnormal traffic determination process is first performed. This involves first checking if the request packet has a trie (prefix tree) in the gateway's memory to quickly determine if the current request poses an abnormal traffic risk. Next, candidate keys from the trie are retrieved, and the request packet is checked to see if it contains all of these candidate keys. The number of candidate keys in the trie depends on the statistical threshold of the asynchronous processing module; this method filters out requests without specific characteristics. Finally, feature values ​​from the request packet are retrieved, and feature value matching is performed. This ensures the most efficient value determination. If these three conditions are met, the request packet is placed in a separate rate-limiting pool to achieve the purpose of rate limiting abnormal traffic.

[0052] Through the above methods, the asynchronous processing module will not block the gateway's processing and can effectively discover weak feature information; the feature information is only stored in the gateway's memory during the abnormal traffic arrival phase, without causing excessive memory consumption; the gateway's triple judgment process is direct and efficient, with almost no increase in the link time of request packets. Furthermore, the above methods can effectively handle the flexible and ever-changing nature of feature information, and can quickly detect and respond when abnormal traffic changes its feature parameters. Therefore, this embodiment of the application can uniformly, efficiently, and effectively identify and process difficult-to-distinguish weak-feature abnormal traffic, effectively ensuring the security of downstream services at the gateway layer and preventing abnormal traffic from consuming normal service resources.

[0053] For example, e-commerce platforms are currently conducting periodic flash sales of designated virtual goods. To attract traffic, the prices of participating goods are extremely low, and users who successfully purchase these goods can resell them for substantial profits. The platform has implemented certain security measures, such as allowing only genuine users with UUIDs to participate in the flash sales and limiting the number of items a single user can purchase. However, in the first few rounds of flash sales, the authenticity of the traffic became apparent, leading operations to suspect abnormal traffic being used by programs to participate in the purchases. However, it was difficult to distinguish between genuine and abnormal traffic based on the request messages. Therefore, the gateway described in this application was implemented. First, the e-commerce platform's services are connected to the unified traffic gateway in this embodiment to achieve unified traffic management. Traffic first enters the gateway, which then determines the traffic routing strategy. Next, the backend services providing flash sale capabilities provide corresponding standard interface documentation, which is then provided to the asynchronous processing module in the gateway. The gateway layer directly copies all received request messages and asynchronously provides them to the asynchronous processing module without waiting for processing results. The asynchronous processing module, through the gateway's feature extraction device, detects that within a certain time window, traffic from a particular source IP consistently exceeds a threshold, and a batch of traffic carries a valid, time-limited anti-counterfeiting identifier. The platform cannot directly determine if the traffic is legitimate; the asynchronous processing module extracts these features through the time window. The gateway layer receives the feature information written back by the asynchronous processing module, processes request packets matching these features, and places them into a separate rate-limiting connection pool. Large amounts of abnormal traffic are blocked; when traffic is low, even falsely identified traffic can pass through the rate-limiting connection pool. If an intruder discovers that the current source IP or anti-counterfeiting identifier is unusable, they may try to access the platform by changing their packet information. In the next time window, this is again processed by the gateway layer, and rate limiting occurs again. If the intruder finds that they cannot complete the purchase operation with abnormal traffic, they may abandon the intrusion. At this point, the gateway layer automatically clears the recorded feature information and closes the feature judgment process. Subsequent abnormal traffic from other intruders will also be processed by the gateway based on their weak traffic characteristics, ensuring the security of downstream services at the gateway layer and preventing abnormal traffic from consuming normal service resources.

[0054] Optionally, after receiving a request message, the gateway layer first determines whether the request link in the request message has a trie in the gateway's memory. If not, the request message is directly forwarded to the backend service module. If it does, the gateway layer retrieves the candidate keys from the trie and determines whether the feature key in the request message contains all the candidate keys in the trie. If the request message does not contain all the candidate keys in the trie (e.g., partially contains or does not contain at least one candidate key in the trie), the request message is directly forwarded to the backend service module. If the request message contains all the candidate keys in the trie, the gateway layer retrieves the feature value of the target feature key in the request message that matches the target candidate key in the trie, and matches the feature value of the target feature key in the request message with the set of candidate values ​​associated with the target candidate key in the trie. If there is no candidate value in the trie that matches the feature value of the target feature key, the request message is directly forwarded to the backend service module. If there is a candidate value in the trie that matches the feature value of the target feature key, the request message is placed in a separate rate limiting pool.

[0055] The embodiments provided in this application employ a triple-determination mechanism to efficiently detect and process highly forged, flexible, and weakly characteristic abnormal traffic. The first determination mechanism, by determining whether the request link of the request packet has a trie in the gateway's memory, can quickly identify interfaces exhibiting abnormal traffic characteristics. Interfaces without abnormal traffic characteristics are directly allowed, avoiding complex feature matching for all request packets, significantly reducing unnecessary computational overhead, and improving processing efficiency. The second determination mechanism, by determining whether the request packet contains all candidate keys in the trie, ensures that the request packet possesses the basic characteristic pattern of abnormal traffic, avoiding misjudgments based on a single feature and improving the accuracy of the determination. The third determination mechanism, by determining whether the feature value of the target feature key in the request packet matches a candidate value in the candidate value set associated with the target candidate key in the trie, further ensures that the feature value of the request packet conforms to the characteristic pattern of abnormal traffic, improving the accuracy of the determination. This triple-determination mechanism ensures accuracy while improving efficiency, effectively solving the technical problem of efficiently detecting and processing highly forged, flexible, and weakly characteristic abnormal traffic in related technologies, thus improving the accuracy and efficiency of abnormal traffic identification.

[0056] In an exemplary embodiment, when it is necessary to match the feature key of a request message with candidate keys in the trie, the traditional method usually adopts a global matching approach, that is, traversing all candidate keys in the trie and comparing them one by one with the feature key of the request message. This approach will incur a large amount of computational overhead when there are many candidate keys, resulting in low matching efficiency and affecting the processing performance of the gateway.

[0057] To address the aforementioned issues, this embodiment divides multiple candidate keys in the trie into multiple first buckets according to their key lengths. By utilizing the length information of the feature keys, the corresponding first target bucket can be quickly located, avoiding a global traversal of all candidate keys, significantly reducing the computational load of matching, and improving the efficiency of feature key matching.

[0058] In some embodiments, multiple candidate keys in the trie are divided into multiple first buckets according to their key lengths, each first bucket corresponding to a different key length, and each first bucket including at least one candidate key. The method further includes: taking each first bucket as the current first bucket, taking each candidate key in the current first bucket as the current candidate key, and performing the following operations: matching at least one feature key in the request message whose key length matches the key length corresponding to the current first bucket with the current candidate key; in response to the existence of a feature key that matches the current candidate key, determining that the request message includes the current candidate key; and in response to the request message including each candidate key in the trie, determining that the request message includes all candidate keys in the trie.

[0059] In this context, the first bucket refers to the set obtained by grouping candidate keys in the trie according to their key length. Each first bucket corresponds to a specific key length and stores all candidate keys with that key length. The purpose of the first bucket is to quickly narrow down the matching range using the length information of the feature keys, avoiding a global traversal of all candidate keys in the trie. For example, firstly, the key length of each candidate key in the trie is extracted; secondly, a mapping structure of "length → candidate key set" is established using the key length as an index, i.e., the first bucket; finally, all candidate keys with the same key length are grouped into the same first bucket.

[0060] Optionally, after receiving a request message, the gateway layer first determines whether the request link has a trie in the gateway's memory. If not, it directly forwards the request message to the backend service module. If it does, it extracts the key length of each feature key in the request message and divides the multiple candidate keys in the trie into multiple first buckets according to their key lengths, with each first bucket corresponding to a different key length. Then, it takes each first bucket as the current first bucket and takes each candidate key in at least one candidate key in the current first bucket as the current candidate key, and performs the following operations: it matches at least one feature key in the request message whose key length matches the key length corresponding to the current first bucket with the current candidate key. In response to the existence of a feature key that matches the current candidate key, it determines that the request message includes the current candidate key. Finally, in response to the fact that the request message includes each candidate key in the trie, it determines that the request message includes all candidate keys in the trie, and continues with subsequent feature value matching.

[0061] For example, in the gateway's memory, for the link: http: / / api.shop.com / order / create, two request header feature key-value pairs are maintained, as follows:

[0062] token = { a0f2d9c3-8e0c-4b15-9f7c-6b2e9b7f2d91, d6e51b19-4d2a-49db-a2d8-6b7f9c04a8c0};

[0063] IP address = {10.9.3.77};

[0064] The feature key `token` and feature key `ip` are related by AND, meaning that both `token` and `ip` must have corresponding candidate keys that match in the trie. Internally, the feature keys `token` and `ip` are related by OR, meaning that for a match to be considered successful, at least one candidate value in the trie's candidate value set corresponding to `token` must match the feature value corresponding to `ip`.

[0065] This embodiment divides multiple candidate keys in the trie into multiple first buckets according to their key length. By utilizing the length information of the feature keys, the corresponding first bucket is quickly located, avoiding a global traversal of all candidate keys. This significantly reduces the computational load of matching and improves the efficiency of feature key matching. Furthermore, the first bucket division method allows for rapid narrowing of the matching range based on the key length of the feature keys, further improving matching efficiency. This method solves the problems of high computational overhead and low matching efficiency in related technologies when performing global feature key matching, thus improving the overall performance of abnormal traffic detection.

[0066] In an exemplary embodiment, when it is necessary to match the feature values ​​of a request message with the candidate value set in the trie, the traditional method usually adopts a global matching approach, that is, traversing all candidate values ​​in the candidate value set and comparing them one by one with the feature values ​​of the request message. This approach will incur a large amount of computational overhead when there are many candidate values, resulting in low matching efficiency and affecting the processing performance of the gateway.

[0067] To address the aforementioned issues, this embodiment divides each candidate value in the candidate value set associated with each candidate key into multiple second buckets according to its value length. By utilizing the length information of the feature value, the corresponding target bucket can be quickly located, avoiding a global traversal of all candidate values, significantly reducing the computational load of matching, and improving the efficiency of feature value matching.

[0068] In some embodiments, each candidate value in the candidate value set associated with each candidate key is divided into multiple second buckets according to its value length. Each second bucket corresponds to a different value length, and each second bucket includes at least one candidate value. The method further includes: determining a target bucket in the second bucket corresponding to the candidate value set associated with the target candidate key whose value length matches that of the feature value of the target feature key; matching at least one candidate value in the target bucket with the feature value of the target feature key; and, in response to the existence of a candidate value in the target bucket that matches the feature value of the target feature key, determining that the feature value of the target feature key matches a candidate value in the candidate value set associated with the target candidate key in the trie.

[0069] The second bucket refers to the set obtained by grouping candidate values ​​in the candidate value set according to their length. Each second bucket corresponds to a specific length and stores all candidate values ​​with that length. In this embodiment, the bucket for candidate values ​​of length len (i.e., the second bucket) is represented as bucket[len], which is the set of all candidate values ​​with a string length equal to len, stored in a container indexed by len. The purpose of the second bucket is to quickly narrow down the matching range using the length information of the feature values, avoiding a global traversal of all candidate values ​​in the candidate value set. For example, firstly, the length of each candidate value in the candidate value set associated with each feature key in the trie is extracted; secondly, a mapping structure of "length → candidate value set" is established using the length as an index, i.e., the second bucket; finally, all candidate values ​​with the same length are grouped into the same second bucket.

[0070] A target bucket refers to the second bucket in the trie that matches the length of the feature value of the target feature key in the request message among the multiple second buckets corresponding to the set of candidate values ​​associated with the target candidate key. The target bucket contains all candidate values ​​whose value length is the same as the feature value of the target feature key in the request message. For example, first, the value length of the feature value for each feature key in the request message is extracted; second, based on the value length, the corresponding second bucket is searched among the multiple second buckets corresponding to the set of candidate values ​​associated with the candidate key matching each feature key in the trie; finally, the found second bucket is determined as the target bucket.

[0071] Optionally, after receiving a request message, the gateway layer first determines whether the request link has a trie in the gateway's memory. If not, it directly forwards the request message to the backend service module. If it does, it performs feature key matching between the feature key in the request message and the candidate keys in the trie. If no candidate key matching a certain feature key in the request message exists in each first bucket, it is determined that the feature key does not match the candidate keys in the trie, and the request message is directly forwarded to the backend service module. When the request message contains all the candidate keys in the trie, the length of the feature value of the target feature key in the request message is extracted, and the corresponding feature key is searched in multiple second buckets of the trie based on the length of the target feature key. The target bucket is identified; after finding the target bucket, at least one candidate value in the target bucket is matched with the feature value of the target feature key; if there is a candidate value in the target bucket that matches the feature value of the target feature key, then the feature value of the target feature key is determined to match the candidate value in the trie; if there is no candidate value in the target bucket that matches the feature value of the target feature key of the request message, then the feature value of the target feature key is determined to not match the candidate value in the trie, and the request message is directly forwarded to the backend service module; when the feature values ​​of all target feature keys of the request message match the candidate values ​​in the trie, the request message is determined to meet the preset judgment conditions, it is marked as abnormal traffic and rate limiting is performed.

[0072] For example, for the link: http: / / api.shop.com / order / create, a corresponding trie was constructed, as shown below:

[0073] (root)

[0074] ├─ token -> matcher(values=[uuid1, uuid2], bitIndex=0)

[0075] └─ ip -> matcher(values=[ip1], bitIndex=1)

[0076] The value is the corresponding candidate value. For example, the candidate value uuid1 = "a0f2d9c3-8e0c-4b15-9f7c-6b2e9b7f2d91".

[0077] The request packet is bucketed based on the length of the candidate value. For example, the target bucket matching the length of the candidate value for the candidate key `token` can be represented as `tokenMatcher.length: 36 -> [uuid1, uuid2]`, where the target bucket matching the length of the candidate value for the candidate key `token` contains two specific candidate values, `uuid1` and `uuid2`, and each candidate value has a string length of 36 characters. The target bucket matching the length of the candidate value for the candidate key `ip` can be represented as `ipMatcher.length: 9 -> [ip1_bytes]`, where the target bucket matching the length of the candidate value for the candidate key `ip` contains only one candidate value: `ip1_bytes`, with a string length of 9 characters. After the feature key of the request packet is matched, the first step is to determine the target buckets that match the length of the feature value corresponding to the target feature key, which is used to quickly narrow down the range of candidate values. Then, the feature value of the target feature key and the candidate values ​​in the target buckets that match the length of the feature value corresponding to the target feature key are matched.

[0078] In this embodiment, each candidate value in the candidate value set associated with each candidate key is divided into multiple second buckets according to its value length. The length information of the feature value is used to quickly locate the corresponding second bucket, avoiding a global traversal of all candidate values, significantly reducing the computational load of matching, and improving the efficiency of feature value matching. Simultaneously, the division into second buckets allows for rapid narrowing of the matching range based on the feature value length, further improving matching efficiency. This method solves the problems of high computational overhead and low matching efficiency in related technologies when performing global feature value matching, improving the overall performance of abnormal traffic detection.

[0079] In an exemplary embodiment, when it is necessary to match the feature values ​​of a request message with the candidate value set in the trie, the traditional method usually adopts a global matching approach, that is, traversing all candidate values ​​in the candidate value set and comparing them one by one with the feature values ​​of the request message. This approach will incur a large amount of computational overhead when there are many candidate values, resulting in low matching efficiency and affecting the processing performance of the gateway.

[0080] To address the aforementioned issues, this embodiment assigns a local random byte position table to each second bucket and uses multiple byte positions in the local random byte position table to sample and compare feature values. This avoids global traversal and complete comparison of all candidate values ​​in the candidate value set, significantly reducing the computational load of matching and improving the efficiency of feature value matching.

[0081] In some embodiments, each second bucket corresponds to a local random byte position table, and the local random byte position table corresponding to each second bucket includes multiple byte positions. Matching at least one candidate value in the target bucket with the feature value of each feature key includes: extracting the first byte at multiple byte positions from the feature value of the target feature key according to the local random byte position table corresponding to the target bucket, and extracting the second byte at multiple byte positions from each candidate value in the target bucket; comparing the first byte at each byte position in the feature value of the target feature key with the second byte at the same byte position in each candidate value in the target bucket; and determining that a candidate value in the target bucket matches the feature value of the target feature key in response to the existence of a candidate value in the target bucket matching the feature value of the target feature key.

[0082] The local random byte position table for each second bucket is a pre-generated data structure containing multiple byte positions. Each byte position is a random integer representing the byte position to be extracted from the feature value or candidate value. The purpose of the local random byte position table is to provide fixed byte positions for feature value sampling and comparison, avoiding complete matching of feature values ​​and improving matching efficiency while ensuring matching accuracy. The byte positions in the local random byte position table are pre-generated and fixed for the same second bucket, not changing with each match. The number of byte positions in the local random byte position table for each second bucket is determined by the number of candidate values ​​in each second bucket; the more candidate values ​​in each second bucket, the more byte positions in the local random byte position table for each second bucket.

[0083] The first byte at multiple byte positions refers to the byte extracted from the feature value of the request message according to its position in the local random byte position table. The second byte at multiple byte positions refers to the byte extracted from the candidate values ​​in the target bucket according to the same byte position in the local random byte position table. The first byte comes from the feature value of the request message and is the object to be determined; the second byte comes from the candidate values ​​in the target bucket and is the reference object used for comparison.

[0084] In some embodiments, the process of matching at least one feature key in the request message whose key length matches the key length corresponding to the current first bucket with the current candidate key can also adopt the scheme of matching at least one candidate value in the target bucket with the feature value of each feature key, which will not be elaborated here.

[0085] Optionally, after receiving a request message, the gateway layer first determines whether the request link has a trie in the gateway's memory. If not, it directly forwards the request message to the backend service module. If it does, it performs feature key matching between the feature key in the request message and the candidate key in the trie. If there is no candidate key in the first target bucket that matches a certain feature key of the request message, it is determined that the feature key does not match the candidate key in the trie, and the request message is directly forwarded to the backend service module. When the request message contains all candidate key matches in the trie, the length of the feature value of each feature key in the request message is extracted, and the corresponding target bucket is searched in multiple second buckets of the trie based on the value length. After finding the target bucket, according to the local random byte position table corresponding to the target bucket, the first byte at multiple byte positions is extracted from the feature value of each feature key in the request message, and multiple byte positions are extracted from each candidate value of at least one candidate value in the target bucket. The second byte of the request message is compared with the second byte at the same byte position of each byte position of the feature value of each feature key in the target bucket. In response to the fact that the second byte at multiple byte positions of one candidate value in the target bucket matches the first byte at multiple byte positions of the feature value of each feature key in the request message, it is determined that there is a candidate value in the target bucket that matches the feature value of each feature key in the request message. If there is no candidate value in all candidate values ​​in the target bucket that matches the feature value of a certain feature key in the request message, it is determined that the feature value of that feature key does not match the candidate value in the trie, and the request message is directly forwarded to the backend service module. When the feature values ​​of all feature keys in the request message match the candidate values ​​in the trie, it is determined that the request message meets the preset judgment conditions, and it is marked as abnormal traffic and rate-limited.

[0086] For example, suppose the local random byte position table corresponding to the target bucket is [2, 5, 8, 12], the feature value of the request message is "abcdefgh123456789", and the candidate value in the target bucket is "abXdefghYij". According to the local random byte position table [2, 5, 8, 12], the first byte at positions 2, 5, 8, and 12 of the request message's feature value is extracted as c, f, i, and 9 respectively. The second byte at positions 2, 5, 8, and 12 of the candidate value is extracted as X, Y, j, and i respectively. Comparing the first byte c, f, i, 9 with the second byte X, Y, j, i, we find that c is not equal to X, f is not equal to Y, i is equal to i, and 9 is not equal to i. Therefore, this candidate value does not match. We continue to compare the next candidate value until a matching candidate value is found or it is determined that all candidate values ​​do not match.

[0087] In this embodiment, a local random byte position table is assigned to each second bucket. Multiple byte positions from this table are used to sample and compare feature values, avoiding a global traversal and complete comparison of all candidate values ​​in the candidate value set. This significantly reduces the computational load of matching and improves the efficiency of feature value matching. Furthermore, the sampling method using the local random byte position table allows for rapid determination of feature value matching accuracy while maintaining matching accuracy, further improving matching efficiency. This method solves the problems of high computational overhead and low matching efficiency associated with complete comparisons of two feature values ​​in related technologies, improving the overall performance of abnormal traffic detection.

[0088] In one exemplary embodiment, when determining the local random byte position table, conventional methods typically regenerate random positions for each match or use a fixed number of random positions. This method of regenerating random positions for each match incurs significant computational overhead, leading to low matching efficiency and impacting the gateway's processing performance.

[0089] To address the aforementioned issues, this embodiment pre-generates a global random byte position table for each second bucket, and then selects a local random byte position table from it based on the number of random positions. This avoids regenerating random positions for each match, thus improving matching efficiency. Simultaneously, by dynamically determining the number of random positions based on the number of candidate values, the number of sampled byte positions is adaptively adjusted, further improving matching efficiency while ensuring matching accuracy.

[0090] In some embodiments, the method further includes: dividing candidate values ​​with the same value length in the trie into the same second bucket to obtain multiple second buckets; determining the number of random positions according to the number of candidate values ​​in each second bucket, and selecting the byte positions of the number of random positions from the global random byte position table corresponding to each second bucket in sequence as the local random byte position table corresponding to each second bucket.

[0091] Each of the multiple second buckets includes at least one candidate value. Each second bucket corresponds to a pre-generated global random byte position table, which contains multiple randomly generated byte positions. Each byte position in the global random byte position table is a non-repeating random integer within the range of zero to the value length corresponding to that second bucket. The global random byte position table for each second bucket is a pre-generated data structure containing multiple byte positions, each of which is a random integer representing a byte position that can be extracted from the candidate value. The byte positions in the global random byte position table are randomly generated, and the number of byte positions in the global random byte position table is the same as the value length corresponding to the second bucket, covering all possible positions from 0 to the value length - 1, ensuring comprehensiveness and randomness of sampling. The global random byte position table is pre-generated and fixed for the same second bucket, not changing with each match.

[0092] In this embodiment, the length of the value corresponding to each second bucket is represented as Len, and the global random byte position table of each second bucket is denoted as positions[Len]. Each number in the global random byte position table positions[Len] of each second bucket is an index in the range [0, Len-1]. The global random byte position table positions[Len] of each second bucket is globally fixed in the trie object and does not need to be generated or calculated for each request.

[0093] For example, the global random byte position table positions[Len] corresponding to the second bucket (Len=36) with a value length of 36 can be positions=[2,7,19,33,5,12,28,35,...]. The global random byte position table positions[Len] corresponding to the second bucket (Len=9) with a value length of 9 can be positions=[1,3,6,8,0,2,4,7,5].

[0094] The number of random positions refers to the number of byte positions selected from the global random byte position table, used to determine the size of the local random byte position table. The number of random positions is determined based on the number of candidate values ​​in the second bucket, and is appropriately increased as the number of candidate values ​​increases to ensure matching accuracy. It can be understood that the number of random positions is consistent with the number of matching operations; that is, the number of random positions equals the number of matching operations required.

[0095] The global random byte position table corresponding to each second bucket is a pre-generated complete set of byte positions, containing all possible positions from 0 to the value length - 1, providing a comprehensive range of byte position selections. The local random byte position table corresponding to each second bucket is a subset of byte positions selected sequentially from the global random byte position table, with a number equal to the number of random positions, used for actual feature value sampling and comparison. The global random byte position table is the source and foundation of the local random byte position table, which is a practical application and simplified version of the global random byte position table. By pre-generating the global random byte position table and then selecting the local random byte position table from it based on the number of random positions, the regeneration of random positions during each matching can be avoided, improving matching efficiency.

[0096] Optionally, the gateway divides candidate values ​​with the same value length in the trie into the same second bucket, resulting in multiple second buckets; a global random byte position table is pre-generated for each second bucket, which contains multiple randomly generated byte positions, each of which is a non-repeating random integer within the range of zero to the value length corresponding to the second bucket; the number of random positions is determined based on the number of candidate values ​​in each second bucket; byte positions of the random position number are selected sequentially from the global random byte position table corresponding to each second bucket, serving as the local random byte position table corresponding to each second bucket; in the subsequent feature value matching process, the local random byte position table is used for sampling and comparison.

[0097] For example, suppose the value length corresponding to a certain second bucket is 36, and the second bucket contains 2 candidate values. First, a global random byte position table is pre-generated, containing 36 byte positions, covering all possible positions from 0 to 35, for example [5,12, 23, 8, 31, 15, 2, 19, 27, 11, 33, 6, 17, 29, 4, 21, 34, 9, 24, 13, 30, 7,18, 25, 3, 20, 32, 10, 26, 14, 28, 16, 1, 22, 0]. Then, based on the number of candidate values ​​in the second bucket, the number of random positions is determined to be 4. Finally, the first 4 byte positions [5,12, 23, 8] are selected sequentially from the global random byte position table as the local random byte position table corresponding to this second bucket. In the subsequent feature value matching process, the local random byte position table [5, 12, 23, 8] is used for sampling and comparison instead of the complete global random byte position table.

[0098] In this embodiment, a global random byte position table is pre-generated for each second bucket, and a local random byte position table is selected from it based on the number of random positions. This avoids regenerating random positions for each match, thus improving matching efficiency. Furthermore, by dynamically determining the number of random positions based on the number of candidate values, the number of sampled byte positions can be adaptively adjusted while maintaining matching accuracy, further improving matching efficiency. This method solves the problems of low random position generation efficiency and inability to adaptively adjust the number of samples in related technologies, improving the overall performance of abnormal traffic detection.

[0099] In one exemplary embodiment, when determining the number of random positions, conventional methods typically use a fixed number of random positions for sampling and comparison, regardless of the number of candidate values. This approach may use too many random positions when the number of candidate values ​​is small, resulting in unnecessary computational overhead; conversely, it may use too few random positions when the number of candidate values ​​is large, leading to insufficient matching accuracy and failing to achieve a balance between matching efficiency and accuracy.

[0100] To address the aforementioned issues, this embodiment dynamically determines the number of random positions based on the number of candidate values ​​in each second bucket, performs logarithmic processing on the number of candidate values, rounds up, and then takes the maximum value with a preset minimum base, thereby adaptively adjusting the number of sampled byte positions and improving matching efficiency while ensuring matching accuracy.

[0101] In some embodiments, determining the number of random positions based on the number of candidate values ​​in each second bucket includes: performing logarithmic processing on the number of candidate values ​​in each second bucket to obtain a logarithmic result, rounding the logarithmic result up to obtain an integer result, and determining the larger of the integer result and a preset minimum base as the number of random positions.

[0102] The logarithmic result refers to the value obtained by taking the logarithm of the number of candidate values ​​in each second bucket. The logarithmic function is base 2, i.e., log2(N), where N represents the number of candidate values ​​in each second bucket. The logarithmic result reflects the exponential growth of the number of candidate values ​​and is used to determine the cardinality of the number of random positions.

[0103] The integer result refers to the integer obtained by rounding up the logarithmic result. The purpose of rounding up is to ensure that the number of random positions is large enough to cover the differentiation requirements brought about by the increase in the number of candidate values.

[0104] The preset minimum cardinality refers to a pre-set minimum value used to guarantee the number of random positions, such as 4, which is strict enough even when N=1. The purpose of the preset minimum cardinality is to prevent the number of random positions from being too small when the number of candidate values ​​is small, resulting in insufficient matching accuracy.

[0105] The number of random positions can be represented by the following formula (1):

[0106] k = max(k0, ceil(log2(N + 1))) (1)

[0107] Where k represents the number of random positions, k0 represents the preset minimum cardinality (e.g., 4, to ensure that it is strict enough when N=1), and N represents the number of candidate values ​​in bucket[len] (the second bucket of length len). This algorithm can efficiently perform short-circuit feature key-value pair judgment. The matching efficiency will not be affected as the number of values ​​increases, while ensuring the accuracy of the matching.

[0108] For example, with a preset minimum cardinality k0 of 4, the number of random positions k corresponding to different values ​​of the number of candidate values ​​N in each second bucket is as follows:

[0109] When N=1, the number of random positions k=max(4, ceil(log2(2)))= 4.

[0110] When N=8, the number of random positions k=max(4, ceil(log2(9)))= 4.

[0111] When N=32, the number of random positions k=max(4, ceil(log2(33)))= 6.

[0112] When N=128, the number of random positions k=max(4, ceil(log2(129))) = 8.

[0113] Therefore, when there is 1 candidate value in each second bucket, 4 random byte positions are allocated, and when there are 128 candidate values ​​in each second bucket, 8 random byte positions are allocated.

[0114] In this embodiment, by employing logarithmic processing, the growth rate of the number of random positions is much lower than the growth rate of the number of candidate values. When the number of candidate values ​​increases from 1 to 128, the number of random positions only increases from 4 to 8, ensuring that the matching efficiency is not affected by the increase in the number of values. Simultaneously, by rounding up and taking the maximum value from the preset minimum base, the number of random positions is ensured to be large enough to cover the differentiation requirements brought about by the increase in the number of candidate values, thus guaranteeing the accuracy of the matching. This calculation method achieves a balance between matching efficiency and accuracy, avoiding unnecessary computational overhead caused by using too many random positions when the number of candidate values ​​is small, and avoiding insufficient matching accuracy caused by using too few random positions when the number of candidate values ​​is large.

[0115] In some embodiments, this embodiment is illustrated based on the matching algorithm of the above embodiments. Assume that the gateway memory already stores the trie corresponding to the request link: http: / / api.shop.com / order / create. This request link maintains two request header feature key-value pairs: token = { a0f2d9c3-8e0c-4b15-9f7c-6b2e9b7f2d91, d6e51b19-4d2a-49db-a2d8-6b7f9c04a8c0}, ip = { 10.9.3.77}. The trie is shown below:

[0116] (root)

[0117] ├─ token -> matcher(values=[uuid1, uuid2], bitIndex=0)

[0118] └─ ip -> matcher(values=[ip1], bitIndex=1)

[0119] At this point, a new request message arrives. The request link, request header, and IP address of this message are as follows: Request link: http: / / api.shop.com / order / create?userId=4c9b1f23-7a6e-41d0-b8d4-2e5f9d0a7c11×tamp=1770259667&4c9b1f23-7a6e-41d0-b8d4-2e5f9d0a7c11&productId=10086&count=1; Request header: token: d6e51b19-4d2a-49db-a2d8-6b7f9c04a8c0; IP address: 10.9.3.77.

[0120] At this point, the link http: / / api.shop.com / order / create in the gateway's memory is matched, and the weak-feature abnormal traffic judgment process begins. First, two feature keys are extracted from the gateway's memory using the request link, and then information is extracted from the request message using these feature keys. The request message contains the key="token" and value="d6e51b19-4d2a-49db-a2d8-6b7f9c04a8c0", and the key="ip" and value="10.9.3.77", and the following query process is performed:

[0121] (1) Look up the key in the trie: root->t->o->k->e->n, go to the terminal, and get tokenMatcher (bitIndex=0), that is, there is a candidate key in the trie that matches the feature key token.

[0122] (2) Value matching: The length of the feature value corresponding to the feature key token is valueLen=36. The target bucket

[36] with a value length of 36 is searched in the trie. The target bucket includes two candidate values ​​[uuid1, uuid2], that is, the number of candidate values ​​in the target bucket is N=2.

[0123] (3) Obtain the number of matches (equal to the number of random positions): k = max(4, ceil(log2(N+1))) = max(4, ceil(log2(3))) = 4. Assume that the global random byte position table positionss with a value length Len=36 is [2,7,19,33,5,12,28,35,...].

[0124] (4) The first k indices of the global random byte position table positions with a value length of Len=36: [2,7,19,33].

[0125] (5) Match the first candidate value uuid1 in the target bucket (i.e., check 4 random bytes): Assuming that the value value[2] in the second byte position of the feature value of the feature key token is not equal to the value uuid1[2] in the second byte position of the candidate value uuid1, it is determined that the feature value of the feature key token and the candidate value uuid1 have failed to match (short circuit, no further bytes are checked).

[0126] (6) Match the second candidate value uuid2 in the target bucket (i.e., check 4 random bytes): Assume that the comparison relationship between the bytes at the selected 4 random byte positions (i.e., value[2], value[7], value

[19] and value

[33] ) in the feature value of the feature key token and the bytes at the same random byte positions in the candidate value uuid2 is as follows:

[0127] value[2] vs uuid2[2]: are equal.

[0128] value[7] vs uuid2[7]: are equal.

[0129] value

[19] vs uuid2

[19] : equal.

[0130] value

[33] vs uuid2

[33] : are equal.

[0131] If all four random bytes match, the token is successfully matched (and the system returns without checking any more candidates).

[0132] (7) Obtain token matching result: uuid2 ("d6e51b19-4d2a-49db-a2d8-6b7f9c04a8c0") token matching successful.

[0133] Following the above process, continue with request header IP matching to obtain the IP matching result, assuming a successful match. Based on the matching result, the current request packet is determined to be weak-featured abnormal traffic, and the gateway adds it to the rate-limiting connection pool. When the traffic exceeds the threshold, rate limiting will automatically occur.

[0134] As described in the above embodiments, traffic requests enter the gateway, which processes and forwards the traffic based on the request message information. The gateway's traffic processing mainly includes request matching and rate limiting judgment, as well as asynchronously providing the request message information to the asynchronous processing module, which then statistically analyzes and extracts weak feature information. The request message information includes, but is not limited to, the request domain name, path, request headers, and parameters. The gateway performs logical judgments and processing based on this information. The asynchronous processing module enables weak feature rate limiting for a specified service and, based on feature statistical thresholds, detects abnormal traffic, writing its feature information back to the gateway's memory. First, it matches the feature interface through a link; then, it performs a feature matching process based on the feature information. The gateway provides a fixed random byte comparison algorithm, generating multiple random position information tables based on the bucket length. This algorithm is used to quickly determine whether the feature value matches. Based on the matching result, it determines whether the current request message is abnormal traffic. If it is abnormal traffic, the gateway adds it to the rate-limiting connection pool; when the traffic exceeds the threshold, rate limiting will automatically occur.

[0135] Figure 4 A flowchart illustrating the process of traffic matching and hit determination in gateway memory, as provided in this application embodiment, is shown below. Figure 4 As shown, after the request message enters the gateway, the following steps are executed:

[0136] (1) First, link matching: The gateway will match the target interface (assuming it is feature interface A) corresponding to the current request from the feature interface library in memory (containing feature interfaces A / B / C). Each feature interface contains metadata such as interface URL, interface information, expiration time, etc., which are used to determine the range of feature rules to be matched later.

[0137] (2) After matching the target feature interface, the feature key matching stage begins: The gateway obtains a set of feature keys (i.e., the first target bucket, such as K1 / K2 / K3 of length C1, K4 / K5 / K6 of length C2) from the feature key length bucket (i.e., the first bucket) that matches the length of the feature keys in the request message. Based on the request message information (domain name, path, request header, parameters, etc.), the message value is extracted according to the feature key, and at least one candidate key in the first target bucket is matched with each feature key in the request message to complete the preliminary matching at the feature key level. In the process of preliminary matching at the feature key level, the comparison can also be performed based on a fixed random byte comparison algorithm.

[0138] (3) After the feature key matching is completed, assuming the feature key matching is successful, the feature value matching stage begins. First, the gateway generates a local random byte position table based on the fixed random byte comparison algorithm, according to the feature value length D1, and assigns a random position P1 and a matching count M1 to the feature value of feature value length D1. It also generates a local random byte position table based on the feature value length D2, and assigns a random position P2 and a matching count M2 to the feature value of feature value length D2, for quick verification of whether the feature value is matched. After extracting the corresponding feature value from the packet, the gateway simultaneously matches the feature values ​​in the feature value position table according to the position (e.g., T1 / T2 corresponds to length D1, T3 / T4 corresponds to length D2), determines whether the feature value is matched, and obtains the packet judgment result. If the packet judgment result indicates that the feature values ​​at the same position are all matched, the request is marked as abnormal traffic and added to the rate-limited connection pool. If the packet judgment result indicates that at least one feature value at the same position is not matched, it is determined as normal traffic and enters the normal connection pool.

[0139] (4) Request packets in the normal / rate-limited connection pool are forwarded to the backend service. At the same time, the gateway asynchronously submits the request packet information (domain name, path, parameters, etc.) to the asynchronous processing module. The asynchronous module collects weak feature information, calculates thresholds, and writes new feature information back to the gateway memory after detecting abnormal traffic, continuously updating the feature interface library and feature key / value rules to achieve dynamic rate limiting.

[0140] This embodiment dynamically determines the number of random positions based on the number of candidate values ​​in each second bucket. The number of candidate values ​​is logarithmically processed, rounded up, and then the maximum value is obtained by combining it with a preset minimum base. This adaptively adjusts the number of sampled byte positions, improving matching efficiency while ensuring matching accuracy. This method solves the problem of a fixed number of random positions and the inability to adaptively adjust the sampling number in related technologies, thus improving the overall performance of abnormal traffic detection.

[0141] In one exemplary embodiment, for weak-feature anomalous traffic—that is, traffic that is not obvious, highly forged by the attacker, flexible, and realistic—traditional methods can only passively handle anomalous traffic by manually judging each instance or by using high-cost protection products to clean the traffic. This approach suffers from low efficiency, high false positive rates, slow response, and high costs. Furthermore, traditional methods cannot efficiently detect and process highly forged, flexible, and weak-feature anomalous traffic, making it difficult to cope with the flexible and ever-changing characteristics of anomalous traffic features.

[0142] To address the aforementioned issues, this embodiment obtains an initial set of candidate keys for the target interface, counts the frequency of candidate keys within a sliding time window, removes low-frequency candidate keys to obtain a target key-value pair set, uses each candidate key in the target key-value pair set as a terminal node, and constructs a prefix tree structure using candidate values ​​as leaf node values ​​to obtain a trie. This achieves pre-construction and dynamic updating of the trie, enabling unified, efficient, and effective identification and processing of weak-feature abnormal traffic that is difficult to distinguish, and preventing abnormal traffic from occupying normal service resources.

[0143] In some embodiments, the method further includes: obtaining an initial candidate key set of the target interface, wherein the initial candidate key set refers to the set of request field names used for identity forgery or bypassing verification; obtaining multiple historical request messages that request to call the target interface within a preset sliding time window, and counting the frequency of each candidate key in the initial candidate key set appearing in the multiple historical request messages; removing candidate key-value pairs whose frequency is less than a preset frequency threshold to obtain a target key-value pair set; and constructing a prefix tree structure with each candidate key in the target key-value pair set as the terminal node and the candidate value of each candidate key in the target key-value pair set as the leaf node value to obtain a trie.

[0144] The initial candidate key set for the target interface refers to the set of request field names extracted from the interface documentation information of the target interface that may be used by abnormal traffic to forge identities or bypass verification. The initial candidate key set contains all possible abnormal traffic feature keys, such as token, IP, user-agent, and referer field names. The purpose of the initial candidate key set is to provide basic data for subsequent feature statistics and filtering, ensuring that no possible abnormal traffic feature keys are missed.

[0145] A sliding time window is a fixed-length time interval that moves along a timeline, used to statistically analyze the characteristic information in historical request packets. The purpose of a sliding time window is to dynamically track the latest traffic characteristics, ensuring that the characteristic information in the dictionary always reflects the abnormal traffic characteristics within the current time window. The length of the sliding time window can be set according to actual needs, such as 5 minutes, 10 minutes, etc. As time progresses, the sliding time window continuously moves forward, new historical request packets enter the window, and old historical request packets leave the window, thereby achieving real-time updates of characteristic information.

[0146] Historical request messages refer to all request messages that invoke the target interface within a preset sliding time window. Historical request messages contain complete request information, including the request path, request headers, parameters, etc., used for statistical analysis of abnormal traffic characteristics. Each historical request message includes at least one candidate key-value pair, where a candidate key-value pair consists of a candidate key and a candidate value, used to represent the characteristics of the abnormal traffic. The candidate key in the candidate key-value pair refers to the field name used by the abnormal traffic, and the candidate value in the candidate key-value pair refers to the field value associated with that candidate key and used by the abnormal traffic.

[0147] The frequency of each candidate key appearing in multiple historical request packets refers to the total number of times a candidate key appears in all historical request packets within a sliding time window. Frequency reflects how often a candidate key is used in abnormal traffic; the higher the frequency, the greater the likelihood that the candidate key is used by abnormal traffic. The preset frequency threshold is a pre-set minimum frequency threshold used to determine whether a candidate key is a characteristic key of abnormal traffic, such as 10 times or 20 times. The purpose of the preset frequency threshold is to filter out occasional, unrepresentative candidate keys, ensuring that the target key-value pair set only contains characteristic keys that are truly frequently used by abnormal traffic.

[0148] The target key-value pair set refers to the set of candidate keys and their corresponding candidate values ​​obtained after removing candidate key-value pairs with frequencies below a preset frequency threshold from the initial candidate key set. Each candidate key in the target key-value pair set is a feature key frequently used by abnormal traffic, and the candidate value set for each candidate key in the target key-value pair set contains multiple candidate values ​​associated with that candidate key in multiple historical request packets. The purpose of the target key-value pair set is to serve as the basic data for building the trie, ensuring that the trie only contains feature keys and candidate values ​​that are truly frequently used by abnormal traffic, thereby improving the accuracy and efficiency of abnormal traffic identification.

[0149] The initial candidate key set contains all possible abnormal traffic feature keys, but not all candidate keys are used frequently by abnormal traffic; some candidate keys may only appear occasionally and are not representative. By counting the frequency and removing low-frequency candidate keys, we can filter out occasional and unrepresentative candidate keys, ensuring that the target key-value pair set only contains feature keys that are truly used frequently by abnormal traffic, thereby improving the accuracy and efficiency of abnormal traffic identification.

[0150] Terminal nodes are the leaf nodes in a prefix tree structure, used to store candidate keys. Each terminal node corresponds to a candidate key, such as a token or IP address. Leaf node values ​​are the set of candidate values ​​stored under a terminal node, containing multiple candidate values ​​associated with the candidate key corresponding to that terminal node in multiple historical request messages. For example, the leaf node values ​​corresponding to the terminal node "token" might contain candidate values ​​such as {a0f2d9c3-8e0c-4b15-9f7c-6b2e9b7f2d91, d6e51b19-4d2a-49db-a2d8-6b7f9c04a8c0}. A prefix tree structure is a tree-like data structure used for efficient storage and retrieval of string data. In this application, the prefix tree structure is used to store the target key-value pair set and the corresponding candidate value set. The prefix tree structure enables rapid matching of feature keys and feature values, improving matching efficiency.

[0151] In this embodiment, pre-constructing a trie allows for the preparation of feature information before abnormal traffic arrives. When abnormal traffic enters the gateway, a triple determination can be performed immediately, eliminating the need for real-time statistics and trie construction, thus significantly improving the response speed and efficiency of abnormal traffic determination. The trie is a feature that is dynamically updated in real time following the sliding time window. As the sliding time window moves, new historical request packets enter the window, and old historical request packets leave the window. The asynchronous processing module continuously collects the latest feature information and updates the candidate keys and candidate values ​​in the trie, ensuring that the trie always reflects the abnormal traffic characteristics within the current time window.

[0152] In this embodiment, the asynchronous feature extraction capability, gateway feature processing procedure, calculation formula for initial candidate key set, sliding time window combined with initial candidate key set to locate target key-value pair set, trie constructed by writing back to gateway memory, and comparison algorithm for fixed random position bytes, etc., enable the gateway to achieve efficient, unified and effective abnormal traffic judgment and flexibly respond to various sudden abnormal traffic.

[0153] In this embodiment, by combining a sliding time window with the initial candidate key set of the target interface, once abnormal traffic increases, the access traffic will be automatically and immediately processed continuously within the subsequent sliding time window. When there is no abnormal traffic, no cost is required; when abnormal traffic with characteristics appears, it will be processed immediately, making the action targeted. This makes the gateway in this embodiment extremely cost-effective and has a high-performance traffic processing capability that matches the characteristics of abnormal traffic. It perfectly matches the attack characteristics of intruders and does not require the constant activation of risk control and monitoring of global traffic like related technologies.

[0154] Optionally, after receiving a request message, the gateway layer asynchronously provides the request message to the asynchronous processing module. Based on the request information, the asynchronous processing module matches the interface documentation information library provided by the backend service module to obtain the initial candidate key set of the target interface. The asynchronous processing module obtains multiple historical request messages that request to call the target interface within a preset sliding time window. The asynchronous processing module counts the frequency of each candidate key in the initial candidate key set in multiple historical request messages. The asynchronous processing module removes candidate keys with a frequency less than a preset frequency threshold to obtain the target key-value pair set. The asynchronous processing module uses each candidate key in the target key-value pair set as the terminal node and the candidate value of each candidate key in the target key-value pair set as the leaf node value to construct a prefix tree structure to obtain a trie. The asynchronous processing module writes the trie back to the gateway memory, and the gateway memory maintains a trie with an expiration date for each interface that meets the conditions.

[0155] For example, assuming the target API is http: / / api.shop.com / order / create, the asynchronous processing module retrieves the initial candidate key set for this API from the API documentation database, including field names such as {token, ip, user-agent, referer, cookie}. The asynchronous processing module then retrieves multiple historical request messages that called this API within a preset sliding time window (e.g., 5 minutes) and counts the frequency of each candidate key in the initial candidate key set appearing in these historical request messages. Assuming the statistics are: token appears 100 times, ip appears 80 times, user-agent appears 5 times, referer appears 3 times, and cookie appears 2 times, with a preset frequency threshold of 10. The asynchronous processing module then removes candidate keys with a frequency less than 10, i.e., removes user-agent, referer, and cookie, resulting in the target key-value pair set {token, ip}. The asynchronous processing module uses each candidate key in the target key-value pair set as the terminal node and the multiple candidate values ​​associated with each candidate key in multiple historical request messages as leaf node values ​​to construct a prefix tree structure. For example, the leaf node value corresponding to the terminal node token is {a0f2d9c3-8e0c-4b15-9f7c-6b2e9b7f2d91, d6e51b19-4d2a-49db-a2d8-6b7f9c04a8c0}, and the leaf node value corresponding to the terminal node IP is {10.9.3.77}. The asynchronous processing module writes the constructed trie back to the gateway memory, and the gateway memory maintains a trie with an expiration date for this interface.

[0156] This embodiment obtains an initial set of candidate keys for the target interface, counts the frequency of candidate keys within a sliding time window, removes low-frequency candidate keys to obtain a target key-value pair set, and constructs a prefix tree structure using each candidate key in the target key-value pair set as a terminal node and the candidate value as the leaf node value, thus obtaining a trie. This achieves pre-construction and dynamic updating of the trie. This method solves the problem in related technologies of being unable to efficiently detect and handle highly forged, flexible, and weakly characteristic abnormal traffic, improving the accuracy and efficiency of abnormal traffic determination. Furthermore, through real-time updates of the sliding time window, it can effectively cope with the flexible and ever-changing characteristics of abnormal traffic features, and can quickly detect and respond when abnormal traffic accesses the interface with different feature parameters.

[0157] In an exemplary embodiment, when obtaining the initial candidate key set for a target interface, traditional methods typically use all field names from the interface documentation as the candidate key set, or use a fixed set of field names. This approach cannot distinguish which field names might be used by abnormal traffic to forge identities or bypass verification, and which field names are generic and not susceptible to forgery by abnormal traffic. This results in the initial candidate key set containing a large number of irrelevant field names, increasing the computational overhead of subsequent feature statistics and filtering, and reducing the efficiency of abnormal traffic detection.

[0158] To address the aforementioned issues, this embodiment obtains the complete set of interface request parameters from the interface documentation information of the target interface, removes the set of general non-feature parameters and the set of interface content parameters to obtain an intermediate candidate key set, and then merges the intermediate candidate key set with the specified parameter set to obtain an initial candidate key set. This filters out irrelevant field names and ensures that the initial candidate key set only contains field names that may be used by abnormal traffic to forge identities or bypass verification, thereby improving the accuracy and efficiency of abnormal traffic determination.

[0159] In some embodiments, obtaining the initial candidate key set of the target interface includes: obtaining the complete set of allowed interface request parameters of the target interface from the interface documentation information of the target interface, wherein the complete set of interface request parameters refers to the set of all candidate keys predefined in the interface documentation information that are allowed to be carried in the request message; removing the set of general non-feature parameters and the set of interface content parameters from the complete set of interface request parameters to obtain an intermediate candidate key set; merging the intermediate candidate key set with the specified parameter set to obtain the initial candidate key set; wherein the set of general non-feature parameters refers to the set of field names that are common to the target interface; the set of interface content parameters refers to the set of field names that cannot be forged by abnormal traffic; and the set of specified parameters refers to the set of pre-specified field names.

[0160] The target interface's API documentation information refers to the metadata information about the target interface stored in the API documentation information repository provided by the backend service module. This API documentation information contains the complete definition of the interface, including all allowed field names, field types, required fields, and default values. The purpose of this API documentation information is to provide the foundational data for obtaining the initial candidate key set, ensuring that no potentially abnormal traffic feature keys are overlooked.

[0161] The complete set of interface request parameters refers to the set of all candidate keys predefined in the interface documentation that are allowed to be carried in request messages. This set includes all field names allowed by the interface, such as userId, productId, count, token, ip, host, content-type, user-agent, accept, cookie, and authorization. In this embodiment, the complete set of interface request parameters can refer to the set of all HTTP request headers and all URL query parameters (denoted as Header∪Query). The purpose of the complete set of interface request parameters is to provide basic data for subsequent filtering and merging, ensuring that no possible abnormal traffic characteristic keys are missed.

[0162] A generic non-featured parameter set refers to a collection of field names that are common to the target interface. These field names exist in all interfaces, lack distinctiveness, and cannot be used to identify abnormal traffic. The purpose of the generic non-featured parameter set is to filter out common, non-distinctive field names, preventing them from interfering with the identification of abnormal traffic. For example, a generic non-featured parameter set might include field names such as {host, content-type, accept, connection, cache-control}.

[0163] The API content parameter set refers to the collection of field names that cannot be forged by abnormal traffic. These field names typically contain user-submitted business data, and abnormal traffic will not forge these field names. The purpose of the API content parameter set is to filter out field names containing business data, preventing these field names from interfering with the abnormal traffic detection. For example, the API content parameter set might include field names such as {userId, productId, count, timestamp, signature}.

[0164] The intermediate candidate key set refers to the set of candidate keys obtained by removing the set of general non-feature parameters and the set of interface content parameters from the complete set of interface request parameters. The intermediate candidate key set only includes field names that might be used by abnormal traffic to forge identities or bypass verification, filtering out general field names and field names containing business data. The purpose of the intermediate candidate key set is to provide basic data for subsequent merging processing.

[0165] The specified parameter set refers to a pre-defined set of field names. These field names are those that the business side believes might be used by abnormal traffic to forge identities or bypass verification, and therefore require special attention. The purpose of the specified parameter set is to supplement the intermediate candidate key set, ensuring that no important abnormal traffic characteristic keys are missed. For example, the specified parameter set might include field names such as {cookie, authorization, referer, x-forwarded-for}.

[0166] In this embodiment, the initial candidate key set can be represented as: F0 = (R - G - C) ∪ M. Where R represents the complete set of interface request parameters (e.g., Header ∪ Query), G represents the set of general non-feature parameters (e.g., traceId, timestamp, nonce, etc.), C represents the set of interface content parameters (e.g., desc, remark, detailList, etc.), M represents the manually specified set of parameters that must participate in matching (e.g., token, ip, deviceId, etc.), and F0 represents the final "initial feature set" obtained for each interface. This method allows for the flexible acquisition of all possible feature keys of the interface.

[0167] In this embodiment, the asynchronous processing module, in conjunction with the interface documentation information library provided by the backend service module, quickly filters and extracts the metadata information of the interface using a difference method, thereby deriving the initial candidate key set for the interface. Specifically, when the asynchronous processing module receives a request message, it does not block the gateway from processing the current message. Instead, based on the request information, it matches the interface documentation information library provided by the backend service module through a link, and the interface information in the library is considered the interface's metadata. The difference calculation is performed between the request message information and the corresponding interface's metadata to obtain the feature key of the target interface. Through the difference calculation, the set of general non-feature parameters and the set of interface content parameters can be quickly removed from the complete set of interface request parameters to obtain an intermediate candidate key set. Then, the intermediate candidate key set is merged with the specified parameter set to obtain the initial candidate key set.

[0168] Optionally, after receiving the request message, the gateway layer asynchronously provides the request message to the asynchronous processing module. Based on the request information, the asynchronous processing module matches the interface documentation information database provided by the backend service module to obtain the interface documentation information of the target interface. The asynchronous processing module obtains the complete set of allowed interface request parameters of the target interface from the interface documentation information of the target interface. The asynchronous processing module removes the set of general non-feature parameters and the set of interface content parameters from the complete set of interface request parameters to obtain the intermediate candidate key set. The asynchronous processing module merges the intermediate candidate key set with the specified parameter set to obtain the initial candidate key set. The asynchronous processing module acquires multiple historical request messages that request to call the target interface within a preset sliding time window; the asynchronous processing module counts the frequency of each candidate key in the initial candidate key set in the multiple historical request messages; the asynchronous processing module removes candidate keys whose frequency is less than a preset frequency threshold from the initial candidate key set to obtain the target key-value pair set; the asynchronous processing module uses each candidate key in the target key-value pair set as the terminal node and the multiple candidate values ​​associated with each candidate key in the target key-value pair set in the multiple historical request messages as leaf node values ​​to construct a prefix tree structure to obtain a trie; the asynchronous processing module writes the trie back to the gateway memory, and the gateway memory maintains a trie with an expiration date for each interface that meets the conditions.

[0169] Figure 5 A flowchart of interface feature extraction in an asynchronous processing module provided in this application embodiment is shown below. Figure 5 As shown, firstly, the asynchronous processing module asynchronously obtains request information from the gateway module in real time. Then, it retrieves the interface documentation information library from the backend service module. Based on the request link in the request message, it matches the interface in the interface documentation information library to obtain interface information. Based on the existing information, feature extraction is performed according to rules. First, an initial candidate key set for the interface is generated according to F0 = (R - G - C) ∪ M. Then, using the initial candidate key set, a sliding window statistical filter is performed on the requests of the current connection to extract the target key-value pair set for the interface. After obtaining the final target key-value pair set for the interface, the target key-value pair set within the time window is written back to the gateway module, which then uses the target key-value pair set to determine the traffic.

[0170] For example, suppose the request link is: http: / / api.shop.com / order / create?userId=4c9b1f23-7a6e-41d0-b8d4-2e5f9d0a7c11×tamp=1770259667&4c9b1f23-7a6e-41d0-b8d4-2e5f9d0a7c11&productId=10086&count=1, the request header is token: a0f2d9c3-8e0c-4b15-9f7c-6b2e9b7f2d91, the IP is 10.9.3.77, and the traceId is 8fdcaa91-01ab-4a01-9cde-1d0a3f5d7b90.

[0171] In conjunction with the backend service, the initial feature parameters F0 of the interface are generated using the formula F0 = (R - G - C) ∪ M. Where R = request header ∪ request parameters, G = {timestamp, traceId, requestId, nonce}, C = {productId, count}, and M = {token, ip}. After removing non-feature fields and content fields, the initial candidate key set F0 = {userId, token, ip} is obtained.

[0172] Subsequently, based on the initial candidate key set F0 of the interface, a sliding window statistical filtering is performed on the interface messages provided by the gateway, and the target key-value pair set FinalFeature is represented by formula (2).

[0173] FinalFeature = { (k=v) | N(k=v, W) > T} (2)

[0174] Where k=v represents a key-value pair, where k is the field name (key) and v is the field value (value). N(k=v, W) represents the total number of times the key-value pair (k=v) appears within the sliding time window W. T represents the preset frequency threshold. Formula (2) means that within the last W seconds, if a specific value of a certain request field (such as token, ip) is accessed more than T times, it will be added to the target key-value pair set for subsequent real-time interception by the gateway. For example, given W = 10s, T = 200, within a certain time window, receive asynchronously provided messages from the gateway and count the occurrences of each field in F0. Assume that: token: N(token="a0f2d9c3-8e0c-4b15-9f7c-6b2e9b7f2d91", 10s) = 560 > 200, meaning that a specific token value has been accessed 560 times in the last 10 seconds, exceeding 200; ip: N(ip="10.9.3.77", 10s) = 770 > 200, meaning that a specific IP value has been accessed 770 times in the last 10 seconds, exceeding 200; userId: N(userId=U1, 10s) = 15 < 200, meaning that a specific userId value has been accessed 15 times in the last 10 seconds, not exceeding 200. Then, the target key-value pair set FinalFeature = { The token is set to "a0f2d9c3-8e0c-4b15-9f7c-6b2e9b7f2d91", and the IP address is set to "10.9.3.77". After extracting the target key-value pair set "FinalFeature" from the target interface, the set is written back to the gateway module, allowing the gateway to perform the request message feature determination process. In this way, the asynchronous processing module extracts the features of a specified interface or link and writes them back to the gateway module, forming a closed loop.

[0175] This embodiment obtains the complete set of interface request parameters from the interface documentation information of the target interface, removes the set of general non-feature parameters and the set of interface content parameters to obtain an intermediate candidate key set, and then merges the intermediate candidate key set with the specified parameter set to obtain the initial candidate key set. This filters out irrelevant field names, ensuring that the initial candidate key set only contains field names that could be used by abnormal traffic to forge identities or bypass verification, thus improving the accuracy and efficiency of abnormal traffic detection. This method solves the problems of the initial candidate key set containing a large number of irrelevant field names, high computational overhead, and low efficiency in related technologies, and improves the overall performance of abnormal traffic detection.

[0176] In one exemplary embodiment, when maintaining a trie in the gateway's memory, traditional methods typically involve permanently storing the trie without setting an expiration date. This approach means the trie remains in the gateway's memory even after abnormal traffic stops, consuming significant memory resources and resulting in low memory utilization, thus impacting the gateway's processing performance. Furthermore, permanently storing the trie cannot adapt to the flexible and ever-changing characteristics of abnormal traffic. When abnormal traffic accesses the gateway with different characteristic parameters, the old trie cannot accurately reflect the latest abnormal traffic characteristics, leading to a decrease in the accuracy of abnormal traffic identification.

[0177] To address the aforementioned issues, this embodiment sets an expiration date for the trie. When the trie's duration in the gateway's memory exceeds its expiration date, it is automatically deleted, thereby freeing up memory resources and improving memory utilization. Furthermore, by setting an expiration date, the system can adapt to the flexible and ever-changing characteristics of abnormal traffic, ensuring that the trie always reflects the latest abnormal traffic features and improving the accuracy of abnormal traffic identification.

[0178] In some embodiments, the trie has a preset validity period; the method further includes: deleting the trie in response to the trie existing in the gateway memory for a period exceeding the validity period.

[0179] In this embodiment, abnormal traffic is typically phased and does not last for a long time. During the abnormal traffic phase, the dictionary is used to quickly identify the abnormal traffic, improving processing efficiency. After the abnormal traffic stops, the dictionary is no longer needed. If it still exists in the gateway's memory, it will consume a large amount of memory resources and reduce memory utilization. By setting an expiration period, it can be ensured that the dictionary is only stored in the gateway's memory during the abnormal traffic phase, without causing excessive memory consumption. At the same time, abnormal traffic characteristics are flexible and changeable. Older dictionaries may not accurately reflect the latest abnormal traffic characteristics. By setting an expiration period and periodically deleting older dictionaries, the asynchronous processing module can be prompted to re-collect the latest characteristic information and build a new dictionary, ensuring that the dictionary always reflects the latest abnormal traffic characteristics.

[0180] The expiration period refers to the maximum time a trie is allowed to exist in the gateway's memory, controlling its lifecycle. The expiration period can be adjusted according to actual needs, such as 5 minutes, 10 minutes, or 30 minutes. Its purpose is to prevent the trie from occupying memory resources for extended periods, ensuring it is promptly deleted after abnormal traffic ceases, thus freeing up memory space. For example, a 10-minute expiration period means the trie will exist in the gateway's memory for a maximum of 10 minutes, after which it will be automatically deleted.

[0181] The duration of a trie's existence in the gateway's memory refers to the time elapsed from its creation to the current moment, used to determine if the trie has exceeded its validity period. The duration is calculated by subtracting the trie's creation time from the current moment. The unit of duration is typically seconds, minutes, or hours, consistent with the unit of validity. For example, if the trie was created at 10:00:00 and the current moment is 10:08:00, then its existence duration is 8 minutes.

[0182] In some embodiments, when the feature key-value pairs in the gateway memory expire, the rate limiting judgment process will be automatically skipped. This method will not increase the computing power consumption of the gateway by performing unnecessary matching processes, nor will it cause the gateway memory to accumulate storage.

[0183] In some embodiments, by default, the validity period of features in the gateway memory is consistent with the sliding time window. Each time a feature is counted within the sliding time window, the feature information is written back to the gateway module. The feature information in the gateway module automatically becomes invalid after it expires. This method ensures that the gateway memory maintains valid feature information.

[0184] In this embodiment, whether it's traffic scrubbing by WAF or DDoS protection products, or scoring requests to determine the risk level of traffic, these mainstream wide-coverage protection methods will intrude on traffic requests to some extent, such as by tagging traffic. This embodiment not only does not affect the request packets, but also ensures that the gateway memory only stores valid information, achieving non-intrusive link operation. Traffic does not need to worry that the processing of this device will affect the packets themselves.

[0185] Optionally, after receiving a request message, the gateway layer first determines whether the requested link has a trie in the gateway's memory. If it does, it records the creation time of the trie and calculates the duration of the trie in the gateway's memory. The gateway layer then determines whether the duration of the trie in the gateway's memory has exceeded its validity period. If the duration has exceeded its validity period, the gateway layer deletes the trie and releases memory resources. If the duration has not exceeded its validity period, the gateway layer continues to use the trie for abnormal traffic detection. After deleting the trie, the gateway layer forwards the request message to the backend service module and stops detecting abnormal traffic.

[0186] This embodiment sets an expiration period for the trie. When the trie's existence time in the gateway's memory exceeds the expiration period, it is automatically deleted, releasing memory resources and improving memory utilization. Simultaneously, by setting an expiration period, it adapts to the flexible and ever-changing characteristics of abnormal traffic, ensuring that the trie always reflects the latest abnormal traffic features and improving the accuracy of abnormal traffic detection. This method solves the problems of permanent trie storage, excessive memory consumption, and inability to adapt to flexible and changing abnormal traffic characteristics in related technologies, thus improving the overall performance of abnormal traffic detection.

[0187] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0188] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the related technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory (ROM) / random access memory (RAM), magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0189] According to another aspect of the embodiments of this application, an abnormal traffic processing apparatus is also provided, which can be used to implement the abnormal traffic processing method provided in the above embodiments, and will not be repeated hereafter. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0190] Figure 6 This is a structural block diagram of an optional abnormal traffic processing device according to an embodiment of this application, such as... Figure 6 As shown, the abnormal flow processing device includes:

[0191] The acquisition module 602 is used to acquire the request message, which contains the request path of the target interface.

[0192] The abnormal traffic processing module 604 is used to mark the request message as abnormal traffic and limit the request message in response to the satisfaction of the preset judgment conditions. The preset judgment conditions include: the gateway memory has a trie of the target interface, the request message includes all candidate keys in the trie, and the feature value of the target feature key in the request message that matches the target candidate key in the trie matches one of the candidate values ​​in the set of candidate values ​​associated with the target candidate key.

[0193] It should be noted that the acquisition module 602 in this embodiment can be used to perform the above step S202, and the abnormal traffic processing module 604 in this embodiment can be used to perform the above step S204.

[0194] In an exemplary embodiment, multiple candidate keys in the trie are divided into multiple first buckets according to their key lengths; each first bucket corresponds to a different key length; each first bucket includes at least one candidate key; the abnormal traffic processing module 604 is further configured to take each first bucket as the current first bucket, take each candidate key in the current first bucket as the current candidate key, and perform the following operations: match at least one feature key in the request message whose key length matches the key length corresponding to the current first bucket with the current candidate key; in response to the existence of a feature key that matches the current candidate key among at least one feature key, determine that the request message includes the current candidate key; in response to the request message including each candidate key in the trie, determine that the request message includes all candidate keys in the trie.

[0195] In one exemplary embodiment, each candidate value in the candidate value set associated with each candidate key is divided into multiple second buckets according to its value length; each of the multiple second buckets corresponds to a different value length; each second bucket includes at least one candidate value; the abnormal traffic processing module 604 is further configured to determine the target bucket in the second bucket corresponding to the candidate value set associated with the target candidate key whose value length matches the feature value of the target feature key, and match at least one candidate value in the target bucket with the feature value of the target feature key; in response to the existence of a candidate value in the target bucket that matches the feature value of the target feature key, determine that the feature value of the target feature key matches a candidate value in the candidate value set associated with the target candidate key.

[0196] In an exemplary embodiment, each second bucket corresponds to a local random byte position table; the local random byte position table corresponding to each second bucket includes multiple byte positions; the abnormal traffic processing module 604 is further configured to extract the first byte at multiple byte positions from the feature value of the target feature key according to the local random byte position table corresponding to the target bucket, and extract the second byte at multiple byte positions from each candidate value in the target bucket; compare the first byte at each byte position in the feature value of the target feature key with the second byte at the same byte position in each candidate value in the target bucket; and determine that there is a candidate value in the target bucket that matches the feature value of the target feature key in response to the existence of a candidate value in the target bucket that matches the feature value of the target feature key.

[0197] In an exemplary embodiment, the abnormal traffic processing module 604 is further configured to obtain an initial candidate key set of the target interface; the initial candidate key set refers to the set of request field names used for identity forgery or bypassing verification; obtain multiple historical request messages that request to call the target interface within a preset sliding time window, and count the frequency of each candidate key in the initial candidate key set appearing in multiple historical request messages; remove candidate key-value pairs whose frequency is less than a preset frequency threshold to obtain a target key-value pair set; and construct a prefix tree structure with each candidate key in the target key-value pair set as the terminal node and the candidate value of each candidate key in the target key-value pair set as the leaf node value to obtain a trie.

[0198] In an exemplary embodiment, the abnormal traffic processing module 604 is further configured to obtain the complete set of allowed interface request parameters of the target interface from the interface documentation information of the target interface; the complete set of interface request parameters refers to the set of all candidate keys predefined in the interface documentation information that are allowed to be carried in the request message; the set of general non-feature parameters and the set of interface content parameters are removed from the complete set of interface request parameters to obtain an intermediate candidate key set; the intermediate candidate key set is merged with the specified parameter set to obtain an initial candidate key set; the set of general non-feature parameters refers to the set of field names that are common to the target interface; the set of interface content parameters refers to the set of field names that cannot be forged by abnormal traffic; and the set of specified parameters refers to the set of pre-specified field names.

[0199] In an exemplary embodiment, the abnormal traffic processing module 604 is further configured to divide candidate values ​​with the same value length in the trie into the same second bucket to obtain multiple second buckets; determine the number of random positions according to the number of candidate values ​​in each second bucket, and select the byte positions of the number of random positions from the global random byte position table corresponding to each second bucket in sequence as the local random byte position table corresponding to each second bucket.

[0200] In an exemplary embodiment, the abnormal traffic processing module 604 is further configured to perform logarithmic processing on the number of candidate values ​​in each second bucket to obtain a logarithmic result, round the logarithmic result up to obtain an integer result, and determine the largest of the integer result and the preset minimum base as the number of random positions.

[0201] In one exemplary embodiment, the trie has a preset validity period; the abnormal traffic processing module 604 is further configured to delete the trie in response to the trie existing in the gateway memory for a period exceeding the validity period.

[0202] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0203] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein the program executes the steps in any of the above method embodiments when it is run.

[0204] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, ROMs, RAMs, portable hard drives, magnetic disks, or optical disks.

[0205] According to another aspect of the embodiments of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor is configured to perform the steps of any of the method embodiments described above via the computer program. In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0206] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0207] According to another aspect of the embodiments of this application, a computer program product is also provided, comprising a computer program / instructions containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit 701, it performs various functions provided in the embodiments of this application. The sequence numbers of the embodiments of this application above are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0208] Figure 7 A schematic block diagram of a computer system architecture for implementing embodiments of the present application is shown. Figure 7 As shown, the computer system 700 includes a Central Processing Unit (CPU) 701, which performs various appropriate actions and processes based on programs stored in ROM 702 or loaded into RAM 703 from storage section 708. Random access memory 703 also stores various programs and data required for system operation. The CPU 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interface 705 is also connected to bus 704.

[0209] The following components are connected to the I / O interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), and speakers, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card, such as a local area network card or modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the input / output interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 710 as needed so that computer programs read from it can be installed into the storage section 708 as needed.

[0210] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit 701, it performs various functions defined in the system of this application.

[0211] It should be noted that, Figure 7 The computer system 700 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0212] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0213] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A method for handling abnormal traffic, characterized in that, The method includes: Obtain the request message, which contains the request path of the target interface; In response to the satisfaction of a preset judgment condition, the request message is marked as abnormal traffic and the request message is rate-limited. The preset judgment condition includes: the gateway memory contains a trie of the target interface, the request message includes all candidate keys in the trie, and the feature value of the target feature key in the request message that matches the target candidate key in the trie matches one of the candidate value sets associated with the target candidate key.

2. The method according to claim 1, characterized in that, The multiple candidate keys in the trie are divided into multiple first buckets according to their key lengths; each of the multiple first buckets corresponds to a different key length; the method further includes: Take each first bucket as the current first bucket, and take each candidate key in the current first bucket as the current candidate key, and perform the following operations: match at least one feature key in the request message whose key length matches the key length corresponding to the current first bucket with the current candidate key; in response to the existence of a feature key among the at least one feature key that matches the current candidate key, determine that the request message includes the current candidate key; In response to the request message including each candidate key in the trie, it is determined that the request message includes all candidate keys in the trie.

3. The method according to claim 1, characterized in that, Each candidate value in the candidate value set associated with each candidate key is divided into multiple second buckets according to its value length; Each of the plurality of second buckets corresponds to a different value length; the method further includes: Determine the target bucket in the second bucket corresponding to the candidate value set associated with the target candidate key that matches the value length of the feature value of the target feature key, and match at least one candidate value in the target bucket with the feature value of the target feature key; In response to the existence of a candidate value in the target bucket that matches the feature value of the target feature key, it is determined that the feature value of the target feature key matches a candidate value in the set of candidate values ​​associated with the target candidate key.

4. The method according to claim 3, characterized in that, Each second bucket corresponds to a local random byte position table; the local random byte position table corresponding to each second bucket includes multiple byte positions; The step of matching at least one candidate value in the target bucket with the feature value of the target feature key includes: According to the local random byte position table corresponding to the target bucket, extract the first byte at multiple byte positions from the feature value of the target feature key, and extract the second byte at multiple byte positions from each candidate value in the target bucket; The first byte at each byte position of the feature value of the target feature key is compared with the second byte at the same byte position in each candidate value of the target bucket; In response to the existence of a candidate value in the target bucket that matches the feature value of the target feature key, it is determined that there is a candidate value in the target bucket that matches the feature value of the target feature key.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: Obtain the initial candidate key set of the target interface; the initial candidate key set refers to the set of request field names used for identity forgery or bypassing verification; Obtain multiple historical request messages that request to call the target interface within a preset sliding time window, and count the frequency of each candidate key in the initial candidate key set appearing in the multiple historical request messages; Candidate key-value pairs with frequencies less than a preset frequency threshold are removed to obtain the target key-value pair set; Using each candidate key in the target key-value pair set as the terminal node and the candidate value of each candidate key in the target key-value pair set as the leaf node value, a prefix tree structure is constructed to obtain the trie.

6. The method according to claim 5, characterized in that, The step of obtaining the initial candidate key set for the target interface includes: Obtain the complete set of allowed interface request parameters for the target interface from the interface documentation information of the target interface; the complete set of interface request parameters refers to the set of all candidate keys predefined in the interface documentation information that are allowed to be carried in the request message; The set of general non-feature parameters and the set of interface content parameters are removed from the complete set of interface request parameters to obtain an intermediate candidate key set. The intermediate candidate key set is then merged with the specified parameter set to obtain the initial candidate key set. The set of general non-feature parameters refers to the set of field names common to the target interface. The set of interface content parameters refers to the set of field names that cannot be forged by abnormal traffic. The set of specified parameters refers to the set of pre-specified field names.

7. The method according to any one of claims 1 to 4, characterized in that, The method further includes: Candidate values ​​with the same length in the trie are grouped into the same second bucket, resulting in multiple second buckets; Based on the number of candidate values ​​in each second bucket, a number of random positions is determined, and the byte positions of the number of random positions are selected sequentially from the global random byte position table corresponding to each second bucket to serve as the local random byte position table corresponding to each second bucket.

8. The method according to claim 7, characterized in that, The step of determining the number of random positions based on the number of candidate values ​​in each second bucket includes: Logarithmic processing is performed on the number of candidate values ​​in each second bucket to obtain a logarithmic result, and the logarithmic result is rounded up to obtain an integer result. The larger of the integer result and the preset minimum base number is determined as the number of random positions.

9. The method according to any one of claims 1 to 4, characterized in that, The trie has a preset validity period; the method further includes: In response to the fact that the trie has existed in the gateway memory for a period exceeding the validity period, the trie is deleted.

10. An abnormal flow processing device, characterized in that, include: The acquisition module is used to acquire a request message, which contains the request path of the target interface. An abnormal traffic processing module is used to mark the request message as abnormal traffic and limit the flow of the request message in response to the satisfaction of a preset judgment condition. The preset judgment condition includes: the gateway memory contains a trie of the target interface, the request message includes all candidate keys in the trie, and the feature value of the target feature key in the request message that matches the target candidate key in the trie matches one of the candidate value sets associated with the target candidate key.

Images