Background: Both the front-end and the back-end are familiar with http. Today, let’s briefly sort out the http cache part of the front-end cache. The details are as follows:
Front-end cache:
Front-end caching can be divided into two categories: http caching and browser caching. Today we will focus on http caching, so you can check browser caching by yourself. The following picture is a general knowledge point of the front-end cache:
HTTP cache
1. What is http cache
Http cache refers to: When the client requests resources from the server, it will first arrive at the browser cache. If the browser has a copy of the "resource to be requested", it can be extracted directly from the browser cache instead of from the original server. this resource.
The common http cache can only cache the resources of the get request response, but can't do anything for other types of responses, so the request cache mentioned later refers to the GET request.
HTTP caching starts from the second request. When the resource is requested for the first time, the server returns the resource and returns the cache parameters of the resource in the response header; when the browser judges these request parameters for the second request, it will directly 200 if it hits the strong cache, otherwise it will add the request parameters to Pass it to the server in the request header to see if it hits the negotiation cache, and returns 304 if it hits, otherwise the server will return a new resource.
1. Classification of http cache:
According to whether it is necessary to re-initiate a request to the server, it can be divided into (mandatory cache, negotiation cache) According to whether it can be used by a single or multiple users, it can be divided into (private cache, shared cache) If the mandatory cache takes effect, it will not It needs to interact with the server again, and whether the negotiation cache is effective or not, it needs to interact with the server. Here are some comparisons between forced caching and negotiated caching:
1.1. Mandatory caching
If the cached data is not expired (that is, the max-age of Cache-Control has not expired or the cache time of Expires has not expired), then the cached data of the browser will be used directly and no more requests will be sent to the server. When the mandatory cache takes effect, the HTTP status code is 200. In this way, the loading speed of the page is the fastest, and the performance is also very good, but during this period, if the resource on the server side is modified, it will not be available on the page, because it will no longer send a request to the server. This situation is what we often encounter in development. For example, you modify a certain style on the page, refresh it on the page but it does not take effect, because it uses a strong cache, so it will be fine after a short operation of Ctrl + F5 up. The header attributes related to mandatory caching are (Pragma/Cache-Control/Expires)
The priority issue when Pragma and Cache-Control coexist is still a bit controversial. I found in different articles: some say that Pragma has a higher priority, and some say that Cache-Control is higher. In order to clarify this problem, I decided to do a wave of hands-on operations. First, I used nodejs to build a background server for the purpose of setting cache parameters. The specific code is as follows:
Then visit on the browser: http://localhost:8888
is the data returned from the background when visiting for the first time:
On second visit:
Finally, it is concluded that
when Pragma and Cache-control coexist, Pragma has a higher priority than Cache-Control.
Note:
There are two situations for the 200 status returned in the chrome browser:
1. from memory cache
(obtain from memory/generally cache js, pictures, fonts and other resources with high update frequency)
2. from disk cache
(obtain from disk/generally cache js, css and other resources with low update frequency)
These two situations are a caching strategy of chrome itself, which is why the chrome browser responds quickly. Other browsers return the cached state, without identifying where the cache was obtained from.
chrome browser:
Firefox browser:
1.2. Negotiation cache
When there is no Cache-Control and Expires in the response header returned by the server during the first request, or the Cache-Control and Expires expire or its attribute is set to no-cache (that is, no strong cache), then the browser makes the second request Negotiation with the server will be carried out when the resource is updated, and compared with the server to determine whether the resource has been modified or updated. If the resources on the server side have not been modified, a 304 status code will be returned, telling the browser that the data in the cache can be used, thus reducing the data transmission pressure on the server. If the data is updated, a 200 status code will be returned, and the server will return the updated resource and return the cached information together. The header attributes related to the negotiation cache include (ETag/If-Not-Match, Last-Modified/If-Modified-Since) request headers and response headers need to appear in pairs
The execution process of the negotiation cache is as follows: when the browser sends a request to the server for the first time, it will return the header attributes of the negotiation cache in the response header: ETag and Last-Modified, where ETag returns a hash value, Last-Modified Modified returns the last modification time in GMT format. Then when the browser sends the request for the second time, it will bring the If-Not-Match corresponding to ETag in the request header, and its value is the value of the ETag returned in the response header, and the If-Modified- Since. After receiving these two parameters, the server will compare them. If the return is a 304 status code, it means that the requested resource has not been modified, and the browser can directly fetch the data from the cache, otherwise, the server will directly return the data.
Note:
ETag/If-Not-Match appeared in HTTP/1.1, mainly to solve the following problems:
(1) The last modification marked by Last-Modified can only be accurate to the second level. If some files are modified multiple times within 1 second, it will not be able to accurately mark the modification time of the file
(2), if some files have been modified, but the content has not changed, but the Last-Modified has changed, causing the file to fail to use the cache
(3) There may be situations where the server does not accurately obtain the file modification time, or the time is inconsistent with the proxy server, etc.
1.3. Private cache (browser-level cache)
Private caches can only be used by individual users: Cache-Control: Private
1.4. Shared cache (proxy-level cache)
Shared cache can be used by multiple users: Cache-Control: Public
2. Why use HTTP caching?
According to the above study, it can be found that the benefits of using cache are as follows:
1. Reduce redundant data transmission and save network fees.
2. Alleviate the pressure on the server and greatly improve the performance of the website
3. Speed up the loading speed of the client
3. How to use HTTP cache?
Generally, the resources that need to be cached include html pages and other static resources:
1. The setting of html page caching is mainly to embed <meta> tags in the <head> tags. This method is only valid for pages and not for resources on pages. 1.1
. The settings for disabling caching on html pages are as follows:
<meta http-equiv="pragma" content="no-cache">
// Tags that are only recognized by IE browsers may not necessarily add Pragma to the request field, but they will Let the current page send a new request every time
<meta http-equiv="cache-control" content="no-cache">
// tags recognized by other mainstream browsers
<meta http-equiv="expires" content="0 ">
// Only the IE browser recognizes the label. This method is only used as a mark to inform IE of the cache time. You cannot find the Expires field in the request or response message.
1.2. The html setting cache is as follows:
<meta http-equiv="Cache-Control" content="max-age=7200" />
// tags recognized by other mainstream browsers
<meta http-equiv="Expires" content=" Mon, 20 Aug 2018 23:00:00 GMT" />
// tag only recognized by IE browser
2. The cache of static resources is generally configured on the web server. Commonly used web servers are: nginx, apache. The specific configuration will not be introduced in detail here, you can check it yourself.
3. Several ways not to use the cache:
3.1, Ctrl + F5 to force refresh, will directly extract data from the server.
3.2. Press F5 to refresh or the browser's refresh button, and add Cache-Control: max-age=0 by default, that is, the negotiated cache will be used.
3.2. Do not want to use cache under IE browser: Open IE, click Tools->Internet Options->General->Browsing History Settings on the toolbar. Select "Never", and then save. Finally, click "Delete" to delete all temporary Internet files (the files cached by IE are temporary Internet files).
3.3. There is also the method of disabling the cache in 1 and 2 above.
3.4. There are also ways to clear the cache for other browsers
Fourth, several points for attention in HTTP caching
1. In the case of strong caching, as long as the cache has not expired, the data will be directly fetched from the cache. Even if there is a data change on the server side, it will not be obtained from the server side, so that the modified data cannot be obtained. The solution is: add a random number to the modified resource to ensure that it will not be taken from the cache.
For example:
http://www.kimshare.club/kim/common.css?v=22324432
http://www.kimshare.club/kim/common.2312331.css
2. Try to reduce 304 requests, because we know that the negotiation cache will interact with the background server every time, so the performance is not very good. From a performance point of view, use strong cache as much as possible.
3. Under the Firefox browser, using Cache-Control: no-cache is invalid, and it recognizes no-store. This can achieve the effect of other browsers using Cache-Control: no-cache. So in order to be compatible with the Firefox browser, it is often written as Cache-Control: no-cache, no-store.
4. Several header attributes related to caching are: Vary, Date/Age.
Vary:
Vary itself means "change", and in the http message, it tends to mean "vary from" (different from...), which indicates what benchmark field the server will use to distinguish and filter the cached version.
There is such an address on the server side, if it is an IE user, it will return the content developed for IE, otherwise it will return the content of another mainstream browser version.
Format: Vary: User-Agent
informs the proxy server that it needs to use the User-Agent request header field to distinguish the cache version, so as to prevent the cache passed to the client from being incorrect.
Date/Age:
Date and Age fields in the response message: to distinguish whether the received resource hits the cache of the proxy server.
Date is of course the time (in GMT format) when the original server sent the resource response message. If you find that the time of Date is quite different from the "current time", or if you refresh F5 continuously and find that the value of Date has not changed, it means that your current request It hit the cache of the proxy server.
Age is also the first field in the response message, which indicates the time (in seconds) that the file exists in the proxy server. If the file is modified or replaced, Age will start accumulating from 0 again.
browser cache
Let’s talk about the most commonly used browser caches: cookie, sessionStorage, and localStorage. The main features of these three are as follows:
Summary of this article:
1. For mandatory caching, the server notifies the browser of a caching time. Within the caching time, the next request will directly use the caching. If it is not within the time, the negotiation caching strategy will be executed.
2. For the negotiation cache, the Etag and Last-Modified in the cache information are sent to the server through the request, and the server verifies it. When the 304 status code is returned, the browser directly uses the cache.
The following figure is the execution flow chart of the browser sending the http request for the first time and again:
The above is about the collation of http cache. This article is reproduced from kim, hoping to help everyone understand http.