Re: [squid-users] persistent connections not being utilized with Chrome
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 squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] persistent connections not being utilized with Chrome
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. signature.asc Description: This is a digitally signed message part ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] persistent connections not being utilized with Chrome
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 squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] persistent connections not being utilized with Chrome
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. signature.asc Description: This is a digitally signed message part ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] persistent connections not being utilized with Chrome
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 squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] persistent connections not being utilized with Chrome
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 squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] persistent connections not being utilized with Chrome
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. signature.asc Description: This is a digitally signed message part ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] persistent connections not being utilized with Chrome
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 squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] persistent connections not being utilized with Chrome
On Mon, 2018-01-15 at 16:06 +, 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. signature.asc Description: This is a digitally signed message part ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] persistent connections not being utilized with Chrome
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:squid-users-boun...@lists.squid-cache.org] On Behalf Of Brian J. Murrell Sent: Monday, January 15, 2018 4:41 PM To: squid-users@lists.squid-cache.org 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 squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
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. signature.asc Description: This is a digitally signed message part ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] persistent connections not being utilized with Chrome
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 squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] persistent connections not being utilized with Chrome
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. signature.asc Description: This is a digitally signed message part ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] persistent connections not being utilized with Chrome
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 squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
