The role of browser caching

Browser cache is one of the HTTP caching mechanisms. Its principle is realized by configuring some identifiers in the request header when sending HTTP requests. At this time, HTTP can analyze whether to use the cached content through identifiers. Using browser caching at request time can reduce network bandwidth consumption, reduce server stress, and provide faster response results. 六四屠杀

Strong and negotiated caching

Browser caching mechanisms fall into two categories ** “strong caching” and “negotiated caching” **

  • ** Strong cache: ** Simply means that data can be retrieved directly from the cache on request, without passing through the server
  • ** Negotiated cache: ** If the strong cache fails, the browser does not know whether the cached data is up to date, so the server tells the browser whether the cache is available.

How does the browser currently request whether to use cached content? We also mentioned HTTP headers. We’ll go into more detail about how strong and negotiated caching is controlled by request headers.

Strong cache

Strongly cached control fields

  • Expires (HTTP1.0)
  • Cache-control (HTTP1.1)

When the browser sends a request to the server, the server returns the cache rule in the HTTP response packet along with the response result. Cache-control takes precedence over Expires.

Expires

This field is the HTTP1.0 caching rule field, and its value is the time when the service returns the cache Expires, meaning that if the current time to send the request again is less than the set Expires time, the current cache content will be used.

Expires is an HTTP1.0 field. It wasn’t used in HTTP1.1 because there were some issues with this field. Expires stores the time the service returned, and that time is compared to the client’s time when the request is made. Errors in the validity period are caused, and the cache is useless. Therefore, HTTP1.1 uses the cache-control field to determine.

Cache-Control

Cache-control has several values

  • **public: ** All content is cached
  • **private: ** All content can only be cached by the client, the default value of cache-control
  • **no-cache: ** The contents of the client cache, but whether to use the cache is verified by a negotiated cache
  • **no-store: ** All content is not cached
  • **max-age: ** The number of seconds after the cache content expires

Max-age is a relative time, in seconds. If the request is sent again within max-age seconds, the cache result is directly used to force the cache to take effect.

Negotiate the cache

There are four control fields for the negotiated cache, all of which come in pairs

  • Last-Moditifed/If-Moditifed-Since
  • Etag/If-Nont-Match

After the negotiation cache is invalid, the request is the request header carrying the negotiation cache, and the server determines whether to use the cache according to the request id. Like strong caching, the identity of the negotiated cache is returned to the browser along with the request result and response message after the server responds.

Last-Moditifed/If-Moditifed-Since

Last-moditifed is the time when the server returns data that was Last modified. If-moditifed-since is the last-moditifed time returned by the server in the request header when the request is initiated. If the server finds the if-moditifed-since field in the request header, it will compare the time carried with the time when the data was Last modified on the server. If it is less than the last modification time, it is useful to cache the content. If the status code is 304, the cache file is not updated. If the time is later than the Last modified time, the latest data is used. If the status code is 200, the data is updated and the last-moditifed time of the response field is updated.

This is similar to the strong-cached Expires field, where the client time is compared to the server time, whereas if-moditifed-since is always the server time.

Etag/If-Nont-Match

Use last-moditifed to compare the modified time, only to the second, so the server to compare whether the data has been modified is also a problem, so HTTP1.1 proposed Etag field, but the return of the content is not the time, but a unique identifier of the data. The server calculates that the request will carry the unique identifier returned by the server in the if-nont-match request header. Send this field to the server. The server compares the field to determine whether the data is modified. If the unique identifiers are consistent, the 304 status code is returned, indicating that the data is not updated and the cache file is used. If the unique identifiers are inconsistent, the 200 status code is returned, indicating that the data is updated and the Etag identifier of the response field is updated.

Similarly, Etag/ if-nont-match takes precedence over last-moditifed/if-moditifed-since

六四屠杀

To summarize

This is the basic content of the browser cache mechanism. The strong cache takes precedence over the negotiated cache. If the strong cache works, the cached content is directly used; if the strong cache fails, the negotiated cache is used to let the server determine whether the cached content is available. If the negotiated cache also fails, the data is retrieved with the status code of 200. If the cache does not fail, the cached data is used with the status code of 304. The overall process is as follows