Web caching is the caching of web documents (e.g., HTML pages, images) in order to reduce bandwidth usage, server load, and perceived lag. A web cache stores copies of documents passing through it; subsequent requests may be satisfied from the cache if certain conditions are met.
Types of Web caches
Web caches can be deployed in a variety of ways. User agent caches, such as those in web browsers, are private caches, operating on behalf of a single user. Intermediaries can also implement shared caches that serve more than one person.
Proxy caches, also known as forward proxy caches, are usually deployed by internet service providers, schools and corporations to save bandwidth. Interception proxy caches (sometimes called "transparent caches") are a variant that doesn't require clients to be explicitly configured to use them.
Gateway caches, sometimes known as reverse proxy caches, surrogate caches, or web accelerators, operate on behalf of the origin server, and to clients are indistinguishable from it. A number of gateway caches can work together to implement a Content Delivery Network.
Intermediaries that cache often perform other duties, such as user authentication and content filtering. Multiple caches can also be coordinated using peering protocols like Internet Cache Protocol and HTCP.
Controlling Web caches
HTTP defines three basic mechanisms for controlling caches: freshness, validation and invalidation.
* Freshness allows a response to be used without re-checking it on the origin server, and can be controlled by both the server and the client. For example, the Expires response header gives a date when the document becomes stale, and the Cache-Control: max-age directive tells the cache how many seconds the response is fresh for.
* Validation can be used to check whether a cached response is still good after it becomes stale. For example, if the response has a Last-Modified header, a cache can make a conditional request using the If-Modified-Since header to see if it has changed.
* Invalidation is usually a side effect of another request that passes through the cache. For example, if URL associated with a cached response subsequently gets a POST, PUT or DELETE request, the cached response will be invalidated.
Types of Web caches
Web caches can be deployed in a variety of ways. User agent caches, such as those in web browsers, are private caches, operating on behalf of a single user. Intermediaries can also implement shared caches that serve more than one person.
Proxy caches, also known as forward proxy caches, are usually deployed by internet service providers, schools and corporations to save bandwidth. Interception proxy caches (sometimes called "transparent caches") are a variant that doesn't require clients to be explicitly configured to use them.
Gateway caches, sometimes known as reverse proxy caches, surrogate caches, or web accelerators, operate on behalf of the origin server, and to clients are indistinguishable from it. A number of gateway caches can work together to implement a Content Delivery Network.
Intermediaries that cache often perform other duties, such as user authentication and content filtering. Multiple caches can also be coordinated using peering protocols like Internet Cache Protocol and HTCP.
Controlling Web caches
HTTP defines three basic mechanisms for controlling caches: freshness, validation and invalidation.
* Freshness allows a response to be used without re-checking it on the origin server, and can be controlled by both the server and the client. For example, the Expires response header gives a date when the document becomes stale, and the Cache-Control: max-age directive tells the cache how many seconds the response is fresh for.
* Validation can be used to check whether a cached response is still good after it becomes stale. For example, if the response has a Last-Modified header, a cache can make a conditional request using the If-Modified-Since header to see if it has changed.
* Invalidation is usually a side effect of another request that passes through the cache. For example, if URL associated with a cached response subsequently gets a POST, PUT or DELETE request, the cached response will be invalidated.
0 comments:
Post a Comment