16 How to Speed Up Cdn Static Resources

16 How to Speed Up CDN Static Resources #

Hello, I am Tang Yang.

In the previous lessons, I introduced you to the definition of cache and the common practices of using cache. Now, you should have a certain understanding of the applicable scenarios and techniques for using cache components such as local cache and distributed cache. Combining with the client high availability solution mentioned in Lecture 14, you can expand a single cache node into a highly available cache cluster. Now, your e-commerce system architecture has evolved into the following:

In this architecture, we use distributed cache to accelerate the reading of dynamic request data. However, there are a large number of static resource requests in our system:

For mobile apps, these static resources mainly include images, videos, and streaming media information.
For web sites, they include JavaScript files, CSS files, static HTML files, and so on.

Specifically for your e-commerce system, the product images, videos that demonstrate how to use the products, and other static resources are now stored on Nginx and other web servers. The read request volume for these resources is extremely high, and there is a high requirement for access speed. They also occupy a high amount of bandwidth. This may result in slow access speed and bandwidth being fully occupied, thereby affecting dynamic requests. In this case, you need to consider how to accelerate the reading of these static resources.

Considerations for static resource acceleration #

You may ask, “Can we also use distributed caching to solve this problem?” The answer is no. Generally, the size of images and videos can range from a few megabytes to several gigabytes. If our application servers and distributed cache are deployed in Beijing, when a user from Hangzhou wants to access a video in the cache, the video file needs to be transmitted from Beijing to Hangzhou, passing through multiple public backbone networks. The latency would be very high and users would perceive the video as loading slowly, seriously impacting their user experience.

Therefore, the key point of accessing static resources is proximity, i.e., Beijing users access Beijing’s data, Hangzhou users access Hangzhou’s data. Only in this way can optimal performance be achieved.

You may say, “Then why don’t we build a data center in Hangzhou so that users can access data from that data center?” But users are distributed throughout the country, and some applications may even have users from overseas. It is not feasible to build data centers in every region, as it would be too expensive.

In addition, individual videos, images, and other static resources are large in size, and their access volume is extremely high. If we rely on business servers and distributed caching to handle this traffic, it would put a great strain on both the internal and external network bandwidth.

Therefore, we consider adding a special layer of caching on top of the business servers to handle the majority of static resource access. These special caching nodes need to be distributed throughout the country, allowing users to choose the nearest node for access. The cache hit rate also needs to be guaranteed, minimizing the number of requests to the resource storage source site (origin server). This layer of caching is the focus of this lesson: CDN.

Key Technologies of CDN #

CDN (Content Delivery Network/Content Distribution Network) is a technology that distributes static resources to servers located in multiple geographical data centers. It effectively solves the problem of accessing data nearby and speeds up the access to static resources.

CDN is widely used in large and medium-sized companies. Big companies choose to build their own CDN to provide more stable CDN services. However, most companies choose professional CDN vendors due to cost considerations. Some mainstream CDN vendors in the industry include Wangsu, ChinaNetCenter, Alibaba Cloud, Tencent Cloud, and BlueCamp. Alibaba Cloud and Tencent Cloud are cloud service providers, so if your services are deployed in the cloud, you can choose CDN services provided by the corresponding cloud service providers.

You may have heard of CDN from the perspective of operations and understood its role. However, when it comes to configuring CDN or troubleshooting CDN-related issues, you may feel at a loss because you don’t understand its principles.

So, let me first explain to you the two key considerations for building a CDN system:

How to map user requests to CDN nodes.
How to select the nearest nodes based on users’ geographical location information.

Now let’s take a closer look at how CDN systems accelerate user requests for static resources.

1. How to route user requests to CDN nodes #

First, let’s consider how to route user requests to CDN nodes. You might think it’s simple - just tell users the IP address of the CDN node and request the CDN service deployed on that IP address. However, there is a problem with this approach. If we are using a third-party CDN service, the CDN vendor will provide us with a CDN node IP, such as “111.202.34.130”. The URL of images in our e-commerce system may be “http://111.202.34.130/1.jpg”, and this address is stored in the database.

What if the node IP changes? Or if we change the CDN vendor, do we need to modify the URL domain for all products? This would be a significant amount of work. So, what we need to do is hide the IP provided by the third-party CDN vendor and provide users with a subdomain under our own domain.

How do we achieve this? We rely on DNS to solve the domain mapping problem.

DNS (Domain Name System) is a distributed database that stores the mapping between domain names and IP addresses. Domain name resolution generally has two types of results: “A records,” which return the IP address corresponding to a domain name, and “CNAME records,” which return another domain name. This means that the resolution of the current domain name needs to be redirected to the resolution of another domain name. In fact, the resolution result of the domain name “www.baidu.com” is a CNAME record. The resolution of the domain name is redirected to “www.a.shifen.com”. We use CNAME records to solve the domain mapping problem. Let me give you an example of how this is done.

Suppose your company’s top-level domain is example.com. You can define the domain name for your image service as “img.example.com” and configure the CNAME resolution of this domain name to the CDN-provided domain name, such as “80f21f91.cdn.ucloud.com.cn”. This way, the image URLs used in your e-commerce system can be “http://img.example.com/1.jpg".

When a user requests this address, the DNS server will resolve the domain name to “80f21f91.cdn.ucloud.com.cn” and then resolve this domain name to the IP of the CDN node, allowing access to the resources on the CDN.

However, there is a problem with this approach. Since the domain name resolution process is hierarchical, each level has dedicated domain name servers responsible for resolution, and the domain name resolution process may require multiple DNS queries across the public network, which is not very efficient in terms of performance.

From the “Domain Name Hierarchical Resolution Diagram,” you can see that DNS is divided into many types, including Root DNS, Top-level DNS, etc. In addition, there are two types of DNS that need special attention: Local DNS, provided by your ISP, which is usually the first stop for domain name resolution; and authoritative DNS, which means DNS that stores the corresponding relationship between the domain name and the IP address in its own database.

Now let me briefly explain the process of domain name resolution using the example of the domain name “www.baidu.com”. At the beginning, the domain name resolution request first checks the local hosts file to see if there is an IP corresponding to www.baidu.com.

If not, it requests the Local DNS to see if there is a cached domain name resolution result. If there is, it returns the result, indicating that it is from a non-authoritative DNS.

If not, it begins the iterative query of DNS. First, it requests the root DNS, which returns the address of the top-level DNS (.com). Then it requests the .com top-level DNS to obtain the domain name server address of baidu.com. Then it queries the IP address corresponding to www.baidu.com from the domain name server of baidu.com. It returns this IP address and marks the result as from the authoritative DNS. At the same time, it writes the resolution result of the Local DNS cache so that the DNS iterative query is not needed for the next resolution of the same domain name.

After querying multiple DNS servers, the entire DNS resolution process can take up to seconds. So how do we solve this performance problem?

One solution is: Perform pre-resolving of the domain name when the APP starts, and then cache the resolved result in a local LRU cache. So when we need to use this domain name, we can directly obtain the required IP address from the cache. Only if the cache does not exist will the entire DNS query process be performed. At the same time, to avoid invalidation of data in the cache due to changes in DNS resolution results, we can start a timer to periodically update the data in the cache.

I have tested this method, and the improvement in response time for HTTP requests is significant. Previously, DNS resolution time often exceeded 1 second. With this method, DNS resolution time can be kept within 200ms, reducing the entire HTTP request process by about 80ms to 100ms.

To summarize, mapping the user’s request to the CDN server is a core issue that needs to be solved when using CDN, and the CNAME record can act as an intermediate proxy layer in the DNS resolution process, proxying the originally used domain name to the correct IP address. Image:

Now, the remaining question is how to find the nearest CDN node to the user, and GSLB takes responsibility for this.

2. How to find the nearest CDN node to the user #

GSLB (Global Server Load Balance) is a server that balances the load among servers deployed in different regions. It may manage many local load balancing components. It has two main functions:

On one hand, it is a load balancing server, which, as the name suggests, evenly distributes traffic to ensure a more balanced load on the servers it manages.

On the other hand, it also needs to ensure that the servers the traffic passes through are relatively close to the source of the traffic in terms of geography.

GSLB can use various strategies to ensure that the returned CDN nodes are as close as possible to the user in terms of geography. For example, the user’s IP address can be divided into several regions based on geographic location, and then the CDN nodes can be assigned to a region, and the appropriate node can be returned based on the user’s location. Another approach is to measure the RTT by sending data packets to determine which node to return. However, these principles are not the focus of this lesson, you just need to have a basic understanding, and I won’t go into detail.

With GSLB, the node resolution process looks like the following:

Of course, whether we can obtain resources from the CDN node also depends on the synchronization latency of the CDN. Generally, we will write static resources to a specific CDN node through the CDN vendor’s interface, and then the CDN’s internal synchronization mechanism will distribute the resources to each CDN node. Even if the internal network of the CDN is optimized, this synchronization process has latency. If we cannot retrieve data from the selected CDN node, we have to retrieve it from the origin server, and the user’s network to the origin server may cross multiple backbone networks, resulting in performance degradation and higher development costs. Therefore, when using CDN, we need to pay attention to the CDN cache hit rate and the bandwidth situation of the origin server.

Course Summary #

In this lesson, I mainly introduced the principles and core technologies of CDN for accelerating static resources. The key points you need to understand are as follows:

DNS technology is a core technology used in CDN implementation, which can map user requests to CDN nodes.
The DNS resolution results need to be locally cached to reduce the response time of the DNS resolution process.
GSLB can return a node closer to the user, speeding up the access to static resources.

As a server-side developer, you may overlook the importance of CDN and disregard occasional CDN problems, thinking that it is not something we should care about. This kind of thinking is wrong.

CDN is the facade of our system. The request volume for cached static data, such as images and video data, is likely to be several times or even higher than the request volume for API data. Once a failure occurs, it will have a huge impact on the overall system. In addition, the bandwidth of CDN has always been a major cost in our development, especially now that we are in the wave of short videos and live streaming, where a large number of short video and live streaming development teams are brainstorming ways to reduce CDN costs. Therefore, CDN is a crucial component of our overall system, and as a special type of cache, its hit rate and availability are key metrics that server-side developers need to focus on.