商业转载请联系腾讯 WeTest 获得授权，非商业转载请注明出处。
原文链接：http://wetest.qq.com/lab/view/300.html

WeTest 导读

WWDC2015 苹果宣布在 ios9 支持纯 IPv6 的网络服务，并且要求 2016 年提交到 app store 的应用必须兼容纯 IPv6 的网络，要求适配的系统版本是 ios9 以上（包括 ios9）。

---

一、背景介绍

1、你了解 IPv6 吗？

IPv6 是 Internet Protocol Version 6 的缩写，简单的概括 IPv6 就是现行的互联网协议（IPV4）的下一代 IP 协议。IPv6 由 128 位二进制数组成，可提供庞大的 IP 地址资源，足以让地球上每个生物乃至每厘米都能被分配到一个或多个 IP 地址。将这 128 位的地址按每 16 位划分为一个段，将每个段转换成十六进制数字，并用冒号隔开。

IPv4 地址示例：192.168.191.1
IPv6 地址示例：2001:0db8:85a3:08d3:1319:8a2e:0370:7344

2、为什么要接入 IPv6？

目前互联网广泛应用的 IPv4 技术，理论上 IPv4 是一个 32 位的二进制数的地址，可编址 1600 万个网络、40 亿台主机。但在采用了 A、B、C 三类编址方式后，可用的网络地址和主机地址数目大打折扣，欧美资本主义列强掌握着核心技术，留给我国的就更少了。

二、改造方案

要想使应用完全支持 IPV6 的环境要做的太多了，从协议到硬件，要做一次彻底的大调整。不但客户端要做 ipv6 的改造，服务器也要适配 ipv6.主要有一下四种对应关系，必须做好以下每一种。

IPv4 -> IPv4

IPv4 -> IPv6

IPv6 -> IPv4

IPv6 -> IPv6

要做到 IPv6 和 IPv4 完全兼容需要做很大的修改，最简单的协议上要兼容 128 位的 IP 地址，路由器，服务器等相关硬件也要升级。应苹果公司的要求，本次改造我们只关注客户端从 IPv6 的网络环境访问 IPv4 的资源。那么问题来了，现在我们大部分后台服务器都是使用 IPv4 接入的，我们要如何做兼容？幸好，从一开始设计 IPv6 就考虑到了向后兼容的问题，运营商会提供一个中间节点，使用 DNS64/NAT64 等技术，负责协议的转换，打通 IPv6 和 IPv4 之间的链路。(IPv6 和 IPv4 互通技术有很多，这里只讨论 apple 要求的技术方案 DNS64/NAT64) 我们要走的服务器必须支持 nat/nat64 的环境，搭建的 wifi 环境本来就支持了，我们不改上层的，只改底层的是影响最小。

1、NAT64 与 DNS64 技术

NAT64 是一种有状态的网络地址与协议转换技术，一般只支持通过 IPv6 网络侧用户发起连接访问 IPv4 侧网络资源。但 NAT64 也支持通过手工配置静态映射关系，实现 IPv4 网络主动发起连接访问 IPv6 网络。NAT64 可实现 TCP、UDP、ICMP 协议下的 IPv6 与 IPv4 网络地址和协议转换。

DNS64 则主要是配合 NAT64 工作，主要是将 DNS 查询信息中的 A 记录（IPv4 地址）合成到 AAAA 记录（IPv6 地址）中，返回合成的 AAAA 记录用户给 IPv6 侧用户。DNS64 也解决了 NAT-PT 中的 DNS-ALG 存在的缺陷。NAT64 一般与 DNS64 协同工作，而不需要在 IPv6 客户端或 IPv4 服务器端做任何修改。NAT64 解决了 NAT-PT 中的大部分缺陷，同时配合 DNS64 的协同工作，无需像 NAT-PT 中的 DNS-ALG 等。

2、举个栗子

这里大概描述一下 NAT64 的工作流程。

（1）IPv6 主机发起 www.ipv6bbs.cn 的 AAAA 域名解析到 DNS64(主机配置的 DNS 地址是 DNS64)

（2）DNS64 触发 AAAA 到 DNS AAAA 中查询;

（3）DNS AAAA 返回 NULL 的信息到 DNS64;

（4）DNS64 然后触发 A 的申请到 DNS A 中查询;

（5）DNS A 返回 www.ipv6bbs.cn 的 A 记录 (11.111.11.11);

（6）DNS64 合成 IPv6 地址 (64:ff9b: 11.111.11.11)，返回 AAAA response 给 IPv6 主机;

（7）IPv6 主机发起目的地址为 64:ff9b: 11.111.11.11 的 IPv6 数据包;由于 NAT64 在 IPv6 域内通告配置的 IPv6 Prefix，因此这个数据包转发到 NAT64 设备上;

（8）NAT64 执行地址转换和协议转换，目的地址转换为 192.0.2.1，源地址根据地址状态转换 (64:ff9b: 11.111.11.11,1500)->( 11.111.11.11,2000);在 IPv4 域内路由到 IPv4 server;

（9）数据包返回，目的地址和端口为 11.111.11.11,2000;

（10）NAT64 根据已有记录进行转换，目的地址转换为 2001:db8::1,源地址为加了 IPv6 前缀的 IPv4 server 地址 64:ff9b: 11.111.11.11，发送到 IPv6 主机;

按照 NAT64 的规则，客户端如果没有做 DNS 域名解析的话（微信依赖的是自己实现的 NEWDNS），客户端就需要完成 DNS64 的工作。这里的关键点是，发现网络是 IPv6-only 的 NAT64 网络的情况下，我们可以自己补充上前缀 64:ff9b::/96，然后进行正常的访问。然而这里客户端能获取的信息量一般都是很有限的。

注：AAAA 记录 (AAAA record) 是用来将域名解析到 IPv6 地址的 DNS 记录。用户可以将一个域名解析到 IPv6 地址上，也可以将子域名解析到 IPv6 地址上。

3、开发同学干了什么？

Xplaform 改造的要点主要有一下 4 个：

a.换用兼容 IPv4 及 IPv6 的 API，例如:getaddrinfo,yaoli 同学在测试过程中发现，ios9 系统在 IPv6-only 的环境下，返回会的地址信息结构体中 port 为 0，所以这里需要重新赋值端口号再进行联网。

b.判断当前客户端是处于 IPv4-only、IPv6-only 还是 IPv4 和 IPv6 并存的环境，然后分别使用不同的网络 API，可以参考http://km.oa.com/articles/show/270667。

c.SCNetworkReachabilityCreateWithAddress 这个方法最好使用探测域名的方式。如果参数填的是 0.0.0.0，苹果文档说明这返回的结果不保证能真正出外网。这样就需要其它辅助的手段尝试是否能出外网了。

d.使用 socket 及 connect 进行的联网操作。

三、客户端兼容性测试办法

1、测试环境搭建

后台不用改，那客户端要改如何兼容。我们可以先用苹果给的测试工具，简单测试。整体原理如下：

其中，在客户端的改造叫做 Xplaform，需要连接 mac 机创建的 NAT64/DNS64 的 wifi，就是传说中的 IPV6 的网络环境，再通过有线网络，路由器，访问到 IPv4 的资源。就做到 IPv6→IPv4 的连接。

下面讲解一下 IPv6wifi 网络环境的搭建。

（1）工具/准备

体验网有线接口、iMAC(10.11 以上的系统) 和 iOS9（包括 iOS9）以上设备

（2）步骤

接好体验网的网线，然后打开系统设置找到 Sharing 图标，如下：

点击进入，然后按住 option 按键同时用鼠标点击下图的 “internet-Sharing”。

这时可以看到下方出现了 “Create NAT64 Network” 可选菜单，把这个选上，如下图：

之后用手机连上这个共享的 wifi 热点，测试对应的网络功能即可。

测试重点：

1、 IPV4 和 IPV6 网络环境判断是否正确

2、 UDP 和 TCP 的切换是否正确

3、 数据线和音视频的基本功能

四、经典 bug 分享

【bug 描述】移动 4G 下无法传文件。

在移动网络下无法查看电脑和进入 wifiphoto，传文件，问题出现的初期我们马上切换到 wifi 下，发现 wifi 下是可以的，把 sim 卡换成联通的，也可以。唯独移动的网络下无法传文件。初步断定是对网络的兼容性问题。

【问题排查】

1、 查看 socket 日志，发现在 connection 一直失败。在建立连接阶段一直失败。我们做该需求的目的在于要增加 IPV6 的客户端能通过 IPV6 的网络访问到 IPV4 的资源。因此，在做 IPV6 的改造中我们做了一个判断逻辑，判断当前网络环境是 IPV4 or IPV6。

2、加日志验证，我们把 socket 绑定的 ip 地址类型打出来，果然：

在移动数据网络下走了 ipv6 的通道。可是各大运营商的网络应该走的是 ipv4 才对。

3、review 代码。问题就很明显了，我们梳理了一下选择 ipv6 或者 ipv4 协议栈的判断逻辑，原来开发判断到网关是 IPv6 的网关之后就不再往下判断，直接建立连接。然而，我们连接上 4G 网络环境的时候，移动基站分发的网关是一个 ipv6 形式网关，它可以兼容 ipv6 和 ipv4 两种 ip（开发同学认为是移动公司兼容 ipv6 的策略，看来移动公司已经走在我们前面了）。

【解决办法】

我们更改了 IPv6 和 IPv4 协议栈的判断逻辑：

1、探测环境

我们的探测环境的方法是：先创建一个 ipv6 的 socket 去连 ipv6 的地址，如果当前网络不是 ipv6 的环境，返回路由不可达。关键点，因为 tcp 是异步的需要三次握手，所以我们使用 udp 来完成这个过程。

2、继续判断网关语法是否是 IPv6 格式，

3、最后获取 DNS 地址，以上都符合 IPv6 的语法，即为 IPv6 的网络，建立 socket 走 IPv6.

4、如果当前网络是 IPv6 的环境，我们就对 IP 进行兼容性改造 IPv6 = 64:ff9b::/96+IPv4。再通过改造后的 IP 地址建立 socket 连接。

5、如果 IPv6 和 IPv4 都可以走通，我们优先建立 IPv4 的连接。

【结果检查】

打印出建立连接的日志：

从日志可以看出，手机连接 4G 之后得到的是 IPv4 的地址和 IPv6 格式的网关。

创建 socket 时，IPv6 失败，走 IPv4 的网。

【经验总结】

逻辑和场景是测试的两个纬度，二者都要兼顾到。

---

【腾讯 WeTest iOS 预审工具】

为了提高 IEG 苹果审核通过率，腾讯专门成立了苹果审核测试团队，打造出 iOS 预审工具这款产品。经过 1 年半的内部运营，腾讯内部应用的 iOS 审核通过率从平均 35% 提升到 90%+。

现将腾讯内部产品的过审经验，以线上工具的形式共享给各位。在 WeTest 腾讯质量开放平台上可以在线使用。点击http://wetest.qq.com/product/ios即可立即体验！

如果使用当中有任何疑问，欢迎联系腾讯 WeTest 企业 QQ：800024531

---

iOS 预审工具分四步进行预审服务

【一键扫描】只需提供 ipa 包、审核图片、审核视频、应用描述，即可在 4 小时内拿到一份完整的检测报告，定位问题的同时提供解决方案，助您成功通过审核。

【案例分享】集结 iOS 审核失败常见原因，丰富案例为您提供参考依据。

【专家服务】腾讯专家团队为您分析各种疑难杂症，提出最优解决方案。

【ASO 优化】专业优化 AppStore 内关键字搜索结果，让产品离用户更近一步。希望 App/手游在预审验收保证下，都可以快快乐乐过审，开开心心赚钱。，开开心心赚钱。