浏览器seek视频时重复请求已缓冲数据的原因及解决方案

当用户在视频中拖动进度条执行seek跳转操作时，浏览器会持续发起HTTP请求，获取那些本应已经完成缓冲存储的视频字节范围数据。

以下为最小可复现代码样例，复现操作方式：快速拖动视频的播放时间控制条跳转播放位置，同时查看浏览器网络请求日志即可观察到重复请求现象。

window.onload = function() {
  var myVideo = document.getElementById('my-video');

  myVideo.addEventListener('progress', function() {
    var bufferedEnd = myVideo.buffered.end(myVideo.buffered.length - 1);
    var duration = myVideo.duration;
    if (duration > 0) {
      document.getElementById('buffered-amount').style.width = ((bufferedEnd / duration) * 100) + "%";
    }
  });

  myVideo.addEventListener('timeupdate', function() {
    var duration = myVideo.duration;
    if (duration > 0) {
      document.getElementById('progress-amount').style.width = ((myVideo.currentTime / duration) * 100) + "%";
    }
  });
}

.buffered {
  height: 20px;
  position: relative;
  background: #555;
  width: 300px;
}

#buffered-amount {
  display: block;
  height: 100%;
  background-color: #777;
  width: 0;
}

.progress {
  margin-top: -20px;
  height: 20px;
  position: relative;
  width: 300px;
}

#progress-amount {
  display: block;
  height: 100%;
  background-color: #595;
  width: 0;
}

<video id="my-video" controls preload="auto">
  <source src="your-video-file.mp4" type="video/mp4">
</video>
<div class="buffered">
  <span id="buffered-amount"></span>
</div>
<div class="progress">
  <span id="progress-amount"></span>
</div>

产生原因 #

这个现象不是浏览器bug，核心诱因分为三类：

• MP4文件索引位置错误：MP4格式的moov atom是存储时间戳、字节偏移映射关系的核心索引块，如果这个块被放在文件尾部，浏览器无法在未下载完整文件的情况下拿到全量索引，哪怕目标位置的片段已经被缓存，seek时也会重新发起请求拉取对应索引和片段。
• 服务端范围请求/缓存配置不符合规范：
  • 未返回Accept-Ranges: bytes响应头，浏览器不会启用可靠的分片缓存机制
  • 范围请求返回的Content-Range格式不标准、状态码未使用206，会导致浏览器无法将已缓存分片和当前请求匹配
  • 视频资源未配置合理的缓存头（Cache-Control/ETag/Last-Modified），或URL带动态变化的签名参数，浏览器会判定缓存未命中
• 浏览器默认媒体缓存策略限制：浏览器给单个媒体元素分配的缓存空间有上限（通常根据设备内存动态调整，范围在几十到上百MB），当已缓冲内容超过阈值时，较早的分片会被自动回收，seek到对应位置时自然会重新发起请求。

规避方法 #

• 优化MP4文件结构：使用ffmpeg处理视频文件，将moov atom前置，这是网页端MP4播放的标准优化项，可解决绝大多数seek重复请求问题，处理命令如下：

  ffmpeg -i 输入文件.mp4 -c copy -movflags +faststart 输出文件.mp4
  

• 校准服务端配置：
  • 确保视频资源响应头包含Accept-Ranges: bytes
  • 处理Range请求时返回标准206状态码，Content-Range头严格遵循bytes 起始偏移-结束偏移/文件总大小格式
  • 给静态视频资源配置合理的强缓存规则，返回固定的ETag/Last-Modified标识；如果使用URL签名，保证同一视频在签名有效期内URL参数固定，不要在播放过程中动态生成新签名
• 长视频场景换用分片流媒体方案：如果是时长超过10分钟的长视频，不要用原生MP4渐进式加载，改用HLS/DASH协议配合MSE实现自主的分片缓存管理，完全可控已下载分片的生命周期，避免浏览器默认缓存策略的限制。

注意：原生video元素的网络请求由浏览器内核控制，前端JS无法直接拦截，所有优化都要从文件结构、服务端配置、传输协议选型三个层面落地。

内容的提问来源于stack exchange，提问作者Derek Pollard