[squid-users] Happy Eyeballs and "connect_timeout" in squid 3.4.12

[Amos Jeffries]

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