persistent connections not being utilized with Chrome

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

persistent connections not being utilized with Chrome

Brian J. Murrell
I am noticing that my Squid 3.5.20 installation is not utilizing
persistent connections with a Chrome browser user.  My Squid
configuration is not disabling the default status of persistent
connections being enabled.

I can see Chrome including "Proxy-Connection: keep-alive" in it's
request and Squid responding with "Connection: keep-alive" but I'm only
seeing one request being processed in each of these connections.

Looking at the network traffic, it does look like it's Squid that it
closing the socket though.  It's the first one to send a FIN packet.

Some possibilities... are persistent connections not available for
CONNECT requests?  I don't believe that to be the case but just want to
confirm.  Or perhaps are persistent connections not available for
Negotiate'd requests?

Are there any other possible reasons that Squid would close down a
socket that appears to be opened persistently?

Cheers,
b.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: persistent connections not being utilized with Chrome

Amos Jeffries
Administrator
On 13/01/18 03:52, Brian J. Murrell wrote:

> I am noticing that my Squid 3.5.20 installation is not utilizing
> persistent connections with a Chrome browser user.  My Squid
> configuration is not disabling the default status of persistent
> connections being enabled.
>
> I can see Chrome including "Proxy-Connection: keep-alive" in it's
> request and Squid responding with "Connection: keep-alive" but I'm only
> seeing one request being processed in each of these connections.
>
> Looking at the network traffic, it does look like it's Squid that it
> closing the socket though.  It's the first one to send a FIN packet.
>
> Some possibilities... are persistent connections not available for
> CONNECT requests?


What do you mean "not available for?

CONNECT can be pipelined after other requests on a persistent
connection. But since it is a tunnel nothing can be pipelined after it.



>  I don't believe that to be the case but just want to
> confirm.  Or perhaps are persistent connections not available for
> Negotiate'd requests?

None of the things that can be negotiated save keep-alive itself have
any relevance to persistence / pipelining. They all interact with it in
various ways but none outright conflict.


>
> Are there any other possible reasons that Squid would close down a
> socket that appears to be opened persistently?
>

Yes, literally everything. Connections can be terminated for any reason
- intentionally or not.

CONNECT tunnels specifically end when the server sends FIN to Squid or
any type of I/O error occurs.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: persistent connections not being utilized with Chrome

Brian J. Murrell
On Sat, 2018-01-13 at 13:15 +1300, Amos Jeffries wrote:
>
> What do you mean "not available for?

I mean, will not actually result in a persistent connection -- a socket
that is reused for multiple HTTP transactions.  I suppose for CONNECT
it would mean either multiple CONNECTs within a single socket or one
CONNECT with multiple "GET/POST" type transactions within it.

> CONNECT can be pipelined after other requests on a persistent
> connection. But since it is a tunnel nothing can be pipelined after
> it.

So, for the purposes of the WWW's current move towards all-https
websites, persistent connections (perhaps only with proxy servers?) are
becoming useless?

> CONNECT tunnels specifically end when the server sends FIN to Squid

So this seems to affirm my question above that in a world where all
websites are https, persistent connections are no more and we are back
to open-fetch-close for every single object on a webpage, yes?

The problem I am trying to solve here is that opening Chrome with, say,
a few hundred tabs open, seems to take about an hour for it to finally
fetch all of the pages while most sit spinning on "waiting for an
available socket" or "proxy tunnel", etc., for a long time, which is
probably due to Chrome's limit on the number of concurrent sockets it
will open to a single destination, including proxy servers.  I was
hoping persistent connections would reduce the socket setup/teardown
overhead of all of that.

Cheers,
b.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: persistent connections not being utilized with Chrome

Alex Rousskov
On 01/12/2018 08:23 PM, Brian J. Murrell wrote:

> I mean, will not actually result in a persistent connection -- a socket
> that is reused for multiple HTTP transactions.

It is best to think of HTTP persistency as applying to an HTTP
connection rather than a TCP connection/socket. Without a proxy, your
definition works well. With a proxy, there are several different use
cases. The one you seem to be interested in is encrypted HTTP connection
through an explicit proxy. In that case, there are two HTTP connections
in play:

  1. An HTTP connection from the client to the origin server.
  2. An HTTP connection from the client to the proxy.

Both HTTP connections use the same TCP client connection/socket (there
is also another TCP server connection socket that HTTP connection #1
also uses).

The first HTTP connection can carry lots of transactions. It can easily
be and often is "persistent".

The second HTTP connection typically carries just one HTTP transaction
(a CONNECT request followed by a 200 OK response establishing a TCP
tunnel through the proxy), but that is OK -- it does not hurt
performance because the useful transactions utilize HTTP connection #1
(which lives inside the tunnel established by the HTTP connection #2).


> I suppose for CONNECT
> it would mean either multiple CONNECTs within a single socket or one
> CONNECT with multiple "GET/POST" type transactions within it.

Authentication and other corner cases aside, there can be at most one
CONNECT request per HTTP connection, but you do not care (much) about
_that_ HTTP connection. The other HTTP connection (the one inside the
CONNECT tunnel) can carry lots of requests, and those transactions
actually deliver "pages" to your browser.


> So, for the purposes of the WWW's current move towards all-https
> websites, persistent connections (perhaps only with proxy servers?) are
> becoming useless?

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


> The problem I am trying to solve here is that opening Chrome with, say,
> a few hundred tabs open, seems to take about an hour for it to finally
> fetch all of the pages while most sit spinning on "waiting for an
> available socket" or "proxy tunnel", etc., for a long time, which is
> probably due to Chrome's limit on the number of concurrent sockets it
> will open to a single destination, including proxy servers.  

Yes, probably something like that is happening.


> I was hoping persistent connections would reduce the socket
> setup/teardown overhead of all of that.

Perhaps they do? How many requests does Chrome send inside a CONNECT
tunnel through Squid, on average? 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.

Origin server response delays rather than TCP handshakes may be your
primary bottleneck because Chrome probably does not pipeline and,
without pipelining, there can be at most one concurrent request per HTTP
connection. To improve throughput in your environment (without raising
the number of TCP connections that Chrome is allowed to open), you would
need to wait for HTTP/2 support. In HTTP/2, a single HTTP connection can
carry lots of concurrent transactions.


HTH,

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: persistent connections not being utilized with Chrome

Brian J. Murrell
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?

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

Understood.  So I do believe you are ACKing my question above.

> 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.  I think what I
want to see is those limited number of TCP-sockets better utilized.
But maybe that cannot happen without pipelining.

> Yes, probably something like that is happening.

So how do I ameliorate it?

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

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

> Origin server response delays rather than TCP handshakes may be your
> primary bottleneck because Chrome probably does not pipeline and,
> without pipelining, there can be at most one concurrent request per
> HTTP
> connection.

I think Chrome disabled pipelining a while back:

https://stackoverflow.com/questions/30477476/why-is-pipelining-disabled-in-modern-browsers

> To improve throughput in your environment (without raising
> the number of TCP connections that Chrome is allowed to open), you
> would
> need to wait for HTTP/2 support. In HTTP/2, a single HTTP connection
> can
> carry lots of concurrent transactions.

So are people without proxies suffering this same issue?  I don't think
they are because their few hundred tabs will all be much more
distributed to various servers and domains across the Internet allowing
their Chrome to open many (many!) more parallel TCP connections and
wait for them all to respond in parallel.

It's the concentration of all of those potential TCP connections
through a single host -- the proxy server -- that is greatly reducing
the parallelism of fetching lots of objects at the same time and
dragging it's wall-clock time out.

Perhaps there is no solution until HTTP/2.

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".  :-(

Cheers,
b.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: persistent connections not being utilized with Chrome

Rafael Akchurin
Hello Brian,

Sorry not to flame it all out further - but I see the same annoying "waiting for proxy tunnel" in Chrome through SSL bumping AD integrated explicit Squid.
*but* the same 200 of tabs loads just fine from FF and the same Squid on the same machine at the same time - so might be a Chrome issue/architecture?

Best regards,
Rafael Akchurin
Diladele B.V.


-----Original Message-----
From: squid-users [mailto:[hidden email]] On Behalf Of Brian J. Murrell
Sent: Monday, January 15, 2018 4:41 PM
To: [hidden email]
Subject: Re: [squid-users] persistent connections not being utilized with Chrome

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?

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

Understood.  So I do believe you are ACKing my question above.

> 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.  I think what I want to see is those limited number of TCP-sockets better utilized.
But maybe that cannot happen without pipelining.

> Yes, probably something like that is happening.

So how do I ameliorate it?

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

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

> Origin server response delays rather than TCP handshakes may be your
> primary bottleneck because Chrome probably does not pipeline and,
> without pipelining, there can be at most one concurrent request per
> HTTP connection.

I think Chrome disabled pipelining a while back:

https://stackoverflow.com/questions/30477476/why-is-pipelining-disabled-in-modern-browsers

> To improve throughput in your environment (without raising the number
> of TCP connections that Chrome is allowed to open), you would need to
> wait for HTTP/2 support. In HTTP/2, a single HTTP connection can carry
> lots of concurrent transactions.

So are people without proxies suffering this same issue?  I don't think they are because their few hundred tabs will all be much more distributed to various servers and domains across the Internet allowing their Chrome to open many (many!) more parallel TCP connections and wait for them all to respond in parallel.

It's the concentration of all of those potential TCP connections through a single host -- the proxy server -- that is greatly reducing the parallelism of fetching lots of objects at the same time and dragging it's wall-clock time out.

Perhaps there is no solution until HTTP/2.

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".  :-(

Cheers,
b.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: persistent connections not being utilized with Chrome

Brian J. Murrell
On Mon, 2018-01-15 at 16:06 +0000, Rafael Akchurin wrote:
> Hello Brian,

Hi,

> *but* the same 200 of tabs loads just fine from FF and the same Squid
> on the same machine at the same time - so might be a Chrome
> issue/architecture?

Interesting.  I'm not sure how I would do it, but it would be
interesting for sure to somehow convert my saved Chrome "session" to a
Firefox session to see if this is the case for me also.

If so, it would make a good bug report to the Chrome devs.

Cheers,
b.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: persistent connections not being utilized with Chrome

Alex Rousskov
In reply to this post by Brian J. Murrell
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.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

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

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: persistent connections not being utilized with Chrome

Amos Jeffries
Administrator
On 16/01/18 07:32, 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.
>


Yes, it is. For values of "bypassing" which includes packets going
through the proxy ... as opaque bytes being blindly relayed.

The proxy has no more relevance or interactions than your network router
to the tunneled traffic.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: persistent connections not being utilized with Chrome

Alex Rousskov
In reply to this post by Brian J. Murrell
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.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: persistent connections not being utilized with Chrome

Brian J. Murrell
On Mon, 2018-01-15 at 12:26 -0700, Alex Rousskov wrote:
>
> What about the transparent proxy part?

I already have that, but that is becoming more or less useless in the
everything-https world we are heading towards since you can't
transparently proxy https.  AFAIU.

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

I'll see if I can double-check that next time I have to restart Chrome.

Cheers,
b.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: persistent connections not being utilized with Chrome

Alex Rousskov
On 01/15/2018 12:31 PM, Brian J. Murrell wrote:
> On Mon, 2018-01-15 at 12:26 -0700, Alex Rousskov wrote:
>> What about the transparent proxy part?

> I already have that, but that is becoming more or less useless in the
> everything-https world we are heading towards since you can't
> transparently proxy https.

That statement does not compute in the current context: A transparent
proxy has many disadvantages over a forward/explicit proxy, but both
transparent and forward/explicit proxies have approximately the same
support for HTTPS. In other words, if you find a forward/explicit proxy
useful for HTTPS, then a transparent proxy can be used similarly.

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: persistent connections not being utilized with Chrome

Brian J. Murrell
On Mon, 2018-01-15 at 13:48 -0700, Alex Rousskov wrote:
>
> That statement does not compute in the current context: A transparent
> proxy has many disadvantages over a forward/explicit proxy,

Sure.  But it has advantages also.

> but both
> transparent and forward/explicit proxies have approximately the same
> support for HTTPS. In other words, if you find a forward/explicit
> proxy
> useful for HTTPS, then a transparent proxy can be used similarly.

And can be done *WITHOUT* doing a MitM attack on my users?

Cheers,
b.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: persistent connections not being utilized with Chrome

Alex Rousskov
On 01/15/2018 02:12 PM, Brian J. Murrell wrote:
> On Mon, 2018-01-15 at 13:48 -0700, Alex Rousskov wrote:
>>
>> both transparent and forward/explicit proxies have approximately the same
>> support for HTTPS. In other words, if you find a forward/explicit
>> proxy useful for HTTPS, then a transparent proxy can be used similarly.

> And can be done *WITHOUT* doing a MitM attack on my users?

The answer depends on what you want the proxy to do, but proxy abilities
rarely depend on the proxy deployment mode (transparent or
explicit/forward) in this context.

Neither transparent nor explicit/forward proxy can decrypt traffic
without MitM attacks, of course. I have interpreted your earlier
response as essentially saying that, in the "TLS Everywhere" world, you
find explicit/forward proxy useful but a transparent proxy useless.
Since both can do approximately the same things, the statement did not
compute for me.

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users