Web cache principle, you really build it? __ Computer Network

One, Web Cache

When introducing Web cache, we need to briefly introduce the understanding of caching 1.1 cache interpretation

Caching is usually cached based on key-value pairs, and the key can be interpreted as an index when it is stored in memory somewhere after the hash is computed. The value is stored in memory space or disk space.

When a user's request is sent to a Web server, the Web server hashes the URL and then the key in the cache (hash table). If hit, then according to the corresponding value to find the location of the data (the value can be interpreted as a pointer, pointing to the location of the corresponding data), so as to obtain the results of the cache.

1.2 Working principle

1.2.1 Cache Hits

① client requests a Web data, it is sent to the cache server, the cache server itself listens to port 80th to receive user requests

② when a Web cache server receives a user request, the request is delivered to the agent process

The ③ process removes the application layer header, TCP header, IP header, etc. from the user request message to obtain the URL in the request message

④ a hash of the URL and then match the cache key in the hash table on the cache server, and cache hits if consistent

⑤ find the corresponding content data on the memory or hard disk space that the corresponding value points to

⑥ is constructed into a response message and returned directly to the client

1.2.2 Cache Misses

① client requests a Web data, it is sent to the cache server, the cache server itself listens to port 80th to receive user requests

② when a Web cache server receives a user request, the request is delivered to the agent process

The ③ process removes the application layer header, TCP header, IP header, etc. from the user request message to obtain the URL in the request message

④ a hash of the URL and then match the cache key in the hash table on the cache server, and the cache misses

⑤ Proxy Server will be packaged into the request message itself, as an HTTP client, to the upstream server to initiate a request

⑥ If content exists, the upstream server will be built into response messages and returned to the proxy server.

⑦ when the proxy server receives a response, it checks that the object can be cached and, if so, creates a key after the URL is hashed, which is stored in the corresponding hash table

⑧ store the corresponding content data on the appropriate memory or disk space

⑨ when the operation is complete, the data is constructed into the corresponding message and then responded to the client 1.3 extension

In the user's own internal browser will have their own cache (private cache), when the user requests a home page, will request to the proxy server, then cached in local links or pictures, if there is a cache locally, then directly respond to the user, and no longer need to request to the proxy server. So our cache is there are multiple levels of two, cache invalidation

Now there is a problem, that is, if our cache fails, it's normal. If the cache expires, we should no longer use this cache. So the cache is a TTL (life-time value) value, and when this TTL value expires, we can use this cache object normally, once expired, the requesting party can only go to a higher level of the next layer of cache in the backend server to request resources.

Suppose a cache object can be cached for 7 days, but on the 2nd day, the back-end server has modified the object, so what should be done at this point. So the data that users get directly from the cache is not up to date. This may result in the user being unable to obtain valid results until the cache expiration date expires. So what if it's handled. 2.1 Ways to cache

Based on absolute time caching
In HTTP 1.0, the use of absolute time to cache, you can understand the precise time algorithm

Based on conditional caching

After the 1.1 release, its caching function has been extended to introduce several functions

1. Introducing relative time-long expiration time
2, the introduction of a powerful cache object control functions (which data can be cached and can not be cached)
3, the introduction of conditional caching 2.2 Based on absolute time

For example, the cache for the Chinese time Zone of July 3, 2016 9:00 cache, the cache TTL value is 7 days, then the expiration date should be 7 days after 9:00 (July 10, 2016) expired, but if it is in the United States, or Europe, because of the different time zones, Using absolute time will result in a cache cache of 2.3 based on conditional caching

Query verification request based on last cache time

When a user accesses the same URL, he finds that there is an identical cache object in their cache space, and he does not immediately use the cache, but instead goes to the upstream server to verify that the cache has expired. Initiate a validation request to the server, request a URL, and send a unique request header (If-modified-sinces:time) asking if you have changed after this time (that is, after the time the cache object was established). If the back-end server discovers that this resource has not been modified, it responds to 304 (the original data was not modified), and because the resource has not changed, the response code is sent here only, and the data is not sent. When the client receives a response, the local cache is used directly.

If the back-end server discovers that the resource has been modified, it finds the corresponding resource, sends a response code of 200 (the original data has been modified), and sends the resource to the client. When the client receives it, it replaces the previously cached results and displays them on the browser.
However, based on the time to record the decision is not ideal, assuming that when the user is authenticated, and your server time is not at that time, then you will not be able to verify the cache time.

Conditional request based on tag (tag)

On the server side, each file, or resource, comes with a tag each time the version is modified (this tag may be a randomly generated number, so it can be understood to be unique). When the user requests resources, will send a unique request header (If-none-match:tag), will be the local cache of the tag sent to the server side, asked if the resource tag matching, matching the resources unchanged, Response 304 response code, or resources have changed, Response 200 response code.

So you don't worry about the problems that arise when you base your time record. three, HTTP caching mode of work 3.1 based on cache expiration Time

1. When a user accesses a resource for the first time, the cache server does not have a corresponding cache object, then the cache server requests data from the back-end server, and the backend server responds to the cached server with Cache-control header information, indicating the time of the cache. The caching server then caches the data locally and then responds to the client with the data.

2. When the client requests the same resource again, if the cache time does not expire, then the cache server directly responds directly to the client for the resource requested by the user.

3. If a client requests a resource and discovers that the cache cycle has expired in the cache server, then the cache server requests resources backwards, caches the information resources locally, and then updates the cached TTL value and responds to the client.

3.2 Based on conditional caching

1. When a client requests a resource for the first time, the cache server initiates a resource request from the back-end server because the cached server does not have a response cache resource. When the backend server receives the request, it responds to the request of the cached server, with Last-modified:time header information, and the caching server caches the resources and last-modified information locally, and then responds to the client together with the information.

2, the client initiates the resource request, if the cache server has the corresponding resource cache entry, but at this time the client does not use directly, but sends the IF-MODIFIED-SINCE:TIME request first to the backend server, asks whether the data has not been modified. If the data is not modified and returns a 304 response code, then the client will use the resources in the cache server directly.

3, similar to the above method, but if the back-end server responds to 200 (data has been modified) response code, then the cache server will accept this response information, and the data cached locally, and then the resource + last-modified response information sent back to the client.

3.3 Combination Application HTTP header

According to the above introduction, we know that if based on time to judge, may result in inaccurate data. The use of conditional caching can compensate for the lack of time, but it has one drawback, that is, the need to constantly ask back-end server data. This consumes the resources and bandwidth of the back-end server. So we can use a combination based on two methods to complete the cache failure judgment.

1, the first user access, then similar to the previous approach, the difference is, at this time the cache server will record ETag information and cache-control information.

2. If the same resource is requested by the client, if the cache does not expire, then the resource on the cached server is still used at this time.

3, when the cache server's resources have expired, then the client will be the back-end server to initiate the If-none-match:etag request header, the back-end server to confirm that the resource has been modified, if the resource has not been modified, at this time the server will respond to 304 (resource unmodified) response code, The cache server then updates the TTL value and responds to the client.