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@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
