优酷IPv6改造纪实:视频行业首家拥抱下一代网络技术
    2019-01-30    

​​

阿里妹导读:2018年双11前,优酷开启了IPV6的大门。9月份PC端业务开启灰度,迎来首位IPV6 VIP用户后,优酷移动客户端也马不停蹄地加入灰度大军。从0到1,花了几个月;从10到1000,花了几天;从1000到50W,只要几小时。IPV6灰度的马车一旦起跑,将再也不需要停止。

 

IPV6在优酷,技术驱动产品的验证

 

2018 世界杯期间,我们验证了IPV6的改造方案和技术可行性,双11期间优酷PC端和App在国内教育网及一线重点城市都有一定比例的IPV6用户,享受着高清直播点播服务,体验着一条刚刚建完的高速大道却没有几辆车的快感。专属的用户身份标识,专属的客户端网络检测能力,专属的会员卡,专属的红包,这一切可能不知不觉中就属于你了。

 

随着双11后阿里集团几大应用相继开启灰度,我们迎来了中国首次IPv6大规模应用上线,优酷不仅能跑而且跑得快。这象征着优酷大家庭通过双11、世界杯等的洗礼,已经拥有了一支能战敢战,战则必胜的技术团队。IPV6不是一个人的功劳,是所有技术人努力的结晶。

 

今天,我们采用专访问答的形式,带你走进优酷IPV6从立项到实践的全过程。优酷IPV6改造项目,由优酷应用架构吴灵晓(盖优)负责。应用架构部主要负责整体架构设计实施优化工作,探索从DEVOPS向AIOPS转变,智能运维、深度学习、大数据分析、智能机器人等新技术也有大量的成熟运用。

 

立项

 

Q:IPV4和IPV6有哪些区别呢?

 

安全:IPv6把IPSec作为必备协议,保证了网络层端到端通信的完整性和机密性。

业务无限扩展:不受地址短缺的影响。

个性化服务:流标签的使用让我们可以为数据包所属类型提供个性化的网络服务,并有效保障相关业务的服务质量。

减少开销:报头格式大大简化,从而有效减少路由器或交换机对报头的处理开销。

万物互联:大容量的地址空间能够真正地实现无状态地址自动配置。

 

Q:为什么想到要做IPV6改造?

 

第一,IPV4环境恶化:

第二,政策驱动:2017-11-26 中共中央办公厅 国务院办公厅印发《推进互联网协议第六版(IPv6)规模部署行动计划》。2018-05-03 工业和信息化部关于贯彻落实《推进互联网协议第六版(IPv6)规模部署行动计划》的通知。

 

第三,技术驱动产品业务:IPv6在客户端-服务端-阿里云CDN-优酷直播点播业务的全线贯通应用,优酷完成了新网络技术到产品应用的实现,改写技术服务产品,服务倒逼技术升级的局面,使得IPV6网络技术能够支撑优酷今后几年甚至十几年的业务需求,5G、P2P、人工智能、AI、物联网等,在网络技术上已经没有障碍。

 

第四,天时地利俱备,差人和:政策支持,集团推动,技术展现为一体,这么好的机会,不能错过。

 

拥有一群打过双11,打过春晚,打过世界杯的战友们,没有什么事是做不好的。

 

Q:决定做之后,怎么列的计划呢?目标是什么?

 

这还真是前无古人,后有来者。谁都没有经验,没有相似可参照的案例,涉及团队众多。

 

各种调查与讨论,以及集团相关的计划安排,整个IPV6项目将分成三步走,包括外网阶段,用户端与接入层支持 v6、内网阶段,服务端内部v4/v6双栈、以及内外网IPv6-only 。

 

外网改造:实现应用快速对外服务,以web/App请求服务为核心,满足IPv6生态发展的需求,并且以外网拉动应用的不同需求;

内网改造:应用逐渐扩大到爬虫、邮箱、DB、存储等V6直接交互,需要内网服务器部分采用IPv6,需要整网双栈交付;

IPv6 Only:当超过50%应用逐步迁移到IPv6后,新应用默认采用v6开发,遗留一些老旧应用、用户继续采用IPv4服务,内网采用4over6进行封装。相对双栈而言,IPv6 only成本更低,查表转发速度更快,只需维护一套协议栈。

 

阿里网络演进从外到内,从用户到应用逐层迭代,尽量做到成本最低,效率最高。

 

 

核心目标

 

18自然年底,实现全量灰度。还是那句话,要么不做,要做就做最好。评估后全量灰度目标虽然风险偏大,但努力一把还是可控的。

 

 

过程

 

Q:对研发同学来说,需要关心哪些?怎么确认哪些要改哪些不要改?

 

对研发的同学来说,只需要关心客户端APP/PC端网页及服务端的改造。

 

客户端基本上涉及到基础网络包NetworkSDK等集团二方包的升级。使用httpdns解析的,需要改造实现客户端网络的判断和接收httpdns服务端下发的AAAA记录;使用localdns解析的,需要改造实现DNS服务请求参数中添加AAAA记录解析的标识。使用三方库的,要升级至最新版并确认支持IPV6,不支持的需要考虑更换三方库。

IP 字段是否正确

extra : {'firstIp': 'xxxxx'} 是否正确携带

探测埋点

弱网、DNS耗时的情况下,探测能否正常

网络切换特别频繁的场景

 

PC端/服务端要关心的就多一点了,只要你的业务处理中有以下任意一点的,都是要做业务改造的,也就是写Bug。

 

 

1.IP地址库使用:是否有用到地址库,对用户IP进行地域来源等判断。有的话需要升级到IPV6地址库,并更新调用方法。

 

2.IP地址格式判断:是否对用户IP进行验证,有的话需要加入IPV6地址格式的正则表达式判断。

 

3.IP地址保存:是否对IP有存库等保存操作,需要修改相应字段的长度,IPV6长于IPV4,MySQL 建议字段类型 VARBINARY(16)。

 

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

 

5.客户端IP地址的取得方式:是否从客户端请求的头部获取。是的话,那么在双栈环境中,同一请求,你只能获取到V4和V6地址中的一个,不可能两个都获取。

 

如果是通过请求正文中的某个字段,把客户端地址传上来的,那么,你需要考虑是否需要获取客户端的v4v6的所有地址。是的话,那么就需要扩展请求字段,将v4,v6分成两个字段提交,同时服务端也需要做接收改造处理。

 

6.日志,数据的采集等数据产品的改造:是否用了第三方的采集工具,如果采集工具不支持IPV6的话,那么采集上来的数据会和服务端的请求日志无法对齐,产生GAP。类似还包括广告投放与监测等分别属于多方的业务场景。

 

从业务上来看,需要区分IPv4用户请求和IPv6用户请求,并分开进行数据分析。所以数据产品数据存储等都需要能够支持用户IPv6数据的采集。

 

7.安全产品:内容安全:文本安全过滤,七层流量清洗等等,安全产品改造,业务升级二方包/客户端。

 

8.监控:以用户IP作为判断条件/统计条件的监控配置,需要改造。

 

9.大数据统计:以用户IP作为判断条件/统计条件的内容,需要业务改造。

 

10.依赖服务:原有阿里云产品需要更新为支持IPV6的产品,VPC,ECS,OSS,CDN等都是更换范围。

 

Q:改造中主要遇到哪些问题呢?

 

1.没有IPV6环境:办公网不具备IPv6接入环境,阻塞业务开发;内网尚未改造,无法打通日常(测试)环境。

 

一开始,基础环境还没有具备的时候,我们使用IPV6 over ipv4链路VPN的方式连入测试环境 ,需要PC/客户端加证书改hosts,移动端无法改hosts的,需要root,越狱,各种凌乱,但至少业务测试可以开始启动。

 

然后,我们加强了基础网络和IT合作,在多个园区部署多个IPV6的接入环境,打通IPV6出口,打通办公网和机房的IPV6链路,慢慢实现外网IPV6,日常环境通,预发通,正式通,慢慢使业务能够测试逐步提升到IPV4相同的测试体验,通过域名劫持等手段,跳过了Hosts配置的尴尬,达到标准的测试效率。

 

2.OS网络模块问题:需要让容器支持从请求头部获取IPV6地址,那么就需要把用户IP一级一级透传过来,就需要在各级的服务器上升级网络模块,扩展报文头部。例如toa模块,toa模块是为了让后端的realserver能够看到真实的clientip而不是lvs的dip。

 

同时,tengine/nginx等应用需要升级到支持IPV6的版本(支持新toa模块等),由于历史原因存在各种老版本无法升级,导致升级受阻。

 

我们通过推动应用接入统一接入改造,避免自行升级网络模块带来的风险。

 

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

 

3.地址库特殊需求:优酷有自己的地域编码,优酷广告业务还有广协提供的地域编码,还有业务使用集团的地址库,总之地址库各种不统一。

 

首先,统一地址库,要求所有业务必须统一使用集团地址库。并且协调集团地址库生产方,满足优酷使用场景需求,使统一过程中业务改造工作量减少。

 

再次,对于广告等必须要使用行业统一地址库的场景,我们也制定了多套方案去解决。

 

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

 

后续方案: 主动出击,联系广协等行业协会,加快产出IPV6地址库,并且主动无偿提供集团地址库数据,体验了阿里的企业责任,更加快了整个行业的改造进度。最终行业协会从立项到产出地址库的时间,只用了不到1个月,而集团收集这些数据花费了一年半的时间。

 

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.安全问题:有运营商的出口能力,黑洞能力进展缓慢或者暂不具备。有安全基础产品的存在绑定域名后就能直接访问任意服务,灰度放大。

 

8.CDN灰度问题:CDN域名由阿里云进行调度控制,无法和业务同一灰度范围。增加IPV6专属CDN域名,通过业务侧增加业务逻辑,分别下发不同的域名来实现同一灰度节奏能力。

 

结果

 

Q:灰度是如何操作执行的?

 

通过httpdns方式 ,提供两种灰度能力:

 

基于用户设备的白名单

基于地域+运营商+百分比+用户设备白名单

基于app版本的全量百分比

 

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

 

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

 

Q:如何确认业务是否正常呢?

 

业务层:业务配置的IPV6监控平台,IPV4与IPV6监控曲线对比。

接入层:IPV6流量大盘,分域名,分接口展示成功量,成功率及RT。

数据平台:业务指标的大数据分析及报表展示。

基础网络:省份运营商的链路成功率,IPV6用户占比,链路质量链路延迟,IPV6降级IPV4比例等数据。

 

有了这些,还怕业务有问题吗?

 

我们知道,视频的生命周期,是从采集到制作到生产,最后到视频的呈现,这里有很多环节,每个环节上都有非常专业的团队来保障。在制作环节会做调音、调色,在生产环节会做编码压缩,在呈现环节的会做解码和后处理,每个环节独立来看都做得不错。但如果我们站在链条的两端来看,制作侧和呈现侧看到的视频效果存在比较大的差异。

 

但是今天,我们的场景发生了改变,我们有形形色色的终端,有手机、Pad、PC、电视、投影,呈现场景已经不可控的,所以今天我们看到的画面,已经不是我们的导演原本希望呈现的画面了。这是今天我们想去解决的问题,当然整个链条上的联动不是靠优酷一家可以解决的,因此我们需要更多产业链上的朋友和我们一起来解决这个问题。

 

当每个人都是导演、演员、编辑、美工的时候,缺少的是什么?

 

空间容量,没有创作空间,没有办公空间,没有消费空间,可持续增量空间。这些不全都是IPV4的错,但确实IPV4是瓶颈,当一个人有上百个设备的时候,IPV4肯定满足不了。

 

有了IPV6,再多设备都OK,每个设备都能互联互通,万物互联。

 

那么,智能化的后期制作变得可能。

 

 

快速将优酷内容库批量处理为适合视频互联网传播的版本,我们使用了自适应调整映射曲线的算法,根据内容明暗程度,有时提升暗区对比度,有时提升亮区对比度。任何端设备都能干。

 

那么,内容版权将变得容易控制,不用花精力去防盗版了。

 

区块链技术+IPV6+5G,每个设备都记录播放信息,要串改内容必须修改超过51%的设备,盗版成本无限放大。没有了防盗成本后,版权不再昂贵,都能接受。

 

展望

 

技术的价值在于帮助人,不是替代人。通过技术保障项目成功,项目成功也推动技术落地。

 

这一切都在IPV6改造项目中体验。

 

随着灰度扩大,下一期改造来临。

 

普通用户根据不知道IPV6是什么的情况下,通过业务,通过产品去更好地展现出来,让用户能有感知。例如:视频变快变清晰了,走到哪里看到哪里了。会员时间增长了,不用花钱了。技术驱动业务,将会更美好。​​​​