Happy Eyeballs v2 (and how I Was Wrong Again)

In Moving Complexity to Application Layer I discussed the idea of trying to use all addresses returned in a DNS response when trying to establish a connection with a server, concluding with “I don’t think anyone big enough to influence browser vendors is interested in reinventing this particular wheel.

I’m really glad to report I was wrong ;) This is what RFC 8305 (Happy Eyeballs v2) says:

Before attempting to connect to any of the resolved destination addresses, the client should define the order in which to start the attempts. Once the order has been defined, the client can use a simple algorithm for racing each option after a short delay (see Section 5). It is important that the ordered list involve all addresses from both families that have been received by this point, as this allows the client to get the racing effect of Happy Eyeballs for the entire list, not just the first IPv4 and first IPv6 addresses.

As the RFC was authored by engineers from Apple, I’m positive we’ll see at least some implementations in foreseeable future. Who knows what the alternative mobile platform will do; they love making people who disagree with them jump through all sorts of hoops.

4 comments:

  1. Does this mean that the browser could try to connect via IPv4 first? Well that would be a step back or turning around in a circle.
    Replies
    1. In theory, it could. The RFC states in the overview section "Note that this document assumes that the preference policy for the
      host destination address favors IPv6 over IPv4". There are more details, so you might want to read the whole RFC.
    2. Thanks for clarification. So to me there's a trade off between going to the whole list with those 2 delay timers for finding the best performing destination versus going for the first received addresses but maybe getting a bad performing destination. It will be interesting to see if the Apple consumers appreciate this approach.
  2. It was my email! XD
Add comment
Sidebar