19

I have two Tomcat servers that need to maintain a persistent connection to cut down on SSL handshaking. One server (the proxy) sits in a DMZ while the other one is safely behind another firewall. The proxy basically just runs a simple servlet that does some sanity checking before forwarding requests over to the secure machine. On an intial request the machines exchange certificates before performing the real work. Therefore I'd like to maintain a persistent connection with a timeout of a few minutes.

To talk to the secure server, the servlet on the proxy uses HttpsUrlConnection. I've set up WireShark and I've noticed that no matter what keepAliveTimeout value I set for connector on the secure machine, the TCP connection gets closed after about 5 or 10 seconds. This number seems to match up with what I've read is the default timeout and how Java handles HTTP Keep-Alive. This link explains that Java honors the Keep-Alive timeout if it is sent by the server, otherwise it uses 5 seconds (direct connections) or 10 seconds (proxy connections) before it closes the connection.

What I'm trying to figure out is how can I force Tomcat to send the Keep-Alive header. Not, Connection: Keep-Alive, but Keep-Alive: timeout=x.

I've experimented with Apache HTTP server and modifying the keepAliveTimeout in httpd.conf does cause the Keep-Alive header to change its timeout value. Furthermore Java does honor this timeout.

UPDATE (12/23/11): After running a few more experiments I tried whipping up some quick and dirty code using Apache's HttpClient (3.1) rather than HttpsUrlConnection. It appears that HttpClient, when set to use Keep-Alive, simply waits for the server to close the connection. I don't know how long it will wait though. I'm shooting to keep the HTTP connection alive for 3 to 5 minutes.

rds
  • 26,253
  • 19
  • 107
  • 134
James Sheppard
  • 301
  • 1
  • 4
  • 15
  • "The TCP connection gets closed after about 5 or 10 seconds". By which end? The client or the server? – user207421 Dec 23 '11 at 03:21
  • It gets closed by the client. – James Sheppard Dec 23 '11 at 16:56
  • You know, the scenario you describe; WebServer in the DMZ forwarding requests to AppServers behind some firewall, is often handled with Apache HTTPD in the DMZ doing the https stuff and forwarding the requests to the Tomcat AppServers using AJP connectors (http://tomcat.apache.org/tomcat-4.0-doc/config/ajp.html). This is an alternate way to avoid the SSL overhead. – Bob Kuhar Dec 29 '11 at 23:16
  • Thanks for the comment. The reason we went with Tomcat to Tomcat is because we wanted to perform a little bit of sanity checking for requests before they made their way to the server behind the DMZ. – James Sheppard Jan 04 '12 at 22:52
  • 1
    you can maintain a persistent connection between the server behind firewall and the DMZ server using apache tomcat Connector, The secure machine can be configured as a worker in the proxy. check this for further information http://tomcat.apache.org/connectors-doc/generic_howto/workers.html – Rajesh Pantula Jan 06 '12 at 19:47
  • If you're using ajp there Read about connect_timeouts in the workers as it was mentioned above. We've faced similar problem and the timeout fixes with ajp's workers fixed it. Hope it helps. – Sergey Benner Jan 13 '12 at 10:19
  • 1
    @James you should post an answer yourself and accept it. That is a perfectly ok thing to do. It also helps keep the site tidy :) – Kevin D Jan 20 '12 at 09:12

4 Answers4

8

I was able to use HttpClient 3.1 to hold the HTTP connection open for 5 minutes by setting the keepAliveTimeout in the Tomcat connector to 300000. I verified it using WireShark that the server will terminate the connection while HttpClient will simply wait. Subsequent requests through HttpClient reuses the existing TCP connection (avoiding any further SSL handshaking). The key there though is to have a single HttpClient instance (i.e. not creating one each time). This might be obvious to most but I wasn't sure what the API mechanics for HTTPClient would be. In short, create one HttpClient instance and for each request (POST, GET, etc.) create a new PostMethod, GetMethod, etc. This will cause the TCP connection to be reused.

rds
  • 26,253
  • 19
  • 107
  • 134
James Sheppard
  • 301
  • 1
  • 4
  • 15
  • Although it reduce the number of SSL handshakes, keep in mind that this approach (holding the connection alive) can easily lead to a situation where the tomcat in the Server has run out of worker threads. So just make sure the client (the proxy server in your case) close the connection if it doesn't expect to use it anymore. – elirandav Aug 05 '19 at 13:53
6

In Tomcat I managed to set the headers in my HttpServelet using HttpServletResponse.addHeader() like this:

  response.addHeader("Connection", "Keep-Alive");
  response.addHeader("Keep-Alive", "timeout=60000");

I confirmed with WireShark that this does work with HttpUrlConnection on the client side. It does not work if you do not set the "Connection" header, so you need to set both.

Jan
  • 161
  • 1
  • 2
  • The Connection header should be set automatically by tomcat if Keep-Alive configuration is added. You are duplicating Keep-Alive from tomcat's server.xml and also your code that is returning a custom Keep-Alive header. There is a very good chance of both going out of sync and in the worst case if the application timeout was somehow longer than tomcat or tomcat itself decides to close, then the client will fail. – kisna Jul 24 '15 at 19:31
  • timeout=60000 - this means 60000 seconds – Viktor Mukhachev Apr 06 '20 at 10:07
2

Java API Http(s)UrlConnection honors seamlessly the Keep-Alive information and manage a pool of connections per server host according to the following detailed explanation (read carefully - each detail is important).

In that case, your code has to completely read buffers, close streams and read error in case of IOException.

Of course HttpClient has less constraints but the best way to handle your situation is to use its MultiThreadedHttpConnectionManager thanks to the following guidelines.

Community
  • 1
  • 1
Yves Martin
  • 10,217
  • 2
  • 38
  • 77
0

If you can upgrade the first (outer) server to Java 19 or higher, you can use this Java system property, which sets the client keep-alive time when the server doesn't specify one:

http.keepAlive.time.server=60

The default is 5 seconds. The above sets it to 1 minute. Changing it to a higher value on the client end of the connection will solve your problem (NB: only on Java 19 and higher).

Carl Hyslop
  • 41
  • 5