包装设计网站官网,网站添加地图,帝国cms企业网站模板,html电影网站模板下载工具文章目录1、下载策略优化CDN选择策略错误处理策略码率选择策略2、协议和架构优化HTTP2TCP变种拥塞控制QUIC架构流媒体协议的选择与分发体系架构的设计对优化起着关键作用。
HLS和DASH协议在点播和OTT直播服务中已逐渐占据主流#xff0c;其思想主要是将视频转为不同码率并切为… 文章目录1、下载策略优化CDN选择策略错误处理策略码率选择策略2、协议和架构优化HTTP2TCP变种拥塞控制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从而带来大量短促的缓冲。解决方法是除了设置恰当的缓冲长度外还可以使用特别的视频片段如无节目片段却带丢失的片段。
码率选择策略
为追求更高的视频质量、较低的缓冲次数和时长给予用户清晰流畅的观看体验一个好的ABRAdaptive Bitrate即码率自适应算法非常重要。
ABR技术理论上可以构建在任何支持多码率的流媒体协议之上。
下面是一个会话中码率动态切换的示意图 ABR算法设计的出发点有基于带宽估计、基于缓冲区长度、混合带宽估计和缓冲区长度等方向代表性算法包括
移动平均线移动平均线即将段时间内的数值连成曲线用来显示历史波动情况当有多条不同区间的移动平均线且平均线之间发生穿越时可被视为超势发牛变化的信号。卡尔曼滤波Kalman Filter即卡尔曼滤波算法基于隐马尔可夫模型能从一系列不完全及包括噪声的信息中估计动态系统的状态它根据各个指标在不同时间下的值考虑其联合分布再产生对未知量的估计算法常用于航空航天技术的导航空制和机器人的运动规划等领域广义的卡尔曼滤波算法包括扩展卡尔曼滤波和无损卡尔曼滤波等。CS2PC2SP又称Cross Session Stateful Predictor是在iQiyi数据的基础上提出的利用HMM模型进行预测的算法。BOLABOLA是基于缓冲区长度估计使用Lyapunov优化的一种算法在Github上有开源的参考实现。MPCMPC即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、支持前向纠错FECFEC即Forward Error Correction前向错误更正通过增加元余信息在发生错误时无须通知发送方重发即问进行错误恢复用于流媒体传输时可将N个音视频包异或得到新包插入流中代价是流的大小变为(N1)/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播放器也应在缓冲区过长的情况下采用丢帧方法追赶进度。
