Strong and negotiated caching

The first time we visit a web site, the server returns all the resources, but the second time we visit it there’s no need for the browser to return all the resources to us. Instead of accessing the server, we can read the corresponding copy of the first access directly from the memory cache or from dist cache. This saving action is cache (verb), and the saved copies are also cache (noun).

Why cache?

Objective factors

  • Network requests and loads are much slower than CPU calculations
  • Network request instability (greatly affected by environmental factors

Advantages of caching

  • Reduces unnecessary data access and saves bandwidth
  • Saves the server’s burden, improves the website’s performance
  • Speed up the browser to load resources and pages

What resources can be cached?

  • Mainly static resources, such as:
    • js
    • css
    • img

Strong cache

Strong cache is also mandatory cache. When the browser first requests, the server will determine whether the returned resource can be cached, so it returns the cache-Control/Expires configuration field corresponding to the cache in response header to inform the browser to perform the corresponding operation, where:

  • expires

    Format: Expires: Fri, 18 June 2021 01:03:05 GMT

    Http1.0-era defined field that indicates the expiration time before the client will retrieve the resource directly from the cache again instead of accessing the server, if needed.

  • cache-control

    Http1.1-era fields have more values that can be set than expires fields, such as:

    • Cache-control: Max – age = 2592000, public

      Max-age indicates the time, in seconds. The value above indicates that the resource is obtained by reading the cache within 30 days

      Public: indicates that both the client and server can cache the resource

  • cache-control: max-age=xxx private

    Indicates that the resource is fetched by reading the cache for a valid period of XXX seconds

    Private indicates that only the client can cache the resource

  • cache-control: no-cache

    Skip mandatory caching (without prejudice to negotiated caching) and access the server on every request

  • cache-control: no-store

    No caching, neither strong caching nor negotiated caching

ps:

  • Current browsers are compatible with Expires and Cache-Control, and when both are present, the browser will be dominated by cache-Control
  • The resource in the strong cache returns a status of 200

Negotiate the cache

Negotiation cache, also called comparison cache, is a caching strategy on the server. The server compares server resources with client resources by resource identification to determine whether the cache can continue to be used.

  • When the client first requests the server, the server returns the resource with the resource identifier ETAG/last-Modified

  • When the client requests the resource again, it will carry the corresponding resource identifier to access the server. The server compares and determines the resource consistency, and then returns the status 304. The client continues to use the cache, otherwise returns the status 200 with the latest resource content and the new ETAG/last-Modified

Resource identifier

There are two types of resource identifiers returned by the server in the Response Header, and two corresponding ones carried by the client in the Request Header:

  • last-modified

    Format: Last-Modified: Thu, 17 June 2021 09:49:49 GMT

    • The (last) modification time of the resource

    • On the first Request, the server returns the resource with last-Modified. On the second Request, the client accesses the server with the if-Modified-since field in the Request Header. The value of this field matches the last-Modified value

    • If the server receives if-modified-since, it will determine whether the last modified time of the corresponding resource in the server is the same as the value sent. If so, 304 will be returned; otherwise, 200 will be returned, and the latest resource and the last modified time last-modified

  • etag

    Format: etag: ’60B9D61E-9e8B8′

    • Unique identifier of the resource, generated based on the content of the resource (string, unique per file, similar to the hash generated by file packaging)

    • On the first Request, the server returns the resource and eTAG. On the second Request, the client carries the if-none-match field in the Request Header to access the server. The value of the if-none-match field is consistent with the value of the ETAG

    • If the resource has not changed, the server returns 304 for the eTAG calculated for the corresponding resource, or 200 for the latest resource and the latest ETAG if it has changed

Using a comparison diagram, we can see more intuitively the size of the resource directly requested and the size returned in the negotiated 304 state:

ps:

  • Etag and Last-Modified can coexist without conflict
  • Etag is preferred when both coexist because last-Modified is only accurate to the second level
  • If the resource is generated repeatedly but with the same content, the last-Modified value changes but the eTAG remains the same, so the Etag is more accurate

Impact of a refresh operation on cache

Ordinary refresh

Refers to entering the URL in the address bar, moving forward or backward, etc

  • Both the mandatory cache and the negotiated cache are valid

Manually refresh

Windows: F5, MAC: CMD + R, click refresh button, right menu refresh, etc

  • Force cache invalidation, negotiate cache validity

Forced to update

Windows: CTRL + F5; MAC: Shift + CMD + R

  • Enforce cache and negotiate cache invalidation

conclusion

Use a flow chart to summarize strong cache and negotiated cache:

The resources

  • Mainly refer to the mooC network teacher Shuangyue about caching related video materials