共计 5610 个字符，预计需要花费 15 分钟才能阅读完成。
阿里妹导读：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 是什么的情况下，通过业务，通过产品去更好地展现出来，让用户能有感知。例如：视频变快变清晰了，走到哪里看到哪里了。会员时间增长了，不用花钱了。技术驱动业务，将会更美好。
本文作者：期待被关注的阅读原文
本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。
