Comment by matja
21 hours ago
Depends on the application, a web-browser that implements Happy Eyeballs protocol may prefer IPv4 if the IPv6 latency is higher.
21 hours ago
Depends on the application, a web-browser that implements Happy Eyeballs protocol may prefer IPv4 if the IPv6 latency is higher.
I know little of this. How/why could one be higher latency over the other?
Different paths. If you’ve got a “dual stack” on your computer, give it a try.
tracert -4 google.com
tracert -6 google.com
I do get very different hops and latency.
However for “happy eyeballs” algo to fallback to IPv4, latency needs to be very bad on IPv6.
(I work on performance tuning a browsers happy eyeballs implementation)
Especially for DNS, browsers don’t wait “very long” for the AAAA (v6) record to be resolved when they already have the A record (v4) and will start the v4 connection after at max 50ms (iirc thats the spec value, but imo it is too long and most browsers wait less I think).
The good news is that if the AAAA still arrives later it will be cached, thus this only affects the first connection to a site.
As for the actual v6 connection being slower (lets say both A and AAAA come from cache) the browser will start a v6 connection and only fall back to v4 if the connection isn’t established within some time (I think the spec says 250ms).
And to make this all more complicated HTTP1/2/3 enter the decision matrix. I.e. should the browser rather try v4/http3 than v6/http2? Opinions probably differ.
All of this is also on the critical path to a website loading for the user, thats why all of those waits cannot be too long. At some point the benefit of the better protocol will be outweighed by waiting. Even worse if the website doesn’t support v6 and the wait was for nothing.
Happy eyeballs is more to fix totally broke ipv6 than speed differential.
For many years and even how there are networks that advertise they can do ipv6 and hand out real addresses but nothing works.