HTTP caching protocol in action

1. What is cache

Cache, also known as Cache, we call the place where data is temporarily stored as the cache pool, and the data in the cache pool is called the cache. When users need to use these data, they first look for them in the cache, and use them directly if they are found. If you can't find it, go to other data sources to find it.

2. Why use caching technology

The essence of caching is to exchange space for time, and temporarily replace the latest data read from the data source with temporarily stored data. The benefits brought by this method are different in different scenarios.

For example:

When we need water, we take out a water glass, go to the faucet and grab a glass of water to drink. You can think about why you use a cup to drink water, instead of drinking directly from the tap with your mouth.

Drinking water from a cup does have some existing problems. For example, the water in the cup tends to get cold, and the water from the faucet is indeed a constant temperature. We can imagine that the scene of colleagues in the company queuing under the tap to drink water is indeed a bit comical, and we would rather accept the problem that the water in the cup will be cold.

Drinking from a cup has several advantages:

• Drinking from a cup solves the problem of always having to go to the faucet because the cup can hold more water at once.
• Drinking water from a cup is less likely to spill, and it is not easy to waste water.
• Drinking from a cup is more elegant than lying under the faucet.

We regard the cup as a buffer pool, and the water in the cup as a cache. We accept the problem that the water in the cup will become cold, which is equivalent to sacrificing the real-time performance of the data. To describe these advantages in another way, the advantages of using cache become the following:

• Reduced system pressure;
• save resource consumption;
• Optimize user experience.

3. The role of HTTP caching

One of the characteristics of the network is instability, and many users are plagued by slow network speeds.

It is easy for the server to calculate data in real time in the scenario of a large number of users, resulting in slow service. From the advantages of caching technology, it is very suitable for solving the problem of unstable network services.

4. HTTP Cache Protocol

An agreement is a rule that both parties abide by and use in the communication process. For example, how many times have the two big brothers, the client and the server, communicated about the new model?

Client: Brother, is the new nex released yet?

Server: Brother, it hasn't been posted yet, remember, don't keep asking me!

A week later...

Client: Brother, I'm here again, what's the latest situation?

Server: Same as last time.

A month later...

Client: Brother, it's been a month, how is it? !

Server: It's on sale!

In this example, some rules are followed in the process of communication between the client and the server. Let's take a look.

• data part : the content of the model;
• Protocol part : 1) Don't keep asking me, 2) What's the latest situation, 3) Same as last time.

The client can understand the words spoken by the server and understand the meaning contained in these words. This is a certain communication protocol between the client and the server.

4.1 HTTP message headers

Before introducing the HTTP caching protocol, let's first understand the basics of HTTP message headers. We are familiar with HTTP/HTTPS data requests. There is a kind of information in HTTP data requests called " header information ".

The header information is a kind of information that is passed to the other party in the client request or the server response. Let's look at the components of the HTTP protocol.

of HTTP request

It consists of three parts: status line, request header, and message body.

of HTTP Response

Status line, response headers, response body.

Among them, the request header and the response header are what we call " header information " or " message header ". So what does the header information do?

4.2 Request headers

as the picture shows:

4.3 Response headers

as the picture shows:

The caching protocol we are going to talk about today, Cache-Control, is also controlled in the message header.

4.4 Cache Protocol

In the first section, we introduced three advantages of using cache technology, which also have these three advantages in the process of network data exchange.

1) Reduce system pressure

Using HTTP caching technology can effectively reduce the pressure on the server, and the server does not need to calculate and return data in real time.

2) Save resource consumption

Using HTTP caching technology can effectively avoid a large number of repeated data transmission and reduce traffic consumption.

3) Optimize user experience

Using HTTP caching technology, the local cache can be loaded at a faster speed, reducing user waiting time.

Before talking about how the HTTP protocol implements caching, let's talk about the types of caching. HTTP caches are generally divided into two categories, private caches and shared caches.

4.4.1 Private Cache

The cache is stored locally on the device or under an independent account system, and is only used by the current user. It can be used to reduce server pressure, improve user experience, and even achieve offline browsing.

4.4.2 Shared Cache

The shared cache is the data that is cached twice in the proxy server or other intermediate servers. Generally, the common one here is the CDN. This cache can be accessed by multiple users to reduce traffic and delay.

For a network data interaction, the local cache and the shared cache can exist at the same time, and the HTTP protocol specifies how to control the use and update of these caches. In HTTP, there are two fields to control the cache: one is Pragma; the other is cache-control.

Pragma is a field defined in HTTP/1.0, query from mozilla official website documentation, Pragma supports almost all existing browsers.

But as a product of the old era, cache-control is gradually replacing it. cache-control is a protocol introduced since HTTP/1.1. Some front-end developers will choose to add Pragma on the basis of cache-control for backward compatibility. In fact, android webview supports both Pragma and cache-control.

When Pragma and cache-control appear at the same time, the priority of Pragma is higher than that of cache-control. Of course, this is not the focus of today. Interested students can check the relevant information by themselves.

Let's talk about the specific definition of the cache-control cache protocol in detail. The HTTP protocol stipulates that the server notifies the client of the caching method through the cache-control in the response header, and the client can also notify the server of its own caching requirements through the cache-control in the request header.

4.4.3 cache-control in response headers

The cache-control in the response header generally has the following values:

• Cache-control: public
• Cache-control: private
• Cache-control: no-cache
• Cache-control: no-store
• Cache-control: no-transform
• Cache-control: must-revalidate
• Cache-control: proxy-revalidate
• Cache-Control: max-age=
• Cache-control: s-maxage=

4.4.4 cache-control in the request header

The cache-control in the request header generally has the following values:

• Cache-Control: max-age=
• Cache-Control: max-stale[=]
• Cache-Control: min-fresh=
• Cache-control: no-cache
• Cache-control: no-store
• Cache-control: no-transform
• Cache-control: only-if-cached

The mozilla developer website divides these values into the following categories to describe them.

4.4.5 Cacheability Control

public

Indicates that the response can be cached by any object (including: the client sending the request, proxy servers, etc.), even content that is not normally cacheable. (For example: 1. The response has no max-age directive or Expires header; 2. The request method corresponding to the response is POST.)

private

Indicates that the response can only be cached by a single user, not as a shared cache (i.e. the proxy server cannot cache it). The private cache can cache the response content, for example, corresponding to the user's local browser.

no-cache

Before publishing the cached copy, force the cache to submit the request to the origin server for validation (negotiate cache validation).

no-store

The cache should not store anything about client requests or server responses, i.e. no cache is used.

4.4.6 Cache Validity Control

max-age=

Sets the maximum period of cache storage, beyond which the cache is considered expired (in seconds). In contrast to Expires, the time is relative to the request.

s-maxage=

Overrides the max-age or Expires header, but only for shared caches (like individual proxies), private caches ignore it.

max-stale[=]

Indicates that the client is willing to receive an expired resource. An optional number of seconds can be set indicating that the response cannot be outdated beyond this given time.

min-fresh=

Indicates that the client wishes to get a response that will keep its state up-to-date for the specified number of seconds.

stale-while-revalidate=

Indicates that the client is willing to accept stale responses while asynchronously checking for new responses in the background. The seconds value indicates how long the client is willing to accept stale responses.

stale-if-error= 

Indicates that the client is willing to accept a stale response if the new check fails. The seconds value indicates how long the client is willing to accept a stale response after the initial expiration.

4.4.7 Revalidation and Reload

must-revalidate

Once a resource has expired (i.e. has exceeded max-age), the cache cannot respond to subsequent requests with that resource until it has successfully authenticated to the origin server.

proxy-revalidate

Same as must-revalidate, but it only applies to shared caches (such as proxies) and is ignored by private caches.

4.4.8 Other controls

no-transform

Resources must not be transformed or transformed. HTTP headers such as Content-Encoding, Content-Range, and Content-Type cannot be modified by the proxy. For example, a non-transparent proxy or something like Google's Light Mode might convert image formats to save cache space or reduce traffic on slow links. The no-transform directive does not allow this.

only-if-cached

Indicates that the client only accepts cached responses and does not check with the origin server for a newer copy.

From these descriptions and classifications, it can be seen that control + cache validity control + other control , these control dimensions are not conflicting, and can jointly implement cache implementation limitations.

In fact, cache-control can indeed accept multiple values at the same time, and multiple different instructions can be used together to control the cache. If contradicting multiple instruction values are used, the instructions are cache-controlled by priority.

For example, no-store and max-age are two contradictory instruction values sent together, so the terminal will only cache according to no-store.

4.4.9 Practical analysis of protocol work

Professional operation and maintenance personnel must understand the meaning of these descriptions. However, as a client or front-end, it may be difficult for us to understand the actual caching effect under different configuration values just by looking at these professional terms.

Therefore, in order to understand the impact of the value on the actual cache effect. I used two computers to build a static resource server (origin server) and a proxy server, respectively, to verify several common cache control modes by simulating the scenario of an online server. The installation of nginx is relatively simple and will not be described here.

Static Resource Server (Origin Server)

windows+nginx, are configured as follows:

Proxy server

windows+nginx, the configuration is as follows:

After the server is built, we change the value of cache-control one by one to simulate several common cache control modes to help you understand these values and deepen your impression. In the daily use process, cache-control is more often placed in the response header to control the caching behavior of browsing, so let's first verify that cache-control is placed in the response header.

Scenario : No cache-control flag is added to the response header of the static resource server (origin server). No logo is added, in fact, it corresponds to the public logo.

public can usually be regarded as the default value. If we do not add any headers related to Cache-control in the response, then the default processing logic of this response is similar to Cache-control: public.

(The uncertain words "usually" and "similar" are used here. It needs to be explained. If the server returns a redirection response such as 302 or 307, adding Cache-control: public will make the browser put the redirection response as well. It is cached, but if Cache-control is not added, it will not be cached, and there is also the possibility of different network frameworks or browsers doing different processing).

Public means that the browser or proxy server can cache the resources returned by the static resource server (origin server). Use a browser to access the static resource server directly (without going through a proxy server).

First visit to

On the first visit, the server returned a 200 status and passed the static html back to the client. At the same time, the server also brings two fields, ETag and Last-Modified. Let's continue to look down. At this point the client does several things:

• The content of static resources is cached;
• The ETag and Last-Modified of the content are recorded.

Click the browser refresh button

After clicking the refresh button of the browser, the client browser requests the server again with the ETag and Last-Modified returned in the first request. Through these two parameters, the server considers that the client has cached the resource, and the server does not need to return the resource again. So the server returned 304.

So what kind of scenario would it be if a proxy server was involved? Remember the proxy server we configured earlier, we set the proxy cache time for the proxy service to 10 seconds.

first visit to

Click the browser refresh button

When the browser's refresh button is clicked, the client browser requests the server again with the ETag and Last-Modified returned in the first request. The server considers that the client has cached the resource through these two parameters, and the server does not need to return the resource again, so the server returns 304.

Note that during this refresh, the HIT mark in the status of ngiux-cache-status hits the cache of the proxy server this time, and this time the client cache validity judgment is completed by the proxy server.

Third refresh after 10 seconds

As mentioned earlier, the cache validity period of the proxy server is set to 10 seconds. At the third refresh, the server still returned 304, and the resource does not need to be updated.

However, during this refresh, the status of ngiux-cache-status is EXPIRED, which indicates that the cache of the proxy server has expired and cannot be used for validity judgment. At this time, the proxy server will transparently transmit this request to static The resource server (origin server) determines the validity of the cache completed by the static resource server (origin server).

In this process, the proxy server will update its own cache again, so there is the following fourth time.

Fourth refresh

The logic diagram is as follows;

Through these four requests, we can clearly understand the entire logic, and the proxy server directly replaces the static resource server (origin server) in some cases. Because the public directive tells the proxy server that the data can be cached, the proxy server caches the data for 10 seconds according to the configuration. After more than 10 seconds, it will re-forward the request to the static resource server (origin server) and re-cache it.

At this time, some students will ask, the proxy server has a time limit for caching, and will not re-request the static resource server (origin server) until the time limit is reached. At this time, the static resource server (source server) is reduced. pressure. So why in the above example, the browser has been requesting the proxy server?

Here I want to explain to you that in the above case, we have been clicking the refresh button of the browser. The refresh button means that the client browser re-requests the server to verify the validity of the cached content.

Take a closer look at the Request-Headers in all the screenshots. Is there a max-age = 0, This command is the browser to tell the server when refreshing the request - my local cache may expire, you need to help I'll verify. If you try to copy the URL to a new browser window and hit enter to open the url instead of hitting the refresh button, it will look like the image below.

The browser will not access the network. Pay attention to the remarks in the brackets in the Status Code. Status Code: 200 OK (from disk cache) indicates that the response data this time is actually taken from the disk cache.

In the WebView of the android system, there is no refresh button under normal circumstances (unless the developer writes one), then in this scenario, the webview will not request the network, and will take data from the disk cache every time, corresponding to the packet capture. , you will not see network requests.

After understanding the entire logic, let's look at the description provided by mozilla, and then combine the above logic to see if we already have a preliminary concept.

4.4.10 Cacheability control in response headers

public

Indicates that the response can be cached by any object (including: the client sending the request, proxy servers, etc.), even content that is not normally cacheable. (For example: 1. The response has no max-age directive or Expires header; 2. The request method corresponding to the response is POST.) This is actually the scenario we just verified.

private

Indicates that the response can only be cached by a single user, not as a shared cache (i.e. the proxy server cannot cache it). The private cache can cache the response content, for example, corresponding to the user's local browser.

If private is used, it means that the resource can be cached by private users, and the cache will not be shared. In actual testing, when marked as private, the browser can cache, but the proxy server will not cache the resource. Some materials mentioned that private can specify the cached user_id, which is a relatively complex configuration, and interested students can study it.

no-cache

Force the cache to submit the request to the origin server for validation (negotiate cache validation).

This is a command that is often used by the server, and it is also a command that is easily confused with no-store. Many front-end and client-side students think that when no-cache is marked in the response of the server, the client will not cache it. Each time the server is requested to fetch new content. Actually it's only half right.

In this scenario, the browser will indeed request the server every time, but it does not mean that the browser does not cache resources. Mozilla's official explanation is "submit the request to the origin server for verification." If there is no problem with the cache, then the server will A 304 will be returned, allowing the browser to continue using its own local cache".

no-store

Nothing about client requests or server responses should be stored, i.e. no caching should be used.

This instruction is to not use the local cache at all. In this mode, the client will not record any cache, including Etag, etc., and will re-initiate the request every time, and get a 200 response and corresponding data. If the front end wants your web pages to be completely uncached, you can try this directive.

The above instructions solve the problem of whether the client and the proxy server can be cached. Some students will have doubts. If the client is allowed to cache locally, then under normal circumstances, if the client does not manually refresh, the client will not request the server. , After the front-end releases a new version, how does the client choose the right time to request the server?

At this time, cache validity control is used. The cache verification between the browser and the server is mutual, that is to say, the server can tell the browser how long you can use the cache and how long it can be kept.

Let's first look at how the server informs the client how long the cache can be used. The cache validity control instruction is generally issued to the client together with the cacheability instruction.

We increase the max-age attribute in the header of the server. At the same time, in order to prevent the proxy server from invalidating the proxy cache in advance, we set the cache validity time of the proxy server to 100 seconds, which exceeds the set by the static resource server (origin server). max-age = 20.

first request

We refreshed the browser with the refresh function, and within 20 seconds we continued to get the HIT status, indicating that the cache of the proxy server was hit. After 20 seconds, the proxy server returns EXPIRED, indicating that the proxy server responded to the instruction of the static resource server (origin server), making the local proxy invalid, and the 100-second local cache time set by the proxy server was ignored at this time.

This time, we still use the browser's refresh function to force the browser to go to the server to verify the validity of the cache. That is to say, in the above test, the browser ignores the max-age by itself every time and accesses the server. .

Conclusion : The newly added max-age controls the cache duration retained by the proxy server. The local proxy ignores the cache duration in the configuration and directly uses the max-age issued by the static resource server (origin server) as the cache duration.

Next, in order to test how the browser uses the local cache, we use the webview on android to experiment, because the webview does not have a refresh button (unless the developer makes one).

open for the first time;

After opening, we will open it again every two seconds;

It can be seen that within 20 seconds, the webview did not repeatedly request the server to download the index.html of the site. In the above screenshot, every time a favicon.ico is displayed, I open the site link once, because I have not configured favicon.ico in the source server. , so every time it is opened, webview is looking for the server to download this resource.

After more than 20 seconds, the webview initiates a request, this time the server returns 304, requiring the client to continue to use the cache for display, this time the max-age directive is reflected. After this verification, the webview will extend the validity period of the local cache for another 20 seconds. After the next 20 seconds, the webview will initiate a new cache verification request again.

Summary : The client webview will cache index.html under the public directive, and will not initiate any network requests to verify resources within the time limit required by max-age.

In one case of the official website mall, after the website went online, the operation and maintenance did not configure any cache-control protocol. In the default public mode, the client webview always used the local cache. The developer found that after the front-end version was released, the client could not be updated in time. page. Therefore, a timestamp is manually spliced after each open URL to force the URL to be changed and invalidate the browser's cache. In fact, this problem can be solved by using nocache or max-age as the cache-control protocol.

In addition to max-age, cache-control can add the following controls on the basis of the cacheability control instruction;

no-transform

The origin server tells the client that the client cannot make changes to the file when caching data, such as compression, format modification, etc...

must-revalidate

The origin server informs the client that once the resource expires, the resource must not be used until authentication is initiated to the static resource server (origin server).

proxy-revalidate

Same as must-revalidate, only for shared caches (eg proxies).

max-age=

The static resource server (origin server) informs the client that within X seconds, the client does not need to verify the cache and can use it directly.

s-maxage=

The static resource server (origin server) informs the proxy server that the proxy server can use the cache within X seconds, and it can be used directly without verification, but the client will ignore this instruction.

The question comes again. During the verification process, how does the server determine whether the browser's cache is valid?

When the client browser has the opportunity to access the server, it will tell the server when my local cache is the last-modified data (Last-Modified) and what the data content is (ETag), so that the server can use these two values. Determines whether the client's cache is valid.

Let's simulate a front-end publishing operation, modify the content of index.html; then use android webview to make a request.

This time the server returned 200 and data without hesitation. Everyone carefully observe the request header and response header;

• The if-None-Match in the request header is actually the retained ETag returned by the server last time;
• The if-Modified-Match in the request header is actually the Last-Modified returned by the server last time;

Now these two values do not correspond to those on the server, so the server returns the latest data and 200 status code, and brings the latest Etag, Last-Modified. The next time the client requests, it will bring the latest Etag and Last-Modified.

In some cases, the verification field returned by the server will be incomplete, such as missing one of Etag and Last-Modified, then the cache verification in this case will be at risk.

In one case on the PC official website, the origin site server returned the Etag and Last-Modified of the static resources, but the proxy server, that is, the CDN manufacturer, cleared the Etag when returning, resulting in the lack of Etag verification. Under normal circumstances, the server only uses the last modification time of the file for cache verification and there is no problem. But there is such a user, the static resources cached in his browser are damaged, the resources read by the browser cannot be used each time, and the page cannot be rendered normally, but every time the server checks the resources with the server, the server The client will still be told 304 (cache available). In this scenario, as long as the source site server does not update the resource, that is, does not change the Last-Modified, the user will never be able to open the file.

After talking about this, you already know a little about the downstream and interactive parts of the entire cache protocol. The rest is the upstream part of the cache protocol. The so-called upstream part is to write cache-control on the request header accessed by the browser.

We also mentioned earlier that the browser's refresh request actually adds a cache-control: max-age = 0 to the request header. This actually tells the server that the client wants to receive a cache that exists for no more than 0 seconds. General origin servers, especially static resource servers, will return 200 or 304 according to the client's cache status.

4.4.11 Cacheability control in request headers

no-cache

Tell the proxy server not to use the cache directly and request to make a request to the origin server.

no-store

All files are not cached in local or temporary folders.

max-age

Tell the server that the client wishes to receive a resource that is not older than X seconds.

max-statle

Tell the server that the client is willing to accept a resource that exceeds the cache time for X seconds.

min-fresh

Tell the server that the client wishes to receive a resource that has been updated in less than X seconds.

no-transform

Tell the proxy server not to allow the proxy server to compress and convert resources. For example, some proxy servers will compress and format images.

only-if-cached

Tell the proxy server that if the proxy server has cached content, give it directly, without having to ask the origin server for it.

Because the cache control in the request header is used less, I will not interpret it too much. Interested students can study it.

V. Summary

The cache-control protocol of HTTP specifies the cache interaction logic between the client, the proxy server, and the origin server. As a client-side development, there are often some cache-related problems that cannot be solved when troubleshooting. Learning and understanding this part of the content can help you quickly analyze and locate this part of the problem.

After the front-end students are familiar with the logic of cache-control, they can also discuss their own caching requirements with operation and maintenance according to the business form, which can effectively reduce the pressure on the server and user traffic, and improve the speed of opening web pages.

Author: vivo Internet Client Team - Chen Long