Write in front: I have learned xiu Yan’s booklet recently and benefited a lot. For HTTP cache this piece, after data query and thinking, also have their own thinking understanding, I hope to share with you to discuss and grow together.
Description of content
- What is caching and its benefits
- Procedure for handling the cache
- Strong and negotiated caching
- Caching decisions
- Summary and Reflection
1. Cache and its advantages
The cache
Caching is a technique that automatically saves copies of common resources and can be used directly on the next request rather than retrieving them again.
That is to say, when we first resource request, the server in return resources to the client at the same time, the cache server or local cache can also save a copy of resources (in the case of allowing cached), when we request of the resources in the next time, can directly use the resources rather than copy from the original server request document again.
Advantages of caching
- Caching reduces redundant data transfers.
- Caching can alleviate network bottlenecks.
- Caching can reduce the requirements on the original server.
- Caching reduces the distance latency of requests.
Redundant transmission of data
When many clients access the same document, the original server returns the same content to different clients over and over again, resulting in redundant data transfer.
Network Bottlenecks
In most cases, the client can access the proxy server faster (with high bandwidth and low latency) than the original server, so if the proxy server can provide a full copy, it will be much faster and less traffic-especially for large files than if it can get a copy from the original server.
Reduce raw server requirements
When a sudden event (such as breaking news, a celebrity event) causes many people to access a Web document at about the same time, there can be instant congestion. The resulting excessive traffic spikes can crash the network and Web servers. Using caching can reduce the strain on the original server to some extent.
Reduce the request distance delay
Physical distance is also an aspect that degrades Web performance. For the same resource, the closer the original server is to the request end, the faster the resource can be obtained.
Strong cache and negotiated cache
1. Explain concepts related to cache
A cache hit
If the result of a request is provided by a cached copy, it is said to be a cache hit.
Cache miss
If no copy is available in the cache or the copy has expired, the request is forwarded to the original server, which is called a cache miss.
Freshness detection
HTTP keeps a copy of a server document for a period of time through caching. During this time, the document is considered “fresh” and can be served by the cache without contacting the server. But once a cached copy stays too long beyond the freshness limit of the document, the object is considered “out of date” and the cache verifies with the server again to see if the document has changed before serving it.
revalidation
The content on the original server can change over time, and the cache needs to check it frequently to see if the copy it keeps is still the most recent copy on the server. These freshness checks are called HTTP revalidation.
Caches can revalidate copies at any time, but most caches only revalidate copies when the client initiates a request and the copies are old enough to warrant detection.
Revalidation hit and revalidation miss
When the cache revalidates a cached copy, it sends a revalidation request to the original server, which responds with 304 Not Modified if the content has Not changed. This is called a revalidation hit or a slow hit. If the content changes, the server responds with 200. This is called a revalidation miss.
2. Processing procedure of cache
- The first is that when a user requests a resource, it will determine whether there is a cache, and if not, it will request the resource from the original server.
- If there is a cache, it will enter the category of strong cache, determine whether the cache is fresh, if the cache is fresh, it will directly return the cache copy to the client. If the cache is stale, the strong cache has failed and will enter the negotiated cache.
- The negotiated cache will determine whether there are Etag and Last-Modified headers, and verify whether the resource has changed through these headers. If there is no change, the negotiated cache has been hit, and the cache copy will be redirected to the client, and the resource will be returned to the client. Otherwise, the negotiated cache has not been hit, and the server will return a new resource.
The concept of strong and negotiated caching
Strong cache
After the server informs the client of the cache duration, the client determines whether to use the cache.
That is, the server writes the cache fresh time in Response Headers for the first request. When the request is made again, if the cache is fresh, the resource is fetched directly from the cache without any further communication with the server.
Negotiate the cache
It is up to the server to decide and tell the client whether to use caching.
In the negotiation cache mechanism, the browser needs to ask the server for information about the cache to determine whether to resend the request, download the complete response, or obtain cached resources from the local server.
4. Implementation principle of strong cache and negotiated cache
(1) Implementation principle of strong cache
Strong caching is implemented through the Expires header or cache-Control: max-age.
Both Expires and cache-Control: max-age are headers used to indicate the expiration date of a resource.
Expires (HTTP / 1.0)
Because expires is an absolute time, artificially changing a time can affect the expiration date of a cache, rendering it meaningless. So in HTTP1.1 we have a complete replacement of Expires header cache-control: max-age
Cache-control HTTP / 1.1) (
Process description
- When we request the resource for the first time, the server will write the Expires header or cache-Control in Response Headers when it returns the resource, indicating the expiration time of the cache. The cache copy will save this part of information.
- When the resource is requested again, the cache responds to date(a generic header that represents the time the original server message was sent). This is the time when a resource was first requested. Compare that to expires/cache-control to determine if the cached copy is fresh enough.
(2) Implementation principle of negotiation cache
Negotiated caching is implemented through last-Modified or Etag request headers.
Last-modified indicates the time when the document was Last Modified, and Etag is encoded by the document content.
Last-Modified
- When requesting a resource for the first time, the server writes the last-Modified header in Response Headers after returning the resource, indicating the Last modification time of the resource on the server.
- When the resource is requested again, the if-modified-since header is written to the Request Headers. In this case, the if-modified-since header is the last-modified value returned when the resource was first requested.
- Upon receiving the request, the server determines whether the resource has changed Since that date based on the if-Modified-since value.
- If Not, 304 Not Modified is returned; If it changes, the changed resource is returned and the last-modified value is updated.
(1) The screenshot of the network panel is not updated
First request:
First request:
Etag
As you can see, Etag is implemented in exactly the same way as Last-Modified, which is not covered here.
Some problems with last-Modified
Some documents may be periodically rewritten, but the actual data is often the same. Although the content does not change, the modification date does.
Some documents may have been modified, but the changes are not significant enough to allow the cache to overload the data (such as changes to spelling or comments).
One-second change dates may not be sufficient for servers that provide documents that change in subsecond intervals (for example, live monitors).
From these descriptions, we can summarize some defects of Last-Modified:
- There is no way to perceive whether the contents of the file have really changed. Ask again when you shouldn’t.
- Changes in content below seconds are not perceptible. They didn’t ask again when they should have.
Etag is a unique identifier string generated by the server for each resource. This identifier string is encoded based on the contents of the file, and the corresponding Etag is different as long as the contents of the file differ. Therefore, Etag can accurately sense changes in the file.
Etag Strong and weak validators
ETag is divided into strong validators and weak validators.
A strong validator requires that every byte of the document be equal, whereas a weak validator requires only that the meaning of the document be equal.
Strong authentication:
5, Cache-control request header common attributes description
max-age/s-maxage
The s-maxage directive performs the same function as max-age, with the only difference being that the s-maxage directive only applies to proxy server caches. S-maxage has a higher priority than max-age.
public/private
Public and private are opposing concepts for whether a resource can be cached by a proxy service.
If we set the resource to public, it can be cached by both the browser and the proxy. If we set private, the resource can only be cached by the browser.
no-cache/no-store
No-cache indicates that the client must validate the document with the original server before requiring the cache to provide its cached copy. That is, the strong cache phase is forcibly skipped and the negotiation cache is directly implemented. A strong cache does not know if the cache is really fresh enough, and the purpose of no-cache is to prevent the cache from returning expired resources from the cache and revalidating the cache.
No-store disables caching, that is, it communicates directly with the original server every time and returns resources from the original server. Generally, a no-store resource indicates that the resource has sensitive information.
6. Priorities
(1) Expires and Cache-Control: max-age
A cache server running HTTP/1.1 will process a max-age directive in preference to an Expires header field when both exist. On HTTP/1.0 cache servers, however, max-age directives are ignored.
(2) Last-Modified and Etag (questionable part)
Many sources say that Etag takes precedence over Last-Modified, but some sources say that when Etag and last-Modified exist together, it is the two that determine whether the identity document changes.
If if-none-match and the server resource were last Modified at a different time, the file was changed, and 200 is returned. There is no need to check if-Modified-since. When Etag hits, last-Modified is determined, and only when both are hit is the cache copy fetched from the cache.
Note: I don’t know if this point of view is correct, but I think it is reasonable, welcome to discuss or give advice.
Caching decisions
Having no hands-on experience with HTTP caching, I don’t really have much insight into caching decisions.
4. Thinking and summarizing
It took me a while to learn about HTTP caching, and I found that the concepts and concepts were so jumbled that I couldn’t connect the whole caching process at first. Through consulting blogs and books, I finally sorted out the process of caching and the concepts and knowledge points involved in each step. Not only have a clear control of the whole process, but also have a certain understanding of the various links and details of the process.
I thought long and hard about how I would write so that I could tell the big story clearly, but also account for everything involved in each step. I hope that through sharing, I can bring you some new things and thinking, then I will be satisfied.
As a final reminder of the caching process, draw this picture in your mind:
Finally, thank you for reading, hard ^_^
If there are any mistakes, please correct them
Data reference
- Nuggets of gold – Front-end performance optimization principles and practices
- Discussion on browser HTTP caching mechanism
- The Definitive GUIDE to HTTP (extract code: 4E45)
- The illustration of HTTP