Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Example Analysis of caching Mechanism in browser

2025-01-19 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/01 Report--

This article mainly introduces the example analysis of the caching mechanism in the browser, which has a certain reference value. Interested friends can refer to it. I hope you will learn a lot after reading this article.

What is the caching mechanism of the browser?

Understanding browser caching

When the browser requests a website, it will load a variety of resources, for some infrequent resources, the browser will save them in local memory, the next time to directly load these resources to improve access speed.

How do you know if a resource is a requested server or a read cache?

Looking at the figure above, some resources have size values, some are from disk cache, some are from memory cache, the size is the requested server resource, and the latter two are read caches.

Disk cache: it stores resources on disk and reads them directly from disk without downloading them when waiting for the next visit. Its direct operation object is CurlCacheManager. (slower than memory cache, but with large storage capacity and long storage time)

Memory cache: cache the resource in memory and read it directly from memory without downloading it again when you wait for the next access. It is the fastest in terms of efficiency and the shortest in terms of survival time. )

-memory cachedisk cache similarities can only store some derived class resource files, only some derived class resource files can be stored. When the data exits the process at different points, the data will be cleared. When the data exits the process, the data will not be erased. Generally, scripts, fonts and pictures will be stored in memory, such as css and so on.

Browser cache classification

Strong cache

Negotiation cache

When the browser requests resources from the server, it first determines whether it hits the strong cache, and then determines whether it hits the negotiation cache.

Strong cache

When loading a resource, the browser will first determine whether to hit the strong cache according to the header of the local cache resource. If it does, it will directly use the resource in the cache and will not send a request to the server. (the information in header here refers to expires and cache-control.)

Expires

This field is the http1.0 specification, and its value is an absolute time GMT formatted time string, such as Expires:Mon,18 Oct 2066 23:59:59 GMT. This time represents the expiration time of the resource, before which the cache is hit. This approach has an obvious disadvantage, because the expiration time is an absolute time, so when the time deviation between the server and the client is large, it will lead to cache confusion. So this approach was quickly abandoned in later versions of HTTP1.1.

Cache-Control

Cache-Control is the header information that appears when http1.1, which is mainly judged by the max-age value of this field. It is a relative time, such as Cache-Control:max-age=3600, which represents that the validity period of the resource is 3600 seconds. In addition to this field, cache-control has the following common setting values:

No-cache: you need to negotiate caching and send a request to the server to confirm whether to use caching.

No-store: the use of caching is prohibited and data is re-requested each time.

Public: can be cached by all users, including end users and intermediate proxy servers such as CDN.

Private: it can only be cached by the end user's browser, and relay cache servers such as CDN are not allowed to cache it.

Cache-Control and Expires can be enabled on the server side at the same time, and Cache-Control has a high priority when enabled at the same time.

Negotiation cache

When the strong cache fails, the browser sends a request to the server, which determines whether or not to hit the negotiation cache based on the information in the header. If hit, 304 is returned, telling the browser that the resource has not been updated and that the local cache can be used. (the header information here refers to Last-Modify/If-Modify-Since and ETag/If-None-Match.)

Last-Modify/If-Modify-Since

When the browser requests a resource for the first time, the header returned by the server will add Last-Modify,Last-modify as a time to identify the last modification time of the resource.

When the browser requests the resource again, the request header of the request contains If-Modify-Since, which is the Last-Modify returned before caching. After receiving the If-Modify-Since, the server determines whether the cache is hit according to the last modification time of the resource.

If the cache is hit, it returns 304, and no resource content is returned, and no Last-Modify is returned.

Disadvantages:

Resources have changed in a short period of time, and Last-Modified will not change.

Periodic changes. If the resource is modified back to its original form within a cycle, we think it is possible to use caching, but Last-Modified does not think so, so there is ETag.

ETag/If-None-Match

Unlike Last-Modify/If-Modify-Since, Etag/If-None-Match returns a check code. ETag can guarantee that each resource is unique, and changes in resources will lead to changes in ETag. The server determines whether to hit the cache based on the If-None-Match value sent on the browser.

Unlike Last-Modified, when the server returns a response of 304 Not Modified, because the ETag has been regenerated, the ETag will also be returned in response header, even if the ETag is the same as before.

Last-Modified and ETag can be used together, and the server will first verify the ETag. If it is consistent, it will continue to compare the Last-Modified, and finally decide whether to return it or not.

Summary

When a browser accesses a resource that has already been visited, its steps are:

1. Let's first see if it hits the strong cache, hit? Use the cache directly if the

two。 If you fail to hit the strong cache, a request will be sent to the server to see if it is hit. Negotiation cache

3. If the negotiation cache is hit, the server returns 304 and tells the browser that the local cache can be used.

4. If the negotiation cache is missed, the server will return the new resource to the browser

Thank you for reading this article carefully. I hope the article "sample Analysis of caching Mechanism in browsers" shared by the editor will be helpful to everyone. At the same time, I also hope that you will support and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report