Enable HTTP Optimization

Prefetches and stores objects embedded in web pages to improve HTTP traffic performance. By default, HTTP optimization is enabled.

Enable SteelFlow WTA (for SteelCentral AppResponse)

Enables the SCC to collect SteelFlow WTA data that can be sent (via REST API) to a SteelCentral AppResponse appliance. SteelFlow web transaction analysis (WTA) data includes the HTTP time stamp and payload data for web objects optimized by the SteelHead. AppResponse can combine this data into page views and calculate detailed metrics for server/network busy times, HTTP request/response delays, slow pages, view rates, HTTP response codes, and so on.

 

You must enable REST API access on each client-side SteelHead. Each client-side SteelHead needs at least one access code defined.

You must enable SSL optimization on the SteelHead if any of the monitored web applications are encrypted with SSL.

For details, see the AppResponse Xpert Integration with Other Riverbed Solutions Guide.

Enable SaaS User Identity
(Office 365)

Enables collection of statistics by user ID that is viewable in the Current Connections report. The User Identity column in the Current Connections report lists the full email address of the user. If the user email address is too long the user ID is displayed.

The SteelHead collects User IDs only from Office 365 users that are authenticated with single sign-on (SSO) using Active Directory Federation Services (ADFS).

This control is disabled by default. You only need to enable this control on one SteelHead in your network. We recommend enabling it on the client-side SteelHead for Office 365 traffic and the server-side SteelHead for SMB and MoH traffic.

Starting with RiOS 9.7, user IDs extracted on Office 365 connections are propagated to other connections originating from the same source IP. Additionally, user IDs for SMB and MAPI over HTTP (MoH) connections are displayed in this field if SMB or MoH optimization is enabled. This feature is disabled by default.

Store All Allowable Objects

Optimizes all objects in the object prefetch table. By default, Store All Allowable Objects is enabled.

Store Objects With The Following Extensions

Examines the control header to determine which objects to store. When enabled, RiOS doesn’t limit the objects to those listed in Extensions to Prefetch but rather prefetches all objects that the control header indicates are storable. This control header examination is useful to store web objects encoded into names without an object extension.

Disable the Object Prefetch Table

Stores nothing.

Minimum Object Prefetch Table Time

Sets the minimum number of seconds the objects are stored in the local object prefetch table. The default is 60 seconds.

This setting specifies the minimum lifetime of the stored object. During this lifetime, any qualified If-Modified-Since (IMS) request from the client receives an HTTP 304 response, indicating that the resource for the requested object hasn’t changed since stored.

Maximum Object Prefetch Table Time

Sets the maximum number of seconds the objects are stored in the local object prefetch table. The default is 86400 seconds.

This setting specifies the maximum lifetime of the stored object. During this lifetime, any qualified If-Modified-Since (IMS) request from the client receives an HTTP 304 response, indicating that the resource for the requested object hasn’t changed since stored.

Extensions to Prefetch

Specify object extensions to prefetch, separated by commas. By default the SteelHead prefetches .jpg, .gif, .js, .png, and .css object extensions.

These extensions are only for URL Learning and Parse and Prefetch.

Enable HTTP Stream Splitting

Enable this control on the client-side SteelHead to split Silverlight smooth streaming, Adobe Flash HTTP dynamic streams, and Apple HTTP Live Streaming (HLS). This global setting only applies to RiOS 8.6 and earlier. For RiOS 9.0 and later, use the per-host autoconfiguration setting.

This control includes support for Microsoft Silverlight video and Silverlight extensions support on Information Internet Server (IIS) version 7.5 installed on Windows Server 2008 R2.

To split Adobe Flash streams, you must set up the video origin server before enabling this control. For details, see the SteelHead Deployment Guide.

Apple HLS is an HTTP-based video delivery protocol for iOS and OSX that streams video to iPads, iPhones, and Macs. HLS is part of an upgrade to QuickTime. RiOS splits both live and on-demand video streams.

Use this control to support multiple branch office users from a single real-time TCP stream. The SteelHead identifies live streaming video URL fragment requests and delays any request that’s already in progress. When the client receives the response, it returns the same response to all clients requesting that URL.

As an example, when employees in branch offices simultaneously start clients (through browser plug-ins) that all request the same video fragment, the client-side SteelHead delays requests for that fragment because it is already outstanding. Since many identical requests typically are made before the first request is responded to, the result is many hits to the server and many bytes across the WAN. When you enable stream splitting on the client-side SteelHead, it identifies live streaming video URL fragment requests, and holds subsequent requests for that fragment because the first request for that fragment is outstanding. When the response is received, it is delivered to all clients that requested it. Thus, only one request and response pair for a video fragment transfers over the WAN. With stream splitting, the SteelHead replicates one TCP stream for each individual client.

Stream splitting optimization doesn’t change the number of sockets that are opened to the server, but it does reduce the number of requests made to the server. Without this optimization, each fragment is requested once per client. With this optimization, each fragment is requested once.

Stream splitting is disabled by default.

 

Enabling this control requires that HTTP optimization is enabled on the client-side and server-side SteelHeads. The client-side SteelHead requires an optimization service restart. No other changes are necessary on the server-side SteelHead.

In addition to splitting the video stream, you can prepopulate video at branch office locations during off-peak periods and then retrieve them for later viewing. For information, see the protocol http prepop list url command in the Riverbed Command-Line Interface Reference Manual.

To view a graph of the data reduction resulting from stream splitting, choose Reports > Optimization: Optimized Throughput.

Enable Per-Host Auto Configuration

Creates an HTTP optimization scheme automatically by evaluating HTTP traffic statistics gathered for the host or server subnet. RiOS derives the web server hostname or server subnet from the HTTP request header and collects HTTP traffic statistics for that host or subnet. RiOS evaluates hostnames and subnets that don’t match any other rules.

Automatic configurations define the optimal combination of URL Learning, Parse and Prefetch, and Object Prefetch Table for the host or subnet. After RiOS evaluates the host or subnet, it appears on the Subnet or Host list at the bottom of the page as Auto Configured. HTTP traffic is optimized automatically.

Automatic configuration is enabled by default. If you have automatically configured hostnames and then disabled Per-Host Auto Configuration, the automatically configured hosts are removed from the list when the page refreshes. They’re not removed from the database. When you reenable Per- Host Auto Configuration, the hosts reappear in the list with the previous configuration settings.

We recommend that both the client-side and server-side SteelHeads are running RiOS 7.0 or later for full statistics gathering and optimization benefits.

Enable this control on the client-side SteelHead.

You can’t remove an automatically configured hostname or subnet from the list, but you can reconfigure them, save them as a static host and then remove them.

In RiOS 8.5 and later, the default configuration appears in the list only when automatic configuration is disabled.

To allow a static host to be automatically configured, remove it from the list.

Enable Kerberos Authentication Support

Enable this control on the server-side SteelHead to optimize HTTP connections using Kerberos authentication end to end between the client-side and server-side SteelHeads and the server-side SteelHead and the server. This method enables RiOS to prefetch resources when the web server employs per-request Kerberos.

In addition to enabling this control on the server-side SteelHead, you must also join the server-side SteelHead to a Windows domain, and add replication users: choose Optimization > Active Directory: Auto Config > Configure Replication Account.

Both the client-side and server-side SteelHeads must be running RiOS 7.0 or later.

No additional configuration is needed on the client-side SteelHead.

Apply

Applies your settings.

 

Strip Compression

Marks the accept-encoding lines from the HTTP compression header so they’re not returned in calls. An accept-encoding directive compresses content rather than using raw HTML. Enabling this option improves the performance of the SteelHead data reduction algorithms. By default, strip compression is enabled.

Insert Cookie

Adds a cookie to HTTP applications that don’t already have one. HTTP applications frequently use cookies to keep track of sessions. The SteelHead uses cookies to distinguish one user session from another. If an HTTP application doesn’t use cookies, the client SteelHead inserts one so that it can track requests from the same client. By default, this setting is disabled.

Insert Keep Alive

Uses the same TCP connection to send and receive multiple HTTP requests and responses, as opposed to opening a new one for every single request and response. Specify this option when using the URL Learning or Parse and Prefetch features with HTTP version 1.0 or HTTP version 1.1 applications using the Connection Close method. By default, this setting is disabled.

 

Object Prefetch Table

Enable this control on the client-side SteelHead to store HTTP object prefetches from HTTP GET requests for cascading style sheets, static images, and Java scripts in the Object Prefetch Table. When the browser performs If-Modified-Since (IMS) checks for stored content or sends regular HTTP requests, the client-side SteelHead responds to these IMS checks and HTTP requests, cutting back on round trips across the WAN.

Stream Splitting

Enable this control on the client-side SteelHead to split Silverlight smooth streaming, Adobe Flash HTTP dynamic streams, and Apple HTTP Live Streaming (HLS). This control only applies to RiOS 9.0 and later.

This control includes support for Microsoft Silverlight video and Silverlight extensions support on Information Internet Server (IIS) version 7.5 installed on Windows Server 2008 R2.

To split Adobe Flash streams, you must set up the video origin server before enabling this control. For details, see the SteelHead Deployment Guide.

Apple HLS is an HTTP-based video delivery protocol for iOS and OSX that streams video to iPads, iPhones, and Macs. HLS is part of an upgrade to QuickTime. RiOS splits both live and on-demand video streams.

Use this control to support multiple branch office users from a single real-time TCP stream. The SteelHead identifies live streaming video URL fragment requests and delays any request that’s already in progress. When the client receives the response, it returns the same response to all clients requesting that URL.

As an example, when employees in branch offices simultaneously start clients (through browser plug-ins) that all request the same video fragment, the client-side SteelHead delays requests for that fragment because it is already outstanding. Since many identical requests typically are made before the first request is responded to, the result is many hits to the server and many bytes across the WAN. When you enable stream splitting on the client-side SteelHead, it identifies live streaming video URL fragment requests, and holds subsequent requests for that fragment because the first request for that fragment is outstanding. When the response is received, it is delivered to all clients that requested it. Thus, only one request and response pair for a video fragment transfers over the WAN. With stream splitting, the SteelHead replicates one TCP stream for each individual client.

RiOS 9.1 increases the cache size by up to five times, depending on the SteelHead model, and stores the video fragments for 30 seconds to keep clients watching the same live video in sync. For details, see the SteelHead Deployment Guide - Protocols.

Stream splitting optimization doesn’t change the number of sockets that are opened to the server, but it does reduce the number of requests made to the server. Without this optimization, each fragment is requested once per client. With this optimization, each fragment is requested once.

Stream splitting is disabled by default.

Enabling this control requires that HTTP optimization is enabled on the client-side and server-side SteelHeads. The client-side SteelHead doesn’t require an optimization service restart in RiOS 9.1. No other changes are necessary on the server-side SteelHead.

In addition to splitting the video stream, you can prepopulate video at branch office locations during off-peak periods and then retrieve them for later viewing. For information, see the protocol http prepop list url command in the Riverbed Command-Line Interface Reference Manual.

To view a graph of the data reduction resulting from stream splitting, choose Reports > Optimization: Live Video Stream Splitting.

 

URL Learning

Enables URL Learning, which learns associations between a base URL request and a follow-on request. Stores information about which URLs have been requested and which URLs have generated a 200 OK response from the server. This option fetches the URLs embedded in style sheets or any JavaScript associated with the base page and located on the same host as the base URL.

For example, if a web client requests /a.php?c=0 and then requests /b.php?c=0, and another client requests a.php?c=1 and then b.php?c=1, if somebody requests a.php?c=123, RiOS determines that it might request b.php?c=123 next and thus prefetches it for the client.

URL Learning works best with nondynamic content that doesn’t contain session-specific information. URL Learning is enabled by default.

Your system must support cookies and persistent connections to benefit from URL Learning. If your system has cookies turned off and depends on URL rewriting for HTTP state management, or is using HTTP version 1.0 (with no keepalives), you can force the use of cookies using the Add Cookie option and force the use of persistent connections using the Insert Keep Alive option.

Parse and Prefetch

Enables Parse and Prefetch, which parses the base HTML page received from the server and prefetches any embedded objects to the client-side SteelHead. This option complements URL Learning by handling dynamically generated pages and URLs that include state information. When the browser requests an embedded object, the SteelHead serves the request from the prefetched results, eliminating the round-trip delay to the server.

The prefetched objects contained in the base HTML page can be images, style sheets, or any Java scripts associated with the base page and located on the same host as the base URL.

Parse and Prefetch requires cookies. If the application doesn’t use cookies, you can insert one using the Insert Cookie option.

 

Reuse Auth

Allows an unauthenticated connection to serve prefetched objects, as long as the connection belongs to a session whose base connection is already authenticated.

This option is most effective when the web server is configured to use per-connection NTLM or Kerberos authentication.

Force NTLM

In the case of negotiated Kerberos and NTLM authentication, forces NTLM. Kerberos is less efficient over the WAN because the client must contact the Domain Controller to answer the server authentication challenge and tends to be employed on a per-request basis.

We recommend enabling Strip Auth Header along with this option.

Strip Auth Header

Removes all credentials from the request on an already authenticated connection. This method works around Internet Explorer behavior that reauthorizes connections that have previously been authorized.

This option is most effective when the web server is configured to use per-connection NTLM authentication.

Gratuitous 401

Prevents a WAN round trip by issuing the first 401 containing the realm choices from the client-side SteelHead.

We recommend enabling Strip Auth Header along with this option.

This option is most effective when the web server is configured to use per-connection NTLM authentication or per-request Kerberos authentication.

 

FPSE

Enables Microsoft Front Page Server Extensions (FPSE) protocol optimization. FPSE is one of the protocols in the Front Page protocol suite. FPSE compose a set of SharePoint server-side applications that let users simultaneously collaborate on the same website and web server to enable multiuser authoring. The protocol is used for displaying site content as a file system and allows file downloading, uploading, creation, listing, and locking. FPSE uses HTTP for transport.

RiOS 8.5 and later cache and respond locally to some FPSE requests to save at least five round trips per each request, resulting in performance improvements. SSL connections and files smaller than 5 MB can experience significant performance improvements.

FPSE supports SharePoint Office 2007/2010 clients installed on Windows XP and Windows 7 and SharePoint Server 2007/2010.

FPSE is disabled by default.

Choose Reports > Networking: Current Connections to view the HTTP-SharePoint connections. To display only HTTP-SharePoint connections, click add filter in the Query area, select for application from the drop-down menu, select HTTP-SharePoint, and click Update.

WebDAV

Enables Microsoft Web Distributed Authoring and Versioning (WebDAV) protocol optimization. WebDAV is an open-standard extension to the HTTP version 1.1 protocol that enables file management on remote web servers. Some of the many Microsoft components that use WebDAV include WebDAV redirector, Web Folders, and SMS/SCCM.

RiOS predicts and prefetches WebDAV responses, which saves multiple round trips and makes browsing the SharePoint file repository more responsive.

WebDAV optimization is disabled by default.

Choose Reports > Networking: Current Connections to view the HTTP-SharePoint connections. To display only HTTP-SharePoint connections, click add filter in the Query area, select for application from the drop-down menu, select HTTP-SharePoint, and click Update.

Add a Prefetch Tag

Displays the controls to add an HTML tag.

Tag Name

Specify the tag name.

Attribute

Specify the tag attribute.

Add

Adds the tag.

Add a Subnet or Host

Displays the controls for adding a server subnet or host. The server must support keepalive.

Server Subnet or Hostname

Specify an IP address and mask pattern for the server subnet, or a hostname, on which to set up the HTTP optimization scheme.

Use this format for an individual subnet IP address and netmask:

xxx.xxx.xxx.xxx/xx (IPv4)

x:x:x::x/xxx (IPv6)

You can also specify 0.0.0.0/0 (all IPv4) or ::/0 (all IPv6) as the wildcard for either IPv4 or IPv6 traffic.

Row Filters

 

Strip Compression

Marks the accept-encoding lines from the HTTP compression header so they’re not returned in calls. An accept-encoding directive compresses content rather than using raw HTML. Enabling this option improves the performance of the SteelHead data reduction algorithms. By default, strip compression is enabled.

Insert Cookie

Adds a cookie to HTTP applications that don’t already have one. HTTP applications frequently use cookies to keep track of sessions. The SteelHead uses cookies to distinguish one user session from another. If an HTTP application doesn’t use cookies, the client SteelHead inserts one so that it can track requests from the same client. By default, this setting is disabled.

Insert Keep Alive

Uses the same TCP connection to send and receive multiple HTTP requests and responses, as opposed to opening a new one for every single request and response. Specify this option when using the URL Learning or Parse and Prefetch features with HTTP version 1.0 or HTTP version 1.1 applications using the Connection Close method. By default, this setting is disabled.

 

URL Learning

Enables URL Learning, which learns associations between a base URL request and a follow-on request. Stores information about which URLs have been requested and which URLs have generated a 200 OK response from the server. This option fetches the URLs embedded in style sheets or any JavaScript associated with the base page and located on the same host as the base URL.

For example, if a web client requests /a.php?c=0 and then requests /b.php?c=0, and another client requests a.php?c=1 and then b.php?c=1, if somebody requests a.php?c=123, RiOS determines that it might request b.php?c=123 next and thus prefetches it for the client.

URL Learning works best with nondynamic content that doesn’t contain session-specific information. URL Learning is enabled by default.

Your system must support cookies and persistent connections to benefit from URL Learning. If your system has cookies turned off and depends on URL rewriting for HTTP state management, or is using HTTP version 1.0 (with no keepalives), you can force the use of cookies using the Add Cookie option and force the use of persistent connections using the Insert Keep Alive option.

Parse and Prefetch

Enables Parse and Prefetch, which parses the base HTML page received from the server and prefetches any embedded objects to the client-side SteelHead. This option complements URL Learning by handling dynamically generated pages and URLs that include state information. When the browser requests an embedded object, the SteelHead serves the request from the prefetched results, eliminating the round-trip delay to the server.

The prefetched objects contained in the base HTML page can be images, style sheets, or any Java scripts associated with the base page and located on the same host as the base URL.

Parse and Prefetch requires cookies. If the application doesn’t use cookies, you can insert one using the Insert Cookie option.

Object Prefetch Table

Enables the Object Prefetch Table, which stores HTTP object prefetches from HTTP GET requests for cascading style sheets, static images, and Java scripts in the Object Prefetch Table. When the browser performs If-Modified-Since (IMS) checks for stored content or sends regular HTTP requests, the client-side SteelHead responds to these IMS checks and HTTP requests, cutting back on round trips across the WAN.

 

Reuse Auth

Allows an unauthenticated connection to serve prefetched objects, as long as the connection belongs to a session whose base connection is already authenticated.

This option is most effective when the web server is configured to use per-connection NTLM or Kerberos authentication.

Force NTLM

In the case of negotiated Kerberos and NTLM authentication, forces NTLM. Kerberos is less efficient over the WAN because the client must contact the Domain Controller to answer the server authentication challenge and tends to be employed on a per-request basis.

We recommend enabling Strip Auth Header along with this option.

Strip Auth Header

Removes all credentials from the request on an already authenticated connection. This method works around Internet Explorer behavior that reauthorizes connections that have previously been authorized.

This option is most effective when the web server is configured to use per-connection NTLM authentication.

Gratuitous 401

Prevents a WAN round trip by issuing the first 401 containing the realm choices from the client-side SteelHead.

We recommend enabling Strip Auth Header along with this option.

This option is most effective when the web server is configured to use per-connection NTLM authentication or per-request Kerberos authentication.

FPSE

Enables Microsoft Front Page Server Extensions (FPSE) protocol optimization. FPSE is one of the protocols in the Front Page protocol suite. FPSE compose a set of SharePoint server-side applications that let users simultaneously collaborate on the same website and web server to enable multiuser authoring. The protocol is used for displaying site content as a file system and allows file downloading, uploading, creation, listing, and locking. FPSE uses HTTP for transport.

RiOS 8.5 and later cache and respond locally to some FPSE requests to save at least five round trips per each request, resulting in performance improvements. SSL connections and files smaller than 5 MB can experience significant performance improvements.

FPSE supports SharePoint Office 2007/2010 clients installed on Windows XP and Windows 7 and SharePoint Server 2007/2010.

FPSE is disabled by default.

Choose Reports > Networking: Current Connections to view the HTTP-SharePoint connections. To display only HTTP-SharePoint connections, click add filter in the Query area, select for application from the drop-down menu, select HTTP-SharePoint, and click Update.

WebDAV

Enables Microsoft Web Distributed Authoring and Versioning (WebDAV) protocol optimization. WebDAV is an open-standard extension to the HTTP version 1.1 protocol that enables file management on remote web servers. Some of the many Microsoft components that use WebDAV include WebDAV redirector, Web Folders, and SMS/SCCM.

RiOS predicts and prefetches WebDAV responses, which saves multiple round trips and makes browsing the SharePoint file repository more responsive.

WebDAV optimization is disabled by default.

Choose Reports > Networking: Current Connections to view the HTTP-SharePoint connections. To display only HTTP-SharePoint connections, click add filter in the Query area, select for application from the drop-down menu, select HTTP-SharePoint, and click Update.

Add

Adds the subnet or hostname.