作者：IPv6 项目组

IPv6 是互联网升级演进的必然趋势，我国主流 APP 也正式进入到 IPv4 和 IPv6 的双栈时代。本文将从 APP 及云产品的角度，和大家分享一下我们在这个过程中的经验积累，为进一步推动 IPv6 规模化部署提供参考。

一、前言

细心的人可能已经发现，我们在首次打开淘宝、天猫、支付宝以及国内主流 APP 的时候，都能看到“IPv6”的标示，这个“IPv6”意味着我国主流 APP 正式进入到 IPv4 和 IPv6 的双栈时代。本文将从 APP 及云产品的角度，和大家分享一下我们在这个过程中的经验积累，为进一步推动 IPv6 规模化部署提供参考。在正式介绍经验之前我们先简单介绍一下 IPv6 的一些基本信息。

1.1 什么是 IPv6？

IPv6 是 Internet Protocol Version 6 的缩写，其中 Internet Protocol 译为“互联网协议”。IPv6 是 IETF（互联网工程任务组，Internet Engineering Task Force）设计的用于替代现行版本 IP 协议（IPv4）的下一代 IP 协议，IPv6 将 IPv4 中 32 位的地址长度扩展到了 128 位，使用 IPv6，可以让全世界的每一粒沙子都能分配到一个 IP 地址。

IPv6 的设计初衷是用以解决 IPv4 地址枯竭问题，同时对 IPv4 进行大量改进，并最终取代 IPv4。然而由于 NAT 等技术的广泛应用，IPv4 在互联网流量中长期占据主要地位，IPv6 的使用增长缓慢。

1.2 IPv6 的国家战略价值

IPv6 是互联网升级演进的必然趋势、网络技术创新的重要方向、网络强国建设的基础支撑。当前，全球范围内 IPv6 网络建设与应用创新持续加速，主要发达国家和地区均出台了 IPv6 发展规划和政策指导，大型网络运营商和应用服务商也在开展 IPv6 大规模商用部署。同时，随着 5G 和 IoT 技术的逐渐成熟，万物互联的时代即将到来，苹果 AppStore 审核要求全面支持 IPv6 等，使得市场上对 IPv6 的呼声不断升高。

IPv6 对我国数字化、支撑网络强国建设有重要的意义。这方面我国推进 IPv6 规模部署专家委主任邬贺铨院士对此有比较充分的论述。

1.3 IPv6 的社会价值

在大家的印象中，IPv6 可能仍然处在部署的初期，各大运营商还在进行网络改造，全面普及似乎离个人还是一件很遥远的事情。但根据国家 IPv6 发展监测平台的数据，目前全国 IPv6 互联网活跃用户总数达到了 6.83 亿，全国 IPv6 互联网活跃用户占比达到了 66.18%，IPv6 已经不知不觉地融入到大家的生活中。随着 IPv6 的规模化部署，它会给我们带来哪些变化呢？

随着 5G 时代的到来，物联网、工业互联网、云计算、人工智能和大数据等新兴领域的快速发展，移动互联网对于 IP 地址的需求日益增加，IPv4 已经无法满足当前网络环境。IPv6 和 5G 是相辅相成的，它们的目标都是尽可能将更多的设备互联，实现万物互联的最终境界。结合 IPv6 海量公网地址的技术属性和 5G 高速率低延迟网络的核心优势，为万物互联网络提供质量保障。

普通用户将会逐步进入全面告别内网的时代，目前运营商大部分都使用了 NAT 技术，这让用户在远程监控、游戏联机、P2P 视频、设备公网互联等方面，体验不太稳定，也制约了这些技术的进一步发展。IPv6 拥有无穷无尽的公网 IP 地址，从而实现真正的万物互联互通。未来我们看的优酷视频可能就是自己邻居分享的，我们使用的钉钉视频会议也会因为 IPv6 变的更快更清晰，我们的家用监控也因支持 IPv6 而变的丝滑流畅，这一切将会在 IPv6 全面普及后逐步实现。

1.4 IPv6 规模化部署过程中遇到的困难与挑战？

1.4.1 超大工程的管理挑战

• IPv6 改造涉及运营商线路和地址申请、网络/计算/存储等 IT 基础设施新建或升级、应用程序代码逻辑更改等事项，升级难度大、复杂度高，如何保障业务连续性？需要满足业务平滑升级、减少业务中断时间，甚至避免业务中断的核心诉求。

• 国家推进 IPv6 规模部署行动提速，企业网站系统、互联网 APP 等需要在较短时间完成 IPv6 改造工作，如何在保证业务稳定性前提下，快速完成升级是不得不面临的挑战。

• 应用软件需要进行大范围改造，同时也会带来运营商线路费用、IT 基础设施软/硬件新购或升级费用、集成服务费用等综合成本，如何提升改造效率，同时实现持续性成本可控可预期也是非常关键的点。

1.4.2 新场景下的技术难题

• 从 IPv4 单栈到 IPv4 和 IPv6 双栈环境，对应底层表象会增加双倍的工作，如何稳定高效的支撑业务发展，这是首先要解决的难题。

• 双栈网络环境增加了测试的复杂度，如何建立便捷的测试工具，方便日常的测试工作同时能够及时发现异常。

• 随着双栈的部署终端面临的环境更加复杂，如何在复杂网络环境中确保用户体验，这是规模化部署过程中必须要解决的技术难题。

1.4.3 常态化运营体系建立

• 规模化部署不是最终目标，IPv6 需要从能用走向好用，需要持续运营下去。互联网技术迭代更新是非常快速的，一到两周就会进行一次版本的迭代发布，如何保证后续的迭代升级中不会影响规模化部署的进程，这需要将这部分工作融入到日常常态化的运营体系中。

1.5 阿里巴巴对 IPv6 的整体思考和改造方案

不论从政策导向、市场需求，还是聚焦于技术演进，IPv6 都将开始进入规模部署阶段，正是基于此背景，阿里巴巴率先全面进入“IPv6 时代”。集团在 2017 年成立集团 IPv6 项目组，主流 APP 均进入到 IPv6 规模化部署中。

• 2018 年启动阶段一：应用接入层改造。

• 2021 年启动阶段二：内网应用 IPv6 升级试点，探索 IPv6 演进的最佳实践方案。

• 2022 年启动阶段三：IPv6 Only 试点。

本文重点会和大家分享阿里巴巴成熟的应用接入层改造经验，后续会逐步为大家分享内网应用 IPv6 升级和 IPv6 Only 试点的改造经验。IPv6 规模化部署是一个超级工程项目，更是一个技术创新项目。

接下来我们将会以四个维度展开：

1. 整体规划；

2. 从云、管、端（服务端、客户端）4 个层面剖析这个超级复杂工程；

3. 为克服新场景困难而打造的三个核心技术；

4. 为 IPv6 常态化运营打造的常态化运营体系。

二、整体改造方案

2.1 战略规划

IPv6 的整体发展，我们可以将其总结为三个战略阶段：

第一个战略阶段是 IPv6 发展的初期，更多是孤岛式的实验环境。

第二个战略阶段是 IPv6 与 IPv4 共存阶段，这个阶段又分为 IPv4 主导和 IPv6 主导两个阶段，这两个阶段侧重点略有差异。IPv4 主导阶段我们重点提升公网 IPv6 流量占比，由于涉及的面非常大，而且短时间内没有业务价值，因此需要有较强的政策牵引。到达 IPv6 主导阶段，企业自主驱动力会增强，端到端改造将会是重点。我们现在就处于第 2 个战略阶段中的 IPv4 主导向 IPv6 主导演进的过程中，因此当前比较急迫的是推进 IPv6 规模化部署，让 IPv6 流量占比实现较大的提升，进入 IPv6 主导阶段。

第三个战略阶段是 IPv6 成熟阶段，我们需要逐步关停 IPv4，全面进入 IPv6 Only 时代。

复杂的问题总会让人望而生畏，将问题拆解，逐个击破是很好的规划思路。基于这三个战略阶段的划分，我们可以分阶段进行改造，隔离相互间的依赖，既能做到快速的实现公网流量的提升同时确保业务的稳定性连续性，又能分步进行创新探索。

1）战略推进：有了长远的战略规划就可以更加清晰进行项目的推进，接下来我们将重点聚焦在 IPv6 流量提升和规模化部署部分。具体到执行阶段，我们大体上遵循“三步走”的策略，每个阶段都需要经历这三个步骤，这是确保我们业务稳定运行的重要保障。

• 步骤一：应用试点，首先需要通过一个应用，跑通整个改造流程，打通云、管、端的依赖。

• 步骤二：小规模上线，实操起来需要具备精细化的灰度策略，按照省份、运营商、比例的精细度，逐步上量。

• 步骤三：需要形成可复制的解决方案，在集团内部进行大规模的推广部署。

2）组织保障：为更好落地整体战略规划，集团成立了一个强有力的执行项目组，根据阿里巴巴主流的 APP，成立 24 个子项目（PM、端、测试、开发的同学组成），再加上云产品的子项目（PM、SA 和各个产品的 PD 开发组成），组建了阿里巴巴 IPv6（基石）项目组。

3）资金支撑：

• 改造过程会涉及到硬件改造以及硬件和平台费用，同时项目组体量比较大，我们涉及到少量的运营费用，这些都需要提前做好预算规划。

• 涉及到硬件设备及测试手机等设备，需要提前采买好相关的设备

2.2 超大工程

接下来我们将会进入实际改造的环节，IPv6 改造是一个系统性的工程，尤其是对阿里巴巴来说，我们涉及的范围非常大。为了项目的高效推进，我们从全局纬度将其分为“云管端”三大部分，其中端的改造又分为服务端和客户端，我们把这个两个单独拆解开来，最终我们会从云，管，端-服务端、端-客户端这四个部分来进行阐述。

2.2.1 云产品改造

为了更好的完成公网流量提升（服务端双栈改造依赖部分不在这里讨论），我们需要全面完成企业互联网域名服务器 IPv6 改造，支持 AAAA 记录和 IPv6 域名解析请求，主要核心业务域名全部配置 A 及 AAAA 记录。使用阿里云 HTTP DNS 服务，支持移动端的 IPv4/IPv6 双栈及 IPv6 Only 环境下的域名解析能力。

云产品改造会以更好的支撑 APP IPv6 改造为首要任务，最终达成 IPv6 用户数和公网流量提升的目标。可以分为三期来进行，首期是在用户访问的公网入口及安全管控处进行了 IPv6 的支持，包括 DNS、http DNS、CDN、SLB、DDoS、WAF、ACL、IP 地址库等，这些产品支持了 IPv6，就意味着用户可以基于这些产品提供安全、高效的 IPv6 服务。接下来阿里云还将在内部网络进行双栈的支持，实现端到端的 IPv6 流量贯通。最后，未来的演进目标是 IPv6 Only。

⍟ 云解析 DNS 支持 IPv6

要使用 IPv6 服务，首先需要 DNS 支持 IPv6 解析。我们都知道，当用户访问互联网时，访问的请求会最先到达 DNS，DNS 会根据访问域名查询并返回正确的 IP 地址。IPv6 时代，阿里云解析 DNS 依然作为云计算服务的入口，同时支持 IPv4 和 IPv6 双栈（即一个域名解析两个地址，一个 IPv4 地址，一个 IPv6 地址）解析，继续提供强大稳定的解析调度入口。

⍟ 负载均衡 SLB 支持 IPv6

公网入口会优先支持 IPv6，快速提升公网流量占比，负载均衡 SLB 长期以来都是关键业务系统的公网入口，它可以对多台 ECS 进行流量分发，提高业务系统的可用性和处理能力。

负载均衡 SLB 支持 IPv6 从产品上看主要有两点：首先，采用了独立的 IPv6 类型 SLB。独立的 IPv6 类型的 SLB 实例和 IPv4 的 SLB 实例性能和功能没有差异。用户只需要在购买 SLB 时选择 IPv6 类型，就可以快速创建一个 IPv6 的 SLB 实例。其次，IPv6 类型的 SLB 和后端的 ECS 通信还采用 IPv4 私网地址。

⍟ CDN 服务

CDN 内容分发网络（Content Delivery Network），解决跨地域跨运营商网络性能问题，提供稳定快速的加速服务。CDN 是互联网的流量入口，阿里云 CDN 团队从 2017 年起就启动了 IPv6 的改造，积极持续地在 IPv6 改造中投入相关资源，从节点部署、节点网络架构改造、IPv6 功能支持、IPv6 调度能力完善、IPv6 全链路监控方案、IPv6 质量评测体系建设等方面持续打磨，投入物理资源、人力资源，推动 IPv6 整体能力不断向 IPv4 靠近。截止到目前累计完成了近千个节点的 IPv6 改造升级，IPv6 合规率超过 90%，超过工信部的验收标准，在产品化上，基础的 CDN 产品和全站加速产品率先通过由全球 IPv6 Forum 论坛发布的 IPv6 Enabled CDN。

阿里云 CDN 将各地域各运营商已经改造完成的 IPv6 CDN 节点加入到调度域，用户在阿里云控制台开启 IPv6 功能，并配置图片域名的灰度比例。可以从流量入口上控制 IPv6 的灰度总量，确保不会出现 IPv6 资源不足或者无资源可调度的问题。

对于 302 调度域名，跳转时会有 IPv6 地址缩写的问题，浏览器访问时会自动用缩写后的 IPv6 地址跳转，APP 内使用 libcurl 等网络库时，并不会触发自动缩写，以获取到的 IPv6 地址原样进行请求。需要 302 节点配置缩写前和缩写后两套 IPv6 的 VIP，确保任何场景下都可以跳转。在 HTTPS 的 VIP 证书中，需要加签 IPv6 的 VIP，确保 https 下也可以正常跳转。

对于免流域名，免流调度域需要分配 IPv6 的 VIP 组，将需要向运营商报备的免流节点 IP 都划入进去，并且具备 IPv6 功能的开启和关闭能力，确保在运营商报备完成前不启用 IPv6 节点，运营商报务完成后又能及时启用节点，避免出现免流失效或者免流调度域水位过高的问题。

⍟ WAF 服务

当用户以 IPv6 进行通信时，还有一个关键的云服务即 Web 应用防火墙，它负责对网站或者 APP 的业务流量进行恶意特征识别及防护，将正常、安全的流量回源到服务器。当我们运行 IPv6 协议时，必须升级到对 IPv6/IPv4 双栈的防护能力，避免网站服务器被恶意入侵，保障业务的核心数据安全，解决因恶意攻击导致的服务器性能异常问题。阿里云 WAF 已经支持一键升级 IPv6 功能，在 WAF 控制台的被防护域名下，直接打开 IPv6 状态开关即可。

⍟ DDoS 服务

同样重要的还有阿里云 DDoS 防护服务，它是以阿里云覆盖全球的 DDoS 防护网络为基础，结合阿里巴巴自研的 DDoS 攻击检测和智能防护体系，向用户提供可管理的 DDoS 防护服务。同样需要增加 IPv6 的防护能力，自动快速地缓解网络攻击对业务造成的延迟增加、访问受限、业务中断等影响，从而减少业务损失，降低潜在 DDoS 攻击风险。如需对 IPv6 地址进行 DDoS 防护，可以开通 DDoS 防护包中的 IPv6 协议，防护对象设置为 IPv6 转换服务的地址。

⍟ ACL 黑白名单及安全策略

确保 IPv6 安全体系防护的完整性与高效性，对防火墙、入侵检测、行为审计、流量清洗等网络安全设备，进行统一升级以支持 IPv6 环境下的正常工作。随着 IPv6 的发展，IPv6 的地址数量将远远超过 IPv4，现有的 ACL 黑白名单容量将无法满足，需要提前进行扩容改造。对于 IPv6 安全防护能力存在风险的节点，应进行网络安全设备升级或替换。从应用业务层面以及安全管理层面进行 IPv6 安全策略制定与配置，保证 IPv6 的安全策略包含了所有的 IPv4 策略。

⍟ 其他云产品支持 IPv6

除了上面提到产品外，还有很多其它产品也已经完成了支持或即将支持，如对象存储 OSS、数据库 RDS、DTS、API 网关等。

2.2.2 管道改造

接下来我们将进入另外一个重点改造的场景即“管道改造”，对于阿里来说我们重点需要完成 IDC 网络和 IT 网络的全面改造。

全面完成集团级数据中心核心网络、互联网出口 IPv6 网络改造。

1）改造步骤

• 首先为了更好的支持云产品改造，实现 Internet 提供 IPv6 的域名解析、负载均衡及安全服务服务，核心网、安全清洗、MC、BSW、LSW 优先支持，然后是 ANAT、XGW 的 4to6 的地址翻译以及 LVS、CDN。

• 然后对 IDC 集群内部的 DSW、PSW、ASW、NC 进行改造，支持 ECS、Docker 服务。

• 最后开始进行 IPv6 Only 尝试，全面进入 IPv6 时代。

2）方案介绍

• 核心网支持双栈，主要有两种技术方向选择：物理机双栈和 MPLS 6PE/6vPE。物理机双栈是在现有的 IPv4 路由器和链路上，使能 IPv6 和路由协议，IPv6 报文和 IPv4 报文一样，直接封装在链路层上转发；MPLS 6PE/6vPE 则是保持现有的 MPLS 网络不变，在 PE 上将 IPv6 报文封装到 MPLS 中进行转发。这种方式可以在 PE 设备按需变更支持。

• 阿里核心网已经开启 MPLS 功能，后续整体演进方向是全面 MPLS 化，P 结点设备成为 BGP-free Core 以大幅减少对设备的功能要求和降低功耗，这对于节省 Capex 和 Opex 成本都有很大帮助。

• 基于阿里核心网的实际情况以及后续整体演进方向，在 IPv6 的演进方案上，我们选择 6PE/6vPE 的方案，通过升级 PE 路由器来支持双栈，不需要对现有核心网 P 路由器做更改。只需 PE 设备使能 IPv6，P 设备不需要使能 IPv6，整体实施成本低。IPv6 作为 MPLS 的一个新业务承载，对现有运营维护冲击小，IPv6 维护范围只在 PE，充分发挥现有的高效运维体系能力。AZ 内则主推物理机双栈，两种技术结合实现高效推进。

阿里巴巴办公网改造

办公网的改造也是一个复杂的过程，不仅涉及到改造的成本，同时也需要投入大量的人力，因此这是一个比较漫长的过程。为了更好的满足业务需求，我们也分为两个步骤来实现。

• 步骤一：两个过渡方案，先通过点状部署，满足大家的测试需求。然后通过改造我们的 Vpn 客户端和网关，通过拨入 Vpn 获取 IPv6 地址，满足开发测试需求。

• 步骤二：在经历一年的测试准备后，2022 年初我们在全国 21 个园区开始逐步进行 IPv6 改造，预计在 2023 年 3 月底完成国内主要园区的双栈改造升级。

在全国核心城市部署园区网汇聚 POP 节点，该汇聚点下联城市各园区核心出口设备，上联阿里云对应 region 接入点，实现园区网所需资源在云上快速拉起部署，借助云上资源 IPv6 能力快速组建新一代园区网双栈运维系统，如 DNSv6 服务、DHCPv6 服务、双栈堡垒机等，免去线下自行搭建付出的巨大人力和资金成本。

2.2.3 应用端改造

我们组织集团 20 多款 APP 同步进行 IPv6 双栈改造，改造内容更加聚焦，效率也会高很多。下面我们先介绍一下服务端改造工程。

⍟ 新建应用改造

1）环境准备

• Web 容器环境：选用支持 IPv6 协议的最新版本 Tengine，安装 toa 模块，支持透传 IPv6 头信息至应用服务。

• 开发环境及 OS 系统：应用的开发编译选用支持 IPv6 协议的操作系统，如 Windows server 2003 以上版本、MAC OS 10 以后，以及 Linux 系统的 CentOS 7 或者 Alios 7U 等。

• 测试环境：办公网环境与测试机房通过 IPv6 专线打通，办公网提供 IPv6 的无线/有线接入点，同时保留了原来的 IPv4 接入点。开发同学可以接入 IPv6 接入点进行日常开发和办公事务处理，需要访问不支持 IPv6 的公网服务时，可以切换到 IPv4 网络环境。也可以通过 Vpn 拨入 IPv6，进行 IPv6 测试。

2）业务应用改造

• 场景 1-IP 地址库：使用 IP 地址库服务对用户归属地进行定位判断处理的，需要升级到最新版本的 IP 地址库数据服务，并具备定期升级能力。确保 IPv6 地域归属判断的准确性。

• 场景 2-IP 地址格式统一：因为 IPv6 地址可以略写的原因，导致直接按字符串进行判断的话，会把有略写和无略写的 IPv6 判断成不是一个 IP 地址，从而导致业务处理出现偏差。同时，部分浏览器请求会自动略写 IPv6 地址，JAVA 网络包、CURL 等，不会主动略写 IPv6 地址，这会增长服务端处理的复杂性，所以需要前置一个公共处理，将所有的 IPv6 地址都经过公共处理进行标准化，统一业务处理逻辑，减少业务间不一致问题。

• 场景 3-IP 地址保存：一般服务端日志落库，用户信息落库等常规处理中，会把用户 IP 保存到数据库等存储中，对于严格限制数据类型和长度的数据库，需要依据存储型号进行定义，原来的 IPv4 只需要 32 位字符串或者长整型数据就可以保存，而 IPv6 需要扩大到 128 位，同时长整型也存不下，需要高 64 位和低 64 位拆分存储等方式进行处理。

• 场景 4-接口传递：某些使用 http get 方式将多个用户 IP 通过参数形式传递时，需要注意 get 的 1024B 的上限，原来传递 IPv4 时 10 个用户一起传递没有问题，但现在改用 IPv6 时 10 个用户的 IP 长度就会超过 get 上限，需要改用 post 或者调低上限。

• 场景 5-存在 IP 地址的 hardcopy：不能把上下游调用接口的 IP 地址直接写在代码中或者配置文件中，因为上下游完成 IPv6 改造的时间并不完全一致，上线时间也不一致，会导致出现线上故障。需要全部改为域名方式调用。

• 场景 6-客户端 IP 出口地址的取得方式：在双栈环境中，同一请求，只能从请求头部中获取到 IPv4/IPv6 地址中的一个，不可能两个都获取。如果希望同时获取 IPv4 或者 IPv6 地址，那么只能选择重复请求，或者是通过参数将客户端地址传上来。需要扩展请求字段，将 IPv4/IPv6 分成两个字段提交，同时服务端也需要做接收改造处理。

• 场景 7-日志分析逻辑：众所周知，为了方便日志分析和拆解，所有的业务日志都会定义一个统一的格式，日志输出的各个字段之间统一使用“||”等分隔符分隔或者按字段长度固定。使用分隔符的，需要考虑到不能再使用了，因为 IPv6 中带了这个符号。使用固定长度分隔的，也需要考虑到对 IP 地址不能再固定 32 位长度了，要调整到 128 位，同时要向下兼容 IPv4，IPv4 也要补齐到 128 位。

3）依赖改造

• 第三方库的更新：选用支持 IPv6 协议的第三方 SDK 版本，如果三方库不再更新支持 IPv6，那就需要寻找置换方案。

• 安全部署环境：接入层安全控件、限流插件、ACL 白名单插件等应用安全服务应支持 IPv6 协议。

4）降级能力构建：需要从业务逻辑上原生考虑 IPv6 网络不可用时，如何降级至 IPv4 来继续提供服务。

⍟ 存量应用改造

1）环境改造

• 接入层改造：制定 IPv6 升级计划，申请 IPv6 的 VIP，将负载均衡的 RS 指向新的 IPv6 接入层，确保 IPv4 与 IPv6 的流量隔离。

• 升级开发环境及 OS 系统：应用的开发编译选用支持 IPv6 协议的操作系统，如 Windows server 2003 以上版本、MAC OS 10 以后，以及 Linux 系统的 CentOS 7 或者 Alios 7U 等。

• 替换 Web 容器环境：升级最新版本 Tengine，升级最新 toa 模块，支持透传 IPv6 头信息至应用服务。

• 基础镜像升级：原业务使用过旧，版本过低的 OS 镜像打包时，需要升级到最新支持 IPv6 的基础镜像，并用最新的 OS 进行编辑打包。

2）业务应用、依赖改造及降级能力构建

• 参考上述新建应用的改造、依赖改造及降级能力构建即可，对存量业务逻辑进行排查，存在上述场景的需要进行业务代码的重构，业务逻辑的修改，使存量业务满足 IPv6 环境下运行需求。

⍟ 回归测试

存量应用一般都经过严格的 IPv4 环境下测试，但不能保证在 IPv6 下一定是没有问题。所以需要在 IPv6 的测试环境下，对存量应用以及新建应用进行回归测试。包括对所有有改动功能点的全量测试，以及没有改动但属于核心功能点的覆盖性测试。

⍟ 验收环节

进行线上灰度验收，按照国家网站/应用 IPv6 升级改造验收督查指标相关要求进行测试验证，在域名 IPv6 支持度、页面 IPv6 可达性、业务 IPv6 支持度、应用服务质量、IPv6 安全防护等方面开展测试。

2.2.4 客户端改造

接下来我们将会进入客户端功能改造部分，客户端有分为手机、电脑等场景，全部需要支持 IPv4/IPv6 双栈及 IPv6-only 环境下的网络通信能力。IPv6 双栈环境测试 IPv6 流量占比不低于 80%，并逐步引导 IPv6-only 模式。

⍟ Windows/mac 端 IKU 应用

接入 HTTPDNS 服务，在客户端集成 HTTPDNS 服务 SDK 包，IKU 应用具备手机移动客户端相同的 IPv6 引流灰度能力。替换 IKU 应用端中的网络包，具备 IPv6 的网络通信能力。开发在 IPv6 弱网条件下的降级能力，在用户可以接受的延迟时间内，切换到 IPv4 通信，保障用户体验无损。逐步关闭低 OS 版本的使用许可，关闭低版本应用的上线使用，推动用户端进行 OS 或者设备的升级，提高 IPv6 使用率。

⍟ 安卓/iPhone/iPad 手机客户端

这块占比最大，同时用户设备类型也是最丰富的，需要通过不断的版本更新，来降低旧版本的占有率，达到提升 IPv6 使用率的目标。

• 终端 IPv6 支持度评估：将安装优酷 APP 的终端按照机型，OS 版本，性能， IPv6 下通信能力分类。对新上市机型进行逐台验证，分别进行 IPv6 支持度评估。

• 客户端 APP 基础套件升级：基础网络包 NetworkSDK 等集团二方包进行升级，实现支持 IPv6 的协议栈解析以及基础降级能力。使用第三方网络库的，例如：libcurl，需要升级到最新版本，同时通过业务逻辑弥补上缺失的自动降级能力。

• 升级 IP 地址：部分 APP 中集成有小型的 IP 地址库，因为数据包大小的问题，基本上小型 IP 库都没有包含 IPv6 的数据。需要重新评估 IP 库数据包大小与 APP 整体包大小的关系，如果集成支持 IPv6 IP 库数据包过大的话，那需要通过服务端判断的方式来替代本地的 IP 库。

• 端侧埋点服务的改造：埋点的正常上报，是整体评估 IPv6 下业务可用性和用户体验一致性保障的前提。特别是在弱网、断网、降级回落的情况下，数据可以正常上报。IPv6 下埋点是否正确检测出网络环境的变化，网络切换导致的 RT 变化等，需要根据业务逻辑和用户操作场景，进行埋点的改造。

2.3 创新技术

通过前面的介绍，相信大家已经对四个板块（云，管道，服务端，客户端）的庞大改造工程有所了解。如前面所说，作为一个创新技术项目，接下来重点介绍三个关键的创新技术方向，在应用的双栈改造过程中对我们流量的提升和服务质量保障起到了至关重要的作用。首先我们会介绍一下核心的全链路双栈技术，这里重点从核心网、硬件和系统三个大的技术方向中选出 AliBGP、双栈智能网卡及 Linux 内核三个点做一个简单的介绍，然后会介绍保障测试效率的 TMQ-Monkey 技术，最后会介绍提升用户体验的 EQM 及 T-happyeyeballs 技术。

2.3.1 关键双栈技术

⍟ 负载均衡网关支持 IPv4、IPv6 双栈平滑演进

双栈支持，在业务向 IPv6 迁移升级过程中，做到无缝切换，有效降低用户使用网络的复杂度。通过 DNAT vxlan 封装或者 FNAT 携带 TCP option，后端内核模块获取访问 SLB 的 IPv6 客户端源地址。 

• 负载均衡网关支持 IPv4、IPv6 双栈后端平滑演进的技术

IPv6 的改造难度大、周期长，一般涉及从原有 IPv4 服务平滑过渡到 IPv6。阿里云负载均衡网关通过支持前后端 IPv4/IPv6 双栈 session 技术提供 NAT64 和 NAT66 session 以及 IPv4/IPv6 后端混挂能力，满足用户平滑演进的需求：初期可通过负载均衡 NAT64 能力的过渡方案，IPv4 后端在不改造或微改造的情况下可通过 IPv6 负载均衡快速对外提供 IPv6 服务；后期通过支持挂载 IPv4、IPv6 混布能力的 IPv6 SLB，逐步切换到 IPv6 后端服务，再逐步减少 IPv4 后端比例，增加 IPv6 后端比例，最终切换到纯 IPv6。

• 获取客户端 IPv6 源地址

在原有 IPv4 场景中，后端服务一般有需要获取到客户端 IPv4 源地址需求。IPv4 到 IPv6 的改造过程中，获取客户端 IPv6 源地址的需求也是显而易见的。在 NAT64 场景下，由于源地址被转换为 IPv4 地址，原始 IPv6 源地址信息只能考虑通过其他方式携带给后端，阿里云 SLB 通过自定义 TCP option 方式中携带 IPv6 地址信息的方式携带源地址给后端，后端通过特定内核模块解析 tcp option 并保存在 sock 中，用户调用 getpeername 来获取 IPv6 源地址。

⍟ AliBGP 大规模 IPv6 路由控制方案

IPv6 网络构建是 IPv6 商业部署的基础设施。而 IPv6 网络构建中的重要一环是 IPv6 路由系统的搭建，其主要包括路由管控和路由快速收敛两部分。在 IPv6 网络中，发布什么路由，学习什么路由，以及在网络抖动时快速收敛，是 IPv6 网络稳定可用的重要课题。

在 IPv4 网络中，C 段的大小是 8bit，即 256 个 IP 地址；而在 IPv6 网络中，C 段的大小是 64bit，最大 IP 地址数可大 2 的 64 次方。在网络中，除了正常转发数据用到的路由，还需要发布防攻击的黑洞路由，容灾用到的不同长度不同优先级的网段和明细路由。为此，单设备中学习和发布的 IPv6 路由条目数可达 10K 甚至 100K 级别，再叠加原先 IPv4 的 32K 路由，整网路由收敛能力需要有数倍增加。同时需要对 IPv6 路由进行更细致的管理，以避免因误发布或者误学习路由造成网络数据包的丢失。

传统 IPv6 网络实际部署业务规模不大，网络路由量也不大，传统的商用交换机的路由学习和收敛能力较低，性能大致为 1.4K 条目每秒，不能适应阿里业务网络路由量的需求。

AliBGP 广泛应用于高性能转发网关、自研交换机、网络业务服务器平台之上。高性能优化，路由收敛性能达到 10K 条目每秒。实现了大规模快速收敛、故障范围控制、快速倒换等方面的能力。

可靠性方面，支持添加路由发布和学习总条目数控制、指定设备路由平滑隔离和恢复、IPv6 路由热重启、远程控制 API 等功能，改善了 IPv6 路由精细化管理能力。

• 高性能：ALIBGP 采用开源的 FRR 路由软件，并在上面做了大量的功能开发和性能提升开发。实现了用户态 IPv6 BGP 协议，并引入了 IPv4 BGP 协议中的 Dynamic Update Peer-Groups 和 Next-Hop tracking 两大特性功能，实现以 Group 方式的发布和学习路由条目，在路由震荡时跟踪 next-hop 状态刷新路由下一跳；同时特别优化了 IPv6 ECMP 路由与内核的交互过程。这些优化极大提升了 IPv6 路由学习和发布效率，以及收敛速度。

• 高可靠：强大的路由控制能力，IPv6 的 route-map 的配置渲染能力，能根据用户规则，精细控制每个路由条目的学习和发布。

高性能 IPv4/IPv6 双栈智能网卡

双栈支持，在业务向 IPv6 迁移升级过程中，做到无缝切换，有效降低用户使用网络的复杂度。

• 后端支持 IPv4、IPv6 混合部署

IPv6 的改造是一个复杂的系统工程，既要保障用户现有 IT 投资，又要紧跟网络发展趋势，从实际来看，IPv4/IPv6 双栈将长期存在。短期来看，IPv6 转换服务会是一个经济适用的过渡方案；但长期来看，无缝支持 IPv4/IPv6 双栈将是终极解决方案。基于此，我们在 AVS 转发阶段即考虑完全兼容 IPv4/IPv6 双栈，从底层有效解决 IPv4、IPv6 混布的问题。IPv4/IPv6 双栈全面支持 TCP、UDP、GRE、ICMP 等各种报文类型，通过自动识别报文版本号、报文类型，提取报文五元组等关键信息实现报文自动转发。

• FPGA 硬件加速，极大提升网络性能

通过使用自研 FPGA 板卡进行 AVS 硬件加速，将 AVS 转发路径下沉硬件，自主定制开发 IPv4/IPv6 转发引擎，实现双栈无差别加速，极大提升 IPv4/IPv6 转发速率。单机性能从软转发的 5Mpps（4core），提升至 30Mpps；端到端单向延时从 60us，降低至 25us，达到业界领先水平。既节省了主机 CPU，又提高了报文处理的效率，有效降低了 IPv6 改造过程中的巨大经济成本。

• 自定义会话压缩技术，支持千万级别会话流表

通过使用外挂 ddr，将流表转发信息转移到外部存储。同时，针对 IPv6 转发信息位宽大的特点，采用自定义数据压缩技术，在有限空间内，无缝存储 IPv4/IPv6 转发信息，极大提高了流的会话数量。session 数从内存模式的几兆提升到几十兆，将单机会话数量提高了一个数量级。为防止外部存储数据错误，自行开发了一套接口信号检错、纠错机制，有效保证整张卡的接口稳定性。

⍟ Linux 内核优化

1）IPv6 内核协议栈 bugfix

• IPv6 路由 cache 优化

当核心网和物理机网卡已经高效支持 IPv6 后，接下来我们还剩下一个非常关键的优化点，那就是操作系统。我们早期在试点 IPv6 应用的过程中发现 IPv6 流量会引起的大规模 CPU 软中断飙高以及宕机现象，所有的 IPv6 请求受到了影响，而且会有宕机风险，这也会对同一台机器上的 IPv4 服务产生影响。因此，Linux 内核的优化就是摆在我们内核工程师面前重点方向。

通过分析发现主要原因是 gc 拥堵，造成了同一个 TCP 连接会在 tcp_v6_rcv 函数里的 socket spinlock 那里 spin，而不同连接则会在 fib6_run_gc 函数里的 gc spinlock 那里 spin 。为什么 IPv4 没有问题而 IPv6 就会有问题呢？

IPv4 地址大概有 43 亿个，去掉广播、组播、私有地址等，系统需要路由处理的地址完全是在哈希、树这种传统数据结构的处理能力之内。但 IPv6 最大的特点就是地址数多了很多，这意味着处理逻辑会变的更加复杂。

经过我们工程师的测试验证，最终选择关闭 IPv6 的路由 cache，看起来只是通过修改配置就能解决，实际上由于 IPv6 的所有路由项都在同一棵树里，所以拆分起来还是有难度的。

• IPv6 代码优化 

IPv6 sysctl 的数据指针是一对一设置的，不利于维护，尤其是使用 kconfig。我们通过补订实现了简化处理，达到了和 IPv4 一样的效果。

• IPv6 协议栈传输机制优化

IPv6 mtu 优化，经过长达一年多的大范围持续验证，最终拟定了 IPv6 MTU1450，在阿里 CDN 的场景下，最大化的兼顾 IPv6 传输性能和业务可用性。

拥塞控制和丢包恢复算法的优化。拥塞控制是协议栈心脏，控制着协议栈的功能启停；丢包恢复系统是免疫系统，负责异常修复，CDN 设计了 CUPLUS 和 PBR 两大核心算法保障 IPv6 协议栈的内容分发效率。

• IPv6 协议栈数据体系建设

在 IPv6 上量规模化过程中，为了建立对 IPv6 网络的基础认知、优化 IPv6 传输机制和监控 IPv6 服务的稳定性，我们构建了 IPv6 协议栈的网络数据中心，数据中心设计了两个大板块的功能：

① 网络链路质量监控：监控 IPv6 的网络链路质量与 IPv4 的差异性，实现了重传率（字节和报文个数两个维度统计）、TCP 连接建连时间、响应时间（服务器视角）、平滑 RTT、最小 RTT、RTT 方差和 IPv6 总传输流量等维度统计；

② 业务质量监控：监控 IPv6 协议栈提供的业务质量与 IPv4 的差异性，实现了请求失败率千分比、平均请求大小、下载速度三个维度统计。产品化能力支持了 TCP 连接粒度和域名维度的数据监控能力。

2.3.2 TMQ-Monkey 技术

Android 系统原生支持 Monkey 能力，通过 adb 命令即可触发 monkey 操作，从而对指定应用进行随机的点击操作。为了更好的提升集团 APP 的 IPv6 浓度占比，我们采用 Android 原生 Monkey 能力进行测试，经过使用后，发现原生 Monkey 能力存在一些痛点，无法满足我们建设自动化测试平台的需求：

• 点击效率低：由于原生 Monkey 完全基于屏幕大小生成随机行为，对页面内容和元素不感知，仅通过快速生成随机坐标进行点击，较多的点击行为是无效的。

• 容易陷入相同页面：原生 Monkey 对页面内容和路径没有记录，完全幂等的行为，导致在相同业务如果退出的出口较少情况下，无法退出业务页面，长期位于同一页面，效率低下。

• 策略较少：原生 Monkey 完全依赖随机策略，不支持针对情况调整页面策略，对于部分场景支持度不高。

• 不支持自定义能力：对于业务需求的页面不支持重点的定制化。

以上痛点导致 IPv6 自动化项目中，原生 Monkey 能力跑出数据量不足，流量不达标且跑到的页面量不足，IPv6 流量测试效果不佳。为了解决这部分问题，与淘宝 TMQ 团队，通过结合 openatx 的 UI 自动化和优化过的 Android Monkey 能力来支持 IPv6 自动化测试能力。在保留 Android 底层直接驱动的快速效果的同时，也能利用 UI 自动化能力支持自定义能力。

TMQ-Monkey 提供了独立的 Python SDK，封装依赖的 Monkey 驱动能力和自动化调度能力，支持一键部署和运行，实现 IPv6 项目低成本的接入和维护。

⍟ TMQ-Monkey 系统技术结构

TMQ-Monkey 基于 Python 封装各类依赖和管理 Monkey 运行任务，主要实现能力如下：

• 生命周期管理：对于每次执行的 Monkey 任务，及时在服务端创建相关信息用于任务记录，并管理 Monkey 运行期间的设备运行、设备状态、插件运行等相关行为，统筹整个运行期间的设备行为。

• 自动化设备接口：基于 openatx 提供 Android 和 iOS 的设备接口，用于处理 monkey 运行前的前期准备和运行期间的自定义行为。

• 依赖管理：处理 Monkey 驱动层相关的依赖下发和配置。

• 配置管理：通过配置管理中心，对各类运行参数、插件信息、运行数据等内容进行管理。

• Monkey 驱动层：主要用于基于 Android Monkey 的底层驱动能力。

• 事件管理机制：Monkey 运行期间的整个驱动层的事件管理，通过事件生成器生成的随机事件，对设备进行运行，并处理各类异常情况。

• 事件生成器：通过策略中心、配置中心、异常识别结合生成最终 Monkey 事件，从而驱动 Monkey 运行。

• 策略中心：按照用户输入的策略选择，依据策略生成相应的事件生成方案。

• 配置中心：处理用户定义的黑白名单和下发的各类场景处理的配置，用于优化 Monkey 执行效果。

• 异常识别能力：有效对运行期间各类异常状态：Crash、假死、跳出等场景进行识别，并处理。

• 插件中心：执行运行期间的其他运行能力。

• 数据收集器：对 Monkey 运行期间的页面信息进行收集，上报服务端，用于数据统计和后续策略优化。

• 自动跳转插件：集团部分支持自动跳转能力的应用，可以通过用户下发常见页面，支持直接跳转后运行 Monkey，有效提高 Monkey 的效果。

• 运行数据监控：有效对运行期间的 SDK 本身的运行情况进行监控，将异常和错误及时记录并上报。

2.3.3 EQM 与 T-happyeyeballs

另一个影响规模化部署的因素就是用户体验保障技术，面临着 IPv6 基础生态发展的不平衡性带来复杂性挑战，以及复杂生产环境中 IPv6 的大规模应用挑战。

• 双栈覆盖（不同运营商、不同省份）发展不平衡

• 公网 IPv6 质量参差不齐

• 移动设备及网络环境的复杂性

⍟ 故障自动发现体系建设

从 IP 调度的角度，任何一个 IP 对某一个端侧设备是好还是坏，主要看以下两个核心指标：

• 连接成功率越高越好

• 请求耗时越低越好

通过这两个指标，结合以下多维度观测，理论上我们可以形成一个智能的调度平台，该平台可以自动发现问题并及时自动最优化调度：

图：故障监控维度覆盖

事实上，我们的“反馈监控—>故障发现—>自动调度”这个过程演进，经过了两个阶段：第一阶段是故障自动发现告警，人工及时干预调度；第二阶段是故障自动发现并实时自动调度。

在第一阶段，因为人工调度无法关注粒度太细的维度，我们主要关注以下三个维度的指标：地理位置（精确到地市）、运营商、平台类型，一旦实时统计发现某个 IP 在上述三个维度上有明显“偏差”（即从成功率与耗时两个指标上，与 IPv4 相比劣化明显），立即给运维人员发送警告短信和邮件，运营人员及时在发现故障的维度上把该 IP 给摘除，控制故障扩散，收敛故障影响。

在第二阶段，因机器可实现高频细粒度调度，我们通过基于拨测记录与业务结果反馈形成的数据，通过智能学习，在发现某个 IP 在某个维度上有明显“偏差”后，自动实现在故障的维度上把该 IP 给摘除，控制故障扩散，收敛故障影响。同时，相比人工告警的方式的，自动调度情况下系统关注维度的粒度与广度要高得多。

图：大规模智能调度示意图

前置网络质量探测

当前业界并无可供直接参考的无线 IPv6 质量数据，在无参考数据的情况下，应用侧直接灰度放量，样本质量波动大、噪点数据多，放量决策价值不高。在业务正式上线前，必须对整个网络有端到端的全景式观测，为业务放量、调度做到有效可靠支撑。

针对现有基础网络 IPv6 发展不平衡的问题，设计了主动式大规模网络质量拨测系统。通过调度大规模端侧设备对指定 IPv6 地址提前探测，实现对基础网络 IPv6 质量的提前测量；通过在大规模移动端实现 ping6、traceroute6 等拨测指令，满足对网络的细粒度全景测量。在该体系基础上，通过对不同省份、不同运营商、不同设备类型、不同无线环境多维度分析，实现基于用户侧的无线端到端大数据全景测量。

其中，拨测指令包含以下内容：

构建全球首个大规模无线 IPv6 监控体系，同时为国内运营商提供了可靠的问题发现与度量系统，进一步推动了国内 IPv6 演进速度。在应用侧为业务安全定向灰度放量提供可靠决策依据。

移动端业务 EQM（端到端质量检测）

前置探测并不能代表实际业务质量，因规模大、影响面广，业务运行期实时监控也是必不可少的环节。且实际运维中，故障的发现与原因排查，后续网络部署的优化与演进，均需要有效数据支撑。

PC 端业务 EQM（端到端质量检测）

当前 PC 端的性能监控方案主要是基于 js 采集浏览器 performance.timing 接口数据上报汇总计算实现的，因为浏览器并没有对 js 暴露当前是基于 v4 还是 v6 建立的连接，所以单纯通过 js 无法实现区分 v4 和 v6 的性能监控。

我们制定了一个通过后端应用 tengine 配合增加一个不影响页面展示 v6 访问特征，js 通过判断特征实现区分 v4 和 v6 访问，并且为 v6 设置单独的采样率，最终生成 v6 独立的性能报表。

⍟ 大规模精准化实时 IP 调度应用

针对现有公网 DNS 在 IPv6 流量调度风险不可控问题，设计了私域大规模精细化实时 IP 调度体系。通过对单个设备直接下发 IP 来满足风险控制需求；通过直接对端侧 IP 识别实现精准调度需求。在该体系基础上，通过单个设备的多维度信息识别，可在地域、运营商、终端类型等多个维度实现细粒度精准调度。并在发现 IPv6 业务故障后，云上大数据分析服务，通过端侧实时反馈，快速感知问题区域，实现流量的智能调度与恢复。

我们通过高频业务的旁路指令，调度指令下发由拉变推，实现基于“探针模式”的快速调度。

应用侧从原来的基于 Local-DNS 的间接调度升级为基于端侧设备直接调度，调度精度与时效大幅上升。产业侧为 IPv6 在应用上大规模落地扫清了障碍，极大加快了整个 IPv6 的发展进程。

T-happyeyeballs 基于移动应用的多 IP&多协议无损切换技术的应用

针对移动网络环境的复杂性及低可靠性，开发了移动应用的多 IP&多协议无损切换技术。通过多 IP 并行建连技术，满足端侧在 IPv6 下快速 Fall-back 需求。基于该技术，端侧具备快速的黑洞逃逸能力，能够在不依赖调度体系情况下快速的自愈。同时根据拨测与业务反馈上报到控制中心调整判断参数（比如某些型号、版本、某网络差的城市），依据综合指标进行不同滑落惩罚的时长。

在手机淘宝应用中，IPv6 失败率在 iOS/Android 双端分别只有 0.4%+/0.6%+。支撑集团 IPv6 活跃设备从 0 至全量过程中 0 故障。

在我们内部实验过程中，还进一步使用了多网卡切换技术。通过在 Wi-Fi 网络下强制数据连接到蜂窝网的能力，实现了在局部固网 IPv6 故障下用户新的无感迁移数据通道能力。

⍟ 应用体验保障实践效果（IPv6 体验指标体系建立）

经过多年沉淀，我们面向海量移动终端与云的 IPv6 商用部署与规模化应用，应对移动网络环境复杂性时不断增强 IPv6 inside 的终端网络架构及技术能力，支撑了 IPv6 端到端规模化创新应用，持续沉淀领域数据、引领 IPv6 体验 &质量标准。通过打造终端网络诊断工具、体系化数据平台，实现了 IPv6 的高质量体验。线上应用最新数据表明，淘宝的 IPv6 应用，在基础网络指标上已经全面优于 IPv4。

当然，用户面临的网络环境愈加复杂，例如家庭 AP 设备驳杂，地域/小运营商/城域网 v6 接入配置标准和启用程度参差不齐，会不断产生新的未知体验问题，这些都将是影响 IPv6 体验的不确定因素，我们将持续创新实践，确保 IPv6 体验质量不断破障。

2.4 运营体系

讲完了庞大的改造工程以及创新的技术亮点，我们技术分享又步入了另外一个重点的领域。IPv6 改造是一个长期的事情，需要有一套完善的机制确保其一直有效的运营下去。所以我们还需要重点介绍一下我们的流程体系，我们需要建立一套常态化的 IPv6 运营方案，IPv6 的技术已经纳入到阿里巴巴的技术文化中，不断的自我演进和迭代。

2.4.1 新增云产品及 APP url 管控体系建设

项目组在推进 IPv6 改造的过程中，业务也在快速的发展，会不停的有新增的 url 和云产品上线，上线之后改造的成本也会增加很多，为了更加高效的解决这个问题，我们会对新增云产品进行 IPv6 评审，为新增 url 上线时默认启动双栈。

2.4.2 版本发布测试体系

阿里的 APP 发版涉及到众多团队，原来已经完成改造的 url，可能会因为一次发布，而导致不支持 IPv6 的情况发生。为了更好的做到 IPv6 流量占比稳步提升，我们将 IPv6 流量占比测试纳入到日常发布测试流程体系中，这样在新版本上线之前就可以通过测试及时发现异常，然后更好的修复。

2.4.3 监控测试体系

主要分为两个大的方向，即全局监控和体验监控。全局监控重点检测 IPv6 占比监控和异常告警、降级率监控和异常告警，然后对异常情况进行及时的分析和解决。体验监控重点关注 IPv6 耗时监控和告警、长尾数据分析以及用户舆情监控。

✪ 故障管理体系

我们把 IPv6 流量占比异常下跌纳入到整体故障管理体系中，从故障前的故障等级定义、监控体系，到故障中的应急响应，再到故障后的复盘、演练。每次异常下跌都会明确原因，责任到人，持续改进，最终实现稳步提升。

✪ 奖励体系

我们通过建立阿里巴巴 IPv6“基石”奖，鼓励各 APP 及云产品进行规模化部署，同时鼓励项目组成员在 IPv6 技术创新及大规模应用上面做出贡献。

三、未来计划

今年我们同步启动了 IPv6 Only 的试点应用，为第三阶段 IPv6 成熟阶段做好技术储备。接下来我们还将尝试打造在用户上云的过程中同步实现双栈改造，这样会对企业的 IPv6 改造效率实现极大的提升。

面向未来的持续创新

P2P 的大规模推广，目前受制于 WiFi 终端 IPv6 支持度不高，在 P2P 的视频会议、通话及长短视频应用领域，IPv6 均无法很好的施展开来，随着规模化部署的推进，最终会迎来这一技术的大量普及和创新。

HTTP3 与 IPv6 的强强联合，rfc9114 使用 QUIC 协议作为传输层协议，可以有效地降低网络卡顿率和首包延迟。QUIC 是基于 UDP 协议实现网络通信，为了实现对 QUIC 协议的支持， SLB 上需要支持 DNAT 转发模式（注：在 UDP 通信中 SLB 的 FNAT 转发模式无法携带客户端 IP 信息）。DNAT 转发模式中，IPv6 的流量只能做 6 to 6 的地址转换，不支持 6 to 4 的地址转换。Aserver 进行 ipv6 双栈升级后，完成了在 IPv6 网络链路中 DNAT 转发模式的后端支持，从而实现了整个 ipv6 网络链路上完整地支持 HTTP3 协议。

手淘客户端发起 IPv6 的 HTTP3 请求，源目的 IP 分别是（CIP，SIP），SLB 通过 DNAT 转换将请求的源目的 IP 转换成（CIP，RIP），转发给 Aserver；Aserver 获取 HTTP 响应数据后，封装源目的 IP（RIP，CIP），将 HTTP3 响应发送到 SLB 上，SLB 将源目的 IP 转换成(SIP，CIP)后，将 HTTP3 响应数据发送给手淘客户端。

总之，IPv6 的发展是一次难得的机会，当然整个过程非常艰难，但如果我们克服这些困难，会为未来在互联网领域的持续创新积累下丰富的经验，打下扎实的基础，创造良好的环境。

参考文献

[01] 关于加快推进互联网协议第六版（IPv6）规模部署和应用工作的通知

http://www.gov.cn/zhengce/zhengceku/2021-07/23/content_5626963.htm

[02] 邬贺铨：加快 IPv6 规模部署支撑网络强国建设

http://www.cac.gov.cn/2022-03/30/c_1648522019215113.htm

[03] Linux 3.10 内核锁瓶颈描述以及解决-IPv6 路由 cache 的性能缺陷

https://blog.csdn.net/dog250/article/details/91046131

[04] Department of State Internet Protocol Version 6 (IPv6) Policy Statement - United States Department of State

https://www.state.gov/department-of-state-internet-protocol-version-6-ipv6-policy-statement/

[05] ipv6: Use math to point per net sysctls into the appropriate struct net https://patchwork.ozlabs.org/project/netdev/patch/20200303065434.81842-1-cambda@linux.alibaba.com/

[06] https://nvd.nist.gov/vuln/detail/CVE-2022-1678

[07] IPv6 详解 卷一：核心协议实现【M】，北京：人民邮电出版社，2009.

[08] 一种流量控制方法及装置，CN106603256B

[09] 一种流量隔离方法及装置，CN106528362A

[10] 服务限流系统、方法、装置及电子设备，CN111367651A

[11] 速率控制方法、装置及电子设备，CN110278160A

[12] 一种流量控制方法、装置及设备，CN111385214A

[13] 压测过程中的流量调度方法、调度平台和调度系统，CN107872397A