Gateway test method and system

Abstract

The invention relates to the technical field of gateway testing, and discloses a gateway testing method and system, and the method comprises the steps: paying attention to a game flow testing set to a testing network based on a flow generator, and obtaining the flow recognition accuracy; constructing a cloud MQTT heartbeat connection and a Kafka data reporting channel based on the flow identification accuracy, and performing device concurrent load injection to obtain an MQTT concurrent connection number and a Kafka cluster throughput; and running the test game on the terminal equipment based on the MQTT concurrent connection number and the Kafka cluster throughput, and obtaining the average delay of the game and the CPU occupancy rate of the gateway end. The method establishes an association test model between the end-side flow identification performance and the cloud collaboration mechanism performance, solves the technical problem that the end-side test is separated from the cloud test in the prior art, and improves the test efficiency. The specific matching link where the traffic identification performance bottleneck is located can be accurately positioned, and the stability in a long-time operation state and the compatibility with broadband and IPTV basic services are realized.

Description

Technical Field

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

[0002] With the increasing demand from operators for large-scale deployment of gateway-side intelligent game acceleration systems, existing testing methods suffer from the following main problems: For the traffic identification stage, traditional testing methods cannot separate and measure the independent time consumption of each engine level—IP address matching, port matching, and feature code matching—leading to difficulties in locating performance bottlenecks. When processing large-scale game feature databases, it is impossible to quantify the contribution of different matching algorithms to the overall identification accuracy. Furthermore, the performance testing of cloud-based collaboration mechanisms is independent of end-side traffic identification testing. No correlation test model has been established between MQTT heartbeat mechanisms, Kafka data reporting, path calculation services, and end-side identification performance, making it impossible to assess the impact of cloud-based collaboration latency on end-side acceleration effects. Summary of the Invention

[0003] This invention provides a gateway testing method and system. It establishes a correlation test model between end-side traffic identification performance and cloud-based collaborative mechanism performance, solving the technical problem of separating end-side testing and cloud-based testing in existing technologies. It can accurately locate the specific matching link where the traffic identification performance bottleneck is located, and achieves stability and compatibility with basic broadband and IPTV services under long-term operation.

[0004] In a first aspect, the present invention provides a gateway testing method, the gateway testing method comprising: The game traffic test set is injected into the test gateway based on the traffic generator, and the traffic identification accuracy is obtained. Based on the traffic identification accuracy, a cloud-based MQTT heartbeat connection and a Kafka data reporting channel are constructed, and concurrent load injection is performed on the device to obtain the number of concurrent MQTT connections and the throughput of the Kafka cluster. The test game was run on the terminal device based on the MQTT concurrent connection count and the Kafka cluster throughput to obtain the average game latency and gateway CPU utilization.

[0005] In conjunction with the first aspect, in the first implementation of the first aspect of the present invention, before injecting the game traffic test set into the test gateway based on the traffic generator and obtaining the traffic identification accuracy, the method further includes: An acceleration program plugin is installed on the test gateway. The acceleration program plugin has an embedded IP address matching engine, a port matching engine, and a signature matching engine. The IP address matching engine, the port matching engine, and the signature matching engine are connected in series. Configure a game traffic template containing target IP address ranges, target port numbers, and application layer signatures on the traffic generator, and generate a game traffic test set based on the game traffic template.

[0006] In conjunction with the first aspect, in a second implementation of the first aspect of the present invention, injecting a game traffic test set into the test gateway based on a traffic generator and obtaining the traffic identification accuracy includes: The game traffic test set is injected into the test gateway based on the traffic generator, and the identification result tags output by the test gateway and the game traffic tags injected by the traffic generator are collected. The ratio of the number of successfully identified data packets in the identification result label to the total number of data packets injected in the game traffic label is calculated, and the ratio is used as the traffic identification accuracy.

[0007] In conjunction with the first aspect, in the third implementation of the first aspect of the present invention, a cloud-based MQTT heartbeat connection and a Kafka data reporting channel are constructed based on the traffic identification accuracy, and concurrent load injection is performed on the device to obtain the number of concurrent MQTT connections and the throughput of the Kafka cluster, including: Based on the traffic identification accuracy, an MQTT Broker and Kafka cluster are deployed on a cloud server. An MQTT heartbeat connection is established between the test gateway and the MQTT Broker, and the heartbeat self-healing restart time is calculated. Based on the test gateway, an acceleration request message is sent to the cloud path calculation service and the path calculation response time is returned. Based on the heartbeat self-healing restart time and the path calculation response time, a device concurrency simulation tool is deployed to perform concurrent load injection on the MQTT heartbeat connection and the Kafka data reporting channel to obtain the number of concurrent MQTT connections and the throughput of the Kafka cluster.

[0008] In conjunction with the first aspect, in the fourth implementation of the first aspect of the present invention, an MQTT Broker and a Kafka cluster are deployed on a cloud server, and an MQTT heartbeat connection is established between the test gateway and the MQTT Broker, and the heartbeat self-healing restart time is calculated, including: Deploy the MQTT Broker on the cloud server, start the acceleration module based on the test gateway to establish an MQTT heartbeat connection with the MQTT Broker, configure the heartbeat timeout threshold as the number of consecutive heartbeats without response, and configure the heartbeat sending interval. The MQTT Broker is simulated to receive a heartbeat message but does not return a heartbeat response. When the number of consecutive non-response counts reaches the heartbeat timeout threshold, the acceleration module is triggered to automatically restart, and the heartbeat timeout trigger time and restart completion time are recorded. The heartbeat self-healing restart time is calculated based on the heartbeat timeout trigger time and the restart completion time.

[0009] In conjunction with the first aspect, in the fifth implementation of the first aspect of the present invention, a device concurrency simulation tool is deployed based on the heartbeat self-healing restart time and the path calculation response time to perform concurrent load injection on the MQTT heartbeat connection and the Kafka data reporting channel, thereby obtaining the number of concurrent MQTT connections and the Kafka cluster throughput, including: Deploy the device concurrency simulation tool to generate simulated gateway devices, configure each simulated gateway device to send heartbeat messages to the MQTT Broker at heartbeat sending intervals, and send traffic statistics to the Kafka cluster at data reporting intervals, and perform concurrent load injection on the MQTT heartbeat connection and the Kafka data reporting channel; The number of concurrent MQTT connections is obtained based on the number of connections exchanging heartbeat messages within the statistical time window of the MQTT Broker. The throughput of the Kafka cluster is obtained based on the number of messages received per second by all partitions of the Kafka cluster.

[0010] In conjunction with the first aspect, in the sixth implementation of the first aspect of the present invention, a test game is run on a terminal device based on the number of concurrent MQTT connections and the throughput of the Kafka cluster to obtain the average game latency and the CPU utilization rate of the gateway, including: Running a test game on a terminal device triggers the test gateway to identify game traffic in real time and allocate reserved bandwidth for the game traffic. Record the average latency returned by the game client, continuously send UDP probe packets to calculate the ratio of lost packets to total packets sent, and obtain the game packet loss rate; The system file corresponding to the process identifier of the acceleration program plugin is read to obtain the process CPU time slice, and the ratio of the process CPU time slice to the sampling interval is calculated to obtain the CPU utilization rate of the gateway.

[0011] In conjunction with the first aspect, in the seventh implementation of the first aspect of the present invention, after running a test game on a terminal device based on the MQTT concurrent connection count and the Kafka cluster throughput, and obtaining the average game latency and gateway CPU utilization, the method further includes: The test game was triggered to switch from the first game server to the second game server; The test gateway detects that the IP address of the second game server has changed and records the first timestamp, and records the second timestamp after completing the acceleration path calculation for the second game server; Calculate the time difference between the second timestamp and the first timestamp to obtain the cross-server switching time.

[0012] In conjunction with the first aspect, in the eighth implementation of the first aspect of the present invention, after obtaining the average game latency and the gateway CPU utilization, the method further includes: Configure the test gateway to perform a full-load test scenario; Deploy a fault monitoring program to monitor the process survival status, heartbeat response status, and abnormal exit logs of the acceleration program plugin, record the number of fault events where the acceleration program process exits or becomes unresponsive for more than a threshold duration, and calculate the ratio of the number of fault events to the monitoring duration to obtain the system failure rate. Broadband internet access and IPTV services are run simultaneously on the test gateway. The number of times the broadband download speed decreases and the number of times the IPTV video stutters are recorded at monitoring intervals. The percentage of time without decrease or stuttering is calculated to obtain the basic service compatibility index.

[0013] Secondly, the present invention provides a gateway testing system, the gateway testing system comprising: The traffic identification module is used to inject game traffic test sets into the test gateway based on the traffic generator and obtain the traffic identification accuracy. The device concurrent load module is used to build cloud MQTT heartbeat connections and Kafka data reporting channels based on the traffic identification accuracy, and to inject device concurrent load to obtain the number of MQTT concurrent connections and Kafka cluster throughput. The test module is used to run test games on terminal devices based on the MQTT concurrent connection count and the Kafka cluster throughput, and to obtain the average game latency and gateway CPU utilization.

[0014] The technical solution provided by this invention achieves separate time-consuming measurement of the three-level serial matching mechanism by inserting timestamp collection probes at the entry and exit points of the IP address matching engine, port matching engine, and feature code matching engine. This allows for precise location of the specific matching stage where the traffic identification performance bottleneck lies. By constructing a cloud-based MQTT heartbeat connection and Kafka data reporting channel, and measuring the heartbeat self-healing restart time and path calculation response time, a correlation test model between end-side traffic identification performance and cloud-based collaborative mechanism performance is established, solving the technical problem of separating end-side testing from cloud testing in existing technologies. By deploying a device concurrency simulation tool to generate tens of millions of simulated gateway devices, and measuring the number of concurrent MQTT connections, Kafka cluster throughput, and cloud server resource utilization, a comprehensive verification of the end-cloud coupling performance in large-scale operator deployment scenarios is achieved. By measuring game latency, packet loss rate, gateway CPU utilization, and cross-server switching time in real game scenarios, it is ensured that the test results accurately reflect the acceleration effect of the system in actual applications. By continuously running the test gateway under full load and monitoring the system failure rate and basic service compatibility indicators, stability and compatibility with broadband and IPTV basic services were achieved during long-term operation. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are 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] Figure 1 This is a schematic diagram illustrating the steps of the gateway testing method in an embodiment of the present invention; Figure 2 This is a schematic diagram of the gateway testing system in an embodiment of the present invention. Detailed Implementation

[0017] This invention provides a gateway testing method and system. The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" or "having" and any variations thereof are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0018] For ease of understanding, the specific process of the embodiments of the present invention is described below. Please refer to [link / reference]. Figure 1 One embodiment of the gateway testing method in this invention includes: Step S1: Inject the game traffic test set into the test gateway based on the traffic generator and obtain the traffic identification accuracy. Step S2: Based on the traffic identification accuracy, construct a cloud-based MQTT heartbeat connection and a Kafka data reporting channel, and perform concurrent load injection on the device to obtain the number of concurrent MQTT connections and the throughput of the Kafka cluster; Step S3: Run the test game on the terminal device based on the MQTT concurrent connection count and the Kafka cluster throughput to obtain the average game latency and gateway CPU utilization.

[0019] In one specific embodiment, before injecting the game traffic test set into the test gateway based on the traffic generator and obtaining the traffic identification accuracy, the method further includes: An acceleration program plugin is installed on the test gateway. The acceleration program plugin has an embedded IP address matching engine, a port matching engine, and a signature matching engine. The IP address matching engine, the port matching engine, and the signature matching engine are connected in series. Configure a game traffic template containing target IP address ranges, target port numbers, and application layer signatures on the traffic generator, and generate a game traffic test set based on the game traffic template.

[0020] Specifically, the acceleration program plugin is pre-installed and deployed on the test gateway device of the OpenWRT architecture. The plugin is packaged as an .ipk installation package, and decompression and loading are completed through the gateway system's package management mechanism. After installation, the plugin is automatically registered to the system service and runs with the device startup. The traffic identification module integrated inside the acceleration program plugin adopts a three-level serial matching architecture, including three independent components: IP address matching engine, port matching engine, and feature code matching engine. The IP address matching engine uses a hash table retrieval algorithm to achieve efficient IP segment lookup, and can complete the location and matching of the game server's main address segment and the CDN acceleration node IP in constant time complexity. The port matching engine uses a bitmap index structure, supports fast filtering of specified TCP or UDP ports, and implements logical intersection operations with IP address matching results to improve identification accuracy. The feature code matching engine is based on the Aho-Corasick automaton algorithm to build a multi-mode state machine, which can identify multiple protocol key byte sequences in parallel in a single traffic traversal, used to restore the application layer game protocol feature characteristics. Three matching engines are connected serially in the order of IP address matching first, port matching second, and feature code matching last. This ensures that traffic is filtered and the identification path is gradually refined as it passes through each matching node, thus forming a coarse-to-fine filtering mechanism on the identification path, reducing the false recognition rate and improving the overall identification efficiency. After the plugin is deployed, a game traffic template is built in the Spirent TestCenter traffic generator or equivalent system. The template contains common target IP address ranges of game servers in real networks, common communication port number ranges, and application layer protocol features extracted from actual game data packets, such as fixed byte sequences during the handshake phase, heartbeat packet flag fields, or key instruction interaction code bits. All information is categorized and summarized according to the protocol behavior of 200 test games and organized into a standardized injection template. Each game corresponds to a complete description entry containing three types of information: IP range, port, and feature code. Based on the game traffic template, the traffic generator automatically generates and injects the corresponding game traffic test set under specified time intervals and bandwidth control conditions. The game traffic test set is transmitted to the test gateway through a physical or virtual link, and then the three-level matching engine in the acceleration program plugin completes the identification, tag allocation and statistical analysis in sequence, thus forming a complete identification capability verification and performance test link.

[0021] In one specific embodiment, the process of performing step S1 may specifically include the following steps: The game traffic test set is injected into the test gateway based on the traffic generator, and the identification result tags output by the test gateway and the game traffic tags injected by the traffic generator are collected. The ratio of the number of successfully identified data packets in the identification result label to the total number of data packets injected in the game traffic label is calculated, and the ratio is used as the traffic identification accuracy.

[0022] Specifically, a game traffic test set is injected into the test gateway using a traffic generator. The template set includes protocol feature entries for 200 typical games. Each entry consists of three elements: the target IP address range, the target communication port number, and the application layer signature. Based on a unified identifier structure, a unique tag field is added to enable data tracking. At the beginning of the test, the traffic generator injects encapsulated game data packet streams into the test gateway at a specified bandwidth (e.g., 100Mbps) and a specified mode (e.g., continuous injection of a single game or mixed injection of multiple games). The source tag field of the game data packets remains unchanged during physical transmission, and each packet's message structure includes information such as the game identifier, timestamp, and sequence number. Simultaneously, the acceleration program plugin running on the test gateway initiates a traffic identification module. It sequentially inputs the received traffic into a three-tiered structure—IP address matching engine, port matching engine, and feature code matching engine—for step-by-step identification processing. After each identification, a result label is generated. This label includes key fields such as the game name, a boolean flag indicating success or failure, the specific level of successful matching (e.g., whether a feature code was hit), and the processing time. This data is written to local logs in real-time or uploaded to a cloud database via a Kafka interface. Once a certain scale of identification data has accumulated, structured extraction of the identification result logs is performed using log collection and analysis tools such as ELK Stack. The number of successfully identified data packets (N1) is counted by counting all successfully identified result labels. Simultaneously, injection task logs or original sending logs are extracted from the traffic generator, and the total number of data packets sent during this injection process (N2) is calculated. Both are aligned and verified using timestamps and unique sequence numbers. The expression for calculating the identification accuracy R is defined as R = N1 / N2 × 100%. In one specific embodiment, the process of performing step S2 may specifically include the following steps: Based on the traffic identification accuracy, an MQTT Broker and Kafka cluster are deployed on a cloud server. An MQTT heartbeat connection is established between the test gateway and the MQTT Broker, and the heartbeat self-healing restart time is calculated. Based on the test gateway, an acceleration request message is sent to the cloud path calculation service and the path calculation response time is returned. Based on the heartbeat self-healing restart time and the path calculation response time, a device concurrency simulation tool is deployed to perform concurrent load injection on the MQTT heartbeat connection and the Kafka data reporting channel to obtain the number of concurrent MQTT connections and the throughput of the Kafka cluster.

[0023] Specifically, based on traffic identification accuracy, the test gateway acceleration program was ensured to achieve an identification accuracy of over 99.5% across 200 test game templates, and an end-to-cloud collaborative path was built upon accurate identification. An MQTT Broker service cluster and a Kafka cluster were deployed on a cloud server group. The MQTT Broker was built on EMQ X 4.4, supporting millions of connections, while the Kafka cluster used version 2.8.0 with a multi-partition architecture to improve concurrent write capabilities. After deployment, the MQTT client in the test gateway acceleration plugin initialized a persistent connection with the cloud Broker, periodically sending heartbeat messages every 5 seconds to maintain connection activity. The cloud-based heartbeat timeout threshold was set to 10 seconds. If no response was received after three consecutive attempts, the connection was considered lost, and a self-healing mechanism was triggered on the gateway to initiate a reconnection process. During this process, the test program recorded the timestamp of the triggered heartbeat timeout and the timestamp of the completed automatic restart recovery, calculating the difference as the heartbeat self-healing restart time, which was measured to be within 1 second. After identifying game traffic, the gateway acceleration program constructs an acceleration request message containing the game server's target IP and the gateway's egress address and sends it to the cloud path calculation service module. The path calculation service retrieves the optimal forwarding path based on the topology database and returns the path node sequence. The gateway records the interval between the sending and receiving times, which is the path calculation response time. Based on the heartbeat self-healing restart time and the path calculation response time, a concurrent performance verification environment for large-scale access is built. A device concurrency simulation tool supporting coroutine scheduling is deployed on the test platform. Each server simulates the access behavior of 100,000 virtual gateway devices and is uniformly configured to send a heartbeat message to the MQTT Broker every 5 seconds and report a data reporting message containing traffic identification accuracy and matching time fields to the Kafka cluster every 10 seconds. By deploying 100 simulated servers running concurrently, a total load pressure of 10 million virtual devices is injected into the cloud component. The number of active connections of the MQTT Broker is monitored in real time, and the number of messages received per second by the Kafka consumer is counted to obtain the stable concurrent connection limit of the MQTT system and the maximum throughput capacity of the Kafka cluster under high pressure conditions.

[0024] In one specific embodiment, the process of deploying an MQTT Broker and a Kafka cluster on a cloud server, establishing an MQTT heartbeat connection with the MQTT Broker based on the test gateway, and calculating the heartbeat self-healing restart time can specifically include the following steps: Deploy the MQTT Broker on the cloud server, start the acceleration module based on the test gateway to establish an MQTT heartbeat connection with the MQTT Broker, configure the heartbeat timeout threshold as the number of consecutive heartbeats without response, and configure the heartbeat sending interval. The MQTT Broker is simulated to receive a heartbeat message but does not return a heartbeat response. When the number of consecutive non-response counts reaches the heartbeat timeout threshold, the acceleration module is triggered to automatically restart, and the heartbeat timeout trigger time and restart completion time are recorded. The heartbeat self-healing restart time is calculated based on the heartbeat timeout trigger time and the restart completion time.

[0025] Specifically, an MQTT Broker is deployed on a cloud server. The MQTT Broker component is built on EMQ X 4.4, runs on the CentOS operating system platform, and is configured to support millions of concurrent connections. An embedded acceleration module is started on the test gateway. This module includes an MQTT client communication submodule, which establishes a persistent connection channel with the MQTT Broker and configures a heartbeat sending mechanism. The heartbeat sending interval is set to 5 seconds, and the heartbeat timeout threshold is set to three consecutive heartbeat messages without a response from the Broker; that is, if no valid response is received within 15 seconds, the connection is considered invalid. After the connection is established, a cloud-simulated fault injection mechanism temporarily blocks the MQTT Broker's response path to heartbeat messages, preventing any response to heartbeat data packets sent by the test gateway. This initiates the heartbeat timeout detection process. When the gateway detects three consecutive heartbeat timeouts without a response, it triggers the built-in self-healing mechanism, automatically restarting the acceleration module to restore the MQTT connection. In this process, the system time point that triggers the heartbeat timeout is recorded in the acceleration program log recording module, and the system time point that the module resumes normal operation is recorded after the module restarts. The time difference between the two is calculated to obtain the self-healing restart time after a complete heartbeat connection interruption.

[0026] In one specific embodiment, the process of deploying a device concurrency simulation tool based on the heartbeat self-healing restart time and the path calculation response time to perform concurrent load injection on the MQTT heartbeat connection and the Kafka data reporting channel, and obtaining the MQTT concurrent connection count and Kafka cluster throughput, can specifically include the following steps: Deploy the device concurrency simulation tool to generate simulated gateway devices, configure each simulated gateway device to send heartbeat messages to the MQTT Broker at heartbeat sending intervals, and send traffic statistics to the Kafka cluster at data reporting intervals, and perform concurrent load injection on the MQTT heartbeat connection and the Kafka data reporting channel; The number of concurrent MQTT connections is obtained based on the number of connections exchanging heartbeat messages within the statistical time window of the MQTT Broker. The throughput of the Kafka cluster is obtained based on the number of messages received per second by all partitions of the Kafka cluster.

[0027] Specifically, a device concurrency simulation tool based on a coroutine concurrency model is deployed in the test environment. The device concurrency simulation tool runs on multiple high-performance servers and has high-density virtual session scheduling capabilities. Each server simulates the behavior of hundreds of thousands of virtual gateway devices. Each simulated virtual gateway device is configured with a unique client identifier and has a built-in MQTT protocol stack and Kafka producer module. After startup, it sends heartbeat messages to the cloud MQTT Broker at preset heartbeat intervals (e.g., every 5 seconds). The message structure conforms to the MQTT standard protocol frame format and includes fields such as device number, timestamp, and connection status. At the same time, it constructs Kafka messages with traffic statistics fields and reports them to the Kafka cluster according to the set data reporting period (e.g., every 10 seconds). The Kafka messages include fields such as simulated game recognition results, matching time, and recognition accuracy and are written to the partition queue, which is received by the Kafka Broker and distributed to the consumer system. As the number of simulated devices continues to increase, the number of active connections on the MQTT Broker side will gradually approach the target concurrency limit. During load injection, a connection monitoring module is deployed in the MQTT Broker cluster to count the total number of connections that successfully complete heartbeat interactions with the Broker within a time window every second, and this total number of connections is used as the current concurrent connection count of the MQTT system. Meanwhile, the monitoring service running inside the Kafka cluster accumulates the number of messages received by each partition within a unit of time, and sums the results across all partitions to obtain the total throughput of the Kafka cluster. The total throughput of the Kafka cluster reflects the system's maximum data carrying capacity under the current scale of device access.

[0028] In one specific embodiment, the process of performing step S3 may specifically include the following steps: Running a test game on a terminal device triggers the test gateway to identify game traffic in real time and allocate reserved bandwidth for the game traffic. Record the average latency returned by the game client, continuously send UDP probe packets to calculate the ratio of lost packets to total packets sent, and obtain the game packet loss rate; The system file corresponding to the process identifier of the acceleration program plugin is read to obtain the process CPU time slice, and the ratio of the process CPU time slice to the sampling interval is calculated to obtain the CPU utilization rate of the gateway.

[0029] Specifically, representative test games are deployed on terminal devices with WiFi connectivity, ensuring that each terminal device is connected to the target test gateway via a wireless LAN. This allows data traffic generated during game startup and operation to pass through the test gateway in real time. The pre-installed acceleration plugin within the test gateway continuously monitors data packet flows passing through the gateway. Based on a three-level serial matching structure consisting of an embedded IP address matching engine, port matching engine, and signature matching engine, it identifies incoming data flows step-by-step. Upon identifying traffic belonging to the target game, it immediately triggers the bandwidth resource scheduling module, allocating a fixed proportion of reserved bandwidth to the identified game traffic. For example, it configures 30% of the total outbound bandwidth to be independently allocated to the game channel, ensuring a low-latency, high-priority forwarding path for game data. During game operation, round-trip time (RTT) data is read in real time through the game client's built-in network diagnostic interface. This data reflects the average network communication latency between the client and the game server. All sampling data are recorded and accumulated at 10-second intervals to calculate the average game latency within one sampling period. UDP probe packets are continuously sent between the client device and the target game server to establish a high-frequency end-to-end link probe channel. The total number of probe packets sent and the number of lost packets without a response are recorded within a certain time period. The number of lost packets is divided by the total number of packets sent and multiplied by a percentage according to the packet loss rate calculation formula to obtain the game packet loss rate indicator. At the operating system level of the test gateway, based on the process resource monitoring mechanism of the Linux system, the stat file corresponding to the target acceleration program plugin process located in the / proc path is read. By parsing the cumulative user-mode time and kernel-mode time fields recorded in the file, the total CPU time slice occupied by the process at the current moment is calculated. Then, the ratio is calculated with the set time sampling interval to obtain the actual CPU resource utilization rate of the acceleration program in the current period, reflecting the processing load required by the plugin in processing game data streams.

[0030] In one specific embodiment, after running the test game on the terminal device based on the MQTT concurrent connection count and the Kafka cluster throughput, and obtaining the average game latency and gateway CPU utilization, the method further includes: The test game was triggered to switch from the first game server to the second game server; The test gateway detects that the IP address of the second game server has changed and records the first timestamp, and records the second timestamp after completing the acceleration path calculation for the second game server; Calculate the time difference between the second timestamp and the first timestamp to obtain the cross-server switching time.

[0031] Specifically, a test game with multi-server scheduling capabilities is run on the terminal device. By controlling game behavior or utilizing the game's own load balancing mechanism, the client is made to generate server switching triggers during operation. These triggers are achieved by simulating network fluctuations, manually switching server regions, or guiding game characters to different logical partitions. When the game client establishes a new session connection with the second game server after the switching operation, the destination IP address in its network data packets will change. This change is reflected in the data flow passing through the gateway as the destination address field switching from the first address family to the second address family. The acceleration program plugin deployed in the test gateway continuously monitors the data flow passing through the gateway and extracts the destination IP field of the data packets in real time in its traffic identification module. When multiple data packets are detected consecutively with destination IP addresses different from the previously cached server IPs, and the new IP address matches a candidate node in the known game server database, it is determined that the current terminal has completed the server switching action. When the switching action is first confirmed, the acceleration program records a current system timestamp as the first timestamp. Subsequently, it automatically triggers the path calculation module to send a new acceleration path request to the cloud path service. This request includes necessary parameters such as the new game server target IP address and the current gateway's exit address. The cloud path service performs path optimization calculations based on real-time topology data and policy algorithms, and returns a multi-level forwarding node sequence. Once the test gateway receives the path calculation result and completes the corresponding acceleration rule update and acceleration session switching operation, it records another system timestamp as the second timestamp. Subtracting the first timestamp from the second timestamp yields the complete time interval from the detection server to the completion of the new path configuration. This interval is defined as the cross-server switching time, quantifying the system's scheduling agility and collaborative efficiency in responding to server switching events.

[0032] In one specific embodiment, after obtaining the average game latency and gateway CPU utilization, the method further includes: Configure the test gateway to perform a full-load test scenario; Deploy a fault monitoring program to monitor the process survival status, heartbeat response status, and abnormal exit logs of the acceleration program plugin, record the number of fault events where the acceleration program process exits or becomes unresponsive for more than a threshold duration, and calculate the ratio of the number of fault events to the monitoring duration to obtain the system failure rate. Broadband internet access and IPTV services are run simultaneously on the test gateway. The number of times the broadband download speed decreases and the number of times the IPTV video stutters are recorded at monitoring intervals. The percentage of time without decrease or stuttering is calculated to obtain the basic service compatibility index.

[0033] Specifically, a full-load test scenario for the gateway is constructed. This involves simultaneously activating multiple functional modules on the test gateway and injecting high-intensity business loads. This includes the continuous operation of the acceleration plugin, a heartbeat mechanism with the MQTT Broker, a performance data reporting channel to the Kafka cluster, and periodically executed feature library update tasks, simulating the extreme working conditions experienced by equipment in a commercial environment. Under full-load conditions, a fault monitoring program is deployed. This program runs as a daemon process in the gateway's operating system, monitoring the acceleration plugin process's liveness at fixed sampling intervals. It obtains the target process identifier by polling the / proc file system to determine if the process is still active, and simultaneously listens for heartbeat responses from the MQTT communication channel. If no heartbeat response is received within a continuous sampling period and the process does not actively report its running status, it is considered a heartbeat anomaly. The fault monitoring program parses system log files in real time, especially exception stack traces and crash records under the / var / log path. If abnormal keywords such as "segfault," "core dumped," or "killed by signal" are found and the acceleration process name is located, it is marked as a process-level fault event. Whenever a process is detected to have abnormally exited or its unresponsive time exceeds a preset threshold (e.g., 30 seconds), it is recorded as a valid fault event and stored in the log buffer. The total number of fault events, N, is accumulated throughout the monitoring period, and the fault rate metric F = N / T × 100% is calculated using the total test duration T. The fault rate reflects the stability performance of the acceleration plugin under high load. Simultaneously, broadband internet access and IPTV video services are activated in parallel within the same test gateway. A continuous HTTP large file download task is executed on a terminal PC to simulate normal user data flow, while a high-definition video stream is stably played on the IPTV set-top box as the media service load. All services maintain complete paths in the gateway's NAT and QoS management modules. During the test period, the system monitoring task collects the download rate every 10 minutes. If the measured rate is lower than 95% of the contracted bandwidth, it is recorded as a download rate attenuation event. Simultaneously, every 10 minutes, the system checks for frame freezing, audio-visual asynchrony, or playback pauses exceeding 1 second in IPTV video playback; if any of these occur, they are recorded as a stuttering event. The percentage of abnormal events is obtained by adding the number of events of the two types and dividing by the total number of samples. Then, the percentage of abnormal events is subtracted from 1 to obtain the basic service compatibility index, which reflects the degree of impact of the gateway on the original basic network services when running the acceleration program plugin.

[0034] The gateway testing method in the embodiments of the present invention has been described above. The gateway testing system in the embodiments of the present invention is described below. Please refer to [link / reference]. Figure 2 One embodiment of the gateway testing system in this invention includes: Traffic identification module 201 is used to inject game traffic test sets into the test gateway based on the traffic generator and obtain the traffic identification accuracy. The device concurrent load module 202 is used to build cloud MQTT heartbeat connections and Kafka data reporting channels based on the traffic identification accuracy, and to inject device concurrent load to obtain the number of MQTT concurrent connections and Kafka cluster throughput. Run test module 203 to run test games on terminal devices based on the number of concurrent MQTT connections and the throughput of the Kafka cluster, and obtain the average game latency and gateway CPU utilization.

[0035] 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.

[0036] 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 a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods 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.

[0037] 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 testing method, characterized in that, include: The game traffic test set is injected into the test gateway based on the traffic generator, and the traffic identification accuracy is obtained. Based on the traffic identification accuracy, a cloud-based MQTT heartbeat connection and a Kafka data reporting channel are constructed, and concurrent load injection is performed on the device to obtain the number of concurrent MQTT connections and the throughput of the Kafka cluster. The test game was run on the terminal device based on the MQTT concurrent connection count and the Kafka cluster throughput to obtain the average game latency and gateway CPU utilization.

2. The gateway testing method according to claim 1, characterized in that, Before injecting the game traffic test set into the test gateway based on the traffic generator and obtaining the traffic identification accuracy, the following steps are also included: An acceleration program plugin is installed on the test gateway. The acceleration program plugin has an embedded IP address matching engine, a port matching engine, and a signature matching engine. The IP address matching engine, the port matching engine, and the signature matching engine are connected in series. Configure a game traffic template containing target IP address ranges, target port numbers, and application layer signatures on the traffic generator, and generate a game traffic test set based on the game traffic template.

3. The gateway testing method according to claim 2, characterized in that, The game traffic test set is injected into the test gateway based on the traffic generator, and the traffic identification accuracy is obtained, including: The game traffic test set is injected into the test gateway based on the traffic generator, and the identification result tags output by the test gateway and the game traffic tags injected by the traffic generator are collected. The ratio of the number of successfully identified data packets in the identification result label to the total number of data packets injected in the game traffic label is calculated, and the ratio is used as the traffic identification accuracy.

4. The gateway testing method according to claim 1, characterized in that, Based on the traffic identification accuracy, a cloud-based MQTT heartbeat connection and a Kafka data reporting channel are constructed, and concurrent load injection is performed on the devices to obtain the number of concurrent MQTT connections and the throughput of the Kafka cluster, including: Based on the traffic identification accuracy, an MQTT Broker and Kafka cluster are deployed on a cloud server. An MQTT heartbeat connection is established between the test gateway and the MQTT Broker, and the heartbeat self-healing restart time is calculated. Based on the test gateway, an acceleration request message is sent to the cloud path calculation service and the path calculation response time is returned. Based on the heartbeat self-healing restart time and the path calculation response time, a device concurrency simulation tool is deployed to perform concurrent load injection on the MQTT heartbeat connection and the Kafka data reporting channel to obtain the number of concurrent MQTT connections and the throughput of the Kafka cluster.

5. The gateway testing method according to claim 4, characterized in that, Deploy an MQTTBroker and Kafka cluster on a cloud server, establish an MQTT heartbeat connection with the MQTT Broker based on the test gateway, and calculate the heartbeat self-healing restart time, including: Deploy the MQTT Broker on the cloud server, start the acceleration module based on the test gateway to establish an MQTT heartbeat connection with the MQTT Broker, configure the heartbeat timeout threshold as the number of consecutive heartbeats without response, and configure the heartbeat sending interval. The MQTT Broker is simulated to receive a heartbeat message but does not return a heartbeat response. When the number of consecutive non-response counts reaches the heartbeat timeout threshold, the acceleration module is triggered to automatically restart, and the heartbeat timeout trigger time and restart completion time are recorded. The heartbeat self-healing restart time is calculated based on the heartbeat timeout trigger time and the restart completion time.

6. The gateway testing method according to claim 4, characterized in that, Based on the heartbeat self-healing restart time and the path calculation response time, a device concurrency simulation tool was deployed to perform concurrent load injection on the MQTT heartbeat connection and the Kafka data reporting channel to obtain the number of concurrent MQTT connections and the Kafka cluster throughput, including: Deploy the device concurrency simulation tool to generate simulated gateway devices, configure each simulated gateway device to send heartbeat messages to the MQTT Broker at heartbeat sending intervals, and send traffic statistics to the Kafka cluster at data reporting intervals, and perform concurrent load injection on the MQTT heartbeat connection and the Kafka data reporting channel; The number of concurrent MQTT connections is obtained based on the number of connections exchanging heartbeat messages within the statistical time window of the MQTT Broker. The throughput of the Kafka cluster is obtained based on the number of messages received per second by all partitions of the Kafka cluster.

7. The gateway testing method according to claim 1, characterized in that, Based on the MQTT concurrent connection count and the Kafka cluster throughput, a test game was run on the terminal device to obtain the average game latency and gateway CPU utilization, including: Running a test game on a terminal device triggers the test gateway to identify game traffic in real time and allocate reserved bandwidth for the game traffic. Record the average latency returned by the game client, continuously send UDP probe packets to calculate the ratio of lost packets to total packets sent, and obtain the game packet loss rate; The system file corresponding to the process identifier of the acceleration program plugin is read to obtain the process CPU time slice, and the ratio of the process CPU time slice to the sampling interval is calculated to obtain the CPU utilization rate of the gateway.

8. The gateway testing method according to claim 7, characterized in that, After running the test game on the terminal device based on the MQTT concurrent connection count and the Kafka cluster throughput, and obtaining the average game latency and gateway CPU utilization, the process also includes: The test game was triggered to switch from the first game server to the second game server; The test gateway detects that the IP address of the second game server has changed and records the first timestamp, and records the second timestamp after completing the acceleration path calculation for the second game server; Calculate the time difference between the second timestamp and the first timestamp to obtain the cross-server switching time.

9. The gateway testing method according to claim 1, characterized in that, After obtaining the game's average latency and gateway CPU utilization, the following is also included: Configure the test gateway to perform a full-load test scenario; Deploy a fault monitoring program to monitor the process survival status, heartbeat response status, and abnormal exit logs of the acceleration program plugin, record the number of fault events where the acceleration program process exits or becomes unresponsive for more than a threshold duration, and calculate the ratio of the number of fault events to the monitoring duration to obtain the system failure rate. Broadband internet access and IPTV services are run simultaneously on the test gateway. The number of times the broadband download speed decreases and the number of times the IPTV video stutters are recorded at monitoring intervals. The percentage of time without decrease or stuttering is calculated to obtain the basic service compatibility index.

10. A gateway testing system, characterized in that, The gateway testing system is used to perform the gateway testing method as described in any one of claims 1-9, and the gateway testing system comprises: The traffic identification module is used to inject game traffic test sets into the test gateway based on the traffic generator and obtain the traffic identification accuracy. The device concurrent load module is used to build cloud MQTT heartbeat connections and Kafka data reporting channels based on the traffic identification accuracy, and to inject device concurrent load to obtain the number of MQTT concurrent connections and Kafka cluster throughput. The test module is used to run test games on terminal devices based on the MQTT concurrent connection count and the Kafka cluster throughput, and to obtain the average game latency and gateway CPU utilization.

Images