HttpsUrlConnection 和保持活动状态

Question

I am using com.sun.net.httpserver.HttpsServer in my current project which deals with client-authentification etc.. Currently it only prints out the clients address/port, so that I can check if one TCP-connection is used for multiple requests ( keep-alive ) or if a new connection is established for every request (and thus a new SSL-handshake is made every time). When I use FireFox to make multiple request against the server I can see that keep-alive is working. So the server part works fine with GET and POST-requests.

If I use HttpURLConnection to make a request against the Server (in this case using no SSL) keep-alive works, too: Only one connection is established for multiple sequentially started requests.

But if I use HttpsURLConnection (using exactly the same code, but using SSL) then keep-alive is not working anymore. So for each request a new connection is established, although I am using the same SSLContext (and SSLSocketFactory ):

// URL myUrl = ...
// SSLContext mySsl = ...
HttpsURLConnection conn = (HttpsURLConnection) myUrl.openConnection();
conn.setUseCaches(false);
conn.setSSLSocketFactory(mySsl.getSocketFactory());

conn.setRequestMethod("POST");
// send Data
// receive Data

How do I force HttpsURLConnection to use keep-alive because many requests will lead to many SSL-handshakes which is a real performance issue?

Update (2012-04-02): Instead of calling mySsl.getSocketFactory() each time, I tried to cache the SSLSocketFactory . But nothing changed. The problem still exists.

Answer 1

I ran into this exact same problem and finally have a solution after some in-depth debugging.

Http(s)UrlConnection does handle Keep-Alive by default but sockets must be in a very specific condition in order to be reused.

These are:

• Input streams must be fully consumed. You must call read on the input stream until it returns -1 and also close it.
• Settings on the underlying socket must use the exact same objects.
• You should call disconnect (yes this is counter-intuitive) on the Http(s)URLConnection when done with it.

In the above code, the problem is:

conn.setSSLSocketFactory(mySsl.getSocketFactory());

Saving the result of getSocketFactory() to a static variable during initialization and then passing that in to conn.setSSLSocketFactory should allow the socket to be reused.

Answer 2

I couldn't get it working with HttpsUrlConnection . But Apache's HTTP client handles keep-alive with SSL connections very well.

Answer 3

SSL connection establishment is really expensive either for service calls or when getting many resources from a browser.

Java Http(s)UrlConnection handles HTTP(S) Keep-Alive by default .

I have not found the source code of the default SSLSocketFactory and probably the keep-alive mechanism is implemented there. As a confirmation, disable your own SSLSocketFactory implementation for a test, with a custom trust store in javax.net.ssl.trustStore so that your self-signed certificate is accepted.

According to OpenJDK 7 ServerImpl implementation which uses ServerConfig the HttpsServer you used emits a keep-alive with 5 minutes timeout per default.

I propose you set the property sun.net.httpserver.debug to true server-side to get details.

Take care your code does not add the header Connection: close which disables keep-alive mechanism.

Answer 4

We may setup an Apache Webserver, add following directives to see whether the Apache's access.log has a keep-alive connection for the http client.

LogFormat "%k %v %h %l %u %t \"%r\" %>s %b" common
CustomLog "logs/access.log" common 

http://httpd.apache.org/docs/current/mod/mod_log_config.html

"%k" Number of keepalive requests handled on this connection. Interesting if KeepAlive is being used, so that, for example, a '1' means the first keepalive request after the initial one, '2' the second, etc...; otherwise this is always 0 (indicating the initial request).

Answer 5

I faced the same problem, and Bill Healey is right. I tested my example code below with few https libraries. HttpsURLConnection and OKHTTP are exact same behavior. Volley is a bit different when session resumption, but almost same behavior. I hope this will be some help.

public class SampleActivity extends Activity implements OnClickListener {

    // Keep default context and factory
    private SSLContext mDefaultSslContext;
    private SSLSocketFactory mDefaultSslFactory;

    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        findViewById(R.id.button_id).setOnClickListener(this);

        try {
            // Initialize context and factory
            mDefaultSslContext = SSLContext.getInstance("TLS");
            mDefaultSslContext.init(null, null, null);
            mDefaultSslFactory = mDefaultSslContext.getSocketFactory();
        } catch (NoSuchAlgorithmException | KeyManagementException e) {
            Log.e(TAG, e.getMessage(), e);
        }

    }

    @Override
    public void onClick(View v){
        SSLContext sslcontext;
        SSLSocketFactory sslfactory;

        try {
            // If using this factory, enable Keep-Alive
            sslfactory = mDefaultSslFactory;

            // If using this factory, enable session resumption (abbreviated handshake)
            sslfactory = mDefaultSslContext.getSocketFactory();

            // If using this factory, enable full handshake each time
            sslcontext = SSLContext.getInstance("TLS");
            sslcontext.init(null, null, null);
            sslfactory = sslcontext.getSocketFactory();
        } catch (NoSuchAlgorithmException | KeyManagementException e) {
            Log.e(TAG, e.getMessage(), e);
        }

        URL url = new URL("https://example.com");
        HttpsURLConnection = conn = (HttpsURLConnection) url.openConnection();
        conn.setSSLSocketFactory(sslfactory);
        conn.connect();
    }
}

Update:

Sharing SSLSocketFactory enables keep-alive. Sharing SSLContext and getting facotry each request enable session resumption. I don't know how TLS stack works, but just confirmed these connection behaviors with some mobile devices.

If you want to enable keep-alive among multiple classes, you should share the instance of SSLSocketFactory using singleton pattern.

If you want to enable session resumption, make sure the session timeout settings is long enough on server side, such as SSLSessionCacheTimeout (apache), ssl_session_timeout (nginx).

Answer 6

In addition to @Bill Healey answer the HostnameVerifier also must be declared static. I've tried several patterns with and without closing input stream and connection they make no change for me. The only thing that matters is the static declarations of mentioned properties.

/**
SSLSocketFactory and HostnameVerifier must be declared static in order to be able to use keep-alive option
*/
private static SSLSocketFactory factory = null;
private static HostnameVerifier hostnameVerifier = new HostnameVerifier() {
    @Override
    public boolean verify(String s, SSLSession sslSession) {
        return true;
    }
};
public static void prepareForCustomTrustIfNeeded(HttpsURLConnection connection) {
        try {
            if(factory == null) {
                SSLContext sslc = SSLContext.getInstance("TLS");
                sslc.init(null, customTrustedCerts, new SecureRandom());
                factory = sslc.getSocketFactory();
            }
            connection.setSSLSocketFactory(factory);
            connection.setHostnameVerifier(hostnameVerifier);
        } catch (Exception e) {
            e.printStackTrace();
        }
}

Answer 7

As far as I can understand HTTP/1.1 and HTTPS protocol, also documented here , Keep-Alive is not an end-to-end header but a hop-to-hop header. Since SSL involves multiple steps of handshaking among "different hops" (eg CA and the server) for each new connection, I think Keep-Alive may not be applicable in SSL context. So, that can be why Keep-Alive header is ignored using HTTPS connections. Based on this this question , you may need to ensure one instance of HTTP connection is used to guarantee Keep-Alive observation. Also, in the question, it seems that Apache HTTPClient has been a better solution.

Answer 8

try to add the following code:

con.setRequestProperty("Connection", "Keep-Alive");
con.setRequestProperty("Keep-Alive", "header");