PS: Life and code are alike, without reflection and iteration, growth cannot be achieved.
Recently, I came across the dual-stack problem. Let's briefly summarize the dual-stack and single-stack. Compared to IPv4, dual-stack client applications experience noticeable connection delays, which deteriorate the user experience of dual-stack clients. Let's learn about the dual-stack problem and its solutions. The main content is as follows:
- Dual-stack selection problem
- Delay when IPv6 is inaccessible
- Happy Eyeballs
- Practical application
Dual-stack selection problem#
The dual-stack selection problem and the IPv6/IPv4 selection problem were first mentioned in the RFC1671 document. IPv6 (Internet Protocol version 6) is the sixth version of the Internet Protocol, and IPv4 (Internet Protocol version 4) is the fourth version of the Internet Protocol. The main problem that IPv6 solves is the increasing depletion of IPv4 address resources. The key enhancement of IPv6 is the extension of the IP address space from 32 bits to 128 bits, fundamentally achieving unrestricted unique IP addresses. The dual-stack selection problem arises in the context of the rapid development of the Internet. In the dual-stack state, there are two types of addresses obtained from DNS resolution, while in the single-stack state, the addresses obtained from DNS resolution are either IPv4 or IPv6 addresses. Of course, currently, when we talk about single-stack, it generally refers to the default single-stack IPv4.
Delay when IPv6 is inaccessible#
When IPv6 is inaccessible, programs that support IPv6 need to delay for a few seconds to switch to IPv4 before they can connect normally. This affects the user experience, so some systems directly disable IPv6 to avoid impacting the user experience.
The reasons for IPv6 inaccessibility are as follows:
Reasons for such failure include no connection to the IPv6 Internet, broken 6to4 or Teredo tunnels, and broken IPv6 peering.
Let's take a look at the flowchart of IPv6 connection failure:
As shown in the above figure, the client resolves the domain name and obtains the IPv6 and IPv4 addresses. It first attempts to connect via IPv6, which fails, and then switches to IPv4 after a few seconds, which succeeds. The time period when IPv6 fails to connect is the delay when IPv6 is inaccessible.
Happy Eyeballs#
RFC6555 defines an algorithm called Happy Eyeballs that reduces visible delays. Its two basic goals are as follows:
- Provide users with the ability to quickly connect to both IPv6 and IPv4, that is, quickly attempt to connect using IPv6, and if the quick connection is unsuccessful, switch to IPv4 for connection.
- Avoid simultaneously connecting to both IPv6 and IPv4, which would impact the network.
The following is a schematic diagram of the above idea:
As shown in the above figure, the client sends two TCP SYN packets simultaneously via IPv6 and IPv4. IPv6 fails to connect, while IPv4 responds successfully. The client retries IPv6 until the user gives up connecting via IPv6 and directly switches to IPv4.
After completing the above process, the client knows whether the IPv6 and IPv4 addresses are successfully connected. The client can cache the result to avoid affecting the network in subsequent connection attempts. For example, in the above example, if the IPv6 connection fails, the client can directly switch to IPv4 for connection in subsequent connections. The connection result cache can be set with a validity period, such as 10 minutes, and the connection status can be refreshed afterwards. This reduces the delay when IPv6 connections are abnormal to some extent and helps improve the user experience.
The following is a schematic diagram of normal IPv6 operation:
As shown in the above figure, the client sends two TCP SYN packets simultaneously via IPv6 and IPv4. Both IPv6 and IPv4 connections are successful. If IPv6 connects successfully, it directly uses IPv6 and ignores IPv4. Similarly, the IPv6 connection status is recorded, and IPv6 can be directly used for connection within the set validity period.
As long as the client host supports dual-stack, the Happy Eyeballs mechanism will always exist. As long as there are servers that only support IPv4, Happy Eyeballs will always exist. Over time, IPv4 will gradually exit the stage of history. The implementation scenarios of Happy Eyeballs may vary, but they generally follow the above requirements.
Practical application#
The commonly used domain name resolution API in the application layer is as follows:
public static InetAddress[] getAllByName(String host)
The above method returns the IP addresses corresponding to the domain name host. At this point, you can adapt to the single-stack and dual-stack problems based on whether the IP address is an IPv6 address or an IPv4 address. The specific implementation can be adjusted and improved according to requirements. The Happy Eyeballs mentioned above mainly solves the delay problem caused by dual-stack. Large-scale apps should have their own corresponding algorithm implementations, and some even implement the DNS part themselves. Let's learn about it here.