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