2020-04-18 09:49  互联网

导读:随着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双栈发展阶段,需要技术和产品特别关注在双栈环境下才会出现的问题,而这些问题几乎没有资料可参考,非常考验运维团队的应变能力。以下是我的一些建议:

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

上一篇:云市场跨步式发展 打造ToB云市场阿里腾讯外“第三股势力” 下一篇:拼多多公布新iPhone SE补贴后价格:2899元起;BOSS直聘回应“App崩了”;Chrome 新测试版发布|极客

发表评论