我正在参与「启航计划」

PS: 人生和代码一样,不反思、不迭代就无法获得成长。

最近接触到单双栈问题,简略梳理下,双栈与单栈,也便是 IPV4 比较,双栈客户端的应用程序会遇到明显的衔接延时,使得双栈客户端的用户体会变差,下面了解一下双栈问题以及其处理方法,首要内容如下:

  1. 双栈挑选问题
  2. IPV6无法拜访时的延时
  3. Happy Eyeballs
  4. 实际运用

双栈挑选问题

双栈挑选问题及 IPV6/IPV4 挑选问题,首见于 RFC1671 文档,IPV6(Internet Protocol version 6) 便是互联网协议第六版,IPV4(Internet Protocol version 4) 便是互联网协议第四版,IPV6 首要处理的问题是 IPV4 的地址资源日益干涸,IPv6 增强的关键是将 IP 地址空间从 32 位扩展到 128 位,从根本上完成不受约束的唯一 IP 地址,双栈挑选问题是在互联网迅速发展的大布景下呈现,当处于双栈状况下,DNS 解析出来的地址有两类地址,,单栈状况下,DNS 解析出来是 IPV4 或 IPV6 地址,当然目前提到单栈一般都是默认单栈 IPV4。

IPV6无法拜访时的延时

当 IPV6 不能拜访时,支撑 IPV6 的程序需求推迟几秒钟才干正常切换到 IPV4,这会影响用户体会,为了不影响用户体会有些体系会直接禁用 IPV6。

IPV6 不能拜访的原因如下:

Reasons for such failure include no connection to the IPv6 Internet, broken 6to4 or Teredo tunnels, and broken IPv6 peering.

下面看下 IPV6 衔接失利的流程图

IPV6、IPV4双栈问题

如上图所示,客户端域名解析获取到 IPV6、IPV4 地址,然后先请求 IPV6 未衔接成功,几秒后切换到 IPV4 衔接成功,其间 IPV6 等候衔接到衔接失利的这段时刻便是 IPV6 无法拜访时的耗时。

Happy Eyeballs

RFC6555 中定义了一种削减可见推迟的算法要求 Happy Eyeballs,其最基础的两个目标如下:

  1. 为用户供给快速衔接 IPV6 和 IPV4 的能力,即快速尝试运用 IPV6 进行衔接,如果快速衔接未成功,则切换到 IPV4 进行衔接。
  2. 防止同时衔接 IPV6 和 IPV4 而对网络造成冲击。

下面是上述思维的示意图如下:

IPV6、IPV4双栈问题

如上图所示,客户端同时经过 IPV6 和 IPV4 发送两个 TCP SYN 包,IPV6 未衔接成功,IPV4 则呼应成功,重试 IPV6 直到用户抛弃衔接 IPV6 直接切换到 IPV4 即可。

执行完上述过程后,客户端则知道 IPV6 和 IPV4 地址是否衔接成功,客户端能够把成果缓存起来,防止后续的衔接尝试中影响网络,如在上面示例中 IPV6 衔接是失利,后续衔接中能够直接切换到 IPV4 进行衔接,能够为缓存衔接成果设定一个有用期,如 10 分钟,之后可刷新衔接状况,这便是在一定程度上削减了 IPV6 衔接反常时的耗时,有助于添加用户体会。

下面是一个 IPV6 工作正常的示意图:

IPV6、IPV4双栈问题

如上图所示,客户端同时经过 IPV6 和 IPV4 发送两个 TCP SYN 包,IPV6 和 IPV4 都衔接成功,IPV6 直接衔接成功,则直接走 IPV6,疏忽 IPV4 即可,相同记录 IPV6 衔接状况,可在设定的有用期内直接 IPV6 进行衔接,

只需客户端主机是支撑双栈的,Happy Eyeballs 机制就会一向存在,只需存在仅支撑 IPV4 的服务器存在,Happy Eyeballs 就会一向存在,跟着时刻的推移,IPV4 将会逐渐退出历史舞台,Happy Eyeballs 的完成场景可能不同,但是根本遵循上述要求。

实际运用

一般应用层运用到的域名解析 API 如下:

public static InetAddress[] getAllByName(String host)

上述方法会返回域名 host 对应的 IP 地址,此时就能够根据 IP 地址是 IPV6 地址仍是 IPV4 地址进行单双栈问题的适配了,具体完成能够根据需求进行调整和完善,上面介绍的 Happy Eyeballs 首要便是在处理双栈时带来的延时问题,大型 App 应该都有自己的对应算法完成,有的甚至 DNS 这块也是自己完成的,这儿暂时了解一下。