以上就是预渲染在业务侧的基本逻辑。在极致情况下,用户侧对于网络、解码、渲染耗时均是无感知的。网络耗时优化——节点优选前文提到,在首帧出现之前还有一个很重要的数据准备环节。数据准备主要是数据模块的下载,可以分为请求开始、DNS 域名解析、DNS cache 等阶段。如何从 DNS cache 或者 IP 池中选出高质量 IP 进行后续建联,从而完成相关首帧播放以及后续播放,这就节点优选要做的事情。网络 IP 选择影响到首帧、未起播率、播放失败甚至后续卡顿等一系列数据,重要性非常高。节点优选就是要在 IP 池里选择最优 IP,保证播控和数据加载都符合预期。但是,节点优选对于点播体系来说,也存在很多潜在风险性问题。端侧本身存在较大的限制:设备之间无法实时感知彼此的择优路径。在极端情况下,如果大量用户都优选到了同一个节点,而请求量级超过了节点的负荷能力,就会影响服务端 CDN 的稳定性。因此,目前我们会把节点优选作为长尾用户的质量优化。上图是节点优选的整体逻辑。在 DNS 解析之后,相关 IP 会经历节点优选的过程,得到最优的推荐 IP。我们再基于这个 IP 进行后续的 TCP 建联、数据上传下载,并在数据传输过程中反向把建联、下载过程中的网络状态传递给节点优选组件,进行二次训练和数据迭代。我们在节点优选过程中面临两个大的挑战:
何时主动选择切换节点;
如何保证切换后的节点是局部最优甚至全局最优。
节点优选策略包括:
节点小黑屋:在没有节点优选的方法之前,如果一个 IP 出现了较大的问题,我们的做法是对该 IP 反复重试。但因为节点本身有问题,无论怎么重试结果都是不符合用户预期的。因此我们就尝试了小黑屋策略,把有问题的 IP 放到小黑屋一段时间,使得下一次播放时不会选到这个 IP。
请求异常归因:当播放失败需要重试时,我们需要对 IP 失败进行基础性归因,弄清楚是端侧故障导致质量差,还是传输 CDN 的节点问题。对于端侧的问题导致的节点质量差(比如当我们进入电梯和地铁时,由于环境因素导致设备的丢包率很高),我们做的判断应该是尽量少的切换节点,而不是频繁切节点。而对于节点故障,则应该尽早切换。
节点质量排序:在节点切换时,如果有多个 IP 可选,就涉及节点选择的择优策略,前瞻性地对节点进行排序。可以根据 QoS 或者 QoE 或者节点本身的客观指标来排序,我们的选择是在旁路场景对当前节点进行探测。比如在预加载和预连接的场景下,进行更多新节点的尝试,从而得到更多、更大覆盖度的探测。