A CDN intelligent scheduling method to reduce client request network anomalies

Abstract

The present invention belongs to the field of computer technology, and discloses a CDN intelligent scheduling method for reducing client request network anomalies. The specific steps are as follows: Step 1: Data collection (client reporting) When a network error occurs on the client, the error is reported immediately. When the user cannot connect to the server, the error information will be reported, and after accumulating a certain amount of samples, the server will perform real-time analysis and calculation to analyze the regional distribution of the error type. If the threshold is triggered, it will switch to other cloud service providers to change the user's network situation and reduce the link timeout error rate. If there are too many connection timeout nodes, the client will be notified to remove the DNS node from the local cache to reduce the error probability, thereby solving the network connection timeout problem. It can also distinguish and analyze and exclude weak network users based on factors such as regional distribution and the user's own network type, and optimize the network usage of other users.

Description

Technical Field

[0001] The present invention belongs to the field of computer technology, and in particular relates to a CDN intelligent scheduling method for reducing network anomalies in client requests. Background Art

[0002] In the era of mobile Internet explosion, the frequency of use of mobile apps has replaced that of PCs, and network access initiated by mobile devices is also flooding the entire network.

[0003] Currently, mobile internet requests can encounter numerous network issues. Due to the diverse networks users navigate, HTTP connection establishment and communication can be challenging, including connection timeouts, read / write timeouts, and handshake errors. Cloud service providers often offer CDN services to address these issues. The underlying principle is to ensure local access. However, achieving this principle requires significant technical support. For example, intelligent DNS scheduling is generally effective if it's implemented accurately. However, cloud service providers have limited IDCs and lack nationwide coverage, even down to the city, district, and county levels. Consequently, requests can cross city or even province lines, significantly impacting mobile users' networks. Cloud service users also consider network coverage and may use multiple cloud service providers to maximize nationwide coverage and address network issues. However, different service providers offer varying network strengths and weaknesses in different regions, requiring user-defined service switching to achieve optimal network performance. This requires further improvement. Summary of the Invention

[0004] The purpose of the present invention is to provide a CDN intelligent scheduling method for reducing network anomalies of client requests, so as to solve the problems raised in the above background technology.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a CDN intelligent scheduling method to reduce client request network anomalies, the specific steps are as follows:

[0006] Step 1: Data collection (client reporting)

[0007] When a network error occurs on the client, the error is reported immediately; the server provides a log collection interface;

[0008] Step 2: Data Analysis (Server-side Analysis)

[0009] 1. Collect sufficient samples, archive them at the minute level according to rules, and calculate the error rate of each domain name. If it exceeds the predetermined threshold, try to switch service providers to improve network quality.

[0010] Analyze regional characteristics. If the characteristics are obvious, proactively push the resolved DNS addresses of nearby areas based on the collected client information to improve the current regional network problems.

[0011] Analyze network quality. When domain name features are obvious, the server intelligently pushes the client to switch domain names, which is equivalent to switching cloud service providers.

[0012] When network connection is abnormal or read / write anomalies are frequent, intelligent decision-making will be made. When the threshold is reached, the client of a high-quality domain name (operator) will be pushed for switching.

[0013] Second, a single service will provide multiple domain names, each of which will correspond to a different cloud service provider to ensure that the collected data is comparable;

[0014] Step 3: DNS resolution

[0015] The original DNS resolution will first search the local cache. If it exists, it will be used directly. If not, it will search localDNS. After optimization, the manufacturer's DNS resolution service will be used first. If no resolution is found, it will return to the original path.

[0016] Step 4: Error warning capability

[0017] If the threshold is still exceeded after the automatic policy is corrected, an alert will be issued to prompt manual intervention;

[0018] Manual decision-making to select cloud service providers;

[0019] Step 5: Manual Decision Making

[0020] Dashboard data analysis provides a basis for decision-making.

[0021] Preferably, the interface data dimensions in step one are defined as including basic device information, IP, region, request time, longitude and latitude, error type, domain name, network type, response time, and status code.

[0022] Preferably, the network error occurring in the client in step 1 includes a DNS resolution error, which is an error occurring when performing domain name resolution.

[0023] Preferably, in step 1, when the user initiates a request and fails to connect to the server, an error message is reported and interface data is collected.

[0024] Preferably, if the threshold is triggered in step 2 and a large number of users use the CDN concentrated on the same service provider, then the feature meets the conditions for switching service providers, and the client will be notified to switch to another cloud service provider.

[0025] Preferably, the large-scale failure of the CDN in step 2 causes the server to be inaccessible. At the same time, due to problems such as local DNS cache, when the user's access is resolved to these failed servers, the client will retry the address a limited number of times. After failing to access, the resolved IP address will be added to the temporary blacklist and synchronized to the server to ensure that the server tells the user not to use the IP when pushing the switch.

[0026] Preferably, when the user initiates a request, the cloud service provider in step 2 will call the service to obtain the optimal IP address instead of directly accessing with the domain name. However, due to the cache of the interface itself, a small number of invalid IPs will be generated, resulting in network access errors. At this time, the client will enter the fault handling process, temporarily clear the IP, and add it to the temporary blacklist.

[0027] Preferably, the DNS in step 3 needs to update the cache after the resolution is completed, clear the previously cached domain name resolution result, and re-acquire the latest domain name resolution result.

[0028] Preferably, the data in step five include key indicators such as error rate, response time, and domain name switching frequency.

[0029] The beneficial effects of the present invention are as follows:

[0030] When a user cannot connect to the server, an error message will be reported. After accumulating a certain amount of samples, the server will perform real-time analysis and calculations to analyze the regional distribution of the error type. If the threshold is triggered, it will switch to other cloud service providers to change the user's network situation and reduce the link timeout error rate. If there are too many connection timeout nodes, the client will be notified to remove the DNS node from the local cache to reduce the error rate, thereby solving the network connection timeout problem. It can also analyze and exclude weak network users based on factors such as regional distribution and the user's own network type, and optimize the network usage of other users. If a small number of users cross the network, resulting in slow reading and writing or even timeouts, if obvious distribution characteristics can be extracted, the server will push adjustments based on the network situation of the best cloud service provider at the time, and can enter the fault handling process when there are large-scale CDN failures and DNS cache errors, thereby ensuring the user's network quality. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 This is a schematic diagram of the business process of the present invention;

[0032] Figure 2 Schematic diagram of the request processing process of the present invention;

[0033] Figure 3 Schematic diagram of the DNS resolution process of the present invention. DETAILED DESCRIPTION

[0034] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0035] like Figures 1 to 3 As shown, the embodiment of the present invention provides a CDN intelligent scheduling method to reduce client request network anomalies, and the specific steps are as follows:

[0036] Step 1: Data collection (client reporting)

[0037] When a network error occurs on the client, the error is reported immediately; the server provides a log collection interface;

[0038] Step 2: Data Analysis (Server-side Analysis)

[0039] 1. Collect sufficient samples, archive them at the minute level according to rules, and calculate the error rate of each domain name. If it exceeds the predetermined threshold, try to switch service providers to improve network quality.

[0040] Analyze regional characteristics. If the characteristics are obvious, proactively push the resolved DNS addresses of nearby areas based on the collected client information to improve the current regional network problems.

[0041] Analyze network quality. When domain name features are obvious, the server intelligently pushes the client to switch domain names, which is equivalent to switching cloud service providers.

[0042] When network connection is abnormal or read / write anomalies are frequent, intelligent decision-making will be made. When the threshold is reached, the client of a high-quality domain name (operator) will be pushed for switching.

[0043] Second, a single service will provide multiple domain names, each of which will correspond to a different cloud service provider to ensure that the collected data is comparable;

[0044] Step 3: DNS resolution

[0045] The original DNS resolution will first search the local cache. If it exists, it will be used directly. If not, it will search localDNS. After optimization, the manufacturer's DNS resolution service will be used first. If no resolution is found, it will return to the original path.

[0046] Step 4: Error warning capability

[0047] If the threshold is still exceeded after the automatic policy is corrected, an alert will be issued to prompt manual intervention;

[0048] Manual decision-making to select cloud service providers;

[0049] Step 5: Manual Decision Making

[0050] Dashboard data analysis provides a basis for decision-making.

[0051] By collecting data on clients that have network errors, we can automatically switch service providers based on the network error rate to ensure that users have good network quality. When the client network connection is abnormal or there are many read and write anomalies, after the threshold is triggered, the client will be automatically provided with a high-quality domain name to ensure the user's network quality. When the requirements cannot be met after the policy is revised, an early warning will be triggered and manual intervention will be allowed to select a cloud service provider to ensure the stability and reliability of the service.

[0052] The interface data dimensions in step 1 are defined as including basic device information, IP, region, request time, latitude and longitude, error type, domain name, network type, response time, and status code.

[0053] By collecting data from all aspects, we can more accurately calculate the error rate of each domain name.

[0054] The network error occurring on the client in step 1 includes a DNS resolution error, which is an error occurring during domain name resolution.

[0055] DNS resolution errors are caused by DNS server failures, domain name resolution errors, and other situations.

[0056] Among them, in step 1, when the user initiates a request and cannot connect to the server, an error message will be reported and the interface data will be collected at the same time.

[0057] By collecting interface data, it is possible to automatically switch between multiple cloud service providers to improve the network quality of mobile phone users' APP requests.

[0058] If the threshold is triggered in step 2 and a large number of users use the same CDN service provider, then the feature meets the conditions for switching service providers, and the client will be notified to switch to another cloud service provider.

[0059] By notifying the client to switch to other cloud service providers, the user's network situation can be changed to reduce the link timeout error rate.

[0060] In step 2, a large-scale CDN failure causes the server to be inaccessible. At the same time, due to problems such as local DNS cache, when user access is resolved to these failed servers, the client will retry the address a limited number of times. If it fails to access, the resolved IP address will be added to the temporary blacklist and synchronized to the server to ensure that the server will tell the user not to use the IP when pushing the switch.

[0061] The client will retry the blacklist every 5 minutes. If it recovers, it will be removed from the blacklist to ensure that the IP is valid.

[0062] In step 2, when the user initiates a request, the cloud service provider will call the service to obtain the optimal IP address instead of directly accessing it using the domain name. However, due to the cache of the interface itself, a small number of invalid IP addresses will be generated, resulting in network access errors. At this time, the client will enter the fault handling process, temporarily clear the IP address, and add it to the temporary blacklist.

[0063] After being included in the temporary blacklist, the client will periodically retry to remove it, to maximize the guarantee that users are using valid resolution results.

[0064] Among them, in step 3, after the DNS resolution is completed, it needs to update the cache, clear the previously cached domain name resolution results, and re-obtain the latest domain name resolution results.

[0065] By giving priority to the manufacturer's DNS resolution service, the advantage is that the accuracy and timeliness of the resolution are guaranteed with a high probability, allowing users to obtain the optimal access path.

[0066] Among them, the data in step five includes key indicators such as error rate, response time, and domain name switching frequency.

[0067] By analyzing the data, we can provide rich basis for decision-making and provide data support for future scheduling strategy optimization.

[0068] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus.

[0069] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. A CDN intelligent scheduling method for reducing client request network anomalies, characterized by: The specific steps are as follows: Step 1: Data Collection When a network error occurs on the client, the error is reported immediately; The server provides a log collection interface; Step 2: Data Analysis The server collects enough samples, archives them minute by minute according to the rules, and calculates the error rate for each domain name. If it exceeds the predetermined threshold, it attempts to switch service providers to improve network quality. Analyze regional characteristics. If regional characteristics do not meet the requirements, proactively push the resolved DNS addresses of nearby areas based on the collected client information to improve the current regional network problems. Analyze network quality. If a large number of CDN users are concentrated on the same cloud service provider, the domain name characteristics meet the conditions for switching service providers, and the client will be notified to switch to another cloud service provider. When network connection is abnormal or read / write anomalies are frequent, intelligent decision-making will be made. When the threshold is reached, high-quality domain names will be pushed to the client for switching. A single service will provide multiple domain names, each corresponding to a different cloud service provider, to ensure that the collected data is comparable; Step 3: DNS resolution The original DNS resolution will first search the local cache. If it exists, it will be used directly. If not, it will search localDNS. After optimization, the manufacturer's DNS resolution service will be used first. If no resolution is found, it will return to the original path. Step 4: Error warning capability If the threshold is still exceeded after the automatic policy is corrected, an alert will be issued to prompt manual intervention; Manual decision-making to select cloud service providers; Step 5: Manual Decision Making Analyze dashboard data and provide a basis for decision making.

2. The CDN intelligent scheduling method for reducing client request network anomalies according to claim 1, characterized in that: The interface data dimensions described in step 1 are defined as including basic device information, IP, region, request time, latitude and longitude, error type, domain name, network type, response time, and status code.

3. The CDN intelligent scheduling method for reducing client request network anomalies according to claim 1, characterized in that: The client network error described in step 1 includes a DNS resolution error, which is an error that occurs during domain name resolution.

4. The CDN intelligent scheduling method for reducing client request network anomalies according to claim 1, characterized in that: In step 1, when the client initiates a request and fails to connect to the server, an error message will be reported and interface data will be collected.

5. The CDN intelligent scheduling method for reducing client request network anomalies according to claim 1, characterized in that: The large-scale CDN failure described in step 2 makes the server inaccessible. At the same time, due to local DNS cache problems, when user access is resolved to these failed servers, the client will retry the address a limited number of times. If it fails to access, the resolved IP address will be added to the temporary blacklist and synchronized to the server to ensure that the server will tell the user not to use the IP when pushing the switch.

6. The CDN intelligent scheduling method for reducing client request network anomalies according to claim 1, characterized in that: When a user initiates a request as described in step 2, the cloud service provider will call the service to obtain the optimal IP address instead of directly accessing it using the domain name. However, due to the cache in the interface itself, a small number of invalid IP addresses will be generated, resulting in network access errors. At this time, the client will enter the fault handling process, temporarily remove the IP address, and add it to the temporary blacklist.

7. The CDN intelligent scheduling method for reducing client request network anomalies according to claim 1, characterized in that: After the DNS resolution is completed in step 3, the cache needs to be updated, the previously cached domain name resolution results need to be cleared, and the latest domain name resolution results need to be obtained again.

8. The CDN intelligent scheduling method for reducing client request network anomalies according to claim 1, characterized in that: The dashboard data described in step 5 includes key indicators such as error rate, response time, and domain name switching frequency.

Images