A multi-source detection and hierarchical routing communication switching method and system

Abstract

The application provides a multi-source detection and hierarchical routing communication switching method and system, and relates to the technical field of communication. The method comprises the following steps: a client pulls encrypted configuration files from multiple CDN nodes in parallel and decrypts to obtain routing configuration information; in the operation gap after the user enters the business channel page and before triggering the business entrance, the background asynchronously detects the availability of the primary and backup domain names; in response to the triggering of the business entrance, hierarchical routing decisions are made according to the routing configuration information and the detection results, and the decision priorities are, in turn, full-line level forced switching, conditional level intelligent switching and IP direct connection bottom line; when the IP direct connection is performed, certificate fingerprint verification is performed; after the switching, the availability of the primary domain name is continuously detected, and when the recovery is performed, the automatic back switching is performed. The corresponding communication switching system is also provided. Through the multi-level degraded link, the asynchronous detection, the certificate security verification and the closed loop back switching mechanism, the end-to-end high availability guarantee and the automatic self-healing of the client business routing are realized.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and specifically to a communication switching method and system for multi-source detection and hierarchical routing. Background Technology

[0002] With the rapid development of internet finance and enterprise applications, the requirements for service availability in e-banking and enterprise client businesses are increasing. To ensure business continuity, existing systems typically adopt an architecture design with multiple domain names or multiple access links. When the primary domain name or primary link fails, service is maintained by switching to a backup domain name or backup link.

[0003] A typical existing technical solution, as described in authorized invention patent CN113890850B, is applied in a software-defined network architecture. This solution involves setting up a primary global routing controller and a backup global routing controller. When the primary global routing controller malfunctions, the system automatically switches to the backup global routing controller. Both the primary and backup controllers are connected to the same routing dependency components to store global routing information. By configuring a significantly different routing weight ratio, the primary controller ensures that routing tasks are handled under normal circumstances. This solution eliminates the risk of single points of failure at the control layer through the deployment of primary and backup dual controllers.

[0004] The aforementioned existing technologies represent the mainstream approach to service disaster recovery switching, which involves deploying primary and backup nodes or links in conjunction with fault detection mechanisms to achieve automatic switching. However, these solutions primarily target the server-side architecture or underlying network link layer. For business routing switching issues in e-banking and enterprise-level client application scenarios, the following unresolved technical shortcomings remain: 1. The availability assurance layer is too simple, lacking an end-to-end multi-level degradation mechanism for client-side business applications. Existing technical solutions are all geared towards disaster recovery at the server-side architecture or underlying link level, switching to controller nodes or data transmission links, without addressing end-to-end availability guarantees for client-side access targets. Current e-banking PC clients typically rely on a single primary domain name for business access. When the primary domain name becomes unavailable due to CDN node failure, DNS poisoning, firewall policy changes, or certificate anomalies, the client directly reports an error and cannot automatically switch to an alternative domain name or direct IP connection for fallback access. The aforementioned existing technologies cannot resolve the business interruption issue on the client side caused by the unavailability of the upper-layer domain name.

[0005] 2. Fault recovery relies on manual intervention and lacks a complete closed-loop self-healing mechanism. Existing technical solutions do not address automatic failback after the primary controller recovers following a switch to the backup controller. In e-banking client scenarios, existing solutions rely on users manually modifying hosts files, manually switching domains, or reinstalling the client to restore service, which is cumbersome, has a low success rate, and cannot achieve self-healing.

[0006] 3. The switching strategy is rigid and lacks hierarchical control and oscillation suppression. Existing technical solutions rely on single fault conditions for switching decisions, failing to support multi-level routing policy configurations such as bank-wide forced switching and condition-based intelligent switching, and also lacking switching oscillation suppression mechanisms for network jitter scenarios. Different fault types require differentiated switching strategies, and a single circuit breaker condition cannot meet the needs of refined operation and maintenance management. Summary of the Invention

[0007] To overcome the technical problems of insufficient availability guarantee for client-side service routing, reliance on manual intervention for fault recovery, and fixed routing switching strategies in existing technologies, this invention provides a communication switching method and system based on multi-source detection and hierarchical strategies.

[0008] This invention provides a communication switching method for multi-source detection and hierarchical routing, comprising the following steps: Step S1, Dynamic Configuration Pull and Decryption: Upon client startup, configuration pull requests are sent in parallel to at least two independent content delivery network nodes to obtain a JSON-formatted configuration file encrypted with an encryption algorithm. The client uses a built-in key to locally decrypt the configuration file, obtaining routing configuration information. The routing configuration information includes at least a full-line toggle switch, a conditional toggle switch, a primary domain name IP address list, and a backup domain name IP address list. The client employs a dual-track mechanism combining scheduled pull and timed polling to detect configuration changes: scheduled pull involves actively pulling the configuration file upon client startup; timed polling triggers a re-pulling of the configuration file when a Universal Serial Bus key device insertion / removal event is detected.

[0009] Step S2, Asynchronous Availability Detection: During the operation interval between the user entering the business channel page and triggering the business entry, the client asynchronously performs domain availability detection in the background. The domain availability detection includes: sending a first lightweight probe request to the primary domain and determining the availability status of the primary domain based on the response result; sending a second lightweight probe request to the backup domain and determining the availability status of the backup domain based on the response result; and reporting the detection results to the monitoring platform. Domain availability is determined based on at least one of the following failure types: connection timeout, connection error, business failure, and content anomaly. Connection timeout refers to no response data received within a preset timeout period; connection error refers to a failure to establish or reset the Transmission Control Protocol (TCP) connection; business failure refers to a Hypertext Transfer Protocol (HTTP) response status code that is not 2xx; and content anomaly refers to response content that does not match the expected content. The client uses a sliding window statistical model to count the continuous detection results. When the number of consecutive failures reaches a preset threshold, the domain is marked as unavailable.

[0010] Step S3, Hierarchical Routing Decision: In response to the user's operation that triggers the service entry point, the client performs a hierarchical routing decision based on the routing configuration information and the detection results; the hierarchical routing decision is executed in the following priority order: If the entire-line switching switch is in the ON state, the service route will be forcibly pointed to the backup domain name; If the overall-level switching switch is in the off state and the condition-level switching switch is in the on state, then it is determined whether the main domain name is available. If the main domain name is unavailable, the service route is pointed to the backup domain name; if the main domain name is available, the client maintains the service route pointing to the main domain name. If both the primary domain name and the backup domain name are unavailable, then an available IP address will be selected from the list of backup domain name IP addresses to perform a direct IP connection.

[0011] Step S4, IP Direct Connection Security Verification: When performing IP direct connection, the client obtains the certificate fingerprint list corresponding to the target IP address, establishes a secure transport layer protocol connection with the target IP address, extracts the public key fingerprint from the server certificate, and compares the extracted public key fingerprint with the certificate fingerprint list. If they match, the communication connection is maintained; if they do not match, the connection is disconnected, and a security risk warning is generated and reported to the monitoring platform. The security risk warning includes the target IP address, the corresponding domain name, the fingerprint comparison result, and the timestamp.

[0012] Step S5, closed-loop rollback: After the client switches the route to the backup domain name, it continues to asynchronously probe the availability of the primary domain name in the background; when the number of consecutive successful probes of the primary domain name reaches a predetermined threshold within a preset time window, it is determined that the primary domain name has been restored to availability, and a rollback instruction is generated to switch the route back to the primary domain name.

[0013] This invention also provides a communication switching system for multi-source detection and hierarchical routing, including a client module, a configuration distribution module, and a monitoring and reporting module: The client module is deployed on the user terminal device and is used to pull encrypted configuration files from at least two independent content delivery network nodes in parallel and decrypt them to obtain routing configuration information. During the operation interval between the user entering the business channel page and triggering the business entry, the availability status of the primary domain name and the backup domain name is asynchronously detected in the background. In response to the user's operation of triggering the business entry, hierarchical routing decisions are performed based on the routing configuration information and the detection results. Certificate fingerprint verification is performed in the IP direct connection scenario. After the route switch, the availability of the primary domain name is continuously detected and a back-switch instruction is generated.

[0014] The configuration distribution module is deployed in the cloud and contains at least two independent content distribution network nodes for storing and distributing routing configuration files encrypted with encryption algorithms. The routing configuration files contain at least a full-line toggle switch, a condition-level toggle switch, a primary domain name IP address list, and a backup domain name IP address list.

[0015] The monitoring and reporting module is used to receive the detection results and security events reported by the client module, generate a main domain name recovery instruction based on the reported data, and feed it back to the client module to trigger route back-switching.

[0016] Compared with the prior art, this application has the following advantages: 1. Configure the fetch mechanism: parallel fetching via dual CDNs and encrypted transmission using national cryptographic standards. Existing technologies typically store configuration information statically on the client's local machine or a single server. Configuration changes require client version upgrades or service restarts to take effect, and the configuration source itself is susceptible to single-point-of-failure risks. This invention employs a dual-CDN parallel fetch mechanism. Upon client startup, it simultaneously requests the configuration file from two independent CDN nodes. If either CDN is unavailable, the configuration can still be obtained from the other node, fundamentally eliminating the single-point-of-failure risk of the configuration center. Simultaneously, the configuration file is encrypted during transmission using national cryptographic algorithms, and the client performs local decryption using a built-in hard-coded key, ensuring the security of configuration information in the transmission link and local storage. Furthermore, the dual-track awareness mechanism of "fixed-point fetching + timed polling" enables the client to proactively obtain configuration changes upon startup and when a Ukey is inserted or removed, resulting in significantly better real-time configuration updates than existing technologies.

[0017] 2. Asynchronous Detection Mechanism: Zero-aware background detection and multi-dimensional judgment Existing technologies use periodic sending of probe messages and determine link status based on the number of timeouts, resulting in coarse-grained detection and a single judgment dimension. Existing client-side solutions typically initiate requests only after the user clicks on a service entry point, leading to delays in fault detection. This invention embeds the probe process into the interval between the user entering the channel page and clicking on the service entry point, performing primary and backup domain name probes asynchronously in the background, completely imperceptible to the user. At the judgment rule level, this invention integrates four failure types—connection timeout, connection error, service failure, and content anomaly—to construct a multi-dimensional domain availability judgment system. Compared to existing technologies that rely solely on a single timeout or status code, this significantly improves the accuracy and reliability of the probe results. The introduction of a sliding window statistical model further avoids false handovers caused by occasional network jitter.

[0018] 3. Routing decision-making mechanism: hierarchical control and conflict resolution Existing technologies rely on single circuit breaker conditions for switching decisions, lacking the ability to manage strategies at different scenarios and granularities. This invention constructs a two-tiered decision-making architecture: a "bank-wide forced switching + condition-based intelligent switching." The bank-wide switch, as the highest priority control method, allows maintenance personnel to force a one-click switch to an alternate domain in the event of a major failure. The condition-based switch, based on asynchronous detection results, enables automated intelligent decision-making. The priority rules and conflict handling logic for both are clearly defined—the bank-wide switch unconditionally overrides the condition-based decision when enabled, effectively avoiding switching chaos caused by policy conflicts. Furthermore, this invention effectively suppresses network jitter by combining a sliding window statistical model with a consecutive failure threshold determination.

[0019] 4. IP Direct Connection Backup Mechanism: Certificate Fingerprint Security Verification Existing technologies do not address fallback solutions for client access when the domain name is completely unavailable. Traditional direct IP connections suffer from certificate-hostname mismatch alerts and man-in-the-middle attack risks. This invention addresses the extreme scenario where both primary and backup domain names are unavailable by implementing a three-tiered fallback through direct IP connection, coupled with a comprehensive certificate fingerprint management mechanism for security assurance: The client queries the IP-domain mapping table based on the target IP to obtain the corresponding domain name and certificate fingerprint list. After the TLS handshake, it extracts the server certificate public key fingerprint and compares it with a local list of valid fingerprints. If they match, normal communication occurs; otherwise, the connection is closed and a security event is reported. This mechanism resolves the certificate alert and security risk issues of traditional direct IP connections, making direct IP connection a secure and usable fallback method.

[0020] 5. Closed-loop back-cut mechanism: from open-loop degradation to closed-loop self-healing Existing technologies rely on manual user intervention to switch back after fault recovery, resulting in low efficiency. This invention achieves a complete closed-loop "probe → switch → probe → switch back": After switching to the backup domain, the client continuously and asynchronously probes the availability of the primary domain. When the number of consecutive successful probes of the primary domain reaches a predetermined threshold within a preset time window, a switchback instruction is automatically generated to switch the route back to the primary domain. This mechanism upgrades traditional open-loop degradation to closed-loop self-healing, enabling automatic switchback after fault recovery without user intervention.

[0021] The aforementioned technical features are not simply superimposed, but rather form a complete technical closed loop through organic synergy: "fault perception → decision-making → safety backup → automatic recovery".

[0022] Specifically: the dual CDN parallel fetching mechanism ensures reliable acquisition of routing configurations, providing foundational data for subsequent probing and decision-making; the asynchronous probing mechanism continuously monitors domain name availability without user awareness, providing real-time and accurate status input for routing decisions; the hierarchical routing decision-making mechanism combines probing results with dynamically adjustable policy switches, achieving a balance between automation and controllability; the IP direct connection certificate fingerprint verification mechanism provides a final line of defense for security and availability in extreme scenarios where both primary and backup domain names are unavailable; and the closed-loop fallback mechanism upgrades the entire switching process from unidirectional degradation to bidirectional self-healing. Each link is interconnected and seamlessly integrated, collectively forming a complete high-availability assurance system for client-side business routing.

[0023] The synergistic gains among the various technical features significantly outperform the sum of their individual effects when applied independently: the detection mechanism provides precise input for decision-making, the decision-making mechanism provides strategic basis for switching, IP direct connection provides a safety net for extreme scenarios, and the back-off mechanism provides an automated closed loop for recovery. This complete link design from fault detection to automatic recovery makes the overall technical effect of this invention far exceed the simple summation of existing technical solutions. Attached Figure Description

[0024] Figure 1 This is a general flowchart of the method described in Embodiment 1; Figure 2 A flowchart for hierarchical routing decision-making; Figure 3 Flowchart for IP Direct Connection Security Verification; Figure 4 This is an architecture diagram of the system described in Example 2. Detailed Implementation

[0025] Definitions: CDN (Content Delivery Network) refers to a distributed server node system deployed across multiple geographical locations to distribute content to the nearest node based on the user's geographical location, thereby accelerating content delivery and improving availability.

[0026] OCSP Online Certificate Status Protocol: This protocol is used to query the revocation status of digital certificates online in real time. Clients use this protocol to query the OCSP server whether the target certificate has been revoked.

[0027] Application Performance Management (APM) refers to a platform system used to monitor and manage the performance and availability of applications, capable of collecting, analyzing, and displaying application runtime status data.

[0028] TLS (Transport Layer Security) is an encryption protocol used to provide secure communication over computer networks, ensuring the confidentiality and integrity of data transmission between clients and servers.

[0029] EV Certificate: Refers to Extended Validation Certificate, a digital certificate issued after strict identity verification. It is usually displayed in green in the browser address bar and has a high degree of credibility.

[0030] OV certificate: refers to Organization Verified Certificate, a digital certificate issued after an organization has verified its identity. Its credibility is lower than that of EV certificate but higher than that of domain verification certificate.

[0031] UKey: refers to a hardware encryption device that uses a USB interface and has built-in digital certificates and keys for user authentication and data encryption.

[0032] Sliding window statistical model: refers to a statistical method based on time series, which counts the continuous detection results within a preset time period. When the number of consecutive failures reaches a preset threshold, the target state is determined to be unavailable, which is used to filter out occasional network jitter.

[0033] Business Channel Page: This refers to the intermediate navigation interface in the client that displays various business service entry points. This page aggregates the corporate online banking entry, the bank-enterprise direct connection entry, and the cash management entry, and is the necessary transition page for users to access specific business functions from the client's homepage. This application utilizes the gaps in user browsing time on this page to perform background probing.

[0034] Example 1 This embodiment provides a communication switching method based on multi-source detection and hierarchical routing. Using a bank client as the carrier, this method performs end-to-end availability management for a three-tier architecture consisting of a primary domain name, a backup domain name, and direct IP connection. This embodiment describes the corresponding timing process in text, such as... Figure 1 As shown, the method includes the following sequentially executed and logically coupled steps.

[0035] Step S1, Configure dynamic fetching and decryption When the bank client process starts, it immediately creates two parallel configuration retrieval threads, which send Hypertext Transfer Security Protocol (HTTP) configuration retrieval requests to two independent content delivery network (CDN) nodes deployed on different carrier networks. If either node fails to respond due to network failure or service downtime, the other node can independently complete the configuration distribution, thus eliminating the single point of failure risk of the configuration center. After obtaining the JSON-formatted configuration file encrypted with the national cryptographic algorithm SM4, the client calls its locally built-in hard-coded key to decrypt and verify the integrity of the ciphertext, obtaining structured routing configuration information. This information includes at least a Boolean-type bank-wide switching switch, a conditional switching switch, and a list of IP addresses corresponding to the primary and backup domain names.

[0036] To achieve real-time configuration awareness, the client adopts a dual-track mechanism combining fixed-point fetching and timed polling: fixed-point fetching refers to the client actively executing the above fetching process during each cold start; timed polling refers to the client registering a USB device hot-plug broadcast listener at the operating system level, which immediately triggers the re-fetching of the configuration file and version comparison when a Universal Serial Bus key device insertion or removal event is detected.

[0037] Regarding the configuration update effectiveness strategy, this method adopts a differentiated hot-reloading mechanism for different configuration items: For routing policy changes, including changes to the domain name switching switch and additions or deletions to the IP address list, the new configuration takes effect during the next routing decision after all currently ongoing business sessions are completed, ensuring that existing services are not interrupted; For certificate fingerprint changes, the client immediately clears the old fingerprints cached in memory and forces the use of the new fingerprint list when the next TLS connection is established; For probe strategy changes such as probe timeout parameter changes and sliding window threshold changes, the probes currently in progress are not affected, and the new parameters are automatically adopted when the next probe cycle starts.

[0038] Step S2, Asynchronous Availability Detection After a user successfully logs in and enters the business channel page, but before the user actually clicks a specific function button on that page, the bank's client performs a domain availability probe in the background via a non-blocking I / O asynchronous task. This probe is completely imperceptible to the user's visual and operational level. The business channel page is the main page for corporate online banking functions, and the specific function buttons are account inquiry or fund transfer buttons.

[0039] The asynchronous probe submodule sends HTTP GET requests to the primary and backup domains, pointing to either a 1KB static JavaScript resource or a dedicated health check interface. The explicit rules for determining probe failure are based on the following four-dimensional types: First, connection timeout, which means that no TCP handshake confirmation packet or data packet is received from the server within a 1-second timeout threshold.

[0040] Second, connection error, that is, receiving an RST reset packet during the TCP three-way handshake phase, or the connection being abnormally disconnected due to network unreachability.

[0041] Third, business failure, i.e., the HTTP response status code is not 2xx, including 500 Internal Error, 502 Gateway Error, and 503 Service Unavailable.

[0042] Fourth, content anomaly, that is, the HTTP status code is 200 but the response entity is missing a fixed field or the field value does not match. The fixed field is the status flag field.

[0043] The aforementioned 1-second timeout value was determined by the bank's network operations center based on nationwide operator RTT round-trip latency (P95) statistics. Nationwide operator RTT P95 statistics typically show a timeout below 200 milliseconds, which is determined in conjunction with the theoretical distribution that 99% of requests can be completed within 1 second. The 1KB probe resource design balances end-to-end verification and server load control. End-to-end verification includes four stages: DNS resolution, TCP connection establishment, TLS handshake, and HTTP response. Regarding server load control, the daily traffic per user is kept below 3MB.

[0044] The client incorporates a sliding window statistical model, which maintains independent failure counters for the primary and backup domains. When a domain experiences any of the aforementioned types of failures, the counter is incremented. When the number of consecutive failures reaches a preset threshold (three consecutive failures), the client switches the domain's status in the state machine from available to unavailable. After a single probe failure, the asynchronous probe submodule automatically performs one retry; only if the retry also fails is the retry counted in the sliding window. This retry strategy, combined with the sliding window mechanism, avoids misjudgments caused by momentary network jitter and prevents secondary pressure on the server from client probe traffic when the server is truly unavailable. Each probe result is accompanied by a timestamp and failure type code, and is reported to the monitoring platform in real time via an encrypted channel.

[0045] Step S3, Hierarchical routing decision like Figure 2 As shown, when a user clicks on a specific business entry point on the business channel page, the client-side routing decision submodule is triggered synchronously. This specific business entry point is the money transfer / remittance entry point. Based on the routing configuration information obtained in step S1 and the latest domain name status maintained in step S2, this module performs route selection according to the following fixed priority.

[0046] The first priority is a bank-wide forced failover. The bank-wide failover switch is read. If enabled, the actual detection status of the primary and backup domains and the conditional switch settings are unconditionally ignored, and all business requests are forcibly routed to the backup domain. This mechanism is used to handle extreme operational scenarios such as large-scale shutdowns of the bank's central data center or global flow control requirements from regulatory authorities.

[0047] The second priority is conditional intelligent switching. When the overall switch is off, the conditional switching switch is read. If the switch is on, the availability of the primary domain name is determined based on the detection result of step S2. If the primary domain name is marked as available, the route is directed to the primary domain name; if the primary domain name is marked as unavailable, the availability of the backup domain name is further determined. If the backup domain name is available, the connection is switched to the backup domain name; if the backup domain name is also unavailable, the third priority IP direct connection is used as a fallback. If the conditional switch is off, the client will forcibly lock the primary domain name regardless of its status. This setting is used to prevent automatic accidental switching when network maintenance personnel confirm that the primary domain name is in a suspended or partially open state.

[0048] The third priority is direct IP connection as a fallback. If, based on the aforementioned two-level judgment, both the primary domain name and the backup domain name are marked as unavailable due to probe failure, the routing decision submodule removes known unreachable IPs from the backup domain name IP address list, selects the first surviving IP address as the target, and performs IP direct connection downgraded access.

[0049] Step S4, IP Direct Connection Security Verification like Figure 3 As shown, upon entering the IP direct connection branch, the client security verification submodule takes over communication control. This submodule first retrieves the locally cached IP-domain mapping table based on the target IP address to obtain the corresponding official domain name, and then indexes the list of legitimate certificate fingerprints corresponding to that domain name. This list of legitimate certificate fingerprints contains at least one set of public key fingerprints in SHA-256 format. Subsequently, the client establishes a TLS connection with the target IP address. After the TLS handshake is complete, it extracts the public key portion from the X.509 certificate returned by the server and calculates its SHA-256 digest value, which is Base64 encoded. The client compares this digest value with the local list of legitimate fingerprints item by item. If they match, the communication connection is maintained, and business data transmission begins. If they do not match, the client immediately sends a TLSAlert message to proactively disconnect, blocking potential man-in-the-middle attacks or certificate impersonation risks, and simultaneously generates a detailed security event log. This security event log contains the target IP, corresponding domain name, the actual extracted fingerprint, and the expected fingerprint list. This log is encrypted and reported to the bank's monitoring platform.

[0050] Step S5, closed-loop back-cut After step S3 or S4 causes the route to switch to the backup domain name or direct IP connection, the asynchronous probing submodule in the client's backend continues to perform availability probing on the primary domain name with the same parameters as in step S2 without interruption. When the sliding window statistical model shows that the number of consecutive successful probes of the primary domain name within a preset time window reaches a predetermined threshold, the client determines that the primary domain name has recovered from the failure. When the sliding window statistical model shows that the number of consecutive successful probes reaches 3, the client determines that the primary domain name has been restored to availability (without needing to set an additional 30-minute time window); or it can be changed to "determine recovery when the percentage of successful probes reaches a preset threshold (e.g., ≥90%) within a 30-minute time window". At this time, the back-switch control submodule generates a back-switch instruction, automatically switching the routing target back to the primary domain name before the next user service request is initiated, completing the complete closed-loop self-healing process of probing, switching, continuous monitoring, recovery verification, and automatic back-switch.

[0051] Example 2 This embodiment provides a communication switching system for multi-source detection and hierarchical routing, which adopts a cloud-based collaborative and layered decoupling architecture. For example... Figure 4 As shown, the system is divided into a basic resource layer, a routing decision execution layer, a configuration control layer, and a monitoring and feedback layer from bottom to top.

[0052] The basic resource layer comprises a primary domain name server cluster and a backup domain name server cluster, as well as an IP address resource pool distributed across various data centers. The primary domain name server cluster deploys EV certificates, and the backup domain name server cluster deploys OV certificates. This layer provides the final business access target for clients.

[0053] The configuration control layer, also known as the configuration distribution module, is deployed on cloud nodes within the bank's DMZ isolation zone. This module comprises at least two independent content delivery network nodes, physically and logically isolated based on geographical location or carrier link. The configuration control layer stores SM4-encrypted JSON-formatted routing configuration files and maintains configuration version numbers and update logs. This module allows bank operations personnel to dynamically modify the bank-wide switching switch status, condition-level switching switch status, domain name-IP mapping table, and certificate fingerprint whitelist via the management console. When configuration changes occur, the control layer employs a dual-caching strategy to push updates. New fingerprints are pre-written into the memory cache and marked as pending activation, while old fingerprints are retained in parallel for a 24-hour grace period to ensure uninterrupted long-term connections during certificate rotation.

[0054] The routing decision execution layer, also known as the client module, resides on the user's PC terminal. This layer is internally divided into a configuration retrieval submodule, an asynchronous detection submodule, a routing decision submodule, a security verification submodule, and a switchback control submodule.

[0055] The configuration pull submodule is responsible for performing dual-source parallel pulls when the client starts up and when the UKey is plugged in or unplugged, completing configuration decryption, version checking, and differentiated hot reloading.

[0056] The asynchronous probe submodule is responsible for performing lightweight HTTP probes during user business operations, running a sliding window statistical model, and managing the state machine of the primary and backup domains, which includes available and unavailable states. The asynchronous probe submodule pushes state change events to the routing decision submodule in real time.

[0057] The routing decision submodule listens for user clicks on service entry points and performs route arbitration based on a hard-coded priority logic: a bank-wide switch has higher priority than a combination of conditional switches and probe states, and a combination of conditional switches and probe states has higher priority than direct IP connections. This submodule communicates with the asynchronous probe submodule through an in-process cache to ensure that the decision is made based on the latest domain name status updated microseconds ago.

[0058] The security verification submodule is responsible for the local comparison of TLS handshake and certificate public key fingerprint, and maintains a local snapshot of the IP-domain mapping table.

[0059] The rollback control submodule monitors the recovery status of the main domain name and manages the cooldown timer and rollback trigger logic.

[0060] The monitoring feedback layer, also known as the monitoring reporting module, is deployed in the bank's operations and maintenance area. This module receives massive amounts of client-reported probe results, switchover events, and security alarms through a high-concurrency log collection interface. The monitoring feedback layer performs real-time streaming computation on the reported data, calculating the global or regional success rate of the main domain. When the analysis indicates that the main domain has recovered to a normal threshold within a preset time window, this module does not directly issue a forced rollback command to avoid server-side impact caused by a sudden large-scale rollback. Instead, this module generates a recovery indication signal and pushes it to the client rollback control submodule. Each client then autonomously triggers the rollback based on its own local sliding window success count, achieving peak smoothing and valley filling of rollback traffic.

[0061] The data flow and control flow relationships between the layers are as follows: The configuration and management layer issues policies to the routing decision execution layer through the CDN link; the routing decision execution layer feeds back the detection results and security events to the monitoring feedback layer through the encrypted uplink; the monitoring feedback layer assists in the back-off decision through downlink signaling, forming a complete closed-loop data circuit of policy issuance, status reporting, and recovery feedback.

[0062] Example 3 This embodiment uses the implementation of the methods and systems described in Embodiments 1 and 2 under the scenario of a regional domain name system failure in a large commercial bank as an example to illustrate the process.

[0063] The bank's corporate online banking client is deployed across provinces and cities nationwide, using a single domain name for business access. One day, a regional DNS hijacking occurred with a telecommunications operator in a province in East China, causing corporate online banking users in that province to have their DNS resolution results redirected to incorrect IP addresses, rendering them unable to access the main domain.

[0064] The bank's operations and maintenance personnel discovered through the monitoring and reporting module that the failure rate of the probes for users in the province had increased sharply. After the customer service confirmed the fault, it was determined to be an anomaly in the provincial operator's domain name system.

[0065] The operations and maintenance personnel enable the condition-level switching switch in the configuration distribution module, setting the condition-level switching policy for users in that province to the enabled state. The configuration distribution module then distributes the updated configuration file to each client in that province through dual content distribution network nodes.

[0066] The deployed client module asynchronously sends lightweight probe requests to the primary and backup domains in the background during the interval between the user's access to the corporate online banking channel page and the click on the business entry point. Due to regional domain name system hijacking, the probe requests sent by the asynchronous probe submodule of the client module to the primary domain are judged as connection errors due to domain name resolution failures. When the number of consecutive failures reaches a preset threshold in the sliding window statistical model, the primary domain is marked as unavailable. At the same time, the backup domain is unaffected because it uses a different domain name resolution line and is marked as available.

[0067] When a user clicks on the corporate online banking service entry point, the routing decision submodule of the client module reads the current routing configuration information. The bank-wide toggle switch is off, the conditional toggle switch is on, the primary domain is unavailable, but the backup domain is available. The routing decision submodule directs the service to the backup domain according to the hierarchical routing decision logic. The user can then complete corporate online banking operations normally under this backup domain, without any manual intervention.

[0068] During the outage, the asynchronous probe submodule of the client module continued to asynchronously probe the availability of the primary domain name in the background of user business operations. Approximately two hours later, the ISP repaired the DNS fault, and the probe requests sent by the asynchronous probe submodule to the primary domain name resumed normal response. The monitoring and reporting module received the successful probe data reported by each client and performed statistical analysis. After the number of consecutive successful probes to the primary domain name reached a predetermined threshold within a preset time window, a primary domain name recovery indication was generated and fed back to the fallback control submodule of each client module, triggering a route fallback to the primary domain name.

[0069] In this embodiment, the entire process from the occurrence of a fault to the automatic switch to the backup domain name takes less than a minute. Users only perceive that the service is loading normally, without the need for manual operations such as modifying network configuration or reinstalling the client.

[0070] Example 4 This embodiment uses the methods and systems described in Embodiments 1 and 2 as examples to illustrate the implementation of the main domain name in a scenario where a digital certificate anomaly causes the main domain name to become unavailable.

[0071] A certain enterprise application client's main domain uses an EV certificate issued by GlobalSign. Due to a power outage in the data center, the OCSP response server for this certificate experienced service interruption, causing the client to be unable to obtain the certificate revocation status during the TLS handshake. Consequently, a large number of connections were terminated because the client's underlying library deemed them insecure due to the lack of OCSP response.

[0072] The asynchronous probe submodule of the deployed client module sends a lightweight probe request to the main domain in the background after the user enters the business channel page. The TCP connection is successfully established, but the TLS handshake phase results in an OCSP query timeout, causing the overall probe request to be judged as a connection timeout. This timeout exceeds 1 second and is classified as a content anomaly. In the sliding window statistical model, after the number of consecutive timeouts reaches a preset threshold, the main domain is marked as unavailable. The backup domain uses an OV certificate issued by DigiCert, and its OCSP response server is functioning normally; therefore, the backup domain is marked as available.

[0073] When a user triggers a service entry point, the routing decision submodule, based on the configuration that the bank-wide toggle switch is off and the condition-level toggle switch is on, and combined with the detection results of the primary domain being unavailable and the backup domain being available, redirects the service route to the backup domain. The user accesses the service normally through the backup domain, and the service operation is not interrupted.

[0074] During the fault repair, bank operations personnel reapplied for a new certificate from the certificate authority and deployed it to the primary domain name server, while simultaneously updating the certificate fingerprint list at the configuration control layer. The configuration distribution module pushed the new fingerprint configuration to each client through dual content delivery network nodes. The client module's configuration retrieval submodule triggered a re-retrieval of the configuration file upon detecting a Universal Serial Bus key device insertion / removal event, obtaining the updated configuration containing the new certificate fingerprint list. According to the differentiated configuration update strategy, certificate fingerprint changes are of the immediate effect type; the client module's security verification submodule cleared the old fingerprint cache and used the new fingerprint list during subsequent transport layer security protocol connection establishment. When the new fingerprint is enabled, the configuration distribution module retains both the old and new fingerprints, entering a grace period. During the grace period, the security verification submodule accepts both the old and new fingerprints when verifying certificate fingerprints, ensuring that existing connections are not affected during certificate rotation. After the grace period ends, the configuration distribution module automatically clears expired fingerprints.

[0075] Meanwhile, the monitoring and reporting module receives the main domain detection results reported by each client. After the OCSP service is restored, the monitoring feedback layer detects that the main domain's HTTP response status code is 200 and the response body contains the correct flag fields, generates a recovery instruction, and the client automatically switches back. Users are automatically switched back after the main domain is restored, and the entire fault handling process is completely unnoticed by the user.

[0076] Example 5 This embodiment uses the methods and systems described in Embodiments 1 and 2 to illustrate how to avoid frequent switching in network jitter scenarios.

[0077] The office network hosting a bank's client application experienced three brief, intermittent outages within 10 minutes, each lasting 6 to 8 seconds before automatically recovering. The client application modules deployed in this region continuously and asynchronously probed the availability of the primary and backup domain names in the background according to a preset probe cycle.

[0078] When the first brief interruption occurs, the asynchronous probing submodule of the client module sends a probe request to the main domain. If no response is received within the preset timeout period, the probe is judged as a connection timeout, and a failure is recorded in the sliding window statistical model. Since the single failure does not reach the preset threshold for the number of consecutive failures, the main domain remains available, and the routing decision submodule continues to route the service to the main domain when the user triggers the service entry.

[0079] When the second interruption occurs, the asynchronous detection submodule records another failure. The number of consecutive failures in the sliding window statistical model accumulates to two, but still does not reach the preset threshold. The main domain name remains available, and the business route continues to point to the main domain name.

[0080] When the third intermittent interruption occurs, the asynchronous probing submodule records the third consecutive failure. When the number of consecutive failures reaches a preset threshold, the primary domain is marked as unavailable. Simultaneously, the backup domain responds normally to probes during each intermittent interruption and is marked as available. When a user triggers a service entry point, the routing decision submodule switches the service route to the backup domain based on the status of the primary domain being unavailable and the backup domain being available.

[0081] After the network outage ends and network service is restored, the asynchronous probe submodule sends a successful probe request to the primary domain name. Based on the sliding window statistical model, the number of consecutive successful probes to the primary domain name is accumulated. When the number of consecutive successful probes reaches a predetermined threshold within a preset time window, the primary domain name is re-marked as available. Upon receiving the report data indicating that the primary domain name has become available, the monitoring and reporting module generates a recovery instruction, and the fallback control submodule triggers a route fallback to the primary domain name.

[0082] In this embodiment, occasional brief disconnections do not trigger unnecessary domain name switching, while continuous failures trigger reasonable switching and automatically switch back after the failure is resolved, thus achieving a synergy between switching oscillation suppression and closed-loop self-healing.

[0083] Example 6 This embodiment illustrates a case of implementing direct IP connection as a fallback in the extreme scenario where both the primary domain name and the backup domain name are unavailable, using the methods and systems described in Embodiments 1 and 2.

[0084] A severe network infrastructure failure occurred in a certain region, causing users in that region to fail to access both the primary and backup domain names. The primary and backup domain names are deployed on different network service providers, and because the failure affects multiple network service providers, both domain names are inaccessible.

[0085] The deployed client module's asynchronous probe submodule asynchronously performs availability probes for the primary and backup domains in the background after a user enters the business channel page. The first lightweight probe request sent to the primary domain fails to receive a response within a preset timeout period and is judged as a connection timeout. The second lightweight probe request sent to the backup domain also fails to receive a response within the preset timeout period and is judged as a connection timeout. In the sliding window statistical model, if the consecutive failure counts for both the primary and backup domains reach a preset threshold, both domains are marked as unavailable.

[0086] When a user triggers the service entry point, the routing decision submodule reads the routing configuration information. With the entire server-wide switching switch off and the conditional switching switch on, both the primary and backup domains are unavailable. The routing decision submodule then enters the three-level fallback phase according to the priority order of the hierarchical routing decisions: selecting an available IP address from the backup domain IP address list to perform a direct IP connection. Based on the connectivity information of each IP address obtained during the asynchronous probing process, the routing decision submodule selects a normally responding IP address from the backup domain IP address list as the direct connection target.

[0087] The security verification submodule performs direct IP connection security verification. Based on the target IP address selected by the routing decision, the security verification submodule queries a pre-configured IP-domain mapping table to obtain the domain name corresponding to the target IP address and the list of certificate fingerprints for that domain name. The security verification submodule establishes a transport layer security protocol connection with the target IP address, extracts the public key fingerprint from the server certificate, and compares the extracted public key fingerprint with the legitimate fingerprints obtained from the certificate fingerprint list.

[0088] If the comparison matches, the security verification submodule determines that the target IP address is legitimate, maintains the communication connection, and the user completes business access through direct IP connection.

[0089] If the comparison fails, the security verification submodule determines that there is a risk of a man-in-the-middle attack or a certificate configuration error. It then disconnects the transport layer security protocol connection with the target IP address and generates a security risk alert, which is reported to the monitoring and reporting module. The security risk alert includes the target IP address, corresponding domain name, fingerprint comparison result, and timestamp. The client module displays the security risk alert information on the user interface, reminding the user that there is a security risk in the current network environment and suggesting switching network environments and trying again.

[0090] In this embodiment, a three-level fallback is achieved through direct IP connection in the extreme scenario where both primary and backup domain names are unavailable. The certificate fingerprint verification mechanism ensures the security of direct IP connection communication and solves the problems of certificate hostname mismatch alarms and man-in-the-middle attack risks in traditional direct IP connection methods.

[0091] The methods, systems, and scenario embodiments described in this application are intended to fully demonstrate the specific implementation paths of the present invention to those skilled in the art, but are not intended to limit the scope of protection of the present invention. Any adaptive changes to the specific parameters, encryption algorithms, application scenarios, and functions of each module in the embodiments, without departing from the core technical concept of this application, are all implementation variations that can be conceived by those skilled in the art after reading this application without creative effort.

[0092] The specific parameters include detection timeout, number of retries, sliding window threshold, and cooldown time; the specific application scenarios are not limited to bank clients, but also applicable to securities clients, government clients, e-commerce clients, and other desktop applications with high availability requirements. These variations should all be understood to fall within the scope of protection of this application. Technical solutions formed by combining various embodiments, as long as they do not violate the basic technical concept of this application, should be considered as part of the technical solutions disclosed and claimed in this application.

Claims

1. A communication switching method for multi-source detection and hierarchical routing, characterized in that, include: The configuration retrieval process involves the client pulling encrypted configuration files from at least two independent content delivery network nodes in parallel and decrypting them to obtain routing configuration information. The routing configuration information includes at least a full-line toggle switch, a condition-level toggle switch, and a list of primary and backup domain name IP addresses. The asynchronous detection step involves the client asynchronously performing a primary and backup domain availability detection in the background during the operation interval between when the user enters the business channel page and before the business entry is triggered. The hierarchical routing decision-making process, in response to a user's triggering of a service entry point, involves the client executing hierarchical routing decisions according to the following priority order based on routing configuration information and probe results: If the bank-wide switching switch is enabled and the backup domain name is available, the service route will be directed to the backup domain name; if the backup domain name is unavailable, direct IP connection will be executed. If the overall switching switch is off and the conditional switching switch is on, then determine whether the main domain is available. If the main domain is available, maintain the main domain; if the main domain is unavailable, switch to the backup domain or direct IP connection. If both the full-level switching switch and the condition-level switching switch are turned off, the service route will continue to point to the main domain name; If both the primary and backup domain names are unavailable, select an available IP address from the backup domain name IP address list to perform a direct IP connection. The closed-loop rollback process involves continuously probing the availability of the primary domain name after a route switch, and automatically switching back to the primary domain name upon recovery.

2. The communication switching method for multi-source detection and hierarchical routing according to claim 1, characterized in that, The client employs a dual-track mechanism combining point-to-point fetching and timed polling to detect configuration changes: point-to-point fetching involves actively fetching the configuration file upon client startup; timed polling triggers a re-fetching of the configuration file when a Universal Serial Bus key device insertion or removal event is detected.

3. The communication switching method for multi-source detection and hierarchical routing according to claim 1, characterized in that, Domain availability is determined based on at least one of the following failure types: connection timeout, connection error, service failure, and content anomaly. Connection timeout means no response data is received within the preset timeout period; connection error means the Transmission Control Protocol (TCP) connection establishment fails or is reset; service failure means the Hypertext Transfer Protocol (HTTP) response status code is not 2xx; and content anomaly means the response content does not match the expected content.

4. The communication switching method for multi-source detection and hierarchical routing according to claim 3, characterized in that, The client uses a sliding window statistical model to count the results of continuous probes. When the number of consecutive failures reaches a preset threshold, the domain name is marked as unavailable. After a single probe failure, the client automatically performs a retry. Only retry failures are counted in the sliding window statistical model.

5. The communication switching method for multi-source detection and hierarchical routing according to claim 1, characterized in that, When performing a direct IP connection, the client obtains the certificate fingerprint list corresponding to the target IP address, establishes a secure transport layer protocol connection with the target IP address, extracts the public key fingerprint from the server certificate, and compares the extracted public key fingerprint with the certificate fingerprint list. If they match, the communication connection is maintained; otherwise, the connection is closed.

6. The communication switching method for multi-source detection and hierarchical routing according to claim 1, characterized in that, When the primary domain name becomes available again, the condition for switching the route back to the primary domain name is: when the number of consecutive successful probes of the primary domain name reaches a predetermined threshold within a preset time window, the primary domain name is determined to have become available again.

7. The communication switching method for multi-source detection and hierarchical routing according to claim 1, characterized in that, The configuration file is encrypted using the national cryptographic algorithm, and the client uses a built-in key to decrypt the configuration file locally.

8. The communication switching method for multi-source detection and hierarchical routing according to claim 1, characterized in that, Different hot-reload mechanisms are adopted for different configuration items: routing policy changes take effect when the next routing decision is made after the current business session is completed; certificate fingerprint changes take effect immediately; and probe policy changes take effect when the next probe cycle starts.

9. The communication switching method for multi-source detection and hierarchical routing according to claim 1, characterized in that, When performing direct IP connection, an available IP address is selected from the list of backup domain name IP addresses. Specifically, the client selects an available IP address as the direct connection target after removing unreachable IPs from the list of backup domain name IP addresses based on the connectivity information of each IP address obtained during the asynchronous probing process. The direct IP connection includes the scenario triggered when the entire row-wide switching switch is enabled and the backup domain name is unavailable.

10. A communication switching system for multi-source detection and hierarchical routing, characterized in that, include: The client module, deployed on the user terminal device, is used to pull encrypted configuration files from at least two independent content delivery network nodes in parallel and decrypt them to obtain routing configuration information. During the interval between the user's entry into the business channel page and the triggering of the business entry point, the availability status of the primary domain name and the backup domain name is asynchronously detected in the background; In response to user-triggered business entry operations, hierarchical routing decisions are executed based on routing configuration information and probe results, and the availability of the primary domain name is continuously probed after a route switch to trigger a route rollback; The configuration distribution module is deployed in the cloud and contains at least two independent content delivery network nodes for storing and distributing encrypted routing configuration files. The routing configuration files contain at least a full-line toggle switch, a condition-level toggle switch, a list of primary domain name IP addresses, and a list of backup domain name IP addresses. The monitoring and reporting module is used to receive the detection results and security events reported by the client module, generate a main domain name recovery instruction based on the reported data, and feed it back to the client module to trigger route back-switching.

Images