HTTP Cache Protocol Practice

1. What is Cache?

Cache, also known as Cache, is a place where data is temporarily stored called a cache pool, and the data in the cache pool is called cache. When users need to use this data, they first search in the cache. If they find it, they use it directly. If they can't find it, they search in other data sources.

2. Why use caching technology?

The essence of caching is to trade space for time, using temporarily stored data to temporarily replace the latest data read from the data source. The benefits of this approach are different in different scenarios.

For example:

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

There are some existing problems with drinking water from a cup, for example, the water in the cup gets cold easily, while the water from the tap is at a constant temperature. We can imagine colleagues in the company queuing up to drink water from the tap, which is indeed a bit funny. We would rather accept the existing problem that the water in the cup gets cold.

Drinking from a cup has several advantages:

Drinking water from a cup solves the problem of always having to find the faucet, because the cup can hold more water at a time.
Drinking water from a cup is less likely to spill and waste water.
Drinking from a cup is more elegant than drinking from the tap.

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

Reduced system pressure;
Saves resource consumption;
Optimize user experience.

3. The role of HTTP cache

One of the characteristics of the Internet is instability, and many users are troubled by slow Internet speeds.

When a server calculates data in real time under the scenario of a large number of users accessing, it is easy to cause bottlenecks, resulting in slow services. From the advantages of caching technology, it is very suitable for solving the problem of unstable network services.

4. HTTP Cache Protocol

A protocol is a set of rules that both parties follow and use during the communication process. For example, how many times did the client and the server communicate about the new model?

Client: Bro, has the new NEX been released?
Server: Hey bro, it hasn’t been sent 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.

One month later...

Client: Bro, it’s been a month, how is it going? !
Server: Now on sale!

In this example, the client and server follow certain rules when communicating. Let's take a look:

Data part: content of the model;
Agreement: 1) Don’t keep asking me, 2) What’s the latest situation, 3) Same as last time.

The client can understand what the server says and know the meaning of it. This is a communication protocol reached between the client and the server.

4.1 HTTP Message Header

Before introducing the HTTP cache protocol, let's first understand the basics of HTTP message headers. We are all familiar with HTTP/HTTPS data requests, and there is a type of information in HTTP data requests called "header information."

The header information is a kind of information that is transmitted to the other party when the client requests or the server responds. Let's take a look at the components of the HTTP protocol.

HTTP request consists of three parts: status line, request header, and message body.
The components of an HTTP response: status line, response header, and response body.

Among them, the request header and response header are what we call "header information" or "message header". So what is the role of header information?

4.2 Request Header

As shown in the figure:

4.3 Response Header

As shown in the figure:

The cache protocol we are going to talk about today - Cache-Control, is also placed in the message header for control.

4.4 Cache Protocol

In the first section, we introduced the three advantages of using caching technology. In the process of network data exchange, using caching technology also has these three advantages.

(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 large amounts of repeated data transmission and reduce traffic consumption.

(3) Optimize user experience

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

Before we talk about how HTTP protocol implements caching, let's first talk about cache types. HTTP cache is generally divided into two categories, private cache and shared cache.

4.4.1 Private Cache

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

4.4.2 Shared Cache

Shared cache is data that is cached twice in a proxy server or other intermediate server. Generally, CDN is the most common one here. This cache can be accessed by multiple users to reduce traffic and latency.

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

Pragma is a field defined in HTTP/1.0. According to the Mozilla official website document, Pragma supports almost all existing browsers.

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

When Pragma and cache-control appear at the same time, Pragma has a higher priority than cache-control. Of course, this is not the focus today. Students who are interested can check the relevant information by themselves.

The following is a detailed definition of the cache-control protocol. The HTTP protocol stipulates that the server notifies the client of the cache mode through the cache-control in the response header, and the client can also notify the server of its own cache 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 describes these values in the following categories.

4.4.5 Cacheability Control

(1) public

Indicates that the response can be cached by anyone (including the requesting client, proxy servers, etc.), even if the content is not normally cacheable. For example:

The response has no max-age directive or Expires header;
The request method corresponding to this response is POST.

(2) private

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

(3) no-cache

Forces the cache to submit requests to the origin server for validation before publishing the cached copy (negotiated cache validation).

(4) 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

(1) max-age=

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

(2) s-maxage=

Overrides the max-age or Expires header, but only applies to shared caches (such as proxies); private caches will ignore it.

(3) max-stale[=]

Indicates that the client is willing to accept a resource that has expired. An optional number of seconds can be set, indicating that the response must not be out of date for more than the given time.

(4) min-fresh=

Indicates that the client wishes to obtain a response that is up to date for the specified number of seconds.

(5) stale-while-revalidate=

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

(6) stale-if-error=

Indicates that the client is willing to accept a stale response if a 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

(1) must-revalidate

Once a resource has expired (for example, max-age has expired), the cache cannot respond to subsequent requests for that resource until it successfully authenticates with the origin server.

(2) proxy-revalidate

Does the 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

(1) no-transform

Resources must not be transformed or converted. HTTP headers such as Content-Encoding, Content-Range, Content-Type, etc. must not be modified by proxies. For example, non-transparent proxies or services such as Google's Light Mode may transform image formats in order to save cache space or reduce traffic on slow links. The no-transform directive disallows this.

(2) only-if-cached

Instructs the client to accept only cached responses and not to check with the origin server for a newer copy.

From these descriptions and classifications, we can see that cacheability control + cache validity control + other controls are not conflicting control dimensions and can jointly implement the cache implementation method limitation.

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

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

4.4.9 Practical analysis of protocol work

Professional operation and maintenance personnel must be very familiar with the meaning of these descriptions. However, as clients or front-end developers, it may be difficult for us to understand the actual cache effects 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 (source server) and a proxy server, and verified several common cache control modes by simulating the online server scenario. The installation of nginx is relatively simple, so I won't go into details here.

(1) Static resource server (source server)

Windows+nginx, the configuration is as follows:

(2) Proxy Server

Windows+nginx, the configuration is as follows:

After the server is built, we change the values of cache-control one by one to simulate several common cache control modes to help everyone understand these values and deepen their impression. In daily use, cache-control is more often placed in the response header to control the browsing cache behavior, so let's first verify the situation where 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 flag is added, which actually corresponds to the public flag.

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

(The use of uncertain words such as "usually" and "similar" here needs to be explained. If the server returns a redirect response such as 302 or 307, adding Cache-control: public will allow the browser to cache the redirect response as well. However, if Cache-control is not added, it will not be cached. There is also the possibility that different network frameworks or browsers may handle it differently).

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

(3) First visit

In the first visit, the server returns a 200 status and passes the static HTML back to the client. At the same time, the server also adds the ETag and Last-Modified fields. Let's continue to look at them. At this time, the client does several things:

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

(4) Click the browser refresh button

After clicking the refresh button on the browser, the client browser requests the server again with the ETag and Last-Modified returned in the first request. The server believes 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.

What will happen if a proxy server gets involved? Remember the proxy server we configured earlier? We set the proxy cache time of the proxy service to 10 seconds.

(5) First visit

(6) Click the browser refresh button

When you click the refresh button on the browser, the client browser requests the server again with the ETag and Last-Modified returned in the first request. The server believes 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 status of ngiux-cache-status is HIT, indicating that the proxy server's cache was hit this time. This time, the client cache validity judgment was completed by the proxy server.

(7) The third refresh after 10 seconds

As mentioned above, the proxy server cache validity period is configured to 10 seconds. When refreshing for the third time, the server still returns 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 proxy server's cache has expired and cannot be used for validity judgment. At this time, the proxy server will pass the request to the static resource server (source server) and complete the cache validity judgment through the static resource server (source server).

During this process, the proxy server will update its cache again, resulting in the fourth update below.

(8) Fourth refresh

The logic diagram is as follows:

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

At this time, some students may ask, the proxy server has a cache time limit, and will not re-request the static resource server (source server) before the time limit is reached, which reduces the pressure on the static resource server (source server). Then why in the above example, the browser keeps requesting the proxy server?

I would like to explain here that in the above case, we have actually 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.

Look carefully at the Request-Header in all the screenshots. Is there a max-age = 0? This instruction is the browser telling the server when refreshing the request - my local cache may have expired, you need to help me verify it. If you try to copy the URL into a new window of the browser and press Enter to open the URL instead of clicking the refresh button, it will be like the following picture.

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

In the WebView of the Android system, there is normally no refresh button (unless the developer writes one himself). In this scenario, the webview will not request the network, and will get data from the disk cache every time. Correspondingly, when capturing packets, no network requests will be seen.

After understanding the whole logic, let's look at the description provided by Mozilla, and then combine it with the above logic, do you already have a preliminary concept?

4.4.10 Cacheability Control in Response Headers

(1) public

Indicates that the response can be cached by anyone (including the requesting client, proxy servers, etc.), even if the content is not normally cacheable. For example:

The response has no max-age directive or Expires header;
The request method corresponding to this response is POST.

This is actually the scenario we just verified.

(2) private

If private is used, it means that this resource can be cached by private users, and the cache will not be shared. In actual testing, when it is marked as private, the browser can cache it, but the proxy server will not cache this resource. Some materials mention that private can specify the cache user_id. This is a more complicated configuration. Interested students can study it.

(3) no-cache

Forces the cache to submit requests to the origin server for validation (negotiated cache validation).

This is a command 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 believe that when the server's response is marked with no-cache, the client will not cache and will request the server to obtain new content every time. In fact, this is 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 original server for verification." If there is no problem with the cache, the server will return 304, allowing the browser to continue using its local cache.

(4) no-store

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

This command means that the local cache is not used at all. In this mode, the client will not record any cache, including Etag, etc. It will re-initiate the request each time and get a 200 response and the corresponding data. If the front-end does not want its web page to be cached at all, you can try this command.

The above instructions solve the problem of whether the client and proxy server can cache. Some students may have questions. If the client is allowed to cache locally, then under normal circumstances, if it is not refreshed manually, 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?

This is where cache validity control comes in. The cache validation between the browser and the server is mutual, which means the server can tell the browser how long you can use the cache and how long you can keep it.

First, let's look at how the server notifies the client about how long the cache can be used. Cache validity control instructions are usually sent to the client together with cacheability instructions.

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

First request:

We use the refresh function to refresh the browser. Within 20 seconds, we continue to get the HIT status, indicating that the proxy server's cache is hit. After 20 seconds, the proxy server returns EXPIRED, indicating that the proxy server responded to the instructions 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 used 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 ignored max-age every time and accessed the server.

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

To test how the browser uses the local cache, we use the webview on Android to conduct the experiment, because the webview does not have a refresh button (unless the developer creates one himself).

First time opening:

After opening, we open it again every two seconds:

It can be seen that within 20 seconds, webview did not repeatedly request the server to download the index.html of the site. In the screenshot above, each favicon.ico displayed means that I opened the site link once. Because I did not configure favicon.ico in the source server, every time I opened it, webview was looking for the server to download this resource.

After more than 20 seconds, the webview initiated a request, and this time the server returned 304, requiring the client to continue to use the cache for display. This time the max-age instruction was 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 a case of an 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 update the page in time. So a timestamp was manually spliced after each opened URL to force the URL to change and invalidate the browser 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 also add the following controls based on the cacheability control instructions:

(1) no-transform

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

(2) must-revalidate

The origin server informs the client that once a resource expires, it cannot be used before initiating verification with the static resource server (origin server).

(3) proxy-revalidate

Same effect as must-revalidate, but only applies to shared caches (such as proxies).

(4) max-age=

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

(5) s-maxage=

The static resource server (source server) tells the proxy server that the proxy server can use the cache within X seconds and does not need to be verified. It can be used directly, but the client will ignore this instruction.

The question arises 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 the data in my local cache was (Last-Modified) and what the data content was (ETag). In this way, the server can determine whether the client's cache is valid based on these two values.

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

This time the server generously returns 200 and data. Look carefully at the request and response headers;

The if-None-Match in the request header actually keeps the ETag returned by the server last time;

The if-Modified-Match in the request header actually keeps the Last-Modified returned by the server last time;

Now these two values do not correspond to the server, so the server returns the latest data and a 200 status code, along with the latest Etag and 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, in which case the cache verification will be risky.

In a case on the PC official website, the source site server returned the Etag and Last-Modified of the static resource, but the proxy server, that is, the CDN manufacturer, cleared the Etag when returning it, resulting in the lack of Etag verification. Under normal circumstances, there is no problem if the server only uses the last modification time of the file for cache verification. However, there is a user whose static resources cached in his browser are damaged. The resources read out by the browser each time cannot be used, and the page cannot be rendered normally. However, every time the resource is verified with the server, the server will still inform the client 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.

Having said all this, you have already had a rough idea of the downstream and interactive parts of the entire cache protocol. The remaining part is the upstream part of the cache protocol, which is to write cache-control on the request header accessed by the browser.

As we mentioned earlier, the browser's refresh request actually adds a cache-control: max-age = 0 in the request header. This actually tells the server that the client wants to receive a cache that exists no longer than 0 seconds. The general source server, especially the static resource server, will return 200 or 304 at this time according to the client's cache status.

4.4.11 Cacheability Control in Request Headers

(1) no-cache

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

(2) no-store

All files are not cached locally or in temporary folders.

(3) max-age

Tells the server that the client wishes to receive a resource that is no older than X seconds.

(4) max-statle

Tells the server that the client is willing to accept a resource that has been cached for a period of X seconds.

(5) min-fresh

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

(6) no-transform

Inform the proxy server that it is not allowed to compress or convert resources. For example, some proxy servers may compress or convert images.

(7) only-if-cached

Tell the proxy server that if the proxy server has cached content, it should be given directly without having to ask the source server for it again.

Since the cache control in the request header is rarely used, I will not interpret it in detail. Students who are interested can study it.

V. Conclusion

HTTP's cache-control protocol specifies the cache interaction logic between the client, proxy server, and source server. As a client developer, you often encounter cache-related problems that you don't know where to start when troubleshooting. By learning about this part, you can quickly analyze and locate these problems.

After front-end students are familiar with the logic of cache-control, they can also discuss their own cache requirements with operations and maintenance based on the business model, effectively reducing server pressure and user traffic, and increasing the speed of opening web pages.

<<: Edge computing and 5G: What’s next for enterprise IT?

>>: What is the impact of major players withdrawing from the LoRaWAN network on China?