We are upgrading this site on Friday 5 March commencing at 17:00 UTC and running until 20:00 UTC. During the maintenance window there will be several reboots and service interruptions so we strongly recommend that you don’t attempt to use the site during the maintenance window.
Page tree
Skip to end of metadata
Go to start of metadata

Happy Eyeballs

The idea of Happy eyeballs was first introduced as improvement to the responsiveness of the dual-stack applications (both IPv4 and IPv6).

The problem

The behavior happy eyeballs is trying to improve is generated by how the TCP handshake protocol works.

Before establishing a connection and after sending a syn packet, TCP waits a syn-ack packet from the counterpart.

He main issue here is that if the syn-ack gets lost or is not sent at all, TCP keeps waiting slowing down all applications that are related to that connection.

The introduction of the dual stack environment, which deals with both IPv4 and IPv6 addresses, has made this performance issue worse.

In a dual stack connection model, an IPv6 (or IPv4) syn will first be sent. TCP then waits for the syn-ack. Only when TCP is sure that this tentative of connection has failed will send the IPv4 (or IPv6) syn. …and wait….

There is clearly too much “waiting time”!

Happy eyeballs algorithm

Referring to the web browser, what happy eyeballs does is introducing a different TCP behavior after a response to the DNS query is received.

Both IPv6 and IPv4 syn packets are sent off at the same time, the first syn-ack that reaches the source will determined the protocol used and the other one will be discarded.

Possible extension

At the moment happy eyeballs relates to the web browser. A possible logical extension would be implementing the algorithm in other applications.


RFC 6555

[ Geoff Huston keynote speech at NORDUnet 2012|https://events.nordu.net/pages/viewpage.action?pageId=2294038]

– Main.AlessandraScicchitano - 2013-05-16

  • No labels