A site with both AAAA and A DNS records may only be available via one of
the IP address families; attempts to connect to that site over the other
IP family will fail, sometimes after painful timeouts. Prior to these
changes, Squid tried to connect to resolved addresses sequentially,
which often resulted in unhappy user eyeballs and aborted (by clients)
client-Squid connections, especially when the first DNS answer contained
multiple unusable IP addresses.
To reduce user-visible delays, Squid now follows the Happy Eyeballs (RFC
8305) strategy: Start opening a to-server TCP connection using IPvX and,
if that "primary" connection was not established fast enough, initiate a
parallel "spare" connection opening attempt using IPvY. As before, X is
the IP protocol family in the first/fastest DNS response received by
Squid. As more IP addresses (from each family) become known, they feed
subsequent connection opening attempts on primary and spare tracks.
No changes in peer selection. No changes in peer usage: Squid still
exhausts all paths to peer[N] before using peer[N+1] IPs, even if it
means waiting for DNS A answer for peer[N] while sitting on an AAAA
answer for peer[N+1].
Happy Eyeballs implementations must balance the desire to improve
response times (by opening as many parallel connections as fast as
possible) with the dangers of triggering DoS alarms and creating
significant traffic overheads. To control that balance, Squid never uses
more than two parallel tracks for forwarding a single request and
provides three admin-configurable parameters (with reasonable defaults).
* happy_eyeballs_connect_timeout forces spare connection establishment
track to wait a little (to give the primary track a chance to
establish a connection).