HTTP caching Technology

Source: Internet
Author: User

1. Introduction to Caching

The cache is the intermediate unit located in the server and client, which is mainly based on the request sent by the user agent, requests the relevant content to the server, and saves the content copy, such as HTML page, picture, text file or streaming media file. Then, when the next request for the same URL arrives, the cache uses the copy directly to respond to the HTTP request without having to send the request to the source server again.

1.1 Benefits of caching
    1. Reduce response latency. The cache server is closer to the user, and if the service is available directly, the response latency will be greatly reduced, making the user feel more responsive to the WEB server.
    2. Reduce network bandwidth consumption. When the cache directly uses replicas for user services, the bandwidth consumption of the communication link between the cache and the source server is greatly reduced, and the cache that provides the service is closer to the user, saving more network resources, especially for the highly congested carrier backbone.
    3. Reduce the load on the source server. A large number of requests that the user originally needs to access the source server are directly serviced within the cache, and the response times of the source server are reduced.
2. Basic working principles of caching
    • If the header information of the response message tells the cache not to keep the copy, the cache does not cache the content.
    • If the request information requires the source server authentication or involves a security protocol, the corresponding request content is not cached.
    • If the contents of the cache contain the following information, the content will be considered new enough, so there is no need to retrieve the content from the source server.
      1. Contains expiration and lifetime information, and the content is still not expired at this time.
      2. Cached content has recently been used to provide services, and the last time the content has been updated is longer than the most recently used.
    • If the cached content has expired, the cache server will issue a validation request (via the ETAG header or last-modified header information) to the source server to determine whether the service can continue to be served directly using the current content.
    • In some cases (such as when the source server is disconnected from the network), the cached content can also be served directly in the event of an expiration.
    • If there is no validation value (ETag header information or last-modified header information) to determine whether the content changes in the response message, and there is no other significant freshness information, the content is usually not cached.
3. Method 1 for controlling HTTP caching. HTML META tags and HTTP header information

The author of the HTML file <HEAD> adds various properties that describe the document in the area of the document, which are often used to mark how long a document cannot be cached or marked for expiration. META tags are very simple to use, but inefficient because there are only a few browsers that can read this tag, and since the intermediate caches almost completely do not parse the HTML content in the document, there is no intermediate cache (proxy cache and gateway cache) to read this rule. If you want to control the page from being cached by meta tags, you will typically add the <HEAD> meta tag "Pragma:no-cache" to the area of the Web page.

2. Use Expires (expiry time) header information to control the freshness period

Typically, the HTTP header information is used primarily to indicate whether the cache and control content are cached. These control information is invisible in the HTML code and is typically generated automatically by the WEB server and identified in the HTTP message. The header information for a typical HTTP 1.1 protocol response message looks like this:

HTTP/1.1 200 OKData: Mon, 18 Jul 2011 22:14:49 GMTServer: ApacheCache-Control: max-age=3600, must-revalidateExpires: Mon, 18 Jul 2011 23:14:49 GMTLast-Modified: Sun, 5 Jun 2011 16:38:21 GMTETag: "5e36-767-576df70c"Content-Length: 1040(空行)HTML 代码

The code contains the Expires header, which indicates the Mon, 18 Jul 2011 23:14:49 GMT expiration time. The Expires method is the basic means of HTTP control caching, which tells the cache how long the content is fresh. After this time, if the client requests this content to the cache, the cache sends a request to the source server to check if the document has changed. Most Web server settings are Expires in many ways, and the most common ones are set to an absolute time value, such as when the last modified point of the content is added to a specific time period (for example, one hours).

3. Verification

The concept of caching is presented in HTTP 1.1, and the purpose of validation is to verify that the cached content is available. When there is an expired cache content in the intermediate cache, and the corresponding access request arrives, the cache should first request authentication to the source server or other cache servers that have not expired to determine if the local cache content is available. This process is the validation process for a cached message.

HTTP 1.1 The way to determine whether to return the message content after this verification is called "conditional" request return method, so as to avoid getting the entire content from the source server or other cache server message, thereby reducing network traffic. When the source server generates a complete response message, it comes with a validation message that the intermediate cache can hold when the content is cached, and when the cached content expires, the intermediate cache can use it to generate a "conditional" request to request validation from the source server. Other cache servers on the source server or on the path that the source server communicates with (if there are unsaved content) can compare the validation information contained in the request to their own local authentication information after receiving such a request. If the two authentication information is equal, then a response message with a specific status code (such as 304 not Modified, which indicates that the content has not been modified) and empty message body content is returned, in which case the network traffic is reduced, and if two authentication information is not equal, a complete response message containing the new content needs to be transmitted.

4. Cache-control (cache control) HTTP header information

Specifying the expiration time and validation is the basic caching mechanism for HTTP 1.1, and is also an implicit instruction for caching. However, in some cases, the server or client may need to present instructions to the HTTP cache for display. As a result, HTTP 1.1 uses Cache-control response header information to enable publishers of the site to control their content more securely and limit the expiration time.

Useful Cache-control response header information includes the following:

    • Max-age: The maximum amount of time that cached content remains fresh. This property is similar to the expiration time, which is based on the relative time interval of the request time, not the absolute expiration time, in seconds, that is, the number of seconds from the start of the request to the expiration time.
    • S-maxage: Similar to the Max-age property, it is applied to the shared cache.
    • Public: This property tags the authentication content can also be cached, in general, the HTTP authentication to access the content is not cached by default.
    • No-cache: Forces each access request to be sent directly to the source server without passing the intermediate cache for the previously mentioned validation. This is useful for applications that require user authentication on the source server, and for applications that are strict with the latest data.
    • No-store: Do not cache any content under any circumstances.
    • Must-revalidate: Tells the cache to follow the content freshness given by the source server. Because HTTP allows caching to return stale data in certain situations, by specifying this property, the source server can tell the cache that if the cached content is out of date, the source server must be re-authenticated before responding to the access request.
    • Proxy-revalidate:proxy-revalidate and Must-revalidate are basically the same, except that it cannot be applied to a non-shared proxy cache. It allows to save those authenticated response messages in the client cache (which contains "public" to ensure that they can be cached), and before the cached content expires, the same access request can return the cached data without being authenticated by the source server. If the content expires, it still needs to be re-verified by the server. For proxy caches that serve multiple users, to ensure that each user is authorized, the server must be authenticated every time (such authorization responses also need to use public directives to allow them to be cached).
5. Pragma HTTP Header information

HTTP also has a caching control mechanism for using Pragma HTTP header information. Pragma is a generic header that contains specific execution instructions that can be applied to any recipient in the client, proxy, gateway, source server, but the HTTP protocol considers the behavior specified by the PRAGMA Directive Optional.

When "Pragma:no-cache" appears in the request message, the request is forwarded directly to the source server, even if the content required for the request response is cached in the cache device. Although the method of controlling caching via Pragma is mentioned in HTTP 1.1, this is primarily intended to be compatible with HTTP 1.0, because caching that supports HTTP 1.0 is primarily a way to control content caching. In HTTP 1.1, the cache is primarily controlled by Cache-control header information, so the protocol requires that when an HTTP 1.1 request is sent from the client, it should contain both the Pragma instruction and the Cache-control control instruction, so that the request is from the client In the process of sending to the source server, both HTTP 1.1 and HTTP 1.0-enabled cache devices can read instruction information. If the client sending the instruction only supports HTTP 1.0, the intermediate cache that supports HTTP 1.1 must control the cache with instructions in Pragma after it receives the request message.

Note: The Pragme property in the HTTP specification does not have any description of the response Information Header Pragma property, it only appears in the request header information, that is, the header information is sent to the server by the browser, but only a few cache servers actually follow this header information in the request message. Therefore, in many cases, using the Pragma property does not necessarily work.

HTTP caching Technology

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.