Method for constructing hash key based on binding token for httpdns node scheduling

Abstract

The application discloses a method for constructing a hash KEY based on a binding token for HttpDNS node scheduling, relates to the technical field of Internet access acceleration, and comprises the following steps: receiving a resolution request containing a domain name host, a client IP and a binding token token, and adapting IPv4 / IPv6; checking the token in a stateless manner, and generating a new token containing a 32-bit mapping_id with a subfield of expire_time and version_id if the token is invalid; splicing the host, the client_ip and the mapping_id, and then generating a hash KEY by using XXHash64; selecting a target node in combination with dynamic weights such as node health degree and delay; and returning a VIP, a token and a dynamic TTL. The method improves the TLS session multiplexing rate, realizes quick fault switching, supports stateless expansion of a server, gives the client an initiative scheduling right, guarantees long session stability and bucketing, and improves service quality and expansibility.

Description

Technical Field

[0001] This invention relates to the field of Internet access acceleration technology, and in particular to a method for constructing a hash key based on a binding token for HttpDNS node scheduling. Background Technology

[0002] In large-scale internet service scenarios, businesses typically deploy multiple service nodes across multiple regions. Intelligent scheduling is needed to accurately allocate user requests to the optimal node to ensure service response speed and stability. Traditional DNS scheduling relies on the hierarchical resolution mechanism of the Domain Name System, which has three inherent flaws: (1) The scheduling accuracy is insufficient. It can only allocate nodes in a coarse-grained manner based on the number of VIPs and cannot accurately adjust the scheduling strategy weights. (2) It is susceptible to DNS hijacking and cache pollution, which can cause the resolution results to deviate from expectations; (3) The TTL caching mechanism causes scheduling to lag, making it impossible to adapt to node load or network fluctuations in real time, and making it difficult to meet the high availability service requirements.

[0003] To overcome the limitations of traditional DNS and with the booming development of mobile internet, the HttpDNS scheduling scheme has gradually become mainstream. It bypasses the traditional DNS resolution link through the HTTP / HTTPS protocol, allowing clients to directly request the target IP from the HttpDNS server. It boasts advantages such as high scheduling accuracy, strong anti-hijacking capabilities, and good real-time response, effectively solving the core pain points of traditional DNS. However, in the critical stage of node scheduling, existing HttpDNS technology still has several problems that urgently need to be solved, restricting service performance and scalability.

[0004] First, the challenge of balancing TLS session reuse rate and failover speed is prominent. Existing solutions for constructing hash keys have significant drawbacks: using random numbers as keys results in extremely low TLS session reuse rates due to different nodes being mapped each time, significantly increasing server CPU consumption and mobile device power consumption; using client IPs as keys improves reuse rates but lacks domain-level isolation, allowing single-node failures to amplify the impact across domains; using a domain name + client IP as keys achieves domain-level isolation but still relies on server health checks or manual adjustments for failover, preventing client-side participation and leading to delayed recovery. None of these three approaches can balance TLS reuse efficiency with failover flexibility, making them unsuitable for dynamic network environments.

[0005] Secondly, the stateful implementation mechanism on the server side limits the ability to scale horizontally quickly. Some HttpDNS solutions require storing massive amounts of client-node mappings on the server to achieve stable binding between clients and nodes. This not only increases storage costs but also requires complex consistency maintenance mechanisms. When adding a new node, historical mapping data needs to be synchronized, resulting in low scaling efficiency, inability to quickly respond to fluctuations in business traffic, and difficulty in supporting large-scale cluster deployments.

[0006] Furthermore, the client lacks proactive scheduling capabilities. Existing solutions all adopt a "server-side one-way scheduling, client-side passive acceptance" architecture: even if the client detects in real time that the target node connection times out, response latency increases, or network environment changes, it cannot proactively trigger node switching. It can only wait for the server to adjust its strategy or for the local cache to expire, resulting in a decline in service experience. Moreover, when the node status is stable, it cannot proactively extend the mapping validity period to optimize the TLS session reuse effect.

[0007] Furthermore, existing solutions lack stable traffic bucketing capabilities at the HttpDNS layer. Experimental bucketing and version control largely rely on upper-layer business logic or independent experimental systems, making it impossible to guarantee that the same client will continuously hit the same experimental bucket throughout the entire business process at the domain name resolution layer. This results in insufficient A / B test coverage for long-session services, affecting the accuracy of experimental results and the efficiency of strategy iteration.

[0008] In summary, existing HttpDNS technology cannot simultaneously meet the core requirements of high TLS session reuse rate, fast failover, client-initiated scheduling, stateless server-side expansion, and stable traffic bucketing. An innovative solution is urgently needed to break through the above technical bottlenecks and improve the overall performance and adaptability of HttpDNS scheduling. Summary of the Invention

[0009] This invention proposes a method for constructing hash keys based on binding tokens for HttpDNS node scheduling, in order to resolve the contradiction between high TLS session reuse rate and slow failover mentioned in the prior art; the client lacks active scheduling capabilities and can only passively accept the server's scheduling results; the server needs to maintain session state, making horizontal scaling difficult; and the experimental bucketing is unstable and the test coverage is insufficient in long session business processes.

[0010] To achieve the above objectives, the present invention adopts the following technical solution: a method for constructing a hash key based on a binding token for HttpDNS node scheduling, comprising the following steps: HttpDNS resolution request reception: The client sends a domain name resolution request to the HttpDNS edge access node. The request carries the domain name to be resolved (host), the client IP address (client_ip), and an optional binding token (token). The client IP address is compatible with both IPv4 and IPv6, and the domain name supports multi-level subdomain resolution. Binding token verification and generation: The HttpDNS edge access node checks whether the binding token in the request exists and has not expired. During verification, it directly compares the current time with the token's expiration timestamp, without needing to store the token status on the server. If the token does not exist or has expired, a new binding token is generated. The new token contains the expiration time (expire_time) and a 32-bit unsigned integer mapping identifier (mapping_id). If the token is valid, the mapping identifier (mapping_id) in the token is used. Consistent hash key construction: The HttpDNS edge access node performs a string concatenation operation based on the domain name host, client IP address client_ip, and mapping identifier mapping_id. The concatenation result is hashed to generate a consistent hash key. The hash calculation uses the XXHash64 algorithm to ensure high performance and low collision. The concatenation order is fixed as host, client_ip, mapping_id. Domain name resolution and node selection: The HttpDNS edge access node adopts a consistent hashing algorithm to map the constructed hash key to the target node in the candidate business edge node set. The target node must meet the requirements of proximity access and resource redundancy. Finally, the VIP address of the node is returned as the domain name resolution result. Resolution result return: The HttpDNS edge access node returns the resolution result to the client. The resolution result includes the target node's VIP address, binding token, and resolution result TTL value. The TTL value is dynamically configured according to network stability, ranging from 120 seconds to 3600 seconds. The client stores the binding token for reuse in subsequent resolution requests.

[0011] As a further aspect of this invention, the mapping identifier mapping_id is divided into at least four sub-fields: a 4-bit version field version_id, an 8-bit experimental bucket field bucket_id, an 8-bit scheduling disturbance field salt_id, and a 12-bit control flag field flag_id. The version field is used to identify the encoded version of the mapping identifier; the experimental bucket field is used for stable traffic bucketing; the scheduling disturbance field is used to control hash distribution; and the control flag field is used to carry the internal server policy. The sub-fields are combined in order from high to low bits, and the field boundaries are divided by a fixed bit width to ensure that different fields are semantically independent and do not overlap.

[0012] As a further aspect of this invention, a dynamic optimization mechanism for the expiration time of the binding token is also included. The expiration time (expire_time) is adaptively adjusted based on the client's network environment and service type, and the optimization formula is as follows: Where expire_time is the optimized token expiration timestamp. Here, k is the current timestamp, k is the time adjustment coefficient with a value ranging from 120 to 3600, T is the baseline value for the basic validity period, μ(τ) is the joint weighting function of network quality and service type, and τ is the integral variable representing the dynamic influence factor of the time dimension. The optimization measures are executed by the client SDK. The better the network quality, the longer the service session connection. The larger the value of μ(τ), the longer the expiration time. This mechanism can balance the TLS session reuse rate and the flexibility of failover.

[0013] As a further aspect of the present invention, a client-initiated scheduling mechanism is also included. When the client detects that the target node connection times out, fails to respond, or the network environment changes, it actively discards the currently bound token or sets the expire_time in the token to the expiration time and re-initiates a domain name resolution request to obtain a new token. When the target node is detected to be stable and has excellent performance, the expiration time of the token is extended, with the extension not exceeding twice the initial validity period. This mechanism gives the client the initiative in scheduling and breaks through the limitation of traditional one-way scheduling by the server.

[0014] As a further solution of the present invention, the experimental bucket_id field is used to achieve stable bucketing for long sessions. Within the complete business process, as long as the bucket_id in the mapping identifier mapping_id remains unchanged, it can be stably mapped to the expected bucket, ensuring that multiple HttpDNS resolution requests are always mapped to the same experimental version. The bucketing process does not require the server to maintain state information. The end-to-end experimental process integrity is achieved through the bucketing information carried by the token. It supports 256 experimental buckets from 0 to 255, which meets the needs of large-scale A / B testing.

[0015] As a further aspect of this invention, the control flag field `flag_id` contains multiple independent control bits, including at least three server-side internal strategies: canary release, scheduling policy priority, and session optimization. The specific semantics of the control bits can be dynamically configured through the HttpDNS policy center. The control flag bits do not expose their specific meanings to the client and are only used during server-side resolution and log processing. Furthermore, in conjunction with `version_id`, the HttpDNS policy center can modify and publish the specific semantics of the control flag bits in real time, with both new and old versions taking effect simultaneously without requiring modification to the client protocol.

[0016] As a further solution of the present invention, the HttpDNS edge access node supports stateless horizontal scaling. When adding a new node, only the candidate node list, weight configuration and hash algorithm parameters need to be synchronized. There is no need to synchronize historical token data. Any edge access node can independently complete token verification, hash calculation and node mapping. The expansion process does not affect the operation of existing services. It supports dynamic scaling according to business traffic. There is no upper limit to the number of edge access nodes that can be deployed in a single cluster.

[0017] As a further aspect of this invention, a result caching optimization mechanism is also included. When the client caches the resolution result, it stores the binding token and the VIP address together. The cache expiration judgment combines the validity period of the client's local cache with the token expiration timestamp. When the token has not expired but the validity period of the client's local cache has expired, the client can initiate an incremental resolution request with the token. The HttpDNS edge access node only needs to verify the validity of the token and return the domain name resolution information. There is no need to re-execute the hash key construction process, which shortens the resolution time and improves the response speed.

[0018] Compared with existing technologies, this invention addresses the core pain points of existing HttpDNS node scheduling technologies by using an innovative design that involves binding tokens to participate in the construction of a consistent hash key. This achieves breakthroughs in multiple dimensions, including session reuse, fault handling, architecture expansion, scheduling initiative, experimental bucketing, and policy flexibility, significantly improving the overall performance and adaptability of HttpDNS scheduling.

[0019] First, this invention efficiently balances TLS session reuse rate and failover flexibility, significantly reducing resource consumption. It constructs a consistent hash key using domain name + client IP + mapping identifier. When the candidate node set is stable and weight fluctuations are small, the mapping identifier remains unchanged, maintaining a high probability of node stability and thus improving the SessionTicket / ID hit rate of TLS sessions, increasing the reuse rate to 78% compared to the traditional 60%. Simultaneously, the server's CPU consumption is reduced by 20% due to the improved TLS session reuse rate, and the client's power consumption is reduced by 25%-40% due to the reduced TLS handshake. When the target node is abnormal, the client can actively discard the token and re-resolve, completing failover within 3-8 seconds, significantly shortening the failover latency compared to the traditional DNS 60-300 second failover time. Furthermore, the hash key construction process includes a domain name dimension, achieving domain-level isolation and preventing cross-domain impact amplification.

[0020] Secondly, a stateless and easily scalable server architecture was constructed to adapt to large-scale business needs. The binding token comes with an expiration timestamp, and the server can complete the verification by comparing the times, without the need to persistently store historical tokens. When adding a new HttpDNS edge access node, only the candidate node list, weight configuration, and hash algorithm parameters need to be synchronized, without the need to synchronize historical data. Any edge node can independently complete token verification, hash calculation, and node mapping, supporting dynamic elastic scaling based on business traffic. There is no upper limit to the number of edge nodes that can be deployed in a single cluster, completely solving the problems of high storage costs, complex consistency maintenance, and low scalability caused by traditional stateful designs.

[0021] Furthermore, it empowers clients with proactive scheduling capabilities, overcoming the limitations of one-way server-side scheduling. Clients can monitor the target node status and network environment in real time. When a node connection timeout, response failure, or network fluctuation is detected, the client can proactively discard the token or set the expire_time in the token to its expiration time and re-initiate the resolution to obtain a new mapping. If the node status is stable and performance is excellent, the token validity period can be extended, realizing an architectural upgrade from passively accepting scheduling to actively controlling node switching, avoiding a decline in user experience caused by server-side adjustment lag.

[0022] Furthermore, it achieves stable traffic bucketing and flexible policy expansion to support refined business operations. The 8-bit experimental bucket field `bucket_id` in the mapping identifier ensures that the same client is in a fixed bucket within the complete business process. Even if multiple resolution requests are initiated, it can continuously map to the same experimental version, supporting 256 experimental buckets from 0 to 255, meeting the needs of large-scale A / B testing and solving the problem of insufficient experimental coverage for long sessions caused by traditional solutions relying on upper-layer business bucketing. The 12-bit control flag field `flag_id` can carry server-side internal policies such as canary releases and scheduling policy priorities. The semantics are dynamically configured through the HttpDNS policy center, and the version field ensures compatibility between new and old policies without modifying the client protocol, reserving flexible policy expansion space for the server.

[0023] Finally, we optimized parsing efficiency and resource utilization to improve service response speed. The client associates the bound token with the VIP address in the cache. The cache expiration is determined by the token's validity period. If the token has not expired, incremental parsing is initiated. The server does not need to rebuild the hash key; it only needs to verify the token's validity to return the result, significantly reducing parsing time. Attached Figure Description

[0024] Figure 1 This is a schematic block diagram of the method for constructing a hash key based on a binding token for HttpDNS node scheduling proposed in this invention; Figure 2 This is a schematic block diagram of the digital twin sodium-lithium hybrid battery collaborative management system proposed in this invention; Figure 3 A comparison chart of fault prediction and handling efficiency in digital twins; Figure 4 This is a graph showing the impact of the number of topology switching operations on the accuracy of state estimation. Figure 5 This is a comparison chart of system cycle life decay. Detailed Implementation

[0025] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," and "counterclockwise," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0027] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified. Furthermore, the terms "installed," "connected," and "linked" should be interpreted broadly; for example, they may refer to a fixed connection, a detachable connection, or an integral connection; they may refer to a mechanical connection or an electrical connection; they may refer to a direct connection or an indirect connection through an intermediate medium; and they may refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances. The invention will now be described in further detail with reference to the accompanying drawings.

[0028] Reference Figures 1 to 5 A method for constructing a hash key based on a binding token for HttpDNS node scheduling, comprising the following steps: HttpDNS resolution request reception: The client sends a domain name resolution request to the HttpDNS edge access node. The request carries the domain name to be resolved (host), the client IP address (client_ip), and an optional binding token (token). The client IP address is compatible with both IPv4 and IPv6, and the domain name supports multi-level subdomain resolution. Binding token verification and generation: The HttpDNS edge access node checks whether the binding token in the request exists and has not expired. During verification, it directly compares the current time with the token's expiration timestamp, without needing to store the token status on the server. If the token does not exist or has expired, a new binding token is generated. The new token contains the expiration time (expire_time) and a 32-bit unsigned integer mapping identifier (mapping_id). If the token is valid, the mapping identifier (mapping_id) in the token is used. Consistent hash key construction: The HttpDNS edge access node performs a string concatenation operation based on the domain name host, client IP address client_ip, and mapping identifier mapping_id. The concatenation result is hashed to generate a consistent hash key. The hash calculation uses the XXHash64 algorithm to ensure high performance and low collision. The concatenation order is fixed as host, client_ip, mapping_id to ensure uniqueness. Domain name resolution and node selection: The HttpDNS edge access node adopts a consistent hashing algorithm to map the constructed hash key to the target node in the candidate business edge node set. The target node must meet the requirements of proximity access and resource redundancy. Finally, the VIP address of the node is returned as the domain name resolution result. Resolution result return: The HttpDNS edge access node returns the resolution result to the client. The resolution result includes the target node's VIP address, binding token, and resolution result TTL value. The TTL value is dynamically configured according to network stability, ranging from 60 seconds to 600 seconds. The client stores the binding token for reuse in subsequent resolution requests.

[0029] In this invention, the mapping identifier `mapping_id` is divided into at least four subfields: a 4-bit version field `version_id`, an 8-bit experimental bucket field `bucket_id`, an 8-bit scheduling disturbance field `salt_id`, and a 12-bit control flag field `flag_id`. The version field identifies the encoded version of the mapping identifier, the experimental bucket field is used for stable traffic bucketing, the scheduling disturbance field is used to control hash distribution, and the control flag field is used to carry the internal server policy. The subfields are combined in order from high to low bits, and the field boundaries are divided by a fixed bit width to ensure that different fields are semantically independent and do not overlap.

[0030] This invention also includes a dynamic optimization mechanism for the expiration time of the binding token. The expiration time (expire_time) is adaptively adjusted according to the client's network environment and service type. The optimization formula is as follows: Where expire_time is the optimized token expiration timestamp. Here, k is the current timestamp, k is the time adjustment coefficient, ranging from 120 to 3600, T is the baseline value for the basic validity period, which is 300 seconds, μ(τ) is the joint weighting function of network quality and service type, and τ is the integral variable representing the dynamic influence factor of the time dimension. The optimization measures are executed by the client SDK. The better the network quality, the longer the service session connection. The larger the value of μ(τ), the longer the expiration time. This mechanism can balance the TLS session reuse rate and the flexibility of failover.

[0031] This invention also includes a client-initiated scheduling mechanism. When the client detects that the target node connection has timed out, the response has failed, or the network environment has changed, it actively discards the currently bound token or sets the expire_time in the token to the expiration time and re-initiates a domain name resolution request to obtain a new token. When the target node is detected to be stable and perform well, the expiration time of the token is extended, with the extension not exceeding twice the initial validity period. This mechanism gives the client the initiative in scheduling and breaks through the limitation of traditional one-way scheduling by the server.

[0032] In this invention, the experimental bucket_id field is used to achieve stable bucketing for long sessions. Within the complete business process, as long as the bucket_id in the mapping identifier mapping_id remains unchanged, it can stably map to the expected bucket, ensuring that multiple HttpDNS resolution requests always map to the same experimental version. The bucketing process does not require the server to maintain state information. The end-to-end experimental process integrity is achieved through the bucketing information carried by the token. It supports 256 experimental buckets from 0 to 255, meeting the needs of large-scale A / B testing.

[0033] In this invention, the control flag field `flag_id` contains multiple independent control bits, including at least three server-side internal strategies: canary release, scheduling policy priority, and session optimization. The specific semantics of the control bits can be dynamically configured through the HttpDNS policy center. The control flag bits do not expose their specific meanings to the client and are only used during server-side parsing and log processing. Furthermore, in conjunction with `version_id`, the HttpDNS policy center can modify and publish the specific semantics of the control flag bits in real time, with both new and old versions taking effect simultaneously without requiring modification to the client protocol.

[0034] In this invention, the HttpDNS edge access node supports stateless horizontal scaling. When adding a new node, only the candidate node list, weight configuration, and hash algorithm parameters need to be synchronized. There is no need to synchronize historical token data. Any edge access node can independently complete token verification, hash calculation, and node mapping. The scaling process does not affect the operation of existing services. It supports dynamic scaling based on business traffic, and there is no upper limit to the number of edge access nodes that can be deployed in a single cluster.

[0035] This invention also includes a parsing result caching optimization mechanism. When the client caches the parsing result, it stores the binding token and VIP address together. The cache expiration judgment combines the validity period of the client's local cache with the token expiration timestamp. When the token has not expired but the validity period of the client's local cache has expired, the client can initiate an incremental parsing request with the token. The HttpDNS edge access node only needs to verify the validity of the token and return the domain name resolution information. There is no need to re-execute the hash key construction process, which shortens the parsing time and improves the response speed.

[0036] The following two examples further illustrate the specific implementation of this system: Example 1: Basic Process and Dynamic Weight Node Selection Scene setting When a client first accesses the video service domain video.demo.com, it needs to obtain a low-latency edge node through HttpDNS to ensure the stability of video stream transmission.

[0037] Step 1: Receiving HttpDNS resolution requests The client sends a POST request to the nearest HttpDNS edge access node, with the request body carrying complete parameters. The client IP supports IPv4 format. The first request does not include a binding token.

[0038] Step 2: Token Verification and Generation The HttpDNS edge access node detects an empty token, determines it as the first request, and generates a new binding token according to the rules. The token contains an expiration timestamp and a 32-bit mapping identifier, with the following specific fields:

[0039] Step 3: Consistent hash key construction The HttpDNS edge access node concatenates the host, client_ip, and mapping_id in a fixed order and performs hash calculations using the XXHash64 algorithm to ensure high performance and low collision rate. String concatenation: "video.demo.com"+"10.20.30.40"+"0x0A1B2C3D" will result in "video.demo.com10.20.30.400x0A1B2C3D". Hash calculation: The concatenated result is processed by the XXHash64 algorithm to generate a hash value. Example: 0x7E2F1A8B9C3D4E5F, which is the consistent hash key.

[0040] Step 4: Domain Name Resolution The HttpDNS edge access node obtains the VIP address 172.16.1.10 from the candidate service edge node set using a weighted intersection hash based on the hash key calculated in the previous step.

[0041] Step 5: The HttpDNS edge access node returns the resolution result to the client in JSON format, where the TTL is configured to be 300 seconds based on the current network stability. { "host":"video.demo.com", "vip":"172.16.1.10", "token":"1735718400_0x0A1B2C3D", "ttl":300 } The client stores the association between the token and the VIP for reuse in subsequent requests.

[0042] Subsequent request reuse If the client visits video.demo.com again within 300 seconds, it will send a request carrying the stored token. The HttpDNS edge access node verifies that the token has not expired. The verification process only compares the current time with the expire_time in the token, without requiring the server to store any token state. The mapping_id=0x0A1B2C3D is extracted from the token, and the reconstructed hash key is consistent with the first time, still mapping to VIP 172.16.1.10. When the client initiates a TLS connection to 172.16.1.10, it carries the SessionTicket obtained during the initial handshake. After the server verifies the connection, it skips the full handshake, establishing a connection in just 1-RTT, improving access efficiency.

[0043] Example 2: Mapping Identifier Resolution and Client-Driven Scheduling Scene setting The client executes the complete shopping process, including browsing products, adding items to the cart, and making payment. It needs to meet two core requirements: first, maintain the stability of long-term session bucketing during A / B testing; and second, quickly switch over when a node fails. It also needs to parse the subfields of the mapping identifier.

[0044] 1. Parsing the mapping identifier subfield When a client makes its first request, the HttpDNS edge access node generates a 32-bit unsigned integer mapping_id=0x1A2B3C4D, which is then broken down into four sub-fields according to the bit width division rules, as follows:

[0045] Each subfield boundary is isolated by a fixed bit width and is semantically independent. Only the HttpDNS edge access node resolves the flag_id internally. The client does not need to know the meaning of the fields and only stores the complete mapping_id.

[0046] 2. Stable flow bucketing E-commerce platforms conduct A / B testing of their checkout processes, with the following bucketing rules:

[0047] In the client-side shopping process, each HttpDNS resolution carries the same token (mapping_id=0x1A2B3C4D) to ensure that bucket_id=162 always belongs to version B. The resolution results of each business step are as follows:

[0048] Throughout the entire process, the client always uses version B to avoid interruptions in the shopping process due to bucket switching, thus ensuring the accuracy of the experimental data.

[0049] 3. Client-initiated scheduling When the client settles payment, it initiates an HTTPS request to the target node 172.16.2.22. If a connection timeout is detected, the active scheduling mechanism of claim 5 is triggered, and the specific steps are as follows: Fault detection: The client's three consecutive connection attempts all timed out, indicating a node malfunction. Token handling: Actively discard the current token: 1735718400_0x1A2B3C4D to prevent subsequent requests from being mapped to abnormal nodes; Re-resolution: Send a request to the HttpDNS edge access node without carrying a token; New token generation: The HttpDNS edge access node generates a new token with expire_time=1735718400 and mapping_id=0x0D3C2B1A; New node selection: Construct a hash key based on the new mapping_id, and use a weighted intersection hash to obtain VIP=172.16.2.23; Connection Re-establishment: The client initiates a TLS connection to 172.16.2.23, completes the handshake within 1 second, and resumes the settlement process.

[0050] The total time for this failover is as follows:

[0051] By having the client actively discard tokens, rapid fault convergence is achieved, overcoming the limitations of traditional one-way scheduling on the server side and improving business continuity.

[0052] Reference Figure 2 This diagram visually illustrates the core advantages of the KEY construction method of this invention. The random number scheme has a reuse rate of only 35% because it maps to different nodes each time; while the pure IP and domain name + IP schemes improve this to 60%-65%, they lack flexible scheduling capabilities. This invention constructs the KEY using "domain name + client IP + mapping_id," achieving domain-level isolation while maintaining stable node placement, with a reuse rate of 78%, an improvement of 18%-23% compared to traditional schemes. This effect stems from the stable mapping characteristics of mapping_id, which reduces repeated TLS handshakes and avoids the impact of partial node failures on overall availability, balancing TLS reuse rate and scheduling flexibility.

[0053] Reference Figure 3 This diagram highlights the rapid failover advantage of the client-initiated scheduling mechanism. Traditional DNS relies on cache expiration or server-side adjustments, resulting in latency of 60-300 seconds, which cannot handle real-time failures. This invention, through the client's proactive discarding of tokens and re-resolution, controls latency to 2.8-8.5 seconds, and only 4.6 seconds in node failure scenarios (consistent with the data in the example). This breakthrough stems from the stateless verification characteristic of tokens; the client does not need to wait for server instructions and proactively triggers the switch, significantly shortening service interruption time and adapting to scenarios with high continuity requirements, such as video and e-commerce.

[0054] Reference Figure 4 This diagram demonstrates the core advantages of stateless scaling. Traditional stateful solutions require synchronizing massive amounts of historical tokens and mapping relationships, resulting in a performance penalty of 92% when the number of nodes increases to 200 (the database becomes the performance bottleneck), making large-scale scaling impossible. This invention eliminates the need for the server to store token states; adding new nodes only synchronizes the candidate node list and weight configuration, keeping the performance penalty consistently below 11% (the performance cost of multi-node load balancing). This feature supports dynamic scaling of business traffic, allowing for unlimited deployment of edge nodes in a single cluster, perfectly adapting to large-scale HttpDNS service scenarios and solving the pain point of low scaling efficiency in traditional solutions.

[0055] Reference Figure 5 This diagram illustrates the advantages of stable bucketing for long sessions, aligning with the requirements of the e-commerce shopping process in this embodiment. Traditional solutions rely on upper-layer business bucketing, where the hit rate gradually decreases to 70% in long sessions, impacting the accuracy of A / B testing. This invention, through the 8-bit bucket_id field in mapping_id, ensures that the same client maintains a fixed bucketing throughout the entire business process, achieving a 100% hit rate. This design eliminates the need for server-side state information maintenance, achieving end-to-end stable bucketing through bucketing information inherent in the token. It supports 256 experimental buckets (0-255), meeting the needs of large-scale, refined A / B testing.

[0056] In summary, this invention, through a complete process of data preparation, smooth version configuration, macro-level solution, and online execution of micro-level solution, incorporates the formula calculations and technical features described in the claims, systematically solving the engineering challenges of linear programming in CDN scheduling. It achieves the technical effects of second-level response, high-precision execution, and low-cost operation in CDN networks of different sizes, and has broad application value.

[0057] The above are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for constructing a hash key based on a binding token for HttpDNS node scheduling, characterized in that, Includes the following steps: HttpDNS resolution request reception: The client sends a domain name resolution request to the HttpDNS edge access node, carrying the domain name to be resolved (host), the client IP address (client_ip), and the binding token (token). Binding token verification and generation: The HttpDNS edge access node checks whether the binding token in the request exists and has not expired. During verification, the current time is directly compared with the token expiration timestamp, without the need to store the token status on the server. If the token does not exist or has expired, a new binding token will be generated. If the token is valid, continue using the mapping identifier (mapping_id) in the token. The mapping identifier mapping_id is divided into at least four subfields: version field for identifying the encoding version of the mapping identifier, experimental bucket field for fixed traffic bucketing, scheduling disturbance field for controlling hash distribution, and control flag field for carrying the internal server policy. The subfields are combined in order from high bit to low bit, and the field boundaries are defined by a fixed bit width. Consistent hash key construction: The HttpDNS edge access node performs a string concatenation operation based on the domain name host, client IP address client_ip, and mapping identifier mapping_id. The concatenation result is hashed to generate a consistent hash key. The hash calculation uses the XXHash64 algorithm to ensure high performance and low collision. The concatenation order is fixed as host, client_ip, mapping_id. Domain name resolution and node selection: The HttpDNS edge access node adopts a consistent hashing algorithm to map the constructed hash key to the target node in the candidate business edge node set. The target node must meet the requirements of proximity access and resource redundancy. Finally, the VIP address of the node is returned as the domain name resolution result. Resolution result return: The HttpDNS edge access node returns the resolution result to the client. The resolution result includes the target node's VIP address, binding token, and resolution result TTL value. The TTL value is dynamically configured according to network stability. The client stores the binding token for reuse in subsequent resolution requests.

2. The method for constructing a hash key based on a binding token for HttpDNS node scheduling according to claim 1, characterized in that, It also includes a dynamic optimization mechanism for the expiration time of the binding token. The expiration time (expire_time) is adaptively adjusted based on the client's network environment and business type. The optimization formula is as follows: Where expire_time is the optimized token expiration timestamp. The current timestamp is given, k is the time adjustment coefficient with a value ranging from 120 to 3600, T is the baseline value for the basic validity period, μ(τ) is the joint weighting function of network quality and service type, and τ is the integral variable representing the dynamic influence factor of the time dimension. The optimization measures are executed by the client SDK.

3. The method for constructing a hash key based on a binding token for HttpDNS node scheduling according to claim 1, characterized in that, It also includes a client-initiated scheduling mechanism. When the client detects that the target node connection has timed out, the response has failed, or the network environment has changed, it will actively discard the currently bound token or set the expire_time in the token to the expiration time and re-initiate the domain name resolution request to obtain a new token. When the target node is detected to be in a stable state and with excellent performance, the token expiration time is extended, but the extension shall not exceed twice the initial validity period.

4. The method for constructing a hash key based on a binding token for HttpDNS node scheduling according to claim 1, characterized in that, The bucket_id field in the experiment bucket is used to achieve stable bucketing for long sessions. Within the complete business process, as long as the bucket_id of the same client remains unchanged, it will be stably mapped to the expected bucket, and the bucketing process does not require the server to store and maintain state information.

5. The method for constructing a hash key based on a binding token for HttpDNS node scheduling according to claim 1, characterized in that, The control flag field `flag_id` contains multiple independent control bits, including at least three server-side internal policies: canary release, scheduling policy priority, and session optimization. The specific semantics of the control bits are dynamically configured through the HttpDNS policy center. The control flag bits do not expose their specific meanings to the client and are only used during server-side resolution and log processing. Furthermore, in conjunction with `version_id`, the HttpDNS policy center can modify and publish the specific semantics of the control flag bits in real time, with both new and old versions taking effect simultaneously without requiring modifications to the client protocol.

6. The method for constructing a hash key based on a binding token for HttpDNS node scheduling according to claim 1, characterized in that, HttpDNS edge access nodes support stateless horizontal scaling. When adding a new node, only the candidate node list, weight configuration, and hash algorithm parameters need to be synchronized. There is no need to synchronize historical token data. Each edge access node can independently complete token verification, hash calculation, and node mapping. The scaling process does not affect the operation of existing services.

7. The method for constructing a hash key based on a binding token for HttpDNS node scheduling according to claim 1, characterized in that, It also includes a parsing result caching optimization mechanism. When the client caches the parsing result, it will bind the token and store it together with the VIP address. The cache invalidation judgment combines the effective duration of the client's local cache and the token's expiration timestamp. When the token has not expired but the client's local cache validity period has expired, the client initiates an incremental resolution request with the token. The HttpDNS edge access node only needs to verify the validity of the token and return the domain name resolution information. There is no need to re-execute the hash key construction process, which shortens the resolution time and improves the response speed.

Images