HTTP Negotiation cache vs Strong Cache

have been to the browser cache can only describe a general, deep-seated principle can not be described up; finally in the front of the two interview process was asked to fall, in order to spite, look at some of the information finally has a more in-depth understanding, nonsense said, hurriedly to see the browser cache of those things, there is wrong place, Please enlighten me.

This article mainly explains the browser side of the cache, the role of caching is self-evident, can greatly improve the performance of the Web page, improve the user experience.

1. Browser Cache

Cache this thing, the first time you must obtain a resource, and then according to the information returned to tell how to cache the resources, may be in a strong cache, may also tell the client browser is negotiated cache, which need to be based on the response header content to determine. Here are two pictures to describe how the browser's cache is playing, so that everyone has a general understanding.

The first time the browser requests:

The browser is subsequently requested:

As you can see, the browser cache contains two types, the strong cache (also called the local cache) and the Negotiate cache, which the browser requests once the first request occurs:

• When a browser requests a resource, it first gets the header information of the resource cache, determines whether to hit the strong cache (Cache-control and expires information), and if the hit directly obtains the resource information from the cache, including the cache header information This request does not communicate with the server at all; under Firebug, you can view information returned by a strong cache resource, such as a strongly cached JS file that is viewed locally firebug
  
  
  
  
• If a strong cache is not hit, the browser sends a request to the server, and the request carries the header field information (Last-modified/if-modified-since and Etag/if-none-match) about the cache returned on the first request. By the server based on the relevant header information in the request compared to whether the results are negotiated cache hit, if hit, the server returns a new response header information updates the corresponding header information in the cache, but does not return the resource content, it tells the browser can be directly from the cache to get Otherwise, the latest resource content is returned

The difference between a strong cache and a negotiated cache can be described using the following table:

	Get Resource Form	Status code	Send request to Server
Strong cache	Fetching from cache	(from Cache)	No, take directly from the cache
Negotiate cache	Fetching from cache	304 (not modified)	Yes, as its name tells you whether the cache is available through the server

2. Strong cache related header fields

The strong cache has been described above to get resources directly from the cache without the server; There are two header fields related to strong cache:

2. expires , This is the specification of http1.0 when the value is a time string in GMT format of an absolute time, such as If the time to send the request is before the expires, then the local cache is always valid, otherwise a request is sent to the server to get the resource
   
   

Note: If Cache-control and expires are present at the same time, the Cache-control priority is higher than expires

3. Negotiate cache related header fields

The negotiation cache is determined by the server to determine whether the cache resources are available, so the client and server side to communicate through some kind of identity, so that the server to determine whether the request resources can cache access, which mainly involves the following two sets of header fields, the two groups of partners are paired up, That is, a field (last-modified or etag) on the response header of the first request, the subsequent request takes on the corresponding request field (If-modified-since or If-none-match), if the response header does not Last-modified or ETag fields, the request header does not have a corresponding field .

1. last-modified/if-modified-since
   Both values are time strings in GMT format, in the following procedure:
   
   • The first time the browser requests a resource with the server, the server returns this resource, In the header of Respone and the header of Last-modified, this header indicates the last modification time of this resource on the server
     
     
   • When the browser requests this resource again with the server, Add If-modified-since header to the header of request, the value of this header is the value of the last-modified returned at the last request
     
     
   • When the server receives the resource request again. According to the browser, if-modified-since and resources on the server last modified time to determine whether the resource changes, if there is no change will return 304 not Modified, but will not return the resource content, if there are changes, the normal return of the resource content. When the server returns a response of 304 not modified, the header of last-modified is no longer added to the response header, since the resource does not change, then last-modified will not change. This is when the server returns 304 when the response header
     
     
   • Browser receives a 304 response, the resource is loaded from the cache
     
     
   • If the negotiation cache is not hit, the browser loads the resource directly from the server. Last-modified's header is updated at reload time, If-modified-since will enable the last returned Last-modified value on the next request
     
     
3. Etag/if-none-match
   These two values are a unique identifying string for each resource generated by the server, which changes as long as the resource changes; its judgment process is similar to last-modified/if-modified-since , unlike Last-modified, When the server returns a response of 304 not modified, the ETag is returned to the response header, even if the etag has not changed since the ETag was regenerated.
   
   

4. Both raw last-modified Mr He etag
You might think that using　　 last-modified is enough to let the browser know if the local cache copy is new enough, why do you need the ETag? The appearance of the ETag in HTTP1.1 is mainly to solve several last-modified problems that are more difficult to solve:

• Some files may change periodically, but his content does not change (just change the modified time), this time we do not want the client to think that the file has been modified, and re-get;

• Some files are modified very frequently, such as in the time of the second to modify, for example, 1s modified n times, if-modified-since can check the granularity is S-class, this modification can not be judged (or UNIX record mtime can only be accurate to the second);

• Some servers cannot accurately get the last modified time of the file.

At this point, the etag can be used to control the cache more accurately, because the ETag is the unique identifier of the server that the server generates automatically or the corresponding resource generated by the developer.

last-modified and ETag can be used together, the server will first verify the ETag , consistent with the case, will continue to compare against last-modified, and finally decide whether to return 304 .

5. The effect of user behavior on caching

Misappropriation of a map on the web, the basic ability to describe the impact of user behavior on the cache

Source: http://www.cnblogs.com/wonyun/p/5524617.html

HTTP Negotiation Cache vs Strong Cache