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