Thank you Amos, for this explanation. On Wed, Apr 29, 2015 at 3:02 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > On 29/04/2015 7:38 p.m., Tom Tom wrote: >> Hi >> >> I'm running squid (3.4.12) on a IPv6/IPv4-dual-stack system. >> >> While accessing the test-site "http://test.rx.td.h.labs.apnic.net";, I >> encountered a 60s connection-timeout (configurable with >> connect_timeout) while squid is making 5 IPv6-connection-attempts >> (SYN), before it tries to connect with IPv4 (which is working on the >> test-site). I can decrease the "connect_timeout"-value to 1 second. >> This behaves in a better "surf"-experience and results in a 1s-timeout >> (also only 1 IPv6-SYN) instead of the default 60s timeout. >> >> Why does squid not tries to connect first IPv6 (based on the host's >> address preference-policy) and then - in case of a failure - switch to >> IPv4 during a 300ms timeout (like current Browsers are doing)? > > Several reasons: > > 1) The default builds and installs do try IPv6 first in accordance with > RFC 6540. Check your config for a "dns_v4_first" directive which forces > IPv4 to be tried first. According to RFC 6555: "Over time, as most content is available via IPv6, the amount of IPv4 traffic will decrease.". With forcing this directive, I reduce the chance for connecting with IPv6 and my outbound connections are probably a long time with IPv4. This is maybe not the behaviour we want? > > > 2) Squid is not the OS built-in resolver. Any obeying of that policy by > Squid is purely arbitrary. The host systems DNS resolver policy does not > supposed to affect standalone resolvers such as Squids internal one. > Particularly when there are squid.conf directives overriding the > resolv.conf behaviour (eg. dns_nameservers). > > dns_v4_first was a partial implementation added for > <http://bugs.squid-cache.org/show_bug.cgi?id=3086>. > > > 3) when performed by middleware such as Squid the "Happy Eyeballs" > algorithm is heavily destructive. > > A browser is consuming at minimum 2 network sockets to perform "Happy > Eyeballs". > > At the middlware each of those translates to potentially 3 sockets > (total 6 proxy sockets, 2 outgoing server sockets). If the middleware > were to perform "Happy Eyeballs" itself that would increase to 4 sockets > (total 8 proxy sockets, 4 outgoing server sockets). But only in the parallel way (1 x IPv6 and 1 x IPv4)? Tests with the current curl (I know, curl != squid) behaves not in doing two similar (parallel) TCP-Connections (1x SYN for IPv6 and 1x SYN for IPv4). Instead, curl tries IPv6 first and in case of an connection-error, it tries after a few milliseconds with IPv4. This way, not a lot of sockets should be consumed. Does this not behave like a native IPv4-Stack? Squid would behave like curl, if I would be able to change the connect_timeout to milliseconds. Is there a well-known restriction (which I don't now, actually), by setting the connect_timeout to 1 second for all those IPv6-Adresses, which aren't connectable and for which the IPv4-Stack should be used after 1s timeout? Is this a practicable way? > > A typical network connection travels through at least 2 sometimes 3 > proxies when CDN are involved. With each proxy hop doubling the number > of server sockets we easily reach a total of 16 inbound sockets on the > poor backend server to deal with for each single browser connection. > > Proxies and servers are already dealing with scales of 10,000 - 100,000 > clients at once. Multiplying the network resource load by a factor of 8 > would easily push the scale up into millions. Which is a little hard to > deal with when constrained to only 65535 ports per IP address. > > Of course the browsers dont care about that because they have only a few > sockets to deal with and plenty of RAM, time, and ports. For them it was > easy. > > Instead we *obey HTTP* by caching, multiplexing requests over persistent > connections, and keeping a pool of idle server connections that have > already been setup. Often that works faster than even "Happy Eyeballs" can. > > Horror story over, we do have > <http://bugs.squid-cache.org/show_bug.cgi?id=3552> though as I mention > in there we need slightly different ways that work better for proxies > than the prescribed browsers server-unfriendly algorithm. > >> >> Can I enforce a "browser behaviour" (300ms) for squid? > > Nope. The big reason for this one is that the config directive is scaled > in whole seconds along with most timeouts in Squid. > > Amos > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
