导读：随着5G的落地，今年，很多用户将5G手机提上日程。但你知道吗？就像路上行驶的汽车必须有号牌一样，每一个设备接入5G，至少需要一个IP地址，用以表示它在网络上的存在。而目前全球的IPv4地址已经耗尽，所有43亿个IPv4地址已分配完毕，这意味着没有更多的IPv4地址可以分配给ISP和其他大型网络基础设施提供商。所以，大家将目光投向了下一代网络协议IPv6，其地址数量号称可以为全球的每一粒沙子编上一个地址。

作为5G的基础架构，优酷从2018年开始IPv6 的全业务改造，从技术策略到全量部署上线总耗时6个月。作为项目的深度参与者，阿里文娱技术专家盖优将详解分享这一技术过程，希望对大家有启发。

作者 | 阿里文娱技术专家 盖优

责编 | 屠敏

概述

什么是IPv6？IPv6=互联网网络层传输协议第六版。广义的讲，IPv6 就是下一代互联网的基础设施，5G 物联网的核心基础。与现行IPv4 相比，它更安全，更高效，更省成本，几乎用不完的IP 地址，业务无限拓展。

本文将详解优酷IPv6技术改造实践，包括遇到的实际问题、技术解法，希望对大家有借鉴。

1.背景

Internet 在形成及演化的初期，经历了一个纷繁复杂的过程，随着网络技术的发展，以IP 协议为核心，包括：地址格式、数据封装及数据转发等Internet网络结构的基本框架，已经稳定 运行30多年不曾改变。5G来临的时候，Internet的现有结构无法快速适应用户及上层应用需求。主要体现在以下几点：

1）IPv4 资源枯竭：海外大量购买资源，私网地址仅可支撑三年；

2）IPv6 用户增长：海外美国50%，印度、欧洲20%；

3）Apple 审核：2016 年6月起，Appstore 就开启了IPv6 only 审核；

4）商业竞争态势：Google、Facebook 已覆盖50% IPv6 终端，IPv6 云产品发布；

5）战略意义：由于IPv4 报文的限制，使得域名根服务器的总数有限制。IPv6 出现以后，这个限制被打破，可写入更多的根服务器地址。目前，全球已完成25 台IPv6 根服务器架设，中国部署了4台，打破了中国过去没有根服务器的困境。

（图 全球 IPv6 根服务器分布）

2.目标阶段

优酷IPv6 项目将分成二步走，包括IPv4/IPv6 双栈阶段，以及内外网IPv6-only 阶段。

1）IPv4/IPv6 双栈改造：实现应用快速对外服务，以Web/APP 请求服务为核心，满足IPv6生态发展的需求，并且以外网拉动应用的不同需求。爬虫、邮箱、DB、存储等直接交互，需要内外网服务器采用IPv4/IPv6 双栈能力，整网双栈交付；

2）IPv6 Only：当超过50%应用逐步迁移到IPv6 后，新应用采用IPv6 准入，遗留一些老旧应用继续采用IPv4 服务，内网采用4over6 进行封装。相对双栈而言，IPv6 only 成本更低，查表转发速度更快，只需维护一套协议栈，全面开启IPv6 only 时代。

3.实施周期

优酷2018 年6月开始，实施了IPv6 的全业务改造，完成客户端及服务端改造，实现应用快速对外服务。2018 年底，实现全量部署上线，总耗时6个月。所以，与优酷同等用户规模和服务体量的企业，基本上6个月甚至更短的时间就可以完成整体IPv6 的改造。

（图 优酷 IPv6 改造计划）

遇到的问题点及解法

IPv6 整个改造过程中可能会遇到的几个典型问题和解决方法，简单的总结如下：

1.没有IPv6环境

众所周知，一般应用从开发到上线，至少要经过开发测试环境、预发环境、Beta 环境，最后上正式环境。一开始，基础环境还没有具备的时候，我们使用IPv6 over IPv4 链路VPN 的方式连入测试环境 ，需要PC/客户端加证书改Hosts，移动端无法改Hosts 的，需要root 越狱。然后，我们加强了基础网络和IT合作，在多个阿里园区部署多个IPv6 的接入环境，打通IPv6 出口，打通办公网和机房的IPv6 链路，实现慢慢外网IPv6，日常环境通、预发通、正式通，慢慢使业务能够测试逐步提升到IPv4 相同的测试体验，通过域名劫持等手段，跳过了Hosts 配置的尴尬，达到标准的测试效率。

2.OS网络模块问题

需要让容器支持从请求头部获取IPv6 地址，那么就需要把用户IP一级一级透传过来，就需要在各级的服务器上升级网络模块，扩展报文头部。例如TOA 模块，TOA 模块是为了让后端的Real Server 能够看到真实的ClientIP 而不是LVS的DIP。同时，Tengine/Nginx 等应用需要 升级到支持IPv6的版本（支持新TOA模块等），由于历史原因存在各种老版本无法升级，导致升级受阻。我们通过推动应用接入统一接入改造，避免自行升级网络模块带来的风险。

通过老版本应用的升级，去Nginx的方式，统一升级安装Tengine-proxy（安装在ECS 测试 机器或宿主机上都可以），为了能减少业务改造工作量，在接入层架构我们做了大量的改造。

3.地址库特殊需求

首先，统一IP 地址库，要求所有业务必须统一使用IP 地址库。其次，协调集团地址库生产方，满足优酷使用场景需求，使统一过程中业务改造工作量减少。再次，对于广告等必须要使用行业统一地址库的场景，我们也制定了多套方案去解决。

兜底方案：将广协地址库中的地区编码，加入到集团地址库中，使集团库具备行业库的能力，在行业库没有完全产出之前，广告业务可以临时使用集团地址库进行改造和测试，保障业务不受损。

长期方案：主动出击，联系广协等行业协会，加快产出IPv6 地址库，并且主动无偿提供阿里集团地址库数据，更加快了整个广协会员单位的改造进度。

4.MTU问题

IPv4 时代，中间网络三层设备会进行分片，所以一般设置为1500 的最大值，以降低网络开销。但IPv6 协议为了减轻中间网络层设备繁杂度及成本，中间设备不再分片，由两端的协商指定。导致默认mtu1500 的情况下，中间设备出现大量丢包，原因是NAT 转换，TCP Option 等额外叠加，实际超过1500。开启SYN Proxy，通过MSS 与端进行协商，调整MTU 为最小值1280。发现中间层MTU 小于1280 时，进行网络报障等办法。

5.客户端是否IPv6，如何验证

这是一个很现实的问题，我的网络已经是IPv6 了，业务也能正常运行，但怎么确认网络是运行在IPv6 上，没有被降级呢？主要有以下两个手段：

1）抓取客户端日志：这也是最笨太最准确的手段。具体抓日志的方法有很多，就不再重复介绍了；

2）业务改造，加入网络检测能力：将优酷客户端当做网络测试的工具。

6.协议回落问题

（图 协议回落）

7.CDN灰度问题

CDN域名由阿里云等CDN 服务提供商进行调度控制，用户请求链路和业务服务是不一样的，导致业务服务是IPv6，CDN 走的是IPv4；也可能CDN是IPv6，业务服务是IPv4，无法和业务统一灰度范围。

解决方案：使用HTTPDNS 能力，让CDN域名和业务域名共同管理，同步开启灰度的地域和运营商。同时，增加IPv6专属CDN 域名，APP 侧通过业务侧增加业务逻辑，分别下发不同的域名来实现同一灰度节奏能力。当业务服务返回客户端的出口IP是IPv6 时，调用IPv6的CDN 域名；当业务服务返回客户端的出口IP 是IPv4时，调用IPv4CDN域名。

架构设计 （图 优酷 IPv6 改造架构图）

从客户端到服务端，所有涉及到的设备、网络、APP、服务器、业务等都是改造范围。

1）用户端的网络，包括移动网络和局域网：这部分移动网络依赖运营商，目前三大运营商的4G IPv6 支持率>70%，固定宽带内部局域网等总体支持率不足3成，家庭路由器等也需要升级；

2）用户终端设备：依赖手机等终端设备厂家更新升级固件，小品牌的终端就听天由命了。部分安卓手机需要分配到64 段的IPv6 才能正常连接上IPv6 的Wi-Fi；

3）OS/浏览器：依赖苹果、谷歌等的更新节奏，需要客户端OS及浏览器都更新至最新版本，老OS 基本不支持；

4）客户端APP/PC 端网页：网络底层包需要支持IPv6 以及降级能力，实施方案中详细说明；

5）HTTPDNS：基于一定的策略对支持双栈网络的客户端下发IPv6 地址，需HTTPDNS 端改造支持；

6）Local DNS：需要DNS 支持IPv6 解析，同时域名解析记录中添AAAA 记录；

7）网络链路：运营商需要支持 IPv6，包括用户端的出口网络和服务端的机房出口，网络路由等；

8）LVS：所有服务的出口，需要支持IPv6，将请求转发至RS（反向代理服务）

9）反向代理层：将请求转发至具体业务服务器，并带上客户端IPv6 地址；

10）业务服务：请看下一节。

详细实施步骤

整个改造过程包括：客户端APP及PC/H5 端/业务服务端的改造，安全测试及灰度保障能力。

1.客户端APP

1）更新网络底层包：涉及到集团二方包或者第三方网络库的，需要升级到最新版本。第三方网络库需要确认具备IPv6 能力，否则需要重新选择其它网络库；

2）升级IP地址库：端上集成有IP地址库的，需要升级到包含IPv6 记录的IP 地址库；

3）升级HTTPDNS 服务库：使用HTTPDNS 服务的，需要确认支持AAAA 记录的下发；使用Local DNS 解析的，需要改造实现DNS 服务请求参数中添加AAAA 记录解析的标识；

4）改造支持降级能力：使用三方库已经具备IPv6 链路质量不佳时自动降级IPv4 能力的，可以不改造。否则，需要业务或者架构侧进行IPv6 网络质量的判断，并实现降级功能；

5）探测埋点改造：弱网、DNS 耗时的情况下，探测能否正常，IPv6下埋点是否正常上报；

6）测试手法：所有功能需要在IPv4 only，IPv6/IPv4 双栈测试通过。IPv6 only 有条件时也需要测试通过。

2.业务服务端/PC端/H5端

1）IP 地址库使用：是否有用到地址库，对用户IP进行地域来源等判断。有的话需要升级到IPv6 地址库，并更新调用方法；

2）IP 地址格式判断：是否对用户IP 进行验证，有的话，需要加入IPv6 地址格式的正则表达式判断；

3）IP 地址保存：是否对IP有存库等保存操作，需要修改相应字段的长度，IPv6 长于IPv4， MySQL建议字段类型VARBINARY(16)；

4）依赖链路上的修改：是否会将IP 作为接口参数传递给下游依赖业务。有的话，下游依赖业务也需要改造；

5）客户端IP 地址的取得方式：如果从客户端请求的头部获取，那么在双栈环境中，同一请求，你只能获取到IPv4 和IPv6 地址中的一个，不可能两个都获取。如果是通过请求正文中的某个字段，把客户端地址传上来的，那么，你需要考虑是否需要获取客户端的v4 和v6 的所有地址；

6）日志：当用了第三方的采集工具，如果采集工具不支持IPv6 的话，那么采集上来的数据会和服务端的请求日志无法对齐，产生GAP。所以第三方数据产品等都需要能够支持用户IPv6 数据的采集；

7）监控：存在用户IP 作为判断条件/统计条件的监控配置时，需要改造；

8）大数据统计：存在用户IP 作为判断条件/统计条件的内容时，需要业务改造。

3.安全，测试及灰度保障

主要包括上线前的测试保障及上线后的灰度引流能力。

1）测试保障：抓取客户端日志；客户端业务改造，加入网络检测能力；客户端增加IPv6 链路日志，服务端日志工具支持对IPv6客户端地址进行分析汇总；IPv6流量压力测试能力；模拟IPv6 网络限速，延迟增加能力。

2）灰度引流能力包括两种方式：

HTTPDNS 方式：基于用户设备的白名单；基于地域+运营商+百分比+用户设备白名单；基于APP 版本的全量百分比。

LocalDNS(ADNS)方式：ADNS 新开发并上线了一个能力，支持一个域名下配置多CNAME 解析功能，并且每条解释都可以配置权重，通过修改IDNS 的CNAME 权重配置来达到比例控制。同时加上自有的线路和运营商的选择能力，满足地域级的灰度需求。

3）自动化能力：我们开发了自动化的灰度系统，根据起始参数和灰度目标，自动规划灰度比和时间节奏，实现完全自动化的灰度引流。监控预警+自动回滚能力，边喝咖啡边看灰度量，就是这么简单。

小结

IPv6还处于过渡期，目前是IPv4/IPv6双栈发展阶段，需要技术和产品特别关注在双栈环境下才会出现的问题，而这些问题几乎没有资料可参考，非常考验运维团队的应变能力。以下是我的一些建议：

IPv6地址还在不断分配中，IPv6地址库的建设将是一项长期工程，当IPv6归属地与IPv4归属地存在偏差时，优先信任哪一边，需要结合业务特点做判断； IPv6建设中最大的投入是监控能力的改造，要让业务监控全部支持IPv6，否则将无法发现IPv6的网络问题。在双栈环境中，不要用总量模式观察，要在各自的协议栈中观察； 双栈特有的IPv6回落IPv4的降级能力，Web端业务不要过度的依赖浏览器的能力，因为有些时候它并不靠谱。可以常识拆分业务域名，判断用户环境及网络质量，不同的环境给出不同的域名，来实现降级能力； 双栈环境下，一个完整的业务流程，可能一部分走IPv4，一部分走IPv6。当业务出现问题时，需要足够的埋点用来定位原因，因为有些场景下很难再现问题； IPv6的改造，更多是面向5G为未来的业务场景布局，当下的用户体验并不明显，所以不需要向产品强调性价比。