trafficserver-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From iga...@apache.org
Subject svn commit: r1070302 [3/4] - in /trafficserver/site/branches/ats-cms/content/docs/trunk: ./ admin/ admin/configuration-files/ admin/configuring-cache/ admin/configuring-traffic-server/ admin/event-logging-formats/ admin/explicit-proxy-caching/ admin/fa...
Date Sun, 13 Feb 2011 21:38:38 GMT
Added: trafficserver/site/branches/ats-cms/content/docs/trunk/admin/http-proxy-caching/index.en.mdtext
URL: http://svn.apache.org/viewvc/trafficserver/site/branches/ats-cms/content/docs/trunk/admin/http-proxy-caching/index.en.mdtext?rev=1070302&view=auto
==============================================================================
--- trafficserver/site/branches/ats-cms/content/docs/trunk/admin/http-proxy-caching/index.en.mdtext (added)
+++ trafficserver/site/branches/ats-cms/content/docs/trunk/admin/http-proxy-caching/index.en.mdtext Sun Feb 13 21:38:37 2011
@@ -0,0 +1,906 @@
+Notice:    Licensed to the Apache Software Foundation (ASF) under one
+           or more contributor license agreements.  See the NOTICE file
+           distributed with this work for additional information
+           regarding copyright ownership.  The ASF licenses this file
+           to you under the Apache License, Version 2.0 (the
+           "License"); you may not use this file except in compliance
+           with the License.  You may obtain a copy of the License at
+           .
+             http://www.apache.org/licenses/LICENSE-2.0
+           .
+           Unless required by applicable law or agreed to in writing,
+           software distributed under the License is distributed on an
+           "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+           KIND, either express or implied.  See the License for the
+           specific language governing permissions and limitations
+           under the License.
+
+
+   
+
+    
+      
+    
+
+ [![](/images/ts75.png)](/index.html)™
+      
+
+# Administrator's Guide # {#AdministratorsGuide}
+
+    
+
+   
+
+   
+
+      
+
+         
+
+            
+
+# HTTP Proxy Caching  # {#HTTPProxyCaching}
+
+Web proxy caching enables you to store copies of frequently-accessed web objects 
+(such as documents, images, and articles) and then serve this information to 
+users on demand. It improves performance and frees up Internet bandwidth for 
+other tasks. 
+
+This chapter discusses the following topics: 
+
+* [Understanding HTTP Web Proxy Caching](#UnderstandingHTTPWebProxyCaching)
+* [Ensuring Cached Object Freshness](#EnsuringCachedObjectFreshness)
+* [Scheduling Updates to Local Cache Content](#SchedulingUpdatesToLocalCacheContent)
+* [Pushing Content into the Cache](#PushingContentIntoCache)
+* [Pinning Content in the Cache](#PinningContentInCache)
+* [To Cache or Not to Cache?](#ToCacheOrNotToCache)
+* [Forcing Object Caching](#ForcingObjectCaching)
+* [Caching HTTP Alternates](#CachingHTTPAlternates)
+* [Using Congestion Control](#UsingCongestionControl)
+
+## Understanding HTTP Web Proxy Caching ## {#UnderstandingHTTPWebProxyCaching}
+
+Internet users direct their requests to web servers all over the Internet. 
+A caching server must act as a **web proxy server **so it can serve those requests. 
+After a web proxy server receives requests for web objects, it either serves 
+the requests or forwards them to the **origin server** (the web server that 
+contains the original copy of the requested information). The Traffic Server 
+proxy supports **explicit proxy caching**, in which the user’s client software 
+must be configured to send requests directly to the Traffic Server proxy. The 
+following overview illustrates how Traffic Server serves a user request.
+
+**Step 1** Traffic Server receives a user request for a web object. 
+
+**Step 2** Using the object address, Traffic Server tries to locate the requested 
+object in its object database (**cache**). 
+
+**Step 3** If the object is in the cache, then Traffic Server checks to see 
+if the object is fresh enough to serve. If it is fresh, then Traffic Server 
+serves it to the user as a **cache hit** (see the figure below).
+
+![](images/cache_hit.jpg)
+
+> 
+>   
+> 
+> _**A cache hit**_ 
+> 
+
+**Step 4** If the data in the cache is stale, then Traffic Server connects 
+to the origin server and checks if the object is still fresh (a **revalidation**). 
+If it is, then Traffic Server immediately sends the cached copy to the user. 
+ 
+
+**Step 5** If the object is not in the cache (a **cache miss**) or if the server 
+indicates the cached copy is no longer valid, then Traffic Server obtains the 
+object from the origin server. The object is then simultaneously streamed to 
+the user and the Traffic Server local cache (see the figure below). Subsequent 
+requests for the object can be served faster because the object is retrieved 
+directly from cache.
+
+![](images/cache_miss.jpg)
+
+> 
+>   
+> 
+> _**A cache miss**_ 
+> 
+
+Caching is typically more complex than the preceding overview suggests. In 
+particular, the overview does not discuss how Traffic Server ensures freshness, 
+serves correct HTTP alternates, and treats requests for objects that cannot/should 
+not be cached. The following sections discuss these issues in greater detail. 
+ 
+
+## Ensuring Cached Object Freshness ## {#EnsuringCachedObjectFreshness}
+
+When Traffic Server receives a request for a web object, it first tries to 
+locate the requested object in its cache. If the object is in cache, then Traffic 
+Server checks to see if the object is fresh enough to serve. For HTTP objects, 
+Traffic Server supports optional author-specified expiration dates. Traffic 
+Server adheres to these expiration dates; otherwise, it picks an expiration 
+date based on how frequently the object is changing and on administrator-chosen 
+freshness guidelines. Objects can also be revalidated by checking with the 
+origin server to see if an object is still fresh. 
+
+## HTTP Object Freshness ## {#HTTPObjectFreshness}
+
+Traffic Server determines whether an HTTP object in the cache is fresh by: 
+
+* **Checking the `Expires` or **`**max**`**`-age` header**  
+ Some HTTP objects contain `Expires` headers or `max-age` headers that explicitly define how long the object can be cached. Traffic Server compares the current time with the expiration time to determine if the object is still fresh.
+* **Checking the `Last-Modified / Date` header**  
+ If an HTTP object has no `Expires` header or `max-age` header, then Traffic Server can calculate a freshness limit using the following formula:   
+`freshness_limit =(_date - last_modified_) * 0.10`   
+ where` _date_` is the date in the object’s server response header and `_last_modified _` is the date in the `Last-Modified` header. If there is no `Last-Modified` header, then Traffic Server uses the date the object was written to cache. The value `0.10` (10 percent) can be increased or reduced to better suit your needs (refer to [Modifying the Aging Factor for Freshness Computations](#ModifyingAgingFactorFreshnessComputations)).  
+ The computed freshness limit is bound by a minimum and maximum value - refer to [Setting an Absolute Freshness Limit](#SettingAbsoluteFreshnessLimit) for more information.
+* **Checking the absolute freshness limit **  
+ For HTTP objects that do not have `Expires` headers or do not have both `Last-Modified` and `Date` headers, Traffic Server uses a maximum and minimum freshness limit (efer to [Setting an Absolute Freshness Limit](#SettingAbsoluteFreshnessLimit)).
+* **Checking revalidate rules in the `cache.config` file**  
+ Revalidate rules apply freshness limits to specific HTTP objects. You can set freshness limits for objects originating from particular domains or IP addresses, objects with URLs that contain specified regular expressions, objects requested by particular clients, and so on (refer to [cache.config](files.htm#cache.config)).
+
+### Modifying the Aging Factor for Freshness Computations ### {#ModifyingAgingFactorforFreshnessComputations}
+
+If an object does not contain any expiration information, then Traffic Server 
+can estimate its freshness from the `Last-Modified` and `Date` headers. By 
+default, Traffic Server stores an object for 10% of the time that elapsed since 
+it last changed. You can increase or reduce the percentage according to your 
+needs. 
+
+##### To modify the aging factor for freshness computations:  ##### {#modifyagingfactorforfreshnesscomputations}
+
+1. In a text editor, open the `records.config` file located in the Traffic Server `config` directory. 
+2. Edit the following variable:
+3. **Variable** **Description** 
+`_proxy.config.http.cache.heuristic_lm_factor_`
+:   
+		
+		Set this variable to specify the aging factor for freshness computations. Traffic Server stores an object for this percentage of the time that elapsed since it last changed.   
+		 The default value is 0.10 (10 percent).
+		
+		
+
+4. Save and close the `records.config` file.
+5. Navigate to the Traffic Server `bin` directory.   
+
+6. Run the `traffic_line -x` command to apply the configuration changes.
+
+### Setting an Absolute Freshness Limit ### {#SettinganAbsoluteFreshnessLimit}
+
+Some objects do not have `Expires` headers or do not have both `Last-Modified` 
+and `Date` headers. To control how long these objects are considered fresh 
+in the cache, specify an **absolute freshness limit**.
+
+##### To specify an absolute freshness limit:  ##### {#specifyanabsolutefreshnesslimit}
+
+1. In a text editor, open the `records.config` file located in the Traffic Server `config` directory. 
+2. Edit the following variables:
+3. **Variable** **Description** 
+_`proxy.config.http.cache.heuristic_min_lifetime`_
+:   Set this variable to specify the minimum amount of time that HTTP objects without 
+		an expiration date can remain fresh in the cache before being considered stale. 
+		The default value is 3600 seconds (1 hour).
+_`proxy.config.http.cache.heuristic_max_lifetime`_
+:   Set this variable to specify the maximum amount of time that HTTP objects without 
+		an expiration date can remain fresh in the cache before being considered stale. 
+		The default value is 86400 seconds (1 day).
+
+4. Save and close the `records.config` file.
+5. Navigate to the Traffic Server `bin` directory.   
+
+6. Run the command `traffic_line -x` to apply the configuration changes. 
+
+### Specifying Header Requirements ### {#SpecifyingHeaderRequirements}
+
+To further ensure freshness of the objects in the cache, configure Traffic 
+Server to cache only objects with specific headers. By default, Traffic Server 
+caches all objects (including objects with no headers); you should change the 
+default setting only for specialized proxy situations. If you configure Traffic 
+Server to cache only HTTP objects with `Expires` or `max-age` headers, then 
+the cache hit rate will be noticeably reduced (since very few objects will 
+have explicit expiration information).
+
+##### To configure Traffic Server to cache objects with specific headers:  ##### {#configureTScacheobjectswithspecificheaders}
+
+1. In a text editor, open the `records.config` file located in the Traffic Server `config` directory. 
+2. Edit the following variable:
+3. **Variable** **Description** 
+`_proxy.config.http.cache.required_headers_`
+:   
+		
+		Set this variable to one of the following values:  
+		   `0` = no headers required to make document cacheable  
+		   `1` = either the `Last-Modified` header, or an explicit lifetime header, ` Expires` or ` Cache-Control: max-age`, is required  
+		   `2` = explicit lifetime is required, ` Expires` or ` Cache-Control: max-age`
+		
+		
+
+4. Save and close the `records.config` file. 
+5. Navigate to the Traffic Server `bin` directory. 
+6. Run the command `traffic_line -x` to apply the configuration changes. 
+
+### Cache-Control Headers  ### {#Cache-ControlHeaders}
+
+Even though an object might be fresh in the cache, clients or servers often 
+impose their own constraints that preclude retrieval of the object from the 
+cache. For example, a client might request that a object _not_ be retrieved 
+from a cache, or if it does, then it cannot have been cached for more than 
+10 minutes. Traffic Server bases the servability of a cached object on `Cache-Control` 
+headers that appear in both client requests and server responses. The following 
+`Cache-Control` headers affect whether objects are served from cache: 
+
+  
+
+* The `no-cache` header, sent by clients, tells Traffic Server that it should not to serve any objects directly from the cache; therefore, Traffic Server will always obtain the object from the origin server. You can configure Traffic Server to ignore client `no-cache` headers - refer to [Configuring Traffic Server to Ignore Client no-cache Headers](#NoCacheHeaders) for more information.
+* The `max-age` header, sent by servers, is compared to the object age. If the age is less than `max-age`, then the object is fresh and can be served.
+* The `min-fresh` header, sent by clients, is an **acceptable freshness tolerance**. This means that the client wants the object to be at least this fresh. If a cached object does not remain fresh at least this long in the future, then it is revalidated. 
+* The `max-stale` header, sent by clients, permits Traffic Server to serve stale objects provided they are not too old. Some browsers might be willing to take slightly stale objects in exchange for improved performance, especially during periods of poor Internet availability. 
+
+Traffic Server applies `Cache-Control` servability criteria after HTTP freshness 
+criteria. For example, an object might be considered fresh but will not be 
+served if its age is greater than its `max-age`.
+
+  
+
+### Revalidating HTTP Objects  ### {#RevalidatingHTTPObjects}
+
+  
+
+When a client requests an HTTP object that is stale in the cache, Traffic Server 
+revalidates the object. A **revalidation** is a query to the origin server 
+to check if the object is unchanged. The result of a revalidation is one of 
+the following:
+
+  
+
+* If the object is still fresh, then Traffic Server resets its freshness limit and serves the object. 
+* If a new copy of the object is available, then Traffic Server caches the new object (thereby replacing the stale copy) and simultaneously serves the object to the user. 
+* If the object no longer exists on the origin server, then Traffic Server does not serve the cached copy. 
+* If the origin server does not respond to the revalidation query, then Traffic Server serves the stale object along with a `111 Revalidation Failed` warning. 
+
+By default, Traffic Server revalidates a requested HTTP object in the cache 
+if it considers the object to be stale. Traffic Server evaluates object freshness 
+as described in [HTTP Object Freshness](#HTTPObjectFreshness). You can reconfigure 
+how Traffic Server evaluates freshness by selecting one of the following options: 
+ 
+
+  
+
+* Traffic Server considers all HTTP objects in the cache to be stale: always revalidate HTTP objects in the cache with the origin server.
+* Traffic Server considers all HTTP objects in the cache to be fresh: never revalidate HTTP objects in the cache with the origin server. 
+* Traffic Server considers all HTTP objects without `Expires` or `Cache-control` headers to be stale: revalidate all HTTP objects without `Expires` or `Cache-Control` headers. 
+
+To configure how Traffic Server revalidates objects in the cache, you can set 
+specific revalidation rules in the `cache.config` file (refer to [cache.config](files.htm#cache.config)). 
+
+##### To configure revalidation options:  ##### {#configurerevalidationoptions}
+
+1. In a text editor, open the `records.config` file located in the Traffic Server `config` directory. 
+2. Edit the following variable: 
+3. **Variable** **Description** 
+`_proxy.config.http.cache.when_to_revalidate_`
+:   
+		
+		Set this variable to one of the following values:  
+		   0 = Configures Traffic Server to revalidate an HTTP object whenever it is considered stale in the cache. (Traffic Server checks the headers and the freshness limit, if applicable.) This is the default option.  
+		   1 = Configures Traffic Server to revalidate HTTP objects that do not contain `Expires` or `Cache-control` headers.  
+		   2 = Configures Traffic Server to always revalidate HTTP objects; Traffic Server always considers HTTP objects to be stale.  
+		   3 = Configures Traffic Server to never revalidate HTTP objects; Traffic Server always considers HTTP objects to be fresh.
+		
+				
+
+4. Save and close the` records.config `file. 
+5. Navigate to the Traffic Server `bin` directory.   
+
+6. Run the command `traffic_line -x` to apply the configuration changes.
+
+## Scheduling Updates to Local Cache Content ## {#SchedulingUpdatesLocalCacheContent}
+
+  
+
+To further increase performance and to ensure that HTTP objects are fresh in 
+the cache, you can use the **Scheduled Update** option. This configures Traffic 
+Server to load specific objects into the cache at scheduled times. You might 
+find this especially beneficial when using Traffic Server as a reverse proxy 
+so you can preload content you anticipate will be in demand. 
+
+To use the Scheduled Update option, you must perform the following tasks. 
+
+  
+
+* Specify the list of URLs that contain the objects you want to schedule for update, the time the update should take place, and the recursion depth for the URL.
+* Enable the scheduled update option and configure optional retry settings.
+
+Traffic Server uses the information you specify to determine URLs for which 
+it is responsible. For each URL, Traffic Server derives all recursive URLs 
+(if applicable) and then generates a unique URL list. Using this list, Traffic 
+Server initiates an HTTP `GET` for each unaccessed URL, ensuring that it remains 
+within the user-defined limits for HTTP concurrency at any given time. The 
+system logs the completion of all HTTP `GET` operations so you can monitor 
+the performance of this feature. 
+
+Traffic Server also provides a **Force Immediate Update** option that enables 
+you to update URLs immediately without waiting for the specified update time 
+to occur. You can use this option to test your scheduled update configuration 
+(refer to [Forcing an Immediate Update](#ForcingImmediateUpdate)). 
+
+### Configuring the Scheduled Update Option  ### {#ConfiguringScheduledUpdateOption}
+
+  
+
+##### To configure the scheduled update option, follow the steps below: ##### {#configurescheduledupdateoption,followstepsbelow}
+
+1. In a text editor, open the `update.config file` located in the Traffic Server `config` directory. 
+2. Enter a line in the file for each URL you want to update (refer to [update.config](files.htm#update.config)). 
+3. Save and close the `update.config` file.
+4. In a text editor, open the `records.config` file located in the Traffic Server `config` directory. 
+5. Edit the following variables:
+6. **Variable** **Description** 
+`_proxy.config.update.enabled_`
+:   Set this variable to 1 to enable the scheduled update option.
+`_proxy.config.update.retry_count_`
+:   Set this variable to specify the number of times you want to retry the scheduled 
+		update of a URL in the event of failure. The default value is 10.
+`_proxy.config.update.retry_interval_`
+:   Set this variable to specify the delay in seconds between each scheduled update 
+		retry for a URL in the event of failure. The default value is 2.
+`_proxy.config.update.concurrent_updates_`
+:   Set this variable to specify the maximum simultaneous update requests allowed 
+		at any point in time. This option prevents the scheduled update process from 
+		overburdening the host. The default value is 100.
+
+7. Save and close the `records.config` file.
+8. Navigate to the Traffic Server `bin` directory.   
+
+9. Run the command `traffic_line -x` to apply the configuration changes. 
+
+### Forcing an Immediate Update  ### {#ForcinganImmediateUpdate}
+
+  
+
+Traffic Server provides a **Force Immediate Update** option that enables you 
+to immediately verify the URLs listed in the `update.config` file. The Force 
+Immediate Update option disregards the offset hour and interval set in the 
+`update.config` file and immediately updates the URLs listed. 
+
+  
+
+ To configure the Force Immediate Update option, follow the steps below:
+
+1. In a text editor, open the `records.config` file located in the Traffic Server `config` directory. 
+2. Edit the following variable:
+3. **Variable** **Description** 
+`_proxy.config.update.force_`
+:   
+		
+		Set this variable to 1 to enable the Force Immediate Update option.
+		
+				  
+
+4. Make sure that the variable `_proxy.config.update.enabled_` is set to 1. 
+5. Save and close the `records.config` file. 
+6. Navigate to the Traffic Server `bin` directory.  
+
+7. Run the `command traffic_line -x` to apply the configuration changes. 
+
+**IMPORTANT: **When you enable the Force Immediate Update option, Traffic Server 
+continually updates the URLs specified in the `update.config` file until you 
+disable the option. To disable the Force Immediate Update option, set the variable 
+`_proxy.config.update.force_` to `0` (zero).
+
+  
+
+## Pushing Content into the Cache ## {#PushingContentintoCache}
+
+  
+
+Traffic Server supports the HTTP `PUSH` method of content delivery. Using HTTP 
+`PUSH`, you can deliver content directly into the cache without user requests. 
+ 
+
+  
+
+### Configuring Traffic Server to Accept PUSH Requests  ### {#ConfiguringTSAcceptPUSHRequests}
+
+  
+
+Before you can deliver content into your cache using HTTP `PUSH`, you must 
+configure Traffic Server to accept `PUSH` requests.
+
+##### To configure Traffic Server to accept `PUSH` requests:  ##### {#configureTSaccept`PUSH`requests}
+
+1. In a text editor, open the `filter.config` file located in the Traffic Server config directory. 
+2. Add the following filter rules to the file to ensure that only certain IP addresses can deliver `PUSH` requests to the cache:   
+`domain=. src_ip=_ipaddress_ method=PUSH action=allow   
+domain=. method=PUSH action=deny `   
+ where `_ipaddress_` is the IP address of the host or range of IP addresses of the hosts from which Traffic Server accepts PUSH requests. 
+3. Save and close the `filter.config` file. 
+4. In a text editor, open the `records.config` file located in the Traffic Server `config` directory. 
+5. Edit the following variable:
+6. **Variable** **Description** 
+`_proxy.config.http.push_method_enabled_`
+:   
+		
+		Set this variable to 1 to enable Traffic Server to accept PUSH requests.
+		
+				  
+
+7. Save and close the `records.config` file. 
+8. Navigate to the Traffic Server `bin` directory. 
+9. Run the command `traffic_line -x` to apply the configuration changes. 
+
+### Understanding HTTP PUSH ### {#UnderstandingHTTPPUSH}
+
+  
+
+`PUSH` uses the HTTP 1.1 message format. The body of a `PUSH` request contains 
+the response header and response body that you want to place in the cache. 
+The following is an example of a `PUSH` request: 
+
+  `PUSH http://www.company.com HTTP/1.0   
+Content-length: 84`
+
+`HTTP/1.0 200 OK   
+Content-type: text/html   
+Content-length: 17`
+
+`<HTML>   
+a   
+</HTML> `
+  
+
+**IMPORTANT: **Your header must include `Content-length`; `Content-length` 
+must include both `header` and `body byte count`.
+
+## Pinning Content in the Cache ## {#PinningContentinCache}
+
+  
+
+The **Cache Pinning Option** configures Traffic Server to keep certain HTTP 
+objects in the cache for a specified time. You can use this option to ensure 
+that the most popular objects are in cache when needed and to prevent Traffic 
+Server from deleting important objects. Traffic Server observes `Cache-Control` 
+headers and pins an object in the cache only if it is indeed cacheable.
+
+##### To set cache pinning rules and enable Cache Pinning:  ##### {#setcachepinningrulesenableCachePinning}
+
+1. In a text editor, open the `cache.config` file located in the Traffic Server `config` directory. 
+2. Add a rule in the file for each URL you want Traffic Server to pin in the cache, as shown below.   
+`url_regex=_URL_ pin-in-cache=12h `   
+ where `_URL_` is the URL you want Traffic Server to pin in the cache. The time format can be `d` for days, `h` for hours (as shown), `m` for minutes, and `s` for seconds. You can also use mixed units: for example, `1h15m20s`. You can add secondary specifiers (such as prefix and suffix) to the rule (refer to [cache.config](files.htm#cache.config) for more information). 
+3. Save and close the `cache.config` file. 
+4. In a text editor, open the `records.config` file located in the Traffic Server `config` directory. 
+5. Edit the following variable:
+6. **Variable** **Description** 
+`_proxy.config.cache.permit.pinning_`
+:   
+		
+		Set this variable to 1 to enable the cache pinning option.
+		
+				  
+
+7. Navigate to the Traffic Server `bin` directory.  
+
+8. Run the command `traffic_line -x` to apply the configuration changes. 
+
+## To Cache or Not to Cache? ## {#CacheNotCache?}
+
+  
+
+When Traffic Server receives a request for a web object that is not in the 
+cache, it retrieves the object from the origin server and serves it to the 
+client. At the same time, Traffic Server checks if the object is cacheable 
+before storing it in its cache to serve future requests. 
+
+## Caching HTTP Objects ## {#CachingHTTPObjects}
+
+  
+
+Traffic Server responds to caching directives from clients and origin servers, 
+as well as directives you specify through configuration options and files. 
+ 
+
+  
+
+### Client Directives  ### {#ClientDirectives}
+
+  
+
+By default, Traffic Server does _not_ cache objects with the following **request** 
+**headers**: 
+
+  
+
+* `Cache-Control: no-store` header 
+* `Cache-Control: no-cache` header   
+ To configure Traffic Server to ignore the `Cache-Control: no-cache` header, refer to [Configuring Traffic Server to Ignore Client no-cache Headers](#NoCacheHeaders). 
+* `Cookie`: header (for text objects)   
+ By default, Traffic Server caches objects served in response to requests that contain cookies (unless the object is text). You can configure Traffic Server to not cache cookied content of any type, cache all cookied content, or cache cookied content that is of image type only. For more information, refer to [Caching Cookied Objects](#CachingCookiedObjects).
+* `Authorization`: header 
+
+#### Configuring Traffic Server to Ignore Client no-cache Headers  #### {#ConfiguringTSIgnoreClientno-cacheHeaders}
+
+  
+
+By default, Traffic Server strictly observes client `Cache Control:no-cache` 
+directives. If a requested object contains a `no-cache` header, then Traffic 
+Server forwards the request to the origin server even if it has a fresh copy 
+in cache. You can configure Traffic Server to ignore client `no-cache` directives 
+such that it ignores `no-cache` headers from client requests and serves the 
+object from its cache. 
+
+##### To configure Traffic Server to ignore client `no-cache` headers:  ##### {#configureTSignoreclient`no-cache`headers}
+
+1. In a text editor, open the `records.config` file located in the Traffic Server `config` directory. 
+2. Edit the following variable:
+3. **Variable** **Description** 
+`_proxy.config.http.cache.ignore_client_no_cache_`
+:   
+		
+		Set this variable to 1 to ignore client requests to bypass the cache.
+		
+				  
+
+4. Save and close the `records.config` file. 
+5. Navigate to the Traffic Server `bin` directory.   
+
+6. Run the command `traffic_line -x` to apply the configuration changes. 
+
+### Origin Server Directives  ### {#OriginServerDirectives}
+
+  
+
+By default, Traffic Server does _not_ cache objects with the following **response** 
+**headers**: 
+
+  
+
+* `Cache-Control: no-store` header 
+* `Cache-Control: private` header 
+* `WWW-Authenticate`: header   
+ To configure Traffic Server to ignore` WWW-Authenticate` headers, refer to [Configuring Traffic Server to Ignore WWW-Authenticate Headers](#ConfiguringTrafficEdgeIgnoreWWWAuthenticateHeaders). 
+* `Set-Cookie`: header 
+* `Cache-Control: no-cache` headers   
+ To configure Traffic Server to ignore `no-cache` headers, refer to [Configuring Traffic Server to Ignore Server no-cache Headers](#ConfiguringTrafficEdgeIgnoreServerNoCacheHeaders). 
+* `Expires`: header with value of 0 (zero) or a past date 
+
+#### Configuring Traffic Server to Ignore Server **no-cache** Headers  #### {#ConfiguringTSIgnoreServer**no-cache**Headers}
+
+  
+
+By default, Traffic Server strictly observes `Cache-Control:no-cache` directives. 
+A response from an origin server with a `no-cache` header is not stored in 
+the cache and any previous copy of the object in the cache is removed. If you 
+configure Traffic Server to ignore `no-cache` headers, then Traffic Server 
+also ignores `no-store` headers. The default behavior of observing `no-cache` 
+directives is appropriate in most cases. 
+
+##### To configure Traffic Server to ignore server `no-cache` headers:  ##### {#configureTSignoreserver`no-cache`headers}
+
+1. In a text editor, open the `records.config` file located in the Traffic Server `config` directory. 
+2. Edit the following variable:
+3. **Variable** **Description** 
+`_proxy.config.http.cache.ignore_server_no_cache_`
+:   
+		
+		Set this variable to 1 to ignore server directives to bypass the cache.
+		
+				  
+
+4. Save and close the `records.config` file. 
+5. Navigate to the Traffic Server `bin` directory.   
+
+6. Run the command `traffic_line -x` to apply the configuration changes. 
+
+#### Configuring Traffic Server to Ignore WWW-Authenticate Headers  #### {#ConfiguringTSIgnoreWWW-AuthenticateHeaders}
+
+  
+
+By default, Traffic Server does not cache objects that contain `WWW-Authenticate` 
+response headers. The `WWW-Authenticate` header contains authentication parameters 
+the client uses when preparing the authentication challenge response to an 
+origin server. 
+
+  
+
+When you configure Traffic Server to ignore origin server `WWW-Authenticate` 
+headers, all objects with `WWW-Authenticate` headers are stored in the cache 
+for future requests. However, the default behavior of not caching objects with 
+`WWW-Authenticate` headers is appropriate in most cases. Only configure Traffic 
+Server to ignore server `WWW-Authenticate` headers if you are knowledgeable 
+about HTTP 1.1.
+
+  
+
+##### To configure Traffic Server to ignore server `WWW-Authenticate` headers:  ##### {#configureTSignoreserver`WWW-Authenticate`headers}
+
+1. In a text editor, open the `records.config` file located in the Traffic Server `config` directory. 
+2. Edit the following variable:
+3. **Variable** **Description** 
+`_proxy.config.http.cache.ignore_authentication_`
+:   
+		
+		Set this variable to 1 to cache objects with WWW Authenticate headers.
+		
+				  
+
+4. Save and close the `records.config` file. 
+5. Navigate to the Traffic Server `bin` directory. 
+6. Run the command `traffic_line -x` to apply the configuration changes. 
+
+### Configuration Directives  ### {#ConfigurationDirectives}
+
+  
+
+In addition to client and origin server directives, Traffic Server responds to directives you specify through configuration options and files.   
+ You can configure Traffic Server to do the following: 
+
+  
+
+* _Not _cache any HTTP objects (refer to [Disabling HTTP Object Caching](#DisablingHTTPObjectCaching)).
+* Cache **dynamic content** - that is, objects with URLs that end in `**.asp**` or contain a question mark (**`?`**), semicolon (`**;**`), or `**cgi**`. For more information, refer to [Caching Dynamic Content](#CachingDynamicContent). 
+* Cache objects served in response to the `Cookie:` header (refer to [Caching Cookied Objects)](#CachingCookiedObjects). 
+* Observe never-cache rules in the `cache.config` file (refer to [cache.config](files.htm#cache.config)).
+
+####  Disabling HTTP Object Caching #### {#DisablingHTTPObjectCaching}
+
+  
+
+By default, Traffic Server caches all HTTP objects except those for which you 
+have set never-cache rules in the `cache.config` file. You can disable HTTP 
+object caching so that all HTTP objects are served directly from the origin 
+server and never cached, as detailed below.
+
+##### To disable HTTP object caching manually:  ##### {#disableHTTPobjectcachingmanually}
+
+1. In a text editor, open the `records.config` file located in the Traffic Server `config` directory. 
+2. Edit the following variable:
+3. **Variable** **Description** 
+`_proxy.config.http.cache.http_`
+:   
+		
+		Set this variable to 0 (zero) to disable HTTP object caching.
+		
+				  
+
+4. Save and close the `records.config` file. 
+5. Navigate to the Traffic Server `bin` directory. 
+6. Run the command `traffic_line -x` to apply the configuration changes.
+
+####  Caching Dynamic Content  #### {#CachingDynamicContent}
+
+  
+
+A URL is considered **dynamic** if it ends in `**.asp**` or contains a question 
+mark (**`?`**), a semicolon (**`;`**), or `**cgi**`. By default, Traffic Server 
+does _not_ cache dynamic content. You can configure Traffic Server to cache 
+dynamic content, although it's recommended for specialized proxy situations 
+only.
+
+##### To configure Traffic Server to cache dynamic content:  ##### {#configureTScachedynamiccontent}
+
+1. In a text editor, open the `records.config` file located in the Traffic Server `config` directory. 
+2. Edit the following variable:
+3. **Variable** **Description** 
+`_proxy.config.http.cache_urls_that_look_dynamic_`
+:   
+		
+		Set this variable to 1 to cache dynamic content.
+		
+				  
+
+4. Save and close the `records.config` file. 
+5. Navigate to the Traffic Server `bin` directory.
+6. Run the command `traffic_line -x` to apply the configuration changes.
+
+####  Caching Cookied Objects  #### {#CachingCookiedObjects}
+
+  
+
+By default, Traffic Server caches objects served in response to requests that 
+contain cookies (unless the object is text). Traffic Server does not cache 
+cookied text content because object headers are stored along with the object, 
+and personalized cookie header values could be saved with the object. With 
+non-text objects, it is unlikely that personalized headers are delivered or 
+used. 
+
+  
+
+You can reconfigure Traffic Server to: 
+
+  
+
+* _Not _ cache cookied content of any type. 
+* Cache cookied content that is of image type only. 
+* Cache all cookied content regardless of type.
+
+##### To configure how Traffic Server caches cookied content:  ##### {#configurehowTScachescookiedcontent}
+
+1. In a text editor, open the `records.config` file located in the Traffic Server `config` directory. 
+2. Edit the following variable:
+3. **Variable** **Description** 
+`_proxy.config.http.cache.cache_responses_to_cookies_`
+:   
+		
+		Set this variable to specify how Traffic Server caches cookied content:   
+		   0 = Do not cache any responses to cookies.   
+		   1 = Cache all responses to cookies.   
+		   2 = Cache responses to cookies of image type only.   
+		   3 = Cache all responses to cookies except text content-types (the default).
+		
+				  
+
+4. Save and close the `records.config` file. 
+5. Navigate to the Traffic Server `bin` directory. 
+6. Run the command `traffic_line -x` to apply the configuration changes. 
+
+## Forcing Object Caching ## {#ForcingObjectCaching}
+
+ 
+
+You can force Traffic Server to cache specific URLs (including dynamic URLs) 
+for a specified duration, regardless of `Cache-Control` response headers. 
+
+##### To force document caching:  ##### {#forcedocumentcaching}
+
+1. In a text editor, open the `cache.config` file located in the Traffic Server `config` directory. 
+2. Add a rule in the file for each URL you want Traffic Server to force cache, as shown below.   
+`url_regex=_URL_ ttl-in-cache=6h`   
+ where`_ URL_` is the URL you want Traffic Server to force cache. The time format can be `d` for days, `h` for hours (as shown), `m` for minutes, and `s` for seconds. You can also use mixed units: for example, `1h15m20s`. In addition, you can add secondary specifiers (for example, prefix and suffix) to the rule (refer to [cache.config](files.htm#cache.config)). 
+3. Save and close the `cache.config` file. 
+4. Navigate to the Traffic Server `bin` directory. 
+5. Run the command `traffic_line -x` to apply the configuration changes. 
+
+## Caching HTTP Alternates ## {#CachingHTTPAlternates}
+
+ 
+
+Some origin servers answer requests to the same URL with a variety of objects. 
+The content of these objects can vary widely, according to whether a server 
+delivers content for different languages, targets different browsers with different 
+presentation styles, or provides different document formats (HTML, PDF). Different 
+versions of the same object are termed **alternates** and are cached by Traffic 
+Server based on `Vary` response headers. You can specify additional request 
+and response headers for specific content types that Traffic Server will identify 
+as alternates for caching. You can also limit the number of alternate versions 
+of an object allowed in the cache. 
+
+### Configuring How Traffic Server Caches Alternates ### {#ConfiguringHowTSCachesAlternates}
+
+##### To configure how Traffic Server caches alternates, follow the steps below:  ##### {#configurehowTScachesalternates,followstepsbelow}
+
+1. In a text editor, open the `records.config` file located in the Traffic Server `config` directory. 
+2. Edit the following variables:
+3. **Variable** **Description** 
+`_proxy.config.http.cache.enable_default_vary_headers_`
+:   
+		
+		Set this variable to 1 to cache alternate versions of HTTP objects that do 
+		not contain the Vary header.
+		
+				  
+`_proxy.config.http.cache.vary_default_text_`
+:   Set this variable to specify the HTTP header field on which you want to vary 
+		if the request is for text: for example, an HTML document.
+`_proxy.config.http.cache.vary_default_images_`
+:   Set this variable to specify the HTTP header field on which you want to vary 
+		if the request is for images: for example, a `.gif` file.
+`_proxy.config.http.cache.vary_default_other_`
+:   Set this variable to specify the HTTP header field on which you want to vary 
+		if the request is for anything other than text or image.
+
+4. **Note:** If you specify `Cookie` as the header field on which to vary in the above variables, then make sure that the variable `_proxy.config.http.cache.cache_responses_to_cookies_` is set appropriately.   
+ For example, if you set `_proxy.config.http.cache.cache_responses_to_cookies_ ` to 2 (cache responses to cookies of image type only) and set the `_proxy.config.http.cache.vary_default_text_` variable to specify cookie, then alternates by cookie will not apply to text. 
+5. Save and close the `records.config` file. 
+6. Navigate to the Traffic Server `bin` directory. 
+7. Run the command `traffic_line -x` to apply the configuration changes. 
+
+### Limiting the Number of Alternates for an Object  ### {#LimitingNumberofAlternatesforanObject}
+
+ 
+
+You can limit the number of alternates Traffic Server can cache per object 
+(the default is 3). 
+
+**IMPORTANT:** Large numbers of alternates can affect Traffic Server cache 
+performance because all alternates have the same URL. Although Traffic Server 
+can look up the URL in the index very quickly, it must scan sequentially through 
+available alternates in the object store.
+
+##### To limit the number of alternates:  ##### {#limitnumberofalternates}
+
+1. In a text editor, open the `records.config` file located in the Traffic Server `config` directory. 
+2. Edit the following variable:
+3. **Variable** **Description** 
+`_proxy.config.cache.limits.http.max_alts_`
+:   
+		
+		Set this variable to specify the maximum number of alternate versions of an 
+		object you want Traffic Server to cache. The default value is three.
+		
+				  
+
+4. Save and close the `records.config` file. 
+5. Navigate to the Traffic Server `bin` directory. 
+6. Run the command `traffic_line -x` to apply the configuration changes. 
+
+## Using Congestion Control ## {#UsingCongestionControl}
+
+ 
+
+The **Congestion Control** option enables you to configure Traffic Server to 
+stop forwarding HTTP requests to origin servers when they become congested. 
+Traffic Server then sends the client a message to retry the congested origin 
+server later. 
+
+ 
+
+To use the **Congestion Control** option, you must perform the following tasks: 
+ 
+
+ 
+
+* Enable the Congestion Control option. 
+* Create rules in the `congestion.config` file to specify: 
+* which origin servers Traffic Server tracks for congestion
+   the timeouts Traffic Server uses, depending on whether a server is congested 
+   the page Traffic Server sends to the client when a server becomes congested 
+   if Traffic Server tracks the origin servers per IP address or per hostname 
+   
+
+##### To enable and configure the Congestion Control option :  ##### {#enableconfigureCongestionControloption}
+
+1. In a text editor, open the `records.config` file located in the Traffic Server `config` directory. 
+2. Edit the following variable:
+3. **Variable** **Description** 
+`_proxy.config.http.congestion_control.enabled_`
+:   
+		
+		Set this variable to 1 to enable the congestion control option.
+		
+				  
+
+4. Save and close the `records.config` file. 
+5. In a text editor, open the `congestion.config` file located in the Traffic Server `config` directory. 
+6. Enter rules to specify which origin servers are tracked for congestion and the timeout values Traffic Server uses to determine congestion. Refer to [congestion.config](files.htm#congestion.config) for the rule format. 
+7. Save and close the `congestion.config` file. 
+8. Navigate to the Traffic Server `bin` directory. 
+9. Run the command `traffic_line -x` to apply the configuration changes. 
+
+      
+
+   
+
+   
+
+         
+
+* [Overview](intro.htm)
+* [Getting Started](getstart.htm)
+* [HTTP Proxy Caching ](http.htm)
+* [Explicit Proxy Caching](explicit.htm)
+* [Reverse Proxy and HTTP Redirects](reverse.htm)
+* [Hierarchical Caching](hier.htm)
+* [Configuring the Cache](cache.htm)
+* [Monitoring Traffic](monitor.htm)
+* [Configuring Traffic Server](configure.htm)
+* [Security Options](secure.htm)
+* [Working with Log Files](log.htm)
+* [Traffic Line Commands](cli.htm)
+* [Event Logging Formats](logfmts.htm)
+* [Configuration Files](files.htm) 
+* [Traffic Server Error Messages](errors.htm)
+* [FAQ and Troubleshooting Tips](trouble.htm)
+* [Traffic Server 管理员指南](ts_admin_chinese.pdf) (PDF)
+
+   
+
+   
+
+ Copyright © 2011 [The Apache Software Foundation](http://www.apache.org/). 
+Licensed under the [Apache License](http://www.apache.org/licenses/), Version 
+2.0. Apache Traffic Server, Apache, the Apache Traffic Server logo, and the 
+Apache feather logo are trademarks of The Apache Software Foundation.
+
+
+

Added: trafficserver/site/branches/ats-cms/content/docs/trunk/admin/monitoring-traffic/index.en.mdtext
URL: http://svn.apache.org/viewvc/trafficserver/site/branches/ats-cms/content/docs/trunk/admin/monitoring-traffic/index.en.mdtext?rev=1070302&view=auto
==============================================================================
--- trafficserver/site/branches/ats-cms/content/docs/trunk/admin/monitoring-traffic/index.en.mdtext (added)
+++ trafficserver/site/branches/ats-cms/content/docs/trunk/admin/monitoring-traffic/index.en.mdtext Sun Feb 13 21:38:37 2011
@@ -0,0 +1,146 @@
+Notice:    Licensed to the Apache Software Foundation (ASF) under one
+           or more contributor license agreements.  See the NOTICE file
+           distributed with this work for additional information
+           regarding copyright ownership.  The ASF licenses this file
+           to you under the Apache License, Version 2.0 (the
+           "License"); you may not use this file except in compliance
+           with the License.  You may obtain a copy of the License at
+           .
+             http://www.apache.org/licenses/LICENSE-2.0
+           .
+           Unless required by applicable law or agreed to in writing,
+           software distributed under the License is distributed on an
+           "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+           KIND, either express or implied.  See the License for the
+           specific language governing permissions and limitations
+           under the License.
+
+
+   
+
+    
+      
+    
+
+ [![](/images/ts75.png)](/index.html)™
+      
+
+# Administrator's Guide # {#AdministratorsGuide}
+
+    
+
+   
+
+   
+
+      
+
+         
+
+            
+
+# Monitoring Traffic # {#MonitoringTraffic}
+
+Traffic Server provides several options for monitoring system performance and 
+analyzing network traffic.
+
+This chapter discusses the following topics:
+
+* [Traffic Server Monitoring Tools](#TrafficEdgeMonitoringTools)
+* [Working with Traffic Manager Alarms](#WorkingTrafficManagerAlarms)
+* [Viewing Statistics from Traffic Line](#ViewingStatisticsTrafficLine)
+
+## Traffic Server Monitoring Tools ## {#TSMonitoringTools}
+
+ Traffic Server provides the following tools to monitor system performance 
+and analyze network traffic:
+
+* Traffic Server can send email that's triggered by alarms that signal any detected failure conditions; refer to [Working with Traffic Manager Alarms](#WorkingTrafficManagerAlarms).
+* The Traffic Line command-line interface provides an alternative method of viewing Traffic Server performance and network traffic information; refer to [Viewing Statistics from Traffic Line](#ViewingStatisticsTrafficLine).
+* The Traffic Shell command-line tool provides yet another alternative method of viewing Traffic Server performance and network traffic information; refer to [Starting Traffic Shell](getstart.htm#StartingTrafficShell).
+
+## Working with Traffic Manager Alarms ## {#WorkingwithTrafficManagerAlarms}
+
+Traffic Server signals an alarm when it detects a problem. For example, the 
+space allocated to event logs could be full or Traffic Server may not be able 
+to write to a configuration file.
+
+### Configuring Traffic Server to Email Alarms ### {#ConfiguringTSEmailAlarms}
+
+To configure Traffic Server to send an email to a specific address whenever 
+an alarm occurs, follow the steps below:
+
+1. In a text editor, open the `records.config` file located in the Traffic Server `config` directory.
+2. Set the `_proxy.config.alarm_email_` variable to the email address alarms will be routed to.
+3. Save and close the `records.config` file.
+4. Navigate to the Traffic Server `bin` directory.   
+
+5. Run the command `traffic_line -x` to apply the configuration changes.
+
+### Using a Script File for Alarms ### {#UsingaScriptFileforAlarms}
+
+Alarm messages are built into Traffic Server - you cannot change them. However, 
+you can write a script file to execute certain actions when an alarm is signaled. 
+Traffic Server provides a sample script file named `example_alarm_bin.sh` in 
+the `bin` directory; simply modify the file to suit your needs.
+
+## Viewing Statistics from Traffic Line ## {#ViewingStatisticsfromTrafficLine}
+
+You can use the Traffic Line command-line interface to view statistics about 
+Traffic Server performance and web traffic. In addition to viewing statistics, 
+you can also configure, stop, and restart the Traffic Server system. For additional 
+information, refer to [Configuring Traffic Server Using Traffic Line](configure.htm#ConfiguringTrafficEdgeUsingTrafficLine) 
+and [Traffic Line Commands](cli.htm). You can view specific information about 
+a Traffic Server node or cluster by specifying the variable that corresponds 
+to the statistic you want to see. 
+
+##### To view a statistic: ##### {#viewastatistic}
+
+1. Log on to a Traffic Server node as the Traffic Server administrator; navigate to the Traffic Server `bin` directory.   
+
+2. Enter the following command:   
+`traffic_line -r _variable_`  
+ where _`variable`_ is the variable representing the information you want to view. For a list of variables you can specify, refer to [Traffic Line Variables](cli.htm#1025718).   
+  
+ For example, the following command displays the document hit rate for the Traffic Server node:   
+`traffic_line -r proxy.node.http.cache_hit_ratio`  
+  
+ If the Traffic Server `bin` directory is not in your path, then prepend the Traffic Line command with `./` (for example: `./traffic_line -r _variable_`).
+
+      
+
+   
+
+   
+
+         
+
+* [Overview](intro.htm)
+* [Getting Started](getstart.htm)
+* [HTTP Proxy Caching ](http.htm)
+* [Explicit Proxy Caching](explicit.htm)
+* [Reverse Proxy and HTTP Redirects](reverse.htm)
+* [Hierarchical Caching](hier.htm)
+* [Configuring the Cache](cache.htm)
+* [Monitoring Traffic](monitor.htm)
+* [Configuring Traffic Server](configure.htm)
+* [Security Options](secure.htm)
+* [Working with Log Files](log.htm)
+* [Traffic Line Commands](cli.htm)
+* [Event Logging Formats](logfmts.htm)
+* [Configuration Files](files.htm) 
+* [Traffic Server Error Messages](errors.htm)
+* [FAQ and Troubleshooting Tips](trouble.htm)
+* [Traffic Server 管理员指南](ts_admin_chinese.pdf) (PDF)
+
+   
+
+   
+
+ Copyright © 2011 [The Apache Software Foundation](http://www.apache.org/). 
+Licensed under the [Apache License](http://www.apache.org/licenses/), Version 
+2.0. Apache Traffic Server, Apache, the Apache Traffic Server logo, and the 
+Apache feather logo are trademarks of The Apache Software Foundation.
+
+
+

Added: trafficserver/site/branches/ats-cms/content/docs/trunk/admin/reverse-proxy-http-redirects/index.en.mdtext
URL: http://svn.apache.org/viewvc/trafficserver/site/branches/ats-cms/content/docs/trunk/admin/reverse-proxy-http-redirects/index.en.mdtext?rev=1070302&view=auto
==============================================================================
--- trafficserver/site/branches/ats-cms/content/docs/trunk/admin/reverse-proxy-http-redirects/index.en.mdtext (added)
+++ trafficserver/site/branches/ats-cms/content/docs/trunk/admin/reverse-proxy-http-redirects/index.en.mdtext Sun Feb 13 21:38:37 2011
@@ -0,0 +1,357 @@
+Notice:    Licensed to the Apache Software Foundation (ASF) under one
+           or more contributor license agreements.  See the NOTICE file
+           distributed with this work for additional information
+           regarding copyright ownership.  The ASF licenses this file
+           to you under the Apache License, Version 2.0 (the
+           "License"); you may not use this file except in compliance
+           with the License.  You may obtain a copy of the License at
+           .
+             http://www.apache.org/licenses/LICENSE-2.0
+           .
+           Unless required by applicable law or agreed to in writing,
+           software distributed under the License is distributed on an
+           "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+           KIND, either express or implied.  See the License for the
+           specific language governing permissions and limitations
+           under the License.
+
+
+   
+
+    
+      
+    
+
+ [![](/images/ts75.png)](/index.html)™
+      
+
+# Administrator's Guide # {#AdministratorsGuide}
+
+    
+
+   
+
+   
+
+      
+
+         
+
+            
+
+# Reverse Proxy and HTTP Redirects # {#ReverseProxyHTTPRedirects}
+
+As a reverse proxy cache, Traffic Server serves requests on behalf of origin 
+servers. Traffic Server is configured in such a way that it appears to clients 
+like a normal origin server.
+
+This chapter discusses the following topics: 
+
+* [Understanding Reverse Proxy Caching](#UnderstandingReverseProxyCaching)
+* [HTTP Reverse Proxy](#HTTPReverseProxy)
+* [Redirecting HTTP Requests](#RedirectingHTTPRequests)
+
+## Understanding Reverse Proxy Caching ## {#UnderstandingReverseProxyCaching}
+
+With **forward proxy caching**, Traffic Server handles web requests to distant 
+origin servers on behalf of the clients requesting the content. **Reverse proxy 
+caching** (also known as **server acceleration **or **virtual web hosting**) 
+is different because Traffic Server acts as a proxy cache on behalf of the 
+origin servers that store the content. Traffic Server is configured to be _the_ 
+origin server that the user is trying to connect to (in contrast to a typical 
+scenario inwhich the advertised hostname of the origin server resolves to Traffic 
+Server, which acts as the real origin server). 
+
+### Reverse Proxy Solutions  ### {#ReverseProxySolutions}
+
+There are many ways to use Traffic Server as a reverse proxy. Below are a few 
+example scenarios. 
+
+You can use Traffic Server in reverse proxy mode to: 
+
+* Offload heavily-used origin servers
+* Deliver content efficiently in geographically distant areas
+* Provide security for origin servers that contain sensitive information 
+
+#### Offloading Heavily-Used Origin Servers  #### {#OffloadingHeavily-UsedOriginServers}
+
+Traffic Server can absorb requests to the main origin server and improve the 
+speed & quality of web serving by reducing load and hot spots on backup origin 
+servers. For example, a web hoster can maintain a scalable Traffic Server serving 
+engine with a set of low-cost, low-performance, less-reliable PC origin servers 
+as backup servers. In fact, a single Traffic Server can act as the virtual 
+origin server for multiple backup origin servers, as shown in the figure below. 
+ 
+
+![](images/revproxy.jpg)
+
+> 
+>   
+> 
+> _**Traffic Server as reverse proxy for a pair of origin servers **_
+> 
+
+#### Delivering Content in Geographically-Dispersed Areas  #### {#DeliveringContentinGeographically-DispersedAreas}
+
+Traffic Server can be used in reverse proxy mode to accelerate origin servers 
+that provide content to areas not located within close geographical proximity. 
+Caches are typically easier to manage and are more cost-effective than replicating 
+data. For example, Traffic Server can be used as a mirror site on the far side 
+of a trans-Atlantic link to serve users without having to fetch the request 
+and content across expensive international connections. Unlike replication, 
+for which hardware must be configured to replicate all data and to handle peak 
+capacity, Traffic Server dynamically adjusts to best utilize the serving and 
+storing capacity of the hardware. Traffic Server is also designed to keep content 
+fresh automatically, thereby eliminating the complexity of updating remote 
+origin servers. 
+
+#### Providing Security for an Origin Server  #### {#ProvidingSecurityforanOriginServer}
+
+Traffic Server can be used in reverse proxy mode to provide security for an 
+origin server. If an origin server contains sensitive information that you 
+want to keep secure inside your firewall, then you can use a Traffic Server 
+outside the firewall as a reverse proxy for that origin server. When outside 
+clients try to access the origin server, the requests instead go to Traffic 
+Server. If the desired content is _not_ sensitive, then it can be served from 
+the cache. If the content is sensitive and not cacheable, then Traffic Server 
+obtains the content from the origin server (the firewall allows only Traffic 
+Server access to the origin server). The sensitive content resides on the origin 
+server, safely inside the firewall. 
+
+### How Does Reverse Proxy Work?  ### {#HowDoesReverseProxyWork?}
+
+When a browser makes a request, it normally sends that request directly to 
+the origin server. When Traffic Server is in reverse proxy mode, it intercepts 
+the request before it reaches the origin server. Typically, this is done by 
+setting up the DNS entry for the origin server (ie, the origin server’s 'advertised' 
+hostname) so it resolves to the Traffic Server IP address. When Traffic Server 
+is configured as the origin server, the browser connects to Traffic Server 
+rather than the origin server. For additional information, see [HTTP Reverse 
+Proxy](#HTTPReverseProxy).
+
+**Note:** To avoid a DNS conflict, the origin server’s hostname and its advertised 
+hostname must not be the same. 
+
+## HTTP Reverse Proxy ## {#HTTPReverseProxy}
+
+In reverse proxy mode, Traffic Server serves HTTP requests on behalf of a web 
+server. The figure below illustrates how Traffic Server in reverse proxy mode 
+serves an HTTP request from a client browser. 
+
+![](images/httprvs.jpg)
+
+> 
+>   
+> 
+> _**HTTP reverse proxy **_
+> 
+
+The figure above demonstrates the following steps: 
+
+1. A client browser sends an HTTP request addressed to a host called `www.host.com` on port 80. Traffic Server receives the request because it is acting as the origin server (the origin server’s advertised hostname resolves to Traffic Server). 
+2. Traffic Server locates a map rule in the `remap.config` file and remaps the request to the specified origin server (`realhost.com`). 
+3. Traffic Server opens an HTTP connection to the origin server. 
+4. If the request is a cache hit and the content is fresh, then Traffic Server sends the requested object to the client from the cache. Otherwise, Traffic Server obtains the requested object from the origin server, sends the object to the client, and saves a copy in its cache. 
+
+To configure HTTP reverse proxy, you must perform the following tasks: 
+
+* Create mapping rules in the `remap.config` file (refer to [Creating Mapping Rules for HTTP Requests](#CreatingMappingRulesHTTPRequests)). 
+* Enable the reverse proxy option (refer to [Enabling HTTP Reverse Proxy](#EnablingHTTPReverseProxy)). 
+
+In addition to the tasks above, you can also [Set Optional HTTP Reverse Proxy 
+Options](#SettingOptionalHTTPReverseProxyOptions). 
+
+### Creating Mapping Rules for HTTP Requests  ### {#CreatingMappingRulesforHTTPRequests}
+
+In forward proxy caching, Traffic Server acts as a proxy server and receives 
+proxy requests. In reverse proxy caching, however, Traffic Server must act 
+as an origin server rather than a proxy server - this means that it receives 
+server requests and not proxy requests. Therefore, to satisfy proxy requests, 
+Traffic Server must construct a proxy request from the server request. 
+
+In HTTP, proxy requests specify the entire URL whereas server requests specify only the path. A server request might look like this:  
+`GET /index.html HTTP/1.0 Host: real.dianes_books.com`  
+  
+However, the corresponding proxy request would look like this:   
+`GET http://real.dianes_books.com/index.html HTTP/1.0 Host: real.dianes_books.com`
+
+Traffic Server can construct a proxy request from a server request by using the server information in the host header. However, the correct proxy request must contain the hostname of the origin server, not the advertised hostname that name servers associate to Traffic Server. The advertised hostname is the name that appears in the host header; for the origin server `real.dianes_books.com`, the server request and host header would be:  
+`GET /index.html HTTP/1.0 Host: www.dianes_books.com`
+
+ And the correct proxy request should be   
+`GET http://real.dianes_books.com/index.html HTTP/1.0 Host: real.dianes_books.com`   
+
+To translate `www.dianes_books.com` to `real.dianes_books.com`, Traffic Server 
+needs a set of URL rewriting rules (mapping rules). Mapping rules are described 
+in [Using Mapping Rules for HTTP Requests](#UsingMappingRulesHTTPRequests). 
+
+In general, use reverse proxy mode to support more than one origin server. 
+In this case, all of the advertised hostnames resolve to the IP address or 
+virtual IP address of Traffic Server. Using host headers, Traffic Server is 
+able to translate server requests for any number of servers into proxy requests 
+for those servers. If Traffic Server receives requests from older browsers 
+that do not support host headers, then Traffic Server can either route these 
+requests directly to a specific server or send the browser to a URL containing 
+information about the problem (refer to [Setting Optional HTTP Reverse Proxy 
+Options](#SettingOptionalHTTPReverseProxyOptions)). 
+
+#### Handling Origin Server Redirect Responses  #### {#HandlingOriginServerRedirectResponses}
+
+Origin servers often send redirect responses back to browsers that redirecting 
+them to different pages. For example, if an origin server is overloaded, then 
+it might redirect browsers to a less loaded server. Origin servers also redirect 
+when web pages have moved to different locations. When Traffic Server is configured 
+as a reverse proxy, it must readdress redirects from origin servers so that 
+browsers are redirected to Traffic Server and _not_ to another origin server. 
+ 
+
+To readdress redirects, Traffic Server uses reverse-map rules. In general, 
+you should set up a reverse-map rule for each map rule. To create reverse-map 
+rules, refer to [Using Mapping Rules for HTTP Requests](#UsingMappingRulesHTTPRequests). 
+ 
+
+#### Using Mapping Rules for HTTP Requests  #### {#UsingMappingRulesforHTTPRequests}
+
+Traffic Server uses two types of mapping rules for HTTP reverse proxy: 
+
+* A **map rule** translates the URL in client requests into the URL where the content is located. When Traffic Server is in reverse proxy mode and receives an HTTP client request, it first constructs a complete request URL from the relative URL and its headers. Traffic Server then looks for a match by comparing the complete request URL with its list of target URLs in the `remap.config `file. For the request URL to match a target URL, the following conditions must be true: 
+* The scheme of both URLs must be the same
+* The host in both URLs must be the same. If the request URL contains an unqualified hostname, then it will never match a target URL with a fully-qualified hostname.
+* The ports in both URLs must be the same. If no port is specified in a URL, then the default port for the scheme of the URL is used.
+* The path portion of the target URL must match a prefix of the request URL path
+ If Traffic Server finds a match, then it translates the request URL into the replacement URL listed in the map rule: it sets the host and path of the request URL to match the replacement URL. If the URL contains path prefixes, then Traffic Server removes the prefix of the path that matches the target URL path and substitutes it with the path from the replacement URL. If two mappings match a request URL, then Traffic Server applies the first mapping listed in the `remap.config` file. 
+* 
+* A **reverse-map rule** translates the URL in origin server redirect responses to point to Traffic Server so that clients are redirected to Traffic Server instead of accessing an origin server directly. For example, if there is a directory `/pub` on an origin server at `www.molasses.com` and a client sends a request to that origin server for `/pub`, then the origin server might reply with a redirect to `http://www.test.com/pub/` to let the client know that it was a directory it had requested, not a document (a common use of redirects is to normalize URLs so that clients can bookmark documents properly).   
+ Traffic Server uses reverse-map rules to prevent clients (that receive redirects from origin servers) from bypassing Traffic Server and directly accessing the origin servers. 
+
+Both map and reverse-map rules consist of a **target** (origin) URL and a **replacement** 
+(destination) URL. In a **map rule**, the target URL points to Traffic Server 
+and the replacement URL specifies where the original content is located. In 
+a **reverse-map rule**, the target URL specifies where the original content 
+is located and the replacement URL points to Traffic Server. Traffic Server 
+stores mapping rules in the `remap.config` file located in the Traffic Server 
+`config` directory.
+
+##### To create mapping rules:  ##### {#createmappingrules}
+
+1. In a text editor, open the `remap.config` file located in the Traffic Server `config` directory. 
+2. Enter your map and reverse-map rules (refer to [remap.config](files.htm#remap.config)). 
+3. Save and close the `remap.config` file. 
+4. Navigate to the Traffic Server `bin` directory. 
+5. Run the command `traffic_line -x` to apply the configuration changes.
+
+### Enabling HTTP Reverse Proxy  ### {#EnablingHTTPReverseProxy}
+
+To enable HTTP reverse proxy, follow the steps below.
+
+1. In a text editor, open the `records.config` file located in the `config` directory. 
+2. Edit the following variable:
+3. **Variable** **Description** 
+`_proxy.config.reverse_proxy.enabled_`
+:   Set this variable to 1 to enable HTTP reverse proxy mode. 
+
+4. Save and close the `records.config` file. 
+5. Navigate to the Traffic Server `bin` directory. 
+6. Run the command `traffic_line -x` to apply the configuration changes. 
+
+### Setting Optional HTTP Reverse Proxy Options  ### {#SettingOptionalHTTPReverseProxyOptions}
+
+Traffic Server provides several reverse proxy configuration options that enable 
+you to: 
+
+* Configure Traffic Server to retain the client host header information in a request during translation
+* Configure Traffic Server to serve requests only to the origin servers listed in the mapping rules. As a result, requests to origin servers not listed in the mapping rules are not served.
+* Specify an alternate URL to which incoming requests from older clients (i.e., ones that do not provide `Host` headers) are directed
+
+##### To set optional HTTP reverse proxy options:  ##### {#setoptionalHTTPreverseproxyoptions}
+
+1. In a text editor, open the `records.config` file located in the `config` directory. 
+2. Edit the following variables:
+3. **Variable** **Description** 
+`_proxy.config.url_remap.pristine_host_hdr_`
+:   Set this variable to 1 to retain the client host header in the request.   
+		 Set this variable to 0 (zero) if you want Traffic Server to translate the client host header.
+`_proxy.config.url_remap.remap_required_`
+:   Set this variable to 1 if you want Traffic Server to serve requests only to the origin servers listed in the mapping rules of the `remap.config` file.   
+		 Set this variable to 0 (zero) if you want Traffic Server to serve requests to all origin servers.
+`_proxy.config.header.parse.no_host_url_redirect_`
+:   Enter the URL to which to redirect requests with no host headers.
+
+4. Save and close the `records.config` file. 
+5. Navigate to the Traffic Server `bin` directory. 
+6. Run the command `traffic_line -x` to apply the configuration changes. 
+
+## Redirecting HTTP Requests ## {#RedirectingHTTPRequests}
+
+You can configure Traffic Server to redirect HTTP requests without having to 
+contact any origin servers. For example, if you redirect all requests for `http://www.ultraseek.com` 
+to `http://www.server1.com/products/portal/search/`, then all HTTP requests 
+for `www.ultraseek.com` go directly to `www.server1.com/products/portal/search`. 
+ 
+
+You can configure Traffic Server to perform permanent or temporary redirects. 
+**Permanent redirects** notify the browser of the URL change (by returning 
+the HTTP status code `**301**`) so that the browser can update bookmarks. **Temporary 
+redirects **notify the browser of the URL change for the current request only 
+(by returning the HTTP status code **`307`**).
+
+##### To set redirect rules:  ##### {#setredirectrules}
+
+1. In a text editor, open the `remap.config` file located in the Traffic Server `config` directory. 
+2. Enter a mapping rule for each redirect you want to set. Each mapping rule must be on a separate line and must consist of three space-delimited fields: `type`, `target`, and `replacement`. The following table describes the format for each field.  
+**Field** **Description** 
+`type`
+:   Enter either one of the following:   
+		   `redirect`—redirects HTTP requests permanently without having to contact the origin server.   
+		   `redirect_temporary`—redirects HTTP requests temporarily without having to contact the origin server.
+`target`
+:   Enter the origin or from URL. You can enter up to four components:   
+		   _`scheme://host:port/path_prefix`_
+`replacement`
+:   Enter the destination or to URL. You can enter up to four components:   
+		   _`scheme://host:port/path_prefix`_
+ The following permanently redirects all HTTP requests for `www.server1.com` to `www.server2.com` :  
+`redirect http://www.server1.com http://www.server2.com `  
+  
+
+3. Save and close the `remap.config` file. 
+4. Navigate to the Traffic Server `bin` directory. 
+5. Run the command `traffic_line -x` to apply the configuration changes.
+
+      
+
+   
+
+   
+
+         
+
+* [Overview](intro.htm)
+* [Getting Started](getstart.htm)
+* [HTTP Proxy Caching ](http.htm)
+* [Explicit Proxy Caching](explicit.htm)
+* [Reverse Proxy and HTTP Redirects](reverse.htm)
+* [Hierarchical Caching](hier.htm)
+* [Configuring the Cache](cache.htm)
+* [Monitoring Traffic](monitor.htm)
+* [Configuring Traffic Server](configure.htm)
+* [Security Options](secure.htm)
+* [Working with Log Files](log.htm)
+* [Traffic Line Commands](cli.htm)
+* [Event Logging Formats](logfmts.htm)
+* [Configuration Files](files.htm) 
+* [Traffic Server Error Messages](errors.htm)
+* [FAQ and Troubleshooting Tips](trouble.htm)
+* [Traffic Server 管理员指南](ts_admin_chinese.pdf) (PDF)
+
+   
+
+   
+
+ Copyright © 2011 [The Apache Software Foundation](http://www.apache.org/). 
+Licensed under the [Apache License](http://www.apache.org/licenses/), Version 
+2.0. Apache Traffic Server, Apache, the Apache Traffic Server logo, and the 
+Apache feather logo are trademarks of The Apache Software Foundation.
+
+
+



Mime
View raw message