Cache and CDN

Web Cache：

• To reduce latency — Because the request is satisfied from the cache (which is closer to the client) instead of the origin server, it takes less time for it to get the representation and display it. This makes the Web seem more responsive.
• To reduce network traffic — Because representations are reused, it reduces the amount of bandwidth used by a client. This saves money if the client is paying for traffic, and keeps their bandwidth requirements lower and more manageable.

Web Cache的种类：

1. Browser Caches
   usecase: like hit “back” button. Usually once a session

2. Proxy Caches
   proxy caches aren’t part of the client or the origin server
   a. browser proxy setting
   b. interception
   Proxy caches are a type of shared cache; rather than just having one person using them, they usually have a large number of users
   
   

3. Gateway Caches
   Also known as “reverse proxy caches” or “surrogate caches,”
   but instead of being deployed by network administrators to save bandwidth, they’re typically deployed by Webmasters themselves, to make their sites more scalable, reliable and better performing.
   Requests can be routed to gateway caches by a number of methods, but typically some form of load balancer is used to make one or more of them look like the origin server to clients.

How it works?
. If the response’s headers tell the cache not to keep it, it won’t.
. If the request is authenticated or secure (i.e., HTTPS), it won’t be cached by shared caches.
. A cached representation is considered fresh (that is, able to be sent to a client without checking with the origin server) if:

. It has an expiry time or other age-controlling header set, and is still within the fresh period, or
. If the cache has seen the representation recently, and it was modified relatively long ago.

Fresh representations are served directly from the cache, without checking with the origin server.
. If a representation is stale, the origin server will be asked to validate it, or tell the cache whether the copy that it has is still good.
. Under certain circumstances — for example, when it’s disconnected from a network — a cache can serve stale responses without checking with the origin server.

If no validator (an ETag or Last-Modified header) is present on a response, and it doesn’t have any explicit freshness information, it will usually — but not always — be considered uncacheable.
Together, freshness and validation are the most important ways that a cache works with content. A fresh representation will be available instantly from the cache, while a validated representation will avoid sending the entire representation over again if it hasn’t changed.

Validators and Validation

Validators are very important; if one isn’t present, and there isn’t any freshness information (Expires or Cache-Control) available, caches will not store a representation at all.

The most common validator is the time that the document last changed, as communicated in Last-Modified header. When a cache has a representation stored that includes a Last-Modified header, it can use it to ask the server if the representation has changed since the last time it was seen, with an If-Modified-Since request.

HTTP 1.1 introduced a new kind of validator called the ETag. ETags are unique identifiers that are generated by the server and changed every time the representation does. Because the server controls how the ETag is generated, caches can be sure that if the ETag matches when they make a If-None-Match request, the representation really is the same.
Almost all caches use Last-Modified times as validators; ETag validation is also becoming prevalent.

Tips for Building a Cache-Aware Site

1. Use URLs consistently — this is the golden rule of caching. If you serve the same content on different pages, to different users, or from different sites, it should use the same URL. This is the easiest and most effective way to make your site cache-friendly. For example, if you use “/index.html” in your HTML as a reference once, always use it that way.
2. Use a common library of images and other elements and refer back to them from different places.
   Make caches store images and pages that don’t change often by using a Cache-Control: max-age header with a large value.
3. Make caches recognise regularly updated pages by specifying an appropriate max-age or expiration time.
   If a resource (especially a downloadable file) changes, change its name. That way, you can make it expire far in the future, and still guarantee that the correct version is served; the page that links to it is the only one that will need a short expiry time.
4. Don’t change files unnecessarily. If you do, everything will have a falsely young Last-Modified date. For instance, when updating your site, don’t copy over the entire site; just move the files that you’ve changed.
5. Use cookies only where necessary — cookies are difficult to cache, and aren’t needed in most situations. If you must use a cookie, limit its use to dynamic pages.
6. Check your pages with REDbot — it can help you apply many of the concepts in this tutorial.

https://www.mnot.net/cache_docs/