In NSX Data Center for vSphere 6.1.5 and later, when you enable x-forwarded-for, the HTTP connection mode changes from passive close (option httpclose) to the default HTTP server-close (option http-server-close) mode. The server-close option keeps the client-facing connection open, while the server-facing connection is closed after receiving a response from the server. Previous to NSX Data Center for vSphere 6.1.5, the Load Balancer did not close the connection proactively, but inserted the Connection:close header in both directions to indicate to the client or server to close the connection. If an HTTP/HTTPS transaction fails on the Load Balancer after upgrading to NSX Data Center for vSphere 6.1.5 or later, add an application rule with the script option httpclose and associate it with the virtual server that is no longer working.
HTTP Server Close (default) - The server-facing connection is closed after the end of the response is received, and the client-facing connection remains open. HTTP Server Close provides latency on the client side (slow network) and the fastest session reuse on the server side to save server resources. It also permits non-keepalive capable servers to be served in keep-alive from a client perspective. This mode is suitable for most common use cases, especially for slow client-facing networks and fast server-facing networks.
HTTP Keep Alive - All requests and responses are processed and connections remain open but idle between responses and new requests. The advantages are reduced latency between transactions, and less processing power required on the server side. Memory requirements will increase to accommodate the number of active sessions, which will be higher because connections are no longer closed after each request. The client-facing idle timeout can be configured using the application rule timeout http-keep-alive [time]. By default the idle timeout is 1 second. This mode is mandatory when an application requires NTLM authentication.
HTTP Tunnel - Only the first request and response are processed and a tunnel is established between the client and the server, they can talk without further analysis of HTTP protocol. After the tunnel is established, the connection is persistent on both the client and server sides. To enable this mode, none of the following options should be set: passive-close mode, server-close mode, force-close mode.
- no logs are generated
- HTTP header parsing
- HTTP header manipulation
- cookie processing
- content switching
- insertion of
X-Forwarded-Forheader
HTTP Passive Close - The same as tunnel mode, but with a Connection: close header added in both the client and server directions. Both ends close after the first request and response exchange. If option httpclose is set, the Load Balancer works in HTTP tunnel mode and checks if a Connection: close header is present in each direction. If the header is not present, a Connection: close header is added. Each end then actively closes the TCP connection after each transfer, resulting in a switch to the HTTP close mode. Any connection header other than close is removed. Applications that cannot process the second and subsequent requests properly, such as an inserted cookie by the Load Balancer then carried back by the following requests from client, can use tunnel mode or passive close mode.
Some HTTP servers do not necessarily close the connections when they receive the Connection: close set by option httpclose. If the client also does not close, the connection remains open until l the timeout expires. This causes a high number of simultaneous connections on the servers, and shows high global session times in the logs. For this reason, they are not compatible with older HTTP 1.0 browsers. If this occurs, use the option forceclose which actively closes the request connection once the server responds. Option forceclose also releases the server connection earlier because it does not have to wait for the client to acknowledge it.
HTTP Force Close - Both the client and the server connections are actively closed by the Load Balancer after the end of a response. Some HTTP servers do not necessarily close the connections when they receive the Connection: close set by option httpclose. If the client also does not close, the connection remains open until the timeout expires. This causes a high number of simultaneous connections on the servers and shows high global session times in the logs. When this happens, option forceclose actively closes the outgoing server channel when the server has finished to respond and release some resources earlier than with option httpclose.
| Version | Default Connection Mode | Connection Mode when X-Forwarded-Foris Enabled |
Available Application Rules to Switch Connection Mode |
|---|---|---|---|
| 6.0.x, 6.1.0, 6.1.1 | HTTP Server Close | The option httpclose is automatically added to the virtual server to force xff to be added to each request as specified in the HAProxy document. The xff header is added into each request from the client when dispatching to a backend server. |
No |
| 6.1.2 - 6.1.4 | HTTP Server Close | The HTTP Passive Close (option httpclose is added automatically to the virtual server) |
|
| 6.1.5 - 6.1.x 6.2.0 - 6.2.2 | HTTP Server Close | The HTTP Server Close xff header is added onto each request from the client when dispatching to the backend server. |
|
| 6.2.3-6.2.5 | HTTP Server Close | The HTTP Server Close xff header is added onto each request from the client when dispatching to the backend server. |
|
| 6.2.3-6.2.5 | HTTP Server Close | The HTTP Server Close xff header is added onto each request from the client when dispatching to the backend server. |
|
| 6.2.5 - 6.2.x | HTTP Server Close | The HTTP Server Close xff header is added onto each request from the client when dispatching to the backend server. |
|
