PPPoE dialing flow level refined shunting method and system based on dpi or dfi identification

Abstract

The application relates to the technical field of Internet and discloses a PPPoE proxy dialing flow level fine shunting method and system based on DPI or DFI identification; wherein the method collects network traffic messages, determines a service application type by relying on feature matching and flow behavior analysis; by means of a preset flow level redirection table, the messages are matched according to the service type and address conversion is completed, so that the traffic is shunted to a corresponding network outlet; the outlet transmission state is monitored in real time, the link quality is evaluated in combination with the service type, and the redirection table mapping relationship is dynamically updated; in the link switching stage, a bidirectional NAT binding mapping of a virtual IP and a service session is built to maintain stable transmission of the session. The scheme breaks the limitation of fixed binding of proxy dialing sessions and terminals, supports application level flexible routing, can allocate high-quality outlet resources on demand, activates idle links, at the same time, avoids the service lag problem caused by link switching, and effectively improves the utilization rate of park network resources and data transmission quality.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and more specifically, to a method and system for fine-grained PPPoE dialing based on DPI or DFI identification. Background Technology

[0002] Currently, most campus networks use PPPoE (Point-to-Point Protocol over Ethernet) dial-up networking via broadband from specific operators, such as China Mobile. Users uniformly rely on this operator's link for internet access. Campus gateways are typically configured with multiple high-quality network egress resources, such as those from China Telecom and CERNET. However, the existing PPPoE dial-up sessions and terminals use a fixed 1:1 or 1:N binding architecture, with a single PPPoE link permanently bound to one or more terminals. Due to the limitations of this session binding mechanism, it is impossible to flexibly schedule network egress resources based on application dimensions for user services. When a single operator's link carries services such as games and online video courses, the line quality is insufficient, easily leading to stuttering and high latency issues. Meanwhile, the idle high-quality egress resources of the gateway cannot be specifically utilized, lacking application-level fine-grained traffic offloading and scheduling capabilities. Summary of the Invention

[0003] The main purpose of this application is to provide a method and system for fine-grained traffic splitting of PPPoE proxy dialing based on DPI or DFI identification, which aims to solve the technical problems of fixed binding between PPPoE proxy dialing sessions and terminals in campus networks, the inability to flexibly select routes according to applications, cross-network lag for specific services, and the inability to effectively utilize high-quality egress resources.

[0004] The first aspect of this application proposes a PPPoE caller ID-based fine-grained traffic offloading method, including: Collect network traffic packets in PPPoE dialing scenarios, perform DPI signature matching and DFI flow behavior analysis respectively, and determine the service application type corresponding to each packet by fusing the identification results. A flow-level redirection table is pre-configured. The flow-level redirection table is retrieved according to the service application type. The source address of the matching application flow uplink packets is translated and redirected to the corresponding network egress. Continuously monitor the transmission status from each network egress to the target server, assess the egress quality based on the business application type, and synchronously update the egress association in the flow-level redirection table. When the application stream switches network exits, a two-way NAT binding mapping is established between the virtual IP and the service session to ensure that the PPPoE proxy session transmission is not interrupted.

[0005] Furthermore, the step of collecting network traffic packets in the PPPoE dialing scenario, performing DPI signature matching and DFI flow behavior analysis respectively, and fusing the identification results to determine the service application type corresponding to each packet includes: Capture the original packets of the PPPoE proxy network, extract the packet session identifier and transmission port information, and generate the original packet sequence with timestamps; The original message sequence is subjected to 5-tuple hash grouping processing to divide the data stream and query the port mapping relationship to generate primary application category labels; Extract the message payload and flow behavior information of the data stream, perform feature code comparison and flow behavior matching respectively, and generate a combined judgment record; The matching indicators in the combined judgment record are read, weighted, and matched against a preset threshold range to determine the business application type corresponding to the message.

[0006] Furthermore, the steps of pre-configuring the flow-level redirection table, retrieving the flow-level redirection table based on the service application type, performing source address translation on the matching application flow uplink packets, and redirecting them to the corresponding network egress include: Parse the application and egress mapping configuration and collect egress transmission parameters to generate an initial mapping table stored in a hash structure; A two-layer hash structure stream-level redirection table is built based on the initial mapping table, and the table entry index key is bound to the session state record; Calculate the hash value of the business application type to retrieve the flow-level redirection table and extract the matching egress interface and port configuration items; Extract the uplink packet's 5-tuple, assign a virtual address and port, replace the packet's source address, set a routing tag, and forward the packet to the corresponding network exit.

[0007] Further, the step of retrieving the hash value of the computing service application type from the flow-level redirection table and extracting the matching egress interface and port configuration items includes: Perform byte operations on strings of business application type to generate corresponding base hash values; Retrieve the sub-table configuration of the stream-level redirection table, calculate the base hash value to obtain the sub-table index number, and access the sub-table pointer array; Read the target sub-table entries from the sub-table pointer array, compare the fields with the business application type, and filter the matching entries. Extract the exit identifier of the matched entry from the address mapping table, obtain the exit address, and read the index key of the entry. Use the index key to query the session record and generate a verification value. After the verification is successful, extract the outgoing interface and port mapping configuration items.

[0008] Furthermore, the step of continuously monitoring the transmission status from each network egress to the target server includes: Traverse all available network exits and send probe messages to the transmission path from each network exit to the target server. By probing the message exchange process, the original transmission status data corresponding to round-trip delay, message loss, and network jitter are collected synchronously. The collected raw transmission status data is normalized and abnormal data is removed to obtain normalized transmission status data. The standardized transmission status data is classified, collected, and stored according to the network exit identifier, forming a transmission status record corresponding to each network exit.

[0009] Furthermore, the step of assessing export quality in conjunction with business application type includes: Read the transmission status records corresponding to each network exit and extract the round-trip time, packet loss and network fluctuation related status parameters contained in the records; Divide into different business application types, query the pre-defined type relationships, and extract the weight configuration data matching each business application type; The extracted transmission status parameters are weighted and calculated with the weight configuration data of the corresponding service application type to obtain the quality assessment data of each network exit. Collect quality assessment data from each network exit, classify exit levels according to preset rules, and generate exit assessment results that can be selected for scheduling.

[0010] Furthermore, the step of synchronously updating the outgoing link relationships in the flow-level redirection table includes: Retrieve the preferred exit identifiers for each business application and query the original exit identifiers bound to the corresponding business in the flow-level redirection table; Compare the preferred export identifier with the original export identifier; if there is a difference in the identifier, generate an association update trigger instruction. Replace the exit identifier information corresponding to the business in the table according to the update instructions, and generate new mapping and association content; Write the changed mapping content to Table Store, overwriting the original records, and complete the update of the flow-level redirection table association.

[0011] Furthermore, the step of establishing a bidirectional NAT binding mapping between the virtual IP and the service session to ensure uninterrupted PPPoE proxy session transmission during network egress switching of the application flow includes: Parse the exit switching command and retrieve the session binding table to extract application flow identification information and generate session identification credentials; Retrieve the old egress mapping record from the bidirectional NAT binding table, lock the new egress port resource, and generate a temporary session mapping table entry; A new bidirectional NAT mapping entry is created using a virtual IP address and a service session identifier, and packets are encapsulated to generate tunnel transmission data packets. Delete the old exit mapping record and enable the new mapping relationship, and update the forwarding information corresponding to the application flow in the connection tracking table.

[0012] Furthermore, the steps of retrieving the old egress mapping record from the bidirectional NAT binding table, locking the new egress port resource, and generating a temporary session mapping table entry include: Parse the old exit identifier carried in the switching command, locate the storage area corresponding to the two-way NAT binding table, and extract the storage index of the application stream to be switched; Retrieve the source and destination address mapping records corresponding to the storage index, compare the flow identifier field, and filter the mapping data that matches the application flow; Adjust the status field of the matching mapping record and write the timestamp information to generate migration marker data with record address and port information; Parse the new exit identifier carried by the switching instruction, retrieve the corresponding address pool port bitmap, and mark the target port as reserved; Bind the reserved port and the application stream session identifier and write them to the storage area to generate a session persistence mapping table entry with temporary effective attributes.

[0013] The second aspect of this application also proposes a PPPoE dial-up fine-grained offloading system based on DPI or DFI identification, comprising: The service identification module is used to collect network traffic packets in PPPoE dialing scenarios, perform DPI feature code matching and DFI flow behavior analysis respectively, and fuse the identification results to determine the service application type corresponding to each packet. The flow mapping and forwarding module is used to pre-configure the flow-level redirection table, retrieve the flow-level redirection table according to the service application type, perform source address translation on the uplink packets of the matching application flow, and redirect them to the corresponding network egress. The exit assessment and update module is used to continuously monitor the transmission status from each network exit to the target server, assess the exit quality in combination with the business application type, and synchronously update the exit association relationship in the flow-level redirection table. The session keep-alive module is used to establish a two-way NAT binding mapping between the virtual IP and the service session when the application flow switches network exits, so as to keep the PPPoE dial-up session transmission uninterrupted.

[0014] The first aspect of this plan brings the following benefits: This application accurately identifies various application service flows by combining DPI feature matching with DFI flow behavior analysis, breaking the traditional fixed binding mode of PPPoE proxy sessions and terminals, realizing flexible routing based on application dimensions, and intelligently scheduling high-quality network egress resources by monitoring the transmission status of each egress in real time and dynamically updating the flow-level redirection table, effectively revitalizing idle links. At the same time, it constructs bidirectional NAT binding mapping during egress switching to ensure uninterrupted sessions, effectively improving the cross-network lag problem for specific services, and significantly improving the utilization rate of campus network egress resources and overall transmission quality. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating a method for fine-grained traffic splitting at the PPPoE dialing level based on DPI or DFI identification, according to an embodiment of this application. Figure 2 This is a schematic diagram of the structure of a PPPoE dialing flow-level fine-tuning system based on DPI or DFI identification according to an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a computer device according to an embodiment of this application; The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0017] Those skilled in the art will understand that, unless explicitly stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in the specification of this application means the presence of features, integers, steps, operations, elements, modules, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, modules, components, and / or groups thereof. It should be understood that when an element is “connected” or “coupled” to another element, it may be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein may include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any modules and all combinations of one or more associated listed items.

[0018] Those skilled in the art will understand that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0019] Implementation Case Background: The methods and systems described in this invention are implemented on a high-performance gateway (e.g., based on DPDK and VPP architecture) using a user-space high-performance packet processing framework and vector packet forwarding architecture. To support high-concurrency scenarios involving multiple PPPoE dial-ups in large campus networks with speeds of 10 Gbps or higher, this system decouples the control plane from the forwarding plane. The control plane is responsible for monitoring the negotiation signaling of PPPoE sessions, maintaining the global state machine, and calculating and generating the dynamic mapping table or flow-level redirection table. The control plane distributes the table entries to the forwarding plane via a high-speed memory channel (such as a shared lockless queue of large pages). In the user-space data channel, the forwarding plane performs millisecond-level packet interception, DPI / DFI deep feature extraction, DNS redirection, and flow-level asymmetric NAT translation in a vector packet batch processing manner. This avoids the context switching overhead caused by frequent switching between kernel and user space in traditional network protocol stacks, ensuring low-latency packet processing at 10 Gigabit line-rate throughput.

[0020] Reference Figure 1 This application provides a method for fine-grained PPPoE caller ID based on DPI or DFI identification, including: S1: Collect network traffic packets in PPPoE dialing scenarios, perform DPI signature matching and DFI flow behavior analysis respectively, and determine the service application type corresponding to each packet by fusing the identification results. S2: Pre-configure the flow-level redirection table, retrieve the flow-level redirection table according to the service application type, perform source address translation on the matching application flow uplink packets and redirect them to the corresponding network exit; S3: Continuously monitor the transmission status from each network egress to the target server, assess the egress quality based on the business application type, and synchronously update the egress association in the flow-level redirection table; S4: When the application flow switches network exits, establish a two-way NAT binding mapping between the virtual IP and the service session to ensure that the PPPoE proxy session transmission is not interrupted.

[0021] In step S1, the reference traffic is first determined to be the Honor of Kings game service traffic packet initiated by the user terminal in the PPPoE dialing scenario of the park (the service application identifier sequence is [8,15], where 8 corresponds to the Honor of Kings game service and 15 corresponds to the ordinary web browsing service). Next, we prepare the input parameters for the fusion identification of DPI (Deep Packet Inspection) and DFI (Deep Flow Inspection): raw traffic packets captured by the user-space packet processing framework (packet batch shape is [200, 64, 128], corresponding to 200 packet streams, 64 terminal samples, and a maximum packet payload length of 128 bytes); pre-built application feature library containing feature codes of various service application layers (the feature code field of Honor of Kings is 0xA23F, and the feature code field of Tencent Meeting is 0xB45E); flow behavior feature parameters include packet length sequence and send / receive time interval (the packet length range of Honor of Kings single stream is 64~1400 bytes, and the packet interval is 5~20ms); the sample batch to be identified consists of 64 PPPoE proxy session traffic streams, with 200 fixed time sampling points for each packet stream. Then, relying on the user-space message processing framework, message regularization is completed, and the application layer payload and transport layer header information of each message are extracted. First, the DPI feature code is matched with the preset application feature library item by item to generate the preliminary DPI identification result; then, the length sequence and transmission and reception time interval of the regularized message are extracted to complete the DFI flow behavior rule comparison and generate the DFI flow behavior identification result. The consistency integration and verification of the DPI identification result and the DFI identification result are performed. The two types of identification data are fused according to the preset judgment rules to obtain the business application type of the batch of 64 samples. Among them, the identification result of the King of Glory business flow is matched with the identifier [8], and the identification result of the ordinary web page browsing business flow is matched with the identifier

[15] . Since DPI relies on static feature codes to accurately match known applications, and DFI relies on flow behavior features to identify encrypted applications without feature codes, the fusion of the two can cover the identification of all types of business traffic. The business application type of each message output in this step is a fixed numerical identifier, which can be directly used as the input basis for subsequent flow-level redirection table retrieval. Step S1 uses DPI and DFI dual-dimensional packet parsing and fusion judgment to transform the original PPPoE dialing traffic packets into standardized business application identifiers, thereby realizing the quantitative transformation of disordered network packets into classifiable business flows.

[0022] In step S2, the reference service flow is first determined to be the Honor of Kings game service flow identified in step S1 (the service application identifier is [8], 8 corresponds to the Honor of Kings game service, the default binding high-quality telecom exit identifier is E1, and the original mobile default exit identifier is E0). Then, the input parameters for flow-level fine-tuning are prepared: the flow-level redirection table is pre-initialized, and the table stores the mapping relationship between the service identifier and the network exit [8:E1, 15:E0]; the application flow uplink message batch after S1 identification, the message five-tuple feature dimension is [64,200], corresponding to 64 PPPoE proxy sessions, each session with 200 message time steps; the source address to be converted is the original address of the park PPPoE proxy terminal 10.0.0.5; the telecom exit adaptation forwarding source address is 202.105.8.30. Then, the flow-level redirection table is searched, and the corresponding target network exit identifier E1 is matched and read using the service identifier [8] as the search keyword. Source address translation is performed on the uplink packets of the King of Glory single application flow that are successfully matched, and the original source address 10.0.0.5 of the packet is replaced with the telecom exit adaptation address 202.105.8.30. After the SNAT address translation is completed, the application flow is independently forwarded to the telecom exit E1. The ordinary web browsing traffic of the same batch with the service identifier

[15] is still forwarded to the mobile exit E0 according to the original link without address modification or exit switching. The flow-level redirection table uses the service identifier as the unique index. Each identifier corresponds to a unique exit number. The address translation only applies to the successfully matched application flow and does not interfere with other service traffic. The packet source address replacement value is the fixed available public network address of the exit network segment to ensure cross-exit route reachability. Step S2 uses the flow-level redirection table to retrieve and translate the source address of the uplink packet to realize the exit isolation forwarding of different service flows under the same PPPoE dialing session, solidify the service identification result output by S1, and provide a stable flow-level scheduling basis for the exit quality monitoring and dynamic update of the mapping table in step S3.

[0023] In step S3, the reference service is first determined to be the Honor of Kings game service (the service application identifier is [8], the corresponding target server IP is 180.105.210.35, and the existing network exit is mobile exit E0 and telecom exit E1). Then, the input parameters for exit quality assessment and table update are prepared: the number of probe packets is 120, and the probe duration is 10ms; the collected indicators include round-trip time (RTT), packet loss rate, and network jitter; the preset weight coefficients for Honor of Kings service are RTT 0.6, packet loss rate 0.3, and jitter 0.1; after normalization, the measured RTT of mobile exit E0 is 45ms, packet loss rate is 2.1%, and jitter is 18ms, and the measured RTT of telecom exit E1 is 12ms, packet loss rate is 0.2%, and jitter is 5ms; the original mapping relationship of the flow level redirection table is [8:E1, 15:E0]. Then, all available network exits are traversed, and probe messages are sent to the paths from the two exits to the target server of Honor of Kings. The original transmission status data is collected and outliers are removed. The data is then classified and stored according to the exit identifier. The weighted scoring calculation rules are called, and the weight coefficients and measured parameters are substituted to perform weighted calculations. The mobile exit E0 quality score is 29.43 and the telecom exit E1 quality score is 7.76. The exit level is distinguished according to the score. It is determined that the preferred exit for Honor of Kings is still E1. The original exit identifier bound to the service identifier in the flow-level redirection table [8] is retrieved. The preferred exit is compared with the original exit identifier. If there is no difference between the two, no update is triggered. If the measured parameters change and the preferred exit changes, an update instruction is generated to replace the mapping relationship between the service and the exit in the table and overwrite the storage. The exit quality score is a quantitative value. The smaller the score, the better the link transmission quality. The probe data is collected in a fixed cycle to ensure that the scoring results are real-time. Step S3 forms a closed loop of linkage between link quality data and traffic splitting rules by detecting the status of multiple outbound links, assessing the weighted quality of services, and verifying and updating the mapping relationship of the flow-level redirection table.

[0024] In step S4, the reference service session is first determined to be the Honor of Kings game service session mentioned above (the service application identifier is [8], the terminal original address is 10.0.0.5, the original mobile exit is E0, and the switching target is the telecom exit is E1). Then, the input parameters for bidirectional NAT and virtual IP mapping are prepared: the service session quintuple is a fixed identifier, the virtual IP address pool is the 192.168.100.0 / 24 network segment; the exit forwarding source address is the telecom exit 202.105.8.30; the session port is 443, and the receiving time step sampling is 200; the bidirectional NAT (Network Address Translation) binding table is preset to store 3000 entries, each with three types of fields: original address, virtual IP, and exit source address. Then, the application flow exit switching event is detected, and the original address and target exit E1 information of the current session are extracted. The original address and port of the terminal are hashed, and the retrieval offset position is determined by referring to the range of the virtual IP address pool. The network prefix of the original address is parsed, the corresponding network segment allocation interval is matched, and the candidate virtual IP is filtered out. After comparing the address occupancy status using a second hash, a dedicated virtual IP address of 192.168.100.58 is assigned. A forward mapping is established between the virtual IP address 192.168.100.58 and the terminal's original address 10.0.0.5. A reverse mapping is established between the telecom egress source address 202.105.8.30 and the virtual IP address 192.168.100.58. These two mappings are integrated into a binding entry and written to the bidirectional NAT binding table. The bidirectional NAT binding table stores the mapping relationships using a 5v tuple index, and both uplink and downlink packets strictly follow the binding entry for address translation and forwarding. The virtual IP is a session-specific fixed address, and the terminal side perceives no change in address before and after the handover. The PPPoE proxy session maintains the original link without being torn down or reconnected. There is no packet interruption or session drop at the service application layer. Step S4, through virtual IP allocation, forward and reverse double-layer mapping, and bidirectional NAT binding table solidification, completes the maintenance of session continuity during cross-egress handover.

[0025] In one embodiment, the step of collecting network traffic packets in a PPPoE dialing scenario, performing DPI signature matching and DFI flow behavior analysis respectively, and fusing the identification results to determine the service application type corresponding to each packet includes: S10: Take the original PPPoE dial-up network packets, extract the packet session identifier and transmission port information, and generate the original packet sequence with timestamps; S11: Perform five-tuple hash grouping processing on the original message sequence, divide the data stream and query the port mapping relationship to generate a primary application category label; S12: Extract the message payload and flow behavior information of the data stream, perform feature code comparison and flow behavior matching respectively, and generate a combined judgment record; S13: Read the matching indicators in the combined judgment record, perform weighted calculation, match the preset threshold range, and determine the business application type corresponding to the message.

[0026] In this embodiment, the first step is to capture the original packets of the PPPoE proxy network, extract the packet session identifier and transmission port information, and generate the original packet sequence with timestamps. Referring to the unified closed-loop case mentioned earlier, the campus gateway is equipped with mobile egress E0 and telecom egress E1. Service identifier 8 corresponds to the traffic of the game Honor of Kings, and service identifier 15 corresponds to the traffic of ordinary web browsing. The gateway registers packet capture callbacks based on the DPDK user-space packet framework to capture the original packets of the network card. 64 PPPoE proxy session traffic are sampled in a single batch, and 200 packet samples with millisecond timestamps are continuously captured for each session. Taking the King of Glory single-channel session with service identifier 8 as an example, the original packet header is captured and parsed to obtain the session identifier SID=0x0068 and the transport layer destination port 443. The single packet timestamp sampling accuracy is 1ms, generating an ordered original packet sequence [TS1:1762031120001,SID=0x0068,Dport=443;TS2:1762031120003,SID=0x0068,Dport=443……]. Within the batch, the web traffic session with service identifier 15 has a session identifier SID=0x0092 and port 80, and a corresponding timestamp packet sequence is generated synchronously. All original packet sequences are stored in partitions according to session SID to ensure that session data is not confused during subsequent group processing. This uniformly inherits the parameters of the multi-exit traffic splitting scenario mentioned above, realizing the closed-loop uniformity of parameters in the entire implementation example.

[0027] Next, the original message sequence is subjected to 5-tuple hash grouping processing to divide the data stream and query the port mapping relationship, generating a primary application category label. The 5-tuple contains the source IP, destination IP, source port, destination port, and transport protocol. A 32-bit hash algorithm is used to perform an XOR operation on the 5-tuple fields to generate a hash index. Messages with the same hash value are grouped into the same data stream container and assigned a unique stream ID. For example, the hash value of the Honor of Kings business stream 5-tuple (source 10.0.0.5, destination 180.105.210.35, source 51234, destination 443, TCP) is calculated to be 0x2175, and the stream ID is assigned to F008; the hash value of the web browsing 5-tuple is 0x3691, and the stream ID is assigned to F015. The built-in well-known port mapping table is retrieved. Port 443 corresponds to the encrypted streaming media / game category, and port 80 corresponds to the web browsing category. Based on this, primary tags are generated: stream ID=F008 is labeled as real-time game, and stream ID=F015 is labeled as ordinary web page. All 64 sessions within the batch are hashed and labeled with primary tags to build a basic data stream classification framework. Next, the packet payload and flow behavior information of the data stream are extracted. Feature code comparison and flow behavior matching are performed respectively to generate a combination judgment record. For each stream ID container, the first packet with a complete payload is extracted, and a 16-byte payload offset is extracted as the feature comparison interval. The default feature code for Honor of Kings is fixed at 0xA23F, and the general feature code for web traffic is 0x71C0. At the same time, the packet length and packet arrival interval sequence of 200 consecutive packets are extracted. The Honor of Kings flow behavior template has a packet length of 64~1400 bytes and a packet interval of 5~20ms. The web traffic template has a packet length fluctuation range of 200~8000 bytes and an interval of 20~100ms. Stream ID=F008's payload feature byte matched 0xA23F bit by bit, with a DPI confidence of 0.96; message length, interval, and similarity to the game template were 0.92. Stream ID=F015's payload matched a webpage feature code, with a DPI confidence of 0.91 and a stream behavior similarity of 0.95. Both types of indicators were stored in a combined judgment record for the same stream. The record fields included stream ID, DPI confidence, DFI similarity, and primary application tag, forming a complete set of judgment records for the entire batch.

[0028] Then, the matching indicators in the combined judgment record are read and weighted, and the preset threshold range is matched to determine the business application type corresponding to the message. The preset weight configuration is DPI feature code weight 0.6 and DFI flow behavior weight 0.4. The judgment threshold range is: comprehensive score ≥ 0.85 is judged as real-time game (identifier 8), 0.6≤score<0.85 is judged as ordinary webpage (identifier 15). The weighted operation is performed on the flow ID=F008: 0.96*0.6+0.92*0.4=0.944. The value falls into the ≥0.85 range, and the final judgment is business identifier [8] King of Glory; the weighted operation is performed on the flow ID=F015: 0.91*0.6+0.95*0.4=0.926. The webpage traffic range is matched, and the final judgment is business identifier

[15] ordinary webpage. The remaining 62 PPPoE session data streams within the batch are calculated using the same weighting formula and threshold rules, outputting a unique standardized service identifier for each data stream. This provides a standardized retrieval key for subsequent flow-level redirection table searches and optimal outbound traffic allocation. It fully inherits the traffic allocation logic described earlier, where the telecom outbound E1 carries games and the mobile outbound E0 carries web pages. This embodiment integrates DPI payload characteristics and DFI flow behavior, taking into account both plaintext and encrypted traffic identification, significantly improving the accuracy of service identification and providing a reliable basis for refined flow-level traffic allocation.

[0029] In one embodiment, the steps of pre-configuring a flow-level redirection table, retrieving the flow-level redirection table based on the service application type, performing source address translation on the matching application flow uplink packets, and redirecting them to the corresponding network egress include: S20: Parse the application and exit mapping configuration and collect exit transmission parameters to generate an initial mapping table stored in a hash structure; S21: Based on the initial mapping table, build a two-layer hash structure stream-level redirection table and bind the table entry index key with the session state record; S22: Calculate the hash value of the business application type to retrieve the flow-level redirection table and extract the matching egress interface and port configuration items; S23: Extract the uplink packet 5-tuple, allocate a virtual address and port, replace the packet source address and set the routing tag, and forward the packet to the corresponding network exit.

[0030] In this embodiment, the first step is to parse the application and egress mapping configuration and collect egress transmission parameters to generate an initial mapping table stored in a hash structure. Continuing the unified closed-loop scenario described earlier: a campus PPPoE dial-up network, with China Mobile's default egress E0 and China Telecom's premium egress E1. Service identifier 8 is for Honor of Kings, and service identifier 15 is for regular web browsing. The preset egress rules for these services are that identifier 8 is bound to E1, and identifier 15 is bound to E0. The gateway reads the local configuration file to parse the binary mapping relationship and simultaneously collects the basic transmission parameters for the two egress points: E0 has a base latency of 45ms and a bandwidth limit of 1000Mbps, while E1 has a base latency of 12ms and a bandwidth limit of 1000Mbps. The application identifier, egress number, latency, and bandwidth parameters are encapsulated into table entries and stored in the memory's basic hash to generate the initial mapping table. A single table entry has the structure {app_id, e_id, base_rtt, bandwidth}. All 64 service flows in the batch share the same initial mapping hash, ensuring a complete match with the service identifiers output by the identification module described earlier. Secondly, a two-layer hash structure stream-level redirection table is built based on the initial mapping table. Table entry index keys are bound to session state records. The business application type is used as the first-level hash key, and the bandwidth requirement level as the second-level hash key. For example, game services have a high bandwidth requirement level (8) and web services have a medium bandwidth requirement level (15). A nested hash structure is constructed, assigning a globally unique index key to each table entry. The index key is synchronously associated with the session state record, which stores the corresponding PPPoE session SID, stream ID, and occupied port range. For example, the game service table entry index key IDX008 is associated with SID=0x0068 and stream ID=F008, and the web service table entry index key IDX015 is associated with SID=0x0092 and stream ID=F015. All entries are uniformly stored in a lock-free hash container in large-page memory, adapting to the concurrent query requirements of 10 Gigabit gateways.

[0031] Next, the hash value of the business application type is calculated to retrieve the flow-level redirection table, extract the matching egress interface and port configuration items, and generate a base hash by XORing and accumulating the business identifier string bytes. The business identifier 8 is calculated to obtain a hash value of 208. The total number of sub-tables in the redirection table is set to 8. The modulo operation of 208 with 8 gives the sub-table index number 0. The sub-table number 0 is accessed and the table entries are traversed to match app_id=8, extracting the egress identifier E1. Then, the egress address mapping table is queried to obtain the telecom egress interface eth1 and the port pool range 10000-30000. The hash value of the business identifier 15 is 240. After modulo, the sub-table index number is 0, matching egress E0, corresponding to the interface eth0 and the port pool range 30001-50000. The session record verification field is queried through the index key. After the verification is successful, the complete interface and port configuration are output to provide parameter support for address translation. Next, the uplink packet 5-tuple is extracted, a virtual address and port are allocated, the packet source address is replaced, and a routing flag is set. The packet is then forwarded to the corresponding network exit. The uplink packet 5-tuple of Honor of Kings is extracted (source 10.0.0.5, destination 180.105.210.35, source 51234, destination 443, TCP). The hash 5-tuple is used as a retrieval index. A virtual IP 202.105.8.30 and an idle port 10240 are allocated from the E1 address pool. The original source IP and source port of the packet are replaced, the IP checksum is recalculated, and the routing flag flag=1 is set to correspond to eth1. The web traffic 5-tuple is allocated with a virtual IP 10.0.0.10 and a port 30010. The routing flag flag=0 corresponds to eth0. After the modification, the packet is forwarded to the corresponding physical exit according to the flag. This embodiment uses a double-layer hash fast table lookup to complete the flow-level SNAT translation, realize differentiated exit forwarding for multiple services on the same terminal, and make full use of multiple link resources.

[0032] In one embodiment, the step of retrieving the hash value of the calculated service application type from the flow-level redirection table and extracting the matching egress interface and port configuration items includes: S220: Perform byte operations on the business application type string to generate the corresponding base hash value; S221: Retrieve the sub-table configuration of the stream-level redirection table, calculate the base hash value to obtain the sub-table index number and access the sub-table pointer array; S222: Read the target sub-table entries from the sub-table pointer array, compare the fields with the business application type, and filter the matching entries; S223: Extract the exit identifier of the hit table entry, retrieve the address mapping table, obtain the exit address, and read the table entry index key; S224: Use the index key to query the session record and generate a verification value. After the verification is successful, extract the egress interface and port mapping configuration items.

[0033] In this embodiment, the first step is to perform byte operations on the service application type strings to generate corresponding base hash values. Continuing the unified closed-loop scenario described earlier: the park's PPPoE dial-up gateway is equipped with a mobile exit E0 and a telecom exit E1. Service identifier 8 corresponds to the game "Honor of Kings," and service identifier 15 corresponds to ordinary web browsing. The identification module outputs service strings "game_8" and "web_15" respectively. The base hash is calculated using a bitwise XOR accumulation algorithm. Taking the "game_8" service string as an example, each character's ASCII byte is extracted and XORed bitwise, resulting in a base hash value of 208. The ordinary web browsing service string "web_15" undergoes the same byte operations, yielding a base hash value of 240. These two types of service hash values ​​are cached separately as the basis for subsequent sub-table location. The entire process reuses the previously mentioned 64 PPPoE sessions, flow IDs F008 and F015, and other established parameters to ensure consistency throughout the case. Next, the sub-table configuration of the flow-level redirection table is retrieved. The sub-table index number is obtained by calculating the base hash value and accessing the sub-table pointer array. The default configuration for the total number of sub-tables in the flow-level redirection table is 8. The sub-table index is obtained by taking the modulo operation of the base hash value with the total number of sub-tables. For example, the hash value of Honor of Kings is 208, and 208%8=0, so the target sub-table index number is 0; the hash value of the webpage is 240, and 240%8=0, so the 0th sub-table is located. The gateway reads the sub-table pointer array in memory and directly accesses the memory base address of the 0th sub-table through the index number offset, without needing to traverse the entire table, reducing memory addressing overhead. All business flows uniformly reuse this sub-table allocation rule to maintain consistency in batch data processing logic.

[0034] Next, the target sub-table entries are read from the sub-table pointer array, and the fields are compared with the business application type. Matching entries are then filtered. Sub-table 0 stores multiple entries with {business string, exit identifier, index key}. All entries are traversed and the business string field is compared. For the King of Glory search for "game_8", the matching entries are: business string "game_8", exit identifier E1, and entry index key IDX008. For the web search for "web_15", the matching entries are: business string "web_15", exit identifier E0, and entry index key IDX015. Other non-matching business entries are filtered out, and only the valid records corresponding to the current stream are retained. Next, the exit identifier of the hit entry is extracted from the address mapping table to obtain the exit address and read the index key of the entry. The exit identifier E1 is retrieved from the King of Glory hit entry, and the global exit address mapping table is searched to find the China Telecom exit IP address 202.105.8.30, and the index key IDX008 is read simultaneously. The web service exit identifier E0 is retrieved to find the China Mobile default exit address 10.0.0.10, and the index key IDX015 is read. The exit address and index key are cached synchronously for subsequent session verification. Finally, the session record is queried using the index key and a verification value is generated. After successful verification, the egress interface and port mapping configuration items are extracted. The session status record table is queried using the index key IDX008 to retrieve the corresponding session SID=0x0068 and flow ID=F008. The session field is weighted and accumulated to generate a verification value of 0x7291, which is consistent with the built-in verification field of the record. The verification is successful, and the telecom egress physical interface eth1 and port pool 10000-30000 are extracted. The verification value 0x4156 of the index key IDX015 is successfully matched, and the mobile egress interface eth0 and port pool 30001-50000 are extracted. The complete interface and port configuration is output and connected to the uplink packet SNAT conversion process. In this embodiment, the layered hash table lookup combined with session verification reduces the table lookup time and prevents illegal flows from tampering with the diversion rules, ensuring accurate and reliable diversion scheduling.

[0035] In one embodiment, the step of continuously monitoring the transmission status from each network egress to the target server includes: S310: Traverse all available network exits and send probe messages to the transmission path from each network exit to the target server. S311: By probing the message exchange process, synchronously collect the raw transmission status data corresponding to round-trip delay, message loss, and network jitter; S312: The collected raw transmission status data is normalized, and abnormal data information is removed to obtain normalized transmission status data. S313: Classify and collect the standardized transmission status data according to the network exit identifier to form the transmission status record corresponding to each network exit.

[0036] In this embodiment, the overall scenario of PPPoE proxy dialing in the campus network described above continues, inheriting the aforementioned service identification and flow-level redirection table traffic splitting embodiment, and continuing to use a fixed instance configuration: users access the Internet through unified PPPoE proxy dialing by mobile operators, with mobile default exit E0 and telecom premium exit E1; service identifier 8 is Honor of Kings, identifier 12 is Tencent Meeting, and identifier 15 is ordinary web browsing, with the target server IP of Honor of Kings fixed at 180.105.35, maintaining consistent parameters and logical closed-loop continuity between the previous and subsequent instances. First, the system starts a timed link detection mechanism, automatically traversing all available network exits of the campus gateway, namely mobile exit E0 and telecom exit E1, and sending standard probe packets to the target server addresses of core services such as Honor of Kings and Tencent Meeting through the two exit routing paths. The probe packets are encapsulated using a fixed-length protocol, with a single probe duration of 10ms and a batch of 120 probe packets, ensuring full coverage sampling of each transmission path and completely simulating the network transmission link of real service traffic. Throughout the entire process of probe message transmission and reception, three types of raw transmission status data are collected in real time and synchronously: round-trip time (RTT), number of packet loss, and network jitter value for the two exit paths. The RTT, whether there is timeout and packet loss, and the fluctuation range of the message interval for each probe message are recorded continuously. The original sampled data is completely preserved without any prior modification or deletion, providing first-hand experimental evidence for subsequent quality assessment.

[0037] After collecting the raw transmission status data, the gateway data processing unit performs regularization and cleaning on the raw batch data. Through threshold filtering, mean filtering, and outlier removal algorithms, it eliminates invalid sampled data due to sudden network fluctuations, timeouts, and abnormally high or low values. It also filters out distorted data caused by signal interference and instantaneous pulses, retaining valid samples that conform to normal network operation characteristics. This results in standardized, highly reliable regularized transmission status data, preventing abnormal data from interfering with subsequent egress quality scoring results. Finally, using network egress identifiers E0 and E1 as classification indexes, the regularized latency, packet loss, and jitter data are categorized, aggregated, and their mean and steady-state intervals are statistically calculated and structured and stored in the database. This forms dedicated transmission status records for mobile egress E0 and telecom egress E1, respectively. Each record is independently stored at the business target server level, providing standardized and callable link foundation data for subsequent business type weight matching, egress quality assessment, and dynamic updates to the flow-level redirection table. This accurately collects and cleans multi-egress link transmission parameters, eliminates abnormal interference, and provides reliable data support for egress quality scoring and dynamic traffic splitting.

[0038] In one embodiment, the step of assessing export quality based on business application type includes: S320: Read the transmission status records corresponding to each network exit and extract the round-trip delay, packet loss and network fluctuation related status parameters contained in the records; S321: Divide different business application types into categories, query the pre-defined type relationships, and extract the weight configuration data matching each business application type; S322: The extracted transmission status parameters are weighted and calculated with the weight configuration data of the corresponding service application type to obtain the quality assessment data of each network exit. S323: Collect quality assessment data from each network exit, classify exit levels according to preset rules, and generate exit assessment results that can be used for scheduling.

[0039] In this embodiment, the fixed networking scenario of PPPoE dialing in the campus network described above is continued. It follows the previous embodiment of monitoring the transmission status of the exit and maintains complete closed-loop uniformity of the instance parameters: campus users rely on mobile operators for unified PPPoE dialing to access the Internet. The gateway is configured with the default exit E0 for China Mobile and the high-quality exit E1 for China Telecom. Service identifier 8 corresponds to the game Honor of Kings, identifier 12 corresponds to online classes via Tencent Meeting, and identifier 15 corresponds to ordinary web browsing. The target server IP for the Honor of Kings service is 180.105.210.35. The two exit transmission status records that have been collected and organized are used throughout the process to complete the full-dimensional evaluation process of the exit quality. First, the system retrieves the transmission status records from each network egress in the database, reading the organized data from mobile egress E0 and telecom egress E1. From these records, it accurately extracts three core status parameters: Round-Trip Time (RTT), packet loss rate, and network jitter fluctuation. Specifically, the measured RTT for mobile egress E0 is 45ms, the packet loss rate is 2.1%, and the jitter is 18ms; for telecom egress E1, the measured RTT is 12ms, the packet loss rate is 0.2%, and the jitter is 5ms. This complete extraction of quantifiable indicators for calculation provides raw numerical support for quality scoring. Second, the system categorizes applications according to their service experience attributes. For example, Honor of Kings is classified as a real-time game, Tencent Meeting as an audio / video conferencing service, and ordinary web pages as ordinary browsing. The system queries the pre-set service type and weight association configuration in the backend, extracting the weight configuration data for each service type. For latency-sensitive game services, a preset RTT weight of 0.6, a packet loss rate weight of 0.3, and a jitter weight of 0.1 are assigned. Meeting and web page services are also matched with their own exclusive weight ratios, achieving differentiated weight assignment for different services and aligning with actual service transmission requirements.

[0040] The extracted transmission status parameters of each exit are then weighted and fused with the weighted configuration data corresponding to the Honor of Kings service. After normalization, the results are input into the weighting formula to calculate the comprehensive quality assessment scores for mobile exit E0 and telecom exit E1. The smaller the score, the better the link transmission quality, quantifying the performance difference between the two exits under the same service. This transforms discrete latency, packet loss, and jitter indicators into comparable unified quality scores. Finally, the system collects the quality assessment data of all network exits and classifies E0 and E1 exits according to preset score sorting and grading rules. Telecom exit E1 is determined to be the optimal exit for the Honor of Kings service, while mobile exit E0 is the secondary exit. This forms a standardized exit assessment result that can be directly called by the forwarding and scheduling module, providing a decision-making basis for subsequent automatic updates to the flow-level redirection table and triggering flow-level service drift. Differentiated weighted scoring by service type quantifies the exit quality level, providing accurate decision-making basis for intelligent routing and dynamic traffic distribution.

[0041] In one embodiment, the step of synchronously updating the outgoing link relationships in the flow-level redirection table includes: S330: Retrieve the preferred exit identifier for each business application and query the original exit identifier bound to the corresponding business in the flow-level redirection table; S331: Compare the preferred export identifier with the original export identifier. If there is a difference in the identifier, generate an association update trigger instruction. S332: Replace the exit identifier information corresponding to the business in the table according to the update instruction, and generate new mapping association content; S333: Write the changed mapping content to the table store, overwriting the original records, and complete the update of the flow-level redirection table association.

[0042] In this embodiment, the overall application scenario of PPPoE dialing in the campus network described above is continued, and the embodiment of outbound quality assessment is adopted, maintaining a completely unified closed loop of parameters before and after the example: Campus users uniformly access the Internet through PPPoE dialing by mobile operators, and the gateway is equipped with a default mobile outbound E0 and a high-quality telecom outbound E1; Service identifier 8 corresponds to the game Honor of Kings, identifier 12 corresponds to Tencent Meeting online classes, and identifier 15 corresponds to ordinary web browsing. Based on the multi-outbound quality score in the previous step, the preferred outbound identifiers of each service are obtained, and the flow-level redirection table is dynamically updated and adapted in conjunction with the process. First, the system retrieves the preferred outbound identifiers of each service application after weighted scoring from the outbound quality assessment module. Combined with the real-time link quality judgment results, the preferred outbound for Honor of Kings service identifier 8 and Tencent Meeting service identifier 12 are both Telecom outbound E1, and the preferred outbound for ordinary web browsing service identifier 15 is mobile outbound E0; at the same time, the system uses the service identifier as the retrieval primary key to query the original fixed-bound outbound identifiers in the flow-level redirection table, reads the original mapping relationship in the table, confirms the original outbound identifiers of the current service configuration, and forms a two-way comparison data source between preferred outbound and historical configuration data. Secondly, the system compares the preferred exit identifier with the original exit identifier for each service. If the two are completely consistent, it means that there are no changes and no rule update needs to be triggered. If the two identifiers are different, for example, when network fluctuations during peak periods cause a decline in the quality of the telecom exit, or when the preferred exit is switched to the mobile exit E0, the system will generate a relationship update trigger instruction to accurately lock the service items that need to be adjusted, avoid meaningless repeated refreshes and unnecessary table changes, and ensure the stable operation of the traffic diversion rules.

[0043] Next, following the update trigger command, the system locates the table entries that need to be changed, such as service identifier 8 and identifier 12, replaces the original egress identifier field content, modifies the original egress binding relationship to the current optimal egress identifier, and regenerates new mapping associations between service application types and network egress identifiers. Only the corresponding service entries are modified; the original egress mapping for other ordinary web browsing service identifiers, such as 15, remains unchanged, achieving precise and targeted updates without interfering with the global traffic splitting rule architecture. Finally, the system writes the newly generated mapping associations to the fixed storage area of ​​the flow-level redirection table, completing data solidification by overwriting the original historical records. The table takes effect immediately after the update. Subsequent service traffic in the PPPoE proxy link will be retrieved and matched, SNAT address translation, and egress forwarded according to the new mapping relationship. This achieves automatic iteration of the traffic splitting strategy based on changes in link quality, ensuring that highly sensitive services always travel on the optimal egress link. The system automatically updates the traffic splitting mapping based on link quality, adapts to network fluctuations, and ensures that services always prioritize the optimal egress for transmission.

[0044] In one embodiment, the step of establishing a bidirectional NAT binding mapping between the virtual IP and the service session to ensure uninterrupted PPPoE proxy session transmission during network egress switching of the application flow includes: S40: Parse the exit switching command and retrieve the session binding table, extract the application flow identification information, and generate session identification credentials; S41: Retrieve the old egress mapping record from the bidirectional NAT binding table, lock the new egress port resource, and generate a temporary session mapping table entry; S42: Create a new bidirectional NAT mapping entry using virtual IP and service session identifier, and encapsulate the message to generate tunnel transmission data packets; S43: Delete the old exit mapping record and enable the new mapping relationship, and update the forwarding information corresponding to the application flow in the connection tracking table.

[0045] In this embodiment, the first step is to parse the exit switching command and retrieve the session binding table, extract the application flow identifier information, and generate a session identification credential. Continuing the unified closed-loop scenario described earlier: a campus PPPoE dial-up network, with China Mobile's default exit E0 and China Telecom's premium exit E1, service identifier 8 corresponding to Honor of Kings, flow ID=F008, session SID=0x0068, and the terminal's original IP 10.0.0.5. The current service is bound to exit E0. Due to link detection, the latency of E0 is determined to be deteriorating, triggering a switching command. The command carries the old exit identifier E0 and the target new exit identifier E1. After parsing the switching command, the gateway retrieves the global session binding table and extracts the complete set of identifiers for the service flow: Flow ID=F008, Session SID=0x0068, and the 5-tuple (Source 10.0.0.5, Destination 180.105.210.35, Source 51234, Destination 443, TCP). A hash operation is performed on the flow identifier, the 5-tuple, and the Session SID to generate a unique session identification credential HASH_F008=0x5621, which serves as the unique identifier to distinguish the service flow throughout the switching process. The same credential generation logic is used for the switching of the remaining 63 PPPoE sessions, reusing the fixed business parameters mentioned above throughout the process to ensure a unified and closed-loop logic before and after the case. Next, the old egress mapping record in the bidirectional NAT binding table is retrieved, the new egress port resource is locked, a temporary session mapping table entry is generated, and the storage area corresponding to the bidirectional NAT binding table is located based on the old egress identifier E0. The old mapping record matched by HASH_F008 is retrieved: source mapping 10.0.0.5<->192.168.100.58, destination mapping 192.168.100.58<-> mobile egress public network address. The status of the two records is changed to pending migration, and the system timestamp 1762031180002 is written to generate a migration mark. The new egress E1 is parsed, its port bitmap is scanned to lock port 51234 which is consistent with the original port and marked as reserved. The reserved port and session identification credential are bound to generate a temporarily effective session persistence mapping table entry to avoid port conflicts during the handover.

[0046] Next, a new bidirectional NAT mapping entry is created using the virtual IP and the service session identifier. The message is encapsulated to generate a tunnel transmission data packet. The original dedicated virtual IP 192.168.100.58 is used without change. An E1 bidirectional NAT entry is created using the virtual IP and session SID as indexes: the forward mapping is between the terminal 10.0.0.5 and the virtual IP 192.168.100.58, and the reverse mapping is between the virtual IP and the public network address of the telecom exit 202.105.8.30. Based on the new mapping relationship, the telecom exit IP header is encapsulated on the outer layer of the original message to build a tunnel transmission data packet. Both uplink and downlink messages are forwarded across the exit through tunnel encapsulation. The virtual IP remains unchanged throughout the process, and the terminal does not perceive any address change. Next, the old egress mapping record is deleted and the new mapping relationship is enabled. The forwarding information corresponding to the application flow in the connection tracing table is updated. After the switch is completed, all old source and destination NAT mappings under E0 are cleared, E0 port resources are released, and the status of the newly created bidirectional NAT entry on E1 is set to effective. The global connection tracing table is searched to locate the record corresponding to flow ID=F008. The stored egress interface is changed from eth0 to eth1, and the egress public network address is updated to 202.105.8.30. Subsequently, all packets of this service directly match the new forwarding path, completing the smooth switch of the egress. This embodiment relies on bidirectional NAT and tunnel encapsulation to achieve seamless egress switching without interrupting the PPPoE session and ensuring the stability of real-time service transmission.

[0047] In one embodiment, the steps of retrieving the bidirectional NAT binding table to mark the old egress mapping record, locking the new egress port resource, and generating a temporary session mapping table entry include: S410: Parse the old exit identifier carried by the switching command, locate the storage area corresponding to the two-way NAT binding table, and extract the storage index of the application stream to be switched. S411: Retrieve the source and destination address mapping records corresponding to the storage index, compare the flow identifier field, and filter the mapping data that matches the application flow; S412: Adjust the status field of the matching mapping record and write the timestamp information to generate migration marker data for record address and port information; S413: Parse the new exit identifier carried by the switching instruction, retrieve the corresponding address pool port bitmap, and mark the target port as reserved; S414: Bind the reserved port and the application flow session identifier and write them to the storage area to generate a session persistence mapping table entry with temporary effective attributes.

[0048] In this embodiment, the old exit identifier carried by the switching command is parsed first, the corresponding storage area of ​​the bidirectional NAT binding table is located, and the storage index of the application flow to be switched is extracted. Continuing the unified closed-loop scenario in the entire text: the park adopts unified PPPoE dialing by mobile operators, the gateway is configured with mobile exit E0 and high-quality telecom exit E1, the core business King of Glory service identifier is 8, flow ID=F008, session SID=0x0068, the terminal's original internal network IP is 10.0.0.5, the original bearer exit is E0, and due to excessive link latency, an exit switching command is issued. The command contains the old exit identifier E0 and the target new exit identifier E1. The service flow five-tuple is fixed as source 10.0.0.5, destination 180.105.210.35, source port 51234, destination port 443, TCP protocol, and the dedicated virtual IP is 192.168.100.58. The entire set of parameters is completely consistent with the previous identification, diversion, and switching main embodiment, ensuring data interoperability in the overall case. The gateway resolves the switching command and extracts the old egress identifier E0. Based on the egress identifier partition storage rules, it locates the memory storage base address corresponding to E0 in the bidirectional NAT binding table. Using the session identification credential HASH_F008=0x5621 as the search keyword, it searches for matching entries in this storage partition and extracts the storage index STO_ID=0068 corresponding to the Honor of Kings service flow. This index binds all NAT mapping data of the current flow. The remaining 63 PPPoE service flows in the batch all use the same partition addressing and index extraction logic to ensure the uniformity of batch processing rules.

[0049] Next, the source and destination address mapping records corresponding to the storage index are retrieved. The flow identifier field is compared, and mapping data matching the application flow is filtered. Based on the storage index STO_ID=0068, two complete mapping records are read from the E0 partition: Source address mapping record: Internal network 10.0.0.5 <-> Virtual IP 192.168.100.58, with built-in flow identifier F008; Destination address mapping record: Virtual IP 192.168.100.58 <-> E0 mobile public network address, also with built-in flow identifier F008. The built-in flow identifier field of each of the two records is compared with the business flow ID=F008 to be switched. If the fields match perfectly, the two complete mapping records are retained. Mapping records for other flow ID=F015 (web service) and unrelated game flows within the partition are filtered out, accurately locking onto mapping entries belonging only to the current Honor of Kings session, avoiding interference with other normal business traffic during the migration operation. Next, the status field of the matching mapping record is adjusted and timestamp information is written to generate migration marker data for the record address and port information. The status field of the two selected source and destination mapping records is changed from "normally effective" to "pending migration". The current millisecond timestamp of the system (1762031180002) is read and written to the status change field of the two records. All address and port parameters in the records are extracted: internal network source IP 10.0.0.5, virtual IP 192.168.100.58, original egress public network address, and source port 51234. All parameters are integrated to generate exclusive migration marker data. The marker data is bound to the storage index STO_ID=0068 as a certificate for releasing the old egress resources in the future, distinguishing between normal mapping and mapping to be migrated, and preventing the old mapping from being accidentally deleted in advance during the switchover process.

[0050] Next, the new exit identifier carried by the switching instruction is parsed, the corresponding address pool port bitmap is retrieved, the target port is marked as reserved, the new exit identifier E1 is obtained by parsing the switching instruction, the storage area of ​​the dedicated address pool port bitmap for telecom exit E1 is located, the bitmap stores the occupancy status by port number and bit. In this case, the original source port 51234 of the service needs to be retained. The bit corresponding to 51234 is retrieved from the bitmap. The original value of this bit is 0, which means it is idle. The bit is modified to 1, and the port is marked as reserved and locked. During the locking period, this port will not be allocated to any other service flow to avoid multiple flows competing for the same port during the switching, which will cause packet disorder. The port bitmap change is written to memory in real time and takes effect. Finally, the reserved port and application flow session identifier are bound and written to the storage area, generating a session persistence mapping entry with temporary validity. All fields of the reserved port 51234, flow ID=F008, session SID=0x0068, session credential HASH_F008, and virtual IP 192.168.100.58 are bound and encapsulated into an independent entry and stored in the temporary session mapping storage area. The entry validity flag is set to "temporarily valid". This temporary entry is only valid during the egress switching window and will automatically expire and be destroyed after the new NAT mapping is stable after the switch is completed. It fully undertakes the overall process of the upper-layer egress switching and forms a closed loop with DPI / DFI service identification, double-layer hash flow distribution table, and link quality assessment module. In this embodiment, the old mapping mark and new port locking are completed step by step, and the temporary entry is used to ensure that the session is not interrupted during the switching window and avoid port resource conflicts.

[0051] refer to Figure 2 The second aspect of this application also proposes a PPPoE caller ID-based fine-grained traffic splitting system based on DPI or DFI identification, comprising: The service identification module 100 is used to collect network traffic packets in PPPoE dialing scenarios, perform DPI feature code matching and DFI flow behavior analysis respectively, and determine the service application type corresponding to each packet by fusing the identification results. The flow mapping and forwarding module 200 is used to pre-configure a flow-level redirection table, retrieve the flow-level redirection table according to the service application type, perform source address translation on the uplink packets of the matching application flow, and redirect them to the corresponding network egress. The exit assessment and update module 300 is used to continuously monitor the transmission status from each network exit to the business target server, assess the exit quality in combination with the business application type, and synchronously update the exit association relationship in the flow-level redirection table. The Session Keep-alive Module 400 is used to establish a two-way NAT binding mapping between the virtual IP and the service session when the application flow switches network exits, so as to keep the PPPoE dial-up session transmission uninterrupted.

[0052] Reference Figure 3This application also provides a computer device, which may be a server, and its internal structure may be as follows: Figure 3 As shown, this computer device includes a processor, memory, network interface, and database connected via a bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores operations, computer programs, and the database. The internal memory provides an environment for the operation and execution of the computer programs stored in the non-volatile storage media. The database stores data such as PPPoE dialing flow-level fine-tuning methods based on DPI or DFI identification. The network interface is used for communication with external terminals via a network connection. When executed by a processor, this computer program implements a fine-grained PPPoE dial-up traffic splitting method based on DPI or DFI identification, including the following steps: collecting network traffic packets in a PPPoE dial-up scenario, performing DPI signature matching and DFI flow behavior analysis respectively, and fusing the identification results to determine the service application type corresponding to each packet; pre-configuring a flow-level redirection table, retrieving the flow-level redirection table according to the service application type, performing source address translation on the matching application flow uplink packets and redirecting them to the corresponding network egress; continuously monitoring the transmission status from each network egress to the service target server, assessing the egress quality in conjunction with the service application type, and synchronously updating the egress association relationship in the flow-level redirection table; and establishing a bidirectional NAT binding mapping between the virtual IP and the service session when the application flow switches network egress to ensure uninterrupted PPPoE dial-up session transmission.

[0053] One embodiment of this application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements a PPPoE proxy dialing flow-level fine-grained traffic splitting method based on DPI or DFI identification, including the following steps: collecting network traffic packets in a PPPoE proxy dialing scenario, performing DPI feature code matching and DFI flow behavior analysis respectively, and fusing the identification results to determine the service application type corresponding to each packet; pre-configuring a flow-level redirection table, retrieving the flow-level redirection table according to the service application type, performing source address translation on the matching application flow uplink packets and redirecting them to the corresponding network exit; continuously monitoring the transmission status from each network exit to the service target server, performing exit quality assessment in conjunction with the service application type, and synchronously updating the exit association relationship in the flow-level redirection table; and establishing a bidirectional NAT binding mapping between the virtual IP and the service session when the application flow switches network exits to ensure uninterrupted PPPoE proxy dialing session transmission.

[0054] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other media provided in this application and used in the embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-speed SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0055] The above description is only a preferred embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural changes made based on the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for fine-grained PPPoE dialing based on DPI or DFI identification, characterized in that, include: Collect network traffic packets in PPPoE dialing scenarios, perform DPI signature matching and DFI flow behavior analysis respectively, and determine the service application type corresponding to each packet by fusing the identification results. A flow-level redirection table is pre-configured. The flow-level redirection table is retrieved according to the service application type. The source address of the matching application flow uplink packets is translated and redirected to the corresponding network egress. Continuously monitor the transmission status from each network egress to the target server, assess the egress quality based on the business application type, and synchronously update the egress association in the flow-level redirection table. When the application stream switches network exits, a two-way NAT binding mapping is established between the virtual IP and the service session to ensure that the PPPoE proxy session transmission is not interrupted.

2. The PPPoE caller ID-based fine-tuning method for PPPoE caller ID based on DPI or DFI identification as described in claim 1, characterized in that, The steps of collecting network traffic packets in the PPPoE dialing scenario, performing DPI signature matching and DFI flow behavior analysis respectively, and fusing the identification results to determine the service application type corresponding to each packet include: Capture the original packets of the PPPoE proxy network, extract the packet session identifier and transmission port information, and generate the original packet sequence with timestamps; The original message sequence is subjected to 5-tuple hash grouping processing to divide the data stream and query the port mapping relationship to generate primary application category labels; Extract the message payload and flow behavior information of the data stream, perform feature code comparison and flow behavior matching respectively, and generate a combined judgment record; The matching indicators in the combined judgment record are read, weighted, and matched against a preset threshold range to determine the business application type corresponding to the message.

3. The PPPoE caller ID-based fine-tuning method for PPPoE caller ID based on DPI or DFI identification as described in claim 1, characterized in that, The steps of retrieving the pre-configured flow-level redirection table based on the service application type, performing source address translation on the matching application flow uplink packets, and redirecting them to the corresponding network egress include: Parse the application and egress mapping configuration and collect egress transmission parameters to generate an initial mapping table stored in a hash structure; A two-layer hash structure stream-level redirection table is built based on the initial mapping table, and the table entry index key is bound to the session state record; Calculate the hash value of the business application type to retrieve the flow-level redirection table and extract the matching egress interface and port configuration items; Extract the uplink packet's 5-tuple, assign a virtual address and port, replace the packet's source address, set a routing tag, and forward the packet to the corresponding network exit.

4. The PPPoE caller ID-based fine-tuning method for PPPoE caller ID based on DPI or DFI identification according to claim 3, characterized in that, The steps for retrieving the hash value from the flow-level redirection table of the computing service application type and extracting the matching egress interface and port configuration items include: Perform byte operations on strings of business application type to generate corresponding base hash values; Retrieve the sub-table configuration of the stream-level redirection table, calculate the base hash value to obtain the sub-table index number, and access the sub-table pointer array; Read the target sub-table entries from the sub-table pointer array, compare the fields with the business application type, and filter the matching entries. Extract the exit identifier of the matched entry from the address mapping table, obtain the exit address, and read the index key of the entry. Use the index key to query the session record and generate a verification value. After the verification is successful, extract the outgoing interface and port mapping configuration items.

5. The PPPoE caller ID-based fine-tuning method for PPPoE caller ID based on DPI or DFI identification according to claim 1, characterized in that, The step of continuously monitoring the transmission status from each network egress to the target server includes: Traverse all available network exits and send probe messages to the transmission path from each network exit to the target server. By probing the message exchange process, the original transmission status data corresponding to round-trip delay, message loss, and network jitter are collected synchronously. The collected raw transmission status data is normalized and abnormal data is removed to obtain normalized transmission status data. The standardized transmission status data is classified, collected, and stored according to the network exit identifier, forming a transmission status record corresponding to each network exit.

6. The PPPoE caller ID-based fine-tuning method for PPPoE caller ID based on DPI or DFI identification according to claim 1, characterized in that, The steps for assessing export quality based on business application type include: Read the transmission status records corresponding to each network exit and extract the round-trip time, packet loss and network fluctuation related status parameters contained in the records; Divide into different business application types, query the pre-defined type relationships, and extract the weight configuration data matching each business application type; The extracted transmission status parameters are weighted and calculated with the weight configuration data of the corresponding service application type to obtain the quality assessment data of each network exit. Collect quality assessment data from each network exit, classify exit levels according to preset rules, and generate exit assessment results that can be selected for scheduling.

7. The PPPoE caller ID-based fine-tuning method for PPPoE caller ID based on DPI or DFI identification according to claim 1, characterized in that, The step of synchronously updating the outgoing link relationships in the flow-level redirection table includes: Retrieve the preferred exit identifiers for each business application and query the original exit identifiers bound to the corresponding business in the flow-level redirection table; Compare the preferred export identifier with the original export identifier; if there is a difference in the identifier, generate an association update trigger instruction. Replace the exit identifier information corresponding to the business in the table according to the update instructions, and generate new mapping and association content; Write the changed mapping content to Table Store, overwriting the original records, and complete the update of the flow-level redirection table association.

8. The PPPoE caller ID-based fine-tuning method for PPPoE caller ID based on DPI or DFI identification according to claim 1, characterized in that, The step of establishing a bidirectional NAT binding mapping between the virtual IP and the service session to ensure uninterrupted PPPoE proxy session transmission during network egress switching of the application flow includes: Parse the exit switching command and retrieve the session binding table to extract application flow identification information and generate session identification credentials; Retrieve the old egress mapping record from the bidirectional NAT binding table, lock the new egress port resource, and generate a temporary session mapping table entry; A new bidirectional NAT mapping entry is created using a virtual IP address and a service session identifier, and packets are encapsulated to generate tunnel transmission data packets. Delete the old exit mapping record and enable the new mapping relationship, and update the forwarding information corresponding to the application flow in the connection tracking table.

9. The PPPoE caller ID-based fine-tuning method for PPPoE caller ID based on DPI or DFI identification as described in claim 8, characterized in that, The steps of retrieving the old egress mapping record from the bidirectional NAT binding table, locking the new egress port resource, and generating a temporary session mapping table entry include: Parse the old exit identifier carried in the switching command, locate the storage area corresponding to the two-way NAT binding table, and extract the storage index of the application stream to be switched; Retrieve the source and destination address mapping records corresponding to the storage index, compare the flow identifier field, and filter the mapping data that matches the application flow; Adjust the status field of the matching mapping record and write the timestamp information to generate migration marker data with record address and port information; Parse the new exit identifier carried by the switching instruction, retrieve the corresponding address pool port bitmap, and mark the target port as reserved; Bind the reserved port and the application stream session identifier and write them to the storage area to generate a session persistence mapping table entry with temporary effective attributes.

10. A PPPoE dial-up fine-grained splitting system based on DPI or DFI identification, characterized in that, include: The service identification module is used to collect network traffic packets in PPPoE dialing scenarios, perform DPI feature code matching and DFI flow behavior analysis respectively, and fuse the identification results to determine the service application type corresponding to each packet. The flow mapping and forwarding module is used to pre-configure the flow-level redirection table, retrieve the flow-level redirection table according to the service application type, perform source address translation on the uplink packets of the matching application flow, and redirect them to the corresponding network egress. The exit assessment and update module is used to continuously monitor the transmission status from each network exit to the target server, assess the exit quality in combination with the business application type, and synchronously update the exit association relationship in the flow-level redirection table. The session keep-alive module is used to establish a two-way NAT binding mapping between the virtual IP and the service session when the application flow switches network exits, so as to keep the PPPoE dial-up session transmission uninterrupted.

Images