1

I am testing a Jetty embedded server (similar to jersey-http2-jetty-bundle) called by a Jersey HTTP/1.1 (HttpURLConnection) client on two different servers.

  1. Linux amss1 4.9.125-linuxkit #1 SMP Fri Sep 7 08:20:28 UTC 2018 x86_64 GNU/Linux
  2. Linux amss2 3.10.0-957.el7.x86_64 #1 SMP Thu Oct 4 20:48:51 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

On the first one, the TCP connection is persistent, i.e. it is reused for several calls and on the second one the TCP connection is directly closed.

Is there a configuration at OS level that can change the TCP persistent behavior so that the second server is re-using TCP connection?

I'm checking if the TCP connection is kept with netstat -anp | grep java | grep 'otherServerIp' from client and server side.

The following configuration is defined on the second server.

$ grep 'net.ipv4.tcp_keepaliv' /etc/sysctl.conf
net.ipv4.tcp_keepalive_time=600

tcpdump on the second server. tcpdump

Nicolas Henneaux
  • 11,507
  • 11
  • 57
  • 82
  • 3
    TCP keepalive is completely unrelated to HTTP persistent connections (i.e. one TCP connection for multiple HTTP requests). HTTP persistent connections are solely implemented at the application layer and needs to be supported and enabled by both HTTP server and HTTP client. – Steffen Ullrich Feb 19 '19 at 13:32
  • @SteffenUllrich I agree but still there is something not working while both application are the same and only the underlying system is different. So what needs to be configured on the second system so that the TCP connection are reused? – Nicolas Henneaux Feb 19 '19 at 13:35
  • 2
    Configuration is done at the application level not the system level. Apart from that - the packet capture shows for me clearly a persistent connection: it shows a TLS connections with application data flowing alternating in both direction, which is the typical pattern for multiple HTTP request + response over the same connection. Then after 30 seconds of inactivity the server closes the persistent connection. – Steffen Ullrich Feb 19 '19 at 13:43
  • Good catch I haven't noticed the connection was closed after 30s. what could cause the `Encrypted alert` that seems to cause the close of the connection ? – Nicolas Henneaux Feb 19 '19 at 13:46
  • 2
    The encrypted alert is just a TLS-level message saying that the session is ending. There's a separate TCP close message because TLS and TCP are separate protocols; TLS works on top of TCP. The reason the connection closes is that your server is configured to close idle connections after 30 seconds. That's actually a pretty long time to wait. If a client is making a request every 29 seconds, that client doesn't really need to reuse a connection. HTTP keepalives are intended to enable a client to send a burst of requests (e.g., load all the images on a page) without creating lots of connections. – Willis Blackburn Feb 19 '19 at 13:51
  • 1
    "HTTP keepalives" is a HTTP/1.0 only concept. If he's using HTTP/1.1 persistence connections is default unless either the server or client specifies a "Connection: close" header. – Joakim Erdfelt Feb 21 '19 at 19:55
  • [Linux Kernel 3.10 was EOL (End of Life) back in Nov 2017](https://lkml.org/lkml/2017/11/4/178). There's really nobody making changes in the JVM to support that old of a Linux kernel anymore. – Joakim Erdfelt Feb 21 '19 at 19:58
  • Kernel is indeed quite old. However it is the latest for rhel7 so I suppose jvm developers are still taking into account such version? – Nicolas Henneaux Feb 22 '19 at 06:59

0 Answers0