Web Cache Fundamentals: terminology, HTTP headers, and caching policies

Brief introduction

For your site's visitors, intelligent content caching is one of the most effective ways to improve the user experience. caching, or temporary storage of previous requests, is one of the most core content distribution policies in the HTTP protocol implementation. Components in the distribution path can cache content to speed up subsequent requests, which are controlled by the cache policy declared on that content.

In this guide, we will discuss some of the basic concepts of Web content caching. This includes how to choose a caching strategy to ensure that the Internet-wide cache can handle your content correctly. We'll talk about the benefits of caching, side effects, and the greatest combination of performance and flexibility that different strategies can bring.

What is cache (caching)?

Caching (caching) is a term that describes the behavior of storing reusable resources in order to expedite subsequent requests. There are many different types of caches, each of which has its own characteristics, and application caches and memory caches are often used because of their acceleration of specific replies.

The main story of this guide is that the Web cache is a different type of cache. Web caching is a core feature of the HTTP protocol, which minimizes network traffic and increases the overall system responsiveness that users perceive. Content from the server to the browser in the transfer process, each level can find the cache figure.

The Web cache caches responses to corresponding HTTP requests based on specific rules. Subsequent requests for cached content can be met directly by the cache instead of resending the request to the Web server.

Benefits

Effective caching technology can help not only users, but also content providers. The benefits of caching for content distribution are:

• Reduced network overhead : content can be cached in many different places from the content provider to the content consumer network path. When content is cached more closely from the content consumer, the request will not consume additional network resources due to the presence of the cache.
• Faster response times : Because the cache does not have to be round-tripping through the entire network, caching can make content more accessible. Slow storage is closer to the user, such as the browser cache, so that the content gets almost instantaneous.
• Speed up on the same hardware : For servers that save raw content, more performance can be squeezed out of hardware by allowing aggressive caching policies. Content owners can leverage a powerful server on the distribution path to cope with the impact of a particular content load.
• content is still available when the network is interrupted : With a strategy, the cache guarantees that the content will remain available to the user when the original server becomes unavailable.

Terms

When you face caching, you may not be familiar with some of the terminology you encounter frequently. Some of the common terms are as follows:

• Original Server : The original server is the original storage location for the content. If you are a Web server administrator, it is the machine you are managing. It is responsible for replying to any content that cannot be obtained from the cache, and is responsible for setting the cache policy for all content.
• Cache Hit Ratio : The validity of a cache is measured in terms of the cache hit rate. It is the ratio of the number of requests that can get data from the cache to the number of all requests. A high cache hit ratio means that a high percentage of data can be obtained from the cache. This is usually the result that most administrators want.
• freshness : Freshness is used to describe whether an item in a cache is still suitable for return to the client. Content in the cache is returned only if it is within the freshness period specified by the cache policy.
• Expired Content : The cache has expired content set according to the freshness of the cache policy. Expired content is marked as "stale." Typically, outdated content cannot be used to respond to requests from clients. You must re-request new content from the original server or at least verify that the cached content is still accurate.
• checksum : Expired content in the cache can be verified to be valid in order to refresh the expiration time. The verification process involves contacting the original server to check whether the cached data still represents the most recent version.
• Failure : Failure is the process of removing content from the cache based on the expiration date. This must be done when the content has been changed on the original server, and content that expires in the cache can cause problems for the client.

There are many other caching terms, but the above should help you get started.

What can be cached?

Some specific content is more easily cached than other content. For most sites, some of the content for caching is as follows:

• Logo and logo image
• Normal non-changeable images (for example, navigation icons)
• CSS style Sheets
• Common JavaScript files
• Downloadable content
• Media files

These files tend to change infrequently, so caching them for long periods of time can be beneficial.

Some items must be noted in the cache:

• HTML page
• Will replace the changed image
• Frequently-modified JavaScript and CSS files
• Content that requires a certified cookie to access

Some content should never be cached:

• Resources related to sensitive information (bank data, etc.)
• User-related and frequently changing data

In addition to the general rules above, you typically need to specify rules to make it easier to cache different kinds of content. For example, if the logged-on user sees the same view of the site, it should be cached everywhere. If a logged-on user sees a user-specific view of the site for a period of time, you should let the user's browser cache the data instead of having any mediation node cache the view.

Location of the Web content cache

Web content is cached in many different locations throughout the distribution path:

• Browser Cache : A small cache is maintained by the Web browser itself. Typically, a browser uses a policy to indicate the most important content of the cache. This may be user-related content or may be requested again and downloaded at a higher cost.
• Intermediate Cache proxy : Any server between the client and your infrastructure can cache some content as expected. These caches may be provided by ISPs (Network service providers) or other independent organizations.
• Reverse Caching : Your server infrastructure can implement its own cache for back-end services. If the cache is implemented, it is possible to return the content at the location where the request is processed without using the backend service each time the request is made.

These locations can usually cache some of the content based on their own cache policies and the cache policy of the content source.

Cache Header

The caching strategy relies on two different factors. The cached entity itself needs to decide whether the acceptable content should be cached. It can cache only a portion of the content that can be cached, but it cannot cache content that exceeds the limit.

Caching behavior is primarily determined by the cache policy, and the cache policy is set by the content owner. These strategies are explicitly expressed through specific HTTP headers.

After several different HTTP protocol changes, there are some different headers for the cache, and their complexity varies. Here are some of the things you might notice:

• * * Expires *: Although the use of the scope is quite limited, but the Expires head is very concise and clear. Usually it sets a future time when content will expire at this time. At this point, any request for the same content should go back to the original server. This head may be just the best fit for fallback mode (fall back).
• * * Cache-Control *: This is Expires a more modern replacement. It has been well supported and has a more flexible implementation. In most cases, it Expires 's better, but it doesn't hurt to set both values. We will discuss the detailed options that you can set later Cache-Control .
• * * ETag *: ETag for cache authentication. The source server can provide a unique content for a content when it is first serviced ETag . When a cache needs to verify that the content is about to expire, he sends the corresponding back to the ETag server. The source server either tells the cache that the content is consistent, or sends the updated content (with the new one ETag ).
• Last-Modified: This header indicates the last time the corresponding content has been modified. It may be used as part of a validation strategy that guarantees content freshness.
• * * Content-Length *: Although not explicitly addressed in the cache, the Content-Length head is important when setting up a caching strategy. Some software refuses to cache the content if it does not know the size of the content in advance to allow enough space.
• * Vary * *: The cache system typically uses the requested host and path as the key to store the resource. The Vary head can be used to alert the cache system to another additional header when judging whether a request is requesting the same content. It is often used to tell the cache system to also pay attention to the Accept-Encoding head so that the cache system can differentiate between compressed and uncompressed content.

Vary the head of the lingo

VaryThe head gives you the ability to store different versions of the same content, at the expense of reducing the capacity of the cache.

When used Accept-Encoding , the set Vary header allows for a clear distinction between compressed and uncompressed content. This is important when serving some browsers that cannot handle compressed data, which guarantees basic availability. VaryA typical value is Accept-Encoding that it has only two to three optional values.

User-Agentat first it looked like this head can be used to differentiate between mobile browsers and desktop browsers so that your site provides differentiated services. But User-Agent strings are non-standard, resulting in many different versions of the cache that hold the same content in the intermediate cache, resulting in a decrease in cache hit ratios. The Vary head should be used with caution, especially if you do not have the ability to standardize requests in the intermediate cache you control (perhaps, for example, you can control the CDN).

How cache control flags affect caching

Above we mentioned Cache-Control how the head is used with modern cache policy standards. It is possible to set many different cache instructions through this head, and several different instructions are separated by commas.

Some of the options that you can use to indicate content caching policies are Cache-Control as follows:

• no-cache: This instruction indicates that all cached content must be re-authenticated before the new request arrives and sent to the client. This instruction actually marks the content as expired immediately, but allows verification to be re-verified to avoid re-downloading the entire content.
• no-store: This directive indicates that the contents of the cache cannot be cached in any way. It is suitable to be set when replying to sensitive information.
• public: It marks the content as public, which means it can be cached by the browser and any other intermediate nodes. Typically, for requests that use HTTP authentication, their replies are marked by default private . publicThis setting will be overwritten by the tag.
• private: It marks the content as private. Private data can be cached by the user's browser, but cannot be cached by any intermediate nodes. It is typically used for user-related data.
• max-age: This setting indicates the maximum lifetime of the cached content, which must be verified at the source server or re-downloaded after the maximum life time. In modern browsers this option largely replaces the Expires head, which the browser also serves as the basis for determining the freshness of the content. The value of this option is expressed in seconds, which can represent a fresh period of one year (31.536 million seconds).
• s-maxage: This option is very similar max-age , it indicates the time when the content can be cached. The difference is that this option is only valid in the middle node's cache. Combining these two options allows you to build a more flexible caching strategy.
• must-revalidate: It indicates that the max-age s-maxage freshness information indicated by or in the Expires head must be strictly adhered to. It avoids the use of cached data in similar scenarios such as network outages.
• proxy-revalidate: It has the same effect as the above option, but applies only to intermediate proxy nodes. In this case, the user's browser can use outdated content when the network is interrupted, but the intermediate cache content cannot be used for this purpose.
• no-transform: This option tells you that there are no circumstances in which you can modify the received content for performance reasons. This means that the cache does not allow compression of the received content (it does not receive the compressed version from the original server) and sends it.

These options can be combined in different ways to get different caching behavior. Some of the mutex values are as follows:

• no-cache, no-store as well as the usual caching behavior indicated by other previously unspecified options
• publicAndprivate

If no-store and no-cache both are set, then it no-store will be replaced no-cache . A reply to a request that is not authorized public is an implicit setting. For replies to an authorized request, the private option is implied. They can be Cache-Control overridden by indicating the corresponding opposite option in the head.

Develop a caching strategy

Ideally, anything can be cached as much as possible, and your server needs to provide only occasional verification of the content. But this rarely happens in reality, so you should try to set some sensible caching strategies to balance the need for long-term caching and site change.

Problems

In many cases, the content should not be cached because of the way in which it was produced (as per user dynamics) or the nature of the content (such as sensitive data from banks). Other issues that many administrators may face when setting up the cache are that the external cached data has not expired, but the new version of the data has been generated.

These are frequently encountered problems that affect the performance of the cache and the accuracy of the data you provide. However, we can mitigate these problems by developing a caching strategy that anticipates these issues in advance.

General recommendations

Although your actual situation will guide you in choosing a caching strategy, the following suggestions can help you get some reasonable decisions.

Before you worry about which particular head to use, there are a few specific steps that can help you improve your cache hit ratio. Some of the recommendations are as follows:

• create specific folders for images, CSS, and shared content : placing content in a specific folder makes it easy for you to reference it from any page in your site.
• use the same URL to represent the same content : Because the cache uses the host name and path in the content request as the key, you should ensure that the content is referenced in all of your pages in the same way that the previous recommendation makes it easier to do so.
• Use CSS image stitching whenever possible : for things like icons and navigation, using CSS image stitching can reduce the need for rendering your pages for a round trip, and allow for a long time for splicing caching.
• Localize host scripts and external resources whenever possible : If you use JavaScript scripts and other external resources, you should consider placing them on your own server if you do not provide the appropriate cache headers upstream. You should be aware of any upstream updates in order to update the local copy.
• collect file summaries for cached content : Static content, such as CSS and JavaScript files, is generally more appropriate for collecting file summaries. This means that adding a unique identifier (usually a hash of the file) to the file name can be used to bypass the cache and ensure that the new content is re-fetched. There are a number of tools that can help you create file summaries and modify references in HTML documents.

For different files to select different headers correctly, the following content can be used as a general reference:

• allow all caches to store generic content : Static content and non-user-related content should be cached on all nodes in the distribution chain. This allows the intermediary node to reply to multiple users.
• allow browser to cache user-related content : For each user's data, caching is generally acceptable and beneficial in the user's own browser. Caching in the user's own browser allows the user to read instantaneously in the next browsing, but the content is not suitable to be cached in any intermediary proxy nodes.
• Use time-sensitive content as a special case : If your data is time sensitive, you should use this data as a special exception relative to the above two references to ensure that outdated data is not used in critical situations. For example, your site has a shopping cart, which should immediately reflect the contents of the shopping cart. Depending on the characteristics of your content, you can use the no-cache or no-store options in the cache-control header.
• always provides validators : validators allow outdated content to be refreshed without re-downloading. Setting the ETag and last-modified headers will allow caching to validate content to the original server and refresh the content freshness to reduce load when the content is not modified.
• Long freshness period for supported content : For more efficient use of caching, some of the supporting content should be set to a longer freshness period. This is usually more appropriate for images and CSS, such as the content that the user requests to render an HTML page. Together with the file summary, setting an extended freshness period will allow caching of these resources for long periods of time. If the resource changes, the modified file summary will invalidate the cached data and trigger a download of the new content. At that time, the new supported content will continue to be cached.
• Set short freshness for parent content : To make the previous pattern work correctly, the contents of the container class should be set to a short freshness period, or not all cached. This is usually an HTML page that is used in other assistance content. This HTML page will be downloaded frequently, allowing it to respond quickly to changes. The supporting content can therefore be cached as much as possible.

The key is to strike a balance, to cache as much as possible, and to preserve the opportunity for the future to change the entire content when changes occur. Your site should have both:

• Try to cache content
• Cache content with a short freshness period that can be re-verified
• Content that is not cached at all

The purpose of this is to maintain acceptable cache hit ratios while moving content as far as possible into the first category (as far as possible to cache).

Web Cache Fundamentals: terminology, HTTP headers, and caching policies