Applies To:

Show Versions Show Versions

Manual Chapter: Other Application-Layer Profiles
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

BIG-IP® Local Traffic ManagerTM offers several features that you can use to intelligently control your application layer traffic. These features are available through various configuration profiles.
A profile is a group of settings, with values, that correspond to a specific type of traffic, such as FTP traffic. A profile defines the way that you want the BIG-IP system to manage that traffic type.
Note: An additional profile type, SMTP, is available when BIG-IP® Protocol Security ModuleTM is licensed on the system.
In addition to these application layer profiles, Local Traffic Manager includes other features to help you manage your application traffic, such as health monitors for checking the health of an FTP service, and iRules® for querying or manipulating header or content data.
To configure and manage various services profiles, log in to the BIG-IP Configuration utility, and on the Main tab, expand Local Traffic, click HTTP, and from the Services menu, choose a profile type.
Local Traffic Manager includes a profile type that you can use to manage File Transfer Protocol (FTP) traffic. You can tailor FTP profile settings to your specific needs. For those settings that have default values, you can retain those default settings or modify them. You can modify any settings either when you create the profile, or at any time after you have created it.
Table 7.1 lists the FTP profile settings, along with a short description of each setting and the default values.
Specifies the user-supplied name of the profile. Specifying a name for your profile is required.
Ensures compatibility between IP version 4 and IP version 6 clients and servers when using the FTP protocol.
Enables the FTP data channel to inherit the TCP profile used by the control channel. If disabled, the data channel uses FastL4 only. The default is unchecked (disabled).
Specifies, when checked (enabled), that the system inspects FTP traffic for security vulnerabilities, by using a security profile in BIG-IP® Protocol Security Module. This option is available only when you are licensed for the module.
Because IP version 6 addresses are not limited to 32 bits (unlike IP version 4 addresses), compatibility issues can arise when using FTP in mixed IP-version configurations.
By default, Local Traffic Manager automatically translates FTP commands when a client-server configuration contains both IP version 4 (IPv4) and IP version 6 (IPv6) systems. For example, if a client system running IPv4 sends the FTP PASV command to a server running IPv6, Local Traffic Manager automatically translates the PASV command to the equivalent FTP command for IPv6 systems, EPSV.
When you configure the BIG-IP system to process FTP traffic, the FTP virtual server fully proxies the control channel, allowing you to use the optimization settings of the client-side and server-side TCP profiles assigned to the virtual server.
However, the profile settings of the FTP control channel are not passed down to the FTP data channel by default. Instead, the FTP data channel uses a Fast L4 flow, which is fully accelerated by Packet Velocity ASIC to maximize performance (on applicable hardware platforms). A data channel using Fast L4 cannot use the same full-proxy TCP optimizations that exist for the control channel.
To take advantage of these optimizations for the FTP data channel, you can enable the Inherit Parent Profile setting of the FTP profile. Enabling this setting disables Fast L4 for the FTP data channel and instead allows the data channel to use the same TCP profile settings that the control channel uses.
The Data Port setting allows the FTP service to run on an alternate port. The default data port is 20.
When the BIG-IP system includes a license for the BIG-IP Application Security ManagerTM, you can enable a security scan for FTP traffic.
You can create a custom DNS profile to enable various features such as converting IPv6-formatted addresses to IPv4 format, enabling DNS ExpressTM, and enabling DNSSEC.
Table 7.2 lists the DNS profile settings, along with a short description of each setting and the default values.
Specifies the user-supplied name of the profile. Specifying a name for your profile is required.
Specifies whether you want the BIG-IP system to convert IPv6-formatted IP addresses to IPv4-formatted IP addresses. The possible values are:
Disabled: Indicates that the BIG-IP system does not map IPv4 addresses to IPv6 addresses.
Secondary: Indicates that the BIG-IP system receives an AAAA query and forwards the query to a DNS server.
Immediate: Indicates that the BIG-IP system receives an AAAA query and forwards the query to a DNS server.
v4 Only: Indicates that the BIG-IP system receives an AAAA query, but forwards an A query to a DNS server.
When you select Secondary, Immediate, or v4 Only, you must also provide a prefix in the IPv6 to IPv4 Prefix field and make a selection from the IPv6 to IPv4 Additional Section Rewrite list.
Indicates whether the dns-express service is enabled. The service handles zone transfers from the primary DNS server.
Specifies whether the system signs responses and replies to DNSSEC-specific queries (for example, DNSKEY query type).
Specifies whether the system uses the local BIND server on the BIG-IP system. The possible values are:
Allow: Indicates that the BIG-IP system forwards the connection request to another DNS server or DNS server pool. If a DNS server pool is not associated with a listener and the Use BIND Server on BIG-IP setting is set to Enabled, connection requests are forwarded to the local BIND server.
Drop: Indicates that the BIG-IP system does not respond to the query.
Reject: Indicates that the BIG-IP system returns the query with the REFUSED return code.
Hint: Indicates that the BIG-IP system returns the query with a list of root name servers.
No Error: Indicates that the BIG-IP system returns the query with the NOERROR return code.
Specifies whether the system forwards non-wide IP queries to the local BIND server on the BIG-IP system. For best performance, disable this setting when using a DNS cache.
Indicates whether to process client-side DNS packets with Recursion Desired set in the header. If set to Disabled, processing of the packet is subject to the unhandled-query-action option.
Enabled: Indicates the BIG-IP system caches DNS responses handled by the virtual servers associated with this profile. When you enable this setting, you must also select a cache from the DNS Cache Name list.
Disabled: Indicates the BIG-IP system does not cache DNS responses handled by the virtual servers associated with this profile. However, the profile retains the association with the DNS cache in the DNS Cache Name field. Disable this setting when you want to debug the system.
Specifies the user-created cache that the system uses to cache DNS responses. When you select a cache for the system to use, you must also enable the DNS Cache setting.
Indicates whether to enable high speed logging for DNS queries and responses. When it is set to Enabled, you must also specify a Logging Profile.
Specifies the DNS logging profile used to configure what events get logged and their message format. These are the DNS Logging profiles you create using the Other option under Profiles in the BIG-IP Configuration utility.
Local Traffic Manager includes a profile type that you can use to manage Real Time Streaming Protocol (RTSP) traffic. Real Time Streaming Protocol (RTSP) is a protocol used for streaming-media presentations. Using RTSP, a client system can control a remote streaming-media server and allow time-based access to files on a server.
The setup of streaming media over UDP. In this case, the control connection opens the required ports to allow data to flow through the BIG-IP system.
A common configuration for the RTSP profile is one that includes RTSP clients and media servers, as well as RTSP proxies to manage accounting and authentication tasks. In this proxied configuration, you most likely want the streaming media from the servers to pass directly to the client, bypassing the RTSP proxy servers.
To implement this configuration, you configure Local Traffic Manager by creating two virtual servers, one for processing traffic to and from the external network, and one for processing traffic to and from the internal network. For each virtual server, you assign a separate RTSP profile.
The RTSP profile on the external virtual server passes client IP address information to the RTSP profile on the internal virtual server.
The RTSP profile on the internal virtual server extracts the client IP address information from the request, processes the media servers response, and opens the specified ports on the BIG-IP system. Opening these ports allows the streaming media to bypass the RTSP proxy servers as the data travels from the server to the client.
The client IP address information is stored in the Proxy Header setting that you specify in the RTSP profile.
Table 7.3 lists the configurable settings in an RTSP profile, along with a short description of each setting and the default values.
Specifies the number of seconds that a UDP connection is idle before the connection is eligible for deletion.
Specifies the largest RTSP request or response header, in bytes, that the BIG-IP system allows before terminating the connection.
Specifies the maximum amount of data, in bytes, that the BIG-IP system buffers, before considering the connection to be unusable and subsequently terminating the connection.
If you are using unicast streams and you enable this setting, the client is able to specify the destination address and port for the streamed data. For security reasons however, the destination address used is the source of the request.
If you are using multicast streams and you enable this setting, the client has permission to supply a different destination for the streamed data.
When this setting is enabled and a disconnected control connection has been resumed, the BIG-IP system persists the resumed control connection to the correct server. Typical clients do not support this behavior.
When this setting is enabled, the system automatically persists Real Networks-tunneled RTSP data over HTTP, which is over the RTSP port. The default value is Enabled. When you disable this setting, a user can override the default behavior with an iRule.
When checked (enabled), specifies that the system examines the origin of the message to determine whether the message came from the client or the server.
Specifies whether the RTSP profile is associated with an RTSP proxy configuration. Possible values are: None, External, and Internal.
Specifies a name for the header that the system inserts into a SETUP request. The name must begin with the string X-. The value of this header typically consists of information about the client IP address and is read by another RTSP profile. Note that the system removes this header from the request prior to sending the request to the server for processing.
Specifies the port number that a Microsoft® Media Services server uses. Normally, Microsoft Media Services uses a fixed Realtime Transport Protocol (RTP) port number. With this setting, you can specify a port number instead of using the fixed RTP port number.
Specifies an RTCP port companion of the RTP Port value. Normally, Microsoft Media Services uses a fixed Real-Time Control Protocol (RTCP) port number. With this setting, you can specify a port number instead of using the fixed RTCP port number.
You can configure one or more Internet Content Adaptation Protocol (ICAP) profiles when you want to use the BIG-IP content adaptation feature for adapting HTTP requests and responses. This feature allows a BIG-IP virtual server to conditionally forward HTTP requests and HTTP responses to a pool of ICAP servers for modification, before sending a request to a web server or returning a response to the client system.
You assign one of the profiles to a virtual server of type Internal that sends HTTP requests to a pool of ICAP servers.
You assign the other profile to a virtual server of type Internal that sends HTTP responses to a pool of ICAP servers.
For more information on content adaptation for HTTP traffic, see the guide titled BIG-IP® Local Traffic Manager: Implementations, available on the AskF5TM knowledge base at http://support.f5.com.
Table 7.4 lists the ICAP profile settings, along with a short description of each setting and the default values.
Tip: You can use macro expansion for all ICAP header values. For example, if an ICAP header value contains {SERVER_IP}, the BIG-IP system replaces the macro with the IP address of the ICAP server. Similarly, if an ICAP header value contains ${SERVER_PORT}, the BIG-IP system replaces the macro with the port of the ICAP server. For example, you can set the URI value in an ICAP profile to icap://${SERVER_IP}:${SERVER_PORT}/virusScan.
Specifies an existing profile to use as the parent profile. A profile inherits settings from its parent, unless you override the setting by checking its Custom box and modifying the value.
Specifies the absolute URI that contains both the complete hostname and the path of the resource to use in the ICAP header. You can find more information in RFC 3507 section 4.2.
Specifies the length, in bytes, of the preview in the transaction. Requests sent to the ICAP server may include a preview, which allows an ICAP server to see the beginning of a transaction to determine whether to receive the remaining portion of the message. It is important that the specified preview length not exceed the length that the ICAP server expects to receive.
Specifies the value of the ICAP FROM: header. You can find more information in RFC 3507.
Specifies the value of the ICAP Host: header. You can find more information in RFC 3507.
Specifies the value of the ICAP Referer: header. You can find more information in RFC 3507.
Specifies the value of the ICAP User-Agent: header. You can find more information in RFC 3507.
You can configure a Request Adapt or Response Adapt profile when you want to use the BIG-IP content adaptation feature for adapting HTTP requests and responses. A Request Adapt or Response Adapt profile instructs an HTTP virtual server to send a request or response to a named virtual server of type Internal, for possible modification by an Internet Content Adaptation Protocol (ICAP) server.
For more information on content adaptation for HTTP traffic, see the guide titled BIG-IP® Local Traffic Manager: Implementations, available on the AskF5TM knowledge base at http://support.f5.com.
Table 7.5 lists the Request Adapt and Response Adapt profile settings, along with a short description of each setting and the default values.
Specifies an existing profile to use as the parent profile. A profile inherits settings from its parent, unless you override the setting by checking its Custom box and modifying the value.
requestadapt or responseadapt
Specifies that the system sends the request or response to the specified Internal type of virtual server for modification.
Specifies the name of the virtual server to use for modifying the request or response. The virtual server you specify must be of type Internal.
Specifies the size, in bytes, of the buffer to store the unmodified request or response, if the adaptation server determines that no modification is necessary.
Specifies the timeout in seconds. If the Internal virtual server does not return a result within the specified time, the operation times out. Specifying 0 disables the timeout.
Ignore: Instructs the system to ignore the request or response, and instead send the unmodified request or response to a content server.
Reset: Instructs the system to reset the connection with the client.
Drop: Instructs the system to drop the connection with the client.
Local Traffic Manager includes a profile type that you can use to manage Diameter traffic. The Diameter protocol is an enhanced version of the Remote Authentication Dial-In User Service (RADIUS) protocol.
When you configure a Diameter type of profile, the BIG-IP system can send client-initiated Diameter messages to load balancing servers. The BIG-IP system can also ensure that those messages persist on the servers.
Table 7.6 lists the settings of a Diameter type of profile, along with a short description of each setting and the default values.
Specifies the profile that you want to use as the parent profile. Your new profile inherits all non-custom settings and values from the parent profile specified.
Allows you to select an attribute name or specify a code for an attribute-value pair (AVP). The system uses this value as the persistent key for making a load balancing decision. The default value is Session-Id. If this value is set to None, the session persistence feature is disabled.
Possible values for the Persist Attribute setting are:
If you select Specify, you can type an AVP code, such as 280. In this case, the allowed range is 1 through 4294967295.
Allows you to select or enter a code for an attribute-value pair (AVP). If the value of the Persist Attribute setting is embedded in the grouped AVP, you must specify the Grouped/Parent Attribute value here; otherwise, persistence is disabled.
Configuring the Grouped/Parent Attribute setting means that the parent AVP is a grouped AVP, and its AVP value contains the Persist Attribute AVP. Only one level of embedding as the value of the parent AVP is allowed.
The possible values for the Grouped/Parent Attribute setting are:
If you select Specify, you can type an AVP code, such as 280. In this case, the allowed range is 1 through 4294967295. For example, you can enter code 280 for the Persist Attribute value, combined with 284 for the Grouped/Parent Attribute value.
Specifies whether the system uses the existing host IP address or overwrites the host IP address value in the request with the pool members IP address.
Specifies whether the system uses the existing originating server or overwrites the originating server value in the request with the one specified here. The default is None.
None: Indicates that the system uses the original originating server in the request.
Specify: Presents a box where you can enter a new originating server for the system to use to replace the originating server attribute in the request. A typical value for this attribute is the fully qualified domain name (FQDN) of the server representing the originating server.
Specifies whether the system uses the existing originating realm or overwrites the originating host value in the request with the one specified here. The default is None.
None: Indicates that the system uses the original originating realm in the request.
Specify: Presents a box where you can enter a new originating realm for the system to use to replace the originating realm attribute in the request. A sample value for this attribute is f5.com.
Specifies whether the system uses the existing destination host or overwrites the destination host value in the request with the pool members IP address. The default is enabled. A typical value for this attribute is the hosts fully-qualified domain name (FQDN).
Specifies whether the system uses the existing destination host or overwrites the destination realm value in the request with the pool members IP address. The default is None.
None: Indicates that the system uses the original destination realm in the request.
Specify: Presents a box where you can enter a new destination realm for the system to use to replace the originating realm attribute in the request. A sample value for this attribute is f5.com.
Indicates the number of seconds before the watchdog times out. The default is 0, meaning that the watchdog does not time out.
Indicates the maximum number of failures the watchdog can experience before closing the connection. The default is 10.
Checking this allows the MBLB proxy to establish a connection to all server pool members without actually having traffic. Normally Diameter servers do not process any request until all server handshakes are done, but for better performance, checking this keeps the server connections primed and ready.
Unchecked (Disabled)
The BIG-IP system includes a profile type that you can use to load balance Remote Authentication Dial-In User Service (RADIUS) traffic.
When you configure a RADIUS type of profile, the BIG-IP system can send client-initiated RADIUS messages to load balancing servers. The BIG-IP system can also ensure that those messages are persisted on the servers.
Table 7.7 lists the settings of a RADIUS load balancing profile, along with a short description of each setting and the default values.
Specifies the profile that you want to use as the parent profile. Your new profile inherits all non-custom settings and values from the parent profile specified.
Specifies the attribute/value pair or code that the BIG-IP system uses to persist RADIUS messages (UDP datagrams). Acceptable values are ASCII strings from section 5 of RFC 2865 or numeric codes (1-255).
Specifies whether to extract subscriber information from RADIUS packets. The default value indicates that the system will not extract subscriber information from RADIUS packets.
Enables the ability to specify individual addresses from which clients can connect. The default value indicates that any client can connect.
Specifies individual host and network addresses from which clients can connect. This setting only appears when the Client Spec value is set to Specify.
Specifies the RADIUS attribute to be used as the subscriber ID when extracting subscriber information from the RADIUS message. This field is ignored if the subscriber-aware is disabled. The value 3GPP IMSI indicates that the 3GPP-IMSI RADIUS sub-attribute is used as the subscriber ID. The value Calling Station ID indicates that the Calling-Station-Id RADIUS attribute is used as the subscriber ID. The value User Name indicates that the User-Name RADIUS attribute is used as the subscriber ID.
Note: The BIG-IP system also includes another type of RADIUS profile that you can use to configure remote authentication of application traffic.
Local Traffic Manager includes a services profile that you can use to manage Session Initiation Protocol (SIP) traffic. Session Initiation Protocol is an application-layer protocol that manages sessions consisting of multiple participants, thus enabling real-time messaging, voice, data, and video. A session can be a simple two-way telephone call or Instant Message dialogue, or a complex, collaborative, multi-media conference call that includes voice, data, and video.
SIP sessions, which are application level sessions, run through one of three Layer 4 protocols: SCTP, TCP, or UDP. The SIP profile configures how the system handles SIP sessions. The specified Layer 4 protocol profile configures the virtual server to open the required port to allow data to flow through the BIG-IP system. When you assign a SIP profile to a virtual server, you can also assign an SCTP, TCP, or UDP profile to the server. If you do not assign one of these protocol profiles to the server, Local Traffic Manager automatically assigns one for you.
The SIP profile automatically configures the BIG-IP system to handle persistence for SIP sessions using Call-ID. The Call-ID is a globally unique identifier that groups together a series of messages, which are sent between communicating applications. You can customize how the system handles persistence for SIP sessions.
Table 7.8 lists the settings in a SIP profile, along with a short description of each setting and the default value. Following this table are more detailed descriptions of the settings.
Specifies the maximum SIP message size that the BIG-IP system accepts. The system drops the connection if the SIP message is larger than this value.
Specifies that you want the BIG-IP system to snoop SIP dialog information and forward it to a known SIP dialog.
Disabled
(Unchecked)
Enables or disables the closing of a connection when a BYE transaction finishes. A BYE transaction is a message that an application sends to another application when it is ready to close the connection between the two. When the BIG-IP system encounters a BYE transaction, if the Terminate on BYE setting is enabled, then the system ends the connection. Use this parameter with UDP connections only, not with TCP connections.
Enabled
(Checked)
Enables or disables the insertion of a Via header into a SIP request. A Via header indicates where the message originated. The response message uses this routing information.
When the Insert Via Header setting is enabled, specifies a string that you want the system to insert as the value for the top Via header in a SIP request. This value specifies the SIP protocol, as well as a virtual address and port.
Enables or disables the insertion of a Secure Via header into a SIP request. A Secure Via Header indicates where the message originated. Use this parameter with SSL/TLS to secure the system. The response message uses this routing information.
Disabled
(Unchecked)
Enables or disables the insertion of a Record-Route SIP header, which indicates the next hop for the following SIP request messages.
Disabled
(Unchecked)
Local Traffic Manager accepts incoming SIP messages that are 65535 bytes or smaller. If a SIP message exceeds this value, the system drops the connection.
Local Traffic Manager can snoop SIP dialog information and automatically forward SIP messages to the known SIP dialog. To forward these messages, you can specify a SIP proxy functional group.
You can specify the name of a proxy functional group. You use this setting in the case where you need multiple virtual servers, each referencing a SIP-type profile, and you want more than one of those profiles to belong to the same proxy functional group.
Local Traffic Manager terminates a SIP connection when either the application that initiated the session (client) or the application that answered the initiated session (server) issues a BYE transaction. This is appropriate when a SIP session is running on UDP. However, if a SIP session is running on a SCTP or TCP connection, you can prevent the system from terminating the SIP connection.
An optional feature in a SIP profile is header insertion. You can specify whether Local Traffic Manager inserts Via, Secure Via, and Record-Route headers into SIP requests. When you assign the configured SIP profile to a virtual server, Local Traffic Manager then inserts the header specified in the profile into any SIP request that Local Traffic Manager sends to a pool or pool member.
You can configure Local Traffic Manager to insert a Via header into SIP requests to indicate where a SIP message originated. The SIP responses use this routing information to locate the session initiator.
When you enable the Insert Via Header setting, you then specify a User Via value. The User Via value is a string that the system inserts as the value of the top Via header value in a SIP request. The string specifies the SIP protocol, as well as a virtual address and port. An example of a User Via string is SIP/2.0/UDP 10.10.10.10:5060.
When you are using SSL/TLS (over TCP) to create a secure channel with the server node, you can configure Local Traffic Manager to insert a Secure Via header into a SIP request. The Secure Via Header setting indicates where the SIP message originated.
You can also configure Local Traffic Manager to insert a Record-Route header into SIP requests. The Insert Record-Route Header setting specifies the next hop for the SIP requests that follow.
Local Traffic Manager includes a type of persistence profile called a SIP persistence profile. You can customize how Local Traffic Manager handles persistence for SIP sessions by configuring both a SIP persistence profile and a SIP profile.
The SIP OneConnectTM feature allows connection flow reuse between inbound and outbound virtual servers for UDP connections. This feature addresses common SIP client behavior where source and destination ports are both 5060.
SIP OneConnect features a built-in dialog-aware behavior that addresses scenarios where the BIG-IP is the intermediary between more than two parties, creating an ambiguity between source and destination for the dialog. For example, in scenarios where an internal client initiates an outbound call using the wildcard virtual server to an external client that already has an existing flow on the inbound virtual server, the SIP OneConnect dialog-aware behavior correctly routes the response traffic.
Note: The SIP OneConnect dialog-aware feature is independent of the Dialog Aware setting in the SIP profile and is activated as long as two SIP profiles have identical community strings.
To activate the SIP OneConnect feature, type identical community strings in both SIP profiles used for the two virtual servers responsible for inbound and outbound SIP connections.
To disable the SIP OneConnect dialog-aware behavior and re-enable the default dialog-aware behavior, check the Dialog Aware setting when both community strings are set.
You can use the BIG-IP system to perform XML content-based routing whereby the system routes requests to an appropriate pool, pool member, or virtual server based on specific content in an XML document. For example, if your company transfers information in XML format, you could use this feature to examine the XML content with the intent to route the information to the appropriate department.
You can configure content-based routing by creating an XML profile and associating it with a virtual server. In the XML profile, define the matching content to look for in the XML document. Next, specify how to route the traffic to a pool by writing simple iRules. When the system discovers a match, it triggers an iRule event, and then you can configure the system to route traffic to a virtual server, a pool, or a node.
The following example shows a simple XML document that the system could use to perform content-based routing. It includes an element called FinanceObject used in this implementation.
Table 7.10 lists the XML profile settings, along with a short description of each setting and the default values.
Specifies the user-supplied name of the profile. Specifying a name for your profile is required.
Specifies how to map XML namespaces (as defined by the xmlns attribute) for the system to use when routing XML traffic to the correct pool, pool member, or virtual server.
Specifies the XPath query to define matching criteria in XML payloads so the system can route the traffic to the correct pool, pool member, or virtual server. In a typical example, you could have the system route a purchase-order (PO) representing less than a certain amount to pool member A, and a PO representing more than that amount to pool member B. When you assign an XML profile to a virtual server, the system searches XML traffic for matches for the defined XPath queries, and routes the traffic based on the search results.
Specifies that a query can be matched only once (if disabled) or may have multiple matches (if enabled).
You can use a SPDY (pronounced "speedy") profile to minimize latency of HTTP requests by multiplexing streams and compressing headers. When you assign a SPDY profile to an HTTP virtual server, the HTTP virtual server informs clients that a SPDY virtual server is available to respond to SPDY requests.
When a client sends an HTTP request, the HTTP virtual server manages the request as a standard HTTP request. It receives the request on port 80, and sends the request to the appropriate server. When the server provides a response, the BIG-IP system inserts an HTTP header into the response (to inform the client that a SPDY virtual server is available to handle SPDY requests), compresses and caches it, and sends the response to the client.
A client that is enabled to use the SPDY protocol sends a SPDY request to the BIG-IP system, the SPDY virtual server receives the request on port 443, converts the SPDY request into an HTTP request, and sends the request to the appropriate server. When the server provides a response, the BIG-IP system converts the HTTP response into a SPDY response, compresses and caches it, and sends the response to the client.
Table 7.11 lists and describes the settings of a SPDY load balancing profile.
Specifies how a connection is established as a SPDY connection. The value NPN specifies that the Transport Layer Security (TLS) Next Protocol Negotiation (NPN) extension determines whether the SPDY protocol is used. Clients that use TLS, but only support HTTP will work as if SPDY is not present. The value Always specifies that all connections must be SPDY connections, and that clients only supporting HTTP are not able to send requests. Selecting Always in the Activation Mode list is primarily intended for troubleshooting.
Specifies how many concurrent requests are allowed to be outstanding on a single SPDY connection.
Specifies whether an HTTP header that indicates the use of SPDY is inserted into the request sent to the origin web server.
Used only with an Activation Mode selection of NPN, specifies the protocol and protocol version (http1.1, spdy2, spdy3, or All Versions Enabled) used in the SPDY profile. For Selected Versions, the order of the protocols in the Selected Versions Enabled list ranges from most preferred (first) to least preferred (last). Adding http1.1 to the Enabled list allows HTTP1.1 traffic to pass. If http1.1 is not added to the Enabled list, clients that do not support HTTP1.1 are blocked. Clients typically use the first supported protocol. At least one SPDY version must be included in the Enabled list. The default is spdy3, spdy2, and http1.1.
All Versions Enabled (spdy3, spdy2, and http1.1.)
Specifies how the SPDY profile handles priorities of concurrent streams within the same connection. Selecting Strict processes higher priority streams to completion before processing lower priority streams. Selecting Fair enables higher priority streams to use more bandwith than lower priority streams, without completely blocking the lower priority streams.
Specifies the receive window, which is SPDY protocol functionality that controls flow, in KB. The receive window allows the SPDY protocol to stall individual upload streams when needed. This functionality is only available in SPDY3.
Specifies the size of the data frames, in bytes, that the SPDY protocol sends to the client. Larger frame sizes improve network utilization, but can affect concurrency.
Specifies the total size of combined data frames, in bytes, that the SPDY protocol sends in a single write function. This setting controls the size of the TLS records when the SPDY protocol is used over SSL. A large write size causes the SPDY protocol to buffer more data and improves network utilization.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)