Recently in the CDN optimization, the browser cache in-depth study, record, convenient later
Drew a sketch:
The details of each state are as follows:
1, the last-modified
The first time a browser requests a URL, the server returns a status of 200 with the requested resource and a last-Modified attribute. The file was Last Modified at the server end in something like this: HttpReponse Header
Last-Modified:Tue, 24 Feb 2009 08:01:04 GMT
When the client requests this URL a second time, the browser sends an if-modified-since Header to the server, asking If the file has been Modified Since:
If-Modified-Since:Tue, 24 Feb 2009 08:01:04 GMT
If the resources on the server do not change, the HTTP304 (NotChanged.) status code is automatically returned with nothing, thus saving the amount of data transferred. When server-side code changes or the server is restarted, the resource is re-issued, returning similar to the first request. This ensures that resources are not repeatedly issued to the client and that the client can get the latest resources when the server changes.
Note: If the time of if-modified-since is later than the current time of the server (the current request time request_time), it is considered an illegal request
2. Working principle of Etag
The HTTP protocol specification defines the ETag as the “entity tag of the requested variable” (see 14.19). The simplest is that the server responds by marking the request URL and passing it to the client in the HTTP response header, similar to the format returned by the server:
Etag: “5 d8c72a5edda8d6a: 3239”
The client’s query update format looks like this:
If None – Match: “5 d8c72a5edda8d6a: 3239”
If the ETag has not changed, the status 304 is returned.
After the client sends the request, the HttpReponse Header contains the Etag: 5D8C72a5edDA8D6A6:3239.
The identifier tells the Client that the resource you have received has a representation ID: 5D8C72A5EDDA8D6A1:3239. When the browser sends a Request for the same URI the next time, the browser sends an if-none-match header (Http RequestHeader) containing the Etag 5D8C72a5EDDA8D6A8:3239.
If None – Match: “5 d8c72a5edda8d6a: 3239”
In this case, if the Client Cache is equal to two copies, the server will compare the two etags. If if-none-match is False, return 304(Not Modified) Response instead of 200.
3, Expires
The date/time given after the response is considered obsolete. Example Expires:Thu, 02 Apr 2009 05:14:08 GMT
Used in combination with last-Modified. Used to control the validity of the request file when the client browser requests data from the cache rather than the server when the request data is within the validity period. The decision to update data from the server is made when the data in the cache becomes invalid or expired.
4. Last-modified and Expires
The last-Modified flag can save a bit of bandwidth, but you still can’t send an HTTP request out, and it needs to be used with Expires. The Expires flag, on the other hand, allows the browser to not even send an HTTP request. For example, when the user F5 or hits the Refresh button, an HTTP request will be sent even to a URI with Expires, so last-Modified is still used. And use Expires with it.
5. Etag and Expires
If both Etag and Expires are set on the server, Etag works the same way: HttpRequestHeader: if-modified-since and if-none-match are HttpRequestHeader versions of last-Modified /Etag. We can see that the values of these two headers are exactly the same as the last-Modified Etag value issued by the WebServer; 304 is returned only after a full Match of if-modified-since and if-none-match is checked for modification time and Etag.
Last-modified and Etag
Last-modified files must be consistent across multiple machines in a distributed system so that load balancing across different machines does not result in a failed alignment
Etags should be turned off for distributed systems as much as possible (eTAGS will vary from machine to machine)
Last-modified is used in conjunction with the HTTP header requested by ETags. The server first generates last-Modified /Etag, which the server can use later to determine whether the page has been Modified and whether the file should continue to be cached
The process is as follows:
1. The client requests A page (A).
2. The server returns to page A and adds A last-Modified /ETag to page A.
3. The client displays the page and caches it along with last-Modified /ETag.
4. The client requests page A again and passes the last-Modified /ETag returned by the server in the Last request.
5. The server checks the last-Modified or ETag, determines that the page has not been Modified since the Last client request, and returns 304 with an empty response body.
Note:
1. Both last-Modified and Etag headers are HttpReponse headers issued by the WebServer and should be supported by the WebServer.
2. After the WebServer sends last-Modified /Etag headers to the client, the client caches these headers.
HttpRequestHeader: if-modified-since and if-none-match HttpRequestHeader: if-modified-since and if-none-match We can see that the values of these two headers are exactly the same as the last-Modified Etag value issued by the WebServer;
4. Check the above values on the server to determine whether the file continues to be cached.
Cache-control: max-age= seconds and Expires
Expires = time, HTTP version 1.0, the cache load time that allows clients to not check before max-age = seconds, HTTP version 1.1, how many seconds a resource is cached locally. If both max-age and Expires exist, they are overridden by the max-age of cache-control.
One drawback to Expires is that the returned expiration time is the server-side time. The problem with Expires is that if the client time is too different from the server time, the error can be large, so starting with HTTP 1.1, cache-control: max-age= seconds is used instead.
Expires =max-age + “Current request time per download”