An acceleration policy
is a collection of rules that specify how the WebAccelerator system caches, assembles, and responds to HTTP requests. There are two main parts to an acceleration policy:
| || |Matching rules
The WebAccelerator system uses matching rules to group requests and responses to a specific leaf node on the Policy Tree. Matching rules are based on specific parameters for HTTP data types, such as path, file extension, cookie, or query parameter.
| || |Acceleration rules
The WebAccelerator system uses acceleration rules to manage HTTP requests and responses.
For each matching rule in an acceleration policy, there are corresponding
acceleration rules. The matching rules and acceleration rules are organized in a tree structure called the Policy Tree
When the WebAccelerator system receives an HTTP request from a client or
a response from an origin web server, it reviews the header information and performs a process called application matching
. During application matching, the WebAccelerator system analyzes information in an HTTP request and matches the request to an application profile that you created. The WebAccelerator system uses the application profiles associated acceleration policys matching rules to group the request and response to a specific leaf node on the Policy Tree. Once the request and response are matched to a leaf node, the WebAccelerator system applies the policys acceleration rules to each group.
are based on specific parameters for HTTP data types and HTTP response header data types. The WebAccelerator system uses matching rules to look for identified objects in an HTTP request or response, such as path, file extension, cookie, or query parameter, in order to group the requests and responses. Once grouped, the WebAccelerator system applies the associated acceleration rules to the request and responses.
When configuring matching rules, you define the HTTP data types that the
WebAccelerator system should look for in an HTTP request to group the requests and responses. Once the WebAccelerator system groups requests and responses, it applies the associated acceleration rules.
Unlike HTTP request data types, matching rules are not based directly on
the value of an HTTP response data type. Instead, the WebAccelerator system uses these values to classify a request or response and generate an object type. Matching rules are based on object type.
For requests, the classification is based on the file extension present in the
request. For example, a matching rule might specify that the WebAccelerator system place all requests with a .gif
extension into a group for images. An assembly rule might specify that the WebAccelerator system use a value for a query parameter contained in a request, as a substitute for a value in the cached response, before it assembles the page.
| || |The Content-Type
header in the response (unless it is an ambiguous MIME type)
Once the WebAccelerator system classifies a request or response by object
type, it generates a content type for it by appending the object type to the group to which the object type belongs.
You can then define a matching rule based on the object type, for example
header, by specifying the regular expression you to match, or not to match, for the content type in a request or response.
dictate how the WebAccelerator system manages requests and responses. Each acceleration rule is associated with a matching rule, represented by a leaf node on the Policy Tree. Once the WebAccelerator system finds the matching leaf node, it applies the leaf nodes associated acceleration rules.
Some of the acceleration rules pertain to how the WebAccelerator system
handles a request, and some pertain to how the WebAccelerator system handles the response.
| || |Variation
Identifies specific elements in an HTTP request that affect the content contained in the web page, and specifies whether the WebAccelerator system should use those elements in the UCI to identify cached content. Variation rules are associated with content that is specific to requests. For example, variation rules can specify content that the WebAccelerator system should serve based on a certain cookie. For more information, see Chapter 7, Configuring Variation Rules
| || |Assembly
Specifies how the WebAccelerator system assembles a compiled response for a request. Assembly rules include options for Intelligent Browser Referencing, MultiConnect, Enable Content Assembly on Proxies, and parameter substitution. The WebAccelerator system applies assembly rules to requests. For more information, see Chapter 8, Configuring Assembly Rules
| || |Proxying
Identifies specific elements in an HTTP request that prompt the WebAccelerator system to forward the request to the origin web servers. The WebAccelerator system applies some elements of proxying rules to requests, and some elements to responses. For more information, see Chapter 9, Configuring Proxying Rules
| || |Lifetime
Specifies, with minimum and maximum age variables, how long content should remain in the WebAccelerator systems cache before the WebAccelerator system sends the request to the origin server for fresh content. The WebAccelerator system applies lifetime rules to responses. For more information, see Chapter 10, Configuring Lifetime Rules
| || |Responses Cached
Specifies the content that the WebAccelerator system should cache, based on the HTTP response code that arrived with the content. The WebAccelerator system applies responses cached rules to responses. For more information, see Chapter 12, Configuring Responses Cached Rules
You have the option to use a different type of acceleration policy for each
application profile that you configure, depending on the matching rules and acceleration rules you want to apply.
The WebAccelerator system ships with several pre-defined acceleration policies
, which are optimized for specific applications. In most cases, you can use one of these pre-defined acceleration policies to manage the HTTP requests to the applications on your sites origin web servers.
If you have an application for which a pre-defined acceleration policy is not
provided, or you want to use a pre-defined acceleration policy that is not configured for a specific application, you may choose to use one of the two pre-defined, general-delivery acceleration policies.
| || |Level 1 Delivery
This pre-defined acceleration policy is compliant with HTML version 2.0. For this pre-defined acceleration policy, the WebAccelerator system:
| || |Level 2 Delivery
This pre-defined acceleration policy is compliant with HTML version 3.0, and later. In most cases, you use this pre-defined policy for those applications for which there is no application-specific pre-defined policy available. For this acceleration policy, the WebAccelerator system:
Both of the general-delivery acceleration policies that are shipped with the
WebAccelerator system work well for sites that use Java 2 Platform Enterprise Edition (J2EE) applications.
In addition to these application-specific and general delivery acceleration
policies, the WebAccelerator system also provides a deployment-specific acceleration policy, called Symmetric Deployment
. You can select this acceleration policy if you have configured an optional symmetric deployment. For more information about the symmetric deployment configuration option, see the Configuration and Maintenance Tasks
chapter in the Configuration Guide for the BIG-IP® WebAcceleratorTM System.
Although the pre-defined acceleration policies work best for most sites, your
site may have a specialized application, or a unique configuration that requires the WebAccelerator system to handle HTTP requests in a specific manner that is not addressed in a pre-defined acceleration policy.
For these types of scenarios, you can create your own user-defined acceleration policy
with customized matching rules and acceleration rules to work with your unique configuration.
Another type of acceleration policy that is available on the WebAccelerator
system is a signed acceleration policy. A policy
is an acceleration policy that is encrypted and digitally signed by the author. Signed acceleration policies can be provided to you by various sources, such as a partner or a consultant, or you can create one yourself by signing a user-defined acceleration policy.
Since a signed acceleration policy is certified by the author, you cannot view
or modify the individual acceleration rules once an acceleration policy is signed. You can, however, modify the signed acceleration policys logging options.