title: Reusing TCP connections with HttpsUrlConnection
body: <p><strong>Executive summary:</strong> I'm using the <code>HttpsUrlConnection</code> class in an Android app to send a number of requests, in a serial manner, over TLS. All of the requests are of the same type and are sent to the same host. At first I would get a new TCP connection for each request. I was able to fix that, but not without causing other issues on some Android versions related to the readTimeout. I'm hoping that there will be a more robust way of achieving TCP connection reuse.</p>
  <hr />
  <h1>Background</h1>
  <p>When inspecting the network traffic of the Android app I'm working on with Wireshark I observed that every request resulted in a new TCP connection being established, and a new TLS handshake being performed. This results in a fair amount of latency, especially if you're on 3G/4G where each round trip can take a relatively long time.
  I then tried the same scenario without TLS (i.e. <code>HttpUrlConnection</code>). In this case I only saw a single TCP connection being established, and then reused for subsequent requests. So the behaviour with new TCP connections being established was specific to <code>HttpsUrlConnection</code>.</p>
  <p>Here's some example code to illustrate the issue (the real code obviously has certificate validation, error handling, etc):</p>
  <pre><code>class NullHostNameVerifier implements HostnameVerifier {
      @Override   
      public boolean verify(String hostname, SSLSession session) {
          return true;
      }
  }
  
  protected void testRequest(final String uri) {
      new AsyncTask&lt;Void, Void, Void&gt;() {     
          protected void onPreExecute() {
          }
          
          protected Void doInBackground(Void... params) {
              try {                   
                  URL url = new URL(&quot;https://www.ssllabs.com/ssltest/viewMyClient.html&quot;);
              
                  try {
                      sslContext = SSLContext.getInstance(&quot;TLS&quot;);
                      sslContext.init(null,
                          new X509TrustManager[] { new X509TrustManager() {
                              @Override
                              public void checkClientTrusted( final X509Certificate[] chain, final String authType ) {
                              }
                              @Override
                              public void checkServerTrusted( final X509Certificate[] chain, final String authType ) {
                              }
                              @Override
                              public X509Certificate[] getAcceptedIssuers() {
                                  return null;
                              }
                          } },
                          new SecureRandom());
                  } catch (Exception e) {
                      
                  }
              
                  HttpsURLConnection.setDefaultHostnameVerifier(new NullHostNameVerifier());
                  HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
  
                  conn.setSSLSocketFactory(sslContext.getSocketFactory());
                  conn.setRequestMethod(&quot;GET&quot;);
                  conn.setRequestProperty(&quot;User-Agent&quot;, &quot;Android&quot;);
                      
                  // Consume the response
                  BufferedReader reader = new BufferedReader(new InputStreamReader(conn.getInputStream()));
                  String line;
                  StringBuffer response = new StringBuffer();
                  while ((line = reader.readLine()) != null) {
                      response.append(line);
                  }
                  reader.close();
                  conn.disconnect();
              } catch (Exception e) {
                  e.printStackTrace();
              }
              return null;
          }
          
          protected void onPostExecute(Void result) {
          }
      }.execute();        
  }
  </code></pre>
  <p>Note: In my real code I use POST requests, so I use both the output stream (to write the request body) and the input stream (to read the response body). But I wanted to keep the example short and simple.</p>
  <p>If I call the <code>testRequest</code> method repeatedly I end up with the following in Wireshark (abridged):</p>
  <pre><code>TCP   61047 -&gt; 443 [SYN]
  TLSv1 Client Hello
  TLSv1 Server Hello
  TLSv1 Certificate
  TLSv1 Server Key Exchange
  TLSv1 Application Data
  TCP   61050 -&gt; 443 [SYN]
  TLSv1 Client Hello
  TLSv1 Server Hello
  TLSv1 Certificate
  ... and so on, for each request ...
  </code></pre>
  <p>Whether or not I call <code>conn.disconnect</code> has no effect on the behaviour.</p>
  <p>So I initially though &quot;Ok, I'll create a pool of <code>HttpsUrlConnection</code> objects and reuse established connections when possible&quot;. No dice, unfortunately, as <code>Http(s)UrlConnection</code> instances apparently aren't meant to be reused. Indeed, reading the response data causes the output stream to be closed, and attempting to re-open the output stream triggers a <code>java.net.ProtocolException</code> with the error message <code>&quot;cannot write request body after response has been read&quot;</code>.</p>
  <p>The next thing I did was to consider the way in which setting up an <code>HttpsUrlConnection</code> differs from setting up an <code>HttpUrlConnection</code>, namely that you create an <code>SSLContext</code> and an <code>SSLSocketFactory</code>. So I decided to make both of those <code>static</code> and share them for all requests.</p>
  <p>This appeared to work fine in the sense that I got connection reuse. But there was an issue on certain Android versions where all requests except the first one would take a very long time to execute. Upon further inspection I noticed that the call to <code>getOutputStream</code> would block for an amount of time equal to the timeout set with <code>setReadTimeout</code>.</p>
  <p>My first attempt at fixing that was to add another call to <code>setReadTimeout</code> with a very small value after I'm done reading the response data, but that seemed to have no effect at all.<br>
  What I did then was set a much shorter read timeout (a couple of hundred milliseconds) and implement my own retry mechanism that attempts to read response data repeatedly until all data has been read or the originally intended timeout has been reached.<br>
  Alas, now I was getting TLS handshake timeouts on some devices. So what I did then was to add a call to <code>setReadTimeout</code> with a rather large value right before calling <code>getOutputStream</code>, and then changing the read timeout back to a couple of hundred ms before reading the response data. This actually seemed solid, and I tested it on 8 or 10 different devices, running different Android versions, and got the desired behaviour on all of them.</p>
  <p>Fast forward a couple of weeks and I decided to test my code on a Nexus 5 running the latest factory image (6.0.1 (MMB29S)). Now I'm seeing the same problem where <code>getOutputStream</code> will block for the duration of my readTimeout on every request except the first.</p>
  <p><strong>Update 1:</strong> A side-effect of all the TCP connections being established is that on some Android versions (4.1 - 4.3 IIRC) it's possible to run into a bug in the OS(?) where your process eventually runs out of file descriptors. This is not likely to happen under real-world conditions, but it can be triggered by automatic testing.</p>
  <p><strong>Update 2:</strong> The <a href="https://android.googlesource.com/platform/external/conscrypt/+/master/src/main/java/org/conscrypt/OpenSSLSocketImpl.java#1090" rel="noreferrer">OpenSSLSocketImpl class</a> has a public <code>setHandshakeTimeout</code> method that could be used to specify a handshake timeout that is separate from the readTimeout. However, since this method exists for the socket rather than the <code>HttpsUrlConnection</code> it's a bit tricky to invoke it. And even though it's possible to do so, at that point you're relying on implementation details of classes that may or may not be used as a result of opening an <code>HttpsUrlConnection</code>.</p>
  <h1>The question</h1>
  <p>It seems improbable to me that connection reuse shouldn't &quot;just work&quot;, so I'm guessing that I'm doing something wrong. Is there anyone who has managed to reliably get <code>HttpsUrlConnection</code> to reuse connections on Android and can spot whatever mistake(s) I'm making? I'd really like to avoid resorting to any 3rd party libraries unless that's completely unavoidable.<br>
  Note that whatever ideas you might think of need to work with a <code>minSdkVersion</code> of 16.</p>