Tag: HTTP

OneConnect & HTTP Requests

This is a copy/paste of a Q&A in devcentral. I didn’t change it as it is quite descriptive and gets the point across.

Current Setup:

We are using Cookie Insert method for session persistence. So LTM adds “BigipServer*” Cookie in the http response header with value as encoded IP address and port name. Subsequent requests from the client (in our case browser) will have this cookie in the request header and this helps LTM to send the request to same server. This LTM cookie’s expiry is set to session, so this cookie will be cleared when we close the browser or we expire it using iRule.

Use Case:

We have set of servers configured as pool members serving traffic to users who are logged in. During release time, we will release the code to new set of servers and add those servers also to the LTM pool. LTM will now have servers with both old code as well as new code. We disable all servers which has the old code so that LTM routes only the requests which already has “BigipServer*” Cookie value pointing to those servers. This will not interrupt the users who are already logged in and doing some work. All new requests (new users) will be load balanced to any of the active servers which has new code. We will ask our already logged in users to logout and login back again once they are done with the current work. We have an iRule configured to expire the LTM cookie during logout, so our expectation is that users will be connected to new servers when they are logging in again.

Problem:

Even though iRule expires the LTM cookie during logout and the cookie is not present the request header of login, users are still routed to the same disabled server when they are logging in again. Ideally, LTM should have load balanced the request to any of the active servers.

Root Cause:

Upon analyzing this further with network traffic, we found that, whenever the browser has a persistent TCP connection open with LTM after logout, browser uses that existing TCP connection for sending the login request. LTM routes this login request to the same disabled server which handled the previous request even though LTM cookie is not present in the request header. If we close the TCP connection manually after logout (using CurrPosts or some other tool), the browser establishes a new connection with LTM during login and LTM load balances this requests to any active server. One option for us is to send “Connection: close” in the response header during logout, but the browser may hold multiple persistent TCP connections (I have seen browser holding even three connections) and hence closing a single TCP connection will not help. Other option is to close the browser, but we don’t have that choice for reasons I cannot explain here (trust me).

SOLUTION:

Try using the following:

  1. OneConnect Profile in VS with netmask of /32.
  2. Action on Service Down in the Pool set to Reselect.

(1) will force the load balancing decision to be made for every HTTP request instead of the the default of lb decision being made only for the 1st HTTP request within a TCP connection.

(2) will force the HTTP Request to be sent to a new pool member when the selected member is down as the load balancing decision is made for every HTTP request instead of the very 1st HTTP request within a persistent/keep-alive connection.

Keep-alive Connection (also referred to as Persistent Connection) is used to refer to the same feature provided by HTTP1.1 where you can utilize a single TCP connection in order to send multiple HTTP requests within a single TCP connection.

 

HTTP Keepalive and Pipelining

HTTP 1.0:

With this old HTTP 1.0 version, there has to be an unique TCP connection for each HTTP Request/Response pair. This is an inefficient way to transfer content between the client and the server as resource is wasted in setting up and tearing down TCP connections at both client and the server.

 

network_1

 

HTTP 1.1 Keepalive:

HTTP Keepalive is also known as Persistent Connections. By default, any HTTP 1.1 Requests are expected to be Keepalive. This basically means, multiple HTTP Requests can be be sent within a single TCP connection between the client and the server. However, each HTTP Request must be followed by a HTTP Response before subsequent HTTP Requests are sent within the TCP Connection.

network_2

HTTP 1.1 Pipelining:

HTTP Pipelining is similar to HTTP Keepalive and is supported in HTTP 1.1 and future versions.

There can be multiple HTTP Requests within the same TCP connection between the client and the server. This is similar to the Keepalive functionality.

The main difference between Keepalive and Pipelining is that in Keepalive, each HTTP Request must be followed by a HTTP Response. In Pipelining, multiple HTTP Request can be sent without waiting for a HTTP Response.

Although, Pipelining seems like an efficient function for HTTP, it is not widely implemented in the internet world and hence, it can break functionality like that of OneConnect on F5. However, it is widely believed that with the new HTTP2.0 implementation, Pipelining will be implemented in the “real-world”.

network_3 (1)

 

An Example:

Imagine a scenario involving a client and a server. The client needs to send 3 HTTP Requests and the server must respond with 3 HTTP Responses in order to exchange the relevant content.

For HTTP1.0, this will involve setting up 1 TCP Connection for each HTTP Request-Response pair. So, we require 3 TCP Connections with an HTTP Request-Response pair per TCP Connection

For HTTP1.1, this will require 1 TCP connection for the 3 HTTP Request-Response pair resulting in a savings of 2 TCP Connections. For HTTP 1.1 Keepalive, the HTTP Request must be followed by an HTTP Response. For HTTP 1.1 Pipelining, multiple HTTP Requests can be sent without waiting for a corresponding HTTP Response from the server.

Advantages of HTTP 1.1:

  • Reduces the total number of TCP Connections.
  • Reduces latency as there is no need to set up/tear down multiple TCP connections
  • Lowers CPU & Memory utilization as there is fewer number of connections set up and torn down.

When you enter a hostname/domain in the browser, the browser opens more than 1 TCP Connection. There isn’t a well-defined limit on the number of TCP Connections that can be opened. This link provides a rough estimate of the number of TCP Connections that each browser opens: TCP Connection on Broswers

HTTP 1.0 RFC1945

HTTP 1.1 RFC2616

HTTP 2.0 Draft