TCP Configurations 编辑

TCP configurations for a Citrix ADC appliance can be specified in an entity called a TCP profile, which is a collection of TCP settings. The TCP profile can then be associated with services or virtual servers that want to use these TCP configurations.

A default TCP profile can be configured to set the TCP configurations that will be applied by default, globally to all services and virtual servers.

Note:

When a TCP parameter has different values for service, virtual server, and globally, the value of the most-specific entity (the service) is given the highest precedence. The Citrix ADC appliance also provides other approaches for configuring TCP. Read on for more information.

Supported TCP configuration

The Citrix ADC appliance supports the following TCP capabilities:

Defending TCP against spoofing attacks

The Citrix ADC implementation of window attenuation is RFC 4953 compliant.

Explicit Congestion Notification (ECN)

The appliance sends notification of the network congestion status to the sender of the data and takes corrective measures for data congestion or data corruption. The Citrix ADC implementation of ECN is RFC 3168 compliant.

Round trip time measurement (RTTM) using the timestamp option

For the TimeStamp option to work, at least one side of the connection (client or server) must support it. The Citrix ADC implementation of the TimeStamp option is RFC 1323 compliant.

Detection of spurious retransmissions

This detection can be done using TCP duplicate selective acknowledgment (D-SACK) and forward RTO-Recovery (F-RTO). If there are spurious retransmissions, the congestion control configurations are reverted to their original state. The Citrix ADC implementation of D-SACK is RFC 2883 compliant, and F-RTO is RFC 5682 compliant.

Congestion control

This functionality use New-Reno, BIC, CUBIC, Nile, and TCP Westwood algorithms.

Window scaling

This increases the TCP receive window size beyond its maximum value of 65,535 bytes.

Points to consider before you configure window scaling

• You do not set a high value for the scale factor, because this might have adverse effects on the appliance and the network.
• You do not configure window scaling unless you clearly know why you want to change the window size.
• Both hosts in the TCP connection send a window scale option during connection establishment. If only one side of a connection sets this option, window scaling is not used for the connection.
• Each connection for the same session is an independent window scaling session. For example, when a client’s request and the server’s response flow through the appliance, it is possible to have window scaling between the client and the appliance without window scaling between the appliance and the server.

TCP maximum congestion window

The window size is a user configurable one. The default value is 8190 bytes.

Selective acknowledgment (SACK)

This uses the data receiver (either a Citrix ADC appliance or a client) notifies the sender about all the segments that have been received successfully.

Forward acknowledgment (FACK)

This functionality avoids TCP congestion by explicitly measuring the total number of data bytes outstanding in the network, and helping the sender (either a Citrix ADC or a client) control the amount of data injected into the network during retransmission timeouts.

TCP connection multiplexing

This functionality enables reuse of existing TCP connections. The Citrix ADC appliance stores established TCP connections to the reuse pool. Whenever a client request is received, the appliance checks for an available connection in the reuse pool and serves the new client if the connection is available. If it is unavailable, the appliance creates a connection for the client request and stores the connection to the reuse pool. The Citrix ADC supports connection multiplexing for HTTP, SSL, and DataStream connection types.

Dynamic receive buffering

This allows the receive buffer to be adjusted dynamically based on memory and network conditions.

MPTCP Connection

MPTCP connections between the client and the Citrix ADC. MPTCP connections are not supported between the Citrix ADC and the back-end server. The Citrix ADC implementation of MPTCP is RFC 6824 compliant.

You can view MPTCP statistics such as active MPTCP connections and active subflow connections by using the command line interface.

At the command prompt, type one of the following commands to display a summary or detailed summary of MPTCP statistics, or to clear the statistics display:

1. Stat MPTCP
2. Stat mptcp –detail
3. Clearstats basic

Note:

To establish an MPTCP connection, both the client and the Citrix ADC appliance must support the same MPTCP version. If you use the Citrix ADC appliance as an MPTCP gateway for your servers, the servers do not have to support MPTCP. When the client starts a new MPTCP connection, the appliance identifies the client’s MPTPC version from the MP_CAPABALE option in the SYN packet. If the client’s version is higher than the one supported on the appliance, the appliance indicates its highest version in the MP_CAPABALE option of the SYN-ACK packet. The client then falls back to a lower version and sends the version number in the MP_CAPABALE option of the ACK packet. If that version is supportable, the appliance continues the MPTCP connection. Otherwise, the appliance falls back to a regular TCP. The Citrix ADC appliance does not initiate subflows (MP_JOIN’s). The appliance expects the client to initiate subflows.

Support for additional address advertisement (ADD_ADDR) in MPTCP

In an MPTCP deployment, if you have a virtual server bound with an IP set that has additional virtual server IP addresses, then the additional address advertisement (ADD_ADDR) functionality advertises the IP address of the virtual servers bound to the IP set. Clients can initiate additional MP-JOIN sub flows to the advertised IP addresses.

Points to remember about MPTCP ADD_ADDR functionality

• You can send a maximum of 10 IP addresses as part of the ADD_ADDR option. If there are more than 10 IP addresses with the mptcpAdvertise parameter enabled, after advertising the 10 IP address, the appliance ignore the rest of the IP addresses.
• If the MP-CAPABLE subflow is made to one of the IP addresses in the IP set instead of the primary virtual server IP address, then the virtual server IP address is advertised if the mptcpAdvertise parameter is enabled for the virtual server IP address

Configure more address advertisement (ADD_ADDR) feature to advertise additional VIP address by using the CLI

You can configure the MPTCP ADD_ADDR functionality for both IPv4 and IPv6 address types. In general, multiple IPv4 and IPv6 IPs can be attached to a single IP set and the parameter can be enabled on any subset of IP addresses. In the ADD_ADDR feature, only the IP addresses that have the “mptcpAdvertise” option enabled is advertised and the remaining IP addresses from the IP set is ignored. Complete the following steps to configure the ADD_ADDR feature:

1. Add an IP set.
2. Add an IP address of type virtual server IP (VIP) with MPTCP advertise enabled.
3. Bind the IP address with the IP set.
4. Configure IP set with the load balancing virtual server.

Add an IP set

At the command prompt, type:

add ipset <name> [-td <positive_integer>]
<!--NeedCopy-->