A gateway-side intelligent acceleration system and method

Abstract

The application relates to the technical field of gateway acceleration, and discloses a gateway-end intelligent acceleration system and method, which comprises the following steps: selecting multiple edge nodes according to the geographical position coordinates of a gateway and establishing a pre-connection edge node channel; matching in-coming data packets of the gateway with a game feature library to obtain a local traffic recognition result and generate game traffic marked with a priority level together with application type labels returned by an operator DPI device; calculating an end-to-end forwarding path from the edge nodes of the pre-connection edge node channel, encapsulating the path into a routing instruction message, and delivering the message to the gateway; and creating a layered token bucket queue in the gateway and forwarding the game traffic marked with the priority level according to the end-to-end forwarding path specified by the routing instruction message. The application establishes a pre-connection channel mechanism between the gateway and the edge nodes of the operator, so that the connection does not need to be re-established when a game is started, the delay of cross-region server switching is reduced, and the smoothness of the user game experience is improved.

Description

Technical Field

[0001] This invention relates to the field of gateway acceleration technology, and in particular to a gateway-side intelligent acceleration system and method. Background Technology

[0002] With the rapid development of esports and cloud gaming industries, game acceleration has become a core value-added service for home networks. Operators face significant technical challenges in deploying game acceleration across tens of millions of gateway devices. Existing game acceleration solutions are optimized for individual consumer routers, failing to consider the hardware heterogeneity of operator-customized gateways. This results in low compatibility and insufficient stability during large-scale deployments. Furthermore, the single-machine acceleration mode at the gateway end lacks a collaborative mechanism with the operator's core network and edge computing nodes, leading to high latency when switching between game servers in different regions due to the need for route re-detection. Summary of the Invention

[0003] This invention provides a gateway-side intelligent acceleration system and method. By establishing a pre-connection channel mechanism between the gateway and the operator's edge node, this invention eliminates the need to re-establish a connection when the game starts, reducing the latency of cross-regional server switching and improving the smoothness of the user's gaming experience.

[0004] The first aspect of this invention provides a gateway-side intelligent acceleration method, the gateway-side intelligent acceleration method comprising: Select multiple edge nodes based on the gateway's geographical coordinates and establish pre-connected edge node channels; The incoming data packets of the gateway are matched with the game feature database to obtain the local traffic identification result, and the game traffic with priority level is generated based on the local traffic identification result and the application type label returned by the operator's DPI device. Calculate the end-to-end forwarding path from the edge node of the pre-connected edge node channel, and encapsulate the end-to-end forwarding path into a routing instruction message and send it to the gateway. The gateway creates a hierarchical token bucket queue and forwards the game traffic marked with priority levels according to the end-to-end forwarding path specified in the routing instruction message.

[0005] In conjunction with the first aspect, in a first implementation of the first aspect of the present invention, before selecting multiple edge nodes based on the geographical coordinates of the gateway and establishing a pre-connected edge node channel, the method further includes: Call the Linux kernel interface to read the cpuinfo file to obtain the CPU model, parse the meminfo file to extract the memory capacity, execute system commands to obtain the firmware version, and query network interface nodes to obtain the network interface speed; The CPU model, memory capacity, firmware version, and network port speed are combined to generate a hardware fingerprint; The hardware fingerprint is queried against the local driver adaptation database to obtain the CPU architecture type, and the corresponding driver configuration file is loaded according to the CPU architecture type. Based on the driver configuration file, a resource control group is created through the cgroup subsystem and bound to the acceleration program process. According to the memory capacity and the number of CPU cores, the memory quotas for fixed cache and elastic cache are set, and the CPU quotas for computing power usage percentage are set to obtain resource quota parameters.

[0006] In conjunction with the first aspect, in a second implementation of the first aspect of the present invention, selecting multiple edge nodes based on the geographical coordinates of the gateway and establishing pre-connected edge node channels includes: The distance between each edge node in the operator's edge computing platform and the gateway is calculated based on the gateway's geographical coordinates, and a comprehensive score is calculated by combining the CPU load rate, bandwidth utilization rate and number of access devices of each edge node. Based on the comprehensive score, multiple edge nodes are selected as pre-connection targets; A TCP connection request with TLS encryption protocol is initiated to the edge node of the pre-connected target and a long connection is established. After the long connection is established, a heartbeat probe message is sent to monitor the round-trip delay and obtain the pre-connected edge node channel.

[0007] In conjunction with the first aspect, in a third implementation of the first aspect of the present invention, the incoming data packets of the gateway are matched with a game feature database to obtain a local traffic identification result, and game traffic with priority levels is generated based on the local traffic identification result and the application type tag returned by the operator's DPI device, including: By registering hook functions in the PREROUTING chain using the netfilter framework, incoming data packets can be intercepted, and the five-tuple information of source IP address, destination IP address, source port number, destination port number, and protocol type, as well as the application layer signature of the load area, can be extracted. The five-tuple information and application layer feature code are matched with the IP address range, port number range and feature code hash value of the game feature library to obtain the local traffic identification result; The system sends a query request for the incoming data packet to the operator's DPI device via the GTP-U tunnel protocol and receives the returned application type label. Based on the application type label and the local traffic identification result, it determines the priority level of the game traffic.

[0008] In conjunction with the first aspect, in the fourth implementation of the first aspect of the present invention, a query request for the incoming data packet is sent to the operator's DPI device via the GTP-U tunnel protocol and the returned application type tag is received. Based on the application type tag and the local traffic identification result, the priority level of the game traffic is determined, including: The gateway sends a traffic label query request for the incoming data packet to the operator's DPI device in the metropolitan area network aggregation layer via the GTP-U tunnel protocol between the gateway and the operator's core network, and receives the application type label returned by the operator's DPI device. Determine whether the application type label and the local traffic identification result both point to the game type and whether the confidence level is higher than a preset threshold. If the determination result is yes, confirm that the inbound data packet is game traffic. The priority level is determined based on the game type corresponding to the game traffic, and the DSCP value corresponding to the priority level is written into the TOS field of the IP header of the game traffic to obtain the game traffic with the priority level marked.

[0009] In conjunction with the first aspect, in a fifth implementation of the first aspect of the present invention, calculating an end-to-end forwarding path starting from the edge node of the pre-connected edge node channel, and encapsulating the end-to-end forwarding path into a routing instruction message and sending it to the gateway, includes: The candidate AS path from the gateway to the game server is queried in the BGP routing table. The edge nodes in the pre-connected edge node channel are used as the starting point for node expansion. The actual cumulative cost and the heuristic estimated cost are calculated as the cost function value based on the weighted sum of the latency, packet loss rate and jitter value of the link between backbone nodes. The backbone node with the smallest cost function value is selected to backtrack the predecessor path to generate an end-to-end forwarding path, and the end-to-end forwarding path is encapsulated into a routing instruction message and sent to the gateway.

[0010] In conjunction with the first aspect, in the sixth implementation of the first aspect of the present invention, the candidate AS path from the gateway to the game server is queried in the BGP routing table, and node expansion is performed starting from the edge nodes in the pre-connected edge node channel. The actual cumulative cost and the heuristically estimated cost are weighted and calculated as the cost function value based on the latency, packet loss rate, and jitter values ​​of the links between backbone nodes. This includes: Query the BGP routing table for candidate AS paths from the gateway to the game server; A priority queue is created using the edge nodes in the pre-connected edge node channel as the starting point to store the backbone nodes to be expanded. Each time, the node with the smallest cost function value is taken from the priority queue for expansion. The actual cumulative cost is calculated by weighting the latency, packet loss rate and jitter values ​​of each link for the expanded backbone node, and the heuristic cost estimate is obtained by dividing the geographical straight-line distance from the backbone node to be expanded to the game server by the light speed propagation delay. The actual cumulative cost is added to the heuristically estimated cost to obtain the cost function value. Adjacent backbone nodes are added to the priority queue and their predecessor paths are recorded.

[0011] In conjunction with the first aspect, in the seventh implementation of the first aspect of the present invention, the creation of a hierarchical token bucket queue at the gateway and forwarding the game traffic marked with priority levels according to the end-to-end forwarding path specified by the routing instruction message includes: Within the computing power quota range defined by the resource quota parameters, a hierarchical token bucket queue is created through the flow control subsystem; According to the routing instruction message, a high-priority static route entry is inserted into the local routing table of the gateway, and the game traffic marked with priority level is forwarded to the corresponding token bucket queue according to the end-to-end forwarding path specified by the static route entry.

[0012] In conjunction with the first aspect, in the eighth implementation of the first aspect of the present invention, after forwarding according to the end-to-end forwarding path specified by the routing instruction message, it further includes: The CPU utilization, memory usage, game traffic latency, and packet loss rate of the gateway are encapsulated into monitoring messages and reported to the cloud time-series database through the operator management channel; Calculate the historical data mean and historical data standard deviation in the cloud time-series database, generate an anomaly alarm work order based on the historical data mean and historical data standard deviation, and push it to the operation and maintenance system; The game's server IP address range, port number, and signature code are extracted from the game developer's official channels to generate an incremental signature database update package. The incremental signature database update package is pushed to the gateway using P2P fragmentation transmission technology, and a dual-partition backup upgrade is performed. After the upgrade is completed, the game signature database of the gateway is updated.

[0013] A second aspect of the present invention provides a gateway-side intelligent acceleration system, the gateway-side intelligent acceleration system comprising: The module is used to select multiple edge nodes based on the geographical coordinates of the gateway and establish pre-connected edge node channels; The traffic identification module is used to match the incoming data packets of the gateway with the game feature library to obtain the local traffic identification result, and generate game traffic with priority level based on the local traffic identification result and the application type tag returned by the operator's DPI device. The calculation module is used to calculate the end-to-end forwarding path from the edge node of the pre-connected edge node channel, and encapsulate the end-to-end forwarding path into a routing instruction message and send it to the gateway. The forwarding module is used to create a hierarchical token bucket queue on the gateway and forward the game traffic marked with priority levels according to the end-to-end forwarding path specified by the routing instruction message.

[0014] Compared to existing technologies, this invention establishes a pre-connection channel mechanism between the gateway and the operator's edge nodes, eliminating the need to re-establish connections upon game startup. This reduces latency during cross-regional server switching and improves the smoothness of the user's gaming experience. A dual-fusion judgment mechanism, employing local game feature library matching and operator DPI device application type tags, enhances the accuracy of game traffic identification and avoids bandwidth waste caused by misjudgments. Based on the pre-connection edge nodes, it fully utilizes the operator's backbone network topology and real-time link quality data to calculate the end-to-end forwarding path with the lowest latency and optimal stability, ensuring low-latency transmission of game data packets. Hardware fingerprinting and driver pool matching mechanisms achieve full coverage adaptation to various customized gateway models from different operators. Combined with the dynamic quota allocation strategy of the resource control group, the resource consumption of the acceleration program is controlled within a reasonable range, avoiding resource competition with basic network services and ensuring the overall stability of the gateway system. The combined application of hierarchical token bucket queues and weighted random early detection algorithms ensures priority protection and fair scheduling of game traffic in multi-service concurrent scenarios. By adopting a feature library update mechanism that uses P2P fragmented transmission and dual-partition backup upgrades, the update cycle for tens of millions of devices is shortened, reducing the operation and maintenance costs and fault response time for large-scale deployments. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] The structures, proportions, sizes, etc., shown in the accompanying drawings of this specification are only for the purpose of assisting those skilled in the art in understanding and reading the content disclosed in the specification, and are not intended to limit the conditions under which the present invention can be implemented. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size, without affecting the effects and objectives that the present invention can produce, should still fall within the scope of the technical content disclosed in the present invention.

[0017] Figure 1This is a flowchart illustrating the gateway-side intelligent acceleration method provided in an embodiment of the present invention; Figure 2 This is a diagram of a three-level collaborative intelligent acceleration system architecture for large-scale deployment by operators, provided by an embodiment of the present invention. Figure 3 This is a timing diagram of game latency changes under the cloud-based predictive switching mechanism provided in this embodiment of the invention; Figure 4 This is a schematic block diagram of the gateway-side intelligent acceleration system provided in an embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the order described. For example, some operations / steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0020] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0021] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items, and all possible combinations, and includes such combinations. See also Figure 1 One embodiment of the gateway-side intelligent acceleration method in this invention includes: Step 100: Select multiple edge nodes based on the geographical coordinates of the gateway and establish pre-connected edge node channels; Step 200: Match the incoming data packets of the gateway with the game feature database to obtain the local traffic identification result, and generate game traffic with priority level based on the local traffic identification result and the application type label returned by the operator's DPI device. Step 300: Calculate the end-to-end forwarding path starting from the edge node of the pre-connected edge node channel, and encapsulate the end-to-end forwarding path into a routing instruction message and send it to the gateway; Step 400: Create a hierarchical token bucket queue on the gateway and forward the game traffic marked with priority levels according to the end-to-end forwarding path specified in the routing instruction message.

[0022] Figure 2 This is a three-tiered collaborative intelligent acceleration system architecture diagram for large-scale deployment by operators, consisting of three layers: cloud-based collaborative acceleration platform, edge computing node layer, and gateway device layer. The cloud platform includes a BGP routing table database for storing backbone network topology information, a path planning engine that executes an improved A* algorithm to calculate the optimal forwarding path, a distributed monitoring module that performs anomaly detection based on a time-series database and the 3σ principle, a link quality monitoring module that collects latency, packet loss, and bandwidth data in real time, a P2P distribution network responsible for updating and pushing feature databases, a traffic intelligent scheduling module that performs business priority management, and carrier DPI devices that provide an L7 layer application type label resolution interface. The edge computing node layer displays edge node 1, edge node 2, and edge node 3 selected by Euclidean distance calculation and comprehensive load scoring. The nodes maintain connection status through a 1-second heartbeat probe. The gateway device layer includes gateway devices of different hardware models (Gateway 1 uses the MT7621 chip, Gateway 2 uses the IPQ5018 chip, and other gateway models). Each gateway has built-in modules such as hardware fingerprint recognition, cgroup resource isolation, game traffic recognition, and HTB queue scheduling, connecting home terminal devices such as game consoles, mobile phones, and IPTV, demonstrating the collaborative working mechanism between tens of millions of gateway devices and the cloud platform.

[0023] In one specific embodiment, before selecting multiple edge nodes based on the geographical coordinates of the gateway and establishing pre-connected edge node channels, the method further includes: Call the Linux kernel interface to read the cpuinfo file to obtain the CPU model, parse the meminfo file to extract the memory capacity, execute system commands to obtain the firmware version, and query network interface nodes to obtain the network interface speed; By combining the CPU model, memory capacity, firmware version, and network port speed, a hardware fingerprint can be generated. The hardware fingerprint is queried against the local driver adaptation database to obtain the CPU architecture type, and the corresponding driver configuration file is loaded according to the CPU architecture type. Based on the driver configuration file, a resource control group is created through the cgroup subsystem and bound to the acceleration program process. The memory quotas for fixed cache and elastic cache are set according to the memory capacity and the number of CPU cores, and the CPU quotas for the percentage of computing power usage are set to obtain the resource quota parameters.

[0024] Specifically, after the gateway powers on, it calls the standard interface provided by the Linux kernel to read the ` / proc / cpuinfo` file sequentially to obtain the CPU model identifier and extract the specific chip model corresponding to the "model name" field. It parses the "MemTotal" field in the ` / proc / meminfo` file to extract the byte value of the physical memory capacity and converts it to MB. It then uses the `uname -a` system command to obtain the current system kernel version and firmware version strings as firmware environment identifiers. Simultaneously, it queries the ` / sys / class / net / eth0 / speed` node to read the actual connection speed of the main network interface (e.g., "1000" represents a gigabit network interface), thus obtaining the network interface performance parameters. The CPU model, memory capacity, firmware version, and network interface speed are combined in a fixed order into a string and a unique 32-byte hardware fingerprint hash value is calculated using a standard hash algorithm (such as SHA-256), uniquely identifying the hardware environment characteristics of the current gateway device. The hardware fingerprint is matched against a driver adaptation database stored locally in the accelerator program's path. This database pre-defines the mapping between hardware fingerprints and driver configuration files for over 100 carrier-customized router models. Each configuration file contains information on optimized instruction modules required for a specific CPU architecture; for example, the MT7621 model for MIPS architecture includes an assembly-level optimized forwarding module, while the Qualcomm IPQ series for ARM architecture loads the corresponding NEON instruction set enhancement module. Once a matching hardware fingerprint is successfully found and its CPU architecture type is determined, the corresponding driver configuration file is loaded, and the driver module initialization and mounting process is completed. The Linux cgroup (controlgroup) subsystem is started according to the resource quota policy in the configuration file, and an independent resource control group is created based on a predefined resource control template in the kernel space. This resource control group is dedicated to constraining the accelerator program's runtime resources. The accelerator program's main process is attached to this control group via a task binding mechanism, and specific memory and CPU quotas are set based on the currently detected physical memory capacity and the number of CPU cores.For memory quotas, when the total memory capacity is greater than or equal to 128MB, a fixed cache area of ​​32MB is allocated to the acceleration program for loading static data such as game feature libraries and storage path routing tables. This memory page is locked using the mlock system call to prevent it from being swapped to disk. Simultaneously, a 16MB elastic cache area is configured to handle sudden bursts of high-speed game traffic. This elastic area can be dynamically requested and released based on usage. For CPU quotas, when the system is detected to be dual-core or lower, the acceleration program is bound to the first core using cpuset, and the cpu.cfs_quota_us parameter limits its maximum usage of that core's computing power to 15%. If the device is detected to be quad-core or higher, the program is allowed to dynamically migrate between multiple cores, but the total computing power usage limit is no more than 10%. All the above resource quota parameters are integrated into a JSON structured data format after the driver is loaded and sent to the cloud management platform via an initialization message.

[0025] In one specific embodiment, the process of performing step 100 may specifically include the following steps: The distance between each edge node in the operator's edge computing platform and the gateway is calculated based on the gateway's geographical coordinates, and a comprehensive score is calculated by combining the CPU load rate, bandwidth utilization rate and number of access devices of each edge node. Multiple edge nodes were selected as pre-connection targets based on comprehensive scoring. Initiate a TCP connection request with TLS encryption protocol to the edge node of the pre-connected target and establish a long connection. After the long connection is established, send heartbeat probe messages to monitor round-trip latency and obtain the pre-connected edge node channel.

[0026] Specifically, after completing local hardware adaptation and resource quota configuration, the device registration process is initiated to the cloud-based collaborative acceleration platform through the management channel. The registration message carries the gateway's geographical location information, which is pre-configured in the database by the operator before the device leaves the factory and obtained through the mapping relationship between MAC address and physical installation address. The cloud platform calls the edge node resource database, which maintains in real-time multi-dimensional indicators such as the operating status, location coordinates, current CPU load rate, bandwidth utilization, and total number of connected devices of edge nodes nationwide, performing the edge node screening and scoring process. Using the Euclidean distance calculation model, the straight-line distance between the gateway's latitude and longitude coordinates and the coordinates of each operator's edge node is calculated, and the distance results for all nodes are normalized to obtain a distance normalization score. The CPU load rate of each node is reverse-processed to calculate "1 - load rate" to reflect the node's idle computing capacity. Simultaneously, the network bandwidth utilization is subjected to the same reverse normalization operation to obtain the available bandwidth factor "1 - utilization rate". The total number of connected devices is normalized into a "device density factor" to assess the current connection pressure of the nodes. By combining these dimensions, a weighted scoring formula is constructed, for example, Node Comprehensive Score = (1-Distance)×0.4 + (1-CPU Load Rate)×0.3 + (1-Bandwidth Utilization)×0.2 + (1-Access Device Normalization Value)×0.1, forming an indicator model to measure the current adaptability of each node. The cloud platform sorts all available edge nodes according to their comprehensive scores and selects several nodes with the highest scores (e.g., 3) as pre-connection target nodes. The platform encapsulates the target node's IP address, access port, TLS encryption key, and session token into a standardized node information packet and pushes it to the target gateway device through a dedicated operator management channel. After receiving the node information, the gateway initiates encrypted TCP connection requests based on the TLS 1.3 protocol to each target edge node. During the TLS handshake, the public key allocated by the cloud platform is used for authentication and key exchange to ensure the integrity, confidentiality, and anti-hijacking capability of the connection channel. After each connection is successfully established, a long connection state is maintained locally, and a standard format heartbeat probe packet is immediately sent to each edge node, with the heartbeat period set to 1 second. The Round Trip Time (RTT) during the heartbeat message round trip is continuously recorded and used as a core indicator of connection quality. The actual network latency characteristics of each edge node's current connection path are calculated using the RTT of each round trip. Simultaneously, the gateway records the RTT value along with other metrics such as connection establishment time, TLS handshake time, and connection retransmission rate, and periodically reports this data to the cloud platform. This data is used to dynamically adjust edge node scheduling strategies or issue early warnings of connection switching. Multiple TLS-encrypted long-lived connections established within the gateway, along with their corresponding RTT monitoring mechanisms, collectively constitute the pre-connected edge node channel.

[0027] After obtaining the pre-connected edge node channel, the process also includes: continuously sending heartbeat probe messages to each edge node through the pre-connected edge node channel, collecting the round-trip time (RTT), packet loss rate, and jitter value of each edge node, and storing the RTT, packet loss rate, and jitter values ​​in a local buffer according to time series; calculating a weighted health score for each edge node based on the RTT, packet loss rate, and jitter values ​​within the most recent time window in the local buffer, where the weights for RTT, packet loss rate, and jitter are set to different values ​​to obtain the real-time health score for each edge node; and determining the current primary edge node. If the real-time health score is lower than the preset health threshold, and the result is yes, the node with the highest health score is selected from the backup edge nodes of the pre-connected edge node channel as the new primary node; a connection activation command is sent to the new primary node and the forwarding target of game traffic is switched from the original primary edge node to the new primary node; after the traffic switch is completed, the TCP long connection of the original primary edge node is disconnected, and the updated pre-connected edge node channel configuration is obtained; the edge node switching event, the original primary node fault information and the new primary node information are encapsulated into a node switching message and reported to the cloud collaborative acceleration platform for recording through the operator management channel.

[0028] In one specific embodiment, the process of performing step 200 may specifically include the following steps: By registering hook functions in the PREROUTING chain using the netfilter framework, incoming data packets can be intercepted, and the five-tuple information of source IP address, destination IP address, source port number, destination port number, and protocol type, as well as the application layer signature of the load area, can be extracted. The quintuple information and application layer signature are matched with the IP address range, port number range, and signature hash value of the game signature database to obtain the local traffic identification result; The system sends a query request for inbound data packets to the operator's DPI device via the GTP-U tunnel protocol and receives the returned application type label. Based on the application type label and the local traffic identification result, it determines the priority level of the game traffic.

[0029] Specifically, all inbound data packets are intercepted and parsed in real time at the gateway level. After the acceleration program starts, it utilizes the Linux kernel's netfilter framework to register a high-priority hook function in the PREROUTING chain. This hook function is triggered before the data packet enters the routing decision logic, intercepting the raw, unprocessed inbound data stream. Whenever a data packet passes through the hook function, the program extracts the packet's five-tuple information: source IP address, destination IP address, source port number, destination port number, and transport layer protocol type (TCP or UDP). This information forms the basic identifier for traffic identification. The program extracts the first 64 bytes of payload content from the packet's payload area, which includes the initial interaction fields of the L7 layer application protocol. By hashing or extracting the signature from this content, a content signature representing the application characteristics is extracted. The acceleration program combines the above five-tuple information and payload signature to construct a local identification query object, and then matches and compares this local identification query object with a locally pre-built game feature database. The game feature database stores communication feature information for thousands of mainstream games. Each entry includes one or more sets of server IP address ranges, communication port ranges, and hash values ​​of application layer feature codes. For example, for a certain MOBA game, the entry includes fields such as destination address range 113.96.0.0 / 16, port number range 8000~9000, and payload feature codes 0x78 0x9A 0xBC. When the source-destination address and port number of a data packet both fall within the specified range and the payload feature code matches the preset hash value, it is determined to be suspected game traffic, and a preliminary local identification result is generated. Based on a deep traffic identification mechanism that interacts with the operator's core network, a data packet query request is sent to the DPI (Deep Packet Inspection) system deployed at the operator's metropolitan area network layer via the GTP-U tunnel protocol. In the request, the acceleration program encapsulates the metadata of the data packet and transmits it to the DPI system via the operator's management network. The system performs fine-grained analysis of the data stream based on a more advanced model, such as time-series behavior, burst characteristics, and session structure, and returns the corresponding L7 layer application type label. The labels include standard categories such as "online games," "streaming media," "file transfer," and "social chat." When the label information returned by the DPI system matches the local identification result, and the identification type is "online games," the acceleration program determines that the data stream is valid game traffic and assigns it a priority level based on the game category. For example, if the identified game is a competitive game, it is marked as Level 6 (highest priority), while if it is traffic from a cloud gaming platform, it is marked as Level 5, and other games such as card games are marked as Level 3. The acceleration program writes the priority level into the DSCP field of the IP header of the data packet; for example, Level 6 corresponds to a DSCP value of 46 (Class EF).

[0030] In one specific embodiment, the process of sending an incoming data packet query request to the operator's DPI device via the GTP-U tunnel protocol and receiving the returned application type label, and determining the priority level of game traffic based on the application type label and the local traffic identification result, can specifically include the following steps: The gateway sends a traffic label query request for the incoming data packet to the operator's DPI device in the metropolitan area network aggregation layer through the GTP-U tunnel protocol between the gateway and the operator's core network, and receives the application type label returned by the operator's DPI device. Determine whether the application type label and the local traffic identification result both point to the game type and whether the confidence level is higher than the preset threshold. If the determination result is yes, confirm that the incoming data packet is game traffic. The priority level is determined based on the game type corresponding to the game traffic, and the DSCP value corresponding to the priority level is written into the TOS field of the IP header of the game traffic to obtain the game traffic marked with the priority level.

[0031] Specifically, the gateway device encapsulates the traffic metadata of incoming data packets into query request messages through a GTP-U tunnel protocol channel established with the operator's core network, and sends them to the operator's DPI device deployed at the metropolitan area network aggregation layer. The DPI device possesses more powerful behavioral model analysis capabilities, enabling it to perform deep analysis of the received data stream based on multi-dimensional features such as long-term sequences, communication frequency, and interaction patterns, and return application type labels. The returned results are presented in a structured manner, including the identified L7 layer service type category (such as "online games," "streaming media," "download services," etc.) and the corresponding identification confidence score. After receiving the DPI return results, the gateway performs a consistency check between the application type label and the traffic identification result previously obtained by matching local 5-tuple information with application layer feature codes. If both identification types point to "game" applications, and the confidence scores of both local identification and DPI identification are higher than a preset threshold (e.g., 0.85), then the currently processed incoming data packet is confirmed as valid game traffic. Based on this, game traffic is assigned a corresponding priority level according to its specific type. For example, MOBA games are classified as Level 6, FPS games and cloud gaming platform traffic are classified as Level 5, and casual card games are classified as Level 3. The corresponding DSCP value is written into the TOS field of the IP header of the data packet according to the level mapping relationship. Level 6 corresponds to DSCP value 46 (i.e., EF class, indicating very low latency and high priority), and Level 5 corresponds to DSCP value 34 (i.e., AF41 class), forming game traffic marked with a clear service level indication.

[0032] Figure 3This is a time sequence diagram of game latency changes under the cloud-based predictive switching mechanism. The horizontal axis represents time in seconds, and the vertical axis represents game network latency in milliseconds. From 0 to 20 seconds is the stable phase before the switch, with latency remaining stable at a low level of around 18ms. From 20 to 24 seconds is the switching period. During this time, the cloud detects that the link bandwidth utilization exceeds the 80% threshold, triggering the predictive mechanism. Alternative paths are sent to the gateway's pre-configured forwarding table entries in advance, resulting in slight latency fluctuations, but the peak does not exceed 20ms. After 24 seconds, the immediate recovery phase begins, activating the pre-configured alternative routes to complete the rapid switch. The latency quickly recovers to a stable level of 18ms and remains so for 60 seconds. The latency fluctuation range during the entire switching process is controlled within 2-3ms, and the switching time is less than 5 seconds. Compared to traditional solutions that require re-probing routes, resulting in switching latency of over 300ms and a peak latency of 180ms, this is significantly better.

[0033] In one specific embodiment, the process of performing step 300 may specifically include the following steps: The candidate AS path from the gateway to the game server is queried in the BGP routing table. The edge nodes in the pre-connected edge node channel are used as the starting point for node expansion. The actual cumulative cost and the heuristic estimated cost are calculated as the cost function value based on the weighted sum of the latency, packet loss rate and jitter value of the link between backbone nodes. The backbone node with the smallest cost function value is selected to backtrack the predecessor path to generate an end-to-end forwarding path. The end-to-end forwarding path is then encapsulated into a routing instruction message and sent to the gateway.

[0034] Specifically, a path search module is launched in the cloud-based collaborative acceleration platform. Based on the BGP routing table of the operator's backbone network, this module queries all feasible candidate paths from the access area where the gateway is located to the Autonomous System (AS) where the target game server is located. During this process, each edge node in the previously established pre-connected edge node channel serves as the starting point for the path search. Starting from the starting point, the backbone nodes in the BGP routing table are expanded layer by layer, and the link metrics between nodes are used as the basis for evaluating path costs. To achieve efficient path selection, the platform introduces a link quality evaluation mechanism based on each BGP routing path, including three quality parameters: latency, packet loss rate, and jitter. During the path search process, the cumulative cost G(n) of each path is dynamically calculated. The cumulative cost is defined as the sum of the costs of all links from the path's starting point to the current extended node n. The cost of each link is calculated using a weighted formula; for example, the cost of each link segment in G(n) is: link latency × 0.6 + packet loss rate × 1000 × 0.3 + jitter × 0.1, reflecting the comprehensive trade-off between transmission latency and stability. To avoid paths getting stuck in local optima, a heuristic cost estimation H(n) is introduced for each node n to be expanded. This cost is calculated by dividing the straight-line geographical distance between node n and the game server deployment address by the speed of light as the theoretical minimum latency estimate, reflecting the minimum potential overhead of its future possible paths. The total cost function F(n) = G(n) + H(n) is calculated for each node, and a priority queue is maintained to select nodes to be expanded based on their F(n) values. Each time, the node with the lowest cost is selected from the queue for expansion, the path costs of its adjacent nodes are updated, and the predecessor information of the path is recorded, until the expanded path reaches the boundary node of the autonomous system where the target game server resides. After the search terminates, the recorded predecessor paths are traced back, returning layer by layer from the target node to the starting point, and concatenating them to generate an end-to-end path sequence. The constructed path includes the edge node of the path's starting point, the IP addresses and next-hop information of all intermediate backbone nodes, link interface identifiers, and the estimated value of the total path latency. The end-to-end forwarding path is encapsulated in a structured manner into standardized routing command messages and distributed to the corresponding gateway devices through a dedicated operator management channel. Upon receiving a packet, the gateway inserts a high-priority static routing rule into its local routing table. Game traffic marked as high-level (e.g., Level 6) is forced to be forwarded along this path, thus achieving end-to-end link-level acceleration between the home terminal and the game server, reducing game latency and improving transmission stability. Simultaneously, the cloud-based path planning module reassesses the link status every 2 seconds to ensure dynamically controllable path quality and pushes alternative paths before congestion risks occur, achieving millisecond-level path switching capabilities.

[0035] After encapsulating the end-to-end forwarding path into routing command messages and sending them to the gateway, the process also includes: the cloud-based collaborative acceleration platform periodically sending active probe messages to each backbone node on the end-to-end forwarding path to collect real-time latency, real-time packet loss rate, and real-time bandwidth utilization of the links between each backbone node; storing the real-time latency, real-time packet loss rate, and real-time bandwidth utilization in a cloud-based time-series database and establishing a link quality time series; calculating the changing trends of each link quality indicator using a sliding time window based on the link quality time series; and predicting the trend values ​​of latency, packet loss rate, and bandwidth utilization of each link in the future time period using a linear regression algorithm; and determining whether the end-to-end forwarding path is... If the bandwidth utilization trend value of a link exceeds the congestion warning threshold or the packet loss rate trend value exceeds the packet loss warning threshold, and the result is yes, the link is marked as a potentially congested link and the alternative path calculation process is triggered; the potentially congested link is excluded from the BGP routing table, and the alternative end-to-end forwarding path from the edge node of the pre-connected edge node channel to the game server is recalculated to obtain the alternative route instruction message; the alternative route instruction message and path switching warning information are sent to the gateway in advance, and the gateway pre-inserts the alternative route entry into the local routing table. When the actual delay of the current path is detected to exceed the preset delay threshold, the alternative route entry is immediately activated to complete the seamless path switching.

[0036] In one specific embodiment, the process of querying the BGP routing table for candidate AS paths from the gateway to the game server, expanding nodes starting from edge nodes in the pre-connected edge node channels, and calculating the sum of the actual cumulative cost and the heuristically estimated cost as the cost function value based on the weighted average of the latency, packet loss rate, and jitter values ​​of the links between backbone nodes can specifically include the following steps: Query the BGP routing table for candidate AS paths from the gateway to the game server; A priority queue is created starting from the edge nodes in the pre-connected edge node channel to store the backbone nodes to be expanded. Each time, the node with the smallest cost function value is taken from the priority queue for expansion. The actual cumulative cost is calculated by weighting the latency, packet loss rate and jitter values ​​of each link for the expanded backbone node, and the heuristic cost estimate is obtained by dividing the geographical straight-line distance from the backbone node to be expanded to the game server by the light speed propagation delay. The actual cumulative cost is added to the heuristically estimated cost to obtain the cost function value. Adjacent backbone nodes are added to the priority queue and their predecessor paths are recorded.

[0037] Specifically, the cloud-based collaborative acceleration platform performs a candidate set query on reachable paths based on the BGP routing table of the operator's backbone network. This includes all legal AS paths originating from the access autonomous system to which the gateway belongs and leading to the target game server's autonomous system. The BGP routing table records the backbone node topology, autonomous system number, connection relationships between ASs, and path attributes nationwide, used to construct a logical topology graph for path search. After the query is completed, the edge nodes with established connections in the pre-connected edge node channels are used as the starting points for path search. A priority queue is created to manage nodes to be expanded. The priority queue is based on the A* path search algorithm. Each node carries a cost function value F(n) when entering the queue. In each iteration, the backbone node with the smallest current F(n) value is taken from the queue for the next expansion. During the expansion process, for each extracted backbone node n, all its directly connected adjacent backbone nodes are traversed, and the cost is evaluated based on the accumulated link performance indicators of the current path. The actual cumulative cost G(n) of the path is determined by the latency, packet loss rate, and jitter of each link traversed between the current node and the starting edge node. These metrics are weighted and synthesized, for example, by multiplying the link latency by a weight of 0.6, adding the packet loss rate by 1000 and then by a weight of 0.3, and adding the jitter by a weight of 0.1. The sum is the actual path cost G(n) from the starting point to node n. Simultaneously, to assess the remaining potential cost from the current node n to the target game server, the straight-line geographical distance between the node and the game server deployment location is calculated. This straight-line geographical distance is divided by the speed of light to obtain the minimum theoretical propagation delay under ideal conditions. This value serves as a heuristic cost estimate H(n) to assist path guidance. The two costs are added together to obtain the total cost function F(n) = G(n) + H(n) for node n. Each adjacent backbone node, along with its corresponding F(n) value, is pushed into a priority queue, and its predecessor node is recorded synchronously for subsequent path backtracking. As nodes continue to expand and queues are iteratively updated, the search process gradually approaches the target game server autonomous system, terminating when it first reaches the target AS boundary node. At this point, by backtracking the predecessor path records, the connection order of all backbone nodes on the end-to-end path is restored.

[0038] In one specific embodiment, the process of performing step 400 may specifically include the following steps: Within the computing power quota limited by resource quota parameters, a hierarchical token bucket queue is created through the flow control subsystem; According to the routing instruction message, a high-priority static route entry is inserted into the gateway's local routing table, and game traffic marked with priority level is forwarded to the corresponding token bucket queue according to the end-to-end forwarding path specified by the static route entry.

[0039] Specifically, within the computing power quota limited by resource quota parameters, a bandwidth management mechanism is constructed. This mechanism invokes the traffic control subsystem (tc) in the Linux kernel to build a hierarchical token bucket (HTB) queue structure under controlled CPU time slices and memory resources. This structure consists of a root queue and multiple sub-queues. The root queue manages the overall bandwidth, while the sub-queues are divided according to service priority levels. Each sub-queue has an independent rate limit and maximum borrowing limit (ceil) to achieve dynamic bandwidth scheduling between different service levels. To ensure operation within controlled computing power, the scheduling logic of the entire HTB structure is bound to a cgroup resource control group created by the acceleration program. The kernel scheduler allocates the maximum number of CPU cores and the maximum scheduling time slice for each group, ensuring that resource contention or priority inversion does not occur for gateway basic services (such as broadband and IPTV). After the cloud-based collaborative acceleration platform generates the optimal forwarding path for game traffic based on the BGP global path planning algorithm, it encapsulates the optimal forwarding path into standardized routing command messages in a structured format and securely distributes them to the corresponding gateway devices through the management channel. The routing command message contains the end-to-end path node sequence, the next-hop address of each backbone node, outgoing interface information, path quality assessment value, and the matching service priority identifier. After the gateway receives the routing command, the acceleration program parses the command content and writes it into the local kernel routing table, inserting a static route entry with the highest priority flag. The purpose of the static route entry is to force high-priority game traffic that meets specific five-tuple conditions to be matched to the specified path interface and next-hop destination address, and to prevent the operating system's default route or dynamic routing protocol from overriding this entry, ensuring that game traffic is not affected by fluctuations in the regular path. When the acceleration program successfully identifies game data packets on the inbound path and completes the priority tagging of the DSCP field, it matches the priority level according to the DSCP value of the TOS field in the IP packet header and classifies the data flow into the corresponding service queue. The acceleration program binds Class EF game traffic with a DSCP value of 46 to the Level 6 queue, and configures the rate parameters of this queue using the tc command, such as setting rate to 40Mbps and ceil to 80Mbps, and uses the kernel-supported HTB scheduler to bind the sub-queue to the output path of the physical interface eth0. Meanwhile, in the class rules of tc qdisc, the destination IP address range, port range, protocol type and marked DSCP value are used as the basis for traffic classification. Filter rules are created to ensure that game traffic is forcibly redirected to the Level 6 sub-queue according to the path of the static route entry.In the actual forwarding process, after the data packet enters the kernel network stack from the gateway, it will be matched with the high-priority static route entry according to the routing table, and then distributed to the designated queue scheduler. The sending rate and scheduling order are controlled by the hierarchical token bucket. High-priority game traffic will always get a larger share of bandwidth and lower queuing latency in the scheduler, thereby ensuring that latency fluctuations, jitter and packet loss in the game communication process are controlled within the tolerance range.

[0040] After forwarding game traffic marked with priority levels to the corresponding token bucket queues, the process also includes: periodically reading the packet sending rate and queue length of each hierarchical token bucket queue, calculating the instantaneous bandwidth utilization of each queue, comparing the instantaneous bandwidth utilization with the guaranteed bandwidth parameters configured for that queue to obtain the bandwidth demand difference for each queue; determining whether the bandwidth demand difference is greater than zero; when the bandwidth demand difference of a high-priority queue is greater than zero and the instantaneous bandwidth utilization of a low-priority queue is lower than the guaranteed bandwidth parameter, allocating the idle bandwidth of the low-priority queue to the high-priority queue according to the priority gradient, performing a dynamic bandwidth borrowing operation and updating the actual available bandwidth parameters of each queue; and dynamically adjusting the bandwidth utilization based on the ratio of the real-time queue length to the queue capacity. The weighted random early detection (WRED) parameters of the queue are set, including minimum packet loss threshold, maximum packet loss threshold, and maximum packet loss probability. Higher priority queues have larger minimum packet loss thresholds and smaller maximum packet loss probabilities. For new data packets arriving at each queue, the current queue length is determined. If the queue length is less than the minimum packet loss threshold, the packet is directly enqueued. If the queue length is between the minimum and maximum packet loss thresholds, a random packet loss probability is calculated and the packet is dropped accordingly. If the queue length exceeds the maximum packet loss threshold, the data packet is directly dropped. The bandwidth utilization, queue length, packet loss rate, and borrowed bandwidth values ​​of each queue are encapsulated into queue status messages and periodically reported to the cloud-based collaborative acceleration platform for global traffic scheduling optimization analysis.

[0041] In one specific embodiment, after forwarding according to the end-to-end forwarding path specified in the routing instruction message, the method further includes: The gateway's CPU utilization, memory usage, game traffic latency, and packet loss rate are encapsulated into monitoring messages and reported to the cloud time-series database through the operator's management channel. Calculate the historical data mean and standard deviation in the cloud time series database, generate anomaly alarm work orders based on the historical data mean and standard deviation, and push them to the operation and maintenance system; The game's server IP address range, port number, and signature code are extracted from the game developer's official channels to generate an incremental signature database update package. P2P fragmentation transmission technology is used to push the incremental signature database update package to the gateway and perform a dual-partition backup upgrade. After the upgrade is completed, the gateway's game signature database is updated.

[0042] Specifically, performance metrics are collected periodically, including CPU utilization, memory usage, average latency of game traffic, and packet loss rate of game traffic. These metrics reflect the accelerator's consumption of local resources and its optimization effect on target traffic, respectively. The monitoring module encapsulates these metrics into structured monitoring messages, using JSON or lightweight binary formats (such as Protobuf) to construct a clear and efficient data structure. The accelerator periodically sends the monitoring messages to a time-series database system in the cloud through a management channel pre-set by the operator. This management channel is deployed independently of the user's business links, ensuring that transmission is not affected by user traffic and possessing high reliability and low latency. The time-series database in the cloud platform uses a high-concurrency write-optimized structure, such as ClickHouse or InfluxDB, supporting efficient storage and indexing of data reported by tens of millions of gateway devices. The operation and maintenance analysis module establishes historical trajectories for monitoring indicators at the device level and periodically calculates the historical mean μ and standard deviation σ for each indicator. Based on the 3σ criterion in statistics, anomaly detection boundaries are constructed. If the reported CPU utilization, memory load, or game traffic latency and packet loss rate at a certain moment falls outside the interval [μ-3σ, μ+3σ], it is identified by the system as an abnormal operating status. Anomaly alarm work order is automatically generated. The work order records the name, value, degree of exceeding the standard deviation range of the abnormal indicator, timestamp of the anomaly, unique device identifier (such as MAC address or hardware fingerprint), and physical geographical location of the device. The work order is pushed to the operator's BOSS operation and maintenance system through the API interface, triggering the operation and maintenance process response, enabling operation and maintenance personnel to obtain alarm information and perform remote troubleshooting within 5 minutes. Meanwhile, to enhance the acceleration system's compatibility with newly launched games, a game content tracking and feature extraction module is deployed in the cloud. This module periodically collects game version update information from official channels of mainstream game developers, including update logs, data packet signatures, and server node changes. Combined with a traffic analysis system, it captures and decodes the post-launch data stream, extracting new server IP address ranges, port number ranges, and application-layer feature byte sequences to construct incremental feature library update packages. The update package size is controlled within 2MB, and a P2P fragmentation transmission mechanism is used for large-scale distribution. Several seed gateway devices distributed in different regions push the complete package to the local machine, and other gateway devices then request data fragments from the seed nodes via the BitTorrent protocol. Each fragment is set to 256KB in size and supports breakpoint resumption and multi-source concurrent downloads, thereby improving update efficiency and reducing the bandwidth burden on the central server.After the download is complete, the acceleration program executes a dual-partition (A / B) backup upgrade strategy. The new feature library is written to the backup partition and its integrity is verified. Once verification is successful, the read path is switched to the new partition to complete the upgrade. If verification fails or the program malfunctions, it automatically rolls back to the old partition to continue using the original feature library, ensuring that the update process does not affect the continuity and stability of the game acceleration service. After the upgrade, the gateway's local feature library is synchronized with the cloud version, thereby improving the accuracy of new game recognition and ensuring continuous coverage of the entire network acceleration service.

[0043] The gateway-side intelligent acceleration method in the embodiments of the present invention has been described above. The gateway-side intelligent acceleration system in the embodiments of the present invention is described below. Please refer to [link / reference]. Figure 4 One embodiment of the gateway-side intelligent acceleration system in this invention includes: Module 41 is used to select multiple edge nodes based on the geographical coordinates of the gateway and establish pre-connected edge node channels; Traffic identification module 42 is used to match the incoming data packets of the gateway with the game feature library to obtain local traffic identification results, and generate game traffic with priority levels based on the local traffic identification results and the application type tags returned by the operator's DPI device. The calculation module 43 is used to calculate the end-to-end forwarding path from the edge node of the pre-connected edge node channel, and encapsulate the end-to-end forwarding path into a routing instruction message and send it to the gateway. Forwarding module 44 is used to create a hierarchical token bucket queue at the gateway and forward game traffic marked with priority levels according to the end-to-end forwarding path specified by the routing instruction message.

[0044] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

[0046] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A gateway-side intelligent acceleration method, characterized in that, include: Select multiple edge nodes based on the gateway's geographical coordinates and establish pre-connected edge node channels; The incoming data packets of the gateway are matched with the game feature database to obtain the local traffic identification result, and the game traffic with priority level is generated based on the local traffic identification result and the application type label returned by the operator's DPI device. Calculate the end-to-end forwarding path from the edge node of the pre-connected edge node channel, and encapsulate the end-to-end forwarding path into a routing instruction message and send it to the gateway. The gateway creates a hierarchical token bucket queue and forwards the game traffic marked with priority levels according to the end-to-end forwarding path specified in the routing instruction message.

2. The gateway-side intelligent acceleration method according to claim 1, characterized in that, Before selecting multiple edge nodes based on the gateway's geographic coordinates and establishing pre-connected edge node channels, the process also includes: Call the Linux kernel interface to read the cpuinfo file to obtain the CPU model, parse the meminfo file to extract the memory capacity, execute system commands to obtain the firmware version, and query network interface nodes to obtain the network interface speed; The CPU model, memory capacity, firmware version, and network port speed are combined to generate a hardware fingerprint; The hardware fingerprint is queried against the local driver adaptation database to obtain the CPU architecture type, and the corresponding driver configuration file is loaded according to the CPU architecture type. Based on the driver configuration file, a resource control group is created through the cgroup subsystem and bound to the acceleration program process. According to the memory capacity and the number of CPU cores, the memory quotas for fixed cache and elastic cache are set, and the CPU quotas for computing power usage percentage are set to obtain resource quota parameters.

3. The gateway-side intelligent acceleration method according to claim 2, characterized in that, Multiple edge nodes are selected based on the gateway's geographic coordinates, and pre-connected edge node channels are established, including: The distance between each edge node in the operator's edge computing platform and the gateway is calculated based on the gateway's geographical coordinates, and a comprehensive score is calculated by combining the CPU load rate, bandwidth utilization rate and number of access devices of each edge node. Based on the comprehensive score, multiple edge nodes are selected as pre-connection targets; A TCP connection request with TLS encryption protocol is initiated to the edge node of the pre-connected target and a long connection is established. After the long connection is established, a heartbeat probe message is sent to monitor the round-trip delay and obtain the pre-connected edge node channel.

4. The gateway-side intelligent acceleration method according to claim 3, characterized in that, The incoming data packets of the gateway are matched with the game feature database to obtain local traffic identification results. Based on the local traffic identification results and the application type tags returned by the operator's DPI device, game traffic with priority levels is generated, including: By registering hook functions in the PREROUTING chain using the netfilter framework, incoming data packets can be intercepted, and the five-tuple information of source IP address, destination IP address, source port number, destination port number, and protocol type, as well as the application layer signature of the load area, can be extracted. The five-tuple information and application layer feature code are matched with the IP address range, port number range and feature code hash value of the game feature library to obtain the local traffic identification result; The system sends a query request for the incoming data packet to the operator's DPI device via the GTP-U tunnel protocol and receives the returned application type label. Based on the application type label and the local traffic identification result, it determines the priority level of the game traffic.

5. The gateway-side intelligent acceleration method according to claim 4, characterized in that, The system sends a query request for the incoming data packet to the operator's DPI device via the GTP-U tunnel protocol and receives the returned application type label. Based on the application type label and the local traffic identification result, it determines the priority level of the game traffic, including: The gateway sends a traffic label query request for the incoming data packet to the operator's DPI device in the metropolitan area network aggregation layer via the GTP-U tunnel protocol between the gateway and the operator's core network, and receives the application type label returned by the operator's DPI device. Determine whether the application type label and the local traffic identification result both point to the game type and whether the confidence level is higher than a preset threshold. If the determination result is yes, confirm that the inbound data packet is game traffic. The priority level is determined based on the game type corresponding to the game traffic, and the DSCP value corresponding to the priority level is written into the TOS field of the IP header of the game traffic to obtain the game traffic with the priority level marked.

6. The gateway-side intelligent acceleration method according to claim 5, characterized in that, Calculate the end-to-end forwarding path from the edge node of the pre-connected edge node channel, encapsulate the end-to-end forwarding path into a routing command message and send it to the gateway, including: The candidate AS path from the gateway to the game server is queried in the BGP routing table. The edge nodes in the pre-connected edge node channel are used as the starting point for node expansion. The actual cumulative cost and the heuristic estimated cost are calculated as the cost function value based on the weighted sum of the latency, packet loss rate and jitter value of the link between backbone nodes. The backbone node with the smallest cost function value is selected to backtrack the predecessor path to generate an end-to-end forwarding path, and the end-to-end forwarding path is encapsulated into a routing instruction message and sent to the gateway.

7. The gateway-side intelligent acceleration method according to claim 6, characterized in that, The BGP routing table is queried for candidate AS paths from the gateway to the game server. Node expansion is performed starting from the edge nodes in the pre-connected edge node channels. The actual cumulative cost is calculated as the sum of the actual cumulative cost and the heuristically estimated cost, weighted by the latency, packet loss rate, and jitter values ​​of the links between backbone nodes. This sum is used as the cost function value, including: Query the BGP routing table for candidate AS paths from the gateway to the game server; A priority queue is created using the edge nodes in the pre-connected edge node channel as the starting point to store the backbone nodes to be expanded. Each time, the node with the smallest cost function value is taken from the priority queue for expansion. The actual cumulative cost is calculated by weighting the latency, packet loss rate and jitter values ​​of each link for the expanded backbone node, and the heuristic cost estimate is obtained by dividing the geographical straight-line distance from the backbone node to be expanded to the game server by the light speed propagation delay. The actual cumulative cost is added to the heuristically estimated cost to obtain the cost function value. Adjacent backbone nodes are added to the priority queue and their predecessor paths are recorded.

8. The gateway-side intelligent acceleration method according to claim 7, characterized in that, The gateway creates a hierarchical token bucket queue and forwards the game traffic marked with priority levels according to the end-to-end forwarding path specified in the routing instruction message, including: Within the computing power quota range defined by the resource quota parameters, a hierarchical token bucket queue is created through the flow control subsystem; According to the routing instruction message, a high-priority static route entry is inserted into the local routing table of the gateway, and the game traffic marked with priority level is forwarded to the corresponding token bucket queue according to the end-to-end forwarding path specified by the static route entry.

9. The gateway-side intelligent acceleration method according to claim 1, characterized in that, After forwarding according to the end-to-end forwarding path specified in the routing instruction message, the process also includes: The CPU utilization, memory usage, game traffic latency, and packet loss rate of the gateway are encapsulated into monitoring messages and reported to the cloud time-series database through the operator management channel; Calculate the historical data mean and historical data standard deviation in the cloud time-series database, generate an anomaly alarm work order based on the historical data mean and historical data standard deviation, and push it to the operation and maintenance system; The game's server IP address range, port number, and signature code are extracted from the game developer's official channels to generate an incremental signature database update package. The incremental signature database update package is pushed to the gateway using P2P fragmentation transmission technology, and a dual-partition backup upgrade is performed. After the upgrade is completed, the game signature database of the gateway is updated.

10. A gateway-side intelligent acceleration system, characterized in that, A gateway-side intelligent acceleration method for performing any one of claims 1-9 includes: The module is used to select multiple edge nodes based on the geographical coordinates of the gateway and establish pre-connected edge node channels; The traffic identification module is used to match the incoming data packets of the gateway with the game feature library to obtain the local traffic identification result, and generate game traffic with priority level based on the local traffic identification result and the application type tag returned by the operator's DPI device. The calculation module is used to calculate the end-to-end forwarding path from the edge node of the pre-connected edge node channel, and encapsulate the end-to-end forwarding path into a routing instruction message and send it to the gateway. The forwarding module is used to create a hierarchical token bucket queue on the gateway and forward the game traffic marked with priority levels according to the end-to-end forwarding path specified by the routing instruction message.

Images