The old saying goes, enter the url to the page loading display is complete

The old saying goes about entering the url to the page loading display is complete, what have you experienced in the middle && browser cache resolution

From: https://www.dazhuanlan.com/2019/12/18/5df9c4cb4e563/

Basic process

1. Type url -Enter
2. The browser first checks the browser cache-system cache-router cache, if there is in the cache, it will directly display the content on the screen. If not, skip to the third step
3. DNS resolution, get the corresponding IP address (first check whether there is a domain name corresponding to the ip in the cache, and then query the local hosts file, if nothing is available, then query the dns server)
4. The browser initiates a TCP connection to the server and establishes a TCP three-way handshake with the browser.
5. After the handshake is successful, the browser sends an http request to the server, requesting data
6. The server receives the request and sends the data to the browser
7. Browser accepts response
8. Read page content, browser rendering, parse html source code
9. Generate dom tree, css tree, js parsing
10. Client and server interaction
11. ajax request

Process 2 analysis (to thoroughly understand the browser caching mechanism)

Two concepts

• Strong cache

The request sent by the user is directly obtained from the client cache, the request is not sent to the server, and no interaction behavior occurs with the server.

• Negotiation cache

After the request sent by the user is sent to the server, the browser determines whether to obtain the resource from the cache.

Analysis of the four processes in the figure

(A) The browser determines whether there is a cache

The so-called "client-side cache" refers to the user's local resources. The addresses of cached files in different browsers are different.

Go to the chrome://cache page, every item in it is a cache

Just click on a resource, you can see:

Back to the question, how does the browser determine whether there is a cache? It can be converted to the browser to read the local cache (Note: different browsers and different systems will be different) whether there is a corresponding request.

In summary, it is a problem of finding whether the file exists.

(B) Whether the cache expires

Let's take this picture again as an example. This picture shows that the client retains a server-side response header.
The Date field inside indicates the time of the server at the time of caching.
There are two fields: expires, Cache-Control

• expires

The standard in Http1.0 indicates the expiration time. Note that the time here refers to the time of the server.
You can see that the expiration time is set to: Thu, 28 Sep 2017 06:38:37 GMT

The problem: the inconsistency between the server time and the client time will cause the cache to deviate from the expected effect.

• Cache-Control

The standard in Http1.1 can be seen as a supplement to expires. The concept of relative time is used.
Briefly introduce the property settings of Cache-Control.

1. max-age: Set the maximum effective time of the cache, in seconds (s). max-age will overwrite Expires

2. s-maxage: Only used for shared cache, such as CDN cache (s -> share). The difference with max-age is: max-age is used for normal caching, while s-maxage is used for proxy caching. If s-maxage is present, it will override max-age and Expires.

3. public: The response will be cached and shared among multiple users. The default is public.

4. private: The response is only used as a private cache and cannot be shared among users. If HTTP authentication is required, the response will be automatically set to private.
5. no-cache: Specifies not to cache the response, indicating that the resource is not cached. However, setting no-cache does not mean that the browser does not cache, but to confirm to the server whether the resource has been changed before caching. Therefore, sometimes it is not enough to set no-cache to prevent caching. You can also add a private command to set the expiration time to a time in the past.
6. no-store: absolutely forbid caching.
7. must-revalidate: If the page expires, go to the server to get it.

So the steps to determine whether the cache expires are:

1. Check if there is max-age / s-maxage of cache-control. If so, use the server time date value + max-age/s-maxage seconds to calculate the new expiration time, and compare the current time with the expiration time To determine whether it has expired

2. Check if there is max-age / s-maxage of cache-control, then use expires as the expiration time comparison

Summary: (b) After the process is executed, if it is determined that it has not expired, the client-side cache is used. Then it is a "strong cache".

(C) Negotiate with the server whether to use caching

At this point, the browser will send a request to the server, and if there are Last-modified and Etag fields in the previous cache, the
browser will add If-Modified-Since (corresponding to Last-modified) to the request header. And If-None-Match (corresponding to Etag).

• Last-modified: Indicates the last modification time of the requested resource.
• If-Modified-Since: The last modification time of the resource reserved by the client.
• Etag: The content identifier of the resource. (Not unique, usually the md5 of the file or a section of hash value, as long as the method of writing and verification is the same)
• If-None-Match: The resource content identifier reserved by the client.

Normally, if the If-None-Match and If-Modified-Since fields are sent at the same time, the server only needs to compare the content of the etag. Of course, the specific processing method depends on the server's agreed rules.

(D) Negotiation cache

At this stage, the server generally returns fields such as Cache-control, expires, last-modified, date, etag, etc. in the response header to facilitate the next cache. Of course, the specific scenario depends on the server's agreed rule setting.

user behavior

Finally, attach a piece, user behavior affects the browser's caching behavior.