背景
大多数的 HAS 方案使用 HTTP/1.1 协议进行请求-回应的事务来取得需要的资源、缓冲取到的视频段并以线性的顺序播放。传统的 HAS 中，只需要 1 个 GET 请求来取得下一个视频的暂时的部分。只要视频段的持续时间比网络内的时延高，这种方法就可行。
在基于 VR 的 HAS 方案中，播放 1 条视频片段就需要取得多种资源：1 次 GET 请求需要同时请求基础的 tile 层和每个空间视频 tile。使用 4x4 的 tile 方案时，客户端需要发起不少于 17 次 GET 请求。使用 1 s 数量级的分段持续时间，即使是 20 ms 的微小网络延迟也会显着阻碍客户端和服务器之间的整体吞吐量，因此会导致较低的视频质量。
解决方案
使用多条持久的 TCP 连接
大多数的现代浏览器都支持同时建立并维持多达 6 条 TCP 连接来减少页面加载时间，并行地获取请求的资源。这允许增加整体吞吐量，并部分消除网络延迟引入的空闲 RTT 周期。
类似地，基于 VR 的 HAS 客户端可以使用多个 TCP 连接并行下载不同的 tile。
使用 HTTP/2 协议的服务端 push 特性
HTTP/2 协议引入了请求和相应的多路复用、头部压缩和请求优先级的特性，这可以减少页面加载时间。
服务端直接 push 短视频片段可以减少视频的启动时间和端到端延迟。
并且，服务端 push 特性可以应用在基于 tile 的 VR 视频推流中，客户端可以向服务器同时请求一条视频片段的所有 tile。
服务端可以使用特制的请求处理器，允许客户端为每个 tile 定义一系列质量等级。
因此可以将应用的启发式自适应的速率的决定传达给服务器，这允许客户端以期望的质量级别取得所有图块。