How to Connect to a CDN: 3 Types of CDN Scheduling Systems

What are CDN Scheduling Systems?

CDN Scheduling Systems are intelligent mechanisms that optimize content delivery by efficiently routing user requests to the most suitable edge servers. These systems use advanced algorithms to determine the best server for each request based on multiple factors:

• Geographic proximity to the user
• Current server load and health status
• Network conditions and performance
• Available server resources

The scheduling system acts as the brain of a CDN, performing two critical functions:

1. Smart Request Routing: Automatically directs user requests to the optimal edge server to minimize latency and ensure fast content delivery.
2. Load Distribution: Balances traffic across multiple servers to prevent overload, maintain high availability, and provide seamless failover when issues occur.

This intelligent routing and load balancing ensures reliable content delivery while maximizing network efficiency and maintaining consistent performance for users worldwide.

How to Connect to a CDN?

Before explaining the scheduling principle, let's take a look at how customers access CDN, or how the customer's traffic input and switching to CDN. Assuming the customer's domain name is: www.test.com, there are roughly the following ways.

1. CNAME Method

The CNAME method is the most common access method, that is, the CDN manufacturer provides a scheduling domain name to the customer, and the customer sets the CNAME of their business domain name to this scheduling domain name, thereby realizing the request to be guided to the CDN.

For example, if your website domain is www.test.com and your CDN provider assigns you www.test.cdn.example.com as the scheduling domain name, you would simply set up a CNAME record pointing www.test.com to www.test.cdn.example.com. Once configured, all requests to your website will be automatically routed through the CDN network.

Behind the CNAME method, there are several modes:

• The CDN manufacturer provides DNS-based scheduling, and the customer's domain name is finally resolved to the CDN node's IP through the CDN's scheduling domain name. 
• The CDN manufacturer provides 302-based scheduling, and the CNAME provided is not a real CDN node, but a scheduling cluster. The real CDN IP address is realized by responding to the request with a 302 redirect on the scheduling cluster.
• Another one is Anycast. From the perspective of the CDN layer, the CNAME provided by the CDN manufacturer has only one or two IP addresses fixed worldwide. Unlike mode 1, the IP resolution results in different regions are different. In this scenario, traffic scheduling is not based on DNS resolution but on Anycast BGP route adjustment. The traffic in various regions is adjusted to which machine room by adjusting the Anycast route.

2. Deep Customization of Scheduling Domain Names

Deep customization of scheduling domain names enables resellers and enterprise customers to maintain brand independence while leveraging CDN services. Through a multi-level CNAME configuration, providers can mask their CDN infrastructure at the DNS level. This setup involves creating a chain where the customer's domain points to a branded intermediary domain, which then connects to a neutral platform domain. For example, when www.test.com points to gslb.mycdn.com, which in turn points to gslb.cdn-platform.com, the entire DNS resolution process remains provider-agnostic, offering complete white-labeling capabilities for CDN resellers.

3. Domain Name Hosting Method

This mode is uncommon. Taking the domain name www.test.com as an example, if the customer needs to switch the request to CDN, they need to change the NS record of test.com to the NS authoritative server provided by the CDN manufacturer. At this time, the CDN manufacturer plays the role of both the DNS service provider and the CDN service provider.

Detailed Explanation of CDN Scheduling Methods

1. DNS Scheduling

The scheduling server of the CDN is the NS authoritative server for the scheduling domain, and the TTL of the scheduling domain is deliberately set to be very short. (e.g., three minutes). This ensures that all requests frequently trigger the client's local DNS to resolve a new IP address from the CDN's scheduling server. At this point, the scheduling server relies on the exit address of the local DNS. The DNS scheduling process is as follows:

1. The client's DNS TTL expires without first access and initiates a DNS query to the local DNS.
2. The local DNS, in the process of recursive resolution, initiates a resolution request to the CDN scheduling server.
3. The CDN scheduling server can see the exit IP of the local DNS. (Sometimes also the client IP is based on EDNS.)
4. Through the IP library, obtain the geographical and operator attributes of the IP in the previous step, match the policy rules of the current scheduling domain, and combine other factors (such as quality monitoring, data center cost factors, etc.) to get the best set of IPs.

Scenario:

DNS Scheduling Principle:

1. The browser initiates the first request for the target URL. There is no p73.ping.dnsv1.com resolution record locally, so it sends a request to the DNS server (also known as local DNS) 202.96.134.133.
2. If 202.96.134.133 (the actual server behind this IP) has no local cache, it initiates a recursive resolution, eventually resolving to 388957.p23.tc.cdntip.com. The resolution request is sent to the authoritative server ns-open3.qq.com for cdnip.com. Ns-open3.qq.com is not a physical server but a virtual IP on the network. To simplify the description, let's assume that the actual DNS authoritative server (or cluster) behind it has an IP of 10.1.1.1.
3. The information currently available to 10.1.1.1 includes the domain name 388957.p23.tc.cdnip.com and the local DNS IP 202.96.136.240. If the local DNS supports EDNS, the client IP 113.87.117.154 can also be seen at this time. With these three pieces of information, the scheduling server can obtain the result through the algorithm.
4. 202.96.134.133 returns the IP result to the client, and the browser initiates an HTTP request to one of the IPs according to its own policy.

Advantages and Disadvantages of DNS Scheduling:

2. 302 Scheduling

Now let's see what's different between the 302 mode and the previous DNS scheduling.

(http://p73.ping.dnsv1.com/a.php)

In the DNS resolution scheduling mode, when the browser accesses the above URL, under normal circumstances, it will receive a return code 200 and file content from the CDN node, which means the IP resolved by DNS will directly act as the file server responding to the browser request. It's similar to:

HTTP/1.1 200 OK

Server: NWS_S1

Connection: keep-alive

Date: Sun, 11 Dec 2018 19:44:02 GMT

Transfer-Encoding: chunked

Keep-Alive: timeout=120

X-Daa-Tunnel: hop_count=2

X-NWS-LOG-UUID:750246221628030518 0be2170ce2df3d9f634cd70470120401

\r\r\r\n File Content

However, in the 302 redirect mode, when accessing the above URL, the browser will receive a response with a status code of 302:

HTTP/1.1 302 Moved Temporarily

Server: stgw/1.3.6.2_1.13.5

Date: Sun, 16 Dec 2018 19:38:58 GMT

Content-Type: text/html

Content-Length: 168

Connection: keep-alive

Location: http://61.142.166.245/p73.ping.dnsv1.com/a.php

This means telling the browser that it needs to continue to request the actual file content from the URL in the Location. So the browser initiates the second request:

http://61.142.166.245/p73.ping.dnsv1.com/a.php

The IP address in this URL is the CDN node allocated by the CDN scheduling system. Let's see how this IP is obtained.

The process of domain name resolution in 302 redirect mode is the same as DNS-based scheduling, and a group of IPs will be obtained in the end. There are two possible situations for the target IP: 1) The target IP is not the actual edge node of the CDN, but the IP of the 302 scheduling cluster; 2) The IP is a common edge node IP of the CDN.

1. The browser initiates an HTTP request to the first IP obtained.
2. If this IP is actually an edge node of the CDN, it will read information from the local configuration file: 
   ● If the requested Host is not an IP, the URL form is: http://p73.ping.dnsv1.com/a.php, then the request will be forwarded to the backend scheduling cluster; 
   ● If the requested Host is an IP, the URL form is: http://61.142.166.245/p73.ping.dnsv1.com/a.php, then it will read from the cache to provide file services.
3. At this point, the request has reached the scheduling cluster, and the client information we can get is the client's exit IP. (In most cases, they are the same.)
4. The next algorithm and DNS-based scheduling can be the same, it's just that the judgment basis has changed from the local DNS exit IP to the client's exit IP. (After all, the scheduling cluster is not a CDN node and cannot provide the actual file content to the client, at this point it can only inform the client through a 302 message.)
5. The browser receives the 302 response, follows the URL in the Location, and continues to initiate an HTTP request. The target IP of this request is the CDN edge node, and the Host is an IP. The CDN node will respond with the actual file content.

Therefore, 302 is only suitable for large file download services with good client compatibility.

3. Routing Scheduling

Anycast routing technology allows physically distributed servers across the globe or different regions to have the same IP address. Client requests for this IP will be guided to the nearest physical server at the routing level.

Anycast BGP routing scheduling mode is similar in appearance to DNreal timeS scheduling:

• The business domain name is resolved to the CDN scheduling domain name through CNAME
• The IP resolved by the CDN scheduling domain name is the edge node IP, and the request will not undergo a 302 redirect

However, there are also unique features:

• The number of global IP addresses in the resolution result is very small, usually only 1-2, or 1-2 for a continent or a large area
• The TTL of DNS is usually very large, often configured to be 2 hours or even longer

Advantages and disadvantages of Anycast routing scheduling:

Conclusion

Tencent EdgeOne, as a next-generation CDN, not only provides acceleration but also offers advanced CDN and scheduling policies. These allow for a flexible and efficient way to manage network traffic, which ultimately contributes to a more reliable and faster user experience. Here's an extension of more CDN Scheduling services EdgeOne can provide:

• Simple Management: With EdgeOne, all you need to do is select a domain name, add service providers, and add scheduling policies. This easy process ensures you focus more on your core business instead of worrying about CDN management.
• Quick Access: By adding the CNAME record assigned by EdgeOne at your DNS service provider, you can swiftly access your content whenever you want.
• Scheduling Modes: EdgeOne supports ratio-based and region-based scheduling. Ratio-based scheduling allows you to distribute your traffic based on certain set ratios for effective load balancing. At the same time, region-based scheduling enables you to direct users to the closest or best-performing server locations, effectively reducing latency.
• Multiple Scenarios: With EdgeOne, flexibility is key. You can use either the origin or services provided by other CDN vendors. This allows for a canary switch – a testing strategy where new versions of a software are gradually deployed for verifications and rollbacks in case of errors. On top of that, you can use services from different vendors at the same time.

EdgeOne offers competitive pricing plans that deliver excellent value for businesses of all sizes. To help you make an informed decision about CDN costs and compare different providers' pricing, check out our comprehensive guide on Cheap CDN Services 2025, where we analyze and compare the most cost-effective CDN solutions available in the market.

Ready to experience enterprise-grade acceleration and security? Start your 14-day free trial with EdgeOne today and get 1TB of data transfer included.