WO2025195082A1 - Network request scheduling method and apparatus for cdn, and device and medium - Google Patents

Abstract

The present disclosure relates to the technical field of edge clouds. Disclosed are a network request scheduling method and apparatus for a CDN, and a device and a medium. The method comprises: acquiring a network request sent by a dynamic acceleration gateway, wherein the network request is sent when the dynamic acceleration gateway performs security check on a network request from a client and the security check is passed; in a trusted execution environment, forwarding the network request to a target application server among a plurality of preset application servers on the basis of a preset scheduling strategy; and receiving a response result of the target application server to the network request, and forwarding the response result to the client.

Description

Method, device, equipment and medium for CDN network request scheduling

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on March 21, 2024, with application number 202410330069.4 and invention name “Network request scheduling method, device, equipment and medium for CDN”, the entire contents of which are incorporated by reference into this application.

Technical Field

The present disclosure relates to the field of edge cloud technology, and in particular to a method, apparatus, device, and medium for scheduling network requests for CDN.

Background Art

With the development of edge cloud technology, content delivery networks (CDNs) have played a vital role. By caching content on edge cloud servers located in edge data centers, CDNs enable users to access required content more quickly, reducing latency between users and central data centers.

Summary of the Invention

In a first aspect, the present disclosure provides a network request scheduling method for a CDN, the method being applied to a dynamic acceleration routing scheduling engine in an edge cloud server configured with a trusted execution environment, the method comprising:

Obtaining a network request sent by a dynamic acceleration gateway, wherein the network request is a network request from a client that the dynamic acceleration gateway performs a security check on and sends after passing the security check;

In the trusted execution environment, forwarding the network request to a target application server among a plurality of preset application servers according to a preset scheduling policy;

Receive a response result of the target application server to the network request, and forward the response result to the client.

In a second aspect, the present disclosure provides a network request scheduling method for CDN, characterized in that the method is applied to a dynamic acceleration gateway in an edge cloud server, and the method includes:

Get the network request sent by the client;

Parsing the network request to determine the request type corresponding to the network request, and querying the security check policy corresponding to the request type;

Performing a security check on the request content carried by the network request using the security check strategy to obtain a preliminary request processing result;

If the preliminary processing result of the request is a legal result, the corresponding edge cloud server is determined according to the network environment information of the client, and the network request is sent to the dynamic acceleration routing scheduling engine in the edge cloud server to schedule the network request through the edge cloud server.

In a third aspect, the present disclosure provides a network request scheduling device for a CDN, wherein the device is deployed in a dynamic acceleration routing scheduling engine applied to an edge cloud server configured with a trusted execution environment, and the device includes:

The acquisition module is used to obtain the network request sent by the client;

A scheduling module, configured to forward the network request to a target application server among a plurality of preset application servers in the trusted execution environment according to a preset scheduling policy;

The response module is used to receive the response result of the target application server to the network request, and to forward the response result to the client.

In a fourth aspect, the present disclosure provides a network request scheduling device for CDN, wherein the device is applied to a dynamic acceleration gateway in an edge cloud server, and the method includes:

Receiving module, used to obtain the network request sent by the client;

A parsing module, configured to parse the network request to determine a request type corresponding to the network request, and query a security check policy corresponding to the request type;

The inspection module is used to perform a security inspection on the request content carried by the network request using the security inspection strategy to obtain a preliminary processing result of the request.

A sending module is used to determine the corresponding edge cloud server based on the network environment information of the client if the preliminary processing result of the request is a legal result, and send the network request to the dynamic acceleration routing scheduling engine in the edge cloud server to schedule the network request through the edge cloud server.

In a third aspect, the present disclosure provides a computer device comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the network request scheduling method for CDN according to the first aspect or any corresponding embodiment thereof by executing the computer instructions.

In a fourth aspect, the present disclosure provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the network request scheduling method for CDN according to the first aspect or any corresponding embodiment thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the specific embodiments of the present disclosure or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the specific embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

FIG1 is a flow chart of a method for scheduling network requests for a CDN according to an embodiment of the present disclosure;

FIG2 is a flow chart of another method for scheduling network requests for a CDN according to an embodiment of the present disclosure;

FIG3 is a flow chart of another method for scheduling network requests for a CDN according to an embodiment of the present disclosure;

FIG4 is a flow chart of yet another method for scheduling network requests for a CDN according to an embodiment of the present disclosure;

FIG5 is a flow chart of another method for scheduling network requests for a CDN according to an embodiment of the present disclosure;

FIG6 is a structural block diagram of a network request scheduling apparatus according to an embodiment of the present disclosure;

FIG7 is a structural block diagram of another network request scheduling device according to an embodiment of the present disclosure;

FIG8 is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present disclosure.

DETAILED DESCRIPTION

To make the purpose, technical solutions, and advantages of the embodiments of the present disclosure more clear, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without making creative efforts shall fall within the scope of protection of the present disclosure.

As mentioned above, with the development of edge cloud technology, content distribution networks have played a significant role. By caching content on edge cloud servers located in edge data centers, CDNs enable users to access required content more quickly, reducing latency between users and central data centers. However, deploying edge cloud servers in edge data centers presents security challenges, which can also affect the security performance of CDNs. Compared to central data centers in central cloud technology scenarios, edge cloud servers in edge data centers are more susceptible to interference from malware or attackers, and security performance is often not guaranteed. If a malicious attack occurs, the normal operation of the edge cloud server may be affected. In particular, as an edge cloud server that schedules network requests, when subjected to external malicious attacks, the trustworthiness of the edge cloud server's routing problem may decrease, making the edge cloud server unable to operate normally.

In view of this, the present disclosure provides a network request scheduling method, apparatus, device and medium for CDN, in order to solve the problem that when subjected to external malicious attacks, the trust of the edge cloud server routing problem may be reduced, thereby making the edge cloud server unable to operate normally. The present disclosure provides a network request scheduling method for CDN, which is applied to a dynamic acceleration routing scheduling engine in an edge cloud server configured with a trusted execution environment. The method can schedule network requests according to a preset scheduling strategy in the trusted execution environment in the edge cloud server, and forward the response results of the target application server to the network request to the client; compared with the relevant technology, the solution provided by the present disclosure can distribute the request to the edge cloud server closer to the client by the dynamic acceleration gateway even when the edge cloud server is subjected to malicious attacks, and the edge cloud server performs load balancing on the network request, thereby optimizing the response time of the edge cloud server and improving the reliability through the collaborative work of the edge cloud server and the dynamic acceleration gateway, thereby ensuring data security.

The present disclosure also provides a network request scheduling method for CDN, which is applied to a dynamic acceleration gateway in an edge cloud server. In this method, the dynamic acceleration gateway obtains and parses the network request sent by the client, and can perform a security check on the request. Malicious requests or attacks can be prevented, improving the security of the system. By determining the request type corresponding to the request and querying the corresponding security check policy, a detailed security check can be performed on the request content according to the security check policy, thereby providing more comprehensive security protection. Then, based on the client's network environment information, a suitable edge cloud server can be determined to minimize latency and improve system performance. Sending network requests to the nearest edge cloud server can reduce the distance and time of data transmission, thereby improving the response speed and performance of the application. In addition, the edge cloud server can distribute requests to the back-end server based on the load balancing algorithm and other strategies to further optimize the load balancing and performance of the system.

With the development of private cloud and edge computing, and the extension of the trend of multi-cloud deployment, more and more dynamic acceleration services need to be deployed in other data centers or even edge computer rooms outside of the autonomous and controllable central cloud. For central cloud servers deployed in the central computer room in the central cloud scenario, they are generally equipped with a high-performance security protection system, so they can withstand attacks from malware or attackers. However, for edge cloud servers deployed in edge computer rooms in edge cloud scenarios, in order to reduce deployment costs, the edge computer rooms selected are generally computer rooms with average or even poor network security. In particular, edge cloud servers that schedule network requests may face the following problems when attacked by external malicious attacks:

(1) Malicious attacks can cause the trustworthiness of edge cloud server routing to degrade. Attackers can forge or tamper with network requests, causing edge cloud servers to make incorrect routing choices. This can cause requests to be sent to inappropriate servers, impacting service quality or security. Alternatively, attackers can exploit vulnerabilities or malicious behavior to change the edge cloud server's routing policy, causing requests to be sent to unsafe or unauthorized destinations.

(2) When an edge cloud server is attacked by malicious means, its ability to resist attacks may be reduced. Attackers may use various attack methods, such as DDoS attacks and denial of service attacks, to prevent the edge cloud server from operating normally, thereby affecting the stability and reliability of the entire edge network.

According to an embodiment of the present disclosure, an embodiment of a network request scheduling method for a CDN is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

In this embodiment, a network request scheduling method for CDN is provided. The network request scheduling method for CDN is applied to a dynamic acceleration routing scheduling engine in an edge cloud server configured with a trusted execution environment.

The Trusted Execution Environment (TEE), also known as trusted computing, is used in this embodiment to protect the dynamic acceleration routing scheduling engine described below, maintaining its security and integrity even in unsafe or attacked environments. Specifically, TEE uses hardware-based security mechanisms to load the code and data involved in the calculation into a trusted environment protected by the CPU (Central Processing Unit), providing confidentiality and integrity protection. Compared with the operating system, TEE provides a higher level of security and is therefore more suitable for processing sensitive data.

FIG1 is a flow chart of a method for scheduling network requests for a CDN according to an embodiment of the present disclosure. As shown in FIG1 , the flow includes the following steps:

Step S101: obtaining a network request sent by a dynamic acceleration gateway. The network request is a security check performed by the dynamic acceleration gateway on a network request from a client and is sent after the security check passes.

When a client sends a network request, it is first sent to the dynamic acceleration gateway. The dynamic acceleration gateway performs security checks on the network request, including identity verification, malicious behavior detection, and security threat prevention. If the security check passes, the dynamic acceleration gateway sends the network request to the edge cloud server. Edge cloud servers are distributed in different locations, closer to the client, to provide faster response and lower latency. After receiving the network request from the dynamic acceleration gateway, the edge cloud server forwards the request to the most appropriate backend server for processing based on load balancing algorithms and other policies.

Through the above architecture and process, the edge cloud server and the dynamic acceleration gateway work together to provide higher performance and security. The dynamic acceleration gateway is responsible for security checks and traffic control, while the edge cloud server is responsible for actual request processing and load balancing. By distributing requests to edge cloud servers closer to the client through the dynamic acceleration gateway, the response time and reliability of the edge cloud server can be optimized. Specifically, the network request can be a request to obtain a web page, data, API (Application Programming Interface) access, or any other type of service.

Based on this, this application can reduce network latency and improve response speed by deploying edge cloud servers in geographical locations closer to users. Users can obtain content from the nearest edge node without the need for remote CDN servers. The edge cloud server can process part of the network requests and cache the content, reducing the load on the remote CDN server. This improves the overall request processing capability and throughput. In addition, the dynamic acceleration gateway can perform security checks on the requests before they reach the CDN to prevent malicious requests and attacks. This can provide an additional layer of security to protect the content security of the CDN and users. Through the collaborative work of the edge cloud server and the dynamic acceleration gateway, the CDN can provide faster, more efficient and more secure content distribution services. The edge cloud server provides content at a location closer to the user, reducing network latency and improving response speed. At the same time, the dynamic acceleration gateway can enhance security and protect the CDN and user content from malicious requests and attacks. Such collaborative work can improve the performance, stability and reliability of the CDN and provide a better user experience.

In the embodiments of the present disclosure, the client involved may specifically include but is not limited to an application client and/or a web page (web terminal) set up on an electronic device, such as a mobile application or other types of client software on an electronic device such as a smartphone, tablet computer or desktop computer.

In some optional implementations, before step S101, the network request scheduling method further includes but is not limited to the following steps a1 to a4.

Step a1: Create the trusted execution environment in the edge cloud server.

This embodiment selects TEE technology based on the server's architecture and requirements. Common TEE technologies include Intel SGX and ARM TrustZone. Based on the selected TEE technology, the corresponding TEE software stack is installed. The TEE software stack includes the TEE runtime environment and the TEE SDK. The runtime environment provides a secure runtime environment for the TEE, while the SDK is used to develop and deploy TEE applications. Configure the edge cloud server's hardware and firmware according to the requirements of the TEE technology. This primarily includes BIOS settings, microcode updates, and secure boot.

Use the TEE SDK to develop and create a trusted execution environment (TEE). This includes writing TEE applications and related security configurations. TEE applications run in a trusted execution environment, providing additional security protections. The developed TEE applications are then deployed to edge cloud servers.

Step a2: verify the signature of the execution code corresponding to the preset scheduling strategy.

Among them, the signature of the execution code can be a digital signature; more specifically, the signature can be a certificate chain, from a root certificate to the final code signing certificate. TEE can be used to verify the entire certificate chain to ensure that the signature of the execution code is credible.

In this embodiment, before the executable code is deployed to the TEE, it can be signed with a secure digital signature, which usually involves using a trusted signing key (usually controlled by the software publisher or organization).

When the execution code is loaded into the TEE, the TEE startup process can include verifying the digital signature of the execution code. Only when the digital signature verification is successful will the execution code be allowed to run, which ensures that only authorized code can run.

In step a3, if the signature of the execution code passes the verification, the execution code is run in the trusted execution environment.

Specifically, this embodiment can load and run the execution code if the execution code passes security verification, that is, load the traffic scheduling logic within the TEE. The scheduling logic is a program specifically used to decide how to allocate and forward inbound traffic to different preset application servers.

In step a4, if the signature of the execution code fails to pass the verification, the execution code is denied from running in the trusted execution environment.

This embodiment further ensures that the code or program that can be run in the TEE is necessarily safe by performing signature verification on the code used to implement the traffic scheduling function, thereby improving the security of traffic scheduling.

Step S102 : forwarding the network request to a target application server among a plurality of preset application servers in a trusted execution environment according to a preset scheduling policy.

Among them, multiple preset application servers are respectively communicated and connected with the edge cloud server, and the preset scheduling strategy is a load balancing strategy.

The preset scheduling strategy of this embodiment may include one or more network request scheduling methods, so as to distribute the traffic brought by a large number of network requests to the corresponding preset application server, and specifically forward it to an instance of the preset application server (such as a container or cloud service, etc.).

In some optional implementations, the preset scheduling strategy includes at least one of a round-robin method, a minimum number of connections method, a scheduling method based on application server resources, a hash calculation method, a path hash method, and a domain name hash method. The above step S102 includes: scheduling the network request by at least one of a round-robin method, a minimum number of connections (Least Connections) method, a scheduling method based on application server resources (Resource-Based Scheduling), a hash calculation method, a path hash method, and a domain name hash method, thereby scheduling the network request to the target application server.

Specifically, the polling method includes at least one of the average polling method and the weighted polling method, the minimum connection number method includes at least one of the average minimum connection number method and the weighted minimum connection number method, and the hash calculation method includes at least one of the source Internet interconnection protocol hash method, the request path hash method, and the session information hash method.

In the process of scheduling network requests by polling, the dynamic acceleration routing scheduling engine in the trusted execution environment allocates the current network request to the next preset application server (i.e., the target application server) in the preset application server list; if the end of the preset application server list is reached, the network request is allocated again from the preset application server at the beginning of the preset application server list, and the preset application server list is used to record the above-mentioned multiple preset application servers; the above-mentioned polling method can be called average polling, which is suitable for scenarios where all preset application servers have the same configuration and roughly the same processing power. On this basis, this embodiment may schedule network requests by weighted polling, including: setting a weight for each preset application server in the preset application server list, and the weight is used to reflect the processing power of the preset application server; for example, when the response of a preset application server slows down, the weight of the preset application server can be dynamically reduced, and more network requests can be allocated to the preset application server with a higher weight. Among them, weighted polling is more suitable for scenarios where there are performance differences between multiple preset application servers in the back end. The dynamic acceleration routing scheduling engine of this embodiment can monitor the performance indicators of each preset application server in the backend in real time. The performance indicators may include but are not limited to response time, CPU usage, memory usage, and number of active connections. These performance indicators are crucial for implementing traffic scheduling and health checks.

In the process of scheduling network requests through the minimum number of connections, the dynamic acceleration routing scheduling engine sends the new network request to the preset application server with the least number of currently active connections; the above-mentioned minimum number of connections method can be called the average minimum number of connections method, which is particularly suitable for processing network requests with uncertain processing time. This method can ensure that no preset application server will become overloaded due to several long-running processes. On this basis, this embodiment may schedule network requests through the weighted minimum number of connections method, including: setting weights for the above-mentioned multiple preset application servers respectively, and allocating the current network request to the target application server according to the set weights and the current number of active connections. By taking the weight factor into account, a more intelligent load distribution can be achieved, so that the target application server receives an appropriate number of connections and network requests according to its actual processing capacity.

In the process of scheduling network requests based on application server resources, the dynamic acceleration routing scheduling engine obtains the current resource usage of the above-mentioned multiple preset application servers, and allocates the current network request to the preset application server with the lowest current resource utilization based on the current resource usage to prevent overloading of certain preset application servers; among which, the current resource usage in this embodiment includes CPU usage and memory usage, etc.

During the process of scheduling network requests using a hash calculation method, the dynamic acceleration routing scheduling engine obtains specific parameters, which may include the client IP address, request path, or session information, and then sends the network request to the corresponding preset application server based on a hash algorithm based on the specific parameters. The specific process of the hash algorithm can be selected from related technologies and will not be described in detail in this embodiment. The network request scheduling scheme based on the hash calculation method can ensure that network requests issued by the same client are always sent to the same preset application server. This scheme is suitable for applications with session persistence.

In the process of scheduling network requests by using a path hashing method, the dynamic acceleration routing scheduling engine can specifically hash the path of the network request to determine the route of the network request, thereby allocating the network request to the corresponding preset application server, and directing different URLs (Uniform Resource Locators) to specific preset application servers. In the process of scheduling network requests by using a domain name hashing method, the dynamic acceleration routing scheduling engine can specifically hash the domain name of the network request to determine the route of the network request, thereby allocating the network request to the corresponding preset application server, and directing different domain names to specific preset application servers. Of course, based on this embodiment, the network request scheduling algorithm can also be customized to meet specific business needs. For the above-mentioned multiple network request scheduling methods, this embodiment allows users to select the most appropriate scheduling method based on actual needs and the characteristics of the preset application server at the back end.

For critical operations such as network request scheduling, the embodiments of the present disclosure provide a secure computing environment through TEE, and critical operations including network request scheduling will not be interfered with by external malware or attackers.

In some optional implementations, network requests are scheduled by at least one of polling, minimum connection number, application server resource-based scheduling, hash calculation, path hash, and domain name hash, including but not limited to the following steps b1 and b2.

Step b1: Acquire response history information and current network status information of multiple preset application servers.

Among them, the response history information can indicate the response of the preset application server to the network request in the past period of time, and the current network status information can indicate the network connection status between the edge cloud server and the preset application server.

Step b2, according to the response history information and the current network status information, select one or more of the polling method, minimum connection number method, application server resource-based scheduling method, hash calculation method, path hash method, and domain name hash method to schedule the network request.

For example, if the historical response results of each preset application server to network requests are consistent, the minimum connection number method can be used according to the network conditions of the preset application servers; if the network conditions of the preset application servers are consistent, the polling method can be used; if the performance of different preset application servers varies greatly, the scheduling method based on application server resources can be used on the basis of the minimum connection number or polling method; if the network request contains specific parameters such as the client IP address, request path or session information, one or more of the hash calculation method, path hash method, and domain name hash method can be used on the basis of the minimum connection number or polling method.

The disclosed embodiments can use historical response information and current network status information as the basis for selecting various scheduling methods. This approach enables dynamic adjustment of traffic scheduling strategies to optimize traffic distribution. This demonstrates that the present embodiment can dynamically adjust traffic based on current network conditions and server load, achieving intelligent traffic distribution. Furthermore, the processing mechanism designed for high-traffic situations allows rapid adjustments to sudden traffic increases, ensuring network stability.

In some optional implementations, forwarding the network request to a target application server among multiple preset application servers according to a preset scheduling policy includes: encrypting the network request, and sending the encrypted network request to the target application server according to the preset scheduling policy.

Among them, this embodiment can encrypt network requests through a dedicated hardware accelerator configured on the edge cloud server.

In a trusted execution environment, this embodiment can encrypt relevant sensitive data including network requests and ensure the integrity of the code. Therefore, based on the solution provided by this embodiment, data security can be maintained even when data is transmitted in an unsafe environment.

Step S103: receiving a response result of the target application server to the network request, and forwarding the response result to the client.

Among them, the target application server is used to respond to the network request. The preset application server in this embodiment can respond to the received network request in the form of a service pool or instance, obtain a response result, and send the response result back to the edge cloud server.

In some optional implementations, forwarding the response result to the client includes: encrypting the response result, and sending the encrypted response result to the client.

It can be seen that this embodiment can further process the response result. The further processing process includes the above-mentioned encryption processing process, and may also include processing processes such as response header modification and compression, and then send the response result after the above-mentioned further processing to the client.

By encrypting the response results, the present disclosure can further improve the security of data transmission between the edge cloud server and the client.

The network request scheduling method for CDN provided in this embodiment provides a secure execution environment based on TEE technology for isolating sensitive computing tasks. The execution environment is independent of the edge cloud server host operating system and can prevent external attackers from accessing or modifying the code and data being executed. This embodiment schedules network requests according to a preset scheduling strategy in the trusted execution environment in the edge cloud server, and forwards the response results of the target application server to the network request to the client. Compared with related technologies, the solution provided by the present disclosure can distribute the request to the edge cloud server closer to the client by the dynamic acceleration gateway even when the edge cloud server is attacked maliciously. The edge cloud server performs load balancing on the network request, thereby optimizing the response time of the edge cloud server and improving reliability through the collaborative work of the edge cloud server and the dynamic acceleration gateway, thereby ensuring data security.

In this embodiment, a network request scheduling method for CDN is provided. The network request scheduling method is applied to a dynamic acceleration routing scheduling engine in an edge cloud server configured with a trusted execution environment. FIG2 is a flow chart of the network request scheduling method according to an embodiment of the present disclosure. As shown in FIG2 , the flow includes the following steps:

Step S201: Obtain a network request sent by a dynamic acceleration gateway. The network request is a security check performed by the dynamic acceleration gateway on a network request from a client and sent after the security check passes. Please refer to step S101 of the embodiment shown in FIG1 for details, which will not be repeated here.

Step S202: In the trusted execution environment, the network request is forwarded to a target application server among the plurality of preset application servers according to a preset scheduling policy. For details, please refer to step S102 of the embodiment shown in FIG1 , which will not be described in detail here.

Step S203: Receive the response result of the target application server to the network request and forward the response result to the client. Please refer to step S103 of the embodiment shown in Figure 1 for details, which will not be repeated here.

Step S204: Record the process of scheduling the network request in the trusted execution environment as a log file, and store the log file.

For example, this embodiment records key operations in a trusted execution environment, records them as log files, and stores the log files.

The network request scheduling method for CDN provided in this embodiment also records the process of scheduling network requests in a trusted execution environment as a log, which is crucial for subsequent analysis, auditing, and monitoring.

This embodiment also provides a method for tracking and troubleshooting using log files, as shown in FIG3 , which specifically includes:

Step c1: Obtain an anomaly detection request.

Anomaly detection requests can be obtained in different ways, including anomaly reports submitted by users, alerts from monitoring systems, automated error detection mechanisms, or output from other anomaly detection systems.

Step c2: query the target log file associated with the anomaly detection request.

Specifically, according to the identifier or related information of the anomaly detection request, the target log file related to the request can be searched and obtained through the system's log management tool or query interface.

Step c3: Analyze the target log file to obtain the scheduling path of the corresponding target network request, and obtain the processing status of each node in the scheduling path in processing the target network request.

Specifically, the target log file must first be parsed. Based on the parsed log data, the unique identifier of the target network request is determined. This can be a request ID, URL, IP address, or other request-related identifier. Using the request identifier, the dispatch path of the request is tracked within the log data. This is achieved by searching for each record of the request in the log and the associated information within it. For example, the corresponding log record can be found based on the request ID, along with the node ID or name within the record.

Based on the traced dispatch path, the processing status of each node is determined. This includes processing time, response status code, error information, and more. This information can be extracted by analyzing relevant fields or flags in the log records. The processing status of each node is collated and summarized, and the data is stored in a data structure for subsequent processing and analysis.

Step c4: perform anomaly detection according to the processing situation to obtain a detection result.

Specifically, the obtained processing data is compared with anomaly detection rules or indicators to generate a judgment. This can be based on threshold comparisons, such as response time exceeding a certain threshold, or rule-based verification, such as error codes not matching expectations. Ultimately, based on the comparison and judgment results, anomaly detection results are generated. For example, abnormal requests may be marked as abnormal, anomaly reports may be generated, or alerts may be set.

In summary, by querying the target log file associated with anomaly detection requests, this application can locate the specific log file at the time the anomaly request was generated, facilitating subsequent analysis and processing. Analyzing the target log file to obtain the dispatch path provides a global perspective on network requests. Then, based on the evaluation and judgment of the processing status of each node in the path, anomaly detection results and reports are quickly generated, helping system administrators or developers to quickly respond to and resolve issues.

For example, the target log file records information related to video services. By analyzing this log file, the scheduling path of video network requests can be obtained, and the processing status of each node can be analyzed to detect anomalies.

According to the log file, the scheduling path for the video network request is as follows: Node1-Node2. The processing status of each node is as follows: Node1: Processing time is 2.1 seconds, response status code is 200, and there is no error message. Node2: Processing time is 3.6 seconds, response status code is 200, and there is no error message.

Based on the processing situation, we perform anomaly detection and obtain the following results: Node1's processing time is within the normal range and is normal. Node2's processing time is longer, which may indicate an anomaly. Therefore, the detection results indicate that Node2 and Node3 have anomalies.

As shown in Figure 4, the dynamic acceleration gateway, the dynamic acceleration routing scheduling engine based on the trusted execution environment (i.e., the dynamic acceleration routing scheduling engine in the aforementioned embodiment), and the dynamic balancing log service can all be deployed on the dynamic acceleration gateway of the edge cloud server. The dynamic acceleration routing scheduling engine of this embodiment can automatically expand and integrate functions with the edge cloud platform, and dynamically adjust back-end resources according to changes in traffic. The dynamic acceleration routing scheduling engine in this embodiment can also perform self-repair. When it detects that a service provided by the preset application server at the back end fails, it automatically reroutes traffic to ensure the continuous operation of the business. In addition, the dynamic acceleration routing scheduling engine can also be integrated with a network application firewall (WAF, Web Application Firewall) to provide traffic monitoring and attack defense at the security level.

Specifically, the network request scheduling method for CDN of this embodiment may include the following steps:

In step S401, a network request sent by a client (e.g., a browser or application on an electronic device) to an edge cloud server first reaches a dynamic acceleration gateway (dynamic acceleration gateway). This means that the user's access to the service reaches the dynamic acceleration gateway, which is responsible for receiving these network requests and parsing them according to predefined rules (e.g., URL path, request type, etc.). The dynamic acceleration gateway can perform preliminary processing on network requests, such as SSL (Secure Sockets Layer) terminal inspection, request inspection, and logging. This stage may also include security checks on the requests, such as preventing DDoS (Distributed Denial of Service attack) and SQL (Structured Query Language) injection, to ensure that only legitimate and secure requests are further processed.

In step S402 , the dynamic acceleration gateway forwards traffic to the dynamic acceleration routing scheduling engine based on the trusted execution environment. That is, the dynamic acceleration gateway forwards the network request to the dynamic acceleration routing scheduling engine based on the trusted execution environment.

In step S403, the dynamic acceleration routing scheduling engine executes the scheduling algorithm in the trusted execution environment, sends the network request to the target application server for processing, receives the response result from the target application server, and feeds back the response result to the corresponding client to complete the network request scheduling.

In the secure environment of the trusted execution environment, the core function of the dynamic acceleration gateway can be executed, that is, the traffic scheduling logic can be implemented. Even if the edge cloud server host operating system is compromised by malware, the traffic scheduling logic in the trusted execution environment will not be affected.

Step S404: Based on the dynamic balancing log service, the dynamic acceleration routing scheduling engine records the trusted execution environment scheduling log.

In summary, the present disclosure uses TEE technology to protect the dynamic acceleration routing scheduling engine, making it run more securely in a multi-cloud environment including an edge cloud environment. Especially in cases where it needs to be deployed in other data centers or edge computer rooms outside the central cloud, the present disclosure can effectively reduce the interference of malware or attackers on the dynamic acceleration service. Even if the malware infects the operating system (subject to operating system-level threats), the scheduling decisions provided by the present disclosure are safe and reliable. It can be seen that the present disclosure significantly improves service reliability and security, especially improves the security and reliability of traffic scheduling by edge cloud servers; the present disclosure is suitable for scenarios with extremely high security requirements, such as financial service data, sensitive data processing, etc.

FIG5 is a flow chart of a method for scheduling network requests for a CDN according to an embodiment of the present disclosure. As shown in FIG5 , the method is applied to a dynamic acceleration gateway, and the method includes:

Step S501: Obtain a network request sent by a client.

The dynamic acceleration gateway is deployed as an intermediate layer between the client and the edge cloud server. The client sends a network request to the dynamic acceleration gateway, and the request data is transmitted to the dynamic acceleration gateway through the network communication protocol.

Step S502: parse the network request to determine the request type corresponding to the network request, and query the security check policy corresponding to the request type.

Step S502 includes: obtaining a request header from the network request; parsing the request header to obtain the fields contained therein and obtain a request identifier; and obtaining the request type corresponding to the request identifier. Parsing and security checking the network request quickly determines the request type and security. This allows for the shortest possible initial processing and a decision on whether to send the request to the edge cloud server for dispatch. Rapid response improves user experience and system performance.

Specifically, when a client sends a network request, a request header is sent along with the request. The dynamic acceleration gateway can obtain the request header from the received request data and parse it to extract the fields within. The request header contains metadata and other information related to the request. It can include multiple fields, each with a specific purpose. Common request header fields include User-Agent, Accept, and Content-Type, which provide detailed information about the client and the request content. The dynamic acceleration gateway can parse the request header and obtain the specific values of each field. For example, the User-Agent field can be parsed to obtain information about the client's browser and operating system. The Accept field can also be parsed to obtain the content type accepted by the client. Furthermore, a custom request identifier field can be added based on business needs and parsed to obtain the request identifier. The request identifier is typically used to uniquely identify a request for subsequent identification and processing. Depending on specific needs, the request identifier can be extracted from a specific field in the request header or from a custom request identifier field. By extracting the request identifier, the dynamic acceleration gateway can identify, route, or perform other processing operations on the request in subsequent processing. By parsing the request header and extracting the field content, the dynamic acceleration gateway can flexibly process according to the client's needs and specific business logic, providing personalized services and enhanced functions.

By obtaining the request identifier, the dynamic acceleration gateway can determine the corresponding request type. This is achieved through matching, mapping, or querying operations. Request types can be categorized based on business needs, such as GET, POST, and PUT. Based on the request identifier, the request type can be associated with specific processing logic or routing.

Step S503: Perform a security check on the request content carried by the network request using the security check policy to obtain a preliminary request processing result.

For example, a client submits a request to query user personal information through an application. The request includes the user ID or username to be queried. After receiving the query request, the dynamic acceleration gateway first executes the security check policy.

Security Check Strategy 1: Verify client permissions. The Dynamic Acceleration Gateway verifies the access credentials (such as access tokens and user IDs) included in the request and checks whether the client has permission to query other users' personal information. If verification fails or the client lacks permission, the query request is rejected and an error message is returned to the client, prompting the client to log in again or obtain the appropriate permissions.

If the verification is successful and the query permission is granted, the next security check policy is executed.

Security Check Strategy 2: Verify the legitimacy of query parameters. The dynamic acceleration gateway verifies parameters such as the client ID or operation identifier carried in the query request to ensure that the parameters comply with the specified format and requirements.

If the query parameters are illegal or pose a potential security risk, the query request will be rejected and an error message will be returned to the client, prompting the client to re-enter valid query parameters.

If the query parameters are valid, the next security check policy is executed.

Security Check Policy 3: Sensitive Information Filtering. The Dynamic Acceleration Gateway filters sensitive information in query results based on security policies to ensure that no potential privacy leaks or security risks are returned. If query results contain sensitive information, the Dynamic Acceleration Gateway will desensitize it or only return authorized information.

In step S504, if the preliminary processing result of the request is a legal result, the corresponding edge cloud server is determined according to the network environment information of the client, and the network request is sent to the dynamic acceleration routing scheduling engine in the edge cloud server to schedule the network request through the edge cloud server.

Specifically, if the initial processing result of the request is legal, it means that the network request has passed the security check policy and is legal and secure. Next, the dynamic acceleration gateway determines the corresponding edge cloud server based on the client's network environment information and sends the network request to the dynamic acceleration routing scheduling engine in the edge cloud server for scheduling and processing.

When determining the most suitable edge cloud server, the dynamic acceleration gateway considers the client's network environment information, including geographic location and network conditions. Based on this information, it selects the nearest edge cloud server to provide services. First, the dynamic acceleration gateway uses the client's geographic location to determine the nearest edge cloud server. Edge nodes are typically located in different regions, and the closer they are to the client's geographic location, the lower the network latency. By comparing the client's geographic location with the location of the edge node, the dynamic acceleration gateway can find the nearest edge cloud server. Second, the dynamic acceleration gateway also selects the optimal network path based on the client's network conditions. It monitors network latency, bandwidth, packet loss rate, and other metrics between the client and each edge cloud server. By evaluating these metrics, it selects the network path with the best performance, ensuring low latency and high bandwidth for the client.

Once the nearest edge cloud server and optimal network path are determined, the dynamic acceleration gateway routes the client's request to that edge cloud server. The edge cloud server can be scheduled based on specific business needs, such as forwarding requests to the nearest application server, performing load balancing based on load, or caching based on content. This allows clients to receive faster response times from the edge cloud server.

In summary, the dynamic acceleration gateway accelerates and optimizes edge services by comprehensively considering the client's geographic location and network conditions, selecting the nearest edge cloud server and the optimal network path. This approach enables efficient access and effective utilization of edge computing resources.

The disclosed dynamic acceleration gateway obtains and parses the network request sent by the client, and can perform security checks on the request. It can prevent malicious requests or attacks and improve the security of the system. By determining the request type corresponding to the request and querying the corresponding security check policy, a detailed security check can be performed on the request content according to the security check policy, thereby providing more comprehensive security protection. Then, the appropriate edge cloud server is determined based on the client's network environment information, which can minimize latency and improve system performance. Sending network requests to the nearest edge cloud server can reduce the distance and time of data transmission, thereby improving the response speed and performance of the application. In addition, the edge cloud server can distribute requests to the back-end server based on the load balancing algorithm and other strategies to further optimize the load balancing and performance of the system.

In summary, the technical solution of acquiring client network requests and parsing them for security checks offers the advantages of enhanced security, rapid response, and edge cloud server scheduling. It also offers flexibility and scalability to adapt to diverse business and system requirements. Furthermore, scheduling based on client network environment information can improve CDN security, performance, and load balancing capabilities.

This embodiment also provides a network request scheduling device for a CDN. This device is used to implement the above-mentioned embodiments and preferred implementations. Details that have already been described will not be repeated. As used below, the term "module" may refer to a combination of software and/or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.

This embodiment provides a network request scheduling device for CDN. The network request scheduling device is deployed in a dynamic acceleration routing scheduling engine applied to an edge cloud server configured with a trusted execution environment. As shown in FIG6 , the network request scheduling device includes:

The acquisition module 601 is used to acquire a network request sent by the dynamic acceleration gateway. The network request is sent by the dynamic acceleration gateway after the dynamic acceleration gateway performs a security check on the network request from the client and passes the security check.

The scheduling module 602 is configured to forward the network request to a target application server among a plurality of preset application servers according to a preset scheduling policy in a trusted execution environment.

The response module 603 is used to receive the response result of the target application server to the network request, and to forward the response result to the client.

In some optional implementations, the network request scheduling device further includes a logging module.

The logging module is used to record the process of scheduling network requests in the trusted execution environment as a log file, and to store the log file.

In some optional implementations, the preset scheduling strategy includes at least one of a polling method, a minimum connection number method, a scheduling method based on application server resources, a hash calculation method, a path hash method, and a domain name hash method.

The scheduling module 602 is specifically used to schedule network requests through at least one of polling, minimum connection number, application server resource-based scheduling, hash calculation, path hash, and domain name hash to schedule network requests to the target application server.

In some optional implementations, the network request scheduling apparatus further includes:

The environment creation module is used to create a trusted execution environment on the dynamic acceleration gateway in the edge cloud server.

The signature verification module is used to verify the signature of the execution code corresponding to the preset scheduling strategy.

The code execution module is used to execute the execution code in a trusted execution environment based on the signature verification of the execution code.

The execution rejection module is used to reject the execution code from running in the trusted execution environment based on the signature of the execution code failing to pass the verification.

In some optional implementations, the scheduling module 602 is further configured to encrypt the network request and send the encrypted network request to the target application server according to a preset scheduling policy.

The response module 603 is further configured to encrypt the response result and send the encrypted response result to the client.

In some optional embodiments, the network request scheduling device also includes: an anomaly detection module, used to obtain an anomaly detection request; query the target log file associated with the anomaly detection request; analyze the target log file to obtain the scheduling path of the corresponding target network request, and obtain the processing status of each node in the scheduling path processing the target network request; perform anomaly detection based on the processing status to obtain a detection result.

This embodiment also provides a network request scheduling device for a CDN. This device is used to implement the above-mentioned embodiments and preferred implementations. Details that have already been described will not be repeated. As used below, the term "module" may refer to a combination of software and/or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.

This embodiment provides a network request scheduling device for CDN, as shown in FIG7 , the network request scheduling device includes:

Receiving module 701, used to obtain the network request sent by the client;

The parsing module 702 is used to parse the network request to determine the request type corresponding to the network request and query the security check policy corresponding to the request type;

The inspection module 703 is used to perform a security inspection on the request content carried by the network request using the security inspection strategy to obtain a preliminary processing result of the request.

The sending module 704 is used to determine the corresponding edge cloud server according to the network environment information of the client if the preliminary processing result of the request is a legal result, and send the network request to the dynamic acceleration routing scheduling engine in the edge cloud server to schedule the network request through the edge cloud server.

In some optional implementations, the parsing module 702 is configured to obtain a request header in a network request; parse the request header to obtain field contents contained in the request header, and obtain a request identifier; and obtain a request type corresponding to the request identifier.

Please refer to Figure 8, which is a structural diagram of a computer device provided by an optional embodiment of the present disclosure. As shown in Figure 8, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components are connected to each other using different buses and can be installed on a common motherboard or installed in other ways as needed. The processor can process instructions executed in the computer device, including instructions stored in or on the memory to display graphical information of the GUI on an external input/output device (such as a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and/or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides part of the necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system).

The processor 10 may be a central processing unit, a network processor, or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic, or any combination thereof.

The memory 20 stores instructions that can be executed by at least one processor 10, so as to enable at least one processor 10 to execute the method shown in the above embodiment.

The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and application programs required for at least one function; the data storage area may store data created based on the use of the computer device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid-state drive; the memory 20 may also include a combination of the above types of memory.

The computer device further includes a communication interface 30 for the computer device to communicate with other devices or a communication network.

The embodiments of the present disclosure also provide a computer-readable storage medium. The above-mentioned method according to the embodiments of the present disclosure can be implemented in hardware, firmware, or implemented as a computer code that can be recorded in a storage medium, or implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and downloaded through a network and will be stored in a local storage medium, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state drive, etc.; further, the storage medium can also include a combination of the above-mentioned types of memory. It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor or hardware, the method shown in the above embodiment is implemented.

Although the embodiments of the present disclosure have been described with reference to the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations are all within the scope defined by the appended claims.

Claims (11)

A network request scheduling method for CDN, the method being applied to a dynamic acceleration routing scheduling engine in an edge cloud server configured with a trusted execution environment, the method comprising: Obtaining a network request sent by a dynamic acceleration gateway, wherein the network request is a network request from a client that the dynamic acceleration gateway performs a security check on and sends after passing the security check; In the trusted execution environment, forwarding the network request to a target application server among a plurality of preset application servers according to a preset scheduling policy; Receive a response result of the target application server to the network request, and forward the response result to the client. The method according to claim 1, further comprising: The process of scheduling the network request in the trusted execution environment is recorded as a log file, and the log file is stored. The method according to claim 1, wherein, before obtaining the network request sent by the dynamic acceleration gateway, the method further comprises: Creating the trusted execution environment in the edge cloud server; Verifying the signature of the execution code corresponding to the preset scheduling policy; If the signature of the execution code passes the verification, running the execution code in the trusted execution environment; If the signature of the execution code fails to pass the verification, the execution code is refused to run in the trusted execution environment. The method according to claim 1, wherein Forwarding the network request to a target application server among a plurality of preset application servers according to a preset scheduling policy includes: encrypting the network request, and sending the encrypted network request to the target application server according to the preset scheduling policy; The forwarding the response result to the client includes: encrypting the response result, and sending the encrypted response result to the client. The method according to claim 1, further comprising: Get anomaly detection request; Querying the target log file associated with the anomaly detection request; Analyze the target log file to obtain a scheduling path for the corresponding target network request, and obtain a processing status of each node in the scheduling path for processing the target network request; Anomaly detection is performed according to the processing situation to obtain a detection result. A network request scheduling method for CDN, the method being applied to a dynamic acceleration gateway, the method comprising: Get the network request sent by the client; Parsing the network request to determine the request type corresponding to the network request, and querying the security check policy corresponding to the request type; Performing a security check on the request content carried by the network request using the security check strategy to obtain a preliminary request processing result; If the preliminary processing result of the request is a legal result, the corresponding edge cloud server is determined according to the network environment information of the client, and the network request is sent to the dynamic acceleration routing scheduling engine in the edge cloud server to schedule the network request through the edge cloud server. The method according to claim 6, wherein the parsing of the network request to determine the request type corresponding to the network request comprises: Obtaining a request header in the network request; Parsing the request header to obtain the field content contained in the request header and obtain a request identifier; Get the request type corresponding to the request identifier. A network request scheduling device for CDN, wherein the device is deployed in a dynamic acceleration routing scheduling engine applied to an edge cloud server configured with a trusted execution environment; the device comprises: An acquisition module, configured to acquire a network request sent by a dynamic acceleration gateway, wherein the network request is a network request from a client that is subjected to a security check by the dynamic acceleration gateway and is sent after passing the security check; A scheduling module, configured to forward the network request to a target application server among a plurality of preset application servers in the trusted execution environment according to a preset scheduling policy; The response module is used to receive the response result of the target application server to the network request, and to forward the response result to the client. A network request scheduling device for CDN, the device being applied to a dynamic acceleration gateway in an edge cloud server, comprising: Receiving module, used to obtain the network request sent by the client; A parsing module, configured to parse the network request to determine a request type corresponding to the network request, and query a security check policy corresponding to the request type; The inspection module is used to perform a security inspection on the request content carried by the network request using the security inspection strategy to obtain a preliminary processing result of the request. A sending module is used to determine the corresponding edge cloud server based on the network environment information of the client if the preliminary processing result of the request is a legal result, and send the network request to the dynamic acceleration routing scheduling engine in the edge cloud server to schedule the network request through the edge cloud server. A computer device comprising: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the network request scheduling method for CDN according to any one of claims 1 to 7 by executing the computer instructions. A computer-readable storage medium having computer instructions stored thereon, wherein the computer instructions are used to enable a computer to execute the network request scheduling method for CDN according to any one of claims 1 to 7.