将 IPv6 照进现实，我们需要做些什么？

The algorithm proceeds as follows: if a positive AAAA response (a responsewith at least one valid AAAA record) is received first, the first IPv6connection attempt is immediately started. If a positive A response is receivedfirst due to reordering, the client SHOULD wait a short time for the AAAAresponse to ensure that preference is given to IPv6 (it is common for the AAAAresponse to follow the A response by a few milliseconds). This delay will bereferred to as the "Resolution Delay". The recommended value for theResolution Delay is 50 milliseconds. If a positive AAAA response is receivedwithin the Resolution Delay period, the client immediately starts the IPv6connection attempt.

简单来说就是 RFC 建议优选 IPv6，且给 AAAA 记录的返回留50毫秒的容忍期。

由于系统的限制，这样选择逻辑的落地是客户端网络库无关的，基于网络材料来看目前各系统的具体实现：

苹果 iOS：在 v4 和 v6 双协议栈的情况下，从 ios9 开始苹果会发出 A 和 AAAA 记录的 DNS 请求，如果首先收到了 DNS 的 AAAA 记录返回，那么苹果会马上发出v6 的 syn，如果首先收到了 A 记录的返回，会有一个 25ms 的定时器，如果超时了就会发送 v4 syn，如果在这个定时器内收到 AAAA 就会发送 v6 的 syn。这个机制和 Happy Eyeball 基本一致，只是等待时长不同，苹果会不会修改到 RFC 建议值未知。

Android：优选 v6，但等待时长未知。

这样的机制从理论上就会出现由于这个等待时长造成业务体验的下降。

还有 NAT 吗，会有 PAT 吗，还有防火墙吗?

在移动网只有 IPv4 的场景下，手机用户访问服务端的整个链路中必不可少的一个中间设备就是运营商的防火墙，一方面为了应对 v4 地址稀缺的问题，设备会做公私网的地址翻译，为了更进一步的复用地址，还会做端口翻译，另一方面为了安全性考虑，设备会做一些类似 ACL 的安全策略，通常只会允许出方向的访问，同时为了降低对于设备的负荷，还会做一些超时的设置，断开那些空闲较长的连接。而这样的限制对于服务端某些过度依赖地址的应用，对于端口转换不友好的应用，对于需要长期保活的应用都会产生一定的影响，那么在 IPv4v6 双栈的场景下如何呢，我做了如下的测试：在一台有公网 IPv6 地址的服务器上简单用 python 写了一个开启80端口的服务端：

Server start at:2400:3200:1000:xx:::80

wait for connection...

在手机上执行busybox telnet 2400:3200:1000:xx:: 80 命令

这是服务端打出的日志

Connected by('2409:8928:84e:995:xxxx:xxxx:xxxx:xxxx', 34102, 0, 0)

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!