HttpClient connection retention, timeouts, and invalidation mechanisms for connection pooling

HTTP is a non-connected transaction protocol, the underlying use of TCP, connection pooling is a TCP connection, the purpose is to make multiple HTTP requests on a TCP connection to improve performance. At the end of each HTTP request, HttpClient will determine if the connection can be persisted, and if it can be managed by the connection manager for the next reuse, close the connection directly. Here are three questions to be addressed:

1, how to determine whether the connection can be maintained?

To stay connected, the client first needs to tell the server that it wants to maintain a long connection, which is called the keep-alive mode (also known as persistent connection, connection reuse), HTTP1.0 is off by default and requires "connection:keep-alive" to be added to the HTTP header. To enable keep-alive by default in keep-alive;http1.1, add "connection:close" before closing.

But the client set the keep-alive does not guarantee that the connection can be maintained, the situation here is more complex. To make HTTP sessions multiple times on a TCP, the key is how to tell the end of an HTTP session? EOF (-1) can be used to determine non-keep-alive mode, but the server does not automatically disconnect when keep-alive, there are two most common ways.

Using Conent-length

As the name implies, Conent-length represents the length of the entity content, and the client (server) can determine whether or not the data is received by this value. When the requested resource is a static page or picture, the server can easily know the size of the content, but what if it encounters dynamic content, or if the file is too large to send multiple times?

Using transfer-encoding

When you need to generate data on one side and send it to the client, the server needs to use transfer-encoding:chunked in place of the content-length,chunk encoding to divide the data into pieces. It is a concatenation of several chunk, ending with a chunk marked with a length of 0. Each chunk is divided into the head and the body two parts, the head content specifies the total number of characters of the body (16 binary numbers) and the number of units (generally do not write), the body part is the actual content of the specified length, separated by a carriage return line (CRLF) between the two parts. The content in the last chunk of length 0 is the content called footer, which is some additional header information.

For how to judge the length of the message entity, the actual situation is more complex, you can refer to this article: Https://zhanjindong.com/2015/05/08/http-keep-alive-header

Summarize how httpclient determines if the connection is maintained:

1. Check the Transfer-encoding field that returns the response header, if the field value exists and is not chunked, the connection is not persisted and is closed directly.
2. Check the Content-length field of the returned response header, if the field value is empty or is malformed (multiple lengths, the value is not an integer), the connection is not persisted and is closed directly.
3. Check the value of the connection field for the returned response header (or Proxy-connection field if the field does not exist):
   • If neither of these fields exists, the 1.1 version defaults to hold, and the 1.0 version defaults to the connection not being persisted and is closed directly.
   • If the field is present, the connection does not persist if the field value is close, and the connection is marked as persisted if the field value is keep-alive.

2. How long does it keep?

The hold time timer start time is the time that the connection is swapped to the connection pool. The duration calculation rule is: Gets the timeout value in the Keep-alive field in the response, or, if it exists, the timeout value *1000, in milliseconds. If not present, the connection hold time is set to-1, which is expressed as infinity.

3. How to ensure the connection is not invalid during the process of maintenance?

It's hard to guarantee. Traditionally blocking I/O models, the socket responds to I/O events only when I/O is operating. When a TCP connection is handed over to the connection manager, it may still be in a "keep-alive" state, but the socket status and response I/O events cannot be monitored. If the server closes the connection at this point, the client is not aware of the change in the state, and therefore cannot take the appropriate means to close the connection.

In response to this situation, HttpClient takes a strategy to check whether connections in the connection pool are "fresh" through a background monitoring thread, and if it expires or is idle for a certain amount of time, it is removed from the connection pool. Clientconnectionmanager provides two methods of Closeexpiredconnections and Closeidleconnections.

Reference articles

HTTP protocol header and keep-alive mode

See KeepAlive again.

Http://www.cnblogs.com/zhanjindong/p/httpclient-connection-pool.html

HttpClient connection retention, timeouts, and invalidation mechanisms for connection pooling