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

[Tom Tom]

Thank you Amos, for this explanation.


On Wed, Apr 29, 2015 at 3:02 PM, Amos Jeffries <squid3 at treenet.co.nz> 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 at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users