基于应用理解的协议栈优化
作者：余兵
移动互联网时代，不同的应用追求的产品体验差异性很大。
应用商店和图片等下载类型业务追求速度、越快越好，短视频关注起播、拖拽响应速度和观看过程卡不卡，直播追求画质清晰、高码率和直播过程流畅；而游戏则是追求低延时，网络稳定、不掉线。
如何保障不同类型应用的差异化产品体验是移动互联网时代的一个巨大的难题。
01 传统协议栈技术与不足
协议栈是底层通信技术，处在 OSI 模型的第四层，协议栈优化技术旨通过克服协议缺陷和改良协议机制，提升内容分发效率，改善产品体验。
传统的协议栈优化思路是以“快”破万法，追求速度的极致，从速度视角去解所有应用的产品体验问题，这对于下载类似的业务适用，但对于直播、点播和游戏等业务确是不适用的，会出现产品体验不好的现象。
点播和直播关注卡不卡、流畅与否，最核心的技术是保障播放器缓存不空，持续不断的有数据播放，和传输速度快慢并无直接关系；游戏信令关注低延时，对带宽需求量很小，但对丢包和网络抖动及其敏感，对于丢包感知、丢包恢复技术要求极高。
显然，速度的解法，并不能满足移动互联网下所有应用产品体验需求，协议栈优化技术需迭代要升级。其中最重要、最核心的技术是协议栈理解应用，理解应用的传输特征、理解应用关键体验指标、理解关键体验指标背后的性能瓶颈，及其造成性能瓶颈的影响因素个各个影响因素贡献的权重比例。
除了理解应用外，协议栈优化技术还需要扩展与延伸协议栈对应用传输过程的感知能力，感知结果与应用传输特征匹配，再定制差异化的拥塞控制和丢包恢复算法。
02 理解应用的协议栈技术
基于应用理解的协议栈，首先要理解不同应用的传输特征、关键体验指标、关键体验指标背后的性能瓶颈，及其造成性能瓶颈的影响因素和个各个影响因素贡献的权重比例；其次是对应用总结、分类，分成不同的业务类别，最后再针对不同的业务分类性的设计不同的算法策略。方案的核心思想是用不同的算法解决不同应用场景的产品体验优化。
应用分类和解法
阿里 CDN 最近四年，一直在协议栈技术智能化道路上探索，基于应用理解的协议栈技术是协议栈智能化的技术基础。针对阿里云 CDN 平台 130T 的业务规模做应用分类，分类规则依据两个维度：应用传输特征（不同的应用在业务特征的差异性会反馈到传输行为上）、应用关键体验指标（关注速度、卡顿率、低延时等不同的体验指标），最终将所有应用分成四类业务：信令业务、下载业务、点播业务、直播业务。
l 信令业务
信令场景的传输特征是交互式、低延时、信息量少，比如游戏对战类、网站访问类、钉钉、微信等 IM 通信工具文字和语音通话类业务。关键的应用体验指标是低延时、网络稳定、不抖动、不闪断，所以信令业务的产品体验优化解法是弱拥塞控制，强丢包恢复。最核心的优化要领总结为“快传快补”，“快传”是指快速的将数据报文发送到网络中，“快补”则是在拥塞检测、丢包恢复技术上及时、实时，只有如此才能达到低延时的应用体验需求。
协议栈技术本质上是一种攻防技术，贪心的拥塞控制是进攻，负责“免疫”的丢包恢复是防御，进攻与防御并存，顺风时进攻，逆风时防御，信令场景优化要领“快传快补”正是如此。协议栈的优化策略必须攻防兼备，设计进攻策略时，同样需要设计辅助的防御策略，一个优秀的拥塞控制算法，必定配套了一个优秀的丢包恢复算法，只有这样才能将协议栈技术演化到极致。
l 下载业务
下载场景特征为数据量大、追求下载速度，需要的带宽量大，期望压着可用带宽跑，充分利用链路可用带宽，典型的应用有应用商店的 APP 下载，大文件下载、高清图片下周、手机操作系统升级包下载等。下载应用关键的体验指标是下载速度、下载耗时，所以下载业务的优化要领是“拥塞控制、细水长流”，持续不断的做好带宽估计，持续不断最大化利用链路探测带宽，才能保障下载类业务的产品体验，短视的突破、取巧难将性能做到极致。
l 点播业务
点播场景特征为静态的视频文件流（缓存在 CDN 边缘节点）、不关注下载速度，关注视频播放卡不卡，视频起播和拖拽响应速度，比如行业手淘、快手、抖音、小红书、优酷和蚂蚁支付宝第三 tab 页等平台上提供的短视频点播业务。关键体验度量指标是卡顿率，卡顿是播放器的行为，保障播放器缓存不空，持续不断的有数据播放是点播场景优化的关键难题。
l 直播业务
直播场景特征为实时流、带宽需求量不大但有突发(和视频编码技术有关)、对网络丢包敏感、不关注下载速度，关注播放过程流畅与否，比如行业的手淘、快手、抖音、虎牙、斗鱼等平台上提供的直播业务。直播业务的关键体验是播放流畅、不卡顿，与点播业务的优化要领相似，区别是直播为实时流，阿里 CDN 的优化思路是弱拥塞控制，强丢包恢复。
基于应用理解分类，阿里云 CDN 设计了一个协议栈算法容器，包含四大主算法，分别覆盖信令业务、下载业务、点播业务和直播业务，每个主算法包含三个子算法，提供了低中高三个不同等级的分级服务，最终满足各种应用的产品体验改善需要。
协议栈算法容器
区别于原始 Linx 内核的算法模式——将不同思想、服务不同场景的算法设计为独立算法，阿里 CDN 结合应用中心式、统一管控需求，也为了能让算法和应用更加灵活匹配，我们使用了一种新模式，设计了一个算法底座，底座上生长了 5 个主算法，主算法提供低中高三种不同级别的分级服务，最终形成了算法容器。
算法容器的构建逻辑如下：
首先，通用能力抽象、底座化，抽象拥塞控制和丢包恢复技术作为算法容器的底座。拥塞控制和丢包恢复是协议栈最核心的两大技术，近乎 95%的协议栈优化工作都集中在此。拥塞控制类别人的心脏，通过带宽估计和带宽使用，控制整个协议栈的启停；丢包恢复则类似人的免疫系统，当网络出现拥塞或出现丢包时负责免疫修复。
其次，通用能力灵活、弹性化，不用的场景分类对拥塞控制和丢包恢复依赖有差别。比如直播对于拥塞控制的依赖比较弱，直播为实时流，需要带宽量相对固定，贪心式的拥塞控制算对直播产品体验优化效果弱，但是对于丢包恢复的能力要求很高；下载业务对于拥塞控制的能力要求极高，需要拥塞控制算法尽力而为，丢包恢复技术要求一般；再如信令业务，对带宽的需求趋于无，但是对丢包恢复的能力要求极高。拥塞控制和丢包恢复通能力灵活、弹性后，场景分类算法可以按照自己的需求选择能力等级。
再次，场景分类主算法设计，主算法设计包含两部分关键类容：第一是基于应用场景特征的理解决策使用通用能力等级（拥塞控制和丢包恢复能力），第二部分是基于场景传输特征和性能瓶颈，迭代专用策略。
最后，算法服务分级的能力（阿里云 CDN 设计了低、中、高三档能力，演化为三个子算法），不同应用对于产品体验的要求有差异、对质量的敏感度也有差异，利用这种差异构建服务分级的能力，可以实现产品体验和成本双赢。比如 CDN 系统内部的日志回传对实时性要求不高，可以给予最低档的优化服务；比如点播、直播、游戏等业务对产品体验要求非常高，可以给予最高的的产品体验优化；又比如 CDN 内部管控类服务对质量的敏感适中，给予中间档位的传输服务。
能力产品化交付
技术能力交付的方式有很多，算法容器遵循了产品化模式交付标准，有如下功能或特性：
域名维度算法配置，支持不同域名配置不同算法：
l 支持域名维度国家、省份、运营商、节点、时间组合维度的算法配置，可以灵活的组合使用算法
l 域名策略 web 化配置、点鼠标实现域名算法配置
l 域名策略 web 化管理，提供网页式域名算法管理能力
l 域名算法分钟级生效，配置动作触发下发逻辑，分钟后生效
l 算法策略到内核态，系统标准化 API，接入网关改造简单、轻量
03 未来展望与规划
移动互联网时代需要的是基于产品体验的协议栈优化技术，基于数据传输的优化技术只是数据报文的搬运工，是缺少灵魂的、行尸走肉的，无法理解应用传输特征和产品体验需求，难以满足存量和爆炸式增长的 APP 应用需求。
基于数据的传输和基于产品体验传输，中间差了一个协议栈智能化技术。正如文章中提到观点，基于应用理解的协议栈优化是协议栈智能化的基础技术，应用理解的协议栈优化技术是我们在智能化道路上迈出的第一步，但不是最后一步，我们仍在路上。
我们的目标是让协议栈优化技术理解应用、给协议栈技术植入智能化基因、用智能化的思路设计产品体验的传输技术，最终解决移动互联网下各种应用的产品体验优化问题。
注：文中的出现的协议栈关键词，如果没有加限定词，特指 TCP 协议栈。
