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

[Alex Rousskov]

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. The fact that a proxy
forwards those raw bytes is irrelevant in this context: You are not
saying "a connection from the client, through the WiFi router, through
the cat5e cable, through the Ethernet switch, through the proxy, through
the fiber optic cable, through ..., to the origin server, do you?
(Rhetorical).

If your Squid bumps the CONNECT tunnel, then Squid may interfere with
what happens on that connection, and, hence, Squid presence becomes
important. Otherwise, it is all between a browser and an origin server.
My classification is based on the classic/standard layout when Squid
does not perform a MitM attack. It is easier to understand persistency
on that level and then add exceptions for SslBump, etc. as/if needed.


>>   2. An HTTP connection from the client to the proxy.
>>
>> Both HTTP connections use the same TCP client connection/socket 


>> No, the optimization is still there as far as client-origin traffic
>> is concerned.

> Except that it is all bottle-necked through the same open-TCP-socket
> limitations that Chrome has to a single destination.  

Yes, but understanding where the bottleneck(s) are is obviously
important. There are currently two very different suspects discussed on
this thread:

* A limit on the number of TCP connections a browser can open.

* A limit on the number of raw HTTP transactions a browser can perform
for each TCP connection opened.

The HTTP persistency affects the latter but not the former. You asked
about persistency, and I tried to explain how it works in your context
so that you can distinguish between the two suspects above. It is
possible that there are two bottlenecks (i.e., removing only one of them
is not going to significantly improve your situation).


>> Yes, probably something like that is happening.
> 
> So how do I ameliorate it?

1. Configure your browser to open more TCP connections. If the current
limit is specific to using a forward proxy, consider complaining to
browser developers and using a transparent proxy.

2. If your Squid uses SslBump, investigate whether bumped HTTP
connections between the client and the origin server are needlessly
closed by Squid.

3. Check whether Chrome supports HTTP/2 proxies and, if it does,
facilitate HTTP/2 development in Squid.


>> Perhaps they do? How many requests does Chrome send inside a CONNECT
>> tunnel through Squid, on average?

> My short investigation using packet sniffing seems to indicate just
> one.

Just to double check: You only saw a single HTTP GET (or similar)
request inside most CONNECT tunnels? If yes, did the response indicate
the desire to keep the connection open? If yes, which TCP connection was
closed first and by which side? Client-Squid or Squid-origin?


>> If you bump CONNECT tunnels using
>> SslBump, then you can use Squid to measure persistency. If you do not
>> bump, then you should still be able to use Chrome developer tools to
>> measure persistency.

> Any clues about how do to do that?

I cannot detail the steps right now but others on this list might be
able to guide you. To improve your chances, you may want to specify
which of the two scenarios apply to you (and what you have tried already).


> I just find it surprising that every IT person that utilizes a proxy
> has to tell their users, "yeah, that's just how it is here in this
> network, very slow to start up your browser".  :-(

I speculate that most users do not have a few hundred browser tabs.

Alex.