在 HTTP 流媒体系统中，视频内容像普通文件一样存储于 HTTP 服务器中，每个 视频文件对应一个 URL(Uniform Resource Locator)。用户想要观看某一视频时，客 户端与服务器端建立一个 TCP 连接，并向服务器端发送包含相应 URL 的 HTTP Get 请 求。随后，服务器端通过一个 HTTP 响应消息，向客户端传送该视频文件。通常，服 务器端以尽可能快的速率发送视频，即 TCP 拥塞控制(congestion control)和流量控 制(flow control)下所允许的最快速率。客服端接收视频，并存储在视频缓存中。当 视频缓存大小超越预设的阈值，即初始化延迟，客户端应用程序开始播放视频，即每 隔一定时间，从缓存中取出一帧，解码后，在屏幕显示该帧。通过缓存机制和预取机 制(prefetching)，HTTP 流媒体技术成功解决 TCP 的拥塞控制和可靠传输机制对连续 播放的阻碍。 

一方面，HTTP/TCP 的应用，使其可以轻松穿越防火墙和 NAT(两者通常被配置为 阻塞 UDP 通信，而允许多数 HTTP 通信)。另一方面，HTTP 流媒体系统无需专用媒体控 制服务器，大大减少了大型网络媒体分发系统的部署成本。由于以上诸多优势，许多 视频流媒体应用系统都采用 HTTP 流媒体技术，如 Youtube，优酷，爱奇艺等等。 

虽然 HTTP 流媒体在实际应用中得到了广泛的部署，但是它面临着一个很大的缺 陷，即所有的客户端均接收相同编码的视频文件，而不管不同客户端间以及同一客户 端不同时间上的可用带宽的巨大变化。因此，为解决这一缺陷，一种新型的基于 HTTP 的流媒体应运而生，即动态 HTTP 流媒体，通常代指 DASH(Dynamic Adaptive Streaming over HTTP)[2]。 

在动态 HTTP 流媒体系统中，同一视频内容将被编码为多个不同版本，每个版本 通常对应一个不同的码率，相应的，视频质量水平也会不同。随后，不同版本的视频

文件被切割为一系列基于 HTTP 的文件片段。每个片段包含时长数秒或数十秒的视频 内容。客户端动态请求来自不同版本的视频片段。当可用带宽高时，客户端请求高倍 率版本的片段；当可用带宽低时，客户端请求低倍率版本的片段。客户端每请求一个 片段，都会发送一个相应的 HTTP GET 请求消息。一方面，DASH 允许处于不同网络环 境的客户端接收不同版本的视频内容。如低速的 3G 连接客户端可以请求低码率的视 频，而高速光纤接入的客户端则可以请求高码率的视频。同时，在会话期间端到端带 宽变化时，DASH 允许客户端根据带宽的变化动态请求不同版本的视频片段。显然，对 于移动端用户来说，该特色尤为重要。通常，移动客户端的可用带宽会随用户与基站 的位置移动而变化。 

通过动态监控可用带宽和客户端缓存水平，通过切换视频版本调整传输的视频 码率，动态 HTTP 流媒体通常获得所能允许的最佳的连续的视频播放体验(best possible)，而不会出现画面停格或跳格(frame freezing or skipping)。另一方面， 基于客户端驱动的视频码率调整逻辑，大大提高了服务器端的可扩展性。同时，客户 端可以使用 HTTP byte-range 请求精确地控制预取视频的大小，即本地缓存视频的大 小，可以避免不必要的带宽浪费，降低服务商运营成本。 

由于以上优点，动态 HTTP 流媒体技术在国内外在互联网流媒体服务领域得到了广 泛的部署和应用。然而，由于延迟问题，DASH 在网络直播领域的应用还十分有限。减 小片段时长是降低延迟最直接的方式。然而，这种方式会导致对特定长度的媒体内容 其请求数量快速膨胀，从而导致请求负载的急剧上升。通过使用 HTTP/2 的服务器推 (Server Push)机制，FDH-DASH 为解决请求数量膨胀问题提供了可能，从而解决 DASH 网络直播中的延迟问题[3]。在 FDH-DASH 中，视频内容被编码为多个码率版本，每个 码率版本的视频进一步切割数秒长的视频片段。利用服务器推机制，FDH-DASH 客户端 发送一个请求，可以接收多个片段，通常称之为 K-PUSH，即一个请求对应 K 个片段[4]。 因此，通过使用服务器推送技术，FDH-DASH 可以在通过减小片段时长降低直播延迟的 同时，维持一个常量或可控数量的片段请求。然而，根据现有文献，对 FDH-DASH 的 研究还十分有限。