A CDN node scheduling method and system based on HTTPDNS to prevent hijacking

Abstract

This invention relates to the field of digital information transmission technology and discloses a CDN node scheduling method and system based on HTTPDNS to prevent hijacking. The method includes sending a scheduling request to an HTTPDNS server and receiving an initial CDN node IP list returned by the server; calculating an initial ranking score for each node IP based on geographical location matching degree, ISP topology proximity, and historical performance scores, and dividing the node IP list into a priority probe set and a candidate probe set; performing joint probes on nodes in the priority probe set and network round-trip time probes on the candidate probe set; calculating the real-time service quality index of each node based on the probe results, and weighting the initial ranking score and penalty score to calculate the scheduling score; generating a connection quality snapshot for the optimal node in this scheduling and updating the network quality summary; setting a cooldown period if connecting to the scheduled node fails; and performing local round-robin scheduling if scheduling requests fail consecutively. The scheduling decision of this invention has a more efficient candidate node detection mechanism.

Description

Technical Field

[0001] This invention relates to the field of digital information transmission technology, specifically to an anti-hijacking CDN node scheduling method and system based on HTTPDNS. Background Technology

[0002] Content Delivery Networks (CDNs) distribute content from origin servers to the nodes closest to users by deploying edge node servers globally, thereby reducing network congestion, improving user access response speed, and service availability. The core task of CDN node scheduling is to select the node with the best overall service quality for user requests.

[0003] Traditional CDN scheduling relies on intelligent DNS systems, which determine a user's approximate geographical location and ISP based on the IP address of their LocalDNS server and return the nearest CDN node IP. However, this approach has significant drawbacks: firstly, DNS resolution results are easily maliciously tampered with, potentially redirecting user traffic to malicious servers, causing security risks and a decline in access quality; secondly, the IP address of the LocalDNS often fails to accurately reflect the user's outgoing network information, easily leading to suboptimal scheduling across regions and ISPs.

[0004] As an improvement, HTTPDNS allows clients to send rich device and network information directly to the HTTPDNS server to obtain a list of IP addresses. However, existing HTTPDNS practices still have the following shortcomings: scheduling decisions are mostly based on static geographical location, ISP information, or single real-time network latency, failing to fully consider the actual service capabilities of nodes. The probing mechanism for candidate nodes is inefficient; full probing introduces unnecessary overhead and scheduling latency, while insufficient probing fails to accurately assess the real-time status of nodes. Furthermore, there is a general lack of utilization of historical connection quality data and adaptability to network fluctuations. When selected nodes experience momentary failures or performance degradation, there is a lack of failure penalties and rapid recovery mechanisms. Moreover, the disaster recovery and degradation schemes adopted when the HTTPDNS service itself is unavailable are relatively simple. Summary of the Invention

[0005] This invention provides an anti-hijacking CDN node scheduling method and system based on HTTPDNS to solve the problem that the scheduling decision-making detection mechanism for candidate nodes is not efficient enough in the prior art.

[0006] In a first aspect, the anti-hijacking CDN node scheduling method based on HTTPDNS of the present invention includes the following steps:

[0007] The client sends a scheduling request to the HTTPDNS server, carrying the client's geographical location, ISP information, terminal type, and a network quality summary generated from historical connection data. It also receives an initial CDN node IP list returned by the server. Based on the geographical location matching degree between each node IP and the client, ISP topology proximity, and by integrating the historical performance score represented by the network quality summary, an initial ranking score is calculated for each node IP. The node IP list is divided into a priority probe set and a candidate probe set according to the initial ranking score. For nodes in the priority probe set, a joint probe including network round-trip time, TCP connection establishment time, and first byte download time is performed in parallel. The candidate probe set performs network round-trip time probing; based on the probe results, the real-time service quality index of each node is calculated, and a scheduling score is calculated by combining the normalized initial ranking score and the penalty score for network jitter and connection time deviation calculated based on historical connection data; a connection quality snapshot containing the mean and variance of network round-trip time is generated for the optimal node in this scheduling, and the network quality summary is updated; if the connection scheduling node fails, a cooldown period is set according to the failure type and the network round-trip time variance in the node's historical connection data; if scheduling requests to the HTTPDNS server fail continuously, the system is downgraded to the built-in authoritative static IP list for local round-robin scheduling.

[0008] Preferably, the initial ranking score for each node IP is calculated based on the geographical location matching degree between each node IP and the client, the ISP topology proximity, and the historical performance score represented by the network quality summary, including:

[0009] The initial sorting score is calculated using the following formula. The calculation formula is:

[0010] ;

[0011] in, The geographic location matching degree is inversely proportional to the geographic distance between the client and the node; For ISP topology proximity, if the client and node belong to the same ISP, then... =1, otherwise This is the preset lower value; The historical performance score is inversely proportional to the exponentially weighted moving average round-trip time in the network quality summary. The preset weighting coefficients are summed to 1.

[0012] Preferably, the step of dividing the node IP list into a priority probe set and a candidate probe set based on the initial sorting score includes:

[0013] Sort all node IPs returned by the HTTPDNS server in descending order according to the initial sorting score, take the top N nodes to form the priority probe set, and the remaining nodes to form the candidate probe set, where N is a preset integer.

[0014] Preferably, the parallel joint probing of nodes within the priority probe set, including network round-trip time, TCP connection establishment time, and first byte download time, includes:

[0015] The client concurrently initiates lightweight HTTP probe requests to each node IP in the priority probe set; by measuring key time points in the HTTP interaction process, the network round-trip time, TCP connection establishment time, and first byte download time are obtained. Among them, the network round-trip time is the time from sending the SYN packet to receiving the SYN / ACK packet during the TCP three-way handshake, the TCP connection establishment time is the total time from sending the SYN packet to completing the three-way handshake, and the first byte download time is the time from sending the complete HTTP request to receiving the first byte of the HTTP response.

[0016] Preferably, the step of calculating the real-time service quality index of each node based on the detection results, and combining it with the normalized initial ranking score and the penalty score for network jitter and connection establishment time deviation calculated based on historical connection data, to weight and calculate the scheduling score includes:

[0017] Scheduling of nodes within the priority detection set Calculated using the following formula:

[0018] ;

[0019] in, It is a real-time service quality indicator calculated and normalized based on network round-trip time, TCP connection establishment time, and first byte download time; The initial sorted score after normalization; The penalty score is calculated and normalized based on the deviation of network jitter and the TCP connection establishment time of this probe from the historical average. These are preset weighting coefficients;

[0020] The scheduling score of nodes in the candidate probe set is calculated based on the network round-trip time and initial sorting score obtained from the probe.

[0021] Preferably, the step of generating a connection quality snapshot containing the mean and variance of the network round-trip time for the optimal node in this scheduling, and updating the network quality summary, includes:

[0022] After establishing a service connection with the optimal node, record the network round-trip time of data packets in the session and calculate the average network round-trip time. With variance Simultaneously record the TCP connection establishment time for this connection. Generate a snapshot of the connection quality;

[0023] The network quality summary of the optimal node is updated using an exponentially weighted moving average algorithm, and the update formula is as follows:

[0024] ;

[0025] ;

[0026] ;

[0027] in, As a smoothing factor, The updated historical index-weighted moving average round-trip time. The weighted moving average round-trip time of the historical index before the update. The updated historical index-weighted moving average variance. The historical index-weighted moving average variance before the update. The updated historical index-weighted moving average TCP connection establishment time. The TCP connection establishment time is a historical index-weighted moving average before the update.

[0028] Preferably, the step of setting a cooling-off period based on the failure type and the network round-trip time variance in the node's historical connection data includes:

[0029] If the connection failure type is TCP connection timeout, then the node's cooldown period... Calculated using the following formula: ;

[0030] in, The standard deviation of historical network round-trip times. The base cooling time, where k is a scaling factor;

[0031] If the connection failure type is a server error, a fixed cooling-off period is set; during the cooling-off period, the node is temporarily ignored in subsequent scheduling.

[0032] Preferably, the step of downgrading to a built-in list of authoritative static IPs for local round-robin scheduling includes:

[0033] The client has a built-in request failure counter. When the number of consecutive failed scheduling requests to the HTTPDNS server reaches a preset threshold, a degradation strategy is triggered. The degradation strategy will suspend sending requests to the HTTPDNS server for a preset period of time and enable a list of authoritative static IPs built into the client. Starting from the first position in the list of authoritative static IPs, the client will attempt to connect sequentially until a connection is successfully established with a node.

[0034] Preferably, the geographical location is the latitude and longitude obtained through the positioning module.

[0035] Secondly, the anti-hijacking CDN node scheduling system based on HTTPDNS of the present invention includes a memory and a processor. The memory stores computer instructions, and when the processor executes the computer instructions, it implements the above-mentioned anti-hijacking CDN node scheduling method based on HTTPDNS.

[0036] The beneficial effects of this invention are as follows: This invention constructs a node performance evaluation model by integrating client geographic location, ISP information, historical connection quality summaries, and multi-dimensional real-time detection data. A layered detection strategy is adopted, performing network quality detection at different depths on the preferred node set and candidate node set, reducing the overhead and time latency of the scheduling process. Furthermore, by using network jitter and connection establishment time deviation based on historical data as penalty scores, the long-term service stability of nodes can be evaluated, avoiding the selection of nodes with excellent instantaneous performance but poor connection quality. When the optimal node connection fails, an avoidance period is set based on historical performance; when the HTTPDNS service is unavailable, scheduling is downgraded to a locally built-in list. These two fault-tolerance mechanisms enhance the high availability of the service. Attached Figure Description

[0037] Figure 1 This is a flowchart illustrating the anti-hijacking CDN node scheduling method based on HTTPDNS provided in an embodiment of the present invention. Detailed Implementation

[0038] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.

[0039] like Figure 1 As shown, an embodiment of the anti-hijacking CDN node scheduling method based on HTTPDNS provided by the present invention includes the following steps:

[0040] S1, the client sends a scheduling request to the HTTPDNS server. The scheduling request carries the client's geographical location, ISP information, terminal type, and network quality summary generated from historical connection data. The client also receives an initial CDN node IP list returned by the server. Based on the geographical location matching degree between each node IP and the client, the ISP topology proximity, and the historical performance score represented by the network quality summary, an initial ranking score is calculated for each node IP.

[0041] Specifically, the client obtains latitude and longitude as geographic location information through its built-in positioning module, retrieves Internet Service Provider (ISP) information by querying network interface information, and determines the terminal type by reading operating system information. The network quality summary is structured data that records the CDN node IPs the client has historically connected to, along with the corresponding mean and variance of network round-trip times. The client encapsulates this information in an HTTP GET or POST request and sends it to the specified HTTPDNS server. Upon receiving the request, the server, based on the client's geographic location and ISP information, selects a group of geographically and topologically adjacent nodes from the global node resource pool, forming an initial CDN node IP list, which is then returned to the client.

[0042] After receiving the initial CDN node IP list, the client calculates the spherical distance between each node IP and its own latitude and longitude. The reciprocal of this spherical distance is used as the geographic location matching score. The ISP to which the node IP belongs is compared with the client's ISP. If they are the same ISP, the ISP topology proximity is highest; if they are different ISPs with peering relationships, the score is next highest; otherwise, the score is lowest. The client checks the network quality summary for historical connection records for the node IP. If found, a historical performance score is calculated based on the historical network round-trip time mean and variance. The shorter and more stable the historical performance time, the higher the score. The geographic location matching score, ISP topology proximity, and historical performance score are combined using a weighted summation method to obtain the initial ranking score for the node IP.

[0043] In an optional embodiment, the initial ranking score for each node IP is calculated based on the geographic location matching degree between each node IP and the client, the ISP topology proximity, and the historical performance score represented by the network quality summary, including:

[0044] The initial sorting score is calculated using the following formula. The calculation formula is:

[0045] ;

[0046] in, The geographic location matching degree is inversely proportional to the geographic distance between the client and the node; For ISP topology proximity, if the client and node belong to the same ISP, then... =1, otherwise This is the preset lower value; The historical performance score is inversely proportional to the exponentially weighted moving average round-trip time in the network quality summary. The preset weighting coefficients are summed to 1.

[0047] For example, suppose a China Unicom user client located in region "xx" initiates a request. HTTPDNS returns the IPs of three nodes: Node A (located in region "xx", operator "China Unicom", historical average round-trip time 20ms); Node B (located in region "yy", operator "China Telecom", historical average round-trip time 80ms); and Node C (located in region "xx", operator "China Mobile", historical average round-trip time 30ms). Calculate the IP addresses of each node. , and First, calculate the values ​​of each node. Since nodes A and C are both in the "xx" region, nodes A and C... The value is relatively high, such as 0.9; because node B is in the "yy" region, which is in a different region from the user client that initiated the request, node B's... Lower, such as 0.5. Then calculate. Node A and the user client that initiated the request are both connected, so node A's The value is 1. Nodes B and C belong to different operators than the user client that initiated the request, so the values ​​of nodes B and C are 1. Set a lower preset value, such as 0.3. Then calculate... , It is inversely proportional to the historical round-trip time, therefore node A's The highest, such as 0.8, is node C. Secondly, for example, 0.7, node B's Minimum, such as 0.2. Assume... It is 0.5. It is 0.3. It is 0.2. (Passed) The initial ranking score for each node is calculated using the given formula. The initial ranking score for node A is 0.91, for node B it is 0.38, and for node C it is 0.68. Therefore, before conducting actual network probing, all available nodes are initially ranked based on static and historical data.

[0048] S2, divide the node IP list into a priority probe set and a candidate probe set according to the initial sorting score; perform joint probes including network round-trip time, TCP connection establishment time and first byte download time in parallel on the nodes in the priority probe set, and perform network round-trip time probes on the candidate probe set.

[0049] Specifically, the client sorts all nodes from highest to lowest initial score, selects the top 3 nodes to form a priority probe set, and selects nodes ranked 4th to 8th to form a candidate probe set. Then, the client initiates multiple parallel probe tasks. For each node in the priority probe set, the task performs three probes: measuring the network round-trip time (RTT) by sending an ICMP echo request or a TCP SYN packet; performing a complete TCP three-way handshake and recording the time from sending the first SYN packet to receiving the acknowledgment of the last ACK as the TCP connection establishment time; and sending a small HTTP request on the established TCP connection and recording the time from the request being sent to receiving the first byte of the response body as the first byte download time. For each node in the candidate probe set, the task only performs network round-trip time (RTT) probing.

[0050] In an optional embodiment, dividing the node IP list into a priority probe set and a candidate probe set based on the initial sorting score includes:

[0051] Sort all node IPs returned by the HTTPDNS server in descending order according to the initial sorting score, take the top N nodes to form the priority probe set, and the remaining nodes to form the candidate probe set, where N is a preset integer.

[0052] For example, suppose HTTPDNS returns 10 node IPs with initial ranking scores of: Node A (0.91), Node B (0.38), Node C (0.68), Node D (0.85), Node E (0.72), and five other nodes with lower scores. These 10 node IPs are then strictly sorted from highest to lowest according to their initial ranking scores. The resulting list is: Node A, Node D, Node E, Node C, and so on, with Node B, the lowest-scoring node, placed towards the end of the list. Assuming N = 3, the top three nodes are prioritized. Therefore, Node A (0.91), Node D (0.85), and Node E (0.72) are placed in the priority probe set. The remaining seven nodes are then placed in the candidate probe set. Clients can concentrate their immediate probe resources on a few nodes that are likely to provide high-quality service, thereby improving decision-making efficiency and reducing probe overhead.

[0053] In an optional embodiment, the parallel joint probing of nodes within the priority probe set, including network round-trip time, TCP connection establishment time, and first byte download time, includes:

[0054] The client concurrently initiates lightweight HTTP probe requests to each node IP in the priority probe set; by measuring key time points in the HTTP interaction process, the network round-trip time, TCP connection establishment time, and first byte download time are obtained. Among them, the network round-trip time is the time from sending the SYN packet to receiving the SYN / ACK packet during the TCP three-way handshake, the TCP connection establishment time is the total time from sending the SYN packet to completing the three-way handshake, and the first byte download time is the time from sending the complete HTTP request to receiving the first byte of the HTTP response.

[0055] Specifically, the priority probe set has been determined to include nodes A, D, and E. The client concurrently sends small HTTP probe requests to the IP addresses of these three nodes, for example, requesting a health check file of only 1 byte in size. Concurrent execution ensures that the total time to obtain the real-time network status of all priority nodes is approximately equal to the probe time of the slowest node, rather than the sum of the probe times of all nodes, thus reducing the waiting time for scheduling decisions. During the probe of node A, the client records the timestamps of various key events at the network protocol stack layer. For example, at time point... At 10:00:00:00:00 AM, a TCP SYN packet was sent; (At 10:00:00:020) Received a SYN / ACK packet from the server; (At 10:00:00:030) the three-way handshake was completed, and the TCP connection was officially established; (10:00:00:035) The entire HTTP request was sent; At 10:00:00:055, the first byte of the HTTP response was received. Based on these timestamps, the client calculates three core metrics: network round-trip time, TCP connection establishment time, and first byte download time. The network round-trip time is... and The difference is 20ms; the TCP connection establishment time is... and The difference is 30ms; the download time for the first byte is... and The difference is 20ms.

[0056] S3. Calculate the real-time service quality index of each node based on the detection results, and combine it with the normalized initial ranking score and the penalty score for network jitter and connection establishment time deviation calculated based on historical connection data to calculate the scheduling score; generate a connection quality snapshot containing the mean and variance of network round-trip time for the optimal node in this scheduling, and update the network quality summary.

[0057] Specifically, the client converts all detected network round-trip times, TCP connection establishment times, and first-byte download times into positive metrics and calculates a real-time service quality metric for each node. Simultaneously, the initial ranking scores of all nodes are linearly normalized to obtain normalized initial ranking scores, ensuring the scores fall between 0 and 1. Then, the network round-trip time variance of each node is retrieved from local historical data as a network jitter penalty score, and the absolute value of the difference between the current TCP connection establishment time and the historical average connection establishment time is calculated as the connection establishment time deviation penalty score.

[0058] In one embodiment, the scheduling score is calculated using the following formula:

[0059] Scheduling score = weight A Real-time service quality index + weight B Normalized initial sorting score - weight C Network jitter penalty score - weight D Connection establishment time deviation penalty score. The node with the highest scheduling score is the optimal node for this scheduling.

[0060] The client records the mean and variance of the network round-trip time measured for the optimal node as a new connection quality snapshot, and uses a moving average algorithm to merge the connection quality snapshot with the locally stored historical data to update the network quality summary of the node.

[0061] In an optional embodiment, the step of calculating the real-time service quality index of each node based on the detection results, and combining it with the normalized initial ranking score and the penalty score for network jitter and connection establishment time deviation calculated based on historical connection data, to weight and calculate the scheduling score includes:

[0062] Scheduling of nodes within the priority detection set Calculated using the following formula:

[0063] ;

[0064] in, It is a real-time service quality indicator calculated and normalized based on network round-trip time, TCP connection establishment time, and first byte download time; The initial sorted score after normalization; The penalty score is calculated and normalized based on the deviation of network jitter and the TCP connection establishment time of this probe from the historical average. These are preset weighting coefficients;

[0065] The scheduling score of nodes in the candidate probe set is calculated based on the network round-trip time and initial sorting score obtained from the probe.

[0066] For example, taking node A in the priority probe set as an example, node A's real-time probe data includes a network round-trip time of 20ms, a TCP connection establishment time of 30ms, and a first-byte download time of 20ms. These three real-time data are then merged into a single real-time service quality indicator. Assuming The value is 0.95. Meanwhile, the initial sorting score of node A, after normalizing to 0.91, yields... The value is 0.98. Then, the penalty score is calculated. Assuming the historical average TCP connection establishment time for node A is 28ms, and the actual measured value is 30ms, there is a deviation. The weights are set to 0.1. The weights α, β, and γ are set to 0.6, 0.3, and 0.1. Based on the scheduling score calculation formula, node A's scheduling score is calculated to be 0.854.

[0067] For a node in the candidate probe set, such as node C, assuming node C was probed and its network round-trip time was measured to be 50ms, the scheduling score of node C is calculated by weighted sum of its network round-trip time and initial sort score.

[0068] In an optional embodiment, generating a connection quality snapshot containing the mean and variance of network round-trip time for the optimal node in this scheduling, and updating the network quality summary, includes:

[0069] After establishing a service connection with the optimal node, record the network round-trip time of data packets in the session and calculate the average network round-trip time. With variance Simultaneously record the TCP connection establishment time for this connection. Generate a snapshot of the connection quality;

[0070] The network quality summary of the optimal node is updated using an exponentially weighted moving average algorithm, and the update formula is as follows:

[0071] ;

[0072] ;

[0073] ;

[0074] in, As a smoothing factor, The updated historical index-weighted moving average round-trip time. The weighted moving average round-trip time of the historical index before the update. The updated historical index-weighted moving average variance. The historical index-weighted moving average variance before the update. The updated historical index-weighted moving average TCP connection establishment time. The TCP connection establishment time is a historical index-weighted moving average before the update.

[0075] For example, after scheduling and scoring, assuming node A is selected as the optimal node with the highest score of 0.854, the client establishes a service connection with node A, for example, to start playing a video. During video playback, the client continuously monitors the round-trip time of network data packets during data transmission. For example, in the first few seconds, five round-trip time data points are collected, at 20ms, 22ms, 19ms, 25ms, and 21ms respectively. Based on this set of real-time data, the client calculates the average round-trip time of this connection. The time was 21.4 ms, and the variance was... The time is 4.24. In addition, the TCP connection establishment time for this connection is... The measured value during the probing phase was 30ms. These three values ​​together constitute this connection quality snapshot. The newly generated connection quality snapshot is used to update the network quality summary stored locally on the client by node A. It is assumed that before the update, node A's historical exponentially weighted moving average round-trip time... The historical exponentially weighted moving average TCP connection establishment time is 20ms. The time is 28ms. Set the smoothing factor. It is 0.2. The value is 0.1. Therefore, the calculated result is... It took 20.28ms. The latency is 28.2ms. Each successful connection generates this feedback and corrects historical data, allowing the network quality summary to dynamically adapt to long-term changes in the network environment.

[0076] S4. If the connection to the scheduling node fails, a cooldown period is set based on the failure type and the network round-trip time variance in the node's historical connection data. If the scheduling request to the HTTPDNS server fails continuously, the system is downgraded to the built-in authoritative static IP list for local round-robin scheduling.

[0077] Specifically, when a client establishes a business connection using the optimal scheduling node, if a TCP connection timeout occurs or an HTTP server error code is received, the connection is considered to have failed. The client sets a base cooldown time based on the failure type; for example, the base time for a TCP connection timeout is longer than that for a server error. The client reads the network round-trip time variance of the node from historical data. The larger the variance, the more unstable the node. The base cooldown time is then multiplied by a coefficient proportional to the variance to obtain the cooldown period. During this period, the node's IP is temporarily blocked. If the client sends scheduling requests to the HTTPDNS server three times consecutively without receiving a response, a degradation mechanism is triggered. The client will stop requesting the HTTPDNS service and instead select IPs sequentially from a pre-configured authoritative static IP list consisting of multiple highly available core CDN node IPs, performing local round-robin scheduling to ensure service continuity.

[0078] In an optional embodiment, setting the cooling-off period based on the failure type and the network round-trip time variance in the node's historical connection data includes:

[0079] If the connection failure type is TCP connection timeout, then the node's cooldown period... Calculated using the following formula: ;

[0080] in, The standard deviation of historical network round-trip times. The base cooling time, where k is a scaling factor;

[0081] If the connection failure type is a server error, a fixed cooling-off period is set; during the cooling-off period, the node is temporarily ignored in subsequent scheduling.

[0082] For example, suppose a TCP connection timeout occurs when a client attempts to connect to node X. This is determined to be a network-level issue. Query the network quality summary of node X to obtain the standard deviation of its historical network round-trip times. If the network quality of node X is stable with minimal jitter, its standard deviation may be only 5ms; conversely, if the network quality of node X fluctuates drastically, its standard deviation may be 50ms. (Base cooling time...) The cooling-off period is calculated as 30.5 seconds for a node X with stable network quality and a scaling factor k of 0.1. For nodes X with drastic network quality fluctuations, the cooling-off period is calculated as 35 seconds. This mechanism implements dynamic penalties; the more unstable a node's network, the longer it will be excluded from the scheduling candidate list after a network failure.

[0083] If a client successfully connects to node Y but receives a 503 error code from the server when requesting business data, this is considered a problem at the server-side application layer, rather than a network link issue. In this case, instead of using dynamic calculation based on network quality, a fixed, predefined cooldown period is set for node Y, for example, a uniform 60 seconds. During the cooldown period, the client will temporarily ignore node Y in all subsequent scheduling requests, thus giving the server sufficient time to recover its service.

[0084] In an optional embodiment, the downgrade to a built-in authoritative static IP list for local round-robin scheduling includes:

[0085] The client has a built-in request failure counter. When the number of consecutive failed scheduling requests to the HTTPDNS server reaches a preset threshold, a degradation strategy is triggered. The degradation strategy will suspend sending requests to the HTTPDNS server for a preset period of time and enable a list of authoritative static IPs built into the client. Starting from the first position in the list of authoritative static IPs, the client will attempt to connect sequentially until a connection is successfully established with a node.

[0086] For example, when a user launches the application, the client requests a list of nodes from the HTTPDNS server. Suppose the first request fails due to poor network conditions or an HTTPDNS server malfunction, and the failure counter in the client increases from 0 to 1. The client makes a second attempt, which also fails, increasing the counter to 2. Assuming a preset threshold of 3 attempts, when the third request fails, the counter reaches 3, triggering a degradation policy. After the degradation policy is triggered, the client stops sending any requests to the HTTPDNS server and starts a 5-minute silent timer. Simultaneously, the client reads a pre-set list of authoritative static IPs from the application package. This list contains several core node IPs with stable and reliable services, such as... , and The client attempts to connect to an IP in the authoritative static IP list. If the connection is successful, this business request will use this node, and the degradation process will complete successfully. If it fails, the client will not retry, but will give up. Instead, try the list The local polling scheduling process will continue until a successful connection is made to one of the IPs in the list, or until all attempts to connect to the IPs in the list have failed. This mechanism ensures that even in the extreme case where the HTTPDNS scheduling service is unavailable, the application still maintains the maximum possible availability of core functions.

[0087] The implementation principle of the anti-hijacking CDN node scheduling method based on HTTPDNS in this invention is as follows: This invention constructs a comprehensive node performance evaluation model by integrating the client's geographical location, ISP information, historical connection quality summaries, and multi-dimensional real-time detection data. This invention employs a layered detection strategy, performing network quality detection at different depths on the preferred node set and the candidate node set, thereby reducing the overhead and time latency of the scheduling process. Furthermore, this invention introduces network jitter and connection establishment time deviation based on historical data as penalty terms to evaluate the long-term service stability of nodes and avoid selecting nodes with excellent instantaneous performance but poor long-term connection quality. Regarding fault tolerance, when the optimal node connection fails, this invention sets a dynamic avoidance period based on its historical performance; and when the HTTPDNS service itself is unavailable, it will degrade to a locally built-in IP list for scheduling. These two fault tolerance mechanisms together enhance the high availability of the service.

[0088] An embodiment of the anti-hijacking CDN node scheduling system based on HTTPDNS provided by the present invention includes a memory and a processor. The memory stores computer instructions, and when the processor executes the computer instructions, it implements the anti-hijacking CDN node scheduling method based on HTTPDNS in the above embodiment.

[0089] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A CDN node scheduling method based on HTTPDNS to prevent hijacking, characterized in that, The process includes the following steps: The client sends a scheduling request to the HTTPDNS server, which carries the client's geographical location, ISP information, terminal type, and network quality summary generated from historical connection data, and receives the initial CDN node IP list returned by the server; Based on the geographical location matching degree between each node IP and the client, the ISP topology proximity, and the historical performance score represented by the network quality summary, an initial ranking score is calculated for each node IP. The node IP list is divided into a priority probe set and a candidate probe set based on the initial sorting score. For nodes in the priority probe set, a joint probe including network round-trip time, TCP connection establishment time and first byte download time is performed in parallel, and network round-trip time probe is performed on the candidate probe set. Based on the detection results, the real-time service quality index of each node is calculated. Combined with the normalized initial ranking score and the penalty score for network jitter and connection establishment time deviation calculated based on historical connection data, a weighted scheduling score is calculated, including the scheduling score of nodes within the priority detection set. Calculated using the following formula: , It is a real-time service quality indicator calculated and normalized based on network round-trip time, TCP connection establishment time, and first byte download time. The initial sorted score after normalization. The penalty score is calculated and normalized based on the deviation of network jitter and the TCP connection establishment time of this probe from the historical average. , , The weighting coefficients are preset; the scheduling score of the nodes in the candidate probe set is calculated based on the network round-trip time and initial sorting score obtained from the probe. Generate a connection quality snapshot containing the mean and variance of network round-trip time for the optimal node in this scheduling, and update the network quality summary; if the connection to the scheduling node fails, set a cooldown period based on the failure type and the network round-trip time variance in the node's historical connection data; if scheduling requests to the HTTPDNS server fail consecutively, downgrade to local round-robin scheduling using the built-in authoritative static IP list.

2. The anti-hijacking CDN node scheduling method based on HTTPDNS according to claim 1, characterized in that, The initial ranking score for each node IP is calculated based on the geographical location matching degree between each node IP and the client, the ISP topology proximity, and the historical performance score represented by the network quality summary, including: The initial sorting score is calculated using the following formula. The calculation formula is: ； in, The geographic location matching degree is inversely proportional to the geographic distance between the client and the node; For ISP topology proximity, if the client and node belong to the same ISP, then... =1, otherwise This is the preset lower value; The historical performance score is inversely proportional to the exponentially weighted moving average round-trip time in the network quality summary. , , The preset weighting coefficients are summed to 1.

3. The anti-hijacking CDN node scheduling method based on HTTPDNS according to claim 1, characterized in that, The process of dividing the node IP list into a priority probe set and a candidate probe set based on the initial sorting score includes: Sort all node IPs returned by the HTTPDNS server in descending order according to the initial sorting score, take the top N nodes to form the priority probe set, and the remaining nodes to form the candidate probe set, where N is a preset integer.

4. The anti-hijacking CDN node scheduling method based on HTTPDNS according to claim 1, characterized in that, The parallel detection of nodes within the priority detection set, including network round-trip time, TCP connection establishment time, and first byte download time, includes: The client concurrently initiates lightweight HTTP probe requests to each node IP in the priority probe set; by measuring key time points in the HTTP interaction process, the network round-trip time, TCP connection establishment time, and first byte download time are obtained. Among them, the network round-trip time is the time from sending the SYN packet to receiving the SYN / ACK packet during the TCP three-way handshake, the TCP connection establishment time is the total time from sending the SYN packet to completing the three-way handshake, and the first byte download time is the time from sending the complete HTTP request to receiving the first byte of the HTTP response.

5. The anti-hijacking CDN node scheduling method based on HTTPDNS according to claim 1, characterized in that, The process of generating a connection quality snapshot containing the mean and variance of the network round-trip time for the optimal node in this scheduling, and updating the network quality summary, includes: After establishing a service connection with the optimal node, record the network round-trip time of data packets in the session and calculate the average network round-trip time. With variance Simultaneously record the TCP connection establishment time for this connection. Generate a snapshot of the connection quality; The network quality summary of the optimal node is updated using an exponentially weighted moving average algorithm, and the update formula is as follows: ； ； ； in, , As a smoothing factor, The updated historical index-weighted moving average round-trip time. The weighted moving average round-trip time of the historical index before the update. The updated historical index-weighted moving average variance. The historical index-weighted moving average variance before the update. The updated historical index-weighted moving average TCP connection establishment time. The TCP connection establishment time is a historical index-weighted moving average before the update.

6. The anti-hijacking CDN node scheduling method based on HTTPDNS according to claim 1, characterized in that, The step of setting a cooldown period based on the failure type and the network round-trip time variance in the node's historical connection data includes: If the connection failure type is TCP connection timeout, then the node's cooldown period... Calculated using the following formula: ; in, The standard deviation of historical network round-trip times. Based on the cooling time, This is the proportionality coefficient; If the connection failure type is a server error, a fixed cooling-off period is set; during the cooling-off period, the node is temporarily ignored in subsequent scheduling.

7. The anti-hijacking CDN node scheduling method based on HTTPDNS according to claim 1, characterized in that, The process of downgrading to a built-in list of authoritative static IPs for local round-robin scheduling includes: The client has a built-in request failure counter. When the number of consecutive failed scheduling requests to the HTTPDNS server reaches a preset threshold, a degradation strategy is triggered. The degradation strategy will suspend sending requests to the HTTPDNS server for a preset period of time and enable a list of authoritative static IPs built into the client. Starting from the first position in the list of authoritative static IPs, the client will attempt to connect sequentially until a connection is successfully established with a node.

8. The anti-hijacking CDN node scheduling method based on HTTPDNS according to claim 1, characterized in that, The geographical location is the latitude and longitude obtained through the positioning module.

9. A CDN node scheduling system based on HTTPDNS to prevent hijacking, characterized in that, It includes a memory and a processor. The memory stores computer instructions. When the processor executes the computer instructions, it implements the anti-hijacking CDN node scheduling method based on HTTPDNS as described in any one of claims 1-8.

Images