HTTP caching mechanism and principle
Preface
Http caching mechanism is an important means for web performance optimization. We need to better understand the principle of Http caching in order to better understand how it actually works, and what caching is usually said, and how is it implemented?
HTTP message
Before understanding the Http cache, we must first understand the Http message. This is because the cache for Http has a great relationship with the message of Http.
Http message, Http message is the data block that is sent and responded to between the browser and the server.
When the browser requests data from the server, it sends a request (request) message ; when the server returns data to the browser, it returns a response (response) message .
The message information is mainly divided into four parts:
-
First line: request method, Http protocol version, status code and status code description
-
Header: key and value key-value pairs, used to store records, data length, data type, whether to cache, and data matching and other information
-
Blank line: separate header and body
-
Body: Http request and the place where data is transmitted in response
Cache rule analysis
Assume that the browser has its own cache database dedicated to caching information.
When the client requests data for the first time, there is no corresponding cache data in the cache database at this time, and the server needs to be requested. After the server returns, the data is stored in the cache database.
There are many types of HTTP caching. According to whether you need to re-initiate a request to the server , we divide them into two categories: mandatory caching and contrast caching
Cached data already exists, based only on mandatory cache , the process of requesting data is as follows:
Cached data already exists. Based on the comparison cache , the process of requesting data is as follows:
We can see the difference between the two types of caching rules. If mandatory caching takes effect, there is no need to interact with the server, while contrast caching needs to interact with the server regardless of whether it takes effect.
Two types of caches can exist at the same time, and the mandatory cache priority is higher than the comparison cache, which means that when the mandatory cache rule is executed, if the cache takes effect, the cache is used directly, and the comparison cache rule is not executed.
Forced caching
From the above, it is known that forced caching can directly use the cached data when the cached data is not invalid. So how does the browser judge whether the cached data is invalid?
We know that when there is no cached data, when the browser requests data from the server, the server will return the data along with the caching rules , and the caching rule information is included in the header.
For mandatory caching, there will be two fields in the response header to identify the expiration rule (Expires/Cache-Control). Using Chrome's developer tools, it can be clearly seen that the mandatory caching takes effect in the case of network requests.
Expires
The value of Expires is the expiration time returned by the service , that is, the next request, the request time is less than the expiration time returned by the server, and the cached data is used directly. However, Expires is HTTP 1.0. Now the default browser uses HTTP 1.1, so its role is basically ignored.
Another problem is that the expiration time is generated by the server, but the client time may be different from the server time, which will cause the error of cache hits, so the HTTP 1.1 version uses Cache-Control instead.
Cache-Control
Cache-Control is the most important rule. Common values are private, public, max-age, no-cache, no-store, and the default is private
-
private: client can cache
-
public: Both the client and the proxy server can be cached
-
max-age=xxx: The cached content will become invalid after xxx seconds
-
no-cache: Need to use contrast cache to verify cached data
-
no-store: All content will not be cached, forced cache, and comparison cache will not be triggered
for example:
In the figure, Cache-Control only specifies max-age, so the default is private , and the cache time is 3153600 seconds (365 days). That is to say, this data is requested again within 365 days and used directly.
Contrast cache
Comparing the cache , as the name implies, requires comparison to determine whether the cache can be used. When the browser requests data for the first time, the server returns the cache identifier and the data to the client, and the client backs up the two to the cache database.
When requesting data again, the client sends the backed-up cache identifier to the server, and the server makes a judgment based on the cache identifier. After the judgment is successful, it returns a 304 status code to notify the client that it is relatively successful and can use the cached data.
First visit:
Second visit:
Through the comparison of the two figures, we can clearly find that when the comparison cache takes effect, the status code is 304, and the message size and data volume are greatly reduced .
The reason is that after the cache identification, the server only returns the header part, and informs the client to use the cache through the status code, and there is no need to return the body of the message to the client.
For the contrast cache, the transmission of the cache identifier is what we need to understand. It is passed between the request header and the response header.
There are two types of delivery:
Last-Modified：
In response to the request, the server tells the browser the last modification time of the resource.
If-Modified-Since：
When you request the server again, the browser will add the parameter If-Modified-Since (the value is Last-Modified in the last response) to the request. After the server receives the request, it finds the header If-Modified-Since and the requested The last modification time of the resource is compared.
If the last modification time of the resource is greater than If-Modified-Since, indicating that the resource has been modified, it will respond to the entire resource content and return a status code of 200 ; if the last modification time of the resource is less than or equal to If-Modified-Since, the resource has no New modification will respond to HTTP 304 , telling the browser to continue using the saved cache.
Etag：
When the server responds to the request, it tells the browser the unique identifier of the current resource on the server (the generation rule is determined by the server).
If-None-Match:
When requesting the server again, this field is used to notify the server of the unique identifier of the data cached by the client. After receiving the request, the server finds that the header If-None-Match is compared with the unique identifier of the requested resource. If it is different, indicating that the resource has been changed, it will respond to the entire resource content and return a status code of 200; the same, indicating the resource If there is no new modification, it responds with HTTP 304, telling the browser to continue using the saved cache.
to sum up
For forced caching, the server informs the browser of a caching time. During the caching time, the next request will use the cache directly, and the comparison caching strategy will be executed if it is not within the time.
For the comparison cache, the Etag and Last-Modified in the cache information are sent to the server through a request, which is verified by the server. When a 304 status code is returned, the browser directly uses the cache.
The first request of the browser:
The second browser request:
