771220 - Open an extra TCP connection to server when initially requesting a page

Status: RESOLVED DUPLICATE of bug 634278

(Core :: Networking: HTTP, defect)

Description

[Kartikaya Gupta (email:[e-mail])]

Attachment: pcap file from loading a simple test page on opera mobile (Galaxy Nexus, Android 4.0)

I was running tcpdump to look at what different browsers do on Android when fetching a simple page. I noticed that Opera seems to open two TCP connections to the server right away even though it only uses one to make the initial HTTP GET request. (See the first two TCP connections in the attached pcap file). The second connection is just left open and eventually closed if it is not used. I'm not sure why it does this (it might be a bug for all I know) but it seems like a good idea for a couple of reasons:

1) If we are requesting a large page with many secondary resources (which is true most of the time) then we're going to want that second TCP connection anyway (or ever more, up to the max-connections-per-server limit). Opening it up ahead of time gets the latency of the 3-way handshake out of the way, so that as soon as we have additional resources we want to fetch, the socket is ready to make those requests.

2) On wireless networks the risk of packet loss is greater. In the case that one of the SYN packets is lost and the corresponding TCP connection hits a resend timeout, the other TCP connection will still be properly set up and can be used to make the initial request. This basically uses multiple TCP connections as a hedge against packet loss. I have a pcap file that caught the current behaviour in this scenario - the initial SYN was lost and we waited 3 seconds before re-sending the SYN packet. Those 3 seconds could have been saved if we could have fallen back to a second TCP connection that succeeded.

Comment 1

[Honza Bambas (:mayhemer)]

ad 2) we are opening a secondary connection when we don't get SYN/ACK for the first connection in 250 ms.

Your suggestion will be (or already is) included in a more general bug on preconnection logic (I don't have a number by hand right now).

Comment 2

[Kartikaya Gupta (email:[e-mail])]

Ah, ok, that makes sense. I did see a second connection get opened in the tcpdump where I saw the 3 second delay, but the second connection also suffered from a lost SYN packet and so didn't do anything.

Feel free to dupe this bug into the more general one if you find the bug number.