Data processing method and device, electronic equipment, storage medium and program product

Abstract

The application provides a data processing method and device, electronic equipment, a storage medium and a program product. The method comprises the following steps: receiving a data packet request, wherein the data packet request comprises a to-be-processed packet, a source address, a destination address, a destination port and network attribute information, and the data packet request is used for requesting access to a target service resource; in a first flow table corresponding to the target service resource, the destination address, the destination port and the network attribute information are matched, and a first parameter is determined, wherein the first parameter is used for indicating a processing flow direction of the to-be-processed packet; according to the first parameter, a target packet processing mode is determined, wherein the target packet processing mode is used for forwarding the to-be-processed packet to a common flow table for processing, and the common flow table is used for managing access rules of each data packet; and according to the target packet processing mode, the to-be-processed packet is processed, thereby improving the reliability of data processing.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data processing method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] With the rapid development of cloud computing and software-defined network (SDN) technologies, the scale and access control complexity of various resources in cloud platforms (such as elastic load balancers) have increased significantly, making efficient filtering and policy management of data traffic increasingly important.

[0003] In related technologies, the SDN controller issues relevant flow tables and rules to the forwarder based on the OpenFlow protocol. Specifically, the SDN controller usually issues flow tables independently for each type of cloud resource and adds high-priority flow table entries to the service flow table of each type of cloud resource to intercept traffic accessing the resource and perform access control.

[0004] However, in the above scheme, the flow table rules for the same address group need to be repeatedly configured and distributed to each type of cloud resource, which causes the number of flow tables to grow exponentially redundantly. Furthermore, when modifying the flow table, the flow table rules in each business table need to be modified one by one, resulting in poor flow table matching efficiency and low data processing reliability. Summary of the Invention

[0005] This application provides a data processing method, apparatus, electronic device, storage medium, and program product to solve the technical problem of low reliability in data processing.

[0006] Firstly, this application provides a data processing method, including:

[0007] Receive data packet requests. Data packet requests include the packet to be processed, source address, destination address, destination port, and network attribute information. Data packet requests are used to request access to target service resources.

[0008] In the first flow table corresponding to the target service resource, the destination address, destination port and network attribute information are matched, and the first parameter is determined. The first parameter is used to indicate the processing flow of the packet to be processed.

[0009] Based on the first parameter, the target packet processing method is determined. The target packet processing method is used to forward the packet to be processed to the shared flow table for processing. The shared flow table is used to manage the access rules of each data packet.

[0010] Process the message to be processed according to the target message processing method.

[0011] In this embodiment, by receiving a packet request containing the packet to be processed, source address, destination address, destination port, and network attribute information, the destination address, destination port, and network attribute information are matched in the first flow table corresponding to the target service resource to determine a first parameter. The target packet processing method is determined based on the first parameter, and the packet to be processed is forwarded to a shared flow table for processing. In this method, the electronic device can indicate the packet processing flow direction through the first parameter, achieving unified packet processing for various service resources based on the shared flow table. This effectively avoids the flow table redundancy problem caused by independent configuration of flow tables for each service resource in the prior art, reducing the exponential growth in the number of flow tables. Different service resources share the same set of shared flow tables for access control processing, eliminating the need for separate maintenance of flow tables for each service resource, significantly reducing maintenance difficulty and management costs. Furthermore, by centrally processing packets through the shared flow table, the packet matching path is shortened, flow table matching efficiency and network forwarding performance are improved, adapting to the access control requirements of various target service resources without requiring additional hardware resources, reducing deployment costs, ensuring the standardization and accuracy of packet processing, and improving the reliability of data processing.

[0012] Optionally, determining the first parameter using the method described above includes:

[0013] Obtain the configuration information of the target business resource, including access identifier, resource type, and address group identifier;

[0014] Write the access identifier to the first field of the register, the resource type to the second field of the register, and the address group identifier to the third field of the register.

[0015] The first parameter is generated based on the written values ​​of the first, second, and third fields.

[0016] In this embodiment, the configuration logic of the first parameter is standardized by encoding the access identifier, resource type and address group identifier into the register by bit field, which ensures that the parameter accurately and reliably indicates the direction of message processing and improves the standardization and accuracy of parameter configuration.

[0017] Optionally, the method described above, based on the first parameter, determines the target message processing method, including:

[0018] Retrieve the historical cache record corresponding to the register. The historical cache record is used to store the processing process of each data packet based on the shared flow table within a historical period.

[0019] Determine whether there is a cache record in the historical cache that corresponds to the first parameter, destination address, destination port, and network attribute information;

[0020] When it is determined that a corresponding cache record exists, the target message processing method is determined based on the corresponding processing procedure in the cache record;

[0021] When it is determined that no corresponding cached record exists, the message to be processed is sent to the second flow table, and the processing method of the target message is determined through the second flow table. The second flow table is used to match the address information of the message to be processed.

[0022] In this embodiment, by querying the historical cache records in the register and prioritizing the reuse of cache results, the matching frequency of the second flow table is reduced, the repeated processing process is avoided, the packet processing efficiency is effectively improved, and the computational resource consumption of the forwarding device is reduced.

[0023] Optionally, as described above, the target message processing method is determined through the second flow table, including:

[0024] In the second flow table, the first parameter is masked to obtain the address group identifier, and the corresponding address range is determined based on the address group identifier;

[0025] The source address and address range of the message to be processed are matched using a mask to obtain the matching result;

[0026] When the matching result indicates that the source address is not within the address range, the target packet processing method is determined to be to discard the pending packet based on the access identifier of the first parameter, and when the access identifier of the first parameter is an allowed access identifier. The allowed access identifier is used to indicate that the pending packet is allowed to access the target service resource.

[0027] If the matching result indicates that the source address is not within the address range and the access identifier of the first parameter is a restricted access identifier, then the target message method is determined to be to send the message to be processed back to the first flow table. The restricted access identifier is used to indicate that the message to be processed is restricted from accessing the target service resources.

[0028] When the matching result indicates that the source address is within the address range, the message to be processed is sent to the third flow table, and the processing method of the target message is determined through the third flow table. The third flow table is used to perform access verification on the message to be processed.

[0029] In this embodiment, by performing mask matching on the first parameter to extract the address group identifier and determine the corresponding address range, and then performing mask matching on the source address and the address range, and performing discard or return processing based on the two matching results and the access identifier, accurate address group filtering and access control decisions are achieved. This enables multiple service resources to share the same set of address group matching rules, avoids redundant configuration of each service flow table, and significantly reduces the number of flow tables.

[0030] Optionally, the method described above, using a third flow table, determines the target message processing method, including:

[0031] In the third flow table, the first parameter is masked and matched. When the access identifier is an allowed access identifier, the target message processing method is determined to allow the message to be processed to pass and is returned to the first flow table.

[0032] When the access identifier is a restricted access identifier, the target message processing method is determined to be to discard the pending message.

[0033] In this embodiment, the access is allowed or rejected based on the access identifier by using a third flow table, which clarifies the specific logic of access verification, accurately implements blacklist and whitelist control, and ensures the security and reliability of access to target business resources.

[0034] Optionally, after receiving the data packet request, the method described above further includes:

[0035] Get the current value of the register;

[0036] When the current value of the register is the preset initial value, perform the matching operation on the destination address, destination port, and network attribute information;

[0037] When the current value of the register differs from the preset initial value, the message to be processed is processed through the first flow table.

[0038] In this embodiment, by detecting whether the current value of the register is a preset initial value, the matching operation of the intercept flow table is skipped when it is not the initial value, and the packet is directly processed by the first flow table. This effectively avoids the loop problem caused by repeated matching of the intercept flow table, and ensures the continuity of packet processing and the stability of network operation.

[0039] Secondly, this application provides a data processing apparatus, comprising:

[0040] The receiving module is used to receive data packet requests. The data packet request includes the packet to be processed, source address, destination address, destination port, and network attribute information. The data packet request is used to request access to the target service resource.

[0041] The matching module is used to match the destination address, destination port and network attribute information in the first flow table corresponding to the target service resource, and determine the first parameter, which is used to indicate the processing flow of the packet to be processed;

[0042] The determination module is used to determine the target packet processing method based on the first parameter. The target packet processing method is used to forward the packet to be processed to the shared flow table for processing. The shared flow table is used to manage the access rules of each data packet.

[0043] The processing module is used to process the packets to be processed according to the target packet processing method.

[0044] Optionally, in the apparatus described above, determining the first parameter, the matching module is specifically used for:

[0045] Obtain the configuration information of the target business resource, including access identifier, resource type, and address group identifier;

[0046] Write the access identifier to the first field of the register, the resource type to the second field of the register, and the address group identifier to the third field of the register.

[0047] The first parameter is generated based on the written values ​​of the first, second, and third fields.

[0048] Optionally, in the apparatus described above, the target message processing method is determined based on the first parameter, and the determining module is specifically used for:

[0049] Retrieve the historical cache record corresponding to the register. The historical cache record is used to store the processing process of each data packet based on the shared flow table within a historical period.

[0050] Determine whether there is a cache record in the historical cache that corresponds to the first parameter, destination address, destination port, and network attribute information;

[0051] When it is determined that a corresponding cache record exists, the target message processing method is determined based on the corresponding processing procedure in the cache record;

[0052] When it is determined that no corresponding cached record exists, the message to be processed is sent to the second flow table, and the processing method of the target message is determined through the second flow table. The second flow table is used to match the address information of the message to be processed.

[0053] Optionally, the apparatus described above determines the target message processing method through the second flow table, and determines the specific function of the module:

[0054] In the second flow table, the first parameter is masked to obtain the address group identifier, and the corresponding address range is determined based on the address group identifier;

[0055] The source address and address range of the message to be processed are matched using a mask to obtain the matching result;

[0056] When the matching result indicates that the source address is not within the address range, and the access identifier of the first parameter is the allowed access identifier, the target packet processing method is determined to be to discard the pending packet. The allowed access identifier is used to indicate that the pending packet is allowed to access the target service resource.

[0057] If the matching result indicates that the source address is not within the address range and the access identifier of the first parameter is a restricted access identifier, then the target message method is determined to be to send the message to be processed back to the first flow table. The restricted access identifier is used to indicate that the message to be processed is restricted from accessing the target service resources.

[0058] When the matching result indicates that the source address is within the address range, the message to be processed is sent to the third flow table, and the processing method of the target message is determined through the third flow table. The third flow table is used to perform access verification on the message to be processed.

[0059] Optionally, the apparatus described above determines the target message processing method and the module is specifically used for: (The third flow table is used to determine the specific function of the module.)

[0060] In the third flow table, the first parameter is masked and matched. When the access identifier is an allowed access identifier, the target message processing method is determined to allow the message to be processed to pass and is returned to the first flow table.

[0061] When the access identifier is a restricted access identifier, the target message processing method is determined to be to discard the pending message.

[0062] Optionally, in the apparatus described above, after receiving a data packet request, the apparatus further includes a determination module, which is specifically used for:

[0063] Get the current value of the register;

[0064] When the current value of the register is the preset initial value, perform the matching operation on the destination address, destination port, and network attribute information;

[0065] When the current value of the register differs from the preset initial value, the message to be processed is processed through the first flow table.

[0066] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0067] The memory stores the instructions that the computer executes;

[0068] The processor executes computer-executable instructions stored in memory to implement the method described in the first aspect.

[0069] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a computer, are used to implement the method described in the first aspect.

[0070] The computer-readable storage medium provided in this application embodiment can execute the technical solutions in the above method embodiments, and its beneficial effects are similar, so they will not be described again here.

[0071] Fifthly, this application provides a computer program product, including a computer program, which, when executed by a computer, is used to implement the method of the first aspect.

[0072] The computer program product provided in this application embodiment can execute the technical solutions in the above method embodiments, and its beneficial effects are similar, so they will not be described again here.

[0073] The data processing method, apparatus, electronic device, storage medium, and program product provided in this application receive a message request containing the message to be processed, source address, destination address, destination port, and network attribute information. The method matches the destination address, destination port, and network attribute information in a first flow table corresponding to the target service resource and determines a first parameter. Based on the first parameter, the method for processing the target message is determined, and the message to be processed is forwarded to a shared flow table for processing. In this method, the electronic device can carry the access control context to the shared flow table through the first parameter, enabling various service resources to share the same set of flow tables for access control processing. This avoids the problem of duplicate rule distribution caused by each service resource having its own independently configured flow table, thereby reducing the number of flow table entries from a product relationship between resource type and policy number to a linear relationship, effectively reducing the exponential redundancy growth of the number of flow tables. Simultaneously, since access control logic is centrally processed by the shared flow table, modifying a policy only requires updating the shared flow table, without needing to modify the flow table rules in the first flow table of each service resource individually. This significantly reduces the difficulty of operation and maintenance and management costs, and avoids inconsistencies caused by missed policy changes. Furthermore, by centrally processing packets through a shared flow table, the matching path of packets in the pipeline is shortened, reducing redundant matching overhead and significantly improving flow table matching efficiency and network forwarding performance. This method is applicable to various cloud resource scenarios such as Elastic Load Balancer (ELB), Virtual Private Network, and Domain Name Resolution, without requiring additional hardware resources, thus reducing system deployment costs. It also improves data processing reliability while ensuring the standardization and accuracy of packet processing. Attached Figure Description

[0074] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0075] Figure 1 This is a schematic diagram of the system architecture provided for an embodiment of this application;

[0076] Figure 2 A flowchart illustrating a data processing method provided in an embodiment of this application;

[0077] Figure 3 A schematic diagram of the structure of a register provided in an embodiment of this application;

[0078] Figure 4 A flowchart illustrating a method for determining a target message processing mode provided in an embodiment of this application;

[0079] Figure 5 A flowchart illustrating another data processing method provided in an embodiment of this application;

[0080] Figure 6 A flowchart illustrating another data processing method provided in an embodiment of this application;

[0081] Figure 7 A flowchart illustrating another data processing method provided in an embodiment of this application;

[0082] Figure 8 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application;

[0083] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0084] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0085] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0086] As the types of service resources and access control policies in cloud networks continue to grow, the limitations of traditional methods in dealing with shared flow table rules across multiple resources are becoming increasingly apparent. Traditional solutions are characterized by: scattered flow table rules, multiplicative growth of flow table entries, and the need for traversing each entry individually for modifications. This typically leads to an exponential increase in the number of flow table entries and increased operational complexity. This places higher demands on the rapid turnover of flow table resources and data processing performance, as flow table expansion directly impacts the deployment of new services, while repetitive matching logic interferes with forwarding efficiency.

[0087] In related technologies, a high-priority flow table entry is typically added to each cloud resource's respective business flow table to intercept access traffic and perform blacklist / whitelist matching to achieve access control.

[0088] However, in the above process, when multiple resources share the same Internet Protocol (IP) address group, the same matching rules need to be repeatedly issued in each business flow table, causing the number of flow table entries to increase exponentially with the resource type and the number of policy entries. Although each resource is logically independent, since the physical storage of blacklist and whitelist rules is independent of each other, relying solely on each business table for independent maintenance will result in significant overhead and long pipeline processing time.

[0089] For example, the technical problem of traditional access control methods can be understood as the inability to achieve batch reuse of flow table rules in scenarios where multiple resources share flow table rules. For example, it is impossible to avoid the problem of repeatedly issuing the same matching rules.

[0090] In the blacklist / whitelist filtering process, matching is typically performed based on the independent priority of each business flow table. Specifically, it is necessary to traverse each business flow table one by one and repeatedly match source addresses and IP address groups.

[0091] However, traditional solutions suffer from inherent drawbacks: First, their architecture is based on storing rules independently for each resource, making it impossible for the system to serve all resources simultaneously with a single rule; second, their core operation involves repeatedly issuing matching rules on a resource-by-resource basis. Even if the same flow table rule needs to be applied to multiple resources, it still requires separate configuration for each resource, making rule-level reuse impossible. These factors make it extremely difficult to efficiently and with low overhead achieve shared access control for multiple resources, resulting in difficulties in guaranteeing both flow table matching efficiency and system performance.

[0092] In addition, the massive amount of redundant flow tables stored in a stack significantly reduces the hardware resource margin of forwarding devices and lengthens the packet matching and addressing path, inevitably leading to increased forwarding latency and decreased network throughput performance.

[0093] Therefore, this application provides a data processing method that matches the destination address, destination port, and network attribute information in the first flow table corresponding to the target service resource, determines a first parameter to indicate the processing flow direction, and carries this first parameter to a shared flow table for unified processing. Based on this first parameter, the shared flow table can perform the same address group matching and blacklist / whitelist actions on packets of all resources without having to repeatedly configure rules in each service table. By decoupling access control logic from specific service resources, centralized management of flow table rules and significant compression of flow table entries are achieved, shortening the packet matching and forwarding path and effectively avoiding the problems of repeated rule distribution and pipeline matching in traditional solutions. This method can adapt to the common need for multiple service resources to share the same access control policy in cloud networks, avoids resource exhaustion and operational complexity caused by flow table expansion, ensures the determinism and consistency of policy execution, and significantly improves flow table utilization efficiency and system processing performance.

[0094] Figure 1 For a schematic diagram of the system architecture provided in this application embodiment, please refer to [link / reference]. Figure 1 This includes electronic devices and terminal devices. Electronic devices can be any device with on-device computing capabilities, such as servers and terminal devices.

[0095] Terminal devices and electronic devices can communicate with each other. Terminal devices can send data processing requests to electronic devices. Electronic devices can process relevant data according to data processing requests, obtain processing results, and send the processing results back to terminal devices, thereby completing data processing.

[0096] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0097] Figure 2 This is a flowchart illustrating a data processing method provided in an embodiment of this application. Specifically, as shown... Figure 2 As shown, the method includes the following steps:

[0098] S201, Request to receive data packets.

[0099] The execution subject of this application embodiment can be an electronic device or a data processing device installed in the electronic device. The data processing device can be implemented by software or by a combination of software and hardware.

[0100] The data packet request includes the message to be processed, source address, destination address, destination port, and network attribute information. The data packet request is used to request access to the target service resource.

[0101] The pending messages can refer to IP service traffic generated by user interaction with cloud resources, which serves as the processing object for flow table matching, access control, and forwarding operations in the OpenFlow switch (OVS). OpenFlow is an SDN control plane protocol used for distributing flow table rules and synchronizing status information between the controller and the switch. In this embodiment, the electronic device may include an SDN controller.

[0102] The source address can refer to the IP address of the sender of the message to be processed, and is used to identify the source of the message.

[0103] The destination address can refer to the target IP address of the message to be processed, such as the IP address of a cloud resource (e.g., ELB), which can be used to locate the specific resource instance that the message wants to access.

[0104] The destination port can refer to the target port number of the message to be processed. The destination port and the destination address work together to achieve accurate identification of specific cloud resource monitoring services, narrow the matching range of the first flow table, and improve positioning accuracy.

[0105] Network attribute information is a set of parameters used to uniquely identify the network domain and transport layer protocol type to which a message belongs. Specifically, network attribute information includes virtual network identifier information and transport layer protocol type information.

[0106] The Virtual Network Identifier (VNI) is used to distinguish different Virtual Private Clouds (VPCs) or network domains. A VPC is a logically isolated private network environment allocated to users within a cloud platform, and IP addresses can overlap between different VPCs. For example, in a cloud environment scenario, since different users' VPCs may use the same IP address and port (e.g., user A's VPC1 may contain service resource A with IP address 10.0.0.10 and port 8090, while user B's VPC2 may contain service resource B with IP address 10.0.0.10 and port 8090), it is necessary to uniquely identify the VPC ID to which a packet belongs using the VLAN ID or VNI.

[0107] In some embodiments, this solution is applied to cloud platforms under the SDN architecture. In cloud platforms, the network functions of various cloud resources (e.g., ELB, etc.) are usually implemented through SDN controllers and OpenFlow switches. Therefore, when creating a VPC, users need to specify the network type. For example, if creating a Virtual Local Area Network (VLAN) type network, a VLAN number (within the range of 1-4095) needs to be specified.

[0108] If you are creating a Virtual eXtensible Local Area Network (VXLAN) type network, you need to specify a VXLAN Network Identifier (VNI) (value range 1-65535).

[0109] For example, when creating VPC1, specify VLAN type and VLAN number 100; when creating VPC2, specify VLAN number 101; and when creating VPC3, specify VXLAN type and VNI 100. After a user creates a VPC, the SDN controller assigns each VPC a monotonically increasing and non-overlapping VPC ID (e.g., starting from 1) across the entire cloud platform. Since the values ​​of VLAN ID and VNI can overlap (e.g., VLAN 100 and VNI 100 are independent), but the VPC ID assigned by the controller is unique, the corresponding VPC ID can be uniquely identified based on the VLAN ID or VNI carried in the packet.

[0110] Transport layer protocol type information is used to indicate the transport layer protocol used by the message to be processed, such as Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). This protocol type information is set when the user creates service resources, such as creating an ELB service on TCP port 8090.

[0111] Target business resources can refer to various virtualized cloud service resources deployed under the SDN architecture. In other words, they can be understood as resource instances in the cloud platform that provide specific network functions, including but not limited to elastic load balancers, virtual private networks (VPNs), etc. These resources have independent access points and business logic.

[0112] In some embodiments, when a user initiates a service access request through a virtual machine or container in a cloud platform, a message to be processed is generated. This message carries the source address, destination address, destination port, and network attribute information, and is sent to the OpenFlow Virtual Switch (OVS) on the physical node via the network protocol stack. The virtual switch, acting as a data plane forwarding device, parses and processes the received message according to pre-issued flow table rules. When the destination address, destination port, and network attribute information of a message match a target service resource (e.g., ELB), the message is identified as traffic requiring access control. The virtual switch then triggers the data processing flow of this embodiment, proceeding to subsequent steps for message matching and forwarding control.

[0113] S202. In the first flow table corresponding to the target service resource, match the destination address, destination port and network attribute information, and determine the first parameter.

[0114] The first parameter indicates the processing flow of the message to be processed.

[0115] The first flow table can refer to a service processing table allocated for a specific service resource in the virtual switch pipeline. In this embodiment, the first flow table is used to match packets destined for the service resource, and upon successful matching, performs an interception operation, redirecting the packet to a subsequent shared flow table for unified access control processing.

[0116] In some embodiments, after receiving a data packet request, the electronic device extracts the destination address, destination port, virtual network identifier, and transport layer protocol type from the packet and matches them with flow entries in a preset first flow table. The first flow table pre-configured high-priority flow entries, whose matching conditions include the IP address, port, and corresponding network attribute information (including VLAN or VNI, TCP or UDP) of the target service resource. When the packet's destination address, destination port, and network attribute information all successfully match the flow entry, it indicates that the packet requests access to the corresponding target service resource, triggering the subsequent first parameter determination process.

[0117] In some embodiments, the electronic device may determine the first parameter in the following manner: the first parameter is configured based on a register; obtain the configuration information of the target service resource, the configuration information including an access identifier, a resource type, and an address group identifier; write the access identifier into the first bit field of the register, the resource type into the second bit field of the register, and the address group identifier into the third bit field of the register; generate the first parameter based on the written values ​​of the first bit field, the second bit field, and the third bit field.

[0118] Configuration information can refer to the access control policy parameters pre-set on the target service resource, which are issued to the virtual switch by the SDN controller when the service resource is created or the policy is changed. In the embodiments of this application, the configuration information includes at least three fields: access identifier, resource type, and address group identifier, which are used to indicate what access control logic should be executed for the traffic of the service resource.

[0119] Access identifiers can refer to the access control type of the target business resource. They can be understood as the flag bits of the current message access permission attribute, used to distinguish between restricted access and allowed access.

[0120] Resource type can refer to the type of resources for the current target business. Different cloud resources are assigned different resource type codes so that traffic sources can be distinguished when processing shared flow tables, reserving identification space for future expansion.

[0121] Address group identifiers can refer to the unique numbers of pre-configured IP address groups. Each IP address group contains one or more IP addresses or network segments (e.g., 10.0.0.0 / 24), meaning that specific IP address groups can be associated with address group identifiers, enabling the reuse of access control rules.

[0122] A register can refer to a storage unit used to carry message context information (e.g., the general-purpose hardware register REG1 configured internally in OVS). In this embodiment, the register is used to store a first parameter, which remains unchanged as the message passes through different flow tables, thereby enabling the transfer of context information between different flow tables. It should be noted that the register can be selected and configured according to actual needs, and this embodiment does not limit this.

[0123] The first field can refer to the most significant bit of the register. In this embodiment, the first field occupies 1 bit and is used to store the access flag. A value of 0 indicates a restricted access flag, and a value of 1 indicates an allowed access flag.

[0124] The second bit field can refer to the second-highest bit region of the register. In this embodiment, the second bit field occupies 7 bits and is used to store the resource type. Different types of service resources can be distinguished through this bit field, supporting up to 128 resource types.

[0125] The third bit field can refer to the lower-order region of the register. In this embodiment, the third bit field may include 16 bits for storing the address group identifier and 8 bits for a reserved bit field. This bit field can be used to index a specific IP address group, supporting more than 60,000 IP address groups.

[0126] In some embodiments, after a packet matches a high-priority flow table entry in the first flow table, the electronic device reads the configuration information corresponding to the resource from a locally stored policy configuration table based on the matched target service resource identifier. This configuration information is pre-issued by the SDN controller and stored in the OpenFlow virtual switch when the service resource is created or the access control policy is changed. The configuration information includes an access identifier (allowed or restricted), a resource type code (e.g., 0000000 for ELB, 0000001 for VPN), and an address group identifier (e.g., 1, 2, 3, etc.).

[0127] In some embodiments, the electronic device can write the acquired configuration information into the corresponding bit fields of the register according to a preset bit field format. Specifically, taking the 32-bit register REG1 as an example, the access identifier can be written into the first bit field (bit 31), the resource type code into the second bit field (bits 30-bit 24), and the address group identifier into bits 15-bit 0 of the third bit field. The reserved bit fields (bits 23-bit 16) in the third bit field remain 0. After the writing is completed, the 32-bit value in the register is the first parameter. This write operation is implemented through the load operation in the OpenFlow flow table and is automatically completed by the switch's hardware pipeline without the participation of other hardware resources.

[0128] Below, in conjunction with Figure 3 The structure of the register will be explained in detail.

[0129] Figure 3 This is a schematic diagram of a register structure provided in an embodiment of this application. Please refer to [link / reference]. Figure 3 The register is a 32-bit register (e.g., REG1 in OVS), and its 32 bits are divided into four parts according to their functions.

[0130] The first part (bit 31): occupies 1 bit and is used to store access flags. When this bit is 0, it indicates a restricted access flag (corresponding to a blacklist); when this bit is 1, it indicates an allowed access flag (corresponding to a whitelist).

[0131] The second part (bits 30 to 24) occupies 7 bits and is used to store the resource type code (Type). This part can represent 128 different cloud resource types, such as 0000000 for ELB, 0000001 for VPN, 0000010 for Domain Name System (DNS), and 0000011 for Direct Connect (DC), etc. Reserved bits can be used to supplement this if the resource type is expanded subsequently.

[0132] The third part (bits 23 to 16) occupies 8 bits and is a reserved field for future feature expansion, such as the number of bits for extended resource type encoding or extended address group identification.

[0133] Part 4 (bits 15 to 0): Occupies 16 bits and is used to store the IP Group Unique Key. This part can represent 65,536 different IP address groups, each with a unique identifier. When a packet enters the IP address group matching table, the value of this bit field is used to index the corresponding IP address group, and the packet's source address is matched.

[0134] Through the above bit field division, the register encodes the access identifier, resource type, and address group identifier into a 32-bit value (i.e., the first parameter), realizing the efficient carrying of context information and providing standardized input for the unified processing of the shared flow table.

[0135] S203. Determine the target message processing method based on the first parameter.

[0136] The target packet processing method is used to forward the packet to be processed to the shared flow table for processing. In other words, the target packet processing method indicates the subsequent path of the packet to be processed in the pipeline, that is, to guide it to the preset shared flow table, where the shared flow table uniformly completes the matching and decision-making for access control.

[0137] The shared flow table is used to manage the access rules for each data packet. It can be understood as a set of common flow tables used for centralized processing of access control logic. After the packets from different service resources have completed the matching and encoding of the first flow table, they are all redirected to the shared flow table for unified address group matching and access identifier judgment, thus realizing the reuse of flow table rules.

[0138] In some embodiments, the electronic device may determine the target packet processing method based on the first parameter in the following manner: obtaining the historical cache record corresponding to the register; determining whether there is a cache record in the historical cache record that corresponds to the first parameter, destination address, destination port, and network attribute information; when it is determined that there is a corresponding cache record, determining the target packet processing method according to the processing procedure corresponding to the cache record; when it is determined that there is no corresponding cache record, sending the packet to be processed to the second flow table, and determining the target packet processing method through the second flow table.

[0139] The historical cache records are used to store the processing procedures of each data packet based on a shared flow table within a historical period. This can be understood as a cache module maintained in the SDN controller or switch, used to indicate the mapping relationship between frequently matched first parameters, destination address, destination port, and network attribute information within a historical period and their corresponding processing methods.

[0140] Since different users' Virtual Private Clouds (VPCs) may contain the same IP address and port (for example, user A's ELB1 address is 10.0.0.10:80, and user B's ELB2 address is also 10.0.0.10:80), and may be configured with the same IP address group and blacklist / whitelist type, thus generating the same first parameter (for example, REG1=0x1), the cache needs to use the destination address, destination port, VLAN or VNI, and TCP or UDP as distinguishing identifiers to avoid cache misses and accelerate packet processing.

[0141] The shared flow table includes a second flow table, which is used to match the address information of packets to be processed. In other words, the second flow table is the first-level processing table in the shared flow table. It determines the corresponding IP address range based on the address group identifier in the first parameter and performs mask matching on the source address of the packet to be processed. By centrally setting the mapping relationship between each address group and IP address range, the second flow table enables multiple service resources to share the same address group matching rules.

[0142] In some embodiments, the caching module is dynamically maintained by the SDN controller based on historical matching records. The SDN controller summarizes the matching frequency of each first parameter, destination address, destination port, and network attribute information, and stores the frequently matched first parameters and their corresponding processing methods (e.g., discarding or returning to the first flow table) in the cache.

[0143] The caching module can be updated using a Least Recently Used (LRU) algorithm to ensure that the cached content always reflects the current traffic pattern. When the first parameter of a packet to be processed is generated, the electronic device first queries the caching module, comparing the current first parameter, destination address, destination port, and network attribute information with the records in the cache. If a match is found, the cache is considered to have hit; otherwise, the cache is considered to have missed.

[0144] Specifically, upon confirming the existence of a corresponding cached record (i.e., a cache hit), the electronic device directly reads the corresponding processing method from the cached record. This processing method includes discarding the pending message or redirecting the pending message back to the first flow table to continue executing business logic. By using the cache hit method, the message does not need to enter the second and third flow tables for a complete matching process, significantly reducing the computational overhead of flow table queries and significantly improving matching efficiency.

[0145] When it is determined that no corresponding cache record exists, i.e., a cache miss, the electronic device redirects the pending packet to the second flow table. After processing by the shared flow table and subsequent service flow tables, the processing method corresponding to the current matching set (first parameter, destination address, destination port, and network attribute information) needs to be synchronously written into the cache module for rapid matching of subsequent packets with the same characteristics, thereby achieving dynamic updating of cache records.

[0146] The second flow table obtains the address group identifier by performing mask matching on the first parameter, determines the corresponding IP address range based on the identifier, and then performs mask matching on the source address of the packet with this range; based on the two matching results and the access identifier in the first parameter, it determines the subsequent packet processing flow.

[0147] S204. Process the message to be processed according to the target message processing method.

[0148] In some embodiments, the electronic device can perform corresponding message processing actions according to the target message processing method determined in step S203. If the target message processing method is to discard, the message processing flow is directly terminated and it is no longer forwarded to the target service resource; if the target message processing method is to send back to the first flow table, the message to be processed is redirected back to the first flow table, and the original business logic of the target service resource continues to be executed. Through the above method, unified management and efficient execution of the message processing flow are achieved while ensuring accurate execution of access control.

[0149] The data processing method, apparatus, electronic device, storage medium, and program product provided in this application receive a message request containing the message to be processed, source address, destination address, destination port, and network attribute information. The method matches the destination address, destination port, and network attribute information in a first flow table corresponding to the target service resource and determines a first parameter. Based on the first parameter, the method determines the target message processing mode and forwards the message to be processed to a shared flow table for processing. In this method, the electronic device can indicate the message processing flow direction through the first parameter. Based on the shared flow table, unified message processing for various service resources is achieved, effectively avoiding the flow table redundancy problem caused by independent configuration of flow tables for each service resource in the prior art, and reducing the exponential growth in the number of flow tables. Different service resources share the same set of shared flow tables for access control processing, eliminating the need for separate maintenance of flow tables for each service resource, significantly reducing maintenance difficulty and management costs. Furthermore, centralized message processing through the shared flow table shortens the message matching path, improves flow table matching efficiency and network forwarding performance, adapts to the access control requirements of various target service resources, requires no additional hardware resources, reduces deployment costs, ensures the standardization and accuracy of message processing, and improves the reliability of data processing.

[0150] Based on any of the above embodiments, the method by which the electronic device determines the target message processing mode through the second flow table in the above processing method will be described in detail.

[0151] Figure 4 This is a flowchart illustrating a method for determining a target message processing mode, provided in an embodiment of this application. Please refer to... Figure 4 The method includes the following steps:

[0152] S401. In the second flow table, perform mask matching on the first parameter to obtain the address group identifier, and determine the corresponding address range based on the address group identifier.

[0153] An address range can refer to one or more IP address ranges contained in a pre-configured IP address group. Each address group is indexed by a unique address group identifier and can store multiple IP network segments (e.g., 10.0.0.0 / 24, etc.) to define the set of source addresses that are allowed or restricted from access.

[0154] Mask matching refers to performing a bitwise AND operation between the value in a register and a preset mask. Bits in the mask that are 1 indicate a strict match, while bits that are 0 indicate no match. This method allows for precise acquisition of the value of a specific field.

[0155] In some embodiments, when it is necessary to determine an address range, the electronic device can extract the third bit field of the first parameter from the register to obtain the address group identifier. Subsequently, it queries a preset address group mapping table in the second flow table, which stores the correspondence between address group identifiers and specific IP address ranges.

[0156] For example, the electronic device uses the mask 0xffffff (binary representation: 0000 0000 1111 11111111 1111 1111 1111, i.e., the lower 24 bits are 1) to perform mask matching on the first parameter to extract the value of the lower 24 bits of the first parameter. These lower 24 bits contain 8 reserved bits and a 16-bit address group identifier. The value obtained after mask matching is the address group identifier. For example, if the value of the first parameter is 0x00000001, matching it with the mask 0xffffff yields 0x1, indicating that the address group identifier is 1; if the value of the first parameter is 0x0000000a, matching it yields 0xa (decimal 10), indicating that the address group identifier is 10.

[0157] It should be noted that regardless of whether the highest bit (access identifier) ​​of the first parameter is 0 or 1, and regardless of the value of the resource type bit field, the mask 0xffffff only focuses on the lower 24 bits, so the address group identifier can be extracted uniformly. For example, in a whitelist scenario, if the first parameter is 0x8000000a, matching 0xffffff will also yield 0xa, which is address group identifier 10.

[0158] After obtaining the address group identifier, the electronic device can query the preset address group mapping table in the second flow table. This mapping table stores the correspondence between address group identifiers and specific IP address ranges. For example, an address group identifier of 1 corresponds to the IP address range 10.0.0.0 / 24; an address group identifier of 10 corresponds to 192.168.1.0 / 24, and so on. Through this mapping relationship, the electronic device can determine the address range that the current packet needs to match.

[0159] In the bit field division of the first parameter, the reserved bits (bits 23 to 16) and the address group identifier bits (bits 15 to 0) together form the lower 24 bits. In this embodiment, the reserved bits are included in the matching range of the address group identifier. Therefore, a mask of 0xffffff (i.e., all lower 24 bits are 1) is used to perform mask matching on the first parameter to extract the address group identifier. If the reserved bits are not included in the address group identifier in other designs, then only the mask of 0xffff (i.e., all lower 16 bits are 1) needs to be used to match the lower 16 bits. This application does not limit the specific length of the mask, as long as it can uniquely determine the address group identifier from the first parameter.

[0160] S402. Perform mask matching on the source address and address range of the message to be processed to obtain the matching result.

[0161] The matching result refers to the status obtained after comparing the source address of the message to be processed with the address range, including two results: the source address is within the address range and the source address is not within the address range. This result will determine the subsequent processing flow of the message.

[0162] In some embodiments, the electronic device performs a masked match between the source address of the message to be processed and a defined address range. Specifically, for each network segment in the address range (e.g., 10.0.0.0 / 24), the source address is bitwise ANDed with the network prefix of that network segment, and then compared with the network address. If the source address matches any network segment, the matching result is that the source address is within the address range; if the source address does not match any network segment, the matching result is that the source address is not within the address range.

[0163] For example, if the source address is 10.0.0.5 and the address range is 10.0.0.0 / 24, the result of the mask operation is the same as the network address 10.0.0.0, which means it is a hit; if the source address is 10.0.1.5 and the result of the operation is different from the network address, which means it is a miss.

[0164] In some embodiments, the second flow table is pre-configured with flow table entries of different priorities. High-priority flow table entries are used to perform the address group identifier matching and source address mask matching operations described above (i.e., step S402). Simultaneously, the second flow table also configures lower-priority default processing flow table entries to handle cases where high-priority rules are not matched. When a packet enters the second flow table, the high-priority flow table entries are matched first: if a match is found, the process proceeds to step S405; if a match is not found (i.e., the source address is not within the address range, or the address group identifier does not match), the lower-priority default processing flow table entries are matched, and the process proceeds to step S403 or step S404 based on the access identifier in the first parameter.

[0165] S403. When the matching result indicates that the source address is not within the address range and the access identifier of the first parameter is an allowed access identifier, the target message processing method is determined to be to discard the message to be processed.

[0166] The access identifier can be either an authorized access identifier or a restricted access identifier.

[0167] The access permission flag indicates whether a pending message is allowed to access the target service resource. For example, a value of 0 in the first field of the register can be interpreted as meaning that only messages with source addresses within the specified address group are allowed to access the target service resource. In the third flow table, when the access permission flag is set to "Allow Access," it indicates that the source address is within the address range and the policy is whitelisted; in this case, the message should be allowed to proceed.

[0168] In some embodiments, when a packet does not match a high-priority flow table entry in the second flow table (i.e., the source address is not within the address range) and instead matches a low-priority flow table entry, the electronic device reads the access identifier from the first field (bit 31) of the first parameter. If the access identifier is an allowed access identifier (value 1, whitelist), and the source address is not within the allowed access address range, then according to the whitelist logic, service traffic not on the list should be blocked. Therefore, the electronic device determines that the target packet processing method is to directly discard the packet to be processed and terminate the subsequent processing flow.

[0169] S404. When the matching result indicates that the source address is not within the address range and the access identifier of the first parameter is a restricted access identifier, the target message processing method is determined to be to send the message to be processed back to the first flow table.

[0170] The restricted access flag is used to indicate that access to target service resources by a pending message is restricted. For example, a value of 1 in the first field of the register can be interpreted as prohibiting messages with source addresses within the specified address group from accessing target service resources. In the third flow table, when the access flag is a restricted access flag, it indicates that the source address is within the address range and the policy is a blacklist; in this case, the message should be discarded.

[0171] In some embodiments, when a packet does not match a high-priority flow table entry in the second flow table (i.e., the source address is not within the address range) but instead matches a low-priority flow table entry, the electronic device reads the first field of the first parameter. If the access identifier is a restricted access identifier (value 0, blacklist), and the source address is not within the restricted access address range, according to the blacklist logic, service traffic not on the list should be allowed. Therefore, the electronic device determines that the target packet processing method is to redirect the packet to be processed back to the first flow table and continue executing the original service logic of the target service resource.

[0172] S405. When the matching result indicates that the source address is within the address range, send the message to be processed to the third flow table, and determine the processing method of the target message through the third flow table.

[0173] The third flow table is used for access verification of packets to be processed. That is, the third flow table can refer to the second-level processing table in the shared flow table, used to execute the final action based on the access identifier in the first parameter. The third flow table only needs to make decisions based on the access identifier (first field), without needing to consider the specific address group or resource type, thus achieving unified processing of the final action.

[0174] In some embodiments, when the matching result indicates that the source address is within the address range, the electronic device redirects the packet to be processed to a preset third flow table via the "resubmit" action in the OpenFlow flow table. This redirection operation is automatically completed by the switch's hardware pipeline, and the packet continues to advance in the pipeline to the third flow table for further processing.

[0175] In some embodiments, the electronic device may determine the target message processing method through a third flow table based on the following implementation: in the third flow table, a mask matching is performed on the first parameter, and when the access identifier is an allowed access identifier, the target message processing method is determined to allow the message to be processed to pass and return it to the first flow table; when the access identifier is a restricted access identifier, the target message processing method is determined to discard the message to be processed.

[0176] In some embodiments, the electronic device reads the first bit field of the first parameter. If the value of this bit field is 1, the access identifier is determined to be an allowed access identifier. At this time, the target packet processing method is determined to redirect the packet to be processed back to the first flow table. This operation is implemented through the "resubmit" action, which sends the packet back to the original service flow table to continue executing the business logic of the target service resource.

[0177] Specifically, after a message is processed by the second and third flow tables and determined to be allowed, the electronic device needs to send the message back to the corresponding service flow table to continue executing the original service logic. That is, the electronic device reads the second bit field (bits 30 to 24) in the first parameter. This bit field stores the resource type code, which is used to identify the type of target service resource accessed by the current message (e.g., ELB, DNS, etc.).

[0178] Electronic devices determine the target first flow table to be transmitted back based on the preset mapping relationship between resource type codes and service flow table numbers. For example, the first flow table number corresponding to ELB is 10, the first flow table number corresponding to VPN is 11, and the first flow table number corresponding to DNS is 12, etc.

[0179] Subsequently, the electronic device redirects the packet to the corresponding first flow table via the "resubmit" action in the OpenFlow flow table, where the flow table continues to execute the business logic of the target service resource. This method ensures that packets from different service resources are accurately returned to their respective processing pipelines, achieving seamless integration of access control and business logic.

[0180] In some embodiments, the electronic device reads the first bit field of the first parameter. If the value of this bit field is 0, the access identifier is determined to be a restricted access identifier. In this case, the target message processing method is determined to discard the message to be processed, directly terminate the processing flow of the message, and no longer forward it to the target service resource.

[0181] For example, using ELB as an example, the flow table design of this solution will be described in detail. This solution uses table=10 as the first flow representation example for ELB services, table=22 as the IP address group matching representation example, and table=23 as the blacklist / whitelist action representation example. For instance, there exists an ELB instance whose VPC identifier is 1 (metadata=0x1), IP address is 10.0.0.10, and port is 80. This ELB is configured with a blacklist policy, associating with the IP address group identifier 1, which includes the network segment 10.0.0.0 / 24.

[0182] In the first flow table (table=10) corresponding to the ELB, a highest-priority flow table entry is pre-added with the matching condition "metadata=0x1, tcp, nw_dst=10.0.0.10, tp_dst=80, reg1=0". The metadata field is used to identify the VPC ID to which the packet belongs (e.g., metadata=0x1 represents VPC1, metadata=0x2 represents VPC2, etc.), which can distinguish potentially overlapping IP addresses in different VPCs. The corresponding action for this matching condition is to set register REG1 to 0x00000001 (the encoded meaning of this value is: the first field being 0 indicates a restricted access flag, the second field being 0 indicates the resource type is ELB, and the third field being 1 indicates the address group flag is 1), and redirect the packet to the second flow table (table=22).

[0183] In the second flow table (table=22), flow table entries with different priorities are pre-configured, specifically including: high-priority flow table entries (e.g., priority 200) are used to match address group identifiers and source address ranges; low-priority flow table entries (e.g., priority 100) are used to handle the default action in case of a miss.

[0184] When a packet with a source address of 10.0.0.5 (belonging to address group 1) arrives and accesses the aforementioned ELB, the packet hits the first flow table entry. REG1 is set to 0x00000001 and the packet enters the second flow table. In the second flow table, the address range 10.0.0.0 / 24 is found based on address group identifier 1. A mask match is performed on the source address 10.0.0.5, and the match result is "source address is within the address range". Since the match result is a hit, the packet is redirected to the third flow table (table=23). In the third flow table, the first field value of REG1 is read as 0, which is determined to be a restricted access flag, and the packet is dropped.

[0185] When a packet with a source address of 10.0.1.1 (not belonging to address group 1) arrives and accesses the aforementioned ELB, it is processed through the first flow table, where REG1 is set to 0x00000001, before entering the second flow table. In the second flow table, a mask match is performed between the source address 10.0.1.1 and the address range 10.0.0.0 / 24. The match result is "source address not within the address range". Since the match result is a miss, and the access identifier is a restricted access identifier (blacklist), the packet is redirected back to the first flow table according to the default action, and the ELB's load balancing business logic continues to execute.

[0186] If the ELB configuration above uses a whitelist policy, then REG1 will be set to 0x80000001 in the first flow table (the first field being 1 indicates an allowed access flag). In this case, packets whose source address is within the address group will be redirected back to the first flow table for further processing after entering the third flow table, based on the allowed access flag; packets whose source address is not within the address group will be matched against low-priority rules in the second flow table and discarded directly based on the allowed access flag.

[0187] In actual deployment, the first-flow tables for different service resources can be configured with different table numbers (e.g., ELB uses table=10, VPN uses table=15, DNS uses table=20, etc.). The IP address group table and blacklist / whitelist table can also be flexibly allocated based on pipeline free table numbers (e.g., using table=30 for the IP address group table and table=31 for the blacklist / whitelist table). As long as the first-flow tables of each service can correctly guide packets to the preset IP address group table and blacklist / whitelist table through redirection actions, the technical effect of this solution can be achieved. Therefore, the table number settings in this solution are only illustrative examples, and users can make adaptive adjustments according to their actual needs.

[0188] For other cloud resources, such as VPN and DNS, the same processing logic is used, requiring only different resource type codes to be set in their respective first-flow tables. For example, the VPN blacklist is set to REG1=0x10000001, and the VPN whitelist is set to REG1=0x90000001; the DNS blacklist is set to REG1=0x20000001, and the DNS whitelist is set to REG1=0xa0000001. Through the above unified coding and flow table design, all business resources can share the same set of second-flow and third-flow tables to complete access control processing. Details are shown in Table 1.

[0189] Table 1

[0190]

[0191] Based on Table 1, this scheme achieves unified processing of ELB blacklists and whitelists through a three-level flow table pipeline. In the first flow table (table=10), the highest priority flow table entry is pre-configured to intercept ELB service traffic. Flow table entry 1 matches the condition "metadata=0x1, tcp, mw_dst=10.0.0.10, tp_dst=80, reg1=0", and the action is to assign register REG1 the value 0x00000001 (indicating blacklist, ELB resource type, and address group identifier are 1), and redirect to the second flow table (table=22). The load... The (load) instruction is an action used to write specified data into a register or metadata field. This instruction encodes access control context information into the register for use by subsequent flow tables. Flow table entry 1' is used in whitelist scenarios. The matching conditions are "metadata=0x1, tcp, mw_dst=10.0.0.10, ip_dst=80, reg1=0". The action is to assign REG1 the value 0x80000001 (whitelist flag is 1) and redirect the packet to table=22.

[0192] It should be noted that the same business service under the same VPC (i.e., the same VPC ID, destination IP address, and destination port) can only be configured with one of the policies from the blacklist or whitelist. That is, flow table entry 1 and flow table entry 1' in Table 1 cannot coexist, in order to avoid rule conflicts.

[0193] In the second flow table (table=22, IP address group matching table), multiple flow table entries are configured in descending order of priority to collaboratively complete REG1 mask matching, source IP address mask matching, and traffic redirection in cases of no match. Specifically, flow table entry 2 has a priority of 200 and a matching condition of "ip, reg1=0x1 / 0xffffff, nw_src=10.0.0.0 / 24", which means matching packets whose lower 24 bits of REG1 are 0x1 and whose source address belongs to IP address group 1 (10.0.0.0 / 24). After a match, the packet is redirected to the third flow table (table=23).

[0194] Flow table entries 3 and 4 both have a priority of 100, which is lower than that of flow table entry 2. They only take effect when flow table entry 2 does not match. That is, flow table entry 3 has a priority of 100 and the matching condition is "reg1=0 / 0x80000000". This means that it matches packets where the highest bit of REG1 is 0 (blacklist) and the above address group rule is not matched. The action is to redirect back to table=10 to continue the ELB business logic.

[0195] Flow table entry 4 has a priority of 100 and a matching condition of "reg1=0x80000000 / 0x80000000", which means it matches packets whose highest bit of REG1 is 1 (whitelist) and which do not match the address group rule. The action is to discard them directly.

[0196] In the third flow table (table=23), two flow table entries are configured to perform the final action. Flow table entry 5 matches "0 / 0x80000000", which means it matches blacklisted packets where the highest bit of REG1 is 0, and performs a discard action. Flow table entry 6 matches "reg1=0x80000000 / 0x80000000", which means it matches whitelisted packets where the highest bit of REG1 is 1, and the action is to redirect back to table=10 to continue the ELB business logic. Through the above flow table design, the second and third flow tables serve as shared flow tables, which can be reused by all business resources, achieving decoupling between blacklists / whitelists and business logic.

[0197] In some embodiments, a time window parameter can be introduced to dynamically activate blacklist and whitelist rules within a specified time period, avoiding resource waste and false blocking issues caused by static rules. The controller allows users to configure an effective time period for access control rules (e.g., 9:00 AM to 6:00 PM on weekdays). During the effective time period, relevant flow table entries in the first, second, and third flow tables are automatically issued to complete blacklist and whitelist matching and processing. Outside the effective time period, the issued flow table entries are automatically deleted, rendering the blacklist and whitelist rules ineffective. Access traffic does not need to undergo blacklist and whitelist verification and is directly forwarded according to the original business logic.

[0198] In this way, through this mechanism, blacklist and whitelist rules only occupy flow table resources during the required time periods and are automatically released during non-working hours, avoiding invalid flow tables from occupying flow table resources for a long time and generating unnecessary matching overhead. For example, if a blacklist rule is configured for IP address group 1 of a certain ELB, and it is only effective during working hours on weekdays, then the controller will issue the relevant flow table between 9:00 AM and 6:00 PM on weekdays, and delete the flow table during other times, reducing the resource consumption of the controller and switch and optimizing the overall system performance.

[0199] In some embodiments, the number of flow tables can be further reduced and management simplified by aggregating multiple IP address ranges within an IP address group. Specifically, each service (IP address + port) can only be bound to one blacklist or whitelist and one IP address group. This IP address group can contain multiple IP address ranges (e.g., 10.0.0.0 / 24, 192.168.1.0 / 24, etc.).

[0200] In the second flow table (IP address group table), the corresponding IP address group is located by matching the address group identifier field of the first parameter using a mask. The controller then determines whether multiple IP address segments within the group can be routed together. If multiple IP network segments within the IP address group can be merged, the SDN controller can pre-aggregate these IP network segments. For example, 10.0.0.0 / 25 and 10.0.0.128 / 25 can be aggregated into 10.0.0.0 / 24, and 192.168.0.0 / 17 and 192.168.128.0 / 17 can be aggregated into 192.168.0.0 / 16. When the controller issues flow tables, it only issues the aggregated IP address segments, without issuing all the original network segments within the group. A unified source address matching is then performed on the aggregated IP network segments, eliminating the need to configure flow table entries separately for each original IP segment. This aggregation method allows multiple segments within an IP address group to share a single flow table rule, effectively reducing the number of flow tables.

[0201] When a segment within an IP address group changes, the controller only needs to dynamically update the address range matching rules corresponding to that address group identifier in the second flow table (table=22), without needing to modify the first flow table of each service resource individually. This is because all service resources share the same set of second and third flow tables. Once the address group matching rules in the second flow table are updated, all service resources referencing that address group automatically take effect, ensuring the real-time nature and consistency of the rules.

[0202] In related technologies, if an IP address group is bound to multiple service resources (e.g., multiple ELB instances, VPN instances, etc.), when the IP segments within that address group change, corresponding matching rules need to be added, deleted, or modified in the first-flow table of each service resource. For example, if a new IP segment is added to an IP address group, and that address group is used by both ELB and VPN, a rule matching that IP segment needs to be added to the first-flow table of both ELB and VPN. This operation is cumbersome and prone to omissions. If more service resources use the address group, each one needs to be modified individually, resulting in extremely high operational costs.

[0203] In this embodiment, since the blacklist / whitelist matching logic is decoupled to a shared flow table, when a segment within an IP address group changes, only the address range corresponding to the address group identifier needs to be updated in the second flow table. For example, if a new IP segment 10.0.2.0 / 24 needs to be added to the address group with address group identifier 1, only a high-priority flow table entry needs to be added to the second flow table (table=22), with the matching condition "reg1=0x1 / 0xffffff, nw_src=10.0.2.0 / 24", and the action is to redirect to the third flow table. All service resources bound to address group identifier 1 (including ELB, VPN, etc.) automatically take effect, without needing to modify the first flow table of each service resource individually.

[0204] It should be noted that in this solution, each service (IP address + port + network attribute information) is configured with independent blacklist and whitelist rules. Rules between different services (e.g., different IP addresses + ports + ELB instances under different VPCs) cannot be merged because access control policies may differ (e.g., a source IP that can access ELB1 within VPC1 may not be able to access ELB2 within VPC2 with the same IP address and port). Therefore, the aggregation processing in this solution only applies to multiple IP ranges within a single IP address group and does not involve merging rules across services or address groups.

[0205] The data processing method, apparatus, electronic device, storage medium, and program product provided in this application determine the address range in the second flow table based on the address group identifier in the first parameter, and obtain the matching result by performing mask matching between the source address and the address range. When the matching result indicates that the source address is not in the address range, the processing method is directly determined based on the access identifier. When the matching result indicates that the source address is in the address range, a message is sent to the third flow table and access verification is performed through the third flow table. In the third flow table, if the access identifier is an allowed access identifier, the message is sent back to the first flow table; if it is a restricted access identifier, the message is discarded. In the above method, electronic devices can reuse address group matching rules across multiple services through the second flow table, effectively avoiding the exponential growth of flow table entries caused by the repeated distribution of the same address range in various service flow tables in traditional solutions. Through the hierarchical design of the second and third flow tables, address range matching and final action execution are decoupled, allowing modifications to address group rules to be updated only in the second flow table, eliminating the need to traverse each service flow table individually, significantly reducing operational complexity and management costs. Furthermore, the dual verification mechanism of mask matching and access identifiers accurately distinguishes between hit and miss address group scenarios, executing corresponding default or final actions accordingly. This effectively avoids mis-allowing or mis-dropping issues caused by chaotic rule configurations. This method eliminates the need to maintain address group matching logic independently for each service resource, reducing redundant occupation of flow table resources and improving packet processing efficiency. Moreover, this method is applicable to various cloud resource scenarios such as load balancers, virtual private networks, and domain name resolution, significantly improving flow table utilization efficiency and system reliability while enhancing access control accuracy.

[0206] Figure 5 This is a flowchart illustrating another data processing method provided in an embodiment of this application. Please refer to... Figure 5 The method includes the following steps:

[0207] S501, Get the current value of the register;

[0208] Before a message enters the first flow table for matching, the electronic device first reads the current value of a register. This scenario corresponds to the need to determine whether a message is entering the first flow table for the first time or is a message returned after being processed by a shared flow table when processing begins in the pipeline. The electronic device directly reads the value stored in a register (e.g., register REG1) through the hardware pipeline. This value is 0 by default when the message enters the pipeline and becomes a non-zero value after being written to the first flow table.

[0209] S502. When the current value of the register is the preset initial value, perform the operation of matching the destination address, destination port and network attribute information.

[0210] The preset initial value is the default value of the register when a message first enters the pipeline. In this embodiment, the preset initial value is 0, indicating that the message has not yet undergone matching in the first flow table or writing to the first parameter.

[0211] In some embodiments, when the electronic device reads the current value of the register as a preset initial value, it determines that the packet is entering the first flow table for the first time and has not yet undergone access control processing. At this time, the electronic device performs a matching operation in the first flow table, comparing the packet's destination address, destination port, and network attribute information with pre-configured high-priority flow table entries in the first flow table. If the match is successful, the subsequent access control process continues (e.g., determining the first parameter, writing to the register, etc.); if the match fails, it is processed according to other flow table entries in the first flow table.

[0212] S503. When the current value of the register is different from the preset initial value, the message to be processed is processed through the first stream table.

[0213] In some embodiments, when the electronic device reads that the current value of the register is not a preset initial value (e.g., not 0), it determines that the packet has been processed by the shared flow table and returned to the first flow table, that is, the access control matching of the blacklist and whitelist has been completed. At this time, since the register value is no longer 0, the high-priority intercept flow table (whose matching condition includes reg1=0) no longer matches, so the packet will not be redirected to the shared flow table again, avoiding an infinite loop.

[0214] Specifically, the first flow table is configured with two types of flow table entries with different priorities: one is the highest priority (e.g., priority=65535) interception flow table, whose matching condition includes "reg1=0" (preset initial value), used to intercept raw packets that have not undergone access control processing and guide them to the shared flow table; the other is the low priority (e.g., priority=200, priority lower than 65535) raw business flow table, which serves the original business logic flow table and does not contain the matching condition "reg1=0", used to process packets after access control has been completed.

[0215] When a message returns from the shared flow table to the first flow table, the current value of the register (the first parameter) is no longer the preset initial value (reg1≠0). Therefore, it will not match the highest priority intercept flow table in the first flow table, thus preventing the message from being guided back to the shared flow table. At this time, the electronic device will directly determine the current value of the register as the first parameter and guide the message to match the low priority original service flow table in the first flow table, and process the message according to the original service business logic.

[0216] For example, in the first flow table (table=10) of the ELB service, the highest priority (priority=65535) interception flow table matching condition is "metadata=0x1,tcp,nw_dst=10.0.0.10,tp_dst=80,reg1=0", used to guide the original packet to the shared flow table; while its original business flow table matching condition is "metadata=0x1,tcp,nw_dst=10.0.0.10,tp_dst=80" (priority=200, lower than 65535), which is the original load balancing business logic flow table of ELB. After the packet completes the blacklist and whitelist processing of the shared flow table, reg1≠0, when returning to table=10, it no longer matches the high-priority interception flow table, but matches the low-priority original business flow table, executes the original business logic such as load balancing, and completes the final processing of the packet.

[0217] The data processing method, apparatus, electronic device, storage medium, and program product provided in this application obtain the current value of a register. When the current value of the register is a preset initial value, the device performs a matching operation on the destination address, destination port, and network attribute information. When the current value of the register differs from the preset initial value, the device processes the packet to be processed through a first flow table. In this method, the electronic device effectively distinguishes between packets entering the first flow table for the first time and packets returned after processing through a shared flow table by detecting whether the current value of the register is the preset initial value. This avoids the infinite loop problem caused by repeated matching of first flow table entries, ensuring the correctness of pipeline processing. Furthermore, this mechanism does not require adding additional flow table entries or modifying the existing pipeline structure; it achieves loop prevention simply by judging the initial state of the register, preventing wasted computing resources and forwarding anomalies caused by loops. Moreover, this method is applicable to first flow table scenarios for various service resources, optimizing the packet processing path without increasing hardware costs, and significantly improving the reliability and efficiency of packet processing while enhancing system stability.

[0218] Figure 6 This is a flowchart illustrating another data processing method provided in an embodiment of this application. Please refer to... Figure 6 The method includes the following steps:

[0219] S601, Request to receive data packets.

[0220] The data packet request includes the message to be processed, source address, destination address, destination port, and network attribute information. The data packet request is used to request access to the target service resource.

[0221] It should be noted that the execution process of S601 above can be found in S201, and will not be repeated here.

[0222] S602. In the first flow table corresponding to the target service resource, match the destination address, destination port and network attribute information, and determine the first parameter.

[0223] The first parameter is used to indicate the processing flow of the message to be processed.

[0224] It should be noted that the execution process of S602 above can be found in S202, and will not be repeated here.

[0225] S603, retrieve the historical cache record corresponding to the register.

[0226] Among them, the historical cache records are used to store the processing procedures of each data packet based on the shared flow table within a historical period.

[0227] S604. Determine whether there is a cache record in the historical cache that corresponds to the first parameter, destination address, destination port, and network attribute information.

[0228] S605. When it is determined that a corresponding cache record exists, the target message processing method is determined according to the corresponding processing procedure in the cache record.

[0229] S606. When it is determined that there is no corresponding cached record, a message to be processed is sent to the second flow table.

[0230] S607. In the second flow table, perform mask matching on the first parameter to obtain the address group identifier, and determine the corresponding address range based on the address group identifier.

[0231] S608. Perform mask matching on the source address and address range of the message to be processed to obtain the matching result.

[0232] S609. When the matching result indicates that the source address is not within the address range, and the access identifier of the first parameter is an allowed access identifier, the target message processing method is determined to be to discard the message to be processed.

[0233] The access permission flag is used to indicate whether the message to be processed is allowed to access the target service resource.

[0234] S610. When the matching result indicates that the source address is not within the address range and the access identifier of the first parameter is a restricted access identifier, the target message method is determined to be to send the message to be processed back to the first flow table.

[0235] The restricted access identifier is used to indicate that access to the target service resources by the pending message is restricted.

[0236] S611. When the matching result indicates that the source address is within the address range, send the message to be processed to the third flow table, and determine the processing method of the target message through the third flow table.

[0237] The third flow table is used to perform access verification on the messages to be processed.

[0238] It should be noted that the execution process of S603-S611 above can be found in S203, and will not be repeated here.

[0239] S612. Process the message to be processed according to the target message processing method.

[0240] Figure 7 This is a flowchart illustrating another data processing method provided in an embodiment of this application. Please refer to... Figure 7 The method includes the following steps:

[0241] The specific process is as follows: Access source A (IP address 10.0.0.1) and access source B (IP address 10.0.1.1) respectively initiate access requests to three types of service resources: ELB, VPN, and DC. All access traffic first enters the first-flow table corresponding to their respective resources (e.g., table=ELB, table=VPN, table=DC).

[0242] In the first flow table, a high-priority interception flow table entry is pre-configured. This entry only intercepts the first new packet whose current register value is a preset initial value (e.g., reg1=0). Since the registers are all at their initial values ​​when each packet first enters the pipeline, traffic from access source A and access source B to each service resource is redirected (access source A corresponds to a solid arrow, and access source B corresponds to a dashed arrow) to the shared flow table, and uniformly enters the access control verification process. When a packet is intercepted, the first flow table encodes the access identifier (allowed or restricted), resource type (ELB, VPN, or DC), and address group identifier (e.g., 1) into the register according to a preset bit field format based on the configuration information of the service resource, generates the first parameter, and redirects the packet to the shared flow table.

[0243] Within the shared flow table, the packet is first processed by the second flow table (IP address group matching table). The second flow table is configured with flow table entries of different priorities: high-priority entries (e.g., priority 200) are used to perform matching between the address group identifier and the source IP range; low-priority entries (e.g., priority 100) are used to handle the default action in case of a match. Specifically, the second flow table first performs mask matching on the first parameter to obtain the address group identifier, and determines the corresponding address range based on this identifier; then, it performs mask matching between the packet's source address and this address range. For access source A (10.0.0.1), its source address matches the address range, and the matching result indicates that the source address is within the address range (i.e., it belongs to 10.0.0.0 / 24, which is within this IP address group). The packet is redirected to the third flow table. For access source B (10.0.1.1), its source address does not match the address range, and the matching result indicates that the source address is not within the address range (i.e., it does not belong to 10.0.0.0 / 24, nor to 10.0.1.5, which is not within this IP address group). In this case, the high-priority rule matching fails, and then the low-priority rule is matched. The default action is executed according to the access identifier in the first parameter: if the access identifier is an allowed access identifier (whitelist), the packet is directly discarded; if the access identifier is a restricted access identifier (blacklist), the packet is redirected back to the first flow table to continue executing the business logic.

[0244] In the third flow table (whitelist / blacklist action table), the electronic device obtains the access identifier from the first parameter. For access source A, since its source address falls within the address range, after entering the third flow table, if the access identifier is an allowed access identifier (whitelist), the target packet processing method is determined to be redirecting the packet back to the first flow table to continue executing the original business logic of each service resource; if the access identifier is a restricted access identifier (blacklist), the target packet processing method is determined to be discarding the packet. In this example, the packet from access source A is marked as compliant and sent back to each service flow table for further processing; the packet from access source B, because it does not fall within the address range and is whitelisted, is marked as non-compliant and directly discarded, unable to access any target service resource.

[0245] Through the above steps, this scheme utilizes register encoding to uniformly carry access identifiers, resource types, and address group identifiers to a shared flow table. Through mask matching (including extracting the address group identifier from the mask of the first parameter and mask matching between the source IP address and the address range), all resources share the same set of IP address group matching rules. This eliminates the need to repeatedly add similar flow table entries to each resource table, effectively avoiding the problem of duplicate configuration of the same flow table entries in different service flow tables. Simultaneously, the register initial value detection mechanism in the first flow table prevents loops from occurring when packets are processed and transmitted back through the shared flow table, ensuring the correctness and stability of the pipelined processing.

[0246] The data processing method, apparatus, electronic device, storage medium, and program product provided in this application achieve unified processing of access control for multiple service resources and efficient utilization of flow table resources through register encoding, mask matching, and a hierarchical design of common flow tables. Specifically, by fully utilizing the 32 bits of the register, access identifiers, resource types, and address group identifiers are encoded into different bit fields, providing a unified context carrying method for various cloud resources. Without affecting the original business flow, by adding a high-priority flow table at the business entry point, traffic is uniformly guided to a common IP address group matching table and blacklist / whitelist action table, thus decoupling access control logic from specific business resources. In the common flow table, through mask matching technology, all business resources referencing the same address group share the same IP address group matching rules, effectively avoiding the problem of duplicate configuration of the same flow table entries in various business flow tables; at the same time, blacklist / whitelist actions also adopt mask matching, requiring only two flow tables to complete the final action decision for all resources, minimizing the number of flow tables. Furthermore, the solution incorporates a register initialization detection mechanism in high-priority flow tables to prevent loops from occurring when packets are processed and transmitted back through shared flow tables, thus ensuring the correctness of pipelined processing. This design minimizes the number of flow table entries in scenarios where multiple resources share the same access control policy, significantly reducing flow table complexity and operational difficulty, while improving flow table matching efficiency and forwarding path performance.

[0247] Figure 8 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application, as shown below. Figure 8 As shown, the device 80 includes: a receiving module 81, a matching module 82, a determining module 83, and a processing module 84.

[0248] The receiving module 81 is used to receive data packet requests. The data packet request includes the packet to be processed, source address, destination address, destination port and network attribute information. The data packet request is used to request access to the target service resource.

[0249] The matching module 82 is used to match the destination address, destination port and network attribute information in the first flow table corresponding to the target service resource, and determine the first parameter, which is used to indicate the processing flow of the packet to be processed;

[0250] The determination module 83 is used to determine the target packet processing method based on the first parameter. The target packet processing method is used to forward the packet to be processed to the shared flow table for processing. The shared flow table is used to manage the access rules of each data packet.

[0251] Processing module 84 is used to process the message to be processed according to the target message processing method.

[0252] The data processing apparatus provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0253] In one possible implementation, the matching module 82 is specifically used for:

[0254] Obtain the configuration information of the target business resource, including the access identifier, resource type, and address group identifier;

[0255] Write the access identifier to the first field of the register, the resource type to the second field of the register, and the address group identifier to the third field of the register.

[0256] The first parameter is generated based on the written values ​​of the first, second, and third fields.

[0257] In one possible implementation, the determining module 83 is specifically used for:

[0258] Retrieve the historical cache record corresponding to the register. The historical cache record is used to store the processing process of each data packet based on the shared flow table within a historical period.

[0259] Determine whether there is a cache record in the historical cache that corresponds to the first parameter, destination address, destination port, and network attribute information;

[0260] When it is determined that a corresponding cache record exists, the target message processing method is determined based on the corresponding processing procedure in the cache record;

[0261] When it is determined that no corresponding cached record exists, the message to be processed is sent to the second flow table, and the processing method of the target message is determined through the second flow table. The second flow table is used to match the address information of the message to be processed.

[0262] In one possible implementation, the determining module 83 is specifically used for:

[0263] In the second flow table, the first parameter is masked to obtain the address group identifier, and the corresponding address range is determined based on the address group identifier;

[0264] The source address and address range of the message to be processed are matched using a mask to obtain the matching result;

[0265] When the matching result indicates that the source address is not within the address range, and the access identifier of the first parameter is the allowed access identifier, the target packet processing method is determined to be to discard the pending packet. The allowed access identifier is used to indicate that the pending packet is allowed to access the target service resource.

[0266] If the matching result indicates that the source address is not within the address range and the access identifier of the first parameter is a restricted access identifier, then the target packet processing method is determined to be to send the packet to be processed back to the first flow table. The restricted access identifier is used to indicate that the packet to be processed is restricted from accessing the target service resources.

[0267] When the matching result indicates that the source address is within the address range, the message to be processed is sent to the third flow table, and the processing method of the target message is determined through the third flow table. The third flow table is used to perform access verification on the message to be processed.

[0268] In one possible implementation, the determining module 83 is specifically used for:

[0269] In the third flow table, the first parameter is masked and matched. When the access identifier is an allowed access identifier, the target message processing method is determined to allow the message to be processed to pass and is returned to the first flow table.

[0270] When the access identifier is a restricted access identifier, the target message processing method is determined to be to discard the pending message.

[0271] In one possible implementation, the device further includes a determination module, which is specifically used for:

[0272] Get the current value of the register;

[0273] When the current value of the register is the preset initial value, perform the matching operation on the destination address, destination port, and network attribute information;

[0274] When the current value of the register differs from the preset initial value, the message to be processed is processed through the first flow table.

[0275] The data processing apparatus provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0276] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 9 As shown, the electronic device 90 may include at least one processor 91 and a memory 92.

[0277] Memory 92 is used to store programs. Specifically, the program may include program code, which includes computer-executable instructions.

[0278] The memory 92 may include random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device.

[0279] The processor 91 is used to execute computer execution instructions stored in the memory 92 to implement the methods described in the foregoing method embodiments. The processor 91 may be a CPU, an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0280] Optionally, the electronic device 90 may also include a communication interface 93. In specific implementations, if the communication interface 93, memory 92, and processor 91 are implemented independently, they can be interconnected via a bus to complete communication. The bus can be an industry standard architecture (ISA) bus, a peripheral component (PCI) bus, or an extended industry standard architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc., but this does not imply that there is only one bus or one type of bus.

[0281] Optionally, in a specific implementation, if the communication interface 93, memory 92, and processor 91 are integrated on a single chip, then the communication interface 93, memory 92, and processor 91 can communicate through an internal interface.

[0282] The electronic device in this embodiment can be used to execute the technical solutions of the above method embodiments. The specific implementation methods and technical effects are similar, and will not be repeated here.

[0283] This application provides a computer-readable storage medium, which may include various media capable of storing computer-executable instructions, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), RAM, a disk, or an optical disk. Specifically, the computer-readable storage medium stores computer-executable instructions, which, when executed by a computer, cause the technical solution shown in the above method embodiment to be executed. The specific implementation and technical effects are similar and will not be repeated here.

[0284] This application provides a computer program product, including a computer program. When the computer program is executed by a computer, the technical solution shown in the above method embodiment is executed. The specific implementation method and technical effect are similar, and will not be repeated here.

[0285] 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 all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0286] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0287] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0288] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0289] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0290] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0291] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0292] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A data processing method, characterized in that, include: Receive a data packet request, the data packet request including the packet to be processed, source address, destination address, destination port and network attribute information, the data packet request is used to request access to the target service resource; In the first flow table corresponding to the target service resource, the destination address, the destination port and the network attribute information are matched, and a first parameter is determined. The first parameter is used to indicate the processing flow of the packet to be processed. Based on the first parameter, a target packet processing method is determined. The target packet processing method is used to forward the packet to be processed to a shared flow table for processing. The shared flow table is used to manage the access rules of each data packet. The message to be processed is processed according to the target message processing method. The first parameter is configured based on registers; Determine the first parameter, including: Obtain the configuration information of the target service resource, the configuration information including access identifier, resource type and address group identifier; Write the access identifier into the first field of the register, the resource type into the second field of the register, and the address group identifier into the third field of the register; The first parameter is generated based on the write value of the first bit field, the write value of the second bit field, and the write value of the third bit field.

2. The method according to claim 1, characterized in that, The shared flow table includes a second flow table; based on the first parameter, the target packet processing method is determined, including: Obtain the historical cache record corresponding to the register. The historical cache record is used to store the processing process of each data packet based on the shared flow table within a historical period. Determine whether there is a cache record in the historical cache records that corresponds to the first parameter, the destination address, the destination port, and the network attribute information; When it is determined that a corresponding cache record exists, the target message processing method is determined according to the corresponding processing procedure in the cache record; When it is determined that there is no corresponding cached record, the message to be processed is sent to the second flow table, and the processing method of the target message is determined through the second flow table, which is used to match the address information of the message to be processed.

3. The method according to claim 2, characterized in that, The shared flow table also includes a third flow table; the access identifier is either an allowed access identifier or a restricted access identifier; the target packet processing method is determined through the second flow table, including: In the second flow table, the first parameter is masked to obtain the address group identifier, and the corresponding address range is determined based on the address group identifier; The source address of the message to be processed is matched with the address range using a mask to obtain the matching result; When the matching result indicates that the source address is not within the address range and the access identifier of the first parameter is an allowed access identifier, the target packet processing method is determined to be to discard the pending packet, and the allowed access identifier is used to indicate that the pending packet is allowed to access the target service resource; When the matching result indicates that the source address is not within the address range and the access identifier of the first parameter is a restricted access identifier, the target packet processing method is determined to be to send the packet to be processed back to the first flow table. The restricted access identifier is used to indicate that the packet to be processed is restricted from accessing the target service resource. When the matching result indicates that the source address is within the address range, the message to be processed is sent to the third flow table, and the processing method of the target message is determined through the third flow table, which is used to perform access verification on the message to be processed.

4. The method according to claim 3, characterized in that, The target message processing method is determined through the third flow table, including: In the third flow table, the first parameter is masked, and when the access identifier is the allowed access identifier, the target packet processing method is determined to allow the packet to be processed to pass and return it to the first flow table; When the access identifier is the restricted access identifier, the target message processing method is determined to be to discard the message to be processed.

5. The method according to claim 1 or 2, characterized in that, After receiving the data packet request, the method further includes: Get the current value of the register; When the current value of the register is a preset initial value, an operation is performed to match the destination address, the destination port, and the network attribute information. When the current value of the register is different from the preset initial value, the message to be processed is processed through the first flow table.

6. A data processing apparatus, characterized in that, include: The receiving module is used to receive data packet requests, which include a packet to be processed, a source address, a destination address, a destination port, and network attribute information. The data packet request is used to request access to a target service resource. The matching module is used to match the destination address, the destination port and the network attribute information in the first flow table corresponding to the target service resource, and determine a first parameter, which is used to indicate the processing flow of the packet to be processed; The first parameter is configured based on registers; The determination module is used to determine the target packet processing method based on the first parameter. The target packet processing method is used to forward the packet to be processed to a shared flow table for processing. The shared flow table is used to manage the access rules of each data packet. The processing module is used to process the message to be processed according to the target message processing method; The matching module is specifically used to obtain the configuration information of the target service resource, the configuration information including access identifier, resource type and address group identifier; write the access identifier into the first field of the register, write the resource type into the second field of the register, and write the address group identifier into the third field of the register; The first parameter is generated based on the write value of the first bit field, the write value of the second bit field, and the write value of the third bit field.

7. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 5.

9. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-5.

Images