![]()
作者：吴灵晓(盖优)
演进路线
![]()
![]()
阶段一（2020年末）
本阶段完成线上所有服务的IPv6改造，全面支持IPv6双栈的访问支持；融入阿里云的IPv6生态体系，内网环境全面支持IPv4/IPv6双栈；提升用户端侧IPv6流量占比，IPv6流量占比不低于总量的40%。
- 管：全面完成优酷主站广域网、集团级数据中心核心网络、互联网出口IPv6网络改造，IPv6在多地域多运营商开通。汰换无法通过升级支持IPv6的核心路由器，交换机。建立CDN专属资源池，全部选用支持IPv4/IPv6的CDN节点。引入IPv6-only的专线链路，适时降低IPv6接入成本；
- 云：全面完成企业互联网域名服务器IPv6改造，支持AAAA记录和IPv6域名解析请求，主要核心业务域名全部配置A及AAAA记录。使用阿里云HTTPDNS服务，支持移动端的IPv4/IPv6双栈及IPv6-only环境下的域名解析能力。优酷相关的服务及接口全面上云，新增的ECS，CDN等资源全部选用支持IPv6区域的资源产品；
- 端：各手机端应用APP以及web浏览器端全部支持IPv4/IPv6双栈及IPv6-only环境下的网络通信能力。尝试引入用户功能体验引导方案，让用户可以直观地体验到IPv6带来的收益。端侧测试 IPv6流量占比不低于总量的40%；
- 安全：全面完成优酷互联网出口安全防护系统的IPv6改造，应用内的安全防护插件全面支持IPv6环境，确保整体安全防护能力不下降。建立IPv6下独立的监控体系，覆盖基础监控及应用监控，具备和IPv4相同的监控能力。
阶段二（2021-2022年）
本阶段全面支持IPv6-only的访问支持；全部融入阿里云的IPv6-only生态体系，内网环境全面支持IPv6-only双栈；IPv6双栈+only比例不低于80%， IPv6流量占比不低于总量的60%。
- 管：全面完成主站机房及CDN节点机房的IPv6出口改造，包括所有内地以及热门海外节点。IPv6流量全面跑在专用链路上，全面实现IPv6下的流量收益能力；
- 云：全面完成企业互联网域名服务器IPv6改造，支持AAAA记录和IPv6域名解析请求，所有业务域名全部配置A及AAAA记录。优酷相关的服务及接口全部使用IPv6环境的资源产品，内部网络环境全部切换到IPv4/IPv6双栈模式；
- 端：全端全站支持IPv6-only访问，用于体验无差异化。用户产品体验设计上全面倾向IPv6，引导用户汰换老设施老终端。IPv6双栈用户比例不低于80%，并逐步引导IPv6-only模式；
- 安全：进一步强化IPv6的网络安全能力，全面提升防护等级，及时发现并解决IPv6环境下衍生出的新业务形态的安全挑战。对边缘计算、物联网、车联网、云游戏等新领域，具备全网同等级别的安全保障能力。
阶段三（2023-2025年）
本阶段全面完成所有机房及CDN节点的改造，全部支持IPv6-only的访问；IPv6-only比例不低于80%， IPv6流量占比不低于总量的80%。
- 管：全面完成IPv6-only改造；
- 云：全部使用云上产品，所有产品都支持IPv6-only；
- 端：IPv6-only比例不低于80%，淘汰双栈模式。对不足20%的IPv4用户提供最小功能集的降级服务，鼓励升级到IPv6-only；
- 安全：进一步强化IPv6-only场景下的安全防护、安全监管、灾难备份与恢复等能力，提升IPv6环境下娱乐网、物联网、车联网、云计算、云游戏、VR/AI智能等领域安全保障能力。
实施指南
网络
机房互联网出口
建设改造中心机房IPv6互联网出口
跟随阿里集团整体节奏，核心服务所在的中心机房全部完成互联网出的改造，支持IPv6。在五大城网出口所在地的中心机房，全部完全IPv6改造。优先选用BGP对接方式，方便互联网出口域内域外路由协议的统一规划。提前做好IPv6降费提速准备，优先调度IPv6流量，提高IPv6流量令牌优先级，在同等环境下优先路由。
建设改造CDN节点机房IPv6互联网出口
由阿里云进行统筹安全改造地域与时间节点，业务同步做好按地域引流工作。
改造升级骨干网VIP+LVS
替换不支持通过升级支持IPv6的老旧设施，包括大量的核心路由器，交换机及负载均衡设备。对互联网出口部分的硬件防火墙、入侵检测设备等安全防护设备进行更新，不支持更新进行替换。优化路由配置，路由配置及缓存使用配比，使改造后的IPv4网络性能不下降的同时，IPv6网络性能略优于IPv4。各安全防护能力达到与IPv4出口等同或者优于IPv4环境下的防护能力。
改造升级应用服务测试环境
通过隧道方式打通生产机房与测试机房之间的IPv6链路，升级企业跳板机代理服务器支持IPv6，支持IPv6环境下登录测试环境满足业务需求。
改造企业园区网络VPN系统
携同阿里企业智能网团队进行IT办公网络的改造，接入IPv6互联网出口，升级园区内路由器交换机以及VPN设备。升级VPN客户端，支持IPv6环境下的用户远程登录，完善远程接入环境IPv6安全防护策略，强化IPv6安全防护能力。
域名解析DNS/HTTPDNS及回落
业务域名网络双栈设计及开启
DNS核心升级：对业务域名开启多CNAME能力。业务域名分别配置IPv4-only及IPv6双栈的CNAME域名，具备权重调节能力。可以按地域按运营商自由地控制IPv4及IPv6双栈折解析比例。对走localdns的PC/H5端进行IPv6的灰度流量控制，实现IPv4协议和IPv6协议共存。IPv6->IPv4的回落能力由浏览器提供，部分过旧的浏览器不支持快速回落能力。
HTTPDNS核心升级：HTTPDNS服务本身部署在IPv6环境，具备IPv6互联网出口，提供IPv6 VIP及域名AAAA解析保障。同时，升级HTTPDNS服务本身，可以根据请求客户端的网络状态，以及用户请求参数，对请求的域名下发AAAA解析记录，确保客户端运行在IPv6环境中，可以正常解析到业务域名的AAAA记录。
HTTPDNS的快速回落：HTTPDNS在获取到客户端支持IPv6时，会把域名的AAAA记录及A记录同时下发给客户端。当客户端建联IPv6不成功时，会同时开始建立IPv4连接，以确保用户体验无影响。
同时，针对一些特殊的业务域名，例如：没有实现PC端降级以及对降级产生的延迟无法容忍。可以去掉权威DNS中业务域名的AAAA记录，将AAAA记录只配置在HTTPDNS中，可以满足客户端走IPv6，PC端走IPv4，既满足了IPv6的需求又可以让PC业务无损。
动态IPv6比例控制能力
IPv6建设初期，建连成功率低于IPv4，RT也高于IPv4，导致业务无法整体切换到IPv6。同时，已经切过去的部分，也可能因为网络变更影响网络质量，需要临时关闭IPv6。这些切换操作，如果都由运维同学手动操作的话，那么像优酷这样有几十上百个域名的，完成一次操作需要花上1-2天的时间，时率上不可接受。因为需要建设一套包含DNS以及HTTPDNS的域名切换系统，可以批量切换域名及HTTPDNS的配置，做到PC和移动端的业务同步。同时，切换时要具备弹性能力，IPv6从100%降到0%，不能一下子切掉，需要90%-80%-70%----0%执行，确保不会给网络设备和服务器以及网络出口带来跳变。同时，需要获取业务成功率的监控数据，如果切换过程中，成功率出现下跌的话，系统能够中止切换或者自动回滚到上一级比例，发出报警让运维同学介入排查。
网络质量数据获取设计
客户端埋点上报支持IPv6
在手机客户端以及PC端中，通常会使用埋点技术将端侧运行数据及错误情况，上报至采集服务器。大部分的数据上报中，并不会主动将客户端的IPv4及IPv6都带上，导致服务端并没有可靠的数据来源去分析IPv6下的业务情况。所以，需要改造采集服务端，支持和客户端进行IPv6建连，确保在IPv6双栈及IPv6-only环境下埋点数据可以正常上报。同时，在app启动，用户鉴权，网络变化等场景发生时，主动从服务端的应答结果中取到客户端的出口IP，并把这些信息存储在本地缓存中，在埋点上报时带上IP地址。这样采集端就可以收集到客户端的真实出口IP，如果的双栈的话，还可以同时收集到IPv4,IPv6地址并自动关联。从根本上解决了双栈环境时，服务端无法同时获取IPv4,IPv6的问题，有助于网络质量数据分析。
资源管理、运维系统改造
实现IPv4,IPv6资源区分管理能力
随着IPv6深入改造及政策支持，对使用IPv6环境的资源设备，流量带宽，调度引流等，将出现区别于IPv4环境的使用场景和计量计费规则。慢慢地IPv6将会在某些应用场景上出现成本上的优势，而现有的资源管理系统上新建网络管理、应用性能管理、认证服务器、DNS/DHCP等支撑系统推荐采用IPv6单栈建设，存量支撑系统推荐进行双栈化改造，具备对IPv6设备、应用或用户的基于机器学习、知识图谱、神经网络等AI加持的智能运维、终端识别、应用识别、智能调优、智能漫游、大数据安全分析等管理能力，待网元设备、应用或用户完成IPv6单栈改造后，支撑系统需同步完成IPv6单栈切换。
实现IPv6环境独立运维能力
改造并开启运维系统双栈协议，使系统具备在IPv6网络环境下对双栈服务器、网络设备、应用容器、监控采集、数据库缓存中间件、配置远程推送及用户数据的管理能力。对于暂时不支持IPv6的系统及设备，提供NAT地址转换、降级IPv4等方式，来进行管理，待改造完成上线后，逐步开启IPv6能力。
应用与服务
接口服务及PC端页面
新建应用
新建应用的部署，选用支持IPv6的主站机房资源或者阿里云地域，机房出口到负载均衡使用双栈标准。
- Web容器环境：选用支持IPv6协议的最新版本Tengine，安装toa模块，支持透传IPv6头信息至应用服务。
- 开发环境及OS系统：应用的开发编译选用支持IPv6协议的操作系统，如Windows server 2003以上版本、MAC OS 10以后，以及Linux系统的CentOS 7或者Alios 7U等。
- 测试环境：办公网环境与测试机房通过IPv6专线打通，办公网提供IPv6的无线/有线接入点，同时保留了原来的IPv4接入点。开发同学可以接入IPv6接入点进行日常开发和办公事务处理，需要访问不支持IPv6的公网服务时，可以切换到IPv4网络环境。
- 业务场景1 IP地址库：使用IP地址库服务对用户归属地进行定位判断处理的，需要升级到最新版本的IP地址库数据服务，并具备定期升级能力。确保IPv6地域归属判断的准确性。
- 业务场景2 IP地址格式统一：因为IPv6地址可以略写的原因，导致直接按字符串进行判断的话，会把有略写和无略写的IPv6判断成不是一个IP地址，从而导致业务处理出现偏差。同时，部分浏览器请求会自动略写IPv6地址，JAVA网络包,CURL等，不会主动略写IPv6地址，这会增长服务端处理的复杂性，所以需要前置一个公共处理，将所有的IPv6地址都经过公共处理进行标准化，统一业务处理逻辑，减少业务间不一致问题。
- 业务场景3 IP地址保存：一般服务端日志落库，用户信息落库等常规处理中，会把用户IP保存到数据库等存储中，对于严格限制数据类型和长度的数据库，需要依据存储型号进行定义，原来的IPv4只需要32位字符串或者长整型数据就可以保存，而IPv6需要扩大到128位，同时长整型也存不下，需要高64位和低64位拆分存储等方式进行处理。
- 业务场景3 接口传递：某些使用http get方式将多个用户IP通过参数形式传递时，需要注意get的1024B的上限，原来传递IPv6时10个用户一起传递没有问题，但现在改用IPv6时10个用户的IP长度就会超过get上限，需要改用post或者调低上限。
- 业务场景4 存在IP地址的hardcopy：不能把上下游调用接口的IP地址直接写在代码中或者配置文件中，因为上下游完成IPv6改造的时间并不完全一致，上线时间也不一致，会导致出现线上故障。需要全部改为域名方式调用。
- 客户端IP出口地址的取得方式：在双栈环境中，同一请求，你只能从请求头部中获取到IPv4 IPv6地址中的一个，不可能两个都获取。如果希望同时获取IPv4 或者IPv6地址，那么只能选择重复请求，或者是通过参数将客户端地址传上来。需要扩展请求字段，将v4,v6分成两个字段提交，同时服务端也需要做接收改造处理。
- 日志分析逻辑：众所周知，为了方便日志分析和拆解，所有的业务日志都会定义一个统一的格式，日志输了的各个字段之间统一使用||等分隔符分隔或者按字段长度固定。使用分隔符的，需要考虑到不能再使用:了，因为IPv6中带了这个符号。使用固定长度分隔的，也需要考虑到对IP地址不能再固定32位长度了，要调整到128位，同时要向下兼容IPv4，IPv4也要补齐到128位。
- 第三方库的更新：选用支持IPv6协议的第三方SDK版本，如果三方库不再更新支持IPv6，那就需要寻找置换方案。
- 安全部署环境：接入层安全控件，限流插件，ACL白名单插件等应用安全服务应支持IPv6协议。
- 降级能力：需要从业务逻辑上原生考虑IPv6网络不可用时，如何降级至IPv4来继续提供服务。
存量应用改造
存量应用可进行代码IPv6重构开发或双栈支持接口开发。对于不支持IPv6改造或者暂时无法改造的，需要单独划定小集群区域，来提供IPv4-only的服务能力。
- 接入层改造：制定IPv6升级计划，申请IPv6的VIP，将负载均衡的RS指向新的IPv6接入层，确保IPv4与IPv6的流量隔离。
- 基础镜像升级：原业务使用过旧，版本过低的OS镜像打包时，需要升级到最新支持IPv6的基础镜像，并用最新的OS进行编辑打包。
- 业务系统改造：依据上述新建应用的业务场景梳理内容，对存量业务逻辑进行排查，存在上述场景的需要进行业务代码的重构，业务逻辑的修改，使存量业务满足IPv6环境下运行需求。
- 替换Web容器环境：升级最新版本Tengine，升级最新toa模块，支持透传IPv6头信息至应用服务。
- 升级开发环境及OS系统：应用的开发编译选用支持IPv6协议的操作系统，如Windows server 2003以上版本、MAC OS 10以后，以及Linux系统的CentOS 7或者Alios 7U等。
进行IPv6测试环境下的回归测试
存量应用一般都经过严格的IPv4环境下测试，但不能保证在IPv6下一定是没有问题。所以需要在IPv6的测试环境下，对存量应用以及新建应用进行回归测试。包括对所有有改动功能点的全量测试，以及没有改动但属于核心功能点的覆盖性测试。
验收
应用改造完成后，进行线上灰度验收，按照国家网站/应用IPv6升级改造验收督查指标相关要求进行测试验证，在域名IPv6支持度、页面IPv6可达性、业务IPv6支持度、应用服务质量、IPv6安全防护等方面开展测试。
移动终端及APP
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变化等，需要根据业务逻辑和用户操作场景，进行埋点的改造。
大屏OTT端
大屏端的硬件汰换率低于手机端，大量不支持IPv6的老设备还在继续使用着。大屏端APP使用的基础架构需要和安卓手机端进行统一，在APP层面上支持IPv6网络环境下的正常使用，参考上述安卓手机端进行改造。对于硬件部分，能通过升级OS固件方式来支持IPv6的，要积极推动硬件厂商进行并推送更新。无法通过升级方式来支持，考虑到硬件的整体使用周期及寿命，逐步提醒更新。
云及CDN
云产品的选型
新建场景
跟据阿里云的IPv6改造计划，选用已经完成改区域的云产品，使用业务原生支持IPv6环境。
存量场景
因为云产品支持IPv6后需要对原产品进行升级或者置换后，才能开启IPv6支持，所以对于存量使用的云产品，有一个迁移的过程。需要把流量迁到已经改造完成的地域后，对原有地域的云平台进行双栈化改造，包括ECS，ENV容器集群控制中心、容器编排系统、VPC/虚拟网关、负载均衡等进行IPv6支持改造，释放原有资源重新申请新的IPv6资源，来快速获取IPv6支持能力。改造完成后再把流量逐步切回，释放掉临时资源。
CDN的IPv6支持
普通加速域名
依据阿里云CDN改造计划，将各地域各运营商已经改造完成的IPv6 CDN节点加入到调度域。调度算法需要支持IPv6 VIP，当区域内IPv6节点资源不足或者没有IPv6节点时，是进行跨省跨区域调度，还是降级IPv4。从用户体验角度来说，IPv6资源不足时降级IPv4是对用户没什么影响的。也可以通过计算支持IPv6的CDN带宽与总带宽的比例，并确定各地域的IPv6引流比例。阿里云控制台开启IPv6功能，并配置图片域名的灰度比例。从流量入口上就控制处IPv6的灰度总量，确保不会出现IPv6资源不足或者无资源可调度的问题。
302调度域名
302域名跳转时，会有前述IPv6地址缩写的问题，浏览器访问时会自动用缩写后的IPv6地址跳转，APP内使用libcurl等网络库时，并不会触发自动缩写，以获取到的IPv6地址原样进行请求。需要302节点配置缩写前和缩写后两套IPv6的VIP，确保任何场景下都可以跳转。在HTTPS的VIP证书中，需要加签IPv6的VIP，确保https下也可以正常跳转。
免流域名
免流调度域需要分配IPv6的VIP组，将需要向运营商报备的免流节点IP都划入进去，并且具备IPv6功能的开启和关闭能力，确保在运营商报备完成前不启用IPv6节点，运营商报务完成后又能及时启用节点，避免出现免流失效或者免流调度域水位过高的问题。
安全
IPv6网络安全整体原则：配合IPv6演进的不同阶段，明确网络、服务、应用app以及新业务场景下，IPv6网络安全的能力范围和保障方案，强化IPv6安全防护能力以及多端共享、边缘计算、云游戏、物联网等新型业务场景下的安全防护能力。
限流能力
限流能力需要具备IPv4/IPv6双栈场景下的应用能力，能够对总流量进行限制，也可以分别对IPv4,IPv6进行限制。具备在系统能力饱和的情况下，怎么样优先让IPv6的请求能力尽快得到处理并响应，保障IPv6优先的用户体验。
ACL黑白名单及安全策略
确保IPv6安全体系防护的完整性与高效性，对防火墙、入侵检测、行为审计、流量清洗等网络安全设备，进行统一升级以支持IPv6环境下的正常工作。随着IPv6的发展，IPv6的地址数量将远远超过IPv4，现有的ACL黑白名单容量将无法满足，需要提前进行扩容改造。对于IPv6安全防护能力存在风险的节点，应进行网络安全设备升级或替换。从应用业务层面以及安全管理层面进行IPv6安全策略制定与配置，保证IPv6的安全策略包含了所有的IPv4策略。
IPv6+创新
IPv6+5G
随着移动互联网的发展，越来越多的设备接入到移动网络中，从某种程度上来讲，5G和IPv6是相辅相成的，目标是一致的，都是尽可能将更多的设备互联，达到万物互联的境界。IPv6解决了万物互联上设备数量受限的问题，因为地址数量不足，IPv4可能无法满足每一个人都接入10设备。接入IPv6的话，别说每个人10个设备，10亿个也没有问题。同时，5G是解决了万物互联质量上的问题，高速率低延迟是5G网络的核心优势。量和质的问题，被IPv6+5G一起给解决了，移动设备的需求爆炸式增长的时代还会不到来吗？5G的技术应用得到了极大的满足，当成本降至合适程度时，IPv6+5G可以替代wifi，不再需要NAT地址转换，不需要切换流量。只要安全能力满足，你和世界都是实时联通的。
IPv6+P2P分享
可以想象，今后家中每个带电的设备都会成为计算中心，娱乐中心，看优酷将不再受限于客户端设备，走到哪里看到哪里，每个人都会是内容的消费者同时也会是内容的生产者，片段化的时间能够最合理的利用，最大程度解放双手，随时随地享受娱乐盛宴。
那么这就代表着一个终端既是服务提供方，又是服务消费方，既要为其它设备提供请求入口，又要主动请求其它服务。现有IPv4+NAT方案，限定了P2P分享的范围，最终能共享到的资源及数据很少，IPv6下理想状态是全网都不再需要NAT，任何设备不需要做地址转换都可以直接请求到网内的所有设备。这样就极大的推展了P2P可达范围，资源及数据几乎可以全覆盖。我为人人，人人为我，全面符合我们的政治远景。
关注【阿里巴巴移动技术】微信公众号，每周 3 篇移动技术实践&干货给你思考！
