文章目录

• • 1、下载策略优化
  • • CDN选择策略
    • 错误处理策略
    • 码率选择策略
  • 2、协议和架构优化
  • • HTTP2
    • TCP变种拥塞控制
    • QUIC
    • 架构

流媒体协议的选择与分发体系架构的设计对优化起着关键作用。

HLS和DASH协议在点播和OTT直播服务中已逐渐占据主流，其思想主要是将视频转为不同码率并切为较小的片段，将流媒体分发从服务器推送转向客户端以HTTP下载方式获取，在此情境下，客户端下载策略是技术优化的重点，主要集中的方面：

• 1、视频链路的选择和切换策略
• 2、视频下载的预请求、并发策略和错误处理策略
• 3、视频码率的选择和切换策略

1、下载策略优化

早先视频服务的下载策略多由工程师凭经验设置，基于IF…ELSE…构造逻辑，但随着各家公司工程水平的提高，许多团队开始使用较复杂的算法作为下载策略，以争取QOS上出色的表现。

当前通用的做法是将策略组件化，且针对不同平台和场景使用不同的算法，持续上线A/B测试并观察数据表现，根据结果进行频繁迭代。

CDN选择策略

对于流量方面，常见的做法是将大部分流量由自有CDN提供，少部分流量由第三方CDN承担，作为削平峰值的手段。小公司无自建CDN，往往使用几家不同的CDN并将流量在其间调配，这样做的好处是：

• 一则避免路径锁定；
• 二则保障流量安全；
• 三则可对服务质量有所比较，汰弱留强。

自建CDN的流量调配，其策略通常是在知晓用户的地理位置和网络状况后，结合节点的位置和负载情况，按规划问题求解。

在混合架构下，既然客户端进行播放时有多个CDN可供选择，与多CDN的情况下所依据的信息较少，大多数第三方CDN并不允许指定边缘节点，视频服务将动态监控不同情况用户（可依据地理位置，网络状况等特征分类）在某CDN获取服务的质量，并据此推断特定用户应由哪个CDN服务。

下图是多CDN切换逻辑：

流量调配可以具备多种策略并能在不同策略件平滑地进行切换，如基于成本的策略、基于质量最优的策略、基于ISP的策略等，其中或许还需要更多约束条件，例如调配一定数量的请求，保证所有CDN均处于缓冲完备的状态。

错误处理策略

在视频播放期间发生某一码率的下载失败时，优先尝试较低码率下载或可解决问题，若所有码率的片段均不能正常下载，可尝试播放前方的片段。当源站的流媒体服务正常，但用户在某一个CDN无法正确获得服务时，转向另一CDN提供的资源可以让播放继续。倘若遇到特殊情况，如下载速度非常缓慢，带来多次缓冲，却并未失败，则需要跟踪下载进度，并为何时放弃，切换下载目标或CDN的判定设定合理规则。

对于直播来说，错误处理的方式要更加细致。

若我们对丢失的视频片段简单跳过，将导致播放位置过于靠近Edge，从而带来大量短促的缓冲。解决方法是：除了设置恰当的缓冲长度外，还可以使用特别的视频片段（如无节目片段）却带丢失的片段。

码率选择策略

为追求更高的视频质量、较低的缓冲次数和时长，给予用户清晰流畅的观看体验，一个好的ABR（Adaptive Bitrate，即码率自适应）算法非常重要。

ABR技术理论上可以构建在任何支持多码率的流媒体协议之上。

下面是一个会话中码率动态切换的示意图：

ABR算法设计的出发点有基于带宽估计、基于缓冲区长度、混合带宽估计和缓冲区长度等方向，代表性算法包括：

• 移动平均线：移动平均线，即将段时间内的数值连成曲线，用来显示历史波动情况，当有多条不同区间的移动平均线，且平均线之间发生穿越时，可被视为超势发牛变化的信号。
• 卡尔曼滤波：Kalman Filter即卡尔曼滤波，算法基于隐马尔可夫模型，能从一系列不完全及包括噪声的信息中估计动态系统的状态，它根据各个指标在不同时间下的值考虑其联合分布，再产生对未知量的估计，算法常用于航空航天技术的导航空制和机器人的运动规划等领域，广义的卡尔曼滤波算法包括扩展卡尔曼滤波和无损卡尔曼滤波等。
• CS2P：C2SP又称Cross Session Stateful Predictor，是在iQiyi数据的基础上提出的利用HMM模型进行预测的算法。
• BOLA：BOLA，是基于缓冲区长度估计使用Lyapunov优化的一种算法，在Github上有开源的参考实现。
• MPC：MPC，即Model Predictive Control,是种综合带宽估计和爱冲区长度的算法。

下面是Netflix的ABR算法

2、协议和架构优化

HTTP2

HTTP2已得到大部分CDN公司、浏览器、反向代理的支持，众多视频网站也在逐步推进中。HTTP2没有改动HTTP的语义，但包含了大量新特性，如对HTTP头进行数据压缩、服务器端推送，请求Pipeline化、对数据传输采用多路复用等。

建立TCP连接的耗时常常达到数百毫秒，HTTP2将TCP连接分为若干个流，每个消息由若干最小的二进制帧组成，对新页面加载的加速十分明显。协议引入HPACK算法，令客户端与服务器维护相同的静态字典和可添加内容的动态字典，以哈夫曼编码减小头部大小。HTTP2引入的服务器端推送，允许服务器提供浏览器渲染页面所需的资源，无须浏览器收到并解析页面之后重行请求，同样节约了加载时间。

TCP变种拥塞控制

TCP协议的拥塞算法常年为人诟病，当网络存在丢包时，TCP连接速率将被大幅度调低，若丢包并非由持续存在的因素导致，实质导致了对带宽的巨大浪费。

（TCP拥塞控制算法与路由器中的主动队列管理(AQM)模型息息相关，路由器中简单的队尾丢弃方案存在多种问题，如果增加预测环节，使得缓存耗尽前有计划地丢弃一部分分组，提早通知发送方降低速率，这就是AQM地核心思想。TCP的拥塞控制大致可以分为基于丢包反馈的协议，如Tahoe Reno、HSTCP、CUBIC等；基于路径延迟反馈的协议，如Vegas、FAST TCP、Westwood等；基于显式反馈的协议，如ECN、XCP等）

Serverspeeder（即锐速）是常用的TCP网络加速软件，可在Linux、Windows服务器上使用，不论网站，还是CDN节点，均可借此大幅提高网络传输速度。另一个知名的优化方式是Google非官方提出的BBR算法，它在RTT（往返时延）增大的时候并非马上降速，而是保持最近的最大速率进行发送，且在有空闲带宽时加速抢占，但缺陷是减速收敛较慢，也并不适合深队列的情形。

QUIC

使用QUIC协议而非TCP协议是近年来一些公司的尝试，这是一个由Google倡导并正在标准化的，构建于UDP协议之上的传输层协议，并可能得到DASH协议的支持，其设计旨在：

1、减少握手数据包、

2、支持前向纠错FEC（FEC即Forward Error Correction，前向错误更正，通过增加元余信息，在发生错误时，无须通知发送方重发即问进行错误恢复，用于流媒体传输时，可将N个音视频包异或得到新包插入流中，代价是流的大小变为(N+1)/N倍。）

3、支持会话的快速重启和并行下载等

最近被重命名为HTTP3。

QUIC协议在快速连接、弱网状态下的下载速度、网络类型切换时连接的保持等方面都颇有优势

架构

对于点播和直播，在CDN的边缘节点上予以缓存是提升包括启动时间在内的传输性能的首要步骤。

对于CDN而言，根据热点预测将视频的初始片段（一个完整的GOP）预先缓存到和边缘服务器仅为常规手段，视频网站可以根据数据预测的结果将热门节目的完整内容主动加入缓存。

此外，由于长视频模式的服务通常版权节目数量不过百万级，若条件允许，可于所有节点服务器中维持持久化的缓存，至少囊括冷门视频在内所有节目的起始片段，以此提高用户体验，在存储成本低廉的当下十分划算。

在自建CDN的场景下，无疑可以从数据预测所有内容的访问热度以及根据用户确认访问的分布，按照预测结果进行预热。由于每个视频均存在不同码率，此时将各码率内容视为不同的文件预测可能得到更好的结果，理论上，可以将节目片段的观看热度、电影的宣发计划等均纳入考量。在规模较大的视频服务商的体系中，约束条件可能还包括在不同的子集群的状态是否健康，子集群和整体的流量是否平衡。

对OTT直播节目来说甚至不需要以上步骤，将频道主动推送至边缘节点，而非待用户请求再自源站拉取，就可以改善首批用户的体验，并降低延时。

完整的播放请求中，资源获取、鉴权等工作通常需要访问源数据中心，对启动时间等指标存在多重影响，在自建CDN场景中，许多服务均可被前移至边缘节点予以加速，常见的如转码服务，在直播场景下节目流上传的节点不需要设置为源站，而可以在任意边缘节点接收、转码、再行分发，如果进行得当的设计，DRM许可、广告投放等服务也并非不能部署在边缘站进行加速。

在游戏、秀场直播场景下，当前仍由非HTTP协议占据主流，视频传输以RTP或相似的协议为主，网络层协议选择UDP，由于UDP的非可靠性，此时对丢包可采用FEC或带外重传的方式。在传输过程中，由于大于MTU[插图]的包将导致IP层分片传输，通常的策略是将音视频帧按略小于MTU的大小切分成RTP包，有些公司认为路由器存在小包优先的策略，因而在拥塞严重的网络环节下对切分上限设置在靠近MTU除以2的位置对传输较为有利。

与HLS或DASH播放时，对直播视频片段来说，若无法下载，则尝试其他码率或下一片段相似，在RTP环境下，服务端应监控传输状况，主动切换合适的码率，丢弃超时的帧乃至整个GOP，播放器也应在缓冲区过长的情况下采用丢帧方法追赶进度。