Data access methods and computer program products

Abstract

This application discloses a data access method and computer program product, relating to the field of content delivery network technology. It solves the scheduling failure problem caused by browser redirection after a 302 redirect in traditional 302 scheduling, which achieves effective scheduling of each data access request from the client. The method involves the DNS server performing two domain name resolutions for the same domain name before obtaining the resource access address, effectively preventing the malicious interception and reuse of edge node addresses, thus enhancing security. Furthermore, the method eliminates the need for the central node and edge servers to provide independent domain names, reducing the complexity of domain name management and ensuring high security and flexibility in data access.

Description

Technical Field

[0001] This disclosure generally relates to the field of content delivery network technology, and more particularly to a data access method and a computer program product. Background Technology

[0002] To provide better service, Content Delivery Networks (CDNs) typically rely on the combined efforts of 302 redirects and Domain Name System (DNS) resolution technologies to improve service quality and make efficient use of resources.

[0003] However, when using 302 redirect scheduling, the scheduling center responds to the client's first request by returning a redirect response containing the target edge server's domain name or address. After the client receives this redirect response and completes the redirect, it will use the target edge server's domain name or address as the default request address for subsequent related access requests, and will no longer be re-scheduled by the scheduling center. This causes some clients to fail to handle the redirect response automatically, resulting in scheduling failure. The edge server address exposed in the redirect response is easily reused maliciously. Furthermore, the above scheduling method requires the scheduling center and each edge server to configure independent domain names, which increases the complexity of domain name management. Summary of the Invention

[0004] In view of the aforementioned defects or deficiencies in the existing technology, it is desirable to provide a data access method and computer program product. This method, through the initial DNS server domain name resolution returning the central node address, the client requesting scheduling from the central node, the central node sending edge server information to the DNS server and then returning a redirect response to the client, and the DNS server performing a secondary domain name resolution returning the resource access address, solves the scheduling failure problem caused by subsequent requests no longer passing through the scheduling center after a browser redirect in traditional 302 scheduling. This achieves effective scheduling of each data access request from the client. The edge server obtains the resource access address only after performing two domain name resolutions for the same domain name, effectively preventing the malicious interception and reuse of edge node addresses, thus enhancing security. The central node and edge servers do not need to provide independent domain names externally, reducing the complexity of domain name management, and providing high security and flexibility for data access.

[0005] Firstly, this application provides a data access method applied to a content delivery network system, which includes a central node, multiple edge service nodes, and address resolution nodes. The method includes: In response to a domain name resolution request sent by a client, the address resolution node determines the central node address that matches the service domain name in the domain name resolution request and sends the central node address to the client. The client addresses the central node based on the central node address and sends an edge node address scheduling request to the central node; the central node responds to the edge node address scheduling request, determines the target edge service node that is compatible with the client, and sends the edge service node information of the target edge service node to the address resolution node; The address resolution node receives the edge service node information, and upon successfully receiving the edge service node information, sends a successful information reception response to the central node; the central node, based on the successful information reception response, sends a redirection response to the client. Based on the redirection response, the client sends the domain name resolution request to the address resolution node, obtains the resource access address corresponding to the service domain name returned by the address resolution node, and sends a business data access request to the target edge service node based on the resource access address.

[0006] In conjunction with the first aspect, in one possible implementation, determining the target edge service node adapted to the client includes: The central node determines the available edge service nodes at the current moment from the plurality of edge service nodes; If multiple available edge service nodes are identified, a selection score is determined for each available edge service node, and the target edge service node corresponding to the highest selection score is selected. The selection score represents the access priority of the corresponding available edge service node to the client. If the available edge service node is not determined, the current time is delayed by a preset time to obtain a new current time, and the process returns to the step of determining the available edge service node at the current time. If the available edge service node is not determined during re-execution, then one edge service node is randomly selected from the plurality of edge service nodes as the target edge service node.

[0007] In conjunction with the first aspect, in one possible implementation, determining the selection score for each of the available edge service nodes includes: Based on the matching results between the region to which the client belongs and the region to which the available edge service node belongs, and the matching results between the region to which the client belongs and the operator to which the available edge service node belongs, the region matching score of the available edge service node is determined; The load score of the available edge service nodes is determined based on the remaining usage count and maximum usage count of the available edge service nodes; The selection score of the available edge service node is determined based on the region matching score of the available edge service node, the load score of the available edge service node, and the weight of each score.

[0008] In conjunction with the first aspect, in one possible implementation, obtaining the resource access address corresponding to the service domain name returned by the address resolution node includes: The address resolution node responds to the domain name resolution request by querying the domain name resolution table based on the service domain name and finding a matching customer domain name resolution table; The client's IP address is used to query the client's domain name resolution table to find the matching edge service node IP table; If the edge service node IP table contains a target edge service node IP whose current timestamp is less than or equal to the last updated timestamp and whose number of uses is less than the maximum number of uses, then the resource access address is determined based on the target edge service node IP. The domain name resolution table includes entries for domain name, central node address, and customer domain name resolution table. The customer domain name resolution table includes entries for client IP, edge service node IP, region matching weight, and load weight. The edge service node IP table includes entries for edge service node IP, maximum number of uses, number of uses, and last update timestamp.

[0009] In conjunction with the first aspect, in one possible implementation, updating the region matching weight and load weight includes: Traverse the edge service node IP table in the customer domain name resolution table to determine the region matching score corresponding to each edge service node IP in the edge service node IP table; From the matching scores of each region, determine the first edge service node IP that is greater than or equal to the preset score threshold and the second edge service node IP that is less than the preset score threshold, and accumulate the remaining available counts for the first edge service node IP and the second edge service node IP respectively to obtain the first count accumulation value and the second count accumulation value; If the first cumulative count is greater than the second cumulative count, then the region matching weight in the customer domain name resolution table is set to a first constant and the load weight is set to a second constant; the first constant is greater than the second constant. If the first accumulated value is equal to the second accumulated value, then the region matching weight is set to a third constant and the load weight is set to a fourth constant; the third constant is greater than the fourth constant and less than the first constant, and the fourth constant is greater than the second constant. If the first cumulative count is less than the second cumulative count, then the region matching weight and load weight are updated based on the quotient of the first cumulative count and the second cumulative count.

[0010] In conjunction with the first aspect, in one possible implementation, updating the region matching weight and load weight based on the quotient of the first accumulated count and the second accumulated count includes: If the quotient is less than the first constant threshold, then the region matching weight is set to the fifth constant, and the load weight is the difference between the second constant threshold and the second constant; the first constant threshold is less than the second constant threshold. If the quotient is greater than or equal to the first constant threshold, then the region matching weight is set to the quotient, and the load weight is the difference between the second constant threshold and the quotient.

[0011] In conjunction with the first aspect, in one possible implementation, determining the resource access address based on the target edge service node IP includes: If there are multiple target edge service node IPs, then the selection score of the edge service node corresponding to each target edge service node IP is determined, and the target edge service node IP corresponding to the highest selection score is determined as the resource access address.

[0012] In conjunction with the first aspect, in one possible implementation, the method further includes: If the customer's domain name resolution table is not found, a query failure is returned, and the data access process ends; or, If the edge service node IP table is not found, the central node address of the central node is sent to the client; or, If the target edge service node IP does not exist in the edge service node IP table, then the target edge service node IP containing the maximum number of uses is determined from the plurality of edge service nodes, and the target edge service node IP is determined as the resource access address.

[0013] In conjunction with the first aspect, in one possible implementation, the method further includes: The central node receives the reported information from the target edge service node and parses the regional information of the target edge service node from the reported information; Based on the IP address of the target edge service node, the edge service node table is searched; the entries in the edge service node table include IP address, remaining available bandwidth information, and region information. If a target entry matching the IP address of the target edge service node is found, the area information and remaining available bandwidth information in the target entry are updated according to the parsed area information and the remaining available bandwidth information contained in the reported information. If the target entry is not found, a new entry is created in the edge service node table using the IP address of the target edge service node as the key, and the parsed area information and the remaining available bandwidth information contained in the reported information are written into the new entry.

[0014] Secondly, this application also provides a computer program product. This computer program product includes instructions that, when executed, cause the method described in the first aspect to be implemented.

[0015] The data access method and computer program product provided in this invention, compared to the existing scheduling method based on HTTP 302 redirection, achieve the following: the DNS server performs an initial domain name resolution to return the address of the central node; the client requests scheduling from the central node; the central node sends edge server information to the DNS server and then returns a redirection response to the client; and the DNS server performs a secondary domain name resolution to return the resource access address. Since the DNS server has updated its domain name resolution records, the secondary domain name resolution directly returns the resource access address of the edge service node. This solves the scheduling failure caused by subsequent requests no longer passing through the scheduling center after browser redirection in traditional 302 scheduling. This approach effectively schedules each client request. Furthermore, the edge service node domain name is not pre-exposed in the initial domain name resolution result. Instead, the edge service node information is obtained after the initial domain name resolution, followed by a second domain name resolution to obtain the resource access address. This effectively prevents the edge node address from being maliciously intercepted and reused, enhancing security. In addition, the central node does not need to provide an independent domain name; clients always complete both resolutions and business accesses through the same service domain name. The 302 scheduling server and edge servers also do not need to be configured with independent domain names, significantly reducing domain name management complexity, lowering labor costs, improving user experience, and ensuring high security and flexibility in data access. Attached Figure Description

[0016] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is one of the flowcharts illustrating a data access method in one embodiment; Figure 2 This is a second flowchart illustrating a data access method in one embodiment; Figure 3 Here is a flowchart of the central scheduling server logic in one embodiment; Figure 4 This is the third flowchart illustrating a data access method in one embodiment; Figure 5 This is the fourth flowchart illustrating a data access method in one embodiment; Figure 6 Here is a flowchart of the DNS server domain name resolution process in one embodiment; Figure 7 Here is a flowchart of the DNS server obtaining the resolution logic from the edge server in one embodiment; Figure 8 This is the fifth flowchart illustrating a data access method in one embodiment; Figure 9 This is a flowchart of a data access method in one embodiment, number six. Figure 10 Here is a flowchart illustrating the weight update logic in the customer's domain name resolution table in one embodiment; Figure 11 This is the seventh flowchart illustrating a data access method in one embodiment; Figure 12 Here is a flowchart illustrating the logic of the central scheduling server processing the edge server in one embodiment; Figure 13 This is a flowchart of 302 scheduling and CDN parsing in a CDN system in one embodiment. Detailed Implementation

[0017] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the invention. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0018] It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of this invention can be combined with each other. The invention will now be described in detail with reference to the accompanying drawings and embodiments. Furthermore, the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The terms "first" and "second," etc., in the specification and claims of the embodiments of this invention are used to distinguish different objects, not to describe a specific order of objects.

[0019] To provide better service, CDNs typically rely on the combined efforts of 302 redirection scheduling and DNS resolution technology to improve service quality and make efficient use of resources.

[0020] However, DNS resolution scheduling has inherent flaws in practical applications: once the DNS resolution result is returned, it is cached at multiple levels, including by the client and the local DNS server, resulting in fixed resolution results and delayed updates. Especially in complex environments with cross-carrier or geographical regions, DNS scheduling struggles to dynamically perceive real-time network conditions (such as edge server load, link congestion, and failures), easily routing clients to suboptimal edge servers, leading to uneven resource allocation and increased access response latency. To address this, existing technologies introduce a scheduling method based on Hypertext Transfer Protocol 302 Found (HTTP 302) (hereinafter referred to as 302 redirect scheduling) to achieve more real-time and granular dynamic scheduling. 302 redirect scheduling is a traffic scheduling method that guides user requests to the optimal node through temporary redirection (302 status code), commonly used for load balancing, address optimization, or failover.

[0021] However, when using 302 redirect scheduling, the scheduling center responds to the client's first request by returning a redirect response containing the target edge server's domain name or address. After the client receives this redirect response and completes the redirect, it will use the target edge server's domain name or address as the default request address for subsequent related access requests, and will no longer be re-scheduled by the scheduling center. This causes some clients to fail to handle the redirect response automatically, resulting in scheduling failure. The edge server address exposed in the redirect response is easily reused maliciously. Furthermore, the above scheduling method requires the scheduling center and each edge server to configure independent domain names, which increases the complexity of domain name management.

[0022] To address the aforementioned technical problems, this application proposes a data access method and a computer program product. The following is a detailed explanation... Figures 1 to 13 This application describes a data access method, wherein the data access method is applied to a CDN system, which typically includes a central node, multiple edge service nodes, and address resolution nodes.

[0023] To facilitate understanding of the data access method provided in the embodiments of this application, the data access method provided in this application will be described in detail below through several exemplary embodiments. It is understood that the following exemplary embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0024] Reference Figure 1 This is a flowchart illustrating the data access method provided in an embodiment of this application, as shown below. Figure 1 As shown, the data access method includes the following steps 101 to 103.

[0025] Step 101: The address resolution node responds to the domain name resolution request sent by the client, determines the central node address that matches the service domain name in the domain name resolution request, and sends the central node address to the client.

[0026] It should be noted that in the CDN system provided in this embodiment of the invention, the central node can be a 302 scheduling center or a central scheduling server, and the address resolution node can be a DNS server; each edge service node is a logical node deployed on the network edge side, capable of providing data access services and having reporting capabilities, and its physical form can include, but is not limited to, edge servers, virtual machines, containers or edge gateway devices with corresponding capabilities.

[0027] Specifically, the client receives the service domain name entered by the user through the browser; for example, when the user requests the service domain name www.xxx.com, they can enter the service domain name www.xxx.com in the browser to access it, which will automatically generate a domain name resolution request containing the service domain name and send the domain name resolution request to the DNS server.

[0028] When a DNS server receives and responds to a domain name resolution request, it can determine the central node address that matches the service domain name in the domain name resolution request based on the preset mapping relationship between service domain names and central node addresses. Alternatively, it can resolve the client's source IP address from the domain name resolution request, thereby identifying the geographical region to which the client belongs, and then find the corresponding central node address of the preset service domain name in each region to determine the central node address that matches the service domain name in the domain name resolution request.

[0029] Step 102: The client addresses the central node based on the central node address and sends an edge node address scheduling request to the central node; the central node responds to the edge node address scheduling request, determines the target edge service node that is compatible with the client, and sends the edge service node information of the target edge service node to the address resolution node.

[0030] Among them, edge service node information is data related to the target edge service node, including but not limited to: service domain name, IP address of the target edge service node, and client IP address.

[0031] Specifically, the client uses the central node address to locate the 302 scheduling server and sends an edge node address scheduling request to the 302 scheduling server. In other words, the client sends a standard HTTP request to the 302 scheduling server.

[0032] The 302 dispatch server receives and responds to standard HTTP requests. It can parse the service domain name and client identification information from these requests and, based on the parsed information, query a pre-built mapping between the service domain name, client identification information, and edge service nodes to obtain the target edge service node adapted to the client. Alternatively, it can parse the service domain name and client Internet Protocol (IP) address from the standard HTTP request and identify the service type based on the service domain name, or dynamically identify the service type based on the path prefix or file extension of the request's Uniform Resource Locator (URL). Then, based on the parsed service domain name, client IP address, and identified service type, it queries a pre-built mapping between the service domain name, client IP address, service type, and edge service node to obtain the target edge service node adapted to the client.

[0033] Subsequently, the 302 scheduling server sends the edge service node information of the target edge service node to the DNS server.

[0034] Step 103: The address resolution node receives the edge service node information and, upon successful receipt of the edge service node information, sends a successful information reception response to the central node; the central node, based on the successful information reception response, sends a redirection response to the client.

[0035] The successful information reception response can be an HTTP 200 status code, a JSON message containing an operation success identifier, or other custom protocol confirmation messages.

[0036] The redirect response is specifically an HTTP 302 redirect response. The Location header of the HTTP 302 redirect response carries the URL of the original service domain name that the client originally requested.

[0037] Specifically, the central node sends the edge service node information to the DNS server, which can instruct the DNS server to update the resolution record of the service domain name (i.e., the domain name originally requested by the client) and point it to the IP address of the target edge service node.

[0038] After receiving the edge service node information from the 302 redirection server, the DNS server can perform integrity verification and domain name resolution on the received edge service node information. If the integrity verification passes and the DNS records for the service domain name are successfully updated to the local DNS table, it can be determined that the edge service node information has been successfully received.

[0039] Once the DNS server determines that it has successfully received the edge service node information, it returns a successful information reception response to the 302 scheduling server.

[0040] After receiving a successful response from the DNS server, the 302 dispatch server confirms that the DNS server is ready to provide the client with the latest domain name resolution service. At this point, the central node sends a redirect response to the client.

[0041] It should be noted that if the DNS server fails to receive or update the resolved record (e.g., integrity check fails, service domain name does not exist, etc.), the DNS server returns a reception failure response to the 302 scheduling server. Upon receiving the failure response, the 302 scheduling server does not send a redirect response to the client to avoid the client getting trapped in an invalid redirection loop or receiving incorrect domain name resolution results. In this case, the 302 scheduling server can either reselect another target edge service node or return an error message to the client.

[0042] Step 104: Based on the redirection response, the client sends a domain name resolution request to the address resolution node to obtain the resource access address corresponding to the service domain name returned by the address resolution node, and sends a business data access request to the target edge service node based on the resource access address.

[0043] Specifically, based on the redirection response, the client initiates another domain name resolution request to the DNS server. Upon receiving the request, the DNS server first checks its local cache for a DNS record for the target edge service node's domain name. If such a record exists, the server directly retrieves the resource access address from it. If not, the server requests an available edge service node's IP address from the 302 redirection server as the resource access address. Finally, the server encapsulates the resource access address into a DNS response message and sends it back to the client.

[0044] The data access method provided in this application, compared to the existing scheduling method based on HTTP 302 redirection, achieves a more efficient approach. It involves the DNS server performing an initial domain name resolution to return the central node address, the client requesting scheduling from the central node, the central node sending edge server information to the DNS server and then returning a redirection response to the client, and the DNS server performing a secondary domain name resolution to return the resource access address. Since the DNS server has updated its domain name resolution records, the secondary domain name resolution directly returns the resource access address of the edge service node. This solves the scheduling failure problem caused by subsequent requests no longer passing through the scheduling center after a browser redirect in traditional 302 scheduling, thus achieving effective scheduling of each data access request from the client. Furthermore, the edge service node performs two domain name resolutions for the same domain name before obtaining the resource access address, effectively preventing the malicious interception and reuse of edge node addresses, enhancing security. In addition, the central node and edge service nodes do not need to provide independent domain names; the client always requests two domain name resolutions and completes business access through the same service domain name, significantly reducing domain name management complexity, reducing labor costs, improving user experience, and providing high security and flexibility for data access.

[0045] Based on the above Figure 1 In one example embodiment of the method shown, step 102 involves determining the target edge service node for the adapted client. The specific process of this step can be achieved through… Figure 2 Steps 201 to 204 shown are implemented.

[0046] Step 201: The central node determines the available edge service nodes at the current moment from multiple edge service nodes.

[0047] Step 202: If multiple available edge service nodes are identified, determine the selection score of each available edge service node and select the target edge service node corresponding to the highest selection score; the selection score represents the access priority of the client connected to the corresponding available edge service node.

[0048] Step 203: If no available edge service node is determined, the current time is delayed by a preset time to obtain a new current time, and then the process returns to step 201.

[0049] Step 204: If re-execution fails to identify an available edge service node, then randomly select one edge service node from the multiple edge service nodes as the target edge service node.

[0050] Among them, the edge node addressing information is the server information of the target edge server, which specifically includes, but is not limited to, the domain name, the client IP, and the target edge server IP.

[0051] Specifically, in response to an edge node address scheduling request, the 302 scheduling server first determines the available edge servers from among multiple edge servers at the current moment. That is, it iterates through all edge servers, determines whether the current available bandwidth of each edge server is greater than a preset bandwidth threshold, and selects edge servers with bandwidth greater than the preset bandwidth threshold as available edge servers. For example, the preset bandwidth threshold is 500M.

[0052] If multiple usable edge servers can be identified, a selection score for each available edge server is calculated using a pre-defined regional matching score algorithm, and the edge server with the highest selection score is selected as the target edge server. If only one usable edge server can be identified, it is directly designated as the target edge service node.

[0053] Conversely, if no available edge server is found, the current time is delayed by a preset duration (e.g., waiting 2 seconds from the current time) to obtain a new current time. The steps of determining the available edge service nodes and the target edge server at the current time are then re-executed. The purpose of delaying the current time by a preset duration, specifically waiting 2 seconds from the current time, is to allow time for some edge servers to complete their currently processed requests, releasing available bandwidth and thus "squeezing out" available edge servers.

[0054] If the second execution still fails to identify a usable edge server, then one edge server is randomly selected from all edge servers as the target edge server, and the server information of the target edge service node is sent to the DNS server.

[0055] For the DNS server, it receives and resolves the server information of the target edge server (including the domain name, client IP, and target edge server IP), matches and stores it according to preset rules, generates a mapping relationship between the target edge server domain name and the target edge server IP address, and can selectively bind this mapping relationship to the client IP, so that the mapping relationship is effective only when the resolution request comes from that client IP. After the DNS server determines that the above mapping relationship is valid, it sends an acknowledgment response to the 302 scheduling server, indicating that it can return a 302 redirect. After receiving the acknowledgment response, the 302 scheduling server returns an HTTP 302 redirect response to the client. The Location header of the HTTP 302 redirect response carries the URL of the original service domain name.

[0056] For example, refer to Figure 3 The central scheduling server logic flowchart shown is as follows: Figure 3As shown, after the two traversals are completed, it is first determined whether at least two available edge servers are aggregated. If at least two available edge servers are aggregated, the edge server corresponding to the highest selection score is selected as the target server by calculating the selection score. Figure 3 The 302 original URL in the response can be understood as the Location header of the HTTP 302 redirect response carrying the URL of the original service domain.

[0057] Based on the above Figure 2 In one example embodiment of the method shown, step 202 determines the selection score of each available edge service node. The specific process of this step in this embodiment can be achieved through… Figure 4 Steps 301 to 303 shown are implemented.

[0058] Step 301: Determine the regional matching score of the available edge service node based on the matching results between the region to which the client belongs and the region to which the available edge service node belongs, as well as the matching results between the region to which the client belongs and the operator to which the available edge service node belongs.

[0059] Step 302: Determine the load score of available edge service nodes based on the remaining usage count and maximum usage count of available edge service nodes.

[0060] Step 303: Determine the selection score of the available edge service nodes based on the regional matching score, the load score, and the weight of each score.

[0061] Specifically, when the region to which the client belongs successfully matches the region to which the available edge server belongs (such as the city where the client is located), and the region to which the client belongs successfully matches the operator to which the available edge server belongs, the region matching score of the available edge service node is 100 points.

[0062] When the region to which the client belongs successfully matches the region to which the available edge server belongs (such as the city of the region), but the region to which the client belongs fails to match the operator to which the available edge server belongs, the region matching score of the available edge service node is 90 points.

[0063] When the region to which the client belongs successfully matches the region to which the available edge server belongs (such as the province where the client is located), and the region to which the client belongs successfully matches the operator to which the available edge server belongs, the region matching score of the available edge service node is 80 points.

[0064] When the region to which the client belongs successfully matches the region to which the available edge server belongs (such as the province of the region), but the region to which the client belongs fails to match the operator to which the available edge server belongs, the region matching score of the available edge service node is 70 points.

[0065] Except for the four cases mentioned above, the area matching score in all other cases is 60 points.

[0066] The load score of available edge servers can be calculated using equation (1).

[0067] Load score = 100 sqrt(remaining usage counts / maximum usage counts) (1) In equation (1), sqrt represents the square root operation.

[0068] Finally, the selection score of available edge servers is calculated according to equation (2).

[0069] Selection score = (Region matching weight × Region matching score) + (Load weight × Load score) (2) In equation (2), the regional matching weight can be configured to 0.7 and the load weight can be configured to 0.3.

[0070] It should be noted that the weights can be adjusted to suit different time periods. For example, during peak hours, the load weight can be increased (e.g., 5:5) to prioritize traffic distribution, while during normal times, the load weight can be decreased (e.g., 7:3) to prioritize network quality.

[0071] For example, when the available edge servers are edge server D (Zhejiang Hangzhou Telecom) and edge server E (Zhejiang Hangzhou Mobile), the selection score calculation process for edge server D and edge server E is as follows: For edge server D (Zhejiang Hangzhou Telecom): Regional matching score: The client region matches the server region city (Hangzhou, Zhejiang) and the carrier matches (China Telecom), so the regional matching score is 100.

[0072] Load score: Load score = 100 × sqrt(20 / 10) = 100 × 0.5 ≈ 70.71.

[0073] Selection score for edge server D: The selected score is calculated as follows: (0.7 × 100) + (0.3 × 70.71) = 70 + 21.213 = 91.213.

[0074] For edge server E (Zhejiang Hangzhou Mobile): Regional matching score: The client region matches the server region city (Hangzhou, Zhejiang) but the carriers do not match (China Telecom and China Mobile), so the regional matching score is 90.

[0075] Load score: Load score = 100 × sqrt(25 / 20) = 100 × 0.8 ≈ 89.44.

[0076] Selection score for edge server E: The selection score = (0.7 × 90) + (0.3 × 89.44) = 63 + 26.832 = 89.832.

[0077] The selection scores for edge server D and edge server E were calculated to be 91.213 and 89.832, respectively.

[0078] Based on the above Figure 1 In one example embodiment of the method shown, step 103 involves obtaining the resource access address corresponding to the service domain name returned by the address resolution node. The specific process of this step can be achieved through… Figure 5 Steps 401 to 403 shown are implemented.

[0079] Step 401: The address resolution node responds to the domain name resolution request by querying the domain name resolution table based on the service domain name and finding the matching customer domain name resolution table.

[0080] Step 402: Query the client's domain name resolution table based on the client's IP address to find the matching edge service node IP table.

[0081] Step 403: If there is a target edge service node IP in the edge service node IP table whose current timestamp is less than or equal to the last updated timestamp and whose number of uses is less than the maximum number of uses, then determine the resource access address based on the target edge service node IP.

[0082] The domain name resolution table includes entries for domain name, central node address, and customer domain name resolution table. The customer domain name resolution table includes entries for client IP, edge service node IP, region matching weight, and load weight. The edge service node IP table includes entries for edge service node IP, maximum number of uses, number of uses, and last update timestamp.

[0083] Specifically, the DNS server receives and resolves the domain name resolution request sent by the client, and queries the domain name resolution table based on the service domain name (key is the domain name, value is the service IP address (here it is the 302 dispatch center address), the client domain name resolution table).

[0084] If a matching client domain name resolution table is found, the client's IP address is queried from the client domain name resolution table (key is client ip, value is edge server IP table, region matching weight, load weight).

[0085] If a matching edge server IP is found, the edge server IP table is traversed (key is the edge server IP, value is the maximum number of uses, the number of uses, and the last update timestamp), and the target edge server IPs whose current timestamp is less than or equal to the last update timestamp and whose number of uses is less than the maximum number of uses are summarized.

[0086] If a summary of the target edge server IP exists, then iterate through the summary results. If it is determined that there is only one target edge server IP that exists, then that target edge server IP can be directly returned to the client as the resource access address of the target edge server.

[0087] For example, client A requests the domain name www.test.com, and the 302 redirection point is C. In response, the DNS server receives A's request for the www.test.com domain name resolution, queries the DNS table using www.test.com, retrieves the client's DNS entry, then queries the client's DNS table using the client's IP address. If the entry is not found, the server responds to address C.

[0088] Client A, region Hangzhou Telecom (Zhejiang), requests domain name www.test.com. Edge server D (Zhejiang Hangzhou Telecom), has been used 10 times, maximum usage is 20; edge server E (Zhejiang Hangzhou Mobile), has been used 20 times, maximum usage is 25. Both edge servers D and E are available within their time limits, with a region matching weight of 0.7 and a load weight of 0.3. The DNS server receives A's www.test.com domain name resolution request, queries the DNS table using www.test.com, retrieves the client's DNS entry, queries the client's DNS table using the client's IP, retrieves the edge server IP entry, and then iterates through the edge server IP entries, summarizing timestamps and available usage counts to retrieve D and E. Selection scores are then calculated for D and E respectively: 91.213 and 89.832. Therefore, the response address is D.

[0089] In one example embodiment, considering the possibility of abnormal situations such as the DNS server query not finding the table, the table being empty, or the IP address not existing, the abnormal situation is handled through the following steps.

[0090] If the client's domain name resolution table is not found, a query failure is returned, and the data access process ends; or, if the edge service node IP table is not found, the central node address of the central node is sent to the client; or, if the target edge service node IP does not exist in the edge service node IP table, the target edge service node IP with the highest number of uses is determined from multiple edge service nodes, and the target edge service node IP is determined as the resource access address.

[0091] Specifically, refer to Figure 6 The DNS server domain name resolution flowchart shown is as follows: Figure 6 As shown, if the DNS server queries the domain name resolution table based on the target edge server's domain name and does not find a matching client domain name resolution table, it means that the resolution of the domain name is not configured to the DNS server, and at least one server IP address should be configured; in this case, the query failure is returned directly, and the data access process ends.

[0092] If the DNS server does not find a matching edge service node IP in the domain name resolution table, it returns the server IP address from the domain name resolution table (this address is configured as the IP address of the central scheduling server, and is configured when manually configuring domain name resolution) to the client, thus ending the data access process.

[0093] If the DNS server does not summarize a target edge server IP, it will use the client's IP address and the zone matching score algorithm to find the edge server IP with the largest maximum usage count (maxCount) among all edge servers and respond to the client with the target edge server's resource access address.

[0094] Based on the above Figure 5 In one example embodiment of the method shown, step 403 determines the resource access address based on the target edge service node IP. The specific process of this embodiment can be implemented through the following steps.

[0095] If there are multiple target edge service node IPs, then determine the selection score of the edge service node corresponding to each target edge service node IP, and determine the target edge service node IP corresponding to the highest selection score as the resource access address.

[0096] For details, please refer to... Figure 6 If there are aggregated target edge server IPs, and after traversing the aggregated results it is determined that at least two target edge server IPs are aggregated, then through the selection score calculation process containing equations (1) and (2), the selection score of the edge server corresponding to each target edge server IP is calculated, and the target edge server IP corresponding to the highest selection score is selected as the resource access address to respond to the client.

[0097] It should be noted that after selecting the target edge server IP corresponding to the highest selection score as the resource access address to respond to the client, the number of times the target edge server IP has been used in the edge server IP table needs to be incremented by 1 to end the DNS server's domain name resolution process.

[0098] In addition, it should be noted that the DNS server obtains the resolution logic from the edge server, which can be specifically described as follows: Figure 7 As shown, the DNS server receives a request from the edge server (containing: domain name, client IP, edge server IP) from the central scheduling server. Based on the domain name, it queries the domain name resolution table. If the domain name is not found, the response fails. The fact that the domain name is not found here indicates that the DNS resolution for that domain name is not configured to this DNS server. At least one server IP address should be configured. Normally, this step wouldn't proceed because the domain name was previously resolved to the central scheduling server, meaning there is already an entry for that domain name in the table.

[0099] If found, query the client's domain name resolution table using the client's IP address.

[0100] If not found, create an entry with the client IP as the key, set the region matching weight to 0.6 and the load weight to 0.4, and create an entry for the edge server IP table with the edge server IP as the key; also, set the maximum number of uses (maxCount) to 1, the number of uses (userCount) to 0, and push the last update time (lastTime) field back 5 seconds from the current timestamp. If the response is successful, the process ends.

[0101] If found, query the edge server IP table using the edge server IP as the key. If found, increment maxCount by 1, and push the lastTime field back 5 seconds based on the current timestamp. If the response is successful, the process ends.

[0102] If not found, create an entry in the edge server IP table with the server IP as the key, set maxCount to 1, userCount to 0, and push the lastTime field back 5 seconds from the current timestamp. If the response is successful, the process ends.

[0103] In one example embodiment, the zone matching weight and load weight in the customer's domain name resolution table entries can be updated periodically via a pre-set scheduled task, such as once per minute; and the update process of the zone matching weight and load weight each time in this embodiment can be specifically achieved through... Figure 8 Steps 501 to 505 shown are implemented.

[0104] Step 501: Traverse the edge service node IP table in the customer's domain name resolution table and determine the region matching score corresponding to each edge service node IP in the edge service node IP table.

[0105] Step 502: From the matching scores of each region, determine the first edge service node IP that is greater than or equal to the preset score threshold and the second edge service node IP that is less than the preset score threshold, and accumulate the remaining available counts for the first edge service node IP and the second edge service node IP respectively to obtain the first count accumulation value and the second count accumulation value.

[0106] Step 503: If the cumulative value of the first count is greater than the cumulative value of the second count, then set the area matching weight in the customer's domain name resolution table to the first constant and the load weight to the second constant; the first constant is greater than the second constant.

[0107] Step 504: If the first accumulated value is equal to the second accumulated value, then set the region matching weight to the third constant and the load weight to the fourth constant; the third constant is greater than the fourth constant and less than the first constant, and the fourth constant is greater than the second constant; Step 505: If the first cumulative value is less than the second cumulative value, update the region matching weight and load weight based on the quotient of the first and second cumulative values.

[0108] The remaining available number of times for the edge server IP is the difference between its maximum number of uses and the number of times it has already been used.

[0109] Specifically, the DNS server traverses the edge server IP table in the client domain name resolution table to resolve the region information of the edge server IP, compares and classifies the edge server IP with the client IP region, and calculates the region matching score of each edge server IP in the edge server IP table according to the region matching score calculation method in the aforementioned embodiment. Based on this, it divides the edge server IP into first edge server IP with a score greater than or equal to a preset score threshold (e.g., 80 points) and second edge server IP with a score less than the preset score threshold. Then, it further accumulates the remaining available attempts for all first edge server IPs and all second edge server IPs to obtain the first accumulated value (A) and the second accumulated value (B).

[0110] If A is greater than B, set the region matching weight in the customer domain name table entry to the first constant (e.g., 0.7) and the load weight to the second constant (e.g., 0.3).

[0111] If A equals B, set the zone matching weight in the customer's domain name resolution table entry to the third constant (e.g., 0.6) and the load weight to the fourth constant (e.g., 0.4).

[0112] If A is less than B, calculate A / B and update the region matching weight and load weight based on A / B.

[0113] In one example embodiment, step 505 updates the region matching weight and load weight based on the quotient of the first and second cumulative values. The specific process of this step in this embodiment can be described through… Figure 9 Steps 601 and 602 shown are implemented.

[0114] Step 601: If the quotient is less than the first constant threshold, then set the region matching weight to the fifth constant and the load weight to the difference between the second constant threshold and the second constant; the first constant threshold is less than the second constant threshold.

[0115] Step 602: If the quotient is greater than or equal to the first constant threshold, then set the region matching weight to the quotient and the load weight to the difference between the second constant threshold and the quotient.

[0116] Specifically, for the first cumulative value (A) and the second cumulative value (B), if A is less than B, calculate A / B. If A / B is less than the first constant threshold (e.g., 0.1), then set the region matching weight in the customer domain name table entry to 0.1, and the load weight to the second constant threshold (e.g., 1) - region matching weight.

[0117] Conversely, if A / B is greater than or equal to the first constant threshold (e.g., 0.1), then the region matching weight in the customer domain name table entry is set to A / B, and the load weight is the second constant threshold (e.g., 1) - A / B.

[0118] For example, refer to Figure 10 The flowchart of the weight update logic in the customer domain name resolution table is shown below. Figure 10 As shown, the DNS server traverses the domain name resolution table and retrieves the entries, and then traverses the client domain name resolution table entries within the domain name resolution table and retrieves the entries.

[0119] The client IP's region information is parsed out, and the edge server IP table in the client's domain name resolution table is traversed to compare and classify the edge server IP with the client IP's region.

[0120] Based on the regional matching score algorithm, the remaining available counts are accumulated for the first edge server IP with a score greater than or equal to 80 and the second edge server IP with a score less than 80, respectively, to obtain the first accumulated count value (A) and the second accumulated count value (B).

[0121] After traversing the edge server IP table, if A is greater than B, set the regional matching weight of the customer domain name table entry to 0.7 and the load weight to 0.3, and then traverse the next customer domain name resolution table.

[0122] After traversing the edge server IP table, if A equals B, set the zone matching weight of the client domain name resolution table entry to 0.6 and the load weight to 0.4, and then traverse the next client domain name resolution table.

[0123] After traversing the edge server IP table, if A is less than B, calculate A / B. If A / B is less than 0.1, set the regional matching weight of the customer domain name table entry to 0.1; otherwise, set the regional matching weight of the customer domain name table entry to A / B, and the load weight to 1 - regional ratio. Then traverse the next customer domain name resolution table.

[0124] Once the client's domain name resolution table has been traversed, the next domain name resolution table is traversed. This process continues until all domain name resolution tables have been traversed, at which point the process ends.

[0125] In one example embodiment, considering that the central scheduling server uses outdated remaining available bandwidth information, users may be scheduled to nodes that are actually overloaded; and, if the regional information of the edge server changes but is not updated, users may also be scheduled to nodes that are geographically distant or cross-carrier, resulting in access delays. Therefore, embodiments of this application address this issue by... Figure 11 Steps 701 to 704 shown resolve this issue.

[0126] Step 701: The central node receives the reported information from the target edge service node and parses the regional information of the target edge service node from the reported information.

[0127] Step 702: Based on the IP address of the target edge service node, look up the edge service node table; the entries in the edge service node table include IP address, remaining available bandwidth information, and region information.

[0128] Step 703: If a target entry matching the IP address of the target edge service node is found, update the area information and remaining available bandwidth information in the target entry according to the parsed area information and the remaining available bandwidth information contained in the reported information.

[0129] Step 704: If the target entry is not found, create a new entry in the edge service node table using the IP address of the target edge service node as the key, and write the parsed area information and the remaining available bandwidth information contained in the reported information into the new entry.

[0130] The IP address of the target edge server is the address used by the target edge service node for management communication with the central scheduling server (such as reporting information and receiving instructions); the resource access address of the target edge server is the service address of the target edge server obtained by the client through domain name resolution and used for accessing business data. These two addresses can be the same or different. This application does not impose specific limitations on this.

[0131] Specifically, the central dispatch server has a locally pre-installed IP geographic information database, which records the mapping relationship between IP address ranges and regional information. The central dispatch server uses the IP address of the target edge server as the key to query the IP geographic information database, matches the IP address range to which the IP address belongs, and then obtains the regional information corresponding to the IP address range.

[0132] Subsequently, the central scheduling server queries the edge server table using the target edge service node's IP address as the key. If a matching target entry is found, the server updates the target entry with the region information and remaining available bandwidth information from the parsed region information and the reported information. This update is necessary because the region information may change. Conversely, if no matching target entry is found, a new entry is created using the target edge server's IP address as the key, and the parsed region information and remaining available bandwidth information from the reported information are written into the new entry.

[0133] For example, refer to Figure 12 The flowchart shown below illustrates the logical process of the central scheduling server processing edge servers. Figure 12 As shown, the central scheduling server receives the reported information from the edge servers (including remaining available bandwidth information) and parses out the edge server IP and region information. Then, it queries the edge server table (entries: remaining available bandwidth information, region information) using the edge server IP as the key. If found, the remaining available bandwidth information and region information are updated, and the process ends. Otherwise, if not found, an entry is created using the edge server IP as the key, recording the remaining available bandwidth information and region information, and the process ends.

[0134] In summary, the purpose of this application is to provide a data access method that can improve the accuracy of 302 scheduling and reduce management complexity, in order to solve the following problems: 1. After 302 scheduling is performed on browser access, subsequent resources are also scheduled using 302; 2. How to prevent 302 scheduling domains from being attacked; 3. How to reduce the management of domains.

[0135] This data access method combines 302 redirection with DNS resolution, and its flowchart is as follows: Figure 13 As shown, in Figure 13In this process, the client accesses a domain name through a browser, sending a DNS resolution request to the DNS server to resolve the domain name; the DNS server responds with a 302 redirect to the dispatch center's IP address; the client sends an HTTP request to the 302 dispatch center to access the domain name; the 302 dispatch center sends the dispatch address of the edge server in this request to the DNS server, and receives a redirect response from the DNS dispatch server; the 302 dispatch center sends the redirect response to the client, and the client sends another DNS resolution request to the DNS server to resolve the domain name, receiving the edge server's IP address from the DNS server; then the client sends an HTTP request to the edge server's IP address and receives an HTTP response.

[0136] For example, client A requests the domain name www.xxx.com, DNS server B, 302 redirection center C, and edge server D; refer to Figure 13 Client A accesses www.xxx.com in its browser and initiates a domain name resolution query for www.xxx.com to DNS server B; DNS server B responds with a 302 redirect address; the client sends an HTTP request to the 302 redirect center C; upon receiving the HTTP request, the 302 redirect center C responds with a 302 redirect address, at which point the 302 location remains unchanged from the original request; the client receives a 302 redirect and initiates a redirect request, sending a domain name resolution query for www.test.com to DNS server B; DNS server B responds with the edge server IP; the client sends an HTTP request to edge server D; edge server D responds with data.

[0137] The data access method provided in this application allocates traffic to the server according to the proportion of available bandwidth to avoid overloading some servers; by introducing fractional smoothing attenuation, it reduces traffic jitter and improves user experience; the entire access process makes 302 scheduling more flexible, preventing edge servers from being easily discovered and attacked; at the same time, it can dynamically adjust weights to adapt to different scenarios and make service operation more stable; in addition, it reduces the burden of domain name management and lowers labor costs.

[0138] It should be noted that although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. On the contrary, the steps depicted in the flowchart can be performed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0139] On the other hand, this application also provides a computer-readable storage medium, which may be included in the computer device described in the above embodiments, or may exist independently and not assembled into the computer device. The aforementioned computer-readable storage medium stores one or more programs that, when used by one or more processors, execute the methods described in this application. For example, it may execute... Figure 1 The steps of the method shown.

[0140] This application provides a computer program product including instructions that, when executed, cause the method described in this application to be performed. For example, it can execute... Figure 1 The steps of the method shown.

[0141] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0142] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A data access method, characterized in that, The method is applied to a content delivery network system, which includes a central node, multiple edge service nodes, and address resolution nodes; the method includes: In response to a domain name resolution request sent by a client, the address resolution node determines the central node address that matches the service domain name in the domain name resolution request and sends the central node address to the client. The client addresses the central node based on the central node address and sends an edge service node scheduling request to the central node; the central node responds to the edge service node scheduling request, determines the target edge service node that is compatible with the client, and sends the edge service node information of the target edge service node to the address resolution node; The address resolution node receives the edge service node information, and upon successfully receiving the edge service node information, sends a successful information reception response to the central node; the central node, based on the successful information reception response, sends a redirection response to the client. Based on the redirection response, the client sends the domain name resolution request to the address resolution node, obtains the resource access address corresponding to the service domain name returned by the address resolution node, and sends a business data access request to the target edge service node based on the resource access address.

2. The method according to claim 1, characterized in that, The process of determining the target edge service node adapted to the client includes: The central node determines the available edge service nodes at the current moment from the plurality of edge service nodes; If multiple available edge service nodes are identified, a selection score is determined for each available edge service node, and the target edge service node corresponding to the highest selection score is selected. The selection score represents the access priority of the corresponding available edge service node to the client. If the available edge service node is not determined, the current time is delayed by a preset time to obtain a new current time, and the process returns to the step of determining the available edge service node at the current time. If the available edge service node is not determined during re-execution, then one edge service node is randomly selected from the plurality of edge service nodes as the target edge service node.

3. The method according to claim 2, characterized in that, Determining the selection score for each of the available edge service nodes includes: Based on the matching results between the region to which the client belongs and the region to which the available edge service node belongs, and the matching results between the region to which the client belongs and the operator to which the available edge service node belongs, the region matching score of the available edge service node is determined; The load score of the available edge service nodes is determined based on the remaining usage count and maximum usage count of the available edge service nodes; The selection score of the available edge service node is determined based on the region matching score of the available edge service node, the load score of the available edge service node, and the weight of each score.

4. The method according to claim 1, characterized in that, The step of obtaining the resource access address corresponding to the service domain name returned by the address resolution node includes: The address resolution node responds to the domain name resolution request by querying the domain name resolution table based on the service domain name and finding a matching customer domain name resolution table; The client's IP address is used to query the client's domain name resolution table to find the matching edge service node IP table; If the edge service node IP table contains a target edge service node IP whose current timestamp is less than or equal to the last updated timestamp and whose number of uses is less than the maximum number of uses, then the resource access address is determined based on the target edge service node IP. The domain name resolution table includes entries for domain name, central node address, and customer domain name resolution table. The customer domain name resolution table includes entries for client IP, edge service node IP, region matching weight, and load weight. The edge service node IP table includes entries for edge service node IP, maximum number of uses, number of uses, and last update timestamp.

5. The method according to claim 4, characterized in that, Updating the region matching weights and load weights includes: Traverse the edge service node IP table in the customer domain name resolution table to determine the region matching score corresponding to each edge service node IP in the edge service node IP table; From the matching scores of each region, determine the first edge service node IP that is greater than or equal to the preset score threshold and the second edge service node IP that is less than the preset score threshold, and accumulate the remaining available counts for the first edge service node IP and the second edge service node IP respectively to obtain the first count accumulation value and the second count accumulation value; If the first cumulative count is greater than the second cumulative count, then the region matching weight in the customer domain name resolution table is set to a first constant and the load weight is set to a second constant; the first constant is greater than the second constant. If the first cumulative count is equal to the second cumulative count, then the region matching weight is set to a third constant and the load weight is set to a fourth constant; the third constant is greater than the fourth constant and less than the first constant, and the fourth constant is greater than the second constant. If the first cumulative count is less than the second cumulative count, then the region matching weight and load weight are updated based on the quotient of the first cumulative count and the second cumulative count.

6. The method according to claim 5, characterized in that, The step of updating the region matching weight and load weight based on the quotient of the first accumulated value and the second accumulated value includes: If the quotient is less than the first constant threshold, then the region matching weight is set to the fifth constant, and the load weight is the difference between the second constant threshold and the fifth constant; the first constant threshold is less than the second constant threshold. If the quotient is greater than or equal to the first constant threshold, then the region matching weight is set to the quotient, and the load weight is the difference between the second constant threshold and the quotient.

7. The method according to claim 4, characterized in that, Determining the resource access address based on the target edge service node IP includes: If there are multiple target edge service node IPs, then determine the selection score of the edge service node corresponding to each target edge service node IP, and determine the target edge service node IP corresponding to the highest selection score as the resource access address.

8. The method according to claim 4, characterized in that, The method further includes: If the customer's domain name resolution table is not found, a query failure is returned, and the data access process ends; or, If the edge service node IP table is not found, the central node address of the central node is sent to the client; or, If the target edge service node IP does not exist in the edge service node IP table, then the target edge service node IP with the maximum number of uses is determined from the plurality of edge service nodes, and the target edge service node IP is determined as the resource access address.

9. The method according to claim 1, characterized in that, The method further includes: The central node receives the reported information from the target edge service node and parses the regional information of the target edge service node from the reported information; Based on the IP address of the target edge service node, the edge service node table is searched; the entries in the edge service node table include IP address, remaining available bandwidth information, and region information. If a target entry matching the IP address of the target edge service node is found, the area information and remaining available bandwidth information in the target entry are updated according to the parsed area information and the remaining available bandwidth information contained in the reported information. If the target entry is not found, a new entry is created in the edge service node table using the IP address of the target edge service node as the key, and the parsed area information and the remaining available bandwidth information contained in the reported information are written into the new entry.

10. A computer program product, characterized in that, The computer program product includes instructions that, when executed, cause the method as described in any one of claims 1 to 9 to be implemented.

Images