search

Fyrd / caniuse

Raw browser/feature support data from caniuse.com
https://caniuse.com
Creative Commons Attribution 4.0 International
5.61k stars 1.38k forks source link

RFC8305 ("happy eyeballs v2") support #7143

Open anarcat opened 1 week ago

anarcat commented 1 week ago

RFC8305 (" Happy Eyeballs Version 2: Better Connectivity Using Concurrency"):

Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555.

Basically, this is the capability of browsers to fallback quickly and elegantly between different A and AAAA records when one is unavailable. According to this post, "major browsers are supporting the Happy Eyeballs for a long time already" (2020), but:

AS of December 2020. YES, HE v1 was implemented long ago BUT I was writing about HE v2 wich was approved in December 2017. One year ago in the end of 2019 HE v2 wasn't implemented in Chrome. But now it works. HE v2 means that a server IP with the nearest ping will be chosen for connection. If IP is down next server will be tried. Under IP I mean IPv6 and IPv4 with IPv6 priority. I made some experiments and I can confirm that at least modern Chrome, Firefox and Opera always choose a server with nearest ping. In the end of 2019 Chrome chose random IP address

Wikipedia's Happy Eyeballs page says Chrome, Opera 12.10 and Firefox 13 support it, but doesn't cite references or specify whether it's v1 or v2.

anarcat commented 1 week ago

digging around this, i couldn't find anything about this in chromestatus.com (not sure what that means) and very few instances in mozilla's source (https://searchfox.org/mozilla-central/search?q=happy+eyeballs&path=&case=false&regexp=false)...

in particular, their docs do mention RFC8305, but say they "implement it differently" linkining to this comment: https://searchfox.org/mozilla-central/rev/23e7e940337d0e0b29aabe0080e4992d3860c940/netwerk/protocol/http/DnsAndConnectSocket.cpp#202-206

... which is basically just an IPv6 fallback, far from a full RFC8305 implementation.

(update: technically, it disables the IPv6 fallback, but my point here is more that it doesn't show any sort of IPv4 fallback...)

so my first guess here is that this is not actually properly implemented and i can't have nice things.