近年来，HTTP/2 协议得到了快速的发展，HTTP/2 标准已于 2015 年 5 月以 RFC 7540 正式发表[11]。HTTP/2 协议提供了一些新特性，其中服务器端推送特性，为解决 DASH 直播中存在的请求报文膨胀和延迟问题提供了一种新的思路。根据 HTTP/2 标准，服 务器推送特征为 Web 服务器提供了直接向客户端推送资源的机制，因此打破了请求报 文和片段数量之间的反向比例关系。然而，HTTP/2 并不是为视频流媒体应用设计的，

因此，需要为直播视频应用定制一些推送策略，服务器推送机制才能应用于流媒体服 务中。MPEG-DASH P6 通过利用 HTTP/2 协议的一些新特性，定制了应用于 DASH 场景的 推送策略，提出了一种基于全双工 HTTP 的 DASH 协议。通过利用 HTTP/2 协议的新特 性，可以增强原有的基于 HTTP1。x 协议的 DASH 的功能。全双工 HTTP 协议，支持客户 端发起及服务器端发起的事务、取消数据传输请求、多路复用等等。这些新的特性的 应用，可减少传输延迟、以及改善对媒体呈现传输过程中服务器端发起的事件的响应。 

本节将讲述 DASH 的基本原理，并介绍 MPEG-DASH P6 国际标准[3]。 

 HTTP/2 动态直播流媒体流程图

2。1。1 基本原理

HTTP/2 自适应流媒体的工作流如图 2。1 所示。首先，利用 HTTP Upgrade 机制， 在客户端与服务端之间建立起一个全双工媒体流通道；然后，客户端发送统一资源标 识符和推送指令，向服务器请求媒体数据，其中推送指令用于通知服务器如何向客户 端推送媒体数据；最后，服务器接收到客户端发送的请求后，先向客户端发送请求的 媒体数据，并启动推送循环，根据推送策略向客户端推送媒体数据。

如图 2。1 所示，在一次 DASH 会话中，客户端首先请求 MPD 数据，然后请求媒

体片段，并发送推送指令。在获取请求的 MPD 后，客户端开始通过指定相应的媒体 片段 URL 和推送指令，向服务器请求视频片段。服务器响应请求，向客户端发送 URL 指定的视频片段，并启动推送循环，根据推送指令指定的推送策略向客户端推送视频 片段。通常，当获取一定数量的媒体数据后，客户端开始播送视频，并循环上述过程 直至整个媒体流会话结束。文献综述

如图 2。2 所示，基于 HTTP/2 的端到端视频流媒体系统架构主要由三部分组成：

1) 源服务器——存储流媒体资源，配置一个或多个推送策略的 HTTP/2 网络服务 器；2) DASH 客户端——获取并播放视频流，可由 HTTP/2 浏览器和 DASH 播放器组 成，也可由一个桌面客户端组成；3) 内容分发网络——连接源服务器和客户端，由多 个配置一个或多个推送策略的 HTTP/2 网络缓存服务器组成。

在上述系统中，有两个持久 HTTP/2 连接，分别存在于客户端和 CDN，以及 CDN 和源服务器之间。另外，在直播场景中，客户端与源服务器间应建立 HTTP/2 隧道连 接。与 HTTP1。x 流媒体不同，除了发送明确请求的资源外，HTTP/2 流媒体服务器(源 端/缓存)还可以主动向客户端(或 CDN)推送媒体数据。

 HTTP/2 动态直播流媒体系统架构

2。1。2  MPEG-DASH P6: DASH with Server Push and WebSockets

MPEG-DASH 是现有动态 HTTP 流媒体技术解决方案中的唯一国际标准，由 MPEG 组 织制订。MPEG 于 2010 年开始 MPEG-DASH 的制订工作，并于 2011 年 1 月成为国际标准 草案[12]。在 2011 年 11 月，MPEG-DASH 成为国际标准，并于 2012 年 4 月发布[2]。 MPEG-DASH 基于 3GPP 第九版中的 AHS(Adaptive HTTP streaming)和 Open IPTV 论坛 发布的 APPLE-HLS 第二版制定。