1. HTTP message introduction
HTTP message is the data block sent and responded when the browser and server communicate.
The browser requests data from the server and sends request message; the server returns data to the browser and returns response message.
Message information mainly includes:
1. Start line ———— the first line of the message is the start line, which is used to describe what to do in the request message and what happened in the response message
2. Include the header of attributes – additional information (cookies, cache information, etc.) and cache related rule information, all of which are included in the header
3. Body containing data — the part that HTTP request really wants to transmit
2. Cache rule resolution
To facilitate your understanding, we believe that there is a cache database in the browser for storing cached information.
When the client requests data for the first time, there is no corresponding cache data in the cache database. It needs to request the server. After the server returns, the data will be stored in the cache database.
There are many rules for HTTP caching, which can be classified according to whether it is necessary to re initiate a request to the server. I divide it into two categories (mandatory caching and comparative caching)
Before introducing these two rules in detail, let us have a simple understanding of these two rules by means of time sequence diagram.
Students who don’t know much about the caching mechanism may ask, in the process based on comparison caching, whether or not to use caching, they need to send requests to the server, so what else can we do with caching?
This question, let’s put it down for the moment. When we introduce each caching rule in detail later, we will give you the answer.
We can see the difference between the two types of caching rules. If the forced cache is effective, there is no need to interact with the server. However, whether the comparative cache is effective or not, it needs to interact with the server.
Two types of cache rules can exist at the same time, and the priority of forced cache is higher than that of comparative cache. That is to say, when the rules of forced cache are executed, if the cache takes effect, the cache is directly used instead of the comparative cache rules.
3. Force cache
From the above we know that forced caching can directly use cached data when the cached data is not invalid. How does the browser judge whether the cached data is invalid?
We know that when there is no cache data, when the browser requests data from the server, the server will return the data together with the cache rule, and the cache rule information is included in the response header.
For the forced cache, there are two fields in the response header to indicate the invalidation rule（Expires/Cache-Control）
Using the developer tools of chrome, you can clearly see the situation of network requests when the forced cache takes effect
The value of expires is the expiration time returned by the server, that is, the next request, when the request time is less than the expiration time returned by the server, uses the cached data directly.
However, expires is the thing of HTTP 1.0. Now, the default browsers use HTTP 1.1 by default, so its function is basically ignored.
Another problem is that the expiration time is generated by the server, but there may be errors between the client time and the server time, which will lead to cache hit errors.
So in the version of HTTP 1.1, cache control is used instead.
Cache control is the most important rule. Common values include private, public, no cache, Max age, and no store. The default value is private.
Private: clients can cache Public: both the client and the proxy server can be cached (the front-end students can think that public and private are the same) Max age = XXX: cached content will expire in XXX seconds No cache: you need to use the contrast cache to verify the cached data (described later) No store: all content will not be cached, forced caching, and comparison caching will not be triggered (for front-end development, the more cache, the better, so... Basically 886)
4. Compare cache
As the name implies, it is necessary to compare and judge whether cache can be used.
When the browser requests data for the first time, the server will return the cache ID and data to the client, and the client will back them up to the cache database.
When requesting data again, the client sends the backup cache ID to the server. The server judges according to the cache ID. after the judgment is successful, the server returns 304 status code to notify the client that it is successful and can use the cache data.
Through the comparison of the two figures, we can clearly find that when the comparison cache is effective, the status code is 304, and the message size and request time are greatly reduced.
The reason is that after the identification comparison, the server only returns the header part and informs the client to use the cache through the status code, so it is no longer necessary to return the message body part to the client.
For the comparison cache, we need to understand the delivery of the cache identity, which is delivered between the request header and the response header,
There are two types of identity passing. Next, we will introduce them separately.
Last-Modified / If-Modified-Since
When the server responds to the request, it tells the browser when the resource was last modified.
When the server is requested again, this field informs the server of the last modification time of the resource returned by the server at the time of the last request.
After receiving the request, the server finds that the header if modified since is compared with the last modification time of the requested resource.
If the last modification time of the resource is longer than if modified since, it means that the resource has been modified again, then it will respond to the whole resource content and return the status code 200;
If the last modification time of the resource is less than or equal to if modified since, it means that there is no new modification of the resource, then respond to HTTP 304 and inform the browser to continue to use the saved cache.
Etag / if none match (priority higher than last modified / if modified since)
When the server responds to the request, it tells the browser the unique identification of the current resource on the server (the generation rule is determined by the server).
When the server is requested again, this field informs the server of the unique identity of the client segment cache data.
After receiving the request, the server finds that if none match with the header is compared with the unique ID of the requested resource,
Different, indicating that the resource has been changed again, it will respond to the whole resource content and return status code 200;
Same, indicating that there is no new modification to the resource, respond to HTTP 304, and inform the browser to continue to use the saved cache.
4. Summary of caching mechanism
For the forced cache, the server informs the browser of a cache time. In the cache time, the next request directly uses the cache, but not in the time, executes the compare cache strategy.
For the comparison cache, Etag and last modified in the cache information are sent to the server through a request, which is verified by the server. When 304 status code is returned, the browser directly uses the cache.
5. Supplement to Etag
What is Etag
Etag: abbreviation of entity tag. Etags are generally not sent to clients in clear text. In each life cycle of a resource, it has different values to identify the state of the resource. When a resource changes, if one or more of its header information changes, or the message entity changes, then the Etag changes.
The change of Etag value indicates that the resource status has been modified. Etag header information can be obtained cheaply by time stamp. In the server, if the corresponding sent back to the consumer is controlled by Etag from the beginning, it can ensure that the more fine-grained Etag upgrade is completely controlled by the service. The service calculates the Etag value and returns it to the client when the corresponding client requests it.
Generally speaking, Etag is the identifier of a specific version of a resource, which is represented as a hash. When a resource is updated, the Etag value also needs to be updated.
Calculate Etag value
There is no specification on how to calculate Etag in HTTP 1.1 protocol. Etag value can be anything that uniquely identifies a resource, such as the version associated with a resource in persistent storage, one or more file attributes, entity header information and verification value, (checksum), or hash value of entity information. Sometimes, in order to calculate an Etag value may have a relatively high cost, you can generate a unique value (such as a common GUID) at this time.
Using the timestamp as a string is a cheap way to get the Etag value. It’s a good enough solution for news that doesn’t change often. The most expensive way to calculate the Etag value is to use the hash algorithm to get the expression value of the resource. You can only calculate the hash value of the resource, or you can include the header information and the value of the header information. If you include header information, be careful not to include header information for the computer ID. You should also avoid including expires, cache control, and variable header information. Note: when calculating the Etag value through the hash algorithm, first assemble the resource representation. If assembly is also time-consuming, you can generate guids. Optimize the acquisition of Etag value.
Types of etags and their differences
There are two types of etags: strong Etag and weak Etag.
Strong Etag representation: "22faa065-2664-4197-9c5e-c92ea03d0a16" Expression of weak Etag: w / "22faa065-2664-4197-9c5e-c92ea03d0a16"
The appearance of strong and weak Etag types is related to the way Apache servers calculate Etag. By default, Apache automatically generates etags through the configuration of fileetag inode mtime size in fileetag (which can also be customized by users).
Inode: number of inodes in the file Mtime: last modified date and time of the file Size: number of bytes in the file
When using Etag in large-scale multi Web Clusters, there are problems, so it is suggested that Etag should not be used when using web clusters. In fact, it is a good solution. Because the inode of multi servers is different, the Etag generated by different servers is different, so users may repeatedly Download (at this time, the Etag will not be allowed). After understanding the above principles and settings, the solution is very easy. Let the next two parameters of Etag As long as Etag is calculated without inode, it will be very accurate
Difference between Etag and last modified
According to the HTTP standard, last modified can only be accurate to the second level. The emergence of Etag can solve this problem well.
Cache control and Etag are set at the same time
When cache control / max age and expires are set on the server at the same time, they will be used at the same time. That is to say, only after if modified since and if none match are fully matched, i.e. the modification time and Etag are checked, can the server return 304