Traffic allocation method based on multi-layer traffic classification and QoS queue control

Abstract

The application provides a traffic allocation method based on multi-layer traffic classification and QoS queue control, which sequentially classifies traffic layer by layer through a three-layer architecture formed by analyzing DNS reply logs, connection tracking meta-information and TLS handshake plaintext fields, and determines different target scheduling modes and parameter sets of HTB queues in a timing task pre-evaluation process, determines the target scheduling mode according to the service classification result in different traffic in periodic acquisition, and does not need to install CA certificates for man-in-the-middle decryption in the three-layer traffic classification process, and does not need to analyze HTTP / HTTPS application layer loads, which can significantly reduce device resource consumption and take into account privacy; after layer-by-layer traffic classification, high-frequency policy evaluation and low-frequency actual delivery are performed, which can effectively reduce network jitter caused by frequent modification of queue parameter sets and reduce the risk of inconsistent state after delivery failure.

Description

Technical Field

[0001] This invention relates to the field of digital information transmission technology, and specifically to a traffic allocation method based on multi-layer traffic classification and QoS queue control. Background Technology

[0002] With the increasing number of concurrent service scenarios in home networks, small office networks, and edge gateway devices, internet traffic is constantly expanding. When performing traffic analysis and application extraction on the face of massive and variable network data traffic, multiple services such as video-on-demand, live conferencing, web browsing, instant messaging, application downloads, and large file transfers may coexist in the network. Different services have different sensitivities to latency, jitter, packet loss rate, and bandwidth usage, often requiring timely monitoring to identify service differences and implement refined network data traffic management, ensure the quality of service (QoS) of critical services, prevent network congestion, and improve the overall efficiency of network data traffic utilization.

[0003] Commonly used traffic control methods include the following five types: The first type: Traffic identification schemes based on Deep Packet Inspection (DPI): These schemes identify traffic types by parsing application layer load, protocol characteristics, or packet content, and then use the identification results for bandwidth scheduling or priority control. This type of scheme has finer granularity, but usually requires continuous analysis of packet content, resulting in high computational resource consumption. It is also easily limited in scenarios with a high proportion of encrypted traffic. The second type: Scheduling schemes based on DNS resolution results: These schemes typically utilize the mapping relationship between domain names and IP addresses to achieve routing, traffic splitting, content distribution scheduling, or specific service identification. This type of scheme requires more sophisticated analysis of plaintext domain name information. The first category is traffic classification based on port, protocol, and connection characteristics. This involves coarsely classifying traffic using information such as five-tuples, port range, connection duration, and byte count. While simple to implement, this approach has limited accuracy, especially in modern applications where port 443 is commonly reused, making single-port judgment insufficient for practical needs. The second category is traffic identification based on machine learning or artificial intelligence models. This involves collecting traffic features and performing model inference to achieve classification, anomaly detection, or policy recommendation. This approach has some adaptability when there are sufficient samples, but it typically relies on training data, model maintenance, and runtime inference resources, making it unsuitable for long-term operation in resource-constrained edge router environments. The third category is traditional QoS queue control. This approach typically uses multiple mechanisms on Linux or OpenWrt platforms to shape and prioritize traffic. Existing dynamic QoS control schemes often tightly couple policy evaluation and policy delivery. Each change in evaluation results may directly modify the tc queue parameters, easily causing policy oscillations, inconsistent states after delivery failures, or frequent changes that impact online services.

[0004] For example, Chinese patent application number 201811412144.2, published on April 9, 2019, discloses a device for automatically identifying traffic and extracting application rules. This device consists of a traffic classification module, a traffic filtering module, an HTTP traffic automatic learning and analysis module, and a non-HTTP traffic feature extraction module. The traffic classification module comprises a traffic comparator and an HTTP traffic feature table. The traffic filtering module comprises a traffic filter and a traffic rule fingerprint database. The HTTP traffic automatic learning and analysis module comprises a traffic type judgment module, a feature string matching analyzer, a domain name and webpage title analyzer, and a server IP address analyzer. The non-HTTP traffic feature extraction module comprises a non-HTTP traffic recorder and a hexadecimal feature converter.

[0005] The aforementioned literature addresses the problem of ineffective handling of internet traffic updates by using a traffic comparator, traffic filter, traffic type judgment module, feature string matching analyzer, and hexadecimal feature converter to achieve automatic classification, filtering, and rule base generation of network traffic. However, different services have varying sensitivities to latency, jitter, packet loss rate, and bandwidth usage, often requiring traffic classification and QoS queue control at the router level. Existing QoS queue control methods may directly modify tc queue parameters with each evaluation result change, easily leading to policy oscillations, inconsistent states after failed deployments, or frequent changes impacting online services. Consequently, the aforementioned devices for handling internet traffic updates are costly to use on resource-constrained OpenWrt routers or edge gateways, and cannot perform layer-by-layer traffic filtering and reallocation. Furthermore, for different rule configurations, it is impossible to determine service classification results without obtaining plaintext information, or to determine service classification results simply and reliably without complex rule matching. Summary of the Invention

[0006] The purpose of this invention is to provide a traffic allocation method based on multi-layer traffic classification and QoS queue control, which can accurately classify traffic for various network services and achieve secure and controllable policy evaluation and bandwidth allocation control, while taking into account both classification accuracy and operational stability.

[0007] To achieve the above objectives, this invention provides a traffic allocation method based on multi-layer traffic classification and QoS queue control, comprising the following steps: S1. Preset built-in rules and user rules corresponding to domain names and business categories; extract the matching mapping relationship between domain names and IP addresses from the DNS response log and form a domain name-IP cache. Then, according to the preset built-in rules and user rules, map the extracted domain names to the matching business categories. Next, in the PREROUTING stage, pre-tag the traffic of subsequent connections. For pre-tagded traffic, output the business classification result corresponding to the pre-tagded traffic. For untagded traffic, read the metadata in the connection tracking table of untagded traffic, classify the untagded traffic according to the connection characteristics corresponding to the metadata, and then output the business classification result corresponding to the untagded traffic. S2. During the pre-evaluation of the scheduled task, the real-time bandwidth ratio of different traffic in the HTB queue is read, and the congestion situation is determined based on the statistics of different traffic. Then, based on the service classification results of different traffic, the congestion situation, and the current policy status, the target scheduling mode and bandwidth allocation results are determined and written only to the log file. Then, the distribution phase begins. In the queue distribution module, it is verified whether the new parameter set distributed to the HTB queues corresponding to different traffic categories is the same as the preset target parameter set, so as to determine whether to change the parameter set of the HTB queue. S3. Periodically determine the service classification results and congestion status in different traffic, and trigger the adoption of the existing target scheduling mode within a preset time according to the service classification results and congestion status in different traffic. When the number of consecutive hits exceeds the preset number, a new target scheduling mode and HTB queue parameter set are used for allocation.

[0008] The above method classifies traffic layer by layer through a multi-layered architecture formed by parsing DNS reply logs and connection tracking metadata. The first-layer classification, based on DNS reply log parsing, boasts a high hit rate and low latency, enabling rapid pre-classification of most common services. The second-layer classification, based on connection tracking metadata for empty packets in the firewall, avoids the constraint of DNS reply log integrity, re-identifying traffic unmarked in the first-layer classification. Furthermore, neither layer-two traffic classification requires installing CA certificates for man-in-the-middle decryption, nor does it require parsing HTTP / HTTPS application layer payloads, significantly reducing device resource consumption while maintaining privacy. After layer-by-layer traffic classification, a scheduled task performs a pre-evaluation to determine the classification results for different traffic services. After pre-evaluating the target scheduling mode based on congestion conditions, and determining whether to reissue the parameter set of the HTB queue, the existing scheduling mode is maintained only if new triggering occurs during the cooldown period (e.g., within a preset time). A new scheduling mode is adopted when multiple triggering occurs. This high-frequency policy evaluation and low-frequency actual issuance effectively reduce network jitter caused by frequent modifications to the queue parameter set and mitigate the risk of inconsistent states after issuance failures. Furthermore, by maintaining complete audit logs of the service classification results for different traffic types, the target scheduling mode corresponding to congestion conditions, and bandwidth allocation records, it is possible to trace problems. This accurate traffic classification of various network services enables secure and controllable policy evaluation and bandwidth allocation control, balancing classification accuracy and operational stability.

[0009] Furthermore, in step S1, both the preset built-in rules and user rules include domain name pattern, service category, confidence level, and optional remarks. The user rules are classification strategies adjusted by the user according to the actual network environment, and user rules take precedence over built-in rules in matching. The process also includes steps S1.1 to S1.3. S1.1 Read the CNAME alias chain in the DNS response log record, then trace the original domain name of the CNAME alias chain and determine whether it hits the built-in rule or user rule. If yes, proceed to step S1.2; if no, and the metadata can be determined, otherwise proceed to step S1.3. S1.2 Write the IP address corresponding to the domain name into the DNS classification cache and record the validity period. Then construct firewall rules according to the DNS classification cache results. In the PREROUTING stage, pre-label the traffic according to the IP address. The pre-label is fwmark. Match the pre-label with the preset IP rules to the corresponding routing table to determine the protocol type, destination port, source port, cumulative number of bytes, cumulative number of packets and average packet length. According to the preset built-in rules, classify the connections in the routing table according to the business results. S1.3 For traffic that is marked as empty by the firewall, it is determined as untagged traffic. The connection tracking metadata of the untagged traffic is determined, and the service classification result is determined based on the metadata.

[0010] The above settings enable traffic connection to be pre-labeled in most common business scenarios through domain name-IP address mapping. The pre-labeling method calls the pre-labeling method in Linux, which can quickly complete the first layer of classification of connection traffic and improve the efficiency of subsequent traffic diagnosis.

[0011] Furthermore, step S1.3 includes: steps S1.3.3 to S1.3.2. S1.3.1 Read the metadata of each active connection in the connection tracking table of untagged traffic. The metadata includes protocol type, destination port, source port, cumulative number of bytes, cumulative number of packets, and average packet length. Determine whether the metadata of each active connection of untagged traffic can be weakly classified according to the built-in rules. If it can be weakly classified, output the classification result after weak classification as the business classification result; otherwise, proceed to step S1.3.2. S1.3.2. The metadata of active connections in the unlabeled traffic that cannot be weakly classified is judged as other low-confidence categories and set as the business classification result.

[0012] The above settings, based on the first-level traffic classification, further classify untagged traffic using metadata from the connection tracking table. This second-level traffic classification can be achieved without relying on plaintext payloads from the application layer, meaning it does not require identifying the specific application type of the data packet. This avoids interference from encrypted traffic when it is the dominant type, thus enabling rapid identification of the second-level traffic classification.

[0013] Furthermore, step S1.3.1 includes: determining whether it is a specific game platform port or a typical media protocol port based on the target port and built-in rules; determining whether it has the characteristics of large-volume download based on the cumulative number of bytes, cumulative number of packets, average packet length, and built-in rules; assigning a low-latency confidence level to the specific game platform port; assigning a streaming media confidence level to the typical media protocol port; assigning a batch download confidence level to the characteristics of large-volume download; and assigning a default low confidence level to general ports that cannot be clearly determined.

[0014] The above settings, for encrypted traffic outside of pre-tagged or untagged traffic, based on the third-level classification of the plaintext field of the TLS handshake, can identify encrypted traffic that cannot be identified in the first and second-level classifications. This can improve the identification rate of traffic blind spots in scenarios such as excessively long CNAME alias chains and missing DNS response logs. As the proportion of encrypted traffic continues to increase, this can effectively improve the traffic classification coverage.

[0015] Furthermore, step S1 includes: steps S1.4.1-S1.4.3. S1.4.1 Determine whether there is resolvable TLS handshake information in the encrypted traffic. If so, read the greeting message of the TLS handshake phase, extract the SNI plaintext field in the greeting message, and parse out the domain name corresponding to the SNI plaintext field; otherwise, proceed to step S1.4.3. S1.4.2 Determine whether the domain name corresponding to the SNI plaintext field matches the built-in rules or user rules. If yes, add the IP address corresponding to the domain name in the SNI plaintext field to the DNS classification cache, then map the corresponding IP address to the matching service category, and output the service classification result corresponding to the encrypted traffic; otherwise, proceed to step S1.4.3. S1.4.3. Encrypted traffic that cannot be parsed to obtain TLS handshake information and encrypted traffic that cannot match built-in rules or user rules are categorized as unidentified traffic, and the business classification results corresponding to the unidentified traffic are output.

[0016] The above settings, based on the second-layer traffic classification, use a third-layer traffic classification to compensate for the lack of traffic identification caused by the first-layer traffic classification (domain name not matched in DNS response logs), the lack of weak classification for established active connections in the second-layer traffic classification, or multiple websites sharing the same set of CDN (Content Delivery Network) cache node resources. Thus, through progressive layer-by-layer classification and identification, and without parsing application-layer encrypted payload content during the three-layer traffic classification process, it can achieve rapid classification layer by layer without parsing application-layer encrypted payload content, effectively reducing device resource consumption.

[0017] Furthermore, step S2 includes: steps S2.1 to S2.2. S2.1 During the scheduled pre-evaluation phase, after triggering a cron scheduled task with a preset default interval, the results of different service classifications, congestion status, and policy status of the current traffic are collected. Then, the current traffic target scheduling mode and bandwidth allocation results are analyzed and written to a structured JSONL log file. The distribution phase is initiated through manual intervention or preset trigger conditions. The target scheduling mode includes low latency priority mode, streaming media priority mode, batch limiting mode, or balanced mode. S2.2 During the distribution phase, read the parameter set of the current HTB queue containing rate, upper limit and priority to form a complete snapshot. Based on the latest strategy suggestion in the allocation results, distribute new parameter sets to different types of HTB queues. After distribution, verify whether the parameter sets of different types of HTB queues are the same as the preset target parameter set. If so, keep the new parameter set effective; otherwise, restore the parameter set of the HTB queue to the snapshot state before distribution.

[0018] The above settings, by combining high-frequency evaluation in the evaluation phase with low-frequency distribution in the distribution phase, can effectively reduce the risk of jitter and error propagation in strategy decisions.

[0019] Furthermore, in the strategy decision module of step S3, based on the periodically collected network quality indicators, the network congestion situation is divided into three levels: normal, mild congestion, and severe congestion. Then, it switches between the cooling time and the number of consecutive hits of built-in rules or user rules through a dual mechanism. When it is in the continuous hit state and high-latency services, streaming media services, or batch download services are detected to be dominant, it changes to the corresponding target scheduling mode based on the current network congestion status. When it is in the cooling time window, it maintains the original target scheduling mode.

[0020] The above settings can avoid frequent switching of strategy decisions due to instantaneous network fluctuations, and thus prioritize the connectivity of basic traffic connections when the proportion of traffic categories is low or the proportion of unknown traffic is high.

[0021] Furthermore, following step S1.4.3, the following is also included: The unidentified category traffic from step S1.4.3 is aggregated and recorded. Then, the frequency and number of occurrences, associated IP samples, and alias chain samples are statistically analyzed to generate corresponding candidate matching patterns. The domain names and statistical sample data corresponding to the unidentified category traffic are then exported. The business classification of the unidentified category traffic is determined through offline intelligent analysis or manual assisted analysis, forming candidate rules containing domain name patterns, business categories, confidence levels, and descriptive information. These candidate rules are then verified. Verified and confirmed candidate rules are saved, and built-in rules take precedence over candidate rules. These rules participate in the traffic classification rule matching in steps S2 and S3 during the next round of traffic classification and allocation. Meanwhile, the candidate rules are continuously iterated and improved in each round of traffic classification and allocation.

[0022] The above settings can effectively improve the classification coverage of unidentified traffic. By continuously iterating and improving the candidate rules and participating in the next round of traffic classification and allocation, the matching rate of unidentified traffic categories can be improved, thereby improving the accuracy of traffic classification.

[0023] Furthermore, the business classification results include low-latency category, streaming media category, batch download category, or other categories.

[0024] The above settings allow you to focus on the most prominent business types. Attached Figure Description

[0025] Figure 1 This is a flowchart of the process of the present invention.

[0026] Figure 2 This is a diagram of the overall architecture of the present invention.

[0027] Figure 3 This is a flowchart of the three-layer flow classification in this invention.

[0028] Figure 4 This is a flowchart of the evaluation and distribution phases in this invention.

[0029] Figure 5 This is a flowchart of matching candidate rules for unidentified category traffic in this invention.

[0030] Figure 6 This is an interface diagram during the compilation process of this invention. Detailed Implementation

[0031] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0032] like Figure 1-6 As shown, a traffic allocation method based on multi-layer traffic classification and QoS queue control is implemented through a control system. The control system includes a DNS domain name mapping module, a rule management module, a firewall classification and marking module, a connection tracking and diagnostic module, a TLS SNI supplementation module, a traffic analysis module, a policy decision module, an adaptive bandwidth allocation module, and a queue distribution module. In this embodiment, the control system is deployed on an OpenWrt router, and external devices connect to the OpenWrt router wirelessly. The OpenWrt router is an embedded Linux distribution primarily used in embedded devices such as routers. The allocation method includes the following specific steps: S1. In the DNS domain name mapping module, the matching mapping relationship between domain names and IP addresses is extracted from the DNS reply log of DNSmasq (a tool for configuring DNS and DHCP, suitable for small networks, providing DNS functions and optional DHCP functions) and a domain name-IP cache is formed. Then, according to the built-in rules and user rules of the rule management module, the domain name is mapped to the matching service category. Next, in the PREROUTING stage of the firewall classification and marking module, the traffic of subsequent connections is pre-labeled, and the service classification result corresponding to the pre-labeled traffic is output. In this embodiment, the built-in rules include domain name patterns, service categories, confidence levels and optional remarks that support exact matching and wildcard matching. The user rules are the classification strategies adjusted by the user according to the actual network environment, and the user rules take precedence over the built-in rules for matching. Specifically, this includes steps S1.1 to S1.3. S1.1 Read the CNAME alias chain in the DNS response log record, then trace the original domain name of the CNAME (mapping record or alias record) alias chain and determine whether it hits the built-in rule or user rule. If yes, proceed to step S1.2; if no, and the metadata can be determined, otherwise proceed to step S1.3; if no, and the metadata cannot be determined, determine that it is encrypted traffic other than pre-labeled and unlabeled traffic, and proceed to step S1.4. S1.2 Write the IP address corresponding to the domain name into the DNS classification cache and record the validity period (TTL). Then, construct firewall rules in the firewall classification and marking module according to the DNS classification cache results. In the PREROUTING stage, pre-label the traffic according to the IP address. The pre-labeling is fwmark. Match the pre-labeled routing table with the preset IP rules to determine the protocol type, destination port, source port, cumulative byte count, cumulative packet count, and average packet length. According to the preset built-in rules, perform service classification on the connections in the routing table and output the service classification results corresponding to the pre-labeled traffic. In this way, by pre-labeling the traffic based on the domain name-IP address mapping, the first layer of classification of connection traffic can be completed quickly to improve the efficiency of subsequent traffic classification and diagnosis. S1.3. For traffic that is not marked with an empty firewall tag, it is determined as untagged traffic. The connection tracking metadata of the untagged traffic is determined, and the service classification result is determined based on the metadata. Specifically, this includes steps S1.3.3~ S1.3.2, S1.3.1 In the connection tracing and diagnostic module, read the metadata of each active connection in the connection tracing table of untagged traffic. In this embodiment, the metadata includes protocol type, destination port, source port, cumulative byte count, cumulative packet count, and average packet length. Determine whether the metadata of each active connection of untagged traffic can be weakly classified according to preset built-in rules. If it can be weakly classified, the metadata of different active connections is judged to be of different confidence levels. In this embodiment, determine whether it is a specific game platform port or a typical media protocol port according to the target port and built-in rules. Determine whether it is a large-volume download feature according to the cumulative byte count, cumulative packet count, average packet length, and built-in rules. Assign a low-latency confidence level to specific game platform ports, a streaming media confidence level to typical media protocol ports, a batch download confidence level to large-volume download features, and assign a default low confidence level to general ports that cannot be clearly determined. S1.4 classifies the metadata of active connections in unlabeled traffic that cannot be weakly classified as other low-confidence traffic, and identifies the unlabeled traffic corresponding to the other low-confidence traffic as encrypted traffic.

[0033] In this embodiment, the SNI plaintext field in the greeting message corresponding to the encrypted traffic is read in the TLS SNI supplement module, the corresponding domain name information is input into the domain name-IP cache in reverse, and the service classification results corresponding to the encrypted traffic are output respectively; specifically including: S1.4.1-S1.4.3; S1.4.1 Determine whether there is resolvable TLS handshake information in the encrypted traffic. If so, read the ClientHello message in the TLS handshake phase, extract the SNI (Server Name Indicator) plaintext field in the message, and parse out the domain name corresponding to the SNI plaintext field; otherwise, proceed to step S1.4.3. S1.4.2 Determine whether the domain name corresponding to the SNI plaintext field matches the built-in rules or user rules of the rule management module. If yes, add the IP address corresponding to the domain name of the SNI plaintext field to the DNS classification cache, then map the corresponding IP address to the matching service category, and output the service classification result corresponding to the encrypted traffic; otherwise, proceed to step S1.4.3. S1.4.3. Encrypted traffic that cannot be parsed to obtain TLS handshake information and encrypted traffic that cannot match built-in rules or user rules are categorized as unidentified traffic, and the business classification results corresponding to the unidentified traffic are output.

[0034] S2. In the traffic analysis module, read the service classification results, congestion indicators, and policy status of different traffic types in the evaluation phase. In this embodiment, the congestion indicators include round-trip time (RTT), packet loss rate, and jitter. The congestion situation can be determined based on the congestion indicators. The congestion situation includes normal, mild congestion, and severe congestion. Severe congestion is defined as RTT, packet loss rate, and jitter being more than 5 times the preset value. Mild congestion is defined as RTT, packet loss rate, and jitter being more than 1.5 times the preset value. Normal congestion is defined as RTT, packet loss rate, and jitter being less than the preset value. The current network evaluation result is generated and written to the log file. Then, the distribution phase begins. In the queue distribution module, it is verified whether the new parameter set distributed to the HTB queues corresponding to different traffic types is the same as the preset target parameter set to determine whether to change the parameter set of the HTB queue. Specifically, this includes steps S2.1 to S2.2. S2.1 During the timed pre-evaluation phase, after triggering a cron job with a preset default interval of one minute, the results of different service classifications, congestion status, and policy status of the current traffic are collected. Then, the results are analyzed to obtain the current traffic target scheduling mode and bandwidth allocation estimation results, and written to a structured JSONL log file. The distribution phase is initiated through manual intervention or preset trigger conditions. In this embodiment, the allocation results also include network congestion status level, bandwidth ratio, classification quality, and DNS cache statistics.

[0035] S2.2 During the distribution phase, a complete snapshot is formed by reading the parameter set of the current HTB queue, including rate, ceiling, and priority. Based on the latest policy recommendations in the network evaluation results, new parameter sets are distributed to different categories of HTB queues. After distribution, it is verified whether the parameter sets of different categories of HTB queues are the same as the preset target parameter set. If they are the same, the new parameter sets are kept in effect; otherwise, if a snapshot anomaly or incomplete snapshot occurs during the distribution process, the HTB queue is restored to the snapshot state before distribution to ensure that network forwarding is not affected. In this way, by combining the high-frequency evaluation in the evaluation phase with the low-frequency distribution in the distribution phase, the risk of policy decision jitter and error propagation can be effectively reduced.

[0036] S3. The strategy decision module outputs the target scheduling mode corresponding to different traffic based on the current network assessment results. Then, the adaptive bandwidth allocation module generates the bandwidth guarantee value for different service categories corresponding to different traffic and writes it to the log file. This ensures that the service corresponding to the traffic maintains its operating rate without degradation when the network is congested.

[0037] Following step S1.4.3, the unidentified category traffic from step S1.4.3 is aggregated and recorded. Then, the frequency and number of occurrences, associated IP samples, and alias chain samples are statistically analyzed to generate corresponding candidate matching patterns. The domain names corresponding to the unidentified category traffic and the statistical sample data are exported. The business classification of the unidentified category traffic is determined through offline intelligent analysis or manual assisted analysis, forming candidate rules containing domain name patterns, business categories, confidence levels, and descriptive information. These candidate rules are then validated. Validated and confirmed candidate rules are written into the rule base of the rule management module, with built-in rules taking precedence over candidate rules. These candidate rules participate in the traffic classification rule matching of steps S2 and S3 in the next round of traffic classification allocation. Simultaneously, the candidate rules are continuously iterated and improved in each round of traffic classification allocation, effectively increasing the classification coverage of unidentified traffic. By continuously iterating and improving candidate rules and participating in the next round of traffic classification allocation, the matching rate of unidentified category traffic can be improved, thereby increasing the accuracy of traffic classification.

[0038] In the strategy decision module of step S3, the network congestion status is divided into three levels: normal, mild congestion, and severe congestion based on the periodically collected network quality indicators. Then, it switches between the cooling time (cooldown_min) and the number of consecutive hits of built-in rules or user rules (debounce_count) through a dual mechanism. When it is in the continuous hit state and high-latency services such as games, video conferencing, streaming media services, or batch download services are detected to be dominant, it changes to the corresponding target scheduling mode based on the current network congestion status. In this embodiment, the target scheduling modes include low latency priority mode, streaming media priority mode, batch restriction mode, and balanced mode. When it is in the cooling time window, the original target scheduling mode is maintained.

[0039] In this embodiment, the traffic service classification result includes low latency, streaming media, batch download, or other categories.

[0040] The working principle of this invention is as follows: Traffic is classified layer by layer through a multi-layered architecture formed by parsing DNS reply logs and connection tracking metadata. In the first-layer classification based on DNS reply log parsing, the hit rate is high and the latency is low, enabling rapid pre-classification of most common services. For the second-layer classification of empty data packets in the firewall based on connection tracking metadata, the constraint of DNS reply log integrity can be avoided, allowing for the re-identification of traffic not marked in the first-layer classification. For the third-layer classification of encrypted traffic (excluding pre-labeled and unlabeled traffic) based on the TLS handshake plaintext field, encrypted traffic that could not be identified in the first and second-layer classifications can be identified. This improves the identification rate of traffic blind spots in scenarios such as excessively long CNAME alias chains and missing DNS reply logs. Thus, as the proportion of encrypted traffic continues to increase, it effectively improves traffic classification coverage. Furthermore, no CA certificate needs to be installed for man-in-the-middle decryption during the multi-layer traffic classification process, and no HT parsing is required. The TP / HTTPS application layer payload significantly reduces device resource consumption while maintaining privacy. After performing layer-by-layer traffic classification, a scheduled task performs a pre-evaluation. Then, based on the classification results and congestion status of different traffic services, a target scheduling mode is determined. After the pre-evaluation, it is determined whether to reissue the parameter set of the HTB queue. During periodic evaluation, the existing scheduling mode is maintained only if there are new triggers during the cooldown period (e.g., within a preset time). A new scheduling mode is adopted when there are multiple triggers. This high-frequency policy evaluation and low-frequency actual issuance effectively reduce network jitter caused by frequent modifications to the queue parameter set and reduce the risk of inconsistent states after issuance failure. At the same time, by retaining complete audit logs for problem tracing, the target scheduling mode and bandwidth allocation records corresponding to the service classification results and congestion status of different traffic services can be accurately classified, enabling secure and controllable policy evaluation and bandwidth allocation control, while ensuring classification accuracy and operational stability.

Claims

1. A traffic steering method based on multi-layer traffic classification and QoS queue control, characterized in that: Includes the following steps: S1. Preset built-in rules and user rules corresponding to domain names and business categories; extract the matching mapping relationship between domain names and IP addresses from the DNS response log, and then map the extracted domain names to the matching business categories according to the preset built-in rules and user rules. Next, in the PREROUTING stage, pre-tag the traffic of subsequent connections. For pre-tagded traffic, output the business classification result corresponding to the pre-tagded traffic; for untagded traffic, Read the metadata from the connection tracking table of untagged traffic, classify the untagged traffic according to the connection characteristics corresponding to the metadata, and then output the service classification results corresponding to the untagged traffic. S2. During the pre-evaluation of the scheduled task, the real-time bandwidth ratio of different traffic in the HTB queue is read, and the congestion situation is determined based on the statistics of different traffic. Then, based on the service classification results of different traffic, the congestion situation, and the current policy status, the target scheduling mode and bandwidth allocation results are determined and written only to the log file. Then, the distribution phase begins. In the queue distribution module, it is verified whether the new parameter set distributed to the HTB queues corresponding to different traffic categories is the same as the preset target parameter set, so as to determine whether to change the parameter set of the HTB queue. S3. Periodically determine the service classification results and congestion status in different traffic, and trigger the adoption of the existing target scheduling mode within a preset time according to the service classification results and congestion status in different traffic. When the number of consecutive hits exceeds the preset number, a new target scheduling mode and HTB queue parameter set are used for allocation. 2.The traffic steering method based on multi-layer traffic classification and QoS queue control according to claim 1, characterized in that: In step S1, the preset built-in rules include domain name pattern, service category, confidence level, and optional remarks. The user rules are classification strategies adjusted by the user according to the actual network environment, and the user rules take precedence over the built-in rules. The steps also include: steps S1.1 to S1.

3. S1.1 Read the CNAME alias chain in the DNS response log record, then trace the original domain name of the CNAME alias chain and determine whether it hits the built-in rule or user rule. If yes, proceed to step S1.2; if no, and the metadata can be determined, proceed to step S1.

3. S1.2 Write the IP address corresponding to the domain name into the DNS classification cache and record the validity period. Then construct firewall rules according to the DNS classification cache. In the PREROUTING stage, pre-label the traffic according to the IP address. The pre-label is fwmark. Match the pre-label with the preset IP rules to the corresponding routing table to determine the protocol type, destination port, source port, cumulative number of bytes, cumulative number of packets and average packet length. According to the preset built-in rules, classify the connections in the routing table according to the business results. S1.3 For traffic that is marked as empty by the firewall, it is determined as untagged traffic. The connection tracking metadata of the untagged traffic is determined, and the service classification result is determined based on the metadata. 3.The traffic steering method based on multi-layer traffic classification and QoS queue control according to claim 1, characterized in that: Step S1.3 includes: steps S1.3.3 to S1.3.

2. S1.3.1 Read the metadata of each active connection in the connection tracking table of untagged traffic. The metadata includes protocol type, destination port, source port, cumulative number of bytes, cumulative number of packets, and average packet length. Determine whether the metadata of each active connection of untagged traffic can be weakly classified according to the built-in rules. If it can be weakly classified, output the classification result after weak classification as the business classification result; otherwise, proceed to step S1.3.

2. S1.3.

2. The metadata of active connections in the unlabeled traffic that cannot be weakly classified is judged as other low-confidence categories and set as the business classification result.

4. The traffic steering method based on multi-layer traffic classification and QoS queue control according to claim 1, characterized in that: Step S1.3.1 includes: determining whether it is a specific game platform port or a typical media protocol port based on the target port and built-in rules; determining whether it has the characteristics of large-volume download based on the cumulative number of bytes, cumulative number of packets, average packet length, and built-in rules; assigning low-latency confidence to specific game platform ports; assigning streaming media confidence to typical media protocol ports; assigning batch download confidence to large-volume download characteristics; and assigning default other low confidence to general ports that cannot be clearly determined.

5. The traffic steering method based on multi-layer traffic classification and QoS queue control according to claim 2, characterized in that: Step S1 also includes: forming a domain-IP cache based on the matching mapping relationship between extracted domain names and IP addresses. Step S1.1 also includes: if the metadata cannot be determined, it is determined to be encrypted traffic other than pre-tagged and untagged traffic. The domain name information is determined by extracting the SNI plaintext field from the greeting message corresponding to the encrypted traffic. The domain name information is then input into the domain-IP cache in reverse, and the business classification results corresponding to the encrypted traffic are output respectively.

6. The traffic allocation method based on multi-layer traffic classification and QoS queue control according to claim 1, characterized in that: Step S1.4 includes: steps S1.4.1-S1.4.

3. S1.4.1 Determine whether there is resolvable TLS handshake information in the encrypted traffic. If so, read the greeting message of the TLS handshake phase, extract the SNI plaintext field in the greeting message, and parse out the domain name corresponding to the SNI plaintext field; otherwise, proceed to step S1.4.

3. S1.4.2 Determine whether the domain name corresponding to the SNI plaintext field matches the preset built-in rules or user rules. If yes, add the IP address corresponding to the domain name in the SNI plaintext field to the DNS classification cache, then map the corresponding IP address to the matching service category, and output the service classification result corresponding to the encrypted traffic; otherwise, proceed to step S1.4.

3. S1.4.

3. Encrypted traffic that cannot be parsed to obtain TLS handshake information and encrypted traffic that cannot match built-in rules or user rules are categorized as unidentified traffic, and the business classification results corresponding to the unidentified traffic are output.

7. The traffic allocation method based on multi-layer traffic classification and QoS queue control according to claim 1, characterized in that: Step S2 includes: steps S2.1 to S2.

2. S2.1 During the scheduled pre-evaluation phase, after triggering the cron scheduled task with the preset default interval, the results of different service classifications, congestion status and policy status of the current traffic are collected. Then, the current traffic target scheduling mode and bandwidth allocation results are analyzed and written to the structured JSONL log file. The distribution phase is entered through manual intervention or preset trigger conditions. The target scheduling mode includes low latency priority mode, streaming media priority mode, batch limiting mode or balanced mode. S2.2 During the distribution phase, read the parameter set of the current HTB queue containing rate, upper limit, and priority to form a complete snapshot. Based on the latest strategy recommendations in the allocation results, distribute new parameter sets to different types of HTB queues. After distribution, verify whether the parameter sets of different types of HTB queues are the same as the preset target parameter set. If so, keep the new parameter set effective; otherwise, restore the parameter set of the HTB queue to the parameter set of the HTB queue corresponding to the snapshot state before distribution.

8. The traffic allocation method based on multi-layer traffic classification and QoS queue control according to claim 7, characterized in that: In the strategy decision module of step S3, the network congestion is divided into three levels: normal, mild congestion, and severe congestion, based on the periodically collected network quality indicators. Then, it switches between the cooling time and the number of consecutive hits of built-in rules or user rules. When it is in the continuous hit state and high-latency services, streaming media services, or batch download services are detected to be dominant, it changes to the corresponding target scheduling mode based on the current network congestion situation. When it is in the cooling time window, it maintains the original target scheduling mode.

9. The traffic allocation method based on multi-layer traffic classification and QoS queue control according to claim 7, characterized in that: Following step S1.4.3, the following is also included: The unidentified category traffic from step S1.4.3 is aggregated and recorded. Then, the frequency and number of occurrences, associated IP samples, and alias chain samples are statistically analyzed, and corresponding candidate matching patterns are generated. Then, the domain names corresponding to the unidentified category traffic and the statistical sample data are exported. The business classification of the unidentified category traffic is judged through offline intelligent analysis or manual assisted analysis, forming candidate rules containing domain name patterns, business categories, confidence levels, and descriptive information. These candidate rules are then verified. The verified and confirmed candidate rules are saved, and the built-in rules take precedence over the candidate rules. They participate in the traffic classification rule matching of steps S2 and S3 in the next round of traffic classification and allocation. Meanwhile, the candidate rules are continuously iterated in each round of traffic classification and allocation.

10. The traffic allocation method based on multi-layer traffic classification and QoS queue control according to claim 1, characterized in that: The business classification results include low latency, streaming media, batch download, or other categories.

Images