Just finished dealing with an online fault for a customer, blood pressure almost did not come up. You say a good e-commerce station, big day home suddenly white screen, the user crazy complaints. A check, good guy, the source station CPU directly soared to 100%, the database connection pool all full. Root cause? A popular product page was crawler a second request thousands of times, each request penetrates the CDN, directly back to the source query database. How can this top ah? High-defense CDN obviously hanging, the attack is prevented, but the speed? Performance? Money spent in vain! The problem lies in the caching strategy is not configured right - either a one-size-fits-all cache, or all dynamic, did not do the differentiation process.
I've seen too many teams treat high defense CDN as a simple “traffic shield”, thinking that as long as the set can be both safe and fast. In fact, a big mistake. The core value of high-defense CDN, half of the security protection, the other half lies precisely in theProper Cache DesignCache is not only able to carry the traffic flood. Cache set up well, not only can carry the traffic peak, and even allow you to be hit when the user is completely insensitive to continue browsing; set up poorly, the attack is prevented, but the normal user can not use the card, the source station may also be injured by mistake.
Why is your CDN cache always wrong? Eighty percent is not to understand the word “static and dynamic separation”. Static content (images, CSS, JS, fonts, etc.) and dynamic content (API interface, user session data, real-time prices) are basically two kinds of creatures, but you use the same set of caching rules to deal with, can not happen? Static content should be cached to death, while dynamic content should be carefully controlled or even bypassed altogether.
Notice here theimmutableattribute, which tells the browser: this file will never change in your life, so you can read it from the local cache without even sending a conditional request. In practice, this is extremely effective in reducing duplicate requests and increasing speed.
The biggest headache is dynamic content. For example, the product details page, most of the content is static (product description, pictures), but a small part of the dynamic (inventory quantity, user nicknames). All cache it, the data will expire; do not cache it, the source station is under great pressure. Here we have to offer my favorite “Edge Partial Cache” (Edge Side Includes) or the more modern “edge computing”Program up.
Taking CDN07 as an example, its edge function feature is massively useful. You can write a simple piece of JS logic to initiate sub-requests for dynamic content only at the edge node, merge them and return them to the user:
In this way, the main body of the page is cached for 10 minutes, while dynamic modules are fetched on demand in real time. This reduces the pressure on the source station and ensures the real-time availability of the core data.
Be sure to set factors that may affect content changes as part of the Cache Key. For example:
but be sure toExcluding factors that don't affect the content, such as User-Agent (unless you're actually outputting different content for mobile and PC), or some tracking parameter (such as utm_source). Otherwise the same resource will be cached in countless copies, and the cache hit rate will just flop.
There is another special scenario for high defense CDNs:Caching strategy in case of CC attacks. When the CDN recognizes that a URL is being wildly scrubbed, you can set a special rule: cache the response to that URL for a short period of time (say 10 seconds). Don't look down on this 10 seconds, it means that all requests for this URL within 10 seconds, the CDN node will return the cached content directly, and will not go back to the source at all. This 10-second “shield” is enough for the CDN security module to determine and block malicious IP. I used this trick on 08Host to successfully resist a CC attack against the search interface, the source site did not even receive a request.
Finally, don't forget cache warming and clearing. Even the best strategy should have supporting measures. For important activity pages, warm up to the CDN node in advance; after the content is updated, the cache should be refreshed in a timely manner. 08Host's API refresh interface speed is the fastest I've ever used, and after calling the 95% node can invalidate the cache within 3 seconds, unlike some vendors who have to wait for half an hour.
Having said that, the bottom line isTest, test, and test again.. After matching the rules, be sure to check the Cache-Control header with curl or your browser to make sure that the cache hit as expected. Observe the cache hit rate report on the CDN console for a period of time, if it is lower than 90%, there must be room for optimization.
Caching strategy is not permanent, it has to follow the business changes. But as long as you master the “static content long-lasting cache, dynamic content fine control, cache key reasonable settings” this core principle, basically will not go wrong. Do not forget, high defense CDN is not just a firewall, it should be the most important layer of your performance architecture gas pedal. Set up a good, the user experience soared; set up a bad, money spent and scolded. These days, even the CDN have to “defense teammates” - to prevent those who do not understand the chaotic configuration of their own people ah.
