This is the third day of my participation in the August More text Challenge. For details, see:August is more challenging
An overview of the
The caching mechanism of the browser is also called THE HTTP caching mechanism, which is based on the cache identifier of HTTP packets. Therefore, before analyzing the caching mechanism of the browser, let’s briefly introduce HTTP packets by using graphics. There are two kinds of HTTP packets:
The format of an HTTP Request packet is as follows: Request line – HTTP header (general information header, Request header, and entity header) – Request body (only POST has a message body), as shown in the following figure
The format of HTTP Response packets is as follows: Status line – HTTP header (general information header, Response header, and entity header) – Response packet body, as shown in the following figure
Note: Generic headers refer to the header fields supported by both request and response packets. They are cache-control, Connection, Date, Pragma, transfer-encoding, Upgrade, and Via. The entity header is the entity header field of the entity information, The values are Allow, Content-Base, content-encoding, Content-language, content-Length, content-Location, content-MD5, content-range, and Conten respectively T-type, Etag, Expires, last-Modified, and extension-header. Just for the sake of understanding, the general information header, the response/request header, and the entity header are all classified as HTTP headers.
Why is browser caching needed?
We know that with HTTP, it takes time for the client and the browser to establish a connection, and large responses require multiple round-trips between the client and the server to get a full response, delaying the time the browser can use and process the content. This increases the cost of accessing the server’s data and resources, so reuse of previously acquired data with the browser’s caching mechanism becomes a performance optimization consideration.
Cache Process Analysis
The communication between the browser and the server is in reply mode, that is, the browser initiates an HTTP request and the server responds to the request. Then, after the browser sends the request to the server for the first time and gets the request result, it will decide whether to cache the result according to the cache identifier of the HTTP header in the response packet. If yes, the request result and cache identifier will be stored in the browser cache. The simple process is as follows:
From the picture above, we can know:
- Every time the browser makes a request, it’s going to
Start by looking in the browser cache for the result of the request and the cache identifier - Every time the browser gets the result of the request back
Store the result and the cache identifier in the browser cache
The above two conclusions are the key to the browser caching mechanism, which ensures that every request is cached and read. Once we understand how the browser cache is used, all problems will be solved. For the sake of understanding, the caching process is divided into two parts, forced caching and negotiated caching, depending on whether or not an HTTP request needs to be re-sent to the server.
Mandatory cache
Forcing caching is the process of looking up the request result from the browser cache and deciding whether to use the cached result based on the caching rules for the result.
There are three main cases of forced caching (the negotiation caching process is not analyzed), as follows:
- If the cache result and the cache identifier do not exist, the cache is forcibly invalidated, and the request is directly sent to the server (the same as the first request), as shown in the figure below:
- The cache result and the cache identifier exist, but the result is invalid. If the mandatory cache is invalid, the negotiated cache is used (not analyzed yet), as shown in the following figure
- The cache result and the cache identifier exist, and the result is not invalid, the cache is forced to take effect, and the result is directly returned, as shown in the figure below
So what are the caching rules that force caching?
When a browser sends a request to the server, the server sends the request back to the browser in the HTTP header of the response packet along with the result of the request. The fields that Control the mandatory Cache are Expires and cache-control, respectively. Cache-control has a higher priority than Expires.
Expires
Expires is an HTTP/1.0 field that controls the cache of web pages. Its value is the time when the server returns the cached result of the request. That is, when the client makes the request again, if the time is less than the Expires value, the cached result will be used directly.
Expires is an HTTP/1.0 field, but browsers now use HTTP/1.1 by default. Is Expires still an Expires field in HTTP/1.1?
In HTTP/1.1, Expire has been replaced by cache-control, because Expires controls the Cache by comparing the time the client returns to the time the server returns. If the time of the client and the server is different for some reason (e.g. different time zones; If there is an error between the client and the server, then the forced Cache will be directly invalidated. In this case, the existence of the forced Cache is meaningless. How can cache-control be controlled?
Cache-Control
In HTTP/1.1, cache-control is the most important rule. It is used to Control the Cache of web pages.
- Public: All content will be cached (both client and proxy servers can be cached)
- Private: All contents can be cached only by the client. Default value of cache-control
- No-cache: The client caches the content, but whether to use the cache needs to be verified by the negotiated cache
- No-store: Nothing will be cached, either by force or negotiation
- Max-age = XXX (XXX is numeric) : The cached content will expire after XXX seconds
Next, let’s look directly at an example, as follows:
From the above example we can see that:
- The expires time value in the HTTP response packet is an absolute value
- In the HTTP response packet, cache-control is the relative value of max-age=600
Since the cache-control priority is higher than Expires, the cache-control value is cached directly. This means that if the request is repeated within 600 seconds, the cached result will be used to force the cache-control to take effect.
Note: Cache-control is a better option than Expires when there is no way to determine whether the client time is synchronized with the server time, so only cache-control takes effect when both are present.
Now that we know how to force caching, let’s think about it more broadly:
Where is the browser cache, and how do I determine whether mandatory caching is valid in the browser?
Here we take the blog request as an example. The request with the gray status code indicates that the mandatory cache is used, and the corresponding Size value of the request indicates the location of the cache, which is from memory cache and from Disk cache.
What about from memory cache and from Disk cache? When do I use from Disk cache and when do I use from memory cache?
From memory cache indicates that the cache in memory is used. From disk cache indicates that the cache in hard disk is used. The browser reads the cache in memory – > disk order.
Can from Disk cache and from Memory cache exist simultaneously?
To solve this problem, we need to understand from memory cache and disk cache, as follows:
From memory cache: Memory cache has two characteristics, namely fast read and timeliness:- Fast read: The memory cache directly stores the compiled and parsed files into the memory of the process, occupying certain memory resources of the process, so as to facilitate fast read in the next run.
- Timeliness: Once the process is shut down, the memory of the process is cleared.
From Disk cache: Disk cache directly writes the cache to a disk file. To read the cache, you need to perform I/O operations on the disk files stored in the cache and then parse the cache contents. The reading process is complex and slower than that of memory cache.
In the browser, files such as JS and images are directly stored in the memory cache after being parsed, so you only need to read from the memory cache when refreshing the page. CSS files, on the other hand, are stored in hard disk files, so every time a page is rendered, it must be read from the disk cache.
Negotiate the cache
Negotiated cache refers to the process in which the browser sends a request to the server with the cache identifier after the mandatory cache is invalid, and the server decides whether to use the cache according to the cache identifier. There are mainly two cases:
Negotiation cache takes effect and returns 304 as follows
304
Negotiation cache invalid, return 200 and request result result, as follows
200
Similarly, the negotiation cache identifier is returned to the browser in the HTTP header of the response packet along with the request result. The following fields control the negotiation cache: Last-modified/if-modified-since and Etag/if-none-match. Etag/if-none-match has a higher priority than last-modified/if-modified-since.
Last-Modified / If-Modified-Since
Last-modified is when the server responds to the request by returning the Last time the resource file was Modified on the server, as follows.
last-modify
If-modified-since is a field that tells the server when the resource was Last Modified when the client made the request again with the last-modified value returned from the Last request. When the server receives the request and finds that the request header contains the if-modified-since field, the server will compare the value of the if-Modified-since field to the last time the resource was Modified on the server. If the last time the resource was Modified on the server is longer than the value of the IF-Modified-since field, the server will compare the value of the if-Modified-since field to the last time the resource was Modified on the server. Then the resource is returned with the status code 200. Otherwise, 304 is returned, indicating that the resource has not been updated and the cache file can continue to be used, as shown below.
If-Modified-Since
Etag / If-None-Match
An Etag is a unique identifier (generated by the server) of the current resource file returned by the server in response to a request, as follows.
How Etag works
As shown in the figure above, the server set the cache time for the first response at 120s. Suppose the browser requests the server for the same resource again after 120s. First, the browser will check the local cache and find the previous response. At this point, the browser could simply make a new request and get a new full response, but this would be inefficient, because if the resource hadn’t changed, there would be no reason to download the exact same bytes that are already in the cache.
This is where the Etag comes into play. Typically, the server generates and returns a verification code in the Etag, usually a hash of the file’s contents or some other fingerprint code. The client doesn’t need to know how the fingerprint code is generated, it just needs to send it to the server on the next request (the browser adds it by default) : If the fingerprint code is still consistent, the resource has Not been Modified, and the server will say “304 Not Modified”, we can skip the download and use the cached resource, which will continue to be cached for 120s.
If-none-match indicates that when the client initiates the request again, it carries the unique IDENTIFIER value returned in the last request. The value of this field tells the server the unique identifier value returned in the last request. After receiving the request, the server finds that the request header contains if-none-match, and compares the value of if-None-match with the Etag value of the resource on the server. If the value is consistent, 304 is returned, indicating that the resource is not updated and the cache file continues to be used. If no, the resource file is returned with the status code 200 as follows:
Etag-match
Note: the priority of Etag/if-none-match is higher than that of last-modified/if-modified-since. If both Etag/if-none-match exist, only Etag/if-none-match takes effect.
conclusion
Browser caches are divided into forced cache and negotiated cache. The forced cache takes precedence over the negotiated cache.
- If mandatory caching (Expires and cache-control, with cache-control having a higher priority than Expires) takes effect,Cache is used directly
- If not, the negotiated cache (last-modified/if-modified-since and Etag/if-none-match, Etag/if-none-match has a higher priority than last-Modified/if-modified-since), and the negotiated cache is determined by the server
- If the negotiation cache is invalid, the request cache is invalid. The request result is obtained again and stored in the browser cache. If effective, return 304 and continue using cache
The main process is as follows:
If there are any mistakes in this article, please correct them in the comments section. If this article has helped you, please like 👍 and follow 😊.