I set up Apache2 with SSL and tried to request the default Apache2 web page ("It works!") using https://[IP_ADDRESS].

The Chrome developer tool shows that only one HTTP connection is established, however, from Wireshark's captured packets, there are three separate TCP streams.

The first two TCP stream finish the SSL routine, however without any application data exchanged. The last TCP stream has application data exchanged. Even more curiously, those TCP connections establish concurrently, not one by one.

The question is: Why are three separate SSL connections needed here?

3 Answers 3


When you connect to an HTTPS Web site which uses a "problematic certificate" (e.g. one which is not issued by a recognized CA, an expired certificate, or a certificate which does not contain the server name as it appears in the URL), the browser asks for confirmation from the user. This can happen only after the server certificate has been retrieved, as part of a SSL handshake. This accounts for at least one initial connection with handshake.

Keeping a SSL connection open uses up some resources on the server; so servers auto-close connections after some inactivity, and browsers try not to keep connections open for too long. Displaying the warning about the invalid certificate implies waiting for the human user to come to a decision (to click or not to click, that is the question). This will take some time; humans are slow. Therefore, the browser will first close its initial SSL connection, the one it used to obtain the server certificate -- not HTTP has occurred yet, though, only the SSL handshake. When the human user finally decides to connect despite the scary warning, the browser will open a new connection, with a new SSL handshake, and in that one there will be some HTTP (as "application data").

As for the other connection (the "initial connection" is actually two connections made in parallel): Chrome is known to open speculative connections so as to speed up subsequent requests; in general, a Web page includes images which will have to be downloaded promptly. Chrome appears to be overzealous at times. The plausible scenario is then:

  1. Chrome opens two connections with SSL handshakes.
  2. Chrome notices that the certificate is flaky, and requires human intervention. It closes the two connections without doing any HTTP within the SSL tunnels.
  3. When the user decides to open the page, Chrome opens a third connection, does a SSL handshake, and this time follows on with the HTTP dialog.

The first one is grabbing the certificate itself, the second is making a secure handshake, and the last is getting the actual data.

  • 1
    why not doing all this in a single connection?
    – PC Yin
    May 13, 2013 at 15:34
  • 1
    Your browser has to check the certificate to make sure it's valid before allowing data to be transferred.
    – Eric Zhang
    May 13, 2013 at 16:25
  • 3
    That's not three separate connections - the SSL handshake includes all three steps in a single connection. May 13, 2013 at 20:29
  • Yeah, I had assumed that there would be only one connection, but the fact is that three separate connections are established. Is there any reference?
    – PC Yin
    May 14, 2013 at 5:58

The "Predict network actions to improve page load performance" setting in Chrome has been known to create additional (initially idle) connections to the server as reported here:


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .