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

[Brian J. Murrell]

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 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?

No.  Of course I don't name every component which is common to most/all
cases.  But a proxy server is not always in the path so it is worth
spelling out if you do actually mean a connection through the proxy. 
Because as I said above, for most people, there is no proxy involved
and so "client to the origin server" could very well mean a single
socket directly between the two.

It is also important to specify because it implies multiple TCP
connection between the client and the origin server and not just one
and it also implies a single, common IP address to which the browser
connects to get to the origin server, not the origin server's IP
address.  These are all very important factors in this situation.

> If your Squid bumps the CONNECT tunnel,

It does not.

> 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.

Except that it's not.  At the TCP socket level it's between the browser
and the proxy server and this is an important factor.

> 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.

Chrome has a fixed (unconfigurable) limit on the number of connections
it will open to a server and I don't believe it provides for any
distinction whether that server is an origin server or a proxy server. 
If I am wrong about this latter aspect, then much of this goes out the
window.

This limitation is what is important here.  Because in a non-proxied
world, the browser can hit this maximum many many times over, once for
each origin server.  But in a proxied world, it can only hit this
maximum once, for the proxy server.  For 10 tabs, open to 10 different
websites, this can mean that without a proxy, it can open 60
connections, vastly parallelizing the fetching of those pages.  But
when a proxy is involved it is limited to opening 6 connections and
trying to fetch all of those pages through those 6 instead of the 60 it
can use without a proxy.

> 1. Configure your browser to open more TCP connections.

I don't believe that is possible with Chrome.

> 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.

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

I cannot look inside CONNECT tunnels.  I don't MitM my users' SSL
connections.  But I did see only one CONNECT per TCP connection to the
proxy server from the Chrome browser.

> If yes, did the response indicate
> the desire to keep the connection open?

Yes.

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

Squid closed the connection to origin first.

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

Perhaps that is the case.

b.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20180115/718cc488/attachment.sig>