[squid-users] persistent connections not being utilized with Chrome

[Alex Rousskov]

On 01/15/2018 11:32 AM, Brian J. Murrell wrote:
> On Mon, 2018-01-15 at 10:56 -0700, Alex Rousskov wrote:
>> On 01/15/2018 08:40 AM, Brian J. Murrell wrote:
>>> On Fri, 2018-01-12 at 21:34 -0700, Alex Rousskov wrote:
>>>> In that case, there are two HTTP connections in play:
>>>>
>>>>   1. An HTTP connection from the client to the origin 
>>>> server.

>>> By this do you mean to say there is a connection from the client,
>>> through the proxy server to the origin server?

>> No, I do not mean to say that. From HTTP point of view, that first
>> HTTP connection is from client to the origin server.

> Well, to my reading, to omit the clarification that the connection is
> through the proxy server means that the connection is directly from the
> client to origin server, bypassing the proxy server.

The HTTP connection bypasses the proxy server indeed (via a TCP tunnel).
The TCP connectionS do not bypass, but my list was about HTTP, not TCP.


> ...  These are all very important factors in this situation.

Indeed they are! They are irrelevant for HTTP persistency point of view
though, and that is the (part of your) question I was trying to answer.
If we keep mixing TCP and HTTP together, it would be difficult to
understand what is happening and what should be happening.


>> If your Squid bumps the CONNECT tunnel,

> It does not.

Great, it simplifies things a lot.


>> If the
>> current
>> limit is specific to using a forward proxy, consider complaining to
>> browser developers and using a transparent proxy.

> Not a viable solution.  Yes, I could complain, but my users don't
> really care that I have complained.  They are still stuck with massive
> browser startup times.

What about the transparent proxy part? Besides solving a specific
problem, it might also motivate the Chrome crew (that must hate
transparent proxies as much most of us do) to fix the alleged problem of
equating next TCP hop address with the origin server address for the
purpose of counting outgoing connections.


>> Just to double check: You only saw a single HTTP GET (or similar)
>> request inside most CONNECT tunnels?

> I cannot look inside CONNECT tunnels. 

You can -- built-in browser "developer tools" should tell you what TCP
connection the browser is using for every HTTP request.


> I did see only one CONNECT per TCP connection to the
> proxy server from the Chrome browser.

There can be at most one (successful) CONNECT per TCP connection. If N
browser tabs go to N different secure origin servers, then Chrome would
have to open N different TCP connections to the proxy. However, if
Chrome has to contact the same origin server many times, then Chrome can
and should reuse the same CONNECT tunnel where HTTP persistency rules
allow for HTTP connection reuse.


>> If yes, which TCP connection was
>> closed first and by which side? Client-Squid or Squid-origin?

> Squid closed the connection to origin first.

Outside the SslBump world, and perhaps with some (long) I/O timeouts
aside, if Squid closed a CONNECT tunnel _first_, then there is a Squid
bug: Under normal circumstances, Squid should only close a successfully
established CONNECT tunnel if the client or origin server close their
end first.


HTH,

Alex.