A cross-cloud secure communication method and system with message degradation capability

Abstract

This invention discloses a cross-cloud secure communication method and system with message degradation capabilities. It collects node registration information and link status data from cross-cloud deployment scenarios, generates a cloud node routing table and a link quality baseline through dynamic endpoint parsing and link quality benchmark assessment. Based on the cloud node routing table, it establishes a cross-cloud encrypted communication channel, completes pre-degradation bidirectional certificate authentication to generate authentication channel credentials, and executes multi-channel multiplexing configuration. It binds multiplexed channel groups through a transparent message queue proxy, and infers the implicit health of business messages based on the link quality baseline to generate a health index sequence and determine the link health level. Based on the link health level, it predicts degradation trends to generate pre-degradation trigger conditions, constructs a degradation execution strategy, and generates a degradation communication sequence. It reverse-verifies the quality of degraded messages to generate a link recovery configuration, executes elastic routing scheduling to construct a recovery communication channel, and outputs the cross-cloud secure communication result, achieving end-to-end secure communication assurance.

Description

Technical Field

[0001] This invention relates to the field of cloud computing network communication technology, and in particular to a cross-cloud secure communication method and system with message degradation capability. Background Technology

[0002] As enterprise businesses migrate to multi-cloud and hybrid cloud architectures, the demand for interconnectivity between different cloud service providers continues to grow. In cross-cloud communication environments, each cloud domain is independent in terms of network topology, certificate system, and protocol standards. When establishing an encrypted connection, both ends of the communication need to cross multiple trust boundaries to complete authentication. The problems of long authentication links and uneven handshake overhead are particularly prominent when the number of nodes increases. Existing solutions lack a pre-built response mechanism for the performance differences in cross-domain authentication, resulting in persistently low communication establishment efficiency for some cloud domain nodes.

[0003] Furthermore, cross-cloud links are affected by the combined effects of multiple network infrastructures, resulting in frequent and difficult-to-detect fluctuations in link quality. When a link deteriorates, traditional communication solutions typically wait for the connection to be interrupted before switching over. During this period, business messages being transmitted face the risk of loss or duplicate delivery due to the lack of differentiated protection mechanisms. For channels carrying mixed-priority business messages, the transmission continuity of high-value messages should be prioritized during the degradation phase. However, existing solutions cannot dynamically adjust message processing strategies during link quality degradation and lack the ability to gradually verify and smoothly transition back to normal communication during the link recovery phase. Summary of the Invention

[0004] This invention discloses a cross-cloud secure communication method and system with message degradation capability, aiming to solve problems such as uneven authentication overhead, difficulty in predicting link quality degradation, and lack of message degradation protection mechanism in cross-cloud deployment scenarios. By establishing a closed-loop processing mechanism covering the entire process of endpoint resolution, channel establishment, health monitoring, degradation execution, and link recovery, it achieves continuous assurance of secure communication capabilities in cross-cloud environments.

[0005] The first aspect of this invention proposes a cross-cloud secure communication method with message degradation capability, comprising the following steps: Collect node registration information and link status data in cross-cloud deployment scenarios, and perform dynamic endpoint parsing and link quality benchmark assessment on the node registration information and link status data to generate cloud node routing tables and link quality baselines; A cross-cloud encrypted communication channel is established using the cloud node routing table via a two-way encrypted communication protocol. A downgrade preparation two-way certificate authentication is performed on the cross-cloud encrypted communication channel to generate an authentication channel credential. The authentication channel credential is then used to perform multi-channel multiplexing configuration on the cross-cloud encrypted communication channel to determine the multiplexing channel group. The multiplexed channel group is subjected to message queue transparent proxy binding to generate a service access mapping. The service access mapping is combined with the link quality baseline to infer the implicit health of service packets and generate a health index sequence. The link quality degradation analysis is performed based on the health index sequence to determine the link health level. The link health level is used to predict link degradation and generate pre-degradation trigger conditions. A degradation execution strategy is constructed based on the pre-degradation trigger conditions, and a degradation communication sequence is generated based on the degradation execution strategy. Based on the degraded communication sequence, reverse verification of the degraded message quality is performed to generate a link recovery configuration. Based on the link recovery configuration, elastic routing scheduling is executed to construct a recovery communication channel. Based on the recovery communication channel, cross-cloud secure communication results are output.

[0006] A second aspect of this invention proposes a cross-cloud secure communication system with message degradation capability, comprising: The endpoint resolution module is used to collect node registration information and link status data in cross-cloud deployment scenarios, and to perform dynamic endpoint resolution and link quality benchmark assessment on the node registration information and link status data to generate cloud node routing tables and link quality baselines. The channel establishment module is used to establish a cross-cloud encrypted communication channel using the cloud node routing table through a two-way encrypted communication protocol, perform downgrade preparation two-way certificate authentication on the cross-cloud encrypted communication channel to generate authentication channel credentials, and use the authentication channel credentials to perform multi-channel multiplexing configuration on the cross-cloud encrypted communication channel to determine the multiplexing channel group. The health inference module is used to perform message queue transparent proxy binding to the multiplexed channel group to generate a service access mapping, and to perform implicit health inference of service packets by combining the service access mapping with the link quality baseline to generate a health index sequence. Based on the health index sequence, link quality degradation analysis is performed to determine the link health level. The degradation decision module is used to predict link degradation based on the link health level, generate pre-degradation trigger conditions, construct a degradation execution strategy based on the pre-degradation trigger conditions, and generate a degradation communication sequence based on the degradation execution strategy. The recovery scheduling module is used to perform reverse verification of the quality of degraded messages based on the degraded communication sequence to generate a link recovery configuration, perform elastic routing scheduling to build a recovery communication channel based on the link recovery configuration, and output cross-cloud secure communication results based on the recovery communication channel.

[0007] The beneficial effects of this invention are reflected in the following points: 1. By systematically collecting and establishing benchmarks for access information and link quality data of each node in a cross-cloud deployment environment, a routing decision basis covering all cloud domain nodes is formed based on round-trip latency and packet loss rate. Furthermore, during the encrypted channel establishment phase, a credential distribution priority system is constructed based on the differences in certificate handshake performance among different nodes, concentrating authentication resources on low-overhead nodes and improving the overall establishment efficiency of cross-cloud encrypted channels. Simultaneously, multi-channel reuse configuration accurately matches channel carrying capacity with business access requirements. 2. By using a transparent message queue proxy, business traffic access and channel status monitoring are decoupled. Implicit inference of link health status is performed using packet transmission characteristics, avoiding additional probing overhead. Link health status, combined with the quality baseline, completes the graded labeling of deviation degree. The temporal changes in health level directly drive degradation prediction and the triggering of degradation strategies, enabling a coherent response between channel status perception and business assurance decisions. 3. Based on the temporal evolution of link health level, deterioration trends are identified in advance. Before the link is interrupted, message priority layering and idempotency assessment are completed to differentiate and ensure the transmission continuity of high-value messages in the degraded channel. During the recovery phase, the recovery confidence is quantified by reverse verification of the quality of degraded messages, and routing scheduling actions of different intensities are matched according to the confidence level, so as to achieve a smooth transition from the degraded state to the normal communication state. Attached Figure Description

[0008] Figure 1 This is a flowchart illustrating a cross-cloud secure communication method with message degradation capability according to the present invention.

[0009] Figure 2 This is a structural block diagram of a cross-cloud secure communication system with message degradation capability according to the present invention. Detailed Implementation

[0010] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0011] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0012] The technical solutions of the embodiments of this application will be described below.

[0013] like Figure 1 As shown, this embodiment of the invention provides a cross-cloud secure communication method with message degradation capability, including the following steps S110-S150: Step S110: Collect node registration information and link status data for cross-cloud deployment scenarios, and perform dynamic endpoint resolution and link quality benchmark assessment on the node registration information and link status data to generate cloud node routing tables and link quality baselines.

[0014] Specifically, node registration information and link status data are collected for cross-cloud deployment scenarios. Node registration information is actively pulled from the access control plane of each cloud domain, triggered by the node's first registration or a change in registration status. Each record includes a unique node identifier, its cloud domain tag, registration timestamp, and online status. The node identifier is constructed by concatenating a cloud domain prefix with a sequence number to ensure cross-domain uniqueness. Link status data is collected from the boundary gateways of each cloud domain via bypass mirroring, with a sampling interval of 5 seconds. Each time, three metrics are extracted: round-trip latency, packet loss rate, and available bandwidth, covering all interconnected links between cloud domains. Data for each link is collected independently without interference. Both node registration information and link status data are appended with a collection timestamp. After timestamp alignment, the data enters the processing flow. Resampling is triggered when the alignment error exceeds 10ms. If a node goes offline during link status data collection, the corresponding link record is retained and marked as offline. This node will not participate in the current batch of dynamic endpoint resolution until it comes back online. When the online status field of the node registration information is inconsistent with the offline labeling of the link measurement, the link measurement status shall prevail and the node registration information shall be corrected. The corrected record shall be reprocessed in the next alignment cycle.

[0015] In some embodiments, the step of generating a cloud node routing table and a link quality baseline by performing dynamic endpoint resolution and link quality benchmark assessment on the node registration information and the link status data includes: splitting the node registration information into a sequence of nodes in each cloud domain; performing cross-domain reachability detection on each node in the sequence of nodes in each cloud domain in conjunction with the link status data to extract node connectivity features; performing cold standby activation delay compensation analysis on the node connectivity features to determine key monitoring nodes; and integrating the node connectivity features with the key monitoring nodes to generate a cloud node routing table and a link quality baseline.

[0016] The node registration information is split to generate node sequences for each cloud domain. The cloud domain label carried by the node is used as the classification basis. Nodes with the same label are grouped into the sequence corresponding to the same cloud domain. Nodes with missing labels in their registration information are temporarily stored in the unclassified queue. Their cloud domain is inferred by reverse engineering using the access gateway address at the time of registration. If the inference fails, the node is marked as having an unknown affiliation and is not temporarily included in this round of sequence generation. When the sequence length corresponding to a certain cloud domain in each cloud domain node sequence is zero, it means that there are currently no online nodes in that domain. This cloud domain is treated as an empty domain during the cross-domain reachability detection phase, and no detection resources are allocated or connectivity records are generated. For nodes that have registration records in multiple cloud domains, their records are added to the corresponding sequences according to their affiliation cloud domain and a multi-domain affiliation mark is attached. During the detection phase, reachability detection is performed independently for each affiliation path, and the results of different paths do not overlap. For example, if a node acts as a boundary proxy for two cloud domains simultaneously, after splitting, one record is retained in each of the two cloud domain node sequences. Within each cloud domain node sequence, nodes are arranged in ascending order of their registration timestamps, with the node registered earliest at the beginning of the sequence. The time order within the sequence determines the execution order of cross-domain reachability probes. The completeness of node registration information directly affects the coverage of each cloud domain node sequence. Nodes with missing registration records cannot enter the sequence and are excluded from this round of probes. Newly registered nodes are immediately appended to the end of their corresponding sequences and trigger probe scheduling.

[0017] Cross-domain reachability probes are performed on each cloud domain node sequence, combined with link state data, to extract node connectivity features. Probes are triggered sequentially for each cloud domain node sequence according to the registration timestamp order within the sequence. The average round-trip latency of probe packets is determined by the arithmetic mean of the latency values ​​of three consecutive valid responses within each probe cycle. If all three responses time out, the node is determined to be unreachable in that cycle. If the unreachable state occurs for three consecutive cycles, the node is marked as persistently unreachable, and the probe resources for persistently unreachable nodes are reallocated to nodes with higher current priority in each cloud domain node sequence. The available bandwidth indicator in the link state data is jointly used with the round-trip latency of probe packets to determine connectivity quality. When bandwidth is sufficient but latency remains persistently high, it is identified as a routing detour problem. For example, if the round-trip latency of a node consistently exceeds 600ms while the available bandwidth is at a normal level, this feature is clearly different from the latency caused by congestion, and is determined to be a routing layer detour rather than a link capacity bottleneck. Node connectivity features are comprised of four metrics: average round-trip time (RTT), packet loss rate, maximum reachable hops, and latency stability. Latency stability is measured by the standard deviation of RTT over five consecutive probe cycles; a larger standard deviation indicates less stable connectivity. The packet loss rate field in the link state data is cross-validated with the packet loss rate metric in the node connectivity features. A deviation exceeding 2% triggers a re-probing attempt to eliminate acquisition errors. This cross-validation mechanism effectively identifies quality misjudgments caused by unilateral acquisition bias. For nodes with multi-domain affiliation tags, node connectivity features are extracted for each affiliation path. Different paths correspond to independent feature records, and the numerical differences between paths reflect the quality differences when the node arrives from different cloud domains. For persistently unreachable nodes, the worst-case values ​​are assigned to each node connectivity feature metric, and an unreachable label is added. The probe progress of each cloud domain node sequence is updated in real-time with each round of results. The more concentrated the latency distribution in the link state data, the narrower the latency stability benchmark range, and nodes deviating from the benchmark trigger anomaly markings more quickly.

[0018] Node connectivity characteristics are analyzed to determine key monitoring nodes based on cold standby activation delay compensation. The delay from activating a cold standby node to being able to handle service traffic consists of three parts: initialization time, network path establishment time, and authentication handshake time. The path establishment time is estimated by the round-trip latency and maximum reachable hop count in the node connectivity characteristics. A higher hop count results in a longer activation command propagation path and a correspondingly larger baseline delay value. Nodes with poor latency stability exhibit larger activation delay fluctuations. An additional 1.5 times the standard deviation of latency is added to the baseline value as a safety margin to address situations where the link state deviates from the historical baseline at the time of activation. Cold standby nodes located at the end of cross-domain links and experiencing frequent historical jitter are more likely to deviate from the baseline at the time of activation, and the safety margin expands in tandem with the deterioration of latency stability. Nodes with activation delays exceeding 300ms in the node connectivity characteristics are identified as high activation delay nodes. These nodes incur high switching costs during primary path failures and require early activation to reduce the actual switching time. Nodes with a packet loss rate exceeding 5% are marked as high-risk nodes. Nodes meeting both the high activation latency and high packet loss risk criteria are added to the key monitoring node set. The status collection interval for key monitoring nodes is reduced from the default 5 seconds to 1 second, ensuring that changes in connectivity status are detected within 1 second. Nodes whose connectivity characteristics meet only one condition are placed in the general monitoring queue, with the collection interval remaining at the default value. The identification results of key monitoring nodes are reviewed synchronously with each round of node connectivity characteristic updates, and nodes automatically exit the key monitoring node set when their indicators recover to below the threshold.

[0019] The cloud node routing table and link quality baseline are generated by integrating node connectivity features with key monitoring nodes. The cloud node routing table sorts all reachable nodes using average round-trip time as the primary sorting key and packet loss rate as the secondary sorting key, based on node connectivity features. Nodes with lower packet loss rates are ranked higher when latency is the same, and the ranking determines the path priority for cross-domain traffic. Key monitoring nodes are marked with a high-priority monitoring flag in the cloud node routing table. During route selection, a real-time status weight is introduced in addition to latency and packet loss rate. This weight is determined by the deviation between the most recent data collection and the historical baseline; the larger the deviation, the lower the node's routing priority. The link quality baseline extracts the mean and standard deviation of round-trip time and packet loss rate for each node over the past 24 hours from the node connectivity features. The mean represents the typical quality level under normal operation, and the standard deviation reflects the natural fluctuation range of the indicators. A degradation alarm is triggered when subsequent monitoring values ​​exceed the mean plus three times the standard deviation. Nodes with a standard deviation exceeding 50% of the mean are marked as high-fluctuation nodes, and the corresponding link quality baseline alarm threshold is appropriately relaxed to reduce false alarms. High-fluctuation nodes are also marked with a fluctuation risk label in the cloud node routing table. Changes in the status of key monitored nodes trigger immediate updates to the cloud node routing table without waiting for the next probe cycle. The link quality baseline is refreshed synchronously with the node connectivity feature update cycle, and abnormal states of key monitored nodes synchronously trigger dynamic corrections to the link quality baseline.

[0020] Step S120: Establish a cross-cloud encrypted communication channel using the cloud node routing table and a two-way encrypted communication protocol. Perform downgrade preparation two-way certificate authentication on the cross-cloud encrypted communication channel to generate authentication channel credentials. Use the authentication channel credentials to perform multi-channel multiplexing configuration on the cross-cloud encrypted communication channel to determine the multiplexing channel group.

[0021] Specifically, a cross-cloud encrypted communication channel is established using a bidirectional encrypted communication protocol via the cloud node routing table. The handshake initiator is the node currently ranked first in the cloud node routing table. The initiator sends a handshake request message carrying the cloud domain certificate to the responder, with the message including the channel identifier generation rule and key negotiation parameters. During the handshake process, both nodes submit their cloud domain-issued node certificates to each other. The initiator submits first, and the responder submits the peer's certificate after successful verification. Once both certificates are successfully verified, the key negotiation phase begins. If verification fails at either end, the handshake is interrupted and retried using an exponential backoff strategy starting at 500ms, with a maximum of 3 retries. Nodes marked as high-fluctuation nodes in the cloud node routing table have their handshake timeout thresholds appropriately relaxed to avoid frequent handshake interruptions caused by instantaneous fluctuations in connectivity quality. After key negotiation, an encrypted session is established between the two ends. The cross-cloud encrypted communication channel is established based on this encrypted session. The channel identifier is generated by concatenating the identifier of the initiating node and the identifier of the responding node. Only one valid cross-cloud encrypted communication channel is allowed between the same node pair. When a channel is repeatedly established, the new channel replaces the old channel and triggers the release of resources of the old channel. Cross-cloud encrypted communication channels involving key monitored nodes in the cloud node routing table immediately enter a continuous connectivity probing state after establishment. The probing interval is consistent with the status collection interval of the key monitored nodes. When a connectivity anomaly occurs in the cross-cloud encrypted communication channel, the backup node ranked second in the cloud node routing table immediately initiates the new channel establishment process.

[0022] In some embodiments, the step of performing downgrade preparation two-way certificate authentication to generate authentication channel credentials for the cross-cloud encrypted communication channel includes: measuring the certificate handshake latency value of each node for the cross-cloud encrypted communication channel; sorting and identifying high-latency nodes and low-latency nodes according to the certificate handshake latency value; constructing a credential priority mapping based on the latency difference between the high-latency nodes and the low-latency nodes; and using the credential priority mapping in combination with the high-latency nodes to generate authentication channel credentials.

[0023] This study measures the certificate handshake latency of each node in a cross-cloud encrypted communication channel. The measurement is triggered immediately after the channel is established. The round-trip latency of the actual certificate exchange process within the channel is used as the measurement object. The time difference from the sending of the handshake message to the return of the handshake acknowledgment from the other end is taken as a single measurement value. Each node is measured five times consecutively, and the median is used as the representative value. The median is less sensitive to extreme outliers than the mean and more accurately reflects the node's true handshake performance. The certificate handshake latency of nodes traversing multiple cloud domains in the cross-cloud encrypted communication channel is typically higher than that of intra-domain paths. This is because cross-domain certificate chain verification requires additional access to the certificate authorities of each cloud domain, with each additional verification hop introducing an average additional latency of 20 to 40 ms. If a node experiences a response timeout during the measurement period, and the number of timeouts exceeds three, the node's certificate handshake latency is marked as an unstable measurement result. When classifying unstable results as high or low latency, the maximum measured value is used as the representative value to conservatively estimate the node's handshake performance. In the certificate handshake latency value, nodes marked as key monitoring nodes in the cloud node routing table are re-measured every 5 minutes, while ordinary nodes are re-measured every 30 minutes. If the deviation between two consecutive measurements exceeds 50ms, a supplementary test is triggered, and the average of the two values ​​is used to update the representative value. The cross-cloud encrypted communication channel maintains normal communication unaffected during the measurement period, and measurement messages and service messages are transmitted through independent measurement sub-sessions within the channel.

[0024] High-latency nodes are identified by sorting their certificate handshake latency values. The sorting is based on the representative certificate handshake latency values ​​of all nodes, arranged in descending order. The dividing line is dynamically determined by the statistical characteristics of the certificate handshake latency value distribution, rather than using a fixed threshold, to accommodate scenarios with significant differences in latency distribution across different network sizes. Nodes with a representative certificate handshake latency value exceeding the median plus 1.5 interquartile range are identified as high-latency nodes, while those below the median minus 0.5 interquartile range are identified as low-latency nodes. Nodes in between are categorized into the intermediate latency range. Nodes in the intermediate latency range are treated according to the rules for low-latency nodes in the credential priority mapping but assigned a lower priority weight. High-latency nodes are typically concentrated in sets of nodes with long cross-domain paths. For example, a node that needs to cross three cloud domains to reach the authentication server will have a significantly higher certificate handshake latency value than a node that only crosses one cloud domain; the latency difference between the two types of nodes often exceeds 100ms. The certificate handshake latency values ​​of low-latency nodes are concentrated and have a small standard deviation, indicating stable handshake performance and suitability for the main path role in credential distribution. Nodes in high-latency nodes marked as unstable by measurement results are additionally labeled with fluctuations. Nodes with fluctuation labels have a further reduced priority in credential priority mapping. After the certificate handshake latency value is refreshed, the high and low latency classification results are updated synchronously. Nodes with changing classifications trigger a local reconstruction of the corresponding credential priority mapping.

[0025] For example, the step of constructing a credential priority mapping based on the latency difference between the high-latency node and the low-latency node includes: calculating the latency difference between the low-latency node and the high-latency node to generate an asymmetric overhead distribution; identifying a dominant low-overhead node region based on the asymmetric overhead distribution; performing cold standby node pre-activation credential distribution path analysis on the dominant low-overhead node region to construct a credential coverage topology; and extracting cross-domain credential distribution paths based on the credential coverage topology to generate a credential priority mapping.

[0026] An asymmetric overhead distribution is generated by calculating the latency difference between low-latency and high-latency nodes. The latency difference is calculated by subtracting the representative value of the certificate handshake latency for each low-latency node from the representative value for each high-latency node. The difference matrix reflects the degree of overhead asymmetry between all node pairs; a larger difference indicates a more significant performance gap in handshake between the corresponding node pairs. The asymmetric overhead distribution is generated by partitioning the difference matrix according to the magnitude of the difference. Node pairs with a difference exceeding 1.5 times the median of all differences are classified into the high asymmetry region, while those with a difference below 0.5 times the median are classified into the low asymmetry region. The high asymmetry region indicates that the corresponding low-latency node has a significant handshake advantage and is prioritized as a candidate starting point for credential distribution. The difference between a low-latency node and other low-latency nodes is usually small or even negative. Negative differences are assigned a value of 0 in the asymmetric overhead distribution, indicating that the handshake performance of the two nodes is comparable and there is no asymmetric overhead advantage. The distribution density of node pairs in the high asymmetry region of the asymmetric overhead distribution reflects the concentration of nodes with superior handshake performance throughout the channel. Higher density indicates a greater concentration of low-overhead nodes and a more abundant pool of alternative credential distribution paths. For example, if multiple low-latency node pairs within a cloud domain exhibit a high asymmetric distribution of the same batch of high-latency nodes, this cloud domain becomes a preferred starting area for credential distribution paths. Node pairs consisting of fluctuation-marked nodes and low-latency nodes in the high-latency node distribution receive an additional fluctuation penalty weight in the asymmetric overhead distribution. This fluctuation penalty weight reduces the effective difference of the node pair by 10%.

[0027] Dominant low-overhead node regions are identified based on asymmetric cost distribution. The identification of dominant low-overhead node regions is based on the geographical and logical distribution of node pairs in high-asymmetric regions. The set of cloud domain labels covered by low-latency nodes in high-asymmetric regions is used as candidate regions. The more nodes and the higher the average difference in a candidate region, the greater the likelihood that the region will become a dominant low-overhead node region. When the number of low-latency nodes in a candidate region within a high-asymmetric region of asymmetric cost distribution exceeds 60% of the total number of nodes in that region, that region is determined to be a dominant low-overhead node region. When multiple candidate regions simultaneously meet the condition, the region with the highest average difference in low-latency nodes is selected. If the differences are similar, the region with more nodes is selected to ensure wider credential coverage. The boundary of a dominant low-overhead node region is determined by both sub-network segments and cloud domain labels. Candidate regions spanning multiple sub-network segments but belonging to the same cloud domain are merged into a single dominant low-overhead node region to reduce the interference of regional fragmentation on path analysis. For example, if the low-latency nodes in three sub-network segments within a cloud domain all exhibit high asymmetric characteristics in the asymmetric cost distribution, the three sub-network segments are merged into a single dominant low-overhead node region. After the asymmetric overhead distribution is updated, the determination of the dominant low-overhead node region is re-executed. When the proportion of low-latency nodes in the original dominant low-overhead node region drops below 40%, the region exits its dominant position, and the next candidate region in the asymmetric overhead distribution that meets the conditions takes over as the new dominant low-overhead node region.

[0028] A credential coverage topology is constructed by analyzing the distribution path of pre-activated credentials for cold standby nodes in the dominant low-overhead node region. The analysis uses nodes within the dominant low-overhead node region as distribution starting points. Path cost is determined by the number of forwarding hops and the average certificate handshake latency per hop. The cumulative path latency is obtained by multiplying the number of hops by the average single-hop latency; paths with lower cumulative latency have higher priority. The set of paths from each starting node within the dominant low-overhead node region to all cold standby nodes constitutes the basic edge set of the credential coverage topology. Each edge records three attributes: the starting node identifier, the ending cold standby node identifier, and the cumulative path latency. The credential coverage topology is organized as a directed graph, with directed edges pointing from the distribution starting point to the cold standby node. When a cold standby node is covered by multiple starting points, only the edge with the lowest cumulative path latency is retained. Removing redundant edges results in a more compact credential coverage topology, facilitating the extraction of cross-domain credential distribution paths. Nodes outside the dominant low-overhead node region that have a cumulative latency lower than 80% of the starting path within that region are also included in the credential coverage topology. This is to prevent overly strict region boundaries from missing high-quality distribution paths. For example, if a node outside the dominant low-overhead node region is directly connected to multiple cold standby nodes and meets the inclusion criteria, it is added to the credential coverage topology. After the credential coverage topology is established, it is verified that all cold standby nodes have at least one valid incoming edge. If a cold standby node has no incoming edge, a connection is forcibly established from the starting point with the lowest cumulative path latency within the dominant low-overhead node region.

[0029] Based on the credential coverage topology, cross-domain credential distribution paths are extracted to generate credential priority mappings. Cross-domain credential distribution paths are extracted from the directed edge set of the credential coverage topology. The edge with the lowest cumulative latency is selected as the primary distribution path, and the edge with the second lowest cumulative latency is selected as the backup distribution path. Both the primary and backup paths cover the same cold backup node to ensure uninterrupted credential distribution capability in the event of a single path failure. Paths involving cross-domain boundaries in the credential coverage topology are additionally subject to an inter-domain verification penalty coefficient. The penalty coefficient increases linearly with the number of cloud domains crossed. The penalty coefficient is calculated as α = 1 + n × 0.1, where α is the inter-domain verification penalty coefficient, and n is the number of cloud domains crossed by the path. When crossing one domain, α = 1.1; when crossing two domains, α = 1.2. The formula for calculating the corrected latency is T_mod = T_cum × α, where T_mod is the corrected latency in milliseconds, and T_cum is the original cumulative latency of the path in milliseconds. The corrected latency serves as the final basis for path priority ranking. For example, if a path crosses two cloud domain boundaries, its T_mod, after penalty adjustment, may be higher than a path with fewer cross-domain boundaries but slightly higher original latency, and it may still be ranked at a lower priority. All cross-domain credential distribution paths are arranged in ascending order of T_mod to form a credential priority mapping. The mapping relationship corresponds to each path in the credential coverage topology from high priority to low priority. Each cold standby node in the credential priority mapping has at least two paths: primary and backup. Cold standby nodes that cannot extract backup paths are marked as single-path coverage and trigger more stringent real-time connectivity verification. When the path status of an edge in the credential coverage topology changes, the path entries involving that edge in the credential priority mapping trigger a local update. After the local update, the priority ranking of the credential priority mapping is rearranged within the range of the cold standby nodes to which that path belongs.

[0030] Authentication channel credentials are generated using a credential priority mapping combined with high-latency nodes. In the credential priority mapping, the main distribution path corresponding to each high-latency node pushes credentials from the high-priority starting point to the target high-latency node. High-latency nodes include cold backup nodes involved in the credential coverage topology. The credential content includes the channel identifier, validity period start and end times, a set of supported downgraded protocol versions, and the issuing node identifier. The downgraded protocol version set includes multiple lightweight protocol alternatives preset when the handshake performance of high-latency nodes is poor, allowing direct switching to alternative protocols without re-authentication in case of main protocol handshake failure. When a high-latency node receives a credential, it performs an integrity check, verifying the credential signature using the issuing node's public key. If the check fails, the credential is re-acquired along the backup distribution path of the credential priority mapping. Two consecutive check failures trigger a credential re-issuance mechanism, which is performed by the highest-priority low-latency node to ensure the quality of the re-issuance link. The validity period of authentication channel credentials is negatively correlated with the handshake latency of high-latency nodes. Nodes with higher handshake latency are assigned shorter validity periods. Shorter validity periods force nodes to update credentials more frequently, thus continuously verifying the node's identity legitimacy. For example, if a high-latency node's handshake latency is 350ms, its authentication channel credential validity period is set to 60% of the standard value. Authentication channel credentials are transmitted on the distribution path determined by the credential priority mapping, without using the default path of the cross-cloud encrypted communication channel. If the primary distribution path is unavailable, the backup path automatically takes over and is marked in the authentication channel credential record. For high-latency nodes, the renewal process is triggered 15% of the validity period before the authentication channel credential expires, ensuring that the credential is refreshed before expiration.

[0031] The cross-cloud encrypted communication channel is configured for multi-channel reuse using authentication channel credentials to determine the reused channel group. The channel identifier and the set of downgraded protocol versions carried in the authentication channel credentials are used as parameters for reuse configuration. The channel identifier distinguishes multiple logical sub-channels between the same node pair in the cross-cloud encrypted communication channel. The set of downgraded protocol versions specifies the range of protocols allowed for each logical sub-channel. Each sub-channel protocol is independent, and an anomaly in one channel does not affect other channels. After the authentication channel credentials are verified, the cross-cloud encrypted communication channel is split into multiple logical sub-channels according to the channel identifier. Each logical sub-channel is independently addressed using the cross-cloud encrypted communication channel as its carrier and inherits its encryption parameters. Each sub-channel has an independent sequence number space. The number of sub-channels is determined by the maximum reuse quantity field in the authentication channel credentials; the upper limit is used when bandwidth is sufficient, and the number is linearly reduced according to the remaining capacity when resources are scarce. The number of sub-channels corresponding to high-latency nodes does not exceed 50% of the reuse limit. Nodes with high handshake latency take longer to complete a single handshake; excessive use of sub-channels will slow down the overall throughput of the channel group. The number of sub-channels is tightened accordingly as the handshake performance gap widens. A reuse channel group consists of a set of logical sub-channels that have all passed verification and completed sub-channel allocation. Each sub-channel is accompanied by a corresponding authentication channel credential identifier and priority weight. Sub-channels with higher weights take priority over high-priority services. After the reuse channel group is established, probe messages are sent to each sub-channel to verify connectivity. Sub-channels that fail the probe are marked as pending activation. When the number of pending activations exceeds 30% of the total number of reuse channel groups, a reuse configuration re-evaluation is triggered. When the authentication channel credential expires, the corresponding sub-channel enters a suspended state, during which it is taken over by other valid sub-channels in the reuse channel group.

[0032] Step S130: Message queue transparent proxy binding is performed on the multiplexed channel group to generate service access mapping. The service access mapping is combined with the link quality baseline to perform implicit health inference of service packets to generate a health index sequence. Based on the health index sequence, link quality degradation analysis is performed to determine the link health level.

[0033] Specifically, a transparent proxy binding is performed on the multiplexed channel group to generate a service access map. The transparent proxy layer intercepts message delivery requests from service senders and routes the delivery requests to logical sub-channels with matching priorities within the multiplexed channel group based on message type. The routing results are written into the service access map for subsequent channel status linkage. Each logical sub-channel in the multiplexed channel group is bound to a message queue partition one-to-one according to priority weight. High-weight sub-channels are bound to high-priority queue partitions, and a single queue partition is bound to only one sub-channel to ensure that the message processing order is not disrupted. The service access map records the correspondence between each sub-channel identifier and the queue partition identifier, as well as the current online status of each sub-channel. When the online status is offline, the queue partition corresponding to that sub-channel is automatically switched to the next priority sub-channel in the multiplexed channel group. The switching in the service access map is transparent to the message sender. Sub-channels in the multiplexed channel group that are to be activated are marked as pending binding in the service access map. When the message backlog of the pending binding partition exceeds a threshold, the sub-channel is forcibly activated and the binding is completed, ensuring that the queue backlog does not continue to expand due to delayed activation of the channel. The service access mapping is updated in real time along with the status of the sub-channels in the multiplexing channel group. When a sub-channel is suspended, its binding relationship is temporarily transferred to the active sub-channel. After the suspension is lifted, the original binding relationship is restored. Changes in the service access mapping synchronously trigger the update of the routing rules in the message queue proxy layer.

[0034] In some embodiments, the step of generating a health index sequence by implicitly inferring the health of service packets through the service access mapping and the link quality baseline includes: separating primary path packet features and backup path packet features for the service access mapping; calculating the difference in packet out-of-order rate between the primary path packet features and the backup path packet features to generate a path quality difference index; performing deviation analysis based on the path quality difference index to determine the health correction type; and quantifying the health correction type into a health deviation degree by combining it with the link quality baseline and mapping it to generate a health index sequence.

[0035] For service access mapping, primary path packet characteristics and backup path packet characteristics are separated. The binding relationship between sub-channels in the service access mapping distinguishes between primary path sub-channels and backup path sub-channels. Primary path sub-channels carry normal service traffic, while backup path sub-channels take over traffic when the primary path is downgraded or switched over. Both types of sub-channels have complete transmission records at the transparent proxy layer. Statistical quantities extracted from the primary path sub-channel transmission records constitute the primary path packet characteristics, including sequence number continuity and throughput per unit time. Sequence number continuity reflects whether packets are out of order or lost. Backup path packet characteristics are extracted from the backup path sub-channel transmission records using the same dimensions. When not carrying services, backup path sub-channels maintain connectivity with low-frequency probe packets. The characteristic values ​​generated by these probe packets serve as the baseline reference values ​​for backup path packet characteristics. After service switching to the backup path, the measured characteristic values ​​replace the baseline reference values. The collection window for primary path and backup path packet features is aligned with the service access mapping refresh cycle. The collection window is reset after each service access mapping refresh to ensure that feature values ​​reflect the latest channel status. When the number of packets in the collection window is less than 10, the corresponding feature value is marked as insufficient sample. Feature values ​​with insufficient samples are downweighted during the out-of-order rate difference generation stage. Sub-channels in the pending binding state in the service access mapping cannot have valid primary path and backup path packet features extracted; the corresponding positions are filled with empty feature values. Empty feature values ​​are skipped during the path quality difference index generation stage.

[0036] A path quality difference index is generated by calculating the difference in out-of-order rates between the primary path and backup path message characteristics. The out-of-order rate is derived from the sequence number continuity index; the number of messages with non-contiguous sequence numbers is divided by the total number of messages within the window. The primary and backup paths are counted independently. A higher out-of-order rate indicates poorer message transmission quality for that path. The difference between the out-of-order rates of the primary and backup paths is calculated. A positive difference indicates a higher degree of out-of-order transmission on the primary path than on the backup path, and a larger absolute value indicates a more significant quality gap between the two paths. The out-of-order rate difference, combined with the throughput deviation, constitutes the path quality difference index. The throughput deviation is obtained by dividing the difference in throughput per unit time between the primary and backup path message characteristics by the normalized mean throughput of the primary path; values ​​exceeding 1 are truncated to 1. The path quality difference index is organized as a two-component vector. The first component is the out-of-order rate difference, and the second component is the normalized throughput deviation. The combination of the signs of the two components reflects the direction of the quality difference between the two paths. For example, if the first component is positive and the second component is negative, it indicates that the main path has severe out-of-order issues and low throughput. If both indicators deteriorate in the same direction, it suggests that there is a persistent quality problem in the main path. The insufficient sample labeling of the path quality difference index is inherited from the packet characteristics of the main path or the backup path. When the sample is insufficient on either side, the corresponding component of the path quality difference index is labeled as low confidence. The low confidence component is not used as the main criterion in subsequent deviation analysis.

[0037] Health correction types are determined through deviation analysis based on the path quality difference index. The deviation analysis uses the historical baseline value of the path quality difference index as a reference. The baseline value is determined by the mean of the two components of each detection cycle over the most recent 24 hours. A significant deviation is defined as the difference between the current path quality difference index and the baseline value exceeding twice the baseline standard deviation. Deviations are classified into three health correction types according to their direction and magnitude: main path disadvantage deviation, equilibrium deviation, and main path advantage deviation. A main path disadvantage deviation is defined as a positive first component with an absolute value exceeding 0.15; an equilibrium deviation is defined as a first component with an absolute value within 0.05; and all other cases are defined as main path advantage deviations. Cycles with deviations not exceeding twice the baseline standard deviation are treated as equilibrium deviations by default. The low-confidence component of the path quality difference index is not involved in the deviation direction determination. When both components are low-confidence, the health correction type is marked as insufficient confidence. In the case of insufficient confidence, the correction type follows the determination result of the previous cycle. When the path quality difference index is determined to be of the same health correction type for three consecutive cycles, a type stabilization label is triggered. A stabilization label indicates that the current deviation state has persisted for a sufficiently long time rather than being a momentary fluctuation. For example, if a channel exhibits a primary path disadvantage deviation for three consecutive cycles and the first component consistently exceeds 0.2, the health correction type after stabilization will receive a higher correction weight in subsequent health deviation mappings. The threshold for determining the health correction type is dynamically adjusted based on the link quality baseline. When the standard deviation of the corresponding channel's delay in the link quality baseline increases, the threshold is appropriately widened.

[0038] The health correction type is quantified into a health deviation by combining it with the link quality baseline and mapped to generate a health index sequence. The deviation is quantified based on the difference between the mean round-trip time (RTT) of the corresponding channel in the link quality baseline and the current measured RTT. The dimensionless basic deviation calculation formula is D_base=(RTT_t-μ) / σ, where D_base is the dimensionless basic deviation, RTT_t is the measured RTT in milliseconds for the current probe period, μ is the mean RTT of the corresponding channel in the link quality baseline in milliseconds, and σ is the standard deviation of the RTT of the corresponding channel in the link quality baseline in milliseconds. The health correction type applies a multiplicative correction coefficient k to the quantization result. The main path disadvantage deviation corresponds to k=1.3, the equilibrium deviation corresponds to k=1.0, the main path advantage deviation corresponds to k=0.8, and the stable labeled health correction type has an additional 0.1 added to the original coefficient. The corrected health deviation calculation formula is D_mod = D_base × k, where D_mod is a dimensionless value representing the corrected health deviation. A D_mod value exceeding 3 is considered a severe deviation, exceeding 1.5 is considered a slight deviation, and not exceeding 1.5 is considered within the normal range. The health index sequence consists of D_mod values ​​for each detection period arranged chronologically with corresponding deviation level labels. When the difference in D_mod values ​​between two adjacent periods exceeds a threshold, a jump label is added. For the health index sequence of channels corresponding to high-fluctuation nodes in the link quality baseline, a relaxed threshold is used when determining the deviation level. Periods with a health correction type of insufficient confidence are marked with a low-confidence label in the health index sequence. Low-confidence label entries do not trigger severe degradation determination in degradation analysis.

[0039] In some embodiments, determining the link health level based on the link quality degradation analysis of the health index sequence includes: performing noise filtering on the health index sequence to generate a degradation feature set; performing recovery trend backtracking analysis on the health index sequence to generate a recovery feature set; comparing the degradation feature set with the recovery feature set to identify the dominant degradation interval and generate a dominant degradation feature; and performing level mapping based on the dominant degradation feature to determine the link health level.

[0040] Noise filtering is performed on the health index sequence to generate a degradation feature set. Median filtering is used, employing a sliding window of five consecutive detection periods. The median of the health deviation in each period within the window replaces the original value. Median filtering effectively eliminates interference from single-point anomalies in identifying degradation trends. For example, if a channel experiences abnormally high deviation in a single period due to instantaneous network jitter, it will be suppressed by neighboring normal values ​​after filtering, preventing misidentification as persistent degradation. Low-confidence entries in the health index sequence are not included in the median calculation. The median of the window containing low-confidence entries is calculated from the remaining valid entries. If there are fewer than three valid entries, the window is marked as unreliable, and unreliable windows are not included in the degradation feature set. In the filtered health index sequence, segments with a deviation level of mild deviation or above that persists for more than two consecutive cycles are extracted as deterioration candidate segments. The start and end cycles of a deterioration candidate segment, along with the average deviation within the segment, serve as the descriptive triplet for that segment. For a certain cross-cloud channel affected by continuous inter-cloud congestion, the deviation remains in the severe deviation range across multiple detection cycles; this is extracted as a single descriptive triplet. The deterioration feature set is composed of the descriptive triplets of all deterioration candidate segments. When the start cycle interval between two adjacent candidate segments is less than three detection cycles, they are merged. The average deviation after merging is the weighted average of the two candidate segments based on their duration. When there are no severely deviated segments in the health index sequence, the deterioration feature set is empty. Subsequent steps also apply to empty inputs, and the dominant deterioration feature is directly set to a no-deterioration state. Candidate segments with abrupt changes are additionally labeled as abrupt deterioration in the deterioration feature set.

[0041] Recovery trend backtracking analysis is performed on the health index sequence to generate a recovery feature set. Recovery trend backtracking identifies segments in the health index sequence where the deviation continuously decreases. A recovery event is defined as a monotonically decreasing deviation over three or more consecutive periods, with the final deviation below the slight deviation threshold. Monotonically decreasing requires a difference of at least 0.05 between adjacent periods to exclude minor decreases caused by numerical noise. The recovery event's starting period deviation, ending period deviation, and recovery duration constitute the recovery description vector. The difference between the starting and ending deviations reflects the magnitude of the recovery; a larger difference indicates a more significant improvement in channel quality. The recovery feature set is composed of the recovery description vectors of all recovery events in the health index sequence. Recovery events with a duration exceeding five detection periods are marked as stable recovery. Stable recovery signifies sustained quality improvement rather than a temporary rebound. For example, if a channel's deviation decreases from 2.8 to 0.4 within six periods, with the final deviation below the slight deviation threshold, it is considered a stable recovery, and a stable label is added to the recovery feature set. Low-confidence entries in the health index sequence block the identification of recovery trends. Low-confidence entries truncate the recovery segment into two segments, and each segment is independently judged to determine whether it meets the recovery event conditions. The recovery magnitude of stable recovery events in the recovery feature set is cross-compared with the mean deviation of the corresponding deterioration candidate segment. When the recovery magnitude exceeds 80% of the mean deviation of the corresponding deterioration candidate segment, it is considered as complete recovery; when it is below 80%, it is considered as partial recovery.

[0042] The dominant degradation feature is generated by comparing the degradation feature set and the recovery feature set to identify degradation-dominant intervals. The identification of the dominant degradation interval involves overlapping analysis between the time ranges of each degradation candidate segment in the degradation feature set and the time ranges of each recovery event in the recovery feature set. When there is no overlap, the candidate segment is directly identified as the dominant degradation interval. When there is overlap, the mean deviation and recovery amplitude of the candidate segment are compared; if the mean deviation is greater than the recovery amplitude, it is identified as the dominant degradation interval. Events marked with stable recovery in the recovery feature set have a higher adversarial weight in the overlap analysis, and overlapping intervals corresponding to stable recovery are more likely to be identified as dominant recovery intervals. All candidate segments of the dominant degradation interval in the degradation feature set are sorted in descending order of mean deviation. The candidate segment with the highest mean deviation is determined as the dominant degradation interval. The duration of the dominant degradation interval and the mean deviation together constitute the dominant degradation feature. When the degradation feature set is empty, the recovery event with the smallest recovery amplitude in the recovery feature set is used as an auxiliary reference. The degradation severity in the dominant degradation feature is marked as mild with low confidence, indicating that the current channel is in a recovery state but has not yet fully stabilized. When the time ranges of stable recovery events in the recovery feature set and abrupt degradation candidate segments in the degradation feature set are adjacent, the two are analyzed together to determine whether an oscillation pattern exists. This alternating pattern of degradation and recovery is common when network devices in the cloud domain experience periodic fluctuations. In the oscillation pattern, the dominant degradation feature is marked with an oscillation label, and the severity level of the oscillation label channel is increased by one level during grade mapping. Degradation intervals in the dominant degradation features that last for more than 10 detection cycles and have a mean deviation D_mod exceeding 2.5 are labeled as high-confidence severe degradation. High-confidence severe degradation directly corresponds to the lowest link health level during grade mapping.

[0043] Link health levels are determined using a grading system based on dominant degradation features. The grading is based on two dimensions: the duration of degradation severity and the mean deviation of the dominant degradation features. After independent mapping of the two dimensions, the higher level is taken as the final link health level, ensuring that the link status is accurately reflected even when either dimension is severely degraded. Deviation dimension: A mean D_mod value exceeding 4 maps to severe degradation, a mean D_mod value between 3 and 4 maps to moderate degradation, and a mean D_mod value below 3 maps to mild degradation. Duration dimension: Exceeding 8 detection cycles maps to severe degradation, 4 to 8 cycles maps to moderate degradation, and less than 4 cycles maps to mild degradation. The final link health level is the higher of the two dimensions; when the dominant degradation feature is set to no degradation, the link health level is mapped to normal. For oscillation-labeled dominant degradation features, the severity level is increased by one level in the grading system, and high-confidence severe degradation labels are directly mapped to severe degradation. After the link health level is determined, it is compared with the result of the previous period. If the level drops continuously for more than 3 periods, a degradation acceleration alarm is triggered, indicating that the channel quality is showing a continuous deterioration trend. Among the dominant degradation features, degradation severity with insufficient confidence does not trigger a severe degradation level, and is only mapped to moderate degradation at most, in order to avoid excessive alarms caused by low confidence data. The link health level is refreshed with each probing period, and a link quality degradation notification is triggered when the level crosses the mild degradation threshold.

[0044] Step S140: Perform link degradation prediction on the link health level to generate pre-degradation trigger conditions, construct a degradation execution strategy based on the pre-degradation trigger conditions, and generate a degradation communication sequence based on the degradation execution strategy.

[0045] Specifically, link health levels are used to predict link degradation and generate pre-degradation trigger conditions. Link degradation prediction is based on the temporal trend of link health levels. Link health levels are assigned values ​​according to severity: 0 for normal, 1 for mild degradation, 2 for moderate degradation, and 3 for severe degradation. The degradation slope is s = ΔL / Δp, where ΔL is the decrease in link health level value over the last 5 detection cycles in the number of levels, Δp is the corresponding number of cycles, and s is the number of levels per cycle. When s exceeds 0.3, it is considered a rapid degradation trend. Predictive analysis is triggered when the link health level shows a continuous decline over the last 5 detection cycles. s and the current level together determine the severity level of the pre-degradation trigger condition. The combination of these two inputs allows the prediction result to reflect both the absolute position of the current quality and the forward risk brought about by the degradation rate. When the current link health level is moderately degraded and there is a rapid degrade trend, the severity of the pre-degradation trigger condition is set to "urgent." The "urgent" level requires the degradation strategy to be built within the next probe cycle. In scenarios with concentrated cross-cloud business traffic, such rapid decline is often accompanied by the simultaneous deterioration of multiple links. The "urgent" level trigger ensures that the degradation strategy is deployed before the quality window completely closes. When the link health level is slightly degraded but the s value consistently exceeds 0.15, the "alert" level pre-degradation trigger condition is triggered. The "alert" level allows the degradation strategy to be completed within 3 probe cycles, providing more preparation time. This is suitable for channels with a slower degradation pace but a clear trend. In such scenarios, early alerts effectively avoid insufficient strategy building time caused by passive waiting. The pre-degradation trigger condition includes a snapshot of the link health level and the s value at the trigger time. Both pieces of information completely record the channel status at the trigger time. The corresponding pre-degradation trigger condition automatically expires after the link health level returns to normal.

[0046] In some embodiments, constructing a degradation execution strategy based on the pre-degradation triggering condition includes: extracting the priority values ​​of all messages in the pre-degradation triggering condition; setting a grading threshold based on the priority values ​​to define a high-priority interval and a low-priority interval; performing a message idempotency verification test in the high-priority interval to generate a candidate degradation strategy set; and constructing a degradation execution strategy based on the candidate degradation strategy set and the characteristics of delayable messages in the low-priority interval.

[0047] Extract the priority values ​​of all messages in the pre-degradation trigger condition. The pre-degradation trigger condition is associated with a complete snapshot of the message queue to be transmitted within the current channel. The snapshot is collected synchronously at the time the pre-degradation trigger condition is triggered, covering all message records in the bound queue partitions of the corresponding channel. The snapshot content includes the message identifier, enqueue timestamp, priority field, and message type tag. The message priority field is explicitly marked by the business sender when delivering, and the value ranges from 1 to 10, with higher values ​​indicating higher priority. When the pre-degradation trigger condition is at the emergency level, messages with missing priority fields are assigned a default value of 5 as intermediate priority. Priority values ​​are extracted by iterating over the message identifier, covering all messages to be transmitted in the queue snapshot. Messages with the same priority are sorted in ascending order by enqueue timestamp, and messages with earlier enqueue times are given priority when constructing the degradation strategy. When the pre-degradation trigger condition is at the warning level, the priority value extraction range only covers messages enqueued within the most recent hour. At the emergency level, this range expands to the most recent three hours. This expanded range ensures that high-priority messages accumulating in a short period are not missed. During peak business periods, when pre-degradation is triggered, the queue often contains a large number of short-term backlogged messages; the expanded range effectively identifies the high-priority portion. The skewness of the priority value distribution reflects the current business characteristics of the queue. When high-priority messages account for more than 60%, it indicates a high sensitivity to degradation. The severity classification of the pre-degradation trigger condition needs to be assessed in conjunction with the skewness to determine whether to increase the threshold. When extreme values ​​are dispersed in the priority value distribution, the range of the classification threshold is correspondingly widened; when extreme values ​​are concentrated, the classification threshold converges towards the concentrated area.

[0048] The priority threshold is set based on priority values ​​to define high-priority and low-priority intervals. The threshold is set based on the distribution characteristics of priority values ​​rather than using fixed values. The lower bound of the high-priority interval is θ_H = Mp + σp, and the upper bound of the low-priority interval is θ_L = Mp - σp, where Mp is the median of all message priority values ​​and σp is the standard deviation of priority values. All messages with a priority higher than θ_H are assigned to the high-priority interval, and all messages with a priority lower than θ_L are assigned to the low-priority interval. Messages between the two intervals are assigned to an intermediate buffer zone. Whether messages in the intermediate buffer zone are included in the protection scope is determined by the remaining channel capacity during downgrade execution. Priority distribution varies significantly across different business scenarios. In financial business queues, high-priority messages are highly concentrated, and a smaller σp results in a narrower gap between θ_H and θ_L, causing the priority threshold to converge towards the higher value range. In contrast, in mixed business queues, the priority distribution is dispersed, and a larger σp naturally widens the boundary between the two intervals. The adaptive threshold setting can accurately distinguish the protection boundary in both scenarios. The proportion of messages in the high-priority interval to the total queue volume reflects the degradation pressure. When the proportion exceeds 40%, the upper limit of messages allowed to be included is tightened to 70% of the current channel's available throughput. If the throughput decreases significantly after channel degradation but the number of high-priority messages still exceeds capacity, messages within the interval are truncated according to their enqueue time to ensure that the earliest enqueued high-priority messages are transmitted first. The delayability characteristic of messages in the low-priority interval is determined based on the message delivery timeout tolerance value field. Messages whose tolerance value exceeds the degradation slope s corresponding to the expected remaining available time are included in the delayable message set. Delayable messages release channel resources for high-priority interval messages during degradation execution. The division result of the high-priority and low-priority intervals triggers threshold recalculation as the priority value changes. Adding or dequeuing messages triggers synchronous refresh of θ_H and θ_L.

[0049] For example, the step of performing message idempotency verification testing in the high-priority interval to generate a candidate degradation strategy set includes: extracting idempotency retry features in the high-priority interval to generate an idempotency score; performing channel stability screening based on the idempotency score to generate a high-stability path; performing strategy adaptation based on the idempotency score and the high-stability path to generate a strategy priority sequence; and determining the candidate degradation strategy set according to the strategy priority sequence.

[0050] Idempotent retry features are extracted and idempotent scores are generated within the high-priority interval. Idempotent retry features are extracted from the historical transmission records of each message within the high-priority interval. These records include the message's response result in each transmission attempt, the number of retries, and the interval between each retry. These three data points characterize the message's behavior in repeated transmission scenarios from different dimensions. Messages with idempotent keys and consistent processing results across multiple transmissions are marked as strongly idempotent; messages with idempotent keys but inconsistent results in the past are marked as weakly idempotent; and messages lacking idempotent keys are marked as non-idempotent. The corresponding base scores E_base for these three categories are assigned 0.9, 0.5, and 0.1, respectively. The idempotent score E_i for a single message within the high-priority interval is E_base × c, where c is the retry stability correction coefficient. c is measured by the standard deviation of the historical retry interval; a smaller standard deviation indicates more regular retry behavior. c ranges from 0.9 to 1.1, and E_i is truncated to the range of 0 to 1. Real-time control messages, due to their complete idempotent keys and highly stable historical retry intervals, have idempotent keys (c) approaching their upper limit and significantly higher retry intervals (E_i) than batch reporting messages. The natural difference in scores between these two message types drives subsequent sub-channel differentiated matching, concentrating degraded resources towards message types with stronger reliable retry capabilities. Messages with fewer than three historical transmission records within the high-priority interval are marked with low-confidence idempotent scores. This low-confidence marking triggers deweighting during the channel stability screening phase, preventing messages with insufficient historical data from occupying high-quality sub-channel resources due to excessively high scores. Idempotent scores are aggregated by message identifier to form the overall score distribution for the high-priority interval. A higher distribution mean indicates stronger overall retry capability within that interval under degraded scenarios, while a larger distribution variance indicates more significant differences in the idempotent characteristics of messages within the interval.

[0051] High-stability paths are generated through channel stability screening based on idempotency scoring. Channel stability screening matches the message set with higher idempotency scores with the quality indicators of each sub-channel in the multiplexing channel group. The sub-channel quality indicator is taken from the rolling average D_mod_avg of the health indicator sequence over the most recent 5 periods, calculated as D_mod_avg=(1 / 5)×ΣD_mod(ti), i=0,1,2,3,4, where D_mod(ti) is the corrected health deviation in the ti-th probe period. The rolling average effectively smooths short-term fluctuations compared to single-period values, more accurately reflecting the continuous health level of the sub-channel. Messages with E_i exceeding 0.7 require the carrying sub-channel to meet D_mod_avg<1.0. Messages with low confidence E_i employ a conservative matching strategy, requiring the carrying sub-channel to meet D_mod_avg<0.5. The conservative threshold is stricter to address the matching risks caused by scoring uncertainty. The set of sub-channels that meet the stability threshold corresponding to the idempotency score constitutes the candidate stable channel pool. The candidate pool is arranged in ascending order of D_mod_avg, with the most stable sub-channel at the top. The sub-channel stability ranking directly affects the allocation priority during subsequent policy adaptation. High-stability paths are selected from the candidate stable channel pool. The selection rules are that they must cover at least all message types in the high-priority range and the number of sub-channels must not exceed 60% of the total number of reused channel groups. In cross-cloud scenarios, channel resources are already tight. The upper limit constraint on the number of high-stability paths effectively avoids squeezing the transmission space of other services due to a large number of locked sub-channels during degradation. The upper limit of the locking ratio maintains a reasonable balance between degradation protection and overall channel availability. When the number of sub-channels in the candidate pool is insufficient to cover all message types, the high-stability path is marked as partially covered, and the list of uncovered message types is appended to the high-stability path for separate processing during the policy adaptation phase.

[0052] Policy priority sequences are generated based on idempotent scoring combined with high-stability paths. Policy adaptation matches the carrying capacity of each sub-channel in the high-stability path with the message transmission requirements of the idempotent scoring distribution. Each matching scheme constitutes a candidate policy, and the adaptation quality of the candidate policy is jointly measured by the matching coverage rate R and channel margin. Messages with high E_i are preferentially assigned to the most stable sub-channel in the high-stability path during policy adaptation. Messages with lower E_i can be matched to sub-channels with relatively relaxed stability thresholds. When alarm messages and statistical reporting messages coexist, the two types of messages naturally fall into sub-channels with different stability thresholds due to the difference in E_i. The allocation gradient of degraded resources is consistent with the business priority gradient, ensuring that high-value services always obtain better quality transmission paths when channel resources are tight. When the high-stability path has partial coverage, uncovered message types are matched to available sub-channels outside the candidate stable channel pool during policy adaptation. The matching rule is relaxed to D_mod_avg < 2.0. If no suitable sub-channel is found after relaxation, the candidate policy corresponding to this message type is marked as having no path coverage. The priority of each candidate strategy is P = R × S_max, where S_max is the stability score of the optimal sub-channel in the high-stability path. The stability score is calculated as S_max = 1 / (1 + D_mod_avg). The lower D_mod_avg is, the higher S_max is, making P positively correlated with the health of the sub-channel. The strategy priority sequence is arranged in descending order of P. When P is the same, strategies that cover a wider range of message types are ranked higher. The matching quality coefficient of candidate strategies corresponding to messages with low idempotency scores is reduced by 15%. Each candidate strategy in the strategy priority sequence is accompanied by a list of covered message types and the corresponding sub-channel identifier.

[0053] The candidate degradation strategy set is determined based on the strategy priority sequence. The strategy with the highest priority (P) in the sequence is directly included in the candidate degradation strategy set as the preferred solution, and the strategy with the second highest priority (P) is also included as an alternative solution. The candidate degradation strategy set must contain at least two strategies, primary and backup. The primary and backup strategies complement each other in terms of sub-channel selection and message type coverage. If one strategy fails, the backup strategy can immediately take over without interrupting services. When there is a strategy without a path coverage marker in the strategy priority sequence, this strategy is only included in the candidate degradation strategy set when all other strategies are unavailable, and a coverage gap marker is added to indicate the range of message types involved. The union of the message type coverage sets of each strategy in the candidate degradation strategy set is taken. If the union covers all message types in the high-priority range, the candidate degradation strategy set is marked as fully covered; if there is a gap in the union, it is marked as partially covered. The list of partially covered message types is appended to the candidate degradation strategy set. When the score difference between adjacent strategies P in the strategy priority sequence exceeds 0.3, a cutoff marker is set. Strategies above the cutoff constitute the high-quality strategy pool, and those below the cutoff constitute the fallback strategy pool. Candidate degradation strategies are preferentially selected from the high-quality strategy pool. Strategies in the high-quality strategy pool are significantly superior to those in the fallback strategy pool in both coverage and channel health. Strategies in the fallback strategy pool are only activated when all high-quality strategies fail. This two-tiered strategy pool design ensures optimal quality during degradation decisions when resources are abundant and retains fallback transmission capabilities even in extremely degraded scenarios. After the strategy priority sequence is updated, the candidate degradation strategy set is re-evaluated synchronously. Replacement is triggered when the original primary / backup strategy P is no longer in the top two positions.

[0054] A degradation execution strategy is constructed based on the candidate degradation strategy set and the characteristics of delayable messages in the low-priority range. The strategy with the highest comprehensive score in the candidate degradation strategy set is determined as the primary degradation scheme. The score calculation formula is Score=R / (1+D_mod_now), where R is the coverage rate of messages applicable to the strategy, and D_mod_now is the rolling average of the latest health deviation of the corresponding sub-channel at the time of degradation execution, which differs from the historical value when the strategy priority sequence was constructed. The higher R and the lower D_mod_now, the higher the Score. The strategy with the highest score performs optimally in both coverage and real-time channel health dimensions, and can carry the widest range of high-priority message types with the most stable sub-channel during degradation. Delayable messages in the low-priority range are divided into two categories based on their delay duration: short delay (not exceeding 30 seconds) and long delay (exceeding 30 seconds). Short delay messages are included in the protection scope when the primary degradation scheme's resources allow, while all long delay messages are pushed into the standby queue to be processed after the channel is restored. During degradation, channel resources are concentrated on messages with higher timeliness, and the temporary storage of long delay messages does not affect the normal transmission rhythm of high-priority services. The degradation execution strategy consists of two parts: a primary degradation plan and deferred message handling rules. The primary degradation plan specifies that messages in the high-priority range are allocated to sub-channels and retry parameters in descending order of E_i. The deferred message handling rules specify the temporary storage time limit and recovery delivery trigger conditions for messages in each delay range in the low-priority range. Together, these two parts cover the handling paths for all message types during degradation, ensuring the orderly transmission of high-priority messages while preventing the infinite backlog of low-priority messages. When no strategy in the candidate degradation strategy set covers messages in the non-idempotent high-priority range, the degradation execution strategy triggers a manual intervention flag for such messages. Messages marked with manual intervention are not automatically retried during degradation. The validity period of the degradation execution strategy is synchronized with the validity period of the pre-degradation trigger conditions; when the conditions expire, the degradation execution strategy is simultaneously revoked.

[0055] The degradation communication sequence is generated based on the degradation execution strategy. The sub-channel allocation rules specified in the primary degradation scheme of the degradation execution strategy directly drive the generation of the degradation communication sequence. Each message in the sequence is grouped and arranged according to the channel priority and idempotency type in the primary degradation scheme. Message groups with higher E_i are placed first, and strongly idempotent messages are placed first to maintain a high transmission success rate in the early stage of degradation, creating a stable channel environment for the gradual delivery of subsequent messages. Each message in the degradation communication sequence records the target sub-channel identifier, the allowed number of retries, and the transmission timeout tolerance value. The allowed number of retries comes from the retry limit field of the primary degradation scheme of the degradation execution strategy. The transmission timeout tolerance value is linked to the expected remaining available window corresponding to the link health level at the time of the pre-degradation trigger condition. Both parameters are directly read from the primary degradation scheme and are not recalculated during the sequence generation stage. The degraded execution strategy's delayed message handling rules append short-delay messages to the end of the degraded communication sequence, while long-delay messages are not included in the degraded communication sequence but are directly pushed into the standby queue. The message delivery volume per unit time in the degraded communication sequence satisfies Q_rate ≤ 0.85 × C_total, where Q_rate is the message delivery volume per unit time in the degraded communication sequence (in messages per second), and C_total is the comprehensive throughput capacity of each sub-channel (in messages per second). If this limit is exceeded, the tail messages are truncated according to the priority order of message types covered by the primary degraded scheme, retaining a 15% capacity margin to ensure the channel still has buffering capacity to handle sudden traffic surges under degraded load. Manually marked messages in the degraded communication sequence are listed separately and appended to the end of the sequence, not participating in automatic transmission scheduling. After the degraded communication sequence is generated, it is immediately distributed to the corresponding sub-channel. During the distribution process, if the target sub-channel's status deteriorates to unavailability, the corresponding message for that sub-channel is rerouted to the alternative sub-channel specified in the degraded execution strategy's alternative scheme.

[0056] Step S150: Based on the degraded communication sequence, reverse verification of the degraded message quality is performed to generate a link recovery configuration. Based on the link recovery configuration, elastic routing scheduling is executed to construct a recovery communication channel. Based on the recovery communication channel, cross-cloud secure communication results are output.

[0057] In some embodiments, the step of generating a link recovery configuration by performing reverse verification of degraded message quality based on the degraded communication sequence includes: performing message quality segmentation analysis on the degraded communication sequence to determine a critical recovery interval; detecting a decreasing trend in the message idempotency retry rate within the critical recovery interval to identify recovery-sensitive features; extracting key features for link recovery stability based on the recovery-sensitive features to construct recovery quality features; and quantifying recovery confidence based on the recovery quality features to classify recovery levels and generate a link recovery configuration.

[0058] Degraded communication sequences are segmented for message quality analysis to determine critical recovery intervals. Segmentation boundaries are based on quality jump points in the transmission results of adjacent messages within the degraded communication sequence. A quality jump point is defined as the moment when the average transmission success rate of five consecutive messages changes by more than 15%. A larger jump indicates a more significant difference in channel quality before and after that point. The degraded communication sequence is divided into several quality segments based on these quality jump points. Within each quality segment, two segment-level indicators are extracted: the average transmission success rate and the average number of retries. These two indicators jointly characterize the overall channel performance within that quality segment. The average transmission success rate reflects the overall effectiveness of message arrival, while the average number of retries reflects the additional transmission cost incurred by the channel during that stage. When the average transmission success rate of adjacent quality segments shows a continuous upward trend and collectively covers more than three messages, this group of quality segments is marked as a candidate recovery segment. After congestion eases, the transmission success rate of cross-cloud links often increases in a step-like manner; identifying candidate recovery segments can accurately capture the starting position of this step. The critical recovery interval is further filtered from the candidate recovery segments. The filtering criteria are an average transmission success rate exceeding 75% and an average number of retries less than 1.5. Only candidate recovery segments that meet both conditions are ultimately confirmed as critical recovery intervals. If only one condition is met, the quality segment is only marked as a quasi-critical segment and does not participate in the subsequent idempotent retry rate detection. If there are no quality segments that meet both conditions in the degraded communication sequence, the segment with the highest transmission success rate among the quasi-critical segments is downgraded and included in the critical recovery interval with a low-confidence label. In the low-confidence critical recovery interval, the confidence level of each segment-level indicator is reduced synchronously, and the judgment threshold for it is appropriately relaxed in the idempotent retry rate detection stage.

[0059] The idempotent retry rate decline trend within the recovery critical interval is used to identify recovery-sensitive features. The idempotent retry rate is calculated by dividing the actual number of retries for each message within the recovery critical interval by the maximum allowed number of retries, ranging from 0 to 1. A lower value indicates that the message can be successfully transmitted without frequent retries under the current channel quality. The idempotent retry rate of strongly idempotent messages often declines first in the early stages of channel quality improvement, and its decline pace precedes that of weakly idempotent messages, making it one of the earliest observable signals in the channel recovery process. The decline trend of the idempotent retry rate sequence within the recovery critical interval is measured by the slope of a linear fit. A negative slope with an absolute value exceeding 0.05 per message is considered a significant decline trend; a larger absolute slope indicates a faster recovery speed. Recovery-sensitive features are composed of three values: the idempotent retry rate decline slope, the number of messages covered by the decline trend, and the proportion of strongly idempotent messages. These three values ​​together describe the strength and reliability of the channel recovery signal within the recovery critical interval. When the proportion of weak idempotent messages is too high, the confidence of the descent slope in the recovery sensitive feature decreases accordingly. The degree of decrease is positively correlated with the proportion of weak idempotent messages. This is because the retry behavior of weak idempotent messages is affected by business logic, and changes in the idempotency retry rate cannot simply reflect channel quality. When the recovery critical interval is marked with low confidence, the descent slope value in the recovery sensitive feature participates in the judgment, but the confidence weight drops to 0.6. When the number of messages covered by the descent trend in the recovery sensitive feature is less than 3, it is marked as insufficient trend samples. Under the condition of insufficient samples, the recovery critical interval needs to be expanded and the probe needs to be retried.

[0060] Based on the recovery-sensitive features, key features for link recovery stability are extracted to construct recovery quality features. The identification of key features for link recovery stability is based on whether the values ​​of each recovery-sensitive feature exceed the stable recovery threshold. A feature is considered a stable key feature if the absolute value of the descent slope exceeds 0.08, the number of covered messages exceeds 5, and the proportion of strongly idempotent messages exceeds 0.6. If only one of these two conditions is met, the corresponding feature is considered an auxiliary feature. Feature items with insufficient trend samples in the recovery-sensitive features are downweighted during the identification of stable key features. After downweighting, this feature is only upgraded to a key feature if all other features are auxiliary features. The set of stable key features and the set of auxiliary features are mapped to the stable and auxiliary components of the recovery quality features, respectively. The weight of each stable key feature item is linearly assigned based on its value exceeding the stable recovery threshold and truncated to 1. The weight of auxiliary feature items is uniformly assigned a value of 0.5. The stable component is determined by the average weight of the stable key feature, and the auxiliary component is determined by the average weight of the auxiliary feature. When all three values ​​of the recovery sensitive features do not exceed the stable threshold, the stable component is assigned a value of 0.1, and the auxiliary component is assigned the mean value of the corresponding auxiliary feature. The whole is marked as a weak recovery quality feature. When the difference between the stable component and the auxiliary component exceeds 0.4, it is marked as a component imbalance. Such deviations are common in multi-cloud domain concurrent recovery scenarios when the improvement pace of link quality in each domain is inconsistent. When classifying recovery levels, recovery quality features with component imbalance are treated conservatively, and the level is not increased by more than one level.

[0061] Generate link recovery configurations by quantifying recovery confidence based on recovery quality characteristics and dividing recovery levels. The formula for calculating recovery confidence is C_conf = D_stable × 0.7 + D_aux × 0.3, where C_conf is the recovery confidence, D_stable is the stable component of the recovery quality characteristics, D_aux is the auxiliary component, and the value range of C_conf is from 0 to 1. When the recovery quality characteristic is a weak recovery quality characteristic, C_conf is additionally reduced by 0.1 on the basis of the weighted sum, and is truncated to 0 when it is lower than 0 after the reduction. The additional suppression of weak signals avoids premature triggering of the main path switch when the channel quality is still unstable. When C_conf exceeds 0.75, it is divided into a high recovery level; between 0.5 and 0.75, it is divided into a medium recovery level; when it is lower than 0.5, it is divided into a low recovery level. The recovery level corresponding to the recovery quality characteristic marked by component imbalance is downgraded by one level based on the C_conf result. In the multi-cloud domain concurrent recovery scenario, the component imbalance appears more frequently, and the downgrading mechanism prevents misjudgment of the switching timing due to the virtual high of signals in some dimensions. The link recovery configuration is jointly determined by the recovery level and D_stable. The link recovery configuration corresponding to the high recovery level allows the immediate initiation of the main path switch and the release of the channel binding of the degraded execution policy. After the switching instruction is issued with the link recovery configuration, the sub-channel resources occupied during the degradation period synchronously enter the release process. The link recovery configuration corresponding to the medium recovery level requires that the detection verification be performed first and then the switch be initiated. The original degraded sub-channel maintains operation before the detection passes, ensuring that the service transmission within the switching window is not interrupted. The link recovery configuration corresponding to the low recovery level only allows conservative expansion without triggering the main path switch. The expansion parameters are linearly mapped from the actual value of D_stable. The higher D_stable is, the greater the expansion ratio, making the expansion intensity maintain a proportional relationship with the currently observable recovery strength.

[0062] Elastic routing scheduling is used to construct a restored communication channel based on link recovery configuration. The execution mode of elastic routing scheduling is determined by the recovery level in the link recovery configuration. High recovery level triggers immediate switching mode, medium recovery level triggers switching mode after probe verification, and low recovery level triggers conservative expansion mode. In cross-cloud scenarios, the link recovery rate varies across different cloud domains. The hierarchical design of the three modes allows routing scheduling to match the corresponding strength of switching action according to the measured recovery level, avoiding secondary jitter caused by overly aggressive switching. Under high recovery level, the link recovery configuration allows the immediate release of sub-channels bound to the degradation execution strategy. The routing scheduling module selects the optimal node path from the current snapshot of the cloud node routing table by sorting by round-trip latency and packet loss rate. The selected path serves as the physical basis for the restored communication channel. Under medium recovery level, the routing scheduling module first sends three rounds of probe messages to the candidate path. Switching is triggered when the average success rate of the three rounds of probes exceeds 90% and the round-trip latency is less than 1.2 times the average link quality baseline. The candidate path must meet both conditions in three consecutive rounds of probes to be confirmed. Paths that fall back after meeting the criteria in a single round do not trigger switching. The restored communication channel is established based on the verified path. At low recovery levels, routing scheduling does not initiate path switching. Instead, it adds parallel transmission threads to the existing degraded sub-channels. The expansion ratio is specified by the conservative expansion parameters in the link recovery configuration. The resulting multi-threaded channel group serves as the recovery communication channel for the current stage. After the recovery communication channel is established, connectivity verification messages are sent to all sub-channels. If the verification message response rate is below 80%, the recovery communication channel is marked as unstable. An unstable recovery communication channel triggers a reassessment of the link recovery configuration. After the recovery level is downgraded, the corresponding mode of scheduling actions is re-executed. Once the recovery communication channel stabilizes, the backup queue for long-delay messages in the downgrade execution strategy is transferred to the recovery communication channel in priority order. The transfer rate does not exceed 60% of the current throughput capacity of the recovery communication channel. During peak business recovery scenarios, the backup queue often accumulates a large number of long-delay messages. The controlled transfer rate allows the recovery communication channel to handle the backlog of messages while maintaining normal response capabilities to new business traffic.

[0063] The cross-cloud secure communication results are output based on the restored communication channel. After the restored communication channel is running stably, the queue partitions bound to the degraded sub-channel in the service access mapping are switched to the corresponding sub-channel of the restored communication channel. The switch is completed by the transparent proxy layer. During the switch, messages in transit are not lost. Messages already assigned to the target sub-channel continue to be transmitted along the original path before new messages are delivered through the restored communication channel. The cross-cloud secure communication results reflect the transmission status under normal channel quality after the switch is completed. The transmission success rate, round-trip latency, and packet loss rate of each sub-channel in the restored communication channel are compared with the link quality baseline in the first detection period after recovery. When all three indicators return to within 1.5 times the standard deviation of the baseline mean, the cross-cloud secure communication results are marked as fully restored. When some indicators still exceed the range, they are marked as partially restored. Indicators exceeding the range are marked with deviation and continuously monitored until they return to the baseline range. The full restoration of the cross-cloud secure communication results triggers a reassessment of the link health level. When the assessment result is normal, the corresponding entry of the pre-degradation trigger condition becomes invalid, the spare queue resources occupied during the degradation period are released synchronously, and the restored communication channel takes over all service traffic. After the communication channel is fully restored, double-frequency encrypted connectivity detection will be maintained for the first 24 hours. If the channel quality index is within 1.5 times the standard deviation of the baseline for three consecutive detection cycles, the double-frequency detection will automatically fall back to the normal interval. The cross-cloud secure communication result will be marked as continuously valid after full restoration, and the link health level assessment will be based on this to maintain the normal level.

[0064] To implement the cross-cloud secure communication method with message degradation capability corresponding to the above method embodiments, and to achieve the corresponding functions and technical effects. See also Figure 2 , Figure 2 This diagram illustrates a structural block diagram of a cross-cloud secure communication system 200 with message degradation capability according to an embodiment of this application. For ease of explanation, only the parts relevant to this embodiment are shown. The cross-cloud secure communication system 200 with message degradation capability provided in this embodiment includes: Endpoint resolution module 201 is used to collect node registration information and link status data in cross-cloud deployment scenarios, and to perform dynamic endpoint resolution and link quality benchmark assessment on the node registration information and the link status data to generate cloud node routing table and link quality baseline; The channel establishment module 202 is used to establish a cross-cloud encrypted communication channel using the cloud node routing table through a two-way encrypted communication protocol, perform downgrade preparation two-way certificate authentication on the cross-cloud encrypted communication channel to generate authentication channel credentials, and use the authentication channel credentials to perform multi-channel multiplexing configuration on the cross-cloud encrypted communication channel to determine the multiplexing channel group. The health inference module 203 is used to perform message queue transparent proxy binding to the multiplexed channel group to generate a service access mapping, and to perform implicit health inference of service packets by combining the service access mapping with the link quality baseline to generate a health index sequence. Based on the health index sequence, link quality degradation analysis is performed to determine the link health level. The degradation decision module 204 is used to predict link degradation based on the link health level, generate pre-degradation trigger conditions, construct a degradation execution strategy based on the pre-degradation trigger conditions, and generate a degradation communication sequence based on the degradation execution strategy. The recovery scheduling module 205 is used to perform reverse verification of the quality of the degraded message based on the degraded communication sequence to generate a link recovery configuration, perform elastic routing scheduling to build a recovery communication channel based on the link recovery configuration, and output cross-cloud secure communication results based on the recovery communication channel.

[0065] The aforementioned cross-cloud secure communication system 200 with message degradation capability can implement one of the cross-cloud secure communication methods with message degradation capability described in the above method embodiments. The options in the above method embodiments are also applicable to this embodiment and will not be detailed here. The remaining content of this application embodiment can be referred to the content of the above method embodiments, and will not be repeated in this embodiment.

[0066] The purpose of the above embodiments is to reproduce and derive the technical solution of the present invention by way of example, and to fully describe the technical solution, purpose and effect of the present invention. The purpose is to enable the public to have a more thorough and comprehensive understanding of the disclosure of the present invention, and not to limit the scope of protection of the present invention.

[0067] The above embodiments are not an exhaustive list based on the present invention, and there may be many other embodiments not listed. Any substitutions and improvements made without departing from the concept of the present invention are within the protection scope of the present invention.

Claims

1. A cross-cloud secure communication method with message degradation capability, characterized in that, include: Collect node registration information and link status data in cross-cloud deployment scenarios, and perform dynamic endpoint parsing and link quality benchmark assessment on the node registration information and link status data to generate cloud node routing tables and link quality baselines; A cross-cloud encrypted communication channel is established using the cloud node routing table via a two-way encrypted communication protocol. A downgrade preparation two-way certificate authentication is performed on the cross-cloud encrypted communication channel to generate an authentication channel credential. The authentication channel credential is then used to perform multi-channel multiplexing configuration on the cross-cloud encrypted communication channel to determine the multiplexing channel group. The multiplexed channel group is subjected to message queue transparent proxy binding to generate a service access mapping. The service access mapping is combined with the link quality baseline to infer the implicit health of service packets and generate a health index sequence. The link quality degradation analysis is performed based on the health index sequence to determine the link health level. The link health level is used to predict link degradation and generate pre-degradation trigger conditions. A degradation execution strategy is constructed based on the pre-degradation trigger conditions, and a degradation communication sequence is generated based on the degradation execution strategy. Based on the degraded communication sequence, reverse verification of the degraded message quality is performed to generate a link recovery configuration. Based on the link recovery configuration, elastic routing scheduling is executed to construct a recovery communication channel. Based on the recovery communication channel, cross-cloud secure communication results are output.

2. The method according to claim 1, characterized in that, The process of generating a cloud node routing table and link quality baseline by dynamically resolving endpoints and evaluating link quality benchmarks based on the node registration information and link status data includes: The node registration information is split into a sequence of nodes in each cloud domain; For each cloud domain node sequence, cross-domain reachability detection is performed node by node in combination with the link status data to extract node connectivity features; The cold standby activation delay compensation analysis is performed on the node connectivity characteristics to identify key monitoring nodes; The node connectivity characteristics are integrated with the key monitored nodes to generate a cloud node routing table and link quality baseline.

3. The method according to claim 1, characterized in that, The step of performing downgrade preparation two-way certificate authentication and generating authentication channel credentials for the cross-cloud encrypted communication channel includes: The certificate handshake latency of each node is measured for the cross-cloud encrypted communication channel. High-latency nodes and low-latency nodes are identified by sorting according to the certificate handshake latency values; A credential priority mapping is constructed based on the latency difference between the high-latency node and the low-latency node; The authentication channel credentials are generated by combining the credential priority mapping with the high-latency node.

4. The method according to claim 1, characterized in that, The step of generating a health indicator sequence by implicitly inferring the health of service packets through the service access mapping and the link quality baseline includes: The service access mapping separates the primary path message characteristics and the backup path message characteristics; The difference in message out-of-order rate between the primary path message characteristics and the backup path message characteristics is used to generate a path quality difference index. Based on the path quality difference index, deviation analysis is performed to determine the health correction type; The health correction type is combined with the link quality baseline to quantify the health deviation and then mapped to generate a health index sequence.

5. The method according to claim 1, characterized in that, The step of determining the link health level by performing link quality degradation analysis based on the health index sequence includes: The health index sequence is subjected to noise filtering to generate a deterioration feature set; A recovery trend backtracking analysis is performed on the health index sequence to generate a recovery feature set; By comparing the degradation feature set with the recovery feature set, the dominant degradation interval is identified, and the dominant degradation feature is generated. The link health level is determined by a level mapping based on the dominant degradation characteristics.

6. The method according to claim 1, characterized in that, The construction of the degradation execution strategy based on the pre-degradation triggering conditions includes: Extract the priority values ​​of all messages in the pre-degradation trigger condition; Based on the priority values, a tiered threshold is set to define the high-priority interval and the low-priority interval; Perform message idempotency verification tests in the high-priority interval to generate a set of candidate degradation strategies; A degradation execution strategy is constructed based on the candidate degradation strategy set and the characteristics of delayable messages in the low priority interval.

7. The method according to claim 1, characterized in that, The step of generating link recovery configuration by performing reverse verification of degraded message quality based on the degraded communication sequence includes: Perform message quality segmentation analysis on the degraded communication sequence to determine the critical recovery interval; In the critical recovery interval, a decreasing trend in the message idempotent retry rate is detected to identify recovery-sensitive features; Based on the aforementioned recovery-sensitive features, key features for link recovery stability are extracted to construct recovery quality features; Based on the aforementioned recovery quality characteristics, the recovery confidence level is quantified, recovery levels are classified, and link recovery configurations are generated.

8. The method according to claim 3, characterized in that, The step of constructing a credential priority mapping based on the latency difference between the high-latency node and the low-latency node includes: Calculate the latency difference between the low-latency node and the high-latency node to generate an asymmetric overhead distribution; Identify the dominant low-overhead node region based on the aforementioned asymmetric overhead distribution; For the dominant low-overhead node region, perform cold backup node pre-activation credential distribution path analysis to construct credential coverage topology; Based on the credential coverage topology, the cross-domain credential distribution path is extracted to generate a credential priority mapping.

9. The method according to claim 6, characterized in that, The step of performing message idempotency verification tests in the high-priority interval to generate a set of candidate degradation strategies includes: Idempotent retry feature extraction is performed in the high-priority interval to generate an idempotent score; Based on the idempotency score, a high-stability path is generated by filtering the channel stability. Based on the idempotent score and the high-stability path, a strategy priority sequence is generated through strategy adaptation. The candidate degradation strategy set is determined based on the strategy priority sequence.

10. A cross-cloud secure communication system with message degradation capability, characterized in that, include: The endpoint resolution module is used to collect node registration information and link status data in cross-cloud deployment scenarios, and to perform dynamic endpoint resolution and link quality benchmark assessment on the node registration information and link status data to generate cloud node routing tables and link quality baselines. The channel establishment module is used to establish a cross-cloud encrypted communication channel using the cloud node routing table through a two-way encrypted communication protocol, perform downgrade preparation two-way certificate authentication on the cross-cloud encrypted communication channel to generate authentication channel credentials, and use the authentication channel credentials to perform multi-channel multiplexing configuration on the cross-cloud encrypted communication channel to determine the multiplexing channel group. The health inference module is used to perform message queue transparent proxy binding to the multiplexed channel group to generate a service access mapping, and to perform implicit health inference of service packets by combining the service access mapping with the link quality baseline to generate a health index sequence. Based on the health index sequence, link quality degradation analysis is performed to determine the link health level. The degradation decision module is used to predict link degradation based on the link health level, generate pre-degradation trigger conditions, construct a degradation execution strategy based on the pre-degradation trigger conditions, and generate a degradation communication sequence based on the degradation execution strategy. The recovery scheduling module is used to perform reverse verification of the quality of degraded messages based on the degraded communication sequence to generate a link recovery configuration, perform elastic routing scheduling to build a recovery communication channel based on the link recovery configuration, and output cross-cloud secure communication results based on the recovery communication channel.

Images