A multi-feature code matching method and device, electronic equipment, medium and program product

Abstract

The application belongs to the technical field of data processing, and specifically discloses a multi-feature code matching method and device, electronic equipment, medium and program product. The method matches effective messages based on a single-feature code line-speed matching algorithm, and constructs single-feature code original information containing identification information, matching attribute information, user association information and matching state information. Then, according to an anchor point marking bit judgment rule type, if it is a normal rule, the combination type and serial number are queried by combination identification, and hierarchical multi-feature code matching is performed. If it is an anchor point rule, pure anchor point feature code matching is performed based on an anchor point type and anchor point identification. The method differentiates between normal rules and anchor point rules, effectively solves the problems of high complexity of multi-feature code combination rules, table item expansion and large resource occupation, realizes efficient identification and matching of multi-dimensional message features, and has the advantages of high processing performance, low resource consumption and good expansibility.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, specifically relating to a multi-feature code matching method, device, electronic equipment, medium, and program product. Background Technology

[0002] Signature matching is commonly used in the following scenarios: Malware detection: By extracting unique code snippets (signatures) from malware and comparing them with target files or traffic, known threats are identified; Attack pattern recognition: Specific characteristics of network attacks (such as packet structure, protocol anomalies, etc.) are extracted to detect known attack behaviors; Virus scanning: Antivirus software compares files against a signature database to identify and remove known viruses; Intrusion detection and prevention: Intrusion detection systems (IDS) and firewalls use signature rules to monitor network traffic and block known attacks; Automated response: When a threat matching a signature is detected, the system can automatically isolate or delete malicious files and block attack traffic. In telecommunications value-added services, deep packet inspection (DPI), also known as signature rules, is used by devices to identify and forward data traffic based on service type.

[0003] As the combination of multiple feature codes becomes a regular requirement, how to flexibly achieve high-performance, high-capacity, multi-dimensional feature code combinations has become a trend in the development of feature code rule technology. Therefore, how to achieve high-performance multi-feature code matching with minimal resource consumption while satisfying flexibility and high rule capacity is a problem worth studying. Summary of the Invention

[0004] To address this issue, the present invention provides a multi-feature code matching method, apparatus, electronic device, medium, and computer program product to solve the aforementioned technical problems.

[0005] This invention provides a multi-feature code matching method, comprising the following steps:

[0006] Step S101: Preprocess the received message to obtain a valid message;

[0007] Step S102: Perform single-feature code matching on the valid message based on the single-feature code line-speed matching algorithm, and construct the original information of the single-feature code for the successfully matched string; the original information includes identification information, matching attribute information, user association information, and matching status information, wherein the identification information includes feature code ID, comb identifier comb_id, and comb identifier sequence number group_index, and the matching attribute information includes anchor flag bit anchor_flag, anchor type anchor_type, and anchor identifier anchor_id;

[0008] Step S103: Determine the rule type based on the anchor_flag. The rule type includes ordinary rules or anchor rules. Ordinary rules are rules where a single feature code belongs to only one specific multi-feature code combination rule and has no common reuse attribute. Anchor rules are rules where a single feature code belongs to the common sub-item of multiple multi-feature code combination rules.

[0009] Step S104: For ordinary rules, query the preset combination type group_type and combination identifier sequence number group_index through the combination identifier comb_id, and perform hierarchical multi-feature code matching based on the combination type and the combination identifier sequence number. The combination type is used to identify the multi-feature code combination level corresponding to the ordinary rule, and the combination identifier sequence number is used to identify the level of the single feature code in the combination rule.

[0010] Step S105: For anchor rules, perform pure anchor feature code matching based on anchor type (anchor_type) and anchor identifier (anchor_id). Anchor type (anchor_type) is used to identify the multi-feature code combination scenario corresponding to the anchor rule, and anchor identifier (anchor_id) is a unique identifier assigned to each anchor rule.

[0011] In another aspect, this application also provides a multi-feature code matching device, comprising:

[0012] The preprocessing module is used to preprocess the received messages to obtain valid messages;

[0013] The single-feature code matching module is used to perform single-feature code matching on the valid message based on the message single-feature code line-speed matching algorithm, and to construct the original information of the single-feature code for the successfully matched string; the original information includes identification information, matching attribute information, user association information, and matching status information, wherein the identification information includes feature code ID, comb identifier comb_id, and comb identifier sequence number group_index, and the matching attribute information includes anchor flag bit anchor_flag, anchor type anchor_type, and anchor identifier anchor_id;

[0014] The rule type determination module is used to determine the rule type based on the anchor flag bit (anchor_flag). The rule type includes ordinary rules or anchor rules. Ordinary rules are rules where a single feature code belongs to only one specific multi-feature code combination rule and has no common reuse attributes. Anchor rules are rules where a single feature code belongs to the common sub-item of multiple multi-feature code combination rules.

[0015] The ordinary rule matching module is used to query the preset combination type group_type and combination identifier sequence number group_index for ordinary rules by using the combination identifier comb_id. It performs hierarchical multi-feature code matching based on the combination type and the combination identifier sequence number. The combination type is used to identify the number of multi-feature code combination levels corresponding to the ordinary rule, and the combination identifier sequence number is used to identify the level of a single feature code in the combination rule.

[0016] The anchor rule matching module performs pure anchor feature code matching based on the anchor type (anchor_type) and anchor identifier (anchor_id) for anchor rules. The anchor type (anchor_type) is used to identify the multi-feature code combination scenario corresponding to the anchor rule, and the anchor identifier (anchor_id) is a unique identifier assigned to each anchor rule.

[0017] This application also provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a multi-feature code matching method as described above.

[0018] In another aspect, this application provides a computer-readable storage medium having stored thereon computer program instructions that can be executed by a processor to implement a multi-feature code matching method as described above.

[0019] Another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements a multi-feature code matching method as described above.

[0020] This invention proposes an efficient multi-feature code matching method by combining BRAM and URAM cache resources within an FPGA. This method introduces an anchor rule mechanism, effectively solving the problem of entry bloat caused by repeated feature code association under multiple combination rules. Its advantages are twofold: firstly, it achieves large-capacity, multi-level feature code combination matching with fewer hardware resources, improving processing performance and scalability; secondly, the off-processing mechanism of ordinary rules and anchor rules, combined with one-hot code parallel comparison, significantly reduces latency and ensures line-speed processing capability. Simultaneously, this scheme supports flexible rule expansion and rapid iterative upgrades, adapting to the multi-dimensional service identification needs in high-density network environments, and possesses the beneficial effects of high performance, low resource consumption, simple structure, and good scalability. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0022] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0023] Figure 1 The flowchart illustrates a multi-feature code matching method provided in an embodiment of the present invention.

[0024] Figure 2 This is a schematic diagram of a single feature code matching process provided in an embodiment of the present invention.

[0025] Figure 3 This is a flowchart illustrating the general rule matching process provided in an embodiment of the present invention.

[0026] Figure 4 This is a flowchart illustrating the anchor point rule matching process provided in an embodiment of the present invention.

[0027] Figure 5 This is a schematic diagram of the structure of a multi-feature code matching device provided in an embodiment of the present invention.

[0028] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0030] Currently, the mainstream solution for multi-feature code matching in splitters is to achieve multi-feature code matching output based on the software processing structure of network processor NPS400+DDR4. Although the NPS chip can achieve flexibility and DDR4 memory can meet the huge capacity of combination rules, poor performance has become an undeniable weakness, especially in high-density 100G network aggregation links where string detection performance requirements are increasingly high.

[0031] Furthermore, conventional FPGA design implementations based on conventional combination rules have a significant drawback. If a level 2 combination rule of A1B1, A1B2, A1B3...A1Bn exists, and the A1 feature code is one of N combination rule sub-items, then the A table entry needs to be associated with N combination IDs to achieve the combination of N rules of A1B1, A1B2, A1B3...A1Bn. In conventional FPGA design, it is virtually impossible to implement such a large linked list of entries, and matching also becomes a problem.

[0032] In response to the above special cases and in light of practical considerations, this invention proposes a special type of sub-item rule in combination rules, defined as anchor rule (i.e., sub-item combination rule; if it appears in multiple combination rules, this type of sub-item rule is called anchor rule in this invention, such as the A1 sub-item rule described above). For anchor rule, it is no longer necessary to assign a combination ID to each combination rule separately, which can be simplified to 1-4 level combination rules. It combines the FPGA's internal high-speed cache BRAM and URAM, resulting in a simple design, high performance, and good scalability. For example, it commonly supports multi-feature code combinations up to 4 levels. If there is a need to expand to combinations of more than 4 levels in the future, the design can be quickly iterated and upgraded to meet the requirements. At the same time, the design facilitates the expansion of multiple feature codes.

[0033] This invention employs an internal FPGA cache to achieve a high-performance multi-signature code matching message output design with relatively low resource consumption. This is typically achieved by setting multiple signature code rules on the device, as a single service may require multiple signature code rules to describe it. In such cases, the combined matching of multiple signature code rules becomes particularly important.

[0034] like Figure 1 As shown, this embodiment of the invention discloses a multi-feature code matching method 100, which includes the following method steps:

[0035] Step S101: Preprocess the received message to obtain a valid message.

[0036] In some embodiments, this step filters valid packets with complete format and matching requirements from the raw link data, eliminating invalid signals and erroneous data. Specifically, low-latency processing is implemented based on an FPGA hardware architecture. For example, the specific process includes:

[0037] The FPGA performs preliminary processing of the raw signal through an external physical interface (such as a 100G Ethernet PHY chip), focusing on eliminating invalid data caused by link noise. The FPGA parses the physical layer frame's preamble (7-byte synchronization sequence), start-of-frame delimiter (SFD, 1 byte "10101011"), data fields, and frame check sequence (FCS, 4 bytes) according to standards. The parsing results are then evaluated for validity. If no valid SFD is detected, or if the frame length exceeds the standard range (e.g., minimum 64 bytes, maximum 9216 bytes), it is directly deemed an invalid signal and discarded, retaining only compliant physical layer frames.

[0038] The system extracts fields such as version number, IP header length (IHL), and total length from the message to define the message boundaries and data structure, and performs format conversion to adapt to subsequent signature matching requirements. It then compares the CRC32 checksum of the physical layer frame with the real-time calculated value using FCS checksum; if they do not match, the message is considered a transmission error. Finally, it verifies the compliance of fields such as IP header IHL and TCP header data offset using protocol header length checksum (e.g., the minimum IP header IHL value is 5, corresponding to 20 bytes); if abnormal, the message is considered a format error message. Both types of error messages are directly discarded, and only messages that successfully adapt to the protocol and pass dual verification are retained.

[0039] Step S102: Perform single-feature code matching on the valid message based on the single-feature code line-speed matching algorithm, and construct the original information of the single-feature code for the successfully matched string; the original information includes identification information, matching attribute information, user association information, and matching status information, wherein the identification information includes feature code ID, comb_id, and group_index, and the matching attribute information includes anchor_flag, anchor_type, and anchor_id.

[0040] Optionally, such as Figure 2 As shown, the single-feature code matching of the valid message is performed based on the single-feature code line-speed matching algorithm, including:

[0041] Step S201: First, use the Bloom algorithm to quickly filter message segments with no possible matches. Step S202: Then, use the FDR algorithm to construct a prefix trie to achieve fast retrieval of variable-length prefixes and locate the prefix segment in the message containing the target feature code. Step S203: Based on the matched prefix segment, extract the complete string in the message starting with the prefix segment. Specifically, use the parallel comparator inside the FPGA to perform a bit-width aligned parallel comparison with the target complete feature code stored in the FPGA's internal cache.

[0042] In some embodiments, for the Bloom algorithm to quickly filter message segments with no possible matches, for example, firstly, a target feature code prefix-Bloom bit array mapping table is constructed in the URAM inside the FPGA: all single feature code prefixes to be matched (such as IP address prefix "192.168.", port prefix "80") are mapped to a fixed-length binary bit array (such as 1024 bits) through 3-4 independent hash functions, and the corresponding positions are marked as "1"; then, after the valid message output in step S101 enters the FPGA, the field segments to be matched (such as IP header field, TCP port field) in the message are extracted, and their mapping positions in the Bloom bit array are calculated through the same hash function; if all mapping positions are "1", it is determined that the segment "may contain the target prefix", and proceeds to the next step; if any position is "0", it is directly determined that "no match is possible", and the subsequent process is skipped, which greatly reduces the overhead of invalid matching.

[0043] Regarding the construction of a prefix trie using the FDR algorithm to achieve fast retrieval of variable-length prefixes, for example, for segments filtered by the Bloom algorithm, a prefix trie (Trie tree) is constructed using the FDR (Fast Dictionary Retrieval) algorithm to achieve fast location of variable-length prefixes, adapting to the parallel access characteristics of FPGA.

[0044] Specifically, a prefix trie is constructed in the FPGA's internal BRAM: each node of the tree corresponds to a character of the feature code prefix (e.g., "192.168." corresponds to nodes "1", "9", "2", ".", "1", "6", "8", "."). The nodes store information such as whether it is a complete prefix and the address of the next-level node. When a fragment is input, the FPGA uses parallel node access logic to traverse multiple branches of the trie simultaneously (e.g., comparing the "192.168." and "10.0." branches at the same time), without needing to traverse serially. If, when traversing to a certain node, the fragment character is completely consistent with the node character and the node is marked as a complete prefix, then the prefix fragment containing the target feature code is successfully located (e.g., locating "192.168." in the IP field).

[0045] Next, based on the located prefix fragment, the complete string is extracted and compared with the target feature code to ensure matching accuracy. Specifically, firstly, according to the protocol attributes of the prefix fragment (e.g., IP prefix corresponds to a 32-bit IPv4 address, port prefix corresponds to a 16-bit TCP port), the complete string starting with the prefix is ​​extracted from the valid packet (e.g., prefix "192.168." corresponds to the complete IP address "192.168.1.100", prefix "80" corresponds to the complete port "80"); then, the list of target complete feature codes (e.g., "192.168.1.0 / 24" "80") is stored in the FPGA's internal BRAM, and a parallel comparator array (e.g., 32-bit or 64-bit width) is constructed; the extracted complete string and the target complete feature code are compared in parallel after being aligned with the bit width (e.g., a 32-bit IP address is compared with 32 bits of data at once, rather than a byte-by-byte serial comparison). If the comparison result is completely consistent, the single feature code is determined to be a successful match; if they are inconsistent, the match is determined to be a failure, and the current feature code matching process is terminated.

[0046] In one embodiment, based on the successful matching of a single feature code, multi-dimensional information is extracted from a preset mapping table inside the FPGA to construct complete original information of the single feature code.

[0047] Specifically, the identification information is used to clarify the combination rule and level to which the successfully matched single feature code belongs. For example, it includes:

[0048] Feature ID (feature_id): Extracted from the full feature code-feature ID mapping table preset in the FPGA's internal BRAM. A unique 16-bit identifier is assigned to each successfully matched full feature code (e.g., "192.168.1.0 / 24" corresponds to feature_id=0x0001), which is used as a unique index for subsequent original information;

[0049] Comb ID: Extracted from the preset feature ID-comb_id mapping table (stored in URAM), it identifies the ordinary combination rule group to which the single feature code belongs (e.g., feature_id=0x0001 corresponds to comb_id=0x0A, which means it belongs to the "IP + port" type combination rule). Only single feature codes of ordinary rules contain this field.

[0050] The group_index identifier is extracted from the preset comb_id-group_index mapping table. It identifies the hierarchical sequence number of the single feature code in the combination rule (e.g., group_index=1 for IP feature code and group_index=2 for port feature code), and is used for subsequent hierarchical combination matching.

[0051] For example, the matching attribute information is used to distinguish whether a single feature code is a regular rule or an anchor rule, and specifically includes, for example:

[0052] Anchor_flag: Extracted from the preset feature ID-anchor_flag mapping table, it is a 1-bit binary identifier (1 = anchor rule, 0 = ordinary rule). Anchor rule means that the single feature code is a common sub-item of multiple combination rules (such as "192.168." belongs to the combination of "A1B1" and "A1B2" at the same time). Ordinary rule means that it belongs to only a specific combination rule.

[0053] Anchor type: Only included in anchor rules (anchor_flag=1), extracted from the anchor identifier-anchor type mapping table, indicating the protocol scenario to which the anchor belongs (e.g., 0x01=IP layer anchor, 0x02=transport layer anchor), used for subsequent pure anchor matching scenario filtering;

[0054] Anchor ID (anchor_id): Contained only by anchor rules, extracted from the feature ID-anchor ID mapping table, and assigned a unique 16-bit identifier to each anchor rule (e.g., "192.168." corresponds to anchor_id=0x10), used for indexing pure anchor matching.

[0055] For example, user association information is used to associate single feature code matching results with specific user business rules. This includes an independent user identifier usr_id (8 bits, such as usr_id=0x05, which identifies the user to whom the feature code belongs) and a user enable status usr_en (1 bit, 1=enabled, 0=disabled, which indicates whether the user has enabled the feature code matching rule). Both are extracted from the FPGA internal feature code ID-user information mapping table (URAM storage) and are used for subsequent priority selection based on the independent user dimension.

[0056] For example, regarding the matching status information, the matching status information is used to identify the validity of a single feature code match. It includes, for example, a valid flag (1 bit, 1 = successful match, 0 = failed match) and a matching position offset (16 bits, indicating the starting byte offset of the feature code in the message, such as offset=0x000C for IP feature codes in the 12th byte of the message). These are generated in real time by the FPGA matching module and written into the original information to ensure that subsequent processes can quickly identify valid matching results.

[0057] Step S103: Determine the rule type based on the anchor_flag. The rule type includes ordinary rules or anchor rules. Ordinary rules are rules where a single feature code belongs to only one specific multi-feature code combination rule and has no common reuse attribute. Anchor rules are rules where a single feature code belongs to a common sub-item of multiple multi-feature code combination rules.

[0058] Specifically, in the original information of the single feature code output in step S102, the matching attribute information includes a 1-bit binary anchor flag bit, anchor_flag. The FPGA directly extracts this field from the original information. If anchor_flag=0, it is determined to be a normal rule. A normal rule means that the single feature code belongs to only one specific multi-feature code combination rule and has no common reuse attribute (such as TCP port "80" only belonging to the combination rule "IP=192.168.1.0 / 24+port=80"). This triggers the subsequent normal rule hierarchical multi-feature code matching process.

[0059] If anchor_flag=1, it is determined to be an anchor rule. The anchoring rule is that the single feature code is a common sub-item of multiple multi-feature code combination rules (such as the IP prefix "192.168." belonging to the combination rules such as "192.168.+port 80" and "192.168.+port 443"). It will not enter the subsequent ordinary rule process in this step, but will be processed in the subsequent pure anchor matching stage.

[0060] Step S104: For ordinary rules, query the preset combination type group_type and combination identifier sequence number group_index by using the combination identifier comb_id. Perform hierarchical multi-feature code matching based on the combination type and combination identifier sequence number. The combination type is used to identify the level of multi-feature code combination corresponding to the ordinary rule, and the combination identifier sequence number is used to identify the level of a single feature code in the combination rule.

[0061] Optionally, such as Figure 3 As shown in the schematic diagram of the ordinary rule matching process, step S301 involves classifying and caching single feature codes based on the combination type group_type and the combination identifier sequence number group_index. Specifically, the combination type is divided into cache partitions based on the combination level, and each partition independently stores the sub-feature code data of the corresponding level. Within each combination type partition, sub-cache areas are further divided according to the hierarchical sequence number of the sub-feature codes. Step S302 involves verifying whether the message contains all the sub-feature codes corresponding to the independent group_index based on the level determined by group_type. If so, for each group_type, the matching of all hierarchical sub-feature codes is verified synchronously and in parallel. Step S303 involves outputting the multi-feature code matching identifier group_id after a successful match.

[0062] Optionally, in step S304, a preset multi-level combined anchor matching table is queried using group_id; in step S305, the anchor identifier anchor_id of the message is converted to a one-hot code; in step S306, if the message contains multiple anchor information, a merging operation is performed first; in step S307, the processed anchor information is compared with the anchor information in the multi-level combined anchor matching table, and if the match is successful, the user rule identifier usr_policy_id and the user identifier usr_en are output; the preset multi-level combined anchor matching table is constructed based on the FPGA's internal URAM, the table key is group_id, and the stored content includes anchor matching conditions and user rule information. The anchor matching conditions include the anchor type to be matched, the number of anchors, and the anchor combination logic. The user rule information includes usr_policy_id and usr_en.

[0063] In some embodiments, this step is based on the original single feature code information output in step S102, the rule type is determined by the anchor point marker, hierarchical multi-feature code matching and anchor point verification are performed on ordinary rules, and finally the user rule information is output.

[0064] For example, regarding the general rule-based hierarchical multi-feature code matching process, it is firstly implemented by constructing a hierarchical cache system through the FPGA's internal BRAM to achieve ordered storage of single feature codes, specifically including:

[0065] Based on the combination type group_type (obtained by querying the comb_id-group_type mapping table in the FPGA's internal URAM through comb_id in step S102, such as group_type=2 representing level 2 combination and group_type=4 representing level 4 combination), the BRAM is divided into corresponding combination type partitions, such as "level 1 combination partition", "level 2 combination partition" and "level 4 combination partition". Each partition independently stores the sub-feature code data of the corresponding level to avoid confusion between data of different levels;

[0066] Within each combination type partition, sub-buffer areas are further divided according to the combination identifier sequence number group_index (which identifies the level of a single feature code in the combination rule, such as group_index=1 corresponding to a level 1 sub-feature code and group_index=2 corresponding to a level 2 sub-feature code). For example, within a level 2 combination partition, sub-buffer areas are divided into group_index=1 and group_index=2.

[0067] The single-feature code data (including feature_id, matching status, etc.) of ordinary rules is written to the corresponding cache partition and sub-area in parallel through multiple ports of FPGA by using the dual-key tags of group_type and group_index. Each data block is appended with a write completion flag (1 bit, 1 = write complete) to facilitate subsequent verification of the data ready status.

[0068] Next, the message is verified to ensure it meets the level requirements of the combination rules, avoiding invalid matches caused by missing factor feature codes. For example, this includes:

[0069] Read the group_type value of the current ordinary rule from the comb_id-group_type mapping table (e.g., group_type=4) and generate verification conditions, such as including all independent sub-signatures of group_index=1~4, where "independent" means that the sub-signatures corresponding to each group_index come from different protocol fields of the packet (e.g., group_index=1 corresponds to the IP field, group_index=2 corresponds to the port field), and there are no duplicates;

[0070] Real-time monitoring of the write completion flags of all group_index sub-regions under the corresponding combination type partition. If all sub-region flags are 1 (e.g., when group_type=4, sub-regions group_index=1~4 have all completed writing), it is determined that the message contains the sub-feature code corresponding to all independent group_index, and parallel matching is initiated; if any sub-region flag is 0, the determination level is incomplete, the current combination rule matching is terminated, and cached data is cleared.

[0071] Next, synchronous matching of all sub-feature codes at all levels is achieved through parallel comparison to ensure line-speed processing. For example, this specifically includes:

[0072] For each group_type, a parallel comparator corresponding to the level is built inside the FPGA (e.g., four 32-bit parallel comparators are built when group_type=4). The input of each comparator is the sub-feature code data in the buffer on one end and the target sub-feature code list (the target feature codes of each level under the preset combination rule) stored in the URAM on the other end.

[0073] Once the level verification is successful, all parallel comparators start the comparison simultaneously, completing the matching verification of all sub-feature codes within a single FPGA clock cycle (e.g., simultaneously comparing sub-feature codes of group_index=1~4 with the target value); if all comparators output a successful matching signal (high level), the ordinary rule level matching is determined to be successful; if any comparator outputs a failure, the matching is determined to be unsuccessful.

[0074] After a successful match, the corresponding group_id is read from the comb_id-group_id mapping table in the FPGA's internal URAM (key is comb_id, value is the multi-feature code matching identifier group_id) and used as the index for subsequent anchor point association.

[0075] In one embodiment, for ordinary rules that successfully match hierarchically, anchor point verification is performed using group_id, and user rule information is output to solve the problem of linkage matching between ordinary rules and anchor point rules. For example, the specific implementation is as follows:

[0076] First, the pre-defined multi-level combination anchor point matching table is queried, and the location is based on the index of group_id. This table is built on the FPGA's internal URAM (high capacity to adapt to a large number of combination rules). The table key is group_id, and the stored content is divided into two categories: anchor point matching conditions and user rule information. Specifically:

[0077] Anchor matching conditions: include the anchor type to be matched (e.g., 0x01 = IP layer anchor), the number of anchors (e.g., 2), and the anchor combination logic (e.g., "AND" logic, which must include all specified anchors at the same time).

[0078] User rule information: includes user rule identifier usr_policy_id (16-bit unique identifier) ​​and user identifier usr_en (1 bit, 1 = enabled, 0 = disabled);

[0079] Using the group_id output from the aforementioned steps as the URAM physical address index, the corresponding table entry is read within one clock cycle to extract the anchor point matching conditions and user rule information (temporarily stored and output after the anchor point verification is successful).

[0080] Next, the anchor identifier anchor_id (binary) of the message is converted into a one-hot code that is easier for the FPGA to compare in parallel, thereby improving the matching efficiency. For example, anchor_id=001 (corresponding to IP anchor) is converted into an 8-bit one-hot code "00000001", and anchor_id=003 is converted into "00000100".

[0081] Each bit of the one-hot code corresponds to a unique anchor_id. When comparing, only simple logic such as "AND gate" and "OR gate" is needed. The latency is much lower than that of comparing binary code values, which is suitable for line speed requirements.

[0082] In one embodiment, if a message contains multiple anchor information (such as matching anchor_id=001 and 003 simultaneously), they need to be merged before matching. Specifically, when the number of anchor information in the message is ≥2, the merging operation is triggered. Through a multi-input OR gate array, parallel OR operations are performed on the one-hot codes of multiple anchors (such as "00000001|00000100=00000101"). The merging result is temporarily stored in the BRAM "Merged Anchor Buffer Area" to ensure that all anchor information is not missed.

[0083] Finally, extract the anchor matching conditions from the multi-level combined anchor matching table and generate the anchor one-hot code template (e.g., if the condition is to contain anchor_id=001 and 003, the template is "00000101"); input the merged anchor one-hot code and the template into an AND gate, and if the operation result is equal to the template (e.g., "00000101&00000101=00000101"), the anchor matching is considered successful;

[0084] After a successful match, the temporarily stored usr_policy_id and usr_en are packaged in the AXI4-Stream protocol format and a matching success flag (1 bit) is attached.

[0085] Step S105: For anchor rules, perform pure anchor feature code matching based on anchor type (anchor_type) and anchor identifier (anchor_id). Anchor type (anchor_type) is used to identify the multi-feature code combination scenario corresponding to the anchor rule, and anchor identifier (anchor_id) is a unique identifier assigned to each anchor rule.

[0086] Optionally, such as Figure 4 As shown in the diagram, for the anchor rule matching process, step S401 involves querying the preset pure anchor matching table using the anchor identifier `anchor_id`; step S402 involves performing a one-hot code conversion on the anchor identifier `anchor_id` of the message; step S403 involves merging multiple anchor information entries if the message contains multiple anchor information entries; step S404 involves comparing the processed anchor information with the anchor information in the pure anchor matching table, and outputting the user rule identifier `usr_policy_id`, user identifier `usr_en`, and action identifier `action_id` after a successful match; the pure anchor matching table is constructed based on the FPGA's internal URAM, with the table key being `anchor_id`, and storing anchor matching conditions and user rule information. The anchor matching conditions include the number of anchors to be matched, anchor combination logic, and anchor type consistency requirements, while the user rule information includes `usr_policy_id`, `usr_en`, and `action_id`.

[0087] In some embodiments, performing pure anchor feature code matching based on anchor type (anchor_type) and anchor identifier (anchor_id) is a core process that runs in parallel with ordinary rule matching. For single feature codes determined to be anchor rules, independent matching can be achieved without associating them with ordinary combination rules.

[0088] First, anchor matching conditions and user rule information templates are obtained from the pre-set pure anchor matching table inside the FPGA using the anchor_id identifier. This table is built based on the FPGA's internal URAM and utilizes the high capacity (supporting storage of millions of entries) and low latency (single-cycle random access) characteristics of URAM to adapt to the storage needs of a large number of pure anchor rules in the current network, avoiding the performance loss caused by relying on external DDR4.

[0089] Specifically, the key of the table entry is the anchor_id (a 16-bit binary unique identifier, representing the matching attribute information field in the original single-feature code output in step S102, such as anchor_id=0x10 corresponding to the IP anchor "192.168."). The value is divided into two categories: "anchor matching conditions" and "user rule information," with the specific field definitions as follows:

[0090] Anchor matching conditions include the number of anchors to be matched (e.g., 1 or 2), anchor combination logic (e.g., "OR" logic: satisfying any anchor is sufficient, "AND" logic: satisfying all anchors), and anchor type consistency requirements (e.g., only IP layer anchor combinations are allowed to avoid cross-layer anchor confusion).

[0091] User rule information includes user rule identifier usr_policy_id (16-bit unique identifier to distinguish different business rules), user identifier usr_en (1 bit, 1 = user enabled, 0 = user disabled), and action identifier action_id (4 bits, defining specific business operations, such as 0x01 = traffic splitting, 0x02 = packet filtering).

[0092] Next, the original information of the single feature code temporarily stored in the BRAM anchor rule cache area contains the anchor type anchor_type and the anchor identifier anchor_id. The anchor_id is extracted, and the consistency requirement between anchor_type and anchor type in the matching table is verified (e.g., anchor_type=0x01=IP layer anchor, only query the IP layer pure anchor matching table partition).

[0093] Using anchor_id as the URAM physical address index, the pure anchor matching table entry is read within one FPGA clock cycle. The anchor matching conditions and user rule information are temporarily stored. If the query result is empty (no corresponding anchor_id table entry), the pure anchor matching preprocessing is determined to have failed, the current process is terminated, and the cached data is cleared.

[0094] In one embodiment, for scenarios where a message may carry multiple anchor information, the matching efficiency is improved by one-hot code conversion, and the verification integrity is ensured by information merging. The specific merging process is the same as step S104 above, and will not be described again in this embodiment.

[0095] Finally, the anchor information is verified to meet the matching conditions through parallel comparison, and the valid user rules are finally output. The specific implementation is as follows:

[0096] Extract the anchor point matching condition fields from the query results of the pure anchor point matching table, and generate a validation template, for example:

[0097] Number of anchor points = 2, combinational logic = "AND", anchor point type consistency requirement = IP layer → the verification template is "must contain 2 IP layer anchor points, and the merged one-hot code must contain the corresponding two anchor point identifier bits"; convert the verification template to an anchor point one-hot code template with the same number of bits as the merged one-hot code (such as the template corresponding to the above conditions = 00000101) to facilitate parallel comparison.

[0098] Construct a "single-input AND gate" (for single anchor point scenarios) or a "multi-input AND gate array" (for multi-anchor point scenarios) inside the FPGA. One input is the "merged anchor point one-hot code" (or a single anchor_id one-hot code), and the other input is the "anchor point one-hot code template".

[0099] Single anchor point scenario (anchor point quantity = 1): If the bitwise AND operation between the one-hot code and the template equals the template (e.g., one-hot code = 00000001, template = 00000001 → result = 00000001), it is determined that "anchor point matching is successful";

[0100] In multi-anchor scenarios (anchor number = 2, logic = "AND"): If the bitwise AND operation result of the merged one-hot code and the template equals the template (e.g., merged one-hot code = 00000101, template = 00000101 → result = 00000101), it is determined that "anchor matching is successful"; if the result is not equal to the template (e.g., merged one-hot code = 00000001, template = 00000101 → result = 00000001), it is determined that "matching fails";

[0101] Only when the anchor point matches successfully and the user identifier usr_en=1 (user enabled) is the user rule information (usr_policy_id, usr_en, action_id) extracted from the pure anchor point matching table. For example, according to the FPGA's internal standardized hardware protocol (such as the AXI4-Stream protocol), the user rule information, anchor identifier anchor_id, and message ID are packaged into a data frame, and a pure anchor point matching success flag (1 bit, 1 = success) is added to the frame header.

[0102] Optionally, in some embodiments, based on the user-enabled usr_en and the user rule identifier usr_policy_id, the rule priority is compared for each independent user, the rule with the highest priority is selected, and the final matching information is output.

[0103] Specifically, based on the user enable usr_en and the user rule identifier usr_policy_id, the rules are compared according to the priority of each independent user, and the final matching information is output. This resolves the conflict between the matching results of ordinary rules and anchor rules under the same independent user, filters out the unique highest priority rule, and outputs standardized business information, providing a basis for the actual business execution of the network splitter.

[0104] For example, the rule results output from the preceding processes (ordinary rule matching and pure anchor point matching) are first filtered for validity, and then cached according to the independent user dimension. The specific implementation is as follows:

[0105] It receives two types of rule result data: one is the user enable usr_en and user rule identifier usr_policy_id output by ordinary rule matching, and the other is the usr_en, usr_policy_id and action identifier action_id output by pure anchor matching. Both types of data carry an independent user identifier usr_id (used to distinguish rules from different users).

[0106] For each rule result, the user enable field usr_en (a 1-bit binary identifier, 1 indicates user enable, 0 indicates user disable) is extracted. If usr_en=0, it is directly determined as an invalid rule and the result is discarded; if usr_en=1, it is determined as a valid rule and the complete field information (including usr_id, usr_policy_id, action_id) is retained to avoid invalid rules occupying subsequent computing resources.

[0107] Independent user cache partitions are constructed based on the FPGA's internal BRAM (low latency, multi-port parallel access characteristics). Each partition uses "independent user identifier usr_id" as a unique index and stores only the valid rule results of the corresponding user.

[0108] Next, for multiple valid rules within a single user cache partition, prioritizing rules with smaller usr_policy_id values, a parallel comparator array on an FPGA is used to sort the rules by priority, selecting the unique highest-priority rule. The specific implementation is as follows:

[0109] The system monitors the data readiness flags of each user's cache partition in real time. When a partition is marked as 1 (meaning there are valid rules), the rule priority comparison process for that user is triggered. If there is only one valid rule in the partition, the rule is directly determined to be the highest priority, and subsequent comparison steps are skipped. If there are two or more valid rules, the parallel comparison logic is started.

[0110] For N valid rules within the cache partition, a tree-structured parallel comparator array is constructed inside the FPGA. For example, three rules correspond to two levels of comparators. The first level sets up two parallel comparators to compare the usr_policy_id of "rule 1 and rule 2" and the usr_policy_id of "rule 2 and rule 3", respectively, and output the two smaller usr_policy_ids. The second level sets up one comparator to compare the two smaller values ​​output by the first level again, and finally obtains the smallest usr_policy_id.

[0111] The rule follows the principle that rules with smaller usr_policy_id values ​​have higher priority. For example, if a user has 3 valid rules with usr_policy_id values ​​of 05, 03, and 07 respectively, after parallel comparison, the rule with the smallest usr_policy_id = 03 is the highest priority rule for that user. After determining the highest priority rule, the complete information of the rule (usr_en, usr_policy_id, action_id) is recorded.

[0112] Figure 5 A multi-feature code matching device 500 is shown. This device embodiment is similar to... Figure 1 Corresponding to the illustrated method embodiments, this device can be specifically applied to various electronic devices. Specifically, it includes:

[0113] The preprocessing module 501 is used to preprocess the received messages to obtain valid messages;

[0114] The single-feature code matching module 502 is used to perform single-feature code matching on the valid message based on the message single-feature code line-speed matching algorithm, and to construct the original information of the single-feature code for the successfully matched string; the original information includes identification information, matching attribute information, user association information, and matching status information, wherein the identification information includes feature code ID, combination identifier comb_id, and combination identifier sequence number group_index, and the matching attribute information includes anchor flag bit anchor_flag, anchor type anchor_type, and anchor identifier anchor_id;

[0115] The rule type determination module 503 is used to determine the rule type based on the anchor flag bit anchor_flag. The rule type includes ordinary rules or anchor rules. Ordinary rules are rules where a single feature code belongs to only one specific multi-feature code combination rule and has no common reuse attributes. Anchor rules are rules where a single feature code belongs to the common sub-item of multiple multi-feature code combination rules.

[0116] The ordinary rule matching module 504 is used to query the preset combination type group_type and combination identifier sequence number group_index by using the combination identifier comb_id for ordinary rules, and perform hierarchical multi-feature code matching based on the combination type and the combination identifier sequence number. The combination type is used to identify the number of multi-feature code combination levels corresponding to the ordinary rule, and the combination identifier sequence number is used to identify the level of a single feature code in the combination rule.

[0117] The anchor rule matching module 505 performs pure anchor feature code matching based on the anchor type (anchor_type) and anchor identifier (anchor_id) for anchor rules. The anchor type (anchor_type) is used to identify the multi-feature code combination scenario corresponding to the anchor rule, and the anchor identifier (anchor_id) is a unique identifier assigned to each anchor rule.

[0118] Based on the same inventive concept, this application also provides an electronic device. The method corresponding to the electronic device can be the method in the foregoing embodiments, and its problem-solving principle is similar to that method. The electronic device provided in this application includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the methods and / or technical solutions of the foregoing embodiments of this application.

[0119] Figure 6The diagram illustrates the structure of an apparatus suitable for implementing the methods and / or technical solutions in the embodiments of this application. The apparatus 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes based on a program stored in a read-only memory (ROM) 602 or a program loaded from a storage portion 608 into a random access memory (RAM) 603. The RAM 603 also stores various programs and data required for system operation. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0120] The following components are connected to I / O interface 605: an input section 606 including a keyboard, mouse, touchscreen, microphone, infrared sensor, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), LED display, OLED display, etc., and speakers, etc.; a storage section 608 including one or more computer-readable media such as hard disk, optical disk, magnetic disk, semiconductor memory, etc.; and a communication section 609 including a network interface card such as a LAN (local area network) card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet.

[0121] In particular, the methods and / or embodiments in this application can be implemented as computer software programs. For example, the embodiments disclosed in 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 flowchart. When the computer program is executed by the central processing unit (CPU) 601, it performs the functions defined in the methods of this application.

[0122] Another embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of this application described above.

[0123] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0124] Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device through software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any specific order.

Claims

1. A multi-feature code matching method, characterized by, The method comprises the following steps: Step S101, preprocessing the received message to obtain an effective message; Step S102, performing single-feature-code matching on the effective message based on a message single-feature-code line-speed matching algorithm, and constructing single-feature-code original information for a matched string; the original information comprises identification information, matching attribute information, user association information, and matching state information, wherein the identification information comprises a feature code ID, a combination identification comb_id, and a combination identification sequence number group_index, the matching attribute information comprises an anchor point marker bit anchor_flag, an anchor point type anchor_type, and an anchor point identification anchor_id; Step S103, determining a rule type based on the anchor point marker bit anchor_flag, wherein the rule type comprises a normal rule or an anchor point rule; the normal rule is that a single-feature-code only belongs to a specific multi-feature-code combination rule, and has no common multiplexing attribute; the anchor point rule is that a single-feature-code belongs to a common sub-item of multiple multi-feature-code combination rules; Step S104, for the normal rule, querying a preset combination type group_type and combination identification sequence number group_index through the combination identification comb_id, and performing hierarchical multi-feature-code matching based on the combination type and the combination identification sequence number; the combination type is used to identify the multi-feature-code combination level corresponding to the normal rule, and the combination identification sequence number is used to identify the level of the single-feature-code in the combination rule; Step S105, for the anchor point rule, performing pure anchor point feature code matching based on the anchor point type anchor_type and the anchor point identification anchor_id; the anchor point type anchor_type is used to identify the multi-feature-code combination scenario corresponding to the anchor point rule, and the anchor point identification anchor_id is a unique identification allocated for each anchor point rule; The single-feature-code matching on the effective message based on the message single-feature-code line-speed matching algorithm comprises the following steps: Step S201, first filtering message segments without matching possibilities through a Bloom algorithm; Step S202, then constructing a prefix dictionary tree through an FDR algorithm to realize fast search of a variable-length prefix, and positioning a prefix segment containing a target feature code in the message; Step S203, based on the matched prefix segment, extracting a complete string in the message starting from the prefix segment, specifically, performing bit-width alignment and parallel comparison of the complete string with a target complete feature code stored in an FPGA internal cache through a parallel comparator in the FPGA. The hierarchical multi-feature code matching based on the combination type group_type and the combination identification sequence number group_index includes the following steps: S301, classifying and caching single-feature codes based on the combination type group_type and the combination identification sequence number group_index, specifically, dividing the cache combination type partitions based on the combination level, each partition independently storing the sub-feature code data of the corresponding level, and further dividing the sub-cache area according to the hierarchical sequence number of the sub-feature code in each combination type partition; S302, verifying whether the message contains all the sub-feature codes corresponding to the independent combination identification sequence number group_index based on the level determined by the combination type group_type; if yes, synchronously and in parallel verifying and matching all the hierarchical sub-feature codes for each combination type group_type; and S303, outputting the multi-feature code matching identifier group_id after the matching is successful. The pure anchor point feature code matching based on the anchor point type anchor_type and the anchor point identifier anchor_id includes the following steps: S401, querying the preset pure anchor point matching table through the anchor point identifier anchor_id; S402, performing one-hot code conversion on the anchor point identifier anchor_id of the message; S403, if the message contains multiple anchor point information, performing a merging operation first; S404, comparing and matching the processed anchor point information with the anchor point information in the pure anchor point matching table, and outputting the user rule identifier usr_policy_id, the user identifier usr_en and the action identifier action_id after the matching is successful; the pure anchor point matching table is constructed based on the FPGA internal URAM, the table entry Key is anchor_id, and the storage content includes the anchor point matching condition and the user rule information, the anchor point matching condition includes the number of anchor points to be matched, the anchor point combination logic and the anchor point type consistency requirement, and the user rule information includes the user rule identifier usr_policy_id, the user identifier usr_en and the action identifier action_id.

2. The method of claim 1, wherein, The hierarchical multi-feature code matching based on the combination type group_type and the combination identification sequence number group_index includes the following steps: S301, classifying and caching single-feature codes based on the combination type group_type and the combination identification sequence number group_index, specifically, dividing the cache combination type partitions based on the combination level, each partition independently storing the sub-feature code data of the corresponding level, and further dividing the sub-cache area according to the hierarchical sequence number of the sub-feature code in each combination type partition; S302, verifying whether the message contains all the sub-feature codes corresponding to the independent combination identification sequence number group_index based on the level determined by the combination type group_type; if yes, synchronously and in parallel verifying and matching all the hierarchical sub-feature codes for each combination type group_type; and S303, outputting the multi-feature code matching identifier group_id after the matching is successful. S304, querying the preset multi-level combination anchor point matching table through the multi-feature code matching identifier group_id; S305, performing one-hot code conversion on the anchor point identifier anchor_id of the message; S306, if the message contains multiple anchor point information, performing a merging operation first; S307, comparing and matching the processed anchor point information with the anchor point information in the multi-level combination anchor point matching table, and outputting the user rule identifier usr_policy_id and the user identifier usr_en after the matching is successful. ​ ​ ​ The preset multi-level combination anchor point matching table is constructed based on a URAM inside the FPGA, a table entry Key is group_id, and storage content includes anchor point matching conditions and user rule information, the anchor point matching conditions include anchor point types to be matched, anchor point quantity, and anchor point combination logic, and the user rule information includes a user rule identifier usr_policy_id and a user identifier usr_en.

3. The multi-feature code matching method of claim 1, wherein, based on the user identifier usr_en and the user rule identifier usr_policy_id, performing rule priority comparison for independent users, selecting a rule with the highest priority, and outputting final matching information.

4. A multi-feature code matching apparatus, characterized by comprising: The method comprises: a preprocessing module configured to preprocess a received message to obtain a valid message; a single-feature code matching module configured to perform single-feature code matching on the valid message based on a message single-feature code line-speed matching algorithm, and to construct single-feature code original information for a successfully matched string; the original information includes identifier information, matching attribute information, user association information, and matching state information, wherein the identifier information includes a feature code ID, a combination identifier comb_id, and a combination identifier sequence number group_index, and the matching attribute information includes an anchor point flag anchor_flag, an anchor point type anchor_type, and an anchor point identifier anchor_id; a rule type determination module configured to determine a rule type based on the anchor point flag anchor_flag; the rule type includes a normal rule or an anchor point rule, wherein the normal rule is a single-feature code that only belongs to a specific multi-feature code combination rule and has no public multiplexing attribute, and the anchor point rule is a single-feature code that belongs to a public subentry of multiple multi-feature code combination rules; a normal rule matching module configured to, for the normal rule, query a preset combination type group_type and a combination identifier sequence number group_index through the combination identifier comb_id, and perform hierarchical multi-feature code matching based on the combination type and the combination identifier sequence number; the combination type is used to identify a multi-feature code combination level corresponding to the normal rule, and the combination identifier sequence number is used to identify a level of the single-feature code in the combination rule; an anchor point rule matching module configured to, for the anchor point rule, perform pure anchor point feature code matching based on the anchor point type anchor_type and the anchor point identifier anchor_id; the anchor point type anchor_type is used to identify a multi-feature code combination scenario corresponding to the anchor point rule, and the anchor point identifier anchor_id is a unique identifier allocated for each anchor point rule. The single-feature-code matching of the effective packet based on the packet single-feature-code line-speed matching algorithm includes: first filtering the packet fragments without matching possibility through the Bloom algorithm; then constructing a prefix dictionary tree through the FDR algorithm to realize the fast search of variable-length prefixes, and positioning the prefix fragments containing the target feature code in the packet; based on the matched prefix fragments, extracting the complete string in the packet starting from the prefix fragments, specifically, performing bit-width alignment and parallel comparison between the parallel comparators in the FPGA and the target complete feature codes stored in the FPGA internal cache. The hierarchical multi-feature-code matching based on the combination type group_type and the combination identification sequence number group_index includes: classifying and caching the single-feature-codes based on the combination type group_type and the combination identification sequence number group_index, specifically, dividing the combination type partitions based on the combination order, and each partition independently stores the sub-feature-code data of the corresponding order, and in each combination type partition, the sub-cache area is further divided according to the hierarchical sequence number of the sub-feature-codes; based on the order determined by the combination type group_type, verifying whether the packet contains all sub-feature-codes corresponding to the independent combination identification sequence number group_index; if yes, for each combination type group_type, all hierarchical sub-feature-codes are synchronously and in parallel verified and matched; and outputting the multi-feature-code matching identification group_id after the matching is successful. The pure anchor point feature code matching based on the anchor point type anchor_type and the anchor point identification anchor_id includes: querying the preset pure anchor point matching table through the anchor point identification anchor_id; performing one-hot code conversion on the anchor point identification anchor_id of the packet; if the packet contains multiple anchor point information, performing a merging operation first; then comparing the processed anchor point information with the anchor point information in the pure anchor point matching table, and outputting the user rule identification usr_policy_id, the user identification usr_en and the action identification action_id after the matching is successful; the pure anchor point matching table is constructed based on the URAM in the FPGA, the table item Key is anchor_id, and the storage content includes anchor point matching conditions and user rule information, the anchor point matching conditions include the number of anchor points to be matched, anchor point combination logic and anchor point type consistency requirements, and the user rule information includes the user rule identification usr_policy_id, the user identification usr_en and the action identification action_id.

5. An electronic device, the electronic device comprising: It comprises: at least one processor; and a memory connected in communication with the processor; wherein the memory stores instructions executable by the processor, and the instructions are executed by the processor to enable the processor to execute the method of any one of claims 1-3.

6. A computer readable medium having stored thereon computer program instructions, characterized in that, The computer program instructions can be executed by the processor to implement the method of any one of claims 1-3.

7. A computer program product comprising a computer program, characterized in that, The computer program, which when executed by the processor, implements the method of any one of claims 1-3.

Images