Shulou(Shulou.com)06/01 Report--

It is believed that many inexperienced people have no idea about how to implement dynamic CDN in AWS. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

CDN is not a new term, and the technology that distributes caches around the world has been around for at least 10 years. It has become popular again recently because of the deepening requirements of users for network response time. In China, there are CDN, ChinaCache, Baidu+Cloudfare, UCloud, 7 Niu and many other products of Aliyun. Because of network problems, many large companies will use foreign servers and then push the content to China through CDN.

Technically, I think one of the reasons why so many companies do CDN together is that it is not complicated. Of course, some other problems will be added to the support at home and abroad. The mainstream technology is Nginx / Varnish as File Cache, and then deploy GSLB (global load balancing). From a technical point of view, I will not build a CDN network by myself, it takes hundreds of nodes to be considered CDN, and the cost of personal installation is a little high. It is considered that the following factors will be taken into account when choosing CDN

Support for Cache invalidation

The time and price required for Invalidation

The flow fee should not exceed USD 0.14/GB.

Support for dynamic CDN

Support for sub-domain names (both CloudFlare and Security Bao require domain name switching, anti-DDOS)

Support for Cache Behaviour (different paths have different cache features)

Can pass through header / cookie

Respect Cache-control header

It is best to have the operation interface directly to change the header.

Support for edge side include

I believe that what can be done above is not simply a simple CDN, but a real CDN. Today's main share is point 4) dynamic CDN

AWS began to support dynamic CDN in Cloudfront in 2013, which means that html can also be stored on CDN. Users can get HTML and static files on CDN without having to request from the server (origin). In principle, this supports unlimited access. Read request day is not a problem, the question is how much a credit card can pay.

The principle of this Dynamic CDN is like this, for example, take abc.com as an example.

Domain name from abc.com CNAME to Cloudfront (xxxxxxxx.aws.cloudfront.com)

The Cloudfront ID (cloudfrontID.default.cloudfront.com) below xxxxxxxx.aws.cloudfront.com accepts abc.com 's request

Xxxxxxxx.aws.cloudfront.com points to origin.abc.com to get data (that is, the server)

If the request does not have a cloudfront local cache, it will continue, otherwise it will return cache.

If the request is not a specific path (cache behaviour), it returns

CloudfrontID.default.cloudfront.com requests object (html / css / .jpg / …) from the web server (Origin)

Record header (cache-header / CORs) in cache as well

Reverse the cache of xxx.default.cloudfront.com to the client of abc.com

Clean the cache in time with the header defined at point 7)

Operate 1-9 on every edge around the world with the requested source IP

It's a bit like a reverse proxy, such as Varnish doing the same thing. It's just that CDN uses edge cache. The general use case of Varnish is to cache files for the longest time, and then update the cache according to the instructions given by Origin. This is what the customer wants most, so that there is no problem of "the first user slows down". But if you have used several CDN, you will find that there is no such thing as CDN supporting permanent caching. What's the reason? There is no official response to this. I feel that edge cache is a lot of servers. Running cache invalidation on AWS to clean up all cache on edge takes 20 minutes and 30 minutes. If every object update has to "push" like Varnish, it will cost a lot of money. It would be better to Expire automatically, and then add an object cache to the edge cache of the nearest location when the next user needs it. This saves a lot of money.

A good CDN has to support Behaviour, which is a feature of different paths. In different applications, especially for logged-in users, using too much cache will cause problems in the system. You have to follow the path to delete / accelerate the refresh.

If login users are supported, Cookie needs to be sent directly to Origin by client, so support (forward cookie) is required.

Each CDN will have a Default behaviour, that is, if it is not specified, it will respond to this behaviour. For example, if we want to support user login, we have to send session back to origin via Dynamic CDN.

After reading the above, have you mastered how to implement dynamic CDN in AWS? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.