Recently accumulated some knowledge about HTTP caching, so combined with chromium implementation summary, mainly from the following 2 facets:
1. Basic knowledge of HTTP caching
2, chromium about the implementation of HTTP cache analysis
I. Basics of HTTP Caching
Basically, each browser has the HTTP caching feature enabled.
When the server returns a response, it responds to a set of HTTP headers that describe the content type, length, cache instruction, authentication token, and so on for the response.
For example, in an interaction, the server returns a 1024-byte response that instructs the client to cache it for up to 120 seconds and provides a validation token ("X234DFF") that can be used to check if the resource has been modified after the response expires.
Therefore, the browser can verify the cached response through the ETAG:
1. The server uses the ETag HTTP header to pass authentication tokens.
2. Validation tokens enable efficient resource update checks: No data is transmitted when the resource has not changed.
From a performance optimization standpoint, the best request is a request that does not require communication with the server: All network latencies can be eliminated through a local copy of the response, and traffic charges for data transfer are avoided.
To achieve this, the HTTP specification allows the server to return Cache-control directives that control how the browser and other intermediate caches cache individual responses and how long the cache is cached.
Note: The Cache-control header is defined in the http/1.1 specification, replacing the header (such as Expires) that was previously used to define the response cache policy. All modern browsers support Cache-control, so it's enough to use it.
"No-cache" and "No-store"
"No-cache" means that you must first confirm with the server whether the returned response has changed before you can use the response to satisfy subsequent requests for the same URL. Therefore, if there is an appropriate authentication token (ETAG), No-cache initiates a round-trip communication to validate the cached response, but avoids the download if the resource has not changed.
By contrast, "No-store" is much simpler. It directly prohibits the browser and all intermediate caches from storing any version of the return response, such as a response that contains personal privacy data or bank business data. Each time a user requests the asset, it sends a request to the server and downloads the full response.
"Public" and "private"
If the response is marked as "public", the response can be cached even if it has associated HTTP authentication, and even the response status code is usually not cached. In most cases, "public" is not required because explicit cache information (such as "Max-age") has indicated that the response is cacheable.
By contrast, browsers can cache "private" responses. However, these responses are usually cached only for a single user, so no intermediate caches are allowed to cache them. For example, a user's browser can cache HTML pages that contain user private information, but the CDN cannot cache.
"Max-age"
The instruction specifies the maximum time (in seconds) to allow the retrieved response to be reused, starting at the requested time. For example, "max-age=60" means that the response can be cached and reused in the next 60 seconds.
Ii. Chromiun implementation of HTTP caching
Code reading is very complicated, so it is to follow their own understanding of the drawing of a class diagram, after the painting is sure that it is clearly a lot.
Content reference: HTTPS://DEVELOPERS.GOOGLE.COM/WEB/FUNDAMENTALS/PERFORMANCE/OPTIMIZING-CONTENT-EFFICIENCY/HTTP-CACHING?HL=ZH-CN
Chromium Source Read--http Cache