Intelligent protocol dynamic switching method, system and device for multi-path network and medium

Abstract

The invention relates to an intelligent protocol dynamic switching method, system and device for a multi-path network and a medium. According to the method, the natural language requirement of a user is converted into a structured service constraint condition capable of being analyzed by a machine in real time, the element reinforcement learning strategy network is driven to be fused with a dynamic network state to generate a joint optimization decision vector of protocol selection and path distribution, and accurate matching of an optimal transmission protocol is achieved based on a standardized protocol behavior feature library. Intelligent scheduling of multi-path traffic is synchronously triggered, so that accurate understanding and quantitative translation of service intentions, online autonomous evolution and cross-scene generalization of transmission strategies and optimal dynamic allocation of multi-path resources are realized; the core problems of lack of service awareness, strategy stiffness, difficulty in protocol extension, unbalanced resource utilization and switching interruption in the traditional scheme are systematically solved.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of intelligent network control, and particularly relates to an intelligent protocol dynamic switching method, system, device and medium for a multi-path network. BACKGROUND

[0002] In the current network communication field, a multi-path transmission technology improves the reliability and throughput of data transmission by simultaneously utilizing multiple network paths, and has become a key means to improve the quality of network services. However, the existing mainstream multi-path protocols (such as MPTCP, QUIC, etc.) have significant limitations in dynamically adapting to complex business requirements. The core problem is that the protocol switching mechanism lacks the ability to perceive the upper-layer business intent, and network administrators still need to rely on artificial experience to preset static rules, resulting in real-time video, financial transactions and other high-sensitive businesses sharing the same transmission strategy as ordinary data transmission, which is difficult to meet the differentiated quality of service requirements.

[0003] On the other hand, the integration and application of new transmission protocols further limit system adaptability. When new congestion control algorithms such as BBR and CUBIC are released, existing systems need to modify the core code library to support them, resulting in a long protocol upgrade cycle of several months. Even after integration, protocol switching still needs to interrupt existing connections to rebuild sessions, causing business flow to stall or even interrupt. This rigidity makes it difficult for the network to quickly respond to sudden changes in traffic patterns.

[0004] Therefore, it is necessary to build a new intelligent protocol dynamic switching mechanism that can accurately understand the business intent and achieve autonomous selection and seamless switching of protocols in a multi-path network environment. SUMMARY

[0005] Therefore, it is necessary to build a new intelligent protocol dynamic switching mechanism that can accurately understand the business intent and achieve autonomous selection and seamless switching of protocols in a multi-path network environment.

[0006] In a first aspect, the application provides an intelligent protocol dynamic switching method for a multi-path network, comprising:

[0007] S1, performing semantic analysis and keyword extraction on a natural language business requirement description input by a user to generate a structured intent analysis result; based on the structured intent analysis result, performing similarity matching through a pre-defined SLA template library to generate a business constraint condition object;

[0008] S2, based on the business constraint condition object and a multi-path network state data set collected by a probe agent deployed on a network node, performing action space probability calculation through a meta-reinforcement learning policy network to generate an action vector including a protocol selection weight and a path allocation ratio;

[0009] S3. Based on the transmission protocol specification information, the behavioral characteristics of various transmission protocols are standardized and characterized through feature extraction and quantization to generate a protocol behavior feature vector library.

[0010] S4. For the protocol selection weighting part based on action vectors, the optimal protocol feature vector is determined by the maximum value index positioning algorithm; based on the optimal protocol feature vector, the target protocol identifier is generated by performing K-nearest neighbor similarity retrieval in the protocol behavior feature vector library.

[0011] S5. Based on the path allocation ratio of the target protocol identifier and action vector, multipath transmission is performed proportionally according to the target protocol.

[0012] Secondly, this application also provides an intelligent protocol dynamic switching system for multi-path networks, used to implement the method described in the first aspect, the system comprising:

[0013] The business intent intelligent parsing module is used to perform semantic parsing and keyword extraction on the natural language business requirement description input by the user, and generate structured intent parsing results; based on the structured intent parsing results, similarity matching is performed through a predefined SLA template library to generate business constraint condition objects;

[0014] The dynamic strategy optimization decision module is used to calculate the action space probability based on the multi-path network state dataset collected by the probe agents deployed on the network nodes and the business constraint objects. It generates action vectors including protocol selection weights and path allocation ratios by performing action space probability calculation through the meta-reinforcement learning policy network.

[0015] The protocol behavior feature library construction module is used to standardize the behavioral characteristics of various transmission protocols based on transmission protocol specification information, through feature extraction and quantization processing, and generate a protocol behavior feature vector library.

[0016] The protocol intelligent matching and retrieval module is used to select the protocol weight part based on the action vector. It determines the optimal protocol feature vector through the maximum value index positioning algorithm. Based on the optimal protocol feature vector, it generates the target protocol identifier by performing K-nearest neighbor similarity retrieval in the protocol behavior feature vector library.

[0017] The multipath dynamic transmission execution module is used to perform multipath transmission proportionally according to the target protocol based on the path allocation ratio of the target protocol identifier and action vector.

[0018] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement a smart protocol dynamic switching method for multipath networks as described in the first aspect.

[0019] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a method for dynamic switching of intelligent protocols for multipath networks as described in the first aspect.

[0020] The aforementioned intelligent protocol dynamic switching method, system, device, and medium for multi-path networks transforms user natural language requirements into machine-parseable structured business constraints in real time. This drives a meta-reinforcement learning policy network to fuse dynamic network states and generate a joint optimization decision vector for protocol selection and path allocation. Based on a standardized protocol behavior feature library, it achieves accurate matching of the optimal transmission protocol and simultaneously triggers intelligent scheduling of multi-path traffic. This enables accurate understanding and quantitative translation of business intent, online autonomous evolution and cross-scenario generalization of transmission strategies, and optimal dynamic allocation of multi-path resources. It systematically solves the core problems of traditional solutions, such as lack of business awareness, rigid strategies, difficulty in protocol expansion, unbalanced resource utilization, and handover interruption. Attached Figure Description

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

[0022] Figure 1 A flowchart illustrating an intelligent protocol dynamic switching method for multi-path networks provided by the present invention.

[0023] Figure 2 This is a schematic diagram of the process of generating action vectors in an optional embodiment of the present invention;

[0024] Figure 3 This is a schematic diagram of the structure of an intelligent protocol dynamic switching system for multi-path networks provided by the present invention. Detailed Implementation

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

[0026] refer to Figure 1 The document presents a flowchart illustrating a method for intelligent protocol dynamic switching in multi-path networks, as provided in this application. This method includes the following steps:

[0027] S1. Perform semantic parsing and keyword extraction on the natural language business requirement description input by the user to generate structured intent parsing results; based on the structured intent parsing results, perform similarity matching through a predefined SLA template library to generate business constraint object.

[0028] Specifically, when processing user-input natural language business requirement descriptions, text preprocessing is first performed to eliminate ambiguity and extract valid information. Mature toolchains in the field of natural language processing can be used for word segmentation, part-of-speech tagging, stop word removal, and named entity recognition. Commonly used toolchains include NLTK, spaCy, and the Hugging FaceTransformers library. Taking a typical business requirement description as an example, the text is first broken down into semantic units through word segmentation, then stop words without actual semantic meaning are removed, and subsequently, key entities such as business type and QoS indicator thresholds are identified through part-of-speech tagging. The semantic parsing stage employs a BERT-based fine-tuning model. This model relies on general language knowledge learned in the pre-training stage and is fine-tuned using a business scenario dataset containing labeled business requirement-intent mapping samples. This enables semantic role labeling and intent classification, ultimately parsing the natural language requirement into structured intent information containing elements such as business type, core QoS indicators, and business priority.

[0029] Keyword extraction employs a fusion algorithm combining TF-IDF and TextRank. TF-IDF calculates the importance of words within a single requirement; for example, words related to a specific business type show significantly higher TF-IDF values ​​in corresponding business requirements compared to other types. TextRank is used to uncover semantic relationships between words, such as the co-occurrence weight of QoS metrics and corresponding thresholds. By fusing these two algorithms, a core keyword set is extracted, and structured intent parsing results are generated in JSON format. These results may include intent identifiers, business types, a list of QoS metrics, business priority, and traffic prediction-related fields.

[0030] After the structured intent parsing results are generated, they are matched against a predefined SLA template library for similarity. The SLA template library covers multiple typical business scenarios, including real-time interaction, big data transmission, and financial transactions. Each scenario corresponds to a dedicated SLA template, which includes standardized SLA parameters and weight configurations. Similarity matching employs a weighted cosine similarity algorithm. First, the structured intent parsing results and the QoS indicators of the SLA templates are converted into feature vectors. Then, the indicator weights are introduced to calculate the weighted cosine similarity. The calculation formula is as follows:

[0031]

[0032] Where, ω i x is the weight of the i-th QoS metric. iLet y be the i-th metric value of the intent result. i Let be the i-th metric value of the template, and n be the number of metrics. If the calculated similarity reaches a preset threshold (which can be dynamically configured according to business scenarios), a successful match is determined, and a business constraint object is generated based on this template. In addition to containing the SLA parameters of the template, the business constraint object can also add fields such as constraint effective duration and fault recovery strategy, and is validated through JSONSchema to ensure the integrity of the fields and the correctness of the data types, providing standardized constraint input for subsequent steps.

[0033] S2. Based on the business constraint objects and the multi-path network state dataset collected by the probe agents deployed on the network nodes, the action space probability is calculated through the meta-reinforcement learning policy network to generate action vectors including protocol selection weights and path allocation ratios.

[0034] Specifically, the business constraint object generated by S1 first undergoes feature engineering to transform non-numerical fields into machine-recognizable numerical features. Business types can be encoded using one-hot encoding, with different encoding vectors for different business types; business priorities can be mapped numerically, assigning different values ​​according to priority; fault recovery strategies can be transformed using enumerated values, with each recovery strategy corresponding to a unique enumerated value; thresholds in QoS constraints are directly used as numerical features, ultimately forming a fixed-dimensional business constraint feature vector.

[0035] The multipath network status dataset is collected by probe agents deployed on network nodes, including edge routers, core switches, and terminal access points. The probe agents employ a hybrid collection mechanism. Traffic statistics can be collected based on the NetFlow / sFlow protocol, including the number of inbound / outbound bytes, packets, and TCP connections for each path. The collection frequency is dynamically adjusted according to the service type. Real-time network quality parameters, including latency, jitter, packet loss rate, and bandwidth utilization, are collected through ICMP Echo Requests, TCP SYN probes, and UDP jitter testing tools. The packet loss rate is calculated by the proportion of lost probe packets during continuous transmission, and bandwidth utilization is determined based on the ratio of total link bandwidth to actual bandwidth usage.

[0036] The collected raw dataset undergoes data cleaning and processing. Outliers are removed using the 3σ criterion, such as when a network quality parameter for a certain path suddenly exceeds the normal range by several standard deviations. Temporarily missing data is filled using linear interpolation, such as a small number of missing sampling points due to lost probe packets. Finally, Min-Max normalization is used to map all numerical features to the [0,1] interval, calculated using the following formula:

[0037]

[0038] Where, x norm Here, x represents the normalized eigenvalues, and x represents the original eigenvalues. min x max These are the minimum and maximum values ​​of the feature in the historical data, respectively, ultimately forming a network state feature matrix that includes the number of paths and the single-path state feature dimension.

[0039] Meta-reinforcement learning policy networks can employ the MAML framework to address the challenge of rapid adaptation in dynamically changing multi-path network environments, including path failures, traffic bursts, and topology adjustments. The network structure comprises an input layer, multiple hidden layers, and an output layer. The input layer receives the concatenated service constraint feature vector and network state feature matrix. The hidden layers employ a fully connected structure with a reasonable number of neurons, using the ReLU activation function to mitigate the vanishing gradient problem. The output layer uses the Softmax activation function to output the probability distribution of the action space. The action space is defined as a combination of a protocol selection weight vector and a path allocation ratio vector, where the dimension of the protocol selection weight vector is the same as the number of supported transmission protocols and the sum of the weights is 1, and the dimension of the path allocation ratio vector is the same as the number of paths and the sum of the allocation ratios is 1.

[0040] Network training is divided into meta-training and meta-fine-tuning phases. The meta-training phase constructs diverse task sets, each corresponding to a network scenario. Each task includes a training set and a test set, both composed of state-action-reward samples. The REINFORCE algorithm is used to calculate the loss, and the reward function is designed as a weighted combination of multi-dimensional metrics. The calculation formula is as follows:

[0041] R = α × R qos +β×R efficiency -γ×R cost

[0042] Among them, R qos For QoS satisfaction, scores are calculated based on whether QoS indicators meet thresholds and then accumulated according to weights; R efficiency Transmission efficiency, which is the ratio of actual throughput to theoretical maximum throughput; R cost For network resource consumption, points are deducted proportionally when bandwidth utilization exceeds a preset range; α, β, and γ are weighting coefficients. Network parameters are updated using meta-gradient descent to ensure the model's average reward on different task test sets reaches a preset standard. In the meta-fine-tuning stage, gradient updates are performed in a small number of rounds using real-time collected samples, further optimizing model adaptability for the current network scenario.

[0043] During the inference phase, the current business constraint feature vector and the network state feature matrix are input into the trained policy network, which outputs the action space probability distribution. Action vectors are generated by sampling using a roulette wheel algorithm. The generated action vectors must satisfy the constraints that the weight sum is 1 and the ratio sum is 1. If the sampling results do not meet these constraints, they are adjusted through normalization.

[0044] S3. Based on the transmission protocol specification information, the behavioral characteristics of various transmission protocols are standardized and characterized through feature extraction and quantization processing to generate a protocol behavior feature vector library.

[0045] Specifically, the collection of transport protocol specification information covers mainstream multipath transport protocols and congestion control algorithms, including MPTCP, QUIC, BBR, CUBIC, TCPVegas, etc. The collection is based on relevant RFC documents, technical white papers, kernel version documents, etc. The focus is on extracting the behavioral characteristic parameters of the protocols, which can be mainly divided into four categories.

[0046] The first category is connection management features, including connection establishment latency, connection migration support, and maximum concurrent connections. Different protocols differ in connection establishment efficiency and migration capabilities. Some protocols support fast connection establishment, while others can maintain connection stability when network parameters change.

[0047] The second category is congestion control characteristics, including congestion window growth models, packet loss response strategies, bandwidth utilization, etc. Different protocols adopt different congestion control logics. Some protocols adjust the congestion window based on function models, while others optimize bandwidth utilization based on real-time network conditions.

[0048] The third category is QoS adaptation features, including latency sensitivity, throughput priority, packet loss recovery speed, etc. Protocols for real-time services usually have lower latency jitter and faster packet loss recovery capabilities, while protocols for non-real-time services pay more attention to throughput stability.

[0049] The fourth category is message processing characteristics, including encapsulation efficiency, encryption support, and multi-path scheduling algorithms. Some protocols have higher encapsulation efficiency and mandatory encryption mechanisms, and different protocols support different scheduling algorithms to achieve differentiated traffic allocation.

[0050] Feature extraction employs a structured mapping method, transforming the aforementioned qualitative / quantitative characteristics into fixed-dimensional feature vectors. Quantitative characteristics are directly used as numerical features, while qualitative characteristics are transformed through binarization or numerical mapping. For example, support for a certain function is represented by a specific numerical value, while lack of support is represented by another numerical value, with different levels of numerical values ​​assigned according to priority. Quantization processing consists of two steps: the first step is standardization, using Z-Score normalization for features of different dimensions, calculated using the following formula: Where x stdThe first step is to assign feature values ​​after standardization, where x is the original feature value, μ is the feature mean, and σ is the feature standard deviation, ensuring that the feature distribution conforms to a standard normal distribution. The second step is to assign feature weights, adjusting the importance of features based on business scenario requirements. For example, latency sensitivity has a higher weight in real-time business, while encryption support and packet loss recovery speed have a higher weight in financial transaction business. Finally, the feature vector of each protocol is the sum of the products of the standardized values ​​of each dimension and their corresponding weights.

[0051] The protocol behavior feature vector library is stored in a relational database. Each record contains fields such as protocol identifier, protocol name, protocol version, feature vector, update time, and supported scenarios. The feature vector is stored in JSON format. The vector library supports dynamic updates. When a new protocol is added or an existing protocol is upgraded, a new vector is generated and added to the library according to the same feature extraction and quantization process. At the same time, the obsolescence status of the old version protocol is marked to ensure the timeliness and completeness of the protocols in the library.

[0052] S4. For the protocol selection weight part based on action vectors, the optimal protocol feature vector is determined by the maximum value index positioning algorithm; based on the optimal protocol feature vector, the target protocol identifier is generated by performing K-nearest neighbor similarity retrieval in the protocol behavior feature vector library.

[0053] Specifically, based on the action vector generated by S2, the protocol selection weight portion is first extracted, and the optimal protocol feature vector is determined using a maximum value index positioning algorithm. This algorithm's execution flow consists of three steps. The first step is to traverse the protocol selection weight array, recording the maximum weight and its corresponding index set. The second step is to determine the length of the index set; if the length is 1, the protocol feature vector corresponding to that index is directly extracted as the optimal protocol feature vector. The third step is to trigger a secondary decision mechanism if the index set length is greater than or equal to 1, meaning there are multiple maximum values ​​with the same weight. This secondary decision mechanism extracts the highest-priority QoS indicator from the business constraint object generated by S1. Taking financial transaction business as an example, the latency indicator typically has the highest weight in this scenario. Then, it queries the protocol behavior feature vector library to find the values ​​of the associated features of these indices for that QoS indicator, selects the protocol index with the largest value, and thus determines the optimal protocol feature vector.

[0054] After determining the optimal protocol feature vector, a K-nearest neighbor similarity search is performed in the protocol behavior feature vector library to verify the accuracy of the optimal vector and generate the target protocol identifier. The K value is determined through cross-validation. The search accuracy of different K values ​​is tested in a historical protocol selection sample set (containing business constraints, optimal protocols, and actual adapted protocol samples), and the K value with the highest accuracy is selected. Cosine similarity is used for similarity calculation because the dimensions of the feature vector have been standardized, and cosine similarity can effectively measure the directional consistency between vectors. The calculation formula is:

[0055]

[0056] in, The feature vector of the optimal protocol. A is a feature vector of a certain protocol in the vector library. i B is the i-th eigenvalue in the eigenvector of the optimal protocol. i Let A be the i-th eigenvalue of the feature vector of a certain protocol in the vector library, and A i With B i They are feature values ​​of the same type, and n represents the dimension of the feature vector of the optimal protocol and the feature vector of a certain protocol in the vector library.

[0057] The retrieval process consists of five steps. The first step calculates the cosine similarity between the feature vector of the optimal protocol and the feature vectors of all protocols in the vector library, obtaining a similarity set. The second step sorts the protocols by similarity from highest to lowest, selecting the top K protocols as the candidate protocol set. The third step counts the frequency of each protocol in the candidate protocol set and selects the protocol with the highest frequency as the target protocol. The fourth step, if candidate protocols have the same frequency of occurrence, calculates the average similarity between these protocols and the feature vector of the optimal protocol, selecting the protocol with the highest average similarity. The fifth step generates a target protocol identifier, which uses a fixed format and is associated with the protocol's supported scenarios and runtime dependency library information.

[0058] To avoid retrieval errors, a similarity threshold is set. If the highest similarity among the candidate protocols is lower than this threshold, an exception handling is triggered. First, it checks whether the protocol behavior feature vector library is missing any protocols corresponding to this business scenario. If there are omissions, the protocol feature supplementation process is automatically triggered; if there are no omissions, the S2 meta-reinforcement learning policy network inference is re-executed, the protocol selection weights are adjusted, and the retrieval is repeated until the target protocol identifier that meets the threshold requirement is obtained.

[0059] S5. Based on the path allocation ratio of the target protocol identifier and action vector, multipath transmission is performed proportionally according to the target protocol.

[0060] Specifically, based on the target protocol identifier generated by S4, the protocol module loading operation is performed first. Network transmission nodes pre-store the runtime modules for each protocol, including dynamic link libraries or containerized images. These network transmission nodes encompass terminal devices, edge gateways, etc. The corresponding module file is located by matching the identifier. Before loading, integrity verification is performed by calculating the hash value of the module file and comparing it with the pre-stored hash value to prevent file tampering. During loading, the dynamic linker resolves module dependencies, including SSL libraries, network interface libraries, etc., ensuring that the module can be initialized correctly. In the initialization phase, the protocol module reads its own configuration file, which contains parameters such as the maximum number of connections, encryption algorithm, and retransmission timeout. Simultaneously, it receives the business constraint object generated by S1 and writes the QoS indicator thresholds into the protocol's runtime parameters.

[0061] The path allocation ratio based on action vectors is combined with the multipath transmission mechanism of the target protocol to perform traffic allocation. Different protocols correspond to different allocation logic:

[0062] 1) For the QUIC protocol, which supports multipath extension, multipath transmission is achieved by establishing multiple paths within a single connection. Each path corresponds to a physical network path, and path reachability is verified using a protocol-specific frame during path establishment. The transmission weight of each path is set according to the allocation ratio, calculated using the following formula:

[0063]

[0064] Among them, W i R is the sending weight for path i. i W represents the allocation ratio for path i. total This represents the total transmission weight for the protocol connection. QUIC's transmission scheduler employs a "weighted round-robin + real-time status adjustment" mechanism, allocating transmission windows according to weight ratios while simultaneously monitoring the latency and packet loss rate of each path in real time. If the network quality parameters of a certain path exceed a threshold, its weight is temporarily reduced, and the released weight is allocated to other normal paths to ensure that the overall QoS meets the constraints.

[0065] 2) For the MPTCP protocol, multipath transmission is achieved by establishing multiple sub-streams, each corresponding to one path. When a sub-stream is established, a TCP three-way handshake is completed and MPTCP options are associated, including the sub-stream ID and mainstream identifier. The traffic scheduling weights of each sub-stream are set according to the allocation ratio. The MPTCP scheduler allocates packets based on these weights and achieves rate control by adjusting the TCP congestion window of each sub-stream. The calculation formula is as follows:

[0066]

[0067] Among them, cwnd iRate represents the congestion window size for the i-th path. total For the total transmission rate, RTT i Let $i$ be the round-trip time for path $i$, and $MSS$ be the maximum segment size, ensuring that the sending rate of each sub-stream conforms to the allocation ratio.

[0068] During multi-path transmission, a monitoring module is deployed to collect key indicators in real time. The collection frequency is dynamically adjusted according to the indicator type. Some indicators are collected at high frequency to ensure real-time performance, while others can be collected at low frequency to reduce resource consumption.

[0069] The monitoring data is compared with the threshold values ​​of the business constraint objects. Dynamic adjustments are triggered if the following conditions are met:

[0070] The first scenario is when the actual traffic percentage deviates from the allocation ratio beyond the preset range. In this case, the scheduling weight of the protocol is adjusted by reducing the weight of the path with the larger deviation and increasing the weight of other paths to achieve traffic balance.

[0071] The second scenario is when the packet loss rate of a certain path exceeds a threshold. In this case, path failover is triggered, and the allocation ratio of that path is reallocated to other normal paths. The allocation formula is as follows:

[0072]

[0073] Among them, R′ i R is the new allocation ratio for normal path i. fault The original allocation ratio of the fault path, ∑ j∈normal R j This represents the sum of the original allocation ratios for the normal path.

[0074] The third scenario is when the overall throughput is below the threshold. In this case, the congestion control parameters of the protocol are adjusted, and the throughput is improved by optimizing the initial congestion window and adjusting the bandwidth probe frequency.

[0075] After transmission is complete, a transmission log is generated. The log includes fields such as transmission identifier, protocol identifier, path usage, QoS metric data, transmission start and end times, and transmission success identifier. The log data serves a dual purpose: firstly, it's used for subsequent model iterations in the meta-reinforcement learning policy network, adding successfully transmitted state-action samples to the training set to optimize the network's decision-making accuracy; secondly, it provides audit evidence for network operations and maintenance, facilitating the tracing of problems during transmission. The entire transmission process requires no manual intervention, achieving end-to-end automation from protocol selection to path allocation, meeting the differentiated QoS requirements of various services.

[0076] The aforementioned intelligent protocol dynamic switching method for multi-path networks transforms user natural language requirements into machine-parseable structured business constraints in real time. This drives a meta-reinforcement learning policy network to fuse dynamic network states and generate a joint optimization decision vector for protocol selection and path allocation. Based on a standardized protocol behavior feature library, it achieves accurate matching of the optimal transmission protocol and simultaneously triggers intelligent scheduling of multi-path traffic. This enables accurate understanding and quantitative translation of business intent, online autonomous evolution and cross-scenario generalization of transmission strategies, and optimal dynamic allocation of multi-path resources. It systematically solves the core problems of traditional solutions, such as lack of business awareness, rigid strategies, difficulty in protocol expansion, unbalanced resource utilization, and handover interruption.

[0077] refer to Figure 2 In one optional embodiment, based on the business constraint object and the multi-path network state dataset collected by the probe agents deployed on the network nodes, the action space probability is calculated through a meta-reinforcement learning policy network to generate an action vector including protocol selection weights and path allocation ratios, including the following steps:

[0078] S11. Based on the network latency weight coefficient and network jitter threshold in the business constraint object, construct a dynamic reward function that is positively correlated with SLA satisfaction; the dynamic reward function is defined as:

[0079] R = w1·f delay +w2·f jitter -w3·Δ switch

[0080] Where R represents the dynamic reward function; f delay Represents the network delay satisfaction function. f jitter This represents the network jitter satisfaction function. Δ switch For protocol switching overhead, w1, w2, and w3 are preset weight coefficients.

[0081] Specifically, constructing a dynamic reward function positively correlated with SLA satisfaction is the core guiding mechanism of reinforcement learning policy networks. In the business constraint object, parameters such as network latency weight coefficient w1 and network jitter threshold...

[0082] The data stems from the core QoS requirements of the business. For example, real-time video services are sensitive to latency and jitter, while financial transaction services have a lower tolerance for jitter.

[0083] Network delay satisfaction function f delay The design logic is: when the actual network latency does not exceed the latency limit allowed by the service, This reflects the degree of latency redundancy; if the actual latency exceeds the upper limit, the satisfaction level is directly set to 0, and penalties are imposed for not meeting the SLA. Network jitter satisfaction function f jitter Similarly, through The calculation reflects the degree to which jitter is satisfied. Protocol switching overhead Δ switch The resource consumption and service interruption risk during protocol switching (such as the time overhead of MPTCP substream reconstruction and the state synchronization overhead of QUIC connection migration) were quantified and used as -w3·Δ switch The penalty parameters can guide the policy network to reduce unnecessary protocol switching while meeting the SLA. The preset weight coefficients w1, w2, and w3 are calibrated in conjunction with the business scenario.

[0084] Ultimately, the dynamic reward function is R = w1·f delay +w2·f jitter -w3·Δ switch By integrating multi-dimensional QoS requirements and switching costs, it provides a goal-oriented approach for policy network optimization.

[0085] S12. Based on the path bandwidth and latency data in the multi-path network state dataset, calculate the path redundancy and load balancing through topology feature extraction, and construct an enhanced network state vector based on the path redundancy and load balancing.

[0086] Specifically, topological features are extracted from the multi-path network state dataset to construct an enhanced network state vector. The multi-path network state dataset contains basic data such as bandwidth and latency for each path. Topological feature extraction begins by calculating path redundancy. The bandwidth coverage relationship between paths can be analyzed; if there is overlap in the path bandwidth range, the overlapping portion will reduce redundancy (redundancy reflects the complementarity of path resources).

[0087] In the specific calculation, the intersection and union operations are performed on the bandwidth sequence of each path (sampled according to the time window). The path redundancy formula is as follows: The smaller the value, the stronger the path redundancy.

[0088] Next, the load balancing degree is calculated: the uniformity of the load on each path is quantified using "1 - coefficient of variation", the formula is as follows: Load k Let μ be the load of the k-th path; μ is the average load, calculated according to (Load1,...,Load...). M ) Calculated, M is the total number of paths; σ is the standard deviation, also based on (Load1,...,Load M The closer Balance is to 1, the more balanced the load is.

[0089] After obtaining path redundancy and load balancing, these are concatenated with the original path bandwidth and latency data (such as average bandwidth and real-time latency for each path) to generate an enhanced network state vector. For example, the original state vector for each path is [Bandwidth...]. k Latency k (Total M paths, dimension 2M, Bandwidth) k Latency represents the bandwidth of the k-th path. k If the delay of the k-th path is represented by , then the enhanced vector adds redundancy (1-dimensional) and balance (1-dimensional), and the total dimension becomes 2M+2, which more comprehensively describes the redundancy capability and load distribution characteristics of the network topology.

[0090] S13. Concatenate the quantitative indicator threshold of the business constraint object with the enhanced network state vector according to the dimension to generate the state input vector.

[0091] Specifically, the business requirements and network state are fused and represented. First, the business constraint quantification index thresholds and the enhanced network state vector are dimensionally aligned and standardized. The business constraint quantification index thresholds (such as latency upper limit and jitter threshold) are transformed into values ​​with the same dimensions as the enhanced network state vector (mapped to the [0,1] interval through Min-Max normalization). Then, the business constraint vector (dimension D) is... constraint ) and the enhanced network state vector (dimension D) network Connect them sequentially to generate the state input vector (dimension D). constraint +D network For example, if the business constraint vector contains "normalized values ​​of latency upper limit and jitter threshold" (dimension 2), and the enhanced network state vector has a dimension of 2M+2, then the concatenated state input vector has a dimension of 2+2M+2=2M+4. This concatenation allows the policy network to simultaneously perceive "what the business needs" and "what the network currently has," providing more accurate state input for action decisions.

[0092] S14. Based on the state input vector, the policy gradient is calculated through a pre-trained meta-policy network, and the action space probability distribution matrix is ​​output. The action space probability distribution matrix is ​​divided into a first subspace and a second subspace. The first subspace carries the decision information corresponding to protocol selection, and the second subspace carries the decision information corresponding to path allocation.

[0093] Specifically, the pre-trained meta-policy network employs a meta-reinforcement learning framework. The pre-training phase covers multiple network scenarios (such as 3-path data center networks, 5-path wide area networks, and dynamic topology networks), enabling the network to quickly adapt to new scenarios. After inputting the state input vector, the policy network calculates the gradient using policy gradient algorithms (such as REINFORCE or PPO) to optimize the probability distribution of action selection. The core of policy gradient is to increase the probability of selecting "high-reward actions" and decrease the probability of selecting "low-reward actions."

[0094] The action space probability distribution matrix is ​​divided into two subspaces: the first subspace corresponds to protocol selection (dimension is the number of supported protocols N), and the second subspace corresponds to path allocation (dimension is the number of paths M). This division ensures the integrity and consistency of the decision-making process because protocol selection and path allocation are two-level decisions (first select the protocol, then allocate path resources to the protocol).

[0095] S15. Based on the action space probability distribution matrix, the first subspace is analyzed using the Softmax function to generate a protocol selection weight vector; the protocol selection weight vector is represented as P. proto =[p1,p2,…,p N ], where p i This represents the probability of choosing the i-th protocol. z i Let be the value of the i-th dimension in the first subspace, and N be the dimension of the first subspace.

[0096] Specifically, the Softmax function transforms the original values ​​of each dimension of the first subspace (logits output by the policy network) into a probability distribution, ensuring that the sum of the selection probabilities of all protocols is 1. The formula is as follows: Where z i This is the output value of the i-th dimension of the first subspace, reflecting the value score of the protocol in the current state. The exponential operation amplifies the gap between high and low scores, making the probability distribution steeper and more inclined to select protocols with higher scores. The generated protocol selection weight vector P... proto =[p1,p2,...,p N In ], each p i This represents the probability of choosing the i-th protocol.

[0097] S16. Based on the action space probability distribution matrix, analyze the second subspace using the Sigmoid function to generate a path allocation ratio vector; the path allocation ratio vector is represented as R. path =[r1,r2,…,r M ], where r k This represents the allocation ratio of the k-th path. v kLet M be the value of the k-th dimension in the second subspace, and M be the dimension of the second subspace.

[0098] Specifically, the Sigmoid function The original output value v of the second subspace k Mapping to the (0,1) interval is suitable for representing "proportion". The output value v of the k-th dimension of the second subspace... k Calculate the path allocation ratio Because of the r of each path k Independent calculations and the sum may not be 1, therefore normalization is performed, and each r is normalized. k Dividing by the sum of the allocation proportions of all paths yields the final path allocation proportion vector R. path =[r1,r2,...,r M ],satisfy

[0099] In this embodiment, by constructing a dynamic reward function that is positively correlated with SLA satisfaction, the service QoS requirements (latency, jitter) and protocol switching costs are accurately integrated. At the same time, topological features such as path redundancy and load balancing are extracted to optimize network state representation, so that meta-policy network decisions can fit service needs and network topology characteristics, reduce invalid switching, and improve the pertinence and rationality of protocol and path selection.

[0100] In one optional embodiment, based on the state input vector, policy gradient calculation is performed through a pre-trained meta-policy network to output an action space probability distribution matrix, including the following steps:

[0101] S21. Based on the state input vector, perform a linear transformation through the input layer of the pre-trained meta-policy network to generate the initial feature vector.

[0102] Specifically, the state input vector is formed by concatenating the business constraint feature vector and the enhanced network state vector. Its dimension is the sum of the business constraint feature dimension and the network state feature dimension. This dimension determines the number of neurons in the input layer, because the number of neurons in the input layer must be completely matched with the dimension of the state input vector to ensure that the vector can be completely input into the network for processing.

[0103] The core of linear transformation is to map the state input vector from the original feature space to a feature space that the hidden layer of the meta-policy network can process through the interaction of the weight matrix and the bias vector, laying the foundation for subsequent nonlinear transformations. The mathematical expression for linear transformation is:

[0104] Z1 = W1 × X + b1

[0105] Where X is the state input vector, W1 is the input layer weight matrix, b1 is the input layer bias vector, and Z1 is the initial feature vector generated after the linear transformation. The dimension of the weight matrix W1 is determined by the number of neurons in the input layer and the number of neurons in the first hidden layer. If the number of neurons in the input layer is D... in If the number of neurons in the first hidden layer is H1, then the dimension of W1 is H1×D. in The dimension of the bias vector b1 is the same as the number of neurons in the first layer of the hidden layer, which is H1-dimensional.

[0106] The initialization of the weight matrix and bias vector follows the stability requirements of network training, employing either He initialization (for the ReLU activation function) or Xavier initialization strategies. He initialization uses a matrix with a mean of 0 and a variance of 2 / D. in Sampling weights from a normal distribution can effectively alleviate the gradient vanishing problem under the ReLU activation function; Xavier initialization starts from a value with a mean of 0 and a variance of 1 / (D). in Sampling in a uniform distribution of +H1) is applicable to a wider range of activation function scenarios.

[0107] The initialized weights and biases are continuously optimized through gradient descent during the meta-training phase to ensure that the linear transformation can accurately extract key features from the state input vector, such as QoS priority in business constraints and path load distribution in network states. Finally, an initial feature vector of dimension H1 is generated. This vector needs to retain the core information of the original state input while having a feature distribution that can adapt to subsequent nonlinear transformations.

[0108] S22. Based on the initial feature vector, perform a nonlinear transformation using a nonlinear activation function to generate the activated feature vector.

[0109] Specifically, performing nonlinear activation function transformations based on the initial feature vectors aims to introduce nonlinear expressive capabilities into the meta-policy network. If only linear transformations are superimposed, the network as a whole remains a linear model, unable to fit the complex mapping relationship between business requirements and network states in multi-path networks (such as the differentiated demands of different services for protocol selection and the path allocation logic under dynamic network topology). Nonlinear activation functions can break the limitations of linear models, enabling the network to learn more complex decision rules.

[0110] The ReLU function is a suitable nonlinear activation function, chosen primarily for three reasons: First, ReLU is computationally efficient, requiring only a determination of whether a feature value is positive, without complex exponential or trigonometric function calculations. This improves the inference speed of the meta-policy network and meets the real-time decision-making needs of multi-path networks. Second, ReLU effectively alleviates the vanishing gradient problem. In deep network training, traditional Sigmoid or Tanh functions can cause gradient saturation, leading to gradients approaching zero in deeper layers. ReLU, however, retains the original gradient for positive features and sets negative features to zero, ensuring that the gradient remains within a valid range during backpropagation. Third, ReLU introduces sparsity by suppressing negative features in the initial feature vector, highlighting key features that positively contribute to protocol selection and path allocation, reducing redundant information interference, and improving network decision-making accuracy.

[0111] The mathematical expression for the nonlinear transformation is:

[0112] A1 = ReLU(Z1) = max(0, Z1)

[0113] Where Z1 is the initial feature vector and A1 is the activated feature vector.

[0114] During this transformation, all elements less than 0 in the initial feature vector are set to 0, while elements greater than or equal to 0 retain their original values. The final activated feature vector has the same dimension as the initial feature vector, which is still H1-dimensional.

[0115] If the meta-policy network contains multiple hidden layers (such as two or three hidden layers), then each hidden layer needs to repeat the process of "linear transformation + non-linear activation": the activated feature vector A1 output by the first hidden layer is used as the input of the second hidden layer. A linear transformation is performed on the second layer's weight matrix W2 and bias b2 to generate Z2, which is then activated by the ReLU function to generate A2. This process continues until the last hidden layer outputs the final activated feature vector A. L , where L is the total number of hidden layers.

[0116] The superposition of multiple nonlinear transformations can further enhance the feature extraction capability of the network, enabling the final activated feature vector to more accurately depict the relationship between business requirements and network state, and providing high-quality feature support for the action space mapping of the subsequent output layer.

[0117] S23. Based on the activated feature vector, a linear transformation is performed through the output layer of the meta-policy network to generate the original action space output vector.

[0118] Specifically, a linear transformation of the output layer is performed based on the activated feature vector. Its core function is to map the high-dimensional feature vector processed by the hidden layer to the corresponding dimension of the action space, generating the original action space output vector. The action space consists of two parts: protocol selection and path allocation. Therefore, the number of neurons in the output layer must be consistent with the sum of the number of registered protocols in the protocol library and the number of currently available paths. If the number of registered protocols in the protocol library is N and the number of currently available paths is M, then the number of neurons in the output layer is N+M, ensuring that the original action space output vector can cover all dimensions of protocol selection and path allocation.

[0119] The mathematical expression for a linear transformation is:

[0120] Z out =W out ×A L +b out

[0121] Among them, A L The activated feature vector output from the last hidden layer (with dimension H) L H L W represents the number of neurons in the last hidden layer. out Let b be the output layer weight matrix. out Z is the output layer bias vector. out This generates the original action space output vector. The output layer weight matrix W is also included. out The dimension is (N+M)×H L Each row corresponds to a weight parameter for an action dimension (i.e., a protocol or a path), and each column corresponds to the output weight of a neuron in the last hidden layer; the bias vector b out The dimension is N+M, and each element corresponds to a bias value of an action dimension, which is used to adjust the baseline level of the output of that dimension.

[0122] Unlike the input and hidden layers, the linear transformation of the output layer does not introduce non-linear activation functions. This is because the original action space output vector needs to retain a continuous numerical range to provide a foundation for the probabilistic processing of subsequent subspaces (such as Softmax probability normalization in the first subspace and Sigmoid scaling in the second subspace). Introducing activation functions into the output layer might compress the output values ​​to a fixed range (e.g., the Sigmoid function compresses values ​​to (0,1)), thus limiting the flexibility of subsequent probability calculations. The weights and biases of the output layer are also optimized during the meta-training phase using a policy gradient algorithm. The optimization goal is to ensure that the original action space output vector accurately reflects the numerical tendency of "high-reward actions," meaning that for protocols and path allocation schemes that meet business QoS requirements and have low network resource consumption, the corresponding dimension of the output vector has a higher output value, laying the foundation for generating a reasonable action probability distribution. The final generated original action space output vector has a dimension of N+M, and the value of each element is directly related to the calculation results of subsequent protocol selection weights and path allocation ratios.

[0123] S24. Based on the original action space output vector, the vector is divided according to the preset dimension segmentation rules to generate the first subspace vector and the second subspace vector; wherein, the dimension of the first subspace vector is equal to the number of registered protocols in the protocol library, and the dimension of the second subspace vector is equal to the number of currently available paths.

[0124] Specifically, based on the original action space output vector, a preset dimension segmentation rule is executed. The core of this method is to split a continuous vector into two independent subspace vectors according to the functional division of the action space (protocol selection and path allocation). This ensures that differentiated probabilistic processing methods can be applied to different subspaces based on their functional requirements. The preset dimension segmentation rule is formulated based on the definition of the meta-policy network action space and dynamically matched with the number of protocols registered in the protocol library and the number of currently available paths to ensure that the segmented subspace vectors accurately cover the corresponding action dimensions.

[0125] The specific logic of dimension partitioning is as follows: the elements of the first N dimensions in the original action space output vector are divided into the first subspace vector, and the elements of the last M dimensions are divided into the second subspace vector. Here, N is the number of registered protocols in the protocol library, determined by the dynamic update mechanism of the protocol library. When a new protocol passes compatibility testing and is registered in the protocol library, N is automatically incremented by 1; when an old protocol is removed from the protocol library due to performance degradation or no longer being supported, N is automatically decremented by 1, ensuring that the dimensions of the first subspace vector always match the actual number of available protocols, avoiding dimension redundancy or missing dimensions. M is the number of currently available paths, determined in real time by the probe agents deployed on network nodes. The probe agents periodically send path reachability probe packets (such as ICMP Echo Requests and TCPSYN probe packets) to determine whether each path is unavailable due to faults, congestion exceeding limits, or other reasons, updating the list of available paths in real time, and dynamically adjusting the value of M to ensure that the dimensions of the second subspace vector perfectly match the actual number of available paths.

[0126] For example, if the protocol library registers four protocols: MPTCP, QUIC, BBR, and CUBIC (i.e., N=4), and the probe agent detects in real time that there are currently 3 available paths (i.e., M=3), then the original action space output vector has a dimension of 4+3=7. After segmentation, the first subspace vector (corresponding to protocol selection) has the first 4 dimensions, and the second subspace vector (corresponding to path allocation) has the last 3 dimensions. The dimension segmentation process is implemented through vector index positioning, which can be completed at the code level through array slicing operations. The two segmented subspace vectors are stored separately, and the corresponding dimension information (real-time values ​​of N and M) is recorded. This provides a dimensional basis for the subsequent concatenation in step S25 and the calculation of subsequent protocol selection weights and path allocation ratios, avoiding decision-making errors caused by dimension mismatch.

[0127] S25. Concatenate the first subspace vector and the second subspace vector in sequence to generate the action space probability distribution matrix.

[0128] Specifically, the first and second subspace vectors are concatenated sequentially to generate an action space probability distribution matrix. The core is to integrate the action dimension information from the two subspaces to form a structured matrix output, providing a standardized input format for action decisions in the subsequent meta-policy network. The concatenation order follows the decision logic of dynamic switching of multi-path network protocols—protocol selection is a prerequisite for path allocation. The target protocol must be determined first, and then the corresponding path resources are allocated to that protocol. Therefore, during concatenation, the first subspace vector corresponding to the protocol selection is placed at the front of the matrix, and the second subspace vector corresponding to the path allocation is placed at the back of the matrix, ensuring that the matrix structure is consistent with the decision logic.

[0129] The action space probability distribution matrix is ​​a one-dimensional row matrix (or column matrix, the specific dimension definition is adapted to the subsequent probability calculation module). Its total length is equal to the sum of the dimensions of the first subspace vector and the second subspace vector, i.e., N+M. The first N elements of the matrix are the elements of the first subspace vector, and the last M elements are the elements of the second subspace vector. For example, if the first subspace vector is [Z1,Z2,Z3,z4] (N=4) and the second subspace vector is [z5,z6,Z7] (M=3), then the concatenated action space probability distribution matrix is ​​[z1,z2,z3,z4,z5,z6,Z7].

[0130] The concatenation process ensures that the order of vector elements is consistent with the original action space output vector. That is, the element order of the first subspace vector corresponds to the registration order of the protocols in the protocol library (e.g., the first element corresponds to MPTCP, the second corresponds to QUIC, etc.), and the element order of the second subspace vector must correspond to the order of available paths detected by the probe agent (e.g., the first element corresponds to path1, the second corresponds to path2, etc.) to avoid subsequent protocol selection or path allocation errors due to disordered order.

[0131] The concatenated action space probability distribution matrix, as the final output of the meta-policy network, is passed to the subsequent probabilistic processing module. For the first subspace vector, the Softmax function is used to transform the elements into protocol selection probabilities (ensuring the probability sum is 1). For the second subspace vector, the Sigmoid function is used to transform the elements into basic values ​​for path allocation ratios (subsequent normalization ensures the ratio sum is 1). This ultimately forms the action decision-making basis that can be directly used for dynamic switching of multi-path network protocols. Simultaneously, the matrix includes dimension identification information (real-time values ​​of N and M) to ensure that subsequent modules accurately identify the boundaries between the two subspaces and avoid dimension confusion during processing.

[0132] In this embodiment, a standardized process of linear transformation of the input layer, nonlinear activation, and dimensional segmentation and splicing of the output layer is adopted to standardize the mapping logic from the state input vector to the probability distribution matrix of the action space. This ensures that the output matrix can accurately correspond to the protocol selection and path allocation dimensions, improves the structure and accuracy of the meta-policy network output, and provides a reliable basis for action decision-making for subsequent protocol selection and path allocation.

[0133] In one optional embodiment, the protocol selection weight portion based on the action vector is used to determine the optimal protocol feature vector through a maximum value index localization algorithm, including the following steps:

[0134] S31. The protocol selection weight part based on action vectors extracts the protocol selection probability vector through vector dimension slicing operation.

[0135] Specifically, the protocol selection weight part based on action vectors performs vector dimension slicing operation. The core is to accurately separate the vector segments corresponding to the protocol selection probability from the action vector through preset dimension partitioning rules, and form the protocol selection probability vector.

[0136] The action vector consists of a protocol selection weight and a path allocation ratio, arranged in a fixed order within the vector. The protocol selection weight corresponds to the first N dimensions of the vector (N being the number of registered protocols in the protocol library), and the path allocation ratio corresponds to the last M dimensions of the vector (M being the number of currently available paths). Therefore, the total dimensions of the action vector are N+M. This dimensional division is based on the decision-making logic of dynamic switching of multi-path network protocols—protocol selection is a prerequisite for path allocation, requiring priority determination of the target protocol before allocating path resources. Therefore, placing protocol-related dimensions at the beginning of the vector ensures that slicing operations can directly locate the core decision dimensions.

[0137] The implementation of vector dimension slicing follows the principle of "precise matching of dimension boundaries." First, the number of registered protocols N in the current protocol library is obtained through the configuration parameters of the meta-policy network (this parameter is synchronized in real-time by the protocol library dynamic update module to ensure consistency with the actual number of registered protocols). This number serves as the dimension boundary for slicing. The logic of the slicing operation is as follows: starting from the initial dimension (the first dimension) of the action vector, elements from N consecutive dimensions are extracted to form a vector of length N. This vector is the protocol selection probability vector. For example, if the action vector dimension is 7 (N=4, M=3), the slicing operation extracts elements from the first 4 dimensions to form the protocol selection probability vector. At the technical implementation level, the slicing operation is completed through vector indexing. The starting index is 0 (or 1, consistent with the vector dimension counting rule), and the ending index is N (excluding the ending index itself, ensuring that exactly N dimensions are extracted). This avoids the extracted vector containing elements of the path allocation ratio or omitting some protocol selection weight elements due to index deviation.

[0138] Each element of the protocol selection probability vector corresponds to the selection probability of a registered protocol in the protocol library, and the order of the elements strictly matches the registration order of the protocols in the library. For example, if the protocols in the protocol library are registered in the order of "MPTCP, QUIC, BBR, CUBIC", then the first element of the protocol selection probability vector corresponds to the selection probability of MPTCP, the second element corresponds to the selection probability of QUIC, and so on. This consistency of order is the basis for the accurate association of "probability-protocol-feature vector" in subsequent steps. If the order is disordered, it will lead to incorrect matching between subsequent protocol selection and feature vector, thus affecting the correctness of the entire handover process. In addition, after the slicing operation is completed, the extracted protocol selection probability vector is validated. The validation includes whether the vector length is equal to N and whether the sum of all elements in the vector is close to 1 (because the protocol selection weights are normalized by Softmax, the theoretical sum is 1, but there may be slight deviations due to floating-point precision errors). If the validation fails, the exception handling process is triggered, and the action vector generation step of the meta-policy network is re-executed to ensure that the extracted protocol selection probability vector has validity and usability.

[0139] S32. Locate the index number corresponding to the maximum probability value in the protocol selection probability vector.

[0140] Specifically, locating the index number corresponding to the highest probability value in the protocol selection probability vector involves using deterministic algorithmic logic to filter out the dimension index corresponding to the protocol with the highest probability, providing a basis for locating the feature vector of the optimal protocol in the subsequent matching process.

[0141] Each element has a floating-point value in the range [0,1], representing the probability of selecting the corresponding protocol. The sum of all elements is 1, therefore, there must be at least one element with the highest probability (i.e., the element with the largest value) in the vector. The core idea for locating the highest probability value is to determine its position (i.e., index) in the vector through traversal comparison or optimization algorithms. The index ranges from 0 to N-1 (or 1 to N, consistent with the vector dimension counting rules) and corresponds one-to-one with the registration order of protocols in the protocol library.

[0142] In practice, the "current maximum probability value" and "current maximum probability index" are first initialized. The "current maximum probability value" is initialized to the first element of the vector, and the "current maximum probability index" is initialized to 0 (or 1). Then, the remaining elements of the probability vector are selected sequentially through the protocol. For each element encountered (let its index be i and its value be p),... i ), p i Compare with the "current maximum probability value": if p i If the value is greater than the "current maximum probability value", then update the "current maximum probability value" to p. iAt the same time, update the "current maximum probability index number" to i; if p i If the value is less than the "current maximum probability value", then keep the values ​​of both variables unchanged; if p i If the value equals the "current maximum probability value" (i.e., multiple identical maximum probability values ​​occur, which is called a "probability tie" scenario), then a secondary decision-making mechanism is triggered to avoid decision bias caused by random selection.

[0143] The secondary decision-making mechanism combines business constraints with protocol characteristics. Its core principle is to select protocols with similar probabilities that better meet business QoS requirements. Specifically, the logic is as follows: Extract the highest-priority QoS indicators (such as "latency sensitivity" for real-time video services and "packet loss tolerance" for financial transactions) from the business constraint object generated by S1. Query the protocol behavior feature vector library for the values ​​of these protocols with similar probabilities on the feature dimension corresponding to that QoS indicator (e.g., a higher value for the "latency sensitivity" feature dimension indicates better latency adaptability). Select the index number corresponding to the protocol with the highest feature value as the final "maximum probability index number." For example, if both QUIC and BBR have the highest selection probability (e.g., 0.4), and "latency sensitivity" has the highest priority among the business constraints, and the query reveals that QUIC's "latency sensitivity" feature value is 0.9 and BBR's is 0.7, then the index number corresponding to QUIC is determined as the final result. This secondary decision-making mechanism ensures that even in scenarios with equal probabilities, the optimal choice can still be made based on business needs, avoiding random decision-making that leads to protocol selection failing to meet SLA requirements and thus affecting data transmission quality.

[0144] After traversal and secondary decision-making, the final determined "maximum probability index number" is checked for consistency with the registration order of the protocol library to ensure that the index number is within the valid range of 0 to N-1 (or 1 to N). If it exceeds the range, it is judged as abnormal, and the protocol selection probability vector generation and maximum probability positioning steps are re-executed to ensure the validity of the index number and lay the foundation for subsequent querying of the optimal protocol feature vector.

[0145] S33. Based on the index number, obtain the corresponding optimal protocol feature vector by querying the protocol feature vector mapping table registered in the protocol behavior feature vector library.

[0146] Specifically, based on the maximum probability index number determined by S32, the optimal protocol feature vector is obtained by querying the protocol feature vector mapping table in the protocol behavior feature vector library. The core is to establish a precise association between "index number-protocol-feature vector", transforming the optimal protocol selection at the probability level into a feature vector that can be used for subsequent similarity retrieval, thereby connecting the decision results with the feature data.

[0147] This mapping table is a structured data set containing three core fields: "Protocol Index Number," "Protocol Unique Identifier," and "Protocol Feature Vector." The "Protocol Index Number" strictly matches the registration order of protocols in the protocol library and corresponds completely to the dimensional order of the protocol selection probability vector in S31 and the maximum probability index number for location in S32, ensuring end-to-end consistency of the index dimensions. The "Protocol Unique Identifier" is a string format (e.g., "PROTO_QUIC_v1," "PROTO_MPTCP_v2") used to uniquely identify the version and type of the protocol, avoiding confusion between feature vectors of different versions. The "Protocol Feature Vector" is a fixed-dimensional numerical vector (e.g., 16-dimensional) containing standardized representations of the protocol's behavioral characteristics such as connection management, congestion control, QoS adaptation, and packet processing. This vector is generated by feature extraction and quantization in step S3 and is comparable to feature vectors of other protocols.

[0148] The mapping table is constructed following the principle of "dynamic synchronization": When a new protocol is added to the protocol library, its features are first extracted and quantized through step S3 to generate a protocol feature vector. A new "protocol index number" is then assigned to it (this index number is the current maximum index number plus 1, ensuring sequential continuity), and the correspondence between "index number - identifier - feature vector" is written into the mapping table. When an old protocol is deleted from the protocol library, the corresponding entry is removed from the mapping table, and the "protocol index numbers" of subsequent protocols are rearranged (or the original index number is retained and marked as "invalid" to avoid affecting existing index associations). This ensures that the index numbers in the mapping table are always synchronized with the registration order of the protocol library, preventing query errors due to index misalignment. For example, if the BBR protocol with original index number 2 is deleted from the protocol library, and a rearrangement strategy is used, the index number of the CUBIC protocol with original index number 3 is updated to 2, and the corresponding entry in the mapping table is modified synchronously, ensuring accurate correspondence between index numbers and protocols in subsequent queries.

[0149] The specific process for querying the optimal protocol feature vector is as follows: First, the maximum probability index number determined by S32 is used as the query keyword and input into the mapping table query interface of the protocol behavior feature vector library; the query interface iterates through the "protocol index number" field in the mapping table to find entries that completely match the query keyword; the set of values ​​for the "protocol feature vector" field is extracted from the matching entries, and this set is the optimal protocol feature vector. For example, if the maximum probability index number is 1, the entries with "protocol index number = 1" in the mapping table are queried, and the corresponding feature vectors (such as [0.85, 0.9, 0.75, ...]) are extracted. This vector is the behavioral feature representation of the optimal protocol under the current service and network conditions. After the query is completed, the extracted optimal protocol feature vector is validated for dimensionality and numerical validity: the dimension must be consistent with the dimension of other protocol feature vectors in the mapping table (e.g., all are 16-dimensional) to avoid subsequent K-nearest neighbor similarity retrieval failure due to inconsistent feature vector dimensions; the numerical value must be within a reasonable range after standardization (e.g., the range [0,1]). If there are numerical values ​​outside the range, it is determined that the feature vector is corrupted, triggering the repair process of the protocol feature vector library (restoring the feature vector of the protocol from the backup data) to ensure that the optimal protocol feature vector is usable.

[0150] In addition, the query process can also record a "query log", which includes information such as query time, maximum probability index number, unique identifier of the matched protocol, and dimension of the extracted feature vector. This log is used for subsequent troubleshooting (if problems occur during subsequent protocol switching, the source of the feature vector query can be traced), and for optimizing the protocol behavior feature vector library (such as counting the query frequency of each protocol to provide a basis for prioritizing the protocol library), ensuring the traceability and optimizability of the entire protocol selection and feature vector matching process.

[0151] In this embodiment, the protocol selection probability is accurately extracted by vector slicing, the optimal protocol direction is locked by the maximum index positioning, and the matching feature vector is queried from the mapping table. This achieves a precise connection from the action vector probability to the specific protocol features, avoids protocol selection bias, ensures the rapid and accurate acquisition of the optimal protocol feature vector, provides high-quality input for subsequent K-nearest neighbor similarity retrieval, and guarantees the correctness of protocol selection.

[0152] In one optional embodiment, multipath transmission is performed proportionally according to the target protocol based on the path allocation ratio portion of the target protocol identifier and the action vector, including the following steps:

[0153] S41. Based on the target protocol identifier, start the pre-packaged protocol container image through the container orchestration platform to generate a protocol container instance.

[0154] Specifically, based on the target protocol identifier, a pre-packaged protocol container image is launched through a container orchestration platform to generate a protocol container instance. The core is to rely on containerization technology to achieve rapid deployment and standardization of the protocol runtime environment, ensuring that the target protocol can run efficiently in a resource environment that meets business needs.

[0155] An image can contain the complete runtime environment of the target protocol (such as the protocol kernel module, user-space drivers, dependent system libraries and third-party components; for example, a QUIC protocol image needs to integrate the QUIC protocol stack, TLS encryption library, and path management module), a pre-defined protocol configuration template (the template reserves interfaces for QoS parameter configuration, such as latency threshold, congestion control algorithm type, maximum number of connections, etc.), and an instance health check script (used to verify the availability of the protocol service after startup). Images can be stored in a private container repository (such as Harbor) and use a one-to-one naming rule of "protocol identifier - image tag". For example, when the target protocol identifier is "PROTO_QUIC_v1", the corresponding image tag is "quic-proto:v1", ensuring that the container orchestration platform can accurately match the required image using the identifier.

[0156] The choice of container orchestration platform should be adapted to the distributed characteristics of multi-path networks. Kubernetes (K8s) can be used as the core orchestration tool because it has capabilities such as node affinity scheduling, dynamic resource allocation, and instance self-healing. The specific implementation logic of the startup process is as follows: First, the container orchestration platform receives a startup request consisting of "target protocol identifier + business resource requirements," where the business resource requirements originate from the business constraint object generated by S1 (such as the number of CPU cores, memory capacity, and minimum network bandwidth). Subsequently, the platform's scheduler filters target nodes based on the principles of "resource sufficiency + network affinity." Resource sufficiency means that the remaining CPU and memory of the node must meet the minimum resource requirements of the protocol container instance (e.g., a QUIC instance requires 1 CPU core and 2GB of memory). Network affinity means prioritizing nodes with a network topology close to the business data source nodes (such as user terminals and business servers) (determined by calculating the number of routing hops or link latency between nodes) to reduce network transmission latency during protocol processing. After scheduling is completed, the platform sends an image pull instruction to the target node. The node pulls the corresponding protocol image from its private container repository. During the pull process, the integrity of the image must be verified by the SHA-256 hash value to prevent the image from being tampered with.

[0157] During the initialization phase, the protocol container instance completes parameter injection and service startup. Parameter injection uses environment variables or configuration file mounting to convert QoS indicators (such as network latency limits, packet loss rate thresholds, and encryption algorithm types) in business constraints into runtime parameters that the protocol can recognize. For example, "latency limit of 50ms" is injected as the "max_latency=50" environment variable for the QUIC protocol. Service startup is executed through the startup script built into the image. The script sequentially starts the protocol kernel service, path management process, and log collection process, and listens on the protocol-specific port (such as QUIC listening on port 443 by default, and MPTCP listening on port 8080).

[0158] After the instance starts, the container orchestration platform performs availability verification through a health check script. The script sends test packets (such as QUIC's PATH_CHALLENGE frame or TCP's SYN packet) to the protocol listening port. If a valid response (such as QUIC's PATH_RESPONSE frame or TCP's SYN-ACK packet) is received within a preset timeout period (such as 3 seconds), the instance is considered to have started successfully and is marked as "Running". If no response is received or the response is abnormal, a restart mechanism is triggered (up to 3 restarts). If the restart still fails, it is scheduled to restart on another node, ensuring that the protocol container instance can stably provide services and laying the foundation for subsequent business flow switching.

[0159] S42. Based on the protocol container instance, the session state transition engine is used to perform business flow switching operations and generate a ready-state protocol connection.

[0160] Specifically, the session state migration engine is used to perform business flow switching operations based on the protocol container instance to generate a ready-state protocol connection. The core is to smoothly migrate the original business flow from the old protocol connection (or the initial connectionless state) to the newly started protocol container instance without interrupting business transmission, so that the business is unaware of the protocol switching.

[0161] The session states of different protocols contain differentiated content. The TCP protocol synchronization state may include sequence number (SN), acknowledgment number (ACK), window size, congestion window (cwnd), and slow start threshold (ssthresh). The QUIC protocol requires the synchronization of connection ID, TLS master secret, stream state (StreamID and corresponding send / receive offset), and path state (list of probed paths and RTT value). The service layer session state may include user session identifiers (such as session tokens) and service data fragmentation progress (such as the number of bytes transferred in a file transfer). The complete migration of these states ensures service continuity.

[0162] The session state migration engine can adopt a three-stage working mechanism of "establish connection first, then synchronize, then switch". The first stage is new connection establishment. The migration engine sends a connection establishment request to the protocol container instance, carrying the business identifier and initial configuration parameters. The protocol container instance creates a new protocol connection based on the parameters (such as a QUIC 0-RTT connection or an MPTCP multi-substream connection) and returns the connection handle and initial state information (such as connection ID and initial sequence number). The second stage is state synchronization. The migration engine synchronizes the old connection state through "incremental snapshot + real-time incremental synchronization". It first captures a snapshot of the current state of the old connection (such as TCP sequence number and QUIC encryption state), compresses the snapshot data, and transmits it to the new protocol container instance. After the snapshot data is loaded, the migration engine captures the state changes of the old connection in real time (such as sequence number increment and window size adjustment), and synchronizes them to the new instance through incremental data packets. The synchronization process uses TCP or QUIC reliable transmission protocol to ensure that state data is not lost, and the synchronization latency can be controlled within 10ms (for real-time services). The third stage is the service flow switching. The migration engine selects the "message gap switching" time, between two adjacent data packets of the service flow (i.e., after the old connection has sent a message and before the next message is sent), and diverts the subsequent messages of the service flow to the new protocol connection to avoid message out-of-order or loss due to switching.

[0163] The service flow switching process executes traffic canary verification and anomaly rollback mechanisms. For example, during the canary verification phase, the migration engine can first divert 10% of the service traffic to the new connection and continuously monitor it for 5 seconds (configurable). If the packet transmission and reception success rate of the new connection is ≥99.9% and the latency is ≤ the service constraint threshold, the verification is considered successful, and the remaining 90% of the traffic is gradually switched to the new connection. If the verification fails (e.g., packet loss rate >0.1%), a rollback is immediately triggered, switching the diverted 10% of traffic back to the old connection and recording the reason for the failure (e.g., incomplete state synchronization, abnormal new connection port). The switching operation is re-executed after investigation and repair.

[0164] The criteria for determining a ready protocol connection can include three aspects. First, the new connection can continuously receive and correctly parse service flow packets, and the service layer reports no data loss or out-of-order delivery. Second, the session state synchronization integrity is ≥99.9%, meaning the state parameters of the new connection (such as sequence number and encryption key) are completely consistent with the old connection (a slight incremental deviation in sequence number is allowed, as the old connection may still be transmitting a small number of packets during synchronization). Third, the resource utilization rate of the new connection (such as CPU utilization and memory usage) is ≤ a preset threshold, ensuring no resource bottlenecks during subsequent multipath transmission. After meeting the above criteria, the migration engine marks the new connection as "ready" and sends a connection ready notification to the multipath transmission control module, preparing for subsequent proportional transmission.

[0165] S43. Based on the ready state protocol connection and the path allocation ratio part of the action vector, the data stream distribution rules are configured through the multipath transmission control module to execute proportional multipath transmission.

[0166] Specifically, based on the path allocation ratio of the ready state protocol connection and action vector, the data flow distribution rules are configured through the multi-path transmission control module to achieve proportional multi-path transmission. The core is to build a closed-loop control mechanism of "proportional configuration - dynamic scheduling - real-time monitoring" to ensure that the traffic ratio of each path is consistent with the allocation ratio specified by the action vector, while adapting to dynamic changes in network status.

[0167] The core components of the multipath transmission control module include a path selector, a traffic scheduler, and a status monitor: the path selector is responsible for managing the list of currently available paths (obtaining real-time path status from the probe agent and filtering out faulty or congestion-overloaded paths); the traffic scheduler performs traffic distribution based on the allocation ratio and path status; and the status monitor collects transmission metrics of each path in real time to provide a basis for scheduling optimization. The three components achieve real-time data interaction through an internal communication bus (such as gRPC).

[0168] The configuration of data stream distribution rules combines the multipath characteristics of the target protocol with the path allocation ratio: First, the multipath transmission control module extracts the path allocation ratio from the action vector. This ratio corresponds to the traffic share of each available path (e.g., path 1 accounts for 30%, path 2 accounts for 50%, and path 3 accounts for 20%). The module converts the ratio into a "path-weight" mapping relationship (e.g., path 1 weight = 30, path 2 weight = 50, and path 3 weight = 20). The total weight is independent of the number of paths and is only used as a proportional reference during traffic scheduling. Second, the distribution rules are configured according to the multipath transmission mechanism of the target protocol. For the MPTCP protocol, the rules specify the physical path corresponding to each sub-stream (e.g., sub-stream 1 is bound to path 1, sub-stream 2 is bound to path 2, and sub-stream 3 is bound to path 3), and set the sending weight of each sub-stream (consistent with the path allocation ratio). Traffic allocation is achieved through the MPTCP sub-stream scheduler. For the QUIC protocol, the rules configure the "sending window percentage" of each path (e.g., the window percentage of path 1 is 30%). The QUIC path scheduler allocates the number of packets to be sent based on the window percentage. For the BBR protocol, which supports multiple paths, the rules configure the bandwidth quota of each path (e.g., the bandwidth quota of path 1 is 30%). The BBR bandwidth allocation module allocates available bandwidth according to the quota.

[0169] The traffic scheduling algorithm employs a hybrid strategy of "weighted round-robin + real-time status feedback". The basic scheduling logic is weighted round-robin, which determines the number of packets sent on each path based on the path weight (e.g., if path 1 has a weight of 30 and path 2 has a weight of 50, then for every 80 packets sent, path 1 sends 30 and path 2 sends 50), ensuring that the long-term traffic share matches the allocation ratio. Real-time status feedback dynamically adjusts the weights based on path metrics (latency, packet loss rate, bandwidth utilization) collected by the status monitor. If the latency of a path exceeds the service constraint threshold (e.g., path 3's latency increases from 40ms to 60ms, exceeding the 50ms threshold), its weight is reduced (e.g., from 20 to 10), and the released weight is proportionally allocated to other normal paths (e.g., path 1's weight increases from 30 to 33 and path 2's weight increases from 50 to 57). The adjustment frequency is once every 1 second (configurable according to service sensitivity), avoiding the impact of a single path anomaly on the overall transmission quality. For service flows that require fragmented transmission (such as large file transfers), the scheduling algorithm also incorporates a fragment reassembly mechanism to ensure that different fragments of the same service flow, after being transmitted along different paths, can be reassembled in order at the receiving end. This can be achieved by adding "fragment ID + total number of fragments + path identifier" information to the fragment header. The receiving end reassembles the fragments based on their fragment IDs. If a fragment is lost on a certain path, the scheduler triggers a retransmission mechanism (preferentially selecting other low-latency paths for retransmission) to ensure fragment integrity.

[0170] The monitoring and adjustment mechanism during multi-path transmission runs continuously. The status monitor collects real-time traffic percentages for each path via NetFlow and compares them with the path allocation ratio. If the deviation exceeds a preset threshold, a weight adjustment is triggered (e.g., if path 1's actual percentage is 25%, which is lower than the 30% allocation ratio, its weight needs to be increased from 30 to 35). Simultaneously, the monitor monitors the congestion status of each path. If the bandwidth utilization of a path exceeds the congestion warning threshold, the transmission rate of that path is reduced through "traffic suppression" (e.g., reducing the number of packets sent by 20%), and traffic is transferred to paths with bandwidth utilization below 60%. Furthermore, the monitor also collects the resource status (CPU, memory, network I / O) of protocol container instances. If the resource utilization exceeds the overload threshold, container instance expansion is triggered (new protocol container instances are launched through the container orchestration platform to share the transmission pressure). Through these mechanisms, the multi-path transmission control module ensures the accuracy and stability of proportional transmission while adapting to dynamic changes in network and resource status, ultimately meeting the QoS requirements under business constraints.

[0171] In this embodiment, containerization enables rapid deployment and standardized operation of the protocol. The session state transition engine ensures seamless service switching. Combined with the dynamic scheduling (weighted polling + real-time status feedback) of the multi-path transmission control module, traffic allocation is achieved according to the action vector ratio, and it can adapt to dynamic network changes (congestion, path anomalies). Ultimately, stable and efficient multi-path transmission is achieved to meet the QoS requirements of services.

[0172] The aforementioned intelligent protocol dynamic switching method for multi-path networks transforms user natural language requirements into machine-parseable structured business constraints in real time. This drives a meta-reinforcement learning policy network to fuse dynamic network states and generate a joint optimization decision vector for protocol selection and path allocation. Based on a standardized protocol behavior feature library, it achieves accurate matching of the optimal transmission protocol and simultaneously triggers intelligent scheduling of multi-path traffic. This enables accurate understanding and quantitative translation of business intent, online autonomous evolution and cross-scenario generalization of transmission strategies, and optimal dynamic allocation of multi-path resources. It systematically solves the core problems of traditional solutions, such as lack of business awareness, rigid strategies, difficulty in protocol expansion, unbalanced resource utilization, and handover interruption.

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

[0174] Based on the same inventive concept, this application also provides a system for implementing the above-described intelligent protocol dynamic switching method for multi-path networks. The solution provided by this system is similar to the implementation described in the above method. Therefore, the specific limitations of one or more embodiments of the intelligent protocol dynamic switching system for multi-path networks provided below can be found in the limitations of the intelligent protocol dynamic switching method for multi-path networks described above, and will not be repeated here.

[0175] In one exemplary embodiment, such as Figure 3 As shown, an intelligent protocol dynamic switching system 30 for multi-path networks is provided to implement the methods in the above-described method embodiments. The system includes:

[0176] The business intent intelligent parsing module 31 is used to perform semantic parsing and keyword extraction on the natural language business requirement description input by the user, and generate structured intent parsing results; based on the structured intent parsing results, similarity matching is performed through a predefined SLA template library to generate business constraint condition objects.

[0177] The dynamic strategy optimization decision module 32 is used to calculate the action space probability through a meta-reinforcement learning policy network based on the multi-path network state dataset collected by the business constraint object and the probe agent deployed on the network node, and generate an action vector including protocol selection weight and path allocation ratio.

[0178] The protocol behavior feature library construction module 33 is used to standardize the behavioral characteristics of various transmission protocols based on transmission protocol specification information through feature extraction and quantization processing, and generate a protocol behavior feature vector library.

[0179] The protocol intelligent matching and retrieval module 34 is used to select the protocol weight part based on the action vector. It determines the optimal protocol feature vector through the maximum value index positioning algorithm. Based on the optimal protocol feature vector, it generates the target protocol identifier by performing K-nearest neighbor similarity retrieval in the protocol behavior feature vector library.

[0180] The multipath dynamic transmission execution module 35 is used to perform multipath transmission proportionally according to the target protocol based on the path allocation ratio part of the target protocol identifier and action vector.

[0181] Embodiments of this application also provide a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the aforementioned method embodiments.

[0182] Embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the above-described method embodiments.

[0183] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The components described as separate parts may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this disclosure according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0184] The above-described embodiments are merely illustrative of several implementation methods of the embodiments of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the embodiments of this application, and these modifications and improvements all fall within the protection scope of the embodiments of this application.

Claims

1. A method for intelligent protocol dynamic switching for multi-path networks, characterized in that, The method includes: S1. Perform semantic parsing and keyword extraction on the natural language business requirement description input by the user to generate a structured intent parsing result; based on the structured intent parsing result, perform similarity matching through a predefined SLA template library to generate a business constraint object; S2. Based on the business constraint object and the multi-path network state dataset collected by the probe agent deployed on the network node, the action space probability is calculated through the meta-reinforcement learning policy network to generate an action vector including protocol selection weight and path allocation ratio. S3. Based on the transmission protocol specification information, the behavioral characteristics of various transmission protocols are standardized and characterized through feature extraction and quantization to generate a protocol behavior feature vector library. S4. Based on the protocol selection weight part of the action vector, the optimal protocol feature vector is determined by the maximum value index positioning algorithm; based on the optimal protocol feature vector, the target protocol identifier is generated by performing K-nearest neighbor similarity retrieval in the protocol behavior feature vector library. S5. Based on the target protocol identifier and the path allocation ratio portion of the action vector, perform multipath transmission proportionally according to the target protocol.

2. The method according to claim 1, characterized in that, The multi-path network state dataset collected based on the business constraint object and the probe agents deployed on network nodes is used to perform action space probability calculation through a meta-reinforcement learning policy network to generate action vectors including protocol selection weights and path allocation ratios, including: S11. Based on the network latency weight coefficient and network jitter threshold in the aforementioned business constraint object, construct a dynamic reward function positively correlated with SLA satisfaction; the dynamic reward function is defined as: R=w1·f delay +w2·f jitter -w3·Δ switch Where R represents the dynamic reward function; f delay Represents the network delay satisfaction function. f jitter This represents the network jitter satisfaction function. Δ switch For protocol switching overhead, w1, w2, and w3 are preset weighting coefficients; S12. Based on the path bandwidth and latency data in the multi-path network state dataset, calculate the path redundancy and load balancing through topology feature extraction, and construct an enhanced network state vector based on the path redundancy and the load balancing. S13. Concatenate the quantitative index threshold of the business constraint object with the enhanced network state vector by dimension to generate a state input vector; S14. Based on the state input vector, perform policy gradient calculation through a pre-trained meta-policy network to output an action space probability distribution matrix; wherein, the action space probability distribution matrix is ​​divided into a first subspace and a second subspace, the first subspace carries decision information corresponding to protocol selection, and the second subspace carries decision information corresponding to path allocation; S15. Based on the action space probability distribution matrix, the first subspace is analyzed using the Softmax function to generate a protocol selection weight vector; the protocol selection weight vector is represented as P. proto =[p1,p2,…,p N ], where p i This represents the probability of choosing the i-th protocol. z i Let be the value of the i-th dimension in the first subspace, and N be the dimension of the first subspace; S16. Based on the action space probability distribution matrix, the second subspace is analyzed using the Sigmoid function to generate a path allocation ratio vector; the path allocation ratio vector is represented as R. path =[r1,r2,…,r M ], where r k This represents the allocation ratio of the k-th path. v k Let M be the value of the k-th dimension in the second subspace, and M be the dimension of the second subspace.

3. The method according to claim 2, characterized in that, The step of calculating the policy gradient through a pre-trained meta-policy network based on the state input vector and outputting an action space probability distribution matrix includes: S21. Based on the state input vector, perform a linear transformation through the input layer of the pre-trained meta-policy network to generate an initial feature vector; S22. Based on the initial feature vector, perform a nonlinear transformation using a nonlinear activation function to generate an activated feature vector; S23. Based on the activated feature vector, perform a linear transformation through the output layer of the meta-policy network to generate the original action space output vector. S24. Based on the original action space output vector, the vector is divided according to a preset dimension segmentation rule to generate a first subspace vector and a second subspace vector; wherein, the dimension of the first subspace vector is equal to the number of registered protocols in the protocol library, and the dimension of the second subspace vector is equal to the number of currently available paths; S25. The first subspace vector and the second subspace vector are concatenated in sequence to generate the action space probability distribution matrix.

4. The method according to claim 1, characterized in that, The protocol selection weighting component based on the action vector determines the optimal protocol feature vector using a maximum value index localization algorithm, including: S31. Based on the protocol selection weight part of the action vector, extract the protocol selection probability vector through vector dimension slicing operation; S32. Locate the index number corresponding to the maximum probability value in the protocol selection probability vector; S33. Based on the index number, obtain the corresponding optimal protocol feature vector by querying the protocol feature vector mapping table registered in the protocol behavior feature vector library.

5. The method according to any one of claims 1 to 4, characterized in that, The path allocation ratio based on the target protocol identifier and the action vector, which performs multipath transmission proportionally according to the target protocol, includes: S41. Based on the target protocol identifier, start the pre-packaged protocol container image through the container orchestration platform to generate a protocol container instance; S42. Based on the protocol container instance, use the session state transition engine to perform a service flow switching operation and generate a ready state protocol connection. S43. Based on the ready state protocol connection and the path allocation ratio of the action vector, configure the data stream distribution rules through the multipath transmission control module and execute proportional multipath transmission.

6. A smart protocol dynamic switching system for multi-path networks, used to implement the method according to any one of claims 1 to 5, characterized in that, The system includes: The business intent intelligent parsing module is used to perform semantic parsing and keyword extraction on the natural language business requirement description input by the user, and generate a structured intent parsing result; based on the structured intent parsing result, similarity matching is performed through a predefined SLA template library to generate a business constraint object; The dynamic strategy optimization decision module is used to calculate the action space probability through a meta-reinforcement learning policy network based on the business constraint object and the multi-path network state dataset collected by the probe agents deployed on the network nodes, and generate an action vector including protocol selection weights and path allocation ratios. The protocol behavior feature library construction module is used to standardize the behavioral characteristics of various transmission protocols based on transmission protocol specification information, through feature extraction and quantization processing, and generate a protocol behavior feature vector library. The protocol intelligent matching and retrieval module is used to determine the optimal protocol feature vector based on the protocol selection weight part of the action vector through the maximum value index positioning algorithm; and based on the optimal protocol feature vector, to generate the target protocol identifier by performing K-nearest neighbor similarity retrieval in the protocol behavior feature vector library. The multipath dynamic transmission execution module is used to perform multipath transmission proportionally according to the target protocol based on the target protocol identifier and the path allocation ratio part of the action vector.

7. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 5.

Images