Standardized api based cross-domain data service trusted sharing method and system

Abstract

The application belongs to the field of communication and provides a cross-domain data service trusted sharing method and system based on standardized API, relates to the technical field of data communication, and solves the technical problem that the transmission channel reliability, performance and security performance are difficult to be considered in the prior art. The method comprises the following steps: establishing a control channel and at least two data channels between a client and a server; the client determines a target data channel for transmitting a business request according to the semantic type of the business request and the state of the data channel, combines the collaborative routing suggestion of the server side, and obtains and binds cross-channel verification information through the control channel; the client sends a security envelope encapsulating the business request and the cross-channel verification information through the target data channel; the server side processes the business request by verifying the binding relationship between the cross-channel verification information and the target data channel and the current session; and the server side returns a response through the control channel and / or the target data channel after processing the business request.

Description

Technical Field

[0001] This invention belongs to the field of data communication technology, specifically relating to a trusted sharing method and system for cross-domain data services based on standardized APIs. Background Technology

[0002] This section provides only background information relevant to this disclosure and is not necessarily prior art.

[0003] With the increasing complexity of internet application architectures and the widespread adoption of distributed systems, cross-domain data exchange based on standardized APIs has become commonplace. However, ensuring the security, efficiency, and reliability of data sharing in complex network environments, especially in cross-domain scenarios, still faces a series of severe technical challenges.

[0004] Existing technologies typically rely on a single HTTPS connection as the transmission channel. While this approach achieves basic encrypted transmission, it has significant limitations. First, a single channel is prone to performance bottlenecks or single points of failure due to network fluctuations or server-side issues, making it difficult to achieve a balanced optimization across different dimensions such as throughput, latency, and reliability. Second, the path selection from the client to the server is often static or based on simple rules, lacking the ability to dynamically and intelligently adapt to real-time network conditions, the specific semantics of business requests, and the overall server load, resulting in low transmission efficiency.

[0005] In terms of security, existing solutions generally employ mechanisms such as TLS encryption, API key or token authentication, but these security measures typically operate in isolation on a single communication link. Once an attacker breaches the security protection of a link through man-in-the-middle attacks, session hijacking, or other means, they can steal or tamper with data, making the security defense relatively weak and limited. More importantly, when applications attempt to introduce multiple parallel channels to improve performance or reliability, existing architectures lack effective mechanisms to ensure real-time, consistent synchronization of security states between different channels, easily leading to vulnerabilities in inconsistent security policy execution and ultimately increasing the attack surface. Summary of the Invention

[0006] This application provides a trusted sharing method and system for cross-domain data services based on standardized APIs, which solves the technical problems in the prior art that make it difficult to balance the reliability, performance and security of the transmission channel, as well as the vulnerability of the security mechanism to breaches.

[0007] To achieve the above objectives, this application adopts the following technical solution:

[0008] Firstly, it provides a trusted method for cross-domain data service sharing based on standardized APIs, including:

[0009] Step 1: Establish and maintain a control channel for transmitting control signaling and at least two data channels with different transmission characteristics for transmitting business data between the client and the server.

[0010] Step 2: The client determines the target data channel for transmitting the business request based on the semantic type of the business request and the status of the data channel, and in conjunction with the server's collaborative routing suggestions, and obtains and binds cross-channel verification information through the control channel;

[0011] Step 3: The client sends a secure envelope containing the business request and the cross-channel verification information through the target data channel; the server processes the business request by verifying the binding relationship between the cross-channel verification information and the target data channel and the current session.

[0012] Step 4: After processing the business request, the server returns a response through the control channel and / or the target data channel; wherein, a change in the security status of any channel triggers cross-channel security status synchronization through the control channel.

[0013] Based on the above technical solutions, the trusted sharing method for cross-domain data services based on standardized APIs provided in this application achieves systemic innovation by constructing a collaborative architecture of control channels and multiple data channels, and introducing semantic-based intelligent routing and cross-channel security verification mechanisms. First, by establishing an independent dedicated control channel that works collaboratively with multiple data channels of varying characteristics, the separation of control signaling and business data transmission is achieved. This not only improves the system's organizational clarity and manageability but also lays the foundation for network fault tolerance and load optimization. Second, the client determines the target channel by combining request semantics, channel status, and server collaborative suggestions. This is a dynamic and intelligent routing strategy that can select the optimal transmission path based on actual business needs and network conditions, thereby significantly improving data transmission efficiency and user experience. Furthermore, a creative "cross-channel verification information" binding and verification process is proposed and implemented, strongly associating the security of business requests with the specific data channel and session that initiated them. This extends the security defense from a single channel to collaborative verification across multiple channels, greatly enhancing the defense capabilities against threats such as man-in-the-middle attacks and channel hijacking, and improving the overall trust level. Finally, by controlling the channel to achieve cross-channel synchronization of security status and flexible selection of response paths, the system has the ability to perceive and respond globally. Any local change in security status can trigger a global and consistent policy adjustment, thereby ensuring the high reliability and resilience of the system in complex cross-domain environments.

[0014] The standardized API refers to an interface design that follows unified specifications and standards, ensuring efficient and reliable data exchange and function calls between different systems, services, or components. The standardized API, or Standardized Application Programming Interface API, conforms to pre-defined public specifications or industry standards and includes at least one set of clearly defined functions, procedures, protocols, data formats, and communication endpoints. The interface is configured to enable unambiguous interaction and data exchange between a first software component and at least one second software component based on the specified specifications, without exposing underlying implementation details. The specifications include constraints on calling methods, parameter structures, return value types, error handling mechanisms, and transmission protocols. The standardized API aims to achieve cross-platform, cross-language, or cross-system interoperability, portability, and consistency, and supports independent implementation and extension by third-party developers based on the same standard.

[0015] In some embodiments, step 1 includes the following steps:

[0016] Step 1-1: Establish a control channel and at least two data channels between the client and the server. The control channel and data channels use different communication protocols. Each data channel is configured with a capability tag that characterizes its transmission characteristics, and the channels are bound to the same session ID.

[0017] Steps 1-2: Monitor the transmission status of each channel, generate quality assessment information for the data channel, and synchronize the quality assessment information between the client and the server through the control channel;

[0018] Steps 1-3: Maintain connection keep-alive through the control channel. When a channel interruption or data channel transmission performance degradation is detected, perform channel reconstruction or performance optimization under the session identifier association.

[0019] In some embodiments, the control channel is established based on the WebSocket protocol, and the data transmitted by the control channel is limited to security signaling, routing instructions, and session state synchronization information;

[0020] The data channels are established based on at least two of the HTTP / 2, HTTP / 3, or QUIC protocols, and each data channel registers a transmission capability tag with the server when it is established; wherein, the transmission capability tag is used to characterize the characteristics of the data channel in terms of transmission delay, bandwidth, or reliability.

[0021] In some embodiments, the status of the data channel is obtained by performing a quality assessment on the channel, and the formula for calculating the quality assessment value is: Where Q represents the quality assessment value, S represents the average effective payload of data transmission within a preset time period, RTT represents the real-time round-trip time, T represents the measured throughput, B represents the theoretical bandwidth of the channel, and L represents the packet loss rate. The variance representing network latency jitter. , , , The weight coefficients for each item, determined based on the semantic type of the business request, are summed to 1.

[0022] In some embodiments, steps 1-3 involve using a heartbeat keep-alive mechanism established on the control channel to detect and determine if the channel is interrupted; for channels in a connection interruption state, the processing flow is as follows:

[0023] If the control channel is interrupted, the client agent immediately initiates a control channel reconnection request. After the server-side gateway verifies the validity of the session ID, it reallocates control channel resources and binds them to the original session ID. After the reconnection is completed, the latest status of all channels is synchronized.

[0024] If the data channel is interrupted, the client agent sends a data channel reconnection request to the server through the control channel. The server reallocates channel resources with the same protocol and characteristics according to the original channel's transmission capacity label. After the reconnection is completed, the "session-channel" mapping relationship is updated.

[0025] By using the quality assessment values ​​of each data channel The quality assessment value of a data channel is compared with a preset quality threshold in real time. If the quality assessment value of a data channel is lower than the threshold for a certain number of consecutive collection cycles, the channel is determined to be in a state of performance degradation.

[0026] For data channels experiencing performance degradation, the client agent triggers a dynamic channel parameter tuning process: based on the protocol type of the data channel, the core transmission parameters are adjusted accordingly; after parameter tuning, the channel quality assessment value is recalculated; if the assessment value recovers to above the threshold, the tuning is completed; if it does not recover, a channel switching request is initiated to the server through the control channel, and the server allocates a new data channel with the same characteristics.

[0027] In some embodiments, step 2 includes the following steps:

[0028] Step 2-1: The client determines a pre-selected channel from the data channels based on the semantic type of the service request, the transmission capacity labels of each data channel, and the real-time quality assessment information. If the semantic type and transmission capacity labels match, the client prioritizes the channel with better real-time quality assessment and sends a routing consultation request carrying the identifier of the pre-selected channel to the server-side gateway through the control channel. The semantic type is determined based on at least one of the following characteristics: the request type of the service request, the data transmission volume, the real-time requirements, and the security level, through preset classification rules or a trained neural network model.

[0029] Step 2-2: The server-side gateway generates a cooperative routing suggestion based on the current status, historical performance, and server-side global policy of the pre-selected channel and returns it to the client proxy through the control channel;

[0030] Steps 2-3: The client agent determines the final target data channel based on the cooperative routing suggestion, and when the preset security conditions are met, obtains cross-channel verification information that is uniquely bound to the current session and the final target data channel through the control channel. The cross-channel verification information is a one-time verification token generated by the server and uniquely bound to the current session and the target data channel, which expires immediately after use.

[0031] In some embodiments, step 2-2 includes the following steps:

[0032] Step 2-2-1: Verify the legitimacy and timeliness of the routing consultation request; wherein, the legitimacy is based on the digital signature or identity token verification of the request, and the timeliness is based on the timestamp or one-time random number verification contained in the request;

[0033] Step 2-2-2: After successful verification, calculate the comprehensive suitability score of the pre-selected channel based on its connection status (load status), transmission performance indicators, and server-side global policy. The real-time load status represents the server's utilization of various network and service processing resources at the current time point, including the current number of connections for the protocol type of the pre-selected data channel, the server's CPU utilization, memory utilization, data transmission bandwidth utilization, and the length of the service request processing queue. The global security policy represents the server's globally unified security control rules and access authorization criteria for ensuring trusted sharing of cross-domain data services, including a list of allowed protocol types, binding authorization rules between client identity and data channels, security access thresholds for different types of data channels, and encryption verification specifications for cross-domain transmission.

[0034] Step 2-2-3 compares the comprehensive suitability score with a preset threshold to generate a collaborative routing suggestion, which includes using the pre-selected channel, switching to other data channels, or adding enhanced security checks.

[0035] In some embodiments, the server performs a channel suitability assessment on the pre-selected target data channel based on real-time load status, global security policies, and semantic type tags. This channel suitability assessment includes:

[0036] The server obtains the current status attributes and historical performance data of the pre-selected target data channel; the status attributes include the connection status, protocol type, and registered transmission capability tags of the target data channel, and the historical performance data includes the average latency, throughput, and error rate within a preset time period;

[0037] Based on the connection status and the error rate, a health sub-score is calculated; specifically, if the connection status is active, a base score is assigned, and the base score is reduced based on whether the error rate is lower than a first error rate threshold.

[0038] Based on the semantic type label of the service request, the transmission capability label, and the average latency and throughput, a performance matching degree sub-score is calculated; specifically, the matching degree of the semantic type label and the transmission capability label is evaluated, and the calculation is performed by combining the degree of closeness between the corresponding historical performance indicators and the optimal performance benchmark value of the semantic type.

[0039] Based on the global security policy, the protocol type, and the actual load status of the server for the protocol type, a policy compliance sub-score is calculated. Specifically, it checks whether the protocol type is in the allowed list, whether the client identity is authorized to use the pre-selected target data channel, and whether the current number of connections for the protocol type channel is lower than the second load threshold. If so, a full score is assigned; otherwise, the score is deducted accordingly based on the specific policy item that does not comply.

[0040] The weighted sum of each sub-score is used to calculate the overall suitability score F of the pre-selected target data channel.

[0041] Specifically, the comprehensive suitability score F mentioned in step 2-2 is obtained by weighted summation of at least one of the following sub-scores, with the weights added together to a value of 1:

[0042] The health sub-score H reflects the health status of the channel connection; the performance matching sub-score P reflects the degree to which the channel transmission performance matches the service requirements; and the policy compliance sub-score C reflects the degree to which the channel conforms to the server's global policy. Specifically:

[0043]

[0044] In the formula, E represents the baseline score for connection status, set to 1.0 when the connection status is "active" and 0.0 otherwise; E is the error rate of the pre-selected channel. The first error rate threshold preset for the server;

[0045]

[0046] In the formula, The tag matching score is assigned based on the cosine similarity between the semantic type tag and the transmission capability tag, with a value range of [0,1]. The higher the similarity, the larger the value. The performance quantization function is dynamically determined based on semantic type labels: low-latency type is... D is the average delay time. The low-latency reference latency value is used; the high-throughput type is... T represents throughput. This is a high-throughput reference throughput baseline; the balance type is...

[0047]

[0048] In the formula, This is a Boolean value, indicating whether the protocol type of the pre-selected channel is in the server's allowed list; Current number of connections, where U is the current number of channel connections. Set a second load threshold for the channel on the server side;

[0049] In some embodiments, generating cooperative routing suggestions for a preset target data channel based on a preset suitability score threshold includes:

[0050] If the suitability score is higher than the first error rate threshold, a recommendation to "approve the use of the pre-selected channel" is generated.

[0051] If the suitability score is lower than the first error rate threshold but higher than the second load threshold, and there are other available channels with suitability scores higher than the current channel, then a suggestion to "switch to another specified data channel" is generated, and the identifier of the other data channel is specified in the suggestion.

[0052] If the suitability score is lower than the second load threshold, or the policy compliance sub-score indicates a policy compliance risk, a recommendation to "require additional enhanced security checks on the pre-selected channel" is generated.

[0053] In some embodiments, determining the target data channel for transmitting the service request in steps 2-3 includes:

[0054] The client filters candidate data channels based on semantic type, sorts them according to the quality assessment value of each candidate channel, selects the highest-ranked channel as the pre-selected channel, and sends a routing consultation request to the server; the client determines the final target data channel based on the cooperative routing suggestions returned by the server.

[0055] Obtaining and binding cross-channel verification information through the control channel includes: when a business request is identified as having a high security level or the collaborative routing suggestion is "attach enhanced security verification on the target data channel", the client initiates a cross-channel verification code request to the server through the control channel; the server generates a one-time verification code that is uniquely bound to the current client session and the target data channel, and sends it to the client through the control channel;

[0056] In some embodiments, step 3 includes the following steps:

[0057] Step 3-1: The client agent constructs a secure envelope, which includes an envelope header and an envelope body. The envelope header contains at least the cross-channel verification information and the final target data channel identifier. The envelope body contains business request data that has been signed by a key bound to the final target data channel. The key is generated through a key negotiation algorithm or a key derivation algorithm. The envelope header also contains a request identifier and a timestamp.

[0058] Step 3-2: The client proxy transmits the secure envelope containing the signed business request and cross-channel verification information to the server-side gateway through the final target data channel;

[0059] Step 3-3: The server-side gateway decapsulates the security envelope and verifies the binding relationship between the cross-channel verification information and the final target data channel. If the verification is successful, the business request is processed. Specifically, the gateway verifies whether the association between the cross-channel verification information, the channel identifier of the final target data channel, and the current client session identifier is consistent with the binding mapping stored on the server. If they are consistent, the verification is successful and the business request is processed; otherwise, the business request is rejected.

[0060] In some embodiments, step 4 includes the following steps:

[0061] Step 4-1: The server-side gateway determines the response transmission strategy based on the type of the service request processing result. Specifically, for service response data, it determines to return the response through the target data channel; for real-time notification or signaling data, it determines to return the response through the control channel; for service processing results, it determines to push a processing status notification through the control channel while returning the response data through the target data channel.

[0062] Step 4-2: The server-side gateway returns response data to the client agent through the control channel and / or the final target data channel according to the response transmission strategy; wherein, the business response data includes, but is not limited to, database query results, file content, and processed structured data; the business processing results include, but are not limited to, payment transaction results, configuration update confirmation, and batch task execution progress reports;

[0063] Step 4-3: When the control channel, the target data channel, or any other data channel detects a security anomaly in any of the data channels, a security state update event is triggered via the server-side gateway. The server-side gateway sends a security policy change instruction to the client agent through the control channel, causing the security policy adjustment to apply to all channels associated with the session identifier. This allows the client agent to update the security context according to the instruction, and the updated security context applies to all channels associated with the session identifier. The client agent adjusts its subsequent communication behavior based on the updated security context. This communication behavior includes, but is not limited to: invalidating the existing session token and triggering re-authentication, increasing the encryption strength of communication, and suspending the sending of specified requests. The security context represents the set of security attributes and policy states of the current session, obtained by parsing the token, certificate, and security policy instructions from the server.

[0064] In some embodiments, the system includes a client proxy module, a server-side gateway module, and multiple heterogeneous data transmission channels connecting the two; wherein...

[0065] The client proxy module is used to initiate routing consultation based on the semantic type and channel status of the business request, and determine the target data channel based on the collaborative routing suggestions from the server-side gateway module; it is also used to obtain cross-channel verification information through the control channel, construct a security envelope, and send the business request through the target data channel.

[0066] The server-side gateway module is used to receive and verify the routing consultation, generate the collaborative routing suggestion based on real-time load, security policy and channel suitability assessment; it is also used to process the application, binding and verification of the cross-channel verification information, and process the business requests sent through the target data channel.

[0067] The plurality of heterogeneous data transmission channels include a control channel based on the WebSocket protocol, dedicated to transmitting control signaling, and at least two data channels based on different standardized application layer protocols, used for transmitting business data and having different characteristics.

[0068] Compared with the prior art, the beneficial effects of this application are:

[0069] First, this application clearly defines the roles of the control channel and various characteristic data channels, and uses transmission capability tags to characterize the channels, thus constructing a clear, efficient, and scalable communication infrastructure for the system. The control channel is dedicated to signaling transmission, ensuring the real-time performance and reliability of control commands; while the multiple data channels based on different standardized protocols, combined with their registered transmission capability tags, provide precise hardware and protocol-level basis for subsequent semantic-based intelligent routing, realizing optimized matching and utilization of resources.

[0070] Secondly, this application enhances the intelligence and reliability of data transmission through a sophisticated evaluation and decision-making mechanism. The client performs initial channel screening based on a multi-dimensional quality assessment model, and then the server makes the final decision by combining collaborative routing suggestions that integrate real-time load, global security policies, and performance matching. This transforms channel selection from a simple polling or static configuration into an intelligent process that dynamically adapts to network conditions, business needs, and security policies. In particular, by introducing cross-channel verification information and uniquely binding this information to specific data channels and sessions, an additional, collaborative verification defense is built on top of the business data transmission layer. This approach embeds security into the routing decision-making and transmission process, rather than simply adding it on, effectively defending against attacks targeting a single channel and significantly enhancing the overall trustworthiness of the sharing process.

[0071] Finally, this application designs a complete closed-loop security and response mechanism to ensure the robustness and consistency of the system. The structured design of the security envelope, combined with the signature bound to the channel, ensures the integrity and trustworthiness of the request source. The response path is optimized based on the data type, or a combination of control and data channels is used, balancing efficiency and timeliness. In addition, by centrally synchronizing security status changes detected by any channel through the control channel, global real-time updates and coordinated responses to security contexts are achieved, enabling the system to respond to security threats quickly and consistently, and comprehensively improving the resilience and adaptability of cross-domain data services in the face of complex network environments and potential attacks. Attached Figure Description

[0072] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments, and the advantages of the present invention in the above and / or other aspects will become clearer.

[0073] Figure 1 System architecture diagram of a trusted cross-domain data service sharing system based on standardized APIs provided in this application embodiment;

[0074] Figure 2 A flowchart illustrating the trusted sharing method for cross-domain data services based on standardized APIs provided in this application embodiment;

[0075] Figure 3 A flowchart illustrating another trusted sharing method for cross-domain data services based on a standardized API, provided as an embodiment of this application;

[0076] Figure 4 This is a flowchart illustrating another trusted sharing method for cross-domain data services based on a standardized API, provided as an embodiment of this application. Detailed Implementation

[0077] It should be noted that, in this application, the terms "exemplary" or "for example" are used to indicate that something is being described as an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0078] The trusted sharing method for cross-domain data services based on standardized APIs provided in this application can be applied to, for example... Figure 1 In the cross-domain data service trusted sharing system shown, based on standardized APIs, such as Figure 1 As shown, the communication system includes: a client proxy module, a server gateway module, and multiple heterogeneous data transmission channels connecting the two; wherein,

[0079] The client proxy module is used to initiate routing inquiries based on the semantic type and channel status of the business request, and to determine the target data channel based on the collaborative routing suggestions from the server-side gateway module; it is also used to obtain cross-channel verification information through the control channel, construct a security envelope, and send the business request through the target data channel.

[0080] The server-side gateway module is used to receive and verify routing inquiries, generate collaborative routing suggestions based on real-time load, security policies, and channel suitability assessments; it is also used to process the application, binding, and verification of cross-channel verification information, and to process business requests delivered through the target data channel.

[0081] Multiple heterogeneous data transmission channels, including a control channel based on the WebSocket protocol dedicated to transmitting control signaling, and at least two data channels based on different standardized application layer protocols, used to transmit business data and with different characteristics.

[0082] To address the technical problems in existing technologies where cross-domain data sharing suffers from single points of failure in the transmission channel, low transmission efficiency, and isolated and vulnerable security mechanisms, making it impossible to simultaneously ensure transmission reliability, performance, and security, this application provides a trusted sharing method for cross-domain data services based on a standardized API. This method includes:

[0083] Between the client and the server, establish and maintain a persistent control channel and at least two data channels with different transmission characteristics;

[0084] Perform real-time quality assessment on each data channel and generate quality assessment values ​​for each data channel;

[0085] When a client proxy initiates a business request, it selects the target data channel from the data channels based on the semantic type and quality assessment value of the business request, and sends a routing consultation request to the server-side gateway.

[0086] The server-side gateway adjudicates routing consultation requests based on global policies, and generates and returns collaborative routing suggestions.

[0087] Based on the cooperative routing recommendations, the client agent determines the final data channel used to transmit business requests and generates a unified security envelope containing cross-channel security identifiers for the business requests.

[0088] The security context information of business requests is synchronized between the client and the server through the control channel.

[0089] The unified security envelope containing the business request is sent to the server-side gateway through the final data channel.

[0090] The server-side gateway verifies the validity of the cross-channel security identifier in the unified security envelope and processes the business request based on the verification result.

[0091] The server-side gateway returns the processing results of business requests to the client proxy through the control channel and / or the final data channel.

[0092] Based on this, this method achieves trusted sharing of cross-domain data by separating control and business data transmission, intelligent routing, and cross-channel security verification.

[0093] like Figure 2 As shown in the embodiments of this application, the trusted sharing method for cross-domain data services based on standardized APIs includes:

[0094] Step 1: Establish and maintain a control channel for transmitting control signaling and at least two data channels with different transmission characteristics for transmitting business data between the client and the server.

[0095] Among them, the control channel is responsible for the dedicated transmission of control signaling. It is the link between the client and the server for command interaction, status synchronization, and security signaling transmission, ensuring efficient and real-time interaction of various control commands. The data channel is dedicated to carrying out business data transmission tasks. Different data channels have different transmission characteristics and can be adapted to different business data transmission needs such as low latency, high throughput, and high reliability, so as to realize targeted transmission of business data.

[0096] First, the client initiates a channel establishment request to the server. The server verifies the client's identity and legitimacy. If the verification is successful, the server allocates independent control channel resources and multiple data channel resources to the client, completing the construction of the basic channel. Subsequently, the client and server monitor the connection status and transmission status of each channel in real time. For interrupted channels, a reconnection mechanism is initiated, and for channels with performance degradation, parameters are tuned. The availability status of all channels is continuously maintained to ensure that the control channel always maintains stable signaling transmission capabilities, and that the data channels can carry corresponding business data according to their own characteristics.

[0097] It should be noted that the control channel and the data channel are logically isolated transmission links. They each perform their own functions and do not interfere with each other. At the same time, the configuration of multiple data channels avoids the single point of failure problem caused by a single channel from the architectural level.

[0098] Step 2: The client determines the target data channel for transmitting the business request based on the semantic type of the business request and the status of the data channel, and in conjunction with the server-side collaborative routing suggestions, and obtains and binds cross-channel verification information through the control channel.

[0099] Among them, collaborative routing suggestions are routing decision suggestions given by the server to the data channels pre-selected by the client, based on its own global load status, overall security policy and the adaptation requirements of business requests. Its role is to make up for the limitations of the client selecting routes based solely on local information, so that the channel selection is more in line with the overall system operation status, and to achieve global resource optimization and security management.

[0100] It should be noted that different business requests have different semantic types and corresponding transmission requirements. For example, real-time query requests require low-latency channels, while batch data upload requests require high-throughput channels. If the channel does not match the business requirements, the transmission efficiency will be greatly reduced. At the same time, the real-time status of different data channels is different. Some channels may be overloaded or have unstable connections. Therefore, arbitrarily selecting a channel will increase the probability of transmission failure and cause unreasonable allocation of system resources.

[0101] The client first performs semantic parsing on the business request to classify the corresponding semantic type. Then, it collects real-time status information of all data channels and filters out candidate data channels that meet the basic conditions based on the transmission requirements of the semantic type. The candidate channels are then used as pre-selected channels and a routing consultation request is sent to the server. After receiving the request, the server generates a collaborative routing suggestion and returns it to the client. The client determines the final target data channel based on the suggestion. Subsequently, the client initiates a cross-channel verification information retrieval request to the server through the control channel. The server generates corresponding verification information based on the client's session information and the target data channel information, and sends it to the client through the control channel. The client associates and binds the verification information with the current business request and the target data channel, completing the verification information binding process.

[0102] It should be noted that the acquisition and binding of cross-channel verification information are both completed through the control channel to avoid this process occupying the transmission resources of the data channel. At the same time, the binding of verification information with business requests and target data channels is a one-to-one relationship to ensure the uniqueness and relevance of the verification information.

[0103] For example, a client initiates a real-time e-commerce payment query request, which is semantically parsed as low-latency. After collecting the data channel status, it filters out a pre-selected channel with low latency characteristics and stable connection, and sends a routing consultation request to the server. The server, based on its own load, finds that the current number of connections for the pre-selected channel is low, and returns a collaborative routing suggestion to use the pre-selected channel. The client then determines this channel as the target data channel. Subsequently, the client requests verification information from the server through the control channel. The server generates a unique verification code and sends it out. The client binds the verification code to the payment query request and the target data channel.

[0104] Step 3: The client sends a secure envelope containing the business request and cross-channel verification information through the target data channel; the server processes the business request by verifying the binding relationship between the cross-channel verification information and the target data channel and the current session.

[0105] The security envelope is a transmission carrier that uniformly encapsulates the business request and cross-channel verification information. It ensures the integrity and confidentiality of the business request during transmission, preventing data theft and tampering during cross-domain transmission. Encapsulating the verification information and business request together ensures they remain connected during transmission, providing a complete basis for server-side verification. The server processes business requests by verifying the binding relationship between the cross-channel verification information, the target data channel, and the current session. This is because cross-domain scenarios present security risks such as man-in-the-middle attacks and channel hijacking. Verifying only the business request itself cannot confirm whether the request originates from a legitimate client or is transmitted through a designated legitimate channel. By verifying the binding relationship of these three elements, the server can confirm the legitimacy of the request, the validity of the channel, and the consistency of the session. This fundamentally prevents unauthorized requests from accessing data through forged channels and impersonated sessions. Only after successful verification can the current business request be considered trustworthy, allowing subsequent processing to proceed.

[0106] Upon receiving the security envelope, the server first decapsulates it, extracting the business request, cross-channel verification information, target data channel identifier, and current session identifier. Then, it retrieves the locally stored verification information and bound channel information corresponding to the session, comparing the extracted cross-channel verification information with the local verification information. Simultaneously, it verifies whether the extracted target data channel identifier matches the locally bound channel information. If both match, the verification passes, and the server performs the corresponding business processing based on the content of the business request, such as database queries, data calculations, and resource calls. If any step fails, the verification fails, the server directly rejects the business request, sends a verification failure notification to the client through the control channel, and records the abnormal request information.

[0107] It should be noted that the server-side verification process is a pre-processing step, completed before any actual business logic processing, to prevent illegal requests from occupying the server's business processing resources. At the same time, the verification results will be fed back to the client in real time to ensure that the client is aware of the transmission status of the request in a timely manner.

[0108] Step 4: After processing the business request, the server returns a response through the control channel and / or the target data channel.

[0109] Changes in the security status of any channel trigger cross-channel security status synchronization through the control channel. The reason for returning responses through different channels is that the response data generated after the server processes the business request has different data types and corresponding transmission requirements. Some response data requires real-time, low-overhead transmission, while some response data requires high-bandwidth, high-stability transmission. Selecting the corresponding channel or a combination of channels to return responses based on the data type of the response can balance the efficiency and rationality of response transmission, while avoiding the bandwidth pressure and transmission risks caused by returning responses through a single channel.

[0110] In some implementations, after the server completes the processing of a business request, it first categorizes the response data, distinguishing between business response data and control response information. For purely data-based business response data, it is directly returned to the client through the target data channel, leveraging the transmission characteristics of the data channel to ensure efficient data transmission. For control response information such as status notifications, processing result confirmations, and progress reminders, it is returned to the client through the control channel, ensuring real-time delivery of this type of information. For highly important business processing results, business response data is returned through the target data channel simultaneously, and processing status notifications are pushed through the control channel, allowing the client to obtain complete business data and confirm the processing status in real time. During the entire response return process, if any channel detects a security anomaly, it immediately sends the security status change information to the server. The server then synchronizes this security status to all channels through the control channel. Upon receiving the synchronization information, the client promptly adjusts its communication behavior to ensure the security of subsequent data transmission.

[0111] It should be noted that the response return logic of the control channel and the data channel can be flexibly adjusted according to the priority of the business. For high-priority business requests, their response data can enjoy the priority allocation of channel transmission resources. At the same time, the cross-channel security status synchronization is a real-time triggering mechanism to ensure that security anomalies can be quickly detected and handled.

[0112] For example, after the server processes a large transfer request, it returns the transfer amount, account, transaction details, and other business response data to the client through the target data channel. At the same time, it pushes a "transfer transaction successful" status notification to the client through the control channel. If the target data channel detects abnormal data packet theft at this time, it immediately sends the security status change information to the server. The server then synchronizes the security anomaly to all channels of the client through the control channel. Upon receiving the notification, the client immediately invalidates the token of the current session and triggers a re-authentication process.

[0113] Based on the above technical solutions, the cross-domain data service trusted sharing method based on standardized APIs provided in this application achieves isolated transmission of control signaling and business data by constructing a collaborative transmission architecture of control channels and multiple data channels. This avoids the single point of failure problem of a single channel and improves the overall transmission organization and manageability of the system. By combining the target channel determination method of business request semantic type, data channel status and server-side collaborative routing suggestions, dynamic and intelligent routing is realized, allowing channel selection to accurately match business needs and the global system status, significantly improving the transmission efficiency of cross-domain data. Through the binding and verification of cross-channel verification information and the encapsulation and transmission of secure envelopes, the security defense is extended from a single channel to the collaborative verification level of channels and sessions, effectively resisting cross-domain security threats such as man-in-the-middle attacks and channel hijacking, and improving the trust level of data sharing. At the same time, based on the differentiated response return method of data types and the global security status synchronization mechanism of the control channel, the system has flexible response capabilities and unified security defense capabilities, ensuring that the system can balance the reliability, performance and security of data transmission in complex cross-domain network environments, and realize trusted sharing of cross-domain data services.

[0114] In one possible implementation of this application embodiment, step 1 can be specifically implemented through the following steps 1-1, 1-2, and 1-3, which are described in detail below:

[0115] Step 1-1: Complete the initialization and resource binding of the control channel and data channel.

[0116] Step 1-1 is the initialization step for channel establishment, which is used to realize mutual recognition of legitimate identities between the client and the server, and to complete the resource allocation, protocol binding and session association of the control channel and multiple data channels, thus building a basic link for data transmission.

[0117] The core prerequisite for channel initialization is identity verification. Only after the client passes the server's authentication can it obtain channel resources. Resource binding associates the allocated channel with the client's unique session, achieving session-level channel isolation and ensuring that the transmission links of different clients do not interfere with each other.

[0118] In some implementations, step 1-1 specifically includes the following operational steps:

[0119] The client proxy first constructs a channel establishment request message containing the client's unique identifier, digital signature, access authorization token, and business transmission requirements, and then sends the request to the unified security access node of the server-side gateway through a standardized API.

[0120] Upon receiving a request, the server-side gateway first verifies the legitimacy of the digital signature and access authorization token. If the verification is successful, it allocates one control channel based on the client's business transmission requirements and the server's current network resource status to the client, along with at least two data channels based on different protocols such as HTTP / 2, HTTP / 3, or QUIC. Simultaneously, it configures and registers a transmission capability label for each data channel. This label explicitly characterizes the core characteristics of the corresponding data channel in terms of transmission latency, bandwidth, and reliability. For example, an HTTP / 2-based channel might be labeled "low latency - medium bandwidth - high reliability," an HTTP / 3-based channel "medium latency - high bandwidth - high reliability," and a QUIC-based channel "low latency - low bandwidth - ultra-high reliability." The labels, presented as a combination of "transmission latency level - bandwidth level - reliability level," intuitively reflect the core transmission characteristics of the data channel. They can also be expanded to formats such as "low latency - high throughput - jitter resistance" or "balanced - general bandwidth - high stability" to precisely match the transmission requirements of different business requests.

[0121] Subsequently, the server-side gateway generates a globally unique session ID for the client, and binds the channel identifier, protocol type, and transmission capability label of the control channel and each data channel to this session ID, forming a session-channel association mapping relationship and storing it in the server-side session management module;

[0122] Finally, the server-side gateway encapsulates the channel allocation results, session ID, and basic configuration parameters of each channel into a response message, and returns it to the client agent through a temporary link. The client agent completes the protocol initialization and connection configuration of the local channel based on the response message, thus completing the initial establishment of the control channel and data channel.

[0123] It should be noted that the control channel is limited to a dedicated signaling transmission link during initialization, allowing only the transmission of security signaling, routing instructions, and session state synchronization information, while prohibiting the transmission of any business data, thus ensuring the real-time performance and low interference of control signaling transmission; at the same time, the transmission capability label of the data channel can be dynamically updated according to the actual transmission performance of the channel after registration, providing accurate characteristic basis for subsequent intelligent routing.

[0124] For example, in a cross-domain data sharing scenario for government affairs, the client agent (government A end) initiates a channel establishment request to the server gateway, carrying its own organization identifier, a valid digital signature, and the business requirement of "low-latency transmission of real-time verification data and high-throughput transmission of batch archive data". After verifying the identity, the server gateway allocates one WebSocket control channel, one low-latency data channel based on the HTTP / 2 protocol, and one high-throughput data channel based on the HTTP / 3 protocol. It also registers the transmission capability tags of "low latency-high reliability" and "high throughput-large bandwidth" for the two data channels respectively, and generates a session ID: GZL-WF33016-2025001, completing the binding of all channels with this session ID. After receiving the configuration, the client agent completes the local channel initialization, thus obtaining the basic transmission link.

[0125] Steps 1-2: Perform real-time quality monitoring and status assessment of the control channel and each data channel.

[0126] Steps 1-2 are the real-time monitoring and evaluation steps of the channel. Through the collection and quantitative calculation of multi-dimensional indicators, the quality evaluation value of each data channel is generated, so as to realize the collaborative perception of the channel status between the client and the server.

[0127] Among them, channel quality assessment is a quantitative analysis process based on multi-dimensional transmission indicators, which is used to transform the real-time transmission status of the channel into comparable and screenable values; while the status monitoring of the control channel focuses on connection stability, ensuring that it always has signaling transmission capabilities, and providing a guarantee for the coordinated operation of the entire system.

[0128] In some implementations, steps 1-2 include the following operational steps:

[0129] Both the client-side proxy and the server-side gateway deploy distributed channel monitoring modules, which collect data in real time at a fixed 100ms interval. This data includes the connection liveness status and heartbeat response latency of the control channel, as well as the average payload size, real-time round-trip time, measured throughput, theoretical bandwidth, packet loss rate, and variance of network latency jitter for each data channel. After collection, the client-side proxy's channel quality assessment model preprocesses the data channel metrics, filtering outliers and normalizing the data. Then, it calculates the quality assessment value Q for each data channel using the following formula: The definitions and meanings of the parameters in the formula are as follows:

[0130] Q is the data channel quality assessment value. The larger the value of Q, the better the real-time transmission quality of the data channel.

[0131] S is the average effective payload size of the data channel within a preset time period (consistent with the indicator collection cycle, which is 100ms), in bytes, reflecting the actual data carrying capacity of the channel.

[0132] RTT stands for Real-time Round Trip Delay of a data channel, measured in milliseconds (ms), and reflects the transmission delay characteristics of the channel.

[0133] T represents the measured throughput of the data channel, measured in Mbps, reflecting the actual data transmission rate of the channel.

[0134] B represents the theoretical bandwidth of the data channel, measured in Mbps, and is an inherent attribute of the channel's hardware and protocol.

[0135] L is the packet loss rate of the data channel, a dimensionless ratio that reflects the transmission reliability of the channel.

[0136] Var(J) is the variance of the data channel network delay jitter, which is a dimensionless value and reflects the stability of the channel transmission delay.

[0137] w1, w2, w3, and w4 are the weight coefficients for each item. The weights are added together to get 1. The value of each coefficient is dynamically determined according to the semantic type of the business request. The core principle is to match the core transmission characteristics corresponding to the business requirements with higher weights. For example, low-latency services are assigned a higher weight to w1, and high-throughput services are assigned a higher weight to w2.

[0138] After the client agent completes the calculation of the quality assessment value of each data channel, it synchronizes the channel identifier, real-time acquisition indicators, and quality assessment value to the session and security context manager of the server gateway through the control channel. After receiving the data, the server gateway updates its local channel status database, thereby achieving global synchronization and consistent understanding of the channel status between the client and the server.

[0139] It should be noted that this formula is a unitless and dimensionless comprehensive calculation method. Only the actual values ​​of each parameter need to be substituted into the calculation. No unit conversion is required. Through mathematical transformations such as logarithms and exponents, transmission indicators of different dimensions and dimensions are transformed into dimensionless values ​​that can be fused and calculated. Finally, a unified quality assessment value Q is output, realizing a quantitative comprehensive evaluation of the multi-dimensional transmission performance of the data channel. This allows data channels with different characteristics to have a unified evaluation standard that can be compared and ranked.

[0140] For example, in the HTTP / 2 low-latency data channel of the above-mentioned cross-domain government affairs scenario, the metrics collected by the client proxy within 100ms are: S=1024Byte, RTT=20ms, T=100Mbps, B=200Mbps, L=0.001, Var(J)=0.5. If the current business is "real-time government affairs data verification" (low-latency semantic type), and the configured weight coefficients w1=0.4, w2=0.2, w3=0.2, w4=0.2, the result is calculated by substituting into the formula:

[0141] The client agent synchronizes the channel's quality assessment value of 1.5587 and various indicators to the server through the control channel, and the server updates its local channel status database.

[0142] Steps 1-3: Implement persistent maintenance and anomaly recovery for control and data channels.

[0143] Steps 1-3 ensure the persistent availability of the control and data channels throughout the entire session lifecycle through mechanisms such as heartbeat keep-alive, anomaly detection, reconnection, and parameter tuning. At the same time, they enable rapid detection and recovery of channel anomalies, thereby improving the system's fault tolerance and reliability.

[0144] In some implementations, the client proxy and the server gateway establish a heartbeat keep-alive mechanism based on the control channel. With a fixed heartbeat period of 1 second, the two parties send heartbeat messages to each other. If no heartbeat response is received from the other party for 3 consecutive times, it is determined that the corresponding channel is in a connection interruption state. At the same time, the client proxy compares the quality assessment value of each data channel with the preset quality threshold in real time. If the quality assessment value of a certain data channel is lower than the threshold for 10 consecutive collection cycles (1 second), it is determined that the channel is in a performance degradation state.

[0145] For channels in a connection interruption state, the processing procedure is as follows:

[0146] 1) If the control channel is interrupted, the client agent immediately initiates a control channel reconnection request. After the server gateway verifies the validity of the session ID, it reallocates the control channel resources of the WebSocket protocol and binds them to the original session ID. After the reconnection is completed, the latest status of all channels is synchronized.

[0147] 2) If the data channel is interrupted, the client agent sends a data channel reconnection request to the server through the control channel. The server reallocates channel resources with the same protocol and characteristics according to the original channel's transmission capacity label. After the reconnection is completed, the "session-channel" mapping relationship is updated.

[0148] For data channels experiencing performance degradation, the client agent triggers a dynamic channel parameter tuning process: based on the data channel's protocol type, core transmission parameters are adjusted accordingly. For example, for HTTP / 2 channels, the concurrent stream count and initial window size are adjusted; for HTTP / 3 or QUIC channels, the congestion control algorithm and packet fragmentation size are adjusted. After parameter tuning, the channel quality assessment value is recalculated. If the assessment value recovers to above the threshold, the tuning is complete. If it does not recover, a channel switching request is initiated to the server through the control channel, and the server allocates a new data channel with the same characteristics.

[0149] Meanwhile, after any channel completes reconnection or parameter tuning, the client agent will synchronize the latest channel status and configuration parameters to the server-side gateway through the control channel to ensure that the server-side channel status database is up-to-date and valid, providing an accurate basis for subsequent collaborative routing.

[0150] It should be noted that channel reconnection and parameter tuning are completed within the original session lifecycle. All newly allocated channels are bound to the original session ID to ensure the continuity of service transmission without requiring the client to re-initiate a channel establishment request. At the same time, the abnormal recovery priority of the control channel is higher than that of all data channels to ensure the priority recovery of the signaling transmission link and provide protection for the abnormal handling of the data channel.

[0151] Based on the above technical solution, this application embodiment, through steps 1-1, 1-2, and 1-3, realizes full lifecycle management of the control channel and multiple data channels, from initialization and establishment to real-time monitoring and evaluation and persistent maintenance, constructing a heterogeneous collaborative transmission architecture with separate control and data channels. Specifically, a dedicated control channel using the WebSocket protocol achieves low-interference, real-time signaling transmission; multiple data channels using HTTP / 2, HTTP / 3, or QUIC protocols and transmission capability tags enable personalized transmission of business data; a quantitative evaluation model using multi-dimensional indicators generates quality assessment values ​​for the data channels, providing accurate data support for subsequent intelligent routing; and a heartbeat keep-alive mechanism and anomaly recovery mechanism ensure the persistent availability of the channels. This architecturally solves the single-point-of-failure problem of a single channel in existing technologies, laying a stable, efficient, and secure transmission foundation for the trusted sharing of subsequent cross-domain data services.

[0152] In one possible implementation of the embodiments of this application, combined with Figure 2 ,like Figure 3 As shown, step 2 above can be implemented through steps 2-1, 2-2, and 2-3, which are explained in detail below:

[0153] Step 2-1: The client performs semantic parsing of the business request and determines the pre-selected channel based on the channel status.

[0154] Step 2-1 is the initial screening step for the target channel. By determining the semantic type of the business request and combining it with the real-time quality status of the data channel, the pre-selected channel is determined. This can provide basic screening results for subsequent server-side collaborative routing and achieve initial channel matching based on business needs.

[0155] Among them, business request semantic parsing is the process of converting unstructured business requests into standardized semantic type tags, which is used to clarify the transmission characteristic requirements of business requests and establish a matching basis for channel selection.

[0156] In some implementations, step 2-1 includes the following steps:

[0157] The client proxy first deploys a semantic parsing module to extract features from received business requests. The extracted features include core features such as request type, data transmission volume, real-time requirements, and security level. Based on preset semantic type classification rules, the business requests are divided into three semantic types: low latency, high throughput, and balanced, and a unique semantic type label is generated for each type of business request.

[0158] Subsequently, the client agent retrieves the real-time calculated quality assessment values ​​of each data channel and the registered transmission capability tags from steps 1-2. Based on the cosine similarity between the semantic type tag and the transmission capability tag, channels with a cosine similarity exceeding a preset threshold are selected as candidate data channels. Alternatively, channels with the same semantic type tag and transmission capability tag are matched using character matching as candidate data channels. The candidate data channels are then sorted from high to low according to their quality assessment values, and the channel ranked first is determined as the pre-selected channel. The channel identifier of the pre-selected channel is then extracted.

[0159] Finally, the client proxy constructs a routing query request, which encapsulates at least the semantic type label of the business request, the pre-selected channel identifier, the client session ID, the timestamp, and the client digital signature, and sends it to the server-side gateway through the control channel.

[0160] It should be noted that the semantic classification rules can be extended according to the actual business scenario, and the semantic parsing process must be completed locally on the client to avoid the leakage of core features of business requests during transmission; at the same time, the selection of pre-selected channels is only based on the channel status data on the client's local side, which is a preliminary decision on the client side, and the final determination needs to be completed in combination with the collaborative routing suggestions from the server's global perspective.

[0161] In some implementations, the semantic parsing module can be based on machine learning algorithms. For example, a neural network model can be built and trained using a dataset of business request samples with semantic type labels. The sample data undergoes request feature extraction, feature vectorization, and label mapping. Through multiple rounds of iterative training, the model's feature recognition and semantic classification capabilities are optimized, resulting in a semantic parsing model capable of automatically determining the semantic type of business requests. This model can automatically extract features and perform semantic matching on input business requests, accurately outputting corresponding semantic type labels such as low latency, high throughput, and balance. It also supports continuous learning and iterative classification of new business request types, improving the adaptability and accuracy of semantic parsing.

[0162] For example, when a client receives a "real-time financial transaction query" service request, the semantic parsing module extracts its core features of "high real-time requirements and small data transmission volume" and generates a "low latency" semantic type label. The client retrieves the data channel status and filters out two data channels with the transmission capability label "low latency-high reliability". Their quality assessment values ​​are 1.5587 and 1.2103, respectively. The channel ranked first is selected as the pre-selected channel, and its channel identifier is extracted as D-HTTP2-001. Then, a routing query request containing the "low latency" label, the D-HTTP2-001 identifier, the session ID GZL-WF33016-2025001, the timestamp, and the digital signature is constructed and sent to the server gateway through the WebSocket control channel.

[0163] Step 2-2: The server-side gateway processes the routing consultation request and generates collaborative routing suggestions.

[0164] Step 2-2 is the server-side global decision-making step. By verifying the legitimacy of the routing consultation request, and combining the server-side global load, security policy, and channel suitability assessment, collaborative routing suggestions are generated to achieve global-level channel resource optimization.

[0165] Among them, the collaborative routing suggestion is a channel selection decision basis provided by the server to the client from a global perspective. It is used to combine the local channel status of the client with the global status of the server to ensure that the channel selection not only matches the business needs, but also meets the overall load balancing and security policy requirements of the system.

[0166] In some implementations, step 2-2 includes the following steps:

[0167] After receiving a routing query request, the server-side gateway first verifies the validity and timeliness of the request:

[0168] The legitimacy is verified based on the client's digital signature or identity token in the request. If the verification is successful, it is confirmed that the request comes from a legitimate client. Then, the timeliness is verified based on the timestamp or one-time random number in the request. If the verification is successful, it is confirmed that the request has not been tampered with or replayed.

[0169] After successful verification, the server-side gateway retrieves the current status attributes and historical performance data of the pre-selected channel. The status attributes include connection status, protocol type, and transmission capacity label. The historical performance data includes the average latency, throughput, and error rate within a preset time period. Subsequently, the health sub-score H, performance matching sub-score P, and policy compliance sub-score C are calculated sequentially, and the comprehensive suitability score F of the pre-selected channel is obtained by weighted summation. The specific calculation process and formula are as follows:

[0170] 1. Health score H: Reflects the basic connectivity and operational health status of the pre-selected channel. The calculation formula is as follows: In the formula, E represents the baseline score for connection status, set to 1.0 when the connection status is "active" and 0.0 otherwise; E is the error rate of the pre-selected channel. The first error rate threshold preset for the server;

[0171] 2. Performance Matching Sub-Score P: Reflects the degree of matching between the transmission capacity of the pre-selected channel and the semantic requirements of the service request. The calculation formula is as follows: In the formula, The tag matching score is assigned based on the cosine similarity between the semantic type tag and the transmission capability tag, with a value range of [0,1]. The higher the similarity, the larger the value. The performance quantization function is dynamically determined based on the semantic type label:

[0172] Low latency type D is the average delay time. The low-latency reference latency value is used; the high-throughput type is... T represents throughput. This is a high-throughput reference throughput baseline; the balance type is... ;

[0173] 3. Policy Compliance Sub-Score C: Reflects the degree to which the use of the pre-selected channel complies with the server's global security and load balancing policies. The calculation formula is as follows: In the formula, This is a Boolean value, indicating whether the protocol type of the pre-selected channel is in the server's allowed list; Current number of connections, The second load threshold preset for the server;

[0174] 4. Overall suitability score F: Reflects the overall suitability of the pre-selected channel. The calculation formula is: F=α×H+β×P+γ×C; where α, β, and γ are weighting coefficients, which are preset by the server according to the business scenario, and satisfy α+β+γ=1. In core business scenarios, the weight of performance matching degree or strategy compliance degree can be appropriately increased.

[0175] The server-side gateway compares the overall suitability score F with the preset suitability score threshold, and generates a collaborative routing suggestion based on the comparison result. The suggestion includes at least one of the following: using a pre-selected channel, switching to another specified data channel, or adding enhanced security checks to the pre-selected channel. Finally, the collaborative routing suggestion is returned to the client agent through the control channel.

[0176] It should be noted that all data for the channel suitability assessment comes from the server's global database, ensuring the objectivity and comprehensiveness of the assessment results; the weighting coefficients α, β, and γ allow the server to dynamically adjust them according to business priorities and system load, enabling flexible adaptation of the assessment strategy.

[0177] For example, after the server gateway verifies that the routing query request for real-time financial transaction inquiry is legitimate and valid, it retrieves the status of the pre-selected channel D-HTTP2-001: the connection status is active, the error rate E=0.0005, and the first error rate threshold. =0.001, average latency D=20ms, low latency reference value =50ms, tag matching degree =0.95, the protocol type is in the allowed list, the client has been authorized to use it, the current number of connections for this protocol type channel is U=80, the second load threshold is T_{load}=100; the preset weighting coefficients are α=0.2, β=0.5, and γ=0.3, which are calculated sequentially as follows:

[0178] H=1.0*(1-min(1,0.0005 / 0.001))=0.5;

[0179] P=0.95*exp(-20 / 50)≈0.95*0.6703≈0.6368;

[0180] C = 1.0 * 1.0 * 1.0 = 1.0;

[0181] F=0.2*0.5+0.5*0.6368+0.3*1.0=0.1+0.3184+0.3=0.7184;

[0182] If the score is higher than the preset threshold of 0.7, the server gateway generates a cooperative routing suggestion of "using the pre-selected channel" and returns it to the client through the control channel.

[0183] Steps 2-3: The client determines the final target data channel and obtains the binding cross-channel verification information.

[0184] Steps 2-3 are the steps for determining and securely binding the target channel. The final target data channel is selected by receiving the server's collaborative routing suggestions. Based on the business security level or routing suggestion requirements, cross-channel verification information is obtained and bound through the control channel to establish a security verification foundation for the subsequent packaging of the security envelope.

[0185] Among them, cross-channel verification information is a one-time exclusive verification information generated by the server for the current session and the final target data channel. It is used to achieve a strong binding between the business request, the target channel, and the client session, and to build a cross-channel security verification defense.

[0186] In some implementations, steps 2-3 include the following operational steps:

[0187] The client proxy receives the cooperative routing suggestions returned by the server gateway through the control channel and determines the final target data channel based on the suggestions: if the suggestion is to use a pre-selected channel, then the pre-selected channel is the final target channel; if the suggestion is to switch to another specified data channel, then the specified channel is used as the final target channel; if the suggestion is to add enhanced security verification, then the pre-selected channel is the final target channel and is marked with the enhanced verification flag.

[0188] The client agent then determines whether it needs to obtain cross-channel verification information. The determination condition is that the business request is marked as a high security level or the cooperative routing is recommended to be marked with an enhanced verification mark. If either condition is met, the client agent initiates a cross-channel verification code request to the server-side gateway through the control channel. The request encapsulates the client session ID, the final target data channel identifier, and the security level of the business request.

[0189] After receiving the request, the server-side gateway generates a one-time, unique verification code that binds the current client session and the final target data channel as cross-channel verification information. This verification code is generated using a random number algorithm and is unpredictable and has one-time validity. After generation, the server-side gateway associates and stores the verification information with the session ID and channel identifier, and sends the verification information to the client agent through the control channel.

[0190] After receiving the cross-channel verification information, the client agent uniquely binds it to the current business request and the final target data channel, completing the cross-channel verification information binding process and preparing for subsequent secure envelope encapsulation.

[0191] It should be noted that the application, generation and distribution of cross-channel verification information are all completed through the control channel to avoid occupying the transmission resources of the data channel. In addition, the verification information is for one-time use and expires immediately after use, effectively preventing replay attacks. If the business request is at the normal security level and the routing recommendation does not require enhanced verification, the steps of obtaining and binding cross-channel verification information can be skipped, and the process can directly enter the security envelope encapsulation stage.

[0192] In some implementations, the business security level can be simultaneously identified and determined in the semantic parsing module. Since the semantic parsing module can accurately extract the core features, request type and business attributes of business requests, it can match the security level with the semantic type, business scenario and data sensitivity of the business request one by one, and automatically assign the corresponding security level identifier to the business request.

[0193] Based on the above technical solution, this embodiment of the application achieves intelligent selection of target data channels from business semantic parsing and client-side local pre-selection to server-side global collaborative decision-making through three steps: steps 2-1, 2-2, and 2-3. It also achieves accurate acquisition and binding of cross-channel verification information. Specifically, semantic parsing enables precise matching of business needs and channel capabilities. Combined with a multi-dimensional quantitative channel suitability assessment model, channel selection is upgraded from static configuration to an intelligent process that dynamically adapts to business needs, network status, and global policies, improving the efficiency and rationality of cross-domain data transmission. By generating and binding one-time cross-channel verification information uniquely associated with the session and channel, a strong binding relationship is constructed between business requests, transmission channels, and client identities. This extends the security defense from a single channel to the collaborative verification level of channels and sessions, effectively resisting cross-domain security threats such as man-in-the-middle attacks and channel hijacking. This lays a solid security foundation for subsequent secure transmission and request processing, further enhancing the trust level of cross-domain data service sharing.

[0194] In one possible implementation of the embodiments of this application, combined with Figure 2 and Figure 4 As shown, step 3 above can be implemented through steps 3-1, 3-2, and 3-3, which are explained in detail below:

[0195] Step 3-1: The client constructs a secure envelope containing cross-channel verification information based on the final target data channel.

[0196] Step 3-1 is the encapsulation preparation step for secure transmission. The business request and cross-channel verification information are encapsulated in a structured secure envelope, and the business request is signed in combination with the channel binding key. This achieves the integrity and confidentiality preprocessing of business data before transmission, and establishes the first layer of security protection for cross-domain transmission.

[0197] Among them, the security envelope is a structured transmission carrier that carries business requests and cross-channel verification information. It is used to uniformly encapsulate business data and security verification information to ensure that the two are not separated or tampered with during transmission. The channel binding key signature adds a unique identity to the business request. Its core function is to verify the legality of the source of the business request and the integrity of the transmission, and to prevent data from being forged or tampered with during cross-domain transmission.

[0198] In some implementations, step 3-1 includes the following steps:

[0199] The client agent first initializes the structured format of the security envelope, dividing the security envelope into two parts: the envelope header and the envelope body. The envelope header is used to store security verification and channel association information, while the envelope body is used to store the signed business request data.

[0200] Subsequently, the client proxy writes the request identifier, timestamp, final target data channel identifier, and cross-channel verification information into the envelope header. The request identifier is a globally unique identifier for the current business request, the timestamp is the real-time time constructed in the envelope to prevent replay attacks, and the target data channel identifier and cross-channel verification information are the information bound in steps 2-3 to ensure that the header information is strongly associated with the business request and the transmission channel.

[0201] Next, the client proxy retrieves the session key that is uniquely bound to the final target data channel. This key is generated by the client and the server through a key negotiation algorithm or a key derivation algorithm during the channel establishment phase in step 1-1, and is uniquely associated with the channel identifier and the client session ID. The original business request is then asymmetrically encrypted and signed using this key to generate a signature result.

[0202] Finally, the client agent writes the signed business request and the signing result into the envelope body, completing the overall construction of the secure envelope and ensuring the integrity and confidentiality of the data inside the envelope.

[0203] It should be noted that the entire construction process of the secure envelope is completed locally on the client side. The original business request that is not fully encapsulated will not be transmitted over the network, thus avoiding the leakage of the original data. The key bound to the target data channel is a session-level temporary key that expires immediately after the session ends. Different data channels correspond to different binding keys, thus achieving channel-level key isolation.

[0204] Step 3-2: The client transmits the security envelope to the server-side gateway through the final target data channel.

[0205] Step 3-2 is the cross-domain transmission step of the secure envelope. The point-to-point transmission of the secure envelope is completed through the determined final target data channel. The transmission characteristics of the data channel ensure efficient and stable transmission of the encapsulated data. At the same time, the protocol security characteristics of the channel itself establish a second layer of security protection for the transmission process.

[0206] Among them, the dedicated transmission of the target data channel means that the security envelope is transmitted only through the final target data channel determined in steps 2-3. This is used to ensure that the transmission path of the business data is consistent with the previously bound channel and verification information, and to provide a path basis for the subsequent binding relationship verification by the server. The native security protection of the protocol means to use the native encryption and congestion control features of the HTTP / 2, HTTP / 3 or QUIC protocol on which the data channel is based to provide basic network layer security for the transmission process of the security envelope.

[0207] In some implementations, step 3-2 includes the following steps:

[0208] After the client agent completes the construction of the security envelope, it first performs standardized encapsulation of the security envelope at the protocol layer. Based on the protocol type (HTTP / 2, HTTP / 3, or QUIC) of the final target data channel, the security envelope is encapsulated into the corresponding protocol's transmission data packet to ensure that the data packet conforms to the protocol's transmission format requirements.

[0209] Subsequently, the client agent transmits the encapsulated secure envelope data packets point-to-point through the dedicated transmission link of the final target data channel. During the transmission process, it relies on the real-time quality monitoring results of the data channel, adopts the protocol's native retransmission mechanism to handle packet loss, and relies on the congestion control mechanism to ensure transmission efficiency.

[0210] During transmission, the client agent sends the transmission status information of the security envelope to the server gateway in real time through the control channel, including the amount of data packets sent, transmission progress, and real-time channel status. The server gateway receives and records this status information to achieve traceability of the transmission process.

[0211] Once the server-side gateway returns a security envelope reception confirmation, the client agent completes the transmission process. If no reception confirmation is received within the preset timeout period, a retransmission reminder based on the control channel is triggered, and the security envelope transmission is re-initiated.

[0212] It should be noted that the transmission of the secure envelope only occupies the transmission resources of the final target data channel and does not occupy the control channel resources. At the same time, only the encapsulated secure envelope is sent during the transmission process, without attaching any additional plaintext business information, further reducing the risk of data leakage.

[0213] Step 3-3: The server-side gateway verifies the binding relationship and processes business requests based on the verification results.

[0214] Step 3-3 is the security verification and processing step for business requests. It is the core security verification link for trusted sharing of cross-domain data services. By verifying the binding relationship between cross-channel verification information and target data channel and current session, the legality, authenticity of source and uniqueness of path of business requests are confirmed. Only after the verification is passed can the actual processing of business requests be carried out, thereby avoiding illegal requests and malicious attacks from the root.

[0215] Among them, cross-channel binding relationship verification is a pre-security check performed by the server on business requests. It is used to confirm that the business request corresponding to the currently received security envelope is a trusted request initiated by a legitimate client in the current valid session through the bound target data channel. All three are indispensable. Verification pre-processing means that binding relationship verification is the first step in processing business requests. Requests that fail verification are directly rejected and do not enter the subsequent business logic processing stage, thus avoiding illegal requests occupying the server's business processing resources.

[0216] In some implementations, after receiving the security envelope, the server-side gateway first decapsulates the security envelope and, according to the client's encapsulation format, parses the envelope header and envelope body in sequence to extract the request identifier, timestamp, target data channel identifier, cross-channel verification information, signed business request, and signature result.

[0217] Subsequently, a multi-dimensional verification of the binding relationship is conducted, and the verification process is as follows:

[0218] 1. Session validity verification: Associate the client session ID with the extracted request identifier, check whether the session ID is a valid session and whether the session status is active. If the session is invalid, the request is rejected directly.

[0219] 2. Timestamp validity verification: The extracted timestamp is compared with the current time on the server. If the time difference exceeds the preset timeout threshold (e.g., 30 seconds), it is judged as a replay attack and the request is directly rejected.

[0220] 3. Binding relationship verification: Retrieve the cross-channel verification information-target data channel identifier association mapping table corresponding to the session ID stored locally on the server, compare the parsed cross-channel verification information and target data channel identifier with the information in the mapping table. If the two match completely, the binding relationship verification passes; if any information does not match, the verification fails and the request is rejected.

[0221] 4. Signature Integrity Verification: Retrieve the session key bound to the target data channel identifier, decrypt and verify the parsed signature result, and confirm that the signed business request has not been tampered with during transmission. If the verification passes, all security checks are completed.

[0222] Once all the above verification steps are successful, the server-side gateway decrypts the signed business request, restoring it to the original business request. Based on the business type of the request, it forwards it to the corresponding business processing module for actual processing, such as database query, data calculation, resource call, etc. If any verification step fails, the server-side gateway immediately rejects the business request, generates a verification failure log, including the request identifier, failure reason, client information, timestamp, etc., and sends a verification failure notification to the client proxy through the control channel, informing it of the specific reason for the failure.

[0223] It should be noted that all server-side verification processes are lightweight pre-processing, with processing speeds far exceeding those of business logic processing, ensuring that the system can quickly filter out illegal requests; at the same time, the cross-channel verification information-target data channel identifier association mapping table is dynamically updated in real time, retained only during the session's validity period, and deleted immediately after the session ends.

[0224] Based on the above technical solution, this embodiment of the application, through three steps—steps 3-1, 3-2, and 3-3—achieves end-to-end security control of business requests, from structured secure encapsulation and secure transmission via dedicated channels to multi-dimensional binding relationship verification on the server side, thus constructing a multi-layered security protection system for cross-domain data transmission. Specifically, a structured secure envelope is used to uniformly encapsulate the business request and cross-channel verification information, and a signature is completed using the channel binding key, ensuring the integrity and confidentiality of the business data before transmission. Dedicated point-to-point transmission is performed through the final target data channel, relying on the protocol's native security features and channel quality assurance mechanisms to achieve efficient and stable transmission of the encapsulated data. Through multi-dimensional binding relationship verification on the server side, the business request is strongly correlated with the client session and the target data channel, fundamentally resisting cross-domain security threats such as man-in-the-middle attacks, channel hijacking, and replay attacks, ensuring that only legitimate and trustworthy requests can enter the business processing stage. This step deeply integrates security verification into the entire process of data transmission and request processing, rather than simply adding an extra step. This effectively improves the trust level of cross-domain data service sharing. At the same time, by verifying beforehand, it significantly reduces the consumption of server resources by illegal requests, thereby improving the overall processing efficiency and security of the system.

[0225] In one possible implementation of this application embodiment, step 4 specifically includes steps 4-1 to 4-3:

[0226] Step 4-1: The server classifies the results of the business request processing and initializes the response transmission strategy.

[0227] Step 4-1 involves classifying the results of business request processing by type and determining response priority, and formulating targeted response transmission strategies to achieve differentiated and efficient transmission of response data, ensuring that different types of response data can be matched with the optimal transmission channel and transmission method.

[0228] The initialization of the response transmission strategy involves pre-determining the transmission channel, transmission format, and synchronization method of the response based on the data type and service priority, ensuring the orderliness and rationality of the response transmission.

[0229] In some implementations, step 4-1 includes the following steps:

[0230] After the server-side business processing module completes the business request processing, it divides the generated processing results into three categories according to data attributes and business value: business response data, control signaling data, and important business processing results. It also assigns a corresponding transmission priority to each type of result.

[0231] Business response data refers to the actual business processing output data, including but not limited to database query results, file content, and structured data after calculation and processing, and is marked as the data transmission priority;

[0232] Control signaling data includes status notifications and real-time reminders for business processing, including but not limited to request receipt confirmations, processing notifications, and lightweight status feedback, and is marked as real-time transmission priority.

[0233] Important business processing results are processing conclusions that have a critical impact on the business process, including but not limited to payment transaction results, configuration update confirmations, and batch task execution progress reports, and are marked as dual-channel guarantee priority;

[0234] Subsequently, the server-side gateway initializes the corresponding response transmission strategy based on the type and priority of each result: for business response data with data transmission priority, it initializes a dedicated transmission strategy for the target data channel, using a high-bandwidth transmission format of the corresponding protocol; for control signaling data with real-time transmission priority, it initializes a dedicated transmission strategy for the control channel, using a lightweight signaling encapsulation format; for important business processing results with dual-channel protection priority, it initializes a collaborative transmission strategy for the control channel and the target data channel, configuring the transmission content and timing of different channels respectively.

[0235] Finally, the server-side gateway generates a globally unique response identifier for all response data, associates the request identifier of the corresponding business request with the client session ID, and completes the basic initialization configuration for response transmission.

[0236] It should be noted that the classification and priority marking of response results is an automated process driven by the classification rules preset by the server. The rules can be expanded and the priorities adjusted according to the actual business scenario. All response data is strongly associated with the original business request and client session, ensuring that the response can be accurately traced back to the corresponding request and client.

[0237] For example, after the server completes the processing of a real-time financial transaction query request, it generates two types of processing results: first, the structured data such as the queried transaction history and account balance, which is classified as business response data and marked with data transmission priority; second, the "transaction query successful" status notification, which is classified as control signaling data and marked with real-time transmission priority. The server-side gateway generates a response identifier RS-2025001-008, associates it with the original request identifier RQ-2025001-008 and the session ID GZL-WF33016-2025001, initializes the target data channel transmission strategy of the HTTP / 2 protocol for the business response data, and initializes the control channel transmission strategy of the WebSocket protocol for the control signaling data.

[0238] Step 4-2: The server returns response data to the client through the corresponding channel according to the transmission strategy.

[0239] Step 4-2: Following the transmission strategy initialized in Step 4-1, different types of response data are transmitted to the client through the control channel and / or the target data channel. The transmission characteristics of each channel are combined to ensure the transmission efficiency, real-time performance and integrity of the response data, so as to achieve accurate delivery of cross-domain responses.

[0240] Among them, dedicated channel transmission refers to the transmission of different types of response data only through their matching channels. Its core function is to fully leverage the advantages of low latency and lightweight signaling transmission of the control channel and the advantages of high bandwidth and high stability of business data transmission of the target data channel. Dual-channel collaborative transmission refers to the simultaneous transmission of different content of important business processing results through two channels, providing dual protection for the transmission of important data and ensuring that the client can obtain the processing results in a timely and accurate manner.

[0241] In some implementations, the server-side gateway encapsulates and transmits different types of response data at the protocol layer according to the initial transmission strategy. The specific execution process is as follows:

[0242] 1. Business response data transmission: The business response data is standardized and encapsulated according to the protocol type of the target data channel (HTTP / 2, HTTP / 3 or QUIC). The encapsulation content includes the response identifier, business data body and data verification code. It is transmitted point-to-point through the final target data channel of the original business request. During the transmission process, the congestion control and retransmission mechanism of the data channel is relied upon to ensure the complete and efficient transmission of large-volume business data. At the same time, the transmission progress is synchronized to the client in real time through the control channel.

[0243] 2. Control signaling data transmission: Control signaling data is lightweightly encapsulated, retaining only core information such as response identifier, status code, and simplified status description. It is pushed in real time through the WebSocket control channel. Relying on the long connection characteristics of the control channel, the signaling data is delivered with low latency and without blocking. The client returns a signaling reception confirmation immediately after receiving the data.

[0244] 3. Transmission of important business processing results: A dual-channel collaborative transmission method is adopted. The complete business processing result data is encapsulated according to the target data channel protocol and transmitted through the target data channel. At the same time, the core status information of the processing result (such as transaction success / failure, configuration update completed / incomplete) is encapsulated into lightweight signaling and pushed first through the control channel to achieve the transmission effect of "real-time awareness of core status and subsequent acquisition of complete data".

[0245] After receiving the response data through the corresponding channel, the client proxy first associates it with the original business request based on the response identifier, and then verifies the data: if it is business response data, it verifies the data checksum to ensure data integrity; if it is control signaling data, it verifies the matching of the status code and session ID. If the verification passes, the client proxy parses the response data and performs business implementation; if the verification fails, it initiates a retransmission request to the server through the control channel.

[0246] It should be noted that during the dual-channel collaborative transmission process, the signaling push of the control channel and the business data transmission of the target data channel are executed in parallel, and the transmission priority of the control channel is higher than that of the target data channel, ensuring that the core status of important services can be delivered to the client as soon as possible; the transmission of all response data is unidirectional push and does not occupy additional channel negotiation resources.

[0247] Step 4-3: The server-side achieves real-time synchronization of security status across channels through the control channel.

[0248] Step 4-3 is the security assurance step for the entire cross-domain data sharing process. It is the core link to achieve global system security protection. By controlling the channel, the security status changes of any channel are broadcast and synchronized in real time to ensure that the security context of the client and the server are consistent, so as to achieve a global, rapid and consistent system response to security threats.

[0249] Among them, security status change detection refers to the process of real-time monitoring of the operating status of the control channel and all data channels to identify various security anomalies, which is used to promptly detect security threats in cross-domain transmission; cross-channel security status synchronization refers to the process of globally broadcasting security status change information through the control channel to achieve unified adjustment of security policies for all channels, avoiding global security risks caused by security anomalies in a single channel, and ensuring the consistency of system security policies.

[0250] In some implementations, both the client proxy and the server gateway deploy security status monitoring modules on all channels to monitor channel transmission behavior, data packets, and connection status 24 / 7. When a security anomaly is detected on any channel, a cross-channel security status synchronization process is immediately triggered. The specific steps are as follows:

[0251] 1. Security Anomaly Identification and Reporting: The security status monitoring module classifies detected anomalies according to preset rules, including but not limited to man-in-the-middle attacks, session hijacking, abnormal data packet theft, abnormal channel connection tampering, and unauthorized access attempts. At the same time, it collects the core information of the anomaly, including the anomaly channel identifier, anomaly type, occurrence time, and anomaly message characteristics. The end to which the anomaly channel belongs initiates a security anomaly report to the server-side gateway. The reported information is transmitted encrypted through the control channel.

[0252] 2. Security status update event trigger: After receiving a security anomaly report, the server-side gateway first verifies and confirms the anomaly information. Once the verification is successful, it immediately triggers a global security status update event. Based on the anomaly type and scope of impact, it generates corresponding security policy change instructions. The instructions include, but are not limited to, session token expiration instructions, encryption strength enhancement instructions, specific request abortion instructions, and channel temporary closure instructions.

[0253] 3. Global Security Status Synchronization: The server-side gateway broadcasts security status update events and security policy change instructions globally to all proxies belonging to the client's channels via the WebSocket control channel, ensuring that the client can obtain the global security status in real time; if the scope of the abnormal event is global on the server side, it will be broadcast to the client proxies of all online clients.

[0254] 4. Security Context Update and Communication Behavior Adjustment: Upon receiving a security state update event and policy change instruction, the client agent immediately updates the security context locally. The security context is a set of security attributes and policy states for the current session, including core information such as session token, encryption algorithm, channel access permissions, and allowed request types. After the update, subsequent communication behavior is strictly adjusted according to the new security context: If it is a token invalidation instruction, the existing session token is immediately invalidated and a re-authentication is initiated to the server; if it is an encryption strength enhancement instruction, the encryption algorithm for channel transmission is upgraded from basic encryption to high-strength encryption; if it is a specific request abort instruction, the sending of that type of business request to the server is temporarily stopped until the security state is restored.

[0255] Meanwhile, the server-side gateway will record and trace all security anomalies, generating security logs containing anomaly information, handling measures, and status synchronization results, providing data support for subsequent security analysis and strategy optimization.

[0256] It should be noted that the entire process of security state synchronization is completed through the control channel and uses encrypted transmission to prevent security policy instructions from being tampered with or stolen during transmission; security context updates take effect in real time, ensuring that the client can respond to the server's security policy adjustments as soon as possible, minimizing the impact of security threats.

[0257] For example, if the server detects abnormal packet theft behavior on the client's D-HTTP2-001 data channel and determines it to be a man-in-the-middle attack, it immediately triggers a global security state update event, generates a security policy change instruction of "session token invalidation + encryption strength enhancement", and broadcasts it to the client agent through the control channel. After receiving the instruction, the client agent immediately updates the security context, invalidates the current session token GZL-WF33016-2025001, upgrades the encryption algorithm of all channels from AES-128 to AES-256, and initiates a re-authentication request to the server until a new session token is bound and a secure communication state is restored.

[0258] Based on the above technical solution, this application embodiment achieves differentiated and precise transmission of business response data and global real-time synchronization of cross-channel security status through three steps: 4-1, 4-2, and 4-3. This constructs a closed-loop response and security protection system for trusted sharing of cross-domain data services. Specifically, by classifying and prioritizing processing results, targeted channel transmission strategies are formulated and executed, fully leveraging the respective transmission advantages of the control channel and the target data channel. This achieves efficient, real-time, and complete transmission of response data, improving the response efficiency and user experience of cross-domain data interaction. Furthermore, by deploying security status monitoring modules on all channels and combining this with the global broadcast capability of the control channel, real-time synchronization of security status across channels is achieved. This ensures a high degree of consistency in the security context between the client and server, enabling the system to respond globally, quickly, and consistently to security anomalies in any channel, effectively mitigating global security risks caused by vulnerabilities in a single channel. This step deeply integrates the efficiency optimization of response transmission with the global coordination of security protection. It not only solves the problems of single response transmission path and low efficiency in existing technologies, but also makes up for the vulnerability of inconsistent security policy execution under multi-channel architecture. It further improves the reliability, resilience and trust level of cross-domain data services in complex network environments, and ensures that the entire cross-domain data sharing process is safe, efficient and controllable.

[0259] This invention provides a trusted sharing approach and method for cross-domain data services based on standardized APIs. Many methods and approaches exist for implementing this technical solution; the above description is merely a preferred embodiment. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this invention, and these improvements and modifications should also be considered within the scope of protection of this invention. All components not explicitly stated in this embodiment can be implemented using existing technologies.

Claims

1. A trusted sharing method for cross-domain data services based on standardized APIs, characterized in that: include: Step 1: Establish and maintain a control channel for transmitting control signaling and at least two data channels with different transmission characteristics for transmitting business data between the client and the server. Step 2: The client determines the target data channel for transmitting the business request based on the semantic type of the business request and the status of the data channel, and in conjunction with the server's collaborative routing suggestions, and obtains and binds cross-channel verification information through the control channel; Step 3: The client sends a secure envelope containing the business request and the cross-channel verification information through the target data channel; The server processes the business request by verifying the binding relationship between the cross-channel verification information and the target data channel and the current session. Step 4: After processing the business request, the server returns a response through the control channel and / or the target data channel; wherein, a change in the security status of any channel triggers cross-channel security status synchronization through the control channel.

2. The trusted sharing method for cross-domain data services based on standardized APIs according to claim 1, characterized in that, Step 1 includes the following steps: Step 1-1: Establish a control channel and at least two data channels between the client and the server. The control channel and data channels use different communication protocols. Each data channel is configured with a capability tag that characterizes its transmission characteristics, and the channels are bound to the same session ID. Steps 1-2: Monitor the transmission status of each channel, generate quality assessment information for the data channel, and synchronize the quality assessment information between the client and the server through the control channel; Steps 1-3: Maintain connection keep-alive through the control channel. When a channel interruption or data channel transmission performance degradation is detected, perform channel reconstruction or performance optimization under the session identifier association.

3. The trusted sharing method for cross-domain data services based on standardized APIs according to claim 1 or 2, characterized in that, The status of the data channel is determined by calculating a quality assessment value. The quality assessment value is determined. Specifically, it is calculated using the following formula: in, The average effective payload size of the data channel during the acquisition period, in bytes; RTT stands for Real-time Round Trip Time, measured in milliseconds (ms). T represents the measured throughput of the data channel, in Mbps; B represents the theoretical bandwidth of the data channel, measured in Mbps. L is the packet loss rate of the data channel, which is a dimensionless ratio. Let V be the variance of the data channel network latency jitter, which is a dimensionless value; , , , These are the weight coefficients for each item, which are added together to equal 1. The value of each coefficient is dynamically determined based on the semantic type of the business request, with the principle being that the core transmission characteristics corresponding to the business requirements are matched with higher weights. The acquisition period for the above parameters is the same, preferably 100ms.

4. The method for trusted sharing of cross-domain data services based on standardized APIs according to claim 3, characterized in that, In steps 1-3, a heartbeat keep-alive mechanism established on the control channel is used to detect and determine whether the channel is interrupted; for channels in a connection interruption state, the processing flow is as follows: If the control channel is interrupted, the client agent immediately initiates a control channel reconnection request. After the server gateway verifies the validity of the session ID, it reallocates control channel resources and binds them to the original session ID. After the reconnection is completed, the latest status of all channels is synchronized. If the data channel is interrupted, the client agent sends a data channel reconnection request to the server through the control channel. The server reallocates channel resources with the same protocol and characteristics according to the original channel's transmission capacity label. After the reconnection is completed, the "session-channel" mapping relationship is updated. By using the quality assessment values ​​of each data channel The quality assessment value of a data channel is compared with a preset quality threshold in real time. If the quality assessment value of a data channel is lower than the threshold for a certain number of consecutive collection cycles, the channel is determined to be in a state of performance degradation. For data channels experiencing performance degradation, the client agent triggers a dynamic channel parameter tuning process: based on the data channel's protocol type, core transmission parameters are adjusted accordingly; after parameter tuning, the channel quality assessment value is recalculated; if the assessment value recovers to above the threshold, the tuning is complete. If the connection is not restored, a channel switching request is initiated to the server through the control channel, and the server allocates a new data channel with the same characteristics.

5. The method for trusted sharing of cross-domain data services based on standardized APIs according to claim 1, characterized in that, Step 2 includes the following steps: Step 2-1: The client determines a pre-selected channel from the data channels based on the semantic type of the service request, the transmission capacity labels of each data channel, and the real-time quality assessment information. If the semantic type and transmission capacity labels match, the client prioritizes the channel with better real-time quality assessment and sends a routing consultation request carrying the identifier of the pre-selected channel to the server-side gateway through the control channel. The semantic type is determined based on at least one of the following characteristics: the request type of the service request, the data transmission volume, the real-time requirements, and the security level, through preset classification rules or a trained neural network model. Step 2-2: The server-side gateway generates a cooperative routing suggestion based on the current status, historical performance, and server-side global policy of the pre-selected channel and returns it to the client proxy through the control channel; Steps 2-3: The client agent determines the final target data channel based on the cooperative routing suggestion, and when the preset security conditions are met, obtains cross-channel verification information uniquely bound to the current session and the final target data channel through the control channel. The cross-channel verification information is a one-time verification token generated by the server and uniquely bound to the current session and the target data channel.

6. The method for trusted sharing of cross-domain data services based on standardized APIs according to claim 5, characterized in that, Step 2-2 includes the following steps: Step 2-2-1: Verify the legality and timeliness of the routing consultation request; Step 2-2-2: After successful verification, calculate the comprehensive suitability score of the pre-selected channel based on its connection status, transmission performance indicators, and server-side global policy. Step 2-2-3 compares the comprehensive suitability score with a preset threshold to generate a collaborative routing suggestion, which includes using the pre-selected channel, switching to other data channels, or adding enhanced security checks.

7. The method for trusted sharing of cross-domain data services based on standardized APIs according to claim 6, characterized in that, The comprehensive suitability score F mentioned in step 2-2 is obtained by weighted summation of at least one of the following sub-scores, with the weights added together to equal 1: The health sub-score H reflects the health status of the channel connection; the performance matching sub-score P reflects the degree to which the channel transmission performance matches the service requirements; and the policy compliance sub-score C reflects the degree to which the channel conforms to the server's global policy. Specifically: In the formula, E represents the baseline score for connection status, set to 1.0 when the connection status is "active" and 0.0 otherwise; E is the error rate of the pre-selected channel. The first error rate threshold preset for the server; In the formula, The tag matching score is assigned based on the cosine similarity between the semantic type tag and the transmission capability tag, with a value range of [0,1]. The higher the similarity, the larger the value. The performance quantization function is dynamically determined based on semantic type labels: low-latency type is... D is the average delay time. The low-latency reference latency value is used; the high-throughput type is... T represents throughput. This is a high-throughput reference throughput baseline; the balance type is... In the formula, This is a Boolean value, indicating whether the protocol type of the pre-selected channel is in the server's allowed list; Current number of connections, where U is the current number of channel connections. Set a second load threshold for the channel on the server side.

8. The method for trusted sharing of cross-domain data services based on standardized APIs according to claim 1, characterized in that, Step 3 includes the following steps: Step 3-1: The client agent constructs a secure envelope, which includes an envelope header and an envelope body. The envelope header contains at least the cross-channel verification information and the final target data channel identifier, and the envelope body contains business request data that has been signed by the key bound to the final target data channel. Step 3-2: The client agent transmits the security envelope to the server-side gateway through the final target data channel; Step 3-3: The server-side gateway decapsulates the security envelope and verifies the binding relationship between the cross-channel verification information and the final target data channel. If the verification is successful, the business request is processed. Specifically, the gateway verifies whether the association between the cross-channel verification information, the channel identifier of the final target data channel, and the current client session identifier is consistent with the binding mapping stored on the server. If they are consistent, the verification is successful and the business request is processed; otherwise, the business request is rejected.

9. The method for trusted sharing of cross-domain data services based on standardized APIs according to claim 1, characterized in that, Step 4 includes the following steps: Step 4-1: The server-side gateway determines the response transmission strategy based on the type of the business request processing result; Step 4-2: The server-side gateway returns the response data to the client agent through the control channel and / or the final target data channel according to the response transmission strategy; Step 4-3: When a security anomaly is detected in any of the data channels, the server-side gateway sends a security policy change instruction to the client agent through the control channel, so that the security policy adjustment applies to all channels associated with the session identifier, and the client agent updates the security context according to the instruction. The update of the security context applies to all channels associated with the session identifier.

10. A trusted cross-domain data service sharing system based on standardized APIs, characterized in that: The system includes a client-side proxy module, a server-side gateway module, and multiple heterogeneous data transmission channels connecting the two. The client proxy module is used to initiate routing consultation based on the semantic type and channel status of the business request, and determine the target data channel based on the collaborative routing suggestions from the server-side gateway module; it is also used to obtain cross-channel verification information through the control channel, construct a security envelope, and send the business request through the target data channel. The server-side gateway module is used to receive and verify the routing consultation, generate the collaborative routing suggestion based on real-time load, security policy and channel suitability assessment; it is also used to process the application, binding and verification of the cross-channel verification information, and process the business requests sent through the target data channel. The plurality of heterogeneous data transmission channels include a control channel based on the WebSocket protocol, dedicated to transmitting control signaling, and at least two data channels based on different standardized application layer protocols, used for transmitting business data and having different characteristics.

Images