preface
If you’re still interviewing for a job, check in appropriately. Today’s morning reading article was contributed by @Ye Heying.
Ye Heying, Tencent front-end engineer, mainly developing system and e-commerce platform projects
The text begins here
An overview of the
The browser cache mechanism is also known as the HTTP cache mechanism. Its mechanism is based on the cache identifier of HTTP packets. Therefore, before analyzing the browser cache mechanism, we will briefly introduce HTTP packets with pictures and pictures.
HTTP Request packet. The packet format is as follows: Request line – HTTP header (general information header, Request header, or entity header) – Request packet body (Only POST has a packet body)
HTTP Response packet. The packet format is as follows: status line – HTTP header (general information header, Response header, or entity header) – Response packet body, as shown in the following figure
Note: The general information header refers to the header fields supported by both request and response packets, which are cache-Control, Connection, Date, Pragma, Transfer-Encoding, Upgrade and Via respectively. Entity header is the entity header field of entity information. Allow, content-base, content-Encoding, content-language, content-Length, content-location, content-MD5, content-range, and Conten respectively T-type, Etag, Expires, Last-Modified, extension-header. For ease of understanding, generic message headers, response/request headers, and entity headers are all classified as HTTP headers.
The above concept here we do not explain more, just a brief introduction, interested in children’s shoes can study by themselves.
Cache process analysis
The browser communicates with the server in reply mode, that is, the browser initiates an HTTP request and the server responds to the request. After the browser sends the request to the server for the first time and gets the request result, it decides whether to cache the result or not according to the cache identifier of the HTTP header in the response packet. If yes, the request result and cache identifier are stored in the browser cache. The simple process is as follows:
From the figure above, we can know:
-
Each time the browser initiates a request, it first looks up the result of the request and the cache identifier in the browser cache
-
Each time the browser receives the result of the returned request, it stores the result and the cache id in the browser cache
The above two conclusions are the key to the browser cache mechanism, which ensures that each request is cached and read. As long as we understand the rules of the browser cache, all problems will be solved, and this article will analyze this in detail. To help you understand, we have divided the caching process into two parts, namely mandatory caching and negotiated caching, depending on whether the HTTP request needs to be re-initiated to the server.
Mandatory cache
Forced caching refers to the process of searching the browser cache for the request result and deciding whether to use the cached result based on the cache rule of the result. There are three main cases of forced caching (the negotiation cache process is not analyzed for the moment), as follows:
If the cache result and cache id do not exist and the cache is forced to be invalid, the request is directly sent to the server (the same as the first request), as shown below:
The cache result and cache id exist, but the result is invalid and the cache is forced to become invalid. In this case, the negotiated cache is used (not analyzed), as shown in the following figure
If the cache result and cache id exist and the cache result is not invalid, the cache is forced to take effect and the cache result is directly returned, as shown in the following figure
So what are the cache rules that enforce caching?
When the browser sends a request to the server, the server returns the Cache rule in the HTTP header of the HTTP response packet together with the request result to the browser. The fields that Control the mandatory Cache are Expires and cache-Control, respectively. Cache-control has a higher priority than Expires.
Expires
Expires is a field that HTTP/1.0 controls the web cache. Its value is the expiration time that the server returns to the cache of the result of the request. That is, when the client initiates the request again, if the time is less than the Expires value, the cached result is used directly.
Expires is an HTTP/1.0 field, but browsers now use HTTP/1.1 by default. Is web caching still controlled by Expires in HTTP/1.1?
With HTTP/1.1, Expire was replaced by cache-control. The reason is that Expires caching works by comparing the client time with the time returned by the server. Client and the server one time is not accurate) error occurs, then forced the Cache will be failure directly, so the existence of forced Cache is meaningless, and then the cache-control is how to Control?
Cache-Control
In HTTP/1.1, cache-control is the most important rule, which is mainly used to Control web caching. Its main values are:
-
Public: All content will be cached (both client and proxy can be cached)
-
Private: All content can be cached only by the client. The default value of cache-control
-
No-cache: indicates the contents of the client cache, but whether to use the cache is verified by the negotiated cache
-
No-store: All content is not cached, that is, neither mandatory cache nor negotiated cache is used
-
Max-age = XXX (XXX is numeric) : The cache contents will expire after XXX seconds
Let’s go straight to an example, as follows:
From the above example we can know:
-
The expires time value in an HTTP response packet is an absolute value
-
The cache-control value in the HTTP response packet is max-age=600, which is relative to the HTTP response packet
Because cache-Control has a priority over Expires, cache-Control values are cached directly, meaning that if the request is made again within 600 seconds, the cached result will be used to enforce the Cache.
Note: Cache-control is a better option than Expires in cases where you can’t determine whether the client’s time is synchronized with the server’s, so only cache-Control works when both exist.
Now that we understand the process of forced caching, let’s think about it more broadly:
Where does the browser cache reside, and how do I determine if the mandatory cache is in effect in the browser?
Here we take the blog request as an example. The request whose status code is gray indicates that the mandatory cache is used. The Size value of the request indicates the location of the cache, namely, from Memory cache and from Disk cache.
What does from memory cache and from Disk cache stand for? When is a FROM Disk cache used and when is a FROM Memory cache used?
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 the order of memory – > Disk.
Although I have directly said the conclusion, but I believe that many people can not understand this, so next let’s analyze the cache read problem in detail, here still let my blog for example analysis:
Visit https://heyingye.github.io/ – > 200 – > close the blog TAB – > back on https://heyingye.github.io/ – > 200 (from disk cache) – > refresh – > 200(from memory cache)
The process is as follows:
-
Go to https://heyingye.github.io/
-
Close the blog TAB
-
To open https://heyingye.github.io/
-
The refresh
from disk memory
The last step is to refresh from disk cache and from memory cache at the same time.
To solve this problem, we need to understand from memory cache and from disk cache, as follows:
-
From memory cache: The memory cache has two characteristics, namely fast access 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, and facilitating the fast read of the next run.
-
Timeliness: Once the process is shut down, its memory is emptied.
-
From disk cache: The cache is directly written to the disk file. To read the cache, I/O operations are performed on the disk file stored in the cache and the cache content is parsed again. The reading of the cache is complex and slower than that of the memory cache.
In the browser, js and image files are directly stored in the memory cache after being parsed. Therefore, when refreshing the page, you only need to read from the memory cache directly. CSS files are stored in disk files, so every rendering page needs to be read from disk cache.
Negotiate the cache
Negotiation cache is a process in which the browser sends a request to the server with the cache ID after the cache is invalid, and the server decides whether to use the cache based on the cache ID. There are two main situations:
The negotiation cache takes effect and 304 is returned as follows
Negotiation cache invalid, return 200 and request result as follows
Similarly, the identity of the negotiation cache is returned to the browser in the HTTP header of the response packet together with the request result. The fields controlling the negotiation cache are as follows: Last-modified/if-modified-since and Etag/if-none-match, where Etag/if-none-match has a higher priority than last-modified/if-modified-since.
Last-Modified / If-Modified-Since
Last-modified returns the time when the resource file was Last Modified on the server when the server responds to the request, as shown below.
If-modified-since indicates that when the client initiates the request again, it carries the last-Modified value returned from the Last request and tells the server the Last Modified time of the resource returned from the Last request. After receiving the request, the server finds that the request header contains the if-Modified-since field. The server compares the value of the if-Modified-since field with the last modification time of the resource on the server. If the last modification time of the resource on the server is greater than the value of the if-Modified-since field, the server compares the value of the if-Modified-since field with the last modification time of the resource on the server. The resource is returned with the status code of 200. Otherwise, 304 is returned, indicating that the resource has not been updated. You can continue to use the cache file, as shown below.
Etag / If-None-Match
Etag is a unique identifier (generated by the server) that is returned to the current resource file when the server responds to a request, as shown below.
If-none-match indicates that when the client initiates the request again, it carries the unique Etag value returned by the last request. The value of this field tells the server the unique Etag value returned by the last request. After receiving the request, the server finds that the request header contains if-none-match. The server compares the if-none-match field 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. If no, return the resource file with the status code 200, as shown in the following figure.
Note: Etag/if-none-match has a higher priority than last-modified/if-modified-since. If both Etag/if-none-match exist, only Etag/if-none-match takes effect.
conclusion
The mandatory-cache takes precedence over the negotiated Cache. If mandatory-cache (Expires and cache-control) is valid, the Cache is used directly, and If not, the negotiated Cache (last-modified/if-modified-since and Etag/if-none-match) is used. The server decides whether to use the negotiation cache. If the negotiation cache is invalid, the request cache is invalid, and the request result is obtained again and stored in the browser cache. If it takes effect, 304 is returned and the cache continues to be used. The main process is as follows:
Finally, a recommendation for you
[Issue 903] Anatomy of the browser cache mechanism
Issue 887. Summary of browser caching mechanisms
About the author: @ Ye Heying original: https://heyingye.github.io/2018/04/16/ / thoroughly understand the browser’s caching mechanism
