阿里妹导读：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是什么的情况下，通过业务，通过产品去更好地展现出来，让用户能有感知。例如：视频变快变清晰了，走到哪里看到哪里了。会员时间增长了，不用花钱了。技术驱动业务，将会更美好。
原文链接
本文为云栖社区原创内容，未经允许不得转载。
