HTML5视频分片加载实际工作原理及相关请求异常问题咨询

请求逻辑拆解 #

你观察到的混乱请求序列是 Chromium 媒体引擎、MP4 容器特性、服务端配置共同作用的结果，各请求的作用如下：

• 首次请求 Range: bytes=0-：浏览器默认先拉取文件开头片段，目的是校验文件类型，同时查找 MP4 的核心元数据块 moov box（存储视频时长、码率、关键帧索引、音视频轨道信息等播放必需数据）。
• 尾部200KB请求 Range: bytes=100237312-：浏览器读取开头片段后，发现 moov box 不在文件头部（绝大多数默认压制的MP4都会把moov放在文件尾部，只有做过快速启动优化的文件才会将moov移到头部），因此中断首次请求，直接拉取文件尾部片段查找moov，拿到元数据后才能完成播放初始化。
• 32KB、6MB起始的后续请求：
  1. 核心诱因是服务端错误开启了 MP4 文件的 gzip 压缩：你的第一条响应头携带 content-encoding: gzip，而 MP4 本身已是高度压缩的媒体格式，gzip 不会带来体积收益，反而因为gzip是流式压缩格式，压缩后的字节与原始文件字节没有固定映射关系，导致基于原始文件字节的Range请求完全失效，最终出现「响应大小与请求范围大小不匹配」的现象。
  2. 浏览器识别到Range请求异常，或拿到moov后确认视频第一个可播放关键帧的字节位置在6MB左右，就会中断前面无效的请求，重新从对应位置发起请求拉取可播放的媒体流。

长存活请求的服务端影响 #

最后一个请求长期保持存活是 Chromium 边下边播的默认逻辑：缓冲足够播放的内容后，浏览器会暂停下载但保留连接，后续播放到缓冲末尾时可直接续传，不需要重新走TCP握手、TLS协商流程，降低加载延迟。
对Apache服务端的影响分两种场景：

• 若使用老旧的 prefork MPM 模式：每个连接独占一个工作进程，大量这类闲置连接会快速占满进程池，导致新请求无法响应，负面影响较大。
• 若使用默认的 event MPM 模式：闲置连接会被放入独立的监听队列，不占用工作进程，常规并发量下几乎没有负面影响。

优化建议 #

• 服务端配置中禁用 MP4、WebM、MOV 等已压缩媒体文件的 gzip 压缩，恢复Range请求的正常逻辑。
• 压制MP4时添加快速启动参数，将moov box移到文件头部，例如用FFmpeg压制时添加 -movflags +faststart 参数，可减少额外的尾部Range请求，加快首帧加载速度。
• 高并发场景下可适当调低 Apache KeepAliveTimeout 参数，减少闲置连接的留存时间。

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