作者:吴灵晓(盖优)
演进路线
阶段一(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智能等领域安全保障能力。
实施指南
网络
1 机房互联网出口
建设改造中心机房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安全防护能力。
2 域名解析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%执行,确保不会给网络设备和服务器以及网络出口带来跳变。同时,需要获取业务成功率的监控数据,如果切换过程中,成功率出现下跌的话,系统能够中止切换或者自动回滚到上一级比例,发出报警让运维同学介入排查。
3 网络质量数据获取设计
客户端埋点上报支持IPv6
在手机客户端以及PC端中,通常会使用埋点技术将端侧运行数据及错误情况,上报至采集服务器。大部分的数据上报中,并不会主动将客户端的IPv4及IPv6都带上,导致服务端并没有可靠的数据来源去分析IPv6下的业务情况。所以,需要改造采集服务端,支持和客户端进行IPv6建连,确保在IPv6双栈及IPv6-only环境下埋点数据可以正常上报。同时,在app启动,用户鉴权,网络变化等场景发生时,主动从服务端的应答结果中取到客户端的出口IP,并把这些信息存储在本地缓存中,在埋点上报时带上IP地址。这样采集端就可以收集到客户端的真实出口IP,如果的双栈的话,还可以同时收集到IPv4,IPv6地址并自动关联。从根本上解决了双栈环境时,服务端无法同时获取IPv4,IPv6的问题,有助于网络质量数据分析。
资源管理、运维系统改造
1 实现IPv4,IPv6资源区分管理能力
随着IPv6深入改造及政策支持,对使用IPv6环境的资源设备,流量带宽,调度引流等,将出现区别于IPv4环境的使用场景和计量计费规则。慢慢地IPv6将会在某些应用场景上出现成本上的优势,而现有的资源管理系统上新建网络管理、应用性能管理、认证服务器、DNS/DHCP等支撑系统推荐采用IPv6单栈建设,存量支撑系统推荐进行双栈化改造,具备对IPv6设备、应用或用户的基于机器学习、知识图谱、神经网络等AI加持的智能运维、终端识别、应用识别、智能调优、智能漫游、大数据安全分析等管理能力,待网元设备、应用或用户完成IPv6单栈改造后,支撑系统需同步完成IPv6单栈切换。
2 实现IPv6环境独立运维能力
改造并开启运维系统双栈协议,使系统具备在IPv6网络环境下对双栈服务器、网络设备、应用容器、监控采集、数据库缓存中间件、配置远程推送及用户数据的管理能力。对于暂时不支持IPv6的系统及设备,提供NAT地址转换、降级IPv4等方式,来进行管理,待改造完成上线后,逐步开启IPv6能力。
应用与服务
1接口服务及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安全防护等方面开展测试。
2移动终端及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
1 云产品的选型
新建场景
跟据阿里云的IPv6改造计划,选用已经完成改区域的云产品,使用业务原生支持IPv6环境。
存量场景
因为云产品支持IPv6后需要对原产品进行升级或者置换后,才能开启IPv6支持,所以对于存量使用的云产品,有一个迁移的过程。需要把流量迁到已经改造完成的地域后,对原有地域的云平台进行双栈化改造,包括ECS,ENV容器集群控制中心、容器编排系统、VPC/虚拟网关、负载均衡等进行IPv6支持改造,释放原有资源重新申请新的IPv6资源,来快速获取IPv6支持能力。改造完成后再把流量逐步切回,释放掉临时资源。
2CDN的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安全防护能力以及多端共享、边缘计算、云游戏、物联网等新型业务场景下的安全防护能力。
1 限流能力
限流能力需要具备IPv4/IPv6双栈场景下的应用能力,能够对总流量进行限制,也可以分别对IPv4,IPv6进行限制。具备在系统能力饱和的情况下,怎么样优先让IPv6的请求能力尽快得到处理并响应,保障IPv6优先的用户体验。
2 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 篇移动技术实践&干货给你思考!
原文链接:https://blog.csdn.net/qq_32198115/article/details/122999260?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165934458816782248570098%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=165934458816782248570098&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~times_rank-5-122999260-null-null.nonecase&utm_term=%E8%87%AA%E5%BB%BAcdn
原创文章,作者:优速盾-小U,如若转载,请注明出处:https://www.cdnb.net/bbs/archives/7029